WO2024262011A1 - 情報管理装置、情報管理方法、およびプログラム - Google Patents

情報管理装置、情報管理方法、およびプログラム Download PDF

Info

Publication number
WO2024262011A1
WO2024262011A1 PCT/JP2023/023344 JP2023023344W WO2024262011A1 WO 2024262011 A1 WO2024262011 A1 WO 2024262011A1 JP 2023023344 W JP2023023344 W JP 2023023344W WO 2024262011 A1 WO2024262011 A1 WO 2024262011A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
request
blockchain
smart contract
matching
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2023/023344
Other languages
English (en)
French (fr)
Inventor
亨 木村
マーティン コップ
クリスチャン ケーベル
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honda Motor Co Ltd
Original Assignee
Honda Motor Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honda Motor Co Ltd filed Critical Honda Motor Co Ltd
Priority to CN202380099433.4A priority Critical patent/CN121311915A/zh
Priority to EP23942442.7A priority patent/EP4715723A1/en
Priority to PCT/JP2023/023344 priority patent/WO2024262011A1/ja
Priority to JP2025527387A priority patent/JPWO2024262011A1/ja
Publication of WO2024262011A1 publication Critical patent/WO2024262011A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/06—Energy or water supply

Definitions

  • the present invention relates to an information management device, an information management method, and a program.
  • 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 the blockchain.
  • An information management device 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 requests related to purchases or sales 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.
  • the processing unit generates a smart contract that includes information about the new request that has been converted into a hash value.
  • the processing unit generates a smart contract including the new request using a program that is pre-stored on the blockchain.
  • the blockchain is Ethereum.
  • the transaction includes an electricity transaction
  • the request includes a request for purchasing or selling electricity
  • the processing unit adds the electricity transaction result for the request to the smart contract.
  • the smart contract includes at least one of the following: information about the user, the transaction type, information about the tokens to be exchanged after the transaction is completed, and information for referencing information about the request recorded in a memory unit outside the blockchain.
  • the processing unit hashes session information in a transaction between the users and stores the hashed information on the blockchain, and stores transaction information including the transaction amount and transaction volume on the blockchain without hashing the transaction information.
  • An information management method 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, generates a smart contract on the blockchain that includes the new request if the match is not established, and adds 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.
  • a program according to one embodiment 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.
  • FIG. 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 according to an embodiment.
  • FIG. 2 is a configuration diagram of a user terminal 200 according to an embodiment.
  • FIG. 2 is a sequence diagram for explaining a series of flows of energy trading in the embodiment.
  • FIG. 13 is a diagram showing an example of an image IM10 displayed on a user terminal 200 in a request generation process.
  • 11 is a flowchart illustrating an example of a matching process and a smart contract generation process in the first embodiment.
  • FIG. 2 is a diagram for explaining requests accepted from each user U in the first embodiment.
  • FIG. 11 is a diagram for explaining a smart contract SC stored on the blockchain 300 in the first embodiment.
  • FIG. 11 is a diagram illustrating an example of a specific configuration of a processing unit 140 in the second embodiment.
  • FIG. 13 is a diagram showing an example of an image IM20 relating to the matching result.
  • FIG. 2 is a diagram for explaining processing related to energy trading.
  • FIG. 13 is a diagram showing an example of an image IM30 relating to the electricity trading situation.
  • FIG. 13 is a diagram for explaining management of a transaction status during a charge/discharge session.
  • 11 is a flowchart illustrating an example of a process executed by the information management device 100
  • FIG. 1 is a configuration diagram of a trading system 1 using an information management device of 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 block chain 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 block chain 300, and the charge/discharge CS 500 can communicate with each other, for example, via 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".
  • 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 consisting of one or more information processing devices.
  • the information management device 100 may also have a function as an edge server that processes data stored on the blockchain 300 or the file system 400.
  • the information management device 100 mediates interpersonal transactions between users. For example, the information management device 100 generates information on energy trading (e.g., smart contract SC) to be stored on the blockchain 300, or generates information on energy trading (e.g., data set DS) to be stored in the file system 400.
  • energy trading e.g., smart contract SC
  • data set DS information on energy trading
  • the blockchain 300 is a data store (database) that manages information about transactions in units called blocks, links the information to clarify the context (order) and stores it.
  • the blockchain 300 may be a blockchain network made up of multiple 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 their operations on the blockchain 300, using smart contracts SC as blocks.
  • the security of transactions can be further ensured by using Ethereum, which has higher tamper resistance and reliability than other public blockchains.
  • the process of generating and storing (saving) smart contract SC on blockchain 300 can be executed by nodes connected to blockchain 300 and information management device 100. Furthermore, in blockchain 300, multiple terminals can save smart contract SC and compare them with each other. In the following description, blockchain 300 may be referred to as "on-chain.”
  • the file system 400 is, for example, a P2P (Peer to Peer) distributed file system using IPFS (Inter Planetary File System).
  • the file system 400 may be an IPFS network consisting of multiple devices (nodes) that can access each other.
  • the file system 400 stores a data set (electronic data) DS that includes information about energy trading.
  • the file system 400 is connected to the information management device 100, and the data set DS stored by the information management device 100 is managed.
  • the data set DS is 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.
  • the file system 400 may be referred to as "off-chain" or "backend".
  • 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.
  • the charging/discharging equipment 520 supplies power to the battery B of the electric vehicle M to charge it, and supplies the power discharged from the battery B to the outside.
  • the charging/discharging CS 500 manages the location information of the multiple charging/discharging equipment 520 installed at various locations, the charging/discharging schedule of the electric vehicle M, etc.
  • the charging/discharging CS 500 may perform control related to charging/discharging based on control information from the information management device 100, and may transmit the charging/discharging results to the information management device 100.
  • the configurations of the information management device 100 and the user terminal 200 will be specifically described.
  • LSI Large Scale Integration
  • ASIC Application Specific Integrated Circuit
  • FPGA Field-Programmable Gate Array
  • GPU Graphics Processing Unit
  • the program may be stored in advance in a storage device (a storage device having a non-transient storage medium) such as a hard disk drive (HDD) or flash memory provided in the information management device 100, or may be stored in a removable storage medium (a non-transient storage medium) such as a DVD or CD-ROM, and the program may be 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.
  • a storage device a storage device having a non-transient storage medium
  • a storage device having a non-transient storage medium such as a hard disk drive (HDD) or flash memory provided in the information management device 100
  • a removable storage medium a non-transient storage medium
  • the program may be 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.
  • 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.
  • 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 the results of the trading from the charging and discharging CS 500.
  • the matching unit 130 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.
  • the processing unit 140 generates a smart contract SC including a 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 existing request with which the matching is successful. Note that in the embodiment, "adding" may include changing, editing, deleting, or updating part of the information in the smart contract SC. The functions of the processing unit 140 will be described in detail later.
  • 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.
  • 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 performs new registration of the user U and registers the new user information in the user information DB 172. The registration unit 150 also performs control such as comparing 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 permitting the use of the service if matching identification information is registered, and refusing the use of the service if no identification information is registered.
  • the providing unit 160 provides various information to the user terminal 200 and the charge/discharge CS 500.
  • 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.
  • the providing unit 160 provides information related to the electric vehicle M performing charging/discharging and the user U to the charge/discharge CS 500.
  • [User terminal] 3 is a configuration diagram of a user terminal 200 according to an embodiment.
  • the user terminal 200 includes, for example, a terminal-side 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-side 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).
  • 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 cooperation between software and hardware.
  • the program may be stored in advance in a storage device (a storage device having a non-transient 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-transient storage medium) such as a DVD or CD-ROM, and the program may be installed in the HDD or flash memory provided in the user terminal 200 by inserting the storage medium into a drive device provided in the user terminal 200.
  • a storage device a storage device having a non-transient storage medium
  • a removable storage medium a non-transient storage medium
  • the program may be installed in the HDD or flash memory provided in the user terminal 200 by inserting the storage medium into a drive device provided in the user terminal 200.
  • the terminal-side memory unit 270 may be realized by the various storage devices described above, or an SSD, an EEPROM, a ROM, a RAM, or the like.
  • the terminal-side memory unit 270 stores, for example, the trading application 272, the processing results of the user terminal 200, programs, and various other information.
  • 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.
  • the input unit 220 accepts input from the user U, for example, by operating various keys, buttons, etc.
  • the input unit 220 may also be equipped with a microphone and accept voice input from the user U, for example.
  • 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.
  • the location information acquisition unit 240 acquires location information (e.g., latitude and longitude information) of the user terminal 200 using a built-in GPS (Global Positioning System) device.
  • location information e.g., latitude and longitude information
  • GPS Global Positioning System
  • 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 memory 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 information such as images and audio acquired from the information management device 100 via the terminal-side communication unit 210 to be output from the output unit 230, 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.
  • 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 input by the input unit 220 (request information), 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 on request results, etc. and information on energy trading, and outputs them to the output unit 230.
  • FIG. 4 is a sequence diagram for explaining a series of flows of power trading in the embodiment.
  • FIG. 4 shows, as an example, the user terminal 200-1 used by the user U1, the user terminal 200-2 used by the user U2, the information management device 100, the blockchain 300, and the processing in the charge/discharge CS 500.
  • Both users U1 and U2 are assumed to be users who can use the services provided by the trading system 1 (users who are permitted to use the services by the registration unit 150).
  • an example of power exchange trading between a battery B1 mounted on an electric vehicle M1 used by the user U1 and a battery B2 mounted on an electric vehicle M2 used by the user U2 will be described below.
  • the trading application 272 of the user terminal 200-1 generates a request for energy trading based on the information input by the user U1 (step S100) and transmits the generated request to the information management device 100 (step S102).
  • the matching unit 130 of the information management device 100 receives the request sent from the user terminal 200-1 and performs matching with 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). In the processing of step S104, it is assumed that matching was not established (there was no existing request 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).
  • 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 the information management device 100 (step S112).
  • the matching unit 130 acquires the request (new request) sent from the user terminal 200-2 and matches it with an existing request by referring to the smart contract SC stored on the blockchain 300 (step S114). The following explanation will be continued assuming that matching has been established 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 result (step S116) and transmits it to the user terminals 200-1 and 200-2 (steps S118, S120).
  • Each of the user terminals 200-1, 200-2 displays information related to the matching results sent from the information management device 100, and accepts instruction information and the like from users U1, U2 (steps S122, S124).
  • the information from users U1, 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, the selection of one of them.
  • Each of the user terminals 200-1, 200-2 sends the information obtained from users U1, U2 to the information management device 100 (steps S126, S128).
  • 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 power trade (for example, information about the users U1 and U2 and the electric vehicles M1 and M2 who will be conducting the power trade) to the charge/discharge CS 500 (step S130).
  • the charge/discharge CS 500 manages the power trade based on the information acquired from the information management device 100 (step S132). Specifically, it sets the charging/discharging equipment 520 to which the target electric vehicle M will be connected, and transmits information such as the location information and usage time (schedule) of the set charging/discharging equipment 520 to the user terminals 200-1 and 200-2 (steps S134 and S136). Note that information such as the schedule for conducting the power trade may be provided by the information management device 100.
  • the charge/discharge CS 500 also performs processes related to power trading management other than steps S134 and S136. For example, the charge/discharge CS 500 transmits information about the users U1 and U2 and the electric vehicles M1 and M2 who use the charge/discharge equipment 520 to the charge/discharge equipment 520 to make a reservation in advance, and prevents other electric vehicles M from using the equipment during the reservation time. The charge/discharge CS 500 also manages the discharge status and the charge status based on information obtained from the charge/discharge equipment 520.
  • the charge/discharge equipment 520 connected to the electric vehicle M2 receives the power discharged from the battery B1 of the electric vehicle M1 of the user U1, and supplies the received power to the battery B2 of the electric vehicle M2 via the charge/discharge equipment 520 connected to the electric vehicle M2.
  • These charge/discharge statuses are managed by the charge/discharge CS 500 at any time based on information from the charge/discharge equipment 520.
  • the charging/discharging CS 500 may transmit information on the transaction status to the user terminals 200-1 and 200-2.
  • the charging/discharging facility 520 transmits information on the electricity transaction status (charging/discharging status) to the information management device 100 at a predetermined timing (step S138).
  • the information on the electricity transaction status includes, for example, charging information (status data) indicating the status of the electric vehicle M1 or M2 during charging/discharging, information indicating completion of charging/discharging (charging result), and information indicating the end of the connection of the electric vehicles M1 and M2 to the charging/discharging facility 520 (session end information).
  • the charging information is transmitted to the information management device 100 at a predetermined cycle, 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.
  • the processing unit 140 of the information management device 100 receives information related to the electricity trading status from the charge/discharge CS 500, and generates a data set DS etc. in the file system 400 for the received information (step S140).
  • the information management device 100 also adds the charging session result (electricity trading result) etc. 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).
  • Steps S100 and S110 When each of the user terminals 200-1 and 200-2 generates a request, the transaction application 272 causes the user terminals 200-1 and 200-2 to display an image for inputting the request on the display 232. This image may be provided from the providing unit 160 of the information management device 100. Also, a sound corresponding to the image may be output.
  • FIG. 5 is a diagram showing an example of an image IM10 displayed on the user terminal 200 in the request generation process.
  • the image IM10 shown in FIG. 5 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.
  • the display mode of the image IM10 such as the layout, character font, size, and display content, is not limited to the example of FIG. 5.
  • the image IM10 shown in FIG. 5 includes, for example, various input items for accepting a new request from the 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.
  • the transaction target equipment information display area AR11 information on the target equipment for electricity trading is displayed.
  • 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 electricity trading.
  • the transaction target equipment information display area AR11 may display an icon IC11 that is a GUI (Graphical User Interface) switch for selecting a vehicle ID.
  • GUI Graphic User Interface
  • the transaction content display area AR12 displays input items that accept information such as the type of transaction (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 during which the transaction can be made (Time Slot), the tokens to be exchanged after the transaction is completed (for example, information about the Payment Token (cryptocurrency) (Payment Methods) and other procedures), and the type of electricity resource to be traded (whether to only use green energy). This information may be set using, for example, check boxes or slider bars as shown in FIG. 5.
  • the switch display area AR13 includes icons IC12 and IC13, which are GUI switches.
  • Icon IC12 is a switch (OK switch) that accepts a new request.
  • Icon IC13 is a switch (cancel switch) that accepts not to register a new request.
  • the user terminal 200-1 transmits the content input by user U1 via image IM10 to the information management device 100 as new request information.
  • the new request information may include information about user U1 (e.g., user ID and address information of user U1), information about the user terminal 200, etc.
  • location information of the user terminal 200 may be transmitted in addition to (or instead of) the new request information.
  • FIG. 6 is a flowchart showing an example of the matching process and the generation process of the smart contract in the first embodiment.
  • the acquisition unit 120 judges whether or not a new request accepted from the user U has been acquired (step (step S200). If it is judged 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 the smart contract SC stored on the blockchain 300 (step S210).
  • the processing unit 140 judges whether or not matching by the matching unit 130 has been established (step S220). If it is judged that matching has not been established (not established), the processing unit 140 generates a new smart contract including the new request (step S230).
  • 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.
  • step S220 If it is determined in 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 a match has been established (step S250). This ends the processing of this flowchart. If it is determined in step S200 that a new request has not been acquired, the processing of this flowchart ends.
  • Figure 7 is a diagram for explaining requests received 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.
  • requests related to energy trading input from user terminals 200-1 to 200-3 used by users U1 to U3, respectively are acquired, and that the smart contract SC is not stored on the blockchain 300 before the input by users U1 to U3.
  • the information management device 100 first obtains a request A (power selling request) for a power transaction to sell 10 kWh of electricity from the user terminal 200-1 of user U1.
  • request A may include information regarding the power trading price (sales price), and may also include other information set using the image IM10.
  • the matching unit 130 matches an existing request included in the smart contract SC already stored on the blockchain 300 with a request A, which is a new request at this point. For example, the matching unit 130 determines that matching is established when there is a request (purchase request) that satisfies a condition such as wanting to purchase electricity of 10 [kWh] or less among the existing requests related to electricity trading, and determines that matching is not established when the above condition is not satisfied. Since there is no smart contract SC (purchase request) yet on the blockchain 300, the matching unit 130 determines that matching is not established. Then, the processing unit 140 generates a new smart contract SC A including the request A as shown in FIG. 7 and stores it on the blockchain 300.
  • a request purchase request
  • a condition such as wanting to purchase electricity of 10 [kWh] or less among the existing requests related to electricity trading
  • the smart contract SC A including the request A includes at least one of information such as information on the user U who generated the request, the transaction type (electricity purchase, electricity sale, etc.), and information on the token to be used (exchanged) after the transaction is completed. Furthermore, the information of request A is converted into a hash value and stored in the smart contract SC generated by the processing unit 140. By converting request A into a hash value, leakage or tampering of the request information can be suppressed, and the request information can be better protected.
  • the registration unit 150 stores (registers) the generated smart contract SC A on the blockchain 300 as shown in Fig. 7. At this point, request A becomes an existing request.
  • the information management device 100 acquires request B (purchase request) for an electricity transaction to purchase 20 [kWh] of electricity from the user terminal 200-3 of user U3.
  • the matching unit 130 matches request A (existing request) included in smart contract SC A already stored on the blockchain 300 with request B (new request). Since request A wants to sell 10 [kWh] of electricity and request B wants to buy 20 [kWh] of electricity, the matching unit 130 determines that the conditions are not met and matching is not established.
  • the processing unit 140 generates a smart contract SC B including the request B for which matching was not established.
  • the request information in this case may also be converted into a hash value.
  • the registration unit 150 stores the generated smart contract SC B on the blockchain 300 as shown in FIG. 8. At this point, the request B becomes an existing request.
  • the processing unit 140 performs a process (state update process) of adding only a state indicating that matching between request A and request C has been achieved, as information about request C, to the smart contract SC A including the matched request A.
  • a process state update process
  • a part of the information about request C may be added.
  • the added information may be converted into a hash value.
  • a new smart contract SC C including request C is not generated on the blockchain, and a new smart contract SC A+C including both request A and request C is not generated.
  • This makes it possible to suppress an increase in the number of smart contracts SC stored on the blockchain 300 (i.e., the amount of data). Furthermore, it is possible to store more detailed and accurate information on the blockchain 300 with less time lag.
  • the second embodiment differs from the first embodiment in that the request information is stored on a file system 400 other than the block chain 300, and the smart contract SC is not generated by the processing unit 140 but is generated by a program on the block chain 300 in response to an instruction from the processing unit 140.
  • the following mainly focuses on the differences.
  • 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 the information of the new request in the file system 400 that exists outside the blockchain 300 without hashing the information.
  • the assignment unit 144 assigns identification information (CID: Content Identifier) to the information of the new request stored in the file system 400.
  • the CID may be a hash value.
  • the assignment unit 144 performs hashing using the information of the new request, etc. as an input value, and assigns this hash value as the CID for the new request.
  • FIG. 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 FIG. 10 differs from the process of steps S200 to S250 shown in FIG. 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.
  • 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.
  • the assignment unit 144 assigns identification information to the new request in the dataset DS (step S204). Therefore, the dataset DS includes CID information.
  • the matching unit 130 performs matching process between the existing request and the new request included in the dataset stored in the file system 400.
  • step S220 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).
  • the new request included in the smart contract may be converted into a hash value.
  • FIG. 11 is a diagram for explaining the requests of each user U in the second embodiment and the smart contract SC stored on the blockchain 300.
  • the first processing unit 142 stores the data set DS A including the request A in the file system 400 as shown in FIG. 11.
  • the assigning unit 144 assigns identification information (CID) to the request A in the data set DS A.
  • the matching unit 130 matches the new request A with an existing request. If it is determined that matching is not established, the second processing unit 146 outputs an instruction to generate a smart contract SC A including the request A to another smart contract SC (hereinafter referred to as a "generation SC") that stores a program for generating a new smart contract SC and is pre-stored on the blockchain 300.
  • the generation SC executes the program based on the instruction from the second processing unit 146 to generate a smart contract SC A corresponding to the request A and stores it on the blockchain 300.
  • smart contracts SC A and SC B corresponding to requests A and B for which matching was not established are generated by the generation SC.
  • the smart contracts SC A and SC B generated by the generation SC include at least one of information on the user U who generated the request, the transaction type (power purchase, power sale, etc.), information on the token to be used (exchanged) after the transaction is completed, and information for referencing data (dataset) stored in the file system 400. These pieces of information may be hashed.
  • the user terminal 200 queries the information management device 100 about the data set DS using information for referencing the data stored in the file system 400, and can refer to the contents of the data set DS when permission of the information management device 100 is obtained.
  • the first processing unit 142 when request C is acquired, stores the data set DS C including request C in the file system 400.
  • the assigning unit 144 assigns a CID corresponding to request C.
  • the matching unit 130 then matches request A of data set DS A and request B of data set DS B with the new request C, and determines that a match has been established between requests A and C. Therefore, the second processing unit 146 adds information based on the matching result to the smart contract SC A stored on the blockchain 300.
  • the third embodiment differs from the second embodiment 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 matching result is approved by the user U.
  • CID request identification information
  • each process may be executed by the same configuration of the processing unit 140 as in the second embodiment.
  • FIG. 12 is a flowchart showing an example of the matching process and the generation process of a smart contract SC in the third embodiment.
  • the process in FIG. 12 differs from steps S200 to S250 shown in FIG. 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.
  • step S220 of FIG. 12 If it is determined in step S220 of FIG. 12 that matching 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 on the blockchain 300 (the program for the SC for generation) (step S234). If it is determined that matching 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 matching has been established (step S252). Note that the CID stored in the smart contract SC in the processes of steps S234 and S252 may be hashed.
  • 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).
  • the second processing unit 146 determines whether or not approval of 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). 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 performed.
  • FIG. 13 is a diagram for explaining the requests of each user U in the third embodiment and the smart contract SC stored on the blockchain 300.
  • the first processing unit 142 accepts the request A of the user U1 and generates a data set DS A including the request A in the file system 400.
  • the assigning unit 144 assigns a CID to the request A in the data set DS A.
  • the second processing unit 146 uses the generation SC to generate a smart contract SC A including the CID assigned to the request A.
  • FIG. 13 is a diagram for explaining the requests of each user U in the third embodiment and the smart contract SC stored on the blockchain 300.
  • the first processing unit 142 accepts the request A of the user U1 and generates a data set DS A including the request A in the file system 400.
  • the assigning unit 144 assigns a CID to the request A in the data set DS A.
  • the second processing unit 146 uses the generation SC to generate a smart contract SC A including the CID assigned to the request A.
  • a smart contract SC A including the CID of the request A for which matching is not established and a smart contract SC B including the CID of the request B are generated using the generation SC in the same manner.
  • the CIDs stored in the smart contracts SC A and SC B may be hashed.
  • the CID in the smart contract SC it is possible to prove that the request information on which the transaction conditions are based exists outside the blockchain (off-chain), thereby ensuring the validity of the transaction.
  • the personal information of the user U can be protected. For example, if the user U wishes to refer to the request information corresponding to the CID, the user 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 obtained.
  • the matching unit 130 matches request C with requests A and B stored in the data sets DS A and DS B of the file system 400, and determines that a match is established between requests A and C.
  • the second processing unit 146 uses the generation SC to add the CID of request C, for which a match has been established, to the smart contract SC A as information based on the matching result.
  • the processing unit 140 adds the CID of request C to smart contract SC A using the generation SC.
  • the program of the generation SC in the third embodiment includes a program that adds the CID of the matched request to an existing smart contract SC.
  • the providing unit 160 generates information (e.g., an image) regarding 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 adds information to the smart contract SC A depending on whether or not the transaction accepted from the users U1 and U2 is approved.
  • the above-mentioned process corresponds to the display and acceptance process of the matching result in steps S122 and S124 shown in FIG. 4.
  • FIG. 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.
  • FIG. 14 shows, as an example, a case where there is multiple pieces of information (requests) for which matching has been established.
  • the contents of each e.g., trading price, trading volume (amount of electricity)
  • radio buttons check boxes
  • Users U1 and U2 select one of the multiple results by using the radio buttons in image IM20. Note that when matching by the matching unit 130 is not established, information indicating that matching was not established may be displayed in the matching result display area AR21.
  • icon IC21 which is a GUI switch for approving a transaction based on the matching result
  • icon IC22 for rejecting (not approving) the transaction
  • user terminals 200-1, 200-2 accept the selection of icon IC21 by user U1
  • they accept the selection of icon IC22 they transmit information to the information management device 100 indicating that the transaction based on the matching result is rejected (processing of steps S126 and S128 in FIG. 4).
  • the processing unit 140 adds a matching result dataset to the smart contract SCA on the blockchain 300.
  • the information (matching result dataset) stored after the approval of the user U includes, for example, contract information (for example, power amount, transaction price, value-added rate) necessary for calculating the transaction price.
  • the value-added rate may be set based on the information acquired by the processing unit 140 from the outside regarding the market situation of the electricity transaction, or may be set based on the service usage status of the user U, or may be arbitrarily set by the administrator of the trading system 1, etc.
  • the matching result dataset added to the smart contract SCA may be hashed.
  • the matching unit 130 may store all matching results, including successful and unsuccessful matches, performed in the file system 400 as a data set or the like in the file system 400, 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 (for example, in addition to the above contract information, request information for which a match was made, 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.
  • the third embodiment described above not only achieves the same effects as the first embodiment, but also proves that the request that is the basis of the transaction conditions exists off-chain (file system 400) by not storing the request information in the smart contract SC, and only storing the CID associated with the request on the smart contract SC, thereby ensuring the validity of the transaction. Also, by not storing the 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.
  • the matching unit 130 may store the matching results performed within the file system 400 within the file system 400, as in the third embodiment.
  • the DID is a transfer framework that enables data exchange between devices by replacing identification information that identifies personal information such as a user name with an independent ID owned by the device and not managed by a third party, and can protect privacy and ensure the security of transactions.
  • DID-Comm which is a P2P communication protocol
  • DID-Comm distributed data linkage is possible with reduced dependency on the device that manages the entire system.
  • DID-Comm it is possible to verify, for example, the certification of the qualification information (user information) of the transmitted data.
  • the communication protocol used in the embodiment is not limited to DID-Comm.
  • the charge/discharge CS 500 registers information on the DID used in the transfer of information on the current energy transaction in the file system 400 ((1) in FIG. 15).
  • the information management device 100 also registers information on the DID and DID-Comm used by the charge/discharge CS 500 in the file system 400 ((2) in FIG. 15).
  • the information management device 100 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 transactionable time (start time, end time) for charge/discharge included in requests A and C of users U1 and U2, and transmits the generated schedule information and information on users U1 and U2 to the charge/discharge CS 500 ((3) in FIG. 15).
  • 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 above information may be provided by the providing unit 160 of the information management device 100 instead of the charge/discharge CS 500.
  • 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 shows an example of an image displayed on the user terminal 200-2 that has sent a purchase request from the side buying electricity (the buyer side).
  • 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 electricity purchase status (or electricity sales status) (for example, remaining charge amount, remaining discharge amount), identification information (charging/discharging equipment ID) and information regarding the location (installation position) of the charging/discharging equipment 520 to which the electric vehicle M is connected.
  • the transaction status display area AR31 may also display information indicating that electricity trading is in progress or has been completed.
  • the transaction summary display area AR32 displays information regarding the electricity transaction (transaction), such as the start time, end time, total amount of electricity, and total cost of charging (or discharging).
  • 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/discharging is completed.
  • Icon IC32 is a switch for ending the display of image IM30.
  • icon IC31 is selected by user U2
  • the transaction application 272 causes an image showing a receipt for the current energy transaction to be displayed on the display 232, and when icon IC32 is selected, the transaction application 272 ends the display of image IM30.
  • the users U1 and U2 move the electric vehicles M1 and M2 they use to the charging/discharging equipment 520 managed by the charging/discharging CS 500, and connect the electric vehicles M1 and M2 to the charging/discharging equipment 520 that corresponds to the charging/discharging equipment 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 equipment 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.
  • the electric vehicle M1 of user U1 is connected to the charging/discharging equipment 520-1
  • the electric vehicle M2 of user U2 is connected to the charging/discharging equipment 520-2.
  • the charging/discharging equipment 520-1, 520-2 acquires the identification information (vehicle ID) of the electric vehicles M1, M2 by connecting to the electric vehicles M1, M2, and outputs the acquired vehicle ID to the charging/discharging CS 500. If the vehicle ID is a vehicle ID that has been permitted to be used in advance (scheduled), the charging/discharging CS 500 starts a charging/discharging session (electricity trading by charging/discharging) and transmits information related to charging/discharging (e.g., charging/discharging information, charging/discharging results, session end) to the information management device 100 ((5) in FIG. 15). The information management device 100 stores the electric power trading status, etc.
  • vehicle ID vehicle ID that has been permitted to be used in advance
  • the charging/discharging CS 500 starts a charging/discharging session (electricity trading by charging/discharging) and transmits information related to charging/discharging (e.g., charging/discharging information, charging/discharging results, session end
  • FIG. 17 is a diagram for explaining the management of the transaction status during a charge/discharge session.
  • a smart contract SC A including a data set of the CID and the matching result corresponding to the requests A and C for which matching of the third embodiment shown in FIG. 13 has been established is stored on the blockchain 300.
  • the example of FIG. 17 shows the management contents of the transaction status during charging/discharging, completion of charging/discharging, and at the end of the session.
  • the charge/discharge CS 500 transmits information regarding 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 charge/discharge session based on the transmitted information.
  • FIG. 18 is a flowchart showing an example of processing executed by the information management device 100 during a charge/discharge session.
  • the processing in FIG. 18 may be executed repeatedly at a predetermined cycle or at a predetermined timing during a charge/discharge session.
  • the acquisition unit 120 of the information management device 100 determines whether or not information regarding charging/discharging has been acquired from the charge/discharge CS 500 (or the charge/discharge equipment 520-1, 520-2) (step S300).
  • the acquisition unit 120 determines whether the acquired information is charging information or not (step S310).
  • the processing unit 140 (first processing unit 142) generates a dataset DS1 corresponding to the charging information as shown in FIG. 13, and stores it in the file system 400 (step S320).
  • the dataset DS1 includes, for example, information regarding the charging and discharging facility ID, charging and discharging time (timestamp), user information, vehicle ID, and 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).
  • step S320 if the dataset DS1 already exists in the file system 400, the changed portion of the dataset DS1 may be updated, or the stored previous dataset DS1 may be deleted and a new dataset DS1 may be stored in the file system 400. Furthermore, the dataset DS1 may include information on both the charging side and the discharging side, and each may be stored as a separate dataset.
  • the acquisition unit 120 determines whether the acquired information regarding charging and discharging is a charging and discharging result to be sent when charging is completed (step S330). If it is determined that the information is a charging and discharging result, the processing unit 140 generates a data set DS2 indicating the charging and discharging result as shown in FIG. 17, and stores the generated data set DS2 in the file system 400 (step S340). In addition to information similar to that of the data set DS1, the data set DS2 includes information indicating that the transaction is complete and information such as the total amount of charging (or discharging) by the session.
  • the processing unit 140 calculates the final transaction amount based on the data set DS1 of the charge/discharge information, the data set DS2 of the charge/discharge results, and the 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 amount (step S350).
  • the transaction information may include, for example, information indicating whether the transaction has been completed.
  • the data set DS3 stores session information (information obtained during communication).
  • the session information includes at least one of the following information: 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 by the session.
  • identification information charge/discharge ID
  • CID identification information
  • user ID the power consumer
  • step S330 if it is determined 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 end information (step S360). If it is determined that the information on charging/discharging is session end information, the second processing unit 146 adds a 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) to the smart contract SC A stored on the blockchain 300 (step S370), and stores it on the blockchain 300 (step S380).
  • a data set for example, at least a part of the contents of the data set DS3
  • the second processing unit 146 hashes the session information included in the data set (power trading result) to be added to the smart contract SC A , and adds the transaction information to the smart contract SC A without hashing it.
  • the second processing unit 146 may add information (status information) that proves that charging/discharging has ended to the smart contract SC A. This ends the process of the flowchart shown in FIG. 18.
  • step S300 if it is determined that the information on charging/discharging has not been acquired, the process of this flowchart ends.
  • the session information including the user's identification information is hashed and stored on the blockchain 300 without revealing the contents of the data, thereby protecting the privacy information of the 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, the final settlement amount can be calculated correctly and quickly.
  • the above-mentioned smart contract SC A includes the CID and matching result data set corresponding to request A, and thus this information can be used to obtain request information, etc. from the file system 400, etc.
  • 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 may be one of the nodes constituting the file system 400 (IPFS network).
  • the information management device 100 may be configured integrally with the blockchain 300, or may be configured integrally with the file system 400.
  • the information management device 100 may also be configured integrally with the charge/discharge CS 500.
  • 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.
  • electricity from an electric vehicle M (more specifically, battery B) owned by a user U has been described, but in addition to (or instead of) electricity from the electric vehicle M, electricity may be obtained from solar power generation, wind power generation, hydroelectric power generation, thermal power generation, geothermal power generation, etc.
  • 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.
  • the information management device 100 includes 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. This makes it possible to reduce the amount of data stored on the blockchain 300 while managing information more accurately.
  • the request information stored in the blockchain 300 is hashed, thereby making it possible to better protect 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, making it possible to more accurately manage each piece of information.
  • a storage medium for storing computer-readable instructions of an information management device that mediates transactions between users and manages transaction results by storing smart contracts related to the transactions on a blockchain; a processor coupled to the storage medium; The processor executes the computer-readable instructions to: Receive purchase or sale requests from users; Matching the newly acquired new request with an existing request included in a smart contract already stored on the blockchain; If the matching is not established, a smart contract including the new request is generated on the blockchain; When the matching is established, adding information of the new request to a smart contract including the existing request with which the matching is established; Information management device.
  • 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 storage 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 storage unit, 300...blockchain, 400...file system, 500...charging/discharging CS, 520...charging/discharging equipment, M...electric vehicle

Landscapes

  • Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Public Health (AREA)
  • Water Supply & Treatment (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

実施形態の情報管理装置は、ユーザ間の取引を仲介し、ブロックチェーン上に前記取引に関するスマートコントラクトを記憶させることで取引結果を管理する情報管理装置であって、ユーザから受け付けた購買または販売に関するリクエストを取得する取得部と、前記取得部により新規に取得した新規リクエストと、既に前記ブロックチェーン上に記憶されたスマートコントラクトに含まれる既存リクエストとのマッチングを行うマッチング部と、前記マッチングが成立しなかった場合に前記ブロックチェーン上に前記新規リクエストを含むスマートコントラクトを生成し、前記マッチングが成立した場合にマッチングが成立した前記既存リクエストを含むスマートコントラクトに前記新規リクエストの情報を追加する処理部と、を備える。

Description

情報管理装置、情報管理方法、およびプログラム
　本発明は、情報管理装置、情報管理方法、およびプログラムに関する。
　近年、ブロックチェーンを用いて情報を記録する技術が研究されている。これに関連して、取引に関するトランザクション情報の記録の頻度を抑えるために、所定期間ごとに情報をまとめてブロックチェーンネットワーク上に記憶する技術が知られている（例えば、特許文献１参照）。
特開２０２２－４６７５７号公報
　しかしながら、従来技術のように所定期間ごとに情報を記憶する場合にはブロックチェーン上のデータ量等のコストは低減されるが、実際の取引状況とのタイムラグが発生するため、１つ１つの情報を正確に管理できない場合があるという課題があった。
　本願は上記課題の解決のため、ブロックチェーン上に記憶する情報のデータ量を低減させつつ、より正確に情報を管理することができる情報管理装置、情報管理方法、およびプログラムを提供することを目的の一つとしたものである。
　この発明に係る情報管理装置、情報管理方法、およびプログラムは、以下の構成を採用した。
　（１）：この発明の一態様に係る情報管理装置は、ユーザ間の取引を仲介し、ブロックチェーン上に前記取引に関するスマートコントラクトを記憶させることで取引結果を管理する情報管理装置であって、ユーザから受け付けた購買または販売に関するリクエストを取得する取得部と、前記取得部により新規に取得した新規リクエストと、既に前記ブロックチェーン上に記憶されたスマートコントラクトに含まれる既存リクエストとのマッチングを行うマッチング部と、前記マッチングが成立しなかった場合に前記ブロックチェーン上に前記新規リクエストを含むスマートコントラクトを生成し、前記マッチングが成立した場合にマッチングが成立した前記既存リクエストを含むスマートコントラクトに前記新規リクエストの情報を追加する処理部と、を備える情報管理装置である。
　（２）：上記（１）の態様において、前記処理部は、ハッシュ値化された前記新規リクエストの情報を含むスマートコントラクトを生成するものである。
　（３）：上記（１）の態様において、前記処理部は、予め前記ブロックチェーン上に記憶されたプログラムにより前記新規リクエストを含むスマートコントラクトを生成させるものである。
　（４）：上記（３）の態様において、前記ブロックチェーンは、イーサリアムである。
　（５）：上記（１）の態様において、前記取引は、電力取引を含み、前記リクエストは、電力の購買または販売に関するリクエストを含み、前記処理部は、前記リクエストに対する電力取引結果を前記スマートコントラクトに追加するものである。
　（６）：上記（１）の態様において、前記スマートコントラクトは、前記ユーザに関する情報、取引種別、取引完了後に交換されるトークンに関する情報、および前記ブロックチェーン外の記憶部に記録される前記リクエストに関する情報を参照するための情報のうち、少なくとも一つを含むものである。
　（７）：上記（１）の態様において、前記処理部は、前記ユーザ間の取引におけるセッション情報をハッシュ値化して前記ブロックチェーン上に記憶させ、取引額および取引量を含む取引情報をハッシュ値化せずにブロックチェーン上に記憶させるものである。
　（８）：この発明の一態様に係る情報管理方法は、ユーザ間の取引を仲介し、ブロックチェーン上に前記取引に関するスマートコントラクトを記憶させることで取引結果を管理する情報管理装置が、ユーザから受け付けた購買または販売に関するリクエストを取得し、新規に取得した新規リクエストと、既に前記ブロックチェーン上に記憶されたスマートコントラクトに含まれる既存リクエストとのマッチングを行い、前記マッチングが成立しなかった場合に前記ブロックチェーン上に前記新規リクエストを含むスマートコントラクトを生成し、前記マッチングが成立した場合にマッチングが成立した前記既存リクエストを含むスマートコントラクトに前記新規リクエストの情報を追加する、情報管理方法である。
　（９）：この発明の一態様に係るプログラムは、ユーザ間の取引を仲介し、ブロックチェーン上に前記取引に関するスマートコントラクトを記憶させることで取引結果を管理する情報管理装置に、ユーザから受け付けた購買または販売に関するリクエストを取得させ、新規に取得した新規リクエストと、既に前記ブロックチェーン上に記憶されたスマートコントラクトに含まれる既存リクエストとのマッチングを行わせ、前記マッチングが成立しなかった場合に前記ブロックチェーン上に前記新規リクエストを含むスマートコントラクトを生成させ、前記マッチングが成立した場合にマッチングが成立した前記既存リクエストを含むスマートコントラクトに前記新規リクエストの情報を追加させる、プログラムである。
　上記（１）～（９）の態様によれば、ブロックチェーン上に記憶する情報のデータ量を低減させつつ、より正確に情報を管理することができる。
実施形態の情報管理装置を利用した取引システム１の構成図である。 実施形態の情報管理装置１００の構成図である。 実施形態のユーザ端末２００の構成図である。 実施形態における電力取引の一連の流れについて説明するためのシーケンス図である。 リクエスト生成処理において、ユーザ端末２００に表示される画像ＩＭ１０の一例を示す図である。 第１実施例におけるマッチング処理およびスマートコントラクトの生成処理の一例を示すフローチャートである。 第１実施例において各ユーザＵから受け付けられるリクエストについて説明するための図である。 第１実施例においてブロックチェーン３００上に記憶されるスマートコントラクトＳＣについて説明するための図である。 第２実施例における処理部１４０の具体的な構成の一例を示す図である。 第２実施例におけるマッチング処理およびスマートコントラクトＳＣの生成処理の一例を示すフローチャートである。 第２実施例における各ユーザＵのリクエストとブロックチェーン３００上に記憶されるスマートコントラクトＳＣを説明するための図である。 第３実施例におけるマッチング処理およびスマートコントラクトＳＣの生成処理の一例を示すフローチャートである。 第３実施例における各ユーザＵのリクエストとブロックチェーン３００上に記憶されるスマートコントラクトＳＣについて説明するための図である。 マッチング結果に関する画像ＩＭ２０の一例を示す図である。 電力取引に関する処理について説明するための図である。 電力取引状況に関する画像ＩＭ３０の一例を示す図である。 充放電セッション中における取引状況の管理について説明するための図である。 充放電セッション中における情報管理装置１００により実行される処理の一例を示すフローチャートである。
　以下、図面を参照し、本発明の情報管理装置、情報管理方法、およびプログラムの実施形態について説明する。なお、以下では、情報管理装置が、ユーザ間で取引を行う取引システム（個人間取引システム）に適用された例について説明する。また、以下では、取引の一例として電力取引を用いて説明するが、電力取引に代えて（または加えて）、クレジット取引等や、他の商品やサービスの取引であってもよい。
　［全体構成］
　図１は、実施形態の情報管理装置を利用した取引システム１の構成図である。取引システム１は、例えば、情報管理装置１００と、一以上のユーザ端末２００－１～２００－ｎと、ブロックチェーン３００と、ファイルシステム４００と、充放電コントロールシステム（以下、充放電ＣＳと称する）５００と、充放電設備５２０とを備える。情報管理装置１００と、ユーザ端末２００と、ブロックチェーン３００と、充放電ＣＳ５００とは、例えば、ネットワークＮＷ等を介して互いに通信可能である。ネットワークＮＷは、例えば、セルラー網や、Ｗｉ－Ｆｉ網、Ｂｌｕｅｔｏｏｔｈ（登録商標）、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、公衆回線、プロバイダ装置、専用回線、無線基地局等を含む。ファイルシステム４００は、「記憶部」の一例である。
　情報管理装置１００は、例えば、サーバ装置やＰＣ（Personal Computer）でもよく、一以上の情報処理装置からなるクラウドコンピューティングにより構成されたクラウドサーバ等でもよい。また、情報管理装置１００は、ブロックチェーン３００またはファイルシステム４００上に記憶するデータに対する処理を行うエッジサーバとしての機能を有していてもよい。情報管理装置１００は、ユーザ間の個人間取引を仲介する。例えば、情報管理装置１００は、ブロックチェーン３００上に記憶する電力取引に関する情報（例えば、スマートコントラクトＳＣ等）を生成したり、ファイルシステム４００に記憶する電力取引に関する情報（例えば、データセットＤＳ）を生成する。
　ユーザ端末２００は、ユーザＵ（需要家）が使用する装置であり、例えば、スマートフォンやタブレット端末、ＰＣ等である。ユーザ端末２００は、ユーザＵにより入力された取引に関するリクエスト（例えば、購買リクエストや売電リクエスト）を受け付け、受け付けたリクエストを情報管理装置１００に送信する。また、ユーザ端末２００は、情報管理装置１００により電力取引に関する情報を受信して、画像表示や音声出力によりユーザＵに提供する。図１の例では、ユーザＵが所有する電動車両Ｍに搭載されるバッテリＢの電力に関する取引を行う。電動車両Ｍは、例えば、バッテリＢから供給される電力によって駆動される電動機（電動モータ）によって走行するＢＥＶ（Battery Electric Vehicle：電気自動車）である。代替的に、電動車両は、ハイブリッド車両に外部充電機能を持たせたＰＨＶ（Plug-in Hybrid Vehicle）またはＰＨＥＶ（Plug-in Hybrid Electric Vehicle）であってもよい。なお、電動車両Ｍは、例えば、四輪の車両のみならず、鞍乗り型の二輪の車両や、三輪（前一輪かつ後二輪の他に、前二輪かつ後一輪の車両も含む）の車両、アシスト式の自転車、電動キックボード等、バッテリから供給される電力によって駆動される電動モータによって走行する「移動体」の全般が含まれる。
　ブロックチェーン３００は、ブロックと呼ばれる単位で取引に関する情報を管理し、その情報を連結して前後関係（順序性）を明確化させて記憶するデータストア（データベース）である。ブロックチェーン３００は、互いにアクセス可能な複数の装置（ノード）により構成されるブロックチェーンネットワークでもよい。ブロックチェーン３００は、例えば、イーサリアム(Ethereum)である。イーサリアムは、スマートコントラクトＳＣをブロックとして、ブロックチェーン３００上でプログラムやその動作を管理することが可能な分散型のアプリケーションプラットフォームである。実施形態では、パブリックブロックチェーンの中でも非改ざん性および信頼性がより高いイーサリアムを使用することでより取引の安全性を担保することができる。
　スマートコントラクトＳＣには、例えば、電力取引に関するリクエスト情報や電力取引情報等のデータがトランザクションとして格納される。トランザクションには、上記情報の他、所定の条件が満たされた場合に自動的に実行されるソフトウェア（コンピュータプログラム）が含まれていてもよい。また、スマートコントラクトＳＣには、一つ前（直前）のブロック（トランザクション）に基づいて生成されたハッシュ値が含まれる。スマートコントラクトＳＣに新たにデータを追加する場合には、例えば、一つ前のブロックのハッシュ値と、格納するデータ（例えば、取引データ）と、ナンス値とを含む新たなブロックをハッシュ値化（例えば、上記ブロックをハッシュ関数に入力しハッシュ値を算出）し、算出したハッシュ値とブロックとを格納することでスマートコントラクトＳＣに過去のブロックと連結してデータを格納することができる。
　ブロックチェーン３００上にスマートコントラクトＳＣを生成して記憶（保存）させる処理は、ブロックチェーン３００に接続されたノードおよび情報管理装置１００によって実行可能である。また、ブロックチェーン３００では、複数の端末がスマートコントラクトＳＣを保存し相互に照合等を行うことができる。以下の説明において、ブロックチェーン３００は「オンチェーン」と称される場合がある。
　ファイルシステム４００は、例えば、ＩＰＦＳ（Inter Planetary File System）によるＰ２Ｐ（Peer to Peer）方式の分散型ファイルシステムである。ファイルシステム４００は、互いにアクセス可能な複数の装置（ノード）により構成されるＩＰＦＳネットワークでもよい。ファイルシステム４００は、電力取引に関する情報を含むデータセット（電子データ）ＤＳを格納する。ファイルシステム４００は、情報管理装置１００と接続されており、情報管理装置１００によって格納されるデータセットＤＳが管理される。データセットＤＳは、ユーザ端末２００等がネットワークＮＷを介して直接参照できないようにセキュアな環境となっている。そのため、ファイルシステム４００内に記憶されるデータはハッシュ値化がされていなくてもよい。以下の説明において、ファイルシステム４００は、「オフチェーン」または「バックエンド」と称される場合がある。
　充放電ＣＳ５００は、充放電設備５２０に接続された電動車両ＭのバッテリＢの充電または放電を管理する。充放電設備５２０は、電動車両Ｍと接続することで、電動車両ＭのバッテリＢに電力を供給して充電させたり、バッテリＢから放電された電力を外部に供給したりする。充放電ＣＳ５００は、各地点に設置された複数の充放電設備５２０の位置情報や電動車両Ｍの充放電スケジュール等を管理する。また、充放電ＣＳ５００は、情報管理装置１００からの制御情報に基づいて、充放電に関する制御を行ってもよく、充放電結果を情報管理装置１００に送信してもよい。次に、情報管理装置１００およびユーザ端末２００の構成について具体的に説明する。
　［情報管理装置］
　図２は、実施形態の情報管理装置１００の構成図である。情報管理装置１００は、例えば、通信部１１０と、取得部１２０と、マッチング部１３０と、処理部１４０と、登録部１５０と、提供部１６０と、装置側記憶部１７０とを備える。取得部１２０と、マッチング部１３０と、処理部１４０と、登録部１５０と、提供部１６０とは、例えば、ＣＰＵ（Central Processing Unit）等のハードウェアプロセッサがプログラム（ソフトウェア）を実行することにより実現される。また、これらの構成要素のうち一部または全部は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）、ＧＰＵ（Graphics Processing Unit）等のハードウェア（回路部；circuitryを含む）によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。プログラムは、予め情報管理装置１００が備えるＨＤＤ（Hard Disk Drive）やフラッシュメモリ等の記憶装置（非一過性の記憶媒体を備える記憶装置）に格納されていてもよいし、ＤＶＤやＣＤ－ＲＯＭ等の着脱可能な記憶媒体（非一過性の記憶媒体）に格納されており、記憶媒体が、情報管理装置１００が備えるドライブ装置に装着されることで情報管理装置１００が備えるＨＤＤやフラッシュメモリにインストールされてもよい。
　装置側記憶部１７０は、上記の各種記憶装置、或いはＳＳＤ（Solid State Drive）、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）、ＲＯＭ（Read Only Memory）、またはＲＡＭ（Random Access Memory）等により実現されてよい。装置側記憶部１７０には、例えば、ユーザ情報ＤＢ（Database）１７２、情報管理装置１００の処理結果、プログラム、その他各種情報が格納される。ユーザ情報ＤＢ１７２には、例えば、取引システム１を利用するユーザＵに関する情報（例えば、ユーザＩＤやユーザＵのアドレス情報）と、ユーザＵが利用するユーザ端末２００に関する情報（例えば、端末ＩＤ）と、ユーザＵが利用する電動車両Ｍに関する情報（例えば、車両ＩＤ）とがそれぞれ対応付けられている。端末ＩＤ、車両ＩＤ等は、それぞれの装置に割り当てられているＭＡＣ（Media Access Control）アドレスであってもよい。ユーザ情報ＤＢ１７２には、ユーザＵごとに一以上のユーザ端末２００が対応付けられていてもよく、一以上の電動車両Ｍが対応付けられていてもよい。
　通信部１１０は、ネットワークＮＷを介して、ユーザ端末２００、ブロックチェーン３００、充放電ＣＳ５００、その他の外部装置と通信を行う。また、通信部１１０は、例えば、専用回線等によりファイルシステム４００と通信を行う。
　取得部１２０は、通信部１１０が受信した情報に基づいて、取引システム１におけるサービスを利用するユーザＵに関する情報を取得する。また、取得部１２０は、ユーザＵから購買または販売に関するリクエストを取得したり、充放電ＣＳ５００から電力の充放電（電力取引）の状況や取引結果に関する情報を取得する。
　マッチング部１３０は、ブロックチェーン３００上に記憶させるスマートコントラクトＳＣの生成前に、取得部１２０により新規に取得した新規リクエスト（受付リクエスト）と、既にブロックチェーン３００上に記憶されたスマートコントラクトＳＣに保存された既存リクエストとのマッチングを行う。
　処理部１４０は、マッチング部１３０により新規リクエストと既存リクエストとのマッチングが成立しなかった場合に新規リクエストを含むスマートコントラクトＳＣを生成する。また、処理部１４０は、上記マッチングが成立した場合にマッチングが成立した既存リクエストを含むスマートコントラクトＳＣに、新規リクエストに関する情報を追加する。なお、実施形態において、「追加する」とは、スマートコントラクトＳＣ内の一部の情報が変更、編集、削除、更新されることが含まれてもよい。処理部１４０の機能の詳細については後述する。
　登録部１５０は、処理部１４０により生成されたスマートコントラクトＳＣをブロックチェーン３００上に記憶する（登録する）。なお、処理部１４０は、登録部１５０を介さずに、ブロックチェーン３００上にスマートコントラクトＳＣを生成してもよい。
　また、登録部１５０は、取引システム１により提供されるサービスを利用するユーザＵの登録を管理してもよい。この場合、登録部１５０は、ユーザＵの新規登録を行って新たなユーザ情報をユーザ情報ＤＢ１７２に登録する。また、登録部１５０は、サービスを利用するためにアクセスしてきたユーザＵやユーザ端末２００の識別情報と、ユーザ情報ＤＢ１７２に登録された識別情報とを比較し、合致する識別情報が登録されている場合にサービスの利用を許可し、識別情報が登録されていない場合にサービスの利用を拒否するといった制御等を行う。
　提供部１６０は、ユーザ端末２００や充放電ＣＳ５００に対し、各種情報を提供する。例えば、提供部１６０は、マッチング部１３０によるマッチング結果に関する情報（画像、音声）を生成し、生成した情報をユーザ端末２００に提供する。また、提供部１６０は、マッチング部１３０によりマッチングが成立した場合に、充放電を行う電動車両ＭやユーザＵに関する情報を充放電ＣＳ５００に提供する。
　［ユーザ端末］
　図３は、実施形態のユーザ端末２００の構成図である。ユーザ端末２００は、例えば、端末側通信部２１０と、入力部２２０と、出力部２３０と、位置情報取得部２４０と、制御部２５０と、アプリ実行部２６０と、端末側記憶部２７０とを備える。位置情報取得部２４０と、制御部２５０と、アプリ実行部２６０とは、それぞれ、例えば、ＣＰＵ等のハードウェアプロセッサがプログラム（ソフトウェア）を実行することにより実現される。また、これらの構成要素のうち一部または全部は、ＬＳＩやＡＳＩＣ、ＦＰＧＡ、ＧＰＵ等のハードウェア（回路部；circuitryを含む）によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。プログラムは、予めユーザ端末２００が備えるＨＤＤやフラッシュメモリ等の記憶装置（非一過性の記憶媒体を備える記憶装置）に格納されていてもよいし、ＤＶＤやＣＤ－ＲＯＭ等の着脱可能な記憶媒体（非一過性の記憶媒体）に格納されており、記憶媒体が、ユーザ端末２００が備えるドライブ装置に装着されることでユーザ端末２００が備えるＨＤＤやフラッシュメモリにインストールされてもよい。
　端末側記憶部２７０は、上記の各種記憶装置、或いはＳＳＤ、ＥＥＰＲＯＭ、ＲＯＭ、またはＲＡＭ等により実現されてよい。端末側記憶部２７０には、例えば、取引アプリ２７２、ユーザ端末２００の処理結果、プログラム、その他各種情報が格納される。
　端末側通信部２１０は、例えば、ネットワークＮＷを介して情報管理装置１００、その他の外部装置と通信を行う。また、端末側通信部２１０は、近距離通信によってユーザＵが利用する電動車両Ｍと通信を行ってもよい。
　入力部２２０は、例えば、各種キーやボタン等の操作によるユーザＵの入力を受け付ける。入力部２２０は、例えば、マイクを備えユーザＵの音声の入力を受け付けてもよい。
　出力部２３０は、例えば、ディスプレイ２３２やスピーカ２３４を備える。ディスプレイ２３２は、例えば、ＬＣＤ（Liquid Crystal Display）や有機ＥＬ（Electro Luminescence）ディスプレイ等である。出力部２３０は、制御部２５０やアプリ実行部２６０の制御により、各種画像をディスプレイ２３２に表示したり、音声をスピーカ２３４から出力する。また、ディスプレイ２３２は、例えばタッチパネルとして入力部２２０の機能も有してよい。
　位置情報取得部２４０は、内蔵されたＧＰＳ（Global Positioning System）装置によりユーザ端末２００の位置情報（例えば、緯度経度情報）を取得する。
　制御部２５０は、ユーザ端末２００の各構成要素全体を制御する。制御部２５０は、入力部２２０により受け付けられた情報を端末側記憶部２７０に記憶させたり、端末側通信部２１０を介して情報管理装置１００に送信させたりする。また、制御部２５０は、例えば、端末側通信部２１０を介して情報管理装置１００から取得した画像や音声等の情報を出力部２３０から出力させてもよく、情報管理装置１００から取得した情報に基づいて画像や音声を生成して、出力部２３０から出力させてもよい。
　アプリ実行部２６０は、端末側記憶部２７０に記憶された取引アプリ２７２が実行されることで実現される。取引アプリ２７２は、例えば、ネットワークＮＷを介して外部装置からダウンロードしたものがユーザ端末２００にインストールされている。取引アプリ２７２は、入力部２２０により入力された情報（リクエスト情報）、および位置情報取得部２４０により取得された位置情報、ユーザ端末２００の識別情報、ユーザ情報等を情報管理装置１００に送信したり、リクエスト結果等に関する情報や電力取引に関する情報を取得して出力部２３０に出力させる。
　［電力取引の流れ］
　次に、実施形態の取引システム１を用いた電力取引の流れについて具体的に説明する。図４は、実施形態における電力取引の一連の流れについて説明するためのシーケンス図である。図４では、一例として、ユーザＵ１が使用するユーザ端末２００－１、ユーザＵ２が使用するユーザ端末２００－２、情報管理装置１００、ブロックチェーン３００、充放電ＣＳ５００における処理を示している。ユーザＵ１およびＵ２は、ともに取引システム１のサービスの提供を利用できるユーザ（登録部１５０によりサービスの利用が許可されたユーザ）であるものとする。また、以下では、ユーザＵ１が利用する電動車両Ｍ１に搭載されたバッテリＢ１とユーザＵ２が利用する電動車両Ｍ２に搭載されたバッテリＢ２との間で電力融通取引を行う例について説明する。
　図４の例において、ユーザ端末２００－１の取引アプリ２７２は、ユーザＵ１により入力された情報に基づいて電力取引に関するリクエストを生成し（ステップＳ１００）、生成したリクエストを情報管理装置１００に送信する（ステップＳ１０２）。
　情報管理装置１００のマッチング部１３０は、ユーザ端末２００－１から送信されたリクエストを受信し、受信したリクエスト（新規リクエスト）に基づいてブロックチェーン３００上に既に記憶されたスマートコントラクトＳＣに含まれる他のリクエスト（既存リクエスト）とのマッチングを行う（ステップＳ１０４）。ステップＳ１０４の処理では、マッチングが不成立であった（新規リクエストの条件に合致する既存リクエストが存在しなかった）ものとする。この場合、情報管理装置１００の処理部１４０は、ブロックチェーン３００に新規リクエストを含むスマートコントラクトＳＣを生成してブロックチェーン３００に送信し（ステップＳ１０６）、ブロックチェーン３００上にスマートコントラクト（ＳＣ）を記憶する（ステップＳ１０８）。
　次に、ユーザＵ２は、ユーザ端末２００－２を用いて取引アプリ２７２を起動し、ユーザＵ１と同様に電力取引に関するリスエストを入力する。ユーザ端末２００－２は、入力された情報に基づいてリクエストを生成し（ステップＳ１１０）、生成したリクエスト情報を情報管理装置１００に送信する（ステップＳ１１２）。
　マッチング部１３０は、ユーザ端末２００－２から送信されたリクエスト（新規リクエスト）を取得し、ブロックチェーン３００上に記憶されたスマートコントラクトＳＣを参照して既存リクエストとのマッチングを行う（ステップＳ１１４）。以下、ユーザＵ１とユーザＵ２のそれぞれのリクエストでマッチングが成立したとして説明を続ける。情報管理装置１００の提供部１６０は、マッチングした結果に関する情報（例えば、画像）を生成し（ステップＳ１１６）、ユーザ端末２００－１、２００－２に送信する（ステップＳ１１８、Ｓ１２０）。
　ユーザ端末２００－１、２００－２のそれぞれは、情報管理装置１００から送信されたマッチング結果に関する情報を表示するとともに、ユーザＵ１、Ｕ２からの指示情報等を受け付ける（ステップＳ１２２、Ｓ１２４）。ユーザＵ１、Ｕ２からの情報としては、マッチング結果による電力取引を承認するか、拒否するかの情報であってもよく、条件にマッチした対象が複数存在した場合に、その何れかを選択した内容であってもよい。ユーザ端末２００－１、２００－２のそれぞれは、ユーザＵ１、Ｕ２のそれぞれから得られる情報を情報管理装置１００に送信する（ステップＳ１２６、Ｓ１２８）。
　情報管理装置１００は、ユーザ端末２００－１、２００－２からの情報を取得し、マッチングが承認されている場合に、充放電ＣＳ５００に電力取引に関する情報（例えば、電力取引を行うユーザＵ１、Ｕ２や電動車両Ｍ１、Ｍ２に関する情報）を出力する（ステップＳ１３０）。充放電ＣＳ５００は、情報管理装置１００から取得した情報に基づいて、電力取引管理を行う（ステップＳ１３２）。具体的には、対象の電動車両Ｍが接続する充放電設備５２０を設定し、設定した充放電設備５２０の位置情報や利用時間（スケージュール）等の情報をユーザ端末２００－１、２００－２に送信する（ステップＳ１３４、Ｓ１３６）。なお、電力取引を行うスケジュール等の情報は、情報管理装置１００から提供されてもよい。
　また、充放電ＣＳ５００は、ステップＳ１３４、Ｓ１３６以外の電力取引管理に関する処理も行う。例えば、充放電ＣＳ５００は、充放電設備５２０に利用するユーザＵ１、Ｕ２および電動車両Ｍ１、Ｍ２に関する情報を充放電設備５２０に送信して事前予約を行い、予約時間に他の電動車両Ｍが利用できないようにする。また、充放電ＣＳ５００は、充放電設備５２０から得られる情報に基づいて、放電状況および充電状況を管理する。例えば、ユーザＵ１が電力を売る側（売り手）で、ユーザＵ２が電力を買う側（買い手）である場合、ユーザＵ１の電動車両Ｍ１のバッテリＢ１から放電された電力を、電動車両Ｍ２と接続中の充放電設備５２０が受け取り、受け取った電力を電動車両Ｍ２が接続中の充放電設備５２０を介して、電動車両Ｍ２のバッテリＢ２に供給する。これらの充放電状況は、充放電設備５２０からの情報に基づいて充放電ＣＳ５００で随時管理される。
　なお、充放電ＣＳ５００は、取引状況に関する情報をユーザ端末２００－１、２００－２に送信してもよい。また、充放電設備５２０は、電力取引状況（充放電状況）に関する情報を所定のタイミングで情報管理装置１００に送信する（ステップＳ１３８）。電力取引状況に関する情報には、例えば、電動車両Ｍ１またはＭ２の充放電中の状況を示す充電情報（ステータスデータ）、充放電完了を示す情報（充電結果）、電動車両Ｍ１、Ｍ２の充放電設備５２０との接続の終了を示す情報（セッション終了情報）等が含まれる。なお、充電情報は、所定周期で情報管理装置１００に送信され、充電結果は充電完了時、セッション終了情報は充放電設備５２０と電動車両Ｍとの接続終了時に情報管理装置１００に送信される。
　情報管理装置１００の処理部１４０は、充放電ＣＳ５００から電力取引状況に関する情報を受信し、受信した情報に対してファイルシステム４００にデータセットＤＳ等を生成する（ステップＳ１４０）。また、情報管理装置１００は、ブロックチェーン３００上に記憶されたマッチング対象の既存リクエストを含むスマートコントラクトＳＣに充電セッション結果（電力取引結果）等を追加し（ステップＳ１４２）、追加したスマートコントラクトＳＣを記憶する（ステップＳ１４４）。
　次に、上述した電力取引の流れの各処理の詳細について説明する。
　［リクエスト生成処理：ステップＳ１００、Ｓ１１０］
　ユーザ端末２００－１、２００－２のそれぞれがリクエストを生成する場合、取引アプリ２７２は、ユーザ端末２００－１、２００－２にリクエストを入力する画像をディスプレイ２３２に表示させる。この画像は、情報管理装置１００の提供部１６０から提供されてよい。また、画像に対応した音声が出力されてもよい。
　図５は、リクエスト生成処理において、ユーザ端末２００に表示される画像ＩＭ１０の一例を示す図である。図５に示す画像ＩＭ１０は、ステップＳ１００の処理においてユーザ端末２００－１に、ステップＳ１１０の処理において、ユーザ端末２００－２に表示される画像である。なお、画像ＩＭ１０のレイアウトや文字フォント、大きさ、表示内容等の表示態様については、図５の例に限定されない。後述する他の画像についても同様とする。図５に示す画像ＩＭ１０には、例えば、ユーザＵ１からの新規リクエストを受け付けるための各種入力項目が含まれている。図５に示す画像ＩＭ１０には、例えば、取引対象機器情報表示領域ＡＲ１１と、取引内容表示領域ＡＲ１２と、スイッチ表示領域ＡＲ１３とが含まれる。
　取引対象機器情報表示領域ＡＲ１１には、電力の取引を行う対象機器に関する情報が表示される。電動車両Ｍに搭載されたバッテリＢの電力取引を行う場合、取引対象機器情報表示領域ＡＲ１１には、電力取引対象の電動車両Ｍを識別する識別情報（例えば、車両ＩＤ）の設定を受け付けるエリアが表示される。なお、取引対象機器情報表示領域ＡＲ１１には、車両ＩＤを選択するためのＧＵＩ（Graphical User Interface）スイッチであるアイコンＩＣ１１が表示されてもよい。ユーザＵ１がアイコンＩＣ１１を選択した場合、予め登録された車両ＩＤの一覧リストが表示され、ユーザＵ１は、表示されたリストの中から一つを選択することで、車両ＩＤが設定される。
　取引内容表示領域ＡＲ１２には、取引種別（買い（Ｂｕｙ）または売り（Ｓｅｌｌ））、取引する量（電力量）、取引価格（購入価格または販売価格）等の情報を受け付ける入力項目が表示される。また、取引内容表示領域ＡＲ１２には、取引可能時間（Time Slot）、取引完了後に交換されるトークン（例えば、Payment Token（暗号資産）に関する情報（Payment Methods）やその他の手続きに関する情報等）、取引する電力資源の種類（グリーンエネルギーのみにするか否か）等の情報が含まれてよい。これらの情報は、例えば図５に示すチェックボックスやスライドバー等を用いて設定されてよい。
　スイッチ表示領域ＡＲ１３には、ＧＵＩスイッチであるアイコンＩＣ１２と、アイコンＩＣ１３とが含まれる。アイコンＩＣ１２は、新規リクエストを受け付けるスイッチ（ＯＫスイッチ）である。アイコンＩＣ１３は、新規リクエストを登録しないことを受け付けるスイッチ（キャンセルスイッチ）である。
　ユーザＵ１によりアイコンＩＣ１２が選択された場合、ユーザ端末２００－１は、ユーザＵ１が画像ＩＭ１０を介して入力した内容が新規リクエスト情報として情報管理装置１００に送信される。新規リクエスト情報には、ユーザＵ１に関する情報（例えば、ユーザＩＤやユーザＵのアドレス情報）、ユーザ端末２００に関する情報等が含まれてよい。また、新規リクエスト情報に加えて（または代えて）、ユーザ端末２００の位置情報が送信されてもよい。
　［マッチング処理およびＳＣ生成処理：ステップＳ１０４～Ｓ１０８、Ｓ１１４］
　次に、ステップＳ１０４～Ｓ１０８およびステップＳ１１４におけるマッチング処理、およびマッチング結果に基づくスマートコントラクトＳＣの生成処理について説明する。なお、以下の処理では、各ユーザ端末２００における電力取引に関するリクエストをトランザクションとしたスマートコントラクトＳＣの生成処理について、幾つかの実施例に分けて説明する。
　（第１実施例）
　図６は、第１実施例におけるマッチング処理およびスマートコントラクトの生成処理の一例を示すフローチャートである。図６の例において、取得部１２０は、ユーザＵから受け付けた新規リクエストを取得したか否かを判定する（ステップ（ステップＳ２００）。新規リクエストを取得したと判定された場合、マッチング部１３０は、新規リクエストとブロックチェーン３００上に記憶されたスマートコントラクトＳＣに含まれる既存リクエストとのマッチング処理を行う（ステップＳ２１０）。次に、処理部１４０は、マッチング部１３０によるマッチングが成立したか否かを判定する（ステップＳ２２０）。マッチングが成立しなかった（不成立である）と判定した場合、処理部１４０は、新規リクエストを含む新しいスマートコントラクトを生成する（ステップＳ２３０）。次に、登録部１５０は、生成したスマートコントラクトをブロックチェーン上に記憶する（ステップＳ２４０）。なお、スマートコントラクトに保存される新規リクエストはハッシュ値化されていてもよい。
　また、ステップＳ２２０の処理において、マッチングが成立したと判定した場合、処理部１４０は、マッチングが成立した既存リクエストを含むブロックチェーン３００上に記憶されたスマートコントラクトに、新規リクエストに関する情報を追加する（ステップＳ２５０）。これにより、本フローチャートの処理は、終了する。また、ステップＳ２００の処理において、新規リクエストを取得していないと判定された場合、本フローチャートの処理は、終了する。
　次に、第１実施例の処理について、より具体的に説明する。なお、以下の例では、説明の便宜上、ユーザＵ１、Ｕ２に加えてユーザＵ３からもリクエストがあった場合について説明する。図７は、第１実施例において各ユーザＵから受け付けられるリクエストについて説明するための図である。図８は、第１実施例においてブロックチェーン３００上に記憶されるスマートコントラクトＳＣについて説明するための図である。図７の例では、ユーザＵ１～Ｕ３がそれぞれ使用するユーザ端末２００－１～２００－３から入力した電力取引に関するリクエストを取得したものとし、ユーザＵ１～Ｕ３が入力する前の段階で、ブロックチェーン３００上には、スマートコントラクトＳＣが記憶されていないものとする。
　図７の例において、情報管理装置１００は、最初にユーザＵ１のユーザ端末２００－１から電力１０［ｋＷｈ］を売りたいという電力取引に関するリクエストＡ（売電リクエスト）を取得する。なお、リクエストＡには、電力の取引価格（販売価格）に関する情報が含まれていてもよく、画像ＩＭ１０を用いて設定された他の情報が含まれてよい。
　マッチング部１３０は、ブロックチェーン３００上に既に記憶されているスマートコントラクトＳＣに含まれる既存リクエストと、この時点での新規リクエストであるリクエストＡとのマッチングを行う。例えば、マッチング部１３０は、電力取引に関する既存リクエストのうち、１０［ｋＷｈ］以下の電力を買いたいといった条件を満たすリクエスト（購買リクエスト）が存在する場合にマッチングが成立したと判定し、上記条件を満たさない場合にマッチングが不成立であると判定する。ブロックチェーン３００上には、まだスマートコントラクトＳＣ（購買リクエスト）が存在しないため、マッチング部１３０は、マッチングが不成立であると判定する。そして、処理部１４０は、図７に示すようにリクエストＡを含む新たなスマートコントラクトＳＣＡを生成し、ブロックチェーン３００上に記憶する。第１実施例において、リクエストＡを含むスマートコントラクトＳＣＡには、例えば、リクエストを生成したユーザＵに関する情報、取引種別(買電、売電等)、および、取引完了後に使用（交換）されるトークンに関する情報のうち、少なくとも一つの情報が含まれる。また、処理部１４０により生成されるスマートコントラクトＳＣには、リクエストＡの情報がハッシュ値化されて格納される。リクエストＡをハッシュ値化することで、リクエスト情報の漏洩や改ざんを抑制することができ、リクエスト情報をより保護することができる。
　登録部１５０は、図７に示すように生成したスマートコントラクトＳＣＡをブロックチェーン３００上に記憶（登録）する。この時点で、リクエストＡは、既存リクエストとなる。
　次に、情報管理装置１００は、ユーザＵ３のユーザ端末２００－３から電力２０［ｋＷｈ］を買いたいという電力取引に関するリクエストＢ（購買リクエスト）を取得する。マッチング部１３０は、ブロックチェーン３００上に既に保存されているスマートコントラクトＳＣＡに含まれるリクエストＡ（既存リクエスト）と、リクエストＢ（新規リクエスト）とのマッチングを行う。リクエストＡの売りたい電力１０［ｋＷｈ］に対して、リクエストＢの買いたい電力が２０［ｋＷｈ］であるため、マッチング部１３０は、条件が合わずにマッチングが不成立であると判定する。
　処理部１４０は、マッチングが不成立となったリクエストＢを含むスマートコントラクトＳＣＢを生成する。この場合のリクエスト情報もハッシュ値化されてよい。登録部１５０は、図８に示すように生成したスマートコントラクトＳＣＢをブロックチェーン３００上に記憶する。この時点で、リクエストＢは、既存リクエストとなる。
　次に、情報管理装置１００は、ユーザＵ２のユーザ端末２００－２から電力１０［ｋＷｈ］を買いたいという電力取引に関するリクエストＣ（購買リクエスト）を取得する。マッチング部１３０は、ブロックチェーン３００上に既に記憶されているスマートコントラクトＳＣＡ、ＳＣＢのそれぞれに含まれるリクエストＡ、Ｂ（何れも既存リクエスト）と、リクエストＣ（新規リクエスト）とのマッチングを行う。リクエストＡに含まれる売りたい電力１０［ｋＷｈ］に対して、リクエストＣに含まれる買いたい電力が１０［ｋＷｈ］がマッチするため、マッチング部１３０は、リクエストＡとリクエストＣとのマッチングが成立したと判定する。
　この場合、処理部１４０は、図８に示すように、マッチングが成立したリクエストＡを含むスマートコントラクトＳＣＡに対し、リクエストＣに関する情報として、リクエストＡとリクエストＣとのマッチングが成立したことを示す状態（ステート）のみを追加する処理（ステートアップデート処理）を行う。なお、処理の処理に代えて（または加えて）、リクエストＣの一部の情報を追加してもよい。この場合、追加される情報は、ハッシュ値化されてよい。
　上述した第１実施例によれば、ブロックチェーン上に新たにリクエストＣを含むスマートコントラクトＳＣＣを生成したり、リクエストＡとリクエストＣとを全て含んだ新たなスマートコントラクトＳＣＡ＋Ｃを生成することがないため、ブロックチェーン３００上に記憶されるスマートコントラクトＳＣの数の増加（すなわちデータ量）を抑制することができ、更にブロックチェーン３００上に、タイムラグが少なく、より細かく且つ正確な情報を記憶させることができる。
　（第２実施例）
　次に、第２実施例について説明する。第２実施例は、第１実施例と比較して、リクエスト情報がブロックチェーン３００以外のファイルシステム４００上に記憶されるとともに、スマートコントラクトＳＣが処理部１４０により生成されるのではなく、処理部１４０からの指示によりブロックチェーン３００上のプログラムによって生成される点で相違する。以下では、主に相違点を中心として説明する。
　図９は、第２実施例における処理部１４０の具体的な構成の一例を示す図である。処理部１４０は、例えば、第１処理部１４２と、付与部１４４と、第２処理部１４６とを備える。第１処理部１４２は、ブロックチェーン３００外に存在するファイルシステム４００に新規リクエストの情報をハッシュ値化せずに記憶させる。付与部１４４は、ファイルシステム４００に記憶された新規リクエストの情報に識別情報（ＣＩＤ：Content Identifier）を付与する。なお、ＣＩＤは、ハッシュ値であってもよい。例えば、付与部１４４は、新規リクエストの情報等を入力値としてハッシュ値化を行い、このハッシュ値を新規リクエストに対するＣＩＤとして付与する。ＣＩＤは、例えば、情報管理装置１００やファイルシステム４００等において、リクエスト（またはデータセットＤＳ）の管理、参照用に利用される。第２処理部１４６は、マッチング部１３０による新規リクエストと既存リクエストとのマッチングが成立しなかった場合に、ブロックチェーン３００上のプログラムによって新規リクエストを含むスマートコントラクトＳＣを生成する。また、第２処理部１４６は、マッチング部１３０によりマッチングが成立した場合に、マッチング相手の既存リクエストを含むスマートコントラクトＳＣに、新規リクエストに関する情報を追加する。
　図１０は、第２実施例におけるマッチング処理およびスマートコントラクトＳＣの生成処理の一例を示すフローチャートである。図１０の処理は、図６に示すステップＳ２００～Ｓ２５０の処理と比較して、ステップＳ２０２、Ｓ２０４の処理が追加され、且つステップＳ２３０の処理に代えてステップＳ２３２の処理を有する点で相違する。したがって、以下では、主にステップＳ２０２～Ｓ２０４およびＳ２３２の処理を中心として説明する。
　図１０のステップＳ２００の処理において、新規リクエストを取得したと判定した場合、第１処理部１４２は、ファイルシステム４００に新規リクエストを含むデータセット（データファイル）ＤＳを記憶する（ステップＳ２０２）。ファイルシステム４００は、情報管理装置１００が管理するセキュアな環境であるため、データセットＤＳに記憶される新規リクエストは、ハッシュ値化されていなくてもよい。次に、付与部１４４は、データセットＤＳ内の新規リクエストに識別情報を付与する（ステップＳ２０４）。したがって、データセットＤＳには、ＣＩＤの情報が含まれる。そして、ステップＳ２１０のマッチング処理において、マッチング部１３０は、ファイルシステム４００に記憶されたデータセットに含まれる既存リクエストと新規リクエストとの間でマッチング処理を行う。
　ステップＳ２２０の処理において、マッチングが成立しなかった（不成立である）と判定した場合、第２処理部１４６は、ブロックチェーン３００上のプログラムを実行させることで、新規リクエストを含むスマートコントラクトを生成させて（ステップＳ２３２）、ブロックチェーン３００上に記憶させる（ステップＳ２４０）。なお、スマートコントラクトに含まれる新規リクエストは、ハッシュ値化されていてもよい。
　次に、第２実施例の処理について、より具体的に説明する。図１１は、第２実施例における各ユーザＵのリクエストとブロックチェーン３００上に記憶されるスマートコントラクトＳＣを説明するための図である。第２実施例において、ユーザＵ１のリクエストＡを取得した場合、第１処理部１４２は、図１１に示すようにファイルシステム４００にリクエストＡを含むデータセットＤＳＡを記憶する。付与部１４４は、データセットＤＳＡ内のリクエストＡに識別情報（ＣＩＤ）を付与する。
　マッチング部１３０は、新規リクエストＡと、既存リクエストとのマッチングを行う。マッチングが不成立であると判定された場合、第２処理部１４６は、ブロックチェーン３００上に予め記憶されている新たにスマートコントラクトＳＣを生成するためのプログラムが格納された別のスマートコントラクトＳＣ（以下「生成用ＳＣ」と称する）にリクエストＡを含むスマートコントラクトＳＣＡを生成させる指示を出力する。生成用ＳＣは、第２処理部１４６からの指示に基づきプログラムを実行させてリクエストＡに対応するスマートコントラクトＳＣＡを生成してブロックチェーン３００上に記憶する。
　図１１の例では、生成用ＳＣにより、マッチングが不成立となったリクエストＡとＢのそれぞれに対応するスマートコントラクトＳＣＡ、ＳＣＢが生成されている。なお、第２実施例において、生成用ＳＣが生成するスマートコントラクトＳＣＡ、ＳＣＢには、例えば、リクエストを生成したユーザＵに関する情報、取引種別(買電、売電等)、取引完了後に使用（交換）されるトークンに関する情報、およびファイルシステム４００に記憶されたデータ（データセット）を参照するための情報のうち、少なくとも一つの情報が含まれる。これらの情報は、ハッシュ値化されていてもよい。例えば、第２実施例において、ユーザ端末２００は、ファイルシステム４００に記憶されたデータを参照するための情報を用いて情報管理装置１００にデータセットＤＳの問い合わせを行い、情報管理装置１００の許可が得られた場合に、データセットＤＳの内容を参照することができる。
　その後、図１１の例において、リクエストＣを取得した場合に、第１処理部１４２は、リクエストＣを含むデータセットＤＳＣをファイルシステム４００に記憶させる。また、付与部１４４は、リクエストＣに対応するＣＩＤを付与する。そして、マッチング部１３０は、データセットＤＳＡのリクエストＡおよびデータセットＤＳＢのリクエストＢと、新規リクエストＣとのマッチングを行い、リクエストＡとＣとでマッチングが成立したと判定する。そのため、第２処理部１４６は、ブロックチェーン３００上に記憶されたスマートコントラクトＳＣＡに対し、マッチング結果に基づく情報を追加する。
　上述した第２実施例によれば、第1実施例と同様の効果を奏する他、ブロックチェーン（オンチェーン）３００よりもセキュアなファイルシステム（オフチェーン）４００にリクエスト情報を記憶してマッチング処理を行うことができる。ファイルシステム４００上のリクエスト情報は、ハッシュ値化されていないため、リクエスト情報のマッチングを迅速かつ正確に行うことができる。また、第２実施例によれば、ブロックチェーン３００上のプログラムを用いてスマートコントラクトＳＣを生成させることで、ブロックが生成される過程をブロックチェーン３００上に記憶させることができる。また、どのようなスマートコントラクトＳＣがどのプログラムによって生成されたかが第三者から検証しやすくなり、取引過程の透明性を確保することができる。
　なお、第２実施例では、生成用ＳＣを用いずに、処理部１４０（第２処理部１４６）が直接ブロックチェーン３００上にスマートコントラクトＳＣを生成してもよく、処理部１４０が生成用ＳＣを生成してもよい。後述する第３実施例についても同様である。
　（第３実施例）
　次に、第３実施例について説明する。第３実施例は、第２実施例と比較して、上述したリクエストの識別情報（ＣＩＤ）をブロックチェーン３００上のスマートコントラクトＳＣに記憶させるとともに、マッチング結果に対するユーザＵの承認があった時点で、マッチング結果がスマートコントラクトＳＣに追加される点で相違する。以下では、主に上記相違点を中心として説明する。なお、第３実施例でも、第２実施例と同様の処理部１４０の構成により各処理が実行されてよい。
　図１２は、第３実施例におけるマッチング処理およびスマートコントラクトＳＣの生成処理の一例を示すフローチャートである。図１２の処理は、図１０に示すステップＳ２００～Ｓ２５０の処理と比較して、ステップＳ２３２、Ｓ２５０の処理に代えてステップＳ２３４、Ｓ２５２の処理を有し、且つステップＳ２６０～Ｓ２８０の処理が追加されている点で相違する。したがって、以下では、主にステップＳ２３４、Ｓ２５２、Ｓ２６０～Ｓ２８０の処理を中心として説明する。
　図１２のステップＳ２２０の処理において、マッチングが成立しなかったと判定された場合、第２処理部１４６は、ブロックチェーン３００上のプログラム（生成用ＳＣのプログラム）によって新規リクエストのＣＩＤ（識別情報）を含む新しいスマートコントラクトＳＣを生成させる（ステップＳ２３４）。また、マッチングが成立したと判定された場合、第２処理部１４６は、マッチングが成立した既存リクエストのＣＩＤを含むスマートコントラクトＳＣに新規リクエストのＣＩＤを追加する（ステップＳ２５２）。なお、ステップＳ２３４およびＳ２５２の処理においてスマートコントラクトＳＣに記憶されるＣＩＤは、ハッシュ値化されていてもよい。
　次に、提供部１６０は、マッチング結果を示す情報を生成してマッチング対象のリクエストを送信したユーザ端末２００に提供する（ステップＳ２６０）。次に、第２処理部１４６は、ユーザ端末２００から取得した情報から電力取引を行うユーザの承認を受け付けたか否かを判定する（ステップＳ２７０）。承認を受け付けたと判定した場合、対象のスマートコントラクトＳＣにマッチング結果に関する情報を追加する（ステップＳ２８０）。また、承認を受けていない（例えば、拒否を示す情報を受け付けた）と判定された場合、ステップＳ２３４以降の処理を行う。
　次に、第３実施例の処理について、より具体的に説明する。図１３は、第３実施例における各ユーザＵのリクエストとブロックチェーン３００上に記憶されるスマートコントラクトＳＣについて説明するための図である。第３実施例において、第１処理部１４２は、ユーザＵ１のリクエストＡを受け付け、ファイルシステム４００にリクエストＡを含むデータセットＤＳＡを生成する。付与部１４４は、データセットＤＳＡ内のリクエストＡにＣＩＤを付与する。また、第２処理部１４６は、マッチング部１３０によりリクエストＡとのマッチングが不成立と判定された場合に、生成用ＳＣを用いて、リクエストＡに割り当てたＣＩＤを含むスマートコントラクトＳＣＡを生成する。図１３の例では、同様に生成用ＳＣを用いて、マッチングが不成立となったリクエストＡのＣＩＤを含むスマートコントラクトＳＣＡとリクエストＢのＣＩＤを含むスマートコントラクトＳＣＢとが生成されている。スマートコントラクトＳＣＡ、ＳＣＢに格納されるＣＩＤは、ハッシュ値化されてもよい。このようにスマートコントラクトＳＣにＣＩＤを格納することで、取引条件の元になるリクエスト情報がブロックチェーン外（オフチェーン上）に存在することを証明することができるため、取引の妥当性を確保することができる。また、スマートコントラクトＳＣにはリクエストをハッシュ値化したＣＩＤのみを記憶させることでユーザＵの個人情報を保護することができる。なお、例えば、ユーザＵがＣＩＤに対応するリクエスト情報を参照したい場合には、ユーザ端末２００から情報管理装置１００にＣＩＤに対するリクエスト情報の問い合わせを行い許可が得られた場合に、参照することができる。
　また、マッチング部１３０によりリクエストＣと、ファイルシステム４００のデータセットＤＳＡ、ＤＳＢに格納されたリクエストＡ、リクエストＢとマッチングを行い、リクエストＡとＣとでマッチングが成立すると判定する。第２処理部１４６は、この時点で生成用ＳＣを用いてスマートコントラクトＳＣＡに対し、マッチング結果に基づく情報としてマッチングが成立したリクエストＣに対するＣＩＤを追加する。なお、処理部１４０は、スマートコントラクトＳＣＡ、ＳＣＢの生成と同様に、生成用ＳＣを用いてスマートコントラクトＳＣＡにリクエストＣのＣＩＤを追加する。なお、第３実施例の生成用ＳＣのプログラムには、マッチングが成立したリクエストのＣＩＤを既存のスマートコントラクトＳＣに付加するプログラムが含まれる。
　ここで、提供部１６０は、上述したマッチング結果に関する情報（例えば、画像）を生成し、生成した情報をユーザ端末２００－１、２００－２に提供する。なお、提供する情報には、マッチング結果に基づく取引を承認するか否かを示す情報が含まれてよい。第２処理部１４６は、ユーザＵ１、Ｕ２から受け付けた取引の承認の有無によって、更にスマートコントラクトＳＣＡに情報を追加する。上述の処理は、図４に示すステップＳ１２２、Ｓ１２４のマッチング結果の表示および受付処理に相当する。
　図１４は、マッチング結果に関する画像ＩＭ２０の一例を示す図である。図１４に示す画像ＩＭ２０には、例えば、マッチング結果表示領域ＡＲ２１と、スイッチ表示領域ＡＲ２２とが含まれる。
　マッチング結果表示領域ＡＲ２１には、リクエストの条件にマッチした結果の内容に関する情報が表示される。図１４では、一例として、マッチングが成立した情報（リクエスト）が複数存在する場合を示している。複数のマッチング結果が得られた場合には、それぞれの内容（例えば、取引価格、取引量（電力量））が表示されるとともに、マッチングが成立した複数の内容のうち何れかを選択するためのラジオボタン（チェックボックス）等が表示される。ユーザＵ１、Ｕ２は、画像ＩＭ２０のラジオボタンにより複数あるうちの何れかを選択する。なお、マッチング部１３０によるマッチングが不成立であった場合には、マッチング結果表示領域ＡＲ２１にマッチング不成立であったことを示す情報が表示されてもよい。
　スイッチング表示領域ＡＲ２２には、マッチング結果に基づく取引を承認するためのＧＵＩスイッチであるアイコンＩＣ２１と、取引を拒否する（承認しない）ためのアイコンＩＣ２２とが表示されている。ユーザ端末２００－１、２００－２は、ユーザＵ１によるアイコンＩＣ２１の選択を受け付けた場合に、マッチング結果表示領域ＡＲ２１で選択したマッチング結果に基づく取引を承認することを示す情報を情報管理装置１００に送信し、アイコンＩＣ２２の選択を受け付けた場合に、マッチング結果に基づく取引を拒否することを示す情報を情報管理装置１００に送信する（図４のステップＳ１２６、Ｓ１２８の処理）。
　図１３に戻り、ユーザＵ１とＵ２の両方が取引を承認した場合、処理部１４０は、ブロックチェーン３００上のスマートコントラクトＳＣＡに、マッチング結果のデータセットを追加する。なお、ユーザＵの承認後に格納される情報（マッチング結果データセット）には、例えば、取引価格を算出するのに必要な契約情報（例えば、電力量、取引価格、付加価値率）等が含まれる。付加価値率は、例えば、処理部１４０が外部から電力取引の市場状況に関する情報を取得し、取得した情報に基づいて設定されてもよく、ユーザＵのサービス利用状況に基づいて設定されてもよく、取引システム１の管理者等が任意設定してもよい。スマートコントラクトＳＣＡに追加されるマッチング結果データセットは、ハッシュ値化されていてもよい。
　なお、第３実施例において、マッチング部１３０は、図１３に示すように、ファイルシステム４００内で行った成立、不成立を含む全てのマッチング結果を、データセット等でファイルシステム４００内に記憶させてもよい。また、マッチング部１３０は、スマートコントラクトＳＣに追加するマッチング結果データセットよりも詳しい情報（例えば、上記契約情報に加えて、マッチングが成立したリクエスト情報等）をファイルシステム４００に記憶させてもよい。これにより、マッチング状況をより詳細に管理することができるとともに、スマートコントラクトＳＣに追加されるデータ容量は減らすことができる。更に、スマートコントラクトＳＣに追加されるマッチング結果データセットには、ユーザに関する情報が含まれないため、ユーザの個人情報を保護することができる。
　上述した第３実施例によれば、第１実施例と同様の効果を奏する他、リクエストの情報をスマートコントラクトＳＣに記憶せず、リクエストに対応付けられたＣＩＤのみをスマートコントラクトＳＣ上に記憶することで、取引条件の元になるリクエストがオフチェーン（ファイルシステム４００）に存在することを証明することができ、取引の妥当性を保証することができる。また、リクエストの情報が記憶されないことで、ブロックチェーン３００上のデータ量を更に削減することができ、情報管理はファイルシステム４００上でタイムより正確に行うことができる。
　なお、上述した第１～第３実施例のそれぞれは、他の実施例の少なくとも一部を組み合わせてもよい。例えば、第２実施例において、マッチング部１３０は、第３実施例と同様に、ファイルシステム４００内で行ったマッチング結果をファイルシステム４００内に記憶させてもよい。
　［電力取引管理処理：ステップＳ１３２～Ｓ１４４］
　次に、図４に示すステップＳ１３２～Ｓ１４４の電力取引管理処理について具体的に説明する。図１５は、電力取引に関する処理について説明するための図である。図１５において、充放電ＣＳ５００と、情報管理装置１００と、ファイルシステム４００とは、例えば情報管理装置１００と、充放電ＣＳ５００のそれぞれに設けられた専用のエージェント（ユーザエージェントプログラム）によりデータの送受信等が行われてよい。また、装置間で送受信されるデータ（トランザクション）は、分散型アイデンティティ（ＤＩＤ：Decentralized Identifier）と呼ばれる方式で転送されてよい。ＤＩＤは、ユーザ名等の個人情報が特定されてしまうような識別情報を、第三者に管理されない自己所有の独立したＩＤに置き換えることで装置間でのデータ交換を可能にするとともに、プライバシーの保護や取引の安全性を確保することができる転送フレームワークである。ＤＩＤを用いたデータ転送には、例えば、Ｐ２Ｐ通信プロトコルであるＤＩＤ-Ｃｏｍｍが用いられる。ＤＩＤ-Ｃｏｍｍを用いることで、システム全体を管理する装置への依存度を下げた状態で、分散型のデータ連携が可能となる。また、ＤＩＤ－Ｃｏｍｍを用いたデータ転送を行うことで、例えば送信されたデータの資格情報（ユーザ情報）の証明を検証することができる。なお、実施形態で用いられる通信プロトコルについてはＤＩＤ－Ｃｏｍｍに限定されなくてもよい。
　図１５において、まず充放電ＣＳ５００は、今回の電力取引に関する情報の転送で用いられるＤＩＤに関する情報をファイルシステム４００に登録する（図１５の（１））。また、情報管理装置１００は、充放電ＣＳ５００で用いられるＤＩＤやＤＩＤ-Ｃｏｍｍに関する情報をファイルシステム４００に登録する（図１５の（２））。また、情報管理装置１００は、ユーザＵ１、Ｕ２により電力取引が承認された場合に、ユーザＵ１、Ｕ２のリクエストＡ、Ｃに含まれる充放電の取引可能時間（開始時間、終了時間）に基づいて、充放電のスケジュール情報等を生成し、生成したスケジュール情報やユーザＵ１、Ｕ２に関する情報を充放電ＣＳ５００に送信する（図１５の（３））。
　充放電ＣＳ５００は、スケジュール情報に基づいて、電力取引状況（契約状態）に関する情報（例えば、画像）を生成してユーザ端末２００－１、２００－２に提供する（図１５の（４））。なお、上記情報は、充放電ＣＳ５００に代えて情報管理装置１００の提供部１６０により提供されてもよい。
　図１６は、電力取引状況に関する画像ＩＭ３０の一例を示す図である。なお、図１６に示す画像ＩＭ３０は、電力を買う側（買い手側）の購買リクエストを送信したユーザ端末２００－２に表示される画像の一例を示している。図１６の例において、画像ＩＭ３０には、例えば、取引状況表示領域ＡＲ３１と、トランザクション概要表示領域ＡＲ３２と、スイッチ表示領域ＡＲ３３とが含まれる。取引状況表示領域ＡＲ３１には、電力の購買状態（または売電状態）を示す情報（例えば、充電残量、放電残量）、電動車両Ｍが接続する充放電設備５２０の識別情報（充放電設備ＩＤ）および場所（設置位置）に関する情報が表示される。また、取引状況表示領域ＡＲ３１には、電力取引中であることや電力取引が完了したことを示す情報が表示されてもよい。トランザクション概要表示領域ＡＲ３２には、例えば、充電（または放電）の開始時間、終了時間、トータル電力量、合計費用等の電力取引（トランザクション）に関する情報が表示される。
　スイッチ表示領域ＡＲ３３には、ＧＵＩスイッチであるアイコンＩＣ３１と、ＩＣ３２とが含まれる。アイコンＩＣ３１は、充放電完了後に、電子領収書（Receipt）の表示指示を受け付けるためのスイッチである。アイコンＩＣ３２は、画像ＩＭ３０の表示を終了させるためのスイッチである。取引アプリ２７２は、ユーザＵ２によりアイコンＩＣ３１が選択された場合には、今回の電力取引における領収書を示す画像をディスプレイ２３２に表示させ、アイコンＩＣ３２が選択された場合には、画像ＩＭ３０の表示を終了させる。
　ユーザＵ１、Ｕ２は、取引状況表示領域ＡＲ３１に表示された場所情報に基づいて、それぞれが利用する電動車両Ｍ１、Ｍ２を充放電ＣＳ５００が管理する充放電設備５２０に移動させ、充放電設備ＩＤに対応する充放電設備５２０に電動車両Ｍ１、Ｍ２を接続させる。なお、取引状況表示領域ＡＲ３１に表示される充放電施設ＩＤや場所情報は、例えば、充放電ＣＳ５００または情報管理装置１００がユーザ端末２００の位置情報に基づいて抽出した、ユーザ端末２００から最も近い充放電設備５２０のＩＤおよび場所情報である。図１５の例では、ユーザＵ１の電動車両Ｍ１が充放電設備５２０-１に接続され、ユーザＵ２の電動車両Ｍ２が充放電設備５２０－２に接続されている。
　充放電設備５２０－１、５２０－２は、電動車両Ｍ１、Ｍ２と接続することで電動車両Ｍ１、Ｍ２の識別情報（車両ＩＤ）を取得し、取得した車両ＩＤを充放電ＣＳ５００に出力する。充放電ＣＳ５００は、車両ＩＤが予め使用が許可された（スケジューリングされた）車両ＩＤである場合に、充放電セッション（充放電による電力取引）を開始し、充放電に関する情報（例えば、充放電情報、充放電結果、セッション終了）を情報管理装置１００に送信する（図１５の（５））。情報管理装置１００は、充放電に関する情報に基づいて電力取引状況等をファイルシステム４００に記憶し（図１５の（６））、電力取引終了後（充放電完了後またはセッション終了後）にブロックチェーン３００に記憶されたスマートコントラクトＳＣに電力取引結果を追加する（図１５の（７））。
　図１７は、充放電セッション中における取引状況の管理について説明するための図である。図１７の例では、充放電のセッション前において、上述した図１３に示す第３実施例のマッチングが成立したリクエストＡ、Ｃに対応するＣＩＤおよびマッチング結果のデータセットを含むスマートコントラクトＳＣＡがブロックチェーン３００上に記憶されているものとする。また、図１７の例では、充放電中、充放電完了、セッション終了時におけるそれぞれの取引状況の管理内容を示している。充放電時に取引状況の管理において、充放電ＣＳ５００は、充放電に関する情報（例えば、充放電情報、充放電結果、セッション終了）を情報管理装置１００に送信する。情報管理装置１００では、送信された情報に基づいて充放電セッション中における取引管理を行う。
　図１８は、充放電セッション中における情報管理装置１００により実行される処理の一例を示すフローチャートである。図１８の処理は、充放電セッション中において、所定周期または所定のタイミングで繰り返し実行されてよい。図１８の例において、情報管理装置１００の取得部１２０は、充放電ＣＳ５００（または充放電設備５２０－１、５２０-２）から充放電に関する情報を取得したか否かを判定する（ステップＳ３００）。
　充放電に関する情報を取得したと判定した場合、取得部１２０は、取得した情報が充電情報か否かを判定する（ステップＳ３１０）。充電情報であると判定された場合、処理部１４０（第１処理部１４２）は、図１３に示すように充電情報に対応するデータセットＤＳ１を生成し、ファイルシステム４００に記憶する（ステップＳ３２０）。データセットＤＳ１には、例えば、充放電施設ＩＤ、充放電時間（タイムスタンプ）、ユーザ情報、車両ＩＤ、放電電力量（または充電電力量）に関する情報が含まれる。また、データセットＤＳ１には、バッテリＢ（充放電対象機器）の識別情報（バッテリＩＤ）、バッテリＢの電力量、充電率（ＳＯＣ；State Of Charge）等の情報が含まれてもよい。
　また、ステップＳ３２０の処理において、既にデータセットＤＳ１がファイルシステム４００に存在する場合には、データセットＤＳ１の変更部分が更新されてもよく、記憶された過去のデータセットＤＳ１が削除されて新たなデータセットＤＳ１がファイルシステム４００に記憶されてもよい。また、データセットＤＳ１には、充電側と放電側の両方の情報が含まれてもよく、それぞれが別データセットとして格納されてもよい。
　また、ステップＳ３１０の処理において、充電情報でないと判定された場合、取得部１２０は、取得した充放電に関する情報が充電完了時に送信される充放電結果であるか否かを判定する（ステップＳ３３０）。充放電結果であると判定された場合、処理部１４０は、図１７に示すように充放電結果を示すデータセットＤＳ２を生成し、生成したデータセットＤＳ２をファイルシステム４００に記憶させる（ステップＳ３４０）。データセットＤＳ２には、データセットＤＳ１と同様の情報の他、取引完了状態であることを示す情報や、セッションによる総充電（または放電）量等の情報が含まれる。
　また、処理部１４０は、充放電情報のデータセットＤＳ１と、充放電結果のデータセットＤＳ２と、マッチング結果データセットに含まれる契約情報（例えば取引価格、付加価値率）に基づいて、最終的な取引額を算出し、算出した取引額や取引量等の取引情報を含むデータセットＤＳ３を生成する（ステップＳ３５０）。なお、取引情報には、例えば、取引が完了しているか否かを示す情報が含まれてよい。また、データセットＤＳ３には、取引情報の他、セッション情報（通信中に得られる情報）が格納される。セッション情報には、例えば充放電設備５２０を識別する識別情報（充放電ＩＤ）、取引の元になるリクエストの識別情報（ＣＩＤ）、電力消費（供給）者であるユーザの識別情報（ユーザＩＤ）、充放電開始時刻、充放電終了時刻、セッション開始時のバッテリ電力量、セッション終了時のバッテリ電力量、セッション開始時のバッテリ充電率、セッション終了時のバッテリ充電率、セッションによる総充放電力量のうち、少なくとも一つの情報が含まれる。
　また、ステップＳ３３０の処理において、放電に関する情報が充放電結果でないと判定した場合、取得部１２０は、取得した充放電に関する情報がセッション終了情報であるか否かを判定する（ステップＳ３６０）。セッション終了情報であると判定した場合、第２処理部１４６は、ブロックチェーン３００上に記憶されたスマートコントラクトＳＣＡに充電セッション結果（電力取引結果）に対応するデータセット（例えば、データセットＤＳ３の内容の少なくとも一部）を追加し（ステップＳ３７０）、ブロックチェーン３００上に記憶する（ステップＳ３８０）。なお、第２処理部１４６は、スマートコントラクトＳＣＡに追加するデータセット（電力取引結果）に含まれるセッション情報をハッシュ値化し、取引情報をハッシュ値化せずにスマートコントラクトＳＣＡに追加する。また、第２処理部１４６は、充放電が終了したことの証明となる情報（ステータス情報）をスマートコントラクトＳＣＡに追加してもよい。これにより、図１８に示すフローチャートの処理は終了する。また、ステップＳ３００の処理において、充放電に関する情報を取得していないと判定された場合、本フローチャートの処理は終了する。
　このように、ユーザの識別情報を含むセッション情報をハッシュ値化してデータの内容が分からない状態でブロックチェーン３００上に記憶することで、ユーザＵのプライバシー情報等を保護することができる。更に、取引額および取引量等の最終決済額を算出するために必要な情報や取引の完了を確認するための情報(つまり、プライバシー情報ではない情報)はハッシュ値化せずにブロックチェーン３００上に記憶することで、最終決済額を正しく速く算出することができる。なお、上述したスマートコントラクトＳＣＡには、リクエストＡに対応するＣＩＤやマッチング結果データセットが含まれるため、これらの情報用いてファイルシステム４００等からリクエスト情報等を取得することができる。
　［変形例］
　実施形態の取引システム１における情報管理装置１００は、ブロックチェーン３００（ブロックチェーンネットワーク）を構成するノードの一つであってもよく、ファイルシステム４００（ＩＰＦＳネットワーク）を構成するノードの一つであってもよい。言い換えると、情報管理装置１００は、ブロックチェーン３００と一体に構成されていてもよく、ファイルシステム４００と一体に構成されていてもよい。また、情報管理装置１００は、充放電ＣＳ５００と一体に構成されていてもよい。また、情報管理装置１００に含まれる機能の一部（例えば、マッチング部１３０、登録部１５０、または提供部１６０の機能）は、ブロックチェーン３００に予め記憶されたプログラム（専用のスマートコントラクト）によって実行されてもよい。
　また、実施形態では、ユーザＵが所有する電動車両Ｍ（より具体的にはバッテリＢ）の電力に関する取引について説明したが、電動車両Ｍからの電力に加えて（または代えて）、太陽光発電、風力発電、水力発電、火力発電、地熱発電等によって得られた電力であってもよい。
　以上説明した実施形態によれば、ユーザ間の取引を仲介し、ブロックチェーン３００上に前記取引に関するスマートコントラクトを記憶させることで取引結果を管理する情報管理装置１００であって、ユーザから受け付けた購買または販売に関するリクエストを取得する取得部１２０と、取得部１２０により新規に取得した新規リクエストと、既にブロックチェーン３００上に記憶されたスマートコントラクトに含まれる既存リクエストとのマッチングを行うマッチング部１３０と、前記マッチングが成立しなかった場合にブロックチェーン３００上に前記新規リクエストを含むスマートコントラクトを生成し、前記マッチングが成立した場合にマッチングが成立した前記既存リクエストを含むスマートコントラクトに前記新規リクエストの情報を追加する処理部１４０と、を備えることにより、ブロックチェーン３００上に記憶する情報のデータ量を低減させつつ、より正確に情報を管理することができる。
　より具体的には、実施形態によれば、マッチングが成立しない場合のみに新規でスマートコントラクトを生成し、マッチングが成立した場合はマッチング相手の既存スマートコントラクトのステータスを変更するため、スマートコントラクトの数を減少させることができる。また、実施形態によれば、ブロックチェーン上のデータ容量および運用コスト(＝トランザクションコスト)を低減させることができ、取引システム１における処理速度の低下を抑制することができる。
　また、実施形態によれば、ブロックチェーン３００に記憶されるリクエストの情報がハッシュ値化されることでリクエスト情報をより保護することができる。また、実施形態によれば、ブロックチェーン上のプログラムを用いてスマートコントラクトを生成することで、取引が生成される過程をブロックチェーン上に記録することができ、取引過程の透明性を確保することができる。また、実施形態によれば、実際の取引状況と、ブロックチェーン３００やファイルシステム４００で管理される情報とのタイムラグを抑制し、１つ１つの情報をより正確に管理することができる。
　上記説明した実施形態は、以下のように表現することができる。
　ユーザ間の取引を仲介し、ブロックチェーン上に前記取引に関するスマートコントラクトを記憶させることで取引結果を管理する情報管理装置のコンピュータによって読み込み可能な命令（computer-readable instructions）を格納する記憶媒体（storage medium）と、
　前記記憶媒体に接続されたプロセッサと、を備え、
　前記プロセッサは、前記コンピュータによって読み込み可能な命令を実行することにより（the processor executing the computer-readable instructions to:）、
　ユーザから受け付けた購買または販売に関するリクエストを取得し、
　新規に取得した新規リクエストと、既に前記ブロックチェーン上に記憶されたスマートコントラクトに含まれる既存リクエストとのマッチングを行い、
　前記マッチングが成立しなかった場合に前記ブロックチェーン上に前記新規リクエストを含むスマートコントラクトを生成し、
　前記マッチングが成立した場合にマッチングが成立した前記既存リクエストを含むスマートコントラクトに前記新規リクエストの情報を追加する、
　情報管理装置。
　以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
　１…取引システム、１００…情報管理装置、１１０…通信部、１２０…取得部、１３０…マッチング部、１４０…処理部、１４２…第１処理部、１４４…付与部、１４６…第２処理部、１５０…登録部、１６０…提供部、１７０…装置側記憶部、２００…ユーザ端末、２１０…端末側通信部、２２０…入力部、２３０…出力部、２３２…ディスプレイ、２３４…スピーカ、２４０…位置情報取得部、２５０…制御部、２６０…アプリ実行部、２７０…端末側記憶部、３００…ブロックチェーン、４００…ファイルシステム、５００…充放電ＣＳ、５２０…充放電設備、Ｍ…電動車両

Claims (9)

  1. 　ユーザ間の取引を仲介し、ブロックチェーン上に前記取引に関するスマートコントラクトを記憶させることで取引結果を管理する情報管理装置であって、
    　ユーザから受け付けた購買または販売に関するリクエストを取得する取得部と、
    　前記取得部により新規に取得した新規リクエストと、既に前記ブロックチェーン上に記憶されたスマートコントラクトに含まれる既存リクエストとのマッチングを行うマッチング部と、
    　前記マッチングが成立しなかった場合に前記ブロックチェーン上に前記新規リクエストを含むスマートコントラクトを生成し、前記マッチングが成立した場合にマッチングが成立した前記既存リクエストを含むスマートコントラクトに前記新規リクエストの情報を追加する処理部と、
    　を備える情報管理装置。
  2. 　前記処理部は、ハッシュ値化された前記新規リクエストの情報を含むスマートコントラクトを生成する、
    　請求項１に記載の情報管理装置。
  3. 　前記処理部は、予め前記ブロックチェーン上に記憶されたプログラムにより前記新規リクエストを含むスマートコントラクトを生成させる、
    　請求項１に記載の情報管理装置。
  4. 　前記ブロックチェーンは、イーサリアムである、
    　請求項３に記載の情報管理装置。
  5. 　前記取引は、電力取引を含み、
    　前記リクエストは、電力の購買または販売に関するリクエストを含み、
    　前記処理部は、前記リクエストに対する電力取引結果を前記スマートコントラクトに追加する、
    　請求項１に記載の情報管理装置。
  6. 　前記スマートコントラクトは、前記ユーザに関する情報、取引種別、取引完了後に交換されるトークンに関する情報、および前記ブロックチェーン外の記憶部に記録される前記リクエストに関する情報を参照するための情報のうち、少なくとも一つを含む、
    　請求項１に記載の情報管理装置。
  7. 　前記処理部は、前記ユーザ間の取引におけるセッション情報をハッシュ値化して前記ブロックチェーン上に記憶させ、取引額および取引量を含む取引情報をハッシュ値化せずにブロックチェーン上に記憶させる、
    　請求項１に記載の情報管理装置。
  8. 　ユーザ間の取引を仲介し、ブロックチェーン上に前記取引に関するスマートコントラクトを記憶させることで取引結果を管理する情報管理装置が、
    　ユーザから受け付けた購買または販売に関するリクエストを取得し、
    　新規に取得した新規リクエストと、既に前記ブロックチェーン上に記憶されたスマートコントラクトに含まれる既存リクエストとのマッチングを行い、
    　前記マッチングが成立しなかった場合に前記ブロックチェーン上に前記新規リクエストを含むスマートコントラクトを生成し、
    　前記マッチングが成立した場合にマッチングが成立した前記既存リクエストを含むスマートコントラクトに前記新規リクエストの情報を追加する、
    　情報管理方法。
  9. 　ユーザ間の取引を仲介し、ブロックチェーン上に前記取引に関するスマートコントラクトを記憶させることで取引結果を管理する情報管理装置に、
    　ユーザから受け付けた購買または販売に関するリクエストを取得させ、
    　新規に取得した新規リクエストと、既に前記ブロックチェーン上に記憶されたスマートコントラクトに含まれる既存リクエストとのマッチングを行わせ、
    　前記マッチングが成立しなかった場合に前記ブロックチェーン上に前記新規リクエストを含むスマートコントラクトを生成させ、
    　前記マッチングが成立した場合にマッチングが成立した前記既存リクエストを含むスマートコントラクトに前記新規リクエストの情報を追加させる、
    　プログラム。
PCT/JP2023/023344 2023-06-23 2023-06-23 情報管理装置、情報管理方法、およびプログラム Ceased WO2024262011A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202380099433.4A CN121311915A (zh) 2023-06-23 2023-06-23 信息管理装置、信息管理方法及程序
EP23942442.7A EP4715723A1 (en) 2023-06-23 2023-06-23 Information management device, information management method, and program
PCT/JP2023/023344 WO2024262011A1 (ja) 2023-06-23 2023-06-23 情報管理装置、情報管理方法、およびプログラム
JP2025527387A JPWO2024262011A1 (ja) 2023-06-23 2023-06-23

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2023/023344 WO2024262011A1 (ja) 2023-06-23 2023-06-23 情報管理装置、情報管理方法、およびプログラム

Publications (1)

Publication Number Publication Date
WO2024262011A1 true WO2024262011A1 (ja) 2024-12-26

Family

ID=93935193

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/023344 Ceased WO2024262011A1 (ja) 2023-06-23 2023-06-23 情報管理装置、情報管理方法、およびプログラム

Country Status (4)

Country Link
EP (1) EP4715723A1 (ja)
JP (1) JPWO2024262011A1 (ja)
CN (1) CN121311915A (ja)
WO (1) WO2024262011A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019153275A (ja) * 2018-03-02 2019-09-12 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 制御方法、コントローラ、データ構造及び電力取引システム
WO2020170656A1 (ja) * 2019-02-22 2020-08-27 株式会社日立製作所 構成変更管理方法、構成変更管理システム、およびノード
JP2022046757A (ja) 2020-02-28 2022-03-23 アスエネ株式会社 電力取引システム
WO2022153375A1 (ja) * 2021-01-13 2022-07-21 富士通株式会社 データ格納方法、データ格納プログラム、および情報処理装置
JP2023061014A (ja) * 2021-10-19 2023-05-01 トヨタ自動車株式会社 電力取引システム、コンピュータ、電力取引方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019153275A (ja) * 2018-03-02 2019-09-12 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 制御方法、コントローラ、データ構造及び電力取引システム
WO2020170656A1 (ja) * 2019-02-22 2020-08-27 株式会社日立製作所 構成変更管理方法、構成変更管理システム、およびノード
JP2022046757A (ja) 2020-02-28 2022-03-23 アスエネ株式会社 電力取引システム
WO2022153375A1 (ja) * 2021-01-13 2022-07-21 富士通株式会社 データ格納方法、データ格納プログラム、および情報処理装置
JP2023061014A (ja) * 2021-10-19 2023-05-01 トヨタ自動車株式会社 電力取引システム、コンピュータ、電力取引方法

Also Published As

Publication number Publication date
JPWO2024262011A1 (ja) 2024-12-26
EP4715723A1 (en) 2026-03-25
CN121311915A (zh) 2026-01-09

Similar Documents

Publication Publication Date Title
US20200286132A1 (en) Second-hand vehicle transaction method and server
TW202038173A (zh) 基於區塊鏈的資料處理系統、方法、計算設備及儲存媒體
CN110659906B (zh) 票据信息处理方法、相关设备及介质
CN109447740A (zh) 无线电频谱资源交易方法、可读存储介质和终端
US20130041770A1 (en) Persistent network-based electronic transaction services
US12524759B2 (en) Systems and methods for transacting over a network
Radhakrishnan et al. Sdpp: Streaming data payment protocol for data economy
CN110955724B (zh) 基于区块链的数据处理方法、装置、节点设备及存储介质
JP2024514859A (ja) ブロックチェーンマイクロトランザクション
US8825008B2 (en) Method and apparatus for authorizing transfer of mobile devices
KR102320550B1 (ko) Did 기반 인터체인 시스템 및 그의 데이터 교환／거래 방법
KR20220095957A (ko) 블록체인 기반의 안전하고 신뢰 가능한 데이터 거래 방법 및 데이터 거래 플랫폼 제공 시스템
CN116957566A (zh) 基于区块链的数据处理方法及装置、电子设备、存储介质
WO2024262011A1 (ja) 情報管理装置、情報管理方法、およびプログラム
WO2024262013A1 (ja) 情報管理装置、情報管理方法、およびプログラム
WO2024262019A1 (ja) 情報管理装置、情報管理方法、およびプログラム
Baskaran Hybrid energy efficient deep learning and redactable consortium blockchain-based secure framework for smart parking in smart cities
CN109801052B (zh) 一种转账方法以及支付平台
CN112446508A (zh) 物流运输中包装的回收方法及装置、存储介质及电子设备
CN115879921A (zh) 一种电子门票的线上转让方法及装置
KR102674689B1 (ko) 상품의 판매 및 이동 이력 정보를 이용한 중고 거래 서비스 제공 시스템
CN115705566A (zh) 云数据处理方法、装置、计算机设备和存储介质
US20230124657A1 (en) EGR Powered System and Energy Provider Billing Entity, Billing Management Using Blockchain
JP2020071817A (ja) 情報処理方法、情報処理装置及びプログラム
JP2020113058A (ja) 情報処理方法、情報処理装置、およびプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23942442

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2025527387

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2023942442

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2023942442

Country of ref document: EP

Effective date: 20251217

ENP Entry into the national phase

Ref document number: 2023942442

Country of ref document: EP

Effective date: 20251217

ENP Entry into the national phase

Ref document number: 2023942442

Country of ref document: EP

Effective date: 20251217

ENP Entry into the national phase

Ref document number: 2023942442

Country of ref document: EP

Effective date: 20251217

ENP Entry into the national phase

Ref document number: 2023942442

Country of ref document: EP

Effective date: 20251217

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2023942442

Country of ref document: EP

Effective date: 20251217

ENP Entry into the national phase

Ref document number: 2023942442

Country of ref document: EP

Effective date: 20251217

ENP Entry into the national phase

Ref document number: 2023942442

Country of ref document: EP

Effective date: 20251217

WWP Wipo information: published in national office

Ref document number: 2023942442

Country of ref document: EP