JP5236375B2 - リソース管理装置、リソース管理方法及びリソース管理プログラム - Google Patents

Description

本発明は、自身の管理するリソースを有効に活用する技術に関する。

近年、ネットワークの普及に伴い、家庭の機器をネットワークにつなげて様々なサービスが実現されるようになってきている。例えば、ＴＶをネットワークにつないで、ＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）にて動画を楽しんだり、ＨＤＤ（ハードディスクドライブ）レコーダをネットワークにつないで、外出先から録画予約の指示をしたりするサービスが出現している。このように、ネットワーク経由で機器を操作したり、管理したりすることが可能となりつつある。

また、テレビ放送の多チャンネル化や２４時間放送、ネットワークを介したコンテンツの配信なども普及しつつある。このようなコンテンツを、大容量のＨＤＤを搭載したハードディスクレコーダーにまとめて録画しておき、後で、利用者が、好みのコンテンツを選択して視聴する場合がある。
特開平１−１３７３５６号 特表２００３−５００９６１号 特開平９−９１２３２号

しかし、このようにして大量に録画されたコンテンツの中で、利用者が実際に視聴するものはほんの一部に過ぎず、ＨＤＤの容量を無駄に使用している。このような無駄が生じているので、自身の管理するリソースを有効に活用することができる機器に対する要望がある。
そこで、本発明は、自身の管理するリソースを有効に活用することができるリソース管理装置、リソース管理方法、リソース管理プログラムを提供することを目的とする。

本発明の１実施態様であるリソース管理装置は、自身の管理するリソースを用いてサービスの提供を受けるリソース管理装置であって、リソースを用いるサービスについて、提供を受ける予定の使用予定時間帯を記憶する記憶手段と、前記使用予定時間帯の開始前に、ネットワークを介してサーバ装置から、自装置の利用者に適した前記リソースの推奨的な動作と動作期間とを示す手順を取得する取得手段と、取得した手順の示す前記動作期間が、前記記憶手段の記憶している前記使用予定時間帯に含まれるか否かを判断する判断手段と、前記使用予定時間帯に含まれると判断された場合、前記動作期間前に前記リソースを確保し、前記起動期間に確保したリソースを取得した手順に従って動作するように制御する制御手段とを備えることを特徴とする。

この構成によると、前記記憶手段はリソースを用いるサービスに対応する使用予定時間帯を記憶する。そのため、前記リソースを用いたサービスを複数利用する予定であっても、各サービス毎に対応する使用予定時間帯を保持しているので、前記リソースを有効に活用して各サービスの提供を受けることができる。
また、前記制御手段は、前記手順に従って、利用者に推奨すべき動作をするようにリソースを制御するため、利用者は当該リソース管理装置から、より快適性や利便性の高いサービスを受けることができる。

１．各種の実施態様
以下に、本発明の様々な実施態様について説明する。
（１）本発明の１実施態様として、自身の管理するリソースを用いてサービスの提供を受けるリソース管理装置とネットワークを介してサービスを提供するサーバ装置からなるサービス提供システムであって、前記リソース管理装置は、リソースを用いるサービスについて、提供を受ける予定の使用予定時間帯を記憶する記憶手段と、前記使用予定時間帯の開始前に、ネットワークを介してサーバ装置から、自装置の利用者に適した前記リソースの推奨的な動作と動作期間とを示す手順を取得する取得手段と、取得した手順の示す前記動作期間が、前記記憶手段の記憶している前記使用予定時間帯に含まれるか否かを判断する判断手段と、前記使用予定時間帯に含まれると判断された場合、前記動作期間前に前記リソースを確保し、確保したリソースを取得した手順に従って動作するように制御する制御手段とを備え、前記サーバ装置は、前記リソース管理装置の利用者に関する情報とサービスを提供する予定の前記使用予定時間帯とを記憶している記憶手段と、前記情報及び前記使用予定時間帯を基に、前記手順を生成する生成手段と、生成した手順を送信する送信手段とを備えることを特徴とするサービス提供システム。

また、別の実施態様として、自身の管理するリソースを用いてサービスの提供を受けるリソース管理装置であって、リソースを用いるサービスについて、提供を受ける予定の使用予定時間帯を記憶する記憶手段と、前記使用予定時間帯の開始前に、ネットワークを介してサーバ装置から、自装置の利用者に適した前記リソースの推奨的な動作と動作期間とを示す手順を取得する取得手段と、取得した手順の示す前記動作期間が、前記記憶手段の記憶している前記使用予定時間帯に含まれるか否かを判断する判断手段と、前記使用予定時間帯に含まれると判断された場合、前記動作期間前に前記リソースを確保し、前記起動期間に確保したリソースを取得した手順に従って動作するように制御する制御手段とを備えることを特徴としてもよい。

前記リソース管理装置は、さらに、他のサービスの提供を受ける他の使用予定時間帯を受け付ける受付手段と、同一のリソースについて、前記記憶手段の記憶している前記使用予定時間帯と前記他の使用予定時間帯とが重複するか否かを判断する競合検出手段と、重複すると判断された場合、その旨を利用者に通知する通知手段とを備えるとしてもよい。
上記の構成によると、前記提示手段により、利用者は、新たに入力した他のサービスに関する予約が受理されない理由を容易に知ることができる。
（２）前記リソース管理装置は、さらに、競合検出手段により重複すると判断された場合に、前記記憶手段の記憶している前記使用予定時間帯を、前記他の使用予定時間帯と重複しないように変更する変更手段と、変更後の前記使用予定時間帯を、ネットワークを介して前記サーバ装置へ通知する通知手段とを備えるとしてもよい。

上記の構成によると、前記変更手段により２つのサービスに係る使用予定時間帯に重複がなくなるので、両方のサービスの提供を受けることができる。
（３）前記変更手段は、利用者により前記他のサービスを優先すると指示された場合にのみ、前記変更を行うとしてもよい。
この構成によると、前記変更に利用者の意思を反映させることができる。
（４）前記変更後の使用予定期間帯を通知した場合、前記取得手段は、前記手順に代えて、前記変更後の使用予定期間において、前記利用者に適した前記リソースの推奨的な動作及び動作期間を示す代替手順を取得し、前記制御手段は、前記手順に代えて、前記代替手順に従って動作するように前記リソースを制御するとしてもよい。

この構成によると、前記記憶手段の記憶している前記使用予定時間帯が変更された場合であっても、滞りなく前記サービスを受けることができる。
（５）重複していないと判断した場合、競合検出手段は、さらに、前記リソースを用いた前記他のサービスの提供を受ける予定の前記他の使用予定期間帯を前記記憶手段に書き込むとしてもよい。

この構成によると、当該リソース管理装置は、前記他のサービスの提供も受けることができる。つまり、リソースの重複や、使用予定時間帯に重複が無ければ、複数のサービスの提供を受けることができる。
（６）前記取得手段は、前記使用予定時間帯の開始時刻から所定の時間を差し引いた要求時刻に前記手順を取得するとしてもよい。

上記の構成において、前記所定の時間を充分短くすれば、前記取得手段は最新の手順を取得することができる。サーバ装置を有するサービス提供者においては、常に、プログラムの検査や改善など品質向上が図られている。従って、上記の構成であれば、できるだけ高品質のプログラム（手順）を得ることができる。
（７）前記サービスは、当該リソース管理装置の利用者の嗜好に合った放送番組の予約録画に関するサービスであって、前記取得手段は、前記使用予定時間帯において前記利用者の嗜好に合った放送番組を録画するような前記リソースの動作を示す前記手順を取得し、前記制御手段は、前記手順に従って、前記放送番組の開始直前に前記リソースを確保し、前記放送番組を録画するように前記リソースを制御するとしてもよい。

上記の構成によると、利用者は、外出中などに放送される番組であって、自身の好みに合う番組を視聴することができる。
（１０）前記サービスは、前記リソースである家電製品の自動制御に関するサービスであって、前記取得手段は、前記利用者の生活パターンに適した前記家電製品の動作を示す手順を取得し、前記制御手段は、前記手順に従って、前記家電製品の動作期間の直前に前記家電製品を確保し、確保した家電製品を前記利用者の生活パターンに適した動作をするように制御するしてもよい。

この構成によると、利用者は自身の生活パターンに適した家電製品を直接操作することなく動作させることができる。
（１１）また、本発明の実施態様としては、上記のリソース管理装置において用いられる方法、プログラムであってもよいし、このプログラムを記録した記録媒体であってもよい。
２．実施の形態１
以下、本発明の実施の形態について、図面を参照しながら説明する。なお、本発明において、リソースは、以下に提示されるものに限らず、端末を構成する要素であれば何でも構わない。また、サービス提供者の用いる機器とは、サーバ装置に限らず、ネットワーク経由で端末を操作、あるいは、管理するものであれば形態は何でも構わない（例えば、他のクライアント端末）。

また、本発明における端末とは、録画再生装置、テレビ、デジタルビデオカメラ、オーディオシステムといった家庭用ＡＶ（オーディオビデオ）機器、ＡＶ機器のみならず、照明、空調などの動作を自動制御する家電制御サーバ、パーソナルコンピュータ、宅内サーバ装置など様々な機器が該当する。これらの端末は、自身保持するリソース及び自身が制御しているリソースを管理するリソース管理装置である。

本発明の実施の形態１として、ネットワークに接続されていない端末１０００内におけるリソースの管理方法について説明する。
図１に示すように端末１０００は、端末リソース確保手段１００１、リソース競合検知手段１００２、予約状況保持手段１００３、リソース競合提示手段１００４、サービス実行手段１００５、リソース群１００６及び入力手段１００７から構成される。また、端末１０００により制御される外部リソース１００８が接続されている。

以下、各部構成について説明する。
２．１ リソース群１００６及び外部リソース１００８
リソース群１００６は端末１０００が保持する１つ以上のリソースであり、さまざまな種類がある。ここでは、例として、チューナー１０１１、ＨＤＤドライブ１０１２を図示しているが、他にも、光学ディスクドライブ、外部スロットといったものがある。

外部リソース１００８は、端末１０００に接続されて端末１０００から制御されるリソースである。例えば、エアコン、照明機器、外付けのディスクドライブ、モニター、などが考えられる。
２．２ 予約状況保持手段１００３
予約状況保持手段１００３は、各リソースの予約状況を記憶している手段であり、例えば、リソース内容とそれを使用する端末ユーザ、使用予定時間帯といった情報を含むリソース予約テーブルを保持している。図２にリソース予約テーブル１０２１の詳細を示す。

リソース予約テーブル１０２１は、図２に示すように複数の予約情報１０２２、１０２３、１０２４・・・から構成される。
各予約情報は、使用リソース、使用者名及び使用予定時間帯を含んで構成される。使用リソースは、使用予定のリソースの名称、使用者名は、リソースの予約を入力したユーザの名称、使用予定時間帯は、リソースを使用する予定の時間帯である。例えば、予約情報１０２２は、ユーザＡの指示により、２００８年１月１日の２１：００〜２２：００の間、チューナーが使用される予定であることを示している。

これらの項目は、一例であって、この他にも、ユーザが利用しようとしている機能の名称（例えば、予約録画、タイマー再生など）を含んでも良い。
２．３ 入力手段１００７
入力手段１００７は、各種の入力キーを備え、端末ユーザによる各種の指示やデータの入力を受付、受け付けた入力内容を端末リソース確保手段１００１、リソース競合提示手段１００４へ出力する。
２．４ 端末リソース確保手段１００１
端末リソース確保手段１００１は、端末のリソースを予約するためのトリガとなる手段であり、入力手段１００７を介して、端末ユーザによるリソース予約の指示を受け取る。

ここで、端末リソース確保手段１００１の受け取る指示は、具体的に、予約すべきリソースを指定するものであっても良いし、端末ユーザの利用しようとしている機能及びサービスの名称であってもよい。
前者の場合、リソース予約の指示には、当該指示を入力したユーザ名、予約をするリソースの名称、予約を希望する時間帯（以下使用予定時間帯）が含まれる。

後者の場合、リソース予約の指示には、当該指示を入力したユーザ名、希望する機能又はサービスの名称及び使用予定時間帯が含まれる。この場合、端末リソース確保手段１００１は、入力された機能又はサービスの名称から、予約すべきリソースを特定する。
続いて、端末リソース確保手段１００１は、ユーザ名、リソース名、使用予定時間帯をリソース競合検知手段１００２へ通知する。
２．５ リソース競合検知手段１００２
リソース競合検知手段１００２は、リソースの予約に競合が起こるかどうかを検知する機能部である。

具体的には、リソース競合検知手段１００２は、端末リソース確保手段１００１から、ユーザ名、リソース名及び使用予定時間帯の通知を受ける。通知を受けると、予約状況保持手段１００３の記憶しているリソース予約テーブル１０２１を参照し、通知されたリソースについて、通知された使用予定時間帯と、既存の予約情報に含まれる使用予定時間帯に重複があるか否かを確認する。重複がある場合を、そのリソースの予約に競合が生じていると呼ぶ。

競合が生じていなければ、リソース競合検知手段１００２は、通知されたリソース名、ユーザー名及び使用予定時間帯からなる予約情報を生成し、生成した予約情報をリソース予約テーブル１０２１に追加登録する。
競合が生じている場合、リソース競合検知手段１００２は、リソースの競合が起こったこととその内容をリソース競合提示手段１００４へ通知する。
２．６ リソース競合提示手段１００４
リソース競合提示手段１００４は、液晶ディスプレイ、スピーカなどを含んで構成され、リソース競合検知手段１００２から通知されたリソースの競合内容を端末ユーザに画像若しくは音声により提示する手段である。

リソースの競合を提示された端末ユーザは、自身が入力したリソース予約を優先するか否かを決定し、入力手段１００７に決定内容を入力する。
リソース競合提示手段１００４は、入力手段１００７を介して、ユーザの入力を受け付ける。ユーザが自身の入力したリソース予約を優先した場合は、リソース競合提示手段１００４は、予約状況保持手段１００３のリソース予約テーブル１０２１内において、競合している予約情報を、新たに入力したリソース予約内容を示す予約情報により上書きする。

ユーザが、先に入力されていたリソース予約を優先した場合には、リソース競合提示手段１００４は、上記の上書きは行わず、各部に新たな予約の中止を通知する。
なお、リソース予約テーブル１０２１の上書きは、本手段ではなく、端末リソース確保手段１００１や、リソース競合検知手段１００２、あるいは、予約状況保持手段１００３自身が行ってもよい。

また、具体的には図示していないが、新たなリソースの予約が確定すると、リソース競合提示手段１００４又はリソース競合検知手段１００２は利用者により要求された機能又はサービス（例えば、予約録画などの機能）を示す要求指示情報をサービス実行手段１００５へ通知する。
２．７ サービス実行手段１００５
サービス実行手段１００５は、図示していないが、各種の機能及びサービスを実現する手順を含んだプログラム及び利用者により入力された録画予約、再生予約等の要求指示情報を記憶する記憶部を備えている。予約状況保持手段１００３に保持されているリソース予約状況及び自身の記憶している要求指示に従って、利用予定時間帯の開始直前にリソースを確保し、指示情報に応じたプログラムを選択し、選択したプログラムを実行することで、各種サービスを提供する手段である。ここで、「確保」とは、そのリソースを独占的に使用し、選択したプログラム以外のプログラム（タスク）から、そのリソースの使用要求があっても、排除することを意味する。

例えば、録画予約を示す指示情報には、少なくとも録画開始時刻、終了時刻、チャネルが含まれている。ここで録画開始時刻及び終了時刻により特定される時間帯は、リソース予約テーブル１０２１に登録されているチューナーの使用予定時間帯と一致する。録画開時刻直前になると、サービス実行手段１００５は、チューナーというリソースを確保し、自身の保持している録画プログラムを読み出し、チューナーを使用して録画プログラムを実行することで録画を行う。
２．８ まとめ
以上、説明してきたように、実施の形態１においては、端末１０００を使用する限られたユーザ間の関係や話し合いにより、各リソースの予約に競合は起こらない。従って、サービス実行手段１００５は、リソース予約テーブル１０２１を参照して、所定の日時に遅滞無く各リソースを確保し、確保したリソースを用いたサービスを実現することができる。
３． 実施の形態２
次に、本発明に係る実施の形態２について説明する。
３．１ 概要
図３は、本実施の形態に係るサービス提供システム１の構成を示す構成図である。図３に示すように、サービス提供システム１は、サービス提供者の有するサーバ装置と端末とが、ネットワーク２を介して接続されており、サービス提供者が端末の管理するリソースを用いてサービスを提供するシステムである。ここでは、一例として、サービス提供者Ａは、推奨番組録画予約サービスを提供する。

推奨番組録画予約サービスとは、ユーザに代わってサービス提供者がユーザの気に入るであろう番組を自動で探し出し、探した番組を予約録画する手順を含むプログラムを端末に提供するものである（Ｓ２０３１）。利用者は、予め、端末及びネットワーク２を介して、自身の嗜好及びサービスの提供を希望する日付、時間帯を、サービス提供者Ａのサーバ装置２０５０に登録しておく。また、同時に端末に、サービス提供者Ａによるサービスを受けるために必要なリソース、使用予定時間帯、サービス提供者名などを入力しておく必要がある。以下の説明では、サービス提供者Ａへの事前の登録は終了しているものとする。

図３には、端末２０００の保持するリソース予約テーブル２０２１の一部が記載されている。ここでは、サービス提供者Ａの名称、サービス提供者Ａの提供する推奨番組録画予約サービスを受けるために必要なリソース名、サービスを受けるためのプログラムの取得先を示すネットワークパス、推奨番組録画予約サービスを利用する時間帯が、使用予定時間帯として記録されている。

図３には、一例として、月曜〜土曜、９：００〜２１：００の間、サービス提供者Ａによる推奨番組録画予約サービスを受けることが記録されており、このサービスを利用するためにチューナーを予約している。
サービス提供者Ａの所有するサーバ装置２０５０は、端末２０００の利用者の嗜好に合った番組を録画するためのプログラムを生成し、端末２０００は、使用開始時間帯の直前（例えば８：５５に）に、このプログラムをダウンロードして実行する。
３．２ 端末２０００の構成
ここで、実施の形態３における端末２０００の構成について説明する。図４に示すように、端末２０００は、入力手段２０１１、端末リソース確保手段２００１、リソース競合検知手段２００２、予約状況保持手段２００３、サービス実行手段２００５、リソース群２００６、ネットワークパス取得手段２００７、サービス取得手段２００８から構成される。また、外部リソース２０１２と接続されている。

以下、各部構成について説明するが、入力手段２０１１、リソース群２００６及び外部リソース２０１２は、上記の実施の形態１において説明した入力手段１００７、リソース群１００６及び外部リソース１００８と同様であるので、説明を省略する。
（１）予約状況保持手段２００３
予約状況保持手段２００３は、ハードディスクなどの不揮発性のメモリにより構成され、リソースの予約時状況を記憶する手段である。例えば、リソース内容とそれを使用する端末ユーザ、もしくは、それを使用するサービス提供者名とそのサービスのネットワークパス、使用予定時刻といった情報を含むリソース予約テーブルを記憶している。図５は、リソース予約テーブル２０２１の構成の一例を示す。

図５に示すように、リソース予約テーブル２０２１は、複数の予約情報２０２２、２０２３、２０２４、２０２６、２０２７・・・を含んで構成される。各予約情報は、使用リソース、使用者名、ネットワークパス、使用予定時間帯、確定フラグ及び確保フラグから構成される。
使用リソースは、予約するリソースの名称であり、使用者名は、そのリソースを用いて実現される端末装置２０００の機能を利用しようとするユーザの名称、若しくは、そのリソースを用いて、端末装置２０００にサービスを提供しようとするサービス提供者の名称である。ネットワークパスは、サービス提供者によるサービスを受ける場合に、サービスの提供を受けるために必要なプログラムなどを取得するネットワーク上の経路を示す。使用予定時間帯は、リソースを使用する予定の時間帯である。確定フラグは、その予約情報の示すリソース予約が確定事項であるか否かを示す。具体的に確定フラグ「Ｙｅｓ」を含む予約情報は、使用予定時間帯に必ずリソースを確保し使用することを示しており、確定フラグ「Ｎｏ」を含む予約情報は、使用予定時間帯に記載されている時間帯において、リソースを確保する可能性があることを示す。つまり、利用予定時間帯に記載されている全時間帯において、リソースを確保しているわけではないことを示している。確保フラグは、「１」又は「０」の１ビット長のデータであって、「１」は、予約情報に対応する処理のために、現在、リソースが確保されていることを示す。「０」は、現在は確保されていないことを示す。

予約情報には、端末装置２０００の備える機能を直接利用する指示の入力に従って生成されたものと、サービス提供者の提供するサービスを利用するために入力されたデータに従って生成されたものの２種類ある。予約情報２０２２及び２０２７が前者に該当し、予約情報２０２３、２０２４及び２０２６が後者に該当する。
前者の一例として、予約情報２０２２は、使用リソース「チューナー」、使用者名「ユーザＡ」、使用予定時間帯「２００８／１／１ ２１：００〜２２：００」、確定フラグ「Ｙｅｓ」及び確保フラグ「０」を含む。予約情報２０２２は、ネットワークパスを含まない。これは、ユーザＡにより、２００８年１月１日、２１：００〜２２：００の間、チューナーが予約されており、確定フラグ「Ｙｅｓ」は、この予約が確定していること、つまりこの時間帯に確実にチューナーが確保される予定であることを示す。また、確保フラグ「０」は、現在、予約情報２０２２に対応する処理のためにチューナーは確保されていないことを示している。

また、後者の一例として、予約情報２０２３は、使用リソース「チューナー」、使用者名「サービス提供者Ａ」、ネットワークパス「ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｉｃｅＡ／ｙｏｙａｋｕ」、使用予定時間帯「月〜土、９：００〜２１：００」、確定フラグ「Ｎｏ」及び確保フラグ「１」を含む。これは、月曜〜土曜、９：００〜２１：００の間、サービス提供者Ａによる、推奨番組録画予約サービスを受けることを示している。ネットワークパスは、サービス提供者Ａのサーバ装置２０５０から、サービスを受けるためのプログラムをダウンロードするためのネットワーク上の経路を示している、例えば、ＵＲＬであり、ネットワーク２経由でアクセスできるパスであれば何でもよい。確定フラグ「Ｎｏ」は、使用予定時間帯に記載された全時間帯に必ずしも使用リソースが確保される訳ではないことを示す。例えば、月曜９：００〜２１：００のうち、推奨する番組の放送時間が２０：００〜２１：００のみであれば、当該サービスのために実際にチューナーが確保される時間帯は２０：００〜２１：００となり、９：００〜２０：００の間は確保されない。

確保フラグ「１」は、現在、サービス提供者Ａによるサービスを受けるため、チューナーが確保されていることを示す。
（２）端末リソース確保手段２００１
端末リソース確保手段２００１は、端末リソース確保手段１００１と同様に入力手段２０１１を介して端末ユーザによるリソース予約の指示や端末装置２０００の機能の使用を要求する指示を受け取る。

例えば、ユーザ自身による録画予約の指示が入力された場合は、端末リソース確保手段１００１の場合と同様に入力された情報をリソース競合検知手段２００２へ出力する。
また、サービス提供者によるサービスを受けることを示す入力が為された場合も、端末リソース確保手段１００１と同様に端末リソース確保手段２００１は、入力された情報をリソース競合検知手段２００２へ通知する。

（３）リソース競合検知手段２００２
リソース競合検知手段２００２は、リソースの予約の競合が起こるかどうかを検知する機能部である。
リソース競合検知手段２００２は、端末リソース確保手段２００１から、リソース名、ユーザ名、使用予定時間帯を通知される。又は、リソース名、サービス提供者名及び使用予定時間帯を通知される。

通知を受けると、リソース競合検知手段２００２は、予約状況保持手段２００３の記憶しているリソース予約テーブル２０２１を参照して、通知されたリソースについて、競合が生じているか否かを確認する。競合が生じていなければ、新たな予約情報を生成し、リソース予約テーブルに追加する。ここで、リソース名と共にユーザ名が通知された場合は、確定フラグ「Ｙｅｓ」及び確保フラグ「０」を含む予約情報を生成し、リソース名と共にサービス提供者名が通知された場合は、確定フラグ「Ｎｏ」及び確保フラグ「０」を含む予約情報を生成する。

予約情報を追加する際、ネットワークパス取得手段２００７に依頼してネットワークパスを取得してもよいし、ユーザが直接入力してもよい。
なお、ここでは、一例として、サービス提供を受けるための予約情報に含まれる確定フラグは、いずれも「Ｎｏ」にするとしたが、提供されるサービスの内容によっては「Ｙｅｓ」であってもよい。また、利用者の操作により、書き換えられるとしてもよい。また、リソース名と共にユーザ名が通知された場合に、確保フラグを「１」にしてもよい。また、利用者の操作により、書き換えられるとしてもよい。

競合が生じていれば、リソース競合検知手段２００２は、上記の予約情報の追加は行わず、最後に入力された予約依頼は中止された旨を各機能部へ通知する。
（４）ネットワークパス取得手段２００７
ネットワークパス取得手段２００７は、リソース競合検知手段２００２からネットワークパスの取得依頼を受け取り、サービス提供者のサーバにアクセスして、プログラムをダウンロードするためのネットワークパスを取得し、リソース競合検知手段２００２に通知する。

（５）サービス実行手段２００５
サービス実行手段２００５は、上記のサービス実行手段１００５と同様に予約状況保持手段２００３に保持されているリソース予約テーブル２０２１及び自身の保持する要求指示を参照し、端末内でリソース群２００６を用いて各種機能を実現したり、サービス提供者によるサービス提供を受けるためのプログラムを実行したりする手段である。

先ず、サービス実行手段２００５は、リソース予約テーブル２０２１を参照して必要なリソースを特定し、所定の時刻になると特定したリソースを確保する。リソースを確保すると、リソース予約テーブル２０２１内の該当する予約情報に含まれる確保フラグを「１」に書き換える。予約情報と対応する処理が終了したり、中断したりして、リソースを開放すると、確保フラグを「０」に書き換える。

例えば、予約録画処理では、チューナーというリソースを特定し、録画開始時刻になるとチューナーを確保して録画を開始する。チューナーを確保する際、リソース予約テーブル２０２１内で参照した予約情報に含まれる確保フラグを「１」に書き換える。
また、参照した予約情報にネットワークパスが定義されている場合は、サービス提供者によるサービスを受けるために、使用予定時間帯の開始する前（例えば５分前）に、サービス取得手段２００８にプログラムの取得依頼とネットワークパスを通知する。そして、サービス取得手段２００８が取得したサービス提供用のプログラムを受け取り、そのプログラムを実行する。プログラムの実行中において、リソースを確保した際には、上記の予約録画の場合と同様に、参照した予約情報に含まれる確保フラグを「１」に書き換え、リソースを開放した際には確保フラグを「０」に戻す。

（６）サービス取得手段２００８
サービス取得手段２００８は、サービス実行手段２００５からプログラムの取得依頼とネットワークパスを受け取り、ネットワークパスの示す経路によりサービス提供者のサーバ装置にアクセスし、サービス提供用のプログラムをダウンロードする。そして、ダウンロードしたサービス提供用のプログラムをサービス実行手段２００５に出力する。
３．３ 動作
以下、図６を用いて、端末２０００のリソース予約動作について説明する。

（１）端末リソース確保手段２００１は、入力手段２０１１を介して端末ユーザによるリソース名、使用者名、使用予定時間帯の入力を受け付ける（ステップＳ１３０２）。なお、リソースの指定は直接リソース名を指定するものではなく、プログラムやサービスを指定して、端末リソース確保手段２００１等が、プログラムやサービスに対応するリソースを特定しても良い。

（２）リソース競合検知手段２００２は、入力されたリソースの予約が競合しているか否か判断する（ステップＳ１３０３）。
（３）ステップＳ１３０３でＹＥＳと判断された場合、リソース競合検知手段２００２はリソース予約を中止する（ステップＳ１３０４）。
（４）ステップＳ１３０３でＮＯと判断された場合、リソース競合検知手段２００２は、入力された使用者名がネットワーク経由の使用者（つまりサービス提供者）かどうかを判断する（ステップＳ１３０５）。

（５）ステップＳ１３０５でＮＯと判断された場合、リソース競合検知手段２００２は、入力されたデータと確定フラグ「Ｙｅｓ」と確保フラグ「０」とを含む予約情報を新たに生成し、生成した予約情報をリソース予約テーブル２０２１に追加する（ステップＳ１３０６）。
（６）ステップＳ１３０５においてＹＥＳと判断された場合であって、端末使用者がさらに、使用者（サービス提供者）のネットワークパスを端末ユーザが直接入力する場合（ステップＳ１３０７のＹｅｓ）、リソース競合検知手段２００２は、入力手段２０１１を介して、端末ユーザによるネットワークパスの入力を受け付ける（ステップＳ１３０９）。

（７）ステップＳ１３０７がＮＯの場合、リソース競合検知手段２００２の指示により、ネットワークパス取得手段２００７は使用者（サービス提供者）にアクセスし、ネットワークパスを取得する（ステップＳ１３０８）。
（８）次に、リソース競合検知手段２００２は、リソース名と使用者名とネットワークパスと確定フラグ「Ｎｏ」と確保フラグ「０」とを含む予約情報を新たに生成し、生成した予約情報を、リソース予約テーブル２０２１に追記する（ステップＳ１３１０）。
３．４ まとめ
上記の構成により、サービス提供システム１では、サービス提供者が端末のリソースを使用してサービスを提供するためのプログラムを生成し、端末にてそのプログラムを実行することによりサービスの提供を受けることができる。また、端末ユーザの指示に従って端末のリソースを使用することも可能となる。また、端末は自端末のリソースがどのサービス提供者により使用される予定であるかを把握できる。さらに、具体的に図示していないが、ネットワークパスを基にサービス提供者に問い合わせることによってそのサービス提供者の提供するサービス内容も容易に知ることができる。

このように、サーバ装置にサービスを代行してもらい、直前にそのサービスを受けるためのプログラムをダウンロードする形態では以下のようなメリットがある。直前のダウンロードなので、最新版のプログラムを得られる、あるいは、リアルタイムにプログラムが変わるようなサービスも可能である。また、その都度、ダウンロードするので、端末２０００が、推奨番組録画予約用のプログラムを保持している場合に比べ、ＨＤＤ使用容量削減が可能である。また、常駐プログラムを回避できるので、ＣＰＵ負荷低減や、消費電力削減が可能である。

また、サービスを受ける度にプログラムをダウンロードするので、端末２０００は、そのつど、サーバが信頼できるサーバかどうかの認証処理を行うことも可能である。機器認証の方法は、相互認証であっても良いし、一方向認証であっても良く、これらは、既存の様々な認証技術により実現可能である。
４．実施の形態３
以下、本発明の実施の形態３のサービス提供システム３について、図面を用いて説明する。
４．１ 概要
図７は、実施の形態３におけるサービス提供システム３の構成を示す構成図である。図７に示すように、端末３０００は、ネットワーク２を介して、サービス提供者の所有するサーバ装置と接続されている。ここでも、一例として、サービス提供者Ａは、サーバ装置４０００を用いて推奨番組録画予約サービスを提供しているとする。

実施の形態２と同様に、端末３０００は、リソース予約テーブルを保持している。図７には、このリソース予約テーブル３０２１の一部を抜粋して記載している。リソース予約テーブル３０２１の詳細な構成は、実施の形態２において説明したリソース予約テーブル２０２１と同様である。
リソース予約テーブル３０２１の予約情報３０２２は、９：００〜２１：００の間、サービス提供者Ａによるサービスを受けるため、チューナーが予約されていることを示している。このリソース予約テーブル３０２１に従うと、端末３０００は、８：５５にサーバ装置４０００から、９：００〜２１：００の間の推奨番組を録画するためのプログラムをダウンロードする予定である（ステップＳ１４０１）。

ところが、８：５５より前に、端末ユーザにより９：００〜１２：００の間、録画予約の指示が入力されたとする（ステップＳ１４０２）。この場合、録画予約に当たって、チューナーの予約をする必要があるので、９：００〜１２：００の間、チューナーの予約が競合することになる（ステップＳ１４０３）。
実施の形態２では、このようなとき、後から入力されたリソース予約を破棄していたが、本実施の形態のサービス提供システム３では、利用者による選択、サービスを受ける時間帯の変更などを行うことで、より柔軟に利用者により直接入力された指示とサービスの利用とを両立させることができる。
４．２ 端末３０００の構成
図８は、実施の形態３における端末３０００の構成を示すブロック図である。図８に示すように、端末３０００は、端末リソース確保手段３００１、リソース競合検知手段３００２、予約状況保持手段３００３、リソース競合提示手段３００４、サービス実行手段３００５、リソース群３００６、サービス内容取得手段３００７、サービス取得手段３００８、リソース競合通知手段３００９、入力手段３０１１、ネットワークパス取得手段３０１３から構成される。また、端末３０００により制御される外部リソース３０１２と接続されている。

以下、各部の構成について説明するが、入力手段３０１１、端末リソース確保手段３００１、予約状況保持手段３００３、ネットワークパス取得手段３０１３、サービス取得手段３００８、サービス実行手段３００５、リソース群３００６及び外部リソース３０１２は、それぞれ、実施の形態２と同様の構成であるので説明を省略し、実施の形態３に固有の部分を中心に説明する。

（１）リソース競合検知手段３００２
リソース競合検知手段３００２は、リソースの予約の競合が起こるかどうかを検知する機能部である。競合の検出の手順および、競合が生じていない場合の予約情報の追記については、実施の形態２と同様であるので、説明を省略する。
競合が生じている場合の一例として、図７に示すように、９：００〜１２：００の間、利用者による録画予約とサービス提供者Ａによるサービス提供のためのチューナーの予約が競合しているとする。

リソース競合検知手段３００２は、予約状況保持手段３００３の記憶しているリソース予約テーブル３０２１の該当する予約情報３０２２からから使用者名を読み出し、読み出した使用者名が端末３０００のユーザ名ではなく、ネットワーク経由のサービス提供者の名称であることを確認する。次に、リソース競合検知手段３００２は、予約情報３０２２からネットワークパスを読み出し、読み出したネットワークパスをサービス内容取得手段３００７へ出力する。

続いて、リソース競合検知手段３００２は、サービス内容取得手段３００７からサービス内容を受け取る。ここでは、具体的に「推奨番組録画予約サービス」というサービスの名称を取得する。
サービス内容を取得すると、リソース競合検知手段３００２は、競合が発生している旨の通知、既存のリソース予約に関する情報と、利用者により入力された指示内容とをリソース競合提示手段３００４へ出力する。

既存のリソース予約に関する情報とは、具体的には、予約情報３０２２に含まれる使用者名「サービス提供者Ａ」、使用予定時間帯「９：００〜２１：００」と取得したサービス内容「推奨番組録画予約サービス」である。利用者により入力された指示内容とは、具体的には、使用者名「ユーザＡ」、「録画予約」と録画予約時間帯「９：００〜１２：００」である。

なお、上記の例では、既存の予約情報がサービス提供者によるサービス提供のためのリソース予約を示しており、利用者により入力された指示が、利用者自身による録画予約であるとしたが、既存の予約情報も利用者により指示された処理に対応している場合には、リソース競合検知手段３００２は、既存の予約情報に含まれるユーザ名をリソース競合提示手段３００４へ出力する。

（２）リソース競合提示手段３００４
リソース競合提示手段３００４は、液晶ディスプレイ、スピーカなどを含んで構成されており、リソースの予約に競合が生じていることを画像又は音声により利用者に報知する手段である。
具体的には、リソース競合提示手段３００４は、リソース競合検知手段３００２から、競合が発生している旨の通知、既存のリソース予約に関する情報及び利用者により新たに入力された指示内容を受け取る。

これらを受け取ると、リソース競合提示手段３００４は、競合が発生している旨を通知する画面を生成し、表示する。図９は、ここで表示される通知画面の一例である。通知画面３０１６は、リソース競合検知手段３００２から受け取った情報を基に、現在生じている競合の内容を通知し、新たに入力した指示を優先するか否かの選択を促す文章３０１９と、選択ボタン「はい」３０１７及び選択ボタン「いいえ」３０１８とが表示されている。

端末ユーザは、入力手段３０１１を操作して何れかのボタンを選択する。
端末ユーザにより、ボタン「いいえ」３０１８が選択された場合、リソース競合提示手段３００４は、各部に、録画予約の中止を通知し、予約状況保持手段３００３の記憶しているリソース予約テーブル３０２１の変更は行わない。
端末ユーザにより、ボタン「はい」３０１７が選択された場合、リソース競合提示手段３００４は、予約状況保持手段３００３の記憶しているリソース予約テーブル３０２１を書き換える。

図１０は、書き換え前のリソース予約テーブル３０２１ａ及び書き換え後のリソース予約テーブル３０２１ｂの詳細を示している。以下、図１０を参照しながらリソース予約テーブル３０２１の書き換え手順について説明する。
先ず、リソース競合検知手段３００２から受け取った既存のリソース予約に関する情報に含まれる使用予定時間帯と、新たに入力された指示内容に含まれる録画予約時間帯とを比較し、使用予定時間帯から録画予定時間帯を差し引いて新たな使用予定時間帯「１２：００〜２１：００」を算出する。続いて、予約状況保持手段３００３の保持しているリソース予約テーブル３０２１ａの予約情報３０２２ａに含まれる使用予定時間帯「９：００〜２１：００」を、新たに算出した使用予定時間帯「１２：００〜２１：００」に書き換える。書き換え後の予約情報３０２２ｂは、使用予定時間帯「１２：００〜２１：００」を含む。

続いて、リソース競合提示手段３００４は、新たに入力された指示内容を基に予約情報３０２３を生成し、生成した予約情報３０２３をリソース予約テーブル３０２１ａに追記する。
このような書換えを行った後のリソース予約テーブル３０２１ｂは、図１０（ｂ）に示すように予約情報３０２３と予約情報３０２２ｂとを含んでいる。

なお、リソース予約テーブル３０２１の書き換えは、本手段ではなく、端末リソース確保手段３００１や、リソース競合検知手段３００２、あるいは、予約状況保持手段３００３自身、もしくは他の手段が行ってもよい。
次に、リソース競合提示手段３００４は、予約情報３０２２ｂに含まれる使用者名、ネットワークパス及び新たな使用予定時間帯をリソース競合通知手段３００９へ出力する。

なお、上記の例では、既存の予約情報がサービス提供者によるサービス提供のためのリソース予約を示しており、利用者により入力された指示が、利用者自身による録画予約であるとしたが、既存の予約情報も利用者により指示された処理に対応している場合、リソース競合検知手段３００２から既存の予約情報に含まれるユーザ名を受け取り、受け取ったユーザ名を画面に表示する。

もしくは、両ユーザ名を表示し、何れの指示を優先するかを利用者に選択させてもよいし、あらかじめ、各ユーザの優先順位を登録しておき、優先順位の高いユーザによる指示を優先するとしても良い。この場合、リソース競合通知手段３００９への通知は行わない。
また、リソースの予約が競合した場合に、利用者による選択を受け付ける代わりに、端末３０００が直接使用するケース及びネットワーク経由で使用するケースにそれぞれに優先度をつけておき、優先度に従って、競合の解消を図っても良い。

（３）サービス内容取得手段３００７
サービス内容取得手段３００７は、リソース競合検知手段３００２から通知されたネットワークパスを元にネットワーク経由でサービス提供者にアクセスし、サービス提供者の提供するサービス内容を取得する。サービス内容取得手段３００７は、取得したサービス内容をリソース競合検知手段３００２へ通知する。なお、取得したサービス内容は予約状況保持手段３００３やリソース競合提示手段３００４へ通知してもよい。

（４）リソース競合通知手段３００９
リソース競合通知手段３００９は、リソース競合提示手段３００４からサービス提供者名、ネットワークパス及び使用予定時間帯を受け取る。これらを受け取ると、ネットワークパスを元にサービス提供者へアクセスし、リソースの使用予定時間帯の変更を通知する。
４．３サーバ装置４０００の構成
サービス提供者Ａの所有するサーバ装置４０００は、推奨番組録画予約サービスを提供する装置である。図１１は、サーバ装置４０００の構成を示すブロック図であって、サービス要求受信手段４００１、サービス生成手段４００２、サービス送信手段４００３、リソース競合通知受信手段４００４及びサービス内容通知手段４００６から構成される。

以下、各部構成について説明する。
（１）サービス要求受信手段４００１
サービス要求受信手段４００１は、端末３０００から推奨番組録画予約サービスの手順を含んだプログラムのダウンロード要求を受信する。端末３０００からのダウンロード要求を受信するとその旨をサービス生成手段４００２へ通知する。

（２）サービス生成手段４００２
サービス生成手段４００２は、端末へ提供するサービスの手順を含んだプログラムを生成する機能部であり、端末ごとや、サービスごとに異なるさまざまなプログラムを生成することも可能であるが、ここでは、推奨番組録画予約サービスの手順を含むプログラムを生成する。

サービス生成手段４００２は、内部に記憶領域を備えており、各端末について、ユーザの嗜好情報、サービスを希望する期間を示す使用予定時間帯などを記憶している。また、サービス生成手段４００２は、定期的に番組表を取得し、最新の番組表を記憶している。
また、サービス生成手段４００２は、リソース競合通知受信手段４００４から、端末３０００におけるリソースの使用予定時間帯の変更を通知される。この通知を受けると、サービス生成手段４００２は、記憶している使用予定時間帯を変更後の使用予定時間帯により更新する。

サービス生成手段４００２は、サービス要求受信手段４００１からプログラムのダウンロード要求を受け取る。ダウンロード要求を受け取ると、端末３０００について記憶している嗜好情報、使用予定時間帯、番組表を基に、使用予定時間帯において、ユーザの嗜好に合った番組を抽出し、抽出した番組を予約録画する手順を含むプログラムを生成する。
また、プログラムを生成した後に、リソース競合通知受信手段４００４から、端末３０００におけるリソースの使用予定時間帯の変更を通知された場合、サービス生成手段４００２は、記憶していた使用予定時間帯に代えて、新たに通知された使用予定時間帯を基に、プログラムを生成しなおす。

続いて、サービス生成手段４００２生成したプログラムをサービス送信手段４００３へ出力する。
なお、変更前の使用予定時間帯に、ユーザの嗜好に合う対象番組があった場合は、再放送を検出して、別の機会に、録画予約指示を含むプログラムを生成しても良い。
また、プログラム生成はダウンロード要求を受け取るタイミングではなく、リソースの使用予定時間帯の変更を通知された時でもよい。

（３）サービス送信手段４００３
サービス送信手段４００３は、サービス生成手段４００２により生成されたプログラムを受け取り、端末３０００へ送信する。
（４）リソース競合通知受信手段４００４
リソース競合通知受信手段４００４は、端末においてリソース予約状況に変更があった場合に、その旨を端末から受信する手段である。端末からのリソース予約状況の変更を受信すると、その旨をサービス生成手段４００２へ通知する。

（５）サービス内容通知手段４００６
サービス内容通知手段４００６は、端末３０００からサービス内容の問合せを受け、当該サーバ装置４０００の提供しているサービスの名称を返信する。
４．４ リソース予約に係る動作
図１２は、端末３０００によるリソース予約の動作を示すフローチャートである。以下、図１２を用いてリソース予約における端末３０００の動作について説明する。

（１）先ず、端末リソース確保手段３００１は、入力手段３０１１を介して、リソースとその使用予定時間帯及び使用者名の入力を受け付ける（ステップＳ６０２）。なお、上述したように、リソース名や使用者名に代えて、利用者が希望するサービスの名称の入力を受け付け、受け付けたサービスの名称を基に、端末リソース確保手段３００１がリソースと使用者名を特定しても良い。

（２）リソース競合検知手段３００２は、予約状況保持手段３００３の記憶しているリソース予約テーブル３０２１内に、入力されたリソース名と、入力された使用予定時間帯と一部でも重複している使用予定時間帯とを含んでいる予約情報を検索する。つまり、そのリソースの予約に競合が生じているか否かを判断する（ステップＳ６０３）。
（３）リソースの予約に競合が生じなかった場合、つまり、該当する予約情報が存在しなかった場合（ステップＳ６０３のＮＯ）、リソース競合検知手段３００２は、入力されたデータを基に新たな予約情報を生成し、生成した予約情報をリソース予約テーブル３０２１に追加する（ステップＳ６０４）。このとき、リソース競合検知手段３００２は、必要に応じて、ネットワークパス取得手段３０１３に依頼して、使用者に対応するネットワークパスを取得する。

（４）リソースの予約に競合が生じた場合、つまり、該当する予約情報が既に存在する場合（ステップＳ６０３のＹＥＳ）、リソース競合検知手段３００２は、検出した既存の予約情報から使用者名を読み出す。リソース競合検知手段３００２は、読み出した使用者名はネットワーク経由の使用者（つまり、サービス提供者）の名称であるかどうかを判断する（ステップＳ６０５）。

（５）ネットワーク経由の使用者ではないと判断された場合（ステップＳ６０５のＮＯ）、リソース競合検知手段３００２は、読み出した使用者名をリソース競合提示手段３００４へ出力し、リソース競合提示手段３００４は、受け取った使用者名を提示する（ステップＳ６０６）。
（６）続いて、リソース競合検知手段３００２又はリソース競合提示手段３００４は、新たに入力されたリソース予約を中止する（ステップＳ６１２）。

（７）読み出した使用者名が、ネットワーク経由の使用者であると判断した場合（ステップＳ６０５のＹＥＳ）、リソース競合検知手段３００２は、ステップＳ６０３で検出した既存の予約情報からネットワークパスを読み出す（ステップＳ６０７）。
（８）次に、サービス内容取得手段３００７は、読み出されたネットワークパスの示す経路に従ってサービス提供者のサーバ装置にアクセスし、サービス内容を取得する（ステップＳ６０８）。

（９）次に、リソース競合提示手段３００４は、取得したサービス内容と、利用者により入力された指示内容とを含む画面（例えば、通知画面３０１６）を表示する（ステップＳ６０９）。
（１０）リソース競合提示手段３００４は、入力手段３０１１を介して、入力されたリソース予約を優先するか否かの、端末ユーザによる選択を受け付ける（ステップＳ６１１）。

（１１）入力されたリソース予約を優先しないと選択された場合（ステップＳ６１１のＮＯ）、端末３０００は、ステップＳ６１２に処理を移す。
（１２）入力されたリソース予約を優先すると選択された場合（ステップＳ６１１のＹＥＳ）、リソース競合提示手段３００４は、ステップＳ６０３において検出された既存の予約情報に含まれる使用予定時間帯を、入力された使用予定時間帯と重複しないように変更する（ステップＳ６１４）。

（１３）また、リソース競合提示手段３００４は、ステップＳ６０２において入力された情報を基に新たな予約情報を生成し、生成した予約情報をリソース予約テーブル３０２１に追加する（ステップＳ６１６）。
（１４）次に、リソース競合通知手段３００９は、ネットワークパスを基に、サービス提供者のサーバ装置に、変更後の使用予定時間帯を送信する（ステップＳ６１７）。
４．５ サービス提供における動作
続いて、サービス提供時における端末３０００及びサーバ装置４０００の動作について、図１３のフローチャートを用いて説明する。ここでは、一例として、図９のように、チューナー予約が競合し、利用者による録画予約を優先するように、サービスを受ける時間帯を調整した後に、サービス提供者Ａによる推奨番組録画予約サービスを受ける場合について説明する。

図１４は、このときの各装置及び装置間のデータフローを示す構成図である。ここで、端末３０００の保持しているリソース予約テーブル３０２１ｂの詳細は、図１０（ｂ）に示す通りである。
（１）サービス実行手段３００５は、定期的に現在時刻とリソース予約テーブル３０２１ｂに記載されている使用予定時間帯「１２：００〜２１：００」とをチェックしている（ステップＳ６３１）。

（２）現在時刻が「１１：５５」になると（ステップＳ６３２）、サービス取得手段３００８は、サービス実行手段３００５の指示により、サーバ装置４０００にプログラムのダウンロードを要求する（ステップＳ６３３）。
（３）サーバ装置４０００のサービス要求受信手段４００１は、端末３０００からダウンロード要求を受信し（ステップＳ６３４）、サービス生成手段４００２へ通知する。

（４）サービス生成手段４００２は、端末３０００について登録されている嗜好情報、使用予定時間帯、番組表を基に、端末ユーザの嗜好に合う番組を抽出する（ステップＳ６３６）。続いて、抽出した番組を予約録画する手順を含むプログラムを生成する（ステップＳ６３７）。
（５）サービス送信手段４００３は、サービス生成手段４００２により生成されたプログラムを端末３０００へ送信する（ステップＳ６３８）。

（６）サービス取得手段３００８は、サーバ装置４０００からプログラムをダウンロードし（ステップＳ６３９）、サービス実行手段３００５へ出力する。
（７）サービス実行手段３００５は、リソース予約テーブルを参照して３０２１を参照してリソース「チューナー」を特定する（ステップＳ６４１）。
（８）続いて、サービス実行手段３００５は、特定したチューナーを用い、取得したプログラムを実行する（ステップＳ６４１）。
４．６ まとめ
以上、説明してきた実施の形態３に係るサービス提供システム３の構成によると、端末ユーザがリソースを予約しようとしたとき、そのリソースに関して、サービス提供者による使用予約と競合した場合に、例えば図９のような画面を表示して、サービス提供者によるサービス内容、競合の発生する時間帯などをユーザに提示する。そのため、ユーザはどのような競合が起こっているのかを知ることができ、例えば、録画予約の操作が速やかに受理されない場合でも、混乱せずにすむ。また、サービス提供者が使用を予定していたリソースが奪われた場合に、サービス提供者にその旨を通知することで、サービス提供者の方で、サービス提供のためのプログラムを変更してサービスに不具合が起こらないようにすることができる。

このようにして、利用者の操作による端末の利用と、サービス提供者による新たなサービスとを両立させることができる。
５．その他の変形例
なお、本発明を上記の実施の形態に基づいて説明してきたが、本発明は、上記の実施の形態に限定されないのはもちろんである。以下のような場合も本発明に含まれる。

（１）上記の実施の形態２及び３において、リソースの予約は、あくまでも端末ユーザの入力により開始されるとしたが、これに限るものではない。例えば、ネットワーク経由で、サーバ装置がリソースの予約依頼を送信するとしても良い。送信のタイミングとしては、利用者が、サービスを受けるために、嗜好情報や、サービスの提供を希望する日時などを登録した直後であってもよいし、登録された日時から所定時間前（例えば１時間前）であってもよい。

このように、利用者の行っていた処理をサーバ装置側で代行することにより、利用者にとっての利便性がより向上する。
（２）上記の実施の形態２及び３では、サーバ装置は、サービス提供の手順を含むプログラムを生成していたが、プログラムに限定するものではなく、端末が利用するデータのみであってもよい。

例えば、端末がテレビのように用途の限定された機器である場合、放送波受信のプログラムなどは特に必要なく、推奨する番組の放送時間及びチャネルのみであってもよい。この場合、端末は、利用者の操作なしで、受信した放送時間になると受信したチャネルを選局し、放送番組を受信及び再生する。
（３）実施の形態２では、リソースの使用予定時間帯を、予めユーザがサーバ装置に登録するとした。また、実施の形態３においては、使用予定時間が変更になった時、変更後の使用予定時間帯をサーバ装置に通知していた。

しかし、使用予定時間帯及びその変更をサーバ装置に通知するタイミングは、これに限るものではなく、例えば、サービス取得手段が、プログラムのダウンロード要求と共に、最新の使用予定時間帯を送信しても良い。
なお、プログラムのダウンロード要求と使用予定時間帯は同時に送信してもよいし、別々に送信してもよい。

（４）実施の形態２及び３では、サービス提供者は、サーバ装置を用いてサービスの提供を行っているが、これに限るものではなく、通常のクライアント（端末）であってもよい。すなわち、図１１の構成要素を含んでいる機器であればよい。
同様に、端末も図４及び図８の構成要素を含んでいる機器であればどのような機器であっても良い。

従って、サーバ同士、クライアント（端末）同士でリソースの確保をすることも可能である。
（５）上記の記載では、サービス提供者の提供するサービスとして、推奨番組録画予約サービスを例に説明してきたがこれは、一例に過ぎない。
冒頭でも述べたが、他には、コンテンツのタイマー再生サービス、通信機器の自動起動及び通信帯域の確保サービス、照明や空調の操作、カーテンの開閉など家電製品の自動制御サービスなどが考えられる。

さらに、端末の具体例についても、各サービスに応じて、ＡＶ機器、パーソナルコンピュータ、家電管理用サーバなど、様々な機器が考えられる。
一例として、家電製品の自動制御サービスについて説明すると、この場合のリソースは、照明、空調、カーテンの開閉を実行するモーター、音楽プレーヤーなど様々な家電製品である。端末は、これらの動作を制御する家電制御サーバである。

利用者は、予めサービス提供者に、自身の生活パターンに関する情報を登録しておく。具体的には、各部屋の用途、起床時刻、就寝時刻、勤務時間、休日などである。
サービス提供者の有するサーバ装置は、これらの情報から、各部屋に設置されているリソースの制御手順を含んだプログラムを生成する。具体的には、起床時刻に寝室のカーテンを開け、音楽を再生する手順、台所の照明や電気ポットをＯＮにする手順、勤務時間が開始すると、これらの家電製品の電源をＯＦＦにする手順などを含むプログラムである。

家電制御サーバは、毎日、所定の時刻にプログラムをダウンロードし、ダウンロードしたプログラムに従って、各リソースを制御する。
また、リソースに対して、プログラムの手順に大きく反する操作がなされたとき、例えば、勤務時間として登録されている時刻に照明が点灯されたときなど、家電制御サーバは、その旨をサーバ装置に通知する。

サーバ装置は、例えば、利用者の携帯電話などに、登録されている生活パターンに合致しない操作が為されたことを通知する。この操作が利用者自身によるものである場合、利用者は、サーバ装置にその旨を通知する。
この場合は、例えば、サーバ装置は、家電制御サーバに自動制御サービスの停止を指示したり、休日の生活パターンに合わせたプログラムを送信しなおしたりする。

この操作が利用者自身によるものでない場合、利用者は、警察や所定の警備会社などに連絡し、自宅の安全確認を依頼することができる。
（６）実施の形態３では、サービスを受けるためのリソース予約よりも、利用者による指示を実行するためのリソース予約を無条件で優先させる構成になっている。具体的には、図１２のステップＳ６０５のＮＯの場合のように、使用者がユーザ名である予約を優先しているが、このような構成に限るものではない。

逆にサービスを受けるためのリソース予約（つまり、使用者名がサービス提供者である予約）を優先しても良いし、使用者がユーザであるかサービス提供者であるかにかかわらず、利用者の選択に任せる構成であっても良い。
（７）上記の実施の形態２及び３では、何れも、所定時刻になると、サービス取得手段がサーバ装置に対してプログラムのダウンロード要求を送信し、プログラムを取得していた。

しかし、サーバ装置側でも使用予定時間帯を保持しているので、端末からは要求することなく、所定時刻にサーバ装置が、プログラムを送信するとしても良い。
この場合、サーバ装置は、自身を識別する情報（例えばサービス提供者名）とプログラムとを送信する。
端末のサービス取得手段は、サービス提供者名とプログラムとを受信し、これらをサービス実行手段へ出力する。

サービス実行手段は、プログラムの内容を解析し、プログラムの実行により用いられるリソースとリソースが動作する予定の動作期間とを特定する。
次に、サービス実行手段は、リソース予約テーブルにおいて、受け取ったサービス提供者名と特定したリソースの名称とを含む予約情報を検出する。検出した予約情報に含まれる使用予定時間帯と、特定した動作期間とを比較し、使用予定時間帯に動作期間が含まれているか否かを判断する。使用予定時間帯に動作期間が含まれていれば、サービス実行手段は、受信したプログラムを実行して、前記リソースを動作させる。

リソース予約テーブル内に、上述した条件に適する予約情報が存在しない場合、サービス実行手段は、受信したプログラム及びサービス提供者名を破棄する。
なお、上記のプログラムの解析及び予約情報の検索は、サービス取得手段が行っても良い。
（８）上記の実施の形態において、リソース予約テーブル２０２１は、確定フラグ及び確保フラグの一方若しくは両方を含まなくても良い。

さらに、リソース予約テーブル２０２１が、確定フラグ及び確保フラグのうち両方とも含まない場合、端末は、確定フラグが常時「Ｙｅｓ」であり、確保フラグが常時「１」であるような動作をします。つまり、後から入力されたリソース予約指示よりも、既に、リソース予約テーブル２０２１に登録済みの予約の方が優先する。
なお、利用者の操作により、後から入力されたリソース予約指示により、既存の予約情報の使用予定時間帯を変更されたり、既存の使用予定情報が削除されたりしてもよい。

（９）上記の各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレィユニット、キーボード、マウスなどから構成されるコンピュータシステムである。前記ＲＡＭ、ＲＯＭ、前記ハードディスクユニットには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、各装置は、その機能を達成する。ここで、コンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。

（１０）上記の各装置を構成する構成要素の一部又は全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。

（１１）上記の各装置を構成する構成要素の一部又は全部は、各装置に脱着可能なＩＣカード又は単体のモジュールから構成されているとしてもよい。前記ＩＣカード又は前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、などから構成されるコンピュータシステムである。前記ＩＣカード又は前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ＩＣカード又は前記モジュールは、その機能を達成する。このＩＣカード又はこのモジュールは、耐タンパ性を有するとしてもよい。

（１２）本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。
また、本発明は、前記コンピュータプログラム又は前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ―ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）、半導体メモリなど、に記録したものとしてもよい。また、これらの記録媒体に記録されている前記コンピュータプログラム又は前記デジタル信号であるとしてもよい。

また、本発明は、前記コンピュータプログラム又は前記デジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
また、本発明は、マイクロプロセッサとメモリとを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記憶しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしてもよい。

また、前記プログラム又は前記デジタル信号を前記記録媒体に記録して移送することにより、又は前記プログラム又は前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
（１３）また、上記実施例におけるメモリカード、ＳＩＭカードの機能ブロックの全てが集積回路であるＬＳＩとして実現される場合も本発明に含まれる。また、機能ブロックの全てに限らず一部がＬＳＩとして実現される場合も本発明に含まれる。これらは個別に１チップ化されても良いし、一部又は全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）やＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
更には、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適応などが可能性として有り得る。

（１４）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。

各種のリソース管理し、ネットワークに接続可能な電気機器を製造及び販売する産業、このような電気機器の管理するリソースを活用したサービスを提供す産業、若しくは、サービスを提供するための機器を製造及び販売する産業において、経営的、反復、継続的に利用することができる。

実施の形態１における端末１０００の構成を示すブロック図である。 リソース予約テーブル１０２１の詳細を示す。 実施の形態２におけるサービス提供システム１の構成を示す構成図である。 実施の形態２における、端末２０００の構成を示すブロック図である。 予約状況保持手段２００３の保持するリソース予約テーブル２０２１の詳細を示す。 端末２０００によるリソース予約の動作を示すフローチャートである。 実施の形態３におけるサービス提供システム３の構成を示す構成図である。 実施の形態３における端末３０００の構成を示すブロック図である。 リソース競合提示手段３００４が提示する画面の一例を示す。 実施の形態３において、リソースの予約に競合が発生した際の、競合解消前のリソース予約テーブル３０２１ａと競合解消後のリソース予約テーブル３０２１ｂの変化を示す。 実施の形態３におけるサーバ装置４０００の構成を示すブロック図である。 端末３０００によるリソース予約の動作を示すフローチャートである。 サービス提供システム３のサービス提供時における各装置の動作を示すフローチャートである。 サービス提供時におけるサービス提供システム３の構成及びデータフローを示す図である。

符号の説明

１ サービス提供システム
１０００ 端末
１００１ 端末リソース確保手段
１００２ リソース競合検知手段
１００３ 予約情報保持手段
１００４ リソース競合提示手段
１００５ サービス実行手段
１００６ リソース群
１００７ 入力手段
１００８ 外部リソース
１０２１ リソース予約テーブル
２０００ 端末
２００７ ネットワークパス取得手段
２００８ サービス取得手段
２０２１ リソース予約テーブル
２０５０ サーバ装置
３０００ 端末
３００４ リソース競合提示手段
３００７ サービス内容取得手段
３００９ リソース競合通知手段
４０００ サーバ装置
４００１ サービス要求受信手段
４００２ サービス生成手段
４００３ サービス送信手段
４００４ リソース競合通知受信手段
４００６ サービス内容通知手段

Claims (13)

1. 自身の管理するリソースを用いてサービスの提供を受けるリソース管理装置であって、
   リソースを用いるサービスについて、提供を受ける予定の使用予定時間帯を記憶する記憶手段と、
   前記使用予定時間帯の開始前に、ネットワークを介してサーバ装置から、自装置の利用者に適した前記リソースの推奨的な動作と動作期間とを示す手順を取得する取得手段と、
   取得した手順の示す前記動作期間が、前記記憶手段の記憶している前記使用予定時間帯に含まれるか否かを判断する判断手段と、
   前記使用予定時間帯に含まれると判断された場合、前記動作期間前に前記リソースを確保し、前記確保したリソースを取得した手順に従って動作するように前記動作期間に制御する制御手段と
   を備えることを特徴とするリソース管理装置。
2. 前記リソース管理装置は、さらに、
   他のサービスの提供を受ける他の使用予定時間帯を受け付ける受付手段と、
   同一のリソースについて、前記記憶手段の記憶している前記使用予定時間帯と前記他の使用予定時間帯とが重複するか否かを判断する競合検出手段と、
   重複すると判断された場合、その旨を利用者に通知する通知手段と
   を備えることを特徴とする請求項１に記載のリソース管理装置。
3. 前記リソース管理装置は、さらに、
   競合検出手段により重複すると判断された場合に、
   前記記憶手段の記憶している前記使用予定時間帯を、前記他の使用予定時間帯と重複しないように変更する変更手段と、
   変更後の前記使用予定時間帯を、ネットワークを介して前記サーバ装置へ通知する通知手段と
   を備えることを特徴とする請求項２に記載のリソース管理装置。
4. 前記変更手段は、利用者により前記他のサービスを優先すると指示された場合にのみ、前記変更を行う
   ことを特徴とする請求項３に記載のリソース管理装置。
5. 前記変更後の使用予定時間帯を通知した場合、
   前記取得手段は、前記手順に代えて、前記変更後の使用予定時間帯において、前記利用者に適した前記リソースの推奨的な動作及び動作期間を示す代替手順を取得し、
   前記制御手段は、前記手順に代えて、前記代替手順に従って動作するように前記リソースを制御する
   ことを特徴とする請求項３に記載のリソース管理装置。
6. 重複していないと判断した場合、
   競合検出手段は、さらに、前記リソースを用いた前記他のサービスの提供を受ける予定の前記他の使用予定時間帯を前記記憶手段に書き込む
   ことを特徴とする請求項２に記載のリソース管理装置。
7. 前記取得手段は、前記使用予定時間帯の開始時刻から所定の時間を差し引いた要求時刻に前記手順を取得する
   ことを特徴とする請求項１に記載のリソース管理装置。
8. 前記サービスは、当該リソース管理装置の利用者の嗜好に合った放送番組の予約録画に関するサービスであって、
   前記取得手段は、前記使用予定時間帯において前記利用者の嗜好に合った放送番組を録画するような前記リソースの動作を示す前記手順を取得し、
   前記制御手段は、前記手順に従って、前記放送番組の開始直前に前記リソースを確保し、前記放送番組を録画するように前記リソースを制御する
   ことを特徴とする請求項１に記載のリソース管理装置。
9. 前記サービスは、前記リソースである家電製品の自動制御に関するサービスであって、
   前記取得手段は、前記利用者の生活パターンに適した前記家電製品の動作を示す手順を取得し、
   前記制御手段は、前記手順に従って、前記家電製品の動作期間の直前に前記家電製品を確保し、確保した家電製品を前記利用者の生活パターンに適した動作をするように制御する
   ことを特徴とする請求項１に記載のリソース管理装置。
10. 自身の管理するリソースを用いてサービスの提供を受けるリソース管理装置とネットワークを介してサービスを提供するサーバ装置からなるサービス提供システムであって、
    前記リソース管理装置は、
    リソースを用いるサービスについて、提供を受ける予定の使用予定時間帯を記憶する記憶手段と、
    前記使用予定時間帯の開始前に、ネットワークを介してサーバ装置から、自装置の利用者に適した前記リソースの推奨的な動作と動作期間とを示す手順を取得する取得手段と、
    取得した手順の示す前記動作期間が、前記記憶手段の記憶している前記使用予定時間帯に含まれるか否かを判断する判断手段と、
    前記使用予定時間帯に含まれると判断された場合、前記動作期間前に前記リソースを確保し、確保したリソースを取得した手順に従って動作するように制御する制御手段とを備え、
    前記サーバ装置は、
    前記リソース管理装置の利用者に関する情報とサービスを提供する予定の前記使用予定時間帯とを記憶している記憶手段と、
    前記情報及び前記使用予定時間帯を基に、前記手順を生成する生成手段と、
    生成した手順を送信する送信手段とを
    備えることを特徴とするサービス提供システム。
11. 自身の管理するリソースを用いてサービスの提供を受けるリソース管理装置で用いられるリソース管理方法であって、
    前記リソース管理装置は、
    リソースを用いるサービスについて、提供を受ける予定の使用予定時間帯を記憶する記憶手段と、取得手段と、判断手段と、制御手段とを備え、
    前記リソース管理方法は、
    前記取得手段が、前記使用予定時間帯の開始前に、ネットワークを介してサーバ装置から、自装置の利用者に適した前記リソースの推奨的な動作と動作期間とを示す手順を取得する取得ステップと、
    前記判断手段が、取得した手順の示す前記動作期間が、前記記憶手段の記憶している前記使用予定時間帯に含まれるか否かを判断する判断ステップと、
    前記制御手段が、前記使用予定時間帯に含まれると判断された場合、前記動作期間前に前記リソースを確保し、前記確保したリソースを取得した手順に従って動作するように前記動作期間に制御する制御ステップと
    を含むことを特徴とするリソース管理方法。
12. 自身の管理するリソースを用いてサービスの提供を受けるリソース管理装置で用いられるリソース管理プログラムであって、
    前記リソース管理装置は、
    リソースを用いるサービスについて、提供を受ける予定の使用予定時間帯を記憶する記憶手段を備え、
    前記リソース管理プログラムは、
    前記使用予定時間帯の開始前に、ネットワークを介してサーバ装置から、自装置の利用者に適した前記リソースの推奨的な動作と動作期間とを示す手順を取得する取得ステップと、
    取得した手順の示す前記動作期間が、前記記憶手段の記憶している前記使用予定時間帯に含まれるか否かを判断する判断ステップと、
    前記使用予定時間帯に含まれると判断された場合、前記動作期間前に前記リソースを確保し、前記確保したリソースを取得した手順に従って動作するように前記動作期間に制御する制御ステップとを、前記リソース管理装置に実行させる
    ことを特徴とするリソース管理プログラム。
13. コンピュータ読み取り可能な記録媒体に記録されていること
    ことを特徴とする請求項１２に記載のリソース管理プログラム。

Images