JP2021086312A - 電力取引支援システム、電力取引支援装置、およびプログラム - Google Patents

Abstract

【課題】電力取引市場における電力取引について、検定されたメータで測定された電力量による精算を可能とする。【解決手段】電力取引支援システム１は、電力取引サーバ２０と決済サーバ２２を備える。電力取引サーバ２０は、電力の売注文と買注文とを受け付け、複数の売注文と買注文を、電力量と取引期間と単価とに基づいてマッチングし、注文を成約させる。決済サーバ２２は、成約した売注文と買注文について、電力量と、単価と、売注文を発行したユーザが電力系統ＰＬに供給した電力の電力量をスマートメータ１０４で測定して得た電力量データと、買注文を発行したユーザが取引期間に電力系統ＰＬから取り入れた電力の電力量をスマートメータ１０４で測定して得た電力量データと、に基づいて、ユーザへの支払い額と請求額とをそれぞれ求める。【選択図】図３

Description

本発明は、電力取引支援システム、電力取引支援装置、およびプログラムに関する。

再生可能エネルギーを用いた発電システムが普及しつつある。また、電力取引の自由化が進められている。

これに伴い、簡単な処理で、売り手と買い手の電力入札の電力量、時間帯および価格に関する情報をマッチングして、余剰電力を融通し合うことを可能とする電力取引仲介システムが提案されている。

例えば、特許文献１には、発電装置と蓄電池とを備えた複数のユーザの間で、余剰電力を融通し合うための電力取引マッチングシステムが開示されている。

特開２０１７−１５３２７４号公報

特許文献１に開示されたマッチングシステムでは、発電設備を有するユーザと系統との間に配置されているスマートメータを用いて電力量に関する情報を送信しているが、スマートメータを用いた電力取引は行われていない。また、特許文献１のマッチングシステムでは、需要家間で取り決めた取引情報に基づいて電力の売買を行っているため、電力事業者が入手するスマートメータのデータを用いて電力料金を精算することができないという問題がある。

我が国の法制度では、電力料金の精算は、検定された計器での積算でしか認められていないため、電力事業者が関与していない特許文献１のマッチングシステムでは、電力の売買に伴う電力料金の正当な清算ができない。

そこで、本発明は、このような課題を解決するために、スマートメータ等を用いて、ユーザ間やユーザと電力事業者間の電力取引を支援するシステムを工夫したものであり、ユーザ間と電力会社等が設ける電力取引サーバとをネットワークを介して連携させると共に、決済サーバとスマートメータのデータとを連携させたものである。

以上の状況に基づき、本発明は、電力取引市場における電力取引について、検定されたメータで測定された電力量による精算を可能とする電力取引支援システム、電力取引支援装置、およびプログラムを提供することを目的とする。

上記目的を達成するため、本発明に係る電力取引支援システムは、
電力事業者とユーザ間とをネットワークを介して連携して電力の取引を支援する電力取引支援システムであって、
端末装置を介してユーザから送信された売注文と買注文とを受け付ける手段と、売注文と買注文とを、電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段とを備える電力取引サーバと、
前記電力取引サーバのマッチング手段により成約した売注文と買注文の、電力量と、単価と、売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと、成約した買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データと、に基づいて、成約した売注文を発行したユーザへの支払い額と成約した買注文を発行したユーザへの請求額とをそれぞれ求める決済サーバと、
を備える。

売注文と買注文とは、それぞれ、取引対象の電力の電力量と取引期間と電力の単価と電力の属性を含んでもよい。この場合、前記電力取引サーバのマッチング手段は、売注文と買注文のそれぞれの取引対象の電力の電力量と取引期間と電力の単価と電力の属性をキーに、複数の売注文と買注文をマッチングしてもよい。

前記電力取引サーバのマッチング手段は、所定の電力事業者による余剰電力の買い取りと不足電力の供給を前提に、複数の売注文と買注文をマッチングしてもよい。

前記決済サーバは、スマートメータからＡルートで出力された、成約した売注文を発行したユーザが取引期間に系統に供給した電力の電力量データ及び成約した買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量データをそれぞれ受信する手段を備えてもよい。

前記決済サーバは、決済用のデータと共にスマートメータからＡルートで受信した電力量データを、Ｃルートを介して、電力取引サーバに通知する手段を備えてもよい。この場合に、前記電力取引サーバは、通知された決済用のデータと電力量データとに基づいて、所定の処理を実行してもよい。

前記電力取引サーバは、スマートメータがＢルートで出力したデータを受信する手段と、受信した電力量データを前記決済サーバに通知する手段を備えてもよく、前記決済サーバは、電力取引サーバから通知された電力量データに基づいて決済処理を実行してもよい。

前記決済サーバは、託送料金と手数料とを課金する手段を備えてもよい。

前記電力取引サーバと前記決済サーバとは、ブロックチェーンを構成する複数の記憶装置を備えてもよい。

前記電力取引サーバが、ユーザに、電力使用の制限を設定し、前記決済サーバは、スマートメータが出力したデータに基づいて、ユーザが制限を満たしたか否かを判別し、満たしたと判別した場合には、該ユーザに一定の報酬を付与するようにしてもよい。

スマートメータから送られて来るデータは、他のメータで測定されたデータを含んでもよい。この場合に、前記決済サーバは、他のメータで測定されたデータに基づく請求額を含めて、ユーザへの請求額を処理してもよい。

この発明の電力取引支援装置は、
電力の取引を支援するための電力取引支援装置であって、
複数の端末装置から送信された売注文と買注文とを受け付ける手段と、
売注文と買注文とを、電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段と、
前記マッチング手段により成約した売注文と買注文の電力量と単価と売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データとに基づいて、成約した売注文を発行したユーザへの支払い額と成約した買注文を発行したユーザへの請求額とをそれぞれ求める手段と、
を備える。

この発明のプログラムは、
コンピュータを、
電力の取引を支援するために、
各端末装置から送信された売注文と買注文とを受け付ける手段と、売注文と買注文とを電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段とを備える電力取引サーバとして機能させ、又は、
前記電力取引サーバのマッチング手段により成約した売注文と買注文について、電力量と単価と売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データとに基づいて、成約した売注文を発行したユーザへの支払い額と成約した買注文を発行したユーザへの請求額とをそれぞれ求める手段として機能させる。

本発明に係る電力取引支援システムによれば、電力量計で測定された電力量に基づいた電力の取引が可能となり、検定された正確な電力量での取引が可能となる。

本発明の実施の形態１に係る電力取引支援システム構成を示すブロック図である。 図１に示す電力取引支援システムの電力取引者システムの構成例を示す図である。 本発明の実施の形態１おいて、ユーザが一般家庭である場合の電力取引支援システムの構成の例を示すブロック図である。 （ａ）と（ｂ）は、図２に示すスマートメータが出力する電力量データのフォーマットの一例を示す図である。 図２に示す端末装置が発行する電力取引注文データの一例を示す図であり、（ａ）は売注文データの例、（ｂ）は買注文データの例を示す。 図１に示す電力取引サーバとＤＢのブロック図である。 図１に示す電力取引サーバと決済サーバに記憶されるユーザテーブルの一例を示す図である。 図１に示す電力取引サーバが作成した決済サーバに送信する取引データの一例を示す図である。 図１に示す決済サーバが記憶する電力量履歴データの一例を示す図である。 図１に示す電力取引サーバが実行するマッチング処理のフローチャートである。 図１０に示すマッチング処理内で実行されるこだわり条件による候補選択処理のフローチャートである。 図１０に示すマッチング処理内で実行される価格による候補選択処理のフローチャートである。 ユーザに提示される取引対象候補売注文一覧データの例である。 図１に示す決済サーバが実行する精算処理のフローチャートである。 図１に示す決済サーバが実行する決済処理のフローチャートである。 本発明の実施の形態２において、ユーザが一般家庭である場合の電力取引支援システム構成を示すブロック図である。 本発明の実施の形態３において、ユーザが一般家庭である場合の電力取引支援システムの構成例を示すブロック図である。 本発明の実施の形態４において、ユーザが一般家庭である場合の電力取引支援システムの構成例を示すブロック図である。 実施の形態５に係る電力取引サーバが実行するデマンドレスポンス処理のフローチャートである。 実施の形態５に係る電力取引サーバが実行するデマンドレスポンス精算処理のフローチャートである。 本発明の実施の形態６に係るスマートメータ、ガスメータ、水道メータの構成例を示すブロック図である。 実施の形態６に係るガスメータと水道メータとが実行するメータデータ送信処理のフローチャートである。 実施の形態６に係るスマートメータが実行するメータデータ送信処理のフローチャートである。

以下、本発明の実施の形態に係る電力取引支援システムについて、図１〜図１８を参照して説明する。

（実施の形態１）
本実施の形態の電力取引支援システム１は、複数の取引希望者（以下、ユーザ）の間での電力の売買を仲介し、支払い代行、託送料金の自動計算などを実施するシステムである。

図１は、電力取引支援システム１のシステム構成図、図２は、図１に示すユーザシステムの詳細図、図３は、ユーザが一般家庭である場合の図１と図２を合体したイメージ図である。

図１及び図３に示すように、本実施の形態に係る電力取引支援システム１は、電力系統ＰＬと、インターネットＩＮと、複数のユーザシステム１０−１，・・・１０−Ｎと、インターネットＩＮに接続されたゲートウエイＧＷと、ゲートウエイＧＷに接続された電力取引サーバ２０と、電力取引サーバ２０に接続されたデータベース２１と、電力取引サーバ２０に接続された決済サーバ２２と、メータデータ管理システム（ＭＤＭＳ）２３と、ユーザシステム１０−１，・・・１０−Ｎが備えるスマートメータとメータデータ管理システム２３とを接続するＡルートのネットワークＮＡと、を備える。

電力系統ＰＬは、電力を伝送する電力送電路であり、配電線、送電線などを含む。
インターネットＩＮは情報を伝達する広域ネットワークである。

ユーザシステム１０−１〜１０−Ｎは、電力の売買を希望するものが保有するシステムである。ユーザは、個人、事業者を問わない。なお、ユーザシステム１０−１〜１０−Ｎを総称する場合には、ユーザシステム１０と呼ぶ。

ユーザシステム１０の構成は任意であるが、基本的には、図２に示すように、発電設備１０１と、パワーコンデショナ（ＰＣＳ）１０２と、負荷１０３と、スマートメータ１０４と、端末装置１０５と、ルータ１０６と、を備える。なお、図３ではユーザシステム１０の一部を省略して示している。

発電設備１０１は、電力を発生する設備であり、太陽光発電設備、風力発電設備、水力発電設備、火力発電設備、地熱発電設備、蓄電池、電気自動車などを含む。

パワーコンデショナ（ＰＣＳ）１０２は、１）発電設備１０１で発電された直流の電力を交流の電力に変換して負荷１０３に供給し、２）発電設備１０１の発電電力が負荷１０３の消費電力より多く、余剰電力が発生した場合には、これを電力系統ＰＬに出力して売電し、３）発電設備１０１の発電電力が負荷１０３の消費電力に不足する場合には、電力系統ＰＬからの電力を負荷１０３に供給することにより、不足分を補う。

負荷１０３は、電力を消費するもの一般を示し、ユーザシステム１０が一般個人のシステムの場合は、例えば、家庭電化製品等であり、ユーザシステム１０が事業者のシステムの場合には、例えば、店舗設備、工場設備等である。

スマートメータ１０４は、電力を測定する電力量計であり、パワーコンデショナ１０２と電力系統ＰＬとを接続する電力線上に配置される。スマートメータ１０４は、１）電力系統ＰＬからこのユーザシステム１０に供給される電力の電力量（ＷＨ）と、２）パワーコンデショナ１０２から電力系統ＰＬに供給される電力の電力量を別個に測定し、期間（時間帯）と共に記録する。スマートメータ１０４は、指定機関による検定を受けた信頼性の高い装置である。

スマートメータ１０４は、Ａルート、Ｂルート、Ｃルートの３つのルートで計測した電力量を示すデータ（電力量データ）を外部に出力する。Ａルートは、データを電力事業者、送配電会社等に通知するルートである。Ｂルートは、ユーザのシステムにデータを出力するルートである。Ｃルートは、電力事業者、送配電会社等経由で小売事業者や民間事業者（第三者）にデータを送信するルートである。

本実施の形態では、スマートメータ１０４は、図４（ａ）に例示するように、例えば、３０分単位で、計測した上り電力量と下り電力量を示すデータをＡルートで電力事業者に設置されている決済サーバ２２に出力する。ここで、上り電力量は、スマートメータ１０４から電力系統ＰＬに向かう電力の電力量である。一方、下り電力量は、電力系統ＰＬからスマートメータ１０４に向かう電力の電力量であり、発電設備１０１の発電電力の不足分として電力系統ＰＬから取り入れた電力の電力量である。

スマートメータ１０４は、予め、自己のユニークな識別情報（スマートメータＩＤ）と自己に割り当てられたハッシュ関数を記憶している。スマートメータ１０４は、図４（ｂ）に示すように、時間帯と電力量を示すデータに、スマートメータＩＤを付加する。スマートメータ１０４は、さらに、データの真正性を担保するため、スマートメータＩＤ、時間帯、上り電力量、下り電力量を示すデータ群ＤＡを自己のハッシュ関数で処理して得られたハッシュ値を、メッセージダイジェストとして付加して、電力量データを生成する。スマートメータ１０４は、生成した電力量データをＡルート経由で決済サーバ２２に送信する。

なお、スマートメータ１０４がメッセージダイジェストを作成する機能を備えていない場合には、電力量データにメッセージダイジェストを付加する必要はない。

端末装置１０５は、デスクトップコンピュータ、ラップトップコンピュータ、スマートフォンなどから構成され、１）電力の買注文或いは売注文の注文データを作成し、２）作成した注文データをインターネットＩＮを介して、電力取引サーバ２０に送信し、３）電力取引サーバ２０から送信される種々の情報をユーザに提供する。なお、端末装置１０５は、直接インターネットＩＮに接続されても、ルータ１０６を介してインターネットＩＮに接続されてもどちらでもよい。

ここで、注文データは、図５（ａ）、（ｂ）に示すように、注文したユーザのＩＤ、売買したい電力の属性、売りと買いの別、売買したい電力量、取引期間、希望単価等の情報を含む。なお、図５（ａ）は売注文データの例、図５（ｂ）は買注文データの例である。ここで電力の属性とは、その電力を発電する元となったエネルギーを意味し、太陽光、風力、水力、火力、原子力、等の別を表す。また、太陽光、風力、水力などを含めて再生可能エネルギーなどと指定可能としてもよい。

図１に示すゲートウエイＧＷは、インターネットＩＮと電力取引サーバ２０との間の通信のプロトコル変換、不正アクセスの遮断などの処理を行う。

電力取引サーバ２０は、コンピュータ装置から構成され、売注文と買注文をマッチングするための様々な機能実現手段をハードウエアとソフトウエアの協働により実現する。具体的には、電力取引サーバ２０は、電力取引の市場を仮想空間上に形成し、１）売注文の注文データと買注文の注文データを受け付け、２）売注文と買注文のマッチング処理を行って売買取引を成立させ、３）約定した取引の情報をユーザの端末装置１０５と決済サーバ２２に通知する。

本電力取引支援システム１は、約定した電力の取引について、電力の不足が生じた場合には、電力を補填し、電力の超過が生じた場合には、これを購入する。即ち、電力取引サーバ２０は、電力事業者による、余剰電力の買い取りと不足電力の供給を前提に、複数の売注文と買注文とをマッチングする。従って、電力取引サーバ２０及び決済サーバ２２を運営する者は、電力小売ならびに発電事業の免許を有する者（以下、単に電力事業者と呼ぶ）又は電力事業者と契約したものである必要がある。このため、本実施の形態では、電力取引サーバ２０及び決済サーバ２２は、電力事業者に設置されているものとする。

電力取引サーバ２０は、図６に例示するように、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、補助記憶装置２０４、表示装置２０５、入力装置２０６、通信装置２０７などを備える。

ＲＯＭ２０２には基本プログラムが格納されている。補助記憶装置２０４には、後述するマッチング処理を実行するためのプログラムが記憶されている。ＣＰＵ２０１は、ＲＡＭ２０３をワークエリアとして、プログラムを実行することにより、必要な機能を実現する。

補助記憶装置２０４は、電力取引の仲介処理を実行するために必要な種々のデータを記憶する。例えば、補助記憶装置２０４は、図５（ａ）、（ｂ）に例示した売注文データ及び買注文データ、図７に例示するユーザテーブル、図８に例示する取引データを記憶する。

図７に例示するユーザテーブルは、この電力取引支援システム１を用いて電力の売買を希望する者の情報を事前登録するテーブルである。例示するように、ユーザテーブルは、ユーザの氏名又は名称、ユーザＩＤ、パスワード、住所、住所の緯度と経度、スマートメータ１０４のＩＤ、端末装置１０５のＩＤ、契約する電力事業者との電力の売買代金、決済方法、口座番号、連絡先などの情報を含む。電力取引支援システム１を用いて電力の売買を希望する者は、定められた手続きにより、これらの情報をユーザテーブルに予め登録する。

図８に例示する取引データは、マッチングにより取引が成立した売注文と買注文について、取引の内容を示すデータである。例示するように、取引データは、スマートメータＩＤ、ユーザアカウント（ユーザＩＤ）、成約日時、電力取引の時間帯、売電力量（ｋＨＷ）、買電力量（ｋＷＨ）、希望単価（円／ｋＷＨ）、成約単価（円／ｋＷＨ）、電力の属性、ユーザシステム１０の所在地（住所・緯度・経度等）、託送料、手数料、その他のデータである。

電力取引サーバ２０は、各端末装置１０５から送信された売注文と買注文とを受け付ける手段と、売注文と買注文とを、電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段と、して機能しうる。

図６に示すデータベース２１は、複数の記憶装置２１１〜２１ｍを備え、電力取引サーバ２０の通信装置２０７に接続されている。電力取引サーバ２０は、ＤＢ２１を外部記憶装置として用いて、内部の補助記憶装置２０４と同様に受信した売注文データ、受信した買注文データ、ユーザテーブル、電力取引データなどを、複数の記憶装置２１１〜２１ｍに並列に記憶させる。さらに、電力取引サーバ２０は、補助記憶装置２０４と各記憶装置２１１〜２１ｍとに、過去のデータ全体と今回のデータとを含むデータ全体のメッセージダイジェストを付加する。このような形態により、電力取引サーバ２０は、これらのデータを記憶する。なお、第ｉの記憶装置２１ｉに記憶させるデータに関して、１段前の記憶装置２１−（ｉ−１）の記憶データ全体（メッセージダイジェストを含む）と記憶装置２１−ｉに今回新たに記憶するデータとのデータ全体のメッセージダイジェストを付加するようにしてもよい。

決済サーバ２２は、ハードウエア的には、図６に示した電力取引サーバ２０と同様の構成を有する。この場合、補助記憶装置２０４には、後述する精算処理、決済処理を行うためプログラムが記憶され、ＣＰＵ２０１がこのプログラムを実行することにより必要な機能を実現する。具体的には、決済サーバ２２は、決済に関連するデータを記憶し、また、ユーザシステム１０−１〜１０−Ｎの各スマートメータ１０４からＡルートを介して３０分単位で送信されてくる電力量データをユーザＩＤ別及び時刻順にソートして、図９に例示するように蓄積する。なお、ここでも、過去のデータ全体（メッセージダイジェストを含む）と今回のデータを含む全データのメッセージダイジェストを付加し、複数箇所に格納することによりブロックチェーンを構成してもよい。

また、決済サーバ２２は、図７に示すユーザテーブルと図８に示す取引データを記憶する。

決済サーバ２２は、例えば、所定期間毎、例えば、毎月特定の日に、ユーザＩＤ別に、取引データと電力量履歴データを集計し、全売電力の売上金額、全買電力の購入費用を集計する。決済サーバ２２は、ユーザテーブルを参照し、各ユーザの決済方法を判別し、設定されている決済方法で決済を行う。例えば、あるユーザの決済方法として、銀行振り込み及び銀行引き落としが設定されていれば、そのユーザについては、全銀システム等にアクセスすることにより、そのユーザの売電力料金を登録済の銀行口座に振り込んで支払いし、買電力料金を登録済の銀行口座から引き落とす。

なお、決済サーバ２２も、過去のデータ全と今回のデータを含む全データのメッセージダイジェストを付加し、複数箇所に格納することによりブロックチェーンを構成してもよい。

メータデータ管理システム２３は、Ａルートのネットワークと電力取引サーバ２０及び決済サーバ２２に接続され、Ａルートを介して複数のスマートメータ１０４から電力量データを受信し、電力取引サーバ２０と決済サーバ２２に提供する。メータデータ管理システム２３は、電力取引サーバ２０と決済サーバ２２からの要求に応じて電力量データを提供してもよい。

決済サーバ２２は、マッチングにより成約した売注文と買注文の電力量と単価、及び、成約した売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと、成約した買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データと、に基づいて、成約した売注文を発行したユーザへの支払い額と、成約した買注文を発行したユーザへ請求額とそれぞれ求める手段として機能する。

次に、上記構成を有する電力取引支援システム１を用いて、電力を売買する処理を説明する。

（事前準備）
電力取引支援システム１を用いて電力の売買を希望する者は、予め定められた手続きにより、ユーザ登録を行い、図８に例示したユーザテーブルに所定のユーザ情報を登録し、電力取引サーバ２０とＤＢ２１と決済サーバ２２に格納する。

また、スマートメータ１０４がＡルートを介して出力する電力量データを、決済サーバ２２に送信するメータデータ管理システム２３に登録する。

スマートメータ１０４は、常時、電力を積算して電力量を求め、３０分単位で、Ａルートで図４（ｂ）に示す電力量データを出力する。メータデータ管理システム２３はこの電力量データを受信し、決済サーバ２２に転送し、決済サーバ２２は、これを図９に示すように電力量履歴データとして蓄積するが、ブロックチェーン形式で蓄積してもよい。

（注文処理）
ユーザ登録終了後、電力の売買を希望する者は、端末装置１０５を操作して、図５（ａ）、（ｂ）に例示した注文データを生成し、電力取引サーバ２０に送信する。

ここで、売注文時の属性は、自身が所有する発電設備１０１の属性を設定する。
一方、買注文時の属性は、あえて購入したい電力の種類を特定する。例えば、再生可能エネルギーのみを購入したい場合には、太陽光、風力、水力を項別に指定しても良いし、再生可能エネルギーなど包括的に指定してもよい。
なお、ここでのメッセージダイジェストは、例えば、ユーザの使用する端末装置１０５に割り当てられたハッシュ関数で作成されるハッシュ値である。

電力取引サーバ２０は、各端末装置１０５から送信された注文データを受信し、これを売注文と買注文とに分類して補助記憶装置２０４とＤＢ２１に蓄積する。

なお、注文データを生成する手法自体は任意である。例えば、電力取引サーバ２０が、提供する注文データを生成するために必要なデータを入力又は選択するＷｅｂページを提供し、ユーザがこれに必要事項を入力して、確認及び承認することで、自動的に注文データを生成するようにしてもよい。

電力取引サーバ２０のＣＰＵ２０１は、マッチングプログラムを実行することにより、図１０のフローチャートに示すマッチング処理を常時実行している。

このマッチング処理において、ＣＰＵ２０１は、所在地、属性、期間・時間帯、単価、電力量をキーとして条件が合致する売注文と買注文を選択する（ステップＳ１１）。なお、マッチングの相手先の注文は１つである必要はない。

例えば、図５（ａ）に示すように、２０１９年の１１月１０日９：００〜１１月１７日１６：００に、３０ｋＷＨを売りたい場合に、例えば、１１月１０日１０：００〜１１月１３日１０：００に、１５ｋＷＨを購入したいＡさん及び１１月１２日１０：００〜１１月１６日１５：００に２０ｋＷＨを購入したいＢさんとの取引を成立させてもよい。この場合、ＣＰＵ２０１は、予め設定されている優先度に従って、例えば、ＡさんとＢさんに、それぞれ１５ｋＷＨを売却するようにしてもよい。この場合、Ｂさんは、５ｋＷＨ分購入電力が不足するが、この分を、他の売却希望者の売却分の全部又は一部を割り当てたり、或いは、電力事業者がＢさんとの契約に基づいて不足部分を供給する等してもよい。

同様に、図５（ａ）に示すように、１１月１０日９：００〜１１月１７日１６：００に、３０ｋＷＨを売りたい場合に、例えば、１１月１０日１０：００〜１１月１３日１０：００に、１０ｋＷＨを購入したいＡさんと、１１月１２日１０：００〜１１月１６日１５：００に、１５ｋＷＨを購入したい、Ｂさんとの取引を成立させる等してもよい。この場合、優先度に従って、例えば、ＡさんとＢさんに、それぞれ１０ｋＷＨと１５ｋＷＨ、合計２５ｋＷＨを売却し、余剰の５ｋＷＨについて、別の人に売却したり、電力事業者で購入するようにしてもよい。

ＣＰＵ２０１は、選択した取引データについて、その地理的条件から託送量を計算し、託送量等を考慮しても、希望売買金額を満たすか否かを判別する（ステップＳ１２）。

託送料等については、例えば、売注文の注文データを受け付けたときに、売り単価に予め設定された託送料金を加算してもよい。託送料金の求め方は任意である。平均的な固定額を加算してもよく、従量制の金額を加算してもよい。また、取引成立後に、売り手と買い手の例えば、緯度・経度情報からその直線距離又は送電線・配電線の距離を求め、その距離に応じた託送料金を設定してもよい。また、単価に上乗せするのではなく、手数料として精算処理時に引き落とす等してもよい。

ステップＳ１２で、条件を満たさない場合（ステップＳ１２：Ｎｏ）、ステップＳ１１にリターンし、満たす場合（ステップＳ１２：Ｙｅｓ）、取引を成立させ、注文の組み合わせを補助記憶装置２０４とＤＢ２１に登録する（ステップＳ１３）。また、図８に示す取引データを生成し、自ら記憶すると共に決済サーバ２２に送信する。
さらに、ユーザテーブルを参照し、取引が成立した旨をメールなどでユーザに通知する（ステップＳ１４）。

このようにして、電力取引サーバ２０は、注文データの受け付け、注文のマッチング、成約した取引を決済サーバ２２に通知すること、マッチングの結果をユーザに通知することなどの処理を繰り返して実行する。

なお、本実施の形態においては、注文者は、自己の注文について、「こだわり条件」を設定可能である。電力取引サーバ２０は、ステップＳ１１でマッチングを行う際に、「こだわり条件」が設定されている場合には、「こだわり条件」を優先的に考慮する。例えば、買い手が、自然エネルギーにより発電された電力を価格に関わらず購入することを希望する場合がある。この場合、ユーザは、図５（ｂ）に示す買注文データの属性の欄に「自然エネルギー」を設定する。同様に、例えば、買い手が、特定地域で発電された電力のみを購入することを希望する場合がある。この場合、ユーザは、図５（ｂ）に示す買注文データの発電地域の欄（図示せず）に「Ｋ県Ｊ市」、「Ｋ地方」等と指定する。同様に、売り手が、特定地域のユーザにのみ電力を売却したいと希望する場合がある。この場合、図５（ａ）に示す売注文データの消費地域の欄（図示せず）に、「Ｌ県」「Ｍ地方」等と指定する。

ＣＰＵ２０１は、図１０に示すマッチング処理のステップＳ１１内で、図１１に示すこだわり条件による候補選択処理を実行する。
この処理においては、電力取引サーバ２０は、こだわり条件があるか否かを判別する（ステップＳ１１１）。こだわり条件がある場合、マッチング対象とする注文データから、この条件に合致しないものをマッチングの対象から除外する（ステップＳ１１２）。残りの注文データがマッチングの対象候補とされ、他の条件が合致すれば、成約となる。

例えば、マッチング処理の対象となっている買注文データの属性の欄が「自然エネルギー」に設定されている場合、電力取引サーバ２０は、図１０のステップＳ１１のマッチング処理を実行するなかで、ステップＳ１１１の処理を実行し、こだわり条件ありと判別し、「属性」が太陽光、風量、地熱、水力等と設定された売注文データのみをマッチングの対象とし、「属性」が火力、原子力等に設定されている売注文データをマッチングの対象から除外する。同様に、マッチング処理の対象となっている買注文データの「発電地域」の欄が「Ｋ県」に設定されている場合、電力取引サーバ２０は、ユーザデータを参照して、Ｋ県に所在するユーザの売注文データをマッチングの対象とし、他地域に所在するユーザからの売注文データをマッチングの対象から除外する。

また、マッチング処理の対象となっている売注文データの「消費地」の欄に「Ｋ県」が設定されている場合、電力取引サーバ２０は、ユーザデータを参照して、Ｋ県に所在するユーザの買注文データをマッチングの対象とし、他地域に所在するユーザからの買注文データをマッチングの対象から除外する。
なお、こだわり条件を満足するだけでは、成約とはならず、他の取引条件を充足することで成約となる。

また、図１０のステップＳ１１で、価格面のマッチングを行う際には、託送料金（発電地から消費地まで電力を送配電するためのコスト）を考慮してマッチングを行うことが望ましい。託送料については、固定額とすることも可能であるが、送配電距離が長くなるに従って託送料を高く、送配電距離が短くなるに従って託送料を安くすることも可能である。この場合のマッチング処理の内容を図１２を参照して説明する。

電力取引サーバ２０のＣＰＵ２０１は、図１０に示すマッチング処理のステップＳ１１の処理内で、図１２に示す価格による候補選択処理を実行する。

この処理においては、ＣＰＵ２０１は、まず、マッチングの対象として選択した売注文と買注文について、少なくともどちらか一方に希望価格が設定されているか否かを判別する（ステップＳ１２１）。希望価格が設定されている場合（ステップＳ１２１：Ｙｅｓ）、電力取引サーバ２０は、注文データに含まれているユーザＩＤをキーにユーザデータを検索し、ユーザの住所・緯度・経度等の地域を特定する情報を取得する（ステップＳ１２２）。次に、売り手の地域と買い手の地域から、その距離或いは送配電ルートを求め、求めた距離又は送配電ルートに基づいて、託送料の単価を計算する（ステップＳ１２２）。なお、取引データの所在地の情報から地理的情報を得ても良い。次に、電力取引サーバ２０は、売注文データに含まれている希望価格に求められた託送料の単価を加算して希望売却価格を補正し、補正した希望売却価格と買注文データに設定されている購入希望価格とを比較して（ステップＳ１２３）、条件を満たすか否かを判別する（ステップＳ１２４）。条件を満たす場合には、取引の候補として残し（ステップＳ１２５）、条件を満たさない場合には、取引の候補から除外する（ステップＳ１２６）。

例えば、売却希望単価が１７円の売注文データと、購入希望単価が１８円の買注文データとがマッチングの対象として選択されたとする。希望価格だけでは、成約可能な状態となっている。ただし、売り手と買い手の所在地から計算された、託送料金の単価が１円より高くなると、価格条件が合致しなくなり、成約は困難となる。電力取引サーバ２０は、このような処理を行うことにより、合理的根拠に基づく託送料金を設定し、電力の地産地消を促進することができる。

なお、電力取引サーバ２０は、自動的なマッチング処理の他、ユーザ自身による取引先の指定による取引も可能とすることができる。この場合、注文者は、自己の売注文データ又は買注文データを電力取引サーバ２０に送信する。電力取引サーバ２０は受信した注文データに基づいて、取引の候補となりうる注文データを一定数量抽出し、図１３に例示するような一覧を作成して、ユーザに提示する。なお、図１３は、買注文を発行したユーザに提示される取引対象候補売注文一覧の例を示す。ユーザは、端末装置１０５にこの一覧を受信し、この一覧から、自己の希望条件に合致するものを取引の対象として選択し、電力取引サーバ２０に取引希望データを送信する。電力取引サーバは、受信した取引希望データについて、成約可能か否か改めてマッチング処理を行う。
この際、電力取引サーバ２０は、ステップＳ１２２、Ｓ１２３と同様の処理を行って託送料金を求め、託送料金と希望価格とその合計単価をリストに含める。これにより、ユーザは、希望価格だけでなく、実際のコストを意識して成約可能な注文を選択できる。

一方、決済サーバ２２は、図１４に示す個々の取引についての精算処理を実行している。この精算処理においては、電力取引サーバ２０から受信した取引データをアカウント単位及びスマートＩＤ単位に抽出し（ステップＳ２１）、取引データとスマートメータ１０４で求められた電力量データとに基づいて、電力の売却額又は購入額を計算する（ステップＳ２２）。

この際、売注文については、本システムの使用料の課金処理、買注文については、託送料の課金処理、本システムの使用料の課金処理をあわせて行う。また、契約不履行の補填やペナルティがあったか否かを判定し、精算に反映する。より詳細に説明すると、ユーザが所有する発電設備１０１は、売注文で特定した電力量の電力を発生できるとはかぎらない。例えば、発電設備１０１が太陽電池、風力発電等である場合、天候により発電量が変化し、売注文データで指定した電力量以上の電力量を発電することもあれば、指定した電力量を発電できないこともある。そこで、注文データと実際の売電電力量或いは買電電力量とが一致しているか否かを判別し、異なる場合には、電力事業者との調整が必要になる。

例えば、図５（ａ）に示す売注文が成立していたとする。この売注文では、取引期間に３０ｋＷＨの電力が売電されている。これに対し、スマートメータ１０４で測定された電力量データでは、この取引期間の上り電力量と下り電力量との差が３１ｋＷＨであったとする。この場合、１ｋＷＨ余分に電力を売却していることになる、このため、売却額は、希望単価１８円／ｋＷＨでの３０ｋＨＷ分の売り上げと、電力事業者への１ｋＷＨの売却額の和となる。決済サーバ２２は、ユーザデータに基づいて、ユーザの契約先の電力事業者を特定し、その電力事業者の買電単価を判別し、買取単価と電力量からユーザへの支払い額を特定し、また、その電力事業者への請求額を設定する。

また、仮にこの取引期間のスマートメータ１０４で測定された上り電力量と下り電力量との差が２５ｋＷＨであったとする。この場合、売却量が５ｋＷＨ不足していることになる。このため、実際の売り上げは、１８円／ｋＷＨでの２５ｋＷＨ分の売り上げと、電力事業者からの５ｋＷＨの購入の和となる。決済サーバ２２は、ユーザデータに基づいて、ユーザの契約先の電力事業者を特定し、その電力事業者の売電単価を判別し、売取単価と電力量からユーザへの請求額を特定し、また、その電力事業者への支払額を設定する。

また、図５（ｂ）に示す買注文が成立していたとする。この買注文では、取引期間に７ｋＷＨの電力が購入されている。これに対し、スマートメータ１０４で測定された電力量データでは、この取引期間の上り電力量と下り電力量との差が１０ｋＷＨであったとする。この場合、３ｋＷＨ余分に電力を購入していることになる。このため、希望単価１７円／ｋＷＨでの７ｋＨＷ分の価格と別途求められている託送量の価格とシステムの使用料、さらに、契約先の電力事業者への３ｋＷＨ分の電力料金を請求する。決済サーバ２２は、その電力事業者への支払い額と送配電会社への支払い額を設定する。
このようにして、決済サーバ２２は、成約取引毎に、成約した売注文・買注文だけでなく、ユーザテーブルを参照し、そのユーザが電力事業者と契約している売電単価及び買電単価を求め、決済用の計算を行う。さらに、託送料及びシステム使用料の課金処理、電力事業者、送配電業者への支払い額の計算なども行う。

決済サーバ２２は、このようにして求められた個々の電力取引についての決済金額をユーザ別、電力小売取引業者等別、配送電会社別に記憶する。

また、決済サーバ２２は、ユーザ別に定められた決済のタイミングで図１５に示す決済処理を実行する。
まず、決済サーバ２２は、ユーザ１人を特定し（ステップＳ３１）、決済対象期間中の個々の決済金額（売却額、購入額）と取引項目のリストを作成する（ステップＳ３２）。続いて、決済期間内の売却額と購入額をそれぞれ累算して売却額の総額と購入額の総額を求める。更に、売却額の総額と購入額の総額の差分を求める（ステップＳ３３）。なお、この段階では、電力事業者との売電・買電の金額も累算する。

決済サーバ２２は、次に、図７に示すユーザテーブルに規定されている決済方法に従って、決済処理を行う（ステップＳ３４）。例えば、ユーザテーブルに規定されている決済方法が銀行口座による決済処理ならば、例えば、全銀システムを介してユーザデータにより特定される銀行口座にアクセスし、決済対象金額を振り込み或いは引き落とす。その他、電子マネーでの支払い、為替での支払い、クレジットカードでの支払い、請求書の発行処理等を行う。
決済サーバ２２は、契約内容に応じて、インターネットＩＮを介して決済情報をユーザに送信する（ステップＳ３５）。

このような処理を繰り返すことにより、検定されたスマートメータ１０４で測定された電力量に基づいた、電力取引の決済処理が実行される。なお、決済サーバ２２は、電力事業者、送配電事業者等についても累算処理を実行する。

このようにして、各ユーザは、端末装置１０５を操作して、注文データを、電力取引サーバ２０に送信することで、電力を希望する条件で売買することができる。

（実施の形態２）
上記実施の形態１においては、電力データの送信にスマートメータ１０４のＡルートを使用したが、Ｃルートを使用することも可能である。以下、Ｃルートを使用する実施の形態を図１６を参照して説明する。

図１６は、図３に対応するシステム構成図である。
本支援システムの基本構成は実施の形態１の電力取引支援システム１と基本的に同一である。ただし、メータデータ管理システム２３は、送配電会社に設置され、電力事業者には、電力取引サーバ２０、決済サーバ２２、メータデータ管理システム２３’が設置される。

電力取引サーバ２０と決済サーバ２２とは、それぞれ、実施の形態１と同様のデータを記憶する。
売注文データと買注文データとは、電力取引サーバ２０に送信される。電力取引サーバ２０は、図１０に示すマッチング処理を実行し、図８に示す取引データを決済サーバ２２に送信する。
決済サーバ２２は、図１４に示した精算処理及び図１５に示した決済処理のうちのステップＳ３１〜Ｓ３３を実行する。
電力量データは、Ａルートでメータデータ管理システム２３に送信され、さらに、Ｃルートを介してメータデータ管理システム２３’に転送され、電力取引サーバ２０と決済サーバ２２に転送される。

（実施の形態３）
実施の形態２において、電力事業者自らが電力の取引を実行する必要はない。契約を結んだ第三者機関により電力取引処理を実行することも可能である。また、電力取引処理の一部のみを第三者機関に委託することも可能である。図１７は、マッチング処理を第三者機関に委託しれ場合のシステム構成を例示する。

この構成では、電力取引サーバ２０は、委託先の第三者機関に設置される。
一方、電力事業者には、決済サーバ２２とメータデータ管理システム２３’が設置され、送配電会社には、メータデータ管理システム２３が設置される。
図１７のシステム構成において、売注文データと買注文データのマッチングまでの処理は、実施の形態１及び２と同様である。
成約した取引のデータ、即ち、取引データは、電力取引サーバ２０から決済サーバ２２に専用線を介して伝達される。
決済サーバ２２は、決済サーバ２２は、精算処理及び決済処理を実行する。

スマートメータ１０４からの電力量データは、送配電業会社に設置されたメータデータ管理システム２３に送信される。メータデータ管理システム２３は、各電力事業者分の電力量データをＣルートを介してメータデータ管理システム２３’を介して決済サーバ２２に送信する。

（実施の形態４）
Ｂルートを介して電力データを電力事業者に通知することも可能である。Ｂルートを使用する場合の構成例を図１８に示す。
この場合、スマートメータ１０４の出力は、無線又は電力線通信で送信され、これらを受信する機能を有するインタフェース１０８を介してルータ１０６を介して端末装置１０５に通知される。インタフェース１０８から端末装置１０５に直接通知されても良い。
端末装置１０５は、Ｂルートで通知された電力データをインターネットＩＮを介してメータデータ管理システム２３に適宜送信する。以後の処理は、実施の形態１と同様である。

なお、この形態の場合でも、第三者機関に電力取引サーバ２０を設置し、電力事業者に決済サーバ２２を設置するような応用も可能である。

電力取引サーバ２０として、ブロックチェーンを構成する例を示したが、電力取引サーバの構成自体は任意である。

また、以上の説明では、電力取引サーバ２０と決済サーバ２２とを区別し、電力取引サーバ２０と決済サーバ２２とが、通信を行いながら協働して電力取引を支援する電力取引支援システムを構成する例を説明した。この発明はこれに限定されない。例えば、電力取引サーバ２０と決済サーバ２２とが、両サーバの機能を兼ね備える１台の電力取引支援装置から構成されてもよい。この場合、電力取引支援装置は、ネットワークを介して売注文と買注文とを受け付ける受付手段と、売注文と買注文とをマッチングし、注文を成約させるマッチング手段と、成約した注文について、電力量計で測定して得た電力量データとに基づいて決済処理を行う決済手段を備える。クラウドサーバ或いはクラウドシステムのように、複数のコンピュータから構成される大きなシステムの一部として機能的に構成されてよい。

なお、受付手段とマッチング手段と決済手段とを備えるコンピュータが異なる場合には、それぞれに、対応するプログラムがインストールされる。

また、サーバの設置場所はどこでもよく、管理権限が上述の例に相当すればよい。さらに、管理も上述した電力事業者、送配電会社、委託契約を結んだ第三者機関等に限定されるものではない。

上記実施の形態で例示した構成は適宜変更可能である。例えば、図１、図３、図１６〜図１８で示した電力取引支援システムの構成は、例示であり、適宜変更してもよい。また、図２に示したユーザシステム１０の構成も適宜変更可能である。例えば、発電設備１０１を備えない買電専門のユーザシステム１０でもよく、負荷１０３を備えない売電専門のユーザシステム１０でもよい。
また、ユーザと電力取引サーバ２０を接続する通信回線は、インターネットＩＮに限定されず、他の任意の通信ネットワークを使用できる。

（実施の形態５）
上記の電力取引支援システム１をデマンドレスポンスに活用することも可能である。以下、電力取引支援システム１をデマンドレスポンスに利用する実施の形態について説明する。

ここで、デマンドレスポンスとは、市場価格の高騰時または系統信頼性の低下時において、設定またはインセンティブの支払に応じて、需要家側が電力の使用を抑制するよう電力の消費パターンを変化させることである。
本実施の形態では、ユーザ情報の登録ときに、デマンドレスレスポンスに対応するか否か、電力事業者との契約内容等を予め登録しておく。

電気事業者等から電力使用の抑制（制限）の要請が発生すると、その要請は電力取引サーバ２０に通知される。
電力取引サーバ２０は、要請に応答して、図１９に示すデマンドレスポンス処理を開始する。

電力取引サーバ２０のＣＰＵ２０１は、ユーザテーブルを参照し、デマンドレスポンスに対応するユーザをピックアップする（ステップＳ４１）。

次に、ＣＰＵ２０１は、デマンドレスポンスの要求内容に応じて、対象となるユーザを抽出する（ステップＳ４２）。例えば、ある特定の地域のみが対象となる場合には、住所・緯度・経度などの情報から、対象となるユーザを抽出する。また、例えば、ある特定の電気事業者と契約しているユーザのみが対象となる場合には、ユーザ情報に含まれている契約情報からその電気事業者と契約しているユーザを抽出する。また、例えば、契約容量が基準値以上のユーザのみが対象となる場合には、要求を満たす容量のユーザを抽出する。

ＣＰＵ２０１は、抽出した各ユーザについて、予め定められた基準に従って、デマンドの内容と各ユーザの節電能力に基づいて、電力の使用量を制限・抑制する内容（制限条件）を設定する（ステップＳ４３）。例えば、契約容量に基づいて、ユーザＡについては、要求された時間帯の電力使用量の上限を２ｋＷＨとし、ユーザＢについては、要求された時間帯の電力使用量の上限を８ｋＷＨとする。

ＣＰＵ２０１は、ステップＳ４２で抽出したユーザのうち、一部のユーザについて、登録されている連絡先（例えば、メールアドレス、スマートホンアプリのプッシュ通知）に、デマンドレスポンスに対応するかの問い合わせと制限条件（例えば、期間、使用量の上限など）とを含む案内を通信装置２０７を介して送付する（ステップＳ４３）。

その後、ＣＰＵ２０１は、案内を送付したユーザからの返信を待ち受ける（ステップＳ４４）。ＣＰＵ２０１は、返信がデマンドレスポンスを受け入れるという返信の場合には、受け入れによって、達成された消費電力量の削減量を累算する（ステップＳ４４）。ＣＰＵ２０１は、所定のタイミングに達したか否かを判別し（ステップＳ４５）、達していなければ（ステップＳ４５：Ｎｏ）、ステップＳ４４にリターンする。一方、所定のタイミングに達していれば（ステップＳ４５：Ｙｅｓ）、削減量の累算値が予め設定されている目標量に達した可否かを判別する（ステップＳ４６）。

達していないと判別した場合（ステップＳ４６：Ｎｏ）、ステップＳ４３にリターンし、案内を出していないユーザの一部に案内を送信する。

ＣＰＵ２０１は、削減量の累積量が目標量に達するまで、ステップＳ４３〜Ｓ４６の処理を繰り返す。
削減量の累積量が目標量に達したと判別した場合（ステップＳ４６：Ｙｅｓ），参加者の情報をセーブすると共に決済サーバ２２に通知して（ステップＳ４７）、処理を終了する。

デマンドレスポンスの期間終了後、決済サーバ２２のＣＰＵは、図２０に示すデマンドレスポンス精算処理を実行し、各参加者について精算処理を行う。

決済サーバ２２のＣＰＵは、ステップＳ４７で取得した情報に基づいて、未精算の参加者を1人通出する（ステップＳ５１）。次に、その参加者の電力量履歴データから、デマンドレスポンス実施時間帯の電力消費実績を取得し（ステップＳ５２）、そのユーザに割り当てられているデマンドレスポンスの制限を満たしているか否かを判別する（ステップＳ５３）。

制限を満たしていると判別すれば（ステップＳ５３：Ｙｅｓ）、その参加者に予め設定されている報酬を付与し（ステップＳ５４）、満たしていなければ（ステップＳ５３：Ｎｏ）、ステップＳ５４をスキップする。

決済サーバ２２のＣＰＵは、全ての参加者について、デマンドレスポンスに基づく精算を実行したか否かを判別し（ステップＳ５５）、未精算の参加者が残っていればステップＳ５１にリターンし（ステップＳ５５：Ｎｏ）、全参加者について精算が終了していれば（ステップＳ５５：Ｙｅｓ）、処理を終了する。

決済サーバ２２のＣＰＵは、図１５の決済処理のステップＳ３２，Ｓ３３において、ステップＳ５４で付与した報酬を考慮する。例えば、報酬として一定の報酬額が与えられた場合は、ステップＳ３２のリストの項目として、デマンドレスポンスでの報酬である旨が記録され、さらに、そのユーザへの支払い額にこの報酬額が含まれる。
これにより、デマンドレスポンスをより効率的に実施できる。

なお、デマンドレスポンスの事前登録を不要として、ステップＳ４１をスキップして、ステップＳ４２から処理を開始するようにしてもよい。また、電力使用制限のしかた、制限条件を満たしたときの報酬は任意に設定可能である。

（実施の形態６）
上記の電力取引支援システム１においては、処理の対象は電力に関する事項のみであった。この発明はこれに限定されない。処理の対象は任意である。
電気に関する料金と共にガス料金、水道料金を処理する例を説明する。

本実施の形態においては、図２１に示すように、スマートメータ１０４，ガスメータ１０１０，水道メータ１０２０は、それぞれ、計器本体１０４１，１０１１，１０２１と共に制御部１０４２，１０１２，１０２２と通信装置１０４３，１０１３，１０２３を備える。また、スマートメータ１０４，ガスメータ１０１０，水道メータ１０２０は、それぞれ、入力装置１０４４，１０１４，１０２４、表示装置１０４５，１０１５，１０２５を備える。

計器本体１０４１，１０１１，１０２１は、それぞれ、消費電力量、消費ガス量、消費水道量を測定する。

制御部１０４２，１０１２，１０２２は、プロセッサとタイマを備え、各部を制御する。通信装置１０４３，１０１３，１０２３は、ホームネットワークＨＮを介して相互に接続されており、他装置と通信を行う。入力装置１０４４，１０１４，１０２４は設定情報等の任意の情報を入力し、表示装置１０４５，１０１５，１０２５は測定データ、メニューなどを表示する。

本実施の形態においては、各ユーザは、ガス使用料及び水道使用料についても、電力取引支援システム１を介した請求及び支払いに予め同意しているものとする。この場合、ユーザテーブルには、契約先のガス会社、料金プラン、契約先の水道会社、料金プランなどが予め登録されている。

ガスメータ１０１０の制御部１０１２と水道メータ１０２０の制御部１０２２は、それぞれ、タイマ割り込みなどにより、適当な周期で図２２のメータデータ送信処理を実行し、まず、データの送信タイミングに達したか否かを判別する（ステップＳ６１）。
送信タイミングに達していいない場合（ステップＳ６１：Ｎｏ）、処理を終了し、達していれば（ステップＳ６１：Ｙｅｓ）、前回の送信時から直近までの計測データを、通信装置１０１３と１０２３、ホームネットワークＨＮを介してスマートメータ１０４に送信する（ステップＳ６２）。

スマートメータ１０４の制御部１０４２は、送信されてきた、計測データを、通信装置１０４３を介して受信し、一旦記憶する。

スマートメータ１０４の制御部１０４２は、タイマ割り込みなどにより、適当な周期で図２３のメータデータ送信処理を実行し、まず、データの送信タイミングに達したか否かを判別する（ステップＳ７１）。
送信タイミングに達していいない場合（ステップＳ７１：Ｎｏ）、処理を終了し、達していれば（ステップＳ７１：Ｙｅｓ）、受信して記憶しておいたガスメータ１０１０と水道メータ１０２０の測定データを、Ａルート、Ｂルート、又はＣルートとメータデータ管理システム２３を介して決済サーバ２２に送信する。

決済サーバ２２は、スマートメータ１０４の制御部１０４２は、送信されてきた計測データを、通信装置１０４３を介して受信し、一旦記憶する。決済サーバ２２のＣＰＵ２０１は、ガスメータ１０１０から受信したデータから、ガス使用料をユーザデータに登録されている契約情報等から求める。決済サーバ２２のＣＰＵ２０１は、水道メータ１０２０から受信したデータから、水道料と下水道料をユーザデータに登録されている契約情報等から求める。

決済サーバ２２のＣＰＵ２０１は、図１５の決済処理のステップＳ３２，Ｓ３３において、求めておいたガス使用料と水道使用料をユーザへの請求額の一部として使用する。
一方、各ガス会社と水道会社については、手数料を差し引いた上で、会社別に売上額として累算され、処理される。

このようにして、各ユーザについて、電気料とガス料と水道料とが一括して処理される。

以上の説明では、ガスメータ１０１０と水道メータ１０２９がそれぞれ通信装置１０１３と１０２３を備える構成を例示したが、スマートメータ１０４に測定値を伝達できるならば、その構成は任意である。例えば、ガスメータ１０１０と水道メータ１０２９の表示装置１０１５と１０２５がそれぞれ表示する計測値を光学的に読み取って、スマートメータ１０４の通信装置１０４３に無線又は有線で伝達する外付け装置を配置する等してもよい。

以上の説明では、スマートメータの他にガスメータと水道メータの測定データを処理する例を示したが、処理対象のデータは、ガス使用量データ、水道使用量データに限定されない。他の任意の装置で取得された課金又は請求の対象となるデータを処理対象としうる。

１ 電力取引支援システム
１０ ユーザシステム
２０ 電力取引サーバ
２１ データベース
２２ 決済サーバ
２３ メータデータ管理システム（ＭＤＭＳ）
１０１ 発電設備
１０２ パワーコンデショナ（ＰＣＳ）
１０３ 負荷
１０４ スマートメータ
１０５ 端末装置
１０６ ルータ
１０８ インタフェース
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ 補助記憶装置
２０５ 表示装置
２０６ 入力装置
２０７ 通信装置
１０１０ ガスメータ
１０２０ 水道メータ
１０４１，１０１１，１０２１ 計器本体
１０４２，１０１２，１０２２ 制御部
１０４３，１０１３，１０２３ 通信装置
１０４４，１０１４，１０２４ 入力装置
１０４５，１０１５，１０２５ 表示装置

本発明は、電力取引支援システム、電力取引支援装置、およびプログラムに関する。

再生可能エネルギーを用いた発電システムが普及しつつある。また、電力取引の自由化が進められている。

これに伴い、簡単な処理で、売り手と買い手の電力入札の電力量、時間帯および価格に関する情報をマッチングして、余剰電力を融通し合うことを可能とする電力取引仲介システムが提案されている。

例えば、特許文献１には、発電装置と蓄電池とを備えた複数のユーザの間で、余剰電力を融通し合うための電力取引マッチングシステムが開示されている。

特開２０１７−１５３２７４号公報

特許文献１に開示されたマッチングシステムでは、発電設備を有するユーザと系統との間に配置されているスマートメータを用いて電力量に関する情報を送信しているが、スマートメータを用いた電力取引は行われていない。また、特許文献１のマッチングシステムでは、需要家間で取り決めた取引情報に基づいて電力の売買を行っているため、電気事業者が入手するスマートメータのデータを用いて電力料金を精算することができないという問題がある。

我が国の法制度では、電力料金の精算は、検定された計器での積算でしか認められていないため、電気事業者が関与していない特許文献１のマッチングシステムでは、電力の売買に伴う電力料金の正当な清算ができない。

そこで、本発明は、このような課題を解決するために、スマートメータ等を用いて、ユーザ間やユーザと電気事業者間の電力取引を支援するシステムを工夫したものであり、ユーザ間と電力会社等が設ける電力取引サーバとをネットワークを介して連携させると共に、決済サーバとスマートメータのデータとを連携させたものである。

以上の状況に基づき、本発明は、電力取引市場における電力取引について、検定されたメータで測定された電力量による精算を可能とする電力取引支援システム、電力取引支援装置、およびプログラムを提供することを目的とする。

上記目的を達成するため、本発明に係る電力取引支援システムは、
ネットワークを介して連携して電力の取引を支援する電力取引支援システムであって、
端末装置を介してユーザから送信された売注文と買注文とを受け付ける手段と、売注文と買注文とを、電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段とを備える電力取引サーバと、
前記電力取引サーバのマッチング手段により成約した売注文と買注文の、電力量と、単価と、売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと、買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データと、に基づいて、成約した売注文を発行したユーザへの支払い額と成約した買注文を発行したユーザへの請求額とをそれぞれ求める決済サーバと、
を備える。

売注文と買注文とは、それぞれ、取引対象の電力の電力量と取引期間と電力の単価と電力の属性を含んでもよい。この場合、前記電力取引サーバのマッチング手段は、売注文と買注文のそれぞれの取引対象の電力の電力量と取引期間と電力の単価と電力の属性をキーに、複数の売注文と買注文をマッチングしてもよい。

前記電力取引サーバのマッチング手段は、所定の電気事業者による余剰電力の買い取りと不足電力の供給を前提に、複数の売注文と買注文をマッチングしてもよい。

前記決済サーバは、スマートメータからＡルートで出力された、成約した売注文を発行したユーザが取引期間に系統に供給した電力の電力量データ及び成約した買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量データをそれぞれ受信する手段を備えてもよい。

前記決済サーバは、決済用のデータと共にスマートメータからＡルートで受信した電力量データを、Ｃルートを介して、電力取引サーバに通知する手段を備えてもよい。この場合に、前記電力取引サーバは、通知された決済用のデータと電力量データとに基づいて、所定の処理を実行してもよい。

前記電力取引サーバは、スマートメータがＢルートで出力したデータを受信する手段と、受信した電力量データを前記決済サーバに通知する手段を備えてもよく、前記決済サーバは、電力取引サーバから通知された電力量データに基づいて決済処理を実行してもよい。

前記決済サーバは、託送料金と手数料とを課金する手段を備えてもよい。

前記電力取引サーバと前記決済サーバとは、ブロックチェーンを構成する複数の記憶装置を備えてもよい。

前記電力取引サーバが、ユーザに、電力使用の制限を設定し、前記決済サーバは、スマートメータが出力したデータに基づいて、ユーザが制限を満たしたか否かを判別し、満たしたと判別した場合には、該ユーザに一定の報酬を付与するようにしてもよい。

スマートメータから送られて来るデータは、他のメータで測定されたデータを含んでもよい。この場合に、前記決済サーバは、他のメータで測定されたデータに基づく請求額を含めて、ユーザへの請求額を処理してもよい。

この発明の電力取引支援装置は、
電力の取引を支援するための電力取引支援装置であって、
複数の端末装置から送信された売注文と買注文とを受け付ける手段と、
売注文と買注文とを、電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段と、
前記マッチング手段により成約した売注文と買注文の電力量と単価と売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データとに基づいて、成約した売注文を発行したユーザへの支払い額と成約した買注文を発行したユーザへの請求額とをそれぞれ求める手段と、
を備える。

この発明のプログラムは、
コンピュータを、
電力の取引を支援するために、
各端末装置から送信された売注文と買注文とを受け付ける手段と、売注文と買注文とを電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段とを備える電力取引サーバとして機能させ、又は、
前記電力取引サーバのマッチング手段により成約した売注文と買注文について、電力量と単価と売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データとに基づいて、成約した売注文を発行したユーザへの支払い額と成約した買注文を発行したユーザへの請求額とをそれぞれ求める手段として機能させる。

本発明に係る電力取引支援システムによれば、電力量計で測定された電力量に基づいた電力の取引が可能となり、検定された正確な電力量での取引が可能となる。

本発明の実施の形態１に係る電力取引支援システム構成を示すブロック図である。 図１に示す電力取引支援システムの電力取引者システムの構成例を示す図である。 本発明の実施の形態１おいて、ユーザが一般家庭である場合の電力取引支援システムの構成の例を示すブロック図である。 （ａ）と（ｂ）は、図２に示すスマートメータが出力する電力量データのフォーマットの一例を示す図である。 図２に示す端末装置が発行する電力取引注文データの一例を示す図であり、（ａ）は売注文データの例、（ｂ）は買注文データの例を示す。 図１に示す電力取引サーバとＤＢのブロック図である。 図１に示す電力取引サーバと決済サーバに記憶されるユーザテーブルの一例を示す図である。 図１に示す電力取引サーバが作成した決済サーバに送信する取引データの一例を示す図である。 図１に示す決済サーバが記憶する電力量履歴データの一例を示す図である。 図１に示す電力取引サーバが実行するマッチング処理のフローチャートである。 図１０に示すマッチング処理内で実行されるこだわり条件による候補選択処理のフローチャートである。 図１０に示すマッチング処理内で実行される価格による候補選択処理のフローチャートである。 ユーザに提示される取引対象候補売注文一覧データの例である。 図１に示す決済サーバが実行する精算処理のフローチャートである。 図１に示す決済サーバが実行する決済処理のフローチャートである。 本発明の実施の形態２において、ユーザが一般家庭である場合の電力取引支援システム構成を示すブロック図である。 本発明の実施の形態３において、ユーザが一般家庭である場合の電力取引支援システムの構成例を示すブロック図である。 本発明の実施の形態４において、ユーザが一般家庭である場合の電力取引支援システムの構成例を示すブロック図である。 実施の形態５に係る電力取引サーバが実行するデマンドレスポンス処理のフローチャートである。 実施の形態５に係る電力取引サーバが実行するデマンドレスポンス精算処理のフローチャートである。 本発明の実施の形態６に係るスマートメータ、ガスメータ、水道メータの構成例を示すブロック図である。 実施の形態６に係るガスメータと水道メータとが実行するメータデータ送信処理のフローチャートである。 実施の形態６に係るスマートメータが実行するメータデータ送信処理のフローチャートである。

以下、本発明の実施の形態に係る電力取引支援システムについて、図１〜図１８を参照して説明する。

（実施の形態１）
本実施の形態の電力取引支援システム１は、複数の取引希望者（以下、ユーザ）の間での電力の売買を仲介し、支払い代行、託送料金の自動計算などを実施するシステムである。なお、スマートメータは電力量計の一種であり、この電力量計は指定機関による検定を受けた信頼性の高い装置をいう。以下、電力量計としてスマートメータを使用する例を説明する。

図１は、電力取引支援システム１のシステム構成図、図２は、図１に示すユーザシステムの詳細図、図３は、ユーザが一般家庭である場合の図１と図２を合体したイメージ図である。

図１及び図３に示すように、本実施の形態に係る電力取引支援システム１は、電力系統ＰＬと、インターネットＩＮと、複数のユーザシステム１０−１，・・・１０−Ｎと、インターネットＩＮに接続されたゲートウエイＧＷと、ゲートウエイＧＷに接続された電力取引サーバ２０と、電力取引サーバ２０に接続されたデータベース２１と、電力取引サーバ２０に接続された決済サーバ２２と、メータデータ管理システム（ＭＤＭＳ）２３と、ユーザシステム１０−１，・・・１０−Ｎが備えるスマートメータとメータデータ管理システム２３とを接続するＡルートのネットワークＮＡと、を備える。

電力系統ＰＬは、電力を伝送する電力送電路であり、配電線、送電線などを含む。
インターネットＩＮは情報を伝達する広域ネットワークである。

ユーザシステム１０−１〜１０−Ｎは、電力の売買を希望するものが保有するシステムである。ユーザは、個人、事業者を問わない。なお、ユーザシステム１０−１〜１０−Ｎを総称する場合には、ユーザシステム１０と呼ぶ。

ユーザシステム１０の構成は任意であるが、基本的には、図２に示すように、発電設備１０１と、パワーコンデショナ（ＰＣＳ）１０２と、負荷１０３と、スマートメータ１０４と、端末装置１０５と、ルータ１０６と、を備える。なお、図３ではユーザシステム１０の一部を省略して示している。

発電設備１０１は、電力を発生する設備であり、太陽光発電設備、風力発電設備、水力発電設備、火力発電設備、地熱発電設備、蓄電池、電気自動車などを含む。

パワーコンデショナ（ＰＣＳ）１０２は、１）発電設備１０１で発電された直流の電力を交流の電力に変換して負荷１０３に供給し、２）発電設備１０１の発電電力が負荷１０３の消費電力より多く、余剰電力が発生した場合には、これを電力系統ＰＬに出力して売電し、３）発電設備１０１の発電電力が負荷１０３の消費電力に不足する場合には、電力系統ＰＬからの電力を負荷１０３に供給することにより、不足分を補う。

負荷１０３は、電力を消費するもの一般を示し、ユーザシステム１０が一般個人のシステムの場合は、例えば、家庭電化製品等であり、ユーザシステム１０が事業者のシステムの場合には、例えば、店舗設備、工場設備等である。

スマートメータ１０４は、電力を測定する電力量計であり、ユーザシステム１０と電力系統ＰＬとを接続する電力線上に配置される。スマートメータ１０４は、１）電力系統ＰＬからこのユーザシステム１０に供給される電力の電力量（ＷＨ）と、２）ユーザシステム１０から電力系統ＰＬに供給される電力の電力量を別個に測定し、期間（時間帯）と共に記録する。スマートメータ１０４は、前述のように、指定機関による検定を受けた信頼性の高い装置である。

スマートメータ１０４は、Ａルート、Ｂルート、Ｃルートの３つのルートで計測した電力量を示すデータ（電力量データ）を外部に出力する。Ａルートは、データを送配電事業者等に通知するルートである。Ｂルートは、ユーザのシステムにデータを出力するルートである。Ｃルートは、送配電事業者等経由で電気事業者（小売事業者）や民間事業者（第三者）にデータを送信するルートである。

本実施の形態では、スマートメータ１０４は、図４（ａ）に例示するように、例えば、３０分単位で、計測した上り電力量と下り電力量を示すデータをＡルートで送配電事業者に設置されている決済サーバ２２に出力する。ここで、上り電力量は、スマートメータ１０４から電力系統ＰＬに向かう電力の電力量である。一方、下り電力量は、電力系統ＰＬからスマートメータ１０４に向かう電力の電力量であり、発電設備１０１の発電電力の不足分として電力系統ＰＬから取り入れた電力の電力量である。

スマートメータ１０４は、予め、自己のユニークな識別情報（スマートメータＩＤ）と自己に割り当てられたハッシュ関数を記憶している。スマートメータ１０４は、図４（ｂ）に示すように、時間帯と電力量を示すデータに、スマートメータＩＤを付加する。スマートメータ１０４は、さらに、データの真正性を担保するため、スマートメータＩＤ、時間帯、上り電力量、下り電力量を示すデータ群ＤＡを自己のハッシュ関数で処理して得られたハッシュ値を、メッセージダイジェストとして付加して、電力量データを生成する。スマートメータ１０４は、生成した電力量データをＡルート経由で決済サーバ２２に送信する。

なお、スマートメータ１０４がメッセージダイジェストを作成する機能を備えていない場合には、電力量データにメッセージダイジェストを付加する必要はない。

端末装置１０５は、デスクトップコンピュータ、ラップトップコンピュータ、スマートフォンなどから構成され、１）電力の買注文或いは売注文の注文データを作成し、２）作成した注文データをインターネットＩＮを介して、電力取引サーバ２０に送信し、３）電力取引サーバ２０から送信される種々の情報をユーザに提供する。なお、端末装置１０５は、直接インターネットＩＮに接続されても、ルータ１０６を介してインターネットＩＮに接続されてもどちらでもよい。

ここで、注文データは、図５（ａ）、（ｂ）に示すように、注文したユーザのＩＤ、売買したい電力の属性、売りと買いの別、売買したい電力量、取引期間、希望単価等の情報を含む。なお、図５（ａ）は売注文データの例、図５（ｂ）は買注文データの例である。ここで電力の属性とは、その電力を発電する元となったエネルギーを意味し、太陽光、風力、水力、火力、原子力、等の別を表す。また、太陽光、風力、水力などを含めて再生可能エネルギーなどと指定可能としてもよい。

図１に示すゲートウエイＧＷは、インターネットＩＮと電力取引サーバ２０との間の通信のプロトコル変換、不正アクセスの遮断などの処理を行う。

電力取引サーバ２０は、コンピュータ装置から構成され、売注文と買注文をマッチングするための様々な機能実現手段をハードウエアとソフトウエアの協働により実現する。具体的には、電力取引サーバ２０は、電力取引の市場を仮想空間上に形成し、１）売注文の注文データと買注文の注文データを受け付け、２）売注文と買注文のマッチング処理を行って売買取引を成立させ、３）約定した取引の情報をユーザの端末装置１０５と決済サーバ２２に通知する。

本電力取引支援システム１は、約定した電力の取引について、電力の不足が生じた場合には、電力を補填し、電力の超過が生じた場合には、これを購入する。即ち、電力取引サーバ２０は、電気事業者による、余剰電力の買い取りと不足電力の供給を前提に、複数の売注文と買注文とをマッチングする。従って、電力取引サーバ２０及び決済サーバ２２を運営する者は、電力小売ならびに発電事業の免許を有する者（以下、単に電気事業者と呼ぶ）又は電気事業者と契約したものである必要がある。このため、本実施の形態では、電力取引サーバ２０及び決済サーバ２２は、電気事業者に設置されているものとする。

電力取引サーバ２０は、図６に例示するように、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、補助記憶装置２０４、表示装置２０５、入力装置２０６、通信装置２０７などを備える。

ＲＯＭ２０２には基本プログラムが格納されている。補助記憶装置２０４には、後述するマッチング処理を実行するためのプログラムが記憶されている。ＣＰＵ２０１は、ＲＡＭ２０３をワークエリアとして、プログラムを実行することにより、必要な機能を実現する。

補助記憶装置２０４は、電力取引の仲介処理を実行するために必要な種々のデータを記憶する。例えば、補助記憶装置２０４は、図５（ａ）、（ｂ）に例示した売注文データ及び買注文データ、図７に例示するユーザテーブル、図８に例示する取引データを記憶する。

図７に例示するユーザテーブルは、この電力取引支援システム１を用いて電力の売買を希望する者の情報を事前登録するテーブルである。例示するように、ユーザテーブルは、ユーザの氏名又は名称、ユーザＩＤ、パスワード、住所、住所の緯度と経度、スマートメータ１０４のＩＤ、端末装置１０５のＩＤ、契約する電気事業者との電力の売買代金、決済方法、口座番号、連絡先などの情報を含む。電力取引支援システム１を用いて電力の売買を希望する者は、定められた手続きにより、これらの情報をユーザテーブルに予め登録する。

図８に例示する取引データは、マッチングにより取引が成立した売注文と買注文について、取引の内容を示すデータである。例示するように、取引データは、スマートメータＩＤ、ユーザアカウント（ユーザＩＤ）、成約日時、電力取引の時間帯、売電力量（ｋＨＷ）、買電力量（ｋＷＨ）、希望単価（円／ｋＷＨ）、成約単価（円／ｋＷＨ）、電力の属性、ユーザシステム１０の所在地（住所・緯度・経度等）、託送料、手数料、その他のデータである。

電力取引サーバ２０は、各端末装置１０５から送信された売注文と買注文とを受け付ける手段と、売注文と買注文とを、電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段と、して機能しうる。

図６に示すデータベース２１は、複数の記憶装置２１１〜２１ｍを備え、電力取引サーバ２０の通信装置２０７に接続されている。電力取引サーバ２０は、ＤＢ２１を外部記憶装置として用いて、内部の補助記憶装置２０４と同様に受信した売注文データ、受信した買注文データ、ユーザテーブル、電力取引データなどを、複数の記憶装置２１１〜２１ｍに並列に記憶させる。さらに、電力取引サーバ２０は、補助記憶装置２０４と各記憶装置２１１〜２１ｍとに、過去のデータ全体と今回のデータとを含むデータ全体のメッセージダイジェストを付加する。このような形態により、電力取引サーバ２０は、これらのデータを記憶する。なお、第ｉの記憶装置２１ｉに記憶させるデータに関して、１段前の記憶装置２１−（ｉ−１）の記憶データ全体（メッセージダイジェストを含む）と記憶装置２１−ｉに今回新たに記憶するデータとのデータ全体のメッセージダイジェストを付加するようにしてもよい。

決済サーバ２２は、ハードウエア的には、図６に示した電力取引サーバ２０と同様の構成を有する。この場合、補助記憶装置２０４には、後述する精算処理、決済処理を行うためプログラムが記憶され、ＣＰＵ２０１がこのプログラムを実行することにより必要な機能を実現する。具体的には、決済サーバ２２は、決済に関連するデータを記憶し、また、ユーザシステム１０−１〜１０−Ｎの各スマートメータ１０４からＡルートを介して３０分単位で送信されてくる電力量データをユーザＩＤ別及び時刻順にソートして、図９に例示するように蓄積する。なお、ここでも、過去のデータ全体（メッセージダイジェストを含む）と今回のデータを含む全データのメッセージダイジェストを付加し、複数箇所に格納することによりブロックチェーンを構成してもよい。

また、決済サーバ２２は、図７に示すユーザテーブルと図８に示す取引データを記憶する。

決済サーバ２２は、例えば、所定期間毎、例えば、毎月特定の日に、ユーザＩＤ別に、取引データと電力量履歴データを集計し、全売電力の売上金額、全買電力の購入費用を集計する。決済サーバ２２は、ユーザテーブルを参照し、各ユーザの決済方法を判別し、設定されている決済方法で決済を行う。例えば、あるユーザの決済方法として、銀行振り込み及び銀行引き落としが設定されていれば、そのユーザについては、全銀システム等にアクセスすることにより、そのユーザの売電力料金を登録済の銀行口座に振り込んで支払いし、買電力料金を登録済の銀行口座から引き落とす。

なお、決済サーバ２２も、過去のデータ全と今回のデータを含む全データのメッセージダイジェストを付加し、複数箇所に格納することによりブロックチェーンを構成してもよい。

メータデータ管理システム２３は、Ａルートのネットワークと電力取引サーバ２０及び決済サーバ２２に接続され、Ａルートを介して複数のスマートメータ１０４から電力量データを受信し、電力取引サーバ２０と決済サーバ２２に提供する。メータデータ管理システム２３は、電力取引サーバ２０と決済サーバ２２からの要求に応じて電力量データを提供してもよい。

決済サーバ２２は、マッチングにより成約した売注文と買注文の電力量と単価、及び、成約した売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと、成約した買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データと、に基づいて、成約した売注文を発行したユーザへの支払い額と、成約した買注文を発行したユーザへ請求額とそれぞれ求める手段として機能する。

次に、上記構成を有する電力取引支援システム１を用いて、電力を売買する処理を説明する。

（事前準備）
電力取引支援システム１を用いて電力の売買を希望する者は、予め定められた手続きにより、ユーザ登録を行い、図８に例示したユーザテーブルに所定のユーザ情報を登録し、電力取引サーバ２０とＤＢ２１と決済サーバ２２に格納する。

また、スマートメータ１０４がＡルートを介して出力する電力量データを、決済サーバ２２に送信するメータデータ管理システム２３に登録する。

スマートメータ１０４は、常時、電力を積算して電力量を求め、３０分単位で、Ａルートで図４（ｂ）に示す電力量データを出力する。メータデータ管理システム２３はこの電力量データを受信し、決済サーバ２２に転送し、決済サーバ２２は、これを図９に示すように電力量履歴データとして蓄積するが、ブロックチェーン形式で蓄積してもよい。

（注文処理）
ユーザ登録終了後、電力の売買を希望する者は、端末装置１０５を操作して、図５（ａ）、（ｂ）に例示した注文データを生成し、電力取引サーバ２０に送信する。

ここで、売注文時の属性は、自身が所有する発電設備１０１の属性を設定する。
一方、買注文時の属性は、あえて購入したい電力の種類を特定する。例えば、再生可能エネルギーのみを購入したい場合には、太陽光、風力、水力を項別に指定しても良いし、再生可能エネルギーなど包括的に指定してもよい。
なお、ここでのメッセージダイジェストは、例えば、ユーザの使用する端末装置１０５に割り当てられたハッシュ関数で作成されるハッシュ値である。

電力取引サーバ２０は、各端末装置１０５から送信された注文データを受信し、これを売注文と買注文とに分類して補助記憶装置２０４とＤＢ２１に蓄積する。

なお、注文データを生成する手法自体は任意である。例えば、電力取引サーバ２０が、提供する注文データを生成するために必要なデータを入力又は選択するＷｅｂページを提供し、ユーザがこれに必要事項を入力して、確認及び承認することで、自動的に注文データを生成するようにしてもよい。

電力取引サーバ２０のＣＰＵ２０１は、マッチングプログラムを実行することにより、図１０のフローチャートに示すマッチング処理を常時実行している。

このマッチング処理において、ＣＰＵ２０１は、所在地、属性、期間・時間帯、単価、電力量をキーとして条件が合致する売注文と買注文を選択する（ステップＳ１１）。なお、マッチングの相手先の注文は１つである必要はない。

例えば、図５（ａ）に示すように、２０１９年の１１月１０日９：００〜１１月１７日１６：００に、３０ｋＷＨを売りたい場合に、例えば、１１月１０日１０：００〜１１月１３日１０：００に、１５ｋＷＨを購入したいＡさん及び１１月１２日１０：００〜１１月１６日１５：００に２０ｋＷＨを購入したいＢさんとの取引を成立させてもよい。この場合、ＣＰＵ２０１は、予め設定されている優先度に従って、例えば、ＡさんとＢさんに、それぞれ１５ｋＷＨを売却するようにしてもよい。この場合、Ｂさんは、５ｋＷＨ分購入電力が不足するが、この分を、他の売却希望者の売却分の全部又は一部を割り当てたり、或いは、電気事業者がＢさんとの契約に基づいて不足部分を供給する等してもよい。

同様に、図５（ａ）に示すように、１１月１０日９：００〜１１月１７日１６：００に、３０ｋＷＨを売りたい場合に、例えば、１１月１０日１０：００〜１１月１３日１０：００に、１０ｋＷＨを購入したいＡさんと、１１月１２日１０：００〜１１月１６日１５：００に、１５ｋＷＨを購入したい、Ｂさんとの取引を成立させる等してもよい。この場合、優先度に従って、例えば、ＡさんとＢさんに、それぞれ１０ｋＷＨと１５ｋＷＨ、合計２５ｋＷＨを売却し、余剰の５ｋＷＨについて、別の人に売却したり、電気事業者で購入するようにしてもよい。

ＣＰＵ２０１は、選択した取引データについて、その地理的条件から託送量を計算し、託送量等を考慮しても、希望売買金額を満たすか否かを判別する（ステップＳ１２）。

託送料等については、例えば、売注文の注文データを受け付けたときに、売り単価に予め設定された託送料金を加算してもよい。託送料金の求め方は任意である。平均的な固定額を加算してもよく、従量制の金額を加算してもよい。従量制の例として、例えば、取引成立後に、売り手と買い手の例えば、緯度・経度情報からその直線距離又は送電線・配電線の距離を求め、その距離に応じた託送料金を設定してもよい。また、単価に上乗せするのではなく、手数料として精算処理時に引き落とす等してもよい。

ステップＳ１２で、条件を満たさない場合（ステップＳ１２：Ｎｏ）、ステップＳ１１にリターンし、満たす場合（ステップＳ１２：Ｙｅｓ）、取引を成立させ、注文の組み合わせを補助記憶装置２０４とＤＢ２１に登録する（ステップＳ１３）。また、図８に示す取引データを生成し、自ら記憶すると共に決済サーバ２２に送信する。
さらに、ユーザテーブルを参照し、取引が成立した旨をメールなどでユーザに通知する（ステップＳ１４）。

このようにして、電力取引サーバ２０は、注文データの受け付け、注文のマッチング、成約した取引を決済サーバ２２に通知すること、マッチングの結果をユーザに通知することなどの処理を繰り返して実行する。

なお、本実施の形態においては、注文者は、自己の注文について、「こだわり条件」を設定可能である。電力取引サーバ２０は、ステップＳ１１でマッチングを行う際に、「こだわり条件」が設定されている場合には、「こだわり条件」を優先的に考慮する。例えば、買い手が、自然エネルギーにより発電された電力を価格に関わらず購入することを希望する場合がある。この場合、ユーザは、図５（ｂ）に示す買注文データの属性の欄に「自然エネルギー」を設定する。同様に、例えば、買い手が、特定地域で発電された電力のみを購入することを希望する場合がある。この場合、ユーザは、図５（ｂ）に示す買注文データの発電地域の欄（図示せず）に「Ｋ県Ｊ市」、「Ｋ地方」等と指定する。同様に、売り手が、特定地域のユーザにのみ電力を売却したいと希望する場合がある。この場合、図５（ａ）に示す売注文データの消費地域の欄（図示せず）に、「Ｌ県」「Ｍ地方」等と指定する。

ＣＰＵ２０１は、図１０に示すマッチング処理のステップＳ１１内で、図１１に示すこだわり条件による候補選択処理を実行する。
この処理においては、電力取引サーバ２０は、こだわり条件があるか否かを判別する（ステップＳ１１１）。こだわり条件がある場合、マッチング対象とする注文データから、この条件に合致しないものをマッチングの対象から除外する（ステップＳ１１２）。残りの注文データがマッチングの対象候補とされ、他の条件が合致すれば、成約となる。

例えば、マッチング処理の対象となっている買注文データの属性の欄が「自然エネルギー」に設定されている場合、電力取引サーバ２０は、図１０のステップＳ１１のマッチング処理を実行するなかで、ステップＳ１１１の処理を実行し、こだわり条件ありと判別し、「属性」が太陽光、風量、地熱、水力等と設定された売注文データのみをマッチングの対象とし、「属性」が火力、原子力等に設定されている売注文データをマッチングの対象から除外する。同様に、マッチング処理の対象となっている買注文データの「発電地域」の欄が「Ｋ県」に設定されている場合、電力取引サーバ２０は、ユーザデータを参照して、Ｋ県に所在するユーザの売注文データをマッチングの対象とし、他地域に所在するユーザからの売注文データをマッチングの対象から除外する。

また、マッチング処理の対象となっている売注文データの「消費地」の欄に「Ｋ県」が設定されている場合、電力取引サーバ２０は、ユーザデータを参照して、Ｋ県に所在するユーザの買注文データをマッチングの対象とし、他地域に所在するユーザからの買注文データをマッチングの対象から除外する。
なお、こだわり条件を満足するだけでは、成約とはならず、他の取引条件を充足することで成約となる。

また、図１０のステップＳ１１で、価格面のマッチングを行う際には、託送料金（発電地から消費地まで電力を送配電するためのコスト）を考慮してマッチングを行うことが望ましい。託送料については、固定額とすることも可能であるが、送配電距離が長くなるに従って託送料を高く、送配電距離が短くなるに従って託送料を安くすることも可能である。この場合のマッチング処理の内容を図１２を参照して説明する。

電力取引サーバ２０のＣＰＵ２０１は、図１０に示すマッチング処理のステップＳ１１の処理内で、図１２に示す価格による候補選択処理を実行する。

この処理においては、ＣＰＵ２０１は、まず、マッチングの対象として選択した売注文と買注文について、少なくともどちらか一方に希望価格が設定されているか否かを判別する（ステップＳ１２１）。希望価格が設定されている場合（ステップＳ１２１：Ｙｅｓ）、電力取引サーバ２０は、注文データに含まれているユーザＩＤをキーにユーザデータを検索し、ユーザの住所・緯度・経度等の地域を特定する情報を取得する（ステップＳ１２２）。次に、売り手の地域と買い手の地域から、その距離或いは送配電ルートを求め、求めた距離又は送配電ルートに基づいて、託送料の単価を計算する（ステップＳ１２２）。なお、取引データの所在地の情報から地理的情報を得ても良い。次に、電力取引サーバ２０は、売注文データに含まれている希望価格に求められた託送料の単価を加算して希望売却価格を補正し、補正した希望売却価格と買注文データに設定されている購入希望価格とを比較して（ステップＳ１２３）、条件を満たすか否かを判別する（ステップＳ１２４）。条件を満たす場合には、取引の候補として残し（ステップＳ１２５）、条件を満たさない場合には、取引の候補から除外する（ステップＳ１２６）。

例えば、売却希望単価が１７円の売注文データと、購入希望単価が１８円の買注文データとがマッチングの対象として選択されたとする。希望価格だけでは、成約可能な状態となっている。ただし、売り手と買い手の所在地から計算された、託送料金の単価が１円より高くなると、価格条件が合致しなくなり、成約は困難となる。電力取引サーバ２０は、このような処理を行うことにより、合理的根拠に基づく託送料金を設定し、電力の地産地消を促進することができる。

なお、電力取引サーバ２０は、自動的なマッチング処理の他、ユーザ自身による取引先の指定による取引も可能とすることができる。この場合、注文者は、自己の売注文データ又は買注文データを電力取引サーバ２０に送信する。電力取引サーバ２０は受信した注文データに基づいて、取引の候補となりうる注文データを一定数量抽出し、図１３に例示するような一覧を作成して、ユーザに提示する。なお、図１３は、買注文を発行したユーザに提示される取引対象候補売注文一覧の例を示す。ユーザは、端末装置１０５にこの一覧を受信し、この一覧から、自己の希望条件に合致するものを取引の対象として選択し、電力取引サーバ２０に取引希望データを送信する。電力取引サーバは、受信した取引希望データについて、成約可能か否か改めてマッチング処理を行う。
この際、電力取引サーバ２０は、ステップＳ１２２、Ｓ１２３と同様の処理を行って託送料金を求め、託送料金と希望価格とその合計単価をリストに含める。これにより、ユーザは、希望価格だけでなく、実際のコストを意識して成約可能な注文を選択できる。

一方、決済サーバ２２は、図１４に示す個々の取引についての精算処理を実行している。この精算処理においては、電力取引サーバ２０から受信した取引データをアカウント単位及びスマートＩＤ単位に抽出し（ステップＳ２１）、取引データとスマートメータ１０４で求められた電力量データとに基づいて、電力の売却額又は購入額を計算する（ステップＳ２２）。

この際、売注文については、本システムの使用料の課金処理、買注文については、託送料の課金処理、本システムの使用料の課金処理をあわせて行う。また、契約不履行の補填やペナルティがあったか否かを判定し、精算に反映する。より詳細に説明すると、ユーザが所有する発電設備１０１は、売注文で特定した電力量の電力を発生できるとはかぎらない。例えば、発電設備１０１が太陽電池、風力発電等である場合、天候により発電量が変化し、売注文データで指定した電力量以上の電力量を発電することもあれば、指定した電力量を発電できないこともある。そこで、注文データと実際の売電電力量或いは買電電力量とが一致しているか否かを判別し、異なる場合には、電気事業者との調整が必要になる。

例えば、図５（ａ）に示す売注文が成立していたとする。この売注文では、取引期間に３０ｋＷＨの電力が売電されている。これに対し、スマートメータ１０４で測定された電力量データでは、この取引期間の上り電力量と下り電力量との差が３１ｋＷＨであったとする。この場合、１ｋＷＨ余分に電力を売却していることになる、このため、売却額は、希望単価１８円／ｋＷＨでの３０ｋＨＷ分の売り上げと、電気事業者への１ｋＷＨの売却額の和となる。決済サーバ２２は、ユーザデータに基づいて、ユーザの契約先の電気事業者を特定し、その電気事業者の買電単価を判別し、買取単価と電力量からユーザへの支払い額を特定し、また、その電気事業者への請求額を設定する。

また、仮にこの取引期間のスマートメータ１０４で測定された上り電力量と下り電力量との差が２５ｋＷＨであったとする。この場合、売却量が５ｋＷＨ不足していることになる。このため、実際の売り上げは、１８円／ｋＷＨでの２５ｋＷＨ分の売り上げと、電気事業者からの５ｋＷＨの購入の和となる。決済サーバ２２は、ユーザデータに基づいて、ユーザの契約先の電気事業者を特定し、その電気事業者の売電単価を判別し、売取単価と電力量からユーザへの請求額を特定し、また、その電気事業者への支払額を設定する。

また、図５（ｂ）に示す買注文が成立していたとする。この買注文では、取引期間に７ｋＷＨの電力が購入されている。これに対し、スマートメータ１０４で測定された電力量データでは、この取引期間の上り電力量と下り電力量との差が１０ｋＷＨであったとする。この場合、３ｋＷＨ余分に電力を購入していることになる。このため、希望単価１７円／ｋＷＨでの７ｋＨＷ分の価格と別途求められている託送量の価格とシステムの使用料、さらに、契約先の電気事業者への３ｋＷＨ分の電力料金を請求する。決済サーバ２２は、その電気事業者への支払い額と送配電会社への支払い額を設定する。
このようにして、決済サーバ２２は、成約取引毎に、成約した売注文・買注文だけでなく、ユーザテーブルを参照し、そのユーザが電気事業者と契約している売電単価及び買電単価を求め、決済用の計算を行う。さらに、託送料及びシステム使用料の課金処理、電気事業者、送配電業者への支払い額の計算なども行う。

決済サーバ２２は、このようにして求められた個々の電力取引についての決済金額をユーザ別、電力小売取引業者等別、配送電会社別に記憶する。

また、決済サーバ２２は、ユーザ別に定められた決済のタイミングで図１５に示す決済処理を実行する。
まず、決済サーバ２２は、ユーザ１人を特定し（ステップＳ３１）、決済対象期間中の個々の決済金額（売却額、購入額）と取引項目のリストを作成する（ステップＳ３２）。続いて、決済期間内の売却額と購入額をそれぞれ累算して売却額の総額と購入額の総額を求める。更に、売却額の総額と購入額の総額の差分を求める（ステップＳ３３）。なお、この段階では、電気事業者との売電・買電の金額も累算する。

決済サーバ２２は、次に、図７に示すユーザテーブルに規定されている決済方法に従って、決済処理を行う（ステップＳ３４）。例えば、ユーザテーブルに規定されている決済方法が銀行口座による決済処理ならば、例えば、全銀システムを介してユーザデータにより特定される銀行口座にアクセスし、決済対象金額を振り込み或いは引き落とす。その他、電子マネーでの支払い、為替での支払い、クレジットカードでの支払い、請求書の発行処理等を行う。
決済サーバ２２は、契約内容に応じて、インターネットＩＮを介して決済情報をユーザに送信する（ステップＳ３５）。

このような処理を繰り返すことにより、検定されたスマートメータ１０４で測定された電力量に基づいた、電力取引の決済処理が実行される。なお、決済サーバ２２は、電気事業者、送配電事業者等についても累算処理を実行する。

このようにして、各ユーザは、端末装置１０５を操作して、注文データを、電力取引サーバ２０に送信することで、電力を希望する条件で売買することができる。

（実施の形態２）
上記実施の形態１においては、電力データの送信にスマートメータ１０４のＡルートを使用したが、Ｃルートを使用することも可能である。以下、Ｃルートを使用する実施の形態を図１６を参照して説明する。

図１６は、図３に対応するシステム構成図である。
本支援システムの基本構成は実施の形態１の電力取引支援システム１と基本的に同一である。ただし、メータデータ管理システム２３は、送配電会社に設置され、電気事業者には、電力取引サーバ２０、決済サーバ２２、メータデータ管理システム２３’が設置される。

電力取引サーバ２０と決済サーバ２２とは、それぞれ、実施の形態１と同様のデータを記憶する。
売注文データと買注文データとは、電力取引サーバ２０に送信される。電力取引サーバ２０は、図１０に示すマッチング処理を実行し、図８に示す取引データを決済サーバ２２に送信する。
決済サーバ２２は、図１４に示した精算処理及び図１５に示した決済処理のうちのステップＳ３１〜Ｓ３３を実行する。
電力量データは、Ａルートでメータデータ管理システム２３に送信され、さらに、Ｃルートを介してメータデータ管理システム２３’に転送され、電力取引サーバ２０と決済サーバ２２に転送される。

（実施の形態３）
実施の形態２において、電気事業者自らが電力の取引を実行する必要はない。契約を結んだ第三者機関により電力取引処理を実行することも可能である。また、電力取引処理の一部のみを第三者機関に委託することも可能である。図１７は、マッチング処理を第三者機関に委託した場合のシステム構成を例示する。

この構成では、電力取引サーバ２０は、委託先の第三者機関に設置される。
一方、電気事業者には、決済サーバ２２とメータデータ管理システム２３’が設置され、送配電会社には、メータデータ管理システム２３が設置される。
図１７のシステム構成において、売注文データと買注文データのマッチングまでの処理は、実施の形態１及び２と同様である。
成約した取引のデータ、即ち、取引データは、電力取引サーバ２０から決済サーバ２２に専用線を介して伝達される。
決済サーバ２２は、決済サーバ２２は、精算処理及び決済処理を実行する。

スマートメータ１０４からの電力量データは、送配電業会社に設置されたメータデータ管理システム２３に送信される。メータデータ管理システム２３は、各電気事業者分の電力量データをＣルートを介してメータデータ管理システム２３’を介して決済サーバ２２に送信する。

（実施の形態４）
Ｂルートを介して電力データを電気事業者に通知することも可能である。Ｂルートを使用する場合の構成例を図１８に示す。
この場合、スマートメータ１０４の出力は、無線又は電力線通信で送信され、これらを受信する機能を有するインタフェース１０８を介してルータ１０６を介して端末装置１０５に通知される。インタフェース１０８から端末装置１０５に直接通知されても良い。
端末装置１０５は、Ｂルートで通知された電力データをインターネットＩＮを介してメータデータ管理システム２３に適宜送信する。以後の処理は、実施の形態１と同様である。

なお、この形態の場合でも、第三者機関に電力取引サーバ２０を設置し、電気事業者に決済サーバ２２を設置するような応用も可能である。

電力取引サーバ２０として、ブロックチェーンを構成する例を示したが、電力取引サーバの構成自体は任意である。

また、以上の説明では、電力取引サーバ２０と決済サーバ２２とを区別し、電力取引サーバ２０と決済サーバ２２とが、通信を行いながら協働して電力取引を支援する電力取引支援システムを構成する例を説明した。この発明はこれに限定されない。例えば、電力取引サーバ２０と決済サーバ２２とが、両サーバの機能を兼ね備える１台の電力取引支援装置から構成されてもよい。この場合、電力取引支援装置は、ネットワークを介して売注文と買注文とを受け付ける受付手段と、売注文と買注文とをマッチングし、注文を成約させるマッチング手段と、成約した注文について、電力量計で測定して得た電力量データとに基づいて決済処理を行う決済手段を備える。クラウドサーバ或いはクラウドシステムのように、複数のコンピュータから構成される大きなシステムの一部として機能的に構成されてよい。

なお、受付手段とマッチング手段と決済手段とを備えるコンピュータが異なる場合には、それぞれに、対応するプログラムがインストールされる。

また、サーバの設置場所はどこでもよく、管理権限が上述の例に相当すればよい。さらに、管理も上述した電気事業者、送配電事業者、委託契約を結んだ第三者機関等に限定されるものではない。

上記実施の形態で例示した構成は適宜変更可能である。例えば、図１、図３、図１６〜図１８で示した電力取引支援システムの構成は、例示であり、適宜変更してもよい。また、図２に示したユーザシステム１０の構成も適宜変更可能である。例えば、発電設備１０１を備えない買電専門のユーザシステム１０でもよく、負荷１０３を備えない売電専門のユーザシステム１０でもよい。
また、ユーザと電力取引サーバ２０を接続する通信回線は、インターネットＩＮに限定されず、他の任意の通信ネットワークを使用できる。

（実施の形態５）
上記の電力取引支援システム１をデマンドレスポンスに活用することも可能である。以下、電力取引支援システム１をデマンドレスポンスに利用する実施の形態について説明する。

ここで、デマンドレスポンスとは、市場価格の高騰時または系統信頼性の低下時において、設定またはインセンティブの支払に応じて、需要家側が電力の使用を抑制するよう電力の消費パターンを変化させることである。
本実施の形態では、ユーザ情報の登録ときに、デマンドレスレスポンスに対応するか否か、電気事業者との契約内容等を予め登録しておく。

電気事業者等から電力使用の抑制（制限）の要請が発生すると、その要請は電力取引サーバ２０に通知される。
電力取引サーバ２０は、要請に応答して、図１９に示すデマンドレスポンス処理を開始する。

電力取引サーバ２０のＣＰＵ２０１は、ユーザテーブルを参照し、デマンドレスポンスに対応するユーザをピックアップする（ステップＳ４１）。

次に、ＣＰＵ２０１は、デマンドレスポンスの要求内容に応じて、対象となるユーザを抽出する（ステップＳ４２）。例えば、ある特定の地域のみが対象となる場合には、住所・緯度・経度などの情報から、対象となるユーザを抽出する。また、例えば、ある特定の電気事業者と契約しているユーザのみが対象となる場合には、ユーザ情報に含まれている契約情報からその電気事業者と契約しているユーザを抽出する。また、例えば、契約容量が基準値以上のユーザのみが対象となる場合には、要求を満たす容量のユーザを抽出する。

ＣＰＵ２０１は、抽出した各ユーザについて、予め定められた基準に従って、デマンドの内容と各ユーザの節電能力に基づいて、電力の使用量を制限・抑制する内容（制限条件）を設定する（ステップＳ４３）。例えば、契約容量に基づいて、ユーザＡについては、要求された時間帯の電力使用量の上限を２ｋＷＨとし、ユーザＢについては、要求された時間帯の電力使用量の上限を８ｋＷＨとする。

ＣＰＵ２０１は、ステップＳ４２で抽出したユーザのうち、一部のユーザについて、登録されている連絡先（例えば、メールアドレス、スマートホンアプリのプッシュ通知）に、デマンドレスポンスに対応するかの問い合わせと制限条件（例えば、期間、使用量の上限など）とを含む案内を通信装置２０７を介して送付する（ステップＳ４３）。

その後、ＣＰＵ２０１は、案内を送付したユーザからの返信を待ち受ける（ステップＳ４４）。ＣＰＵ２０１は、返信がデマンドレスポンスを受け入れるという返信の場合には、受け入れによって、達成された消費電力量の削減量を累算する（ステップＳ４４）。ＣＰＵ２０１は、所定のタイミングに達したか否かを判別し（ステップＳ４５）、達していなければ（ステップＳ４５：Ｎｏ）、ステップＳ４４にリターンする。一方、所定のタイミングに達していれば（ステップＳ４５：Ｙｅｓ）、削減量の累算値が予め設定されている目標量に達した可否かを判別する（ステップＳ４６）。

達していないと判別した場合（ステップＳ４６：Ｎｏ）、ステップＳ４３にリターンし、案内を出していないユーザの一部に案内を送信する。

ＣＰＵ２０１は、削減量の累積量が目標量に達するまで、ステップＳ４３〜Ｓ４６の処理を繰り返す。
削減量の累積量が目標量に達したと判別した場合（ステップＳ４６：Ｙｅｓ），参加者の情報をセーブすると共に決済サーバ２２に通知して（ステップＳ４７）、処理を終了する。

デマンドレスポンスの期間終了後、決済サーバ２２のＣＰＵは、図２０に示すデマンドレスポンス精算処理を実行し、各参加者について精算処理を行う。

決済サーバ２２のＣＰＵは、ステップＳ４７で取得した情報に基づいて、未精算の参加者を1人通出する（ステップＳ５１）。次に、その参加者の電力量履歴データから、デマンドレスポンス実施時間帯の電力消費実績を取得し（ステップＳ５２）、そのユーザに割り当てられているデマンドレスポンスの制限を満たしているか否かを判別する（ステップＳ５３）。

制限を満たしていると判別すれば（ステップＳ５３：Ｙｅｓ）、その参加者に予め設定されている報酬を付与し（ステップＳ５４）、満たしていなければ（ステップＳ５３：Ｎｏ）、ステップＳ５４をスキップする。

決済サーバ２２のＣＰＵは、全ての参加者について、デマンドレスポンスに基づく精算を実行したか否かを判別し（ステップＳ５５）、未精算の参加者が残っていればステップＳ５１にリターンし（ステップＳ５５：Ｎｏ）、全参加者について精算が終了していれば（ステップＳ５５：Ｙｅｓ）、処理を終了する。

決済サーバ２２のＣＰＵは、図１５の決済処理のステップＳ３２，Ｓ３３において、ステップＳ５４で付与した報酬を考慮する。例えば、報酬として一定の報酬額が与えられた場合は、ステップＳ３２のリストの項目として、デマンドレスポンスでの報酬である旨が記録され、さらに、そのユーザへの支払い額にこの報酬額が含まれる。
これにより、デマンドレスポンスをより効率的に実施できる。

なお、デマンドレスポンスの事前登録を不要として、ステップＳ４１をスキップして、ステップＳ４２から処理を開始するようにしてもよい。また、電力使用制限のしかた、制限条件を満たしたときの報酬は任意に設定可能である。

（実施の形態６）
上記の電力取引支援システム１においては、処理の対象は電力に関する事項のみであった。この発明はこれに限定されない。処理の対象は任意である。
電気に関する料金と共にガス料金、水道料金を処理する例を説明する。

本実施の形態においては、図２１に示すように、スマートメータ１０４，ガスメータ１０１０，水道メータ１０２０は、それぞれ、計器本体１０４１，１０１１，１０２１と共に制御部１０４２，１０１２，１０２２と通信装置１０４３，１０１３，１０２３を備える。また、スマートメータ１０４，ガスメータ１０１０，水道メータ１０２０は、それぞれ、入力装置１０４４，１０１４，１０２４、表示装置１０４５，１０１５，１０２５を備える。

計器本体１０４１，１０１１，１０２１は、それぞれ、消費電力量、消費ガス量、消費水道量を測定する。

制御部１０４２，１０１２，１０２２は、プロセッサとタイマを備え、各部を制御する。通信装置１０４３，１０１３，１０２３は、ホームネットワークＨＮを介して相互に接続されており、他装置と通信を行う。入力装置１０４４，１０１４，１０２４は設定情報等の任意の情報を入力し、表示装置１０４５，１０１５，１０２５は測定データ、メニューなどを表示する。

本実施の形態においては、各ユーザは、ガス使用料及び水道使用料についても、電力取引支援システム１を介した請求及び支払いに予め同意しているものとする。この場合、ユーザテーブルには、契約先のガス会社、料金プラン、契約先の水道会社、料金プランなどが予め登録されている。

ガスメータ１０１０の制御部１０１２と水道メータ１０２０の制御部１０２２は、それぞれ、タイマ割り込みなどにより、適当な周期で図２２のメータデータ送信処理を実行し、まず、データの送信タイミングに達したか否かを判別する（ステップＳ６１）。
送信タイミングに達していいない場合（ステップＳ６１：Ｎｏ）、処理を終了し、達していれば（ステップＳ６１：Ｙｅｓ）、前回の送信時から直近までの計測データを、通信装置１０１３と１０２３、ホームネットワークＨＮを介してスマートメータ１０４に送信する（ステップＳ６２）。

スマートメータ１０４の制御部１０４２は、送信されてきた、計測データを、通信装置１０４３を介して受信し、一旦記憶する。

スマートメータ１０４の制御部１０４２は、タイマ割り込みなどにより、適当な周期で図２３のメータデータ送信処理を実行し、まず、データの送信タイミングに達したか否かを判別する（ステップＳ７１）。
送信タイミングに達していいない場合（ステップＳ７１：Ｎｏ）、処理を終了し、達していれば（ステップＳ７１：Ｙｅｓ）、受信して記憶しておいたガスメータ１０１０と水道メータ１０２０の測定データを、Ａルート、Ｂルート、又はＣルートとメータデータ管理システム２３を介して決済サーバ２２に送信する。

決済サーバ２２は、スマートメータ１０４の制御部１０４２は、送信されてきた計測データを、通信装置１０４３を介して受信し、一旦記憶する。決済サーバ２２のＣＰＵ２０１は、ガスメータ１０１０から受信したデータから、ガス使用料をユーザデータに登録されている契約情報等から求める。決済サーバ２２のＣＰＵ２０１は、水道メータ１０２０から受信したデータから、水道料と下水道料をユーザデータに登録されている契約情報等から求める。

決済サーバ２２のＣＰＵ２０１は、図１５の決済処理のステップＳ３２，Ｓ３３において、求めておいたガス使用料と水道使用料をユーザへの請求額の一部として使用する。
一方、各ガス会社と水道会社については、手数料を差し引いた上で、会社別に売上額として累算され、処理される。

このようにして、各ユーザについて、電気料とガス料と水道料とが一括して処理される。

以上の説明では、ガスメータ１０１０と水道メータ１０２９がそれぞれ通信装置１０１３と１０２３を備える構成を例示したが、スマートメータ１０４に測定値を伝達できるならば、その構成は任意である。例えば、ガスメータ１０１０と水道メータ１０２９の表示装置１０１５と１０２５がそれぞれ表示する計測値を光学的に読み取って、スマートメータ１０４の通信装置１０４３に無線又は有線で伝達する外付け装置を配置する等してもよい。

以上の説明では、スマートメータの他にガスメータと水道メータの測定データを処理する例を示したが、処理対象のデータは、ガス使用量データ、水道使用量データに限定されない。他の任意の装置で取得された課金又は請求の対象となるデータを処理対象としうる。

１ 電力取引支援システム
１０ ユーザシステム
２０ 電力取引サーバ
２１ データベース
２２ 決済サーバ
２３ メータデータ管理システム（ＭＤＭＳ）
１０１ 発電設備
１０２ パワーコンデショナ（ＰＣＳ）
１０３ 負荷
１０４ スマートメータ
１０５ 端末装置
１０６ ルータ
１０８ インタフェース
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ 補助記憶装置
２０５ 表示装置
２０６ 入力装置
２０７ 通信装置
１０１０ ガスメータ
１０２０ 水道メータ
１０４１，１０１１，１０２１ 計器本体
１０４２，１０１２，１０２２ 制御部
１０４３，１０１３，１０２３ 通信装置
１０４４，１０１４，１０２４ 入力装置
１０４５，１０１５，１０２５ 表示装置

上記目的を達成するため、本発明に係る電力取引支援システムは、
ネットワークを介して連携して電力の取引を支援する電力取引支援システムであって、
端末装置を介してユーザから送信された売注文と買注文とを受け付ける手段と、売注文と買注文とを、電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段とを備える電力取引サーバと、
前記電力取引サーバのマッチング手段により成約した売注文と買注文の、電力量と、単価と、売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと、買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データと、に基づいて、成約した売注文を発行したユーザへの成約した取引に関する支払い額を、そのユーザからの電力量データが示す系統への供給電力量が成約した売注文の電力量以上の場合には、成約した売注文の電力量と単価とに基づいて求め、成約した買注文を発行したユーザへの成約した取引に関する請求額を、そのユーザからの電力量データが示す系統から取り入れた電力量が成約した買注文の電力量以上の場合には、成約した買注文の電力量と単価とに基づいて求める決済サーバと、
を備える。

例えば、売注文、取引対象の電力の属性を特定する情報を含み、買注文は、取引対象の電力の属性を特定する情報を含む。前記電力取引サーバのマッチング手段は、例えば、属性が一致する売注文と買注文の間で注文を成約させる。
例えば、売注文は、地域を特定する情報を含み、買注文は、地域を特定する情報を含む。前記電力取引サーバのマッチング手段は、例えば、地域が一致する売注文と買注文のなかで注文を成約させる。
前記電力取引サーバのマッチング手段は、所定の電気事業者による余剰電力の買い取りと不足電力の供給を前提に、電力量が一致しない売注文と買注文であっても、条件が満たされる場合には、その売注文と買注文を成約させてもよい。
前記電力取引サーバのマッチング手段は、所定の電気事業者による余剰電力の買い取りと不足電力の供給を前提に、複数の売注文を組み合わせて１つ又は複数の買注文と成約させ、複数の買注文を組み合わせて１つ又は複数の売注文と成約させてもよい。
前記決済サーバは、例えば、成約した売注文を発行したユーザからの電力量データが示す系統への供給電力量が成約した売注文の電力量を超える部分については、電気事業者による余剰電力の買い取りの単価に基づいて、該ユーザへの支払い額を求める。
前記決済サーバは、例えば、成約した売注文を発行したユーザからの電力量データが示す系統への供給電力量が成約した売注文の電力量未満の場合には、不足部分については、電気事業者による不足電力の供給の単価に基づいて、該ユーザへの請求額を求める。
前記決済サーバは、例えば、成約した買注文を発行したユーザからの電力量データが示す系統から取り入れた電力量が成約した買注文の電力量を超える部分については、電気事業者による不足電力の供給単価に基づいて、該ユーザへの請求額を求めてもよい。
前記決済サーバは、例えば、成約した買注文を発行したユーザからの電力量データが示す系統から取り入れた電力量が成約した買注文の電力量未満の場合には、不足部分については、電気事業者による余剰電力の買い取り単価に基づいて、該ユーザへの請求額を求めてもよい。

前記決済サーバは、託送料金又は手数料を課金する手段を備えてもよい。
前記決済サーバは、託送料金として、予め設定された金額、固定額、従量制の金額、又は、発電地域と消費地域との間の距離に基づいて定まる金額を設定してもよい。

前記電力取引サーバが、ユーザの電力使用に条件を設定し、前記決済サーバは、スマートメータが出力したデータに基づいて、ユーザの電力使用が条件を満たしたか否かを判別し、満たしたと判別した場合には、該ユーザに一定の報酬を付与するようにしてもよい。

スマートメータから送られて来るデータは、他のメータで測定された消費量を示すデータを含んでもよい。この場合に、前記決済サーバは、他のメータで測定されたデータが示す消費量と契約先の料金プランに適用して請求額を求め、求めた請求額を含めて、ユーザへの請求額を処理してもよい。

この発明の電力取引支援装置は、
電力の取引を支援するための電力取引支援装置であって、
複数の端末装置から送信された売注文と買注文とを受け付ける手段と、
売注文と買注文とを、電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段と、
前記マッチング手段により成約した売注文と買注文について、電力量と単価と売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データとに基づいて、成約した売注文を発行したユーザへの成約した取引に関する支払い額を、そのユーザからの電力量データが示す系統への供給電力量が成約した売注文の電力量以上の場合には、成約した売注文の電力量と単価とに基づいて求め、成約した買注文を発行したユーザへの成約した取引に関する請求額を、そのユーザからの電力量データが示す系統から取り入れた電力量が成約した買注文の電力量以上の場合には、成約した買注文の電力量と単価とに基づいて求める手段と、
を備える。
上述の電力取引支援装置と、
前記電力取引支援装置にネットワークを介して接続され、売注文と買注文とを前記電力取引支援装置に送信する複数の端末装置と、
前記電力取引支援装置にネットワークを介して接続され、ユーザが系統に供給した電力の電力量と系統から取り入れた電力の電力量を測定し、電力量データを前記電力取引支援装置に供給する電力量計と、
前記電力量計を介して前記系統に接続された発電設備と、
前記電力量計を介して前記系統に接続された負荷と、
を備える電力取引支援システムを提供してもよい。

この発明のプログラムは、
コンピュータを、
電力の取引を支援するために、
各端末装置から送信された売注文と買注文とを受け付ける手段と、売注文と買注文とを電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段とを備える電力取引サーバとして機能させ、
前記電力取引サーバのマッチング手段により成約した売注文と買注文について、電力量と単価と売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データとに基づいて、成約した売注文を発行したユーザへの成約した取引に関する支払い額を、そのユーザからの電力量データが示す系統への供給電力量が成約した売注文の電力量以上の場合には、成約した売注文の電力量と単価とに基づいて求め、成約した買注文を発行したユーザへの成約した取引に関する請求額を、そのユーザからの電力量データが示す系統から取り入れた電力量が成約した買注文の電力量以上の場合には、成約した買注文の電力量と単価とに基づいて求める手段として機能させる。

ＣＰＵ２０１は、図１０に示すマッチング処理のステップＳ１１内で、図１１に示すこだわり条件による候補選択処理を実行する。
この処理においては、電力取引サーバ２０は、こだわり条件があるか否かを判別する（ステップＳ１１１）。こだわり条件がある場合、この条件に合致しないものをマッチングの対象から除外する（ステップＳ１１２）。残りの注文データがマッチングの対象候補とされ、他の条件が合致すれば、成約となる。

また、図５（ｂ）に示す買注文が成立していたとする。この買注文では、取引期間に７ｋＷＨの電力が購入されている。これに対し、スマートメータ１０４で測定された電力量データでは、この取引期間の上り電力量と下り電力量との差が１０ｋＷＨであったとする。この場合、３ｋＷＨ余分に電力を購入していることになる。このため、希望単価１７円／ｋＷＨでの７ｋＨＷ分の価格と別途求められている託送量の価格とシステムの使用料、さらに、契約先の電気事業者への３ｋＷＨ分の電力料金を請求する。決済サーバ２２は、その電気事業者への支払い額と送配電事業者への支払い額を設定する。
このようにして、決済サーバ２２は、成約取引毎に、成約した売注文・買注文だけでなく、ユーザテーブルを参照し、そのユーザが電気事業者と契約している売電単価及び買電単価を求め、決済用の計算を行う。さらに、託送料及びシステム使用料の課金処理、電気事業者、送配電事業者への支払い額の計算なども行う。

決済サーバ２２は、このようにして求められた個々の電力取引についての決済金額をユーザ別、電力小売取引業者等別、送配電事業者別に記憶する。

図１６は、図３に対応するシステム構成図である。
本支援システムの基本構成は実施の形態１の電力取引支援システム１と基本的に同一である。ただし、メータデータ管理システム２３は、送配電事業者に設置され、電気事業者には、電力取引サーバ２０、決済サーバ２２、メータデータ管理システム２３’が設置される。

この構成では、電力取引サーバ２０は、委託先の第三者機関に設置される。
一方、電気事業者には、決済サーバ２２とメータデータ管理システム２３’が設置され、送配電事業者には、メータデータ管理システム２３が設置される。
図１７のシステム構成において、売注文データと買注文データのマッチングまでの処理は、実施の形態１及び２と同様である。
成約した取引のデータ、即ち、取引データは、電力取引サーバ２０から決済サーバ２２に専用線を介して伝達される。
決済サーバ２２は、決済サーバ２２は、精算処理及び決済処理を実行する。

スマートメータ１０４からの電力量データは、送配電事業者に設置されたメータデータ管理システム２３に送信される。メータデータ管理システム２３は、各電気事業者分の電力量データをＣルートを介してメータデータ管理システム２３’を介して決済サーバ２２に送信する。

ここで、デマンドレスポンスとは、市場価格の高騰時または系統信頼性の低下時において、設定またはインセンティブの支払に応じて、需要家側が電力の使用を抑制するよう電力の消費パターンを変化させることである。
本実施の形態では、ユーザ情報の登録時に、デマンドレスレスポンスに対応するか否か、電気事業者との契約内容等を予め登録しておく。

Claims (12)

1. 電力事業者とユーザ間とをネットワークを介して連携して電力の取引を支援する電力取引支援システムであって、
   端末装置を介してユーザから送信された売注文と買注文とを受け付ける手段と、売注文と買注文とを電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段とを備える電力取引サーバと、
   前記電力取引サーバのマッチング手段により成約した売注文と買注文の、電力量と、単価と、売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと、買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データと、に基づいて、成約した売注文を発行したユーザへの支払い額と成約した買注文を発行したユーザへの請求額とをそれぞれ求める決済サーバと、
   を備える電力取引支援システム。
2. 売注文と買注文とは、それぞれ、取引対象の電力の電力量と取引期間と電力の単価と電力の属性を含み、
   前記電力取引サーバのマッチング手段は、売注文と買注文のそれぞれの取引対象の電力の電力量と取引期間と電力の単価と電力の属性をキーに、複数の売注文と買注文をマッチングする、
   請求項１に記載の電力取引支援システム。
3. 前記電力取引サーバのマッチング手段は、所定の電力事業者による余剰電力の買い取りと不足電力の供給を前提に、複数の売注文と買注文をマッチングする、
   請求項１又は２に記載の電力取引支援システム。
4. 前記決済サーバは、スマートメータからＡルートで出力された、成約した売注文を発行したユーザが取引期間に系統に供給した電力の電力量データ及び成約した買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量データをそれぞれ受信する手段、
   を備える、請求項１から３の何れか１項に記載の電力取引支援システム。
5. 前記決済サーバは、決済用のデータと共にスマートメータからＡルートで受信した電力量データを、Ｃルートを介して、前記電力取引サーバに通知する手段を備え、
   前記電力取引サーバは、通知された決済用のデータと電力量データとに基づいて、所定の処理を実行する、
   請求項４に記載の電力取引支援システム。
6. 前記電力取引サーバは、スマートメータがＢルートで出力したデータを受信する手段と、受信した電力量データを前記決済サーバに通知する手段を備え、
   前記決済サーバは、前記電力取引サーバから通知された電力量データに基づいて決済処理を実行する、
   請求項１から５の何れか１項に記載の電力取引支援システム。
7. 前記決済サーバは、託送料金と手数料とを課金する手段を備える、
   請求項１から６の何れか１項に記載の電力取引支援システム。
8. 前記電力取引サーバと前記決済サーバとは、ブロックチェーンを構成する複数の記憶装置を備える、
   請求項１から７の何れか１項に記載の電力取引支援システム。
9. 前記電力取引サーバは、ユーザに、電力使用の制限を設定し、
   前記決済サーバは、スマートメータが出力したデータに基づいて、ユーザが制限を満たしたか否かを判別し、満たしたと判別した場合には、該ユーザに一定の報酬を付与する、
   請求項１から８の何れか１項に記載の電力取引支援システム。
10. 前記決済サーバに、スマートメータから送られて来るデータは、他のメータで測定されたデータを含み、
    前記決済サーバは、他のメータで測定されたデータに基づく請求額を含めて、
    ユーザへの請求額を処理する、
    請求項１から９の何れか１項に記載の電力取引支援システム。
11. 電力の取引を支援するための電力取引支援装置であって、
    複数の端末装置から送信された売注文と買注文とを受け付ける手段と、
    売注文と買注文とを、電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段と、
    前記マッチング手段により成約した売注文と買注文について、電力量と単価と売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データとに基づいて、成約した売注文を発行したユーザへの支払い額と成約した買注文を発行したユーザへの請求額とをそれぞれ求める手段と、
    を備える電力取引支援装置。
12. コンピュータを、
    電力の取引を支援するために、
    各端末装置から送信された売注文と買注文とを受け付ける手段と、売注文と買注文とを電力量と取引期間と単価とに基づいてマッチングし、注文を成約させるマッチング手段とを備える電力取引サーバとして機能させ、又は、
    前記電力取引サーバのマッチング手段により成約した売注文と買注文の、電力量と単価と売注文を発行したユーザが取引期間に系統に供給した電力の電力量を電力量計で測定して得た電力量データと買注文を発行したユーザが取引期間に系統から取り入れた電力の電力量を電力量計で測定して得た電力量データとに基づいて、成約した売注文を発行したユーザへの支払い額と成約した買注文を発行したユーザへの請求額とを求める手段として機能させる、
    プログラム。

Images