Information management device, information management method, and program

Abstract

An information management device according to an embodiment of the present invention intermediates power transactions between users and manages transaction results by storing information relating to the power transactions in a block chain, the information management device comprising a processing unit, and a processing unit that hash-values session information relating to a result of a charge / discharge session including information of a user who performs the power transaction and stores the session information in the block chain, and that stores transaction information including a transaction amount and a transaction volume of the power in the block chain without hash-values.

Description

TECHNICAL FIELD

[0001] The present application relates to an information management apparatus, an information management method, and a program. BACKGROUND

[0002] In recent years, a technique of recording information using a blockchain is being studied. In association with this, a technique is known in which an attribute field generated based on measurement data, prediction data of a power machine, and the like is hash-processed, and transaction data of a power transaction is recorded using a blockchain (for example, refer to Patent Literature 1).

[0003] PRIOR ART DOCUMENTS

[0004] PATENT LITERATURE

[0005] Patent Literature 1: Japanese Patent Application Publication No. 2021-34826 SUMMARY

[0006] PROBLEMS TO BE SOLVED BY THE INVENTION

[0007] However, when the attribute field of the information that becomes the transaction data of the power transaction is itself hash-processed as in the conventional technique, time is taken in a case where processing of calculating the final settlement amount of the power transaction and the like is performed, and thus there is a problem that proper information management cannot be performed at times.

[0008] One object of the present application is to provide an information management apparatus, an information management method, and a program that enable more proper information management by storing proper information on a blockchain, in order to solve the above problem.

[0009] SOLUTION TO THE PROBLEM

[0010] The information management apparatus, the information management method, and the program according to the present application adopt the following structure.

[0011] (1) An information management apparatus according to an aspect of the present application mediates a power transaction between users and manages a transaction result by storing information related to the power transaction on a blockchain, wherein the information management apparatus includes a processing unit that hash-processes session information related to a session result of charging and discharging, including information of a user who performs the power transaction, and stores the session information on the blockchain, and stores transaction information, including a transaction amount and a transaction volume of the power, on the blockchain without hash-processing.

[0012] (2) In the aspect of the above (1), the blockchain is Ethereum.

[0013] (3): The scheme of the above (1) is based on the fact that the session information includes at least one of identification information identifying a charge / discharge device that performs charge / discharge of the electric power, identification information of a request that becomes a source of the electric power transaction, identification information of the user, a charge / discharge start time, a charge / discharge end time, a storage battery power amount at a session start, a storage battery power amount at a session end, a storage battery charge rate at a session start, a storage battery charge rate at a session end, and a total charge / discharge power amount under a session.

[0014] (4): The scheme of the above (1) is based on the fact that the information management device further has a matching section that performs matching between a new request related to purchase or sale of electric power received from the user and an existing request included in a smart contract already stored on the blockchain, and the processing section appends information of the new request to the smart contract including the existing request for which the matching is established, and appends the session information and the transaction information to the smart contract after the electric power transaction ends.

[0015] (5): The scheme of the above (1) is based on the fact that the processing section stores charge / discharge information in the electric power transaction in a storage section existing outside the blockchain.

[0016] (6): An information management method according to an aspect of the present application performs processing by an information management device that mediates electric power transactions between users and manages transaction results by storing information related to the electric power transactions on a blockchain, wherein the information management method causes the information management device to perform processing of: hashing and storing on the blockchain session information related to a session result of charge / discharge, including information of a user who performs the electric power transaction; and storing transaction information, including a transaction amount and a transaction volume of the electric power, on the blockchain without hashing.

[0017] (7): A program according to an aspect of the present application causes an information management device that mediates electric power transactions between users and manages transaction results by storing information related to the electric power transactions on a blockchain to perform processing of: hashing and storing on the blockchain session information related to a session result of charge / discharge, including information of a user who performs the electric power transaction; and storing transaction information, including a transaction amount and a transaction volume of the electric power, on the blockchain without hashing.

[0018] Effects of the Invention

[0019] According to the above-described (1) to (7), more appropriate information management can be performed by storing appropriate information on the blockchain. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 is a configuration diagram of a transaction system 1 of an information management apparatus using the embodiment.

[0021] Figure 2 is a configuration diagram of an information management apparatus 100 of the embodiment.

[0022] Figure 3 is a configuration diagram of a user terminal 200 of the embodiment.

[0023] Figure 4 is a sequence diagram for explaining a series of processes of the power transaction in the embodiment.

[0024] Figure 5 is a diagram showing an example of an image IM10 displayed on the user terminal 200 in the request generation process.

[0025] Figure 6 is a flowchart showing an example of the matching process and the generation process of the smart contract in the first embodiment.

[0026] Figure 7 is a diagram for explaining the requests accepted from the users U in the first embodiment.

[0027] Figure 8 is a diagram for explaining the smart contract SC stored on the blockchain 300 in the first embodiment.

[0028] Figure 9 is a diagram showing an example of a specific configuration of the processing section 140 in the second embodiment.

[0029] 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.

[0030] Figure 11 is a diagram for explaining the requests of the users U and the smart contract SC stored on the blockchain 300 in the second embodiment.

[0031] Figure 12 is a flowchart showing an example of the matching process and the generation process of the smart contract SC in the third embodiment.

[0032] Figure 13 is a diagram for explaining the requests of the users U and the smart contract SC stored on the blockchain 300 in the third embodiment.

[0033] Figure 14 is a diagram showing an example of an image IM20 related to a matching result.

[0034] Figure 15 is a diagram for explaining a process related to a power transaction.

[0035] Figure 16 is a diagram showing an example of an image IM30 related to a power transaction status.

[0036] Figure 17 is a diagram for explaining management of a transaction status in a charge / discharge session.

[0037] Figure 18 is a flowchart showing an example of a process executed by the information management apparatus 100 in a charge / discharge session. DETAILED DESCRIPTION

[0038] Hereinafter, an embodiment of the information management apparatus, the information management method, and the program of the present application will be described with reference to the drawings. Note that hereinafter, an example in which the information management apparatus is applied to a transaction system (interpersonal transaction system) in which transactions are made among users will be described. In addition, hereinafter, a power transaction will be described as an example of a transaction, but a credit transaction or the like, a transaction of other goods or services can be used instead of (or on the basis of) the power transaction.

[0039] [Overall Structure]

[0040] Figure 1 is a diagram showing the structure of a transaction system 1 of the information management apparatus using the embodiment. The transaction system 1 has, for example, an information management apparatus 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 device 520. The information management apparatus 100, the user terminals 200, the blockchain 300, and the charge / discharge CS 500 can communicate with each other via a network NW or the like, for example. The network NW includes, for example, a cellular network, a Wi-Fi network, Bluetooth (registered trademark), the Internet, a WAN (Wide Area Network), a LAN (Local Area Network), a public line, a provider apparatus, a dedicated line, a wireless base station, and the like. The file system 400 is an example of a "storage unit".

[0041] The information management apparatus 100 can be, for example, a server apparatus, a PC (Personal Computer), or a cloud server configured by cloud computing constituted by one or more information processing apparatuses. The information management apparatus 100 can also have a function as an edge server that processes data stored on the blockchain 300 or the file system 400. The information management apparatus 100 mediates inter-personal transactions between users. For example, the information management apparatus 100 generates information related to power transactions (for example, a smart contract SC or the like) stored on the blockchain 300 or generates information related to power transactions (for example, a data set DS) stored on the file system 400.

[0042] The user terminal 200 is an apparatus used by a user U (a demander), such as a smartphone, a tablet terminal, a PC, or the like. The user terminal 200 accepts a request related to a transaction (for example, a purchase request, a power selling request) input by the user U and transmits the accepted request to the information management apparatus 100. The user terminal 200 also receives information related to a power transaction from the information management apparatus 100 and provides the information to the user U through image display or sound output. Figure 1 In the example, a transaction related to power of a storage battery B mounted on an electric vehicle M owned by the user U is performed. The electric vehicle M is, for example, a BEV (Battery Electric Vehicle) that travels by driving an electric motor (electric motor) using power supplied from the storage battery B. Alternatively, the electric vehicle can be a PHV (Plug-in Hybrid Vehicle) or a PHEV (Plug-in Hybrid Electric Vehicle) that has an external charging function for a hybrid vehicle. Note that the electric vehicle M includes, for example, not only a four-wheeled vehicle but also a two-wheeled vehicle of a straddle type, a three-wheeled vehicle (a vehicle having two front wheels and one rear wheel), an auxiliary bicycle, an electric scooter, and the like that travel by driving an electric motor using power supplied from a storage battery.

[0043] The blockchain 300 is a data storage section (database) that manages information related to transactions in units called blocks, and links and makes the chronological relationship (sequentiality) of the information explicit. The blockchain 300 can also be a blockchain network constituted by a plurality of devices (nodes) that can access each other. The blockchain 300 is, for example, Ethereum. Ethereum is a distributed application platform that can manage programs and / or their actions on the blockchain 300 as blocks of a smart contract SC. In an embodiment, by using Ethereum, which is non-tamperable and has high reliability among public blockchains, the security of transactions can be more ensured.

[0044] In the smart contract SC, data such as request information related to power transactions, power transaction information, and the like is saved as transaction data (transaction). In the transaction data, in addition to the above information, software (computer program) that is automatically executed when a prescribed condition is satisfied can also be included. In addition, the smart contract SC includes a hash value generated based on the previous (immediately preceding) block (transaction data). In the case of newly adding data to the smart contract SC, for example, a new block including the hash value of the previous block, the saved data (for example, transaction data), and a random number (Nonce Value) is hashed (for example, the above block is input to a hash function to calculate a hash value), and the calculated hash value and the block are saved, whereby data can be linked to past blocks and saved in the smart contract SC.

[0045] The process of generating and storing (saving) the smart contract SC on the blockchain 300 can be performed by the nodes connected to the blockchain 300 and the information management device 100. In addition, in the blockchain 300, a plurality of terminals can save the smart contract SC and check against each other, and the like. In the following description, the blockchain 300 is sometimes referred to as "on-chain".

[0046] The file system 400 is, for example, a distributed file system of a P2P (Peer to Peer) method based on IPFS (Inter Planetary File System). The file system 400 can also be an IPFS network constituted by a plurality of devices (nodes) that can access each other. The file system 400 saves a data set (electronic data) DS containing information related to power transactions. The file system 400 is connected to the information management device 100, and the saved data set DS is managed by the information management device 100. The data set DS becomes a secure environment in a manner that the user terminal 200 or the like cannot directly refer to via the network NW. Therefore, the data stored in the file system 400 can also not be hashed. In the following description, the file system 400 is sometimes referred to as "off-chain" or "backend".

[0047] The charge-discharge CS 500 manages charging or discharging of the battery B of the electric vehicle M connected to the charge-discharge device 520. The charge-discharge device 520 performs charging by supplying electric power to the battery B of the electric vehicle M connected thereto, or supplies electric power discharged from the battery B to the outside. The charge-discharge CS 500 manages position information of a plurality of charge-discharge devices 520 provided at respective sites, a charge-discharge schedule of the electric vehicle M, and the like. In addition, the charge-discharge CS 500 can perform control related to charging and discharging based on control information from the information management apparatus 100, and can transmit a charge-discharge result to the information management apparatus 100. Next, the structure of the information management apparatus 100 and the user terminal 200 will be described in detail.

[0048] [Information Management Apparatus]

[0049] Figure 2 is a block diagram of the information management apparatus 100 according to the embodiment. The information management apparatus 100 includes, for example, a communication section 110, an acquisition section 120, a matching section 130, a processing section 140, a registration section 150, a provision section 160, and an apparatus-side storage section 170. The acquisition section 120, the matching section 130, the processing section 140, the registration section 150, and the provision section 160 are implemented by, for example, a hardware processor such as a CPU (Central Processing Unit) executing a program (software). In addition, a part or all of these components can be implemented by hardware (including circuitry) such as an LSI (Large Scale Integration), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), a GPU (Graphics Processing Unit), or can be implemented by a combination of software and hardware. The program can be stored in advance in a storage device (a storage device including a non-transitory storage medium) such as an HDD (Hard Disk Drive), a flash memory, or the like included in the information management apparatus 100, or can be stored in a removable storage medium (a non-transitory storage medium) such as a DVD, a CD-ROM, or the like, and installed in the HDD, the flash memory included in the information management apparatus 100 by mounting the storage medium in a drive device included in the information management apparatus 100.

[0050] The device-side storage section 170 can be implemented by the various storage devices described above, or an SSD (Solid State Drive), an EEPROM (Electrically Erasable Programmable Read Only Memory), a ROM (Read Only Memory), or a RAM (Random Access Memory), and the like. The device-side storage section 170 stores, for example, a user information DB (Database) 172, processing results of the information management device 100, programs, and other various information. In the user information DB 172, for example, a correspondence relationship is established between information related to the user U who uses the transaction system 1 (for example, a user ID, address information of the user U), information related to the user terminal 200 used by the user U (for example, a terminal ID), and information related to the electric vehicle M used by the user U (for example, a vehicle ID). The terminal ID, the vehicle ID, and the like can also be MAC (Media Access Control) addresses assigned to each device. In the user information DB 172, there can be one or more user terminals 200 corresponding to each user U, and there can be one or more electric vehicles M corresponding to each user U.

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

[0052] The acquisition section 120 acquires information related to the user U who uses the service in the transaction system 1 based on information received by the communication section 110. In addition, the acquisition section 120 acquires a request related to purchase or sale from the user U, or acquires information related to the status of charge / discharge of electric power (electric power transaction) or the transaction result from the charge / discharge CS 500.

[0053] The matching section 130 performs matching between a new request (acceptance request) newly acquired by the acquisition section 120 and an existing request stored in the smart contract SC already stored on the blockchain 300 before generation of the smart contract SC stored on the blockchain 300.

[0054] The processing section 140 generates the smart contract SC including the new request in a case where it is not established that the matching between the new request and the existing request is made by the matching section 130. In addition, the processing section 140 appends information related to the new request to the smart contract SC including the existing request in which the matching is established in a case where the matching is established. Note that, in the embodiment, the “appending” can also include that a part of the information in the smart contract SC is changed, edited, deleted, or updated. Details of the function of the processing section 140 will be described later.

[0055] The registration section 150 stores (registers) the smart contract SC generated by the processing section 140 on the blockchain 300. Note that the processing section 140 can also generate the smart contract SC on the blockchain 300 without going through the registration section 150.

[0056] In addition, the registration section 150 can also manage the registration of the user U who uses the service provided by the transaction system 1. In this case, the registration section 150 performs new registration of the user U and registers new user information in the user information DB 172. In addition, the registration section 150 performs control or the like that compares the identification information of the user U, the user terminal 200, which accesses in order to use the service, with the identification information registered in the user information DB 172, and permits the use of the service in a case where the matching identification information is registered, and denies the use of the service in a case where the identification information is not registered.

[0057] The providing section 160 provides various information to the user terminal 200, the charge-discharge CS 500. For example, the providing section 160 generates information (image, sound) related to the matching result based on the matching section 130, and provides the generated information to the user terminal 200. In addition, the providing section 160 provides information related to the electric vehicle M that performs the charge-discharge, the user U to the charge-discharge CS 500 in a case where it is established that the matching is made by the matching section 130.

[0058] [User Terminal]

[0059] Figure 3Fig. 1 is a block diagram of a user terminal 200 according to an embodiment. The user terminal 200 includes, for example, a terminal-side communication section 210, an input section 220, an output section 230, a position information acquisition section 240, a control section 250, an application execution section 260, and a terminal-side storage section 270. The position information acquisition section 240, the control section 250, and the application execution section 260 are each implemented, for example, by a hardware processor such as a CPU executing a program (software). In addition, some or all of these components can be implemented by hardware (including circuitry) such as an LSI, an ASIC, an FPGA, a GPU, or the like, or by a combination of software and hardware. The program can be stored in advance in a storage device (a storage device including a non-transitory storage medium) such as an HDD, a flash memory, or the like included in the user terminal 200, or in a removable storage medium (a non-transitory storage medium) such as a DVD, a CD-ROM, or the like, and installed in the user terminal 200 by mounting the storage medium in a drive device included in the user terminal 200.

[0060] The terminal-side storage section 270 can be implemented by various storage devices described above, or an SSD, an EEPROM, a ROM, a RAM, or the like. In the terminal-side storage section 270, for example, a transaction application 272, a processing result of the user terminal 200, a program, other various information, or the like is stored.

[0061] The terminal-side communication section 210 communicates with the information management device 100, other external devices, or the like via a network NW, for example. In addition, the terminal-side communication section 210 can communicate with an electric vehicle M used by the user U through close proximity communication.

[0062] The input section 220 accepts an input of the user U based on an operation of various keys, buttons, or the like, for example. The input section 220 can also include a microphone and accept an input of a voice of the user U, for example.

[0063] The output section 230 includes, for example, a display 232 and a speaker 234. The display 232 is, for example, an LCD (Liquid Crystal Display), an organic EL (Electro Luminescence) display, or the like. The output section 230 displays various images on the display 232 or causes sound to be output from the speaker 234 in accordance with a control of the control section 250 or the application execution section 260. In addition, the display 232 can also function as the input section 220 as a touch panel, for example.

[0064] The position information acquisition section 240 acquires position information (for example, latitude and longitude information) of the user terminal 200 through a built-in GPS (Global Positioning System) device.

[0065] The control section 250 controls the entire user terminal 200. The control section 250 causes the terminal-side storage section 270 to store information accepted by the input section 220, or transmits information accepted by the input section 220 to the information management apparatus 100 via the terminal-side communication section 210. In addition, the control section 250 can cause information such as images, sounds, and the like acquired from the information management apparatus 100 via the terminal-side communication section 210 to be output from the output section 230, or can generate images, sounds, and the like based on information acquired from the information management apparatus 100 and cause them to be output from the output section 230.

[0066] The application execution section 260 is realized by executing a transaction application 272 stored in the terminal-side storage section 270. The transaction application 272 is downloaded from an external apparatus via the network NW and installed in the user terminal 200, for example. The transaction application 272 transmits information (request information) input by the input section 220, and position information acquired by the position information acquisition section 240, identification information of the user terminal 200, user information, and the like to the information management apparatus 100, or acquires information related to a request result and the like, information related to a power transaction, and causes the output section 230 to output the acquired information.

[0067] [Flow of power transaction]

[0068] Next, the flow of a power transaction performed by the transaction system 1 of the embodiment will be described in detail. Figure 4 is a sequence diagram for explaining a series of flows of a power transaction in the embodiment. In Figure 4 , as an example, processing in the user terminal 200-1 used by the user U1, the user terminal 200-2 used by the user U2, the information management apparatus 100, the blockchain 300, and the charge and discharge CS 500 is shown. The users U1 and U2 are both users who are permitted to use the services provided by the transaction system 1 (users whose use of the services is permitted by the registration section 150). In the following, an example in which a power accommodation transaction is performed between the storage battery B1 mounted on the electric vehicle M1 used by the user U1 and the storage battery B2 mounted on the electric vehicle M2 used by the user U2 will be described.

[0069] In the example of Figure 4 , the transaction application 272 of the user terminal 200-1 generates a request related to a power transaction based on information input by the user U1 (step S100), and transmits the generated request to the information management apparatus 100 (step S102).

[0070] The matching section 130 of the information management apparatus 100 receives the request transmitted from the user terminal 200-1, and performs matching between the received request (new request) and other requests (existing requests) included in the smart contract SC already stored on the blockchain 300 based on the received request (new request) (step S104). It is assumed that in the process of step S104, matching does not hold (there is no existing request that matches the conditions of the new request). In this case, the processing section 140 of the information management apparatus 100 generates a smart contract SC including the new request with respect to the blockchain 300 and transmits it to the blockchain 300 (step S106), and stores the smart contract (SC) on the blockchain 300 (step S108).

[0071] Next, the user U2 uses the user terminal 200-2 to start the transaction application 272, and inputs a request related to the power transaction as with the user U1. The user terminal 200-2 generates a request based on the input information (step S110), and transmits the generated request information to the information management apparatus 100 (step S112).

[0072] The matching section 130 acquires the request (new request) transmitted from the user terminal 200-2, and performs matching with the existing requests by referring to the smart contract SC stored on the blockchain 300 (step S114). Hereinafter, it is assumed that matching holds in the respective requests of the user U1 and the user U2, and the description will be continued. The providing section 160 of the information management apparatus 100 generates information (for example, an image) related to the result of matching (step S116), and transmits it to the user terminals 200-1, 200-2 (steps S118, S120).

[0073] The user terminals 200-1, 200-2 respectively display the information related to the matching result transmitted from the information management apparatus 100, and accept the instruction information and the like from the users U1, U2 (steps S122, S124). As the information from the users U1, U2, it can be information to approve or reject the power transaction based on the matching result, or it can be content to select one of the plurality of objects that match the conditions. The user terminals 200-1, 200-2 respectively transmit the information obtained from the users U1, U2 to the information management apparatus 100 (steps S126, S128).

[0074] The information management apparatus 100 acquires information from the user terminals 200-1, 200-2, and outputs information related to the power transaction (for example, information related to the users U1, U2, the electric vehicles M1, M2 that are involved in the power transaction) to the charge / discharge CS 500 in the case where the matching is permitted (step S130). The charge / discharge CS 500 performs power transaction management based on the information acquired from the information management apparatus 100 (step S132). Specifically, the charge / discharge apparatus 520 to which the object electric vehicle M is connected is set, and the information such as the position information, the use time (schedule) of the set charge / discharge apparatus 520 is transmitted to the user terminals 200-1, 200-2 (steps S134, S136). Note that the schedule and the like of the power transaction can also be provided from the information management apparatus 100.

[0075] In addition, the charge / discharge CS 500 also performs processing related to the power transaction management other than steps S134, S136. For example, the charge / discharge CS 500 performs a reservation in advance by transmitting information related to the users U1, U2 and the electric vehicles M1, M2 that use the charge / discharge apparatus 520 to the charge / discharge apparatus 520 so that other electric vehicles M cannot use at the reserved time. In addition, the charge / discharge CS 500 manages the discharging state and the charging state based on the information obtained from the charge / discharge apparatus 520. For example, in the case where the user U1 is on the side that sells power (the seller) and the user U2 is on the side that buys power (the buyer), the power discharged from the battery B1 of the electric vehicle M1 of the user U1 is acquired by the charge / discharge apparatus 520 connected to the electric vehicle M2, and the acquired power is supplied to the battery B2 of the electric vehicle M2 via the charge / discharge apparatus 520 connected to the electric vehicle M2. These charge / discharge states are managed at all times by the charge / discharge CS 500 based on the information from the charge / discharge apparatus 520.

[0076] Note that the charge / discharge CS 500 can also transmit information related to the transaction state to the user terminals 200-1, 200-2. In addition, the charge / discharge apparatus 520 transmits information related to the power transaction state (charge / discharge state) to the information management apparatus 100 at a prescribed timing (step S138). The information related to the power transaction state includes, for example, charging information (state data) indicating the state in the charging of the electric vehicle M1 or M2, information indicating the completion of the charging (charging result), information indicating the end of the connection of the electric vehicle M1, M2 to the charge / discharge apparatus 520 (session end information), and the like. Note that the charging information is transmitted to the information management apparatus 100 at a prescribed period, the charging result is transmitted to the information management apparatus 100 at the completion of the charging, and the session end information is transmitted to the information management apparatus 100 at the end of the connection of the charge / discharge apparatus 520 to the electric vehicle M.

[0077] The processing section 140 of the information management apparatus 100 receives information related to the power transaction status from the charge / discharge CS 500, and generates a data set DS or the like in the file system 400 with respect to the received information (step S140). In addition, the information management apparatus 100 appends a charging session result (power transaction result) or the like to the smart contract SC including the existing request of the matching object stored on the blockchain 300 (step S142), and stores the appended smart contract SC (step S144).

[0078] Next, the details of each process of the above-described flow of the power transaction will be described.

[0079] [Request generation process: steps S100, S110]

[0080] In a case where the requests are respectively generated by the user terminals 200-1, 200-2, the transaction application 272 causes an image inputting the request to the user terminals 200-1, 200-2 to be displayed on the display 232. The image can be provided from the providing section 160 of the information management apparatus 100. In addition, a sound corresponding to the image can be output.

[0081] Figure 5 is an example of an image IM10 displayed on the user terminal 200 in the request generation process. Figure 5 The image IM10 illustrated is an image displayed on the user terminal 200-1 in the process of step S100, and on the user terminal 200-2 in the process of step S110. Note that the display form of the image IM10, such as the layout, the font of the text, the size, the display content, and the like, is not limited to Figure 5 the example of Figure 5 The image IM10 illustrated, for example, includes various input items for accepting a new request from the user U1. Figure 5 The image IM10 illustrated, for example, includes a transaction object machine information display area AR11, a transaction content display area AR12, and a switch display area AR13.

[0082] In the transaction object machine information display area AR11, information related to the object machine of the electric power transaction is displayed. In the case where the electric power transaction of the battery B mounted on the electric vehicle M is performed, the transaction object machine information display area AR11 displays a region where the setting of the identification information (for example, vehicle ID) that identifies the electric vehicle M as the object of the electric power transaction is accepted. Note that an icon IC11 that is a GUI (Graphical User Interface) switch for selecting the vehicle ID can also be displayed in the transaction object machine information display area AR11. In the case where the icon IC11 is selected by the user U1, a list of the vehicle IDs that are registered in advance is displayed, and the user U1 selects one from among the displayed list, thereby setting the vehicle ID.

[0083] The transaction content display area AR12 displays input items that accept the input of information such as the transaction category (Buy or Sell), the amount of the transaction (the amount of electric power), the transaction price (the purchase price or the sales price), and the like. In addition, the transaction content display area AR12 can include information such as the time slot of the transaction, the token (for example, information related to the Payment Token (cryptographic asset), information related to other procedures, and the like) that is exchanged after the completion of the transaction, the kind of the electric power resource of the transaction (whether to be set to only green energy), and the like. These pieces of information can be set using, for example, a check box, a slide bar, or the like as shown in FIG. 10. Figure 5

[0084] The switch display area AR13 includes an icon IC12 and an icon IC13 that are GUI switches. The icon IC12 is a switch that accepts a new request (OK switch: "OK" switch). The icon IC13 is a switch that accepts no registration of a new request (cancel switch).

[0085] In the case where 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 to the information management apparatus 100 as new request information. The new request information can include information related to the user U1 (for example, the user ID, the address information of the user U), information related to the user terminal 200, and the like. In addition, the position information of the user terminal 200 can also be transmitted on the basis of the new request information (or instead of this).

[0086] [Matching process and SC generation process: Steps S104 to S108, S114]

[0087] ​Next, the matching processing in steps S104 to S108 and step S114, and the generation processing of the smart contract SC based on the matching result will be described. Note that, in the following processing, the generation processing of the smart contract SC in which the request related to the power transaction of each user terminal 200 is set as the transaction data is described in several embodiments.

[0088] (First Embodiment)

[0089] Figure 6 is a flowchart showing an example of the matching processing and the generation processing of the smart contract in the first embodiment. In Figure 6 In the example of , the acquisition unit 120 determines whether a new request accepted from the user U is acquired (step S200). In a case where it is determined that the new request is acquired, the matching unit 130 performs the matching processing between the new request and the existing request included in the smart contract SC stored on the blockchain 300 (step S210). Next, the processing unit 140 determines whether the matching performed by the matching unit 130 is established (step S220). In a case where it is determined that the matching is not established (not established), 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 can also be hashed.

[0090] In addition, in a case where it is determined in the processing of step S220 that the matching is established, the processing unit 140 appends information related to the new request to the smart contract stored on the blockchain 300 including the existing request in which the matching is established (step S250). Thereby, the processing of the present flowchart ends. In addition, in a case where it is determined in the processing of step S200 that the new request is not acquired, the processing of the present flowchart ends.

[0091] Next, the processing of the first embodiment will be described in more detail. Note that, in the following example, in order to facilitate the description, a case where a request is generated from the user U3 in addition to the users U1 and U2 will be described. Figure 7 is a diagram for explaining the requests accepted from each user U in the first embodiment. Figure 8 is a diagram for explaining the smart contract SC stored on the blockchain 300 in the first embodiment. In Figure 7 In the example of , it is assumed that the requests related to the power transaction input from the user terminals 200-1 to 200-3 used by the users U1 to U3 are acquired, and it is assumed that the smart contract SC is not stored on the blockchain 300 at a stage before the input of the users U1 to U3.

[0092] In Figure 7In the example of FIG. 1, the information management apparatus 100 initially acquires a request A (power selling request) related to a power transaction in which 10 [kWh] of power is intended to be sold from the user terminal 200-1 of the user U1. Note that the request A can include information related to a transaction price (selling price) of power, or other information set using the image IM10.

[0093] The matching section 130 performs matching between an existing request included in the smart contract SC already stored on the blockchain 300 and the request A that is a new request at this point in time. For example, the matching section 130 determines that matching is established in a case where there is a request (purchase request) that satisfies the condition of intending to purchase 10 [kWh] or less of power among existing requests related to a power transaction, and determines that matching is not established in a case where the above condition is not satisfied. In the blockchain 300, there is no smart contract SC (purchase request) yet, so the matching section 130 determines that matching is not established. Then, the processing section 140 generates a new smart contract SC Figure 7 containing the request A as shown in A , and stores it on the blockchain 300. In the smart contract SC A containing the request A in the first embodiment, for example, at least one of information related to the user U who generated the request, a transaction category (power purchase, power sale, or the like), and information related to a token used (exchanged) after the transaction is completed is included. In addition, in the smart contract SC generated by the processing section 140, the information of the request A is saved by being hashed. By hashing the request A, leakage and tampering of the request information can be suppressed, and the request information can be further protected.

[0094] The registration section 150 stores (registers) the smart contract SC A generated as shown in Figure 7 on the blockchain 300. At this point in time, the request A becomes an existing request.

[0095] Next, the information management apparatus 100 acquires a request B (purchase request) related to a power transaction in which 20 [kWh] of power is intended to be purchased from the user terminal 200-3 of the user U3. The matching section 130 performs matching between the request A (existing request) included in the smart contract SC A already saved on the blockchain 300 and the request B (new request). The power intended to be purchased by the request B is 20 [kWh], which is greater than the power intended to be sold 10 [kWh] by the request A, so the matching section 130 determines that the condition is not satisfied and matching is not established.

[0096] The processing section 140 generates a smart contract SC BIn this case, the request information can also be hashed. Registration Department 150 will then... Figure 8 The smart contract SC generated as shown B Stored on blockchain 300. At this point in time, request B becomes an existing request.

[0097] Next, the information management device 100 obtains a request C (purchase request) related to the electricity transaction of wanting to purchase 10 [kWh] of electricity from the user terminal 200-2 of user U2. The matching unit 130 executes the smart contract SC already stored on the blockchain 300. A SC B The matching process involves matching requests A and B (both existing requests) with request C (a new request). Request A contains the request to sell 10 kWh of electricity, and request C contains the request to purchase 10 kWh of electricity, thus matching the request A and request C are matched. Therefore, the matching unit 130 determines that a match has been established between request A and request C.

[0098] In this case, the processing unit 140, as Figure 8 As shown, the following processing (state update processing) is performed: for smart contract SC, including request A where a match has been found... A As information related to request C, only a state indicating that a match has been established between request A and request C is appended. It should be noted that, alternatively (or based on) the processing, a portion of the information from request C can be appended. In this case, the appended information can be hashed.

[0099] According to the first embodiment described above, no new smart contract SC containing request C will be generated on the blockchain. C Alternatively, a new smart contract SC can be generated that includes both request A and request C. A+C Therefore, it can suppress the increase in the number of smart contracts SC stored on blockchain 300 (i.e., the amount of data), and can store information with less latency and more fine and accurate information on blockchain 300.

[0100] (Second Embodiment)

[0101] Next, the second embodiment will be described. The second embodiment differs from the first embodiment in that the request information is stored on a file system 400 outside the blockchain 300, and the smart contract SC is not generated by the processing unit 140, but rather by a program on the blockchain 300 according to instructions from the processing unit 140. The following description will focus primarily on these differences.

[0102] Figure 9is a diagram showing an example of a specific structure of the processing section 140 in the second embodiment. The processing section 140 includes, for example, a first processing section 142, an assignment section 144, and a second processing section 146. The first processing section 142 stores the information of the new request in the file system 400 existing outside the blockchain 300 without being hashed. The assignment section 144 assigns an identification information (CID: Content Identifier) to the information of the new request stored in the file system 400. Note that the CID can also be a hash value. For example, the assignment section 144 hashes the information of the new request and the like as an input value, and assigns the hash value as the CID for the new request. The CID is used for management and reference of the request (or the data set DS) in the information management apparatus 100, the file system 400, and the like. The second processing section 146 generates the smart contract SC including the new request through a program on the blockchain 300 in a case where the matching between the new request and the existing request by the matching section 130 does not hold. In addition, the second processing section 146 appends information related to the new request to the smart contract SC including the matching target in a case where it is determined by the matching section 130 that the matching holds.

[0103] Figure 10 is a flowchart showing an example of the matching processing and the generation processing of the smart contract SC in the second embodiment. Figure 10 The processing of Figure 6 The processing of the step S200 to S250 shown in FIG. 17 is different from the processing of the steps S200 to S250 shown in FIG. 16 in that the processing of the steps S202 and S204 is added, and the processing of the step S232 is provided instead of the processing of the step S230. Therefore, the following description will mainly focus on the processing of the steps S202 to S204 and S232.

[0104] In the processing of the step S200 of Figure 10 In a case where it is determined in the processing of the step S200 that the new request is acquired, the first processing section 142 stores the data set (data file) DS including the new request in the file system 400 (step S202). The file system 400 is a secure environment managed by the information management apparatus 100, and thus the new request stored in the data set DS can not be hashed. Next, the assignment section 144 assigns an identification information to the new request in the data set DS (step S204). Therefore, the data set DS includes information of the CID. Also, in the matching processing of the step S210, the matching section 130 performs the matching processing between the existing request included in the data set stored in the file system 400 and the new request.

[0105] If, in step S220, a match is determined to be invalid (not valid), the second processing unit 146 executes the program on the blockchain 300, thereby generating a smart contract containing the new request (step S232) and storing it on the blockchain 300 (step S240). It should be noted that the new request contained in the smart contract can also be hashed.

[0106] Next, the processing of the second embodiment will be described in more detail. Figure 11 This is a diagram illustrating the requests of each user U in the second embodiment and the smart contract SC stored on the blockchain 300. In the second embodiment, upon receiving request A from user U1, the first processing unit 142... Figure 11 As shown, the dataset DS containing request A will be... A Stored in file system 400. Assigning part 144 pairs of datasets DS A Request A within the scope is assigned identification information (CID).

[0107] The matching unit 130 performs a match between the new request A and the existing request. If the match is determined to be invalid, the second processing unit 146 outputs the following instruction: another smart contract SC (hereinafter referred to as the "generation SC") that is pre-stored on the blockchain 300 and contains a program for generating a new smart contract SC generates a smart contract SC containing request A. A The program executes to generate the smart contract SC corresponding to request A, based on instructions from the second processing unit 146. A And store it on Blockchain300.

[0108] exist Figure 11 In the example, the smart contracts SC corresponding to requests A and B that did not match were generated by the generator SC. A SC B It should be noted that, in the second embodiment, the smart contract SC generated using SC is... A SC B The data may include, for example, information related to the user U who generated the request, the transaction type (electricity purchase, electricity sale, etc.), information related to the token used (exchanged) after the transaction, and information for referencing data (dataset) stored in the file system 400. This information may also be hashed. For example, in the second embodiment, the user terminal 200 uses the information for referencing data stored in the file system 400 to query the information management device 100 for the dataset DS, and, with the permission of the information management device 100, can refer to the contents of the dataset DS.

[0109] After that, Figure 11In the example of FIG. 6, when the request C is acquired, the first processing section 142 appends the data set DS C to the file system 400. In addition, the assignment section 144 assigns the CID corresponding to the request C. Then, the matching section 130 performs matching between the data set DS A of the request A and the data set DS B of the request B and the new request C, and determines that the matching is established between the requests A and C. Thus, the second processing section 146 appends information based on the matching result to the smart contract SC A stored on the blockchain 300.

[0110] According to the second embodiment described above, in addition to the same effects as the first embodiment, it is possible to perform the matching process while storing the request information in the file system (off-chain) 400 that is more secure than the blockchain (on-chain) 300. The request information on the file system 400 is not hashed, and thus it is possible to quickly and accurately perform the matching of the request information. In addition, according to the second embodiment, it is possible to generate the smart contract SC using a program on the blockchain 300, and thus store the process of generating the block on the blockchain 300. In addition, it is possible to easily verify from a third party which smart contract SC is generated by which program, and thus ensure the transparency of the transaction process.

[0111] Note that, in the second embodiment, the smart contract SC can be generated on the blockchain 300 directly by the processing section 140 (the second processing section 146) without using the generation-use SC, and the generation-use SC can be generated by the processing section 140. The same applies to the third embodiment described later.

[0112] (Third Embodiment)

[0113] Next, the third embodiment will be described. The third embodiment differs from the second embodiment in that the identification information (CID) of the request described above is stored in the smart contract SC on the blockchain 300, and the matching result is appended to the smart contract SC at the point in time when the user U approves the matching result. Hereinafter, the description will be mainly focused on the above difference. Note that, in the third embodiment, each process can be performed by the same configuration of the processing section 140 as the second embodiment.

[0114] Figure 12 is a flowchart illustrating an example of the matching process and the generation process of the smart contract SC in the third embodiment. Figure 12 is the same as Figure 10The processes of steps S200 to S250 shown differ in that, instead of the processes of steps S232 and S250, the processes of steps S234 and S252 are provided, and the processes of steps S260 to S280 are additionally provided. Therefore, hereinafter, the processes of steps S234, S252, and S260 to S280 will be mainly described.

[0115] In Figure 12 the process of step S220, in the case where it is determined that matching does not hold, the second processing section 146 generates a new smart contract SC including the CID (identification information) of the new request by a program on the blockchain 300 (generation-use SC) (step S234). In the case where it is determined that matching holds, the second processing section 146 appends the CID of the new request to the smart contract SC including the CID of the existing request for which matching holds (step S252). Note that the CIDs stored in the smart contract SC in the processes of steps S234 and S252 can be hashed.

[0116] Next, the provision section 160 generates information indicating the matching result and provides it to the user terminal 200 that transmitted the request for matching (step S260). Next, the second processing section 146 determines whether or not the acceptance of the user who performed the power transaction has been received based on the information acquired from the user terminal 200 (step S270). In the case where it is determined that the acceptance has been received, information related to the matching result is appended to the target smart contract SC (step S280). In the case where it is determined that the acceptance has not been received (for example, information indicating rejection has been received), the processes after step S234 are performed.

[0117] Next, the processes of the third embodiment will be described in more detail. Figure 13 is a diagram for explaining the request of each user U in the third embodiment and the smart contract SC stored on the blockchain 300. In the third embodiment, the first processing section 142 accepts the request A of the user U1, and generates a data set DS A containing the request A on the file system 400. The assignment section 144 assigns a CID to the request A within the data set DS A . In the case where it is determined by the matching section 130 that matching does not hold with the request A, the second processing section 146 generates a smart contract SC A containing the CID assigned to the request A using a generation-use SC. In Figure 13 the example, a smart contract SC A containing the CID of the request A for which matching does not hold and a smart contract SC B containing the CID of the request B are generated using the generation-use SC. The smart contract SCA , SC B The CID of the SC A may also be hashed. By saving the CID in the smart contract SC like this, it is possible to prove that the request information that is the origin of the transaction condition exists outside the blockchain (off-chain), and thus it is possible to ensure the validity of the transaction. In addition, by storing only the CID of the hashed request information in the smart contract SC, it is possible to protect the personal information of the user U. Note that, for example, in a case where the user U wants to refer to the request information corresponding to the CID, the user U can refer to the request information when permission is obtained by making a request for the request information from the user terminal 200 to the information management apparatus 100.

[0118] In addition, the request C is matched with the data set DS B , the request A and the request B saved in the file system 400 by the matching unit 130, and it is determined that the matching is established in the request A and the request C. The second processing unit 146 appends the CID of the request C for which the matching is established to the smart contract SC A as information based on the matching result at this point in time. Note that the processing unit 140 appends the CID of the request C to the smart contract SC A , SC B using the generation SC similarly to the generation of the smart contract SC A . Note that, in the program of the generation SC of the third embodiment, a program of appending the CID of the request for which the matching is established to the existing smart contract SC is included.

[0119] Here, the providing unit 160 generates information (for example, an image) related to the matching result described above, and provides the generated information to the user terminals 200-1 and 200-2. Note that, in the provided information, information indicating whether or not the transaction based on the matching result should be permitted can be included. The second processing unit 146 further appends information to the smart contract SC A according to whether or not the permission of the transaction is accepted from the users U1 and U2. The above-described processing corresponds to the display and acceptance processing of the matching result of steps S122 and S124 shown in Figure 4 .

[0120] Figure 14 is an example of an image IM20 indicating the matching result. In the image IM20 shown in Figure 14 , for example, a matching result display region AR21 and a switch display region AR22 are included.

[0121] In the matching result display region AR21, information related to the content of the result of matching to the condition of the request is displayed. In the matching result display region AR21, for example, a matching result display region AR21 and a switch display region AR22 are included. Figure 14In the present embodiment, as an example, a case where multiple pieces of information (requests) for which matching is established exist is shown. In a case where multiple matching results are obtained, each content (for example, a transaction price, a transaction volume (amount of electric power)) is displayed, and a radio button (check box) or the like for selecting which of the multiple contents for which matching is established is displayed. The user U1, U2 selects any one of the multiple contents that exist through the radio button of the image IM20. Note that, in a case where matching based on the matching unit 130 is not established, information indicating that matching is not established can also be displayed in the matching result display area AR21.

[0122] In the switch display area AR22, an icon IC21 as a GUI switch for permitting a transaction based on a matching result, and an icon IC22 for rejecting (not permitting) a transaction are displayed. The user terminal 200-1, 200-2 transmits information indicating that a transaction based on the matching result selected in the matching result display area AR21 is permitted to the information management apparatus 100 in a case where selection of the icon IC21 by the user U1 is accepted, and transmits information indicating that a transaction based on the matching result is rejected to the information management apparatus 100 in a case where selection of the icon IC22 is accepted. Figure 4 The processing of steps S126, S128 of the matching unit 130).

[0123] Returning to Figure 13 In a case where the transaction is permitted by both the user U1 and the user U2, the processing unit 140 adds a data set of a matching result to the smart contract SC A on the blockchain 300. Note that, in the information (matching result data set) saved after the permission of the user U, for example, contract information (for example, an amount of electric power, a transaction price, an added value rate) required for calculation of a transaction price is included. As for the added value rate, for example, the processing unit 140 can acquire information related to a market situation of a power transaction from the outside, and set the added value rate based on the acquired information, can set the added value rate based on a service utilization situation of the user U, or can arbitrarily set the added value rate by a manager or the like of the transaction system 1. The matching result data set added to the smart contract SCA can also be hashed.

[0124] Note that, in the third embodiment, the matching unit 130 can also be configured as Figure 13As shown, all matching results, including those that are true and those that are false, that have been performed within the file system 400 are stored in the file system 400 as a dataset. Additionally, the matching unit 130 can also store more detailed information (e.g., in addition to the contract information mentioned above, information about requests for successful matches) in the file system 400 than the matching result dataset appended to the smart contract SC. This allows for more detailed management of the matching status and reduces the amount of data appended to the smart contract SC. Furthermore, the matching result dataset appended to the smart contract SC does not contain user-related information, thus protecting the user's personal information.

[0125] According to the third embodiment described above, in addition to achieving the same effect as the first embodiment, the requested information is not stored in the smart contract SC, but only the CID corresponding to the request is stored on the smart contract SC. This proves that the request that is the origin of the transaction conditions exists off-chain (file system 400), ensuring the legitimacy of the transaction. Furthermore, by not storing the requested information, the amount of data on the blockchain 300 can be further reduced, allowing for more accurate information management on the file system 400.

[0126] It should be noted that the first to third embodiments described above can each be combined with at least a portion of other embodiments. For example, in the second embodiment, the matching unit 130 can also store the matching results performed in the file system 400 in the file system 400 in the same way as in the third embodiment.

[0127] [Power Transaction Management Processing: Steps S132~S144]

[0128] Next, regarding Figure 4 The power transaction management process shown in steps S132 to S144 will be explained in detail. Figure 15 This is a diagram used to illustrate the processes related to electricity trading. Figure 15In this embodiment, the charging / discharging CS500, information management device 100, and file system 400 can, for example, have dedicated intelligent agents (user intelligent agent programs) set up in both the information management device 100 and the charging / discharging CS500 to handle data transmission and reception. Furthermore, data transmitted between devices (transaction data) can be transferred using a method called Distributed Identifier (DID). DID refers to a transmission framework that replaces personal identification information such as usernames with a unique ID owned by the user, which is not managed by a third party, thereby enabling data exchange between devices and ensuring privacy protection and transaction security. For example, DID-Comm, a P2P communication protocol, can be used for data transmission using DID. By using DID-Comm, distributed data collaboration can be achieved while reducing the device's dependence on the overall management system. Additionally, by using DID-Comm for data transmission, verification of, for example, the authentication information (user information) of the sent data can be performed. It should be noted that the communication protocol used in this embodiment is not limited to DID-Comm.

[0129] exist Figure 15 First, the CS500 charging and discharging system registers the information related to the DID used in the transmission of information related to this electricity transaction in the file system 400. Figure 15 (1)). In addition, the information management device 100 registers information related to the DID and DID-Comm used in the charging and discharging CS500 in the file system 400 ( Figure 15 (2)). In addition, when users U1 and U2 agree to the electricity transaction, the information management device 100 generates charging and discharging schedule information based on the tradable charging and discharging time (start time and end time) included in the requests A and C of users U1 and U2, and sends the generated schedule information and information related to users U1 and U2 to the charging and discharging CS500. Figure 15 (3)).

[0130] The CS500 charging and discharging system generates information (e.g., images) related to the electricity trading status (contract status) based on schedule information and provides it to user terminals 200-1 and 200-2. Figure 15 (4) It should be noted that the above information can also be provided by the information management device 100's provisioning unit 160 instead of by the charging / discharging CS500.

[0131] Figure 16 This is an example of an image IM30 related to electricity trading conditions. It should be noted that... Figure 16The illustrated image IM30 shows an example of an image displayed on the user terminal 200-2 of the side that transmitted the purchase request of the purchased electric power (the buyer side). In Figure 16 In the example, the image IM30 includes, for example, a transaction status display area AR31, a transaction data summary display area AR32, and a switch display area AR33. In the transaction status display area AR31, information indicating the state of purchase of electric power (or sale of electric power) (for example, the remaining amount of charge, the remaining amount of discharge), the identification information (charge / discharge device ID) of the charge / discharge device 520 to which the electric vehicle M is connected, and information related to the site (setting location) are displayed. In addition, information indicating that the electric power transaction is in progress, or that the electric power transaction is completed can also be displayed in the transaction status display area AR31. In the transaction data summary display area AR32, information related to the electric power transaction (transaction data) such as the start time, the end time, the total amount of electric power, the total cost of charge (or discharge) is displayed.

[0132] The switch display area AR33 includes icons IC31, IC32 as GUI switches. The icon IC31 is a switch for accepting a display instruction of an electronic receipt (Receipt) after the completion of charge / discharge. The icon IC32 is a switch for ending the display of the image IM30. The transaction application 272 causes an image indicating the receipt in the present electric power transaction to be displayed on the display 232 when the icon IC31 is selected by the user U2, and ends the display of the image IM30 when the icon IC32 is selected.

[0133] The users U1, U2 cause the electric vehicles M1, M2 used by them, respectively, to move to the charge / discharge devices 520 managed by the charge / discharge CS 500 based on the site information displayed in the transaction status display area AR31, and connect the electric vehicles M1, M2 to the charge / discharge devices 520 corresponding to the charge / discharge device IDs. Note that the charge / discharge facility IDs and the site information displayed in the transaction status display area AR31 are, for example, the ID and the site information of the charge / discharge device 520 closest to the user terminal 200 extracted by the charge / discharge CS 500 or the information management device 100 based on the position information of the user terminal 200. In Figure 15 In the example, the electric vehicle M1 of the user U1 is connected to the charge / discharge device 520-1, and the electric vehicle M2 of the user U2 is connected to the charge / discharge device 520-2.

[0134] Charging and discharging devices 520-1 and 520-2 obtain the identification information (vehicle ID) of electric vehicles M1 and M2 by connecting to them, and output the obtained vehicle ID to the charging and discharging CS500. When the vehicle ID is a vehicle ID for which usage has been pre-authorized (scheduled), the charging and discharging CS500 initiates a charging and discharging session (electricity transaction based on charging and discharging) and sends charging and discharging related information (e.g., charging and discharging information, charging and discharging results, session end) to the information management device 100. Figure 15 (5)). The information management device 100 stores information such as electricity trading status in the file system 400 based on information related to charging and discharging. Figure 15 (6) After the power transaction is completed (after charging / discharging or after the session ends), the power transaction result is added to the smart contract SC stored in blockchain 300. Figure 15 (7)).

[0135] Figure 17 This is a diagram used to illustrate the management of transaction status during a charging / discharging session. Figure 17 In the example, assuming that before the charging / discharging session, the above... Figure 13 The third embodiment shown includes a smart contract SC containing the CIDs corresponding to matching requests A and C, and a dataset of matching results. A Stored on Blockchain 300. Additionally, in Figure 17 The example illustrates the management of transaction status during charging / discharging, after charging / discharging is complete, and at the end of the session. During charging / discharging, the charging / discharging CS500 sends charging / discharging-related information (e.g., charging / discharging information, charging / discharging results, session end) to the information management device 100. The information management device 100 then manages transactions during the charging / discharging session based on the sent information.

[0136] Figure 18 This is a flowchart illustrating an example of the processing performed by the information management device 100 during a charging / discharging session. Figure 18 The processing can be performed repeatedly at specified intervals or at specified times during a charge / discharge session. Figure 18 In the example, the acquisition unit 120 of the information management device 100 determines whether it has obtained charging and discharging related information from the charging and discharging CS500 (or charging and discharging devices 520-1, 520-2) (step S300).

[0137] If it is determined that information related to charging and discharging has been obtained, the acquisition unit 120 determines whether the obtained information is charging information (step S310). If it is determined to be charging information, the processing unit 140 (first processing unit 142) proceeds as follows: Figure 13The processing section 140 generates a data set DS1 corresponding to the charging information as shown in the drawing, and stores it in the file system 400 (step S320). The data set DS1 contains, for example, information related to the charging / discharging facility ID, the charging / discharging time (time stamp), the user information, the vehicle ID, the discharged power amount (or the charged power amount). In addition, the data set DS1 can also contain information such as the identification information (battery ID) of the battery B (charging / discharging target machine), the power amount of the battery B, the charging rate (SOC; State Of Charge), and the like.

[0138] In addition, in the processing of step S320, in the case where the data set DS1 already exists in the file system 400, the changed part of the data set DS1 can be updated, or the stored past data set DS1 can be deleted and the new data set DS1 can be stored in the file system 400. In addition, the data set DS1 can contain information of both the charging side and the discharging side, or can be saved as different data sets, respectively.

[0139] In addition, in the case where it is determined in the processing of step S310 that it is not charging information, the acquisition section 120 determines whether the acquired information related to charging / discharging is the charging / discharging result transmitted at the time of completion of charging (step S330). In the case where it is determined that it is the charging / discharging result, the processing section 140 generates a data set DS2 indicating the charging / discharging result as shown in the drawing, and stores the generated data set DS2 in the file system 400 (step S340). The data set DS2 contains, in addition to the same information as the data set DS1, information indicating the case where the transaction is completed, the total charging (or discharging) amount under the session, and the like. Figure 17

[0140] In addition, the processing section 140 calculates the final transaction amount based on the data set DS1 of the charging / discharging information, the data set DS2 of the charging / discharging result, the contract information (for example, the transaction price, the added value rate) contained in the matching result data set, and generates a data set DS3 containing the calculated transaction information such as the transaction amount, the transaction volume (step S350). Note that the transaction information can contain, for example, information indicating whether the transaction is completed. In addition, the data set DS3 saves, in addition to the transaction information, the session information (information obtained in the communication). The session information contains, for example, at least one of the identification information (charging / discharging ID) identifying the charging / discharging device 520, the identification information (CID) of the request which is the origin of the transaction, the identification information (user ID) of the user who is the power consumer (supplier), the charging / discharging start time, the charging / discharging end time, the battery power amount at the session start, the battery power amount at the session end, the battery charging rate at the session start, the battery charging rate at the session end, the total charging / discharging power amount under the session.

[0141] ​Furthermore, if in step S330 the information related to discharge is determined not to be a charging / discharging result, the acquisition unit 120 determines whether the acquired charging / discharging related information is session termination information (step S360). If it is determined to be session termination information, the second processing unit 146 sends a request to the smart contract SC stored on the blockchain 300. A Append a dataset corresponding to the charging session result (electricity transaction result) (e.g., at least a portion of the contents of dataset DS3) (step S370) and store it on blockchain 300 (step S380). It should be noted that the second processing unit 146 will send data to the smart contract SC. A The session information contained in the appended dataset (electricity transaction results) is hashed, while the transaction information is appended to the smart contract SC without hashing. A Additionally, the second processing unit 146 can also add information (status information) proving the end of charging / discharging to the smart contract SC. A .thus, Figure 18 The process shown in the flowchart ends. Additionally, if it is determined in step S300 that no information related to charging / discharging has been obtained, the process in this flowchart also ends.

[0142] In this way, session information, including user identification information, is hashed and stored on blockchain 300 in a state where the data content is unknown, thereby protecting user U's privacy information. Furthermore, information needed to calculate the final settlement amount, such as transaction amount and volume, as well as information used to confirm transaction completion (i.e., information that is not private), is not hashed but stored on blockchain 300, thus enabling accurate and rapid calculation of the final settlement amount. It should be noted that the aforementioned smart contract SC... A It contains the CID corresponding to request A and the matching result dataset, so this information can be used to obtain request information from file system 400, etc.

[0143] [Variation Example]

[0144] In the transaction system 1 of the embodiment, the information management device 100 can be a node constituting the blockchain 300 (blockchain network) or a node constituting the file system 400 (IPFS network). In other words, the information management device 100 can be integrated with the blockchain 300 or the file system 400. Furthermore, the information management device 100 can also be integrated with the charging / discharging CS500. Additionally, some of the functions included in the information management device 100 (e.g., the functions of the matching unit 130, the registration unit 150, or the providing unit 160) can be executed through a program (a dedicated smart contract) pre-stored in the blockchain 300.

[0145] In addition, in the embodiments, a transaction related to the electric power of the electric vehicle M (more specifically, the battery B) owned by the user U is explained, but the electric power obtained by solar power generation, wind power generation, hydroelectric power generation, thermal power generation, geothermal power generation, or the like can be used in addition to (or instead of) the electric power from the electric vehicle M.

[0146] According to the embodiments described above, the information management device 100 mediates a transaction of electric power between users and manages a result of the transaction by storing information related to the transaction on a blockchain, wherein the information management device 100 has a processing section 140 that hashes and stores session information related to a result of a session of charging and discharging, including information of users who transact electric power, on the blockchain, and stores transaction information, including a transaction amount and a transaction volume of the electric power, on the blockchain without hashing, whereby appropriate information can be stored on the blockchain to perform more appropriate information management.

[0147] More specifically, according to the embodiments, information including identification information of a transactioner is hashed and stored on the blockchain, and information that is not private information (a transaction amount, a transaction volume, and information indicating whether a transaction is completed, or the like) is stored on the blockchain without hashing, whereby the calculation of a final settlement amount and the like can be performed correctly and quickly while protecting private information and the like of users, because information that is not private information is not hashed for the calculation of the final settlement amount. Therefore, more appropriate information processing, management based on a result of the processing, and the like can be performed.

[0148] In addition, according to the embodiments, as the session information, at least one of identification information that identifies a charging and discharging device that performs charging and discharging of electric power, identification information of a request that is a source of a transaction of electric power, identification information of a user, a charging and discharging start time, a charging and discharging end time, a battery power amount at a session start, a battery power amount at a session end, a battery charge rate at a session start, a battery charge rate at a session end, and a total charging and discharging power amount under a session is included, whereby the transaction status can be grasped in more detail. In addition, according to the embodiments, by storing the session information and the transaction information on the blockchain 300 and the file system 400 that is a secure environment, the information can be more appropriately protected. Therefore, a more secure electric power transaction service can be provided. In addition, according to the embodiments, the charging and discharging information in the electric power transaction is stored on the file system 400 that exists outside the blockchain, whereby the status of the electric power transaction can be managed in a state with less delay.

[0149] In addition, according to the embodiment, the smart contract is newly generated only in the case where the matching is not established, and the new request, the power transaction result is added to the existing smart contract of the matching object in the case where the matching is established, so that the number of smart contracts can be reduced. Thus, the data capacity on the blockchain and the operation cost (= transaction data cost) can be reduced, and the reduction in the processing speed in the transaction system 1 can be suppressed.

[0150] The above-described embodiment can be expressed as follows.

[0151] The information management apparatus includes:

[0152] a storage medium that stores computer-readable instructions that are readable by a computer of the information management apparatus that mediates a power transaction between users and manages a transaction result by storing information related to the power transaction on a blockchain; and

[0153] a processor connected to the storage medium,

[0154] the processor executing the computer-readable instructions to:

[0155] hash and store on the blockchain session information related to a session result of charging and discharging, including information of users who have performed the power transaction; and

[0156] store on the blockchain transaction information including a transaction amount and a transaction volume of the power without hashing.

[0157] The above, the specific embodiments of the present application are explained using the embodiments, but the present application is not limited at all to such embodiments, and various modifications and substitutions can be applied within the scope of the gist of the present application.

[0158] Explanation of Reference Signs

[0159] 1… transaction system, 100… information management device, 110… communication unit, 120… acquisition unit, 130… matching unit, 140… processing unit, 142… first processing unit, 144… attribution unit, 146… second processing unit, 150… registration unit, 160… provision unit, 170… device-side storage unit, 200… user terminal, 210… terminal-side communication unit, 220… input unit, 230… output unit, 232… display, 234… speaker, 240… position information acquisition unit, 250… control unit, 260… application execution unit, 270… terminal-side storage unit, 300… blockchain, 400… file system, 500… charge / discharge CS, 520… charge / discharge device, M… electric vehicle.

Claims

1.An information management apparatus that mediates a power transaction between users and manages a transaction result by storing information related to the power transaction on a blockchain, wherein the information management apparatus includes a processing unit that hashes and stores session information related to a result of a session of charging and discharging, including information of a user who performs the power transaction, on the blockchain, and stores transaction information, including a transaction amount and a transaction volume of the power, on the blockchain without hashing. 2.The information management apparatus according to claim 1, wherein the blockchain is Ethereum. 3.The information management apparatus according to claim 1, wherein the session information includes at least one of identification information that identifies a charging and discharging device that performs charging and discharging of the power, identification information of a request that is a source of the power transaction, identification information of the user, a charging and discharging start time, a charging and discharging end time, a battery power amount at a session start time, a battery power amount at a session end time, a battery charge rate at the session start time, a battery charge rate at the session end time, and a total charging and discharging power amount in the session. 4.The information management apparatus according to claim 1, wherein the information management apparatus further includes a matching unit that performs matching between a new request related to purchase or sale of the power received from the user and an existing request included in a smart contract already stored on the blockchain, the processing unit appends information of the new request to the smart contract including the existing request in which the matching is established, and appends the session information and the transaction information to the smart contract after the power transaction ends. 5.The information management apparatus according to claim 1, wherein the processing unit stores charging and discharging information in the power transaction in a storage unit that exists outside the blockchain. 6.An information management method that performs processing by an information management apparatus that mediates a power transaction between users and manages a transaction result by storing information related to the power transaction on a blockchain, wherein the information management method causes the information management apparatus to perform processing of: hashing and storing session information related to a result of a session of charging and discharging, including information of a user who performs the power transaction, on the blockchain; and storing transaction information, including a transaction amount and a transaction volume of the power, on the blockchain without hashing. 7.A program that performs processing by an information management apparatus that mediates a power transaction between users and manages a transaction result by storing information related to the power transaction on a blockchain, wherein the program causes the information management apparatus to perform processing of: hashing and storing session information related to a result of a session of charging and discharging, including information of a user who performs the power transaction, on the blockchain; and storing transaction information, including a transaction amount and a transaction volume of the power, on the blockchain without hashing. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ Transaction information including a transaction amount and a transaction volume of the electric power is stored on the blockchain without being hashed.

Images