ホーム > 特許ランキング > トヨタ自動車株式会社
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-11-18
(45)【発行日】2024-11-26
(54)【発明の名称】電力取引システム
(51)【国際特許分類】
G06Q 30/08 20120101AFI20241119BHJP
G06Q 50/06 20240101ALI20241119BHJP
【ＦＩ】
G06Q30/08
G06Q50/06
【請求項の数】
10
(21)【出願番号】P 2021170752
(22)【出願日】2021-10-19
(65)【公開番号】P2023061014
(43)【公開日】2023-05-01
【審査請求日】2023-10-26
(73)【特許権者】
【識別番号】000003207
【氏名又は名称】トヨタ自動車株式会社
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】工藤 由貴
(72)【発明者】
【氏名】木村 和峰
(72)【発明者】
【氏名】小幡 一輝
(72)【発明者】
【氏名】木暮 宏光
(72)【発明者】
【氏名】菊池 智志
(72)【発明者】
【氏名】間庭 佑太
【審査官】上田 威
(56)【参考文献】
【文献】米国特許出願公開第２０１８／０２０４２９３（ＵＳ，Ａ１）
【文献】特開２００２－０５６２２５（ＪＰ，Ａ）
【文献】特開２０１９－０４６１５５（ＪＰ，Ａ）
【文献】特開２０２１－０８７２９８（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
電力取引コンピュータと、前記電力取引コンピュータに対して入札を行なう入札コンピュータとを含む電力取引システムであって、前記電力取引コンピュータは、前記入札コンピュータによる入札が約定した場合に、約定済み入札の入札データを前記入札コンピュータへ送るように構成され、
前記入札コンピュータは、
所定フォーマットの入札データを前記電力取引コンピュータへ送ることにより電力取引の入札を行なう入札部と、
前記約定済み入札の入札データに含まれる所定情報を転記して、前記約定済み入札を打ち消すための打消し入札の入札データを生成する生成部と、
を含み、
前記所定情報は、取引に係る電力の属性を示す属性情報を含み、
前記電力取引コンピュータには、電力系統に電気的に接続可能なリソースを保有する複数のユーザが登録されており、
前記入札コンピュータは、前記電力取引コンピュータに登録されたユーザごとに設けられ、
前記電力取引は、前記電力系統を通じて送配電される電力の売買であり、
前記生成部は、前記電力系統に関する同時同量のインバランスを解消するための前記打消し入札の入札データを生成するように構成され、
前記電力取引の約定後、電力を売ったユーザの前記リソースは、当該ユーザが売った電力を前記電力系統へ出力し、電力を買ったユーザの前記リソースは、当該ユーザが買った電力を前記電力系統から受電する、電力取引システム。
【請求項2】
前記所定フォーマットの入札データは、入札価格と、入札量とを含み、前記生成部は、前記打消し入札の入札量が前記約定済み入札の入札量を超えないように、前記打消し入札の入札データを生成する、請求項１に記載の電力取引システム。
【請求項3】
前記約定済み入札は買い入札であり、前記打消し入札は売り入札である場合、前記生成部は、前記打消し入札の入札価格が前記約定済み入札の入札価格よりも安くなるように、前記打消し入札の入札データを生成する、請求項２に記載の電力取引システム。
【請求項4】
前記約定済み入札は売り入札であり、前記打消し入札は買い入札である場合、前記生成部は、前記打消し入札の入札価格が前記約定済み入札の入札価格よりも高くなるように、前記打消し入札の入札データを生成する、請求項２に記載の電力取引システム。
【請求項5】
前記属性情報は、取引に係る電力の発電方式を示し、
前記入札コンピュータは、買い入札のための入札データにおいて、個人の識別情報を用いて託送元を指定するように構成され、
前記入札コンピュータは、売り入札のための入札データにおいて、個人の識別情報を用いて託送先を指定するように構成される、請求項１～４のいずれか一項に記載の電力取引システム。
【請求項6】
前記電力取引コンピュータは、前記入札コンピュータから入札データを取得した場合に、入札を受け入れるか否かの審査を実行するように構成され、前記電力取引コンピュータは、前記打消し入札に関する前記審査において、取得した前記入札データが所定の要件を満たす場合に入札を受け入れるように構成され、
前記所定の要件は、前記約定済み入札の入札者と前記打消し入札の入札者とが一致することを含む、請求項１～５のいずれか一項に記載の電力取引システム。
【請求項7】
前記所定の要件は、前記約定済み入札と前記打消し入札とで電力の受渡し期間が一致することと、
前記打消し入札の入札量が前記約定済み入札の入札量を超えないことと、
をさらに含む、請求項６に記載の電力取引システム。
【請求項8】
前記電力取引コンピュータは、前記打消し入札を受け入れる旨判定した場合に、前記打消し入札の入札データに基づいて前記約定済み入札を打ち消す電力取引を実行し、その電力取引のトランザクションをブロックチェーン台帳に記録する、請求項６又は７に記載の電力取引システム。
【請求項9】
前記入札コンピュータは、対応するユーザに関して、
時間帯ごとの消費電力量及び発電量を予測し、
予測された前記消費電力量及び前記発電量によって示される需給計画値と、需給実績値との差分が、所定の許容範囲以内であるか否かを判断し、
前記差分が前記所定の許容範囲を超える場合には、前記打消し入札、又は前記打消し入札ではない新規入札を実行する
ように構成される、請求項１～８のいずれか一項に記載の電力取引システム。
【請求項10】
前記入札コンピュータは、前記打消し入札を行なうと判断した場合に、
当該打消し入札によって打ち消す約定済み入札を選択し、
当該打消し入札の入札量及び入札価格を決定し、
決定された前記入札量及び前記入札価格を記載するとともに、選択された前記約定済み入札の入札データから前記所定情報を転記することにより、当該打消し入札の入札データを生成し、
生成された前記打消し入札の入札データを前記電力取引コンピュータへ送る
ように構成され、
前記所定情報は、前記属性情報に加えて、前記約定済み入札の識別情報と、入札者の識別情報と、電力の受渡し期間とをさらに含む、請求項９に記載の電力取引システム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、電力取引システム、コンピュータ、及び電力取引方法に関する。
【背景技術】
【0002】
たとえば特開２０２０－９３３４号公報（特許文献１）には、各構成員が電力を売買することが可能な電力取引プラットフォームが開示されている。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０２０－９３３４号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
近年、ブロックチェーン技術を利用して電力の属性をトラッキングする電力取引システムが知られている。しかし、こうしたシステムでは、約定済み入札を打ち消すための打消し入札を行なう場合には、電力の属性がトラッキングされない。このため、取引に係る電力によっては、付加価値（たとえば、環境価値）が失われてしまうことになる。
【0005】
本開示は、上記課題を解決するためになされたものであり、その目的は、約定済み入札を打ち消すための打消し入札を行なう場合において、電力の属性をトラッキングできる電力取引システム、コンピュータ、及び電力取引方法を提供することである。
【課題を解決するための手段】
【0006】
本開示の第１の観点に係る電力取引システムは、電力取引コンピュータと、電力取引コンピュータに対して入札を行なう入札コンピュータとを含む。入札コンピュータは、入札部と、生成部とを含む。入札部は、所定フォーマットの入札データを電力取引コンピュータへ送ることにより電力取引の入札を行なうように構成される。生成部は、約定済み入札の入札データに含まれる所定情報を転記して、約定済み入札を打ち消すための打消し入札の入札データを生成するように構成される。上記所定情報は、取引に係る電力の属性を示す属性情報を含む。以下、上記所定情報を「転記情報」とも称する。
【0007】
上記電力取引システムでは、約定済み入札の入札データに含まれる属性情報が打消し入札の入札データに転記される。このため、約定済み入札を打ち消すための打消し入札を行なう場合において、電力の属性をトラッキングできる。
【0008】
上記所定フォーマットの入札データは、入札価格と、入札量とを含んでもよい。生成部は、打消し入札の入札量が約定済み入札の入札量を超えないように、打消し入札の入札データを生成するように構成されてもよい。
【0009】
上記構成によれば、打消し入札の入札量が約定済み入札の入札量（すなわち、打消し可能な入札量の上限値）を超えることが抑制される。このため、打消し入札に関して適切な入札データを生成しやすくなる。
【0010】
約定済み入札は買い入札であり、打消し入札は売り入札であってもよい。生成部は、打消し入札の入札価格が約定済み入札の入札価格よりも安くなるように、打消し入札の入札データを生成するように構成されてもよい。
【0011】
上記構成によれば、購入時の価格よりも安い価格で転売が実行される。これにより、転売が成功しやすくなる。
【0012】
約定済み入札は売り入札であり、打消し入札は買い入札であってもよい。生成部は、打消し入札の入札価格が約定済み入札の入札価格よりも高くなるように、打消し入札の入札データを生成するように構成されてもよい。
【0013】
上記構成によれば、売却時の価格よりも高い価格で買戻しが実行される。これにより、買戻しが成功しやすくなる。
【0014】
転記情報は、約定済み入札の識別情報と、入札者の識別情報と、電力の受渡し期間とをさらに含んでもよい。
【0015】
属性情報に加えて上記情報が打消し入札の入札データに転記されることで、電力取引コンピュータが入札審査を適切に行ないやすくなる。
【0016】
生成部は、同時同量のインバランスを解消するための打消し入札の入札データを生成するように構成されてもよい。こうした構成によれば、打消し入札によってインバランスを解消しやすくなる。同時同量のインバランスは、たとえば需給計画値と需給実績値（実需給）との差分に相当する。
【0017】
電力取引コンピュータは、入札コンピュータから入札データを取得した場合に、入札を受け入れるか否かの審査を実行するように構成されてもよい。電力取引コンピュータは、打消し入札に関する審査において、取得した入札データが所定の要件を満たす場合に入札を受け入れるように構成されてもよい。上記所定の要件は、約定済み入札の入札者と打消し入札の入札者とが一致することを含む。以下、上記所定の要件を「入札要件」とも称する。
【0018】
上記構成によれば、本人（約定済み入札の入札者）以外による不正な打消し入札（転売又は買戻し）を排除しやすくなる。
【0019】
上記所定の要件は、約定済み入札と打消し入札とで電力の受渡し期間が一致することと、打消し入札の入札量が約定済み入札の入札量を超えないこととをさらに含む。
【0020】
上記構成によれば、約定範囲を超える打消し入札（転売又は買戻し）を排除しやすくなる。
【0021】
なお、入札要件は任意に設定できる。入札要件は、約定済み入札で打消し入札が禁止されていないことをさらに含んでもよい。
【0022】
本開示の第２の観点に係るコンピュータは、電力取引の入札を行なうように構成される。コンピュータは入札部と生成部とを含む。入札部は、所定フォーマットの入札データを送ることにより電力取引の入札を行なうように構成される。生成部は、約定済み入札の入札データに含まれる所定情報を転記して、約定済み入札を打ち消すための打消し入札の入札データを生成するように構成される。上記所定情報は、取引に係る電力の属性を示す属性情報を含む。
【0023】
上記コンピュータによっても、前述した電力取引システムと同様、約定済み入札を打ち消すための打消し入札を行なう場合において、電力の属性をトラッキングすることが可能になる。
【0024】
本開示の第３の観点に係る電力取引方法は、データ生成と、打消し入札とを含む。データ生成では、約定済み入札の入札データに含まれる所定情報を転記して、約定済み入札を打ち消すための打消し入札の入札データを生成する。打消し入札では、打消し入札の入札データを送ることにより電力取引の入札を行なう。上記所定情報は、取引に係る電力の属性を示す属性情報を含む。
【0025】
上記電力取引方法によっても、前述した電力取引システムと同様、約定済み入札を打ち消すための打消し入札を行なう場合において、電力の属性をトラッキングすることが可能になる。
【発明の効果】
【0026】
本開示によれば、約定済み入札を打ち消すための打消し入札を行なう場合において、電力の属性をトラッキングできる電力取引システム、コンピュータ、及び電力取引方法を提供することが可能になる。
【図面の簡単な説明】
【0027】
【図1】本開示の実施の形態に係る電力取引システムの概要について説明するための図である。
【図2】買い入札のタグの一例を示す図である。
【図3】売り入札のタグの一例を示す図である。
【図6】本開示の実施の形態に係る車両エージェント（入札コンピュータ）の詳細構成を示す図である。
【図11】本開示の実施の形態に係る電力取引プラットフォーム（電力取引コンピュータ）によって実行される電力取引に係る処理を示すフローチャートである。
【発明を実施するための形態】
【0028】
本開示の実施の形態について、図面を参照しながら詳細に説明する。図中、同一又は相当部分には同一符号を付してその説明は繰り返さない。
【0029】
図１は、本開示の実施の形態に係る電力取引システムの概要について説明するための図である。図１を参照して、この実施の形態に係る電力取引プラットフォームＰＦは、Ｐ２Ｐ（Peer to Peer）電力取引プラットフォームである。たとえば、アグリゲータが電力取引プラットフォームＰＦを利用して電力取引市場を運営する。電力取引プラットフォームＰＦは、個人間での電力取引を可能にする。電力取引プラットフォームＰＦは、ブロックチェーン台帳と、入札審査メカニズムと、マッチングメカニズムと、スマートコントラクトとを備える。電力取引プラットフォームＰＦは、記憶装置に記憶されたプログラムと、プログラム（オペレーティングシステムなど）を稼働させるサーバと、サーバ及びコンピュータ群（ノード）を相互につなぐＰ２Ｐネットワークとによって具現化される。この実施の形態では、電力取引プラットフォームＰＦにおいてプログラムを稼働させるサーバが、本開示に係る「電力取引コンピュータ」の一例に相当する。
【0030】
電力取引プラットフォームＰＦのユーザは、電力系統ＰＧを通じて送配電される電力を売買する。電力系統ＰＧは、各種建物に設置された発電設備及び蓄電設備（図示せず）のほか、各種電気事業者が保有する多くの発電設備及び蓄電設備（図示せず）と接続されている。電力系統ＰＧの需給バランスは、同時同量（バランシング）が達成されるように調整される。アグリゲータは、ＢＲＰ（Balance Responsible Party）に相当する。電力取引プラットフォームＰＦの各ユーザは、電力系統ＰＧと電気的に接続可能なリソースを保有する。
【0031】
電力取引プラットフォームＰＦのユーザは、予め電力取引プラットフォームＰＦに登録される。この実施の形態では、複数のプロシューマＤ１と、複数のコンシューマＤ２と、複数の発電事業者Ｄ３と、複数の小売電気事業者Ｄ４とが、電力取引プラットフォームＰＦに登録されている。電力取引プラットフォームＰＦに登録されたユーザの数は任意であり、５以上１００未満であってもよいし、１００以上であってもよい。
【0032】
登録された各ユーザは、アセットと、エージェントとを保有する。この実施の形態では、各ユーザが保有するリソースが、アセットとして機能する。エージェントは、電力取引プラットフォームＰＦに入札する機能を有する。これにより、個人単位での電力の売買が可能になる。約定後において、リソースは、ユーザが売った電力を電力系統ＰＧへ出力したり、ユーザが買った電力を電力系統ＰＧから受電したりする。
【0033】
電力系統ＰＧとリソースとの間には電力メータが設けられる。電力メータは、リソースが電力系統ＰＧへ出力した電力量（逆潮流量）と、電力系統ＰＧからリソースが受電した電力量との少なくとも一方を計測する。電力メータは、計測値を電力取引プラットフォームＰＦへ逐次送る。電力メータの計測値は、ＥＭＳ（Energy Management System）を介して、電力取引プラットフォームＰＦへ送られてもよい。電力メータは、日々の需要電力（ユーザが使った電力量）を計測するスマートメータであってもよいし、電力取引のために導入された専用端末であってもよい。リソースごとに電力メータが設けられてもよいし、複数のリソースに対して１つの電力メータ（共通の電力メータ）が設けられてもよい。プロシューマＤ１におけるＥＭＳは、発電電力及び需要電力を管理するように構成されてもよい。
【0034】
以下、プロシューマＤ１がコンシューマＤ２に電力を売る場合を例にとって、電力取引プラットフォームＰＦを通じて行なわれる電力取引について説明する。
【0035】
まず、アグリゲータが、図示しない取引所からトークンを購入する。このトークンはスマートコントラクトを履行するための手数料として用いられる。そして、プロシューマＤ１のノード（エージェント）が売り入札（プライスオファー）を行ない、コンシューマＤ２のノード（エージェント）が買い入札（プライスリクエスト）を行なう。電力取引プラットフォームＰＦに対して双方の入札が行なわれると、入札審査メカニズムが、適切な入札か否かの審査（入札審査）を実行する。入札審査メカニズムは、所定のアルゴリズムに従って入札審査を実行する。そして、双方の入札が入札審査に合格すると、マッチングメカニズムが、資金確認（Funds validation）を行なった後、売り入札と買い入札とのマッチングを行なう。マッチングメカニズムは、所定のアルゴリズムに従ってマッチングを実行する。
【0036】
ユーザ（入札者）のエージェントは、所定フォーマットの入札データ（以下、「タグ」と称する）を電力取引プラットフォームＰＦ（電力取引コンピュータ）へ送ることにより電力取引の入札を行なう。タグは、価格及び電力量（ｋＷｈ）を提示する。入札者は、タグによって付加情報を付けて入札を行なうことができる。
【0037】
図２は、買い入札のタグの一例を示す図である。図２を参照して、このタグは、入札者ＩＤ（入札者の識別情報）と、電力の受渡し期間と、入札価格と、入札量（ｋＷｈ）と、属性情報と、追加の入札情報（以下、「ＩＮＦＯ」と称する）とを含む。
【0038】
買い入札タグの属性情報は、買い入札に係る電力の属性を示す。買い入札者（たとえば、コンシューマＤ２）のエージェントは、入札者が購入を希望する電力の属性（発電方式、産地など）を買い入札のタグに記載することができる。発電方式の例としては、再生可能エネルギー全般、特定の再生可能エネルギー（太陽光発電、風力発電、地熱発電、バイオマス発電など）、火力発電が挙げられる。電力産地は、都道府県の名称で指定されたエリアであってもよいし、経度及び緯度で指定されたエリアであってもよい。ユーザがポインティングデバイスを利用して任意に指定したマップ上のエリアが、タグに記載されてもよい。買い入札者のエージェントは、電力の属性に関する購入条件を買い入札のタグに記載することにより、入札者が希望する電力を購入することができる。発電方式で再生可能エネルギーを指定することで、環境価値の高い電力を購入できる。産地で地元を指定することで、地産地消が可能になる。
【0039】
買い入札タグのＩＮＦＯは、買い入札に関する特記事項を示す情報である。買い入札者のエージェントは、取引先に関する条件をＩＮＦＯに記載することができる。取引先は、企業名又は個人ＩＤで指定されてもよい。個人ＩＤで託送元を指定することで、自己託送が可能になる。買い入札者のエージェントは、タグのＩＮＦＯによって購入条件を細かく指定できる。
【0040】
入札ＩＤは、入札者のエージェントではなく、電力取引プラットフォームＰＦによって付与される。具体的には、入札審査メカニズムは、入札者から上記タグを取得すると、入札審査（入札を受け入れるか否かの審査）を実行する。そして、入札審査に合格した入札のタグには、入札審査メカニズムによって入札ＩＤ（入札の識別情報）が付与される。このことは、以下に説明する売り入札のタグについても同様である。
【0041】
図３は、売り入札のタグの一例を示す図である。図３を参照して、このタグは、入札者ＩＤ（入札者の識別情報）と、電力の受渡し期間と、入札価格と、入札量（ｋＷｈ）と、属性情報と、ＩＮＦＯ（追加の入札情報）とを含む。
【0042】
売り入札タグの属性情報は、売り入札に係る電力の属性を示す。売り入札者（たとえば、プロシューマＤ１）のエージェントは、売る電力の属性（発電方式、産地、証書など）を売り入札のタグに記載する。入札者が非化石証書付きの電力を売る場合には、非化石証書の種類（たとえば、再エネ指定ありのＦＩＴ非化石証書、再エネ指定ありの非ＦＩＴ非化石証書、再エネ指定なしの非ＦＩＴ非化石証書のいずれか）がタグに記載される。なお、再エネは、「再生可能エネルギー」を意味する。ＦＩＴは、「Feed-in Tariff」を意味する。
【0043】
売り入札タグのＩＮＦＯは、売り入札に関する特記事項を示す情報である。売り入札者のエージェントは、取引先に関する条件をＩＮＦＯに記載することができる。取引先は、企業名又は個人ＩＤで指定されてもよい。個人ＩＤで託送先を指定することで、自己託送が可能になる。また、売り入札者のエージェントは、販売条件として転売禁止をＩＮＦＯに記載することができる。さらに、売り入札者のエージェントは、電力取引に付随して提供される特典を示す特典情報をＩＮＦＯに記載することができる。特典の例としては、クーポンが挙げられる。特典情報は、クーポンの利用範囲（たとえば、地域又は店舗）及び利用価値（たとえば、金銭的価値又はサービス内容）を示す。クーポンは、電子クーポンであってもよい。売り入札者のエージェントは、タグのＩＮＦＯによって販売条件及び特典情報を電力取引プラットフォームＰＦに知らせることができる。
【0044】
再び図１を参照して、マッチングメカニズムは、入札価格、入札量、及び受渡し期間だけでなく、タグが示す付加情報（属性情報及びＩＮＦＯ）も考慮して、タグが示す購入条件及び販売条件を満たすようにマッチングを行なう。プロシューマＤ１とコンシューマＤ２とのマッチングが成功すると、コンシューマＤ２が、法定通貨（たとえば、ＪＰＹ、ＵＳＤ、ＧＢＰ、ＥＵＲなど）によって電気料金をアグリゲータに支払う。その後、アグリゲータが電力取引プラットフォームＰＦ上に上記トークンを預託する。プロシューマＤ１は、入札時に提示した電力量（ｋＷｈ）を電力系統ＰＧに供給する。コンシューマＤ２は、入札時に提示した電力量（ｋＷｈ）を電力系統ＰＧから受け取る。スマートコントラクトは、電力供給の確認（Proof of delivery）後、電力取引を実行する。具体的には、スマートコントラクトは、預託された上記トークンをアグリゲータに戻し、トランザクションを記録するブロックチェーン台帳（たとえば、ローカルネットワーク台帳）を更新する。トランザクションは、各ノードに記録される。
【0045】
スマートコントラクトによって電力取引が実行されると、アグリゲータは、取引結果に対応する額の法定通貨をプロシューマＤ１に支払う。また、アグリゲータは、取引コスト（託送料金、プラットフォームコストなど）を精算する。
【0046】
電力取引プラットフォームＰＦのブロックチェーン台帳の記録は、外部のプラットフォームの台帳（たとえば、イーサリアム台帳）に反映される。アグリゲータは、トークン流通量を制限するため、取引終了後、最初に購入したトークンを取引所で処分する。
【0047】
上記のように、アグリゲータが中心となって、電力取引プラットフォームＰＦ上でのトークン取引きと、電気料金の支払いと、託送料金の支払いとが行なわれる。なお、アグリゲータによる処理は、図示しないノード（たとえば、アグリゲータに帰属するサーバ）上で行なわれる。
【0048】
図４は、プロシューマＤ１の電力設備の一例を示す図である。図１とともに図４を参照して、プロシューマＤ１の家屋１００Ａの屋根には、太陽光パネル１１０が設置されている。家屋１００Ａの屋内には、ＰＣＳ（Power Conditioning System）１２０と、分電盤１４１と、電力負荷１４２とが設けられている。ユーザの自宅の敷地内（屋外）には、ＥＶＳＥ（Electric Vehicle Supply Equipment）１５０Ａが設置されている。さらに、電力系統ＰＧと分電盤１４１との間にはスマートメータ１４３が設置されている。
【0049】
太陽光パネル１１０は、太陽光を利用して発電を行なう。太陽光パネル１１０は、気象条件によって発電出力が変動する自然変動電源であり、発電した電力をＰＣＳ１２０へ出力する。ＰＣＳ１２０は、発電電力を系統電力（電力系統ＰＧの電力）に変換する機能を備える。ＰＣＳ１２０は、ＤＣ／ＤＣコンバータ１２１と、インバータ１２２と、制御装置１２５とを含む。制御装置１２５は、たとえば太陽光パネル１１０の発電電力と、ユーザの自宅における消費電力（需要電力）とに基づいて、ＤＣ／ＤＣコンバータ１２１及びインバータ１２２の各々を制御するように構成される。
【0050】
ＤＣ／ＤＣコンバータ１２１は、太陽光パネル１１０が発電した直流電力を、系統電力に応じた電圧に変圧する。そして、インバータ１２２は、ＤＣ／ＤＣコンバータ１２１から出力された直流電力を、系統電力に応じた交流電力に変換して分電盤１４１へ出力する。制御装置１２５は、ＤＣ／ＤＣコンバータ１２１及びインバータ１２２の少なくとも一方を制御することにより、太陽光パネル１１０から分電盤１４１に入力される電力を調整できる。制御装置１２５は、ユーザからの指示に従い、太陽光パネル１１０の発電電力を、電力系統ＰＧに対して逆潮流してもよい。
【0051】
分電盤１４１には、電力系統ＰＧと太陽光パネル１１０（ＰＣＳ１２０）との各々から電力（たとえば、三相交流電力）が供給される。電力負荷１４２は、屋内で使用される電気機器であり、分電盤１４１から電力の供給を受ける。電力負荷１４２はコンセント（図示せず）を介して分電盤１４１と接続されてもよい。電力負荷１４２は、照明器具、空調設備、調理器具、情報機器、冷蔵庫、又は洗濯機のような家庭用電気機械器具であってもよい。
【0052】
ＥＶＳＥ１５０Ａは、車両に対して給電を行なう設備であり、分電盤１４１から電力の供給を受ける。ＥＶＳＥ１５０Ａの本体につながる充電ケーブル１５２のコネクタ１５１が車両のインレットに接続（プラグイン）されることによって、車両と電力系統ＰＧとが互いに電気的に接続される。以下、車両と電力系統ＰＧとが互いに電気的に接続された状態を、「プラグイン状態」と称する。また、車両と電力系統ＰＧとが互いに電気的に接続されていない状態を、「プラグアウト状態」と称する。走行中の車両はプラグアウト状態である。
【0053】
車両２００Ａは、蓄電装置に蓄えられた電力を用いて走行可能なｘＥＶである。ｘＥＶは、電力を動力源の全て又は一部として利用する車両である。具体的には、車両２００Ａは、インレット２１０と、充電器２２０と、バッテリ２３０と、モータ２４０と、ＥＣＵ（Electronic Control Unit）２５０とを備える。バッテリ２３０は、走行用のエネルギー貯蔵装置である。バッテリ２３０は、公知の車両用蓄電装置（たとえば、液式二次電池、全固体二次電池、又は組電池）を採用できる。車両用二次電池の例としては、リチウムイオン電池、ニッケル水素電池が挙げられる。車両２００Ａは、バッテリ２３０からモータ２４０に電力を供給して、モータ２４０によって生成される動力によって走行する。モータ２４０は、ＭＧ（Motor Generator）であってもよい。車両２００Ａは、たとえばＢＥＶ（電気自動車）である。しかしこれに限られず、プロシューマＤ１（図１）の電力設備に含まれる車両は、ＢＥＶ以外のｘＥＶであってもよい。
【0054】
車両２００Ａは、ＥＶＳＥ１５０Ａを介して電力系統ＰＧと電気的に接続可能に構成される。インレット２１０は、ＥＶＳＥ１５０Ａのコネクタ１５１と接続可能に構成される。充電器２２０は、インレット２１０とバッテリ２３０との間に位置し、ＥＣＵ２５０によって制御される。充電器２２０は、たとえばインバータを含む。プラグイン状態において電力系統ＰＧから車両２００Ａへ電力が供給される場合には、インレット２１０からバッテリ２３０に適切な電力が入力されるようにＥＣＵ２５０が充電器２２０を制御する。
【0055】
車両２００Ａは、Ｖ２Ｈ（Vehicle to Home）機能を有する。車両２００Ａは、プラグイン状態においてバッテリ２３０の電力をＥＶＳＥ１５０Ａを介して家屋１００Ａ（より特定的には、分電盤１４１）へ供給可能に構成される。さらに、車両２００Ａは、Ｖ２Ｇ機能（電力系統ＰＧとの間で双方方向に電力をやり取りする機能）を有する。放電回路（放電のための電力変換回路）は、充電器２２０、インレット２１０、又はコネクタ１５１に内蔵されてもよいし、インレット２１０及びコネクタ１５１の両方に装着可能な放電コネクタに内蔵されてもよい。なお、プロシューマＤ１（図１）の電力設備に含まれる車両は、Ｖ１ＧタイプのｘＥＶ（電力系統ＰＧから一方的に電力の供給を受けるタイプのｘＥＶ）であってもよい。充放電器の機能は、車両ではなくＥＶＳＥに搭載されてもよい。
【0056】
ＥＣＵ２５０は、車両２００Ａに搭載された図示しない無線通信機を介して、モバイル端末３００Ａと通信を行なう。モバイル端末３００Ａと車両２００Ａとは、たとえばＮＦＣ（Near Field Communication）又はＢｌｕｅｔｏｏｔｈ（登録商標）のような近距離通信（すなわち、車両周辺の範囲での直接通信）を行なう。モバイル端末３００Ａは、ユーザによって操作される。この実施の形態では、モバイル端末３００Ａとして、タッチパネルディスプレイを具備するスマートフォンを採用する。ただしこれに限られず、モバイル端末３００Ａとしては、任意のモバイル端末を採用可能であり、ラップトップ、タブレット端末、ウェアラブルデバイス（たとえば、スマートウォッチ又はスマートグラス）、又は電子キーなども採用可能である。
【0057】
車両２００Ａは、車両２００Ａの状態を検出する各種センサ（図示せず）を具備する。車両２００Ａは、これらのセンサによって検出された車両２００Ａの状態をモバイル端末３００Ａへ送信する。車両２００Ａは、たとえば、現在位置（たとえば、経度及び緯度）、ＳＯＣ（State Of Charge）、及び系統接続状態（プラグイン状態／プラグアウト状態）を、モバイル端末３００Ａを介して、車両エージェント５００へ送信する。車両２００ＡのＳＯＣは、バッテリ２３０のＳＯＣを意味する。ＳＯＣは、蓄電装置の蓄電残量を示し、たとえば満充電状態の蓄電量に対する現在の蓄電量の割合を０～１００％で表わしたものである。この実施の形態では、車両２００Ａがプラグアウト状態からプラグイン状態に切り替わったときに、モバイル端末３００Ａがユーザに対して走行開始時刻の入力を要求する。そして、モバイル端末３００Ａは、入力された走行開始時刻を車両エージェント５００へ送信する。
【0058】
この実施の形態では、クラウドサーバが、車両エージェント５００として機能する。車両エージェント５００は、図示しないプロセッサと、プロセッサにより実行されるプログラムとによって具現化される。クラウドコンピューティングによってクラウド上に車両エージェント５００が提供される。車両エージェント５００の構成については後述する（図６参照）。図４に示すプロシューマＤ１の電力設備において、太陽光パネル１１０（ＰＣＳ１２０付き）、電力負荷１４２、及び車両２００Ａの各々は、リソースに相当する。
【0059】
図５は、コンシューマＤ２の電力設備の一例を示す図である。図１とともに図５を参照して、家屋１００Ｂは、太陽光パネル１１０及びＰＣＳ１２０を有しないこと以外は、図４に示した家屋１００Ａと同じ構成を有する。モバイル端末３００Ｂは、図４に示したモバイル端末３００Ａと同じ構成を有する。車両２００Ｂ、ＥＶＳＥ１５０Ｂも、それぞれ図４に示した車両２００Ａ、ＥＶＳＥ１５０Ａと基本的には同じ構成を有する。ただし、車両２００Ｂは、Ｖ１ＧタイプのＢＥＶであり、Ｖ２Ｈ機能を有しない。
【0060】
たとえば、車両を所有するユーザがアグリゲータと所定の契約を結んだ場合には、アグリゲータが、そのユーザを電力取引プラットフォームＰＦに登録し、さらに、そのユーザのための車両エージェント５００をクラウド上に用意する。車両エージェント５００は、アグリゲータと上記契約を結んだユーザごとに用意される。これらの車両エージェント５００は、ユーザごとにユーザＩＤで区別されて管理される。また、アグリゲータは、クラウドコンピューティングによってクラウド上にデータベースを用意する。このデータベースにおいては、電力取引プラットフォームＰＦに登録された各ユーザの情報がユーザＩＤで区別されて管理される。ユーザは、クラウド環境で上記の車両エージェント５００及びデータベースを利用できる。
【0061】
図６は、車両エージェント５００の詳細構成を示す図である。図６を参照して、この実施の形態に係る電力取引システムは、車両エージェント５００として機能するクラウドサーバと、電力取引プラットフォームＰＦと、車両２００と、モバイル端末３００とを含む。車両エージェント５００は、本開示に係る「入札コンピュータ」の一例に相当する。車両２００は、電力取引プラットフォームＰＦに登録されたユーザが所有する車両であり、たとえば前述した車両２００Ａ（図４）と同じ構成を有する。モバイル端末３００は、電力取引プラットフォームＰＦに登録されたユーザによって携帯される機器であり、たとえば前述したモバイル端末３００Ａ（図４）と同じ構成を有する。
【0062】
モバイル端末３００には、所定のアプリケーションソフトウェア（以下、単に「アプリ」と称する）がインストールされている。モバイル端末３００は、上記アプリを通じて車両エージェント５００と情報のやり取りを行なうことができる。ユーザは、たとえばモバイル端末３００のタッチパネルディスプレイを通じて、上記アプリを操作できる。また、モバイル端末３００のタッチパネルディスプレイは、ユーザに対して情報を報知する。
【0063】
車両エージェント５００は、クラウド上のデータベースにアクセスしながら処理を実行する。データベースは、ユーザに関する情報（たとえば、図４又は図５に示した電力設備の仕様）を含む。車両エージェント５００は、情報収集エージェント５１０と、予測エージェント５２０と、入札エージェント５３０とを含む。
【0064】
情報収集エージェント５１０は、車両２００に関する車両情報と、ユーザに関するユーザ情報とを取得して保存するように構成される。
【0065】
情報収集エージェント５１０は、前述した電力メータ（たとえば、図４又は図５に示したスマートメータ１４３）の計測値を逐次受信する。情報収集エージェント５１０は、ユーザの電力メータから、電力系統ＰＧに関するユーザの需給状況を示すユーザ情報（以下、「需給情報」と称する）を取得する。また、情報収集エージェント５１０は、モバイル端末３００から車両情報（たとえば、位置、ＳＯＣ、系統接続状態、及び走行開始時刻）を取得する。
【0066】
予測エージェント５２０は、価格予測部５２１と、電力予測部５２２とを含む。予測エージェント５２０は、１日（たとえば、翌日）を所定の時間単位で区切って、区切られた時間帯ごとに電力価格、蓄電余力、及び必要電力量を予測するように構成される。所定の時間単位は、３０分程度であってもよいし、１時間以上３時間未満であってもよいし、３時間以上であってもよい。
【0067】
価格予測部５２１は、気象情報（現在又は未来の気象条件を示す情報）と、市場価格情報（電力市場における電力価格を示す情報）と、電力取引プラットフォームＰＦにおける取引状況とに基づいて、電力取引プラットフォームＰＦにおける時間帯ごとの電力価格（電力の売買価格）を予測するように構成される。たとえば、価格予測部５２１は、気象予測データ（天気、気温、風など）に基づいてＶＲＥ（変動性再生可能エネルギー）発電量を予測することができる。ＶＲＥ発電量が多くなるほど電力価格は安くなる傾向がある。
【0068】
電力予測部５２２は、情報収集エージェント５１０が取得した需給情報に基づいて、時間帯ごとの必要電力量を予測するように構成される。具体的には、電力予測部５２２は、たとえば蓄積された需給履歴情報（過去の需給状況を示す情報）及び気象情報（たとえば、気象予報情報）に基づいて、時間帯ごとの需要量（消費電力量）及び発電量を予測し、得られた予測データから時間帯ごとの必要電力量を算出する。必要電力量は、たとえば需要量から発電量を減算することにより算出される。需要量が多くなるほど必要電力量が多くなる。発電量が需要量を上回る場合には、電力予測部５２２は、必要電力量の代わりに余剰電力量を予測する。余剰電力量は、たとえば発電量から需要量を減算することにより算出される。
【0069】
電力予測部５２２は、情報収集エージェント５１０が取得した車両情報に基づいて、時間帯ごとの蓄電余力を予測するように構成される。車両２００がプラグイン状態のときには、車両２００がプラグアウト状態のときよりも蓄電余力が大きくなる。プラグイン状態の車両２００は、電力系統ＰＧから供給される電力をバッテリ２３０（図４）に蓄えることができる。プラグイン状態の車両２００のＳＯＣが低いほど蓄電余力は大きくなる。電力予測部５２２は、情報収集エージェント５１０が取得した走行開始時刻に基づいて、プラグイン状態の車両２００がプラグアウト状態になるタイミング（以下、「系統離脱タイミング」と称する）を予測することができる。また、電力予測部５２２は、車両２００の位置及びＳＯＣに基づいて、プラグアウト状態の車両２００がプラグイン状態になるタイミング（以下、「系統接続タイミング」と称する）を予測することができる。この実施の形態では、情報収集エージェント５１０が車両２００の位置及びＳＯＣを逐次取得する。なお、モバイル端末３００は、系統接続タイミングを示す走行終了時刻の入力をユーザに要求し、入力された走行終了時刻を車両エージェント５００へ送信してもよい。こうした形態では、電力予測部５２２が、走行終了時刻に基づいて系統接続タイミングを予測できる。
【0070】
ユーザは、不足する電力（必要電力量）を電力取引プラットフォームＰＦで購入する。また、ユーザは、余った電力（余剰電力量）を電力取引プラットフォームＰＦで売却する。入札エージェント５３０は、ユーザの代わりに電力取引の自動入札を行なう。入札エージェント５３０は、所定の入札アルゴリズムに従って入札を行なう。ユーザは、入札アルゴリズムに入札条件を設定できる。具体的には、入札エージェント５３０は、予測エージェント５２０が予測した情報に基づいて、電力取引プラットフォームＰＦに対して入札を行なう。入札エージェント５３０は、時間帯ごとの電力価格と、時間帯ごとの蓄電余力とに基づいて、時間帯ごとの必要電力量を購入するための入札を行なう。また、入札エージェント５３０は、時間帯ごとの電力価格と、時間帯ごとの蓄電余力とに基づいて、時間帯ごとの余剰電力量を売却するための入札を行なう。
【0071】
入札エージェント５３０は、基本的には、電力の売買による利益が大きくなるように（あるいは、電力コストを低減するように）入札を行なう。ただし、ユーザによって入札条件が設定されている場合には、入札エージェント５３０はその条件に従って入札を行なう。たとえば、目標再エネ率が設定されている場合には、入札エージェント５３０は目標再エネ率を達成するように入札を行なう。
【0072】
蓄電余力は、電力供給タイミングと電力使用タイミングとのずれを許容（吸収）する。蓄電余力が大きいほど入札の自由度は高くなる。たとえば、入札エージェント５３０は、電力需要が多くなる時間帯に使用される電力を、前もって価格の安い時間帯に購入して蓄電しておくことができる。モバイル端末３００は、車両エージェント５００からの指示に従い、充放電パラメータ（充放電制御に関するパラメータ）を車両２００へ送信してもよい。ＥＣＵ２５０（図４）は、車両エージェント５００からの指示に従ってバッテリ２３０の充放電制御を実行してもよい。
【0073】
入札エージェント５３０が入札を行なった後、入札結果（電力取引の結果）が電力取引プラットフォームＰＦから情報収集エージェント５１０へ送られる。約定した入札に関しては、約定済み入札のタグ（後述する図８参照）が電力取引プラットフォームＰＦから情報収集エージェント５１０へ送られる。約定済み入札のタグは、クラウド上のデータベースに保存される。電力予測部５２２は、電力取引の結果に応じて必要電力量及び余剰電力量を更新する。たとえば、電力取引プラットフォームＰＦにおいて必要電力量の一部が落札された場合には、電力予測部５２２は、落札した電力量を必要電力量から減算することにより、必要電力量を更新する。
【0074】
入札エージェント５３０は、判断部５３１と、生成部５３２と、入札部５３３とを含む。判断部５３１は、入札を行なうか否かを判断する。また、判断部５３１は、約定済み入札を打ち消すための打消し入札を行なうか否かを判断する。生成部５３２は、判断部５３１によって入札を行なうと判断された場合に、前述したタグ（所定フォーマットの入札データ）を生成する。また、判断部５３１によって打消し入札を行なうと判断された場合には、生成部５３２が、約定済み入札のタグに含まれる所定情報（転記情報）を転記して、打消し入札のタグを生成する。この実施の形態では、入札ＩＤ（約定済み入札の識別情報）、入札者ＩＤ（入札者の識別情報）、電力の受渡し期間、及び電力の属性情報（取引に係る電力の属性を示す情報）を、転記情報とする。入札部５３３は、生成部５３２によって生成されたタグを電力取引プラットフォームＰＦへ送ることにより電力取引の入札を行なう。入札アルゴリズムに従って判断部５３１、生成部５３２、及び入札部５３３が動作することで、前述の態様で入札が実行される。
【0075】
図７は、車両エージェント５００によって実行される入札に係る処理を示すフローチャートである。このフローチャートに示される処理は、たとえば図２に示した電力設備を保有するプロシューマＤ１の車両エージェント５００によって繰り返し実行される。この場合、図４に示した車両２００Ａ、モバイル端末３００Ａが、それぞれ図６に示した車両２００、モバイル端末３００として機能する。以下では、フローチャート中の各ステップを、単に「Ｓ」と表記する。
【0076】
図６とともに図７を参照して、Ｓ１１では、車両エージェント５００が、電力系統ＰＧに関する同時同量を監視する。具体的には、生成部５３２は、Ｓ１１において、同時同量のインバランス（計画値と実需給との差分）が所定の許容範囲以内であるか否かを判断し、インバランスが許容範囲を超えた場合に（Ｓ１１にてＹＥＳ）、処理をＳ１２に進める。この実施の形態では、電力予測部５２２が予測した時間帯ごとの需要量及び発電量が、時間帯ごとの計画値に相当する。また、情報収集エージェント５１０によって取得された需給情報が、実需給を示す。
【0077】
Ｓ１１の判断は、入札を行なうか否かの判断に相当する。Ｓ１１においてＹＥＳと判断されたこと（すなわち、同時同量のインバランスが発生したこと）は、入札を行なうことを意味する。Ｓ１１においてＮＯと判断されたことは、入札を行なわないことを意味する。Ｓ１１においてＮＯと判断されている間は、Ｓ１１の判断が繰り返し実行される。
【0078】
Ｓ１２では、判断部５３１が、約定済み入札を打ち消すための打消し入札を行なうか否かを判断する。たとえば、インバランスの発生に起因して約定済み入札を遂行できないと予測される場合には、Ｓ１２においてＹＥＳと判断され、処理がＳ１４に進む。他方、遂行できない約定済み入札が存在しない場合には、Ｓ１２においてＮＯと判断され、処理がＳ１３に進む。Ｓ１３では、車両エージェント５００が通常の入札（打消し入札ではない新規入札）を実行する。具体的には、生成部５３２が、同時同量のインバランスを解消するための入札のタグを生成し、入札部５３３が、そのタグを電力取引プラットフォームＰＦへ送る。
【0079】
Ｓ１４では、打消し入札が実行される。図８は、Ｓ１４の詳細を示すフローチャートである。図６とともに図８を参照して、Ｓ１４１では、生成部５３２が、打ち消したい約定済み入札を選択する。たとえば、生成部５３２は、約定済み入札のうち遂行できないと予測されるものを選択する。Ｓ１４１で選択された約定済み入札が買い入札である場合には、打消し入札は売り入札になる。Ｓ１４１で選択された約定済み入札が売り入札である場合には、打消し入札は買い入札になる。一例では、図８に示すタグＴ１１によって示される約定済み入札が、Ｓ１４１で選択される。タグＴ１１は、買い入札タグである。
【0080】
続くＳ１４２では、生成部５３２が打消し入札の入札量を決定する。生成部５３２は、Ｓ１４１で選択された約定済み入札の入札量の範囲内で、打消し入札の入札量を決定する。生成部５３２は、たとえば約定済み入札の入札量のうち遂行できない分を、打消し入札の入札量とする。ただしこれに限られず、生成部５３２は、遂行可能な分も含めて約定済み入札の入札量の全てを、打消し入札の入札量としてもよい。また、生成部５３２は、ユーザによって指定された入札量を、打消し入札の入札量としてもよい。たとえば、Ｓ１４２において生成部５３２がモバイル端末３００に入札量を要求してもよい。そして、モバイル端末３００は、生成部５３２からの要求に従い、ユーザに対して入札量の入力を要求し、入力された入札量を車両エージェント５００へ送信してもよい。
【0081】
続くＳ１４３では、生成部５３２が打消し入札の入札価格を決定する。生成部５３２は、たとえばＳ１４１で選択された約定済み入札の入札価格に基づいて、打消し入札の価格を決定する。打消し入札が売り入札である場合には、生成部５３２は、打消し入札の入札価格が約定済み入札の入札価格よりも安くなるように、打消し入札の入札価格を決定する。これにより、転売が成功しやすくなる。また、打消し入札が買い入札である場合には、生成部５３２は、打消し入札の入札価格が約定済み入札の入札価格よりも高くなるように、打消し入札の入札価格を決定する。これにより、買戻しが成功しやすくなる。
【0082】
生成部５３２は、約定済み入札の入札価格に所定倍率を乗算した価格を、打消し入札の入札価格として決定してもよい。また、生成部５３２は、市場価格情報に基づいて、確実に約定できる価格を打消し入札の入札価格として決定してもよい。生成部５３２は、市場価格に所定倍率を乗算した価格を、打消し入札の入札価格として決定してもよい。また、生成部５３２は、ユーザによって指定された入札価格を、打消し入札の入札価格としてもよい。たとえば、Ｓ１４３において生成部５３２がモバイル端末３００に入札価格を要求してもよい。そして、モバイル端末３００は、生成部５３２からの要求に従い、ユーザに対して入札価格の入力を要求し、入力された入札価格を車両エージェント５００へ送信してもよい。
【0083】
続くＳ１４４では、生成部５３２が、上記Ｓ１４２及びＳ１４３で決定された入札量及び入札価格を記載するとともに、約定済み入札のタグに含まれる転記情報を転記して、打消し入札のタグを生成する。転記情報は、たとえば、入札ＩＤ、入札者ＩＤ、電力の受渡し期間、及び電力の属性情報である。一例では、図８に示す打消し入札のタグＴ２１が、Ｓ１４４の処理によって生成される。タグＴ２１は、売り入札タグである。図８に示されるように、タグＴ１１とタグＴ２１とでは、入札者ＩＤ、受渡し期間、及び属性情報が一致する。また、タグＴ１１の入札ＩＤが、転売される入札を特定する情報としてタグＴ２１のＩＮＦＯに転記される。
【0084】
図９は、約定済み入札のタグ及び打消し入札のタグの第１変形例を示す図である。図９を参照して、タグＴ１２は、ＩＮＦＯに特典情報（より特定的には、クーポン情報）を含む。クーポンの種類は、各種記号（文字、数字など）によって識別されてもよい。タグＴ１２が約定済み入札のタグである場合には、入札ＩＤと入札者ＩＤと電力の受渡し期間と電力の属性情報と特典情報とが打消し入札のタグＴ２２に転記される。入札ＩＤ及び特典情報は、タグＴ２２のＩＮＦＯに転記される。また、当該入札が打消し入札（より特定的には、転売のための入札）であることも、タグＴ２２のＩＮＦＯに記載される。
【0085】
図１０は、約定済み入札のタグ及び打消し入札のタグの第２変形例を示す図である。図１０を参照して、タグＴ１３は売り入札タグである。タグＴ１３が約定済み入札のタグである場合にも、前述したタグＴ１１（図８）が約定済み入札のタグである場合と同様、入札ＩＤと入札者ＩＤと電力の受渡し期間と電力の属性情報とが打消し入札のタグＴ２３に転記される。そして、当該入札が打消し入札（より特定的には、買戻しのための入札）であることが、タグＴ２３のＩＮＦＯに記載される。
【0086】
再び図６とともに図８を参照して、上記Ｓ１４４の処理後、入札部５３３は、Ｓ１４５において、打消し入札のタグ（Ｓ１４４で生成されたタグ）を電力取引プラットフォームＰＦへ送ることにより、打消し入札を行なう。これにより、打消し入札（図７のＳ１４）が完了する。
【0087】
以上説明したように、この実施の形態に係る電力取引方法は、データ生成（図８のＳ１４４）と、打消し入札（図８のＳ１４５）とを含む。データ生成では、約定済み入札の入札データに含まれる前述の転記情報を転記して、約定済み入札を打ち消すための打消し入札の入札データを生成する。打消し入札では、打消し入札の入札データを送ることにより電力取引の入札を行なう。上記の電力取引方法では、転記情報に属性情報が含まれることによって、打消し入札において電力の属性をトラッキングすることが可能になる。
【0088】
この実施の形態に係る車両エージェント５００（入札コンピュータ）では、生成部５３２が、同時同量のインバランスを解消するための打消し入札の入札データを生成するように構成される。これにより、打消し入札によってインバランスを解消しやすくなる。また、生成部５３２は、打消し入札の入札量が約定済み入札の入札量を超えないように、打消し入札の入札データを生成する。これにより、打消し入札の入札量が約定済み入札の入札量（すなわち、打消し可能な入札量の上限値）を超えることが抑制される。この実施の形態では、図７に示した処理が、電力取引プラットフォームＰＦに登録された各ユーザのエージェント（図１参照）によって実行される。
【0089】
図１１は、この実施の形態に係る電力取引プラットフォームＰＦによって実行される電力取引に係る処理を示すフローチャートである。図１とともに図１１を参照して、この実施の形態に係る電力取引方法は、入札審査（Ｓ１）と、マッチング（Ｓ２）と、電力取引（Ｓ３）と、記録及び通知（Ｓ４）とを含む。Ｓ１～Ｓ４の各処理は、電力取引プラットフォームＰＦ（電力取引コンピュータ）によって実行される。
【0090】
Ｓ１では、電力取引プラットフォームＰＦ（より特定的には、入札審査メカニズム）が入札審査を実行する。入札審査においては、タグ（入札データ）が所定フォーマットで作成されているか否かが審査される。また、打消し入札の審査においては、通常の入札の審査とは異なる要件について審査される。
【0091】
図１２は、打消し入札の審査に係る処理を示すフローチャートである。図１とともに図１２を参照して、Ｓ２１では、電力取引プラットフォームＰＦが、打消し入札のタグに記載された約定済み入札の識別情報（入札ＩＤ）に基づいて、打ち消される約定済み入札を特定する。
【0092】
続けて、電力取引プラットフォームＰＦは、Ｓ２２、Ｓ２３、Ｓ２４、Ｓ２５において、それぞれ入札要件Ａ、Ｂ、Ｃ、Ｄを満たすか否かを判断する。入札要件Ａは、約定済み入札の入札者と打消し入札の入札者とが一致することである。入札要件Ｂは、約定済み入札と打消し入札とで電力の受渡し期間が一致することである。入札要件Ｃは、打消し入札の入札量が約定済み入札の入札量を超えないことである。入札要件Ｄは、約定済み入札で打消し入札が禁止されていないことである。
【0093】
入札要件Ａ～Ｄの全てを満たす場合には（Ｓ２２～Ｓ２５の全てでＹＥＳ）、電力取引プラットフォームＰＦは、Ｓ２６１において、入札を受入れる旨判定する。他方、入札要件Ａ～Ｄのいずれかが満たされない場合には（Ｓ２２～Ｓ２５のいずれかでＮＯ）、電力取引プラットフォームＰＦは、Ｓ２６２において、入札を拒絶する旨判定する。
【0094】
再び図１とともに図１１を参照して、入札審査の結果は、ユーザ端末（たとえば、モバイル端末３００）又はエージェント（たとえば、車両エージェント５００）に通知される。審査不合格（入札拒絶）の通知を受けたユーザは、タグを修正して再度入札を行なってもよい。
【0095】
入札審査に合格すると、処理がＳ２に進む。Ｓ２では、電力取引プラットフォームＰＦ（より特定的には、マッチングメカニズム）が、審査に合格したタグに基づいてマッチングを行なう。そして、マッチングが成功すると、電力取引プラットフォームＰＦ（より特定的には、スマートコントラクト）は、Ｓ３において、マッチングに成功した双方のタグに基づいて電力取引を実行する。その後、電力取引プラットフォームＰＦは、Ｓ４において取引の記録と通知を行なう。具体的には、タグに基づいて電力取引のトランザクションがブロックチェーン台帳に記録される。また、約定済み入札のタグが電力取引プラットフォームＰＦからユーザ端末（たとえば、モバイル端末３００）及びエージェント（たとえば、車両エージェント５００）の各々に通知される。
【0096】
上記のように、電力取引プラットフォームＰＦ（電力取引コンピュータ）は、ユーザのエージェント（入札コンピュータ）から入札データを取得した場合に、入札を受け入れるか否かの審査を実行する（図１１のＳ１）。電力取引プラットフォームＰＦは、打消し入札に関する審査において、取得した入札データが所定の要件（入札要件Ａ～Ｄ）を満たす場合に入札を受け入れる（図１２参照）。打消し入札の審査では、本人（約定済み入札の入札者）以外による不正な打消し入札（転売又は買戻し）が拒絶される。また、約定範囲を超える打消し入札（転売又は買戻し）、及び約定済み入札で禁止された打消し入札も拒絶される。
【0097】
上記所定の要件（入札を受け入れる要件）は、入札要件Ａ～Ｄに限られず、適宜変更可能である。たとえば、入札要件Ｄ（図１２のＳ２５）が割愛されてもよい。また、転売のための打消し入札の審査において、打消し入札の入札価格が約定済み入札の入札価格以下であることが、入札要件として追加されてもよい。こうした要件によって、利益を得る目的での転売が禁止されてもよい。
【0098】
図４に示したプロシューマＤ１では、太陽光パネル１１０（太陽光発電設備）で発電された電力を蓄電する蓄電装置として車載バッテリが用いられている。しかしこれに限られず、プロシューマＤ１（図１）は、太陽光発電設備で発電された電力を蓄電する蓄電装置として、定置式の蓄電装置を所有してもよい。
【0099】
上記実施の形態では、車両と車両エージェントとが直接通信せず、モバイル端末を介して両者が通信する。しかし、こうした形態には限られない。車両は、移動体通信網（テレマティクス）にアクセス可能な無線通信機（たとえば、ＤＣＭ（Data Communication Module））を備え、車両エージェントと直接的に無線通信してもよい。また、車両はＥＶＳＥを介して車両エージェントと通信してもよい。
【0100】
上記実施の形態では、ユーザ端末としてモバイル端末を採用している。しかしこれに限られず、ユーザに帰属する任意の端末をユーザ端末として採用できる。たとえば、ユーザ端末は車載端末（たとえば、ナビゲーションシステム）であってもよい。
【0101】
上記実施の形態では、個人が所有する車両（ＰＯＶ）について言及した。しかしこれに限られず、ＰＯＶに代えてＭａａＳ（Mobility as a Service）車両が採用されてもよい。ＭａａＳ車両は、ＭａａＳ事業者が管理する車両である。
【0102】
車両は、内燃機関を備えないＢＥＶに限られず、内燃機関を備えるＰＨＥＶ（プラグインハイブリッド車）であってもよい。車両は、乗用車に限られず、バス又はトラックであってもよい。車両は、非接触充電可能に構成されてもよい。車両は、自動運転可能に構成されてもよいし、飛行機能を備えてもよい。車両は、無人で走行可能な車両（たとえば、ロボタクシー、無人搬送車（ＡＧＶ）、又は農業機械）であってもよい。
【0103】
上記実施の形態では、車両エージェントがクラウド上に設けられている。しかしこれに限られず、車両エージェントの機能の少なくとも一部は、オンプレミスサーバ、車両、又はモバイル端末に実装されてもよい。
【0104】
電力系統ＰＧは、大規模な交流グリッドに限られず、マイクログリッドであってもよいし、ＤＣ（直流）グリッドであってもよい。車両は、直流電力用の充電器又は充放電器を備えてもよい。
【0105】
今回開示された実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した実施の形態の説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【0106】
１００Ａ，１００Ｂ 家屋、１１０ 太陽光パネル、１４１ 分電盤、１４２ 電力負荷、１４３ スマートメータ、１５０Ａ，１５０Ｂ ＥＶＳＥ、１５２ 充電ケーブル、２００ 車両、２１０ インレット、２２０ 充電器、２３０ バッテリ、２４０ モータ、２５０ ＥＣＵ、３００ モバイル端末、５００ 車両エージェント、５１０ 情報収集エージェント、５２０ 予測エージェント、５２１ 価格予測部、５２２ 電力予測部、５３０ 入札エージェント、５３１ 判断部、５３２ 生成部、５３３ 入札部、ＰＦ 電力取引プラットフォーム、ＰＧ 電力系統、Ｔ１１～Ｔ１３，Ｔ２１～Ｔ２３ タグ。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】