Information management device, information management method, and program

Abstract

An information management device according to an embodiment, which mediates a transaction between users and manages the transaction result by storing a smart contract regarding the transaction on a blockchain, is provided with: an acquisition unit that acquires a request regarding buying or selling as received from a user; a matching unit that matches a new request newly acquired by the acquisition unit with an existing request included in a smart contract already stored on the blockchain; and a processing unit that, when the matching is not established, generates a smart contract including the new request on the blockchain, and when the matching is established, adds information about the new request to the smart contract including the matched existing request.

Description

Information management device, information management method, and program

[0001] The present invention relates to an information management device, an information management method, and a program.

[0002] In recent years, research has been conducted into technologies for recording information using blockchains. In this context, a technology is known in which transaction information is collected at predetermined intervals and stored on a blockchain network in order to reduce the frequency of recording transaction information (see, for example, Patent Literature 1).

[0003] Japanese Patent Application Laid-Open No. 2022-46757

[0004] However, while storing information at predetermined intervals, as in conventional technology, reduces costs such as the amount of data on the blockchain, there is a time lag with the actual transaction status, which means that it may not be possible to accurately manage each piece of information.

[0005] In order to solve the above-mentioned problems, one of the objectives of this application is to provide an information management device, an information management method, and a program that can manage information more accurately while reducing the amount of data stored on a blockchain.

[0006] The information management device, information management method, and program according to the present invention employ the following configuration: (1): An information management device according to one aspect of the present invention is an information management device that mediates transactions between users and manages transaction results by storing smart contracts related to the transactions on a blockchain, and includes: an acquisition unit that acquires purchase or sale requests received from users; a matching unit that matches a new request newly acquired by the acquisition unit with an existing request included in a smart contract already stored on the blockchain; and a processing unit that, if the matching is not established, generates a smart contract on the blockchain that includes the new request, and, if the matching is established, adds information about the new request to the smart contract that includes the existing request with which the matching was established.

[0007] (2): In the aspect of (1) above, the processing unit generates a smart contract including information of the new request converted into a hash value.

[0008] (3): In the aspect of (1) above, the processing unit generates a smart contract including the new request using a program stored in advance on the blockchain.

[0009] (4): In the above aspect (3), the blockchain is Ethereum.

[0010] (5): In the aspect of (1) above, the transaction includes an electricity transaction, the request includes a request for purchasing or selling electricity, and the processing unit adds the electricity transaction result for the request to the smart contract.

[0011] (6): In the above aspect (1), the smart contract includes at least one of information regarding the user, the transaction type, information regarding the tokens to be exchanged after the transaction is completed, and information for referencing information regarding the request recorded in a memory unit outside the blockchain.

[0012] (7): In the above aspect (1), the processing unit hashes session information in transactions between the users and stores it on the blockchain, and stores transaction information including the transaction amount and transaction volume on the blockchain without hashing it.

[0013] (8): An information management method according to one embodiment of the present invention is an information management method in which an information management device that mediates transactions between users and manages transaction results by storing smart contracts related to the transactions on a blockchain acquires a purchase or sale request received from a user, matches the newly acquired new request with an existing request included in a smart contract already stored on the blockchain, and if the matching is not successful, generates a smart contract on the blockchain that includes the new request, and if the matching is successful, adds information about the new request to the smart contract that includes the existing request with which the matching was achieved.

[0014] (9): A program according to one aspect of the present invention is a program that causes an information management device, which mediates transactions between users and manages transaction results by storing smart contracts related to the transactions on a blockchain, to acquire a purchase or sale request received from a user, match the newly acquired new request with an existing request included in a smart contract already stored on the blockchain, generate a smart contract on the blockchain that includes the new request if the match is not established, and add information about the new request to the smart contract that includes the existing request with which the match is established if the match is established.

[0015] According to the above aspects (1) to (9), it is possible to reduce the amount of data stored on the blockchain while managing information more accurately.

[0016] 1 is a configuration diagram of a trading system 1 using an information management device of an embodiment. FIG. 1 is a configuration diagram of an information management device 100 of an embodiment. FIG. 1 is a configuration diagram of a user terminal 200 of an embodiment. FIG. 2 is a sequence diagram for explaining a series of flows of energy trading in an embodiment. FIG. 3 is a diagram showing an example of an image IM10 displayed on the user terminal 200 in a request generation process. FIG. 4 is a flowchart showing an example of a matching process and a smart contract generation process in the first embodiment. FIG. 5 is a diagram for explaining requests received from each user U in the first embodiment. FIG. 6 is a diagram for explaining smart contracts SC stored on the blockchain 300 in the first embodiment. FIG. 7 is a diagram showing an example of a specific configuration of a processing unit 140 in the second embodiment. FIG. 8 is a flowchart showing an example of a matching process and a smart contract generation process in the second embodiment. FIG. 9 is a diagram for explaining requests from each user U and smart contracts SC stored on the blockchain 300 in the second embodiment. FIG. 10 is a flowchart showing an example of a matching process and a smart contract generation process in the third embodiment. FIG. 11 is a diagram for explaining requests from each user U and smart contracts SC stored on the blockchain 300 in the third embodiment. FIG. 12 is a diagram for explaining requests from each user U and smart contracts SC stored on the blockchain 300 in the third embodiment. FIG. 13 is a diagram showing an example of an image IM20 related to the matching result. FIG. 14 is a diagram for explaining processing related to energy trading. It is a figure which shows an example of an image IM30 concerning the energy trading situation. It is a figure for demonstrating the management of the trading situation during the charge and discharge session. It is a flowchart which shows an example of the process which is executed by the information management device 100 during the charge and discharge session.

[0017] Hereinafter, with reference to the drawings, an embodiment of an information management device, an information management method, and a program of the present invention will be described. An example in which the information management device is applied to a trading system (person-to-person trading system) in which transactions are conducted between users will be described. Furthermore, while the following description uses electricity trading as an example of trading, credit trading, etc., or trading of other products or services may be used instead of (or in addition to) electricity trading.

[0018] [Overall Configuration] FIG. 1 is a configuration diagram of a trading system 1 using an information management device according to an embodiment. The trading system 1 includes, for example, an information management device 100, one or more user terminals 200-1 to 200-n, a blockchain 300, a file system 400, a charge / discharge control system (hereinafter referred to as a charge / discharge CS) 500, and a charge / discharge facility 520. The information management device 100, the user terminal 200, the blockchain 300, and the charge / discharge CS 500 can communicate with each other via, for example, a network NW. The network NW includes, for example, a cellular network, a Wi-Fi network, Bluetooth (registered trademark), the Internet, a wide area network (WAN), a local area network (LAN), a public line, a provider device, a dedicated line, a wireless base station, and the like. The file system 400 is an example of a "storage unit."

[0019] The information management device 100 may be, for example, a server device or a PC (Personal Computer), or may be a cloud server configured by cloud computing including one or more information processing devices. The information management device 100 may also function as an edge server that processes data stored on the blockchain 300 or the file system 400. The information management device 100 mediates transactions between users. For example, the information management device 100 generates information related to energy trading (e.g., smart contract SC) to be stored on the blockchain 300, or generates information related to energy trading (e.g., data set DS) to be stored in the file system 400.

[0020] The user terminal 200 is a device used by a user U (consumer), and may be, for example, a smartphone, a tablet terminal, or a PC. The user terminal 200 accepts transaction requests (e.g., purchase requests or electricity sale requests) input by the user U and transmits the accepted requests to the information management device 100. The user terminal 200 also receives information related to electricity transactions from the information management device 100 and provides the information to the user U by displaying images or outputting audio. In the example of FIG. 1 , a transaction is conducted regarding the power of a battery B installed in an electric vehicle M owned by the user U. The electric vehicle M is, for example, a battery electric vehicle (BEV) that runs using an electric motor driven by power supplied from the battery B. Alternatively, the electric vehicle may be a plug-in hybrid vehicle (PHV) or a plug-in hybrid electric vehicle (PHEV), which is a hybrid vehicle equipped with an external charging function. In addition, electric vehicle M includes not only four-wheeled vehicles, but also saddle-type two-wheeled vehicles, three-wheeled vehicles (including vehicles with one front wheel and two rear wheels as well as vehicles with two front wheels and one rear wheel), assisted bicycles, electric kick scooters, and other "mobile bodies" that run using an electric motor powered by power supplied from a battery.

[0021] The blockchain 300 is a data store (database) that manages information about transactions in units called blocks, links the information, and stores it to clarify the context (order). The blockchain 300 may be a blockchain network composed of multiple devices (nodes) that can access each other. The blockchain 300 is, for example, Ethereum. Ethereum is a distributed application platform that uses smart contracts SC as blocks and can manage programs and their operations on the blockchain 300. In the embodiment, the use of Ethereum, which has higher tamper resistance and reliability than other public blockchains, can further ensure the security of transactions.

[0022] The smart contract SC stores data such as request information and energy trading information related to energy trading as transactions. In addition to the above information, the transaction may also include software (computer programs) that are automatically executed when certain conditions are met. The smart contract SC also includes a hash value generated based on the immediately preceding block (transaction). When adding new data to the smart contract SC, for example, a new block containing the hash value of the immediately preceding block, the data to be stored (e.g., transaction data), and a nonce value is hashed (e.g., the block is input into a hash function to calculate the hash value), and the calculated hash value and block are stored, thereby linking the data to the previous block and storing it in the smart contract SC.

[0023] The process of generating and storing (saving) a smart contract SC on the blockchain 300 can be executed by the nodes connected to the blockchain 300 and the information management device 100. Furthermore, in the blockchain 300, multiple terminals can store smart contract SC and perform cross-checking, etc. In the following description, the blockchain 300 may be referred to as "on-chain."

[0024] The file system 400 is, for example, a P2P (Peer to Peer) distributed file system based on the Inter Planetary File System (IPFS). The file system 400 may be an IPFS network configured with multiple devices (nodes) that can access each other. The file system 400 stores a dataset (electronic data) DS containing information about energy trading. The file system 400 is connected to the information management device 100, which manages the stored dataset DS. The dataset DS is stored in a secure environment so that the user terminal 200 and the like cannot directly access it via the network NW. Therefore, the data stored in the file system 400 does not need to be hashed. In the following description, the file system 400 may be referred to as an "off-chain" or "backend."

[0025] The charging / discharging CS 500 manages the charging or discharging of the battery B of the electric vehicle M connected to the charging / discharging equipment 520. By connecting to the electric vehicle M, the charging / discharging equipment 520 supplies power to the battery B of the electric vehicle M to charge it, and supplies power discharged from the battery B to the outside. The charging / discharging CS 500 manages location information of the multiple charging / discharging equipment 520 installed at various locations, a charging / discharging schedule for the electric vehicle M, and the like. The charging / discharging CS 500 may also control charging / discharging based on control information from the information management device 100, and may transmit charging / discharging results to the information management device 100. Next, the configurations of the information management device 100 and the user terminal 200 will be described in detail.

[0026] [Information Management Device] Figure 2 is a configuration diagram of an information management device 100 according to an embodiment. The information management device 100 includes, for example, a communication unit 110, an acquisition unit 120, a matching unit 130, a processing unit 140, a registration unit 150, a provision unit 160, and a device-side storage unit 170. The acquisition unit 120, the matching unit 130, the processing unit 140, the registration unit 150, and the provision unit 160 are implemented by a hardware processor, such as a central processing unit (CPU), executing a program (software). Some or all of these components may be implemented by hardware (including circuitry), such as a large-scale integration (LSI), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a graphics processing unit (GPU), or may be implemented by a combination of software and hardware. The program may be stored in advance in a storage device (storage device with a non-transitory storage medium) such as a HDD (Hard Disk Drive) or flash memory provided in the information management device 100, or may be stored in a removable storage medium (non-transitory storage medium) such as a DVD or CD-ROM, and installed in the HDD or flash memory provided in the information management device 100 by inserting the storage medium into a drive device provided in the information management device 100.

[0027] The device-side storage unit 170 may be realized by the various storage devices described above, or a solid-state drive (SSD), an electrically erasable programmable read-only memory (EEPROM), a read-only memory (ROM), a random-access memory (RAM), or the like. The device-side storage unit 170 stores, for example, a user information database (DB) 172, processing results of the information management device 100, programs, and various other information. The user information DB 172 associates, for example, information about a user U who uses the trading system 1 (e.g., a user ID and address information of the user U), information about a user terminal 200 used by the user U (e.g., a terminal ID), and information about an electric vehicle M used by the user U (e.g., a vehicle ID). The terminal ID, vehicle ID, etc. may be a media access control (MAC) address assigned to each device. One or more user terminals 200 and one or more electric vehicles M may be associated with each user U in the user information DB 172.

[0028] The communication unit 110 communicates with the user terminal 200, the blockchain 300, the charge / discharge CS 500, and other external devices via the network NW. The communication unit 110 also communicates with the file system 400, for example, via a dedicated line or the like.

[0029] The acquisition unit 120 acquires information about the user U who uses the services in the trading system 1 based on the information received by the communication unit 110. The acquisition unit 120 also acquires requests for purchases or sales from the user U, and acquires information about the status of charging and discharging electricity (electricity trading) and transaction results from the charging and discharging CS 500.

[0030] Before generating the smart contract SC to be stored on the blockchain 300, the matching unit 130 matches the new request (accepted request) newly acquired by the acquisition unit 120 with the existing request stored in the smart contract SC already stored on the blockchain 300.

[0031] The processing unit 140 generates a smart contract SC including the new request when the matching unit 130 fails to match the new request with an existing request. Furthermore, when the matching is successful, the processing unit 140 adds information about the new request to the smart contract SC including the matching existing request. Note that in the embodiment, "adding" may also include changing, editing, deleting, or updating some information in the smart contract SC. Details of the functions of the processing unit 140 will be described later.

[0032] The registration unit 150 stores (registers) the smart contract SC generated by the processing unit 140 on the blockchain 300. Note that the processing unit 140 may generate the smart contract SC on the blockchain 300 without going through the registration unit 150.

[0033] The registration unit 150 may also manage the registration of users U who use services provided by the trading system 1. In this case, the registration unit 150 newly registers the user U and registers the new user information in the user information DB 172. The registration unit 150 also compares the identification information of the user U or the user terminal 200 who has accessed to use the service with the identification information registered in the user information DB 172, and performs control such as permitting use of the service if matching identification information is registered, and denying use of the service if no identification information is registered.

[0034] The providing unit 160 provides various types of information to the user terminal 200 and the charge / discharge CS 500. For example, the providing unit 160 generates information (images, audio) related to the matching result by the matching unit 130, and provides the generated information to the user terminal 200. Furthermore, when matching is established by the matching unit 130, the providing unit 160 provides the charge / discharge CS 500 with information related to the electric vehicle M that will perform charging / discharging and the user U.

[0035] [User Terminal] Figure 3 is a configuration diagram of a user terminal 200 according to an embodiment. The user terminal 200 includes, for example, a terminal communication unit 210, an input unit 220, an output unit 230, a location information acquisition unit 240, a control unit 250, an application execution unit 260, and a terminal storage unit 270. The location information acquisition unit 240, the control unit 250, and the application execution unit 260 are each realized by, for example, a hardware processor such as a CPU executing a program (software). Furthermore, some or all of these components may be realized by hardware (including circuitry) such as an LSI, ASIC, FPGA, or GPU, or may be realized by a combination of software and hardware. The program may be stored in advance in a storage device (a storage device with a non-transitory storage medium) such as a HDD or flash memory provided in the user terminal 200, or may be stored in a removable storage medium (a non-transitory storage medium) such as a DVD or CD-ROM, and the storage medium may be installed in the HDD or flash memory provided in the user terminal 200 by being inserted into a drive device provided in the user terminal 200.

[0036] The terminal-side storage unit 270 may be realized by the various storage devices described above, or an SSD, an EEPROM, a ROM, a RAM, etc. The terminal-side storage unit 270 stores, for example, the trading application 272, processing results of the user terminal 200, programs, and various other information.

[0037] The terminal-side communication unit 210 communicates with the information management device 100 and other external devices via the network NW, for example. The terminal-side communication unit 210 may also communicate with the electric vehicle M used by the user U via short-range communication.

[0038] The input unit 220 receives input from the user U by operating various keys, buttons, etc. The input unit 220 may include a microphone and receive voice input from the user U, for example.

[0039] The output unit 230 includes, for example, a display 232 and a speaker 234. The display 232 is, for example, an LCD (Liquid Crystal Display) or an organic EL (Electro Luminescence) display. Under the control of the control unit 250 and the application execution unit 260, the output unit 230 displays various images on the display 232 and outputs audio from the speaker 234. The display 232 may also have the function of the input unit 220, for example, as a touch panel.

[0040] The location information acquisition unit 240 acquires location information (for example, latitude and longitude information) of the user terminal 200 using a built-in GPS (Global Positioning System) device.

[0041] The control unit 250 controls all of the components of the user terminal 200. The control unit 250 stores information received by the input unit 220 in the terminal-side storage unit 270, and transmits the information to the information management device 100 via the terminal-side communication unit 210. The control unit 250 may also cause the output unit 230 to output information such as images and audio acquired from the information management device 100 via the terminal-side communication unit 210, or may generate images and audio based on the information acquired from the information management device 100 and output the images and audio from the output unit 230.

[0042] The application execution unit 260 is realized by executing a trading application 272 stored in the terminal-side storage unit 270. The trading application 272 is, for example, downloaded from an external device via the network NW and installed in the user terminal 200. The trading application 272 transmits information (request information) input by the input unit 220, location information acquired by the location information acquisition unit 240, identification information of the user terminal 200, user information, etc. to the information management device 100, and also acquires information related to the request results, etc. and information related to energy trading and outputs the information to the output unit 230.

[0043] [Flow of Energy Trading] Next, a flow of energy trading using the trading system 1 of the embodiment will be specifically described. FIG. 4 is a sequence diagram for explaining a series of flows of energy trading in the embodiment. As an example, FIG. 4 shows processing in the user terminal 200-1 used by user U1, the user terminal 200-2 used by user U2, the information management device 100, the blockchain 300, and the charge / discharge CS 500. It is assumed that users U1 and U2 are both users who can use the services provided by the trading system 1 (users who have been permitted to use the services by the registration unit 150). In addition, an example of an energy interchange transaction between a battery B1 mounted on an electric vehicle M1 used by user U1 and a battery B2 mounted on an electric vehicle M2 used by user U2 will be described below.

[0044] In the example of FIG. 4, the trading application 272 of the user terminal 200-1 generates a request for an energy trade based on information input by the user U1 (step S100) and transmits the generated request to the information management device 100 (step S102).

[0045] The matching unit 130 of the information management device 100 receives the request sent from the user terminal 200-1 and performs matching of the received request (new request) with other requests (existing requests) included in smart contracts SC already stored on the blockchain 300 (step S104). In the processing of step S104, it is assumed that matching was not successful (there were no existing requests that met the conditions of the new request). In this case, the processing unit 140 of the information management device 100 generates a smart contract SC including the new request in the blockchain 300, transmits it to the blockchain 300 (step S106), and stores the smart contract (SC) on the blockchain 300 (step S108).

[0046] Next, user U2 starts the trading application 272 using user terminal 200-2 and inputs a request for energy trading in the same manner as user U1. User terminal 200-2 generates a request based on the input information (step S110) and transmits the generated request information to information management device 100 (step S112).

[0047] The matching unit 130 acquires the request (new request) sent from the user terminal 200-2 and matches it with existing requests by referencing the smart contract SC stored on the blockchain 300 (step S114). The following explanation will be continued assuming that matching has been achieved between the requests of user U1 and user U2. The providing unit 160 of the information management device 100 generates information (e.g., an image) related to the matching results (step S116) and transmits it to the user terminals 200-1 and 200-2 (steps S118 and S120).

[0048] Each of the user terminals 200-1 and 200-2 displays information related to the matching results transmitted from the information management device 100, and also receives instruction information and the like from users U1 and U2 (steps S122 and S124). The information from users U1 and U2 may be information on whether to approve or reject the energy trade based on the matching results, or, if there are multiple targets that match the conditions, may be information on which of them to select. Each of the user terminals 200-1 and 200-2 transmits the information obtained from users U1 and U2 to the information management device 100 (steps S126 and S128).

[0049] The information management device 100 acquires information from the user terminals 200-1 and 200-2, and if matching is approved, outputs information about the energy transaction (e.g., information about the users U1 and U2 and the electric vehicles M1 and M2 conducting the energy transaction) to the charge / discharge CS 500 (step S130). The charge / discharge CS 500 manages the energy transaction based on the information acquired from the information management device 100 (step S132). Specifically, the charge / discharge CS 500 sets the energy transaction facility 520 to which the target electric vehicle M is connected, and transmits information about the location and usage time (schedule) of the set energy transaction facility 520 to the user terminals 200-1 and 200-2 (steps S134 and S136). Note that information about the energy transaction schedule may be provided by the information management device 100.

[0050] The charging / discharging CS 500 also performs processes related to energy trading management other than steps S134 and S136. For example, the charging / discharging CS 500 transmits information about the users U1 and U2 and the electric vehicles M1 and M2 who will use the charging / discharging facility 520 to the charging / discharging facility 520 to make advance reservations and prevent other electric vehicles M from using the facility during the reserved time. The charging / discharging CS 500 also manages the discharging status and charging status based on information obtained from the charging / discharging facility 520. For example, if user U1 is the seller of electricity and user U2 is the buyer of electricity, the charging / discharging CS 500 receives power discharged from the battery B1 of user U1's electric vehicle M1 and supplies the received power to the battery B2 of electric vehicle M2 via the charging / discharging facility 520 to which electric vehicle M2 is connected. The charging / discharging CS 500 constantly manages these charging / discharging statuses based on information from the charging / discharging facility 520.

[0051] The charging / discharging CS 500 may transmit information regarding the transaction status to the user terminals 200-1 and 200-2. The charging / discharging facility 520 transmits information regarding the electricity transaction status (charging / discharging status) to the information management device 100 at a predetermined timing (step S138). The information regarding the electricity transaction status includes, for example, charging information (status data) indicating the status of charging or discharging of the electric vehicle M1 or M2, information indicating completion of charging or discharging (charging result), and information indicating the end of the connection between the electric vehicles M1 and M2 and the charging / discharging facility 520 (session end information). The charging information is transmitted to the information management device 100 at a predetermined interval, and the charging result is transmitted to the information management device 100 when charging is completed, and the session end information is transmitted to the information management device 100 when the connection between the charging / discharging facility 520 and the electric vehicle M is ended.

[0052] The processing unit 140 of the information management device 100 receives information about the electricity trading status from the charging / discharging CS 500, and generates a data set DS and the like in the file system 400 based on the received information (step S140). The information management device 100 also adds the charging session result (electricity trading result) and the like to the smart contract SC including the existing request to be matched stored on the blockchain 300 (step S142), and stores the added smart contract SC (step S144).

[0053] Next, each step in the flow of energy trading described above will be described in detail. [Request Generation Process: Steps S100, S110] When each of the user terminals 200-1 and 200-2 generates a request, the trading application 272 causes the display 232 to display an image of the request input to the user terminals 200-1 and 200-2. This image may be provided by the providing unit 160 of the information management device 100. Also, sound corresponding to the image may be output.

[0054] FIG. 5 is a diagram illustrating an example of an image IM10 displayed on the user terminal 200 during the request generation process. The image IM10 shown in FIG. 5 is an image displayed on the user terminal 200-1 during the process of step S100 and on the user terminal 200-2 during the process of step S110. The layout, character font, size, display content, and other display aspects of the image IM10 are not limited to the example shown in FIG. 5 . The same applies to other images described below. The image IM10 shown in FIG. 5 includes, for example, various input fields for accepting a new request from user U1. The image IM10 shown in FIG. 5 includes, for example, a transaction target device information display area AR11, a transaction content display area AR12, and a switch display area AR13.

[0055] The transaction target equipment information display area AR11 displays information about the target equipment for the electricity trading. When trading electricity for a battery B installed in an electric vehicle M, the transaction target equipment information display area AR11 displays an area for accepting the setting of identification information (e.g., a vehicle ID) that identifies the electric vehicle M that is the subject of the electricity trading. Note that the transaction target equipment information display area AR11 may also display an icon IC11, which is a GUI (Graphical User Interface) switch for selecting a vehicle ID. When the user U1 selects the icon IC11, a list of pre-registered vehicle IDs is displayed, and the user U1 can set the vehicle ID by selecting one from the displayed list.

[0056] The transaction content display area AR12 displays input fields for accepting information such as the transaction type (buy or sell), the amount to be traded (amount of electricity), and the transaction price (purchase price or sale price). The transaction content display area AR12 may also include information such as the time slot during which trading is possible, the tokens to be exchanged after the transaction is completed (for example, information on payment tokens (crypto assets) (payment methods) and other procedures), and the type of electricity resource to be traded (whether to trade only green energy). This information may be set using, for example, check boxes or a slide bar as shown in FIG. 5.

[0057] The switch display area AR13 includes icons IC12 and IC13, which are GUI switches. Icon IC12 is a switch (OK switch) for accepting a new request. Icon IC13 is a switch (cancel switch) for not registering a new request.

[0058] When the icon IC12 is selected by the user U1, the user terminal 200-1 transmits the content input by the user U1 via the image IM10 as new request information to the information management device 100. The new request information may include information about the user U1 (for example, a user ID or address information of the user U1), information about the user terminal 200, etc. Furthermore, location information of the user terminal 200 may be transmitted in addition to (or instead of) the new request information.

[0059] [Matching Process and SC Generation Process: Steps S104 to S108, S114] Next, the matching process in steps S104 to S108 and step S114, and the process of generating a smart contract SC based on the matching results will be described. Note that in the following process, the process of generating a smart contract SC in which a request related to energy trading in each user terminal 200 is used as a transaction will be explained using several examples.

[0060] First Embodiment FIG. 6 is a flowchart illustrating an example of a matching process and a smart contract generation process in the first embodiment. In the example of FIG. 6, the acquisition unit 120 determines whether a new request received from a user U has been acquired (step S200). If it is determined that a new request has been acquired, the matching unit 130 performs a matching process between the new request and an existing request included in a smart contract SC stored on the blockchain 300 (step S210). Next, the processing unit 140 determines whether a match has been established by the matching unit 130 (step S220). If it is determined that a match has not been established (failed), the processing unit 140 generates a new smart contract including the new request (step S230). Next, the registration unit 150 stores the generated smart contract on the blockchain (step S240). Note that the new request stored in the smart contract may be hashed.

[0061] Furthermore, if it is determined in the processing of step S220 that a match has been established, the processing unit 140 adds information about the new request to the smart contract stored on the blockchain 300 that includes the existing request with which the match has been established (step S250). This ends the processing of this flowchart. Furthermore, if it is determined in the processing of step S200 that a new request has not been acquired, the processing of this flowchart ends.

[0062] Next, the processing of the first embodiment will be described in more detail. For ease of explanation, the following example will be described assuming that a request is received from user U3 in addition to users U1 and U2. FIG. 7 is a diagram illustrating requests received from each user U in the first embodiment. FIG. 8 is a diagram illustrating smart contracts SC stored on the blockchain 300 in the first embodiment. In the example of FIG. 7, it is assumed that requests related to energy trading input from user terminals 200-1 to 200-3 used by users U1 to U3, respectively, have been acquired, and that no smart contracts SC have been stored on the blockchain 300 prior to the input by users U1 to U3.

[0063] 7, the information management device 100 first acquires a request A (power selling request) for an electricity transaction to sell 10 kWh of electricity from the user terminal 200-1 of the user U1. Note that the request A may include information regarding the trading price (selling price) of the electricity, and may also include other information set using the image IM10.

[0064] The matching unit 130 matches existing requests included in smart contracts SC already stored on the blockchain 300 with request A, which is a new request at this point. For example, the matching unit 130 determines that matching is successful if there is a request (purchase request) among existing requests related to electricity trading that satisfies the condition of wanting to purchase electricity of 10 kWh or less, and determines that matching is unsuccessful if the above condition is not met. Since there is no smart contract SC (purchase request) yet on the blockchain 300, the matching unit 130 determines that matching is unsuccessful. Then, the processing unit 140 creates a new smart contract SC including request A as shown in FIG. 7. Ａ and stores it on the blockchain 300. In the first embodiment, a smart contract SC including the request A is generated. ＡFor example, the smart contract SC includes at least one of the following information: information about the user U who generated the request, the transaction type (power purchase, power sale, etc.), and information about the token to be used (exchanged) after the transaction is completed. Furthermore, the smart contract SC generated by the processing unit 140 stores the information about request A in the form of a hash value. By hashing request A, it is possible to prevent the request information from being leaked or tampered with, thereby further protecting the request information.

[0065] The registration unit 150 registers the generated smart contract SC as shown in FIG. Ａ is stored (registered) on the blockchain 300. At this point, request A becomes an existing request.

[0066] Next, the information management device 100 acquires a request B (purchase request) for an electricity transaction to purchase 20 kWh of electricity from the user terminal 200-3 of the user U3. The matching unit 130 then matches the request B with the smart contract SC Ａ The matching unit 130 matches request A (existing request) included in the request B with request B (new request). Since request A wishes to sell 10 kWh of electricity and request B wishes to buy 20 kWh of electricity, the matching unit 130 determines that the conditions are not met and matching is not successful.

[0067] The processing unit 140 receives the smart contract SC including the request B for which matching was not established. Ｂ The request information in this case may also be hashed. The registration unit 150 generates the generated smart contract SC as shown in FIG. Ｂ is stored on the blockchain 300. At this point, request B becomes an existing request.

[0068] Next, the information management device 100 acquires a request C (purchase request) for an electricity transaction to purchase 10 kWh of electricity from the user terminal 200-2 of the user U2. The matching unit 130 then matches the request C with the smart contract SC already stored on the blockchain 300. Ａ, SC Ｂ The matching unit 130 matches requests A and B (both existing requests) included in each of the requests with request C (a new request). Since the 10 kWh of electricity to sell included in request A matches the 10 kWh of electricity to buy included in request C, the matching unit 130 determines that request A and request C are matched.

[0069] In this case, the processing unit 140 generates a smart contract SC containing the matched request A as shown in FIG. Ａ A process (state update process) is performed to add only the state indicating that a match between request A and request C has been achieved as information about request C. Note that instead of (or in addition to) this process, part of the information about request C may be added. In this case, the added information may be converted into a hash value.

[0070] According to the first embodiment described above, a smart contract SC including a new request C is created on the blockchain. Ｃ or generate a new smart contract SC that includes both Request A and Request C. Ａ＋Ｃ Since no additional data is generated, the increase in the number of smart contracts SC stored on the blockchain 300 (i.e., the amount of data) can be suppressed, and more detailed and accurate information can be stored on the blockchain 300 with less time lag.

[0071] Second Example Next, a second example will be described. The second example differs from the first example in that the request information is stored in a file system 400 other than the blockchain 300, and the smart contract SC is not generated by the processing unit 140, but is generated by a program on the blockchain 300 in response to instructions from the processing unit 140. The following description will mainly focus on the differences.

[0072] FIG. 9 illustrates an example of the specific configuration of the processing unit 140 in the second embodiment. The processing unit 140 includes, for example, a first processing unit 142, an assignment unit 144, and a second processing unit 146. The first processing unit 142 stores information about a new request in a file system 400 outside the blockchain 300 without hashing it. The assignment unit 144 assigns identification information (CID: Content Identifier) ​​to the information about the new request stored in the file system 400. The CID may be a hash value. For example, the assignment unit 144 hashes the information about the new request as an input value and assigns this hash value as the CID for the new request. The CID is used, for example, in the information management device 100, the file system 400, etc., for managing and referencing requests (or data sets DS). If the matching unit 130 fails to match the new request with an existing request, the second processing unit 146 generates a smart contract SC including the new request using a program on the blockchain 300. In addition, when a match is established by the matching unit 130, the second processing unit 146 adds information about the new request to the smart contract SC that includes the existing request of the matching partner.

[0073] Figure 10 is a flowchart showing an example of the matching process and the generation process of the smart contract SC in the second embodiment. The process in Figure 10 differs from the process of steps S200 to S250 shown in Figure 6 in that steps S202 and S204 are added, and step S232 is replaced with step S230. Therefore, the following description will mainly focus on the processes of steps S202 to S204 and S232.

[0074] 10 , if it is determined that a new request has been acquired, the first processing unit 142 stores a dataset (data file) DS including the new request in the file system 400 (step S202). Because the file system 400 is a secure environment managed by the information management device 100, the new request stored in the dataset DS does not need to be hashed. Next, the assigning unit 144 assigns identification information to the new request in the dataset DS (step S204). Therefore, the dataset DS includes CID information. Then, in the matching process of step S210, the matching unit 130 performs a matching process between the existing request and the new request included in the dataset stored in the file system 400.

[0075] If it is determined in the processing of step S220 that matching has not been established (is not established), the second processing unit 146 executes a program on the blockchain 300 to generate a smart contract including the new request (step S232) and stores the smart contract on the blockchain 300 (step S240). Note that the new request included in the smart contract may be converted into a hash value.

[0076] Next, the processing of the second embodiment will be described in more detail. FIG. 11 is a diagram for explaining the requests of each user U and the smart contract SC stored on the blockchain 300 in the second embodiment. In the second embodiment, when a request A of user U1 is acquired, the first processing unit 142 stores a data set DS including the request A in the file system 400 as shown in FIG. Ａ The assigning unit 144 stores the data set DS Ａ An identification information (CID) is assigned to the request A in the request list.

[0077] The matching unit 130 matches the new request A with the existing requests. If it is determined that the matching is not successful, the second processing unit 146 creates a smart contract SC including request A in another smart contract SC (hereinafter referred to as a "creation SC") that is stored in advance on the blockchain 300 and that stores a program for generating a new smart contract SC. Ａ The generation SC executes a program based on the instruction from the second processing unit 146 to generate a smart contract SC corresponding to request A. Ａ is generated and stored on the blockchain 300.

[0078] In the example of FIG. 11, the generation SC generates smart contracts SCs corresponding to requests A and B for which matching was not established. Ａ , SC Ｂ In the second embodiment, the smart contract SC generated by the generating SC is Ａ , SC Ｂ The request includes at least one of the following information: information about the user U who generated the request; the transaction type (power purchase, power sale, etc.); information about the token to be used (exchanged) after the transaction is completed; and information for referencing data (dataset) stored in the file system 400. This information may be converted into a hash value. For example, in the second embodiment, the user terminal 200 queries the information management device 100 about the data set DS using the information for referencing the data stored in the file system 400, and can refer to the contents of the data set DS if permission is obtained from the information management device 100.

[0079] After that, in the example of FIG. 11, when request C is acquired, the first processing unit 142 acquires a data set DS including request C. Ｃ The assigning unit 144 assigns a CID corresponding to the request C to the file system 400. The matching unit 130 then assigns the data set DS Ａ Request A and dataset DS ＢThe second processing unit 146 matches the request B with the new request C and determines that a match is established between the requests A and C. Therefore, the second processing unit 146 matches the smart contract SC Ａ Add information based on the matching results to the

[0080] According to the second embodiment described above, in addition to achieving the same effects as the first embodiment, request information can be stored in a file system (off-chain) 400, which is more secure than the blockchain (on-chain) 300, and matching processing can be performed. Since the request information on the file system 400 is not hashed, matching of the request information can be performed quickly and accurately. Furthermore, according to the second embodiment, by generating a smart contract SC using a program on the blockchain 300, the process by which blocks are generated can be stored on the blockchain 300. Furthermore, it becomes easier for a third party to verify which smart contract SC was generated by which program, ensuring transparency of the transaction process.

[0081] In the second embodiment, the processing unit 140 (second processing unit 146) may generate the smart contract SC directly on the blockchain 300 without using the generation SC, or the processing unit 140 may generate the generation SC. The same applies to the third embodiment described below.

[0082] (Third Example) Next, a third example will be described. The third example differs from the second example in that the above-mentioned request identification information (CID) is stored in the smart contract SC on the blockchain 300, and the matching result is added to the smart contract SC when the user U approves the matching result. The following mainly focuses on the above differences. Note that in the third example, each process may be executed by a processing unit 140 having the same configuration as in the second example.

[0083] Figure 12 is a flowchart showing an example of the matching process and the smart contract SC generation process in the third embodiment. The process in Figure 12 differs from steps S200 to S250 shown in Figure 10 in that steps S234 and S252 are included instead of steps S232 and S250, and steps S260 to S280 are added. Therefore, the following description will mainly focus on steps S234, S252, and S260 to S280.

[0084] 12, if it is determined that a match has not been established, the second processing unit 146 generates a new smart contract SC including the CID (identification information) of the new request using a program (the generation SC program) on the blockchain 300 (step S234). If it is determined that a match has been established, the second processing unit 146 adds the CID of the new request to the smart contract SC including the CID of the existing request with which a match has been established (step S252). The CID stored in the smart contract SC in the processes of steps S234 and S252 may be hashed.

[0085] Next, the providing unit 160 generates information indicating the matching result and provides it to the user terminal 200 that sent the matching request (step S260). Next, the second processing unit 146 determines whether approval from the user who will be conducting the energy trade has been received from the information acquired from the user terminal 200 (step S270). If it is determined that approval has been received, information regarding the matching result is added to the target smart contract SC (step S280). On the other hand, if it is determined that approval has not been received (for example, information indicating refusal has been received), the processing from step S234 onwards is carried out.

[0086] Next, the processing of the third embodiment will be described in more detail. FIG. 13 is a diagram for explaining the requests of each user U and the smart contract SC stored on the blockchain 300 in the third embodiment. In the third embodiment, the first processing unit 142 receives a request A from user U1 and stores a data set DS including the request A in the file system 400. Ａ The assigning unit 144 generates the data set DS Ａ Furthermore, if the matching unit 130 determines that matching with request A is not established, the second processing unit 146 uses the generation SC to generate a smart contract SC including the CID assigned to request A. Ａ In the example of FIG. 13, a smart contract SC containing the CID of request A for which matching was not successful is generated using the generation SC. Ａ and a smart contract SC containing the CID of request B Ｂ The smart contract SC is generated. Ａ , SC Ｂ The CID stored in the smart contract SC may be hashed. Storing the CID in the smart contract SC in this way proves that the request information that forms the basis of the transaction conditions exists outside the blockchain (off-chain), thereby ensuring the validity of the transaction. Furthermore, storing only the CID, which is the hashed value of the request, in the smart contract SC protects the personal information of user U. For example, if user U wishes to refer to the request information corresponding to the CID, he or she can inquire about the request information for the CID from the user terminal 200 to the information management device 100, and can refer to the request information if permission is granted.

[0087] The matching unit 130 also matches the request C with the data set DS of the file system 400. Ａ , D.S. Ｂ and determines that a match is established between requests A and C. At this point, the second processing unit 146 uses the generation SC to generate the smart contract SCＡ The processing unit 140 adds the CID of the request C for which matching is established as information based on the matching result to the smart contract SC Ａ , SC Ｂ Similar to the generation of the smart contract SC, the generation SC is used to generate the smart contract SC. Ａ The program for the generation SC in the third embodiment includes a program that adds the CID of the request for which a match is established to the existing smart contract SC.

[0088] Here, the providing unit 160 generates information (for example, an image) related to the above-mentioned matching result and provides the generated information to the user terminals 200-1 and 200-2. The provided information may include information indicating whether or not to approve the transaction based on the matching result. The second processing unit 146 further determines whether or not to approve the transaction received from the users U1 and U2 by creating a smart contract SC Ａ The above-described process corresponds to the display and reception process of the matching result in steps S122 and S124 shown in FIG.

[0089] 14 is a diagram showing an example of an image IM20 relating to the matching result. The image IM20 shown in FIG. 14 includes, for example, a matching result display area AR21 and a switch display area AR22.

[0090] The matching result display area AR21 displays information about the content of the results that match the conditions of the request. FIG. 14 shows, as an example, a case where there is a plurality of pieces of information (requests) for which matching has been established. When a plurality of matching results are obtained, the respective contents (e.g., transaction price, transaction volume (amount of electricity)) are displayed, and radio buttons (check boxes) or the like are displayed for selecting one of the plurality of matching contents. Users U1 and U2 select one of the plurality of results using the radio buttons in image IM20. Note that, when matching by the matching unit 130 is not established, information indicating that matching has not been established may be displayed in the matching result display area AR21.

[0091] The switching display area AR22 displays an icon IC21, which is a GUI switch for approving a transaction based on the matching result, and an icon IC22 for rejecting (not approving) the transaction. When the user terminals 200-1 and 200-2 accept the selection of the icon IC21 by the user U1, they transmit to the information management device 100 information indicating that the transaction based on the matching result selected in the matching result display area AR21 is approved, and when the user terminals 200-1 and 200-2 accept the selection of the icon IC22, they transmit to the information management device 100 information indicating that the transaction based on the matching result is rejected (processing of steps S126 and S128 in FIG. 4).

[0092] Returning to FIG. 13, if both users U1 and U2 approve the transaction, the processing unit 140 creates a smart contract SC Ａ A matching result dataset is added to the smart contract SCA. Note that the information stored after user U's approval (matching result dataset) includes, for example, contract information necessary for calculating the trading price (e.g., amount of electricity, trading price, value-added rate). The value-added rate may be set based on information acquired by the processing unit 140 from an external source regarding the market situation of electricity trading, or may be set based on the service usage status of user U, or may be arbitrarily set by an administrator of the trading system 1, etc. The matching result dataset added to the smart contract SCA may be hashed.

[0093] In the third embodiment, the matching unit 130 may store all matching results, including successful and unsuccessful matches, performed within the file system 400 as a data set or the like, as shown in FIG. 13 . Furthermore, the matching unit 130 may store in the file system 400 more detailed information than the matching result data set added to the smart contract SC (e.g., in addition to the contract information, request information for successful matches, etc.). This allows for more detailed management of the matching status and reduces the amount of data added to the smart contract SC. Furthermore, the matching result data set added to the smart contract SC does not include information about the user, so the user's personal information can be protected.

[0094] According to the above-described third embodiment, in addition to achieving the same effects as the first embodiment, by not storing request information in the smart contract SC and storing only the CID associated with the request in the smart contract SC, it is possible to prove that the request that is the basis of the transaction conditions exists off-chain (file system 400), thereby ensuring the validity of the transaction. Furthermore, by not storing request information, the amount of data on the blockchain 300 can be further reduced, and information management can be performed more accurately on the file system 400.

[0095] Each of the first to third embodiments described above may be combined with at least a portion of the other embodiments. For example, in the second embodiment, the matching unit 130 may store the matching results performed within the file system 400 in the file system 400, as in the third embodiment.

[0096] [Energy Trading Management Process: Steps S132 to S144] Next, the energy trading management process of steps S132 to S144 shown in FIG. 4 will be described in detail. FIG. 15 is a diagram for explaining the process related to energy trading. In FIG. 15, the charge / discharge CS 500, the information management device 100, and the file system 400 may exchange data using, for example, dedicated agents (user agent programs) provided in the information management device 100 and the charge / discharge CS 500, respectively. Furthermore, data (transactions) exchanged between the devices may be transferred using a method known as a decentralized identity (DID). DID is a transfer framework that enables data exchange between devices by replacing identification information that could identify personal information, such as a user name, with a self-owned, independent ID that is not managed by a third party, while also protecting privacy and ensuring the security of transactions. Data transfer using DID uses, for example, DID-Comm, a P2P communication protocol. By using DID-Comm, distributed data linkage becomes possible while reducing the dependency on the device that manages the entire system. Furthermore, by performing data transfer using DID-Comm, it is possible to verify the certification of the qualification information (user information) of the transmitted data, for example. Note that the communication protocol used in the embodiment does not have to be limited to DID-Comm.

[0097] 15 , first, the charge / discharge CS 500 registers information about the DID used in transferring information about the current energy transaction in the file system 400 ((1) in FIG. 15 ). The information management device 100 also registers information about the DID and DID-Comm used by the charge / discharge CS 500 in the file system 400 ((2) in FIG. 15 ). When the energy transaction is approved by users U1 and U2, the information management device 100 generates charge / discharge schedule information and the like based on the available times for charge / discharge transactions (start time, end time) included in requests A and C from users U1 and U2, and transmits the generated schedule information and information about users U1 and U2 to the charge / discharge CS 500 ((3) in FIG. 15 ).

[0098] The charge / discharge CS 500 generates information (e.g., an image) related to the electricity trading status (contract status) based on the schedule information and provides it to the user terminals 200-1 and 200-2 ((4) in FIG. 15). Note that the information may be provided by the providing unit 160 of the information management device 100 instead of the charge / discharge CS 500.

[0099] FIG. 16 is a diagram showing an example of an image IM30 relating to the status of an electricity transaction. The image IM30 shown in FIG. 16 is an example of an image displayed on the user terminal 200-2 that has transmitted a purchase request from the power buyer (the buyer). In the example of FIG. 16, the image IM30 includes, for example, a transaction status display area AR31, a transaction summary display area AR32, and a switch display area AR33. The transaction status display area AR31 displays information indicating the power purchase status (or power sales status) (e.g., remaining charge amount, remaining discharge amount), identification information (charging / discharging equipment ID) and location (installation location) of the charging / discharging equipment 520 connected to the electric vehicle M. The transaction status display area AR31 may also display information indicating that an electricity transaction is in progress or has been completed. The transaction summary display area AR32 displays information relating to the electricity transaction, such as the start time, end time, total energy, and total cost of charging (or discharging).

[0100] The switch display area AR33 includes icons IC31 and IC32, which are GUI switches. Icon IC31 is a switch for receiving an instruction to display an electronic receipt after charging or discharging is completed. Icon IC32 is a switch for ending the display of image IM30. When icon IC31 is selected by user U2, the transaction application 272 displays an image showing a receipt for the current energy transaction on the display 232, and when icon IC32 is selected, the transaction application 272 ends the display of image IM30.

[0101] Based on the location information displayed in the transaction status display area AR31, the users U1 and U2 move their respective electric vehicles M1 and M2 to the charging / discharging facility 520 managed by the charging / discharging CS 500, and connect the electric vehicles M1 and M2 to the charging / discharging facility 520 corresponding to the charging / discharging facility ID. The charging / discharging facility ID and location information displayed in the transaction status display area AR31 are, for example, the ID and location information of the charging / discharging facility 520 closest to the user terminal 200, extracted by the charging / discharging CS 500 or the information management device 100 based on the location information of the user terminal 200. In the example of FIG. 15 , the electric vehicle M1 of user U1 is connected to charging / discharging facility 520-1, and the electric vehicle M2 of user U2 is connected to charging / discharging facility 520-2.

[0102] The charging / discharging facilities 520-1 and 520-2 connect to the electric vehicles M1 and M2 to acquire identification information (vehicle IDs) of the electric vehicles M1 and M2 and output the acquired vehicle IDs to the charging / discharging CS 500. If the vehicle IDs are those permitted for use (scheduled), the charging / discharging CS 500 starts a charging / discharging session (electricity trading through charging / discharging) and transmits information related to the charging / discharging (e.g., charging / discharging information, charging / discharging results, and session end) to the information management device 100 ((5) in FIG. 15 ). The information management device 100 stores the electricity trading status and the like in the file system 400 based on the information related to the charging / discharging ((6) in FIG. 15 ), and after the electricity trading is completed (after charging / discharging is completed or the session is ended), adds the electricity trading results to the smart contract SC stored in the blockchain 300 ((7) in FIG. 15 ).

[0103] 17 is a diagram for explaining the management of the transaction status during a charge / discharge session. In the example of FIG. 17, before the charge / discharge session, a smart contract SC Ａis stored on the blockchain 300. The example in FIG. 17 also shows the management contents of the transaction status during charging / discharging, when charging / discharging is completed, and at the end of the session. In managing the transaction status during charging / discharging, the charging / discharging CS 500 transmits information related to charging / discharging (e.g., charging / discharging information, charging / discharging results, and end of the session) to the information management device 100. The information management device 100 performs transaction management during the charging / discharging session based on the transmitted information.

[0104] 18 is a flowchart showing an example of processing executed by the information management device 100 during a charging / discharging session. The processing in FIG. 18 may be executed repeatedly at a predetermined cycle or at a predetermined timing during the charging / discharging session. In the example in FIG. 18, the acquisition unit 120 of the information management device 100 determines whether or not information related to charging / discharging has been acquired from the charging / discharging CS 500 (or charging / discharging equipment 520-1, 520-2) (step S300).

[0105] When it is determined that information regarding charging and discharging has been acquired, the acquisition unit 120 determines whether the acquired information is charging information (step S310). When it is determined that the information is charging information, the processing unit 140 (first processing unit 142) generates a dataset DS1 corresponding to the charging information as shown in FIG. 13 and stores the dataset DS1 in the file system 400 (step S320). The dataset DS1 includes, for example, information regarding a charging and discharging facility ID, charging and discharging time (timestamp), user information, a vehicle ID, and the amount of discharged power (or charged power). The dataset DS1 may also include information such as identification information (battery ID) of battery B (device to be charged and discharged), the amount of power of battery B, and the charging rate (SOC; State Of Charge).

[0106] Furthermore, in the processing of step S320, if the data set DS1 already exists in the file system 400, the changed portion of the data set DS1 may be updated, or the stored previous data set DS1 may be deleted and a new data set DS1 may be stored in the file system 400. Furthermore, the data set DS1 may include information on both the charge side and the discharge side, and each may be stored as a separate data set.

[0107] Furthermore, if it is determined in the processing of step S310 that the information is not charging information, the acquisition unit 120 determines whether the acquired information regarding charging / discharging is a charging / discharging result to be transmitted when charging is completed (step S330). If it is determined that the information is a charging / discharging result, the processing unit 140 generates a data set DS2 indicating the charging / discharging result as shown in FIG. 17 and stores the generated data set DS2 in the file system 400 (step S340). In addition to the same information as the data set DS1, the data set DS2 includes information indicating that the transaction is complete and information such as the total amount charged (or discharged) by the session.

[0108] The processing unit 140 also calculates the final transaction amount based on the data set DS1 of charge / discharge information, the data set DS2 of charge / discharge results, and contract information (e.g., transaction price, value-added rate) included in the matching result data set, and generates a data set DS3 including transaction information such as the calculated transaction amount and transaction volume (step S350). The transaction information may include, for example, information indicating whether the transaction has been completed. In addition to the transaction information, the data set DS3 also stores session information (information obtained during communication). The session information includes, for example, at least one of identification information (charge / discharge ID) for identifying the charge / discharge equipment 520, identification information (CID) of the request that is the basis of the transaction, identification information (user ID) of the user who is the power consumer (supplier), the start time of charge / discharge, the end time of charge / discharge, the battery power amount at the start of the session, the battery power amount at the end of the session, the battery charging rate at the start of the session, the battery charging rate at the end of the session, and the total charge / discharge capacity for the session.

[0109] Furthermore, if it is determined in the processing of step S330 that the information on discharging is not a charge / discharge result, the acquisition unit 120 determines whether the acquired information on charging / discharging is session termination information (step S360). If it is determined that the information is session termination information, the second processing unit 146 acquires the smart contract SC Ａ(Step S370), and stores the data set (for example, at least a part of the contents of the data set DS3) corresponding to the charging session result (power trading result) on the blockchain 300 (Step S380). Ａ The session information included in the data set (energy trading results) to be added to the smart contract SC is hashed, and the transaction information is not hashed. Ａ In addition, the second processing unit 146 adds information (status information) that proves that charging and discharging has been completed to the smart contract SC Ａ This completes the process of the flowchart shown in Fig. 18. Furthermore, if it is determined in the process of step S300 that information regarding charging and discharging has not been acquired, the process of this flowchart completes.

[0110] In this way, session information including user identification information is hashed and stored on the blockchain 300 without revealing the contents of the data, thereby protecting the privacy information of user U. Furthermore, by storing information necessary for calculating the final settlement amount, such as the transaction amount and transaction volume, and information for confirming the completion of the transaction (i.e., information that is not privacy information) on the blockchain 300 without hashing it, the final settlement amount can be calculated correctly and quickly. Note that the smart contract SC Ａ Since the CID and matching result data set corresponding to request A are included in the request log, request information and the like can be obtained from the file system 400 or the like using this information.

[0111] [Modification] The information management device 100 in the trading system 1 of the embodiment may be one of the nodes constituting the blockchain 300 (blockchain network) or one of the nodes constituting the file system 400 (IPFS network). In other words, the information management device 100 may be configured integrally with the blockchain 300 or may be configured integrally with the file system 400. Furthermore, the information management device 100 may be configured integrally with the charge / discharge CS 500. Furthermore, some of the functions included in the information management device 100 (for example, the functions of the matching unit 130, the registration unit 150, or the provision unit 160) may be executed by a program (dedicated smart contract) pre-stored in the blockchain 300.

[0112] In addition, in the embodiment, a transaction regarding electricity for an electric vehicle M (more specifically, battery B) owned by a user U is described, but in addition to (or instead of) electricity from the electric vehicle M, electricity may also be obtained from solar power generation, wind power generation, hydroelectric power generation, thermal power generation, geothermal power generation, etc.

[0113] According to the embodiment described above, the information management device 100 mediates transactions between users and manages transaction results by storing smart contracts related to the transactions on the blockchain 300, and is equipped with an acquisition unit 120 that acquires requests related to purchases or sales received from users, a matching unit 130 that matches a new request newly acquired by the acquisition unit 120 with an existing request included in a smart contract already stored on the blockchain 300, and a processing unit 140 that generates a smart contract including the new request on the blockchain 300 if the matching is not established, and adds information about the new request to the smart contract including the existing request with which the matching is established if the matching is established, thereby making it possible to manage information more accurately while reducing the amount of information stored on the blockchain 300.

[0114] More specifically, according to the embodiment, a new smart contract is generated only when a match is not made, and when a match is made, the status of the existing smart contract of the matching partner is changed, thereby reducing the number of smart contracts. Furthermore, according to the embodiment, it is possible to reduce the data capacity and operation costs (= transaction costs) on the blockchain, and to prevent a decrease in processing speed in the trading system 1.

[0115] Furthermore, according to the embodiment, the request information stored in the blockchain 300 is hashed, thereby enabling better protection of the request information. Furthermore, according to the embodiment, by generating a smart contract using a program on the blockchain, the process by which a transaction is generated can be recorded on the blockchain, ensuring transparency of the transaction process. Furthermore, according to the embodiment, the time lag between the actual transaction status and the information managed by the blockchain 300 or the file system 400 can be reduced, enabling more accurate management of each piece of information.

[0116] The above-described embodiment can be expressed as follows: An information management device comprising: a storage medium storing computer-readable instructions for an information management device that mediates transactions between users and manages transaction results by storing smart contracts related to the transactions on a blockchain; and a processor connected to the storage medium, wherein the processor executes the computer-readable instructions to: acquire purchase or sale requests received from users, match the newly acquired new request with existing requests included in smart contracts already stored on the blockchain, if the match is not established, create a smart contract on the blockchain including the new request, and if the match is established, add information of the new request to the smart contract including the existing request with which the match was established.

[0117] The above describes the form for carrying out the present invention using an embodiment, but the present invention is not limited to such an embodiment, and various modifications and substitutions can be made within the scope that does not deviate from the gist of the present invention.

[0118] 1...Trading system, 100...Information management device, 110...Communication unit, 120...Acquisition unit, 130...Matching unit, 140...Processing unit, 142...First processing unit, 144...Assignment unit, 146...Second processing unit, 150...Registration unit, 160...Provision unit, 170...Device side memory unit, 200...User terminal, 210...Terminal side communication unit, 220...Input unit, 230...Output unit, 232...Display, 234...Speaker, 240...Location information acquisition unit, 250...Control unit, 260...Application execution unit, 270...Terminal side memory unit, 300...Blockchain, 400...File system, 500...Charging / discharging CS, 520...Charging / discharging equipment, M...Electric vehicle

Claims

1. An information management device that mediates transactions between users and manages transaction results by storing smart contracts related to the transactions on a blockchain, comprising: an acquisition unit that acquires purchase or sale requests received from users; a matching unit that matches a new request newly acquired by the acquisition unit with an existing request included in a smart contract already stored on the blockchain; and a processing unit that generates a smart contract including the new request on the blockchain if the matching is not established, and adds information of the new request to the smart contract including the existing request with which the matching is established if the matching is established.

2. The information management device according to claim 1, wherein the processing unit generates a smart contract including information of the new request converted into a hash value.

3. The information management device according to claim 1, wherein the processing unit generates a smart contract including the new request using a program previously stored on the blockchain.

4. The information management device according to claim 3, wherein the blockchain is Ethereum.

5. The information management device of claim 1, wherein the transaction includes an electricity transaction, the request includes a request for purchasing or selling electricity, and the processing unit adds an electricity transaction result for the request to the smart contract.

6. The information management device of claim 1, wherein the smart contract includes at least one of information regarding the user, a transaction type, information regarding tokens to be exchanged after the transaction is completed, and information for referencing information regarding the request recorded in a memory unit outside the blockchain.

7. The information management device of claim 1, wherein the processing unit hashes session information in transactions between the users and stores it on the blockchain, and stores transaction information including the transaction amount and transaction volume on the blockchain without hashing it.

8. An information management method in which an information management device that mediates transactions between users and manages transaction results by storing smart contracts related to the transactions on a blockchain acquires purchase or sale requests received from users, matches the newly acquired new request with existing requests included in smart contracts already stored on the blockchain, generates a smart contract on the blockchain including the new request if the match is not established, and adds information of the new request to the smart contract including the existing request with which the match was established if the match is established.

9. A program that causes an information management device, which mediates transactions between users and manages transaction results by storing smart contracts related to the transactions on a blockchain, to acquire purchase or sale requests received from users, match the newly acquired new requests with existing requests included in smart contracts already stored on the blockchain, generate a smart contract on the blockchain including the new request if the matching is not established, and add information of the new request to the smart contract including the existing request with which the matching was established if the matching was established.

Images