Electricity trading computer and electricity trading system

Abstract

To provide an electric power transaction computer which can distribute, to each vehicle in a disaster area, electric power supplied by a resource capable of performing electric power supply in the disaster area, while suppressing traffic congestion in the disaster area.SOLUTION: An electric power transaction platform (electric power transaction computer) is configured to, when a disaster occurs, operate an electric power transaction market for distributing, to each vehicle in a disaster area, electric power supplied by a resource capable of performing electric power supply in the disaster area. The electric power transaction platform (electric power transaction computer) is configured to, when receiving a bid for the electric power transaction market, determine whether to accept the bid using a traffic situation in the disaster area, a placement position of the resource which delivers the electric power, and a position of the vehicle which receives the electric power.SELECTED DRAWING: Figure 9

Description

[Technical field]

[0001] The present disclosure relates to an energy trading computer. [Background technology]

[0002] For example, JP 2020-114051 A (Patent Document 1) discloses a technology that uses electric vehicles as a power source for an evacuation shelter when a disaster occurs. The electric vehicle used as a power source for the evacuation shelter is selected according to the distance to the evacuation shelter and the remaining power. The technology described in Patent Document 1 uses electric vehicles to transport electricity to the evacuation shelter. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2020-114051 A Summary of the Invention [Problem to be solved by the invention]

[0004] When a disaster occurs, places that need power are not limited to evacuation shelters. For example, if users who own electric vehicles (vehicles equipped with power storage devices) in a disaster-stricken area need power, it may be possible to quickly rescue people in the disaster-stricken area by directly supplying power to the electric vehicles (users) from resources that can supply power in the disaster-stricken area.

[0005] However, if the above-mentioned electricity transfer is carried out in a disorderly manner, it may cause traffic congestion during the transfer of electricity, hindering the recovery efforts in the disaster-stricken areas. For example, when an electric vehicle heads to the resource installation site to receive electricity from the resource, it may impede the traffic of vehicles involved in disaster response (recovery efforts).

[0006] The present disclosure has been made to solve the above-mentioned problems, and has an objective to provide an energy trading computer that can distribute electricity supplied by resources capable of supplying electricity within a disaster-stricken area to each vehicle in the disaster-stricken area while suppressing traffic congestion in the disaster-stricken area. [Means for solving the problem]

[0007] The energy trading computer according to the present disclosure is configured to operate an energy trading market for distributing, when a disaster occurs, electricity supplied by resources capable of supplying electricity within a disaster-stricken area to each vehicle within the disaster-stricken area. When a bid is received for the energy trading market, the energy trading computer is configured to determine whether to accept the bid using traffic conditions within the disaster-stricken area, the installation positions of the resources that transfer the electricity, and the positions of the vehicles that receive the electricity.

[0008] By executing power trading in the power trading market, power supplied by resources capable of supplying power within the disaster-stricken area can be distributed to each vehicle within the disaster-stricken area. However, power trading is not concluded for bids that are not accepted by the power trading computer. When the power trading computer receives a bid for the power trading market, it determines whether or not to accept the bid based on the traffic conditions in the disaster-stricken area, the installation location of the resource that transfers the power, and the location of the vehicle that receives the power. Therefore, it is possible to manage so that power trading is not concluded for bids from vehicles (users) that are likely to cause traffic congestion in the disaster-stricken area. This suppresses the transfer of power that causes traffic congestion in the disaster-stricken area.

[0009] According to the above-described energy trading computer, it is possible to distribute the electricity supplied by the resources capable of supplying power within the disaster area to each vehicle within the disaster area while suppressing traffic congestion within the disaster area.

[0010] Examples of traffic congestion include traffic jams that impede the traffic of vehicles in general, as well as traffic conditions that impede the traffic of specific vehicles (e.g., vehicles for disaster response). The vehicle that receives the electric power may be an xEV equipped with a power storage device. An xEV is a vehicle that uses electric power as all or part of its power source.

[0011] Examples of the resource include a power generation facility and a power storage facility. The resource may be a stationary resource that is configured to be able to directly supply power to a vehicle without using a power grid.

[0012] The traffic conditions in the disaster area may include a travel route of a specific vehicle (hereinafter referred to as a "priority vehicle") in the disaster area. The energy trading computer may determine whether to accept a bid based on a route from a position of a vehicle receiving power (hereinafter referred to as a "bidding vehicle") to a position of a resource transferring power (hereinafter referred to as a "bidding resource") and the travel route of the priority vehicle. The energy trading computer may determine not to accept a bid if the bidding vehicle will obstruct traffic of the priority vehicle when heading to an installation location of the bidding resource to receive power from the bidding resource.

[0013] A priority vehicle may be a medical vehicle (eg, an ambulance) or a disaster response vehicle (eg, a recovery vehicle, a fire engine, or a municipal vehicle).

[0014] The energy trading computer may be configured to operate an energy trading market in normal times (hereinafter also referred to as a "normal time market") when no disaster occurs. Then, when a disaster occurs, the energy trading computer may open an energy trading market in disaster times (hereinafter also referred to as a "disaster time market") in addition to the normal time market. The disaster time market may be a P2P (Peer to Peer) energy trading market. After the occurrence of a disaster, the energy trading computer may continue to operate the normal time market for energy transactions outside the disaster area.

[0015] An acceptance period for accepting bids in the disaster market may be set to be shorter than that in the normal market. The energy trading computer may execute energy trading for the bids accepted during each acceptance period. The energy trading computer may set a next acceptance period each time the acceptance period elapses.

[0016] In a bid for the disaster market, the bid price may be a fixed amount. The energy trading computer may determine a successful bidder based on criteria other than price. The energy trading computer may give priority to a bidding vehicle that meets certain requirements. Effect of the Invention

[0017] According to the present disclosure, it is possible to provide an energy trading computer that can distribute electricity supplied by resources capable of supplying power within a disaster-stricken area to each vehicle within the disaster-stricken area while suppressing traffic congestion within the disaster-stricken area. [Brief description of the drawings]

[0018] [Figure 1] FIG. 1 is a diagram for explaining an overview of an energy trading system according to an embodiment of the present disclosure. [Diagram 2] FIG. 13 shows an example of tags used in each of a buying bid and a selling bid. [Diagram 3] FIG. 2 is a diagram illustrating a part of the power system shown in FIG. [Figure 4] FIG. 1 is a diagram illustrating a configuration of an energy trading system according to an embodiment of the present disclosure. [Diagram 5] 5 is a flowchart showing an aspect of operation management in the energy trading system shown in FIG. 4 when a disaster occurs. [Figure 6] 5 is a flowchart showing a process executed by an energy trading platform in the energy trading system shown in FIG. 4 when a disaster occurs. [Figure 7] FIG. 1 is a diagram showing an example of a disaster area. [Figure 8] 7 is a flowchart showing a process related to the energy trading shown in FIG. 6. [Figure 9] 9 is a flowchart showing the process relating to the bid examination shown in FIG. 8. [Figure 10] FIG. 10 is a diagram for explaining requirements (bid requirements) in the bid screening shown in FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present disclosure will now be described in detail with reference to the accompanying drawings, in which the same or corresponding parts are designated by the same reference numerals and will not be described repeatedly.

[0020] FIG. 1 is a diagram for explaining an outline of an energy trading system according to an embodiment of the present disclosure. With reference to FIG. 1, the energy trading platform PF according to this embodiment is a P2P (Peer to Peer) energy trading platform. For example, an aggregator uses the energy trading platform PF to operate an energy trading market. The energy trading platform PF enables energy trading between individuals. The energy trading platform PF includes a blockchain ledger, a bid screening mechanism, a matching mechanism, and a smart contract. The energy trading platform PF is embodied by a program stored in a storage device, a server that runs the program (such as an operating system), and a P2P network that interconnects the server and a group of computers (nodes). In this embodiment, the server that runs the program in the energy trading platform PF corresponds to an example of an "energy trading computer" according to the present disclosure.

[0021] Users of the energy trading platform PF buy and sell electricity transmitted and distributed through the power grid PG. The power grid PG is connected to power generation facilities and power storage facilities (not shown) installed in various buildings, as well as many power generation facilities and power storage facilities (not shown) owned by various electric power companies. As will be described in detail later, the power grid PG supplies electricity generated by power generation facilities to each consumer via substation facilities (see Figure 3). The supply and demand balance of the power grid PG is adjusted so that simultaneous equal amounts (balancing) are achieved. The aggregator corresponds to a BRP (Balance Responsible Party). Each user of the energy trading platform PF holds assets that can be electrically connected to the power grid PG.

[0022] Users of the energy trading platform PF are registered in advance in the energy trading platform PF. In this embodiment, a plurality of prosumers D1, a plurality of consumers D2, a plurality of power generation companies D3, and a plurality of electricity retailers D4 are registered in the energy trading platform PF. The number of users registered in the energy trading platform PF is arbitrary, and may be 5 or more and less than 100, or may be 100 or more.

[0023] Each registered user has an asset and an agent. In this embodiment, each of the vehicles 210 and resources 310 (see FIG. 4), which will be described later, functions as an asset. The agent has a function of bidding on the energy trading platform PF. This enables buying and selling of electricity on an individual basis. After the contract is concluded, the asset outputs the electricity sold by the user to the power grid PG and receives the electricity purchased by the user from the power grid PG.

[0024] A power meter is provided between the power system PG and the asset. The power meter measures at least one of the amount of power (reverse power amount) output by the asset to the power system PG and the amount of power received by the asset from the power system PG. The power meter sequentially transmits the measurement value to the energy trading platform PF. The measurement value of the power meter may be transmitted to the energy trading platform PF via an EMS (Energy Management System). The power meter may be a smart meter that measures daily power demand (amount of power used by a user) or may be a dedicated terminal introduced for power trading. A power meter may be provided for each asset, or one power meter (common power meter) may be provided for multiple assets. The EMS in the prosumer D1 may be configured to manage generated power and demanded power.

[0025] Hereinafter, the energy trading carried out through the energy trading platform PF will be described by taking as an example the case where a prosumer D1 sells energy to a consumer D2.

[0026] First, the aggregator purchases tokens from an exchange (not shown). The tokens are used as fees for fulfilling the smart contract. Then, the node (agent) of the prosumer D1 makes a selling bid (price offer), and the node (agent) of the consumer D2 makes a buying bid (price request). When both bids are made to the energy trading platform PF, the bid screening mechanism performs screening to determine whether or not the bids are appropriate (bid screening). The bid screening mechanism performs bid screening according to a predetermined algorithm. Then, when both bids pass the bid screening, the matching mechanism performs funds validation and then matches the selling bid and the buying bid. The matching mechanism performs matching according to a predetermined algorithm.

[0027] A user (bidder) agent submits a bid for energy trading by sending bid data in a specified format (hereinafter referred to as "tag") to the energy trading platform PF. The tag indicates the price and the amount of energy (kWh). Bidders can submit bids with additional information attached via the tag.

[0028] Fig. 2 is a diagram showing an example of tags used in each of buying bids and selling bids. Referring to Fig. 2, tag T11 is a buying bid tag, and tag T12 is a selling bid tag. Each of tags T11 and T12 includes a bidder ID (identification information of the bidder), a delivery period of electricity, a bid price, a bid amount (kWh), and additional bid information (hereinafter referred to as "INFO"). INFO is information indicating special notes regarding the bid. The bidder's agent can specify the bidding conditions in detail using the tag INFO.

[0029] Referring again to FIG. 1, when the bid screening mechanism obtains the above tag from a bidder, it performs bid screening (screening to see whether or not to accept the bid). Then, a bid ID (identification information of the bid) is assigned by the bid screening mechanism to the tag of the bid that passes the bid screening. After that, the matching mechanism performs matching for the bids that pass the bid screening. The matching mechanism performs matching so as to satisfy the purchase and sale conditions indicated by the tag, taking into consideration not only the bid price, bid amount, and delivery period indicated by the tag, but also the additional information (INFO) indicated by the tag.

[0030] When the matching between the prosumer D1 and the consumer D2 is successful, the consumer D2 pays the electricity bill to the aggregator in legal tender (e.g., JPY, USD, GBP, EUR, etc.). The aggregator then deposits the above tokens on the energy trading platform PF. The prosumer D1 supplies the amount of electricity (kWh) offered at the time of bidding to the power grid PG. The consumer D2 receives the amount of electricity (kWh) offered at the time of bidding from the power grid PG. The smart contract executes the energy trading after confirming the power supply (Proof of delivery). Specifically, the smart contract returns the above deposited tokens to the aggregator and updates the blockchain ledger (e.g., local network ledger) that records the transaction. The transaction is recorded in each node.

[0031] When the energy transaction is executed by the smart contract, the aggregator pays the prosumer D1 an amount of legal tender corresponding to the transaction result. The aggregator also settles the transaction costs (wheeling charges, platform costs, etc.).

[0032] The records of the blockchain ledger of the energy trading platform PF will be reflected in the ledger of an external platform (for example, the Ethereum ledger). In order to limit the amount of tokens in circulation, the aggregator will dispose of the tokens initially purchased at the exchange after the transaction is completed.

[0033] As described above, the aggregator plays a central role in token trading on the energy trading platform PF, electricity bill payment, and wheeling charge payment. Note that the processing by the aggregator is performed on a node (e.g., a server belonging to the aggregator) not shown.

[0034] FIG. 3 is a diagram showing a part of the power system PG. Referring to FIG. 3 together with FIG. 1, the power system PG includes a plurality of substation facilities (only substation facilities P111 and P112 are shown in FIG. 3) that transform power generated at a power plant P110. Each substation facility includes a primary substation, a distribution substation, and a transformer (e.g., a pole transformer). An under-frequency relay (UFR) is installed at each substation feeder. In this embodiment, the general power transmission and distribution utility corresponds to the system operator (SO) of the power system PG. The general power transmission and distribution utility maintains and manages the power system PG (commercial power system).

[0035] The power plant P110 supplies extra-high voltage power to area A1, high voltage power to area A2, and low voltage power to area A3 through the substation P111. The power plant P110 also supplies extra-high voltage power to area A4, high voltage power to area A5, and low voltage power to area A6 through the substation P112. For example, if a disaster occurs and the distribution substation of the substation P111 breaks down, areas A2 and A3 will suffer a power outage. In this case, areas A2 and A3 correspond to the disaster area. If a disaster occurs and the UFR installed in the primary substation of the substation P111 is activated and an emergency cutoff by the UFR is performed, areas A1 to A3 will suffer a power outage. In this case, areas A1 to S3 correspond to the disaster area. If a disaster occurs and the power plant P110 stops, all areas (including areas A1 to A6) that receive power from the power plant P110 will correspond to the disaster area (power outage area). Although FIG. 3 shows only one power generation facility (power plant P110), a plurality of power generation facilities are connected to the power system PG.

[0036] The server 500 receives information indicating the state of the equipment (operating state, presence or absence of a malfunction, etc.) from each power generation equipment and each substation equipment. The server 500 can identify the disaster area (power outage area) based on the state of each equipment.

[0037] Fig. 4 is a diagram showing a configuration of an energy trading system according to an embodiment of the present disclosure. With reference to Fig. 4 together with Fig. 1, the energy trading system includes an energy trading platform PF, an information management server 100, a plurality of vehicle agents 200, a plurality of vehicles 210, a plurality of mobile terminals 220, a plurality of resource agents 300, a plurality of resources 310, the server 500 shown in Fig. 3, and a traffic management system 700.

[0038] The resource 310 is a stationary resource configured to be able to directly supply power to the vehicle 210 without using the power grid PG. The resource 310 may be connected to an electric vehicle supply equipment (EVSE) (not shown). The EVSE is equipment that supplies power to the vehicle. The resource 310 may supply power to the vehicle 210 via the EVSE.

[0039] The multiple resources 310 included in the energy trading system may have different configurations. The resources 310 may be at least one of a power storage device and a power generation facility installed in a building. A power storage facility configured to store the power generated by the power generation facility may be adopted as the resource 310. Examples of the power generation facility include a power generation facility that generates power using fuel (fossil fuel, hydrogen, etc.) and a power generation facility that generates power using natural energy (solar power, wind power, hydroelectric power, etc.). A solar panel installed on a building, a vacant lot, a parking lot, etc. may be adopted as the power generation facility. An example of the power storage facility is an ESS (Energy Storage System) installed in a building as an emergency power source.

[0040] The vehicle 210 is an xEV that can run using power stored in a power storage device. Specifically, the vehicle 210 includes an inlet, a charger, a battery, a motor, and an ECU (Electronic Control Unit). The inlet is configured to be connectable to an EVSE. The EVSE that receives power from the power system PG may be installed in a storage location for the vehicle 210 (for example, a parking lot at the user's home). The connector of a charging cable connected to a main body of the EVSE is connected (plugged in) to the inlet of the vehicle, thereby electrically connecting the vehicle and the EVSE to each other. Hereinafter, a state in which the vehicle and the EVSE are electrically connected to each other is referred to as a "plugged-in state." Also, a state in which the vehicle and the EVSE are not electrically connected to each other is referred to as a "plugged-out state." The vehicle is in the plugged-out state while traveling.

[0041] The charger includes, for example, an inverter. The battery is an energy storage device for driving. A known vehicle power storage device (for example, a liquid secondary battery, an all-solid-state secondary battery, or a battery pack) can be used as the battery. Examples of vehicle secondary batteries include a lithium-ion battery and a nickel-metal hydride battery. The vehicle 210 is driven by power generated by a motor supplied with power from the battery. The motor may be a motor generator (MG).

[0042] The ECU communicates with the mobile terminal 220 via a wireless communication device (not shown) mounted on the vehicle 210. The vehicle 210 and the mobile terminal 220 perform short-range communication (i.e., direct communication within the range around the vehicle) such as NFC (Near Field Communication) or Bluetooth (registered trademark). The mobile terminal 220 is operated by a user. In this embodiment, a smartphone equipped with a touch panel display is adopted as the mobile terminal 220. However, the present invention is not limited to this, and any mobile terminal can be adopted as the mobile terminal 220, and a tablet terminal, a wearable device (e.g., a smart watch or smart glasses), or an electronic key can also be adopted.

[0043] The vehicle 210 includes various sensors (not shown) for detecting the state of the vehicle 210. The vehicle 210 transmits the state of the vehicle 210 detected by these sensors to the mobile terminal 220. The vehicle 210 transmits, for example, a current position (for example, longitude and latitude), a SOC (State Of Charge), and a grid connection state (plugged-in state / plugged-out state) to the vehicle agent 200 via the mobile terminal 220. The SOC of the vehicle 210 means the SOC of the battery. The SOC indicates the remaining amount of electricity stored in the electricity storage device, and is, for example, a ratio of the current amount of electricity stored to the amount of electricity stored in a fully charged state, expressed as 0 to 100%. In this embodiment, when the vehicle 210 switches from the plugged-out state to the plugged-in state, the mobile terminal 220 requests the user to input a travel start time. Then, the mobile terminal 220 transmits the inputted travel start time to the vehicle agent 200.

[0044] The multiple vehicles 210 included in the energy trading system may have different configurations. The vehicle 210 may be a BEV (electric vehicle) that does not have an internal combustion engine. The vehicle 210 may be a PHEV (plug-in hybrid vehicle) that has an internal combustion engine. The vehicle 210 may also be a FCEV (fuel cell vehicle). The vehicle 210 may be a V1G type xEV (a type of xEV that receives a unilateral supply of power from the power grid PG). The vehicle 210 may be an xEV that has at least one of a V2H (Vehicle to Home) function and a V2G function (a function for bidirectionally exchanging power with the power grid PG).

[0045] In this embodiment, when a user signs a specified contract with an aggregator, the aggregator registers the user in each of the information management server 100 and the energy trading platform PF, and further prepares an agent for the user on the cloud. An agent is prepared for each user who signs the above-mentioned contract with the aggregator. These agents are distinguished and managed for each user by their user ID. In addition, the aggregator prepares a database on the cloud by cloud computing. The user can use the above-mentioned agent and database in the cloud environment.

[0046] In the above database, information of each user registered in the energy trading platform PF is managed by distinguishing them by user ID. The database includes, for a user who owns a resource 310, the location and specifications of the resource 310. For a user who owns a vehicle 210, the database includes, for a user who owns a vehicle 210, the specifications of the vehicle 210, the location of the user's home (e.g., address), and the storage location of the vehicle 210 (location of the parking lot).

[0047] The resource 310 is a resource registered in the energy trading platform PF. The vehicle 210 is a vehicle owned by a user registered in the energy trading platform PF. The mobile terminal 220 is a device carried by a user registered in the energy trading platform PF. A specific application software (hereinafter simply referred to as an "app") is installed in the mobile terminal 220. The mobile terminal 220 can exchange information with the vehicle agent 200 through the app. A user can operate the app, for example, through a touch panel display of the mobile terminal 220. In addition, the touch panel display of the mobile terminal 220 notifies the user of information.

[0048] The vehicle agent 200 submits a bid to the energy trading platform PF to secure power (battery charging power) to be supplied to the vehicle 210. The mobile terminal 220 may transmit charging parameters (parameters related to charging control) to the vehicle 210 according to an instruction from the vehicle agent 200. The ECU may execute battery charging control according to an instruction from the vehicle agent 200. In this embodiment, a cloud server functions as the vehicle agent 200. The vehicle agent 200 is embodied by a processor (not shown) and a program executed by the processor. The vehicle agent 200 is provided on the cloud by cloud computing.

[0049] The information management server 100 is, for example, a computer equipped with a processor, a RAM (Random Access Memory), and a storage device (none of which are shown in the figures). The processor executes a program stored in the storage device, thereby executing various processes in the information management server 100. However, the various processes in the information management server 100 are not limited to being executed by software, and may also be executed by dedicated hardware (electronic circuits).

[0050] The information management server 100 acquires vehicle information (e.g., location, SOC, grid connection state, and travel start time) of each vehicle 210. The information management server 100 may acquire the vehicle information directly from the vehicle 210, or may acquire the vehicle information from the vehicle 210 via the mobile terminal 220. The information management server 100 also acquires resource information (information indicating the resource state) of each resource 310. The information management server 100 may acquire the resource information from an EMS provided in the resource 310. The information management server 100 sends predetermined information to the energy trading platform PF in response to a request from the energy trading platform PF or periodically.

[0051] The energy trading platform PF includes a normal market mechanism and a disaster market mechanism. The normal market mechanism is configured to operate an energy trading market (normal market) according to a predetermined first market algorithm when no disaster occurs. The disaster market mechanism is configured to operate an energy trading market (disaster market) according to a predetermined second market algorithm when a disaster occurs. The first market algorithm and the second market algorithm are different.

[0052] The vehicle agent 200 performs automatic bidding for energy trading on behalf of the user. When no disaster occurs, the vehicle agent 200 performs bidding in the normal market according to a predetermined first bidding algorithm. When a disaster occurs, the vehicle agent 200 performs bidding in the disaster market according to a predetermined second bidding algorithm. The user can set bidding conditions for each bidding algorithm. The first bidding algorithm will be described below.

[0053] When no disaster occurs, the vehicle agent 200 is configured to divide a day (for example, the next day) into predetermined time units and predict the power price and the required power amount for each divided time period. The vehicle agent 200 makes a buying bid in the normal market to secure the predicted required power amount. The above-mentioned predetermined time unit may be about 30 minutes, may be more than 1 hour and less than 3 hours, or may be more than 3 hours.

[0054] The vehicle agent 200 obtains vehicle information (e.g., location, SOC, grid connection state, and travel start time) from the mobile terminal 220, and predicts the amount of power required for each time period based on the vehicle information. The predicted amount of power required is the amount of power required to charge the battery installed in the vehicle 210.

[0055] The vehicle agent 200 can predict the timing when the vehicle 210 in the plugged-in state will become plugged-out state (hereinafter referred to as "grid disconnection timing") based on the travel start time. The vehicle agent 200 can also predict the timing when the vehicle 210 in the plugged-out state will become plugged-in state (hereinafter referred to as "grid connection timing") based on the position and SOC of the vehicle 210. In this embodiment, the vehicle agent 200 sequentially acquires the position and SOC of the vehicle 210.

[0056] The vehicle agent 200 predicts the electricity price for each time period based on meteorological information (information indicating current or future weather conditions), market price information (information indicating the electricity price in the electricity market), and the trading situation in the electricity trading platform PF. The predicted electricity price is the electricity price for each time period (the buying and selling price of electricity) in the electricity trading platform PF. The vehicle agent 200 executes bidding in the normal market based on the predicted electricity price for each time period and the required amount of electricity. The vehicle agent 200 basically executes bidding to reduce electricity costs. However, if bidding conditions are set by the user, the vehicle agent 200 executes bidding in accordance with the conditions. For example, if a target renewable energy rate is set, the vehicle agent 200 executes bidding to achieve the target renewable energy rate.

[0057] The first bidding algorithm (bidding method in normal times) has been described above. The second bidding algorithm (bidding method in disaster times) will be described later. In both normal times and disaster times, after the vehicle agent 200 makes a bid, the bidding result (result of energy trading) is sent from the energy trading platform PF to the vehicle agent 200.

[0058] The resource agent 300 submits a bid to the energy trading platform PF to sell the power supplied by the resource 310. The resource agent 300 performs automatic bidding for energy trading on behalf of the user according to a predetermined algorithm.

[0059] The traffic control system 700 includes a computer equipped with, for example, a processor, a RAM, and a storage device (none of which are shown). The processor executes a program stored in the storage device to execute various processes in the traffic control system 700. However, the various processes in the traffic control system 700 are not limited to being executed by software, and can also be executed by dedicated hardware (electronic circuitry).

[0060] The traffic control system 700 is configured to manage traffic and logistics in an area (hereinafter referred to as the "target area") that receives power supply from the power system PG. The traffic control system 700 acquires traffic information (e.g., traffic congestion information) and disaster information (e.g., disaster-stricken areas) related to the target area. The traffic control system 700 acquires traffic information, for example, from an information center of the Ministry of Land, Infrastructure, Transport and Tourism. The traffic control system 700 also acquires disaster information from the server 500. The traffic control system 700 is configured to manage the operation of specified vehicles (hereinafter referred to as the "managed vehicles") in the target area. The traffic control system 700 acquires the current position of each managed vehicle (for example, a position based on a Global Positioning System (GPS)).

[0061] In this embodiment, the management vehicles include vehicles for transportation (e.g., postal vehicles, delivery vehicles, buses, and taxis), fire engines, and ambulances. The management vehicles may be driven either manually or automatically. In this embodiment, the driver of the management vehicle drives the management vehicle according to instructions from the traffic management system 700. For example, when the traffic management system 700 receives a request for transportation to a specific destination, the traffic management system 700 searches for an optimal time period and travel route (e.g., a time period and travel route that can arrive at the destination the fastest) based on traffic information and disaster information. Then, the traffic management system 700 instructs the driver of the management vehicle who performs the requested transportation of the destination, the departure time, the travel route, and the arrival time. The instruction content received by the management vehicle may be set in the navigation system of the management vehicle. However, this is not limited to this, and the management vehicle may run unmanned. The traffic management system 700 may control the automatic driving of the management vehicle by remote control.

[0062] In the event of a disaster, the traffic control system 700 performs traffic control of managed vehicles in a manner different from that in normal times. FIG. 5 is a flowchart showing the manner of traffic control in the event of a disaster. The process shown in this flowchart is repeatedly executed by the traffic control system 700. In the following, each step in the flowchart will simply be abbreviated as "S".

[0063] 5 together with FIG. 4, in S101, the traffic control system 700 judges whether or not a disaster has occurred in the target area. Specifically, when a disaster occurs in the target area, information indicating the disaster area (hereinafter, referred to as "disaster area information") is transmitted from the server 500 to the traffic control system 700. In this embodiment, when the traffic control system 700 receives the disaster area information, YES is determined in S101, and the process proceeds to S102. On the other hand, during a period in which the traffic control system 700 does not receive the disaster area information, NO is determined in S101, and the judgment of S101 is repeatedly executed.

[0064] When a disaster occurs in the target area (YES in S101), the traffic control system 700 imposes traffic restrictions in S102. Specifically, the traffic control system 700 restricts transportation vehicles among the managed vehicles from entering the disaster area. This alleviates traffic congestion (e.g., traffic jams) in the disaster area. The traffic control system 700 may manage to prevent any transportation vehicles from entering the disaster area. Alternatively, the traffic control system 700 may permit only vehicles performing specific transportation (e.g., transportation to support disaster victims) to enter the disaster area. Furthermore, the traffic control system 700 dispatches fire engines and ambulances included in the managed vehicles toward the disaster area as necessary.

[0065] Next, in S103, the traffic control system 700 transmits traffic information within the disaster area. In this embodiment, the traffic control system 700 transmits the traffic information to an energy trading platform PF (energy trading computer). The traffic information includes the travel routes of the fire engines and ambulances within the disaster area.

[0066] Fig. 6 is a flowchart showing the processing executed by the energy trading platform PF when a disaster occurs. When the energy trading platform PF detects the occurrence of a disaster, it starts a series of processing shown in Fig. 6. In this embodiment, when a disaster occurs in a target area, disaster area information is sent from the server 500 to the energy trading platform PF (energy trading computer). When the energy trading platform PF receives the disaster area information, it determines that a disaster has occurred. Note that the processing shown in Figs. 6, 8, and 9 is executed by the server (energy trading computer) executing a program in the energy trading platform PF.

[0067] Referring to Fig. 6 together with Fig. 4, in S11, the energy trading platform PF opens a disaster market. The disaster market corresponds to an energy trading market for distributing power supplied by resources 310 capable of supplying power within a disaster area to each vehicle 210 within the disaster area. The disaster market is operated by a disaster market mechanism. For energy trading outside the disaster area, the operation of the normal market by the normal market mechanism continues.

[0068] Thereafter, in S12, the energy trading platform PF identifies the disaster area based on the disaster area information. Subsequently, in S13, the energy trading platform PF identifies resources 310 that can supply power within the disaster area. Specifically, the energy trading platform PF queries each of the resources 310 that exist within the disaster area among the multiple resources 310 registered in the energy trading platform PF as to whether or not they are safe. Resources 310 that are safe (i.e., resources 310 that can supply power) respond to this query with a signal indicating that they are safe (notification of safety). On the other hand, resources 310 that are not safe do not respond to this query. The energy trading platform PF determines whether or not each of the resources 310 that exist within the disaster area can supply power based on the presence or absence of a response.

[0069] Next, in S14, the energy trading platform PF identifies vehicles 210 that are movable within the disaster area. Specifically, the energy trading platform PF inquires of each vehicle 210 that is present within the disaster area, among the multiple vehicles 210 registered in the energy trading platform PF, whether it is safe or not. Vehicles 210 that are safe respond to this inquiry with a signal indicating that they are safe (notification of safety). On the other hand, vehicles 210 that are not safe do not respond to this inquiry. The energy trading platform PF judges whether each vehicle 210 present within the disaster area is movable or not, based on the presence or absence of a response.

[0070] Fig. 7 is a diagram showing an example of a disaster area. Referring to Fig. 7, in S13 of Fig. 6, a resource RA that can supply power in the disaster area is identified. In S14 of Fig. 6, a vehicle V that can move in the disaster area is identified. Note that the resource RB in Fig. 7 corresponds to a resource that cannot supply power in the disaster area.

[0071] Referring again to FIG. 6 together with FIG. 4, in S15, the energy trading platform PF notifies the resources 310 and the vehicles 210 in the disaster area identified in S13 and S14 of the opening of the disaster market, and invites bids for the disaster market. Thereafter, in S16, the energy trading platform PF determines whether a predetermined acceptance period has elapsed. Until the acceptance period has elapsed (NO in S16), the processes of S13 to S15 are repeatedly executed. The acceptance period corresponds to a period during which bids are accepted. In this embodiment, the acceptance period in the disaster market (S16) is set shorter than the acceptance period in the normal market. The acceptance period in the disaster market may be about 5 minutes, may be 10 minutes or more and less than 30 minutes, or may be 30 minutes or more.

[0072] An agent (vehicle agent 200) of a vehicle 210 that wishes to purchase electricity makes a buying bid within the acceptance period. Specifically, upon receiving the above notification (S15), the vehicle agent 200 requests the conditions of the buying bid from a user terminal (for example, the mobile terminal 220). In this embodiment, the conditions of the buying bid are requested to be the bid price, the bid amount (kWh), and the delivery period of the electricity. The user terminal requests the user to input the buying bid conditions, and when the buying bid conditions are input by the user, the user terminal returns the conditions to the vehicle agent 200. The vehicle agent 200 makes a buying bid according to the received conditions. At this time, the vehicle agent 200 sends a tag (see FIG. 2) indicating the buying bid conditions to the energy trading platform PF. The buying bid is executed according to the second bidding algorithm of the vehicle agent 200.

[0073] An agent (resource agent 300) of a resource 310 that wishes to sell electricity also submits a bid within the acceptance period. The resource agent 300 submits a selling bid under conditions (e.g., bid price, bid amount, and electricity delivery period) acquired from a user, similar to the vehicle agent 200 described above. At this time, the resource agent 300 sends a tag (see FIG. 2) indicating the selling bid conditions to the energy trading platform PF. Note that an agent of a prosumer who owns both a vehicle 210 and a resource 310 may submit either a buying bid or a selling bid.

[0074] When the acceptance period has elapsed (YES in S16), the energy trading platform PF (more specifically, the disaster market mechanism) executes energy trading for the bids made within the acceptance period in S17. Fig. 8 is a flowchart showing the details of S17.

[0075] 8 together with FIG. 4, in S21, the energy trading platform PF (more specifically, the bid screening mechanism included in the disaster market mechanism) executes bid screening. FIG. 9 is a flowchart showing the details of S21. A series of processes shown in FIG. 9 is executed for each sell bid made to the disaster market within the acceptance period. Hereinafter, the sell bid to be processed is also referred to as a "target bid".

[0076] 4 and 9, in S31, the bid review mechanism obtains traffic information from the traffic control system 700. The traffic information indicates the traffic conditions in the disaster area. Specifically, the traffic information includes the travel routes of the fire engines and the ambulances in the disaster area.

[0077] Next, in S32, the bid examination mechanism obtains the installation location of the resource 310 for which the target bid has been made. The bid examination mechanism obtains the installation location of the resource 310 from, for example, a database on the cloud. Alternatively, the bid examination mechanism may obtain the installation location of the resource 310 from the information management server 100.

[0078] Next, in S33, the bid examination mechanism obtains the current location and SOC of the vehicle 210 for each vehicle 210 that has made a purchase bid in the disaster market during the acceptance period. The bid examination mechanism obtains the current location and SOC of the vehicle 210, for example, from the information management server 100. Alternatively, the bid examination mechanism may obtain the current location and SOC of the vehicle 210 from the vehicle agent 200 of each vehicle 210.

[0079] Next, the bid screening mechanism determines whether or not the bid satisfies bidding requirements A, B, and C, respectively, in S34, S35, and S36. Bidding requirement A is that the location of vehicle 210 obtained in S33 is within the disaster area. Bidding requirement B is that the SOC of vehicle 210 obtained in S33 is equal to or less than a predetermined value (hereinafter referred to as "Th"). Bidding requirement C is that the transfer of electricity after the agreement is made does not disrupt traffic in the disaster area.

[0080] If all of the bidding requirements A through C are met (YES in all of S34 through S36), the bid review mechanism determines in S361 to accept the bid. On the other hand, if any of the bidding requirements A through C are not met (NO in any of S34 through S36), the bid review mechanism determines in S362 to reject the bid.

[0081] In S36, the bid screening mechanism judges whether or not the bid requirement C is satisfied based on the traffic conditions in the disaster area, the installation location of the resource that transfers the power, and the location of the vehicle that receives the power. Fig. 10 is a diagram for explaining the bid requirement C. The disaster area shown in Fig. 10 is the same as the disaster area shown in Fig. 7.

[0082] 10, in S36 of FIG. 9, it is determined whether the transfer of electricity to be performed after the agreement will disrupt traffic in the disaster area based on whether the movement route of the bidding vehicle during the power transfer period interferes (overlaps) with the movement routes L11 to L13 of the priority vehicle during the power transfer period. In this embodiment, a fire engine and an ambulance are each considered to be priority vehicles. In the example shown in FIG. 10, each of vehicles V1 and V2 is a vehicle 210 that made a purchase bid on the disaster market during the acceptance period, and corresponds to a bidding vehicle (a vehicle that receives electricity).

[0083] For example, the route from the position of vehicle V1 to the installation positions of resources R2 and R3 interferes with the travel routes L11 and L12 of the priority vehicles, respectively. Therefore, in the bid screening of the selling bids made by resources R2 and R3, the buying bid of vehicle V1 does not satisfy the bidding requirement C. On the other hand, the route L1 from the position of vehicle V1 to the position of resource R1 does not interfere with any of the travel routes L11 to L13 of the priority vehicles. Therefore, in the bid screening of the selling bid made by resource R1, the buying bid of vehicle V1 satisfies the bidding requirement C. In the example shown in FIG. 10, each of resources R1 to R3 is a resource 310 that made a selling bid to the disaster market during the acceptance period, and corresponds to a bidding resource (a resource that delivers electricity).

[0084] In addition, the route from the position of vehicle V2 to the position of resource R4 interferes with the movement route L13 of the priority vehicle. Therefore, in the bid screening of the selling bid made by resource R4, the buying bid of vehicle V2 does not satisfy the bidding requirement C. On the other hand, the route L2 from the position of vehicle V2 to the position of resource R5 does not interfere with any of the movement routes L11 to L13 of the priority vehicle. Therefore, in the bid screening of the selling bid made by resource R5, the buying bid of vehicle V2 satisfies the bidding requirement C.

[0085] As described above, the bid screening mechanism included in the disaster market mechanism manages so that electricity transactions are not concluded for bids from vehicles (users) that are likely to cause traffic congestion in the disaster area. This suppresses the transfer of electricity that causes traffic congestion in the disaster area. In addition to the route from the bidding vehicle to the bidding resource (hereinafter also referred to as the "outbound route"), the determination in S36 of FIG. 9 may also take into account the route from the bidding resource to the storage location of the bidding vehicle (hereinafter also referred to as the "return route"). The outbound route is the route by which the bidding vehicle receives the electricity that it has won. The return route is the route by which the bidding vehicle returns the electricity that it has received from the bidding resource to the storage location (for example, the home of the user who owns the bidding vehicle). If either the outbound route or the return route interferes with the travel route of the priority vehicle, NO may be determined in S36 of FIG. 9. If neither the outbound route nor the return route interferes with the travel route of the priority vehicle, YES may be determined in S36 of FIG. 9.

[0086] When the above-mentioned bid screening (FIG. 9) is performed for all bids submitted to the disaster market within the acceptance period, the process proceeds to S22 in FIG. 8. Referring again to FIG. 8 together with FIG. 4, in S22, the energy trading platform PF (more specifically, the matching mechanism included in the disaster market mechanism) performs matching for bids that have passed the screening. The matching mechanism matches selling bids with buying bids so as to satisfy the conditions indicated by the tags. Then, if the matching is successful, the energy trading platform PF (more specifically, the smart contract included in the disaster market mechanism) executes energy trading for both successfully matched bids in S23. This results in the establishment of a contract between the matched bidders.

[0087] Next, in S24, the smart contract issues authentication information to each bidder. The authentication information is sent to an agent of each bidder together with information indicating the agreed content (e.g., bid price, bid amount (kWh), power delivery period, and installation location of the bidding resource). The installation location of the agreed bidding resource may be sent from the agent (vehicle agent 200) to the bidding vehicle and set in the navigation system of the bidding vehicle. The navigation system may guide the bidding vehicle to the bidding resource. The agreed bidding vehicle uses the authentication information to use the agreed bidding resource. The bidding resource allows the bidding vehicle that has presented the authentication information to charge.

[0088] After that, the energy trading platform PF records the transaction in S25. Specifically, the energy trading transaction is recorded in the blockchain ledger. When the process of S25 is executed, the series of processes shown in Fig. 8 is ended, and the process proceeds to S18 in Fig. 6.

[0089] Referring again to FIG. 6 together with FIG. 4, in S18, the disaster market mechanism judges whether or not to close the disaster market. In this embodiment, when the power outage is restored, restoration information informing the same is sent from the server 500 to the energy trading platform PF (energy trading computer). If the disaster market mechanism does not receive the restoration information, it judges NO in S18 and returns the process to S13. Then, the disaster market mechanism accepts bids for the disaster market in the next acceptance period while executing the processes of S13 to S16. On the other hand, if the disaster market mechanism receives the restoration information, it judges YES in S18 and the series of processes shown in FIG. 6 ends. This closes the disaster market. The power purchase fee in the disaster market is charged on a deferred basis (for example, monthly). The fee in the disaster market may be charged at a premium to the fee in the normal market.

[0090] As described above, the energy trading platform PF (energy trading computer) according to this embodiment operates a disaster market (an energy trading market for distributing electricity supplied by resources capable of supplying electricity in a disaster-stricken area to each vehicle in the disaster-stricken area) when a disaster occurs. When the energy trading platform PF (energy trading computer) receives a bid for the disaster market, it determines whether to accept the bid using the traffic conditions in the disaster-stricken area, the installation positions of the resources that transfer the electricity, and the positions of the vehicles that receive the electricity (see FIG. 9). The energy trading platform PF makes it possible to distribute electricity supplied by resources capable of supplying electricity in the disaster-stricken area to each vehicle in the disaster-stricken area while suppressing traffic congestion in the disaster-stricken area.

[0091] In the above embodiment, only resources that wish to sell power submit a selling bid to the disaster market. However, the present invention is not limited to this embodiment, and when a disaster occurs, all resources that can supply power within the affected area may be contractually obligated in advance to submit a selling bid to the disaster market.

[0092] In the above embodiment, in the bidding for the disaster market, the bid price, the bid amount (kWh), and the delivery period of the electricity are determined by the bidder. However, the present invention is not limited to this form, and in the bidding for the disaster market, the bid price and the bid amount may be constant (fixed value), and only the delivery period of the electricity may be determined by the bidder. Then, the smart contract included in the disaster market mechanism may be configured to determine the successful bidder based on a criterion other than the price. For example, the smart contract may give priority to a prioritized vehicle (for example, a vehicle of a local government) in the successful bid. The smart contract may give priority to a bidding vehicle close to the bidding resource (a bidding vehicle with a short distance to the bidding resource). The smart contract may give priority to a bidding vehicle having a V2H function. The smart contract may give priority to a bidding vehicle having a V2G function.

[0093] The bidding requirements (requirements for accepting bids) are not limited to the bidding requirements A to C described above, and may be modified as appropriate. For example, bidding requirement B (S35 in FIG. 9) may be omitted. Also, a requirement that the bidding vehicle be stored within the disaster area may be added as a bidding requirement. Priority vehicles (S36 in FIG. 9) are not limited to fire engines and ambulances, and are optional. Priority vehicles may include at least one of vehicles involved in restoration work and local government vehicles.

[0094] In the above embodiment, the vehicle and the vehicle agent do not communicate directly, but communicate with each other via a mobile terminal. However, the present invention is not limited to this embodiment. The vehicle may be equipped with a wireless communication device (e.g., a Data Communication Module (DCM)) that can access a mobile communication network (telematics) and may wirelessly communicate directly with the vehicle agent. The vehicle may also communicate with the vehicle agent via an EVSE.

[0095] In the above embodiment, a mobile terminal is used as the user terminal. However, the present invention is not limited to this, and any terminal belonging to a user can be used as the user terminal. For example, the user terminal may be an in-vehicle terminal (e.g., a navigation system).

[0096] In the above embodiment, a vehicle (POV) owned by an individual is mentioned. However, the present invention is not limited to this, and a MaaS (Mobility as a Service) vehicle may be adopted instead of the POV. The MaaS vehicle is a vehicle managed by a MaaS operator.

[0097] The vehicle 210 is not limited to a passenger car, and may be a bus or a truck. The vehicle 210 may be configured to be capable of contactless charging. The vehicle 210 may be configured to be capable of autonomous driving, or may have a flying function. The vehicle 210 may be a vehicle capable of traveling without a driver (for example, a robotaxi, an automated guided vehicle (AGV), or an agricultural machine).

[0098] In the above embodiment, the vehicle agent is provided on the cloud, but the present invention is not limited to this, and at least a part of the functions of the vehicle agent may be implemented in an on-premise server, a vehicle, or a mobile terminal.

[0099] The power system PG is not limited to a large-scale AC grid, and may be a microgrid or a DC (direct current) grid. The vehicle 210 may be equipped with a charger or a charger / discharger for DC power.

[0100] The embodiments disclosed herein should be considered to be illustrative and not restrictive in all respects. The scope of the present invention is defined by the claims, not by the description of the embodiments described above, and is intended to include all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0101] 100 information management server, 200 vehicle agent, 210 vehicle, 220 mobile terminal, 300 resource agent, 310 resource, 500 server, 700 operation management system, P110 power generation equipment, P111, P112 substation equipment, PF power trading platform, PG power system.

Claims

1. An energy trading computer comprising: When the energy trading computer receives disaster area information indicating a disaster area, the energy trading computer notifies resources in the disaster area and vehicles in the disaster area of ​​an opening of an energy trading market; when the energy trading computer receives a selling bid indicating power selling conditions from a resource within the disaster area and a buying bid indicating power purchasing conditions from a vehicle within the disaster area, the energy trading computer determines whether or not the selling bid and the buying bid satisfy bidding requirements; The vehicle includes a power storage device and is configured to be able to receive power from the resource; The bidding requirements include that the transfer of power from the resource to the vehicle after the contract is concluded does not disrupt traffic in the disaster area; the energy trading computer determines whether or not the transfer of the electricity to be performed after the agreement will disrupt traffic in the disaster area, using the traffic conditions in the disaster area, the installation location of the resource that has made the selling bid, and the location of the vehicle that has made the buying bid; The energy trading computer is configured to execute an energy transaction to establish an energy purchase and sale contract in the energy trading market only for the buying bids and the selling bids that satisfy the bidding requirements.

2. Each of the electricity sales terms and the electricity purchase terms includes a delivery period of electricity, The traffic conditions in the disaster area include a travel route of a priority vehicle in the disaster area; The priority vehicles include fire engines and ambulances; The energy trading computer includes: if a route from the location of the vehicle that made the buying bid to the installation location of the resource that made the selling bid interferes with the movement route of the priority vehicle during the power transfer period, it is determined that the power transfer that will be performed after the agreement will disrupt traffic in the disaster area; configured to determine that the transfer of electricity to be performed after the agreement will not disrupt traffic in the disaster area when a route from the location of the vehicle that has made the buying bid to the installation location of the resource that has made the selling bid does not interfere with the movement route of the priority vehicle during the power transfer period; The energy trading computer according to claim 1 , wherein after concluding an electricity purchase and sale contract for the buying bid and the selling bid that satisfy the bidding requirements, the energy trading computer issues information indicating the contents of the contract to a user of the vehicle that has entered into the contract.

3. An energy trading system comprising an energy trading platform, The energy trading platform comprises a blockchain ledger and an energy trading computer that executes a program related to the energy trading platform; a plurality of users, a plurality of assets held by the plurality of users, and a plurality of agents held by the plurality of users are registered in the energy trading computer; Each of the plurality of assets is configured to be electrically connectable to a power grid, The plurality of assets includes a plurality of vehicles and a plurality of resources; Each of the plurality of vehicles is equipped with a power storage device and is configured to be able to receive the power purchased by the user from the power grid or the resource; Each of the plurality of resources is configured to be able to output the power sold by the user to the power grid or the vehicle; the plurality of agents include a vehicle agent that makes an automatic bid to buy electricity to be supplied to the vehicle, and a resource agent that makes an automatic bid to sell electricity supplied by the resource; The energy trading system further includes a first server, a second server, and a traffic management system. the first server is configured to acquire vehicle information relating to each of the plurality of vehicles from the vehicle; The vehicle information includes a position and a State Of Charge (SOC) of the vehicle, the first server is configured to obtain, from each of the plurality of resources, resource information relating to the resource; The operation management system is configured to be able to acquire traffic information and disaster information related to a target area that receives power supply from the power system, The operation management system is configured to acquire a current position of the management vehicle from the management vehicle and transmit an instruction regarding the driving of the management vehicle to the management vehicle; The management vehicles include vehicles for transportation, fire engines, and ambulances, the second server is configured to receive facility information indicating a facility status from each of a plurality of power generation facilities and a plurality of substation facilities that supply power to the power grid, and to identify a disaster-stricken area of ​​the target region based on the facility information; the second server is configured to transmit disaster area information indicating the identified disaster area to each of the energy trading computer and the traffic management system; the energy trading computer is configured to, upon receiving the disaster area information, open an energy trading market in the energy trading platform, inquire of each of the vehicles present within the disaster area among the plurality of vehicles and each of the resources present within the disaster area as to whether they are safe or not, and notify the vehicles and resources which reply to the inquiry that the energy trading market will be opened; the vehicle agent of the vehicle that has been notified of the opening of the energy trading market requests conditions for a buying bid on the energy trading market from a user terminal of the vehicle, and transmits first bid data indicating the conditions for the buying bid received from the user terminal to the energy trading computer; the resource agent of the resource that has been notified of the opening of the energy trading market requests conditions for a sell bid to the energy trading market from a user terminal of the resource, and transmits second bid data indicating the conditions for the sell bid received from the user terminal to the energy trading computer; the energy trading computer is configured to perform a bid review on the first bid data and the second bid data; The bid review shall be The energy trading computer acquires traffic information indicating a traffic condition in the disaster area from the traffic management system; The energy trading computer obtains, from the vehicle agent or the first server, a location and an SOC of a vehicle that has made a buying bid using the first bid data; The energy trading computer acquires, from a database on a cloud or the first server, installation locations of the resources for which a selling bid has been made based on the second bid data; determining whether the buy bid and the sell bid satisfy bidding requirements; Including, The traffic information indicating a traffic condition within the disaster area includes travel routes of the fire engine and the ambulance within the disaster area, The bidding requirements are: a first requirement that is satisfied when a vehicle that has made a purchase bid based on the first bid data is located within the disaster area; a second requirement that is satisfied when the SOC of the vehicle for which a purchase bid has been made based on the first bid data is equal to or less than a predetermined value; A third requirement is met when the delivery of electricity after the agreement does not disrupt traffic in the disaster area; and Including, the energy trading computer is configured to determine whether the third requirement is satisfied based on the traffic information indicating traffic conditions in the disaster area, installation locations of resources that have made selling bids based on the second bidding data, and locations of vehicles that have made buying bids based on the first bidding data; an energy trading computer configured to match combinations of buying bids and selling bids that satisfy the bidding requirements based on the conditions of the buying bids indicated by the first bidding data and the conditions of the selling bids indicated by the second bidding data, execute energy trading for the buying bids and the selling bids that have been successfully matched, and record the executed energy trading transactions in the blockchain ledger.

Images