(57)【要約】【課題】デマンドレスポンスイベントの間にユーザのリソース消費量を削減させることが可能な方法等を提供する。【解決手段】方法は、ユーザに関連する１つ以上のユーザインタレストを決定し、複数のマーチャントから複数のオファーを受けることを有する。夫々のオファーは、品物又はサービスを購入するための購入インセンティブと、品物又はサービスに関連するインタレストのカテゴリとを含む。方法は、ユーザインタレストをインタレストのカテゴリと照合して、ユーザとオファーとの間の一致を識別し、デマンドレスポンスイベントに関連する期間を決定し、ユーザのためのクーポンを生成することを有する。クーポンは、オファーと、決定された期間の間に指定された物理的な位置でそのクーポンを引き換える実行インセンティブを提供する実行ボーナスとを含む。方法は、指定された物理的な位置での引き換えのためにユーザにクーポンを提供することを有する。【選択図】図４
2016143412.tif 000002
【特許請求の範囲】
【請求項１】
デマンドレスポンスイベントの間に引き換えられるようにクーポンをユーザと照合する方法であって、
ユーザに関連する１つ以上のユーザインタレストを決定し、
複数のマーチャントからの複数のオファーであり、夫々が、品物又はサービスを購入するための購入インセンティブと、前記品物又はサービスに関連するインタレストのカテゴリとを含む前記複数のオファーを受け、
前記ユーザに関連する前記１つ以上のユーザインタレストを、前記品物又はサービスに関連する前記インタレストのカテゴリと照合して、前記ユーザと前記複数のオファーのうちのあるオファーとの間の一致を識別し、
デマンドレスポンスイベントに関連する期間を決定し、
前記ユーザのためのクーポンであり、前記オファーと、指定された物理的な位置で前記デマンドレスポンスイベントに関連する前記期間の間に当該クーポンを引き換えるための実行インセンティブを提供する実行ボーナスとを含む前記クーポンを生成し、
前記指定された物理的な位置での引き換えのために前記ユーザに前記クーポンを提供し、前記ユーザによる前記指定された物理的な位置での前記クーポンの引き換えは、前記ユーザに関連する居住場所でのリソース消費の減少を引き起こす
ことを有する方法。
【請求項２】
前記クーポンは、前記デマンドレスポンスイベントに関連する前記期間の間に前記クーポンを引き換えることに同意するためのサインアップインセンティブを提供するサインアップボーナスを更に含む、
請求項１に記載の方法。
【請求項３】
前記ユーザが前記デマンドレスポンスイベントに関連する前記期間の間に前記クーポンを引き換えることに同意するとのインジケーションをユーザから受け、
前記ユーザが前記デマンドレスポンスイベントに関連する前記期間の間に前記クーポンを引き換えることに同意したことを、前記オファーに関連するマーチャントに知らせる
ことを更に有する請求項２に記載の方法。
【請求項４】
前記ユーザに関連する前記１つ以上のユーザインタレストを決定するように前記ユーザから前記１つ以上のユーザインタレストを受ける
ことを更に有する請求項１に記載の方法。
【請求項５】
前記ユーザに関連するユーザ位置を決定し、
前記複数のマーチャントに関連する店舗位置を決定し、
前記ユーザ位置からの距離の閾範囲内にある店舗位置を持ったマーチャントのサブセットを識別する
ことを更に有する請求項１に記載の方法。
【請求項６】
前記複数のオファーを、前記ユーザ位置からの距離の前記閾範囲内にある店舗位置を持った前記マーチャントのサブセットからのフィルタをかけられたオファーに狭めるように、前記複数のマーチャントからの前記複数のオファーにフィルタをかけることを更に有し、
前記ユーザと前記複数のオファーのうちのあるオファーとの間の一致を識別することは、前記ユーザと前記フィルタをかけられたオファーのうちのあるオファーとの間の一致を識別することを有し、
前記クーポンは、短縮された期間内に引き換えるための緊急インセンティブを提供する緊急ボーナスを更に含む、
請求項５に記載の方法。
【請求項７】
前記ユーザに関連するアドレス、買い物の好み、及びクーポンのタイプへの関心のうちの１つ以上に関する情報を前記ユーザから受ける
ことを更に有する請求項１に記載の方法。
【請求項８】
動作を実行するよう又は該動作の実行を制御するようプロセッサによって実行可能なコンピュータ可読命令を記憶した非一時的なコンピュータ可読媒体であって、
前記動作は、
ユーザに関連する１つ以上のユーザインタレストを決定し、
複数のマーチャントからの複数のオファーであり、夫々が、品物又はサービスを購入するための購入インセンティブと、前記品物又はサービスに関連するインタレストのカテゴリとを含む前記複数のオファーを受け、
前記ユーザに関連する前記１つ以上のユーザインタレストを、前記品物又はサービスに関連する前記インタレストのカテゴリと照合して、前記ユーザと前記複数のオファーのうちのあるオファーとの間の一致を識別し、
デマンドレスポンスイベントに関連する期間を決定し、
前記ユーザのためのクーポンであり、前記オファーと、指定された物理的な位置で前記デマンドレスポンスイベントに関連する前記期間の間に当該クーポンを引き換えるための実行インセンティブを提供する実行ボーナスとを含む前記クーポンを生成し、
前記指定された物理的な位置での引き換えのために前記ユーザに前記クーポンを提供し、前記ユーザによる前記指定された物理的な位置での前記クーポンの引き換えは、前記ユーザに関連する居住場所でのリソース消費の減少を引き起こす
ことを有する、非一時的なコンピュータ可読媒体。
【請求項９】
前記クーポンは、前記デマンドレスポンスイベントに関連する前記期間の間に前記クーポンを引き換えることに同意するためのサインアップインセンティブを提供するサインアップボーナスを更に含む、
請求項８に記載の非一時的なコンピュータ可読媒体。
【請求項１０】
デマンドレスポンスイベントに基づきリソースを入札する方法であって、
デマンドレスポンスイベントに関連する目標費用及び目標リソース削減を決定し、
マーチャントからの複数のオファーを受け、
複数のユーザの夫々が、前記マーチャントからの複数のオファーのうちの１つ以上を含むクーポンを、指定された物理的な位置で前記デマンドレスポンスイベントに関連する期間の間に引き換える可能性を決定し、
前記目標費用、前記目標リソース削減、及び前記複数のユーザの夫々が前記クーポンを引き換える前記可能性に基づき、前記複数のユーザのうちの一部へのクーポンの組を生成し提供し、前記複数のユーザのうちの１以上のユーザによる前記指定された物理的な位置での前記クーポンの組に含まれる１以上のクーポンの引き換えは、前記複数のユーザのうちの前記１以上のユーザに関連する１つ以上の居住位置でのリソース消費の減少を引き起こし、
前記クーポンを受ける前記複数のユーザのうちの前記一部に基づき、前記リソースの総削減量を推定し、
前記総削減量に基づき前記リソースについての提供価格及び量を提供することによって、１日前市場で前記リソースを入札する
ことを有する方法。
【請求項１１】
前記リソースの前記総削減量に基づき利益を最大にするように供給曲線のパラメータを決定することを更に有し、
前記リソースについての前記提供価格及び前記量は、前記利益に基づく、
請求項１０に記載の方法。
【請求項１２】
前記利益を決定することは、
前記１日前市場から前記リソースを購入する価格に、提示されたＤＲ入札についての精算需要を乗じたものを含むリソースクレジットを決定し、
前記リソースクレジットからデマンドレスポンスインセンティブのための価格を減じる
ことを有する、請求項１１に記載の方法。
【請求項１３】
前記利益を決定することは、前記リソースについての前記提供価格及び前記量を決定するように供給曲線を生成することに基づく、
請求項１２に記載の方法。
【請求項１４】
前記利益を決定することは、前記１日前市場での１日前価格予測と、実時間市場での実時間価格予測とを、夫々累積分布関数により、確率論的関数としてモデリングすることを有する、
請求項１２に記載の方法。
【請求項１５】
夫々のクーポンは、前記指定された物理的な位置で前記デマンドレスポンスイベントに関連する前記期間の間に当該クーポンを引き換えるための実行インセンティブを提供する実行ボーナス及びオファーを含む、
請求項１０に記載の方法。
【請求項１６】
新しい情報に基づき前記目標費用及び前記目標リソース削減を更新し、
前記更新された目標費用、前記更新された目標リソース削減、及び前記複数のユーザの夫々が前記クーポンを引き換える前記可能性に基づき、前記複数のユーザのうちの更なる一部への更なるクーポンの組を生成し提供し、
前記更新された目標費用及び前記更新された目標リソース削減を提供することによって、時間前市場で前記リソースを入札する
ことを更に有する請求項１０に記載の方法。
【請求項１７】
前記複数のユーザの夫々が前記クーポンを前記指定された物理的な位置で前記デマンドレスポンスイベントに関連する前記期間の間に引き換える前記可能性を決定することは、前記ユーザの夫々によって指定されるインタレストに基づく、
請求項１０に記載の方法。
【請求項１８】
前記クーポンを受ける前記複数のユーザのうちの前記一部に基づき前記リソースの前記総削減量を推定することは、前記複数のユーザのうちの前記一部に含まれる夫々のユーザが前記クーポンを引き換える可能性に、前記複数のユーザのうちの前記一部に含まれる夫々のユーザについての負荷低減を乗じたものの和を決定することを含む、
請求項１０に記載の方法。
【請求項１９】
前記負荷低減を決定することは、前記ユーザの夫々の居住位置でのアプライアンスのタイプと、前記クーポンを受ける前記複数のユーザの夫々の居住位置での前記アプライアンスのタイプに関連するリソース消費とを決定することに基づく、
請求項１８に記載の方法。
【請求項２０】
前記複数のユーザのうちの前記一部に含まれる夫々のユーザが前記クーポンを引き換える可能性、及び前記複数のユーザのうちの前記一部に含まれる夫々のユーザについての前記負荷低減は、独立変数である、
請求項１８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
ここで議論される実施形態は、住居のデマンドレスポンスにおけるクーポンの活用に関する。
【背景技術】
【０００２】
公共事業体は、ある高負荷期間の間のリソース使用量の削減を奨励して、より大きな需要を満足するように又は製造費用を最小限にするように公共事業体の能力を高める。例えば、夏季の数ヶ月に、ピークエネルギ使用量は、真夏日の夕方近くに起こり得る。公共事業体は、夕方近くの顧客の家庭におけるエネルギ使用量を減らすように顧客にインセンティブを提供することがある。それに応じて、顧客は、皿洗いをすることを避け、家庭内の空調設備を弱め、あるいは、別なふうにしてエネルギ使用量を削減し得る。単一の住居は、エネルギ消費において大きな差を生じさせるほどにはエネルギを消費しないかもしれないので、公共事業体は、多くの顧客にインセンティブを提供してよく、それらの顧客に関連する家庭でのリソース削減の寄せ集めは、デマンドレスポンスイベントのために消費量を削減するのに十分であり得る。このようにして、公共事業体は、ピークエネルギ利用の間のエネルギ需要を満足する自身の能力を高め、且つ／あるいは、エネルギ需要を満足するための更なるエネルギを生成又は購入することを回避してよい。
【０００３】
ピーク又は高負荷期間の間のリソース使用量の削減は、デマンドレスポンス（ＤＲ；demand  response）と一般的に呼ばれることがある。指定された期間の間のリソース使用量の削減は、ＤＲイベントと呼ばれ得る。ＤＲイベントは、一般的に、公共事業体が高い需要を期待して、顧客にリソース使用量を削減又は低減するよう頼む場合に、起こる。幾つかのＤＲシステムはＤＲアグリゲータを含む。ＤＲアグリゲータは、公共事業体と顧客との間のやり取りをとりなしてよい。ＤＲアグリゲータは、一般に、顧客と協調してＤＲイベントを実施するように、公共事業体との同意を有する。
【０００４】
ここで請求される対象は、上述のような欠点を解消したり、あるいは、上述のような環境でのみ動作したりする実施形態に制限されない。むしろ、この背景技術は、ここで記載される実施形態が実施され得る一例としての技術分野を説明するために与えられているにすぎない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の実施形態は、デマンドレスポンスイベントの間にユーザにリソース消費量を削減させるインセンティブをユーザに提供することができる方法及び非一時的なコンピュータ可読媒体を対象とする。
【課題を解決するための手段】
【０００６】
本発明の実施形態は、デマンドレスポンスイベントの間に引き換えられるようにクーポンをユーザと照合する方法を提供する。方法は、ユーザに関連する１つ以上のユーザインタレストを決定し、複数のマーチャントからの複数のオファーであり、夫々が、品物又はサービスを購入するための購入インセンティブと、前記品物又はサービスに関連するインタレストのカテゴリとを含む前記複数のオファーを受け、前記ユーザに関連する前記１つ以上のユーザインタレストを、前記品物又はサービスに関連する前記インタレストのカテゴリと照合して、前記ユーザと前記複数のオファーのうちのあるオファーとの間の一致を識別し、デマンドレスポンスイベントに関連する期間を決定し、前記ユーザのためのクーポンであり、前記オファーと、指定された物理的な位置で前記デマンドレスポンスイベントに関連する前記期間の間に当該クーポンを引き換えるための実行インセンティブを提供する実行ボーナスとを含む前記クーポンを生成し、前記指定された物理的な位置での引き換えのために前記ユーザに前記クーポンを提供し、前記ユーザによる前記指定された物理的な位置での前記クーポンの引き換えは、前記ユーザに関連する居住場所でのリソース消費の減少を引き起こすことを有する。
【０００７】
本発明の他の実施形態は、動作を実行するよう又は該動作の実行を制御するようプロセッサによって実行可能なコンピュータ可読命令を記憶した非一時的なコンピュータ可読媒体を提供する。前記動作は、ユーザに関連する１つ以上のユーザインタレストを決定し、複数のマーチャントからの複数のオファーであり、夫々が、品物又はサービスを購入するための購入インセンティブと、前記品物又はサービスに関連するインタレストのカテゴリとを含む前記複数のオファーを受け、前記ユーザに関連する前記１つ以上のユーザインタレストを、前記品物又はサービスに関連する前記インタレストのカテゴリと照合して、前記ユーザと前記複数のオファーのうちのあるオファーとの間の一致を識別し、デマンドレスポンスイベントに関連する期間を決定し、前記ユーザのためのクーポンであり、前記オファーと、指定された物理的な位置で前記デマンドレスポンスイベントに関連する前記期間の間に当該クーポンを引き換えるための実行インセンティブを提供する実行ボーナスとを含む前記クーポンを生成し、前記指定された物理的な位置での引き換えのために前記ユーザに前記クーポンを提供し、前記ユーザによる前記指定された物理的な位置での前記クーポンの引き換えは、前記ユーザに関連する居住場所でのリソース消費の減少を引き起こすことを有する。
【０００８】
本発明の更なる実施形態は、デマンドレスポンスイベントに基づきリソースを入札する方法を提供する。方法は、デマンドレスポンスイベントに関連する目標費用及び目標リソース削減を決定し、マーチャントからの複数のオファーを受け、複数のユーザの夫々が、前記マーチャントからの複数のオファーのうちの１つ以上を含むクーポンを、指定された物理的な位置で前記デマンドレスポンスイベントに関連する期間の間に引き換える可能性を決定し、前記目標費用、前記目標リソース削減、及び前記複数のユーザの夫々が前記クーポンを引き換える前記可能性に基づき、前記複数のユーザのうちの一部へのクーポンの組を生成し提供し、前記複数のユーザのうちの１以上のユーザによる前記指定された物理的な位置での前記クーポンの組に含まれる１以上のクーポンの引き換えは、前記複数のユーザのうちの前記１以上のユーザに関連する１つ以上の居住位置でのリソース消費の減少を引き起こし、前記クーポンを受ける前記複数のユーザのうちの前記一部に基づき、前記リソースの総削減量を推定し、前記総削減量に基づき前記リソースについての提供価格及び量を提供することによって、１日前市場で前記リソースを入札することを有する。
【発明の効果】
【０００９】
本発明の実施形態によれば、デマンドレスポンスイベントの間にユーザにリソース消費量を削減させるインセンティブをユーザに提供することが可能となる。
【図面の簡単な説明】
【００１０】
例となる実施形態は、添付の図面の使用を通じて、更なる特定及び詳細をもって記載及び説明される。
【００１１】
【図１】デマンドレスポンスイベントの間に引き換えられるようにクーポンをユーザと照合するよう構成されるデマンドレスポンスシステムの例のブロック図である。
【図２】デマンドレスポンスイベントの間に引き換えられるようにクーポンをユーザと照合する装置の例を表す。
【図３】クーポン及び種々のタイプのインセンティブを含むグラフィカルユーザインタフェースの例を表す。
【図４】デマンドレスポンスイベントの間に引き換えられるようにクーポンをユーザと照合する方法の例のフローチャートを表す。
【図５】デマンドレスポンスイベントに基づきリソースを入札する方法の例のフローチャートを表す。
【発明を実施するための形態】
【００１２】
［要約］
実施形態の態様に従って、デマンドレスポンスイベントの間に引き換えられるようにクーポンをユーザと照合する方法は、ユーザに関連する１つ以上のユーザインタレストを決定することを有してよい。方法は、複数のマーチャントからの複数のオファーを受けることを更に有してよく、夫々のオファーは、品物又はサービスを購入するための購入インセンティブと、前記品物又はサービスに関連するインタレストのカテゴリとを含む。方法は、前記ユーザに関連する前記１つ以上のユーザインタレストを、前記品物又はサービスに関連する前記インタレストのカテゴリと照合して、前記ユーザと前記複数のオファーのうちのあるオファーとの間の一致を識別することを更に有してよい。方法は、デマンドレスポンスイベントに関連する期間を決定することを更に有してよい。方法は、前記ユーザのためのクーポンを生成することを更に有してよく、該クーポンは、前記オファーと、指定された物理的な位置で前記デマンドレスポンスイベントに関連する前記期間の間に当該クーポンを引き換えるための実行インセンティブを提供する実行ボーナスとを含む。方法は、前記指定された物理的な位置での引き換えのために前記ユーザに前記クーポンを提供することを更に有してよく、前記ユーザによる前記指定された物理的な位置での前記クーポンの引き換えは、前記ユーザに関連する居住場所でのリソース消費の減少を引き起こす。
【００１３】
実施形態の目的及び利点は、特許請求の範囲で特定に指し示されている要素、特徴、及び組み合わせによって少なくとも実現及び達成される。前述の概要及び以下の詳細な説明はいずれも、例示及び説明であり、請求される発明の限定でない点が理解されるべきである。
【００１４】
［実施形態の説明］
従来の住居のデマンドレスポンス（ＤＲ）プログラムは、ユーザに、彼らの住居内でのリソース消費量を削減するようインセンティブを提供する。かかるプログラムは、ユーザが、そのインセンティブを、リソース消費量を削減する不便さに対して不十分且つ価値がないと考え得るために、順守率が低いことがある。加えて、どのユーザがプログラムに従うのか及びいつ彼らがプログラムに従うのかを予測することは、困難であり得る。結果として、どの程度リソース消費量が削減され得るのかを予測することは、困難であり得る。リソース消費量が予測不可能である場合に、公共事業体及び／又はＤＲアグリゲータは、誤っていることによるペナルティのために、予測に基づき行動を起こすことを望まないことがあり得る。
【００１５】
そのような及び他のシステムの欠点は、公共事業体及びマーチャントの双方が、ユーザにリソース消費量を削減させるインセンティブをユーザに提供するＤＲシステムによって解消され得る。ここで記載されるＤＲシステムは、コンピューティング装置を有してよい。例えば、ＤＲシステムは、パーソナルコンピュータ、ラップトップ、タブレットコンピュータ、携帯電話機、サーバ、又はあらゆるプロセッサベースのコンピューティング装置を有してもよい。ＤＲシステムはメモリ及びプロセッサ装置を有してよい。プロセッサ装置は、例えば、図４及び図５を参照して夫々以下で記載される方法４００及び５００の１つ以上の動作又はステップのような、ここで記載される１つ以上の動作を実行するように又はその実行を制御するようにプログラムされてよい。ＤＲシステムの１つ以上の例となる実施形態は、以下で記載される。
【００１６】
ＤＲシステムは、ユーザに関連するユーザインタレストを決定するＤＲアプリケーションを有してよい。例えば、ＤＲアプリケーションは、ユーザが映画に関心があると決定してよい。ＤＲアプリケーションは、マーチャントからのオファーを受けてよく、夫々のオファーは、品物又はサービスを購入する購入インセンティブと、その品物又はサービスに関連するインタレストのカテゴリとを含む。例えば、オファーは、衣料品店での商品の２０％オフ、映画チケットの５ドルオフ、などを含んでよい。ＤＲアプリケーションは、ユーザインタレストを品物又はサービスに関連するインタレストのカテゴリと照合することによって、オファーの中の１つとユーザとの間の一致を識別してよい。例えば、ＤＲアプリケーションは、ユーザが映画に関心があることから、映画チケットの５ドルオフのオファーとユーザとの間の一致を識別してよい。
【００１７】
ＤＲアプリケーションは、デマンドレスポンスイベントに関連する期間を決定してよい。その期間は動的であって、例えば、週、日、又は現在時間から数分といった、短い期間を有してよい。ＤＲアプリケーションは、ユーザのためのクーポンを生成してよく、クーポンは、オファーと、デマンドレスポンスイベントに関連する期間の間に指定された物理的な位置でクーポンを引き換えるための実行インセンティブを提供する実行ボーナスとを含む。この例では、指定された物理的な場所は、一致するオファーを提供したマーチャントに関連する映画館であってよい。クーポンは、例えば、マーチャントによって提供される映画チケットの５ドルオフのオファーと、デマンドレスポンスイベントに関連する期間の間にクーポンを引き換える代わりに公共事業体によって提供される５ドル（例えば、割引の一助）とを含んでよい。結果として、ＤＲアプリケーションは、住居のリソース消費量を低減するようユーザに奨励するために、複数の財源を有利に使用する。
【００１８】
クーポンは、デマンドレスポンスイベントに関連する期間の間にクーポンを引き換えることに同意するためのサインアップインセンティブを提供するサインアップボーナスを更に含んでよい。ユーザがクーポンを引き換えることに同意する場合に、ＤＲアプリケーションは、（例えば、オファーを公表したマーチャントサーバを通じて）マーチャントに知らせてよい。このことは、マーチャントがユーザの事前通告を受け取ることを有利にもたらすことができる。加えて、デマンドレスポンスイベントに関連する期間は、マーチャントの店舗における遅れた期間と重なってよい。このことは、その遅れた期間の間のマーチャントについてのチケット及び／又は割引販売の増大をもたらすことができる。
【００１９】
ＤＲアプリケーションは、複数のユーザのためのクーポンを生成してよい。ＤＲアプリケーションは、ユーザがデマンドレスポンスイベントに関連する期間の間に指定された物理的な位置でクーポンを引き換える可能性に基づき、ユーザの一部のためにクーポンを生成してよい。ＤＲアプリケーションは、クーポンを受けるユーザの一部に基づき、リソースの総削減量を推定してよい。例えば、ＤＲアプリケーションは、ユーザの一部に含まれる夫々のユーザがクーポンを引き換える可能性に、ユーザの一部に含まれる夫々のユーザについての負荷低減を乗じたものの和に基づき、リソースの総削減量を推定してよい。ＤＲアプリケーションは、リソースの総削減量に基づきリソースについての提供価格及び量を提供することによって１日前市場（day-ahead  market）でリソースを入札するために、リソースの総削減量を使用してよい。幾つかの実施形態において、ＤＲアプリケーションは、利益を決定するためにリソースの総削減量を使用してよく、ＤＲアプリケーションは、リソースについての提供価格及び量を決定するために利益を使用してよい。ＤＲアプリケーションは、目標費用及び目標リソース削減を更新してよい。例えば、ＤＲアプリケーションは、更なる量のリソースが需要を満足するのに必要とされると決定することがある。ＤＲアプリケーションは、更なるクーポンの組を発行して、時間前市場（hour-ahead  market）で更なるリソースを入札してよい。
【００２０】
幾つかの実施形態は、添付の図面を参照して説明される。ここでの実質的にあらゆる複数及び／又は単数語の使用に関しても、当業者は、文脈及び／又は用途に適切であるように、複数を単数に及び／又は単数を複数に変換してよい。様々な単数／複数置換は、明りょうさのために、ここで明示的に説明され得る。
【００２１】
図１は、ここで記載される少なくとも幾つかの実施形態に従って配置される、デマンドレスポンスイベントの間に引き換えられるようにクーポンをユーザと照合するよう構成されるＤＲシステム１００の例のブロック図である。ＤＲシステム１００は、ＤＲサーバ１０１、マーチャントサーバ１１５、ユーザ装置１２０、及びサードパーティサーバ１３４を有してよく、これらはネットワーク１０５を介して互いと通信してよい。ＤＲシステム１００の１つ以上の例となる実施は、以下で記載される。
【００２２】
ネットワーク１０５は、１つ以上のワイドエリアネットワーク（ＷＡＮ）及び／又はローカルエリアネットワーク（ＬＡＮ）を有してよい。それらのネットワークは、ＤＲサーバ１０１、マーチャントサーバ１１５、ユーザ装置１２０、及びサードパーティサーバ１３４の間の通信を可能にしてよい。幾つかの実施形態において、ネットワーク１０５は、複数のＷＡＮ及び／又はＬＡＮの間の論理的及び物理的な接続によって形成されたグローバルなインターネットワークを含むインターネットを含む。代替的に、又は追加的に、ネットワーク１０５は、１つ以上のセルラー無線周波数（ＲＦ）ネットワーク、ＧＰＳネットワーク、並びに／又は、例えば、しかし制限なしに、８０２．ｘｘネットワーク、ブルートゥースアクセスポイント、無線アクセスポイント、若しくはインターネットプロトコル（ＩＰ）ベースネットワークのような、１つ以上の有線及び／若しくは無線ネットワークを含んでよい。ネットワーク１０５は、１つのタイプのネットワークが他のタイプのネットワークとインタフェース接続することを可能にするサーバを更に有してよい。
【００２３】
ＤＲサーバ１０１は、公共事業体及び／又はＤＲアグリゲータに関連してよい。公共事業体は、リソースの生成、伝送及び／又は分配に関与するあらゆるＬＳＥ（load  serving  entity）を有してもよい。公共事業体は、公営又は私営であってよい。公共事業体の幾つかの例は、電力会社、エネルギ協同組合、及び水道会社を含んでよいが、これらに限られない。公共事業体は、ＤＲイベントを識別し、例えば、インセンティブのタイプ、ＤＲイベントに関連する期間、目標費用、及び目標リソースのような、ＤＲイベントのための１つ以上の項目を設定するよう構成されてよい。
【００２４】
ＤＲアグリゲータは、ＤＲイベントの実施を統合するように、公共事業体、マーチャント、及びユーザ装置１２０に関連するユーザの間の媒介の役目を務めてよい。特に、ＤＲアグリゲータは、ユーザの住居でのリソースの総削減量がＤＲイベントの全体的なエネルギ使用量の削減を満足するのに十分であるように、ＤＲイベントを統合してよい。幾つかの実施形態において、公共事業体によって提供されるインセンティブは、ＤＲアグリゲータによって受け取られてよい。ＤＲアグリゲータは、次いで、ＤＲイベントへの参加の見返りに、そのインセンティブのいくらかをユーザに提供してよい。ＤＲアグリゲータは、ＤＲイベントの実施をユーザ装置１２０を通じてユーザと協調させてよい。幾つかの実施形態において、アグリゲータは、公共事業体の部分であってよい。
【００２５】
ＤＲサーバ１０１は、アプリケーション及び／又はハードウェア（例えば、ラックマウント式のサーバコンピュータ、ブレードサーバコンピュータ、及び／又は他のコンピュータハードウェア）を有してよい。ＤＲサーバ１０１は、メモリ及びプロセッサ装置を有してよい。プロセッサ装置は、例えば、図４及び図５を参照して夫々以下で記載される方法４００及び５００の１つ以上の動作又はステップのような、ここで記載される１つ以上の動作を実行するように又はその実行を制御するようにプログラムされてよい。
【００２６】
ＤＲサーバ１０１は、デマンドレスポンスイベントの間に引き換えられるようにクーポンをユーザと照合するよう構成されるＤＲアプリケーション１１１を有してよい。例えば、ＤＲアプリケーション１１１は、ユーザ装置１２０からユーザに関連するユーザインタレストを受けてよい。ＤＲアプリケーション１１１は、マーチャントサーバ１１５からマーチャントに関連するオファーを受けてよい。オファーは、品物又はサービスを購入するための購入インセンティブと、その品物又はサービスに関連するインタレストの１つ以上のカテゴリとを含んでよい。ＤＲアプリケーション１１１は、ユーザインタレストのうちの１つが品物又はサービスに関連するインタレストのカテゴリのうちの１つと一致することに基づき、ユーザとオファーのうちの１つとの間の一致を識別してよい。
【００２７】
ＤＲアプリケーション１１１はまた、サードパーティサーバ１３４によって管理される市場でリソースを入札するよう構成されてよい。ＤＲアプリケーション１１１は、ＤＲアプリケーション１１１が新しい情報を受けるたびに入札してよい。ＤＲイベントまでの時間が近くなるにつれて、ＤＲアプリケーション１１１は、１日前市場での入札から時間前市場での入札へ切り替えてよい。
【００２８】
マーチャントサーバ１１５は、ユーザにそれらのマーチャントの物理的な店舗位置を訪れるよう働きかけるようにＤＲサーバ１０１にオファーを提供するよう構成されるアプリケーション及び／又はハードウェア（例えば、ラックマウント式のサーバコンピュータ、ブレードサーバコンピュータ、及び／又は他のコンピュータハードウェア）を有してよい。マーチャントサーバ１１５は、夫々がメモリ及びプロセッサ装置を有してよい。プロセッサ装置は、ここで記載される１つ以上の動作を実行するよう又はその実行を制御するようプログラムされてよい。例えば、マーチャントサーバ１１５は、品物又はサービスを購入するためのユーザのインセンティブと、品物又はサービスに関連するインタレストのカテゴリと、サインアップボーナスと、ＤＲサーバ１０１が如何にしてユーザをオファーと照合するのかを決定するために使用される追加の入札情報とを含むオファー情報をＤＲサーバ１０１へ提供するようプログラムされてよい。
【００２９】
サードパーティサーバ１３４は、サードパーティによって管理されてよい。サードパーティは、ＤＲシステム１００においてリソースの交換を制御又は管理するエンティティを有してよい。サードパーティサーバ１３４は、リソースが住居間で適切に割り当てられることを確かにし、リソースの価格がそれらの住居及び／又は分配チャネル（例えば、１つ以上の変電所、分配網、配管、ポンプ、タンク、又はリソースが公共事業体と住居との間で輸送され得るためのあらゆる他のコンポーネント）について設定されることを可能にし、リソースのやり取りを市場に提供してよい。公共事業体が電気を住居に供給する幾つかの実施形態において、サードパーティサーバ１３４は、例えば、独立系運用機関（ＩＳＯ；independent  system  operator）又は地域送電機関（ＲＴＯ；regional  transmission  organization）を有してよい。
【００３０】
サードパーティサーバ１３４は、分配チャネルでのリソースの供給及び需要に関連する情報を受け、計算し、且つ／あるいは、公表するよう構成されるアプリケーション及び／又はハードウェア（例えば、ラックマウント式のサーバコンピュータ、ブレードサーバコンピュータ、及び／又は他のコンピュータハードウェア）を有してよい。情報は、連続的に、周期的に、ランダムに、疑似ランダムに、又はオンデマンドで受け取られ、計算され、且つ／あるいは、公表されてよい。サードパーティサーバ１３４は、次いで、経済データを計算し、該経済データを分配チャネルに関連付けて公表してよい。
【００３１】
幾つかの実施形態において、サードパーティサーバ１３４は、ネットワーク１０５を介してアクセス可能なウェブサイトをホスティングするよう構成されてよい。サードパーティサーバ１３４は、ＤＲサーバ１０１を介したＤＲアプリケーション１１１によるウェブサイトへのアクセスを提供してよい。ＤＲアプリケーション１１１は、然るべく、ＤＲサーバ１０１を介してウェブサイトへアクセスし、且つ／あるいは、そのウェブサイトとインタフェース接続してよい。ウェブサイトは、ウェブサイトにアクセスするＤＲアプリケーション１１１へユーザインタフェースを提供してよい。特に、経済データは、ウェブサイトを介してアクセス可能であってよい。追加的に、又は代替的に、サードパーティサーバ１３４は、経済データをＤＲサーバ１０１へ連続的に、周期的に、ランダムに、疑似ランダムに、又はオンデマンドで送ってよい。
【００３２】
ユーザ装置１２０は、例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、携帯電話機、パーソナルデジタルアシスタント（ＰＤＡ）、モバイル型電子メール装置、携帯型ゲーム機、携帯型音楽プレイヤー、ウェラブル装置、又はネットワーク１０５にアクセスすることができる他の電子機器などの、パーソナルコンピューティング装置を有してよい。夫々のパーソナルコンピューティング装置は、メモリ及びプロセッサを有する。幾つかの実施形態において、ユーザ装置１２０は、夫々がプロセッサベースのコンピューティング装置を有してよい。
【００３３】
ユーザ装置１２０は、クーポンアプリケーション１２１を有してよい。幾つかの実施形態において、クーポンアプリケーション１２１は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）又は特定用途向け集積回路（ＡＳＩＣ）を含むハードウェアを用いて実装されてよい。幾つかの他の実施形態において、クーポンアプリケーション１２１は、ハードウェア及びソフトウェアの組み合わせにより実装されてよい。
【００３４】
クーポンアプリケーション１２１は、ＤＲアプリケーション１１１からグラフィカルデータを受け、そのグラフィカルデータを、ユーザ装置１２０に付随するディスプレイ上に表示するよう構成されてよい。例えば、ＤＲアプリケーション１１１は、ユーザが登録情報を提供するためのフィールドを含むユーザインタフェースを表示するグラフィカルデータを送信してよい。登録情報は、そのユーザ及びユーザインタレストについての情報を特定することを含んでよい。例えば、ユーザは、ユーザ名及びパスワードを選択し、インタレストのリストを提供してよい。インタレストの例は、例えば、スポーツ、ファッション、政治、アート、音楽、映画、などのような比較的広いインタレストや、例えば、サッカー（又はフットボール）、アメリカンフットボール、水泳、又は他のスポーツ、男性ものの衣服、女性ものの衣服、フォーマルウェア、又はファッションの他のタイプ若しくはサブカテゴリ、コメディ、アクション映画、ドラマ、独立系フィルム、又は他の映画ジャンル、などを含む上記の特定のタイプ若しくはサブカテゴリのような比較的狭いインタレストや、例えば、特定のスポーツチーム若しくはレベル（例えば、大学対プロ）、特定のファッションデザイナー、特定の映画サブジャンル、スタジオ、監督、及び／又は俳優／女優、などのようなより狭いインタレストを含む。クーポンアプリケーション１２１はまた、クーポンを含むユーザインタフェースを生成するためのグラフィカルデータをＤＲアプリケーション１１１から受けるよう構成されてよい。クーポンは、バーコード又はＱＲコード（登録商標）のような、機械が読み取れるコードを含んでよく、それにより、ユーザは、引き換えのためにマーチャントにクーポンを提示することができる。代替的に、ユーザは、クーポンのハードコピーを印刷し、そのハードコピー（機械が読み取れるコードを含む。）を引き換えのためにマーチャントに提示してよい。マーチャントは、機械が読み取れるコードをスキャンして、クーポンに含まれるインセンティブの価値を決定してよい。
【００３５】
幾つかの実施形態において、クーポンアプリケーション１２１は、部分的にユーザ装置１２０において且つ部分的にＤＲサーバ１０１においてＤＲアプリケーション１１１の部分として記憶され得るシンクライアントアプリケーションとして部分的に機能を果たしてよい。幾つかの実施形態において、ユーザは、例えば、ブラウザを介してＤＲアプリケーション１１１にアクセスすることによって、クーポンアプリケーション１２１ではなくＤＲアプリケーション１１１にアクセスする。
【００３６】
図２は、ここで記載される少なくとも幾つかの実施形態に従って配置される、デマンドレスポンスイベントの間に引き換えられるようにクーポンをユーザと照合する装置２００の例を表す。図２の装置２００は、図１を参照して上述されたＤＲシステム１００によって使用されるハードウェアの例であってよい。装置２００は、図４及び図５を参照して夫々以下で記載される方法４００及び５００の１つ以上のブロックを実行するようにプログラムされている特別目的のプロセッサベースのコンピューティング装置を有してよい。
【００３７】
装置２００は、プロセッサ装置２２５及びメモリ２２７を有してよい。プロセッサ装置２２５は、算術論理演算ユニット、マイクロプロセッサ、汎用コントローラ、又はここで記載される動作を実行する又はその実行を制御する何らかの他のプロセッサ若しくはプロセッサアレイを有してよい。プロセッサ装置２２５はデータ信号を処理し、複数命令セットコンピュータ（ＣＩＳＣ）アーキテクチャ、縮小命令セットコンピュータ（ＲＩＳＣ）アーキテクチャ、又は命令セットの組み合わせを実装するアーキテクチャを含む様々なコンピューティングアーキテクチャを有してよい。図２は単一のプロセッサ装置２２５を表すが、装置２００は複数のプロセッサ装置２２５を有してよい。他のプロセッサ、オペレーティングシステム、及び物理的構成が可能であってよい。
【００３８】
メモリ２２７は、プロセッサ装置２２５によって実行されるか又はそこで動作し得る命令又はデータを記憶する。命令又はデータは、ここで記載される動作を実行するように又はその実行を制御するようにプロセッサ装置２２５によって実行され得るプログラミングコードを有してよい。メモリ２２７は、動的ランダムアクセスメモリ（ＤＲＡＭ）装置、静的ランダムアクセスメモリ（ＳＲＡＭ）装置、フラッシュメモリ、又は何らかの他のメモリ装置を有してよい。幾つかの実施形態において、メモリ２２７は、ハードディスクドライブ、フロッピー（登録商標）ディスクドライブ、コンパクトディスクＲＯＭ（ＣＤ−ＲＯＭ）装置、ＤＶＤ−ＲＯＭ装置、ＤＶＤ−ＲＡＭ装置、ＤＶＤ−ＲＷ装置、フラッシュメモリ装置、又はより永続的に情報を記憶するための何らかの他の大容量ストレージを含む不揮発性メモリ又は同様の永久ストレージ及び媒体を更に有する。
【００３９】
図示される実施形態で、メモリ２２７は、図１のＤＲアプリケーション１１１及びシステムデータ２１２のうちの１つ以上を記憶してよい。幾つかの実施形態において、ＤＲアプリケーション１１１は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）又は特定用途向け集積回路（ＡＳＩＣ）を含むハードウェアにより実装されてよい。幾つかの他の実施形態において、ＤＲアプリケーション１１１は、ハードウェア及びソフトウェアの組み合わせにより実装されてよい。
【００４０】
ＤＲアプリケーション１１１は、登録モジュール２０２、ＤＲモジュール２０４、クーポンモジュール２０６、ユーザインタフェースモジュール２０８、並びに、測定及び検証モジュール２１０を有してよい。モジュール２０２、２０４、２０６、２０８及び２１０は、１つの装置２００に記憶されているものとして表されているが、モジュール２０２、２０４、２０６、２０８及び２１０は、例えば、分散型データシステムにおいて、異なる装置に記憶されてよい。
【００４１】
システムデータ２１２は、その機能を提供するように装置２００によって使用されるデータを含んでよい。例えば、システムデータ２１２は、ユーザ情報、マーチャント情報、及びＤＲ情報のうちの１つ以上を含んでよい。ユーザ情報は、ユーザ名、パスワード、ユーザインタレスト、ユーザに関連するアドレス、買い物の好み、クーポンのタイプへの関心、居住施設にあるアプライアンスのタイプ、ユーザに関連するリソース消費履歴、及び行動履歴（例えば、いつユーザがクーポンを引き換えたか、何割のクーポンが引き換えられたか、及びインセンティブの価値に関する情報）を含んでよい。マーチャント情報は、マーチャントによって提供されているオファー、どのオファーが入札の間に選択されるか、どのオファーが引き換えられたクーポンの部分であるのかを含んでよい。ＤＲ情報は、ＤＲイベントに関連する期間及び入札情報（例えば、供給曲線、利益モデル、１日前市場についての予測、及び実時間市場についての予測）を含んでよい。
【００４２】
ＤＲアプリケーション１１１の様々なモジュール２０２、２０４、２０６、２０８及び２１０は、これより、より詳細に記載される。
【００４３】
登録モジュール２０２は、概して、ユーザを登録するよう構成されてよい。例えば、登録モジュール２０２は、ユーザインタフェースモジュール２０８に、ユーザがユーザ名、パスワード、ユーザインタレスト、ユーザに関連するアドレス、買い物の好み、クーポンのタイプへの関心、居住施設にあるアプライアンスのタイプ、ユーザに関連するリソース消費履歴、及び行動履歴を提供するためのフィールドを持ったユーザインタフェースを生成するように指示してよい。ユーザインタレストは、ユーザが行うのを楽しむアクティビティ（例えば、サッカー）、ユーザが関心を持っているトピック（例えば、コンテンポラリーアート）、及びユーザが好む対象（例えば、ダークチョコレート）を含んでよい。ユーザインタレストは、大まか（例えば、お茶）又は具体的（例えば、中国の浙江省で採れた高級緑茶）であってよい。
【００４４】
居住施設にあるアプライアンスのタイプは、例えば、ＤＲモジュール２０４を参照して以下で更に詳細に論じられるようにＭＩＳＯ（midcontinent  ISO）に従ってプロダクト及びタイプに分けられるアプライアンスを含んでよい。行動履歴は、いつユーザがクーポンを引き換えたか、何割のクーポンが引き換えられたか、及びインセンティブの価値に関する情報を含んでよい。登録モジュール２０２は、ユーザからユーザ名、パスワード、及びユーザインタレストを受け、情報を含むユーザについてのユーザプロファイルを生成してよい。
【００４５】
幾つかの実施形態において、登録モジュール２０２は、ユーザインタレストを決定するために他のソースから情報を受けてよい。例えば、登録モジュール２０２は、ユーザインタフェースモジュール２０８に、ユーザがソーシャルネットワークのログイン情報を入力するためのオプションを生成するように指示してよい。登録モジュール２０２は、ソーシャルネットワーク、ソーシャルネットワーク上のアクティビティ、などに関連するユーザプロファイルからユーザインタレストを決定してよい。
【００４６】
登録モジュール２０２は、ＤＲプログラムのためにユーザを登録してよい。ＤＲプログラムは、ユーザがユーザの住居でリソース消費を削減するのと引き換えにユーザにインセンティブを提供することを有してよい。例えば、リソースが水である場合に、ユーザは、ＤＲイベントの間に水消費量を低減することに同意してよい。特に、このことは、ＤＲイベントの間にユーザが自動スプリンクラーシステムを停止させたり、皿洗いをすること又は食器洗浄機を稼働することを止めたり、シャワーを浴びない、などのことを意味してよい。ユーザがユーザの住居に留まる代わりにクーポンを引き換えるために店舗にいる場合にユーザがリソースを消費する可能性は低くなるので、ユーザがクーポンを受けることに応答してＤＲイベントの間にリソース消費量を削減することは、ユーザにとってより容易であり得る。結果として、幾つかの実施形態において、ユーザは、ＤＲイベントの間にリソースを消費しない。これは、そのようなことが、ユーザが店舗にいる結果として当然に起こり得るからである。
【００４７】
ＤＲプログラムの部分として、登録モジュール２０２は、ユーザのためのロイヤルティプログラムを生成してよい。ロイヤルティプログラムは、そのロイヤルティプログラムに参加するマーチャントに関連する店舗でユーザが引き換えることができる還元ポイントを含んでよい。例えば、１００還元ポイントは５０ドルに交換されてよく、あるいは、何らかの他の数の還元ポイントは、何らかの他のドル価値、店内クレジット、又は他の価値に交換されてよい。
【００４８】
ＤＲモジュール２０４は、概して、ＤＲイベントを決定し、クーポンと一致するユーザを特定し、クーポンを受けるユーザに基づきリソースの総削減量を推定し、利益を決定し、リソースを入札するよう構成されてよい。それらのステップは、クーポンモジュール２０６及び／又はユーザインタフェースモジュール２０８から追加データを受けた後に反復的に繰り返されてよい。
【００４９】
ＤＲモジュール２０４は、分配チャネルに存在する需給バランスを利用するＤＲイベントを決定するよう構成されてよい。例えば、ＤＲイベントは、実時間価格でのリソースの購入を回避するようにリソースを抑えるよう構成されてよい（例えば、地域別限界価格（ＬＭＧ；locational  marginal  pricing））。代替的に、ＤＲモジュール２０４は、実時間価格で販売され得る超過分を生成するようにリソースを抑えるよう構成されてよい。
【００５０】
ＤＲイベントに関連する情報は、デマンドレスポンスイベントに関連する期間、目標リソース削減及び目標費用を含んでよい。ＤＲモジュール２０４は、デマンドレスポンスイベントに関連する期間を決定するよう構成されてよい。ＤＲイベントに関連する期間は、連続的であっても、あるいは、インターバルを含んでもよい。ＤＲモジュール２０４は、ＤＲイベントの１週間前、１日前、数分前、などに、ＤＲイベントに関連する期間を決定してよい。幾つかの実施形態において、ＤＲモジュール２０４は、マーチャントからオファーを受け、クーポンを受けるべきユーザを特定し、クーポンを受けるユーザに基づきリソースの総削減量を推定し、リソースを入札し、更新された情報を受け、プロセスを繰り返す反復プロセスを、ＤＲイベントに関連する期間が現れるまで行う。
【００５１】
例えば、ＤＲイベントに関連する期間の１週間前に、ＤＲモジュール２０４は、マーチャントからのオファーを受けてよい。ＤＲイベントに関連する期間の３日前に、クーポンモジュール２０６は、ユーザにクーポンを発行してよい。ＤＲイベントに関連する期間の前日の午後１２時に、ＤＲモジュール２０４は、１日前市場でリソースを入札してよい。ＤＲモジュール２０４及びクーポンモジュール２０６は前のステップを繰り返してよく、ＤＲモジュール２０４は、ＤＲイベントに関連する期間の前日の午後４時まで、更新された情報によりリソースを入札し続けてよい。ＤＲイベントに関連する期間の１時間前に、ＤＲモジュール２０４は、実時間市場でリソースを入札してよい。ＤＲモジュール２０４は、ＤＲイベントが起こるまで、実時間市場で、更新された情報によりリソースを入札し続けてよい。１日前市場及び実時間市場の例は、ＰＪＭ、ＩＳＯニューイングランド（ＩＳＯ−ＮＥ）及びニューヨーク独立系統運用機関（ＮＹＩＳＯ）を含んでよい。
【００５２】
ＤＲモジュール２０４は、目標リソース削減を決定するよう構成されてよい。目標リソース削減は、ＤＲイベントの間に起こるべきリソースの削減の推定量を含んでよい。ＤＲモジュール２０４は、サードパーティサーバ１３４からのリソース経済データに基づき目標リソース削減を決定してよい。例えば、ＤＲモジュール２０４は、ウェブサイトから経済データを読み出してよく、あるいは、サードパーティサーバ１３４からの通信を受けてよい。図示される実施形態では、ＤＲモジュール２０４は、１日前需要、１日前ＬＭＰ、及び実時間ＬＭＰを読み出してよい。代替的に、幾つかの実施形態において、ＤＲモジュール２０４は、経済データを受信及び／又は計算する他のエンティティから経済データを受信又はアクセスしてよい。
【００５３】
加えて、ＤＲモジュール２０４は、実時間リソース需要を推定してよい。例えば、ＤＲモジュール２０４は、住居から及び／又はリソース供給機関からのメータ読み出し（例えば、変電所でのメータ読み出し）を受けてよい。ＤＲモジュール２０４は、次いで、実時間リソース需要を推定するようにメータ読み出しを集約してよい。幾つかの実施形態において、メータ読み出しは、先行インターバルからであってよい。例えば、ＤＲイベントが評価されるインターバルが午後２時から午後２時５分までである場合に、メータ読み出しは、午後１時５５分から午後２時のインターバルからであってよい。幾つかの代替の実施形態において、実時間需要は、サードパーティサーバ１３４から読み出される１つ以上の需要予測アルゴリズムを用いて推定されてよい。そのような及び他の実施形態において、経済データ及び推定される実時間需要は、ＤＲイベントに関連する期間の需給不均衡を決定するのに使用されてよい。
【００５４】
ＤＲモジュール２０４は、ＤＲイベントの採算性を最大にする目標リソース削減を決定してよい。ＤＲモジュール２０４は、ＤＲイベントの費用を最小限とし且つ削減が起こる場合の経済データに対する変更を考慮に入れることによって、目標リソース削減を決定してよい。例えば、幾つかの実施形態において、ＤＲモジュール２０４は、ＤＲイベントに含まれる削減要求量の関数として実時間価格を予測してよい。住居がリソースを削減する場合に、需要は相応に低下し得る。これは実時間価格に作用し得る。ＤＲモジュール２０４は、目標リソース削減を決定することに応答して、需要に対する及び価格に対する変更を考慮に入れてよい。
【００５５】
ＤＲモジュール２０４は、ＤＲイベントの目標費用を決定してよい。目標費用は、ＤＲイベントのためのリソースの推定価格にリソースの量を乗じたものを含んでよい。例えば、ＤＲイベントのためのリソースはエネルギを含んでよい。ＤＲモジュール２０４は、目標価格が毎時ＭＷあたり２０．００ドルであり、エネルギの量が毎時１００ＭＷであると決定してよい。結果として、目標コストは２０００．００ドルであってよい。
【００５６】
ＤＲイベントの目標費用はまた、目標リソース削減の関数であってよい。例えば、ＤＲイベントがより大きい目標リソース削減を有する場合は、ＤＲイベントの費用は、より低い目標リソース削減を伴うＤＲイベントの費用よりも高くてよい。目標リソース削減の決定は、ＤＲイベントの費用に少なくとも部分的に基づいてよい。例えば、ＤＲイベントの費用が潜在的な採算性よりも大きい場合は、ＤＲモジュール２０４は、目標リソース削減量がゼロであり得ると決定してよく、結果として、ＤＲモジュール２０４は、ＤＲイベントを決定しなくてよい。
【００５７】
目標リソース削減及び目標費用の決定は、履歴データに基づいてよい。追加的に、又は代替的に、決定は、住居及び／又はユーザの位置又は地域に基づいてよい。例えば、分配チャネルについてのリソースの実時間ＬＭＰが増大する場合は、ＤＲモジュール２０４は、ＤＲイベントの間にリソースを削減するように、分配チャネルに位置する住居を識別してよい。代替的に、他の分配チャネルについてのリソースの実時間ＬＭＰが増大する場合は、ＤＲモジュール２０４は、ＤＲイベントの間にリソースを削減するように、他の分配チャネルに位置する住居を識別してよい。ＤＲモジュール２０４は、ＤＲイベントの採算性を最大にするように、複数の分配チャネルにわたって然るべく需給のバランスを取ってよい。
【００５８】
ＤＲモジュール２０４は、ユーザがＤＲイベントに関連する期間の間に店舗でクーポンを引き換え得る可能性に基づき、クーポンと一致するユーザを識別してよい。ユーザがユーザの住居の代わりに店舗にいる場合に、住居はさほどリソースを消費しない。ＤＲモジュール２０４は、ＤＲイベントに参加すべくユーザによって特定されたインタレストと、実行履歴とに基づき、ユーザがクーポンを引き換え得る可能性を決定してよい。実行履歴は、例えば、ユーザが午後１時より前ではなくあくまで午後１時から午後４時の間にクーポンを引き換えるかどうかといった、いつユーザがクーポンを引き換えたかを含んでよい。ＤＲモジュール２０４は、その日の特定の時刻に起こるＤＲイベントのためにユーザを選択するために、実行履歴を使用してよい。実行履歴は、引き換えられたクーポンのパーセンテージと、例えば、ユーザがクーポンを引き換える前にクーポンが閾量を越えてオファーを含むかどうかといった、解析データとを更に含んでよい。ＤＲモジュール２０４は、クーポンを引き換える可能性の程度に従って、ユーザを評価するか、あるいは、ユーザを分類してよい。
【００５９】
ＤＲモジュール２０４は、ユーザ及びユーザインタレストに関する情報をクーポンモジュール２０６に送信してよい。クーポンモジュール２０６は、オファーとユーザとの間の一致を決定してよい。ＤＲモジュール２０４は、クーポンを引き換えることに同意する、クーポンを受けたユーザのうちの１以上から、返答を受け取ってよい。返答及び／又は、ユーザの夫々がクーポンを引き換える可能性に基づき、ＤＲモジュール２０４は、クーポンを受けるべきユーザのサブセットを決定してよい。ＤＲモジュール２０４は、ユーザに関連する家庭用アプライアンスのタイプを決定することによって、サブセット内の夫々のユーザについて負荷低減を推定してよい。ＤＲモジュール２０４はまた、負荷低減を推定するために実行履歴を使用してよい。例えば、ＤＲモジュール２０４は、ユーザについての負荷低減を推定するように、前回のＤＲイベントに参加したユーザに関連する住居でのリソースの前回の削減を使用してよい。
【００６０】
ＤＲモジュール２０４は、種々のタイプのＤＲプロダクト及びリソースに従って、住居のアプライアンスを分類してよい。ＤＲモジュール２０４は、リソースのタイプ及び対象サービスのタイプに従って、リソースを分類してよい。ＤＲモジュール２０４は、リソースのスケジュール及び信頼性、コミットメントレベル、並びに費用及び入札ストラテジに基づき、リソースを分類してよい。ＤＲモジュール２０４がリソースを分類した後、ＤＲモジュール２０４は、どのプロダクトにリソースを適用すべきかを決定してよい。
【００６１】
表１は、ＭＩＳＯに従って編成される種々のタイプのＤＲプロダクト及びリソースを含む。エネルギは、実時間市場又は１日前市場における短期のエネルギ使用における減少を指し、これは、ユーザのための短期の価格低下をもたらす。調整予備力（regulation  reserve）は、２０分内のフルレンジ性能を有して数秒内で需要又は供給を低減又は増大させる能力を指す。瞬時／運転予備力（sppin/supplemental  reserve）は、１０分内に需要を低減させるか又は供給を増大させ、指定された期間保持する能力を指す。モジュールＥは、公共事業体ベースの予測を監視するリソース適性コンストラクト（resource  adequacy  construct）であってよい。緊急エネルギ（emergency  energy）は、需要が供給を凌ぐ脅威を与えることに応答して需要を低下させることを指す。緊急エネルギは、輪番停電を回避するために使用されてよい。
【００６２】
ＤＲＲタイプＩは、（ｉ）エネルギ及び運用予備力（operating  reserve）市場に参加するよう登録され得、（ｉｉ）特定の量のエネルギ、コンティンジェンシーサーバ、又は能力を、市場参加者の選択時に、物理的な負荷中断を通じてエネルギ及び運用予備力市場に供給することができ、（ｉｉｉ）伝送プロバイダの命令に従うことができ、且つ（ｉｖ）適切な計量設備を設置され得るＭＩＳＯバランシング権限地域内で、エネルギ消費者、ＬＳＥ（load  serving  entity）、又は小売客のアグリゲータ（ＡＲＣ；aggregator  of  retail  customers）によってホスティングされるリソースであってよい。
【００６３】
ＤＲＲタイプＩＩは、（ｉ）エネルギ及び運用予備力市場に参加するよう登録され得、（ｉｉ）エネルギ及び／又は運用予備力の範囲を、市場参加者の選択時に、ビハインド・ア・メータ・ジェネレーション（behind-a-meter  generation）及び／又は制御可能な負荷を通じてエネルギ及び運用予備力市場に供給することができ、（ｉｉｉ）伝送プロバイダの設定命令に従うことができ、且つ（ｉｖ）適切な計量設備を設置され得るＭＩＳＯバランシング権限地域内で、エネルギ消費者、ＬＳＥ、又はＡＲＣによってホスティングされるリソースであってよい。
【００６４】
負荷変更リソース（ＬＭＲ；load  modifying  resources）は、ＬＭＲ  ＤＲ及びＬＭＲビハインド・ザ・メータ・ジェネレーション（ＢＴＭＧ；behind-the-meter  generation）リソースを含んでよい。ＬＭＲ  ＤＲは、緊急事態の間に需要を低減し得る中断可能な負荷又は直接制御負荷及び他のリソースを管理してよい。ＬＭＲ  ＢＴＭＧは、伝送プロバイダの設定命令に含まれ得ない商業価格決定ノード（ＣＰＮｏｄｅ；commercial  pricing  node）の後ろにある卸売又は小売負荷に供給するために使用されるリソースを生成してよい。
【００６５】
緊急デマンドレスポンス（ＥＤＲ；emergency  demand  response）リソースは、緊急状態の間市場参加者への費用を低減してよく、それらのオファー及びＬＭＰに基づきそれらのサービスを補償されてよい。
【表１】
2016143412.tif 000003
【００６６】
ＤＲモジュール２０４は、利益（例えば、最大限の利益）及び／又はリスク（最小限のリスク）を決定し、利益及び／又はリスクを用いてリソースを入札してよい。ＤＲモジュール２０４は、利益を最大限とすること又はリスクを最小限とすることにおいて因子として使用される利益マージン又はリスクマネージメントのバッファを特定してよい。
【００６７】
ＤＲモジュール２０４は、利益を最大にするように供給曲線のパラメータを決定してよい。例えば、ＤＲモジュール２０４は、オファー価格（Ｐ）及び量（Ｄ）（例えば、需要）を決定してよく、このとき、供給曲線は、利益を最大にするように供給曲線における需要ビット（Ｄｉ，Ｐｉ）の関数としてオファー価格を決定するのに使用される。供給曲線は、一対のパラメータ（Ｄ１，Ｐ１）を持った単段の供給曲線、複数対のパラメータ（Ｄｉ，Ｐｉ）を持った多段の供給曲線、又は線形パラメータ（Ｄｍｉｎ，Ｄｍａｘ，Ｐｍｉｎ，Ｐｍａｘ）を持った線形な供給曲線を含んでよい。幾つかの実施形態において、Ｄｍｉｎは、入札プロセスに参加するに値する最低限の需要についての一定の制約としてサードパーティサーバ１３４によって指定される。
【００６８】
ＤＲモジュール２０４は、次のパラメータ：デマンドレスポンスの価格（ＰＤＲ）、入札すべきＤＲプロダクトのタイプ、価格及び量を含む入札供給曲線、翌日の毎時ごとの１日前市場での予測される価格（ＰＤＡ）、並びに翌日の毎時ごとの実時間市場での予測される価格（ＰＲＴ）を決定してよい。
【００６９】
ＤＲモジュール２０４は、ＤＲイベントの間にリソースを削減することが、削減が多数の市場参加者からの総供給曲線を再モデリングするほど十分にＬＭＰに影響を及ぼさないＬＳＥ又はＤＲアグリゲータからの全体の供給へのほんのわずかな寄与に相当すると考える。
【００７０】
供給曲線は、リソースの量がリソースの需要と同じであることに応答して、１日前市場についての予測された価格（ＰＤＡ）がＬＭＰと同等であると考えてよい。結果として、ＤＲモジュール２０４は、ＬＳＥ又はＤＲアグリゲータから寄与される精算需要（clearing  demand）（Ｄｃ）に基づき、供給指し値をモデリングしてよい。
【００７１】
ＤＲモジュール２０４は、線形関数に基づき供給曲線から線形供給指し値を生成してよい。ケース１は：ｐｄａ＜ｐｍｉｎならば、Ｄｃ＝０を提示する。ケース２は：ｐｍｉｎ≦ｐｄａ≦ｐｍａｘならば、Ｄｃ＝（（ｐｄａ−ｐｍｉｎ）／（ｐｍａｘ−ｐｍｉｎ））×（Ｄｍａｘ−Ｄｍｉｎ）＋Ｄｍｉｎを提示する。ケース３は：ｐｄａ＞ｐｍａｘならば、Ｄｃ＝Ｄｍａｘを提示する。
【００７２】
ＤＲモジュール２０４は、１日前価格（ＰＤＡ）及び実時間価格（ＰＲＴ）の両方の価格予測を、夫々累積分布関数（ＣＤＦ；cumulative  distribution  function）（ＦＰＤＡ（ｐｄａ）及びＦＰＲＴ（ｐｒｔ））により、確率論的関数としてモデリングしてよい。ＤＲモジュール２０４は、価格のＣＤＦを生成するために価格予測を使用してよい。ＤＲモジュール２０４は、下限（ｐｌ）及び上限（ｐｕ）を含む価格範囲を決定してよい。下限の関数又は値（Ｆｐ（ｐｌ））はゼロであってよく、上限の関数又は値（Ｆｐ（ｐｕ））は１であってよい。例えば、上限は、市場オペレータ（例えば、ＩＳＯ）によって指定されたプライスキャップであってよい。
【００７３】
ＤＲモジュール２０４は、価格シナリオを確率論的関数に適用してよい。このとき、（ｐ）は価格を表し（例えば、最大価格はｐｍａｘと表されてよい。）、（Ｄ）は需要を表し（例えば、最大需要はＤｍａｘと表されてよい。）、（Ｆ）は累積分布関数を表し（例えば、最大価格の累積分布関数はＦＰ（ｐｍａｘ）と表されてよい。）、確率分布関数は（ｐｒｏｂ）と表されてよい。例えば、ケース１は：ｐｍａｘ＜ｐｌならば、ＦＰ（ｐｍａｘ）＝０≡ｐｒｏｂ（Ｄｃ＝Ｄｍａｘ）＝１を提示する。ケース２は：ｐｍｉｎ≦ｐｌ≦ｐｍａｘならば、ＦＰ（ｐｍｉｎ）＝０；（２−１）：ｐｍｉｎ≦ｐｄａ≦ｐｍａｘならば、ｐｒｏｂ（Ｄｃ＝（（ＰＤＡ−Ｐｍｉｎ）／（Ｐｍａｘ−Ｐｍｉｎ））×（Ｄｍａｘ−Ｄｍｉｎ）＋Ｄｍｉｎ）＝ＦＰ（ｐｍａｘ）；（２−２）：ｐｍａｘ≦ｐｄａならば、ｐｒｏｂ（Ｄｃ＝Ｄｍａｘ）＝１−ＦＰ（ｐｍａｘ）を提示する。ケース３は：ｐｌ＜ｐｍｉｎ≦ｐｍａｘ＜ｐｕならば、０＜ＦＰ（ｐｍｉｎ）≦ＦＰ（ｐｍａｘ）＜１；（３−１）：ｐｄａ＜ｐｍｉｎならば、ｐｒｏｂ（Ｄｃ＝０）＝ＦＰ（ｐｍｉｎ）；（３−２）：ｐｍｉｎ≦ｐｄａ≦ｐｍａｘならば、ｐｒｏｂ（Ｄｃ＝（（ＰＤＡ−Ｐｍｉｎ）／（Ｐｍａｘ−Ｐｍｉｎ））×（Ｄｍａｘ−Ｄｍｉｎ）＋Ｄｍｉｎ）＝ＦＰ（ｐｍａｘ）−ＦＰ（ｐｍｉｎ）；（３−３）：ｐｍａｘ＜ｐｄａならば、ｐｒｏｂ（Ｄｃ＝Ｄｍａｘ）＝１−ＦＰ（ｐｍａｘ）を提示する。
【００７４】
ＤＲモジュール２０４は、クーポンを受けるユーザのサブセットについてのリソースの総削減量を推定してよい。ＤＲモジュール２０４は、個々の削減量（ｄｉ）を持ったユーザ（ｉ）について、その個々の削減量が２つの確率変数の乗算であり得ると決定してよい。その２つの確率変数とは、ユーザがクーポンを引き換えることによってＤＲイベントに参加する可能性（すなわち、需要柔軟性評価）（ｌｉ）と、ユーザがクーポンを引き換える場合の負荷低減の分布（ｃｉ）とである。関係はｄｉ＝ｌｉ・ｃｉと表されてよい。
【００７５】
ＤＲモジュール２０４は、クーポンを引き換えるユーザ（ｌｉ）と、ユーザがクーポンを引き換える場合の負荷低減の分布（ｃｉ）とに基づき、全てのユーザ（ｉ）のうちのクーポンを受けるユーザのサブセット（Ｒ）について、総削減量
（外１）
2016143412.tif 000004
を、次の式のように評価してよい：
【数１】
2016143412.tif 000005
簡略化されたモデルは、参加の可能性が離散確率変数であり、負荷低減が正規分布としてモデリングされると考えてよい。結果として、ＤＲモジュール２０４は、総削減量を正規分布（Ｎ）として推定してよい。つまり：
【数２】
2016143412.tif 000006
このとき、ｌｉは、ユーザがＤＲイベントに参加する可能性を表し、ｃｉは、ユーザがクーポンを引き換える場合の負荷低減の分布を表し、Ｅ［ｃｉ］は、分布ｃｉの期待値（すなわち、平均）を表し、σ２は、分布ｃｉの分散を表す。
【００７６】
ＤＲモジュール２０４は、最大限の利益を決定するために、総削減量、１日前予測及び実時間価格を使用してよい。利益は、ＰＤＡ・ＤＣ−ＰＤＲ・ＤＲ−ＰＲＴ・（ＤＣ−ＤＲ）＝ＤＣ・（ＰＤＡ−ＰＲＴ）＋ＤＲ・（ＰＲＴ−ＰＤＲ）として定義されてよい。ＰＤＡ・ＤＣはリソースクレジットと称されてよい。リソースクレジットは、１日前市場からリソースを購入する価格（ＰＤＡ）に、提示されたＤＲ入札についての精算需要（ＤＣ）を乗じたものを含む。デマンドレスポンスインセンティブのための価格（ＰＤＲ・ＤＲ）は、リソースクレジットから減じられてよい。ＰＲＴ・（ＤＣ−ＤＲ）は、実時間市場からリソースを購入する価格（ＰＲＴ）に、提示されたＤＲ入札についての精算需要（ＤＣ）とＤＲイベント後の実際のパフォーマンス（ＤＲ）との間の差を乗じたものとして示されてよい。
【００７７】
ＤＲモジュール２０４は、入札が過剰量又は過小量のリソースのためであるかどうかに基づき最大限の利益を決定してよい。総削減量（ＤＲ）がＬＳＥから寄与される精算需要（ＤＣ）よりも少ない場合は、ＬＳＥは、ＰＲＴ・（ＤＣ−ＤＲ）の追加費用で実時間市場からエネルギを購入する必要があり得る。例えば、ＤＲモジュール２０４が１日前ＬＭＰで入札し、ＭＷあたり２０．００ドルの１００ＭＷの削減エネルギを供給する場合に、ＤＲモジュール２０４は２０００．００ドルを支払われる。実際の需要削減が９５ＭＷであり、実時間ＬＭＰが２３ドルである場合に、ＤＲモジュール２０４は、１１５．００ドルの追加料金の代わりにＭＷあたり２３ドルで５ＭＷを購入する。
【００７８】
総削減量（ＤＲ）がＬＳＥから寄与される精算需要（ＤＣ）よりも多い場合は、ＬＳＥは、ＰＲＴ・（ＤＲ−ＤＣ）の実時間市場からの特別クレジットを受ける。例えば、ＤＲモジュール２０４が１日前ＬＭＰで入札し、ＭＷあたり２５．００ドルの１００ＭＷの削減エネルギを供給する場合に、ＤＲモジュールは２５００．００ドルを支払われる。実際の需要削減が１０５ＭＷであり、実時間ＬＭＰが２０ドルである場合に、ＤＲモジュール２０４は、ＭＷあたり２０ドルでの５ＭＷのクレジット、すなわち、合計で１００．００ドルを受け取る。
【００７９】
ＤＲモジュール２０４は、１日前価格ＣＤＦ、実時間価格ＣＤＦ、及び総削減量ＣＤＦを推定することによって、最低価格（ｐｍｉｎ）、最高価格（ｐｍａｘ）、及び最大需要（ｄｍａｘ）に基づき最大限の利益（ｍａｘ（ｐｍｉｎ，ｐｍａｘ，ｄｍａｘ））を決定してよい。例えば、次の例は、線形供給曲線に基づいてよい：
ｍａｘ（ｐｍｉｎ，ｐｍａｘ，ｄｍａｘ）Ｅ［ＤＣ・（ＰＤＡ−ＰＲＴ）＋ＤＲ・（ＰＲＴ−ＰＤＲ）］＝ｍａｘ（ｐｍｉｎ，ｐｍａｘ，ｄｍａｘ）Σ（ｐｄａ，ｐｒｔ，ｄｒ）ｐｒｏｂ（ｐｄａ，ｐｒｔ，ｄｒ）・［ＤＣ・（ｐｄａ−ｐｒｔ）＋ｄｒ・（ｐｒｔ−ＰＤＲ）］
ＤＲモジュール２０４は、定量化ステップ（Δｄａ，Δｒｔ，Δｒ）により変数空間（ｐｄａ，ｐｒｔ、ｄｒ）を定量化してよい。次に：ｆＰＤＡ（ｐｄａ）＝ＦＰＤＡ（ｐｄａ＋（１／２）Δｄａ）−ＦＰＤＡ（ｐｄａ−（１／２）Δｄａ）。ｆＰＤＡ（ｐｄａ）は、ｐｄａに等しい１日前価格の確率を表す。ｆＰＤＡ（ｐｄａ）の値は、ｐｄａの周りの累積分布関数ＦＰＤＡの定量化された値、すなわち、ＰＤＡ（ｐｄａ＋（１／２）Δｄａ）とＦＰＤＡ（ｐｄａ−（１／２）Δｄａ）との差に基づき、推定される。１日前価格（ｐｄａ）、実時間価格（ｐｒｔ）、及び実時間需要（ｄｒ）についての変数空間の確率（ｐｒｏｂ（ｐｄａ，ｐｒｔ、ｄｒ））は、ｐｒｏｂ（ｐｄａ，ｐｒｔ、ｄｒ）＝ｆＰＤＡ（ｐｄａ）・ｆＰＲＴ（ｐｒｔ）・ｆＤＲ（ｄｒ）として表され得る独立した確率変数として変数空間を簡単化することによって、計算されてよい。
【００８０】
ＤＲモジュール２０４は、定量化ステップ（Δｄａ，Δｒｔ，Δｒ）を特定し、出力された変数空間（ｐｄａ，ｐｒｔ、ｄｒ）の全数検索を実行して最適な客観的価値を見つけることによって、最大限の利益を決定してよい。これは、ｐｒｏｆｉｔ（ｐｍｉｎ，ｐｍａｘ，ｄｍａｘ）＝Σ（ｐｄａ，ｐｒｔ，ｄｒ）ｐｒｏｂ（ｐｄａ，ｐｒｔ，ｄｒ）・［ＤＣ・（ｐｄａ−ｐｒｔ）＋ｄｒ・（ｐｒｔ−ＰＤＲ）］と表されてよい。このとき、精算需要（ＤＣ）は、上記の線形供給指し値のためのモデルに基づき計算されてよい。幾つかの実施形態において、検索は、量子化ステップ（Δｄａ，Δｒｔ，Δｒ）の大きい値から開始してよい。最大限の利益の値は記録されてよい。最大限の利益を決定するプロセスは、量子化ステップ（Δｄａ，Δｒｔ，Δｒ）の値を小さくすることによって続いてよい。検索は、最大限の利益がそれ以上改善され得ない場合に終了してよい。
【００８１】
ＤＲモジュール２０４は、１日前市場でリソースの価格及び量を入札するために最大限の利益を使用してよい。ＤＲモジュール２０４が落札することができない場合は、ＤＲモジュール２０４は、実時間市場でリソースの価格及び量を入札してよい。ＤＲモジュール２０４が落札する場合は、ＤＲモジュール２０４は、確認されているＤＲイベントをユーザのサブセットに知らせてよい。ＤＲモジュール２０４は、ＤＲイベントが起こる一定量の時間前に、確認されているＤＲイベントをユーザのサブセットに思い出せてよい。
【００８２】
入札の間、ＤＲモジュール２０４は、ＤＲイベントの間に削減され得るリソースの位置を特定してよい。例えば、ＤＲモジュール２０４は、ＤＲイベントに参加しているクーポンを受けるユーザのサブセットに関連する住所を特定してよい。ＤＲモジュール２０４は、ユーザがクーポンを引き換える可能性を決定することに基づき、ユーザのサブセットがＤＲイベントに参加していると有利に決定してよい。加えて、ＤＲモジュール２０４は、ユーザがＤＲイベントの間にクーポンを引き換えることに同意するとの１以上のユーザからのインジケーションを受け取ってよい。
【００８３】
クーポンモジュール２０６は、オファーとユーザとの間の一致を識別し、オファー及び他のインセンティブ（例えば、実行ボーナス及び緊急ボーナス）を含むユーザのためのクーポンを生成するよう構成されてよい。
【００８４】
クーポンモジュール２０６は、オファーと一致するユーザのインジケーションをＤＲモジュール２０４から受けてよい。例えば、ＤＲモジュール２０４は、クーポンを引き換える可能性が高いユーザの初期サブセットを送信してよい。クーポンモジュール２０６は、ユーザに関連するユーザインタレストを更に受けてよい。
【００８５】
クーポンモジュール２０６は、図１のマーチャントサーバ１１５からオファーを受けてよい。例えば、クーポンモジュール２０６は、オファーのためにマーチャントサーバ１１５へリクエストを送信してよい。代替的に、又は追加的に、マーチャントサーバ１１５は、周期的に（例えば、５分ごと、１時間ごと、毎日、など）、ランダムに、疑似ランダムに、又はオンデマンドで、オファーをクーポンモジュール２０６へ送信してよい。クーポンモジュール２０６は、オファーを送信する期限をマーチャントに提供してよい。
【００８６】
オファーは、品物又はサービスを購入するための購入インセンティブと、その品物又はサービスに関連するインタレストのカテゴリとを含んでよい。例えば、オファーは、お茶を提供しているカフェでの飲食の１０％割引を含んでよい。
【００８７】
クーポンモジュール２０６は、複数のオファーの中のあるオファーとユーザとの間の一致を識別してよい。クーポンモジュール２０６は、オファーの部分である品物又はサービスに関連するインタレストのカテゴリと、ユーザに関連するユーザインタレストとを特定することに基づき、一致を識別してよい。例えば、クーポンモジュール２０６は、カフェでの１０％割引についてのオファーがお茶のカテゴリを含むことを決定してよく、そして、クーポンモジュール２０６は、オファーを、お茶に対するユーザインタレストを持ったユーザと照合してよい。幾つかの実施形態において、クーポンモジュール２０６は、クーポンのタイプについてのユーザの好みに基づき、オファーをユーザと照合してよい。そのタイプは、例えば、パーセンテージ割引、金銭割引、又は還元ポイントなどの報酬のタイプについての好みを含んでよい。
【００８８】
クーポンモジュール２０６は、一致するオファーをマーチャントに知らせてよい。例えば、クーポンモジュール２０６は、１日の間のある時点でマーチャントに知らせてよい。代替的に、マーチャントは、一致するオファーに関する通知をどれくらい前もって受け取るか（例えば、３日）を指定してよい。
【００８９】
クーポンモジュール２０６は、オファーを含むユーザのためのクーポンを生成してよい。例えば、クーポンモジュール２０６は、クーポンを引き換える代わりの１０％割引を含んでよい。クーポンモジュール２０６は、デマンドレスポンスイベントに関連する期間を更に受けてよい。クーポンモジュール２０６は、デマンドレスポンスイベントに関連する期間の間に指定された物理的な位置でクーポンを引き換えるための実行インセンティブを提供する実行ボーナスを伴うクーポンを生成してよい。例えば、クーポンは、クーポンを引き換える代わりの１０％割引と、午後３時から３時３０分の間にカフェでクーポンを引き換える代わりの余分の５％ディスカウントとを含んでよい。幾つかの実施形態において、実行インセンティブは、デマンドレスポンスイベントの具体的な日時に関連してよい。加えて、実行インセンティブは、デマンドレスポンスイベントに関連する実際のリソース削減に依存してよい。実際のリソース削減の計算は、測定及び検証モジュール２１０によって提供される。
【００９０】
幾つかの実施形態において、クーポンモジュール２０６は、実行インセンティブの費用をマーチャントに償還することによって、公共事業体に成り代わって実行インセンティブの代価を支払ってよい。クーポンモジュール２０６は、実行インセンティブの額面とは異なる率でマーチャントに償還してよい。例えば、クーポンモジュール２０６は、実行インセンティブの値の３０％をマーチャントに償還してよい。
【００９１】
幾つかの実施形態において、クーポンモジュール２０６は、ＤＲイベントに関連する期間の間にクーポンを引き換えることに同意するユーザにサインアップインセンティブを提供するサインアップボーナスを含むクーポンを生成してよい。例えば、クーポンモジュール２０６は、追加割引をユーザに提供し、関係する位置で引き換えられ得るロイヤルティプログラムのための還元ポイントを提供する、などしてよい。サインアップボーナスは、クーポンを引き換えることに同意することに答えるための期限を含んでよい。期限は、ＤＲモジュール２０４が１日前市場又は時間前市場で入札する際に使用するのに有利であり得る。行動は、ユーザからの明示的な同意でなくても、同意と見なされてよい。例えば、同意は、ＤＲイベントに関連する期間の間にレストランでテーブルを予約するためのユーザからのリクエストを含んでよい。サインアップボーナスは、例えば、日中の最も暑い時間帯のエネルギ消費量のような、ピーク時間の間に起こるＤＲイベントのための実行ボーナスと併せて、使用されてよい。
【００９２】
マーチャント、公共事業体、又はマーチャントと公共事業体との組み合わせは、サインアップインセンティブの代金を支払ってよい。クーポンモジュール２０６は、ユーザがＤＲイベントに関連する期間の間にクーポンを引き換えるとの同意に従ったかどうかを監視してよい。例えば、クーポンがＤＲイベントに関連する期間の間に引き換えられず、あるいは、全く引き換えられない場合は、クーポンモジュール２０６は、ユーザがクーポンを引き換えることに同意した時点で贈られたサインアップインセンティブを無効にしてよい。
【００９３】
幾つかの実施形態において、クーポンモジュール２０６は、短縮された期間内に引き換えるための緊急インセンティブを提供する緊急ボーナスを含むクーポンを生成してよい。例えば、短縮された期間は、ユーザがクーポンを受ける時から数分であってよい。緊急インセンティブは、供給不足を補償するために使用されてよい。
【００９４】
幾つかの実施形態において、クーポンモジュール２０６は、ユーザに関連するユーザ位置を決定し、ユーザ位置からの距離の閾範囲内にある店舗位置を持ったマーチャントのサブセットを決定するようにマーチャントからのオファーにフィルタをかける。ユーザ位置は、例えば、ユーザに関連する住居を含んでよい。クーポンモジュール２０６は、マーチャントのサブセットの中の１つのマーチャントからのオファーを使用してよい。それにより、店舗位置は、ユーザが短縮された期間の間にその店舗位置に到達できるほど十分に近くにあることができる。緊急ボーナスは、例えば電気供給などのリソースが逼迫する可能性があり、公共事業体が、近隣に住むユーザに彼らの住居でのエネルギ消費量を減らすよう働きかけたい場合に、その近隣で有利に使用されてよい。
【００９５】
クーポンモジュール２０６は、クーポンに関する情報をマーチャントサーバ１１５に知らせてよい。例えば、クーポンモジュール２０６は、マーチャントサーバ１１５に、クーポンモジュール２０６がそのマーチャントサーバ１１５からのオファーを使用してクーポンをユーザに送信するかどうかを知らせてよい。クーポンモジュール２０６は、ユーザがクーポンを引き換え得るＤＲイベントに関連する期間を含んでよい。他の例では、クーポンモジュール２０６は、ユーザがＤＲイベントに関連する期間の間にクーポンを引き換えることに同意するかどうかをマーチャントサーバ１１５に知らせてよい。マーチャントサーバ１１５は、ユーザに備えるために情報を有利に使用してよい。例えば、ユーザが、レストランで予約することによって、ＤＲイベントに関連する期間の間にクーポンを引き換えることに同意する場合に、レストランは、そのレストランのためにどれくらいの量の料理を前もって準備すべきかを決定するために予約を使用してよい。更なる他の例では、マーチャントサーバ１１５は、クーポンモジュール２０６が閾値を上回る値を持ったインセンティブオファーを提供するかどうかをクーポンモジュール２０６がマーチャントサーバ１１５に知らせることを要求してよい。例えば。クーポンモジュール２０６は、インセンティブオファーが品物又はサービスの５ドルよりも多い価値のためである場合に、マーチャントサーバ１１５に通知してよい。そのような通知を受けると、マーチャントサーバ１１５は、マーチャントサーバ１１５からの追加のインセンティブオファーを伴うクーポンを生成してよい。
【００９６】
クーポンモジュール２０６は、ユーザが店舗でクーポンを引き換える場合にマーチャントサーバ１１５から通知を受けてよい。クーポンがユーザに還元ポイントを提供するためのインセンティブを含んだならば、クーポンモジュール２０６は、マーチャントサーバ１１５からの通知を受けることに応答して、還元ポイントをユーザのアカウントに加えてよい。
【００９７】
ユーザインタフェースモジュール２０８は、ユーザインタフェースを表示するグラフィカルデータを生成してよい。ユーザインタフェースモジュール２０８は、ユーザがユーザを登録するための情報を入力するユーザインタフェースをユーザ装置１２０での表示のために生成するように、登録モジュール２０２から命令を受けてよい。ユーザインタフェースモジュール２０８は、ユーザ装置１２０でクーポンを表示するグラフィカルデータを生成するように、クーポンモジュール２０６から命令を受けてよい。
【００９８】
測定及び検証モジュール２１０は、リソースに関する情報を受け、ユーザがクーポンを引き換えたことを確認するよう構成されてよい。例えば、測定及び検証モジュール２１０は、メータデータレポートを受けてよい。測定及び検証モジュール２１０は、住居がリソースの削減を経験したかどうかを決定するために、リソースに関する情報を使用してよい。測定及び検証モジュール２１０は、リソースの削減に関する決定をＤＲモジュール２０４へ送信してよい。ＤＲモジュール２０４は、リソースの削減に関する決定に基づき、ユーザに関連するレスポンス履歴情報を更新してよい。
【００９９】
測定及び検証モジュール２１０は、ユーザがＤＲプログラムに従ったことを確かめるために、リソースの削減に関する決定を使用してよい。例えば、ユーザがクーポンを引き換えたが、ユーザがクーポンを引き換えている間にユーザの住居でアプライアンスを運転したままであった場合は、検証モジュール２１０は、ユーザがＤＲプログラムの条件を満足することができなかったと決定してよい。結果として、検証モジュール２１０は、クーポンに付随するボーナスを取り消してよい。例えば、ユーザがクーポンを引き換えることに同意し、同意する代わりに１００還元ポイントを受け取ったとのインジケーションをクーポンモジュール２０６が受けた場合に、検証モジュール２１０は、ユーザのアカウントから１００還元ポイントを控除してよい。
【０１００】
図３は、クーポン及び種々のタイプのインセンティブを含むグラフィカルユーザインタフェース３００の例を表す。この例では、クーポンは、映画館で５ドルオフのクーポンを引き換えるためのオファー及びバーコードを伴う部分３０５を含む。クーポンは、２０１５年２月のいずれかの平日の午後２時３０分から３時の間に売店でクーポンを引き換えて、別の５ドルオフ（例えば、売店での購入の一助）を受けるための実行インセンティブ３１０を更に含む。クーポンは、ユーザが特定の日時（例えば、この例では、２０１５年２月３日）にクーポンを引き換えることに同意するために同意ボタン３２０を選択する場合に関係する店舗で引き換え可能である追加の２ドル価値を受けるためのサインアップインセンティブ３１５を含む。クーポンモジュール２０６は、次のオファーボタンを選択することによって見ることができるユーザのための複数のクーポンを生成してよい。
【０１０１】
図４は、ここで記載される少なくとも幾つかの実施形態に従って配置される、ＤＲイベントの間に引き換えられるようにクーポンをユーザと照合する方法４００の例のフローチャートを表す。方法４００は、全体的に又は部分的に、図１のＤＲサーバ１０１、図１若しくは２のＤＲアプリケーション１１１、図２の装置２００、又は他の適切な装置、サーバ及び／若しくはシステムのうちの１つ以上によって実装されてよい。方法４００はブロック４０２から開始してよい。
【０１０２】
ブロック４０２で、ユーザに関連する１つ以上のユーザインタレストは決定される。例えば、ＤＲアプリケーション１１１及び／又は登録モジュール２０２はユーザインタレストを決定する。ユーザは、明示的にユーザインタレストを提供してよく、あるいは、ＤＲアプリケーション１１１及び／又は登録モジュール２０２は、ユーザインタレストを含むソーシャルネットワークなどの他のアカウントへリンクしてよい。
【０１０３】
ブロック４０４で、複数のオファーは複数のマーチャントから受け取られてよい。夫々のオファーは、品物又はサービスを購入するための購入インセンティブと、その品物又はサービスに関連するインタレストのカテゴリとを含む。例えば、ＤＲアプリケーション１１１及び／又はクーポンモジュール２０６は、品物又はサービスを購入するための購入インセンティブと、その品物又はサービスに関連するインタレストのカテゴリとを夫々が含む複数のマーチャントからの複数のオファーを受けてよい。幾つかの実施形態において、品物又はサービスは、インタレストの複数のカテゴリに関連してよい。
【０１０４】
ブロック４０６で、一致は、複数のオファーの中のあるオファーとユーザとの間で識別されてよい。これは、ユーザに関連する１つ以上のユーザインタレストを、品物又はサービスに関連するインタレストのカテゴリと照合することを含む。例えば、ＤＲアプリケーション１１１及び／又はクーポンモジュール２０６は、ユーザに関連する１つ以上のユーザインタレストを品物又はサービスに関連するインタレストのカテゴリと照合して、複数のオファーの中のオファーとユーザとの間の一致を識別する。ユーザインタレスト及びインタレストのカテゴリは同一であってよく、あるいは、ユーザインタレストは、インタレストのカテゴリの種を含んでよく（あるいは、その逆も同様）、あるいは、ユーザインタレストは、インタレストのカテゴリと類似してよい、など。照合は、ユーザの対象グループ、例えば、退職者又は主婦に基づいてよい。照合は、デマンドレスポンスイベントの時点でのユーザの位置に基づいてよい。例えば、ユーザが前回のデマンドレスポンスイベントの時間中に自身の住居にいたとクーポンモジュール２０６が特定する場合に、ユーザは、より高い価値を持ったクーポンに適合すべきより高い優先度のユーザと見なされてよい。更なる他の例では、照合は、購入履歴の記録に基づいてよい。
【０１０５】
ブロック４０８で、ＤＲイベントに関連する期間は決定されてよい。例えば、ＤＲアプリケーション１１１及び／又はＤＲモジュール２０４は、ＤＲイベントに関連する期間を決定してよい。
【０１０６】
ブロック４１０で、クーポンは、オファーと、ＤＲイベントに関連する期間の間に指定された物理的な位置でクーポンを引き換えるための実行インセンティブを提供する実行ボーナスとを含んで、ユーザのために生成されてよい。例えば、ＤＲアプリケーション１１１及び／又はクーポンモジュール２０６は、オファーと、ＤＲイベントに関連する期間の間に指定された物理的な位置でクーポンを引き換えるための実行インセンティブを提供する実行ボーナスとを含むユーザのためのクーポンを生成してよい。
【０１０７】
ブロック４１２で、クーポンは、指定された物理的な位置での引き換えのためにユーザに提供されてよい。ユーザによる指定された物理的な位置でのクーポンの引き換えは、ユーザに関連する住居位置でのリソース消費の低減を引き起こす。例えば、ＤＲアプリケーション１１１及び／又はクーポンモジュール２０６は、指定された物理的な位置での引き換えのためにユーザにクーポンを提供してよい。
【０１０８】
図５は、ＤＲイベントに基づきリソースを入札する方法５００の例のフローチャートを表す。方法５００は、全体的に又は部分的に、図１のＤＲサーバ１０１、図１若しくは２のＤＲアプリケーション１１１、図２の装置２００、又は他の適切な装置、サーバ及び／若しくはシステムのうちの１つ以上によって実装されてよい。方法５００はブロック５０２から開始してよい。
【０１０９】
ブロック５０２で、ＤＲイベントに関連する目標費用及び目標リソース削減は決定されてよい。例えば、図１のＤＲアプリケーション１１１及び／又はＤＲモジュール２０４は、ＤＲイベントに関連する目標費用及び目標リソース削減を決定してよい。
【０１１０】
ブロック５０４で、複数のオファーは複数のマーチャントから受け取られてよい。例えば、図１のＤＲアプリケーション１１１及び／又はクーポンモジュール２０６は、マーチャントから複数のオファーを受けてよい。
【０１１１】
ブロック５０６で、複数のユーザの夫々がＤＲイベントに関連する期間の間に指定された物理的な位置でクーポンを引き換える可能性は、決定されてよい。例えば、図１のＤＲアプリケーション１１１及び／又はＤＲモジュール２０４は、複数のユーザの夫々がＤＲイベントに関連する期間の間に指定された物理的な位置でクーポンを引き換える可能性を決定してよい。
【０１１２】
ブロック５０８で、クーポンの組は、目標費用、目標リソース削減、及び複数のユーザの夫々がクーポンを引き換える可能性に基づき、生成され、そして、複数のユーザのサブセットに提供されてよい。例えば、図１のＤＲアプリケーション１１１及び／又はクーポンモジュール２０６は、目標費用、目標リソース削減、及び複数のユーザの夫々がクーポンを引き換える可能性に基づき、複数のユーザのサブセットへのクーポンの組を生成し供給してよい。
【０１１３】
ブロック５１０で、クーポンを受ける複数のユーザのサブセットに基づくリソースの総削減量は、推定されてよい。例えば、図１のＤＲアプリケーション１１１及び／又はＤＲモジュール２０４は、クーポンを受ける複数のユーザのサブセットに基づきリソースの総削減量を推定してよい。
【０１１４】
ブロック５１２で、リソースの総削減量に基づき利益を最大限にするための供給曲線のパラメータは、決定されてよい。例えば、図１のＤＲアプリケーション１１１及び／又はＤＲモジュール２０４は、リソースの総削減量に基づき利益を最大限にするように供給曲線のパラメータを決定してよい。
【０１１５】
ブロック５１４で、１日前市場でのリソースは、供給曲線のパラメータに基づきリソースの提供価格及び量を提供することによって、入札されてよい。例えば、図１のＤＲアプリケーション１１１及び／又はＤＲモジュール２０４は、供給曲線のパラメータに基づきリソースの提供価格及び量を提供することによって、１日前市場でリソースを入札してよい。
【０１１６】
ここで記載される実施形態は、以下で更に詳細に論じられるように、様々なコンピュータハードウェア又はソフトウェアモジュールを含む特別目的又は汎用のコンピュータの使用を含んでよい。
【０１１７】
ここで記載される実施形態は、コンピュータ実行可能な命令又はデータ構造を搬送又は記憶するコンピュータ可読媒体を用いて実装されてよい。そのようなコンピュータ可読媒体は、汎用又は特別目的のコンピュータによってアクセスされ得るあらゆる利用可能な媒体を有してもよい。一例として、制限なしに、そのようなコンピュータ可読媒体は、ランダムアクセスメモリ（ＲＡＭ）、読出専用メモリ（ＲＯＭ）、電気的消去可能なプログラム可能読出専用メモリ（ＥＥＰＲＯＭ）、コンパクトディスク型読出専用メモリ（ＣＤ−ＲＯＭ）若しくは他の光ディスクストレージ、磁気ディスクストレージ若しくは他の磁気ストレージ装置、フラッシュメモリ装置（例えば、ソリッドステートメモリ装置）、あるいは、コンピュータ実行可能な命令又はデータ構造の形で所望のプログラムコードを搬送又は記憶するのに使用され得且つ汎用又は特別目的のコンピュータによってアクセスされ得るあらゆる他の記憶媒体も含む非一時的な又は有形なコンピュータ可読記憶媒体を有してよい。上記の組み合わせもコンピュータ可読媒体の適用範囲内に含まれてよい。
【０１１８】
コンピュータ実行可能な命令は、例えば、汎用のコンピュータ、特別目的のコンピュータ、又は特別目的のプロセッサ装置（例えば、１つ以上のプロセッサ）に、ある機能又は機能群を実行させる命令及びデータを含んでよい。対象は、構造的な特徴及び／又は方法論的な動作に特有の言語において記載されてきたが、添付の特許請求の範囲で定義される対象は、必ずしも、上記の特定の特徴又は動作に制限されない点が理解されるべきである。むしろ、上記の特定の特徴又は動作は、特許請求の範囲の実装する例となる形態として開示されている。
【０１１９】
ここで使用されるように、語「モジュール」又は「コンポーネント」は、そのモジュール若しくはコンポーネントの動作を実行するよう構成されるハードウェア実施形態及び／又は、コンピューティングシステムの汎用のハードウェア（例えば、コンピュータ可読媒体、プロセッサ装置、など）によって記憶及び／又は実行され得るソフトウェアオブジェクト若しくはソフトウェアルーチンを指してよい。幾つかの実施形態において、ここで記載される種々のコンポーネント、モジュール、エンジン及びサービスは、（例えば、別個のスレッドとして）コンピューティングシステムで実行するオブジェクト又はプロセッサとして実装されてよい。ここで記載されるシステム及び方法のうちの幾つかは、（汎用のハードウェアによって記憶及び実行される）ソフトウェアにおいて実装されるものとして概して記載されているが、特定のハードウェア実施形態又はソフトウェアと特定のハードウェア実施形態との組み合わせも可能であり、考えられている。本明細書において、「コンピューティングエンティティ」は、ここで以前に定義されたようなあらゆるコンピューティングシステム、又はコンピューティングシステムで実行されるあらゆるモジュール若しくはモジュールの組み合わせであってもよい。
【０１２０】
ここで挙げられている全ての例及び条件付き言語は、当該技術を促進させることに発明者によって寄与される概念及び発明を読者が理解するのを助ける教育的な目的を意図され、そのような具体的に挙げられている例及び条件に制限されないものとして解釈されるべきである。本発明の実施形態が詳細に記載されてきたが、様々な変更、置換及び代替は、発明の主旨及び適用範囲から逸脱することなしにそれらに対してなされてよい点が理解されるべきである。
【０１２１】
上記の実施形態に加えて、以下の付記を開示する。
（付記１）
デマンドレスポンスイベントの間に引き換えられるようにクーポンをユーザと照合する方法であって、
ユーザに関連する１つ以上のユーザインタレストを決定し、
複数のマーチャントからの複数のオファーであり、夫々が、品物又はサービスを購入するための購入インセンティブと、前記品物又はサービスに関連するインタレストのカテゴリとを含む前記複数のオファーを受け、
前記ユーザに関連する前記１つ以上のユーザインタレストを、前記品物又はサービスに関連する前記インタレストのカテゴリと照合して、前記ユーザと前記複数のオファーのうちのあるオファーとの間の一致を識別し、
デマンドレスポンスイベントに関連する期間を決定し、
前記ユーザのためのクーポンであり、前記オファーと、指定された物理的な位置で前記デマンドレスポンスイベントに関連する前記期間の間に当該クーポンを引き換えるための実行インセンティブを提供する実行ボーナスとを含む前記クーポンを生成し、
前記指定された物理的な位置での引き換えのために前記ユーザに前記クーポンを提供し、前記ユーザによる前記指定された物理的な位置での前記クーポンの引き換えは、前記ユーザに関連する居住場所でのリソース消費の減少を引き起こす
ことを有する方法。
（付記２）
前記クーポンは、前記デマンドレスポンスイベントに関連する前記期間の間に前記クーポンを引き換えることに同意するためのサインアップインセンティブを提供するサインアップボーナスを更に含む、
付記１に記載の方法。
（付記３）
前記ユーザが前記デマンドレスポンスイベントに関連する前記期間の間に前記クーポンを引き換えることに同意するとのインジケーションをユーザから受け、
前記ユーザが前記デマンドレスポンスイベントに関連する前記期間の間に前記クーポンを引き換えることに同意したことを、前記オファーに関連するマーチャントに知らせる
ことを更に有する付記２に記載の方法。
（付記４）
前記ユーザに関連する前記１つ以上のユーザインタレストを決定するように前記ユーザから前記１つ以上のユーザインタレストを受ける
ことを更に有する付記１に記載の方法。
（付記５）
前記ユーザに関連するユーザ位置を決定し、
前記複数のマーチャントに関連する店舗位置を決定し、
前記ユーザ位置からの距離の閾範囲内にある店舗位置を持ったマーチャントのサブセットを識別する
ことを更に有する付記１に記載の方法。
（付記６）
前記複数のオファーを、前記ユーザ位置からの距離の前記閾範囲内にある店舗位置を持った前記マーチャントのサブセットからのフィルタをかけられたオファーに狭めるように、前記複数のマーチャントからの前記複数のオファーにフィルタをかけることを更に有し、
前記ユーザと前記複数のオファーのうちのあるオファーとの間の一致を識別することは、前記ユーザと前記フィルタをかけられたオファーのうちのあるオファーとの間の一致を識別することを有し、
前記クーポンは、短縮された期間内に引き換えるための緊急インセンティブを提供する緊急ボーナスを更に含む、
付記５に記載の方法。
（付記７）
前記ユーザに関連するアドレス、買い物の好み、及びクーポンのタイプへの関心のうちの１つ以上に関する情報を前記ユーザから受ける
ことを更に有する付記１に記載の方法。
（付記８）
動作を実行するよう又は該動作の実行を制御するようプロセッサによって実行可能なコンピュータ可読命令を記憶した非一時的なコンピュータ可読媒体であって、
前記動作は、
ユーザに関連する１つ以上のユーザインタレストを決定し、
複数のマーチャントからの複数のオファーであり、夫々が、品物又はサービスを購入するための購入インセンティブと、前記品物又はサービスに関連するインタレストのカテゴリとを含む前記複数のオファーを受け、
前記ユーザに関連する前記１つ以上のユーザインタレストを、前記品物又はサービスに関連する前記インタレストのカテゴリと照合して、前記ユーザと前記複数のオファーのうちのあるオファーとの間の一致を識別し、
デマンドレスポンスイベントに関連する期間を決定し、
前記ユーザのためのクーポンであり、前記オファーと、指定された物理的な位置で前記デマンドレスポンスイベントに関連する前記期間の間に当該クーポンを引き換えるための実行インセンティブを提供する実行ボーナスとを含む前記クーポンを生成し、
前記指定された物理的な位置での引き換えのために前記ユーザに前記クーポンを提供し、前記ユーザによる前記指定された物理的な位置での前記クーポンの引き換えは、前記ユーザに関連する居住場所でのリソース消費の減少を引き起こす
ことを有する、非一時的なコンピュータ可読媒体。
（付記９）
前記クーポンは、前記デマンドレスポンスイベントに関連する前記期間の間に前記クーポンを引き換えることに同意するためのサインアップインセンティブを提供するサインアップボーナスを更に含む、
付記８に記載の非一時的なコンピュータ可読媒体。
（付記１０）
デマンドレスポンスイベントに基づきリソースを入札する方法であって、
デマンドレスポンスイベントに関連する目標費用及び目標リソース削減を決定し、
マーチャントからの複数のオファーを受け、
複数のユーザの夫々が、前記マーチャントからの複数のオファーのうちの１つ以上を含むクーポンを、指定された物理的な位置で前記デマンドレスポンスイベントに関連する期間の間に引き換える可能性を決定し、
前記目標費用、前記目標リソース削減、及び前記複数のユーザの夫々が前記クーポンを引き換える前記可能性に基づき、前記複数のユーザのうちの一部へのクーポンの組を生成し提供し、前記複数のユーザのうちの１以上のユーザによる前記指定された物理的な位置での前記クーポンの組に含まれる１以上のクーポンの引き換えは、前記複数のユーザのうちの前記１以上のユーザに関連する１つ以上の居住位置でのリソース消費の減少を引き起こし、
前記クーポンを受ける前記複数のユーザのうちの前記一部に基づき、前記リソースの総削減量を推定し、
前記総削減量に基づき前記リソースについての提供価格及び量を提供することによって、１日前市場で前記リソースを入札する
ことを有する方法。
（付記１１）
前記リソースの前記総削減量に基づき利益を最大にするように供給曲線のパラメータを決定することを更に有し、
前記リソースについての前記提供価格及び前記量は、前記利益に基づく、
付記１０に記載の方法。
（付記１２）
前記利益を決定することは、
前記１日前市場から前記リソースを購入する価格に、提示されたＤＲ入札についての精算需要を乗じたものを含むリソースクレジットを決定し、
前記リソースクレジットからデマンドレスポンスインセンティブのための価格を減じる
ことを有する、付記１１に記載の方法。
（付記１３）
前記利益を決定することは、前記リソースについての前記提供価格及び前記量を決定するように供給曲線を生成することに基づく、
付記１２に記載の方法。
（付記１４）
前記利益を決定することは、前記１日前市場での１日前価格予測と、実時間市場での実時間価格予測とを、夫々累積分布関数により、確率論的関数としてモデリングすることを有する、
付記１２に記載の方法。
（付記１５）
夫々のクーポンは、前記指定された物理的な位置で前記デマンドレスポンスイベントに関連する前記期間の間に当該クーポンを引き換えるための実行インセンティブを提供する実行ボーナス及びオファーを含む、
付記１０に記載の方法。
（付記１６）
新しい情報に基づき前記目標費用及び前記目標リソース削減を更新し、
前記更新された目標費用、前記更新された目標リソース削減、及び前記複数のユーザの夫々が前記クーポンを引き換える前記可能性に基づき、前記複数のユーザのうちの更なる一部への更なるクーポンの組を生成し提供し、
前記更新された目標費用及び前記更新された目標リソース削減を提供することによって、時間前市場で前記リソースを入札する
ことを更に有する付記１０に記載の方法。
（付記１７）
前記複数のユーザの夫々が前記クーポンを前記指定された物理的な位置で前記デマンドレスポンスイベントに関連する前記期間の間に引き換える前記可能性を決定することは、前記ユーザの夫々によって指定されるインタレストに基づく、
付記１０に記載の方法。
（付記１８）
前記クーポンを受ける前記複数のユーザのうちの前記一部に基づき前記リソースの前記総削減量を推定することは、前記複数のユーザのうちの前記一部に含まれる夫々のユーザが前記クーポンを引き換える可能性に、前記複数のユーザのうちの前記一部に含まれる夫々のユーザについての負荷低減を乗じたものの和を決定することを含む、
付記１０に記載の方法。
（付記１９）
前記負荷低減を決定することは、前記ユーザの夫々の居住位置でのアプライアンスのタイプと、前記クーポンを受ける前記複数のユーザの夫々の居住位置での前記アプライアンスのタイプに関連するリソース消費とを決定することに基づく、
付記１８に記載の方法。
（付記２０）
前記複数のユーザのうちの前記一部に含まれる夫々のユーザが前記クーポンを引き換える可能性、及び前記複数のユーザのうちの前記一部に含まれる夫々のユーザについての前記負荷低減は、独立変数である、
付記１８に記載の方法。
【符号の説明】
【０１２２】
１００  ＤＲシステム
１０１  ＤＲサーバ
１０５  ネットワーク
１１１  ＤＲアプリケーション
１１５  マーチャントサーバ
１２０  ユーザ装置
１２１  クーポンアプリケーション
１３４  サードパーティサーバ
２００  装置
２０２  登録モジュール
２０４  ＤＲモジュール
２０６  クーポンモジュール
２０８  ユーザインタフェースモジュール
２１０  測定及び検証モジュール
２１２  システムデータ
２２５  プロセッサ装置
２２７  メモリ
３００  グラフィカルユーザインタフェース
３０５  オファー
３１０  実行インセンティブ
３１５  サインアップインセンティブ
【図１】
2016143412.tif 000007
【図２】
2016143412.tif 000008
【図３】
2016143412.tif 000009
【図４】
2016143412.tif 000010
【図５】
2016143412.tif 000011