指定されたUPnPUniversalPlugandPlayのサービスを提供するためのプログラムをインストールするための、UPnPの特定のサービスを、端末が探索し、前記特定のサービスを提供するデバイスが、前記端末に応答を返し、前記端末が、前記応答により検出される前記特定のサービスに対して、UPnPの新規サービスを提供するための新規プログラムの前記デバイスへのインストールに関わるインストール関連通知を送信し、前記デバイスが、前記特定のサービスを提供するための特定のプログラムにしたがって動作することによって、前記インストール関連通知の受信の後に前記新規プログラムを取得するとともに取得した前記新規プログラムを前記デバイスにインストールし、前記デバイスが、インストールした前記新規プログラムにしたがって動作することにより、前記新規サービスを前記端末に提供することを特徴とするサービス提供方法。前記インストール関連通知は、前記新規サービスを指定するサービス指定情報を含み、前記サービス提供方法は、さらに、前記サービス指定情報と対応づけて前記新規プログラムを格納しており、前記端末に含まれるかまたは他のコンピュータに含まれる管理部に対して、前記デバイスが、前記端末からの前記インストール関連通知に含まれる前記サービス指定情報を通知し、前記管理部が、前記サービス指定情報の通知に応じて、前記新規プログラムを前記デバイスに送信することを含み、前記デバイスは、前記管理部から前記新規プログラムを受信することにより、前記新規プログラムを取得することを特徴とする請求項1に記載のサービス提供方法。前記インストール関連通知は、前記新規プログラムを受信するための準備を行うよう、前記デバイスに促す通知であり、前記サービス提供方法は、さらに、特定の環境に前記デバイスが存在しているとき、検出装置が、前記デバイスが前記特定の環境下にあることを示す検出通知を送信し、前記新規サービスを指定するサービス指定情報および前記特定の環境と対応づけて前記新規プログラムを格納する管理部が、前記検出通知の受信に応じて、前記新規プログラムを前記デバイスに送信することを含み、前記デバイスは、前記管理部から前記新規プログラムを受信することにより、前記新規プログラムを取得することを特徴とする請求項1に記載のサービス提供方法。端末が、デバイスの提供するUPnPのサービスを検出し、前記端末が、前記デバイスに含まれるかまたは他のコンピュータに含まれる管理部に対して、前記サービスを識別するサービス識別情報を通知し、前記サービスを利用するためのUPnPの特定のコントローラを実現するプログラムであって、通知された前記サービス識別情報と対応づけられて前記管理部に格納されている特定のコントローラプログラムを、前記管理部が前記端末に送信し、前記端末が、前記特定のコントローラプログラムを受信し、前記端末が、受信した前記特定のコントローラプログラムを前記端末にインストールし、前記端末が、インストールした前記特定のコントローラプログラムにしたがって動作することにより、検出した前記サービスを利用するための制御メッセージを、検出した前記サービスに対して与えることを特徴とするサービス利用方法。前記管理部は、前記サービスを含む複数のサービスそれぞれについて、当該サービスを識別するサービス識別情報および当該サービスが利用される環境と対応づけて、当該サービスを利用するためのUPnPのコントローラのプログラムを格納しており、前記サービス利用方法は、さらに、特定の環境に前記端末が存在しているときに、検出装置が、前記端末が前記特定の環境下にあることを示す検出通知を前記管理部に送信することを含み、前記管理部は、前記検出通知を受信すると、前記端末から通知された前記サービス識別情報と前記特定の環境とに対応づけて格納している前記特定のコントローラプログラムを検索し、検索により見つけた前記特定のコントローラプログラムを前記端末に送信することを特徴とする請求項4に記載のサービス利用方法。第1の端末と第2の端末と管理装置を含むシステムで実行される方法であって、UPnPUniversalPlugandPlayのサービスを提供するためのサービスプログラムと、UPnPの何らかのサービスを利用するためのUPnPのコントローラを実現するためのコントローラプログラムのいずれが指定されても、指定されたプログラムをインストールするためのUPnPのサービスである更新サービスを、前記第1の端末と前記第2の端末がともに提供しており、前記第1の端末と前記第2の端末が特定の環境に入ると、前記第1の端末と前記第2の端末が前記特定の環境下にあることを示す検出通知を、検出装置が送信し、1つ以上のUPnPのサービスのそれぞれについて、当該サービスと、当該サービスのインストール先の端末であるサービス提供端末の種類と、当該サービスを利用するためのコントローラと、当該コントローラのインストール先の端末であるコントローラ端末の種類と、当該サービスが利用される環境とを、互いに対応づける条件情報を、前記管理装置が格納しており、前記条件情報により前記特定の環境と対応づけられているサービス提供端末の種類が、前記第1の端末の前記種類と一致し、かつ、前記条件情報により前記特定の環境と対応づけられているコントローラ端末の種類が、前記第2の端末の前記種類と一致する第1の場合には、前記検出通知の受信に応じて、前記管理装置が、前記条件情報により前記特定の環境と対応づけられている特定のサービスを提供するための特定のサービスプログラムを前記第1の端末に送信するとともに、前記条件情報により前記特定の環境と対応づけられている特定のコントローラを実現するための特定のコントローラプログラムを前記第2の端末に送信し、前記第1の端末が、前記更新サービスによる処理の一部として、前記特定のサービスプログラムの前記第1の端末へのインストールを実行し、前記第2の端末が、前記更新サービスによる処理の一部として、前記特定のコントローラプログラムの前記第2の端末へのインストールを実行し、前記条件情報により前記特定の環境と対応づけられているサービス提供端末の種類が、前記第2の端末の前記種類と一致し、かつ、前記条件情報により前記特定の環境と対応づけられているコントローラ端末の種類が、前記第1の端末の前記種類と一致する第2の場合には、前記検出通知の受信に応じて、前記管理装置が、前記特定のサービスプログラムを前記第2の端末に送信するとともに、前記特定のコントローラプログラムを前記第1の端末に送信し、前記第1の端末が、前記更新サービスによる処理の一部として、前記特定のコントローラプログラムの前記第1の端末へのインストールを実行し、前記第2の端末が、前記更新サービスによる処理の一部として、前記特定のサービスプログラムの前記第2の端末へのインストールを実行することを特徴とする方法。UPnPUniversalPlugandPlayの新規サービスを提供するための新規プログラムを、外部から与えられる通知の受信の後に取得してインストールするための、UPnPの特定のサービスを提供するデバイスと、端末であって、前記特定のサービスをUPnPのディスカバリプロトコルおよびディスクリプションプロトコルにしたがって探索する探索部と、前記探索部が前記特定のサービスを検出すると、前記特定のサービスに対して、前記新規プログラムの前記デバイスへのインストールに関わるインストール関連通知を送信する第1の通知部と、前記デバイスが前記インストール関連通知の受信の後に前記デバイスに前記新規プログラムをインストールすると、前記新規サービスに対してUPnPのコントロールプロトコルにしたがって制御メッセージを与える第1の制御部と、を備えることを特徴とする端末と、を備えることを特徴とするシステム。近年、様々な電子機器においてソフトウェア制御が採用されており、ソフトウェアのインストールによる機能拡張が実現可能な電子機器の種類も増えてきた。また、UPnPの普及も進みつつあり、UPnPの多くのサービスは、ソフトウェアを用いて実現される。しかしながら、UPnPの分野においては、ソフトウェア制御の柔軟性を活かしてUPnPのサービスを動的に導入する技術は、まだまだ未発達である。本発明は、1つの側面では、UPnPのサービスの動的な導入を可能とすることを目的とする。一態様によるサービス提供方法では、指定されたUPnPのサービスを提供するためのプログラムをインストールするための、UPnPの特定のサービスを、端末が探索する。そして、前記特定のサービスを提供するデバイスが、前記端末に応答を返す。また、前記端末が、前記応答により検出される前記特定のサービスに対して、UPnPの新規サービスを提供するための新規プログラムの前記デバイスへのインストールに関わるインストール関連通知を送信する。さらに、前記デバイスが、前記特定のサービスを提供するための特定のプログラムにしたがって動作することによって、前記インストール関連通知の受信の後に前記新規プログラムを取得するとともに取得した前記新規プログラムを前記デバイスにインストールする。そして、前記デバイスが、インストールした前記新規プログラムにしたがって動作することにより、前記新規サービスを前記端末に提供する。上記サービス提供方法によれば、デバイスは、端末による探索に応じて、UPnPの新規サービスを端末に提供することができる。すなわち、上記サービス提供方法によれば、UPnPのサービスが動的にデバイスに導入される。以下、第1~第5実施形態について、図面を参照しながら詳細に説明する。第1および第3実施形態は、UPnPのサービスの動的な更新に関連し、第2および第4実施形態は、UPnPのコントローラすなわちコントロールポイントの動的な更新に関連する。また、第5実施形態は、UPnPのサービスとコントローラ双方の動的な更新に関連する。以下に説明するとおり、第1~第5実施形態のいずれによっても、UPnPの一層柔軟な利用が可能となる。なお、説明の便宜上、第1~第4実施形態に関しては、サービスを提供する装置をデバイスといい、コントローラとして動作する装置を端末という。また、詳しくは後述するとおり、第5実施形態では、2台の装置のどちらにサービスがインストールされどちらにコントローラがインストールされるかは環境に応じて動的に決まる。そのため、第5実施形態に関しては、2台の装置をともに端末という。しかし、これらのデバイスおよび端末という名称は、説明の便宜上のものにすぎない。さて、図1は、第1実施形態の動作シーケンス図である。また、図2は、第1実施形態のシステム構成図である。図2に示すように、第1実施形態のシステム100は、端末110とデバイス120とサービス管理装置130を含む。システム100内には、端末110以外の端末がさらにあってもよい。図1は、図2の端末110、デバイス120、およびサービス管理装置130、ならびに図2には不図示の端末140による動作シーケンスの例を示す。端末110は、通信機能とUPnPのコントローラ機能を有する端末であれば、どのような種類の端末であってもよい。例えば、端末110は、携帯電話、スマートフォン、タブレット端末、PDAPersonalDigitalAssistant、ノートPCPersonalComputerのような携帯端末であってもよいし、デスクトップPCであってもよい。端末140も端末110と同様である。デバイス120は、通信機能とUPnPのサービス提供機能を有する装置であり、製造工場からの出荷後にソフトウェアをインストールすることの可能な装置である。例えば、携帯電話、スマートフォン、タブレット端末、PDA、ノートPC、デスクトップPCなどがデバイス120として使われることもある。あるいは、組み込み型コンピュータを有するその他の種類の装置例えば、プリンタ、プロジェクタ、テレビ、録画装置、照明装置などがデバイス120として使われてもよい。端末110とデバイス120は、ネットワークを介して互いに通信することができる。同様に、端末140とデバイス120も、ネットワークを介して互いに通信することができる。サービス管理装置130は、例えば、ネットワークを介してデバイス120と通信可能なコンピュータであってもよい。あるいは、端末110がサービス管理装置130を含んでいてもよい。端末110とデバイス120とサービス管理装置130のさらなる詳細は、後ほど図2を参照して説明することにして、先に図1の動作シーケンスについて説明する。図1の動作シーケンスは、例えば、端末110が何らかのUPnPのサービスを利用しようとしたのに、当該サービスを提供するデバイスが見つからなかったという場合などに実行される。例えば、端末110のユーザは、ドキュメント表示サービスを利用したいかもしれない。すると、ユーザは、ドキュメント表示サービスを提供するデバイスを探索するよう端末110に指示するための入力を端末110に与える。端末110は、ユーザからの入力にしたがって、ドキュメント表示サービスを提供するデバイスを探索する。しかし、端末110の周囲には、ドキュメント表示サービスを提供するデバイスが存在しなかったとする。すると、端末110は、図1のステップS101の探索を実行する。以下のステップS101~S112の説明から明らかなとおり、図1の処理により、端末110は、プログラムをインストールすることによって、新たにドキュメント表示サービスを提供することが可能になるデバイスが周囲に存在するか否かを確認する。そして、もしそのようなデバイスが見つかれば、端末110は、見つかったデバイスに対して、ドキュメント表示サービスのプログラムをインストールして、ドキュメント表示サービスを提供せよと命令する。その結果、端末110は、ドキュメント表示サービスを利用することが可能となる。図1の処理は、以上のようにして所望のサービスを端末110で利用可能とするために、行われてもよい。もちろん、上記の端末110が何らかのUPnPのサービスを利用しようとしたのに、当該サービスを提供するデバイスが見つからなかったという場合以外の場合に、図1の処理が行われてもよい。つまり、図1の処理が開始されるトリガは、特に限定されない。具体的には、まずステップS101で、端末110がUPnPの特定のサービスを探索する。以下では説明の便宜上、この特定のサービスをサービス更新サービスという。サービス更新サービスは、指定されたUPnPのサービスを提供するためのプログラムをインストールするための、UPnPのサービスである。サービス更新サービスに対してインストール対象として指定されるサービスは、今まで存在しなかった全く新たなサービスであってもよいし、既存のサービスをアップグレードした新たなバージョンのサービスであってもよい。つまり、サービス更新サービスは、全く新たなサービスを追加するために使われることもあるし、既存のサービス更新するために使われることもある。なお、既存のサービスを更新することは、換言すれば、既存のサービスを新規サービスで上書きすることである。つまり、既存のサービスの更新も、広い意味では新規サービスの導入と見なせる。よって、以下では、追加と更新を特に区別しないことがある。また、サービス更新サービスは、指定されたUPnPのサービスを提供するためのプログラムをアンインストールするための機能を、さらに有していてもよい。つまり、サービス更新サービスは、既存のサービスの削除するための機能を有していてもよい。ステップS101における探索は、UPnPのディスカバリプロトコルであるSSDPSimpleServiceDiscoveryProtocolにしたがって行われる。具体的には、ステップS101で端末110は、Msearchメッセージを送信する。Msearchメッセージの送信は、具体的には、ネットワーク内へのマルチキャストである。図1の例では、デバイス120がサービス更新サービスを提供しているものとする。したがって、ステップS102で、デバイス120が端末110に応答を返す。ステップS102の応答は、具体的には、HTTPHypertextTransferProtocol応答である。ステップS102でのHTTP応答は、OKという意味を示す200というステータスコードを含む。ステップS102の応答の具体例は、後述の図5に示す。端末110は、ステップS102の応答を受信すると、次に、ステップS103~S106に示すとおり、UPnPのディスクリプションプロトコルにしたがって、デバイス120の詳細な情報を取得する。具体的には、ステップS103で端末110が、デバイス120のデバイス定義devicedescriptionを要求する。ステップS103での要求は、具体的には、GETメソッドが指定されたHTTP要求である。デバイス120は、ステップS103の要求を受信すると、ステップS104で、デバイス定義ファイルを端末110に送信する。デバイス定義ファイルは、XMLExtensibleMarkupLanguage形式で記述されており、デバイス120が提供するサービスについての情報を含む。上記のとおりデバイス120はサービス更新サービスを提供しているので、ステップS104で送信されるデバイス定義ファイルは、サービス更新サービスにアクセスするための情報を含む。したがって、端末110は、デバイス定義ファイルを受信すると、サービス更新サービスにアクセスするための情報を得ることができる。そこで、端末110は、次のステップS105で、サービス更新サービスのサービス定義servicedescriptionを要求する。ステップS105での要求も、具体的には、GETメソッドが指定されたHTTP要求である。デバイス120は、ステップS105の要求を受信すると、ステップS106で、サービス更新サービスのサービス定義ファイルを端末110に送信する。サービス定義ファイルもXML形式で記述されている。また、サービス更新サービスのサービス定義ファイルでは、サービス更新サービスを利用するために使われる制御メッセージアクションともいうの、名前や引数などが定義されている。以上のようにして、端末110は、デバイス120により提供されるサービス更新サービスを検出することができる。そして、端末110は、検出したサービス更新サービスに対して、ステップS107でコマンドを送信する。具体的には、ステップS107においてコマンドは、UPnPのコントロールプロトコルであるSOAPもとはSimpleObjectAccessProtocolの略だが今は何かの略語ではないによって送信される。ステップS107のコマンドは、端末110が利用しようとしたものの見つけられなかった新規サービス上記の例ではドキュメント表示サービスのインストールをデバイス120に命じるためのコマンドである。ステップS107のSOAPコマンドの具体例は、後述の図5に示す。ところで、上記のように、新規サービスのインストールは、既存の古いサービスの置き換えによる更新のために行われることもあるし、全く新規のサービスの追加のために行われることもある。よって、図1のステップS107にはサービス追加更新コマンドと書いてあるが、上記のとおり、更新の処理と追加の処理は同様である。デバイス120は、ステップS107のコマンドを受信すると、次のステップS108で端末110に応答を返す。ステップS108での応答は、具体的には、OKという意味を示す200というステータスコードを含むHTTP応答である。デバイス120は、さらにステップS109で、サービス管理装置130にサービスを要求する。より具体的には、デバイス120は、SOAPコマンドにおいて端末110により指定された新規サービスを提供するためのプログラムの送信を、サービス管理装置130に要求する。ステップS107のSOAPコマンドには、端末110が利用しようとする新規サービスを指定するサービス指定情報が含まれている。よって、デバイス120は、ステップS109で当該サービス指定情報をサービス管理装置130に通知することができる。つまり、デバイス120は、サービス指定情報の通知により、上記サービス指定情報で識別される新規サービスのプログラムの送信をサービス管理装置130に要求する。すると、次のステップS110でサービス管理装置130は、ステップS109で要求されたサービスより具体的には、当該サービスを提供するためのプログラムを含むデータを、デバイス120に送信する。デバイス120は、こうしてサービス管理装置130からプログラムを受信することにより、インストール対象のプログラムを取得する。そして、ステップS111でデバイス120は、取得したプログラムをデバイス120自身にインストールする。その結果、デバイス120は、新規サービスを提供することができるようになる。また、プログラムのインストールにより、デバイス120が提供するサービスが追加または更新されるので、デバイス120は、デバイス定義ファイルを書き換える。デバイス120は、追加または更新されたサービスのサービス定義ファイルも保存する。また、ステップS112でデバイス120は、新規サービスの提供が可能になったことすなわちサービス追加更新イベントの発生を通知する。ステップS112での通知は、UPnPのイベント通知プロトコルであるGENAGeneralEventNotificationArchitectureにしたがって行われる。もしくは、ステップS112での通知は、UPnP1.1より導入されたプロトコルであるMulticastEventingを用いてもよい。GENAを用いてイベントを通知する場合は、後述するように、予め所定のプロトコルにしたがい、端末がデバイスに対して購読要求subscriptionrequestを通知しておく必要がある。MulticastEventingを用いる場合は、事前に端末によるデバイスへの購読要求通知を行う必要はない。以下の例でGENAにより行っているイベント通知は、UPnP1.1以降では、MulticastEventingに置き換えてもよい。図1の例では、ステップS112でデバイス120がサービス追加更新イベントの通知をGENAのプロトコルにしたがって通知する。よって、端末110だけでなく端末140も、デバイス120が新規サービスの提供を開始したことを認識することができる。また、図1には示されていないが、上記のようにしてデバイス120が新規サービスの提供を開始した後、端末110は、ステップS103~S104と同様にしてデバイス120のデバイス定義ファイルを再度取得する。こうして取得されるデバイス定義ファイルは、ステップS111で更新されたものであり、インストールされた新規サービスにアクセスするための情報を含む。したがって、端末110は、ステップS105~S106と同様にして、新規サービスについてのサービス定義ファイルを取得することができる。そして、端末110は、取得したサービス定義ファイルに定義されている制御メッセージを、適宜ステップS107と同様にしてSOAPによりデバイス120に送信することで、新規サービスを利用することができる。もちろん、端末140も同様にして、デバイス120の新規サービスを利用することができる。続いて、図2を参照して、端末110とデバイス120とサービス管理装置130の詳細について説明する。図2に示すように、端末110には、UPnPコントローラ111が実装されている。UPnPコントローラ111は、サービス更新サービスに対して制御メッセージつまりコマンドを与える機能を有する、UPnPのコントローラである。図1に示した端末110の動作は、具体的にはUPnPコントローラ111により実行される。また、デバイス120は、UPnPサービス提供部121を含む。UPnPサービス提供部121は、サービス更新サービス122を提供する。図1のステップS109の要求、ステップS110の受信、ステップS111のインストール、およびステップS112の通知は、具体的には、サービス更新サービス122により行われる。つまり、デバイス120は、サービス更新サービス122を提供するためのプログラムを実行することにより、ステップS109~S112の処理を行う。なお、図2には、図1のステップS111でインストールされる新規サービス123が破線で示されている。新規サービス123のプログラムのインストール後には、UPnPサービス提供部121は、新規サービス123も提供することが可能である。また、UPnPコントローラ111は、サービス更新サービス122に対して制御メッセージを与える機能だけでなく、新規サービス123に対して制御メッセージを与える機能を有していてもよい。さて、サービス管理装置130は格納部131を有する。格納部131には、新規サービス123を提供するためのプログラムである新規サービスプログラム132が、新規サービス123を識別する情報と対応づけられて、格納されている。新規サービスプログラム132は、図1のステップS110でデバイス120に送信され、ステップS111でデバイス120にインストールされる。そして、インストールの結果として、デバイス120は新規サービス123の提供を開始する。なお、簡単化のため、図1には1つの新規サービスプログラム132のみが示されている。しかし、格納部131は、複数のサービスそれぞれのプログラムを、当該サービスを識別する情報と対応づけて格納していてもよい。つまり、格納部131は、様々なサービスを提供するための各種プログラムのレポジトリであってもよい。続いて、図3~5を参照して、第1実施形態で使われるファイルとメッセージの例について説明する。図3は、サービス更新サービス122のインストールされたデバイス120に関するデバイス定義ファイルの例である。図4は、サービス更新サービス122のサービス定義ファイルの例である。また、図5は、端末110とデバイス120の間で送受信されるメッセージの例である。図3のデバイス定義ファイル150は、新規サービス123を提供するための新規サービスプログラム132が図1のステップS111でインストールされるのにともなって更新された、デバイス定義ファイルの具体例である。なお、図3には参照の便宜のため、左側に行番号が示してある。図4などの他のいくつかの図においても、同様の行番号が示してある。UPnPのデバイス定義ファイルの一般的な形式は公知である。よって、デバイス定義ファイル150のうちサービス更新サービス122と直接関係しない部分については、適宜、説明を省略または簡略化する。5~9行目には、デバイス120全体に関する情報例えば、9行目のUDNUniqueDeviceNameなどが記載されている。そして、10~25行目には、デバイス120が提供するサービスのリストが記載されている。デバイス定義ファイル150の例では、10~25行目のリストには、2つのサービスの情報が記載されている。具体的には、11~17行目には、サービス更新サービス122の情報が記載されている。そして、18~24行目には、サービス更新サービス122によってデバイス120にインストールされたドキュメント表示サービスつまり、図2の新規サービス123の具体例の情報が記載されている。11~17行目に記載されているサービス更新サービス122に関する情報は、具体的には以下の情報を含む。12行目には、サービス更新サービス122の種類が記載されている。また、13行目には、サービス更新サービス122のIDidentifierが記載されている。14行目には、サービス更新サービス122のサービス定義ファイル例えば図4のサービス定義ファイル151のある場所のURIUniformResourceIdentifierが記載されている。例えば図1のステップS104で端末110は、デバイス定義ファイル150を取得することで、14行目から、サービス更新サービス122のサービス定義ファイル151のURIを認識することができる。端末110は、デバイス定義ファイル150の14行目のURIを指定してステップS105の要求を送信することで、ステップS106でサービス定義ファイル151を取得することができる。また、例えば図1のステップS107のSOAPコマンドのように、何らかの制御メッセージがサービス更新サービス122に送信されることがある。15行目には、このようなサービス更新サービス122に対する制御メッセージの宛先のURIが記載されている。つまり、端末110は、デバイス定義ファイル150から、ステップS107のSOAPコマンドをどこに宛てて送信すればよいかを認識することができる。また、端末110は、サービス更新サービス122の状態変数statevariableが変化したときにGENAによるイベント通知を受け取れるようにするために、購読要求subscriptionrequestをサービス更新サービス122に送信してもよい。もちろん、端末140も同様に、購読要求を送信してもよい。16行目には、購読要求の宛先のURIが記載されている。例えば、図1の例では、サービス更新サービス122は、ステップS107のコマンドを送信した端末110を、サービス更新サービス122の特定の状態変数具体的には、後述の状態変数UpdateTimeの購読を要求したものと見なす。また、図1の例では、端末140も、予めデバイス120に対して、状態変数UpdateTimeの購読を要求していたものと仮定する。そのため、図1の例では、ステップS112で、GENAによる通知が端末110と端末140に送信されている。デバイス定義ファイル150においては、以上説明した12~16行目の情報が、11行目と17行目のタグにはさまれている。したがって、端末110は、デバイス定義ファイル150の11~17行目から、サービス更新サービス122にアクセスしてサービス更新サービス122を利用するための情報を得ることができる。なお、18~24行目に記載された、ドキュメント表示サービスに関する情報も、11~17行目の情報と同様の形式である。よって、18~24行目についての詳細な説明は省略する。また、以上の説明から明らかなように、図1のステップS104で送信される更新前のデバイス定義ファイルは、図3のデバイス定義ファイル150の18~24行目がない状態のものである。換言すれば、ステップS111でのインストールにともなって、図3の18~24行が追加される。さて、次に図4を参照して、図1のステップS106で送信される、サービス更新サービス122のサービス定義ファイルの詳細について説明する。なお、説明の都合上、図4には、第1実施形態では使われないアクションや状態変数についての定義も含むサービス定義ファイル151が例示されており、これらのアクションや状態変数は、後述の第3実施形態で使われる。具体的には、19~26行目のListenという名前のアクションと、39~42行目のServerUriおよびListeningという状態変数は、第1実施形態では使われず、第3実施形態で使われる。よって、ここでは19~26行目と39~42行目の説明は省略する。また、特に混乱のおそれはないので、以下の第1実施形態の説明におけるサービス定義ファイル151という用語は、19~26行目と39~42行目のない状態のサービス定義ファイルを指すものとする。また、UPnPのサービス定義の一般的な形式は公知である。そこで、以下ではサービス定義ファイル151の形式についての説明は省略し、サービス定義ファイル151の内容について主に説明する。さて、サービス定義ファイル151は、図3のデバイス定義ファイル150の14行目に記載されたURIで識別される場所具体的にはデバイス120内の記憶装置に記憶されており、図1のステップS106で送信される。4~33行目には、サービス更新サービス122に関して定義されているアクションのリストが記載されている。具体的には、5~12行目では、サービスの追加および更新用の、UpdateServiceという名前のアクションが定義されている。このアクションは2つの入力引数をとる。1番目の引数は、argServiceNameという名前であり、追加または更新の対象のサービスを識別するためのサービス識別情報例えばURNUniformResourceNameなどの名前でもよいし、何らかのIDでもよいを表す。また、このargServiceNameという引数は、後述のServiceNameという状態変数と関係しており、具体的には、サービス更新サービス122は、argServiceNameという引数に指定された値をServiceNameという状態変数に代入する。2番目の引数は、argServiceUriという名前であり、追加または更新の対象のサービスのデータつまりサービスのプログラムを含むデータが記憶されている場所を示す。具体的には、URIがargServiceUriという引数として指定される。例えば、図1のステップS107のSOAPコマンドは、具体的にはUpdateServiceというアクションを指定する制御メッセージである。そして、ステップS107では、図2のサービス管理装置130の格納部131内の新規サービスプログラム132が記憶されている場所のURIが、argServiceUriという引数として指定される。なお、端末110にとっては、以上の2つの引数として指定する2つの値は、既知である。また、13~18行目では、サービスの削除用の、DeleteServiceという名前のアクションが定義されている。なお、DeleteServiceというアクションは省略可能であり、実施形態によっては、サービス更新サービス122がサービスの削除機能を持たなくてもよい。図4の例では、DeleteServiceというアクションは、argServiceNameという名前の1つの入力引数をとる。この引数は、削除対象のサービスを識別するためのサービス識別情報例えばサービスの名前を表す。また、この引数も、後述のServiceNameという状態変数と関係しており、具体的には、サービス更新サービス122は、argServiceNameという引数に指定された値をServiceNameという状態変数に代入する。19~26行目のListenという名前のアクションについては、第3実施形態とともに後述する。27~32行目では、サービス更新サービス122によってサービスの追加または更新が行われた最終日時を、端末例えば端末110が取得するための、GetUpdateTimeという名前のアクションが定義されている。なお、GetUpdateTimeというアクションは省略可能である。図4の例では、GetUpdateTimeというアクションは、入力引数をとらず、ResultUpdateTimeという名前の返り値を返す。ResultUpdateTimeという返り値は、具体的には、後述のUpdateTimeという状態変数の値である。また、34~45行目には、サービス更新サービス122に関して定義されている状態変数のリストが記載されている。具体的には、35~36行目には、ServiceNameという名前の文字列型の状態変数が定義されている。ServiceNameという状態変数は、サービス更新サービス122が最後に追加、更新、または削除したサービスの識別情報例えばサービスの名前を示す。そして、37~38行目には、ServiceUriという名前のURI型の状態変数が定義されている。ServiceUriという状態変数は、サービス更新サービス122が最後に追加または更新したサービスのプログラムがどこから取得されたのかを示す。39~42行目については、第3実施形態とともに後述する。また、43~44行目には、UpdateTimeという名前の日付時刻型の状態変数が定義されている。UpdateTimeという状態変数は、サービス更新サービス122によってサービスの追加または更新が行われた最終日時以下、追加と更新を区別せず、単に最終更新日時というを示す。次に、図5を参照して、端末110とデバイス120の間で送受信されるメッセージの例を説明する。図5の応答152は、図1のステップS102で送信されるHTTP応答の具体例であり、図5のSOAPコマンド153は、図1のステップS107で送信されるSOAPコマンドの具体例である。応答152の1行目は、HTTPのステータスラインである。2行目は、探索対象ST:searchtargetがルートデバイスであることを示す。3行目は、USNUniqueServiceNameを示す。4行目には、応答152を返すデバイス120のデバイス定義ファイル具体的には図3のデバイス定義ファイル150のある場所を示すURIが記載されている。5行目は、応答152がHTTPヘッダのみを含むつまり、エンティティボディを含まないことを示す。例えば、図1の端末110は、ステップS102で応答152を受信すると、応答152の4行目のURIを宛先としてステップS103でHTTP要求を送信する。すると、端末110は、ステップS104で図3のデバイス定義ファイル150を取得することができる。さて、図5に示すように、図1のステップS107で送信されるSOAPコマンド153は、具体的にはPOSTメソッドのHTTP要求である。SOAPコマンド153の1行目は、HTTPのリクエストラインである。1行目には、図3のデバイス定義ファイル150の15行目に記載されたURIが、HTTP要求の宛先として指定されている。2行目のリクエストヘッダフィールドには、SOAPコマンド153の宛先のホストであるデバイス120の、アドレスとポート番号が指定されている。3行目は、図3の11~17行目のように定義されるサービス更新サービス122に対して、SOAPコマンド153の送信元の端末110が、図4の5~12行目のように定義されるUpdateServiceというアクションの実行を命令することを示す。4~5行目は一般的なHTTPヘッダフィールドである。7~16行目はHTTP要求のエンティティボディであり、7~16行目に具体的な制御メッセージが記載されている。具体的には、11~14行目において、UpdateServiceというアクションに与える2つの入力引数が指定されている。図4の5~12行目に示すように、UpdateServiceというアクションは、argServiceNameとargServiceUriという2つの引数をとる。SOAPコマンド153の12行目では、argServiceNameという引数の値として、ドキュメント表示サービスつまり、インストール対象の新規サービス123の名前であるDocViewSrvという文字列が指定されている。また、13行目では、argServiceUriという引数の値として、ドキュメント表示サービスのデータつまり、新規サービスプログラム132を含むデータが格納された場所のURIが指定されている。したがって、図1のステップS107でSOAPコマンド153を受信したデバイス120より具体的には、デバイス120内のサービス更新サービス122は、SOAPコマンド153の12~13行目から、インストール対象を認識することができる。すなわち、デバイス120は、SOAPコマンド153の13行目のURIを宛先として、図1のステップS109の要求を送信することができる。また、デバイス120は、当該要求の中に、インストール対象のサービスを識別するサービス名として、SOAPコマンド153の12行目に記載された名前を含めることができる。ところで、図1のステップS107でのコマンドの受信から、ステップS112でのイベント通知までの処理は、デバイス120が図6のフローチャートにしたがって動作することにより、実現される。図6は、サービス追加更新コマンドの受信に応じてデバイス120が行う処理のフローチャートである。まず、ステップS201で、デバイス120のUPnPサービス提供部121が、端末110より具体的には、端末110内のUPnPコントローラ111から、図1のステップS107のサービス追加更新コマンドを受信する。図5のSOAPコマンド153の12~13行目に示すように、ステップS201で受信されるコマンドは、追加または更新の対象であるサービスの名前とURIを引数とする。UPnPサービス提供部121は、コマンドを受信すると、図1のステップS108のとおり、HTTP応答を返す。また、UPnPサービス提供部121は、受信されたSOAPコマンド153がサービス更新サービス122に対するコマンドであることを、SOAPコマンド153の1行目から認識することができる。よって、UPnPサービス提供部121はサービス更新サービス122を呼び出す。すると、次のステップS202でサービス更新サービス122が、通知されたURIにあるサービス管理装置130に対して、通知された名前のサービスを要求する。より具体的には、サービス更新サービス122は、SOAPコマンド153の13行目に記載されたURIつまり新規サービスプログラム132のURIを宛先として、12行目の名前で識別されるサービスを要求する。ステップS202の要求は、図1のステップS109に相当する。なお、ステップS202の要求は、任意の形式の要求でよく、例えばHTTP要求であってもよいし、その他の形式の要求であってもよい。また、図1のステップS110に示すように、サービス更新サービス122は、要求したサービスのデータを、サービス管理装置130から受信する。なお、こうしてステップS202で受信されるデータは、具体的には、例えば、新規サービスプログラム132と、新規サービス123のサービス定義ファイルとを含むデータでもよい。受信後、ステップS203においてサービス更新サービス122は、受信したサービスのデータに基づいて、以下の3つの処理を行う。第1に、サービス更新サービス122は、デバイス120のデバイス定義ファイルを更新する。具体的には、例えば、サービス更新サービス122は、図3の18~24行目をデバイス定義ファイル150に追加し、更新後のデバイス定義ファイル150をデバイス120の記憶装置に記憶する。第2に、サービス更新サービス122は、受信したサービスのサービス定義ファイルを追加または更新する。全く新規のサービスがデバイス120にインストールされる場合は、インストールするサービスのサービス定義ファイルはデバイス120内にない。そこで、この場合、サービス更新サービス122は、サービス管理装置130から受信したデータに基づき、新たなサービス定義ファイルを作成して保存する。また、デバイス120にインストール済みの既存のサービスの新規バージョンがデバイス120にインストールされる場合つまり既存のサービスが更新される場合は、当該既存のサービスのサービス定義ファイルはデバイス120内に既にある。そこで、この場合、サービス更新サービス122は、サービス管理装置130から受信したデータに基づき、既存のサービス定義ファイルを更新する。第3に、サービス更新サービス122は、受信したサービスのプログラムつまり新規サービスプログラム132をデバイス120にインストールする。サービス更新サービス122は、以上の3つの処理をステップS203で行った後、ステップS204で、図4の43行目に示すUpdateTimeという状態変数の値を現在時刻に更新する。ステップS203~S204は、図1のステップS111に対応する。そして、次のステップS205でサービス更新サービス122は、GENAにより、デバイス120の周辺の端末例えば、図1では端末110と端末140に対して、ステップS204で更新したUpdateTimeという状態変数の値を通知する。ステップS205は図1のステップS112に対応する。以上説明した第1実施形態によれば、端末110は、たとえ所望のサービスを既に提供しているデバイスを見つけられなくても、所望のサービスをサービス更新サービス122に通知することで、所望のサービスを受けられるようになる。なぜなら、サービス更新サービス122が、通知されたサービスのプログラムつまり新規サービスプログラム132をデバイス120にインストールし、デバイス120が上記所望のサービスつまり新規サービス123の提供を開始するからである。このように、第1実施形態によれば、UPnPの新規サービスプログラム132が動的にデバイス120に導入されるので、ユーザの利便性が高まる。以上のような第1実施形態の利点についてさらに詳しく説明すれば、以下のとおりである。例えば、比較例として、第1のサービスを提供する第1のデバイスが、第2のデバイスが提供する第2のサービスを利用して第1のサービスを拡張し、拡張したサービスを提供する技術を想定する。この比較例では、第1のデバイスはいかようにでもサービスを拡張することができるわけではない。つまり、この比較例において実現可能な機能拡張は、第1のデバイスからアクセス可能な既存の第2のデバイスがどのようなサービスを提供するかによって、限定されてしまう。また、この比較例における機能拡張では、ユーザが今どのサービスの利用を望んでいるかという、ユーザの要望に柔軟に対応することができない。つまり、この比較例では、第1のデバイスの外部から、ユーザの要望に応じた機能拡張を行うように第1のデバイスに命令することができない。あるいは、たとえユーザの所望するサービスを第1のデバイスに通知することができたとしても、この比較例では、実現可能な機能拡張が限定的なので、ユーザの要望に対処不能なことが多い。つまり、この比較例によれば、UPnPのサービスの動的な導入あるいは更新が可能ではあるが、非常に限定的である。他方、あるデバイス例えばデバイス120が発売された時点では予想されていなかったような、新たなサービスが、新たに生まれることがあり得る。つまり、ユーザが将来どのようなサービスの利用を望むようになるかを、予め知ることはできない。また、既存のサービスに関しても、もちろん、世の中のあらゆるデバイスが当該既存のサービスを提供しているわけではない。そして、当該既存のサービスを提供しているデバイスが近くにない状況下で、ユーザが当該既存のサービスを利用したくなることもあり得る。したがって、ユーザがあるサービスを利用したいと思ったときに、当該サービスを既に提供しているデバイスがユーザの近くに存在していないという状況は、ユーザが望むサービスが全く新規であるか既存のものであるかを問わず、起こり得る。そのような状況下でユーザが所望のサービスを受けられるようにするための、動的なサービスの導入は、ユーザの利便性を高めるうえで非常に有益である。ここで、ユーザが、ある任意のサービスの利用を望んだと仮定する。また、ユーザが望んだ当該サービスは、ユーザの近くに存在する既存のデバイス例えばデバイス120のハードウェア以外の新たなハードウェアを、必要としないものとする。つまり、もし当該既存のデバイスが、ソフトウェアのインストールが可能な種類のものであれば、当該既存のデバイスは、ユーザが望むサービスを提供する潜在的可能性を持っている。そして、近年では、汎用的なPCのみならず、携帯電話、スマートフォン、タブレット端末、PDAなどの携帯端末も、製造工場からの出荷後のソフトウェアのインストールが可能である。また、プリンタ、プロジェクタ、テレビ、録画装置、照明装置などの種々の装置も、製造工場からの出荷後のソフトウェアのインストールが可能な種類のものが増えてきた。つまり、ソフトウェアのインストールによる機能拡張が可能なデバイスの普及が進んできている。そして、そのようなデバイスの普及により、デバイスが任意のサービスを新たに提供するための基盤は、整いつつある。しかし、そのような基盤は、十分に活用されているとはまだ言い難く、UPnPの機能拡張も、上記の比較例のように限定的なレベルにとどまっている。それに対し、第1実施形態によれば、予めサービス管理装置130に新規サービスプログラム132が格納されており、デバイス120がサービス更新サービス122を提供してさえいれば、ユーザは、端末110を介して任意の新規サービス123を受けられる。より正確には、ユーザが望む新規サービス123が、デバイス120の既存のハードウェア以外のハードウェアを必要とせず、ソフトウェアにより実現可能なものであれば、ユーザは端末110を介してデバイス120から任意の新規サービス123を受けられる。このように、第1実施形態によれば、非常に柔軟に、UPnPのサービスの動的な更新を行うことが可能となる。したがって、第1実施形態は、ユーザの利便性向上に資するところが大きい。また、第1実施形態のサービス更新サービス122は、UPnPのサービスの1種である。サービス更新サービス122がUPnPのサービスであることは、以下のような2つの利点をもたらす。第1に、図1のステップS101~S108に示すように、端末110は、UPnPのプロトコルにしたがって、サービス更新サービス122に対して新規サービス123のインストールを命じることができる。つまり、端末110は、新規の特殊なプロトコルを使用する必要がない。第2に、サービス更新サービス122を多くのデバイス120に組み込むことが容易であり、利便性向上に有益なサービス更新サービス122の普及が促進される。理由は次のとおりである。種々のOSOperatingSystem用にUPnPに関するライブラリが開発されている。そして、UPnPに関する機能は、ライブラリを用いて実装されることが多い。ここで、サービス更新サービス122はUPnPのサービスの1種なので、UPnP用のライブラリの中に、サービス更新サービス122を実現するためのプログラムモジュール例えばライブラリ関数を組み込むことが可能である。すると、広く使われるライブラリを介して、多くのデバイス120にサービス更新サービス122を実装することが可能となる。多くのデバイス120においてサービス更新サービス122が実装されていれば、図1のステップS101の探索に対して、サービス更新サービス122を提供するデバイス120が少なくとも1台は見つかる蓋然性も高まる。その結果、ユーザの利便性も向上する。続いて、第2実施形態について説明する。第2実施形態は、コントローラの動的な更新に関する。サービスだけでなくコントローラも動的に更新することが可能であれば、ユーザの利便性が大きく向上する。例えば、あるサービスを提供するデバイスが存在する環境において、ユーザは当該サービスを利用したいかもしれないし、または、ユーザの端末で動作するアプリケーションが、当該サービスを利用しようとするかもしれない。しかし、ユーザの端末には、当該サービスに対応するコントローラがインストールされていないかもしれない。この場合、もし端末に動的にコントローラをインストールすることができれば、ユーザは所望のサービスを受けられるようになり、利便性が向上する。あるいは、ユーザの周囲には1つまたは複数のデバイスがあり、ユーザはそれらのデバイスがそれぞれどのようなサービスを提供するのかを知らないかもしれない。そこで、ユーザは、周囲のデバイスがどのようなサービスを提供するのかを調べるよう、端末に指示を与えるかもしれない。その結果、ユーザは使いたいサービスを見つけるかもしれないが、見つけたサービスを利用するためのコントローラは、ユーザの端末にはインストールされていないかもしれない。この場合も、もし端末に動的にコントローラをインストールすることができれば、ユーザは所望のサービスを受けられるようになり、利便性が向上する。そこで、第2実施形態では、コントローラの動的な更新が行われる。以下、図7~12を参照して第2実施形態について詳しく説明する。図7は、第2実施形態の動作シーケンス図である。また、図8は、第2実施形態のシステム構成図である。図8に示すように、第2実施形態のシステム200は、端末210とデバイス220とコントローラ管理装置230を含む。システム200内には端末210以外の端末がさらにあってもよい。図7は、以上の端末210とデバイス220とコントローラ管理装置230による動作シーケンスの例を示す。端末210は、通信機能とUPnPのコントローラ機能を有し、かつ、ソフトウェアをインストールすることが可能であれば、どのような種類の端末であってもよい。例えば、端末210は、携帯電話、スマートフォン、タブレット端末、PDA、ノートPCのような携帯端末であってもよいし、デスクトップPCであってもよい。デバイス220は、通信機能とUPnPのサービス提供機能を有していれば、どのようなデバイスでもよい。第1実施形態のデバイス120とは異なり、第2実施形態のデバイス220は、ソフトウェアのインストールが不可能なものであってもよい。例えば、携帯電話、スマートフォン、タブレット端末、PDA、ノートPC、デスクトップPC、プリンタ、プロジェクタ、テレビ、録画装置、照明装置など、様々な装置がデバイス220として利用される可能性がある。なお、端末210とデバイス220は、ネットワークを介して互いに通信することができる。コントローラ管理装置230は、例えば、ネットワークを介して端末210と通信可能なコンピュータであってもよい。あるいは、デバイス220がコントローラ管理装置230を含んでいてもよい。端末210とデバイス220とコントローラ管理装置230のさらなる詳細は、後ほど図8を参照して説明することにして、先に図7の動作シーケンスについて説明する。なお、先に例示したとおり、端末210に動的にコントローラをインストールすることができれば好ましい状況はいくつかある。しかし、以下では説明の簡単化のため、次の2つの仮定が成り立つ状況における動作シーケンスについて説明する。ユーザが、ある1つのUPnPサービスを利用したい旨を示す入力を、端末210に与えた。または、端末210上で動作するアプリケーションが、ある1つのUPnPサービスを利用しようとした。しかし、上記のある1つのUPnPサービス以下では便宜上、対象サービスともいうに対して制御メッセージを送る機能を持つコントローラは、端末210にはインストールされていない。さて、図7のステップS301では、端末210が、Msearchメッセージをマルチキャストすることにより、対象サービスを探索する。図7の例では、デバイス220が対象サービスを提供しているものとする。したがって、ステップS302で、デバイス220が端末210に応答具体的には、OKという意味を示す200というステータスコードを含むHTTP応答を返す。端末210は、ステップS302の応答を受信すると、次に、ステップS303でデバイス220のデバイス定義を要求する。すると、デバイス220は、ステップS304でデバイス定義ファイルを端末210に送信する。端末210は、デバイス定義ファイルを受信すると、対象サービスにアクセスするための情報を得ることができる。そこで、端末210は、次のステップS305で、対象サービスのサービス定義を要求する。すると、デバイス220は、ステップS306で対象サービスのサービス定義ファイルを送信する。なお、ステップS301~S306は、図1のステップS101~S106と類似なので、上記の説明では詳細を割愛した。また、端末210は以上のようにして、デバイス220の提供する対象サービスを検出し、対象サービスに関する情報を取得することができる。そして、端末210は、次のステップS307で、コントローラ管理装置230に対して、対象サービスに対応するコントローラを要求する。ステップS307の要求は、対象サービスを識別するサービス識別情報例えばサービスのIDまたは名前を含む。つまり、ステップS307の要求は、サービス識別情報の通知でもある。また、対象サービスに対応するコントローラとは、具体的には、対象サービスを利用するために対象サービスに対して制御メッセージを送る機能を持つUPnPのコントローラである。ところで、コントローラ管理装置230は、1つ以上のサービスのそれぞれに対応するコントローラを実現するプログラムを、当該サービスを識別するサービス識別情報と対応づけて格納している。よって、コントローラ管理装置230は、ステップS307の要求を受信すると、通知されたサービス識別情報を用いて、対象サービスに対応するコントローラを実現するプログラムを検索する。そして、コントローラ管理装置230は、検索により見つけたプログラムを、ステップS308で端末210に送信する。すると、端末210は、対象サービスに対応するコントローラのプログラムを受信する。そして、端末210は、ステップS309で、受信したプログラムを端末210自身にインストールする。以上のようにして、端末210には、所望の対象サービスに対応するコントローラのプログラムが、動的にインストールされる。よって、図7には示されていないが、端末210は、今後、インストールされたコントローラから制御メッセージ具体的にはSOAPコマンドを送信することにより、対象サービスを利用することができる。続いて、図8を参照して、端末210とデバイス220とコントローラ管理装置230の詳細について説明する。図8に示すように、端末210にはUPnP制御部211が含まれる。UPnP制御部211は、1つ以上のコントローラを含むことができるが、例えば図7のステップS301の時点では、UPnP制御部211は1つもコントローラを含んでいなくてもよい。また、端末210は、指定されたUPnPのサービスに対応するコントローラを追加または更新するための、コントローラ更新サービス212を提供する。なお、全く新たなコントローラを追加することも、既存のコントローラを新たなバージョンのコントローラに更新することも、コントローラのプログラムのインストールにより同様に実現される。したがって、以下ではコントローラの追加と更新を区別しないことがある。また、第2実施形態では、コントローラ更新サービス212がUPnPのサービスとして実装されている。したがって、コントローラ更新サービス212は、図8には不図示の他の端末のコントローラから、対象サービスを指定する制御メッセージを受け取ることで、対象サービスを決めてもよい。あるいは、端末210のUPnP制御部211の中に、コントローラ更新サービス212を利用するための不図示のコントローラがさらに実装されていてもよい。そして、当該不図示のコントローラが、コントローラ更新サービス212に対して、対象サービスを指定する制御メッセージを与えてもよい。しかし、実施形態によっては、コントローラ更新サービス212と同様の機能を持つものの、UPnPのサービスではないといったプログラムモジュールが、コントローラ更新サービス212の代わりに使われてもよい。ところで、図7のステップS301の探索、ステップS302の応答の受信、ステップS303の要求、ステップS304の受信、ステップS305の要求、およびステップS306の受信は、具体的には、コントローラ更新サービス212により実行される。また、ステップS307の要求、ステップS308の受信、およびステップS309のインストールも、コントローラ更新サービス212により実行される。そして、ステップS309のインストールの結果として、UPnP制御部211には、対象サービスに対応する新規コントローラ213がインストールされる。図8には、新規コントローラ213が破線で示されている。また、デバイス220は、UPnPサービス提供部221を含む。UPnPサービス提供部221は、上記の対象サービスであるサービス222を提供する。さて、コントローラ管理装置230は格納部231を有する。格納部231には、サービス222に対応する新規コントローラ213を実現するためのプログラムである新規コントローラプログラム232が、サービス222を識別する情報と対応づけられて、格納されている。新規コントローラプログラム232は、図7のステップS308で送信され、ステップS309で端末210にインストールされる。そして、インストールの結果として、端末210は、新規コントローラ213を介してサービス222を利用することができるようになる。なお、簡単化のため、図8には1つの新規コントローラプログラム232のみが示されている。しかし、格納部231は、複数のサービスに対応する複数のコントローラそれぞれのプログラムを格納していてもよい。つまり、格納部231は、様々なコントローラのプログラムのレポジトリであってもよい。また、コントローラ管理装置230は、指定されたサービスに対応するコントローラを決定するコントローラ決定部233を含む。コントローラ決定部233は、具体的には、条件テーブル234を参照することで、指定されたサービスに対応するコントローラを決定する。図9に、条件テーブル234の具体例を示す。図9に示すように、条件テーブル234は、サービスとコントローラを対応づけるテーブルである。なお、図9では、理解を容易にするために、サービスとコントローラがそれぞれ名前で表現されている。しかし、条件テーブル234は、例えば、サービスのIDとコントローラのIDとを対応づけるテーブルであってもよい。IDとしては、例えば、UUIDUniversallyUniqueIdentifierが利用されてもよい。図9の例では、ドキュメント表示サービスにドキュメントページめくりコントローラが対応づけられている。また、照明ON/OFFサービスに、照明ON/OFFリモコンコントローラが対応づけられている。そして、ビデオ録画サービスに、ビデオリモコンコントローラが対応づけられている。したがって、例えば、対象サービスすなわち図8のサービス222がビデオ録画サービスの場合、図7のステップS307の要求では、ビデオ録画サービスの識別情報例えば、名前またはIDが指定される。すると、コントローラ決定部233は、条件テーブル234を参照し、指定されたビデオ録画サービスに対応づけられているコントローラを検索する。検索の結果、コントローラ決定部233は、端末210に送信する対象のプログラムは、ビデオリモコンコントローラのプログラムであると決定する。コントローラ決定部233による決定にしたがって、コントローラ管理装置230は、図7のステップS308で、格納部231に格納されているビデオリモコンコントローラのプログラムを送信する。以上のように、コントローラ管理装置230では、条件テーブル234により、各コントローラのプログラムが、対応するサービスの識別情報と対応づけられている。しかし、実施形態によっては、例えば、対応するサービスの識別情報を含むパスで示されるフォルダにコントローラのプログラムを格納するなどの、他の方法による対応づけが採用されてもよい。さて、上記のとおり第2実施形態では、図8のコントローラ更新サービス212は、UPnPのサービスの1種である。よって、コントローラ更新サービス212のインストールされた端末210に関するデバイス定義ファイルには、コントローラ更新サービス212に関する情報が含まれる。また、端末210は、デバイス定義ファイルだけでなく、コントローラ更新サービス212に関するサービス定義ファイルも格納している。以下、図10~11を参照して、これらのデバイス定義ファイルとサービス定義ファイルの具体例について説明する。図10は、端末210に関するデバイス定義ファイルの例である。図10のデバイス定義ファイル240において、5~9行目には、デバイス220全体に関する情報が記載されている。そして、10~18行目には、デバイス220が提供するサービスのリストが記載されている。デバイス定義ファイル240の例では、10~18行目のリストには、1つのサービスすなわちコントローラ更新サービス212の情報のみが記載されている。具体的には、12行目に、コントローラ更新サービス212の種類が記載されており、13行目に、コントローラ更新サービス212のIDが記載されている。また、14行目には、コントローラ更新サービス212のサービス定義ファイルのある場所のURIが記載されている。そして、コントローラ更新サービス212は、外部から制御メッセージ具体的にはSOAPコマンドを受け取ることもできる。15行目には、このようなコントローラ更新サービス212に対する制御メッセージの宛先のURIが記載されている。さらに、16行目には、コントローラ更新サービス212の状態変数についての購読要求の宛先のURIが記載されている。次に、図11を参照して、コントローラ更新サービス212のサービス定義ファイルの詳細について説明する。なお、説明の都合上、図11には、第2実施形態では使われない状態変数についての定義も含むサービス定義ファイル241が例示されている。具体的には、25~26行目のListeningという状態変数は、第2実施形態では使われず、第4実施形態で使われる。よって、ここでは25~26行目の説明は省略する。また、特に混乱のおそれはないので、以下の第2実施形態の説明におけるサービス定義ファイル241という用語は、25~26行目のない状態のサービス定義ファイルを指すものとする。さて、サービス定義ファイル241は、図10のデバイス定義ファイル240の14行目に記載されたURIで識別される場所具体的には端末210内の記憶装置に記憶されている。4~19行目には、コントローラ更新サービス212に関して定義されているアクションのリストが記載されている。具体的には、5~12行目では、コントローラの追加および更新用の、UpdateControllerという名前のアクションが定義されている。このアクションは2つの入力引数をとる。1番目の引数は、argServiceNameという名前であり、追加または更新の対象のコントローラに対応するサービスを識別するための識別情報例えばサービスの名前を表す。また、このargServiceNameという引数は、後述のServiceNameという状態変数と関係しており、具体的には、コントローラ更新サービス212は、argServiceNameという引数に指定された値をServiceNameという状態変数に代入する。2番目の引数は、argServerUriという名前であり、追加または更新の対象のコントローラのデータつまりコントローラのプログラムを含むデータが記憶されている場所を示す。具体的には、コントローラ管理装置230のURIが、argServerUriという引数として指定される。なお、端末210にとって当該URIは既知である。また、13~18行目では、コントローラ削除用の、DeleteControllerという名前のアクションが定義されている。なお、DeleteControllerというアクションは省略可能であり、実施形態によっては、コントローラ更新サービス212がコントローラの削除機能を持たなくてもよい。図11の例では、DeleteControllerというアクションは、argServiceNameという名前の1つの入力引数をとる。この引数は、削除対象のコントローラに対応するサービスを識別するための識別情報例えばサービスの名前を表す。また、この引数も、ServiceNameという状態変数と関係しており、具体的には、コントローラ更新サービス212は、argServiceNameという引数に指定された値をServiceNameという状態変数に代入する。また、20~27行目には、コントローラ更新サービス212に関して定義されている状態変数のリストが記載されている。具体的には、21~22行目には、ServiceNameという名前の文字列型の状態変数が定義されている。ServiceNameという状態変数は、コントローラ更新サービス212が最後に追加、更新、または削除したコントローラに対応するサービスの識別情報例えばサービスの名前を示す。そして、23~24行目には、ServerUriという名前のURI型の状態変数が定義されている。ServerUriという状態変数は、コントローラ更新サービス212が最後に追加、更新、または削除したコントローラのプログラムがどこから取得されたのかを示す。25~26行目については、第4実施形態とともに後述する。ところで、図7のステップS301~S309までの処理は、端末210が図12のフローチャートにしたがって動作することにより、実現される。まず、ステップS401で、コントローラ更新サービス212が、図7のステップS301のようなMsearchメッセージのマルチキャストにより、端末210の周辺にあるデバイスのUPnPサービスつまり、上記の対象サービスを検索する。上記のとおり、対象サービスは、何らかの方法により決められているものとする。もし、例えばデバイス220のように、対象サービスを提供するデバイスがあれば、コントローラ更新サービス212は図7のステップS302のような応答を受信する。この場合、コントローラ更新サービス212はさらに、図7のステップS303~S306のようにして、対象サービスを提供するデバイスのデバイス定義ファイルと、対象サービスのサービス定義ファイルを取得する。次に、ステップS402でコントローラ更新サービス212は、ステップS401で検索したUPnPサービスつまり対象サービスを提供するデバイスが発見されたか否かを判断する。ステップS401でのMsearchメッセージの送信から所定の時間が経過しても、ステップS302のような応答が1つも受信されない場合、コントローラ更新サービス212は、対象サービスを提供するデバイスは発見されなかったと判断する。そして、対象サービスを提供するデバイスが発見されなかった場合、図12の処理は終了する。つまり、この場合は新規コントローラ213のインストールは行われない。逆に、ステップS302のような応答が得られて、デバイス定義ファイルとサービス定義ファイルが取得されていれば、対象サービスを提供するデバイスが存在する。よって、この場合、コントローラ更新サービス212は、対象サービスを提供するデバイスが発見されたと判断する。そして、図12の処理はステップS403へと移行する。ステップS403でコントローラ更新サービス212は、コントローラ管理装置230に対して、発見したUPnPサービスつまり対象サービスの情報例えば名前やIDなどの識別情報を通知して、対象サービスに対応するコントローラを要求する。ステップS403での要求は、図7のステップS307に対応する。そして、図7のステップS308に示すように、コントローラ更新サービス212は、コントローラ管理装置230から、対象サービスに対応するコントローラのデータ具体的には、図8の新規コントローラプログラム232を含むデータを受信する。最後に、ステップS404でコントローラ更新サービス212は、受信したコントローラのプログラムを端末210にインストールする。その結果、UPnP制御部211は、サービス222を利用するための新規コントローラ213が存在する状態となる。したがって、端末210のユーザは、端末210から所望のサービス222を利用することが可能となる。以上説明した第2実施形態によれば、端末210には、必要に応じてコントローラがインストールされる。したがって、対応するコントローラが端末210にプレインストールされていないようなサービスであっても、端末210から利用可能である。つまり、第2実施形態には、端末210のユーザが使えるサービスを増やすことで、ユーザの利便性を向上させる効果がある。また、第2実施形態のコントローラ更新サービス212はUPnPのサービスなので、UPnP用のライブラリの中に、コントローラ更新サービス212を実現するためのプログラムモジュール例えばライブラリ関数を組み込むことが可能である。すると、広く使われるライブラリを介して、多くの端末210にコントローラ更新サービス212を実装することが可能となる。すなわち、コントローラ更新サービス212がUPnPのサービスであることは、利便性の向上に有益なコントローラ更新サービス212の普及を促進する効果がある。続いて、第3実施形態について説明する。第3実施形態は、サービスの更新に関する点において第1実施形態と共通である。しかし、第1実施形態では、端末110からのサービス追加更新コマンドが、デバイス120におけるサービスのインストールのトリガであるのに対して、第3実施形態では、デバイスが特定の環境に入ることがインストールのトリガである。すなわち、第3実施形態によれば、デバイスが存在する環境に応じて、当該環境で使われるサービスあるいは当該環境に適したサービスが、デバイスにインストールされる。以下、図13~19を参照して第3実施形態について詳しく説明する。図13は、第3実施形態の動作シーケンス図である。また、図14は、第3実施形態のシステム構成図である。図14に示すように、第3実施形態のシステム300は、端末310とデバイス320とサーバ330とセンサ340を含む。システム300内には、端末310以外の端末がさらにあってもよく、センサ340以外のセンサがさらにあってもよい。図13は、図14の端末310、デバイス320、サーバ330、およびセンサ340、ならびに図14には不図示の端末350による動作シーケンスの例を示す。端末310は、通信機能とUPnPのコントローラ機能を有する端末であれば、どのような種類の端末であってもよい。例えば、端末310は、携帯電話、スマートフォン、タブレット端末、PDA、ノートPCのような携帯端末であってもよいし、デスクトップPCであってもよい。端末350も端末310と同様である。デバイス320は、通信機能とUPnPのサービス提供機能を有する装置であり、製造工場からの出荷後にソフトウェアをインストールすることの可能な装置である。より具体的には、デバイス320は、第1実施形態と類似のサービス更新サービス322を提供する。また、例えば、携帯電話、スマートフォン、タブレット端末、PDA、ノートPC、デスクトップPC、プリンタ、プロジェクタ、テレビ、録画装置、照明装置などの様々な装置が、デバイス320として利用される可能性がある。なお、端末310とデバイス320は、ネットワークを介して互いに通信することができる。サーバ330は、ネットワークを介した通信が可能なコンピュータである。後述するとおり、第3実施形態では、ある種の通知が、デバイス320からサーバ330に送信されてもよいし、端末310からサーバ330に送信されてもよい。また、別の通知が、センサ340からサーバ330に送信されてもよいし、端末310からサーバ330に送信されてもよい。サーバ330は、ネットワーク例えばインターネットを介して各種通知を適宜受信することができるものとする。また、センサ340は、1種の検出装置である。具体的には、デバイス320が特定の環境に存在する場合に、センサ340は、デバイス320が特定の環境に存在することを示す検出通知を送信する。センサ340は、特定の環境に予め設置されていてもよい。例えば、上記特定の環境が、特定の建物の特定の部屋である場合、当該特定の部屋に予め設置された、無線LANLocalAreaNetworkアクセスポイントやRFIDRadioFrequencyIdentificationリーダなどの装置が、センサ340として使われてもよい。例えば、デバイス320は、無線LANの通信インタフェイスを有していてもよい。その場合、デバイス320が特定の環境にあるか否かは、当該特定の環境に設置された無線LANアクセスポイントを介して検出可能である。同様に、デバイス320はRFID回路を含んでいてもよい。その場合、デバイス320が特定の環境にあるか否かは、当該特定の環境に設置されたRFIDリーダを介して検出可能である。あるいは、センサ340は、端末310に内蔵されていてもよい。例えば、端末310にGPSGlobalPositioningSystemセンサ内蔵されている場合、当該GPSセンサがセンサ340として使われてもよい。GPSセンサのほかにも、高度センサなど他の種類のセンサが使われてもよい。例えば、近傍のデバイス320を端末310が検出したときに、端末310に内蔵されたGPSセンサが、端末310の緯度と経度を検出してもよい。検出された緯度と経度は、デバイス320の緯度と経度でもある、と見なせる。よって、上記の特定の環境が緯度と経度の所定の範囲で表される場合、端末310が近傍にデバイス320を検出したときにGPSセンサが検出した緯度と経度は、デバイス320が特定の環境にあるか否かを示す。または、センサ340は、デバイス320に内蔵されていてもよい。例えば、センサ340は、デバイス320に内蔵されているGPSセンサであってもよい。デバイス320に内蔵されているGPSセンサが検出する緯度と経度は、デバイス320が特定の環境にあるか否かを示すことが可能な情報の例である。なお、以下ではデバイス320が存在する環境をコンテキストともいう。さて、端末310とデバイス320とサーバ330のさらなる詳細は、後ほど図14を参照して説明することにして、先に図13の動作シーケンスについて説明する。図13のステップS501~S506は、図1のステップS101~S106と同様である。よって、詳しい説明は省略するが、ステップS501~S506の結果として、端末310は、デバイス320により提供されるサービス更新サービス322を発見し、デバイス320からデバイス定義ファイルとサービス定義ファイルを取得する。その後、ステップS507で端末310は、検出したサービス更新サービス322に対してコマンド以下では説明の便宜上受信準備コマンドというを送信する。受信準備コマンドも、具体的にはSOAPコマンドの形式で送信される。受信準備コマンドは、サービスのデータがサーバ330から将来送信されてくるのに備えて、データを受信する準備を行うようにとデバイス320に促すコマンドである。また、受信準備コマンドはサーバ330のアドレスを含み、デバイス320に対してサーバ330のアドレスを通知する役目も果たす。デバイス320は、受信準備コマンドを受信すると、次にステップS508で端末310に応答を返す。ステップS508での応答は、具体的には、OKという意味を示す200というステータスコードを含むHTTP応答である。デバイス320は、さらにステップS509で、サーバ330からサービスのデータを受信するための準備を行う。例えば、デバイス320がサービスのデータを所定のTCPTransmissionControlProtocolポートで受信する場合は、ステップS509の受信準備は、上記の所定のTCPポートを開放するすなわち上記の所定のTCPポートをLISTEN状態に設定する処理を含んでもよい。デバイス320は、受信の準備を終えると、次に、ステップS510aに示すように、サーバ330に通知を送る。以下では説明の便宜上、ステップS510aの通知を受信開始通知という。受信開始通知は、デバイス320がサービスのデータを受信可能なことをサーバ330に知らせるための通知である。受信開始通知は、サービスのインストール先であるデバイス320のアドレスを明示的にペイロードに含んでもよい。または、サーバ330は、受信開始通知の送信元アドレスを、デバイス320のアドレスとして認識してもよい。以下では、サービスのインストール先を示す情報として、受信開始通知には、デバイス320のIPアドレスとデバイス320のUUIDが含まれるものとする。また、複数のOSに応じて、同じサービスを提供するためであっても複数の異なるプログラムが使われる場合がある。よって、以下では、受信開始通知には、デバイス320のOSを示す情報例えばOSの名称とバージョン番号を表す文字列が含まれるものとする。ところで、ステップS510aの代わりに、ステップS510bのように端末310が受信開始通知をサーバ330に送信してもよい。つまり、端末310は、ステップS508の応答を受信すると、応答の受信を契機として、ステップS510bでサーバ330に対して受信開始通知を送信してもよい。ステップS510bの受信開始通知は、ステップS510aの受信開始通知と同様に、デバイス320のIPアドレスとデバイス320のUUIDを含む。例えば、ステップS508の応答のメッセージボディにデバイス320のUUIDが含まれていてもよい。すると、端末310は、応答からデバイス320のUUIDを抽出して、受信開始通知に含めることが可能である。第3実施形態では、ステップS510aまたはS510bで受信開始通知が送信された後、サービスのデータがすぐにデバイス320に送信されるとは限らない。サーバ330は、ステップS511aまたはS511bのようなトリガを検出してはじめて、ステップS512のようにサービスのデータをデバイス320に送信する。具体的には、センサ340がデバイス320を検出した場合、ステップS511aのように、センサ340は、センサ値とデバイス320のデバイスIDをサーバ330に通知する。なおここで、センサ値とは、デバイス320が検出された環境を判別するための情報である。また、デバイスIDとは、デバイス320を識別する識別情報である。例えば、センサ340が所定の場所に固定的に設置されている場合、サーバ330は、センサ340の識別情報とセンサ340の設置場所を対応づけるデータベースを有していてもよい。すると、センサ340の識別情報から、サーバ330は、デバイス320が検出された環境すなわちセンサ340の固定的な設置場所を判別することができる。したがって、センサ値としてセンサ340の識別情報が利用可能である。あるいは、センサ340が端末310またはデバイス320に内蔵されているGPSセンサである場合、GPSセンサの出力する緯度と経度が、センサ値として利用可能である。また、デバイスIDは、例えば、デバイス320のIPInternetProtocolアドレスであってもよいし、デバイス320のUUIDであってもよいし、両者の組み合わせであってもよい。以上のステップS511aのようにセンサ340がセンサ値とデバイスIDをサーバ330に通知する代わりに、ステップS511bのように、端末310がサーバ330に対して、デバイス320へサービスのデータを送信するよう要求してもよい。例えば、場合によっては、実際のセンサ値が得られない環境もあるかもしれない。また、ユーザは、実際のセンサ値と関係なく、デバイス320が特定の環境にあるものと見なして、当該特定の環境に適したサービスをデバイス320から受けたいと思うかもしれない。よって、端末310は、ステップS511bのようにサーバ330に要求を送信してもよい。また、ステップS511bの要求には、特定の環境を指定する情報後述のコンテキスト情報と、インストール先のデバイス320を識別する識別情報が含まれる。例えば、端末310は、いくつかの環境を選択肢として含むリストをユーザに提示してもよく、端末310は、ユーザからの入力に基づいて、ユーザの選択した環境を指定する情報を要求に含めてもよい。そして、ステップS511aの通知またはステップS511bの要求の受信に応じて、ステップS512でサーバ330は、サービスより具体的には、当該サービスを提供するためのプログラムを含むデータをデバイス320に送信する。具体的には、ステップS511aの通知を受信した場合、サーバ330は、センサ値に基づいてデバイス320のコンテキストを判別する。また、ステップS511bの要求を受信した場合、サーバ330は、要求からコンテキスト情報を抽出する。そして、サーバ330は、コンテキストに応じた適宜のサービスを選択し、選択したサービスのデータをステップS512で送信する。すると、デバイス320はサービスのデータを受信する。サービスのデータは、具体的には、サービスのプログラムとサービス定義ファイルのデータを含む。よって、デバイス320は、ステップS513で、受信により取得したプログラムをデバイス320自身にインストールする。インストールの結果、デバイス320は、新規サービスを提供することができるようになる。また、デバイス320は、デバイス定義ファイルを更新し、サービス定義ファイルを更新または追加する。さらに、次のステップS514でデバイス320は、図1のステップS112と同様にして、GENAにより、サービス追加更新イベントの発生を通知する。また、図13には示されていないが、上記のようにしてデバイス320が新規サービスの提供を開始した後、端末310および端末350は、新規サービスを利用することができる。インストールされた新規サービスを利用するための方法は、第1実施形態と同様である。ところで、第3実施形態においても、第1実施形態と同様のデバイス定義ファイル例えば図3のデバイス定義ファイル150のようなデバイス定義ファイルが使われる。また、第1実施形態に関して図4を参照して説明したとおり、図4には、説明の都合上、第1実施形態では使われず第3実施形態で使われるアクションや状態変数についての定義も含むサービス定義ファイル151が例示されている。具体的には、図4の19~26行目で定義されているアクションと、図4の39~42行目で定義されている状態変数は、上記のとおり、第1実施形態では使われず、第3実施形態で使われる。そこで、以下に図4の19~26行目と39~42行目について説明する。図4に示したサービス更新サービスのサービス定義ファイル151の19~26行目には、図13のステップS507の受信準備コマンドに相当する、Listenという名前のアクションが定義されている。このアクションは2つの入力引数をとる。1番目の引数は、argServerUriという名前であり、サービスのデータの送信元すなわちサーバ330のURIを表す。また、このargServerUriという引数は、後述のServerUriという状態変数と関係しており、具体的には、デバイス320におけるサービス更新サービス322は、argServerUriという引数に指定された値をServerUriという状態変数に代入する。2番目の引数は、setListeningFlagという名前であり、サーバ330からのサービスのデータの受信が可能な状態にデバイス320を設定するか否かを表す。また、このsetListeningFlagという引数は、後述のListeningという状態変数と関係しており、具体的には、デバイス320におけるサービス更新サービス322は、setListeningFlagという引数に指定された値をListeningという状態変数に代入する。さて、39~40行目には、ServerUriという名前のURI型の状態変数が定義されている。ServerUriという状態変数は、デバイス320が受信しようとするあるいは既に受信したデータの送信元のサーバ330を示す。また、41~42行目には、Listeningという名前のブール型の状態変数が定義されている。Listeningという状態変数の値が真trueの場合、デバイス320は、受信準備が完了した状態つまりサーバ330からの受信が可能な状態である。逆に、Listeningという状態変数の値が偽falseの場合、デバイス320は、サーバ330からの受信が不可能な状態例えば、所定のTCPポートが閉じている状態である。続いて、図14を参照して、端末310とデバイス320とサーバ330の詳細について説明する。図14に示すように、端末310には、UPnPコントローラ311が実装されている。UPnPコントローラ311は、サービス更新サービスに対して制御メッセージつまりコマンドを与える機能を有する、UPnPのコントローラである。図13に示した端末310の動作ただしステップS511bの要求の送信を除くは、具体的にはUPnPコントローラ311により実行される。また、端末310はステップS511bのような要求を送信する要求部312をさらに有していてもよい。要求部312は、ステップS511bの要求で指定する環境をユーザに指定させるための処理も行う。しかし、要求部312は省略されていてもよい。また、デバイス320は、UPnPサービス提供部321を含む。UPnPサービス提供部321は、サービス更新サービス322を提供する。図13のステップS513は、具体的にはサービス更新サービス322により行われる。なお、図14には、ステップS513でインストールされる新規サービス323が破線で示されている。新規サービス323のプログラムのインストール後には、UPnPサービス提供部321は、新規サービス323も提供することが可能である。また、UPnPコントローラ311は、サービス更新サービス322に対して制御メッセージを与える機能だけでなく、新規サービス323に対して制御メッセージを与える機能を有していてもよい。デバイス320はさらに受信部324を含む。受信部324は、サーバ330から新規サービス323のデータを受信するのを待ち、データを受信すると、サービス更新サービス322に受信を通知する。具体的には、図13のステップS507の受信準備コマンドに応じて、サービス更新サービス322が受信部324を起動し、ステップS309で受信部324が受信準備を行ってもよい。そして、ステップS512で新規サービス323のデータが受信されると、受信部324がサービス更新サービス322に受信を通知してもよい。サービス更新サービス322は、受信部324からの通知に応じて、受信部324が受信したデータを使ってステップS513でインストールを実行してもよい。さて、サーバ330は、格納部331を有する。格納部331には、新規サービス323を提供するためのプログラムである新規サービスプログラム332が、新規サービス323を識別する情報と対応づけられて、格納されている。新規サービスプログラム332は、図13のステップS512で送信され、ステップS513でデバイス320にインストールされる。なお、簡単化のため、図14には1つの新規サービスプログラム332のみが示されているが、格納部331は、複数のサービスそれぞれのプログラムを、当該サービスを識別する情報と対応づけて格納していてもよい。つまり、格納部331は、様々なサービスを提供するための各種プログラムのレポジトリであってもよい。また、あるOSにしたがって動作するデバイスが新規サービス323を提供するためのプログラムと、別のOSにしたがって動作する別のデバイスが、同じ新規サービス323を提供するためのプログラムは、異なる場合がある。そのため、格納部331は、新規サービス323を識別する情報だけでなく、OSを表す情報とも対応づけて、新規サービスプログラム332を格納しているものとする。さて、サーバ330は、図13のステップS511aでセンサ340から送信されるセンサ値から、デバイス320のコンテキストすなわちデバイス320の存在する環境を抽出するコンテキスト抽出部333をさらに有する。コンテキスト抽出部333は、例えば、所定の場所に設置されたセンサ340例えば無線LANアクセスポイントやRFIDリーダなどの識別情報と、センサ340の設置場所を対応づけるデータベースを使って、センサ値からコンテキストを抽出してもよい。また、コンテキスト抽出部333は、地図データを使って、センサ値としての緯度と経度から、コンテキストを抽出してもよい。なお、コンテキストの粒度は実施形態に応じて任意である。例えば、Xビルの3階にある第1会議室やY氏の自宅のような非常に細かな粒度のコンテキストが利用されてもよいし、会議室や自宅のようにある程度一般化されたコンテキストが利用されてもよい。コンテキスト抽出部333は、実施形態に応じた粒度のコンテキストをセンサ値から抽出するための適宜のルールデータベースを有していてもよい。また、所定の場所に設置されたセンサ340の識別情報と、センサ340の設置場所を対応づける上記データベースにおいて、設置場所がコンテキストの粒度に応じて表現されていてもよい。サーバ330はさらに、デバイス320に送信する対象のサービスを決定するサービス決定部334を含む。なお、図13のステップS511bのように要求部312から要求が送信される場合、サービス決定部334が要求を受信する。そして、サービス決定部334は、受信した要求から、コンテキスト情報を抽出する。逆に、図13のステップS511aのようにセンサ値が送信される場合、サービス決定部334は、コンテキスト抽出部333から、コンテキスト情報を取得する。いずれにせよ、サービス決定部334は、コンテキストに基づいてサービスを決定する。その際、サービス決定部334は、条件テーブル335を参照することで、コンテキストに対応するサービスを決定する。図15に、条件テーブル335の具体例を示す。図15に示すように、条件テーブル335は、コンテキストとサービスを対応づけるテーブルである。なお、図15では、理解を容易にするために、コンテキストとサービスがそれぞれ名前で表現されている。しかし、条件テーブル335は、例えば、コンテキストを示すコード番号と、サービスのIDとを対応づけるテーブルであってもよい。図15の例では、会議室というコンテキストに、ドキュメント表示サービスが対応づけられている。また、事務所というコンテキストに、照明ON/OFFサービスが対応づけられている。そして、自宅というコンテキストに、ビデオ録画サービスが対応づけられている。したがって、コンテキスト抽出部333によって例えば会議室というコンテキストが抽出された場合、サービス決定部334は、ドキュメント表示サービスのデータをデバイス320に送信することを決定する。ここで、再度図14の説明に戻ると、サーバ330はさらに、受信準備の整ったデバイス320についての情報を管理するデバイス管理部336を有する。デバイス管理部336は、具体的には、デバイステーブル337を用いて、デバイス320についての情報を管理する。図16に、デバイステーブル337の具体例を示す。デバイステーブル337の各エントリは、1台のデバイス320に対応する。図16には、2台のデバイス320にそれぞれ対応する2つのエントリが例示されている。図16に示すように、デバイステーブル337は、デバイス320のIPアドレスと、デバイス320のUUIDと、デバイス320のOSとを対応づけるテーブルである。図14には1台の端末310と1台のデバイス320しか図示されていないが、システム300は、複数の端末310と複数のデバイス320を含んでいてもよい。よって、デバイス管理部336は、ある1台のデバイス320より具体的には受信部324から図13のステップS510aのように受信開始通知を受信するたびに、デバイステーブル337にエントリを追加するか、または既存のエントリを更新する。また、デバイス管理部336は、ある1台の端末310より具体的にはUPnPコントローラ311から図13のステップS510bのように受信開始通知を受信するたびに、デバイステーブル337にエントリを追加するか、または既存のエントリを更新する。ここで、再度図14の説明に戻ると、サーバ330はさらに送信部338を有する。送信部338は、サービス決定部334の決定にしたがって、格納部331から適宜の新規サービスプログラム332を読み出して、新規サービスプログラム332をデバイス320に送信する。ところで、図13のステップS507~S514までの処理は、サーバ330が図17と図18のフローチャートにしたがって動作し、デバイス320が図19のフローチャートにしたがって動作することにより、実現される。具体的には以下のとおりである。図17は、デバイス320または端末310からの受信開始通知に応じて、サーバ330が行う処理のフローチャートである。ステップS601でサーバ330のデバイス管理部336は、デバイス320または端末310から、受信開始通知を受信する。より具体的には、図13のステップS510aのように、デバイス管理部336は、デバイス320の受信部324から受信開始通知を受信することもある。あるいは、図13のステップS510bのように、デバイス管理部336は、端末310のUPnPコントローラ311から受信開始通知を受信することもある。いずれにしても、受信開始通知は、ステップS510aとS510bに関して説明したとおり、サービスのインストール先であるデバイス320の、IPアドレスとUUIDを含む。なお、デバイス320のIPアドレスが変化する場合もあり得る。例えば、DHCPDynamicHostConfigurationProtocolによってIPアドレスが割り当てられているデバイス320が再起動すると、再起動の前後でデバイス320のIPアドレスは変化するかもしれない。再起動したデバイス320は、サーバ330に新たなIPアドレスを通知するために受信開始通知を再び送信してもよい。また、ある1台のデバイス320が、複数台の端末310から、何らかの間隔を置いて、受信準備コマンドを受信することもあり得る。その場合、複数の受信準備コマンドに対応して、同じデバイス320から、複数の受信開始通知をサーバ330が受信することになる。そこで、デバイス管理部336は、端末310またはデバイス320から受信開始通知を受信すると、次のステップS602で、受信開始通知によって通知されたUUIDと同じUUIDが格納されたエントリがデバイステーブル337に存在するか否かを判断する。もしそのようなエントリがデバイステーブル337にあれば、処理はステップS603に移行する。逆に、そのようなエントリがデバイステーブル337になければ、処理はステップS604に移行する。ステップS603でデバイス管理部336は、ステップS602で見つけた当該エントリのIPアドレスとOSのフィールドを、受信開始通知により通知されたIPアドレスとOSの値で上書きする。そして、図17の処理は終了する。また、ステップS604でデバイス管理部336は、受信開始通知により通知されたIPアドレスとUUIDとOSの値を格納する新規エントリを、デバイステーブル337に追加する。そして、図17の処理は終了する。図18は、図13のステップS511aのようなセンサ340からの通知に応じて、サーバ330が行う処理のフローチャートである。なお、ステップS511bのような要求に応じてサーバ330が新規サービスプログラム332を送信する場合については、上記の図13~14についての説明から明らかなので、フローチャートを省略する。さて、ステップS701でコンテキスト抽出部333が、センサ340から、図13のステップS511aのように、センサ値とデバイスIDを受信する。デバイスIDは、具体的には、IPアドレスまたはUUIDである。次に、ステップS702でコンテキスト抽出部333が、通知されたセンサ値からコンテキスト情報を生成する。なお、コンテキスト情報とは、コンテキストを表す情報である。例えば、コンテキストが会議室のような文字列で表される場合は、コンテキスト情報は文字列であるが、もちろん、コンテキスト情報の形式は任意であり、コード番号などが使われてもよい。図14に関して説明したように、例えば、センサ340の識別情報とセンサ340の設置位置を対応づけるデータベース、地図データ、ルールデータベースなどの適宜の情報を利用することで、コンテキスト抽出部333はコンテキスト情報を生成することができる。そして、コンテキスト抽出部333は、生成したコンテキスト情報をサービス決定部334に通知する。また、ステップS703でコンテキスト抽出部333は、センサ340から通知されたデバイスIDをデバイス管理部336に通知する。そして、デバイス管理部336は、通知されたデバイスIDがUUIDとIPアドレスのどちらなのかを判断する。通知されたデバイスIDがUUIDの場合、処理はステップS704に移行する。逆に、通知されたデバイスIDがIPアドレスの場合、処理はステップS705に移行する。ステップS704でデバイス管理部336は、通知されたUUIDがUUIDのフィールドに記憶されているエントリが、デバイステーブル337にあるか否かを判断する。もしそのようなエントリがなければ、図18の処理は終了する。逆に、通知されたUUIDがUUIDのフィールドに記憶されているエントリが見つかれば、デバイス管理部336は、見つけたエントリをサービス決定部334に通知し、処理はステップS706に移行する。また、ステップS705でデバイス管理部336は、通知されたIPアドレスがIPアドレスのフィールドに記憶されているエントリが、デバイステーブル337にあるか否かを判断する。もしそのようなエントリがなければ、図18の処理は終了する。逆に、通知されたIPアドレスがIPアドレスのフィールドに記憶されているエントリが見つかれば、デバイス管理部336は、見つけたエントリをサービス決定部334に通知し、処理はステップS706に移行する。ステップS706でサービス決定部334は、ステップS702でコンテキスト抽出部333から通知されたコンテキスト情報と合致するエントリが条件テーブル335にあるか否かを判断する。例えば、コンテキスト抽出部333が事務所というコンテキスト情報をサービス決定部334に通知した場合、サービス決定部334は、コンテキストのフィールドに事務所と記憶されているエントリを条件テーブル335において探す。もし、通知されたコンテキスト情報と合致するエントリが条件テーブル335にあれば、処理はステップS707に移行する。逆に、そのようなエントリが見つからなければ、図18の処理は終了する。ステップS707でサービス決定部334は、ステップS704またはS705でデバイステーブル337において見つかったエントリから、IPアドレスとUUIDとOSの値を取得する。そして、サービス決定部334は、取得したこれらの値と、ステップS706で条件テーブル335において見つけたエントリにおけるサービスフィールドの値とを、送信部338に通知する。最後に、ステップS708で送信部338は、サービス決定部334から宛先として通知されたデバイス320に対し、サービス決定部334から通知されたサービスのデータを送信する。より具体的には、送信部338は、サービス決定部334から通知されたサービスとOSに基づいて、格納部331から送信対象のデータつまり新規サービスプログラム332と、新規サービス323のサービス定義ファイルを含むデータを読み出す。そして、送信部338は、通知されたIPアドレスを宛先として、読み出したデータを送信する。ステップS708の送信は、図13のステップS512の送信に対応する。なお、ステップS704、S705、またはS706で、検索条件に合致するエントリが見つからない場合は、何らかのエラーがある場合である。よって、これらの場合、上記のとおり図18の処理は終了し、ステップS708のような送信は行われない。さて、図19は、図13のステップS507のような受信準備コマンドに応じて、デバイス320が行う処理のフローチャートである。図19は、図13のステップS507~S514に対応する。なお、図13には、ステップS510aが行われる場合とステップS510bが行われる場合の双方が例示されているが、図19には、ステップS510aが行われる場合の処理手順を例示した。さて、ステップS801でデバイス320のサービス更新サービス322は、端末310より具体的にはUPnPコントローラ311から、図13のステップS507の受信準備コマンドを受信する。図示は省略したが、ステップS801で受信される受信準備コマンドは、具体的にはSOAPコマンドである。図4のサービス定義ファイル151の19~26行目に定義されているように、受信準備コマンドは、具体的にはListenというアクションであり、srgSrverUriとsetListeningFlagという2つの引数が与えられる。srgSrverUriという引数には、サーバ330のURIが指定される。また、受信準備をデバイス320に行わせるために、setListeningFlagという引数は真に設定される。サービス更新サービス322は、受信準備コマンドを受信すると、図13のステップS508のとおり、HTTP応答を返す。なお、サービス更新サービス322は、サービス更新サービス322のListeningという状態変数の値を、setListeningFlagという引数に指定された値すなわち真に更新する。そして、ステップS802でサービス更新サービス322は、受信部324を起動する。その際、サービス更新サービス322は、受信部324に対して、デバイス320自身のUUIDと、サーバ330のアドレスつまり、受信準備コマンドで引数に指定されていたサーバ330のURIを通知する。起動された受信部324は、サーバ330からデータを受信するための適宜の処理を行う。例えば、受信部324は、所定のTCPポートを開放してもよい。ステップS802は図13のステップS509の受信準備に対応する。また、ステップS803で受信部324は、デバイス320のIPアドレスと、デバイス320のUUIDと、デバイス320のOSを、サーバ330のデバイス管理部336に通知する。ステップS803の通知は、図13のステップS510aの受信開始通知である。そして、ステップS803での受信開始通知の送信後、デバイス320は、ステップS804に示すように、受信部324がサーバ330からサービスのデータつまり新規サービスプログラム332を含むデータを受信するまで待つ。ステップS804での待機は、図13において、デバイス320がステップS510aの送信の後、ステップS512での受信まで待つことに対応する。そして、受信部324がサーバ330からサービスのデータを受信すると、ステップS805で受信部324は、受信したデータをサービス更新サービス322に通知する。すると、ステップS806でサービス更新サービス322は、受信部324から通知されたデータに基づいて、以下の3つの処理を行う。第1に、サービス更新サービス322は、デバイス320のデバイス定義ファイルを更新する。第2に、サービス更新サービス322は、新規サービス323のサービス定義ファイルを追加または更新する。つまり、新規サービス323が今までデバイス320に存在していなかった全く新しいサービスである場合は、サービス更新サービス322は、新たなサービス定義ファイルを作成して保存する。また、新規サービス323が、デバイス320にインストール済みの既存のサービスの新規バージョンである場合は、サービス更新サービス322は、当該既存のサービスのサービス定義ファイルを更新する。第3に、サービス更新サービス322は、受信した新規サービスプログラム332をデバイス320にインストールする。そして、次のステップS807で、サービス更新サービス322は、図4の43行目に示すUpdateTimeという状態変数の値を現在時刻に更新する。ステップS806~S807は、図13のステップS513に対応する。最後に、ステップS808でサービス更新サービス322は、GENAにより、デバイス320の周辺の端末例えば、図13では端末310と端末350に対して、ステップS807で更新したUpdateTimeという状態変数の値を通知する。ステップS808は図13のステップS514に対応する。以上説明した第3実施形態には、第1実施形態と同様に、動的なサービスの更新による利便性向上という効果がある。また、サービス更新サービス322がUPnPのサービスであるため、第1実施形態と同様に、端末310が新規の特殊なプロトコルを使用する必要がなく、かつ、ライブラリを介してサービス更新サービス322の普及が促進される、という効果もある。さらに、第3実施形態によれば、デバイス320は、コンテキストに応じて、コンテキストに適したサービスを提供することができる。よって、端末310または端末350は、デバイス320がコンテキストに応じて提供することが可能となったサービスを利用することができる。続いて、第4実施形態について説明する。第4実施形態は、コントローラの更新に関する点において第2実施形態と共通である。しかし、第4実施形態は、端末が特定の環境に入ることがインストールのトリガである点において、第2実施形態と異なる。すなわち、第4実施形態によれば、端末が存在する環境に応じて、当該環境で使われるサービスあるいは当該環境に適したサービスを利用するためのコントローラが、端末にインストールされる。以下、図20~26を参照して第4実施形態について詳しく説明する。図20は、第4実施形態の動作シーケンス図である。また、図21は、第4実施形態のシステム構成図である。図21に示すように、第4実施形態のシステム400は、端末410とデバイス420とサーバ430とセンサ440を含む。システム400内には、端末410以外の端末がさらにあってもよく、センサ440以外のセンサがさらにあってもよい。図20は、図21の端末410、デバイス420、サーバ430、およびセンサ440による動作シーケンスの例を示す。端末410は、通信機能とUPnPのコントローラ機能を有し、かつ、ソフトウェアをインストールすることが可能であれば、どのような種類の端末であってもよい。例えば、端末410は、携帯電話、スマートフォン、タブレット端末、PDA、ノートPCのような携帯端末であってもよいし、デスクトップPCであってもよい。デバイス420は、通信機能とUPnPのサービス提供機能を有していれば、どのようなデバイスでもよい。デバイス420は、ソフトウェアのインストールが不可能なものであってもよい。例えば、携帯電話、スマートフォン、タブレット端末、PDA、ノートPC、デスクトップPC、プリンタ、プロジェクタ、テレビ、録画装置、照明装置など、様々な装置がデバイス420として利用される可能性がある。なお、端末410とデバイス420は、ネットワークを介して互いに通信することができる。サーバ430は、ネットワーク例えばインターネットを介した通信が可能なコンピュータである。サーバ430は、少なくとも端末410と通信可能である。また、後述するとおり、第4実施形態では、ある種の通知が、センサ440からサーバ430に送信されてもよく、端末410からサーバ430に送信されてもよい。センサ440が通知を送信する場合は、サーバ430は、センサ440とも通信可能なように構成される。センサ440は、1種の検出装置である。具体的には、端末410が特定の環境に存在する場合に、センサ440は、端末410が特定の環境に存在することを示す検出通知を送信する。なお、第3実施形態に関する説明と同様に、第4実施形態に関する説明においても、環境のことをコンテキストともいう。例えば、センサ440は、特定の環境に予め設置された無線LANアクセスポイントやRFIDリーダなどの装置であってもよい。あるいは、センサ440は、端末410に内蔵されたGPSセンサなどのセンサであってもよい。さて、端末410とデバイス420とサーバ430のさらなる詳細は、後ほど図21を参照して説明することにして、先に図20の動作シーケンスについて説明する。図20のステップS901~S906は、図7のステップS301~S306と同様である。よって、詳しい説明は省略するが、ステップS901~S906の結果として、端末410は、デバイス420の提供するサービス例えば、後述する図21のサービス422を発見し、デバイス420からデバイス定義ファイルとサービス定義ファイルを取得する。その後、ステップS907で端末410は、発見したサービスを利用するためのコントローラのデータをサーバ430から受信するための準備を行う。例えば、ステップS907の受信準備は、所定のTCPポートを開放する処理を含んでもよい。端末410は、受信の準備を終えると、次のステップS908で、サーバ430に通知を送る。以下では説明の便宜上、ステップS908の通知のことも受信開始通知という。第4実施形態における受信開始通知は、端末410がコントローラのデータを受信可能なことをサーバ430に知らせるための通知である。受信開始通知は、コントローラのインストール先である端末410のアドレスを明示的にペイロードに含んでもよい。または、サーバ430は、受信開始通知の送信元アドレスを、端末410のアドレスとして認識してもよい。以下では、コントローラのインストール先を示す情報として、受信開始通知には、端末410のIPアドレスと端末410のUUIDが含まれるものとする。また、複数のOSに応じて、同じサービスを利用するためであっても複数の異なるコントローラプログラムが使われる場合がある。よって、以下では、受信開始通知には、端末410のOSを示す情報例えばOSの名称とバージョン番号を表す文字列が含まれるものとする。さらに、受信開始通知には、端末410が利用しようとするサービスつまりステップS901~S906で検出されたサービスを識別する識別情報例えばサービスIDも含まれる。さて、第4実施形態では、ステップS908で受信開始通知が送信された後、コントローラのデータがすぐに端末410に送信されるとは限らない。サーバ430は、ステップS909aまたはS909bのようなトリガを検出してはじめて、ステップS910のようにコントローラのデータを端末410に送信する。例えば、センサ440が所定の場所に固定的に設置されている場合、センサ440は、端末410を検出すると、ステップS909aのように、センサ値と端末410の端末IDをサーバ430に送信する。この場合、センサ値は、センサ440の識別情報であってもよい。サーバ430は、センサ440の識別情報とセンサ440の設置場所を対応づけるデータベースを参照することで、端末410が検出された環境すなわちセンサ440の固定的な設置場所を判別することができる。あるいは、センサ440が端末410に内蔵されている場合、センサ440は、定期的に、または不定期に、ステップS909aのように、センサ値と端末410の端末IDをサーバ430に送信する。この場合、センサ値は、例えば、緯度と経度の組み合わせである。サーバ430は、地図データを参照することで、端末410の存在する環境を判別することができる。図20の例では、ステップS909aで通知されたセンサ値が、端末410は特定の環境に存在していると示す値であったものとする。なお、端末IDは、例えば、端末410のIPアドレスであってもよいし、端末410のUUIDであってもよいし、両者の組み合わせであってもよい。ところで、ステップS909aのようにセンサ440が通知を送信する代わりに、ステップS909bのように、端末410がサーバ430に対して、ステップS901~S906で検出したサービスを利用するためのコントローラのデータを要求してもよい。例えば、場合によっては、実際のセンサ値が得られない環境もあるかもしれない。また、ユーザは、実際のセンサ値と関係なく、端末410が特定の環境にあるものと見なして、当該特定の環境に適したサービスを、端末410を介してデバイス420から受けたいと思うかもしれない。よって、端末410は、ステップS909bのように要求を送信してもよい。また、ステップS909bの要求には、特定の環境を指定する情報つまりコンテキスト情報と、端末410すなわち、所望のサービスを利用するためのコントローラのインストール先を識別する端末IDが含まれる。例えば、端末410は、いくつかの環境を選択肢として含むリストをユーザに提示してもよい。そして、端末410は、ユーザからの入力に基づいて、ユーザの選択した環境を指定する情報を要求に含めてもよい。そして、ステップS909aの通知またはステップS909bの要求の受信に応じて、ステップS910でサーバ430は、適宜のコントローラより具体的には、当該コントローラを実現するためのプログラムを含むデータを端末410に送信する。具体的には、ステップS909aの通知を受信した場合、サーバ430は、センサ値に基づいて端末410のコンテキストを判別する。あるいは、ステップS909bの要求を受信した場合、サーバ430は、コンテキストを指定する情報を要求から抽出する。いずれにせよ、サーバ430は、コンテキストを表す情報を取得する。また、サーバ430は、ステップS908の受信開始通知の内容を記憶している。よって、サーバ430は、ステップS909aで通知されたデバイスIDを用いて、記憶している受信開始通知の内容を検索することにより、当該デバイスIDで識別される端末410からかつて受信開始通知により通知されたサービスの識別情報を取得する。そして、サーバ430は、コンテキストと、サービスの識別情報に基づいて、端末410に送信する対象の適宜のコントローラを選択し、選択したコントローラのプログラムをステップS910で送信する。すると、端末410は、ステップS910で送信されたコントローラのプログラムを受信し、次のステップS911で、受信したプログラムを端末410自身にインストールする。以上のようにして、端末410には、動的にコントローラのプログラムがインストールされる。よって、図20には示されていないが、端末410は、今後、インストールされたコントローラから制御メッセージ具体的にはSOAPコマンドを送信することにより、デバイス420により提供されるサービスを利用することができる。ところで、第4実施形態においても、第2実施形態と同様に、コントローラ更新サービス412がUPnPのサービスとして実装されるので、端末410はデバイス定義ファイルとサービス定義ファイルを記憶している。第4実施形態の端末410のデバイス定義ファイルは、例えば、図10のデバイス定義ファイル240と同様であってもよい。また、第2実施形態に関して図11を参照して説明したとおり、図11には、説明の都合上、第2実施形態では使われず第4実施形態で使われる状態変数についての定義も含むサービス定義ファイル241が例示されている。具体的には、図11の25~26行目で定義されているListeningという状態変数は、上記のとおり、第2実施形態では使われず第4実施形態で使われる。このListeningという状態変数は、ブール型の状態変数である。Listeningという状態変数の値が真の場合は、端末410は受信準備が完了した状態つまりサーバ430からの受信が可能な状態である。逆に、Listeningという状態変数の値が偽の場合、端末410は、サーバ430からの受信が不可能な状態例えば、所定のTCPポートが閉じている状態である。続いて、図21を参照して、端末410とデバイス420とサーバ430の詳細について説明する。図21に示すように、端末410にはUPnP制御部411が含まれる。UPnP制御部411は、1つ以上のコントローラを含むことができるが、例えば図20のステップS901の時点では、UPnP制御部411は、1つもコントローラを含んでいなくてもよい。また、端末410は、UPnPのサービスを利用するためのコントローラを動的に追加または更新するための、コントローラ更新サービス412を提供する。図20のステップS901の探索、ステップS902の応答の受信、ステップS903の要求、ステップS904の受信、ステップS905の要求、およびステップS906の受信は、具体的には、コントローラ更新サービス412により実行される。また、ステップS911のインストールも、コントローラ更新サービス412により実行される。なお、全く新たなコントローラを追加することも、既存のコントローラを新たなバージョンのコントローラに更新することも、コントローラのプログラムのインストールにより同様に実現される。したがって、以下ではコントローラの追加と更新を区別しないことがある。また、第2実施形態と同様に第4実施形態でも、コントローラ更新サービス412がUPnPのサービスとして実装されている。しかし、実施形態によっては、コントローラ更新サービス412同様の機能を持つものの、UPnPのサービスではないというプログラムモジュールが、コントローラ更新サービス412の代わりに使われてもよい。端末410はさらに受信部413を含む。受信部413は、サーバ430からのデータ受信を待ち、データを受信すると、コントローラ更新サービス412に受信を通知する。具体的には、図20のステップS906の後、コントローラ更新サービス412が受信部413を起動し、ステップS907で受信部413が受信準備を行ってもよい。また、ステップS908の受信開始通知は、受信部413から送信されてもよい。受信部413は、ステップS910でコントローラのプログラムを受信すると、コントローラ更新サービス412に受信を通知する。すると、コントローラ更新サービス412がステップS911でコントローラのプログラムを端末410にインストールする。端末410は、さらに、図20のステップS909bのような要求を送信する要求部414を有していてもよい。要求部414は、ステップS909bの要求で指定する環境をユーザに指定させるための処理も行う。しかし、要求部414は省略されてもよい。なお、図21には、ステップS911でインストールされる新規コントローラ415が破線で示されている。また、デバイス420は、UPnPサービス提供部421を含む。UPnPサービス提供部421は、サービス222を提供する。サービス222は、具体的には、新規コントローラ415を介して利用されるサービスである。換言すれば、サービス222と対応づけられた特定の環境に端末410が入ることをきっかけとして、端末410には新規コントローラ415がインストールされる。さて、サーバ430は格納部431を有する。格納部431には、サービス422に対応する新規コントローラ415を実現するためのプログラムである新規コントローラプログラム432が格納されている。新規コントローラプログラム432は、図20のステップS910で送信され、ステップS911で端末410にインストールされる。インストールの結果として、端末410は、新規コントローラ415を介してサービス222を利用することができるようになる。なお、簡単化のため図21には1つの新規コントローラプログラム432のみが示されている。しかし、格納部431は、複数のサービスに対応する複数のコントローラそれぞれのプログラムを格納していてもよい。また、あるOSにしたがって動作する端末が新規コントローラ415を実現するためのプログラムと、別のOSにしたがって動作する別の端末が、同じ新規コントローラ415を実現するためのプログラムは、異なる場合がある。そのため、格納部431は、具体的には、サービス422を識別する情報とOSを表す情報の双方と対応づけて、新規コントローラプログラム432を格納しているものとする。さて、サーバ430は、図20のステップS909aで送信されるセンサ値から、端末410のコンテキストすなわち端末410の存在する環境を抽出するコンテキスト抽出部433をさらに有する。コンテキスト抽出部433の詳細は、第3実施形態のコンテキスト抽出部333と同様なので、詳しい説明は省略する。第4実施形態のコンテキスト抽出部433も、実施形態に応じた適宜の粒度のコンテキストを抽出することができる。サーバ430はさらに、端末410に送信する対象のコントローラを決定するコントローラ決定部434を含む。なお、図20のステップS909bのように要求部414から要求が送信される場合、コントローラ決定部434が要求を受信する。そして、コントローラ決定部434は、受信した要求から、コンテキスト情報を抽出する。逆に、図20のステップS909aのようにセンサ値が送信される場合、コントローラ決定部434は、コンテキスト抽出部433から、コンテキスト情報を取得する。いずれにせよ、コントローラ決定部434は、コンテキストに基づいてコントローラを決定する。その際、コントローラ決定部434は、条件テーブル435を参照することで、コンテキストと指定されたサービスの組み合わせに対応するコントローラを決定する。図22に、条件テーブル435の具体例を示す。図22に示すように、条件テーブル435は、コンテキストとサービスとコントローラを対応づけるテーブルである。なお、図22では、理解を容易にするために、コンテキストとサービスとコントローラがそれぞれ名前で表現されている。しかし、例えば、条件テーブル435は、コンテキストを示すコード番号と、サービスIDとコントローラIDとを対応づけるテーブルであってもよい。図22の例では、会議室というコンテキストと、ドキュメント表示サービスと、ドキュメントページめくりコントローラが対応づけられている。そして、事務所というコンテキストと、照明ON/OFFサービスと、照明ON/OFFリモコンコントローラが対応づけられている。また、自宅というコンテキストと、ビデオ録画サービスと、ビデオリモコンコントローラが対応づけられている。例えば、図20のステップS908で端末410の受信部413から送信される受信開始通知において指定されているサービスが、ドキュメント表示サービスであったとする。この場合、コンテキスト抽出部433による会議室というコンテキストの抽出に応じて、コントローラ決定部434は、ドキュメントページめくりコントローラのプログラムを端末410に送信することを決定する。ここで、再度図21の説明に戻ると、サーバ430はさらに、受信準備の整った端末410についての情報を管理する端末管理部436を有する。端末管理部436は、具体的には、端末テーブル437を用いて、端末410についての情報を管理する。図23に、端末テーブル437の具体例を示す。端末テーブル437の各エントリは、1台の端末410に対応する。図23には、2台の端末410にそれぞれ対応する2つのエントリが例示されている。図23に示すように、端末テーブル437は、端末410のIPアドレスと、端末410のUUIDと、端末410のOSと、端末410が受信を待っている対象のコントローラに対応するサービスとを対応づけるテーブルである。図21には1台の端末410と1台のデバイス420しか図示されていないが、システム400は複数の端末410と複数のデバイス420を含んでいてもよい。よって、端末管理部436は、ある1台の端末410より具体的には受信部413から図20のステップS908のように受信開始通知を受信するたびに、端末テーブル437にエントリを追加するか、または既存のエントリを更新する。ここで、再度図21の説明に戻ると、サーバ430はさらに送信部438を有する。送信部438は、コントローラ決定部434の決定にしたがって、格納部431から適宜の新規コントローラプログラム432を読み出して、新規コントローラプログラム432を端末410に送信する。ところで、図20のステップS901~S911までの処理は、サーバ430が図24と図25のフローチャートにしたがって動作し、端末410が図26のフローチャートにしたがって動作することにより、実現される。具体的には以下のとおりである。図24は、端末410からの受信開始通知に応じて、サーバ430が行う処理のフローチャートである。ステップS1001でサーバ430の端末管理部436は、端末410から、受信開始通知を受信する。より具体的には、図20のステップS908のように、端末管理部436は、端末410の受信部413から受信開始通知を受信する。なお、受信開始通知は、ステップS908に関して説明したとおり、コントローラのインストール先である端末410の、IPアドレスとUUIDを含む。また、受信開始通知は、端末410のOSを示す情報も含み、端末410が受信を待っている対象のコントローラに対応するサービスを識別する識別情報も含む。そして、第3実施形態において同じデバイス320から複数回サーバ330が受信開始通知を受信する場合があり得るのと類似の理由から、第4実施形態においてもサーバ430は、同じ端末310から複数回受信開始通知を受信する場合があり得る。そこで、端末管理部436は、端末410から受信開始通知を受信すると、次のステップS1002で、受信開始通知によって通知されたUUIDと同じUUIDが格納されたエントリが端末テーブル437に存在するか否かを判断する。もしそのようなエントリが端末テーブル437にあれば、処理はステップS1003に移行する。逆に、そのようなエントリが端末テーブル437になければ、処理はステップS1004に移行する。ステップS1003で端末管理部436は、ステップS1002で見つけた当該エントリのIPアドレスとOSとサービスのフィールドを、受信開始通知により通知されたIPアドレスとOSとサービスの値で上書きする。そして、図24の処理は終了する。また、ステップS1004で端末管理部436は、受信開始通知により通知されたIPアドレスとUUIDとOSとサービスの値を格納する新規エントリを、端末テーブル437に追加する。そして、図24の処理は終了する。図25は、図20のステップS909aのようなセンサ440からの通知に応じて、サーバ430が行う処理のフローチャートである。なお、ステップS909bのような要求に応じてサーバ430が新規コントローラプログラム432を送信する場合については、上記の図20~21についての説明から明らかなので、フローチャートを省略する。さて、ステップS1101でコンテキスト抽出部433が、センサ440から、図20のステップS909aのように、センサ値と端末IDを受信する。端末IDは、具体的には、IPアドレスまたはUUIDである。次に、ステップS1002でコンテキスト抽出部433が、通知されたセンサ値からコンテキスト情報を生成する。ステップS1002におけるコンテキスト情報の生成方法の詳細は、図18のステップS702と同様である。そして、コンテキスト抽出部433は、生成したコンテキスト情報をコントローラ決定部434に通知する。また、ステップS1103でコンテキスト抽出部433は、センサ440から通知された端末IDを端末管理部436に通知する。そして、端末管理部436は、通知された端末IDがUUIDとIPアドレスのどちらなのかを判断する。通知された端末IDがUUIDの場合、処理はステップS1104に移行する。逆に、通知された端末IDがIPアドレスの場合、処理はステップS1105に移行する。ステップS1104で端末管理部436は、通知されたUUIDがUUIDのフィールドに記憶されているエントリが、端末テーブル437にあるか否かを判断する。もしそのようなエントリがなければ、図25の処理は終了する。逆に、通知されたUUIDがUUIDのフィールドに記憶されているエントリが見つかれば、端末管理部436は、見つけたエントリをコントローラ決定部434に通知し、処理はステップS1106に移行する。また、ステップS1105で端末管理部436は、通知されたIPアドレスがIPアドレスのフィールドに記憶されているエントリが、端末テーブル437にあるか否かを判断する。もしそのようなエントリがなければ、図25の処理は終了する。逆に、通知されたIPアドレスがIPアドレスのフィールドに記憶されているエントリが見つかれば、端末管理部436は、見つけたエントリをコントローラ決定部434に通知し、処理はステップS1106に移行する。ステップS1106でコントローラ決定部434は、下記2つの情報の組み合わせと合致するエントリが条件テーブル435にあるか否かを判断する。ステップS1102でコンテキスト抽出部433から通知されたコンテキスト情報。ステップS1104またはS1105で見つかったエントリつまり端末管理部436から通知されたエントリのサービス。例えば、センサ440から通知された端末IDが、192.168.0.7というIPアドレスだったとする。この場合、図23の端末テーブル437の2番目のエントリがステップS1105で見つかる。2番目のエントリのサービスのフィールドには、ドキュメント表示サービスを示す値が格納されている。また、ステップS1102では、コンテキスト抽出部433が会議室というコンテキスト情報をコントローラ決定部434に通知したものとする。すると、ステップS1106でコントローラ決定部434は、図22の条件テーブル435において、会議室とドキュメント表示サービスの組み合わせと合致する1番目のエントリを見つける。例えば以上のようにして、ステップS1106においてエントリが見つかった場合、処理はステップS1107に移行する。逆に、エントリが見つからなければ、図25の処理は終了する。ステップS1107でコントローラ決定部434は、ステップS1104またはS1105で端末テーブル437において見つかったエントリから、IPアドレスとUUIDとOSの値を取得する。そして、コントローラ決定部434は、取得したこれらの値と、ステップS1106で条件テーブル435において見つけたエントリにおけるコントローラフィールドの値とを、送信部438に通知する。最後に、ステップS1108で送信部438は、コントローラ決定部434から宛先として通知された端末410に対し、コントローラ決定部434から通知されたコントローラのデータを送信する。より具体的には、送信部438は、コントローラ決定部434から通知されたコントローラとOSに基づいて、格納部431から送信対象のデータつまり新規コントローラプログラム432を含むデータを読み出す。そして、送信部438は、通知されたIPアドレスを宛先として、読み出したデータを送信する。ステップS1108の送信は、図20のステップS910の送信に対応する。なお、ステップS1104、S1105、またはS1106で、検索条件に合致するエントリが見つからない場合は、何らかのエラーがある場合である。よって、これらの場合、上記のとおり図25の処理は終了し、ステップS1108のような送信は行われない。さて、図26は、端末410が行う処理のフローチャートである。図26は図20のステップ901~S911に対応する。なお、図20には、ステップS909aが行われる場合とS909bが行われる場合の双方が例示されているが、図26には、ステップS909aが行われる場合の処理手順を例示した。さて、ステップS1201でコントローラ更新サービス412が、図20のステップS901のようなMsearchメッセージのマルチキャストにより、端末410の周辺にあるデバイスのUPnPサービスを検索する。第2実施形態に関して対象サービスが何らかの方法により決められているものと仮定したのと同様に、第4実施形態でも、ステップS1201で検索する対象のサービスが何らかの方法により決められているものとする。もし、例えばデバイス420のように、対象サービスを提供するデバイスがあれば、コントローラ更新サービス412は図20のステップS902のような応答を受信する。この場合、コントローラ更新サービス412はさらに、図20のステップS903~S906のようにして、対象サービスを提供するデバイスのデバイス定義ファイルと、対象サービスのサービス定義ファイルを取得する。次に、ステップS1202でコントローラ更新サービス412は、ステップS1201で検索したUPnPサービスを提供するデバイスが発見されたか否かを判断する。ステップS1201でのMsearchメッセージの送信から所定の時間が経過しても、ステップS902のような応答が1つも受信されない場合、コントローラ更新サービス412は、対象サービスを提供するデバイスは発見されなかったと判断する。そして、図26の処理も終了する。逆に、ステップS902のような応答が得られて、デバイス定義ファイルとサービス定義ファイルが取得されていれば、対象サービスを提供するデバイスが存在する。よって、この場合、コントローラ更新サービス412は、対象サービスを提供するデバイスが発見されたと判断し、処理はステップS1203へと移行する。ステップS1203でコントローラ更新サービス412は、受信部413を起動する。その際、コントローラ更新サービス412は受信部413に対して、端末410自身のUUIDと、ステップS1201で発見したサービスと、サーバ430のアドレス例えばURIを通知する。起動された受信部413は、サーバ430からデータを受信するための適宜の処理を行う。例えば、受信部413は、所定のTCPポートを開放してもよい。ステップS1203は図20のステップS907の受信準備に対応する。また、ステップS1204で受信部413は、端末410のIPアドレスと、端末410のUUIDと、端末410のOSと、ステップS1201で発見されたサービスを、サーバ430の端末管理部436に通知する。ステップS1204の通知は、図20のステップS908の受信開始通知である。そして、ステップS1204での受信開始通知の送信後、端末410は、ステップS1205に示すように、受信部413がサーバ430からコントローラのプログラムつまり図21の新規コントローラプログラム432を受信するまで待つ。ステップS1204での待機は、図20において、端末410がステップS908の送信の後、ステップS910での受信まで待つことに対応する。そして、受信部413がサーバ430から新規コントローラプログラム432を受信すると、ステップS1206で受信部413は、受信した新規コントローラプログラム432をコントローラ更新サービス412に通知する。すると、ステップS1207でコントローラ更新サービス412は、受信部413から通知された新規コントローラプログラム432を端末410にインストールする。その結果、UPnP制御部411は、サービス422を利用するための新規コントローラ415が存在する状態となる。したがって、端末410のユーザは、端末410からサービス422を利用することが可能となる。以上説明した第4実施形態には、第2実施形態と同様に、動的なコントローラの更新による利便性向上という効果がある。また、コントローラ更新サービス412がUPnPのサービスであるため、第2実施形態と同様に、UPnP用のライブラリを介してコントローラ更新サービス412の普及が促進される、という効果もある。さらに、第4実施形態によれば、端末410は、コンテキストに応じて、コンテキストに適したサービスを利用するためのコントローラを取得することができ、取得したコントローラを介して、サービスを享受することができる。続いて、第5実施形態について説明する。第5実施形態は、第3実施形態と第4実施形態の組み合わせに似ており、具体的には、2台の端末の一方にサービスが動的にインストールされ、他方にコントローラが動的にインストールされる。ただし、第5実施形態では、インストールのタイミングがコンテキストに依存するだけでなく、ある端末にサービスとコントローラのいずれがインストールされるのかという選択も、コンテキストに依存する。以下、図27~39を参照して第5実施形態について詳しく説明する。図27は、第5実施形態の動作シーケンス図である。また、図28は、第5実施形態のシステム構成図である。図28に示すように、第5実施形態のシステム500は、端末510と端末520とサーバ530とセンサ540を含む。システム500内には、端末510と端末520以外の端末がさらにあってもよく、センサ540以外のセンサがさらにあってもよい。図27は、図28の端末510、端末520、サーバ530、およびセンサ540、ならびに図28には不図示の端末550による動作シーケンスの例を示す。端末510と端末520は、通信機能と、UPnPのサービス提供機能と、UPnPのコントローラ機能を有し、製造工場からの出荷後にソフトウェアをインストールすることが可能な端末であれば、どのような種類の端末であってもよい。また、端末550は、通信機能と、UPnPのコントローラ機能を有する端末であれば、どのような種類の端末であってもよい。端末510と端末520と端末550のいずれも、例えば、携帯電話、スマートフォン、タブレット端末、PDA、ノートPCのような携帯端末であってもよいし、デスクトップPCであってもよい。また、端末510と端末520と端末550は、ネットワークを介して互いに通信することができる。また、以下では、端末510と端末520が一緒に移動するものとする。例えば、端末510は、あるユーザが携帯するスマートフォンであり、端末520は、当該ユーザが携帯するタブレット端末であるという場合、ユーザの移動にともなって端末510と端末520は一緒に移動する。サーバ530は、ネットワークを介して、端末510、端末520、およびセンサ540と通信が可能なコンピュータである。また、センサ540は、1種の検出装置である。上記のように一緒に移動する端末510と端末520が特定の環境に存在する場合に、センサ540は、端末510と端末520が特定の環境に存在することを示す検出通知を送信する。なお、第3~4実施形態に関する説明と同様に、第5実施形態に関する説明においても、環境のことをコンテキストともいう。センサ540は、特定の環境に予め設置された、無線LANアクセスポイントやRFIDリーダなどの装置であってもよい。この場合、センサ540は、一緒に移動する端末510と端末520の少なくとも一方を検出したときに、上記の検出通知を送信してもよい。あるいは、センサ540は、端末510と端末520のどちらかに内蔵されたGPSセンサであってもよい。また、端末510と端末520の双方に内蔵されたGPSセンサが、それぞれセンサ540として利用されてもよい。例えば、GPSセンサは、定期的に、または不定期に、緯度と経度を送信してもよい。端末510と端末520が特定の環境に存在する場合、緯度と経度は特定の値を持つので、上記のようにしてGPSセンサが送信する緯度と経度は、検出通知の1種として利用可能である。さて、端末510と端末520とサーバ530のさらなる詳細は、後ほど図28を参照して説明することにして、先に図27の動作シーケンス図について説明する。第5実施形態の端末510と端末520は、サービスをインストールする機能とコントローラをインストールする機能を有する、UPnPのサービス以下、更新サービスというを提供する。図27の動作シーケンスは、更新サービスを提供する1台の端末が、更新サービスを提供する他の端末を探索する処理から始まる。図27の例では、端末510がステップS1301で探索を行うが、端末510と端末520は対称的なので、場合によっては、端末520が探索を行うこともあり得る。具体的には、ステップS1301で端末510が、Msearchメッセージをマルチキャストすることにより、更新サービスを探索する。上記のとおり端末520も更新サービスを提供しているので、ステップS1302では、端末520が端末510に応答を返す。ステップS1302の応答は、具体的には、OKという意味を示す200というステータスコードを含むHTTP応答である。端末510は、ステップS1302の応答を受信すると、次に、ステップS1303で端末520のデバイス定義を要求する。すると、デバイス520は、ステップS1304でデバイス定義ファイルを端末510に送信する。端末510は、デバイス定義ファイルを受信すると、更新サービスにアクセスするための情報を得ることができる。そこで、次のステップS1305で端末510は、端末520の提供する更新サービスに関するサービス定義ファイルを、端末520に要求する。すると、端末520は、ステップS1306でサービス定義ファイルを端末510に送信する。なお、ステップS1301~S1306は、図1のステップS101~S106と類似なので、上記の説明では詳細を割愛した。さて、次のステップS1307で端末510は、検出した更新サービスに対してコマンドを送信する。ステップS1307で送信されるコマンドは、サービスまたはコントローラのデータがサーバ530から将来送信されてくるのに備えて、データを受信する準備を行うようにと端末520に促すためのコマンドである。よって、ステップS1307のコマンドを、以下では、第3~4実施形態と同様に受信準備コマンドという。受信準備コマンドは、サーバ530のアドレスを含み、端末520に対してサーバ530のアドレスを通知する役目も果たす。また、第5実施形態における受信準備コマンドも、具体的にはSOAPコマンドの形式で送信される。端末520は、受信準備コマンドを受信すると、次にステップS1308で端末510に応答を返す。ステップS1308での応答は、具体的には、OKという意味を示す200というステータスコードを含むHTTP応答である。このHTTP応答のメッセージボディには、端末520に関する情報が含まれる。具体的には、端末520のIPアドレスと、端末520のUUIDと、端末520の種別と、端末520のOSを表す情報が、HTTP応答のメッセージボディに含まれる。なお、端末520の種別とは、例えば、携帯電話、スマートフォン、タブレット端末、ノートPCなどの種別である。さらに、ステップS1309で端末520は、サーバ530からサービスまたはコントローラのデータを受信するための準備を行う。例えば、ステップS1309の受信準備は、所定のTCPポートを開放する処理を含んでもよい。また、端末510も同様に、ステップS1310で受信準備を行う。さらに、端末510は、ステップS1308の応答を受信した後、ステップS1311で、サーバ530に通知を送る。以下では説明の便宜上、ステップS1311の通知のことも受信開始通知という。第5実施形態における受信開始通知は、端末510に関する情報具体的には、端末510のIPアドレス、UUID、OS、および種別と、端末520に関する情報具体的には、端末510のIPアドレス、UUID、OS、および種別を含む。そして、以上の情報を含む受信開始通知は、端末510と端末520がペアを組んでいることを表してもいるし、また、端末510と端末520がサーバ530からのデータの受信に備えていることを表してもいる。なお、以下のステップS1312a~S1317bに例示するように、ペアを組んだ端末510と端末520の一方にやがてサービスがインストールされ、他方にコントローラがインストールされる。また、ペアを組んだ端末510と端末520の双方から重複して受信開始通知を送る必要はないため、第5実施形態では、ステップS1301の探索を行った方の端末510が、サーバ530に受信開始通知を送信する。しかし、実施形態によっては、探索に応答する方の端末520が、サーバ530に受信開始通知を送信してもよい。あるいは、端末510と端末520のそれぞれが受信開始通知を送信する実施形態も可能である。さて、第5実施形態では、第3~第4実施形態と同様に、ステップS1311で受信開始通知が送信された後、サービスとコントローラのデータがすぐにサーバ530から送信されるとは限らない。サーバ530は、ステップS1312aまたはS1312bのようなトリガを検出してはじめて、サービスとコントローラのデータを送信する。例えば、センサ540が所定の場所に固定的に設置されている場合、センサ540は、端末510または端末520を検出すると、ステップS1312aのように、センサ値と、検出した端末の端末IDとをサーバ530に送信する。この場合、センサ値は、センサ540の識別情報であってもよい。サーバ530は、センサ540の識別情報とセンサ540の設置場所を対応づけるデータベースを参照することで、端末510または端末520が検出された環境すなわちセンサ540の固定的な設置場所を判別することができる。あるいは、センサ540が端末510に内蔵されている場合、センサ540は、定期的に、または不定期に、ステップS1312aのように、センサ値と端末510の端末IDをサーバ530に送信する。同様に、センサ540が端末520に内蔵されている場合、センサ540は、定期的に、または不定期に、ステップS1312aのように、センサ値と端末520の端末IDをサーバ530に送信する。例えばセンサ値が緯度と経度の組み合わせである場合、サーバ530は、地図データを参照することにより、センサ540を内蔵する端末の存在する環境を判別することができる。なお、上記のとおり、第5実施形態では端末510と端末520が一緒に移動するものとする。つまり端末510と端末520は同じ環境にあるものとする。センサ540の種類が何であれ、図27の例では、ステップS1312aで通知されたセンサ値が、端末510と端末520が特定の環境に存在していると示す値であったものとする。また、端末IDは、端末のIPアドレスでもよいし、端末のUUIDでもよいし、両者の組み合わせでもよい。なお、ステップS1312aのようにセンサ540が通知を送信する代わりに、ステップS1312bのように、端末510がセンサ540に対して、端末510と端末520の一方にサービスのデータを送信し、他方にコントローラを送信せよと要求してもよい。例えば、場合によっては、実際のセンサ値が得られない環境もあるかもしれない。また、ユーザは、実際のセンサ値と関係なく、端末510と端末520が特定の環境にあるものと見なして、当該特定の環境に適したサービスを受けたいと思うかもしれない。よって、端末510は、ステップS1312bのように要求を送信してもよい。また、ステップS1312bの要求には、特定の環境を指定する情報つまりコンテキスト情報と、端末510の端末IDと、端末520の端末IDが含まれる。例えば、端末510は、いくつかの環境を選択肢として含むリストをユーザに提示してもよい。そして、端末510は、ユーザからの入力に基づいて、ユーザの選択した環境を指定する情報を要求に含めてもよい。そして、ステップS1312aの通知またはステップS1312bの要求の受信に応じて、サーバ530は、どちらの端末にサービスのデータを送信し、どちらの端末にコントローラのデータを送信するかを決定する。サーバ530による決定は、センサ値またはステップS1312bの要求から得られるコンテキスト情報と、端末510に関する情報具体的には種別と、端末520に関する情報具体的には種別とに基づく。なお、図27におけるステップS1313a~S1317aは、サーバ530が端末510にコントローラのデータを送信し、端末520にサービスのデータを送信すると決定した場合のシーケンスを示す。逆に、サーバ530が端末510にサービスのデータを送信し、端末520にコントローラのデータを送信すると決定した場合のシーケンスは、ステップS1313b~S1317bとして例示されている。具体的には、ステップS1313aでサーバ530は、コンテキストに応じたコントローラのデータ具体的にはコントローラのプログラムを含むデータを端末510に送信する。すると、次のステップS1314aで端末510は、コントローラを端末510自身にインストールする。また、ステップS1315aでサーバ530は、上記コントローラに対応するサービスのデータ具体的にはサービスのプログラムとサービス定義ファイルを含むデータを端末520に送信する。すると、次のステップS1316aで端末520は、サービスを端末520自身にインストールする。さらに、ステップS1317aで端末520は、図1のステップS112と同様にして、GENAにより、サービス追加更新イベントを通知する。図27の例では、端末510と端末550にサービス追加更新イベントが通知される。なお、ステップS1313aとS1315aの送信の順序は逆でもよく、端末510における処理と端末520における処理は独立して行われる。また、以上のステップS1313a~S1317aの結果として、ユーザは、端末520にインストールされたサービスを、端末510のコントローラを介して利用することができるようになる。以上のステップS1313a~S1317aとは逆に、ステップS1313b~S1317bでは、次のような処理が行われる。まず、ステップS1313bでサーバ530は、コンテキストに応じたサービスのデータを端末510に送信する。すると、次のステップS1314bで端末510は、サービスを端末510自身にインストールする。さらに、ステップS1315bで端末510は、GENAにより、サービス追加更新イベントを通知する。図27の例では、端末520と端末550にサービス追加更新イベントが通知される。また、ステップS1316bでサーバ530は、上記サービスに対応するコントローラのデータを端末520に送信する。すると、次のステップS1317bで端末520は、コントローラを端末520自身にインストールする。なお、ステップS1313bとS1316bの送信の順序は逆でもよく、端末510における処理と端末520における処理は独立して行われる。また、以上のステップS1313b~S1317bの結果として、ユーザは、端末510にインストールされたサービスを、端末520のコントローラを介して利用することができるようになる。続いて、図28を参照して、端末510と端末520とサーバ530の詳細について説明する。図28に示すように、端末510はUPnP制御部511を有し、端末520はUPnP制御部521を有する。UPnP制御部511には既存コントローラ512があってもよく、なくてもよい。同様に、UPnP制御部521には既存コントローラ522があってもよく、なくてもよい。また、端末510はUPnPサービス提供部513を有し、端末520はUPnPサービス提供部523を有する。UPnPサービス提供部513は、既存サービス514を提供していてもよく、提供していなくてもよい。同様に、UPnPサービス提供部523は、既存サービス524を提供していてもよく、提供していなくてもよい。また、UPnPサービス提供部513は更新サービス515を提供し、UPnPサービス提供部523は更新サービス525を提供する。更新サービス515と525は、UPnPのサービスとコントローラのどちらのプログラムが指定された場合にも、指定されたプログラムをインストールすることのできる、UPnPのサービスである。また、更新サービス515と525は、さらに、指定されたサービスまたはコントローラをアンインストールする機能を備えていてもよい。さらに、端末510は受信部516を有する。受信部516は、サーバ530から新規サービス518のデータまたは新規コントローラ519のデータを受信するのを待ち、データを受信すると、更新サービス515に受信を通知する。同様に、端末520は受信部526を有する。受信部526は、サーバ530から新規サービス528のデータまたは新規コントローラ529のデータを受信するのを待ち、データを受信すると、更新サービス525に受信を通知する。なお、端末510は、図27のステップS1312bのような要求を送信する要求部517を有していてもよい。要求部517は、ステップS1312bの要求に指定する環境をユーザに指定させるための処理も行う。端末520も、要求部517と同様の要求部527を有していてもよい。しかし、要求部517と要求部527はなくてもよい。図28に示す端末510と端末520の各部と図27との関係は次のとおりである。例えば、更新サービス515は、図27のステップS1301の探索、ステップS1302の応答の受信、ステップS1303の要求、ステップS1304の受信、ステップS1305の要求、およびステップS1306の受信を行う。実施形態によっては、以上のステップS1301~S1306の更新サービス515の動作を、既存コントローラ512が代わりに行ってもよい。そして、ステップS1302の応答、ステップS1303の要求の受信、ステップS1304の送信、ステップS1305の要求の受信、およびステップS1306の送信は、UPnPサービス提供部523が行う。その後のステップS1307では、更新サービス515が受信準備コマンドを送信し、更新サービス525が受信準備コマンドを受信する。さらに、更新サービス525は、ステップS1308で応答を送信し、受信部526を起動する。そして、受信部526がステップS1309の受信準備を行う。また、ステップS1308の応答は更新サービス515により受信される。そして、更新サービス515は受信部516を起動し、受信部516がステップS1310の受信準備を行う。また、受信部516は、ステップS1311で受信開始通知を送信する。なお、上記のように、ステップS1312bで要求部517が要求を送信してもよい。その後は、状況に応じて、ステップS1313aで受信部516が新規コントローラ519のデータを受信し、ステップS1314aで更新サービス515が新規コントローラ519のインストールを実行する場合もある。または、ステップS1313bで受信部516が新規サービス518のデータを受信し、ステップS1314bで更新サービス515が新規サービス518のインストールを実行し、ステップS1315bで更新サービス515が通知を送信する場合もある。端末520に関しても同様に、状況に応じた動作が行われる。具体的には、ステップS1315aで受信部526が新規サービス528のデータを受信し、ステップS1316aで更新サービス525が新規サービス528のインストールを実行し、ステップS1317aで更新サービス525が通知を送信する場合もある。または、ステップS1316bで受信部526が新規コントローラ529のデータを受信し、ステップS1317bで更新サービス525が新規コントローラ529のインストールを実行する場合もある。さて、サーバ530は、格納部531を有する。格納部531には、新規サービス518または528を提供するためのプログラムである新規サービスプログラム532と、新規コントローラ519または529を提供するためのプログラムである新規コントローラプログラム533が、格納されている。なお、簡単化のため、図28には1つの新規サービスプログラム532と1つの新規コントローラプログラム533のみが図示されている。しかし、格納部531は、複数のサービスそれぞれのプログラムと、それら複数のサービスに対応する複数のコントローラそれぞれのプログラムを格納していてもよい。格納部531は、例えば、サービスを識別する情報と対応づけて、当該サービスのプログラムと、当該サービスを利用するためのコントローラのプログラムとを格納していてもよい。また、プログラムはOSに依存することがある。そのため、格納部531は、サービスを識別する情報だけでなく、OSを表す情報とも対応づけて、新規サービスプログラム532および新規コントローラプログラム533を格納していてもよい。さて、サーバ530は、図27のステップS1312aでセンサ540から送信されるセンサ値から、コンテキストを抽出するコンテキスト抽出部534をさらに有する。コンテキスト抽出部534の詳細は、第3実施形態のコンテキスト抽出部333と同様なので、詳しい説明は省略する。第5実施形態のコンテキスト抽出部534も、実施形態に応じた適宜の粒度のコンテキストを抽出することができる。サーバ530はさらに決定部535を有する。決定部535は、送信対象のサービスと送信対象のコントローラを決定する。また、決定部535は、端末510と端末520のどちらにサービスを送信するか換言すれば、端末510と端末520のどちらにコントローラを送信するかも決定する。決定部535は、具体的には、条件テーブル536を参照することで、決定を下す。図29に、条件テーブル536の具体例を示す。図29に示すように、条件テーブル536は、以下の5つの項目を対応づけるテーブルである。コンテキストサービスのインストール先の端末以下サービス提供端末ともいうの種別コントローラのインストール先の端末以下コントローラ端末ともいうの種別コンテキストに応じたサービスつまりサービス提供端末にインストールする対象のサービス上記サービスを利用するためのコントローラつまりコントローラ端末にインストールする対象のコントローラなお、図29では、理解を容易にするために、上記5つの項目がいずれも名前で表現されているが、適宜のコード番号やIDが代わりに使われてもよい。図29には、条件テーブル536の2つのエントリが例示されている。1番目のエントリでは、会議室というコンテキストと、タブレット端末と、スマートフォンと、ドキュメント表示サービスと、ドキュメントページめくりコントローラが対応づけられている。2番目のエントリでは、自宅というコンテキストと、デスクトップPCと、スマートフォンと、ビデオ録画サービスと、ビデオリモコンコントローラが対応づけられている。例えば、図27のステップS1312aで通知された端末IDで識別される端末510の種別、および、端末510とペアを組んでいる端末520の種別は、ステップS1311で既にサーバ530に通知されている。通知された種別が、例えば、スマートフォンとタブレット端末だとする。また、ステップS1312aでは、端末510または端末520のうち、センサ540により検出された方の端末IDが通知されるものとする。そして、ステップS1312aで通知されたセンサ値から、コンテキスト抽出部534が会議室というコンテキストを抽出したとする。すると、決定部535は、センサ540からサーバ530に通知された端末IDから、端末510と端末520のペアを認識し、端末510と端末520の種別を認識する。そして、決定部535は、会議室というコンテキストと、スマートフォンという種別と、タブレット端末という種別の組み合わせに合致するエントリを条件テーブル536において検索する。なお、端末510の種別がサービス提供端末の種別に合致し、端末520の種別がコントローラ端末の種別に合致する場合と、逆に、端末510の種別がコントローラ端末の種別に合致し、端末520の種別がサービス提供端末の種別に合致する場合があり得る。検索の結果、図29の例では、1番目のエントリが見つかる。したがって、決定部535は、見つかった1番目のエントリに基づいて、次のように決定する。端末510と端末520のうち、種別がタブレット端末である方が、サービスのデータの送信先である。端末510と端末520のうち、種別がスマートフォンである方が、コントローラのデータの送信先である。送信対象のサービスは、ドキュメント表示サービスである。送信対象のコントローラは、ドキュメントページめくりコントローラである。ここで、再度図28の説明に戻ると、サーバ530はさらに、受信準備の整った端末図27の例では端末510と端末520の情報を管理する端末管理部537を有する。端末管理部537は、具体的には、端末テーブル538を用いて、端末についての情報を管理する。図30に、端末テーブル538の具体例を示す。端末テーブル538の各エントリは、1台の端末に対応する。図30には、4台の端末にそれぞれ対応する4つのエントリが例示されている。各エントリは、IPアドレス、UUID、OS、種別、および子端末UUIDという5つのフィールドを含む。以下では説明の便宜上、図27のステップS1301~S1308のような処理によりペアを組んだ2台の端末のうち、ステップS1311で受信開始通知を送信する方の端末を親端末または親といい、他方の端末を子端末または子という。なお、親子関係は、端末管理部537による管理の便宜上の関係にすぎない。つまり、親端末にサービスがインストールされて子端末にコントローラがインストールされる場合もあるし、逆に、親端末にコントローラがインストールされて子端末にサービスがインストールされる場合もある。端末テーブル538のあるエントリが、ある端末Xに関するエントリであるとする。この場合、IPアドレス、UUID、OS、および種別の各フィールドには、端末XのIPアドレス、端末XのUUID、端末XのOS、および端末Xの種別が記録される。また、子端末UUIDのフィールドには、端末Xが他の端末Yの親である場合は、端末YのUUIDが記録される。逆に、端末Xが他の端末Zの子である場合は、端末X自身は子を持たないので、端末Xに関するエントリにおける子端末UUIDの値は、NULLである。図30の端末テーブル538の例では、1番目のエントリの子端末UUIDの値が2番目のエントリのUUIDとして記録されている。そして、2番目のエントリの子端末UUIDの値はNULLである。つまり、1番目のエントリで表される端末と2番目のエントリで表される端末はペアを組んでおり、前者が親端末、後者が子端末である。また、3番目のエントリの子端末UUIDの値が4番目のエントリのUUIDとして記録されており、4番目のエントリの子端末UUIDの値はNULLである。つまり、3番目のエントリで表される端末と4番目のエントリで表される端末はペアを組んでおり、前者が親端末、後者が子端末である。ここで、再度図28の説明に戻ると、サーバ530はさらに送信部539を有する。送信部539は、決定部535の決定にしたがって、格納部531から適宜の新規サービスプログラム532を読み出して、新規サービスプログラム532とサービス定義ファイルを含むデータを、サービス提供端末に送信する。また、送信部539は、決定部535の決定にしたがって、格納部531から適宜の新規コントローラプログラム533を読み出して、新規コントローラプログラム533を含むデータを、コントローラ端末に送信する。さて次に、図31を参照して、サービスとコントローラ双方の更新機能を持つ更新サービス525がインストールされた端末520に関するデバイス定義ファイルの例について説明する。図31のデバイス定義ファイル560は、新規サービス528のインストールにともなって更新されたデバイス定義ファイルの例である。より具体的には、図31の例においては、新規サービス528は、ドキュメント表示サービスである。図31のデバイス定義ファイル560は、図3のデバイス定義ファイル150と類似である。具体的には、デバイス定義ファイル560の5~9行目には、端末520全体に関する情報が記載されており、10~25行目には、端末520が提供するサービスのリストが記載されている。図31の例では、10~25行目のリストは、11~17行目の更新サービス525に関する情報と、18~24行目のドキュメント表示サービスに関する情報を含む。図31の11~17行目の内容は、図3のデバイス定義ファイル150の11~17行目のサービス更新サービス122に関する情報の内容とは異なるが、形式は同じである。よって、図31については、詳しい説明を省略する。以上のようなデバイス定義ファイル560が、図27のステップS1304で端末520から端末510に送信される。また、図示は省略するが、更新サービス515がインストールされた端末510のデバイス定義ファイルも、図31のデバイス定義ファイル560と同様である。次に、図32を参照して、更新サービス525のサービス定義ファイルについて説明する。更新サービス525のサービス定義ファイルは、例えば、図32のサービス定義ファイル561のようなファイルであってもよい。サービス定義ファイル561は、以下のような定義を含む。サービス更新サービス122についての図4のサービス定義ファイル151と同様の、UpdateServiceというアクションの定義。サービス定義ファイル151と同様の、DeleteServiceというアクションの定義。サービス定義ファイル151と同様の、Listenというアクションの定義。コントローラ更新サービス212についての図11のサービス定義ファイル241と同様の、UpdateControllerというアクションの定義。サービス定義ファイル241と同様の、DeleteControllerというアクションの定義。サービス定義ファイル151と同様の、GetUpdateTimeというアクションの定義。サービス定義ファイル151および241と同様の、ServiceName、ServerUri、およびListeningという状態変数の定義。サービス定義ファイル151と同様の、ServiceUriおよびUpdateTimeという状態変数の定義。もちろん、実施形態によっては別のサービス定義ファイルが使われてもよい。また、端末510の更新サービス515についてのサービス定義ファイルも、更新サービス525のサービス定義ファイルと同様である。なお、図27のステップS1307の受信準備コマンドは、具体的にはListenというアクションが指定されたSOAPコマンドである。ところで、図27の処理は、サーバ530が図33~37のフローチャートにしたがって動作し、端末510が図38~39のフローチャートにしたがって動作し、端末520が図39のフローチャートにしたがって動作することにより、実現される。具体的には以下のとおりである。図33~35は、端末からの受信開始通知に応じてサーバ530が行う処理のフローチャートである。なお、サーバ530は、図27のステップS1311のように親端末からの受信開始通知を受信することがあるだけでなく、親端末または子端末の受信部から、受信開始通知と同様の形式の通知以下では、当該通知も受信開始通知というを受信することもある。例えば、DHCPによってIPアドレスが割り当てられている端末は、再起動後にIPアドレスが変化する可能性がある。そこで、端末は、再起動後に、IPアドレスをサーバ530に通知するために、受信開始通知を送信してもよい。また、OSがアップグレードされた後に、端末は、新しいOSをサーバ530に通知するために、受信開始通知を送信してもよい。ここで、ある端末Xからの受信開始通知は、以下の8つの項目を含む。端末XのIPアドレスを示す端末IPアドレス。端末XのUUIDを示す端末UUID。端末XのOSを示す端末OS。端末Xの種別を示す端末種別。端末Xが他の端末Yの親である場合は端末YのIPアドレスを示し、端末Xが他の端末Zの子である場合はNULLである子端末IPアドレス。端末Xが他の端末Yの親である場合は端末YのUUIDを示し、端末Xが他の端末Zの子である場合はNULLである子端末UUID。端末Xが他の端末Yの親である場合は端末YのOSを示し、端末Xが他の端末Zの子である場合はNULLである子端末OS。端末Xが他の端末Yの親である場合は端末Yの種別を示し、端末Xが他の端末Zの子である場合はNULLである子端末種別。また、上記のように受信開始通知は、図27のステップS1311で送信される場合があるだけでなく、任意のタイミングで送信され得るし、子端末からも送信され得る。しかも、例えば、第1と第2の端末がペアを組んだ後、第2の端末が、第3の端末からの更新サービスの探索に応えて、第3の端末とペアを組みなおすかもしれない。同様に、第1の端末が第3の端末とペアを組みなおすこともあり得る。新たなペアが組まれるたびに、ステップS1311と同様の受信開始通知がサーバ530において受信される。そこで、第5実施形態では、新たなペアが組まれた場合、サーバ530の端末管理部537は、古いペアの情報すなわち端末テーブル538上の既存エントリを適宜更新または削除し、必要に応じて新規エントリを追加することで、情報の整合性を保つ。図33~35の処理は、情報の整合性を保つための処理である。具体的には、ある端末Xからの受信開始通知をサーバ530の端末管理部537が受信する場合としては、以下の12通りの場合便宜上、ケースA~ケースLというがあり得る。図33~35の概要を明らかにするため、まず、ケースA~Lについて説明する。なお以下のケースA~Lの説明における登録とは、具体的には、端末テーブル538への登録である。ケースAは次のような場合である。端末Xは、現在、端末C0の親として登録されている。現在、端末P1が端末C1の親として登録されている。しかし、今回、端末Xは端末P1を端末Xの子として通知してきた。ケースAで端末管理部537は、端末C0と端末C1の登録を削除し、端末Xと端末P1を対応づけ、端末Xと端末P1についての登録済みの情報を通知にしたがって更新する。ケースBは次のような場合である。端末Xは、現在、端末C0の親として登録されている。今回、端末Xは端末C0を端末Xの子として通知してきた。ケースBで端末管理部537は、単純に、端末Xと端末C0についての登録済みの情報を通知にしたがって更新する。ケースCは次のような場合である。端末Xは、現在、端末C0の親として登録されている。現在、端末C1が端末P1の子として登録されている。しかし、今回、端末Xは端末C1を端末Xの子として通知してきた。ケースCで端末管理部537は、端末C0と端末P1の登録を削除し、端末Xと端末C1を対応づけ、端末Xと端末C1についての登録済みの情報を通知にしたがって更新する。ケースDは次のような場合である。端末Xは、現在、端末C0の親として登録されている。端末Uは未登録の端末である。今回、端末Xは端末Uを端末Xの子として通知してきた。ケースDで端末管理部537は、端末C0の登録を削除し、端末Uを新たに登録し、端末Xと端末Uを対応づけ、端末Xについての登録済みの情報を通知にしたがって更新する。ケースEは次のような場合である。端末Xは、現在、端末C0の親として登録されている。今回、端末Xは、端末X自身がいずれかの端末の子であるものとして、端末X自身の情報を通知してきた。ケースEで端末管理部537は、端末C0の登録を削除し、端末Xについての情報を通知にしたがって更新する。ケースFは次のような場合である。端末Xは、現在、端末P0の子として登録されている。現在、端末P1が端末C1の親として登録されている。しかし、今回、端末Xは端末P1を端末Xの子として通知してきた。ケースFで端末管理部537は、端末P0と端末C1の登録を削除し、端末Xと端末P1を対応づけ、端末Xと端末P1についての登録済みの情報を通知にしたがって更新する。ケースGは次のような場合である。端末Xは、現在、端末P0の子として登録されている。現在、端末C1が端末P1の子として登録されている。しかし、今回、端末Xは端末C1を端末Xの子として通知してきた。ケースGで端末管理部537は、端末P0と端末P1の登録を削除し、端末Xと端末C1を対応づけ、端末Xと端末C1についての登録済みの情報を通知にしたがって更新する。ケースHは次のような場合である。端末Xは、現在、端末P0の子として登録されている。端末Uは未登録の端末である。今回、端末Xは端末Uを端末Xの子として通知してきた。ケースHで端末管理部537は、端末P0の登録を削除し、端末Uを新たに登録し、端末Xと端末Uを対応づけ、端末Xについての登録済みの情報を通知にしたがって更新する。ケースIは次のような場合である。端末Xは、現在、端末P0の子として登録されている。今回、端末Xは、端末X自身の情報を通知してきた。ケースIで端末管理部537は、単純に、端末Xについての登録済みの情報を通知にしたがって更新する。ケースJは次のような場合である。端末Xは未登録である。現在、端末P1が端末C1の親として登録されている。しかし、今回、端末Xは端末P1を端末Xの子として通知してきた。ケースJで端末管理部537は、端末C1の登録を削除し、端末Xを新たに登録し、端末Xと端末P1を対応づけ、端末P1についての登録済みの情報を通知にしたがって更新する。ケースKは次のような場合である。端末Xは未登録である。現在、端末C1が端末P1の子として登録されている。しかし、今回、端末Xは端末C1を端末Xの子として通知してきた。ケースKで端末管理部537は、端末P1の登録を削除し、端末Xを新たに登録し、端末Xと端末C1を対応づけ、端末C1についての登録済みの情報を通知にしたがって更新する。ケースLは次のような場合である。端末Xは未登録である。端末Uも未登録である。今回、端末Xは端末Uを端末Xの子として通知してきた。ケースLで端末管理部537は、端末Xを新たに登録し、端末Uも新たに登録し、端末Xと端末Uを対応づける。以上のように端末管理部537は、ケースA~Lに応じて、端末テーブル538を適宜書き換えることで、情報の整合性を保つ。具体的な処理手順は、以下のとおりである。端末管理部537は、ステップS1401において、いずれかの端末以下端末Xとするから受信開始通知を受信する。すると、次にステップS1402で端末管理部537は、受信開始通知で通知された端末UUIDがUUIDフィールドに格納されたエントリつまり端末Xに対応するエントリが端末テーブル538に存在するか否かを判断する。そして、エントリが見つかった場合すなわちケースA~Iのいずれか、処理はステップS1403に移行する。逆に、エントリが見つからなかった場合すなわちケースJ~Lのいずれか、処理は図35のステップS1419に移行する。ステップS1403で端末管理部537は、ステップS1402で見つかったエントリの子端末UUIDフィールドと、受信開始通知により通知された子端末UUIDが同じか否かを判断する。両者の値が等しい場合すなわちケースBまたはI、処理はステップS1404に移行する。逆に、両者の値が異なる場合すなわちケースAおよびC~Hのうちのいずれか、処理はステップS1407に移行する。ステップS1404で端末管理部537は、受信開始通知により通知された子端末UUIDがNULLか否かを判断する。通知された子端末UUIDがNULLの場合すなわちケースI、処理はステップS1405に移行する。逆に、通知された子端末UUIDが非NULLの場合すなわちケースB、処理はステップS1406に移行する。ところで、ステップS1405は、図33に示すように、ステップS1404の判断結果によらず、実行される。つまり、ステップS1405は、ケースBでも実行され、ケースIでも実行される。ステップS1405で端末管理部537は、ステップS1402で見つかったエントリつまり端末X自身に対応するエントリを更新する。具体的には、端末管理部537は、当該エントリのIPアドレス、OS、および種別の各フィールドを、受信開始通知により通知された端末IPアドレス、端末OS、および端末種別の値で上書きする。そして、図33~35の処理は終了する。また、ステップS1406はケースBにおいて実行される。ステップS1406で端末管理部537は、端末テーブル538において、受信開始通知により通知された子端末UUIDがUUIDフィールドに格納されているエントリを更新する。つまり、端末管理部537は、端末Xにとっての子端末C0に対応するエントリを更新する。具体的には、端末管理部537は、当該エントリのIPアドレス、OS、および種別の各フィールドを、受信開始通知により通知された子端末IPアドレス、子端末OS、および子端末種別の値で上書きする。そして、処理はステップS1405へと移行する。また、ステップS1407で端末管理部537は、ステップS1402で見つかったエントリつまり端末X自身に対応するエントリの子端末UUIDフィールドがNULLか否かを判断する。子端末UUIDフィールドがNULLの場合すなわちケースF~Hのいずれか、処理はステップS1408に移行する。逆に、子端末UUIDフィールドがNULLでない場合すなわちケースAおよびC~Eのうちのいずれか、処理は図34のステップS1409に移行する。ステップS1408で端末管理部537は、ステップS1402で見つかったエントリつまり端末X自身に対応するエントリのUUIDフィールドと同じ値が子端末UUIDフィールドに格納されているエントリを削除する。つまり、端末Xにとって今まで親として登録されていた端末P0に対応するエントリを、端末管理部537は削除する。そして、処理は図34のステップS1413に移行する。さて、図34のステップS1409は、ケースAおよびC~Eのうちのいずれかであるとき、実行される。ステップS1409で端末管理部537は、ステップS1402で見つかったエントリつまり端末X自身に対応するエントリの子端末UUIDフィールドと同じ値がUUIDフィールドに格納されているエントリを削除する。つまり、端末Xにとって今まで子として登録されていた端末C0に対応するエントリを、端末管理部537は削除する。そして、次のステップS1410で端末管理部537は、受信開始通知により通知された子端末UUIDがNULLか否かを判断する。通知された子端末UUIDがNULLの場合すなわちケースE、処理はステップS1411に移行する。逆に、通知された子端末UUIDがNULLでない場合すなわちケースA、C、またはD、処理はステップS1413に移行する。ステップS1411で端末管理部537は、ステップS1402で見つかったエントリつまり端末X自身に対応するエントリの子端末UUIDフィールドをNULLに書き換える。すなわち、端末管理部537は、端末Xが子を持たないという最新情報を記録する。そして、次のステップS1412で端末管理部537は、ステップS1402で見つかったエントリつまり端末X自身に対応するエントリを更新する。具体的には、端末管理部537は、当該エントリのIPアドレス、OS、および種別の各フィールドを、受信開始通知により通知された端末IPアドレス、端末OS、および端末種別の値で上書きする。そして、図33~35の処理は終了する。さて、ステップS1413は、ケースA、C、D、F、G、またはHにおいて実行される。ステップS1413で端末管理部537は、ステップS1402で見つかったエントリつまり端末X自身に対応するエントリを更新する。具体的には、端末管理部537は、当該エントリのIPアドレス、OS、種別、および子端末UUIDの各フィールドを、受信開始通知により通知された端末IPアドレス、端末OS、端末種別、および子端末UUIDの値で上書きする。なお、子端末UUIDフィールドの上書きにより、端末Xが今までのペアを解消して別の端末と新たなペアを組んだということが端末テーブル538に反映される。そして、次のステップS1414で端末管理部537は、受信開始通知により通知された子端末UUIDがUUIDフィールドに格納されたエントリが端末テーブル538に存在するか否かを判断する。つまり、端末管理部537は、今回の端末Xからの受信開始通知により端末Xの子端末として通知された端末に対応するエントリが端末テーブル538に存在するか否かを判断する。そして、エントリが見つからない場合すなわちケースDまたはH、処理はステップS1415に移行する。逆に、エントリが見つかった場合すなわちケースA、C、F、またはG、処理はステップS1416に移行する。ステップS1415で端末管理部537は、以下のような新規エントリを端末テーブル538に追加する。つまり、端末管理部537は、ケースDまたはHにおける未登録の端末Uについての新規エントリを作成する。IPアドレスフィールドの値は、受信開始通知により通知された子端末IPアドレスである。UUIDフィールドの値は、受信開始通知により通知された子端末UUIDである。OSフィールドの値は、受信開始通知により通知された子端末OSである。種別フィールドの値は、受信開始通知により通知された子端末種別である。子端末UUIDフィールドは、NULLである。ステップS1415における以上のエントリの追加後、図33~35の処理は終了する。さて、ステップS1416は、ケースA、C、F、またはGのとき実行される。ステップS1416で端末管理部537は、ステップS1414で見つかったエントリつまり今回の受信開始通知により端末Xの子端末として通知された端末に対応するエントリの子端末UUIDフィールドがNULLか否かを判断する。子端末UUIDフィールドがNULLではない場合つまりケースAまたはF、処理はステップS1417に移行する。逆に、子端末UUIDフィールドがNULLの場合つまりケースCまたはG、処理はステップS1418に移行する。ステップS1417で端末管理部537は、ステップS1414で見つかったエントリの子端末UUIDフィールドと同じ値がUUIDフィールドに格納されているエントリを削除する。つまり、ケースAまたはFにおいて、今回端末Xが新たにペアを組んだ端末P1が今までペアを組んでいた端末C1に関するエントリを、端末管理部537は削除する。そして、処理はステップS1418へ移行する。ところで、ステップS1418は、図34に示すように、ステップS1416の判断結果によらず、実行される。つまり、ステップS1418は、ケースA、C、F、Gのいずれであっても、実行される。ステップS1418で端末管理部537は、ステップS1414で見つかったエントリつまり今回の受信開始通知により端末Xの子端末として通知された端末に対応するエントリを更新する。具体的には、端末管理部537は、当該エントリのIPアドレス、OS、および種別の各フィールドを、受信開始通知により通知された子端末IPアドレス、子端末OS、および子端末種別の値で上書きする。また、端末管理部537は、当該エントリの子端末UUIDフィールドをNULLに上書きする。なお、子端末UUIDフィールドの上書きにより、端末Xの新たな子端末が、今までのペアを解消して端末Xと新たにペアを組んだということが端末テーブル538に反映される。ステップS1418での更新が済むと、図33~35の処理も終了する。さて、図35のステップS1419は、ケースJ、K、またはLのときつまり端末テーブル538に未登録の端末Xから受信開始通知を端末管理部537が受信した場合に実行される。ステップS1419で端末管理部537は、受信開始通知により通知された子端末UUIDがUUIDフィールドに格納されたエントリが端末テーブル538に存在するか否かを判断する。そして、エントリが見つかった場合すなわちケースJまたはK、処理はステップS1420に移行する。逆に、エントリが見つからなかった場合すなわちケースL、処理はステップS1424に移行する。ステップS1420で端末管理部537は、ステップS1419で見つかったエントリつまりケースJの場合は端末P1に対応するエントリであり、ケースKの場合は端末C1に対応するエントリの子端末UUIDフィールドがNULLか否かを判断する。そして、子端末UUIDフィールドがNULLの場合つまりケースK、処理はステップS1421に移行する。逆に、子端末UUIDフィールドがNULLでない場合つまりケースJ、処理はステップS1422に移行する。ところで、ステップS1421は、図35に示すように、ステップS1420の判断結果によらず、実行される。つまり、ステップS1421は、ケースJでも実行され、ケースKでも実行される。ステップS1421で端末管理部537は、ステップS1419で見つかったエントリを更新する。更新対象のエントリは、今までのペアを解消して端末Xと新たにペアを組む登録済みの端末に関するエントリであり、より具体的には、ケースJの場合は端末P1に対応するエントリであり、ケースKの場合は端末C1に対応するエントリである。ステップS1419において、端末管理部537は、具体的には、当該エントリのIPアドレス、OS、および種別の各フィールドを、受信開始通知により通知された子端末IPアドレス、子端末OS、および子端末種別の値で上書きする。ステップS1421での更新後、処理はステップS1425に移行する。さて、ステップS1422~S1423はケースJで実行される。具体的には、ステップS1422で端末管理部537は、ステップS1419で見つかったエントリつまり端末P1に対応するエントリの子端末UUIDフィールドと同じ値がUUIDフィールドに格納されているエントリを削除する。換言すれば、端末管理部537は、ケースJにおける端末C1に対応するエントリを削除する。そして、次のステップS1423で端末管理部537は、ステップS1419で見つかったエントリの子端末UUIDフィールドをNULLに更新する。換言すれば、端末管理部537は、ケースJにおける端末P1を、親端末の立場から子端末の立場へと、いわば変身させる。そして、処理はステップS1421に移行する。さて、ステップS1424はケースLのとき実行される。ステップS1424で端末管理部537は、以下のような新規エントリを端末テーブル538に追加する。つまり、端末管理部537は、ケースLにおける未登録の端末Uについての新規エントリを作成する。IPアドレスフィールドの値は、受信開始通知により通知された子端末IPアドレスである。UUIDフィールドの値は、受信開始通知により通知された子端末UUIDである。OSフィールドの値は、受信開始通知により通知された子端末OSである。種別フィールドの値は、受信開始通知により通知された子端末種別である。子端末UUIDフィールドは、NULLである。ステップS1424における以上のエントリの追加後、処理はステップS1425に移行する。ステップS1425は、ケースJ、K、またはLのときつまり端末テーブル538に未登録の端末Xから受信開始通知を端末管理部537が受信した場合、実行される。ステップS1425で端末管理部537は、以下のような新規エントリを端末テーブル538に追加する。つまり、端末管理部537は、端末Xについての新規エントリを作成する。IPアドレスフィールドの値は、受信開始通知により通知された端末IPアドレスである。UUIDフィールドの値は、受信開始通知により通知された端末UUIDである。OSフィールドの値は、受信開始通知により通知された端末OSである。種別フィールドの値は、受信開始通知により通知された端末種別である。子端末UUIDフィールドの値は、受信開始通知により通知された子端末UUIDである。ステップS1425における以上のエントリの追加後、図33~35の処理も終了する。次に、図36~37のフローチャートを参照して、図27のステップS1312aのようなセンサ540からの通知に応じてサーバ530が行う処理について説明する。図36~37のフローチャートにしたがって、図27のステップS1312a、S1313a、およびS1315aの処理シーケンスが実現されることもあるし、ステップS1312a、S1313b、およびS1316bの処理シーケンスが実現されることもある。さて、ステップS1501でコンテキスト抽出部534が、センサ540から、図27のステップS1312aのように、センサ値と端末IDを受信する。端末IDは、具体的には、IPアドレスまたはUUIDである。次に、ステップS1502でコンテキスト抽出部534が、通知されたセンサ値からコンテキスト情報を生成する。ステップS1502におけるコンテキスト情報の生成方法の詳細は、図18のステップS702と同様である。そして、コンテキスト抽出部534は、生成したコンテキスト情報を決定部535に通知する。また、ステップS1503でコンテキスト抽出部534は、センサ540から通知された端末IDを端末管理部537に通知する。そして、端末管理部537は、通知された端末IDがUUIDとIPアドレスのどちらなのかを判断する。通知された端末IDがUUIDの場合、処理はステップS1504に移行する。逆に、通知された端末IDがIPアドレスの場合、処理はステップS1505に移行する。ステップS1504で端末管理部537は、通知されたUUIDがUUIDのフィールドに記憶されているエントリが、端末テーブル538にあるか否かを判断する。もしそのようなエントリがなければ、図36~37の処理は終了する。逆に、通知されたUUIDがUUIDのフィールドに記憶されているエントリが見つかれば、端末管理部537は、見つけたエントリを決定部535に通知し、処理はステップS1506に移行する。また、ステップS1505で端末管理部537は、通知されたIPアドレスがIPアドレスのフィールドに記憶されているエントリが端末テーブル538にあるか否かを判断する。もしそのようなエントリがなければ、図36~37の処理は終了する。逆に、通知されたUUIDがUUIDのフィールドに記憶されているエントリが見つかれば、端末管理部537は、見つけたエントリを決定部535に通知し、処理はステップS1506に移行する。ステップS1506で端末管理部537は、ステップS1504またはS1505で見つかったエントリの子端末UUIDのフィールドがNULLか否かを判断する。子端末UUIDのフィールドがNULLの場合、処理はステップS1507に移行する。逆に、子端末UUIDのフィールドがNULLでない場合、処理はステップS1508に移行する。ステップS1507は、センサ540から通知された端末IDが、ある端末の子端末のIDである場合に実行される。ステップS1507で端末管理部537は、当該子端末の種別と、当該子端末の親である上記ある端末の種別を取得する。具体的には、端末管理部537は、ステップS1504またはS1505で見つかったエントリの種別の値を取得する。また、端末管理部537は、ステップS1504またはS1505で見つかったエントリのUUIDのフィールドの値が、子端末UUIDのフィールドに記憶されているエントリの、種別の値を取得する。そして、端末管理部537は、取得した2台の端末の種別の値を決定部535に通知する。また、端末管理部537は、2台の端末に対応する2つのエントリを決定部535に通知してもよい。そして、処理は図37のステップS1509に移行する。他方、ステップS1508は、センサ540から通知された端末IDが、ある端末の親端末のIDである場合に実行される。ステップS1508で端末管理部537は、当該親端末の種別と、当該親端末の子である上記ある端末の種別を取得する。具体的には、端末管理部537は、ステップS1504またはS1505で見つかったエントリの種別の値を取得する。また、端末管理部537は、ステップS1504またはS1505で見つかったエントリの子端末UUIDのフィールドの値が、UUIDのフィールドに記憶されているエントリの、種別の値を取得する。そして、端末管理部537は、取得した2台の端末の種別の値を決定部535に通知する。また、端末管理部537は、2台の端末に対応する2つのエントリを決定部535に通知してもよい。そして、処理は図37のステップS1509に移行する。さて、図37のステップS1509で決定部535は、下記の情報の組み合わせと合致するエントリが条件テーブル536にあるか否かを判断する。ステップS1502でコンテキスト抽出部534から通知されたコンテキスト情報。ステップS1507またはS1508で端末管理部537から通知された、2台の端末それぞれの種別。例えば、センサ540から通知された端末IDが、10.8.9.11というIPアドレスだったとする。この場合、図30の端末テーブル538の2番目のエントリがステップS1505で見つかる。また、端末テーブル538の2番目のエントリの子端末UUIDのフィールドは、NULLである。よって、ステップS1507で、2番目のエントリの種別が取得され、さらに、2番目のエントリが表す端末の親端末を表すエントリすなわち1番目のエントリの種別が取得される。すなわち、タブレット端末とスマートフォンという2つの種別の値が取得される。ここで、仮にステップS1502では会議室というコンテキストが抽出されたとする。すると、ステップS1509において、決定部535は、図29の条件テーブル536において、会議室とタブレット端末とスマートフォンの組み合わせと合致する1番目のエントリを見つける。また、仮にセンサ540から通知された端末IDが10.8.9.10というIPアドレスだった場合も、ステップS1507ではなくステップS1508で種別の値が取得される点以外は上記と同様にして、条件テーブル536の1番目のエントリが見つかる。例えば以上のようにして、ステップS1509において条件テーブル536のエントリが見つかった場合、処理はステップS1510に移行する。逆に、エントリが見つからなければ、図36~37の処理は終了する。ステップS1510で決定部535は、ステップS1509において条件テーブル536で見つかったエントリの、サービス提供端末の種別のフィールドと種別の値が合致した方の端末を、サービスの宛先として決定する。そして、決定部535は、当該端末のIPアドレス、UUID、およびOSの値を、端末テーブル538から取得し、取得した値を、サービスの宛先の端末に関する情報として送信部539に通知する。また、決定部535は、ステップS1509において条件テーブル536で見つかったエントリのサービスを、送信対象のサービスとして送信部539に通知する。さらに、ステップS1511で決定部535は、ステップS1509において条件テーブル536で見つかったエントリの、コントローラ端末の種別のフィールドと種別の値が合致した方の端末を、コントローラの宛先として決定する。そして、決定部535は、当該端末のIPアドレス、UUID、およびOSの値を、端末テーブル538から取得し、取得した値を、コントローラの宛先の端末に関する情報として送信部539に通知する。また、決定部535は、ステップS1509において条件テーブル536で見つかったエントリのコントローラを、送信対象のコントローラとして送信部539に通知する。なお、ステップS1510とS1511の順序は逆でもよい。例えば上記のようにセンサ540から10.8.9.11というIPアドレスが端末IDとして通知された場合、ステップS1509では条件テーブル536の1番目のエントリが見つかる。よって、ステップS1510では、種別がタブレット端末である方の端末つまり10.8.9.11というIPアドレスの端末が、ドキュメント表示サービスの宛先として決定される。また、ステップS1511では、種別がスマートフォンである方の端末つまり10.8.9.10というIPアドレスの端末が、ドキュメントページめくりコントローラの宛先として決定される。最後に、ステップS1512で送信部539は、条件テーブル536からサービスとコントローラそれぞれの宛先として通知された端末に対し、サービスとコントローラそれぞれのデータを送信する。なお、送信部539は、決定部535から通知されたOSの値に応じて、適宜の新規サービスプログラム532と適宜の新規コントローラプログラム533を選んで送信する。ステップS1512の送信は、図27のステップS1313aとS1315aの送信に対応する場合もあるし、ステップS1313bとS1316bの送信に対応する場合もある。なお、ステップS1504、S1505、またはS1509で、検索条件に合致するエントリが見つからない場合は、何らかのエラーがある場合である。よって、これらの場合、上記のとおり図36~37の処理は終了し、ステップS1512のような送信は行われない。さて、図38は、端末510が事前に行う処理のフローチャートである。図38は、図27のステップS1301~S1311に対応する。なお、場合によっては端末520が図38の処理を行ってもよいすなわち図27で端末510と端末520が入れ替わってもよい。さて、ステップS1601で更新サービス515が、図27のステップS1301のようなMsearchメッセージのマルチキャストにより、端末510の周辺にある端末の更新サービスを検索する。もし、端末520のように、更新サービスを提供する端末があれば、更新サービス515は図27のステップS1302のような応答を受信する。この場合、更新サービス515はさらに、図27のステップS1303~S1306のようにして、発見した他の端末例えば端末520のデバイス定義ファイルと、発見した更新サービスのサービス定義ファイルを取得する。次に、ステップS1602で更新サービス515は、ステップS1601で更新サービスを提供する端末が発見されたか否かを判断する。ステップS1601でのMsearchメッセージの送信から所定の時間が経過しても、ステップS1302のような応答が1つも受信されない場合、更新サービス515は、更新サービスを提供する他の端末は発見されなかったと判断する。そして、図38の処理も終了する。逆に、ステップS1302のような応答が得られて、デバイス定義ファイルとサービス定義ファイルが取得されていれば、更新サービスを提供する他の端末例えば端末520が存在する。よって、この場合、更新サービス515は、更新サービスを提供する他の端末が発見されたと判断し、処理はステップS1603へと移行する。さて、以下の説明では、ステップS1601の検索の結果、更新サービス525を提供する端末520が見つかったものとする。ステップS1603で更新サービス515は、ステップS1601の検索の結果見つけた端末520に対して、図27のステップS1307のように受信準備コマンドを送信する。そして、更新サービス515は、受信準備コマンドに対する、ステップS1308のような応答を、見つけた端末520から受信する。受信される応答は、更新サービス515が見つけた端末520の、IPアドレス、UUID、OS、および種別の値を含む。そして、次のステップS1604で更新サービス515は、受信部516を起動する。その際、更新サービス515は、受信部516に対して、以下の情報を通知する。端末510自身のUUID。更新サービス515が見つけた端末520の、IPアドレス、OS、および種別。サーバ530のアドレス例えばURI。起動された受信部516は、サーバ530からデータを受信するための適宜の処理例えば、所定のTCPポートを開放する処理などを行う。ステップS1604は図27のステップS1310の受信準備に対応する。また、ステップS1605で受信部516は、サーバ530の端末管理部537に対して、以下の情報を通知する。端末510自身の、IPアドレス、OS、および種別。更新サービス515が見つけた端末520の、IPアドレス、OS、および種別。ステップS1605の通知は、具体的には、図27のステップS1311の受信開始通知である。さて、図39は、端末510と端末520のそれぞれがサーバ530からのデータの受信に応じて行う処理のフローチャートである。以下では便宜上、端末510が図39の処理を実行する場合を例にして説明を行う。まず、ステップS1701で受信部516が、サーバ530からデータを受信する。そして、ステップS1702で受信部516は、受信したデータがサービスのデータなのかコントローラのデータなのかを判断する。サービスのデータつまり新規サービスプログラム532とサービス定義ファイルを含むデータが受信された場合、処理はステップS1703に移行する。逆に、コントローラのデータつまり新規コントローラプログラム533を含むデータが受信された場合、処理はステップS1707に移行する。ステップS1703で受信部516は、受信したサービスのデータを更新サービス515に通知する。すると、ステップS1704で更新サービス515は、受信部516から通知されたデータを使って、以下の3つの処理を行う。第1に、更新サービス515は、端末510のデバイス定義ファイルを更新する。第2に、更新サービス515は、新規サービス518のサービス定義ファイルを追加または更新する。つまり、新規サービス518が今まで端末510に存在していなかった全く新しいサービスである場合は、更新サービス515は、新たなサービス定義ファイルを作成して保存する。また、新規サービス518が、端末510にインストール済みの既存のサービスの新規バージョンである場合は、更新サービス515は、当該既存のサービスのサービス定義ファイルを更新する。第3に、更新サービス515は、受信した新規サービスプログラム532を端末510にインストールする。そして、次のステップS1705で更新サービス515は、図32のサービス定義ファイル561で定義されているUpdateTimeという状態変数の値を現在時刻に更新する。端末510が図39の処理を実行する場合、ステップS1704~S1705は、図27のステップS1314bに対応する。最後に、ステップS1706で更新サービス515は、GENAにより、端末510の周辺の端末例えば、図27の例では、端末520と端末550に対して、ステップS1705で更新したUpdateTimeという状態変数の値を通知する。端末510が図39の処理を実行する場合、ステップS1706は、図27のステップS1315bに対応する。他方、コントローラのデータが受信された場合、ステップS1707~S1708の処理が行われる。つまり、ステップS1707で受信部516が、受信した新規コントローラプログラム533を更新サービス515に通知する。すると、ステップS1708で更新サービス515が、通知された新規コントローラプログラム533を端末510にインストールする。端末510が図39の処理を実行する場合、ステップS1708は図27のステップS1314aに対応する。以上説明した第5実施形態には、サービスとコントローラの更新による利便性向上という効果がある。また、更新サービス515と525はUPnPのサービスであるため、UPnP用のライブラリを介して更新サービス515と525の普及が促進される。さらに、第5実施形態では、コンテキストに応じた動的なサービスの利用が可能となる。ところで、以上説明した第1~第5実施形態における種々の装置は、どれも1種の情報処理装置である。図40に情報処理装置の構成図を示す。図40の情報処理装置600は、CPUCentralProcessingUnit601、ROMReadOnlyMemory602、RAMRandomAccessMemory603、および通信インタフェイス604を有する。また、情報処理装置600はさらに、入力装置605、出力装置606、記憶装置607、および記憶媒体610の駆動装置608を有していてもよい。そして、情報処理装置600内の上記コンポーネントは、バス609により互いに接続されている。また、情報処理装置600は、通信インタフェイス604を介してネットワーク611に接続されている。ネットワーク611は、例えば、LANでもよいし、LANとインターネットの組み合わせでもよい。CPU601は、プログラムをRAM603にロードし、RAM603をワーキングエリアとしても使用しながら、プログラムを実行する。プログラムは、予めROM602または記憶装置607に記憶されていてもよい。記憶装置607は、例えばハードディスク装置であってもよい。あるいは、プログラムは、プログラム提供者612により提供され、ネットワーク611と通信インタフェイス604を介して情報処理装置600にダウンロードされ、記憶装置607に記憶されてもよい。プログラム提供者612は、例えば、情報処理装置600以外の他の情報処理装置である。また、プログラムは、コンピュータ読み取り可能な可搬型の記憶媒体610に記憶されて提供されてもよい。プログラムは、駆動装置608にセットされた記憶媒体610から、駆動装置608により読み取られる。読み取られたプログラムは、その後、一旦記憶装置607にコピーされてからRAM603にロードされてもよいし、直接RAM603にロードされてもよい。記憶媒体610としては、CDCompactDiscやDVDDigitalVersatileDiskなどの光ディスク、光磁気ディスク、磁気ディスク、不揮発性の半導体メモリカードなどが利用可能である。なお、図40には1つの通信インタフェイス604のみが図示されているが、情報処理装置600は、異なる複数の種類の通信インタフェイス604を有していてもよい。例えば、以下のようなものが通信インタフェイス604として利用可能である。有線LAN用のネットワークインタフェイス装置無線LAN用のネットワークインタフェイス装置無線PANPersonalAreaNetwork用のネットワークインタフェイス装置3GPPThirdGenerationPartnershipProject、LTELongTermEvolution、WiMAXWorldwideInteroperabilityforMicrowaveAccessなどの、携帯電話やスマートフォンなどで使われる通信規格にしたがった通信回路入力装置605は、例えば、入力ボタン、キーボード、マウスやタッチスクリーンなどのポインティングデバイス、マイク、またはそれらの組み合わせである。出力装置606は、例えば、ディスプレイ、スピーカ、LEDLightEmittingDiodeランプなどのインジケータ、またはそれらの組み合わせである。ディスプレイは、タッチスクリーンであってもよい。また、ROM602、RAM603、記憶装置607、および記憶媒体610は、いずれも、コンピュータ読み取り可能な記憶媒体の例である。これらのコンピュータ読み取り可能な記憶媒体は、有形のtangible記憶媒体であり、信号搬送波のような一時的なtransitory媒体ではない。ところで、第1実施形態と図40の関係は次のとおりである。図1~2の端末110、デバイス120、サービス管理装置130、および端末140のいずれも、情報処理装置600のように構成されていてもよい。図1のシーケンス図に示すような各種の通信は、通信インタフェイス604とネットワーク611を介して行われる。端末110のUPnPコントローラ111は、プログラムを実行するCPU601と、CPU601からの指示にしたがって通信を行う通信インタフェイス604により実現される。デバイス120のUPnPサービス提供部121も同様に、CPU601と通信インタフェイス604より実現される。サービス管理装置130の格納部131は、サービス管理装置130の記憶装置607により実現される。なお、図2の格納部131の中には、簡単化のため、新規サービス123についてのデータとして、新規サービスプログラム132しか図示されていない。しかし、新規サービス123のサービス定義ファイルなども、格納部131には格納されている。他の実施形態に関する図でも同様に、格納部の中にはプログラムしか図示されていないが、格納部には、定義ファイルなどの他の情報も含むデータが格納されている。図3のデバイス定義ファイル150や図4のサービス定義ファイル151は、デバイス120の記憶装置607に格納されており、必要に応じてRAM603上に読み出される。端末110は、取得したデバイス定義ファイル150やサービス定義ファイル151を、RAM603上に保持してもよいし、必要に応じて記憶装置607に格納してもよい。また、第2実施形態と図40の関係は次のとおりである。図7~8の端末210、デバイス220、およびコントローラ管理装置230のいずれも、情報処理装置600のように構成されていてもよい。図7のシーケンス図に示すような各種の通信は、通信インタフェイス604とネットワーク611を介して行われる。端末210のUPnP制御部211とコントローラ更新サービス212は、いずれも、プログラムを実行するCPU601と、CPU601からの指示にしたがって通信を行う通信インタフェイス604により実現される。デバイス220のUPnPサービス提供部221も同様に、CPU601と通信インタフェイス604より実現される。また、コントローラ管理装置230のコントローラ決定部233も同様に、CPU601と通信インタフェイス604より実現される。そして、コントローラ管理装置230の格納部231は、コントローラ管理装置230の記憶装置607により実現される。条件テーブル234は、コントローラ管理装置230の記憶装置607に予め格納されており、必要に応じてRAM603上に読み出される。図10のデバイス定義ファイル240や図11のサービス定義ファイル241は、端末210の記憶装置607に格納されており、必要に応じてRAM603上に読み出される。また、第3実施形態と図40の関係は次のとおりである。図13~14の端末310、デバイス320、サーバ330、および端末350のいずれも、情報処理装置600のように構成されていてもよい。図13のシーケンス図に示すような各種の通信は、通信インタフェイス604とネットワーク611を介して行われる。端末310のUPnPコントローラ311と要求部312は、いずれも、プログラムを実行するCPU601と、CPU601からの指示にしたがって通信を行う通信インタフェイス604により実現される。デバイス320のUPnPサービス提供部321と受信部324のそれぞれも、同様に、CPU601と通信インタフェイス604より実現される。サーバ330のコンテキスト抽出部333とサービス決定部334とデバイス管理部336と送信部338のそれぞれも、同様に、CPU601と通信インタフェイス604より実現される。また、サーバ330の格納部331は、サーバ330の記憶装置607により実現される。条件テーブル335は、サーバ330の記憶装置607に予め格納されており、必要に応じてRAM603上に読み出される。デバイステーブル337は、RAM603上に作成され、記憶されていてもよい。そして、図3のデバイス定義ファイル150や図4のサービス定義ファイル151は、デバイス320の記憶装置607に格納されており、必要に応じてRAM603上に読み出される。端末310は、取得したデバイス定義ファイル150やサービス定義ファイル151を、RAM603上に保持してもよいし、必要に応じて記憶装置607に格納してもよい。また、第4実施形態と図40の関係は次のとおりである。図20~21の端末410、デバイス420、およびサーバ430のいずれも、情報処理装置600のように構成されていてもよい。図20のシーケンス図に示すような各種の通信は、通信インタフェイス604とネットワーク611を介して行われる。端末410のUPnP制御部411とコントローラ更新サービス412と受信部413と要求部414は、いずれも、プログラムを実行するCPU601と、CPU601からの指示にしたがって通信を行う通信インタフェイス604により実現される。デバイス420のUPnPサービス提供部421も同様に、CPU601と通信インタフェイス604より実現される。サーバ430のコンテキスト抽出部433とコントローラ決定部434と端末管理部436と送信部438のそれぞれも、同様に、CPU601と通信インタフェイス604より実現される。また、サーバ430の格納部431は、サーバ430の記憶装置607により実現される。条件テーブル435は、サーバ430の記憶装置607に予め格納されており、必要に応じてRAM603上に読み出される。端末テーブル437は、RAM603上に作成され、記憶されていてもよい。そして、図10のデバイス定義ファイル240や図11のサービス定義ファイル241は、端末410の記憶装置607に格納されており、必要に応じてRAM603上に読み出される。また、第5実施形態と図40の関係は次のとおりである。図27~28の端末510、端末520、およびサーバ530のいずれも、情報処理装置600のように構成されていてもよい。図27のシーケンス図に示すような各種の通信は、通信インタフェイス604とネットワーク611を介して行われる。端末510のUPnP制御部511とUPnPサービス提供部513と受信部516と要求部517は、いずれも、プログラムを実行するCPU601と、CPU601からの指示にしたがって通信を行う通信インタフェイス604により実現される。同様に、端末520のUPnP制御部521とUPnPサービス提供部523と受信部526と要求部527は、いずれも、プログラムを実行するCPU601と、CPU601からの指示にしたがって通信を行う通信インタフェイス604により実現される。サーバ530のコンテキスト抽出部534と決定部535と端末管理部537と送信部539のそれぞれも、同様に、CPU601と通信インタフェイス604より実現される。また、サーバ530の格納部531は、サーバ530の記憶装置607により実現される。条件テーブル536は、サーバ530の記憶装置607に予め格納されており、必要に応じてRAM603上に読み出される。端末テーブル538は、RAM603上に作成され、記憶されていてもよい。そして、端末520に関する図31のデバイス定義ファイル550や図32のサービス定義ファイル551は、端末520の記憶装置607に格納されており、必要に応じてRAM603上に読み出される。端末510は、端末520からデバイス定義ファイル550やサービス定義ファイル551を取得した場合、取得したこれらのファイルを、RAM603上に保持してもよいし、必要に応じて記憶装置607に格納してもよい。同様に、端末510に関するデバイス定義ファイルやサービス定義ファイルは、端末510の記憶装置607に格納されており、必要に応じてRAM603上に読み出される。端末520は、端末510からデバイス定義ファイルやサービス定義ファイルを取得した場合、取得したこれらのファイルを、RAM603上に保持してもよいし、必要に応じて記憶装置607に格納してもよい。ところで、本発明は上記の第1~第5実施形態に限られるものではない。上記の説明においてもいくつかの変形について説明したが、第1~第5実施形態は、さらに下記の観点から変形することもできる。そして、上記の各実施形態および下記の各種変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。例えば、上記の説明においては、様々なシーケンス図とフローチャートを用いて、様々な処理を説明したが、いくつかのステップの順番は入れ替え可能である。例えば、図1のステップS108とS109の順序は逆でもよい。また、図27において、ステップS1310がステップS1307の前に行われてもよい。他にも、順序を入れ替えても矛盾が生じないステップ同士は、逆の順序で実行されてもよいし、並行して実行されてもよい。デバイス定義ファイルやサービス定義ファイルの具体的な内容も、実施形態に応じて様々であってよい。例えば、サービス更新サービスのサービス定義ファイルにおける各アクションの定義は、図示した定義とは異なる定義であってもよい。また、いくつかの図ではデータをテーブル形式で例示した。しかし、テーブル形式以外の形式が使われてもよい。例えば、XML形式のデータが使われてもよいし、連想配列が使われてもよい。なお、上記では説明の簡単化のため、第1実施形態と第2実施形態に関しては、OS依存性について説明を省略した。しかし、例えば第1実施形態において、サービス管理装置130は、同じ新規サービス123に対応する、複数のOS用の複数の新規サービスプログラム132を、格納部131に格納していてもよい。そして、図1のステップS109の要求は、デバイス120のOSに関する情報を含んでいてもよい。サービス管理装置130は、通知されたOS用の新規サービスプログラム132をステップS110で送信してもよい。第2実施形態も同様に変形されてよい。例えば、コントローラ管理装置230は、同じ新規コントローラ213に対応する、複数のOS用の複数の新規コントローラプログラム232を、格納部231に格納していてもよい。そして、図7のステップS307の要求は、端末210のOSに関する情報を含んでいてもよい。コントローラ管理装置230は、通知されたOS用の新規コントローラプログラム232をステップS308で送信してもよい。また、いくつかの実施形態を組み合わせることも可能である。例えば、第1実施形態のサービス更新サービス122と、第3実施形態のサービス更新サービス322の機能を兼ね備えたサービス更新サービスが、デバイスに実装されてもよい。同様に、第2実施形態のコントローラ更新サービス212と、第4実施形態のコントローラ更新サービス412の機能を兼ね備えたコントローラ更新サービスが、端末に実装されてもよい。あるいは、第5実施形態の更新サービス515や525が、第1実施形態のサービス更新サービス122のようにコンテキストに依存せずにサービスを更新する機能をさらに有していてもよい。同様に、更新サービス515や525が、第2実施形態のコントローラ更新サービス212のようにコンテキストに依存せずにコントローラを更新する機能をさらに有していてもよい。また、第5実施形態の説明から明らかなように、1台の端末が、場合に応じて、UPnPコントローラとして動作し得るだけでなく、UPnPサービスを提供することもできる。そこで、以下のような第1実施形態と第2実施形態の組み合わせも可能である。すなわち、1台の端末の中に、第1実施形態のサービス更新サービス122と第2実施形態のコントローラ更新サービス212の双方があってもよい。ところで、図1のステップS101、図7のステップS301、図13のステップS501、図20のステップS901、および図27のステップS1301には、Msearchメッセージの送信による探索が例示されている。そして、これらのステップの探索に対して、図1、7、13、20、および27には、1つの応答が返される場合が例示されている。しかし、状況によっては、2つ以上の応答が返される場合があり得る。例えば、図1のステップS101のMsearchメッセージに対して、それぞれサービス更新サービス122を提供する複数のデバイスデバイス120が、ステップS102と同様に応答を返すことがあり得る。その場合、端末110は、複数のデバイス120のそれぞれに対して、ステップS103以降の処理を実行してもよい。逆に、端末110は、複数のデバイス120のうちの1台を選んでから、選んだ1台のデバイス120に対してステップS103以降の処理を実行してもよい。端末110は、例えば、発見された複数のデバイス120のリストを画面に表示し、ユーザからの入力に応じて1台のデバイス120を選択してもよい。あるいは、端末110は、発見された複数のデバイス120のうちの任意の1台例えば最も早く応答を返したデバイス120を自動的に選択してもよい。図7の場合も同様に、ステップS302のような応答が2つ以上返された場合は、端末210は、1台のデバイス220を選択してもよいし、複数のデバイス220それぞれに対してステップS303以降の処理を実行してもよい。図13と図20の場合も上記の図1や図7と同様である。なお、第5実施形態では、サーバ530の端末管理部537が2台の端末をペアとして管理する。よって、図27のステップS1302のような応答が複数得られた場合、端末510は、複数の端末520の中から1台を選択してステップS1303以降の処理を実行することが好ましい。しかし、端末管理部537による端末の管理の仕方が変形された実施形態においては、端末510は、ステップS1302のような応答を返した複数の端末520のそれぞれに対してステップS1303以降の処理を実行してもよい。例えば、端末管理部537は、2台以上の端末を含む端末グループを管理してもよい。例えば、ステップS1302のような応答が2台の端末520から返された場合、端末510は、2台の端末520それぞれに対してステップS1303~S1308の処理を行ってもよい。そして、ステップS1311では、3台の端末つまり端末510自身と、発見された2台の端末520についての情報を含む受信開始通知を、端末510が送信してもよい。端末管理部537は、3台の端末を1つのグループとして管理してもよい。そして、決定部535は、ステップS1312aまたはS1312bの通知に応じて、同じグループに属する任意の2台の端末のペアのうち、通知されたコンテキストとの組み合わせが条件テーブル536のエントリと合致するペアを選んでもよい。また、各実施形態において、サービスまたはコントローラのインストール前に、ユーザにインストールを承認してもらうための処理が行われてもよい。例えば、第1実施形態において、端末110の持ち主とデバイス120の持ち主は違うかもしれない。そこで、例えばステップS107のサービス追加更新コマンドを受信すると、デバイス120は、指定されたサービスのインストールを許可するか否かをデバイス120のユーザに尋ねるダイアログを表示してもよい。ユーザがインストールを許可した場合のみ、図1のステップS108以降の処理が行われてもよい。他の実施形態においても、適宜のタイミングで、プログラムのインストールを許可するか否かをユーザに確認させるための処理が行われてもよい。また、上記の説明では、簡単化のため、エラー処理については省略したが、適宜のエラー処理がさらに行われてもよい。例えば、要求されたサービスまたはコントローラのデータがない場合にエラーメッセージを送信するなどの処理が行われてもよい。ところで、上記の説明においては、サービスまたはコントローラの削除についての説明を簡略化したが、以下のようにして削除が行われてもよい。例えば、第1実施形態の端末110は、図1のステップS111でデバイス120にインストールされた新規サービス123を使い終わったら、デバイス120に対して、新規サービス123の削除を命じてもよい。具体的には、端末110のUPnPコントローラ111は、図4のサービス定義ファイル151で定義されたDeleteServiceアクションを指定したSOAPコマンドをサービス更新サービス122に対して送信してもよい。そして、サービス更新サービス122は、受信したコマンドに応じて、削除対象として指定された新規サービス123をアンインストールしてもよい。あるいは、サービス更新サービス122は、デバイス定義ファイル150から、指定された新規サービス123に関する定義例えば図3の18~24行を単に削除することで、新規サービス123を外部のコントローラから使用不能な状態にしてもよい。なお、サービス管理装置130が新規サービス123用のアンインストーラを格納していてもよく、サービス更新サービス122は、アンインストーラをサービス管理装置130に要求してもよい。もちろん、削除対象のサービスは、図2の新規サービス123に限らず、任意のサービスでよい。また、端末110が削除を命じるタイミングも任意である。また、第2実施形態の端末210は、図7のステップS309でインストールされた新規コントローラ213を使ってサービス222を利用し終わったら、新規コントローラ213を削除してもよい。具体的には、コントローラ更新サービス212が、新規コントローラ213を削除してもよい。なお、コントローラ管理装置230が新規コントローラ213用のアンインストーラを格納していてもよく、コントローラ更新サービス212は、アンインストーラをコントローラ管理装置230に要求してもよい。もちろん、削除対象のコントローラは、図8の新規コントローラ213に限らず、任意のコントローラでよい。また、削除のタイミングも任意である。第3~第5実施形態に関しても、同様に、明示的な命令に基づく、任意のタイミングでの、サービスまたはコントローラの削除が可能である。さらに、第3~第5実施形態では、センサからの出力に基づく削除も可能である。例えば、サーバのコンテキスト抽出部は、センサ値からコンテキストの変化を検出することもできる。あるコンテキストの検出に応じてサーバの送信部がサービスまたはコントローラのデータを送信した後、コンテキスト抽出部がコンテキストの変化を検出したら、サーバは、送信済みのサービスまたはコントローラの削除を、端末またはデバイスに命じてもよい。例えば、ある会議室にデバイス320が入るのにともなって、会議室というコンテキストが検出され、会議室というコンテキストに応じてサービスがデバイス320にインストールされることがある。当該会議室からデバイス320が出るときも、センサ340によるセンサ値の送信が行われてもよい。そして、コンテキスト抽出部333が、コンテキストの変化を検出してもよい。サーバ330は、コンテキストの変化に応じて、上記サービスの削除をデバイス320に命じてもよい。なお、コンテキスト抽出部333による別の新たなコンテキスト例えば自宅というコンテキストの検出は、暗黙的にはかつて検出されたコンテキスト例えば会議室というコンテキストの環境から、デバイス320が出たということを示す。よって、このような新たなコンテキストの検出にともなって、サーバ330がサービスの削除をデバイス320に命じてもよい。同様に、第4実施形態でも、例えば端末410が会議室から出るのにともなって、センサ440がセンサ値を送信してもよく、コンテキスト抽出部433がコンテキストの変化を検出してもよい。そして、コンテキストの変化に応じて、サーバ430は、コントローラの削除を端末410に命じてもよい。同様に、第5実施形態でも、コンテキストの変化にともなって、サーバ530が端末510と端末520にサービスとコントローラの削除を命じてもよい。以上のようなコンテキストの変化に応じた削除により、不要なプログラムが削除される。よって、端末やデバイスの記憶容量の無駄な使用が防止可能である。また、ある特定のコンテキスト以外では利用を禁止することが望ましいサービスが、他のコンテキストで利用されることを防ぐことも可能となる。ところで、第1実施形態と第3実施形態の共通点は色々あるが、例えば以下の2点が挙げられる。新規サービスプログラムのデバイスへのインストールに関わる通知便宜上、インストール関連通知というを、端末が送信する。デバイスが、インストール関連通知の受信の後に、新規サービスプログラムを取得する。つまり、第1実施形態におけるインストール関連通知は、図1のステップS107のサービス追加更新コマンドであり、第3実施形態におけるインストール関連通知は、図13のステップS507の受信準備コマンドである。そして、以上の共通点から理解されるように、第1実施形態の端末110のUPnPコントローラ111も、第3実施形態の端末310のUPnPコントローラ311も、以下の探索部および通知部として動作する。サービス更新サービスをUPnPのディスカバリプロトコルおよびディスクリプションプロトコルにしたがって探索する探索部。探索部がサービス更新サービスを検出すると、サービス更新サービスに対して、インストール関連通知を送信する通知部。また、第1実施形態と第3実施形態のいずれにおいても、端末は、デバイスが新規サービスプログラムをインストールすると新規サービスに対してUPnPのコントロールプロトコルにしたがって制御メッセージを与える制御部を有する。例えば、図2のUPnPコントローラ111や図14のUPnPコントローラ311が、当該制御部として動作してもよいし、不図示の他のUPnPコントローラが当該制御部として動作してもよい。また、第5実施形態の更新サービスも、サービス更新サービスの1種と見なせる。そして、例えば図28の既存コントローラ512が更新サービス525を探索する場合、既存コントローラ512を上記の探索部と見なすこともでき、受信準備コマンドを送信する更新サービス515を上記の通知部と見なすこともできる。また、UPnP制御部511を上記の制御部と見なすこともできる。また、第2実施形態と第4実施形態の共通点も色々あるが、例えば、以下のような共通点が挙げられる。デバイスの提供するサービスを検出するための検出部として、コントローラ更新サービスが動作する。検出したサービスを識別するサービス識別情報を、管理部具体的にはコントローラ管理装置230またはサーバ430に通知する通知部に相当するコンポーネントを、端末が有している。例えば、端末210においては、コントローラ更新サービス212が上記通知部として動作する。また、端末410においては、受信部413または要求部414が上記通知部として動作する。通知部からの通知に応じて管理部が新規コントローラプログラムを送信すると、新規コントローラプログラムを端末にインストールするインストール部として、コントローラ更新サービスが動作する。インストールされた新規コントローラプログラムにしたがって動作することにより、検出されたサービスを利用するための制御メッセージを当該サービスに対して与える制御部として、UPnP制御部内の新規コントローラが動作する。以上、様々な実施形態について説明したが、上記に例示した以外の適宜の変形が行われてもよい。いずれの実施形態によっても、UPnPのサービスとコントローラの一方または双方が動的に更新されるので、利便性が向上する。最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。付記1指定されたUPnPUniversalPlugandPlayのサービスを提供するためのプログラムをインストールするための、UPnPの特定のサービスを、端末が探索し、前記特定のサービスを提供するデバイスが、前記端末に応答を返し、前記端末が、前記応答により検出される前記特定のサービスに対して、UPnPの新規サービスを提供するための新規プログラムの前記デバイスへのインストールに関わるインストール関連通知を送信し、前記デバイスが、前記特定のサービスを提供するための特定のプログラムにしたがって動作することによって、前記インストール関連通知の受信の後に前記新規プログラムを取得するとともに取得した前記新規プログラムを前記デバイスにインストールし、前記デバイスが、インストールした前記新規プログラムにしたがって動作することにより、前記新規サービスを前記端末に提供することを特徴とするサービス提供方法。付記2前記インストール関連通知は、前記新規サービスを指定するサービス指定情報を含み、前記サービス提供方法は、さらに、前記サービス指定情報と対応づけて前記新規プログラムを格納しており、前記端末に含まれるかまたは他のコンピュータに含まれる管理部に対して、前記デバイスが、前記端末からの前記インストール関連通知に含まれる前記サービス指定情報を通知し、前記管理部が、前記サービス指定情報の通知に応じて、前記新規プログラムを前記デバイスに送信することを含み、前記デバイスは、前記管理部から前記新規プログラムを受信することにより、前記新規プログラムを取得することを特徴とする付記1に記載のサービス提供方法。付記3前記インストール関連通知は、前記新規プログラムを受信するための準備を行うよう、前記デバイスに促す通知であり、前記サービス提供方法は、さらに、特定の環境に前記デバイスが存在しているとき、検出装置が、前記デバイスが前記特定の環境下にあることを示す検出通知を送信し、前記新規サービスを指定するサービス指定情報および前記特定の環境と対応づけて前記新規プログラムを格納する管理部が、前記検出通知の受信に応じて、前記新規プログラムを前記デバイスに送信することを含み、前記デバイスは、前記管理部から前記新規プログラムを受信することにより、前記新規プログラムを取得することを特徴とする付記1に記載のサービス提供方法。付記4前記インストール関連通知は、前記新規プログラムを受信するための準備を行うよう、前記デバイスに促す通知であり、前記サービス提供方法は、さらに、前記新規プログラムを格納する管理部に対して、前記端末が、前記デバイスへの前記新規プログラムの送信を要求し、前記端末からの要求に応じて、前記管理部が前記新規プログラムを前記デバイスに送信することを含み、前記デバイスは、前記管理部から前記新規プログラムを受信することにより、前記新規プログラムを取得することを特徴とする付記1に記載のサービス提供方法。付記5前記デバイスが、前記新規サービスのインストール後、前記新規サービスが前記デバイスにインストールされたことを示す通知を送信することをさらに含むことを特徴とする付記1から4のいずれか1項に記載のサービス提供方法。付記6端末が、デバイスの提供するUPnPのサービスを検出し、前記端末が、前記デバイスに含まれるかまたは他のコンピュータに含まれる管理部に対して、前記サービスを識別するサービス識別情報を通知し、前記サービスを利用するためのUPnPの特定のコントローラを実現するプログラムであって、通知された前記サービス識別情報と対応づけられて前記管理部に格納されている特定のコントローラプログラムを、前記管理部が前記端末に送信し、前記端末が、前記特定のコントローラプログラムを受信し、前記端末が、受信した前記特定のコントローラプログラムを前記端末にインストールし、前記端末が、インストールした前記特定のコントローラプログラムにしたがって動作することにより、検出した前記サービスを利用するための制御メッセージを、検出した前記サービスに対して与えることを特徴とするサービス利用方法。付記7前記管理部は、通知された前記サービス識別情報を用いて前記特定のコントローラプログラムを検索し、検索により見つけた前記特定のコントローラプログラムを前記端末に送信することを特徴とする付記6に記載のサービス利用方法。付記8前記管理部は、前記サービスを含む複数のサービスそれぞれについて、当該サービスを識別するサービス識別情報および当該サービスが利用される環境と対応づけて、当該サービスを利用するためのUPnPのコントローラのプログラムを格納しており、前記サービス利用方法は、さらに、特定の環境に前記端末が存在しているときに、検出装置が、前記端末が前記特定の環境下にあることを示す検出通知を前記管理部に送信することを含み、前記管理部は、前記検出通知を受信すると、前記端末から通知された前記サービス識別情報と前記特定の環境とに対応づけて格納している前記特定のコントローラプログラムを検索し、検索により見つけた前記特定のコントローラプログラムを前記端末に送信することを特徴とする付記6に記載のサービス利用方法。付記9前記端末には、UPnPの特定のサービスのプログラムがインストールされており、前記端末は、前記特定のサービスの前記プログラムにしたがって動作することにより、前記管理部への通知および前記特定のコントローラプログラムのインストールを実行することを特徴とする付記6から8のいずれか1項に記載のサービス利用方法。付記10第1の端末と第2の端末と管理装置を含むシステムで実行される方法であって、UPnPUniversalPlugandPlayのサービスを提供するためのサービスプログラムと、UPnPの何らかのサービスを利用するためのUPnPのコントローラを実現するためのコントローラプログラムのいずれが指定されても、指定されたプログラムをインストールするためのUPnPのサービスである更新サービスを、前記第1の端末と前記第2の端末がともに提供しており、前記第1の端末と前記第2の端末が特定の環境に入ると、前記第1の端末と前記第2の端末が前記特定の環境下にあることを示す検出通知を、検出装置が送信し、1つ以上のUPnPのサービスのそれぞれについて、当該サービスと、当該サービスのインストール先の端末であるサービス提供端末の種類と、当該サービスを利用するためのコントローラと、当該コントローラのインストール先の端末であるコントローラ端末の種類と、当該サービスが利用される環境とを、互いに対応づける条件情報を、前記管理装置が格納しており、前記条件情報により前記特定の環境と対応づけられているサービス提供端末の種類が、前記第1の端末の前記種類と一致し、かつ、前記条件情報により前記特定の環境と対応づけられているコントローラ端末の種類が、前記第2の端末の前記種類と一致する第1の場合には、前記検出通知の受信に応じて、前記管理装置が、前記条件情報により前記特定の環境と対応づけられている特定のサービスを提供するための特定のサービスプログラムを前記第1の端末に送信するとともに、前記条件情報により前記特定の環境と対応づけられている特定のコントローラを実現するための特定のコントローラプログラムを前記第2の端末に送信し、前記第1の端末が、前記更新サービスによる処理の一部として、前記特定のサービスプログラムの前記第1の端末へのインストールを実行し、前記第2の端末が、前記更新サービスによる処理の一部として、前記特定のコントローラプログラムの前記第2の端末へのインストールを実行し、前記条件情報により前記特定の環境と対応づけられているサービス提供端末の種類が、前記第2の端末の前記種類と一致し、かつ、前記条件情報により前記特定の環境と対応づけられているコントローラ端末の種類が、前記第1の端末の前記種類と一致する第2の場合には、前記検出通知の受信に応じて、前記管理装置が、前記特定のサービスプログラムを前記第2の端末に送信するとともに、前記特定のコントローラプログラムを前記第1の端末に送信し、前記第1の端末が、前記更新サービスによる処理の一部として、前記特定のコントローラプログラムの前記第1の端末へのインストールを実行し、前記第2の端末が、前記更新サービスによる処理の一部として、前記特定のサービスプログラムの前記第2の端末へのインストールを実行することを特徴とする方法。付記11前記検出装置が、前記第1の端末に含まれるか、前記第2の端末に含まれるか、または、前記特定の環境に予め設置されていることを特徴とする付記10に記載の方法。付記12前記第1の端末が、前記更新サービスを提供する第2の端末を探索し、前記第2の端末が、前記第1の端末に応答を返し、前記第1の端末が、前記管理装置から送信されるプログラムを受信するための準備を行うよう、前記応答により検出される前記第2の端末に命令し、前記第1の端末が、前記管理装置から送信されるプログラムを受信するための準備を行い、前記第1の端末と前記第2の端末の一方または双方からの通知により、前記管理装置が、前記第1の端末と前記第2の端末それぞれの前記種類を認識することをさらに含むことを特徴とする付記10または11に記載の方法。付記13UPnPUniversalPlugandPlayの新規サービスを提供するための新規プログラムを、外部から与えられる通知の受信の後に取得してインストールするための、UPnPの特定のサービスを提供するデバイスと、端末であって、前記特定のサービスをUPnPのディスカバリプロトコルおよびディスクリプションプロトコルにしたがって探索する探索部と、前記探索部が前記特定のサービスを検出すると、前記特定のサービスに対して、前記新規プログラムの前記デバイスへのインストールに関わるインストール関連通知を送信する第1の通知部と、前記デバイスが前記インストール関連通知の受信の後に前記デバイスに前記新規プログラムをインストールすると、前記新規サービスに対してUPnPのコントロールプロトコルにしたがって制御メッセージを与える第1の制御部と、を備えることを特徴とする端末と、を備えることを特徴とするシステム。付記14前記デバイスまたは他のデバイスにより提供される、前記特定のサービス以外かつ前記新規サービス以外の、UPnPの別のサービスを利用するための、UPnPのコントローラを実現するコントローラプログラムを、前記別のサービスと対応づけて格納する管理部を、前記システムはさらに備え、前記端末はさらに、前記別のサービスを検出する検出部と、前記検出部が検出した前記別のサービスを識別するサービス識別情報を前記管理部に通知する第2の通知部と、前記通知部からの通知に応じて前記管理部が前記コントローラプログラムを送信すると、前記コントローラプログラムを前記端末にインストールするインストール部と、前記インストール部がインストールした前記コントローラプログラムにしたがって動作することにより、前記別のサービスを利用するための制御メッセージを、前記別のサービスに対して与える第2の制御部とを備えることを特徴とする付記13に記載のシステム。