(57)【要約】【課題】ＡＰに対して抽象サービスのみを意識させ、ＡＰの要求に最適なリソース機能が選択され制御される仕組みを提供する。【解決手段】ＡＰに対して抽象サービスを指定するＩ／Ｆ４を提供する抽象サービス管理機能１、抽象サービスの提供に必要な論理リソース機能の操作手順を記した実装プログラム、その属性情報を管理する実装プログラム管理機能２、論理リソース機能の属性情報を管理する論理リソース機能管理機能３、実際のリソース機能と対応の論理リソース機能ＬＲ１〜ＬＲ４を備える。抽象サービス管理機能１が、ＡＰから抽象サービス要求を受信すると、管理機能２、３に検索要求を実施して、要求に最適な実装プログラムを特定および実行することで、当該実装プログラムの制御対象となる論理リソース機能によるコマンド変換処理を経て、対応するリソース機能が制御される。【選択図】      図１
2006065674.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションプログラムに対して、リソースが提供する機能・サービスを抽象化して分類・定義された抽象サービスを指定するインタフェースを提供する抽象サービス管理機能と、実際にサービスを提供するリソース機能と対応付けられた論理リソース機能と、前記抽象サービスの提供に必要な論理リソース機能に対する操作手順を記述した実装プログラムおよび当該実装プログラムの属性情報を管理する実装プログラム管理機能と、前記論理リソース機能の属性情報を管理する論理リソース機能管理機能とを備え、
前記抽象サービス管理機能は、前記アプリケーションプログラムから抽象サービス、抽象サービス提供位置および要求内容等の引数を持つ抽象サービス要求を受信すると、前記実装プログラム管理機能および前記論理リソース機能管理機能に対して検索、問い合わせを要求して、前記アプリケーションプログラムの要求に最適な実装プログラムおよび論理リソース機能を特定し、
前記特定された実装プログラムを実行することにより、当該実装プログラムにて実行される当該論理リソース機能に対するコマンドが、当該論理リソース機能によって対応するリソース機能が具備する制御プロトコル規定に従う固有コマンドヘとコマンド変換処理されて、当該リソース機能が制御される、
ことを特徴とする抽象サービスによるリソース制御方法。
【請求項２】
請求項１に記載の抽象サービスによるリソース制御方法において、実装プログラムの属性情報は、実装プログラム名、抽象サービス、利用される全ての論理リソース機能種別、優先度等を含み、論理リソース機能の属性情報は、論理リソース機能名、論理リソース機能種別、抽象サービス提供位置を含むことを特徴とする抽象サービスによるリソース制御方法。
【請求項３】
請求項１もしくは２に記載の抽象サービスによるリソース制御方法において、実装プログラムには、１つの抽象サービスに対して、利用する論理サービス種別およびその操作手順の異なる複数のパターンが存在しうることを特徴とする抽象サービスによるリソース制御方法。
【請求項４】
請求項２もしくは３に記載の抽象サービスによるリソース制御方法において、実装プログラムの特定は、抽象サービス管理機能が実装プログラム管理機能に検索要求を実施することによってアプリケーションプログラムが要求した抽象サービスに適合する実装プログラムの候補を特定する過程、当該抽象サービス管理機能が実装プログラム管理機能に問い合わせることによって当該実装プログラムにて利用される全ての論理リソース機能種別を把握する過程、当該抽象サービス管理機能が論理リソース機能管理機能に検索要求を実施することによって、当該実装プログラムごとに利用される全ての論理リソース種別について当該抽象サービス以外のアプリケーションプログラムの要求を満たす論理リソース機能の有無の確認を行う過程を経て特定されることを特徴とする抽象サービスによるリソース制御方法。
【請求項５】
請求項４に記載の抽象サービスによるリソース制御方法において、実装プログラムによって制御される論理リソース機能は、当該実装プログラムごとに利用される全て論理リソース種別について抽象サービス以外のアプリケーションプログラムの要求を満たす論理リソース機能の有無の確認を行う過程において特定されることを特徴とする抽象サービスによるリソース制御方法。
【請求項６】
請求項１乃至５のいずれか１項に記載の抽象サービスによるリソース制御方法において、実装プログラムは、論理リソース機能種別を用いて記述され、当該論理リソース機能種別および当該実装プログラムに記述される当該論理リソース機能種別に対するコマンドは唯一の制御プロトコル規定に従うことを特徴とする抽象サービスによるリソース制御方法。
【請求項７】
請求項１乃至５のいずれか１項に記載の抽象サービスによるリソース制御方法において、実装プログラム管理機能が管理する実装プログラムに関する属性情報は、唯一の制御プロトコル規定に従うことを特徴とする抽象サービスによるリソース制御方法。
【請求項８】
請求項１乃至５のいずれか１項に記載の抽象サービスによるリソース制御方法において、論理リソース機能管理機能が管理する論理リソース機能に関する属性情報は、唯一の制御プロトコル規定に従うことを特徴とする抽象サービスによるリソース制御方法。
【請求項９】
請求項３に記載の抽象サービスによるリソース制御方法において、実装プログラムの属性情報として、優先度を設けることによって、抽象サービス管理機能は優先度に応じプログラムを１つに特定することを特徴とする抽象サービスによるリソース制御方法。
【請求項１０】
請求項１乃至５に記載の抽象サービスによるリソース制御方法において、全ての実装プログラムは同一のプログラム記述言語によって記述されることを特徴とする抽象サービスによるリソース制御方法。
【請求項１１】
アプリケーションプログラムに対して、リソースが提供する機能・サービスを抽象化して分類・定義された抽象サービスを指定するインタフェースを提供する抽象サービス管理機能と、実際にサービスを提供するリソース機能と対応付けられた論理リソース機能と、前記抽象サービスの提供に必要な論理リソース機能に対する操作手順を記述した実装プログラムおよび当該実装プログラムの属性情報を管理する実装プログラム管理機能と、前記論理リソース機能の属性情報を管理する論理リソース機能管理機能とを備え、
前記抽象サービス管理機能は、前記アプリケーションプログラムから抽象サービス、抽象サービス提供位置および要求内容等の引数を持つ抽象サービス要求を受信すると、前記実装プログラム管理機能および前記論理リソース機能管理機能に対して検索、問い合わせを要求して、前記アプリケーションプログラムの要求に最適な実装プログラムおよび論理リソース機能を特定し、
前記特定された実装プログラムを実行することにより、当該実装プログラムにて実行される当該論理リソース機能に対するコマンドが、当該論理リソース機能によって対応するリソース機能が具備する制御プロトコル規定に従う固有コマンドヘとコマンド変換処理されて、当該リソース機能が制御される、
ことを特徴とする抽象サービスによるリソース制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソースにサービスを要求するアプリケーションプログラムに対して、必要なリソースを意識させることなく、抽象サービスおよび抽象サービス提供位置等の抽象サービスに関する要求のみを指定させることによって、最適なリソースが制御される抽象サービスによるリソース制御方法およびシステムに関するものである。
【背景技術】
【０００２】
従来、ネットワークに接続されるリソースを統一的に制御する仕組みとして、Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ（ＵＰｎＰ）、ＥＣＨＯＮＥＴ、Ｊｉｎｉ、ＨＡＶｉ（Ｈｏｍｅ  Ａｕｄｉｏ／Ｖｉｄｅｏ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）等の制御プロトコルが提案されており、これら制御プロトコルは、サービス、機能、デバイスオブジェクト等の論理的な存在に対して制御要求を行うことができる仕組みを提供している。しかしながら、リソースごとに実装される制御プロトコルが異なるため、特定の範囲のネットワーク、例えばホームネットワークを考えた場合、異なる複数の制御プロトコルが混在することが想定される。その結果、アプリケーションプログラムは、制御対象リソースが実装する全ての制御プロトコルを認識する仕組みを具備し、かつ、それら全ての制御プロトコルに対応する必要がある。
【０００３】
一方、ネットワーク上に分散する機能を、独自のネーミングシステムを用いて抽象度の高い名前で管理し、サービスに必要な機能の名前および機能間の相互接続関係および機能の選択基準を記述したサービスグラフを用いて、動的なサービス合成を実現するネットワークアプリケーションサービスプラットフォームとしてサービスシンセサイザ（ＳＴＯＮＥ）が提案されている（例えば、非特許文献１参照）。しかしながら、ＳＴＯＮＥでは、同種のサービスに対して機能の組み合わせや相互接続関係等の異なる複数のパターンのサービスグラフが存在する状況は想定されておらず、さらに当該サービスグラフの属性情報を管理することによって、クライアント（アプリケーションプログラム等）の要求に最適なサービスグラフを特定するという仕組みも存在しない。
【０００４】
また、異なる制御プロトコルが混在する状況において、ネットワーク上のリソースを統合的かつ動的に管理するＵｎｉｖｅｒｓａｌ  Ｈｏｍｅ  Ｎｅｔｗｏｒｋ  Ｍｉｄｄｌｅｗａｒｅ（ＵＨＮＭ）が提案されている（例えば、非特許文献２参照）。ＵＨＮＭでは、ネットワーク上のリソースが具備する制御プロトコルの違いに関わらず、共通的なコマンドでリソースの検索・制御が行われる。さらに、ＵＨＮＭは、サービスが利用するリソースを管理する機能を具備しており、アプリケーションプログラムは、共通的なインタフェースを用いてサービスに対する要求を行うことにより、当該サービスに必要なリソースの発見・利用可否の確認・制御を行う。しかしながら、ＵＨＮＭでは、同種のサービスに対してリソースの組み合わせの異なる複数のパターンが存在するという状況は想定されておらず、さらに当該パターンの属性情報を管理することによって、アプリケーションプログラムの要求に最適なパターンを特定するという仕組みも存在しない．
【０００５】
【非特許文献１】南正輝、森川博之、青山友紀“ネットワークサービスシンセサイザのデザイン”電子情報通信学会総合大会  ２００３年３月
【非特許文献２】Ｋｙｅｏｎｇ−Ｄｅｏｋ  Ｍｏｏｎ，Ｙｏｕｎｇ−ＨｅｅＬｅｅ，Ｙｏｕｎｇ−Ｓｕｎｇ  Ｓｏｎ  ａｎｄ  Ｃｈａｅ−Ｋｙｕ  Ｋｉｍ“Ｕｎｉｖｅｒｓａｌ  Ｈｏｍｅ  Ｎｅｔｗｏｒｋ  Ｍｉｄｄｌｅｗａｒｅ  Ｇｕａｒａｎｔｅｅｉｎｇ  Ｓｅａｍｌｅｓｓ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ａｍｏｎｇ  ｔｈｅ  Ｈｅｔｅｒｏｇｅｎｅｏｕｓ  Ｈｏｍｅ  Ｎｅｔｗｏｒｋ  Ｍｉｄｄｌｅｗａｒｅ”，ＩＥＥＥ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｃｏｎｓｕｍｅｒ  Ｅｌｅｃｔｒｏｎｉｃｓ，Ｖｏｌ．４９，Ｎｏ．３，Ａｕｇｕｓｔ  ２００３
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、上記のような問題を解決するものであり、リソースサービス要求を行うアプリケーションプログラムに対しては、抽象サービスのみを意識させ、抽象サービスの実現方法としての実装プログラムは、１つの抽象サービスについて複数のパターンを許容し、アプリケーションプログラムからの要求があるごとに、当該要求内容（抽象サービス提供位置、機能、性能等）に最適な実装プログラムを選択する仕組みを具備し、さらに実装プログラムは、リソースが具備する制御プロトコルに依存しない唯一の制御プロトコルに従いかつ唯一のプログラム記述言語で記述される抽象サービスによるリソース制御方法およびシステムを提供することにある。
【課題を解決するための手段】
【０００７】
本発明は、アプリケーションプログラムに対して、抽象サービスおよび抽象サービス提供位置および要求内容等を指定するインタフェースを提供する抽象サービス管理機能、抽象サービスの提供に必要な論理リソース機能種別に対する操作手順を記した実装プログラムおよび当該実装プログラムの属性情報（実装プログラム名、抽象サービス、利用される全ての論理リソース機能種別、優先度等）を管理する実装プログラム管理機能、論理リソース機能の属性情報（論理リソース機能名、論理リソース機能種別、位置等）を管理する論理リソース機能管理機能、実装プログラムにて実行されるコマンドを適切な制御プロトコル規定の固有コマンドに変換する論理リソース機能を備える。抽象サービス管理機能は、アプリケーションプログラムから抽象サービス要求を受信すると、実装プログラム管理機能および論理リソース機能管理機能に対して検索および問い合わせ等を要求することによって、アプリケーションプログラムの要求に最適な実装プログラムおよび論理リソース機能を特定し、当該実装プログラムを実行する。当該実装プログラムにて実行される当該論理リソース機能に対するコマンドは、当該論理リソース機能によって対応するリソース機能が具備する制御プロトコル規定に従う前記固有コマンドヘとコマンド変換処理され、その結果、当該リソース機能が制御される。
【０００８】
本発明の実装プログラムには、１つの抽象サービスに対して、利用する論理サービス種別およびその操作手順の異なる複数のパターンが存在しうることを特徴とする。
【０００９】
また、本発明では、抽象サービス管理機能による実装プログラムの特定は、抽象サービス管理機能が実装プログラム管理機能に検索要求を実施することによってアプリケーションプログラムが要求した抽象サービスに適合する実装プログラムの候補を特定する過程、当該抽象サービス管理機能が実装プログラム管理機能に問い合わせることによって当該実装プログラムにて利用される全ての論理リソース機能種別を把握する過程、当該抽象サービス管理機能が論理リソース機能管理機能に検索要求を実施することによって、当該実装プログラムごとに利用される全て論理リソース種別について当該抽象サービス以外のアプリケーションプログラムの要求（抽象サービス提供位置等）を満たす論理リソース機能の有無の確認を行う過程、等を経て特定されることを特徴とする。
【００１０】
また、本発明では、実装プログラムによって制御される論理リソース機能は、抽象サービス管理機能が当該実装プログラムごとに利用される全て論理リソース種別について抽象サービス以外のアプリケーションプログラムの要求（抽象サービス提供位置等）を満たす論理リソース機能の有無の確認を行う過程において特定されることを特徴とする。
【００１１】
また、本発明では、実装プログラムは、論理リソース機能種別を用いて記述され、当該論理リソース機能種別および当該実装プログラムに記述される当該論理リソース機能種別に対するコマンドは唯一の制御プロトコル規定に従うことを特徴とする。
【００１２】
また、本発明では、実装プログラム管理機能が具備する実装プログラムに関する属性情報は、唯一の制御プロトコル規定に従うことを特徴とする．
また、本発明では、論理リソース機能管理機能が具備する論理リソース機能に関する属性情報は、唯一の制御プロトコル規定に従うことを特徴とする。
【００１３】
また、本発明では、実装プログラムの属性情報として、優先度を設けることによって、抽象サービス管理機能は実装プログラムを１つに特定することを特徴とする。
【００１４】
また、本発明では、全ての実装プログラムは同一のプログラム記述言語によって記述されることを特徴とする。
【発明の効果】
【００１５】
本発明によれば、アプリケーションプログラムが必要な抽象サービスおよび抽象サービスに係わる要求内容のみを指定することによって、要求された抽象サービスに対して管理されている複数のパターンの実装プログラムの中から最適な１つを選択し、その結果、最適なリソースを制御する仕組みを提供するため、アプリケーション開発者は、必要な論理リソース機能種別およびリソース種別、特定の位置（例えば建物や部屋）におけるリソースの配置状況、リソースに実装される制御プロトコル種別、リソースの機能・性能等を全く意識することなく、汎用的なアプリケーションを開発することが可能となる。
【００１６】
また、実装プログラムは、リソースが具備する制御プロトコルとは無関係に、唯一の制御プロトコルに従いかつ唯一のプログラム記述言語によって記述されるため、実装プログラム開発者は、開発する実装プログラムによって制御されるリソースが具備する制御プロトコルを意識することなく、汎用的な実装プログラムを開発することが可能となる。
【発明を実施するための最良の形態】
【００１７】
以下に、本発明の実施の形態について、図面を用いて具体的に説明する。
図１は、本発明の抽象サービスによるリソース制御方法を実現するシステム構成例を示す図である。本システム１００は、クライアント（パソコン、携帯端末、携帯電話等）のアプリケーションプログラムＡＰ１〜ＡＰ２に対して、室温調整サービスＳ１、セキュリティサービスＳ２等の抽象サービスおよび抽象サービスに関わる要求内容等を指定するインタフェース４を提供する抽象サービス管理機能１、抽象サービスの提供に必要な論理リソース機能種別の操作手順を記した実装プログラムＰ１〜Ｐ４、さらに各実装プログラムについて対象する抽象サービスおよび必要な全ての論理リソース機能種別等を記した実装プログラム属性情報ＰＩ１、ＰＩ２、ＰＩ３、ＰＩ４を管理する実装プログラム管理機能２、実装プログラムＰ１、Ｐ２、Ｐ３、Ｐ４より実行されるコマンドを適切な制御プロトコル規定の固有コマンド５に変換する論理リソース機能ＬＲ１〜ＬＲ４、及び各論理リソース機能について論理リソース機能種別および制御プロトコル種別および位置等を記した論理リソース機能属性情報ＬＲＩ１〜ＬＲＩｎを管理する論理リソース機能管理機能３で構成され、各論理リソース機能ＬＲ１〜ＬＲ４は、実際にサービスを提供するリソース機能（情報家電等）Ｒ１〜Ｒ４と対応付けられている。
【００１８】
ここで、全ての実装プログラムは同一のプログラム記述言語によって記述される。また、実装プログラム管理機能２が管理する実装プログラムＰ１〜Ｐ４に関する属性情報ＰＩ１〜ＰＩ４は、唯一の制御プロトコル規定に従うようにする。同様に、論理リソース機能管理機能３が管理する論理リソース機能ＬＲ１〜ＬＲｎに関する属性情報ＬＲＩ１〜ＬＲＩｎは、唯一の制御プロトコル規定に従うようにする。
【００１９】
また、実装プログラムＰ１〜Ｐ４の関する属性情報ＰＩ１〜ＰＩ４は、当該実装プログラムとは独立にファイルまたはデータベースに記録されていても、当該実装プログラム内に記述されていても良い。同様に、論理リソース機能ＬＲ１〜ＬＲｎに関する属性情報ＬＲＩ１〜ＬＲＩｎは、当該論理リソース機能とは独立にファイルまたはデータベースに記録されていても、当該論理リソース機能内に記述されていても良い。
【００２０】
なお、抽象サービス管理機能１、実装プログラム管理機能２及び論理リソース機能管理機能３等は、例えば、抽象サービスリソース制御サーバとして一つのサーバ内に集約するか、あるいは、それぞれ抽象サービス管理サーバ、実装プログラム管理サーバ、論理リソース機能管理サーバなどとしてネットワーク上に分散して用意するか、さらには、一部機能のみを分散させるなどのいずれでもよい。
【００２１】
図２は、実装プログラム管理機能２で管理される実装プログラム属性情報ＰＩ１〜ＰＩ４の一例を示す図である。図２では、簡単化のためにＰＩ１とＰＩ２のみしか示していないが、ＰＩ３、ＰＩ４についても同様である。
実装プログラム属性情報ＰＩ１には、実装プログラムＰ１の属性情報が記述されており、本実施例においては、対応する抽象サービスは室温調整サービスＳ１、実装プログラムＰ１で利用される論理リソース機能種別はエアコンＬＲ１、優先度はＡ、その他である。実装プログラム属性情報ＰＩ２には、実装プログラムＰ２の属性情報が記述されており、本実施例においては、対応する抽象サービスは実装プログラムＰ１と同じ室温調整サービスＳ１であるが、実装プログラムＰ２で利用される論理リソース機能種別はクーラーＬＲ２、ヒーターＬＲ３、温度センサＬＲ４であり、優先度はＢ、その他である。
【００２２】
図３は、論理リソース機能管理機能３で管理される論理リソース機能属性情報ＬＲＩ〜ＬＲＩｎの一例を示す図である。論理リソース機能属性情報ＬＲＩ１には、論理リソース機能ＬＲ１の属性情報が記述されており、本実施例においては、論理リソース機能名はエアコン００１、論理リソース機能種別はエアコン、位置はＬｉｖｉｎｇＲｏｏｍ、その他である。論理リソース機能属性情報ＬＲＩ２には、論理リソース機能ＬＲ２の属性情報が記述されており、本実施例においては、論理リソース機能名はクーラー００２、論理リソース機能種別はクーラー、位置はＬｉｖｉｎｇＲｏｏｍ、その他である。論理リソース機能属性情報ＬＲＩ３には、論理リソース機能ＬＲ３の属性情報が記述されており、本実施例においては、論理リソース機能名はヒーター００３、論理リソース機能種別はヒーター、位置はＬｉｖｉｎｇＲｏｏｍ、その他である。論理リソース機能属性情報ＬＲＩ４には、論理リソース機能ＬＲ４の属性情報が記述されており、本実施例においては、論理リソース機能名は温度センサ００４、論理リソース機能種別は温度センサ、位置はＬｉｖｉｎｇＲｏｏｍ、その他である。
【００２３】
以下、本システム１００の動作例を説明する。ここでは、アプリケーションプログラムＡＰ１から室温調整サービスＳ１、設定温度２５°Ｃ、サービス提供位置Ｌｉｖｉｎｇ  Ｒｏｏｍ等を引数に持つ抽象サービス要求を受けたとする。また、実装プログラム属性情報ＰＩ１、ＰＩ２は図２の通りであり、論理リソース機能属性情報ＬＲＩ１〜ＬＲＩ４は図３の通りであるとする。
【００２４】
まず、アプリケーションプログラムＡＰ１からの抽象サービス要求に最適な実装プログラムを特定する動作について説明する。
【００２５】
図４は、抽象サービス管理機能１が実装プログラムＰ１〜Ｐ４を特定する処理シーケンス例を示す図である。
アプリケーションプログラムＡＰ１から室温調整サービスＳ１、設定温度２５℃、サービス提供位置ＬｉｖｉｎｇＲｏｏｍ、等の引数を持つ抽象サービス要求を抽象サービス管理機能１が受信すると（Ｓ１０１）、抽象サービス管理機能１は、実装プログラム管理機能２に対して、室温調整サービスＳ１を検索条件とする実装プログラム検索要求を実行する（Ｓ１０２）。実装プログラム管理機能２は、実装プログラム属性情報ＰＩ１〜ＰＩ４を参照し、検索条件である室温調整サービスＳ１に該当する実装プログラム名のリストを返す（Ｓ１０３）。本実施例においては、実装プログラムＰ１およびＰ２が該当したものとする。
【００２６】
次に、抽象サービス管理機能１は、実装プログラム管理機能２に対し、実装プログラムＰ１の属性情報取得要求を実行し（Ｓ１０４）、実装プログラム管理機能２から実装プログラム属性情報ＰＩ１を受け取る（Ｓ１０５）。同様に、実装プログラムＰ２の属性情報取得要求を実行し、実装プログラム属性情報ＰＩ２を受け取る（Ｓ１０４、Ｓ１０５）。ここで、実装プログラムＰ１の優先度Ａと実装プログラムＰ２の優先度Ｂとの関係はＡ＞Ｂであるとする。
【００２７】
抽象サービス管理機能１は、優先度の高い実装プログラムＰ１の属性情報ＰＩ１に記載されている全ての利用論理リソース機能種別（本実施例においてはエアコン）について、アプリケーションプログラムＡＰ１からの要求である設定温度２５℃、提供位置ＬｉｖｉｎｇＲｏｏｍを検索条件に加えて、論理リソース機能管理機能３に対し、論理リソース機能検索要求を実行する（Ｓ１０６）。論理リソース機能管理機能３は、論理リソース機能属性情報ＬＲＩ１〜ＬＲＩｎを参照し、検索条件に該当する論理リソース機能が存在する場合は、論理リソース機能種別名を、存在しない場合は、ＮＧを返す（Ｓ１０７）。その結果、実装プログラムＰ１の属性情報ＰＩ１に記載されている全ての利用論理リソース機能種別（エアコン）について、論理リソース機能名が返ってきた場合は、抽象サービス管理機能１は、アプリケーションプログラムＡＰ１からの要求に最適な実装プログラムは、実装プログラムＰ１であると特定し、アプリケーションプログラムＡＰ１に対し、抽象サービス要求応答としてＯＫを返す（Ｓ１０８）。
【００２８】
一方、ＮＧが返ってきた場合は、次の優先度を持つ実装プログラムＰ２について、同様の処理を行う（Ｓ１０６、Ｓ１０７）。その結果、実装プログラムＰ２の属性情報ＰＩ２に記載されている全ての利用論理リソース機能種別（本実施例においてはクーラー、ヒーター、温度センサ）について、論理リソース機能名が返ってきた場合は、抽象サービス管理機能１は、アプリケーションプログラムＡＰ１からの要求に最適な実装プログラムは、実装プログラムＰ２であると特定し、アプリケーションプログラムＡＰ１に対し、抽象サービス要求応答としてＯＫを返し、１つでもＮＧが返ってきた場合は、次の候補が存在しないため、アプリケーションプログラムＡＰ１に対し、抽象サービス要求応答としてＮＧを返す（Ｓ１０８）。
【００２９】
次に、特定された実装プログラムを実行する動作について説明する。ここでは、実装プログラムＰ１、Ｐ２が特定されたケースについてそれぞれ説明する。
【００３０】
図５は、抽象サービス管理機能１が実装プログラムＰ１を実行する処理シーケンス例を示す図である。
アプリケーションプログラムＡＰ１の要求に最適な実装プログラムとして実装プログラムＰ１、利用論理リソース機能としてエアコン００１ＬＲ１と特定された場合、抽象サービス管理機能１は、実装プログラムＰ１に対して、引数をアプリケーションプログラムＡＰ１の要求に従い２５℃とした実装プログラム実行要求を実施する（Ｓ２０１）。
【００３１】
実装プログラムＰ１は、自らの処理手順に従い、論理リソース機能エアコン００１ＬＲ１に対して、運転モードを自動とするプロパティ設定要求を実行する（Ｓ２０２）。論理リソース機能エアコン００１ＬＲ１は、対応するリソース機能ＨＶＡＣ０００１Ｒ１が具備する制御プロトコル（本実施例においてはＵＰｎＰ）規定に従った固有コマンド５（本実施例では、ＳｅｒｖｉｃｅＴｙｐｅ：ＨＶＡＣ＿ＵｓｅｒＯｐｅｒａｔｉｎｇＭｏｄｅ，Ａｃｔｉｏｎ：ＳｅｔＭｏｄｅＴａｒｇｅｔ，Ａｒｇｕｍｅｎｔ：ＮｅｗＭｏｄｅＴａｒｇｅｔ，Ｖａｌｕｅ  ｏｆ  Ａｒｇｕｍｅｎｔ：ＡｕｔｏＣｈａｎｇｅＯｖｅｒ等の要素を含むＳＯＡＰメッセージ）に変換し、ＨＶＡＣ０００１Ｒ１に当該固有コマンド５を送信する（Ｓ２０３）。
【００３２】
続いて、実装プログラムＰ１は、論理リソース機能エアコン００１ＬＲ１に対して、設定温度２５℃とするプロパティ設定要求を実行する（Ｓ２０６）。論理リソース機能エアコン００１ＬＲ１は、対応するリソース機能ＨＶＡＣ０００１Ｒ１が具備する制御プロトコル（本実施例においてはＵＰｎＰ）規定に従った固有コマンド５（本実施例では、ＳｅｒｖｉｃｅＴｙｐｅ：ＴｅｍｐｅｒａｔｕｒｅＳｅｔｐｏｉｎｔ，Ａｃｔｉｏｎ：ＳｅｔＣｕｒｒｅｎｔＳｅｔｐｏｉｎｔ，Ａｒｇｕｍｅｎｔ：ＮｅｗＣｕｒｒｅｎｔＳｅｔＰｏｉｎｔ，Ｖａｌｕｅ  ｏｆ  Ａｒｇｕｍｅｎｔ：２５００等の要素を含むＳＯＡＰメッセージ）に変換し、ＨＶＡＣ０００１Ｒ１に当該固有コマンド５を送信する（Ｓ２０６）。ＨＶＡＣＯＯＯ１Ｒ１は、運転温度を２５°Ｃに設定して、論理リソース機能エアコン００１ＬＲ１にＯＫを返し（Ｓ２０８）、論理リソース機能エアコン００１ＬＫ１はプロバティ設定要求応答（ＯＫ）を実装プログラムＰ１に返す（Ｓ２０９）。
【００３３】
図６、図７は、抽象サービス管理機能１が実装プログラムＰ２を実行する処理シーケンス例を示す図である。これは、実装プログラムＰ２が定期的に論理リソース機能温度センサ００４ＬＲ４を介して実際の温度センサ０００４Ｒ４から現在の室温を取得して、室温が設定温度（本実施例では２５°Ｃ）を上回った場合には、論理リソース機能クーラー００２ＬＲ２を介して実際の冷風機０００２Ｒ２を動作状態とし（図６）、また、室温が設定温度を下回った場合には、冷風機００２Ｒ２を不動作として、替って論理リソース機能ヒーター００３ＬＲ３を介して実際の電気暖房機０００３Ｒ３を動作状態として（図７）、室温調整を実現するものである。
【００３４】
まず、図６の処理シーケンスについて説明する。アプリケーションプログラムＡＰ１の要求に最適な実装プログラムとして実装プログラムＰ２、利用論理リソース機能としてクーラー００２ＬＲ２、ヒーター００３ＬＲ３、温度センサ００４ＬＲ４と特定された場合、抽象サービス管理機能１は、実装プログラムＰ２に対して、引数をアプリケーションプログラムＡＰ１の要求に従い２５℃とした実装プログラム実行要求を実施する（Ｓ３０１）。実装プログラムＰ２は、自らの処理手順に従い、論理リソース機能温度センサ００４ＬＲ４に対して、要求プロパティを温度とするプロパティ取得要求を実行する（Ｓ３０２）。論理リソース機能温度センサ００４ＬＲ４は、対応するリソース機能温度センサ０００４Ｒ４が具備する制御プロトコル（本実施例においてはＥＣＨＯＮＥＴ）規定に従った固有コマンド５（本実施例では、ＥＳＶ（ＥＣＨＯＮＥＴＳｅｒｖｉｃｅ）：０ｘ６２（プロパティ読み出し要求），ＥＰＣ（ＥＣＨＯＮＥＴＰｒｏｐｅｒｔｙＣｏｄｅ）：０ｘＥＯ（温度計測値）等の要素を含むＥＣＨＯＮＥＴ電文）に変換し、実際の温度センサ０００４Ｒ４に当該固有コマンド５を送信する（Ｓ３０３）。温度センサ０００４Ｒ４から、当該固有コマンド５に対する応答としての固有コマンド５（本実施例では、ＥＳＶ（ＥＣＨＯＮＥＴ  Ｓｅｒｖｉｃｅ）：０ｘ７２（プロパティ読み出し応答），ＥＰＣ（ＥＣＨＯＮＥＴＰｒｏｐｅｒｔｙＣｏｄｅ）：０ｘＥ０（温度計測値），ＥＤＴ（ＥＣＨＯＮＥＴＤａｔａ）：０ｘ０１２Ｃ等の要素を含むＥＣＨＯＮＥＴ電文）が、温度センサ００４ＬＲ４に返信される（Ｓ３０４）。論理リソース機能温度センサ００４ＬＲ４は、受信した固有コマンド５の引数を反映したプロパティ取得応答を実装プログラムＰ２に対して実行する（Ｓ３０５）。
【００３５】
実装プログラムＰ２は、設定温度２５℃を上回る数値（本実施例では３０℃）が返ってきた場合、論理リソース機能クーラー００２ＬＲ２に対して、動作状態をＯＮとするプロパティ設定要求を実行する（Ｓ３０６）。論理リソース機能クーラー００２ＬＲ２は、対応するリソース機能冷風機０００２Ｒ２が具備する制御プロトコル（本実施例においてはＥＣＨＯＮＥＴ）規定に従った固有コマンド５（本実施例では、ＥＳＶ（ＥＣＨＯＮＥＴＳｅｒｖｉｃｅ）：０ｘ６０（プロパティ書き込み要求［応答不要］），ＥＰＣ（ＥＣＨＯＮＥＴＰｒｏｐｅｒｔｙＣｏｄｅ）：０ｘ８０（動作状態），ＥＤＴ（ＥＣＨＯＮＥＴＤａｔａ）：０ｘ３０（ＯＮ）等の要素を含むＥＣＨＯＮＥＴ電文）に変換し、冷風機０００２Ｒ２に当該固有コマンド５を送信する（Ｓ３０７）。また、論理リソース機能クーラー００２ＬＲ２は、実装プログラムＰ２に対してプロパティ設定要求応答を返す（Ｓ３０８）。
【００３６】
次に、図７の処理シーケンスについて説明する。実装プログラムＰ２は、定期的に、論理リソース機能温度センサ００４ＬＲ４に対して、要求プロパティを温度とするプロパティ取得要求を実行し（Ｓ４０１）、その結果、設定温度２５℃を下回る数値（本実施例では２０℃）が返ってきた場合（Ｓ４０４）、論理リソース機能クーラー００２ＬＲ２に対して、動作状態をＯＦＦとするプロパティ設定要求を実行する（Ｓ４０５）。論理リソース機能温度センサ００４ＬＲ４と実際の温度センサ０００４Ｒ３との間のやり取り（Ｓ４０２、Ｓ４０３）は、図６のＳ３０３、Ｓ３０４と同様であるので省略する。
【００３７】
論理リソース機能クーラー００２ＬＲ２は、対応するリソース機能冷風機０００２Ｒ２が具備する制御プロトコル（本実施例においてはＥＣＨＯＮＥＴ）規定に従った固有コマンド５（本実施例では、ＥＳＶ（ＥＣＨＯＮＥＴＳｅｒｖｉｃｅ）：０ｘ６０（プロパティ書き込み要求［応答不要］），ＥＰＣ（ＥＣＨＯＮＥＴＰｒｏｐｅｒｔｙＣｏｄｅ）：０ｘ８０（動作状態），ＥＤＴ（ＥＣＨＯＮＥＴＤａｔａ）：０ｘ３１（ＯＦＦ）等の要素を含むＥＣＨＯＮＥＴ電文）に変換し、冷風機０００２Ｒ２に当該固有コマンド５を送信する（Ｓ４０６）。また、論理リソース機能クーラー００２ＬＲ２は、実装プログラムＰ２に対してプロパティ設定要求応答を返す（Ｓ４０７）。
【００３８】
その後、実装プログラムＰ２は、論理リソース機能ヒーター００３ＬＲ３に対して、動作状態をＯＮとするプロパティ設定要求を実行する（Ｓ４０８）。論理リソース機能ヒーター００３ＬＲ３は、対応するリソース機能電気暖房機０００３Ｒ３が具備する制御プロトコル（本実施例においてはＥＣＨＯＮＥＴ）規定に従った固有コマンド５（本実施例では、ＥＳＶ（ＥＣＨＯＮＥＴＳｅｒｖｉｃｅ）：０ｘ６０（プロパティ書き込み要求［応答不要］），ＥＰＣ（ＥＣＨＯＮＥＴＰｒｏｐｅｒｔｙＣｏｄｅ）：０ｘ８０（動作状態），ＥＤＴ（ＥＣＨＯＮＥＴＤａｔａ）：０ｘ３０（ＯＮ）等の要素を含むＥＣＨＯＮＥＴ電文）に変換し、電気暖房機０００３Ｒ３に当該固有コマンド５を送信する（Ｓ４０９）。また、論理リソース機能ヒーター００３ＬＲ３は、実装プログラムＰ２に対してプロパティ設定要求応答を返す（Ｓ４１０）。
【００３９】
このように、実装プログラムＰ２は、温度センサ００４ＬＲ４の結果に応じて、クーラー００２ＬＲ２またはヒーター００３ＬＲ３に対して、動作状態をＯＮまたはＯＦＦとしたプロパティ設定要求を実行する。
【００４０】
以上、実施例では、アプリケーションプログラム（ユーザ）には、抽象サービスの室温調整サービスのみを意識させ、エアコンやクーラー、ヒーター等の実際のリソースを意識させることなく、該アプリケーションプログラムの要求に最適なリソースが選択されて温室調整される仕組みを説明したが、本発明は、これに限られるものでないことは云うまでもない。
【００４１】
なお、図１で示したシステムにおける一部もしくは全部の処理機能をコンピュータのプログラムで構成し、そのプログラムをコンピュータを用いて実行して本発明を実現することができること、あるいは、図４〜図７で示した処理手順をコンピュータのプログラムで構成し、そのプログラムをコンピュータに実行させることができることは言うまでもない。また、コンピュータでその処理機能を実現するためのプログラム、あるいは、コンピュータにその処理手順を実行させるためのプログラムを、そのコンピュータが読み取り可能な記録媒体、例えば、ＦＤ、ＭＯ、ＲＯＭ、メモリカード、ＣＤ、ＤＶＤ、リムーバブルディスクなどに記録して、保存したり、提供したりすることができるとともに、インターネット等のネットワークを通してそのプログラムを配布したりすることが可能である。
【図面の簡単な説明】
【００４２】
【図１】本発明の抽象サービスによるリソース制御方法を実現するシステム構成例を示す図。
【図２】実装プログラム管理機能で管理される実装プログラム属性情報の例を示す図。
【図３】論理リソース機能管理機能で管理される論理リソース機能属性情報の例を示す図。
【図４】抽象サービス管理機能が実装プログラムを特定する処理シーケンス例を示す図。
【図５】抽象サービス管理機能が実装プログラムＰ１を実行する処理シーケンス例を示す図。
【図６】抽象サービス管理機能１が実装プログラムＰ２を実行する処理シーケンス例の前半を示す図。
【図７】抽象サービス管理機能が実装プログラムＰ２を実行する処理シーケンス例の後半を示す図。
【符号の説明】
【００４３】
ＡＰ１〜ＡＰ２  アプリケーションプログラム
１  抽象サービス管理機能
２  実装プログラム管理機能
３  理リソース機能管理機能
４  インタフェース
５  固有コマンド
Ｐ１〜Ｐ４  実装プログラム
ＰＩ１〜ＰＩ４  実装プログラム属性情報
ＬＲ１  論理リソース機能（エアコン００１）
ＬＲ２  論理リソース機能（クーラー００２）
ＬＲ３  論理リソース機能（ヒーター００３）
ＬＲ４  論理リソース機能（温度センサ００４）
ＬＲＩ１〜ＬＲＩ４  論理リソース機能属性情報
Ｒ１  リソース機能（ｍＣ０００ｌ）
Ｒ２  リソース機能（冷風機０００２）
Ｒ３  リソース機能（電気暖房機０００３）
Ｒ４  リソース機能（温度センサ０００４）
【図１】
2006065674.tif 000003
【図２】
2006065674.tif 000004
【図３】
2006065674.tif 000005
【図４】
2006065674.tif 000006
【図５】
2006065674.tif 000007
【図６】
2006065674.tif 000008
【図７】
2006065674.tif 000009