(57)【特許請求の範囲】
【請求項１】
宅外ネットワークとそれぞれが異なる宅内ネットワークとを接続する複数の接続装置に前記宅外ネットワークを介して接続される組み合わせ生成装置であって、
第１の接続装置に第１の宅内ネットワークを介して接続された機器によって提供されたサービスを利用した機器に第２の宅内ネットワークを介して接続された第２の接続装置から、当該サービスに関して評価された信頼度を受信する第１の受信部と、
前記第１の受信部によって受信された信頼度を、前記第１の接続装置の識別情報に対応付けて記憶する記憶部と、
いずれかの前記接続装置から、前記サービスを提供可能な機器に接続された前記接続装置の検索要求を受信すると、前記各接続装置に関して前記記憶部に記憶されている信頼度の履歴に基づいて、いずれかの前記接続装置を選択し、選択された前記接続装置の識別情報を応答する検索部と、
を有することを特徴とする組み合わせ生成装置。
【請求項２】
前記検索部によって選択され、サービスを提供中の機器に前記宅内ネットワークを介して接続された前記接続装置から、当該サービスの提供状況を示す情報を受信する第２の受信部と、
前記第２の受信部によって受信された情報に基づいて、当該サービスに関する料金を算出する算出部と、
を有することを特徴とする請求項１記載の組み合わせ生成装置。
【請求項３】
宅外ネットワークとそれぞれが異なる宅内ネットワークとを接続する複数の接続装置に前記宅外ネットワークを介して接続される組み合わせ生成装置であって、
１以上の機器によって提供されたサービスを利用した機器に前記宅内ネットワークを介して接続された１以上の接続装置から、当該サービスに関して評価された信頼度を受信する第３の受信部と、
前記第３の受信部によって受信された信頼度を、前記サービスを提供した機器に宅内ネットワークを介して接続された前記接続装置の識別情報に対応付けて記憶する記憶部と、
サービスを提供する機器と前記宅内ネットワークを介して接続された前記接続装置から、サービスの提供条件を定期的に受信し、サービスを利用する機器と前記宅内ネットワークを介して接続された前記接続装置から、サービスの利用条件を定期的に受信する第４の受信部と、
前記提供条件及び前記利用条件と、前記各接続装置に関して前記記憶部に記憶されている信頼度の履歴とに基づいて、前記サービスの提供元と前記サービスの利用先との組み合わせを生成する生成部と、
を有することを特徴とする組み合わせ生成装置。
【請求項４】
宅外ネットワークとそれぞれが異なる宅内ネットワークとを接続する複数の接続装置に前記宅外ネットワークを介して接続されるコンピュータが、
第１の接続装置に第１の宅内ネットワークを介して接続された機器によって提供されたサービスを利用した機器に第２の宅内ネットワークを介して接続された第２の接続装置から、当該サービスに関して評価された信頼度を受信する第１の受信手順と、
前記第１の受信手順において受信された信頼度を、前記第１の接続装置の識別情報に対応付けて記憶部に記憶する記憶手順と、
いずれかの前記接続装置から、前記サービスを提供可能な機器に接続された前記接続装置の検索要求を受信すると、前記各接続装置に関して前記記憶部に記憶されている信頼度の履歴に基づいて、いずれかの前記接続装置を選択し、選択された前記接続装置の識別情報を応答する検索手順と、
を実行することを特徴とする組み合わせ生成方法。
【請求項５】
前記検索手順において選択され、サービスを提供中の機器に前記宅内ネットワークを介して接続された前記接続装置から、当該サービスの提供状況を示す情報を受信する第２の受信手順と、
前記第２の受信手順において受信された情報に基づいて、当該サービスに関する料金を算出する算出手順と、
を前記コンピュータが実行することを特徴とする請求項４記載の組み合わせ生成方法。
【請求項６】
宅外ネットワークとそれぞれが異なる宅内ネットワークとを接続する複数の接続装置に前記宅外ネットワークを介して接続されるコンピュータが、
１以上の機器によって提供されたサービスを利用した機器に前記宅内ネットワークを介して接続された１以上の接続装置から、当該サービスに関して評価された信頼度を受信する第３の受信手順と、
前記第３の受信手順において受信された信頼度を、前記サービスを提供した機器に宅内ネットワークを介して接続された前記接続装置の識別情報に対応付けて記憶部に記憶する記憶手順と、
サービスを提供する機器と前記宅内ネットワークを介して接続された前記接続装置から、サービスの提供条件を定期的に受信し、サービスを利用する機器と前記宅内ネットワークを介して接続された前記接続装置から、サービスの利用条件を定期的に受信する第４の受信手順と、
前記提供条件及び前記利用条件と、前記各接続装置に関して前記記憶部に記憶されている信頼度の履歴とに基づいて、前記サービスの提供元と前記サービスの利用先との組み合わせを生成する生成手順と、
を実行することを特徴とする組み合わせ生成方法。
【請求項７】
請求項１乃至３いずれか一項記載の各部としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、組み合わせ生成装置、組み合わせ生成方法、及びプログラムに関する。
【背景技術】
【０００２】
スマートグリッドは、従来の電力ネットワークに対して情報通信技術を融合することで実現される電力の供給システムである。スマートグリッドにおいて、電力の供給元（電源）は、例えば、自然エネルギー等を用いた発電源を備えた各家庭に分散される。したがって、スマートグリッドが普及すれば、電源と需要家との関係は、１：Ｎのツリー構造からＮ：Ｍへ移行するものと考えられる。
【０００３】
このようなスマートグリッドに関して、非特許文献１では、所定のアルゴリズムによってマッチングされた分散電源と需要家とのＰ２Ｐ（peer to peer）通信によって、同時同量の制御（電力の需給制御）を行うことが提案されている。
【０００４】
図１は、Ｐ２Ｐ通信による同時同量の制御を説明するための図である。図１において、ＨＧＷ５０ｘは、分散電源の１つである家庭Ｘに設置されたホームゲートウェイである。ＨＧＷ５０ｙは、需要家の１つである家庭Ｙに設置されたホームゲートウェイである。なお、ホームゲートウェイについては、非特許文献１等において詳しい。
【０００５】
図１では、家庭Ｘによる供給と家庭Ｙによる需要とがマッチングされて、ＨＧＷ５０ｘとＨＧＷ５０ｙとの間のＰ２Ｐ通信に基づいて、家庭Ｘにおいて発電され、家庭Ｙにおいて消費される電力について、同時同量の制御が行われる例が示されている。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】浅見康介，遠藤光泰，沓澤遼，山本草詩，高島研也，竹下秀俊，山中直明，スマートグリッド環境下におけるPIAXを活用した電力の需給マッチング手法，信学技報，vol. 114, no. 478, IN2014-170，pp. 289-294，2015年3月.
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、非特許文献１よる需給マッチング方法では、事前の約束通りに電力の供給を行わない者や、消費した分の電力量に見合った料金を支払わない者等、信頼性の低いユーザを排除するのは困難であると考えられる。
【０００８】
本発明は、上記の点に鑑みてなされたものであって、サービスの利用者に対して信頼性の高い提供者を組み合わせることを目的とする。
【課題を解決するための手段】
【０００９】
そこで上記課題を解決するため、宅外ネットワークとそれぞれが異なる宅内ネットワークとを接続する複数の接続装置に前記宅外ネットワークを介して接続される組み合わせ生成装置は、第１の接続装置に第１の宅内ネットワークを介して接続された機器によって提供されたサービスを利用した機器に第２の宅内ネットワークを介して接続された第２の接続装置から、当該サービスに関して評価された信頼度を受信する第１の受信部と、前記第１の受信部によって受信された信頼度を、前記第１の接続装置の識別情報に対応付けて記憶する記憶部と、いずれかの前記接続装置から、前記サービスを提供可能な機器に接続された前記接続装置の検索要求を受信すると、前記各接続装置に関して前記記憶部に記憶されている信頼度の履歴に基づいて、いずれかの前記接続装置を選択し、選択された前記接続装置の識別情報を応答する検索部と、を有する。
【発明の効果】
【００１０】
サービスの利用者に対して信頼性の高い提供者を組み合わせることができる。
【図面の簡単な説明】
【００１１】
【図１】Ｐ２Ｐ通信による同時同量の制御を説明するための図である。
【図２】第１の実施の形態における需給マッチングシステムの構成例を示す図である。
【図３】第１の実施の形態におけるＭ２Ｍプラットフォームのハードウェア構成例を示す図である。
【図４】第１の実施の形態におけるホームゲートウェイ及びＭ２Ｍプラットフォームの機能構成例を示す図である。
【図５】第１の実施の形態における需給マッチングシステムにおいて実行される処理手順の一例を説明するための図である。
【図６】第１の実施の形態におけるペア履歴記憶部の構成例を示す図である。
【図７】第２の実施の形態における需給マッチングシステムにおいて実行される処理手順の一例を説明するための図である。
【図８】第２の実施の形態におけるペア履歴記憶部の構成例を示す図である。
【図９】第３の実施の形態におけるホームゲートウェイ及びＭ２Ｍプラットフォームの機能構成例を示す図である。
【図１０】第３の実施の形態における需給マッチングシステムにおいて実行される処理手順の一例を説明するための図である。
【図１１】需要情報記憶部の構成例を示す図である。
【図１２】供給情報記憶部の構成例を示す図である。
【図１３】第４の実施の形態においてホームゲートウェイに接続される機器の一例を示す図である。
【発明を実施するための形態】
【００１２】
以下、図面に基づいて本発明の実施の形態を説明する。図２は、第１の実施の形態における需給マッチングシステムの構成例を示す図である。図２に示されるユーザ宅Ｈａ、Ｈｂ、及びＨｃのそれぞれの宅内には、ホームネットワーク（以下、「宅内ネットワーク」という。））Ｎｉａ、Ｎｉｂ、Ｎｉｃが構築されている。また、ユーザ宅Ｈａ、Ｈｂ、及びＨｃのそれぞれには、ＨＧＷ２０ａ、ＨＧＷ２０ｂ、又はＨＧＷ２０ｃが設置されている。以下、ユーザ宅Ｈａ、Ｈｂ、及びＨｃを区別しない場合、「ユーザ宅Ｈ」という。また、宅内ネットワークＮｉａ、Ｎｉｂ、及びＮｉｃを区別しない場合、「宅内ネットワークＮｉ」という。更に、ＨＧＷ２０ａ、ＨＧＷ２０ｂ、及びＨＧＷ２０ｃを区別しない場合、「ＨＧＷ２０」という。なお、ユーザ宅Ｈは、需給マッチングシステムのユーザの家庭、オフィス、又はビル等である。
【００１３】
ＨＧＷ２０は、宅内ネットワークＮｉと、宅外の情報通信網である宅外ネットワークＮｏとを接続するホームゲートウェイと呼ばれる装置である。図２において、各ＨＧＷ２０は、ファイアウォールＦＷを介して、宅外ネットワークＮｏに接続される。なお、ファイアウォールＦＷは、ＨＧＷ２０によって実現されてもよいし、ＨＧＷ２０と異なる装置によって実現されてもよい。
【００１４】
各ユーザ宅Ｈの宅内の情報通信網である宅内ネットワークＮｉに接続された各機器は、電力を消費する機器又は電力を発電する機器である。例えば、或るユーザ宅Ｈの機器は、他のユーザ宅Ｈの機器によって発電された電力を消費して動作することができる。なお、電力を発電する機器は、例えば、ソーラーパネル等を含む太陽光発電システムである。太陽光発電システムには蓄電池が含まれてもよい。電力を消費する機器は、例えば、家電、照明器具等である。なお、各機器は、宅内ネットワークＮｉを介してホームゲートウェイに接続される。
【００１５】
本実施の形態では、便宜上、ユーザ宅Ｈａには電力を消費する機器が設置されており、ユーザ宅Ｈｂ及びＨｃには、電力を発電する機器が設置されていることとする。すなわち、ユーザ宅Ｈａは、需要家であり、ユーザ宅Ｈｂ及びＨｃは、電力供給元であるとする。
【００１６】
なお、需給マッチングシステムには、４つ以上のユーザ宅Ｈが含まれてもよい。
【００１７】
各ユーザ宅ＨのＨＧＷ２０は、宅外ネットワークＮｏを介してＭ２Ｍプラットフォーム１０に接続される。Ｍ２Ｍプラットフォーム１０は、１以上のコンピュータによって構成されるコンピュータシステムである。
【００１８】
図３は、第１の実施の形態におけるＭ２Ｍプラットフォームのハードウェア構成例を示す図である。図３のＭ２Ｍプラットフォーム１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
【００１９】
Ｍ２Ｍプラットフォーム１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００２０】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってＭ２Ｍプラットフォーム１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００２１】
なお、それぞれが図３に示される構成を有する複数のコンピュータが、Ｍ２Ｍプラットフォーム１０を構成してもよい。また、各ＨＧＷ２０も、図３に示されるハードウェア構成を有していてもよい。
【００２２】
図４は、第１の実施の形態におけるホームゲートウェイ及びＭ２Ｍプラットフォームの機能構成例を示す図である。図４において、ＨＧＷ２０は、登録要求部２０１、検索要求部２０２、交渉部２０３、ペア通知部２０４、状況送信部２０５、クレジット評価部２０６、終了通知部２０７、及びブラックリスト登録部２０８等を有する。これら各部は、ＨＧＷ２０にインストールされた１以上のプログラムが、ＨＧＷ２０のＣＰＵに実行させる処理により実現される。
【００２３】
登録要求部２０１は、ＨＧＷ２０の登録要求をＭ２Ｍプラットフォーム１０に送信する。検索要求部２０２は、電力の供給元の検索要求をＭ２Ｍプラットフォーム１０に送信する。交渉部２０３は、Ｍ２Ｍプラットフォーム１０によって検索（選択）された供給元に係るＨＧＷ２０との間で、電力の取り引きに関する交渉を行う。ペア通知部２０４は、交渉部２０３による交渉が成功した場合、すなわち、電力の需給に関してペア（組み合わせ）が成立した場合に、当該ペアを示す情報をＭ２Ｍプラットフォーム１０に送信する。状況送信部２０５は、ペア間における電力の同時同量の制御中において、電力の供給状況又は消費状況を示す情報をＭ２Ｍプラットフォーム１０に送信する。クレジット評価部２０６は、当該ＨＧＷ２０が電力の需要側（消費側）である場合に、電力の供給状況に基づいて、供給元の信頼度を評価する。以下、当該信頼度を「クレジット」という。本実施の形態において、クレジットは、１０点満点の数値であるとする。但し、クレジットは、１００点満点であってもよいし、他の尺度によって表現されてもよい。終了通知部２０７は、同時同量の制御が終了した際に、ペアの終了（解消）をＭ２Ｍプラットフォーム１０に通知する。この際、供給元に対するクレジットも通知される。ブラックリスト登録部２０８は、電力の供給状況に対するクレジットが所定値未満である場合、電力の供給元について、ブラックリストへの登録要求をＭ２Ｍプラットフォーム１０に送信する。ブラックリストとは、電力の取り引きに関する信頼性が著しく低いユーザ宅Ｈ（ＨＧＷ２０）の一覧情報をいう。
【００２４】
一方、Ｍ２Ｍプラットフォーム１０は、マッチング検索部１１、認証部１２、連絡部１３、料金決済部１４、及び状況受信部１５等を有する。これら各部は、Ｍ２Ｍプラットフォーム１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。又は、これら各部は、複数のサーバコンピュータに分散されて実現されてもよい。Ｍ２Ｍプラットフォーム１０は、また、ユーザ一覧記憶部１２１、ブラックリスト記憶部１２２、ペア履歴記憶部１２３、消費ログ記憶部１２４、及び供給ログ記憶部１２５等を利用する。これら各記憶部は、例えば、補助記憶装置１０２、Ｍ２Ｍプラットフォーム１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
【００２５】
マッチング検索部１１は、電力の供給元の検索要求に応じて、供給元のユーザ宅Ｈ（ＨＧＷ２０）を検索（選択）する。供給元の選択は、各ユーザ宅（各ＨＧＷ２０）に関してペア履歴記憶部１２３に記憶されているクレジットの履歴に基づいて行われる。認証部１２は、ブラックリスト記憶部１２２に記憶されているブラックリストを管理する。連絡部１３は、電力の需給に関して生成されたペア間に関して、非図示の電力系のシステムに対して同時同量の制御の要求等を行う。料金決済部１４は、電力の供給に対する料金を算出すると共に、当該料金の決済を代行する。状況受信部１５は、同時同量の制御中において、需要側のＨＧＷ２０及び供給元のＨＧＷ２０のそれぞれから、電力の消費状況又は電力の供給状況を示す情報を受信する。
【００２６】
ユーザ一覧記憶部１２１は、Ｍ２Ｍプラットフォーム１０に対して登録要求を送信した各ＨＧＷ２０（各ユーザ宅Ｈ）の一覧情報を記憶する。ペア履歴記憶部１２３は、電力の需給に関して生成されたペアに関する履歴を記憶する。消費ログ記憶部１２４は、状況受信部１５によって受信される電力の消費状況を示す情報を記憶する。供給ログ記憶部１２５は、状況受信部１５によって受信される電力の供給状況を示す情報を記憶する。
【００２７】
以下、需給マッチングシステムにおいて実行される処理手順について説明する。図５は、第１の実施の形態における需給マッチングシステムにおいて実行される処理手順の一例を説明するための図である。
【００２８】
各ＨＧＷ２０の登録要求部２０１は、例えば、起動時等において、当該ＨＧＷ２０（当該ＨＧＷ２０に係るユーザ宅Ｈ）の存在を通知するための登録要求をマッチング検索部１１に送信する（ステップＳ１０１〜Ｓ１０３）。各登録要求には、各ＨＧＷ２０（各ユーザ宅Ｈ）の識別情報であるユーザＩＤと、各ユーザ宅Ｈの属性情報等とを含むユーザ情報が指定される。本実施の形態において、ユーザＩＤは、各ＨＧＷ２０に対して割り当てられたＩＰアドレスであるとする。また、ユーザ宅Ｈの属性情報には、電力の供給の可否を示す情報が含まれる。但し、全てのユーザ宅Ｈが電力を供給可能な場合、当該情報は属性情報に含まれなくてもよい。マッチング検索部１１は、受信された登録要求ごとに、当該登録要求に指定されているユーザ情報を、ユーザ一覧記憶部１２１に記憶する。
【００２９】
その後、電力の需要が発生時等、任意のタイミングにおいて、ユーザ宅ＨａのＨＧＷ２０ａの検索要求部２０２は、電力の供給元の検索要求を、マッチング検索部１１に送信する（ステップＳ１０４）。当該検索要求には、ＨＧＷ２０ａに係るユーザＩＤが指定される。なお、電力の需要の発生とは、必ずしも、現時点の電力の需要でなく、将来における電力の需要であってもよい。
【００３０】
マッチング検索部１１は、当該検索要求に応じ、認証部１２に対してブラックリストを要求する（ステップＳ１０５）。認証部１２は、ブラックリスト記憶部１２２からブラックリストを取得し、当該ブラックリストをマッチング検索部１１に通知する（ステップＳ１０６）。続いて、マッチング検索部１１は、ユーザ宅Ｈａに対する電力の供給元を選択する（ステップＳ１０７）。具体的には、マッチング検索部１１は、ユーザ一覧記憶部１２１に記憶されているユーザ情報の一覧の中から、電力を供給可能であることを示す属性を含むユーザ情報の一覧を抽出する。マッチング検索部１１は、抽出されたユーザ情報の一覧から、ブラックリストに含まれているユーザＩＤを含むユーザ情報と、当該検索要求元のユーザＩＤを含むユーザ情報とを除去する。続いて、マッチング検索部１１は、残ったユーザ情報の一覧（以下、「候補一覧」という。）のそれぞれのユーザＩＤについて、過去Ｎ回の電力の取り引きにおけるクレジットの平均値を算出する。クレジットの平均値は、ペア履歴記憶部１２３を参照して算出することができる。
【００３１】
図６は、第１の実施の形態におけるペア履歴記憶部の構成例を示す図である。図６に示されるペア履歴記憶部１２３には、電力の需給に関して過去に生成されたペアごと（すなわち、過去における電力の取り引き（同時同量の制御）ごと）に、レコードが記憶されている。各レコードは、需要側ＩＤ、供給元ＩＤ、単価、開始日時、終了日時、及び供給元クレジット等の項目を含む。
【００３２】
需要側ＩＤは、電力の需要側の（すなわち、電力を消費した）ユーザ宅ＨのユーザＩＤである。供給元ＩＤは、電力の供給元のユーザ宅ＨのユーザＩＤである。単価は、ペア間において決定された電力の単価である。開始日時は、ペア間における同時同量制御の開始日時である。終了日時は、当該同時同量制御の終了日時である。供給元クレジットは、需要側のユーザ宅ＨのＨＧＷ２０によって、供給元のユーザ宅Ｈ（ＨＧＷ２０）に対して与えられたクレジットである。
【００３３】
マッチング検索部１１は、候補一覧に含まれるユーザＩＤごとに、当該ユーザＩＤを供給元ＩＤとするレコードのうち新しい順にＮ件のレコードを、ペア履歴記憶部１２３から取得する。または、当該ユーザＩＤを供給元ＩＤとする全てのレコードが取得されてもよい。マッチング検索部１１は、検索されたレコードの供給元クレジットの総和を求め、当該総和をレコードの件数（例えば、Ｎ）で除することで、クレジットの平均値を算出する。マッチング検索部１１は、クレジットの平均値が最大であるユーザＩＤを特定する。すなわち、クレジットの平均値が最大であるユーザＩＤに係るユーザ宅Ｈが、供給元として選択される。なお、クレジットの平均値ではなく、クレジットの合計値が最大であるユーザＩＤが、供給元として選択されてもよい。
【００３４】
続いて、マッチング検索部１１は、供給元として選択されたユーザ宅ＨのユーザＩＤを含む応答を、ＨＧＷ２０ａの検索要求部２０２に返信する（ステップＳ１０８）。
【００３５】
ＨＧＷ２０ａの検索要求部２０２によって当該応答が受信されると、ＨＧＷ２０ａの交渉部２０３は、電力の取り引きに関するペアの相手になることの要求（ペア要求）を、当該応答に含まれているユーザＩＤに係るＨＧＷ２０に送信する（ステップＳ１０９）。図５では、ＨＧＷ２０ｃが、当該ＨＧＷ２０である例が示されている。なお、当該ペア要求がユーザ宅ＨｃのファイアウォールＦＷを通過可能とするために、マッチング検索部１１は、ステップＳ１０８の前に、電力の供給元として選択されたことを示し、ＨＧＷ２０ａのユーザＩＤを含む通知を、ＨＧＷ２０ｃに送信してもよい。ＨＧＷ２０ｃは、当該ユーザＩＤに係る要求がファイアウォールＦＷを通過可能なようにするための設定を、ユーザ宅ＨｃのファイアウォールＦＷに対して行ってもよい。同様に、ＨＧＷ２０ａは、ユーザ宅ＨａのファイアウォールＦＷに対して、ＨＧＷ２０ｃからの通知等を通過可能にするための設定を行ってもよい。ＨＧＷ２０ａとＨＧＷ２０ｃとが異なるＮＡＴ（Network Address Translation）配下に配置されている場合には、ＷｅｂＲＴＣ（Web Real-Time Communication）等の仕組みを利用することで、ＨＧＷ２０間の通信が確立されてもよい。
【００３６】
続いて、ＨＧＷ２０ａの交渉部２０３と、ＨＧＷ２０ｃの交渉部２０３との間で、電力の需給に関する交渉（ネゴシエーション）がＰ２Ｐ（peer-to-peer）で行われる（ステップＳ１１０）。例えば、必要な電力量（上限値、平均値、変動予想等）や、開始予定日時及び終了予定日時等が、需要側のＨＧＷ２０ａからＨＧＷ２０ｃへ通知される。また、希望単価が、供給元のＨＧＷ２０ｃからＨＧＷ２０ａへ通知される。双方の交渉部２０３は、相手の条件を許容可能か否かを判定して、判定結果を相手に返信する。なお、需要側に関して、必要な電力量、開始予定日時、及び終了予定日時等は、予めユーザによって設定されてもよいし、過去の電力の消費状況に基づいて自動的に算出されてもよい。過去の電力の消費状況は、例えば、宅内ネットワークＮｉａを介して接続されるスマートメータから取得されてもよい。また、需要側のＨＧＷ２０ａには、単価の上限値が予め設定されていてもよい。供給元の希望単価が、当該上限値以下であれば、供給元の条件が許容可能であると判定されてもよい。一方、供給元のＨＧＷ２０ｃは、宅内ネットワークＮｉｃを介して接続される発電機器による発電状況に基づいて、需要側の条件を許容可能であるか否かを判定してもよい。
【００３７】
少なくともいずれか一方が他方の条件を拒否した場合、ステップＳ１０４以降が繰り返されてもよい。この場合、再度のステップＳ１０４において、ＨＧＷ２０ａの検索要求部２０２は、ユーザ宅Ｈｃを供給元から除外することを示すパラメータを検索要求に含めてもよい。
【００３８】
双方が相手の条件を許容可能である場合、ＨＧＷ２０ａのペア通知部２０４は、電力の需給に関してペアが成立したことを示すペア通知を、料金決済部１４に送信する（ステップＳ１１１）。当該ペア通知には、需要側のユーザＩＤ、供給元のユーザＩＤ、単価、開始予定日時、及び終了予定日時等が含まれる。料金決済部１４は、当該ペア通知を受信すると、当該ペア通知に係るペアに対応するレコードを、ペア履歴記憶部１２３に記憶する（図６）。この時点では、当該レコードの需要側ＩＤ、供給元ＩＤ、及び単価に対して、ペア通知に含まれていた値が記憶される。
【００３９】
続いて、ペア通知に含まれている開始予定日時が到来すると、連絡部１３は、非図示の電力系のシステムに対して、ユーザ宅Ｈａとユーザ宅Ｈｃとの間での同時同量の制御を要求する。その結果、当該電力系のシステムによって、ユーザ宅Ｈａとユーザ宅Ｈｃとの間で、非図示の電力網を介して同時同量の制御が行われる（ステップＳ１１２）。又は、連絡部１３は、ペア通知に応じて、直ちに、同時同量の制御を電力系のシステムに対して要求してもよい。この場合、ペア通知に含まれていた開始予定日時が、同時同量の制御の開始時刻として電力系のシステムに通知されてもよい。電力系のシステムは、当該開始時刻が到来すると、同時同量の制御を開始してもよい。又は、供給元の選択（ステップＳ１０７）の際に、マッチング検索部１１から電力系のシステムに対して制御の開始日時が通知されてもよい。この場合、例えば、供給元の検索要求（ステップＳ１０４）において、当該開始日時が指定されていてもよい。
【００４０】
なお、Ｍ２Ｍプラットフォーム１０によって決定された需給マッチング（ペア）に関する情報は、電力系のシステムに通知されると、今後の電力需給関係の変化予想等において、付加的な情報として用いられ、より安定した電力網の構成に寄与しうる。
【００４１】
同時同量の制御が行われている間、ペアであるＨＧＷ２０ａ及びＨＧＷ２０ｃのそれぞれの状況送信部２０５は、それぞれの状況を示す情報を、Ｍ２Ｍプラットフォーム１０の状況受信部１５に対して送信する。例えば、ＨＧＷ２０ａからは、一定間隔（例えば、１０秒間隔又は３０秒間隔等）ごとに、電力の消費量が送信される。電力の消費量は、宅内ネットワークＮｉａを介してＨＧＷ２０ａに接続されているスマートメータから取得されてもよい。また、ＨＧＷ２０ｃからは、一定間隔（例えば、１０秒間隔又は３０秒間隔等）ごとに、発電量が送信される。発電量は、宅内ネットワークＮｉｃを介してＨＧＷ２０ｃに接続されている発電機器から取得されてもよい。状況受信部１５は、ＨＧＷ２０ａから受信した情報を、消費ログとして、消費ログ記憶部１２４に記憶し、ＨＧＷ２０ｃから受信した情報を、供給ログとして、供給ログ記憶部１２５に記憶する。なお、消費ログ及び供給ログが、同時同量の制御に対してフィードバックされてもよい。また、同時同量の制御中に、電力の需給のミスマッチが発生し、その差が一定以上となった場合には、ＨＧＷ２０ａは、現在のペアを解消し、改めてステップＳ１０４以降を実行してもよい。
【００４２】
同時同量の制御が終了すると、ＨＧＷ２０ａのクレジット評価部２０６は、供給元のユーザ宅Ｈｃ（ＨＧＷ２０ｃ）に対するクレジットを評価する（ステップＳ１１３）。例えば、以下のようにクレジットが算出されてもよい。
クレジット＝同時同量の制御期間における供給電力量／同時同量の制御期間において必要だった電力量
但し、他の方法によってクレジットが算出されてもよい。
【００４３】
なお、同時同量の制御は、必ずしも、終了予定時刻まで継続されなくてもよい。例えば、一定時間（例えば、１０秒）ごとにペアが解消され、改めて、ステップＳ１０４以降が実行されてもよい。又は、需要側において電力が不要となったタイミング、若しくは供給元において電力を供給できなくなったタイミングで、需要側又は供給元のＨＧＷ２０が、ペアを解消してもよい。供給元が原因でペアが解消された場合には、改めて、ステップＳ１０４以降が実行されてもよい。また、Ｍ２Ｍプラットフォーム１０が、一定時間ごと（例えば、１秒ごと）に、同時同量の制御を監視し、供給元が供給不足となった場合に、ステップＳ１０７以降を実行してもよい。
【００４４】
続いて、ＨＧＷ２０ａの終了通知部２０７は、クレジット評価部２０６によって評価された、供給元（ユーザ宅Ｈｃ）に対するクレジットを含む終了通知を料金決済部１４に対して送信する（ステップＳ１１４）。料金決済部１４は、当該クレジットを、ペア履歴記憶部１２３に記憶されているレコードのうち、ユーザ宅Ｈａとユーザ宅Ｈｃとのペアに係るレコードの供給元クレジットとして記憶する。
【００４５】
続いて、ブラックリスト登録部２０８は、クレジット評価部２０６によって算出されたクレジットが所定値未満である場合には、供給元のユーザＩＤについて、ブラックリストへの登録要求を認証部１２に送信する（ステップＳ１１５）。認証部１２は、当該登録要求に含まれているユーザＩＤを、ブラックリスト記憶部１２２に記憶されているブラックリストに追加する。
【００４６】
なお、上記では、Ｍ２Ｍプラットフォーム１０によって供給元が選択される（すなわち、需給マッチングが行われる）例について説明したが、供給元の選択は、需要側のＨＧＷ２０（図５では、ＨＧＷ２０ａ）によって行われてもよい。この場合、ステップＳ１０４〜Ｓ１０８の代わりに、ＨＧＷ２０ａが、Ｍ２Ｍプラットフォーム１０から、ユーザ情報の一覧、ブラックリスト、及びペア履歴記憶部１２３に記憶されているレコードを取得して、供給元を選択してもよい。供給元の選択処理の内容は、図５のステップＳ１０７と同様でもよい。
【００４７】
需要側のＨＧＷ２０によって供給元が選択される場合、各ＨＧＷ２０がペア履歴記憶部１２３を有するようにしてもよい。この場合、各ＨＧＷ２０のペア履歴記憶部１２３には、当該ＨＧＷ２０がペアのいずれか一方だった取り引きに関するレコードが記憶されればよい。当該ＨＧＷ２０が需要側だったペアに対するレコードについては、供給元クレジットに値が記憶されればよい。この場合、需要側のＨＧＷ２０は、他の各ＨＧＷ２０のそれぞれのペア履歴記憶部１２３に記憶されているレコードを取得して、他の各ユーザ宅Ｈのクレジットの履歴を入手してもよい。
【００４８】
上述したように、第１の実施の形態によれば、電力の取り引きが行われるたびに供給元に対して付与されるクレジットの履歴に基づいて、電力の供給元が選択される。したがって、電力の需要側に対して、相対的に信頼性の高い供給元をマッチングすることができる。すなわち、電力の供給といったサービスの利用者（消費者）に対して信頼性の高い提供者（供給者）を組み合わせることができる。
【００４９】
次に、第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。第２の実施の形態では、電力の使用に関する料金の決済について説明する。
【００５０】
図７は、第２の実施の形態における需給マッチングシステムにおいて実行される処理手順の一例を説明するための図である。なお、図７では、図５における需給マッチングが前提とされている。すなわち、ユーザ宅Ｈａとユーザ宅Ｈｃとがペアであり、ユーザ宅Ｈａが需要側、ユーザ宅Ｈｃが供給元である。
【００５１】
ステップＳ２０１において、料金決済部１４は、ＨＧＷ２０ａから終了通知を受信する（ステップＳ２０１）。ステップＳ２０１は、図５のステップＳ１１４に相当する。続いて、料金決済部１４は、ＨＧＷ２０ｃから料金の代行徴収要求を受信すると（ステップＳ２０２）、ユーザ宅Ｈｃが供給した電力についての料金を算出する（ステップＳ２０３）。具体的には、料金決済部１４は、ペア履歴記憶部１２３に記憶されているレコードのうち、代行徴収要求に含まれているユーザ宅ＨｃのユーザＩＤが供給元として記憶されている最後のレコードを参照して、当該レコードの需要側ＩＤに基づいて、電力の供給を受けたのがユーザ宅Ｈａであることを特定し、当該レコードの開始日時及び終了日時に基づいて、電力の供給期間を特定する。また、料金決済部１４は、当該レコードの単価に基づいて、当該供給に関する単価を特定する。料金決済部１４は、供給ログ記憶部１２５に記憶されている供給ログの中で、当該供給期間におけるユーザ宅Ｈｃに関する供給ログに基づいて、当該供給期間における電力の供給量を算出し、当該供給量と単価とに基づいて、料金を算出する。
【００５２】
続いて、料金決済部１４は、ユーザ宅Ｈａから、料金を徴収する（ステップＳ２０４）。料金の徴収は、例えば、ユーザ宅Ｈａによって予め登録されている銀行口座からのオンライン取り引きによる引き落としによって行われてもよい。続いて、料金決済部１４は、代行徴収の手数料を徴収した料金から差し引く（ステップＳ２０５）。代行徴収の手数料は、例えば、Ｍ２Ｍプラットフォーム１０の運用者の銀行口座に対してオンライン取り引きによって振り込まれてもよい。続いて、料金決済部１４は、料金から代行徴収の手数料を差し引いた分の金額を、ユーザ宅Ｈｃに対して支払う（ステップＳ２０６）。当該金額の支払いは、例えば、ユーザ宅Ｈｃによって予め登録されている銀行口座に対するオンライン取り引きによる振り込みによって行われてもよい。なお、図７の例では、ユーザ宅Ｈａから６００円が徴収され、代行徴収の手数料として３０円が差し引かれ、ユーザ宅Ｈｃに対して５７０円が支払われた例が示されている。
【００５３】
なお、料金決済部１４は、例えば、ステップＳ２０６に続いて、ユーザ宅Ｈａに対する請求額（６００円）と、ユーザ宅Ｈａから徴収できた金額とを、ユーザ宅ＨｃのＨＧＷ２０ｃに対して送信してもよい。ＨＧＷ２０ｃのクレジット評価部２０６は、請求額と徴収できた金額とに基づいて、ユーザ宅Ｈａに対するクレジットを算出してもよい。例えば、以下のようにクレジットが算出されてもよい。
クレジット＝１０×徴収額／請求額
ＨＧＷ２０ｃのクレジット評価部２０６は、算出したクレジットを、料金決済部１４に対して送信する。料金決済部１４は、当該クレジットを、ペア履歴記憶部１２３に記憶されているレコードのうち、ユーザ宅ａとユーザ宅ｃとのペアに対応するレコードに対して記憶する。
【００５４】
図８は、第２の実施の形態におけるペア履歴記憶部の構成例を示す図である。図８に示されるように、第２の実施の形態において、ペア履歴記憶部１２３の各レコードは、更に、需要側クレジットの項目を有する。需要側クレジットに対しては、供給元のＨＧＷ２０のクレジット評価部２０６によって算出されたクレジットが記憶される。
【００５５】
すなわち、ユーザ宅Ｈａから料金が徴収できない場合も考えられる。例えば、予め登録されている銀行口座の残高が不足していることも考えられる。したがって、徴収額が請求額に満たない可能性も考えられる。徴収額に基づいて、需要側のクレジットを評価することで、電力の供給元は、信頼性の低い需要家に対する電力の供給を回避することができる。例えば、図５のステップＳ１１０のネゴシエーションの際に、供給元のＨＧＷ２０の交渉部２０３は、需要側のクレジットの履歴を、料金決済部１４に照会してもよい。図５の例では、ＨＧＷ２０ｃの交渉部２０３が、ユーザ宅Ｈａに対するクレジットの履歴を、料金決済部１４に照会する。料金決済部１４は、ユーザ宅ＨａのユーザＩＤを需要側ＩＤとするレコードをペア履歴記憶部１２３から検索し、検索された各レコードのクレジットの値をＨＧＷ２０ｃの交渉部２０３に返信する。ＨＧＷ２０ｃの交渉部２０３は、当該クレジットの合計値又は平均値が所定値未満である場合、ＨＧＷ２０ａの交渉部２０３に対して、電力の供給の拒否を通知する。
【００５６】
上述したように、第２の実施の形態のＭ２Ｍプラットフォーム１０は、電力の供給量（すなわち、電力の消費量又は使用量）に応じて、需要側からの料金の徴収を代行することができる。また、電力の需要側に対してもクレジットが評価されるため、供給元は、当該クレジットに基づいて、相対的に信頼性の高い需要側に対して電力を供給することができる。
【００５７】
次に、第３の実施の形態について説明する。第３の実施の形態では第１の実施の形態と異なる点について説明する。第３の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００５８】
図９は、第３の実施の形態におけるホームゲートウェイ及びＭ２Ｍプラットフォームの機能構成例を示す図である。図９中、図４と同一又は対応する部分には同一符号を付し、その説明は省略する。
【００５９】
図９において、ＨＧＷ２０は、更に、供給情報送信部２０９及び需要情報送信部２１０等を有する。これら各部は、ＨＧＷ２０にインストールされた１以上のプログラムが、ＨＧＷ２０のＣＰＵに実行させる処理によって実現される。
【００６０】
供給情報送信部２０９は、当該ＨＧＷ２０に宅内ネットワークＮｉを介して接続された発電機器による発電の状況及び電力の供給条件等を含む情報（以下、「供給情報」という。）を、定期的（例えば、１０秒ごと）にＭ２Ｍプラットフォーム１０に送信する。発電の状況とは、例えば、現在発電されている電力量（ｋＷ）である。また、供給条件とは、例えば、希望単価である。供給情報には、当該ＨＧＷ２０に係るユーザＩＤも含まれる。なお、供給情報送信部２０９は、電力の供給元のユーザ宅ＨのＨＧＷ２０において有効に機能する。
【００６１】
需要情報送信部２１０は、電力に対する需要の状況及び需要条件を示す情報（以下、「需要情報」という。）を、定期的（例えば、１０秒ごと）にＭ２Ｍプラットフォーム１０に送信する。需要の状況とは、例えば、必要電力量（ｋＷ）である。必要電力量は、例えば、宅内ネットワークＮｉを介してＨＧＷ２０に接続されているスマートメータから取得されるデータに基づいて特定されてもよい。また、需要条件とは、例えば、希望単価である。希望単価は、例えば、予めユーザによってＨＧＷ２０に設定されていてもよい。なお、需要情報には、当該ＨＧＷ２０に係るユーザＩＤが含まれる。
【００６２】
なお、第３の実施の形態において、ＨＧＷ２０は、検索要求部２０２、交渉部２０３、及びペア通知部２０４を有していなくてもよい。
【００６３】
一方、Ｍ２Ｍプラットフォーム１０は、供給情報記憶部１２６及び需要情報記憶部１２７等を更に有する。これら各記憶部は、補助記憶装置１０２等を用いて実現可能である。供給情報記憶部１２６は、供給元の各ＨＧＷ２０から定期的に送信され、状況受信部１５によって受信される供給情報の履歴を記憶する。需要情報記憶部１２７は、需要側の各ＨＧＷ２０から定期的に送信され、状況受信部１５によって受信される需要情報の履歴を記憶する。
【００６４】
図１０は、第３の実施の形態における需給マッチングシステムにおいて実行される処理手順の一例を説明するための図である。図１０において、ＨＧＷ２０ａは、需要側に該当し、ＨＧＷ２０ｃは、供給元に該当する。なお、第３の実施の形態では、図５のステップＳ１０４〜Ｓ１１１は、実行されなくてよい。
【００６５】
ＨＧＷ２０ａ等の需要側の各ＨＧＷ２０の需要情報送信部２１０は、定期的に、需要情報を状況受信部１５へ送信する（ステップＳ３０１）。図１０では、需要側のＨＧＷ２０としてＨＧＷ２０ａのみが示されているが、他のＨＧＷ２０からも需要情報が定期的に送信される。状況受信部１５は、需要情報が受信されるたびに、当該需要情報を需要情報記憶部１２７に記憶する（ステップＳ３０２）。
【００６６】
図１１は、需要情報記憶部の構成例を示す図である。図１１において、需要情報記憶部１２７には、受信された需要情報ごとにレコードが記憶される。各レコードは、日時、必要電力量、希望単価、及びユーザＩＤ等を含む。日時は、需要情報が受信された日時である。必要電力量、希望単価、及びユーザＩＤは、需要情報に含まれている値がそのまま記憶される。
【００６７】
また、ＨＧＷ２０ｃ等の供給元の各ＨＧＷ２０の供給情報送信部２０９は、定期的に、供給情報を状況受信部１５へ送信する（ステップＳ３０３）。図１０では、供給元のＨＧＷ２０としてＨＧＷ２０ｃのみが示されているが、他のＨＧＷ２０からも供給情報が定期的に送信される。状況受信部１５は、供給情報が受信されるたびに、当該供給情報を供給情報記憶部１２６に記憶する（ステップＳ３０４）。
【００６８】
図１２は、供給情報記憶部の構成例を示す図である。図１２において、供給情報記憶部１２６には、受信された供給情報ごとにレコードが記憶される。各レコードは、日時、発電量、希望単価、及びユーザＩＤ等を含む。日時は、供給情報が受信された日時である。発電量、希望単価、及びユーザＩＤは、供給情報に含まれている値がそのまま記憶される。
【００６９】
一方、マッチング検索部１１は、一定時間ごと（例えば、１時間ごと）に、ステップＳ３１１以降の処理を実行する。ステップＳ３１１において、マッチング検索部１１は、直近の一定時間において需要情報記憶部１２７に記憶された需要情報の履歴を、需要情報記憶部１２７から取得する。続いて、マッチング検索部１１は、直近の一定時間において供給情報記憶部１２６に記憶された供給情報の履歴を、供給情報記憶部１２６から取得する（ステップＳ３１２）。続いて、マッチング検索部１１は、需要情報の履歴及び供給情報の履歴と、当該履歴に含まれる各需要情報又は各供給情報に含まれている各ユーザＩＤに係るユーザ宅Ｈ（ＨＧＷ２０）に対してペア履歴記憶部１２３に記憶されているクレジットとに基づいて、電力の供給元と需要側とについて、Ｍ：Ｎの組み合わせを生成する（ステップＳ３１３）。すなわち、第３の実施の形態では、電力の供給元と需要側とが必ずしも１対１ではなくてもよい。供給元と需要側とは、１対多、多対多、又は多対１であってもよい。このような組み合わせが複数生成されてもよい。
【００７０】
なお、需要情報に含まれているユーザＩＤに対するクレジットは、ペア履歴記憶部１２３に記憶されているレコードの中で、当該ユーザＩＤを需要側ＩＤとして含むレコードから取得される。また、供給情報に含まれているユーザＩＤに対するクレジットは、ペア履歴記憶部１２３に記憶されているレコードの中で、当該ユーザＩＤを供給元ＩＤとして含むレコードから取得される。
【００７１】
Ｍ：Ｎの組み合わせの生成に際し、マッチング検索部１１は、需要情報の履歴と供給情報の履歴とに基づいて、今後の一定時間の電力の需要量と発電量とを推定する。推定値は、各履歴の値がそのまま用いられたものでもよい。その上で、マッチング検索部１１は、Ｍ個の供給元の発電量の総量とＮ個の需要側の需要量の総量とが一致するように、Ｍ：Ｎの組み合わせを生成する。この際、供給元及び需要側のそれぞれにおいて希望単価が設定されている場合には、各希望単価が満たされるように、組み合わせが生成されてもよい。この場合、供給元の希望単価は、単価の下限値とされる。需要側の希望単価は、単価の上限値とされる。更に、組み合わせに含まれる各ユーザ宅Ｈのクレジットの総和が最大となるように、組み合わせが生成されてもよい。
【００７２】
このような組み合わせは、線形計画のようなアルゴリズムによって最適値を求めることにより生成されてもよいし、ヒューリスティックなアルゴリズムに基づいて生成されてもよい。
【００７３】
続いて、図５のステップＳ１１２以降の処理手順が実行される。この際、電力系のシステムにおいては、Ｍ：Ｎの関係において同時同量の制御が行われる。また、Ｍ個の供給元のそれぞれに対して与えられるクレジットは、例えば、Ｎ個の需要側による、当該Ｍ個の供給元のそれぞれに対するクレジットの履歴に基づいて算出されてもよい。たとえば、Ｍ個の供給元のうちの１つである供給元Ｍ（１）に対するクレジットは、供給元Ｍ（１）に対する、Ｎ個の需要側のそれぞれによる過去のクレジットの平均値であってもよい。同様に、Ｎ個の需要側のそれぞれに対して与えられるクレジットは、例えば、Ｍ個の供給元による、当該Ｎ個の需要側のそれぞれに対するクレジットの履歴に基づいて算出されてもよい（例えば、平均値）。
【００７４】
上述したように、第３の実施の形態によれば、供給元と需要側とについて、Ｍ：Ｎの組み合わせを生成することができる。なお、第３の実施の形態が、第２の実施の形態と組み合わされてもよい。
【００７５】
次に、第４の実施の形態について説明する。第４の実施の形態では上記各実施の形態と異なる点について説明する。第４の実施の形態において特に言及されない点については、上記各実施の形態と同様でもよい。第４の実施の形態では、取り引きの対象が電力以外のサービスである場合について説明する。
【００７６】
図１３は、第４の実施の形態においてホームゲートウェイに接続される機器の一例を示す図である。図１３では、供給元のユーザ宅ＨにおけるＨＧＷ２０に対して、センサやカメラ等が接続される例が示されている。需要側のユーザ宅ＨのＨＧＷ２０には、例えば、センサによって計測されるデータやカメラによって撮像される画像データ等を利用するＰＣ（Personal Computer）等のコンピュータが接続されてもよい。
【００７７】
第４の実施の形態において実行される処理手順は、第１〜第３の実施の形態における処理手順のいずれかと同様でよい。但し、第１の実施の形態の処理手順（図５９を利用する場合、ステップＳ１０４の検索要求には、欲しいデータの種類を示す情報が含まれてもよい。ステップＳ１０７における供給元の選択では、当該情報が示す種類のデータを供給可能なユーザ宅Ｈの中から供給元が選択されればよい。また、第３の実施の形態の処理手順（図１０）を利用する場合、需要情報には、必要電力量の代わりに欲しいデータの種類が含まれればよい。また、供給情報には、発電量の代わりに供給可能なデータの種類を示す情報が含まれればよい。図１０のステップＳ３１３では、データの種類を考慮して、組み合わせが生成されればよい。更に、同時同量の制御のステップにおいては、データの送信が行われればよい。
【００７８】
例えば、需要側のコンピュータが、供給元のセンサによって計測されるデータを利用してリアルタイムの天気予報を実行してもよい。この場合、需要側は、自らが、全国にセンサを配置する必要が無くなり、そのためのコストを削減することができる。また、供給元は、センサ等の機器によって計測されるデータの供給に対して課金を行うことで、利益を得ることができる。また、クレジットに基づいてマッチングが行われることで、需要側は、信頼できるデータを得ることができ、供給元は、信頼できるユーザにデータを提供することができる。なお、料金は、例えば、データ量（ビット数）等に基づいて算出されてもよい。
【００７９】
このように、上記各実施の形態における、需給マッチングは、電力以外のサービスのやりとりに関して適用することもできる。
【００８０】
なお、上記各実施の形態において、Ｍ２Ｍプラットフォーム１０は、組み合わせ生成装置の一例である。ＨＧＷ２０は、接続装置の一例である。マッチング検索部１１は、検索部及び生成部の一例である。ペア履歴記憶部１２３は、記憶部の一例である。状況受信部１５は、第２の受信部及び第４の受信部の一例である。料金決済部１４は、第１の受信部、算出部、及び第３の受信部の一例である。また、電力の供給は、サービスの提供の一例である。電力の消費は、サービスの利用の一例である。
【００８１】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００８２】
１０          Ｍ２Ｍプラットフォーム
１１          マッチング検索部
１２          認証部
１３          連絡部
１４          料金決済部
１５          状況受信部
２０ａ、２０ｂ、２０ｃ  ＨＧＷ
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
１２１        ユーザ一覧記憶部
１２２        ブラックリスト記憶部
１２３        ペア履歴記憶部
１２４        消費ログ記憶部
１２５        供給ログ記憶部
１２６        供給情報記憶部
１２７        需要情報記憶部
２０１        登録要求部
２０２        検索要求部
２０３        交渉部
２０４        ペア通知部
２０５        状況送信部
２０６        クレジット評価部
２０７        終了通知部
２０８        ブラックリスト登録部
２０９        供給情報送信部
２１０        需要情報送信部
Ｂ            バス
Ｈａ、Ｈｂ、Ｈｃ  ユーザ宅
Ｎｏ          宅外ネットワーク
Ｎｉ          宅内ネットワーク
【図１】
0006426075.tif 000002
【図２】
0006426075.tif 000003
【図３】
0006426075.tif 000004
【図４】
0006426075.tif 000005
【図５】
0006426075.tif 000006
【図６】
0006426075.tif 000007
【図７】
0006426075.tif 000008
【図８】
0006426075.tif 000009
【図９】
0006426075.tif 000010
【図１０】
0006426075.tif 000011
【図１１】
0006426075.tif 000012
【図１２】
0006426075.tif 000013
【図１３】
0006426075.tif 000014