(57)【要約】【課題】エネルギー需給逼迫時に需要を抑制し、その対価を払うデマンドレスポンスにおいて、デマンドレスポンスを実施する事業体を加入しやすくするサービス連携環境を実現する。【解決手段】エネルギーの需要抑制を実施するエネルギー需要抑制システムにおいて、異なる需要抑制の機能を、需要抑制に関わる処理を実施するＤＲサービスサーバ間で相互に通信する手段と、ＤＲサービスサーバから提供されている需要抑制に関わる機能の一部もしくはすべてを保持および検索するサービス管理手段と、ＤＲサービスサーバから提供されている需要抑制に関わる異なる機能の一部もしくはすべてを組み合わせ、需要抑制を実施するためのＤＲプログラムを自動作成する手段と、需要抑制の実行時に、作成した需要抑制のＤＲプログラムに従い、ＤＲサービスサーバが需要抑制に関わる異なる機能を実行する手段と、を備える。【選択図】  図１
2014060879.tif 000002
【特許請求の範囲】
【請求項１】
エネルギーの需要抑制を実施するエネルギー需要抑制方法において、
需要家からサービス機能の作成依頼を受信する受信ステップと、
他のサービス提供者に前記サービス機能の保有を問い合わせる問い合わせステップと、
前記問い合わせの結果を組み合わせて、前記需要家からの依頼に対する新たなサービス機能を作成する作成ステップと、
エネルギーの需要抑制情報を受信する需要抑制受信ステップと、
前記作成した新たなサービス機能を実行する前記他のサービス提供者に、前記需要抑制情報に応じた需要抑制処理の実行を指示する実行指示ステップと、
前記他のサービス提供者により、需要抑制処理を実行する実行ステップと、
を備えることを特徴とするエネルギー需要抑制方法。
【請求項２】
請求項１に記載のエネルギー需要抑制方法において、
前記問い合わせステップは、前記受信ステップで受信したサービス機能について、当該サービス機能を構成する各サービス項目単位で、それぞれについて前記他のサービス提供者に問い合わせを行なうことを特徴とするエネルギー需要抑制方法。
【請求項３】
エネルギーの需要抑制を実施するエネルギー需要抑制システムにおいて、
需要家からサービス機能の作成依頼、及び電力会社からの需要抑制指示を受信する受信部と、他のサービス提供者に前記サービス機能の保有を問い合わせる問い合わせ部と、前記問い合わせの結果を組み合わせて、前記需要家からの依頼に対する新たなサービス機能を作成する作成部と、前記作成した新たなサービス機能を実行する前記他のサービス提供者に、前記需要抑制情報に応じた需要抑制処理の実行を指示する実行指示部と、を備えるエネルギー需要抑制装置と、
前記エネルギー需要抑制装置からの指示を受信し、需要抑制処理を実行する他のサービス提供者のエネルギー需要抑制装置と、
を備えることを特徴とするエネルギー需要抑制システム。
【請求項４】
エネルギーの需要抑制を実施するエネルギー需要抑制システムにおいて、
異なる需要抑制の機能を、需要抑制に関わる処理を実施するＤＲサービスサーバ間で相互に通信する手段と、
ＤＲサービスサーバから提供されている需要抑制に関わる機能の一部もしくはすべてを保持および検索するサービス管理手段と、
ＤＲサービスサーバから提供されている需要抑制に関わる異なる機能の一部もしくはすべてを組み合わせ、需要抑制を実施するためのＤＲプログラムを作成する手段と、
需要抑制の実行時に、作成した需要抑制のＤＲプログラムに従い、ＤＲサービスサーバが需要抑制に関わる機能を実行する手段と、
を備えることを特徴とするエネルギー需要抑制システム。
【請求項５】
請求項４に記載のエネルギー需要抑制システムであって、
需要抑制に関わる機能のサービス管理手段においては、
需要抑制を実施する需要抑制装置を需要家へ設置していないアグリゲータにおいても、該当アグリゲータが設置するＤＲサービスサーバが提供を受ける需要抑制に関わる機能の一部もしくはすべてをリストとして保持する手段とを備えることを特徴とするエネルギー需要抑制システム。
【請求項６】
請求項４又は５に記載のエネルギー需要抑制システムであって、
需要抑制に関わる機能のサービス管理手段においては、
ＤＲプログラムとして、需要抑制に関わる機能を少なくとも需要抑制時のエネルギーの使用量を示す実績値を計測する機能、需要抑制するための機能、需要抑制に関わる履歴を確認する機能、需要抑制に関わる料金精算を実施する機能とを保持および検索するサービス管理手段と、を備えることを特徴とするエネルギー需要抑制システム。
【請求項７】
請求項６に記載のエネルギー需要抑制システムであって、
需要抑制に関わる料金精算を実施する機能を管理するサービス管理手段においては、
ＤＲプログラムにおいてアグリゲータがサービスとして実行しない料金精算の口座管理を、異種システムのサービスに依頼する口座管理連携サービス連携手段とを備えることを特徴とするエネルギー需要抑制システム。
【請求項８】
請求項４に記載のエネルギー需要抑制システムであって、
ＤＲプログラムを自動作成する手段と、
日程や時間帯ごとの実施される割合や、需要抑制の状態によって、事前に指定された機能を切り替えるための情報を保持する需要抑制を実施するためのＤＲプログラム作成手段と、
需要抑制の実行時に、需要抑制に関わる機能を実行する手段においては、
需要抑制におけるＤＲプログラムの機能を組み合わせて実行する手段において、作成されたＤＲプログラムに従い、時間帯ごとの実施される割合や、需要抑制の状態によって、事前に指定された機能を切り替えてＤＲプログラムを実施するスケジュール管理手段とを備えることを特徴とするエネルギー需要抑制システム。
【請求項９】
請求項４に記載のエネルギー需要抑制システムであって、
需要抑制の実行時に、需要抑制に関わる機能を実行する手段においては、
他のアグリゲータにＤＲプログラムに関わる機能を提供する際に、その機能で利用するデータの粒度を変化させて提供するデータ演算手段とを備えることを特徴とするエネルギー需要抑制システム。
【請求項１０】
請求項４に記載のエネルギー需要抑制システムであって、
需要抑制に関わる機能のサービス管理手段においては、
ＤＲプログラムを実行する処理装置の記憶部にＤＲプログラムに関わる機能を設置する手段と、
設置したＤＲプログラムの機能を利用する際に、ＤＲプログラムの提供者と利用者が直接の契約を実施せずに契約処理を代行する手段とを備えることを特徴とするエネルギー需要抑制システム。
【請求項１１】
請求項４に記載のエネルギー需要抑制システムであって、
ＤＲプログラムを自動作成する手段においては、
需要抑制におけるＤＲプログラムの作成機能が、集中サーバに設置されていても、もしくは複数のサーバに設置されていても、既存の提供された需要抑制に関わる機能の内容とアドレスのリストを管理することによって、需要抑制のプログラムの一部またはすべての機能が提供されるサーバを検索し、機能を取得する手段と、
その取得した機能を組み合わせることによるＤＲプログラムを作成する手段と、を備えることを特徴とするエネルギー需要抑制システム。
【請求項１２】
エネルギーの需要抑制を実施するエネルギー需要抑制方法において、
ＤＲプログラムを作成する際に、希望するＤＲプログラムの機能が提供されているか検索し、
提供されている場合には、希望するＤＲプログラムの需要抑制の機能の一部もしくはすべての機能の情報を取得し、需要抑制を実施するためのプログラムとして組み合わせ、ＤＲプログラムを作成し、
需要抑制の依頼があり、ＤＲプログラムを実施する際には、作成したＤＲプログラムに従い、複数の需要抑制に関わる機能の処理を提供する機能ごとに相互に通信し、
需要抑制のプログラムを実施することを特徴とするエネルギー需要抑制方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、様々な事業体によってエネルギー需給逼迫時におけるデマンドレスポンス（ＤＲ）を実現するためのサービス連携技術に関わる。
【背景技術】
【０００２】
近年、エネルギー消費における需要の高まりや、エネルギー供給設備の停止などによって、エネルギーの供給不足が懸念されている。その対策として、エネルギーの供給家が需要家に対して需要抑制の依頼や、エネルギー供給設備によるエネルギー供給の依頼を実施し、その行動や抑制量に対してインセンティブを提供するＤＲがある。ＤＲによってエネルギーの供給と需要のバランスを調整することが検討されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１２−６５４０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１では、電力需要を制御するための電力制御装置によって、電力供給側から電力需要側の消費電力の削減要求を実施する技術が開示されている。その際、電力需要側の照明機器の調整においてはブラインドの開閉状態や、空調機器においては設定温度など環境状態を示す環境情報を取得し、削減要求に応じた電力削減量を算出する。ただし、特許文献１では、需要家のエネルギーの消費量の抑制を需要家側の環境状態に合わせて目標値に合わせた抑制量を算出できるが、各拠点の需要家の需要抑制の行動によっては目標値よりもエネルギー抑制量が達成できない場合がある。その対処例としては、エネルギーの需給安定のために、他の拠点の需要家が目標値よりを達成できなかった該当需要家の抑制量の不足分を補てんするなどが考えられるが、抑制量の不足分を補てんするためには、多くの需要家による需要抑制量を集めるなどの予備力を確保するなどが必要となる。
【０００５】
一方、欧米のＤＲにおいては多数の需要家が需要抑制を実施することによって供給側の発電所が電力を発電するのに相当する電力供給の効果を出す仕組みがある。これは、電力会社や電力を取引する市場に対して多数の需要家から集めた需要抑制の電力容量を売買などの仲介をするアグリゲータによって構成される。特許文献１の課題を解決する多くの需要家を集め、需要抑制を取りまとめる仕組みを持ち、１つのアグリゲータが複数の需要家に対して時間帯別料金プランやピーク時の価格を変動させるプランなど、ＤＲを実施するＤＲプログラムにより需要の抑制を図る（本明細書では、プランと同義でDRプログラムという文言を使用する。コンピュータで動作させるプログラムについてはコンピュータプログラムという文言を使用する）。
【０００６】
ただし、１つのアグリゲータが提供するＤＲプログラム数は限られており需要家が希望するＤＲプログラムを提供されていない場合がある。例えば、ＤＲプログラムでは様々な項目の条件によって構成され、時間帯別料金プランなどの料金計算や負荷機器の需要抑制を制御装置による自動制御の需要削減方法など、電力使用計測値などの計測粒度やタイミングなどいくつものＤＲプログラムに関わる機能項目の希望が挙げられる。また、新たなＤＲプログラムをアグリゲータが提供するためには、電力会社から需要抑制の要請を受けること、需要抑制装置を需要家の元に設置できること、デマンドレスポンスに関わる実績値データや需要家データを管理するデータセンタやアプリケーションを保持すること、需要抑制に対するインセンティブを計算し経済的にアグリゲータ自身が事業継続するための収支計算を実施することなど、１つのアグリゲータで多くの業務や設備を保持している必要がある。これは業務コストが肥大化する。
【０００７】
本発明の目的は、エネルギーの供給家が需要家に対して需要抑制の依頼や、エネルギー供給設備によるエネルギー供給の依頼を実施し、その行動や抑制量に対してインセンティブを提供するＤＲにおいて、ＤＲプログラムをアグリゲータが提供しやすくすることにある。
【課題を解決するための手段】
【０００８】
本発明では、ＤＲプログラムに関わる機能項目をサービスとしてアグリゲータが保持するサーバに提供する、もしくは需要抑制のＤＲプログラムを実施するＤＲサービスサーバと、需給バランスを検知し需要抑制の依頼を通知する需要抑制管理サーバと、需要家の負荷機器に対する需要抑制を管理する需要抑制管理装置と、を備えるエネルギー需要抑制システムを提供する。
【０００９】
上記において、ＤＲプログラムの機能項目をＤＲサービスサーバがサービスとして提供し、複数のＤＲサービスサーバによってＤＲプログラムに関わる機能項目のサービスを取得し、新たなＤＲプログラムを組み合わせることで解決する。
【発明の効果】
【００１０】
本発明によって、１つのアグリゲータがＤＲに関わるすべての業務や設備の保持をしなくてよくなり、すでにＤＲプログラムを提供しているアグリゲータにとっては自身の得意とする部分の業務や設備の保持に集中することができる。また、新たにＤＲプログラムを提供するアグリゲータにとっては、ＤＲプログラムに関わる業務の実施や設備の保持をしていなくてもアグリゲータ事業を実現することができる。
【００１１】
これにより、すべてのＤＲプログラムに関する機能の開発をしなくてよくなり、業務コストの低減につながる。また、本発明によって、エネルギーの抑制量を集める業務を実施するアグリゲータだけではなく、ＤＲに関わるサービスのみを提供するサービス提供事業者がＤＲ事業に関わることができ市場の活性化につながる。また、エネルギーの供給と需要のバランスの観点の効果として、需要家の加入増加が見込まれ多くの抑制量が集めることができ、エネルギーの供給と需要のバランスを調整することにつながる、という波及効果も奏する。
【図面の簡単な説明】
【００１２】
【図１】エネルギー需給抑制システム（第一実施例）のシステム構成図である。
【図２】データベースのテーブル構成を示した図である。
【図３】サービス管理テーブルの構成例（第一実施例）を示した図である。
【図４】業務フローを示したシーケンス図である。
【図５】ＤＲプログラムを検索する処理の示したフローチャートである。
【図６】サービスを検索する処理のフローチャートである。
【図７】サービス連携処理のフローチャートである。
【図８】エネルギー需給抑制システム（第二実施例）のシステム構成図である。
【図９】サービス管理テーブルの構成例（第二実施例）を示した図である。
【図１０】サービス連携処理のフローチャートである。
【図１１】サービステーブル（実績管理）の構成例を示した図である。
【発明を実施するための形態】
【００１３】
＜第一の実施形態＞
本発明において想定するＤＲプログラムの業務フローの例を説明する。ＤＲプログラムでは、電力会社は需要が供給量よりも多くなり需給逼迫となる時間帯を予測し、その時間帯に対して事前に需要抑制を依頼することをアグリゲータに通知する。また、アグリゲータは需要家に対して需要抑制となる負荷設備の停止や自家発電設備を稼働させるなどの制御または行動を促すなどの需要抑制を実施する。さらにアグリゲータは、需要家の契約電力量や月間最大電力値などからその抑制時間帯の消費電力量の差を計算し、需要抑制の行動の実績値を取得する。次に需要抑制の実績に対して需要家にインセンティブを渡すことや電気料金からの割引を実施する。ただし、実績値は電力会社との契約などによって算出方法は様々である。
【００１４】
図１は実施例１に関するエネルギー需要抑制システムのシステム構成図である。本構成図では、エネルギーを供給する電力会社１１００、新規にＤＲプログラムを作成し電力の需給逼迫時に需要家から抑制量の取りまとめを実施するαアグリゲータ１２００、既存のＤＲプログラムをすでに提供し需要抑制の依頼時に抑制量を取りまとめるβアグリゲータ１３００、エネルギーを消費する需要家１４００、が事業主体として登場する。各事業者は、それぞれ複数の事業者が存在してもよい。
【００１５】
次に、各事業者が保持する装置とその機能を説明する。電力会社１１００は、電力の需給逼迫時にアグリゲータ１２００、１３００に向けて需要抑制を依頼したり、需要抑制の結果を受け取りその実績を記録したりしておく需要抑制管理サーバ１１０１を保持する。
【００１６】
αアグリゲータ１２００は、サービス連携を実現するＤＲサービスサーバ１２０１を保持する。ここで、サービス連携とは新たなＤＲプログラムを作成することを意味する。
【００１７】
ＤＲサービスサーバ１２０１は、ＤＲプログラムの作成などの処理を実施する演算部１２１０、インターネットなどの外部ネットワーク１６００と接続しデータを授受する通信部１２２０、ＤＲプログラムを実施する際の連携するアグリゲータのサービス一覧を保持するサービス管理機能１２３１とＤＲプログラムを作成する機能１２３２とＤＲプログラムの機能項目ごとのサービスを提供する、もしくは提供されるサービスを連携するＤＲサービス連携機能１２３３とを備える記憶部（メモリ）１２３０、また、ＤＲプログラムに記憶部１２３０に格納された各機能に必要なデータを保持するデータベース（ハードディスク）１２４０を保持する。ここで各機能は、コンピュータプログラムとして記憶部に格納されたものであり、演算部で実行することで各機能を果たす。
【００１８】
βアグリゲータ１３００が保持するＤＲサービスサーバ１３０１はＤＲサービスサーバ１２０１と同様に演算部１３１０、通信部１３２０、記憶部１３３０を保持する。記憶部１３３０には、ＤＲプログラムを実行するための需要家情報を管理する機能１３３１とＤＲプログラムのためのサービスを連携するＤＲサービス連携機能１２３３と同様のＤＲサービス連携機能１３３２が格納されている。ＤＲプログラムに記憶部の各機能に必要なデータを保持するデータベース１３４０を保持する。
【００１９】
需要家１４００においては、工場ならばプレス機など製造設備、ビルや家庭ならばエレベータや空調機器や照明機器やＯＡ機器などの電力を消費する負荷機器１４４０やバッテリーや太陽光発電機器などの電力を提供する自家発電機器１４４１が設置されている。また、ＤＲサービスサーバ１２０１、１３０１からの需要抑制の依頼があると、負荷機器１４４０の使用電力量を削減したり、自家発電機器１４４１から発電を実施し需要家内で消費する電力を電力会社の系統から供給量を減らしたりする調整を実施する需要抑制管理装置１４０１が設置されている。需要抑制管理装置１４０１には、需要抑制時の処理を実施する演算部１４１０と外部ネットワーク１６００や負荷機器１４４０、自家発電設備１４４１と接続してデータの授受を実施する通信部１４２０と負荷機器１４４０や自家発電装置１４４１へ需要抑制時に需要を抑制する制御する処理を実施する機能１４３１と消費量を取得し、アグリゲータに通知する実績取得通知機能１４３２と、負荷機器１４４０、自家発電設備１４４１など設置されている機器の数や空調機器や照明機器などの種別を管理する設備管理機能１４３３を保持する。また、需要家が希望するＤＲプログラムの機能項目をαアグリゲータ１２００やβアグリゲータ１３００にＷｅｂページなどでリクエストするクライアントＰＣなどのＤＲプログラムリスエスト装置１４５０を需要家１４００が保持している。
【００２０】
また、各サーバや機器の通信部が接続しデータを授受できる外部ネットワーク１６００と接続された構成である。
【００２１】
図２にＤＲプログラムの作成、ＤＲプログラムによる需要抑制の実行処理を実現するためのデータを格納しておくためのデータベースの構造を示す。
【００２２】
αアグリゲータ１２００のＤＲサービスサーバ１２０１に設置されたデータベース１２４０では、ＤＲプログラムに関する機能項目をサービスして提供している提供先と提供機能の内容を示すサービス管理テーブル１２４１と、ＤＲプログラムに加入するアグリゲータの情報を示す需要家テーブル１２４２と、アグリゲータとして電力会社へ需要抑制の実績を通知するために、各需要家が実施した需要抑制の実績値を取りまとめる実績管理テーブル１２４３を保持する。βアグリゲータ１３００のＤＲサービスサーバ１３０１に設置されたデータベース１３４０では新たなＤＲプログラムのためのサービスを連携するために、そのＤＲプログラムごとに連携するアグリゲータ名とサービスのアドレスとを保持するサービス連携先テーブル１３４１と、需要家の情報に関するサービス連携をする際の需要家情報を格納しておくサービステーブル(需要家管理)１３４２と、需要家の需要抑制の実績値に関するサービスを連携する場合に実績値情報を格納しておくサービステーブル(実績管理)１３４３とを保持する。上記に示すデータベースのテーブル構成は実施例を説明するための構成であり、ＤＲプログラムにおいて連携するサービスに合わせて必要なデータを格納するためのテーブルが増加したり削減されたりする。
【００２３】
図３にサービス管理テーブル１２４１のテーブル構造を示す。サービス管理テーブル１２４１はＤＲプログラムの機能項目を提供するアグリゲータが提供するサービスの一覧を示したものであり、１レコードごとに提供する１サービスを示している。１レコードにて提供されているサービスは、βアグリゲータ１３００と同様の構成である、他のアグリゲータからもサービスを提供されることを示している。ＤＲプログラムの機能項目に相当するサービスのカテゴリをサービスの種別を示すカラムであるサービスカテゴリＣ１２４１１と、ＤＲプログラムの機能項目ごとの内容を示すサービス種別名Ｃ１２４１２と、サービスを提供する事業者を示すアグリゲータ／サービス提供者名Ｃ１２４１３と、サービスを連携した際に提供するサービスアドレスＣ１２４１４によって構成される。本実施形態においては、サービスを提供するアグリゲータを区別するためにアグリゲータ／サービス提供者名Ｃ１２４１３に、図１のシステム構成ではβアグリゲータと同様の構成であるため省略したアグリゲータＡ、アグリゲータＢ、アグリゲータＣ、θアグリゲータがサービスを提供することを示す記載をしている。
【００２４】
図４にＤＲプログラムをアグリゲータが提供しやすくするための業務フローを示す。この業務フローの一例における前提として、ＤＲにおいて電力会社１１００が電力需給の逼迫を検知し、需要抑制の依頼を実施する。その際、電力会社１１００は多くの需要家１４００に対して多く需要抑制の実績量を集めたいが需要家１４００の電力使用状態や各ＤＲプログラムなどを直接管理することは膨大な数な管理コストが増大する問題があるため、その取り纏めを実施するアグリゲータ１２００、１３００に需要抑制の依頼を実施する。アグリゲータ１２００、１３００は需要家１４００に対してＤＲプログラムを提供するが、１つの需要家１４００はエネルギーを受ける箇所が一箇所であるため、需要抑制の実績量を取り扱えるのは１つのアグリゲータ１２００、１３００としている。これは複数のアグリゲータ１２００、１３００によって需要抑制の実績量を重複して計算することを防ぐことを想定している。
【００２５】
また、本実施例においては、アグリゲータが参入しやすい環境を実現するために、需要家の希望するＤＲプログラムの希望を抽出する方法によってアグリゲータがＤＲプログラムの作成に関する調査などの工数を減らす方法として需要家の希望を受け付ける。需要家が希望するＤＲプログラムの機能項目は例として、料金プラン、実績値の計測方法、負荷機器の需要削減方法、需要抑制の実績値や料金など履歴確認方法である。以降は料金プランとしてはピーク時間帯に需要を削減した実績値分のインセンティブを電気料金から割り引く「ＰＴＲ（Ｐｅｅｋ  Ｔｉｍｅ  Ｒｅｂａｔｅ）」、実績値の計測方法としては需要抑制管理装置による３０分単位の自動計測が実施される「自動計測」、需要削減方法としては需要抑制管理装置によりピーク時のみ負荷機器の電源を自動ＯＦＦにする「自動負荷抑制制御」、履歴確認方法は「Ｗｅｂページ」を希望した場合を示す。
【００２６】
業務フローの初めに需要家１４００は希望するＤＲプログラムがないか、すでにサービスを提供しているβアグリゲータ１３００に問い合わせる。問い合わせ方法は電話やβアグリゲータ１３００が提供するＷｅｂページ等である。βアグリゲータ１３００は提供できるＤＲプログラムにおいて、料金プランとしてピーク時間帯のみ価格が高くなる料金プラン「ＣＰＰ（ＣｒｉｔｉｃａｌＰｅｅｋ  Ｐｒｉｃｅ）」、実績値の計測方法は「自動計測」、需要削減方法は需要家自身が手動で負荷機器の電源を落とす「手動」方式、履歴確認方法は紙ベースで送付する「郵送」であることを通知する（Ｆ１００１）
次に需要家１４００はβアグリゲータから提供されたＤＲプログラムの機能項目において需要削減方法が「自動負荷抑制制御」、履歴確認方法が「Ｗｅｂページ」であり、希望通りではなかったため、ＤＲプログラムリクエスト装置１４５０によって希望するＤＲプログラムの作成をαアグリゲータ１２００へリクエストする(Ｆ１００２)。
【００２７】
リクエストを受けたαアグリゲータが実行するサービスの検索と連携についての処理フローを、図５、図６を用いて説明する。
【００２８】
図５にて初めに需要家が希望するＤＲプログラムの機能項目の料金プラン「ＰＴＲ」、実績値の計測方法「自動計測」、需要削減方法「自動負荷抑制制御」、履歴確認方法「Ｗｅｂページ」としたＤＲプログラムの機能項目をＤＲプログラムリクエスト装置１４５０からＷｅｂのフォームに入力し送信する。送信されたデータをＤＲサービスサーバ１２０１の通信部１２２０が受信し、そのデータを演算部１２１０が記憶部１２３０のＤＲサービス管理機能１２３１に入力し、送信されたデータで受け付ける（Ｓ１４０１）。
【００２９】
次に、ＤＲサービスサーバ１２０１がサービス管理機能１２３１はデータベース１２４０のサービス管理テーブル１２４１からアグリゲータ/サービス提供者名カラムＣ１２４１３に対して「αアグリゲータ１２００」をキーとして検索処理を実施し、自身の提供するＤＲプログラムの機能項目のレコードを取得する（Ｓ１４０２）。
【００３０】
Ｓ１４０１とＳ１４０２で取得したデータの比較を実施し、各ＤＲプログラムの機能項目ごとに一致するかを判断する（Ｓ１４０３）。具体的には希望の料金プランは「ＰＴＲ」でありアグリゲータの提供項目も「ＰＴＲ」であり一致、希望の実績値の計測方法は「自動計測」でありアグリゲータの提供項目は「メール送付」であり一致しない、希望の需要削減方法は「自動負荷抑制制御」でありアグリゲータの提供項目は「自動負荷抑制制御」で一致、希望の履歴確認方法は「Ｗｅｂページ」でありアグリゲータの提供項目は「メール送付」であり一致しない。もし、すべてのＤＲプログラムの機能項目において、需要家の希望とアグリゲータの提供項目が一致する場合は、他のアグリゲータやサービス提供者とのサービス連携を実施する必要がなく、既存のサービスを提供することとなり処理を終了する。
【００３１】
次に、Ｓ１４０３の処理によりαアグリゲータ１２００は、自身が提供するＤＲプログラムの機能項目において料金プランは「ＰＴＲ」、需要削減方法は「自動負荷抑制制御」で希望のＤＲプログラムと一致しているが、実績値の計測方法は、需要抑制管理装置が計測するがその計測値は電子メールで送付する「メール送付」、履歴確認方法がひと月単位で履歴を電子メールで送付する「メール送付」であり、αアグリゲータ１２００は希望のＤＲプログラムに応えられず、一致しない項目（サービスカテゴリ）である「実績値の計測方法」と「履歴確認方法」をリストアップして処理を終了する（Ｓ１４０４）。
【００３２】
図６にてＤＲサービス管理機能１２３２のサービス検索処理フローを説明する。まず、他のアグリゲータが提供するサービスを検索する（Ｓ１５０１）。具体的には、ＤＲプログラムの機能項目である実績値の計測方法「自動計測」、および、履歴確認方法「Ｗｅｂページ」において、代行して実施するサービスとして提供していないか検索する。
【００３３】
Ｓ１４０４でリストアップしたＤＲプログラムの機能項目を検索するために、サービス管理テーブル１２４１からサービスカテゴリのカラムＣ１２４１１とサービス種別のカラムＣ１２４１２に対して「実績値の計測方法」「自動計測」をキーとして検索処理を実施し、他のアグリゲータが提供するＤＲプログラムの機能項目のレコードを取得する。同様に履歴確認方法が「Ｗｅｂページ」であるレコードを取得する。
【００３４】
次にすべてのＤＲプログラムの機能項目のレコードが存在し希望と一致するか判断する（Ｓ１０５２）。一致しない場合は、希望通りのＤＲプログラムを作成できないため、後述のＦ１００５のフローにて需要家へその旨通知し終了する。
【００３５】
一致する場合は、その対象レコードからアグリゲータ/サービス提供者名カラムＣ１２４１３とサービスアドレスＣ１２４１４の値を保持して終了する（Ｓ１５０３）。
【００３６】
次に、図４に戻り、αアグリゲータの処理を説明する。サービス管理機能１２３１にて該当するＤＲプログラムの機能項目である実績値の計測方法が「自動計測」を提供するβアグリゲータ１３００に対してサービスの提供を依頼するサービス問い合わせを実施、同様に履歴確認方法が「Ｗｅｂページ」をサービスとして提供するθアグリゲータに対してサービスを利用する問い合わせを実施する(Ｆ１００３)。
この際、サービスを提供するに当たり、βアグリゲータ１３００やθアグリゲータはαアグリゲータ１２００に対して対価を受け取ること、データの受け渡しタイミングなどを決定する契約を交わし、サービスを提供することに対する返答を実施する。
【００３７】
上記では、サービスを利用する側と提供する側のアグリゲータの構成数が少ない場合を想定しているが、様々なアグリゲータがサービスを提供する環境となった場合に、個別に契約や課金精算処理を実施することは複雑になりかねない。また、サービスを提供するサーバを保持していない場合はサービスを提供できない課題も発生する。そのため，サービスを利用する側と提供する側が直接契約を実施せずに、契約や課金精算処理やサービスを記憶する環境を提供するなどのＤＲプログラムを実施するための補助的な機能を実施するサービス提供取引所を構築した構成を本発明では含めてもよい。
【００３８】
サービス提供取引所では、ネットワーク１６００に接続されたサーバを保持する。サービス提供取引所のサーバは、ＤＲサービスサーバ１３０１のサービスを記憶している記憶部１３３０と同様の構成を保持しており、サービスの提供者がサービスを実施するプログラムをネットワーク１６００経由、もしくは郵送や手渡しによってサービス提供取引所の管理者へ送付し、管理者はそのプログラムをサービス提供取引所のサーバの記憶部に設置する。また、この際、提供されたサービスの情報をサービス管理機能１２３１へ通知しサービス管理機能１２３１がサービス管理テーブル１２４１へレコードを追加する。ただし、この例ではサービス管理テーブル１２４１はαアグリゲータ１２００のＤＲサービスサーバ１２０１が保持するように示したが、サービス提供取引所のサーバがサービス管理機能１２３１やサービス管理テーブル１２４１と同様の機能を保持していてもよい。登録されたサービスはサービスの提供者が示した料金情報を該当レコードに登録する。
【００３９】
契約処理においては、サービス管理機能が、サービスを利用したい利用者から依頼を受信すると上記登録してある料金情報を送信する。その後、利用者が契約を希望した場合、利用者の情報を含めた契約情報をサービス提供取引所のサーバのサービス管理機能がサービス契約テーブルに対して登録を実施する。
【００４０】
以上の処理により、サービスを利用する側と提供する側が直接契約を実施せずに、契約や課金精算処理などのＤＲプログラムに関わるサービス連携のための補助的な機能を実施することでサービス連携のための環境を構築できる。
【００４１】
ＤＲプログラムの作成フローとして、次に、αアグリゲータ１２００は、需要家１４００から受け取った希望されるＤＲプログラムの機能項目のリクエストに合うように、ＤＲプログラムを料金プランとしては「ＰＴＲ」、実績値の計測方法としては需要抑制管理装置による３０分単位の自動計測が実施される「自動計測」、需要削減方法としては需要抑制管理装置によりピーク時のみ負荷機器の電源を自動ＯＦＦにし抑制する「自動負荷抑制制御」、履歴確認方法は「Ｗｅｂページ」とするＤＲプログラム自動作成機能１２３２によってＤＲプログラムを作成する（Ｆ１００４）。
【００４２】
また、ＤＲプログラム自動作成機能１２３２によって作成したＤＲプログラムを需要家１４００に対して内容を通知し希望通りであるかの判断を依頼する（Ｆ１００５）。需要家１４００はＤＲプログラムが希望通りであるかを判断し、該当ＤＲプログラムにて加入の契約を実施する（Ｆ１００６）。以上の業務フローにおいて、ＤＲプログラムの作成は完了する。
【００４３】
ＤＲプログラムにおける需要抑制の依頼が電力会社１１００の需要抑制管理サーバから発せられた場合のサービス連携の業務フローを説明する。需要抑制の依頼がありＤＲプログラムを実行する場合は、需要家１４００に対して需要抑制を依頼する旨と料金プランが「ＰＴＲ」でありピーク時間帯とその時間帯の電力価格について電話、メール、Ｗｅｂなどにて通知する。次にＤＲプログラムにおけるαアグリゲータ１２００が保持していない機能を、協力するβアグリゲータ１３００、θアグリゲータへサービスの提供を依頼しＤＲプログラムの実施依頼をする。その後、サービスを実施した結果をＤＲプログラム実施有無の返答として受け取る。（Ｆ１００７）。
【００４４】
図７を用いて、具体的なＦ１００７のサービス連携の実行における処理フローを説明する。実現手段としては、Ｗｅｂを経由してサービスの連携を実現するＷｅｂサービスや各アグリゲータ間の取り決めた通信プロトコルなどを想定する。αアグリゲータ１２００のＤＲサービスサーバ１２１０のＤＲサービス連携機能は需要抑制に関わる機能の処理を実施するため、サービス連携先に前記で示したサービス連携の契約に基づきサービス連携を実施する。具体的には各ＤＲプログラムの機能項目の処理を依頼する（Ｓ１６００）。
【００４５】
需要抑制の依頼においては、ＤＲサービス連携機能１２３３が需要家１４００の需要抑制管理装置１４０１に対してピーク時のみ負荷機器の電源を自動ＯＦＦにし抑制する需要削減方法の「自動負荷抑制制御」の信号を送信する。需要抑制管理装置１４０１は需要抑制制御機能１４３１にて負荷機器１４４０の電源をＯＦＦにし、需要を抑制する。上記処理においてはαアグリゲータ１２００が自身の機能として提供できるＤＲプログラムの機能項目であるため、サービス連携は実施しない。
【００４６】
次に、需要家の需要抑制の実績を管理するために、αアグリゲータ１２００はＤＲプログラムの機能項目である実績値の計測を実施するが、自身の保持する機能では実現できないため、サービス連携先であるβアグリゲータ１３００のＤＲサービス連携機能１３３２が公開するサービスのアドレス「ｈｔｔｐ：／／ｗｗｗ．ｄｒｓｅｒｖ．ｘｘ／ｔｏ＿ｍｅａｓｕｒｅｍｅｎｔ．ｓｒｖ」へ需要家１４００のＩＤと日時をキーとして指定し、該当する実績値を取得するように要求する（Ｓ１６０１）。
【００４７】
次にβアグリゲータ１３００のＤＲサービス連携機能１３３２が、引数のＩＤで指定された該当する需要家の実績値の計測を、需要抑制管理装置１４０１の実績取得通知機能１４３２を呼び出すことよって実現する（Ｓ１６０２）この際、需要家の抑制管理装置１４０１はβアグリゲータ１３００が需要家１４００に対して設置し管理していることを想定している。次に、ＤＲサービス連携機能１３３２は、サービス連携の契約時に取り決めてある実績値の通知先であるαアグリゲータ１２００のサービスアドレス「ｍｅａｓｕｒｅｍｅｎｔ＿ｒｅｃｅｉｖｅ＠ｘｘｘｘ．ｃｏｍ」をサービス連携先テーブル１３４１から取得し、そのアドレスに対して実績値の値を指定されたフォーマットに変換し、メールで送付する（Ｓ１６０３）。サービスの処理が完了すると完了したメッセージをＤＲサービス連携機能１２３３へ通知する。
【００４８】
需要家１４００が需要抑制の履歴を確認するための方法として、「Ｗｅｂページ」を希望しており、αアグリゲータ１２００は自身の保持する機能では実現できないため、サービス連携先であるθアグリゲータのＤＲサービス連携機能が公開するＷｅｂページによるサービスのアドレス「ｈｔｔｐ：／／ｗｗｗ．ｂａｇｒｉ−ｓｅｒｖ．ｘｘ／ｈｉｓｔｏｒｙ．ｓｒｖ」へ需要家１４００のＩＤと先にＳ１６０３で取得した実績値をメッセージとして渡たす（Ｓ１６１１）。
【００４９】
次にθアグリゲータのＤＲサービス連携機能が、メッセージのキーであるＩＤと該当する需要家の実績値の計測値をデータベース１５４０のＷｅｂ作成テーブル１５４２に格納し、Ｗｅｂページにて表示できるように、Ｗｅｂページから参照できるＷｅｂページ作成プログラムを設定する（Ｓ１６１２）。このＷｅｂページ作成プログラムは事前に設定されており、実績値をデータベースへ格納する処理のみでもよい。次に需要家１４００がＷｅｂページにて履歴の実績値に参照できるようにするためのアドレスとアカウント情報をサービス連携先テーブル１５４１からαアグリゲータ１２００のアドレスを取得し通知する（Ｓ１６１３）。この際、θアグリゲータが需要家１４００へ直接通知してもよい。そうでない場合はαアグリゲータ１２００が需要家１４００へアドレスとアカウント情報を通知する。上記と同様にＤＲプログラムを需要家と契約する時点において事前に通知しておいてもよい。サービスの処理が完了すると完了したメッセージをＤＲサービス連携機能１２３３へ通知する。
【００５０】
その後、αアグリゲータ１２００は実績値のＤＲプログラムの料金プラン「ＰＴＲ」に合わせた精算処理を実施する。
【００５１】
ＤＲサービス連携機能１２３３が各連携したサービスの処理が完了したメッセージが基にサービス連携処理フローにおいてすべての処理が完了したかを判断する（Ｓ１６２０）。
【００５２】
ＤＲプログラムの機能項目の処理が完了していなければ、サービス連携先のＤＲサービス連携機能に対して、サービスの処理状態の確認の問い合わせを実施する（Ｓ１６２１）。以上により、ＤＲプログラムにおける処理を完了する。
【００５３】
＜第二の実施形態＞
第一の実施形態において、ＤＲプログラムに関わる機能をサービスとして提供する事業体はアグリゲータとしていたが、第二の実施形態では、ＤＲプログラムを実施しない事業体において、関わる機能の一部もしくはすべてをサービスとしてアグリゲータへ提供するサービス提供事業者を含めた構成例を示す。これにより、本発明がアグリゲータのみによって構成されることよりも多くの事業体がＤＲ事業に関わることができ市場の活性化につながり、より多くのアグリゲータがＤＲプログラムを提供することにより多くの需要抑制量を集めることができる。
【００５４】
図８を用いて第二の実施形態のシステム構成を示す。図８では図１に示した第一の実施形態のシステム構成に、ＤＲプログラムに関わる機能の一部もしくはすべてをサービスとしてアグリゲータへ提供するサービス提供事業者とその関連するサーバに関わる構成である。
【００５５】
サービス提供事業者１５００においては、ＤＲサービスサーバ１５０１を保持しており、構成はＤＲサービスサーバ１２０１と同様の構成であり演算部１５１０と通信部１５２０と記憶部１５３０とデータベース１５４０を備える。ただし、ＤＲサービスサーバ１５０１はＤＲサービスサーバ１２０１と異なる部分として需要抑制管理サーバ１１０１からの需要抑制の依頼を受けたり需要家１４００と契約を結び需要抑制の抑制に対してインセンティブを払ったりするなどのＤＲプログラムを実施しないため区別している。サービス提供事業者１５００のＤＲサービスサーバ１５０１に設置されたデータベース１５４０では、サービス連携先テーブル１３４１と同様のサービス連携先テーブル１５４１と、履歴確認のサービスを提供する場合は、実績値の履歴を表示するためのＷｅｂページ、Ｗｅｂ作成のためのデータを格納するテーブル１５４２などのＤＲプログラムに関わる機能を提供するためのテーブルを保持する。また、ＤＲプログラムに関わる機能を提供する処理については、βアグリゲータ１３００のＤＲサービスサーバ１３０１が保持しているＤＲサービス連携機能１３３２と同様である。
【００５６】
また、サービス提供事業者１５００はＤＲプログラムを実施するために開発された機能を提供する事業者でなくてもよい。例えば、第一の実施形態ではＤＲプログラムにおいては、アグリゲータは需要抑制のための実績値計測機能や需要抑制制御機能のサービスを提供していると記載したが、アグリゲータが需要抑制に対するインセンティブを計算する部分はＤＲプログラムで実施し、その後、金融機関などが該当するサービス提供事業者１５００は、計算されたインセンティブを支払う際にアグリゲータが管理していない需要家の口座情報の管理を実施する機能サービスとして提供し、インセンティブの振込機能を実施してもよい。上記のようにサービス連携機能１５３１においてはＤＲプログラムに関わる機能として、異種システムの機能をサービスとして連携できるようになる。
【００５７】
需要抑制の依頼があり、ＤＲプログラムにおいて実績値の計測し、その実績値を基に料金プラン「ＰＴＲ」によるインセンティブ計算を実施し、インセンティブ支払を実施する例における実現手段を示す。
【００５８】
業務フローである需要抑制の依頼があり、ＤＲプログラムを実施するＦ１００７において、αアグリゲータ１２００のＤＲサービス連携機能１２３３はＳ１６０３にて取得した需要家情報である需要家のＩＤと実績値をメールで受信し、実績値から時間帯ごとのインセンティブを計算する。例えば、需要家との契約条件において、「１３：００−１４：００」において１ｋｗあたりの需要抑制において１００円インセンティブを支払うと取り決められている場合に合わせて料金計算を実施する。
【００５９】
その後、ＤＲサービス連携機能１２３３は、サービス提供事業者１５００のサービス連携機能１５３１によって提供されるインセンティブ振込サービスに対して、需要家ＩＤとインセンティブ額を送信する。サービス連携機能１５３１のインセンティブ振込サービスは需要家ＩＤから管理している該当需要家の口座番号を取得する。さらに該当需要家のエネルギーの該当精算対象月の利用料金を検索して取得し、その利用料金からインセンティブの割引を実施した金額を先の口座へ振り込みを実施する。
【００６０】
＜第三の実施形態＞
第一の実施形態と第二の実施形態においては、ＤＲプログラムを実施する際にどの時間帯やＤＲプログラムの状態においても同一の機能を実施する例を示していたが、第三の実施形態では、ＤＲプログラムを実施する時間帯や状態によって、実施するプログラム機能を変化させる構成を示す。これにより、サービスを提供する側の処理負荷を平準化することや、需要家が時間帯ごとに異なる機能を求める場合にニーズに沿うことや、電力供給において安定化を求める電力会社などにおいて電力需給状態に合わせて変化させることができる。
【００６１】
第三の実施形態におけるシステム構成においては、第一の実施形態もしくは第二の実施形態のいずれかと同様である。以降、第一の実施形態、第二の実施形態と異なる部分についてのみ示す。
【００６２】
図９に、時間帯やステータスによってＤＲプログラムを動的に変更させて実行するためのテーブル構成を示す。図９は図３のテーブル構成１２４１の代わりのテーブル構成である。サービスの１レコードごとにサービスを提供する時間帯を示す時間帯とサービスを提供する状態を示すステータスＣ１２４１５のカラムを追加で保持している。
【００６３】
図１０に、時間帯やステータスによってＤＲプログラムを動的に変更させて実行するサービス連携処理フローを示す。図１０では図７において動的に処理を変更させる処理を追加した処理フローとなる。それ以外の処理においては、第一の実施形態、もしくは第二の実施形態と同様である。ＤＲプログラムを動的に変更させて実行する処理フローとしてＤＲプログラムの機能を実行するＳ１６００において、他のサービス連携のための処理と同様に分岐して処理を実行する。
【００６４】
まず、時間帯によって処理を変更するために、処理を実施する時間を、サービスを提供するサーバのシステム時間から取得する（Ｓ１６３１）。ここではαアグリゲータ１２００のＤＲサービスサーバ１２１０が提供するシステム時間を取得した例として「１３：１０」であった場合を示す。
【００６５】
次に、ＤＲサービスサーバ１２０１のサービス管理機能１２３１はＤＲプログラムの需要削減方法にて指定されている「自動負荷抑制制御」であるレコードのサービスの時間帯ごとのステータスを取得するために、データベース１２４０のサービス管理テーブル１２４１からサービスカテゴリＣ１２４１１のカラムに対して、「需要削減サービス」を、また、サービス種別名Ｃ１２４１２のカラムに対して「自動負荷抑制制御」をキーとし、サービスを提供する時間帯を示す時間帯とサービスを提供する状態を示すステータスＣ１２４１５のカラムの検索処理を実施し、「１３：００−１５：００／強制ＯＦＦ、０：００−１３：００、１５：００−２４：００／事前設定」のデータを取得する（Ｓ１６３２）。
【００６６】
次に、取得した時間帯に合わせて、ＤＲプログラムの自動負荷抑制制御における動的に処理を変更させる。実施例としてはサービスのステータスに合わせてサービスを提供するアドレスに対して、その値を渡してここでは、取得した時間「１３：１０」から、該当する実施するサービスのステータスは「強制ＯＦＦ」であり、ＤＲプログラムを実施するαアグリゲータ１２００のＤＲサービスサーバ１２１０のＤＲサービス連携機能１２３３は自動負荷抑制制御のサービスに対して、強制ＯＦＦのステータス値をメッセージとして送信する（Ｓ１６３３）。
その後、自動負荷抑制制御のサービスが需要家１４４０の機器に対して強制ＯＦＦによる処理を実施する。以降は、第一の実施形態で示したＳ１６２０の処理、Ｓ１６２１の処理と同様であり変更はない。
【００６７】
＜第四の実施形態＞
第一から第三の実施形態においては、アグリゲータもしくはサービス提供事業者が他のアグリゲータへＤＲプログラムに関わる機能をサービスとして提供する際に、自身が実施するサービスと提供するサービスにおいては同じ機能である記載をした。ただし、サービスとして提供する側において、提供するサービスおよびサービスで利用するデータは個人情報の観点やビジネス上の提供したくない情報を含む場合があり、サービスを提供できない場合が想定される。この場合、ＤＲプログラムに関わる機能が提供されない場合は本発明の目的が達成できない。
【００６８】
第四の実施形態では、上記の状況においては、サービスを提供する側が提供するサービス及びサービスで利用するデータについて、自身が提供する場合と比較して粒度を変化させることで提供できるようにする。実施例としてβアグリゲータが計測した実績値をβアグリゲータ自身がＤＲプログラムにおいては秒単位を示す「ｓｅｃ」のサンプリング周期を利用するが、サービスとして提供する場合においては分単位を示す「ｍｉｎ」のデータを提供することとする。これにより、サービスの提供を受ける場合のデータの粒度が下がり、βアグリゲータが提供するデータとして提供したくない情報でなくなったと想定する。
【００６９】
実施例におけるシステム構成は、第一の実施形態から第三の実施形態のいずれかと同様であり、サービス及びサービスで利用するデータについての粒度を変化させるＤＲサービス連携機能１３３２の内部処理が異なる。
【００７０】
まず、内部処理にて利用するデータを管理するデータベース１３４０のサービステーブル（実績管理）１３４３の例を示す。
【００７１】
図１１では、βアグリゲータ１３００が保持しているＤＲサービスサーバ１３０１に設置されたデータベース１３４０のサービステーブル（実績管理）１３４３の構成を示している。サービステーブル（実績管理）１３４３では、需要家が利用したエネルギーを管理するテーブルであり、負荷機器１４４０が消費したエネルギーもしくは自家発設備１４４１が生産したエネルギーの合計値を実績値取得通知機能１４３２がメッセージとしてネットワーク１６００を経由してβアグリゲータ１３００へ送信し、需要家管理機能１３３１がメッセージを受信し、メッセージを需要家ごとに時系列の実績値として登録する。サービステーブル（実績管理）１３４３では、１つの需要家ごとのある時間単位の実績値を１レコードとして格納する。テーブルは需要家をユニークに特定するための需要家ＩＤ（Ｃ１３４３１）と、計測した実績値の時間周期を示すサンプリング周期Ｃ１３４３２、計測した時間を示すサンプリングタイムＣ１３４３３、実績値を示すサンプリング値Ｃ１３４３４のカラムで構成される。
【００７２】
サービスの提供する際にデータの粒度を変更されせるＤＲサービス連携機能１３３２の内部処理について示す。内部処理では、第一の実施形態に示した、αアグリゲータが需要家の需要抑制の実績を取得する処理Ｓ１６０２の際に、βアグリゲータ１３００のＤＲサービス連携機能１３３２が、取得要求を受けた際に、需要抑制管理装置１４０１の実績取得通知機能１４３２から実績値を取得してサービステーブル（実績管理）１３４３に格納し、サンプリング周期「ｓｅｃ」から「ｍｉｎ」へ粒度を変化させる処理を実施する。取得要求の条件が需要家ＩＤ「１０００」、日時「２０１２／１０／１０＿１０：００：００」から「２０１２／１０／１０＿１１：００：００」に対する実績値の粒度の変化としては、サービステーブル（実績管理）１３４３に対して需要家ＩＤ（Ｃ１３４３１）「１０００」とサンプリングタイムＣ１３４３３「２０１２／１０／１０＿１０：００：００」から「２０１２／１０／１０＿１１：００：００」をキーとして実績値のデータを取得する。第一の実施形態では取得したデータをメール送信Ｓ１６０３の処理に渡していたが、本実施形態では、サンプリング周期が「ｍｉｎ」であるため、分ごとのデータを平均値として演算する。２０１２／１０／１０＿１０：００であるならば、２０１２／１０／１０＿１０：００：００のサンプリング値「３０」、２０１２／１０／１０＿１０：００：０１の「３０」、２０１２／１０／１０＿１０：００：０２の「３２」と１分間のサンプリング値の演算により平均値を算出する。その値を指定された時間分繰り返し、需要家ＩＤ「１０００」、サンプリング周期「１ｍｉｎ」、サンプリングタイム「２０１２／１０／１０＿１０：００」、サンプリング値「３２」、需要家ＩＤ「１０００」、サンプリング周期「１ｍｉｎ」、サンプリングタイム「２０１２／１０／１０＿１０：０１」、サンプリング値「３３」のように実績値を算出し、Ｓ１６０３の処理へ渡す。ここでは平均値を求めるような演算としたが、中央値や最大／最小値などの演算方法は提供するサービスによって決定される。
【００７３】
最後に実施例で想定した条件に発明が限定されないための記述をする。
【００７４】
本発明において電力会社は、発電する事業者、送電する事業者、配電する事業者などの事業者をまとめて記載しているが、事業を実施する機能ごとに事業体が分割されていてもよい。その際に需要抑制を依頼する場合はいずれかの事業体が依頼することを想定している。また、電力会社から購入する電力を抑制するために自家発電設備を実施例にて記載しているが、特定規模発電事業者（ＰＰＳ）などの発電事業体による発電量は電力会社の系統から購入する電力に対する需要抑制量と見なし、需要抑制のための削減制御サービスとしてサービス連携先の一つに加えてもよい。
また、実施例では、新たなＤＲプログラムの作成する事業体はαアグリゲータと呼称して実施しているが、αアグリゲータがすでにＤＲプログラムを提供しているβアグリゲータにサービスを提供してもよい。さらに、実施形態では１つのアグリゲータがＤＲプログラムを作成し、実施するように示したが、複数のアグリゲータが協力しサービスを連携することによって新たなＤＲプログラムを作成し複数のアグリゲータが実施してもよい。また、ＤＲプログラムの作成を実施する事業体と、作成したＤＲプログラムに合わせて需要抑制時の業務を実施する事業体は、別事業体である別のアグリゲータに実施を依頼して実施してもよい。さらに、ＤＲプログラムの作成する機能は１つのαアグリゲータが保持しているように記載したが、αアグリゲータだけではなく、βアグリゲータやサービス提供事業者など、ＤＲプログラムを作成する機能が保持されているＤＲサービスサーバであればいずれでもよい。これにより需要家はＤＲプログラムの作成依頼をいずれのアグリゲータやサービス提供事業者に問い合わせを実施してもよいため、複数アグリゲータから対象のアグリゲータを選択する手間が軽減される。
また、本実施例においては、エネルギーの種別を電力としたが、ガスや水道など供給量と需要量の関係があるエネルギー種別においても適用可能である。
また、実施例では需要家の情報を、ＤＲプログラムを実施するアグリゲータと直接契約がないアグリゲータやサービス提供事業者に提供しているが、個人情報管理の観点により需要家からの第三者への開示の合意が得られない場合には、需要家情報をサービス連携先のデータベースに格納しないようする。例として、Ｗｅｂページにて履歴を表示するプログラムにならば、サービス提供事業者のサービスに対して、Ｗｅｂページの表示依頼があるたびに、実績値を保持している直性契約のあるアグリゲータへ問い合わせ、Ｗｅｂページのプログラムにて表示するなどの対処をする。
また、本実施例においては、アグリゲータが参入しやすい環境を実現するために、需要家の希望するＤＲプログラムの希望を抽出する方法によってアグリゲータがＤＲプログラムの作成に関する調査などの工数を減らすことをしているが、需要家からのＤＲプログラムに関する希望を抽出せずに、サービス連携によるアグリゲータが提供したいＤＲプログラムを提供してもよい。
【符号の説明】
【００７５】
１１００  電力会社
１１０１  需要抑制管理サーバ
１２００  αアグリゲータ
１２０１、１３０１、１５０１  ＤＲサービスサーバ
１２１０、１３１０、１４１０  演算部
１２２０、１３２０、１４２０  通信部
１２３０、１３３０、１４３０  記憶部
１２３１  サービス管理機能
１２３２  ＤＲプログラム自動作成機能
１２３３、１３３２、１５３１  ＤＲサービス連携機能
１２４０、１３４０、１５４０  データベース
１２４１  サービス管理テーブル
１２４２  需要家管理テーブル
１２４３  実績管理テーブル
１３００  βアグリゲータ
１３３１  需要家管理機能
１３４１、１５４１  サービス連携先テーブル
１３４２  サービステーブル（需要家管理）
１３４３  サービステーブル（実績管理）
１４００  需要家
１４０１  需要抑制管理装置
１４３１  需要抑制制御機能
１４３２  実績取得通知機能
１４３３  設備管理機能
１４４０  負荷機器
１４４１  自家発電設備
１４５０  ＤＲプログラムリクエスト装置
１５００  サービス提供事業者
１５４２  Ｗｅｂ作成テーブル
１６００  外部ネットワーク
【図１】
2014060879.tif 000003
【図２】
2014060879.tif 000004
【図３】
2014060879.tif 000005
【図４】
2014060879.tif 000006
【図５】
2014060879.tif 000007
【図６】
2014060879.tif 000008
【図７】
2014060879.tif 000009
【図８】
2014060879.tif 000010
【図９】
2014060879.tif 000011
【図１０】
2014060879.tif 000012
【図１１】
2014060879.tif 000013