WO2020072069A1 - Jeton de performance associé à un actif industriel utilisant un grand livre distribué sécurisé - Google Patents

Jeton de performance associé à un actif industriel utilisant un grand livre distribué sécurisé

Info

Publication number
WO2020072069A1
WO2020072069A1 PCT/US2018/054534 US2018054534W WO2020072069A1 WO 2020072069 A1 WO2020072069 A1 WO 2020072069A1 US 2018054534 W US2018054534 W US 2018054534W WO 2020072069 A1 WO2020072069 A1 WO 2020072069A1
Authority
WO
WIPO (PCT)
Prior art keywords
performance
industrial asset
contract
token
secure
Prior art date
Application number
PCT/US2018/054534
Other languages
English (en)
Inventor
Dan Yang
Jason Nichols
Benjamin Edward BECKMANN
John William Carbone
Joseph Salvo
Original Assignee
General Electric Company
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 General Electric Company filed Critical General Electric Company
Priority to PCT/US2018/054534 priority Critical patent/WO2020072069A1/fr
Publication of WO2020072069A1 publication Critical patent/WO2020072069A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q10/00—Administration; Management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0639—Performance analysis of employees; Performance analysis of enterprise or organisation operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/04—Manufacturing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/18—Legal services; Handling legal documents
    • G06Q50/188—Electronic negotiation
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/30—Computing systems specially adapted for manufacturing

Definitions

  • Some embodiments disclosed herein relate to an industrial asset performance token and, more particularly, to a token utilizing a secure, distributed transaction ledger.
  • a performance guarantee for an industrial asset is normally based on contractual terms with strict constraints on expected usage patterns and timeframes.
  • the actual usage pattern for the asset may play an important role for prosecuting a performance guarantee.
  • On an individual level a problem may occur when the difference between the actual and expected usage pattern leads to poor outcomes for either the customer or the guarantor.
  • On a collective level there is a distribution of performance for a group of assets with some assets outperforming expectations while others underperform.
  • a system may include a performance token creation node associated with an industrial asset.
  • the performance token creation node may receive information about the industrial asset performance model and access a set of industrial asset parameters associated with the industrial asset.
  • An industrial asset performance prediction, associated with at least one performance metric, may then be determined based on the industrial asset performance model and industrial asset parameters.
  • the performance token creation node may then create a performance token contract in accordance with the industrial asset performance prediction and record information about the performance token contract via a secure, distributed transaction ledger.
  • Some embodiments comprise: means for receiving, at a performance token creation node computer processor, information about an industrial asset performance model; means for accessing a set of industrial asset parameters associated with the industrial asset; means for determining an industrial asset performance prediction, associated with at least one performance metric, based on the industrial asset performance model and industrial asset parameters; means for creating a performance token contract in accordance with the industrial asset performance prediction; and means for recording information about the performance token contract via a secure, distributed transaction ledger.
  • FIG. 1 is a high-level block diagram of a system according to some embodiments.
  • FIG. 2 is a method in accordance with some embodiments.
  • FIG. 3 illustrates an industrial asset performance token environment according to some embodiments.
  • FIG. 4 illustrates an implementation of performance token contracts in accordance with some embodiments.
  • FIG. 5 contains global states associated with performance tokens according to some embodiments.
  • FIG. 6 is a high-level process diagram in accordance with some embodiments.
  • FIG. 7 is a system component and user diagram according to some embodiments.
  • FIG. 8 is a system implementing performance tokens with blockchain validation according to some embodiments.
  • FIG. 9 is a system implementing performance tokens with multiple token creation engines in accordance with some embodiments.
  • FIG. 10 is an example of a method associated with a battery life coin in accordance with some embodiments.
  • FIG. 11 is a create life model contract and contract creation result display according to some embodiments.
  • FIG. 12 is a storage life update display in accordance with some
  • FIG. 13 is a tablet computer with a contract update result display according to some embodiments.
  • FIG. 14 is a query balance and query balance result display in accordance with some embodiments.
  • FIG. 15 is a query usage and query usage results display according to some embodiments.
  • FIG. 16 contains graphs illustrating capacity and life coin values over time for various use cases in accordance with some embodiments.
  • FIG. 17 is a method associated with capacity coin according to some embodiments.
  • FIG. 18 contains a graph illustrating capacity coin values over time for various scenarios in accordance with some embodiments.
  • FIG. 19 is a distributed ledger reference architecture according to some embodiments.
  • FIG. 20 illustrates a platform according to some embodiments.
  • FIG. 21 is a portion of a performance token contracts database in accordance with some embodiments.
  • FIG. 1 is a high-level block diagram of a system 100 according to some embodiments.
  • the system 100 includes a performance token creation node 150 that communicates with an industrial asset performance model database 110.
  • the phrase“industrial asset” may refer to, for example, a battery or an energy reservoir ( e.g ., associated with a microgrid).
  • the phrase“energy reservoir” might refer to, for example, one or more energy storage devices such as batteries adapted to store electricity for a microgrid support from approximately three to
  • the term“energy consumer” may refer to individuals who consume or otherwise demand energy for their use as well as electrical loads, devices, appliances, vehicles, residences, buildings, or other objects or entities, both public and private, that may consume, or in some circumstances, generate energy.
  • the energy reservoir might be adapted to store energy generated by a local renewable energy source coupled to the microgrid (e.g., solar panels, wind turbines, hydroelectric energy sources, electric vehicle batteries, etc.).
  • the term “microgrid” may refer to any network associated with power distribution including networks that can stand alone (e.g, are isolated) as well as networks that are connected to a larger electrical grid.
  • the energy reservoir may in addition or instead be adapted to store energy generated by non-renewable sources such as combustion or compression sources.
  • the performance token creation node 150 may create and record performance contracts associated with digital tokens or coins.
  • the phrase“digital token” might be associated with, for example, a decentralized cryptotoken such as Bitcoin or a similar digital asset that serves as a medium of exchange using cryptography to secure the transactions and/or control the creation of additional units of the token.
  • a cryptotoken may be produced at a rate defined when the system is created.
  • the safety, integrity and balance of ledgers may be maintained by a community of entities utilizing, for example, the Secure Hash Algorithm (“SHA”) 256 cryptographic hash function, the XI 1 algorithm, the Equihash mining algorithm, the Scrypt key derivation function, etc.
  • SHA Secure Hash Algorithm
  • the performance token creation node 150 may also receive a set of industrial asset parameters.
  • the performance token creation node 150 might receive information about a battery’s temperature, voltage, depth of charge, slop of charge, etc.
  • a secure, distributed ledger 190 such as a ledger that utilizes“blockchain” technology.
  • the term“blockchain” may refer to a list of records, called blocks, which are linked and secured using cryptography. Each block may contain, for example, a hash pointer as a link to a previous block, a timestamp, transaction data, etc.
  • a blockchain may be resistant to data modification or tampering allowing parties to efficiently record information in a verifiable and permanent way.
  • a blockchain is managed by a peer-to-peer network that adheres to a protocol for validating new blocks.
  • the performance token creation node 150 could be completely de-centralized and/or might be associated with a third party, such as a vendor that performs a service for an enterprise.
  • the performance token creation node 150 might be, for example, associated with a Personal Computer (“PC”), laptop computer, a tablet computer, a smartphone, an enterprise server, a server farm, an Application Specific Interface Circuit (“ASIC”), a single board microcontroller card, an energy transaction engine, and/or a database or similar storage devices.
  • PC Personal Computer
  • ASIC Application Specific Interface Circuit
  • a single board microcontroller card a single board microcontroller card
  • an energy transaction engine and/or a database or similar storage devices.
  • an“automated” performance token creation node 150 may automatically facilitate the creation and/or use of performance contracts.
  • the term“automated” may refer to, for example, actions that can be performed with little (or no) intervention by a human.
  • devices including those associated with the performance token creation node 150 and any other device described herein, may exchange information via any communication network which may be one or more of a Local Area Network
  • LAN Local Area Network
  • MAN Metropolitan Area Network
  • WAN Wide Area Network
  • PSTN Public Switched Telephone Network
  • Wireless Fidelity Wireless Fidelity
  • WAP Application Protocol
  • Bluetooth Wireless LAN network
  • IP Internet Protocol
  • any devices described herein may communicate via one or more such
  • the performance token creation node 150 may store information into and/or retrieve information from data stores (e.g ., containers local to the controller and/or other data stores), such as the industrial asset performance model database 110.
  • the data stores might, for example, store electronic records representing industrial asset models, performance parameters, smart contracts, digital tokens, etc.
  • the data stores may be locally stored or reside remote from the performance token creation node 150.
  • FIG. 1 a single performance token creation node 150 is shown in FIG. 1, any number of such devices may be included and may be configured in a centralized, distributed, or cloud-based configuration.
  • various devices described herein might be combined according to embodiments of the present invention.
  • the performance token creation node 150, a device for exchanging contracts and digital tokens, the secure distributed ledger 190, and/or other devices might be co-located and/or may comprise a single apparatus.
  • the system 100 may facilitate an automated non- mutable warranty for an industrial asset (e.g. , based on usage of a battery and a battery life model).
  • the data may trustworthy and transparent to both manufactures and users of the industrial asset (e.g, storages vendor and customers).
  • Some embodiments may allow the performance of an asset to be treated as a fungible commodity that can be bought, sold, and/or traded in an open, trusted market.
  • Embodiments may also let buyer/seller relationships be established between humans and/or machines and enable a market driven optimization (e.g, to dynamically balance the allocation of performance risk across the market based on individual asset usage).
  • FIG. 2 illustrates a method 200 that might be performed by the performance token creation node 150 and/or other elements of the system 100 described with respect to FIG. 1, or any other system, according to some embodiments of the present invention.
  • the flow charts described herein do not imply a fixed order to the steps, and embodiments of the present invention may be practiced in any order that is practicable. Note that any of the methods described herein may be performed by hardware, software, or any combination of these approaches.
  • a computer-readable storage medium may store thereon instructions that when executed by a machine result in performance according to any of the embodiments described herein.
  • the system may receive, at a performance token creation node computer processor, information about an industrial asset performance model.
  • the performance model might comprise a physics-based model or surrogate model that predict how the industrial asset will perform over time.
  • the performance token creation node might be associated with, for example, a manufacturer of the industrial asset, an owner of the industrial asset, a user of the industrial asset, a service provider of the industrial asset, etc.
  • the system may access a set of industrial asset parameters associated with the industrial asset.
  • an industrial asset performance prediction associated with at least one performance metric, may be determined based on the industrial asset performance model and industrial asset parameters.
  • the industrial asset parameters might comprise, for example, values reflecting conditions that may impact the performance of the industrial asset (e.g ., a battery voltage, temperature, etc.).
  • a performance token contract may be created in accordance with the industrial asset performance prediction.
  • performance tokens e.g.,“coins
  • the performance token contract might include contract rules, exchange rules, a contract balance, at least one key consumption parameter, a reference to the industrial asset performance model, etc.
  • the performance token contract might be associated a fixed-time warranty or a fixed-usage warranty.
  • the system may record information about the performance token contract via a secure, distributed transaction ledger.
  • the transaction ledger might be associated with, for example, blockchain technology.
  • actual industrial asset parameters are measured by sensors and used to update the
  • a change to the industrial asset e.g ., an instillation of replacement batteries
  • parties may query the performance token contract via the secure, distributed transaction ledger to determine a current state of the asset.
  • embodiments may allow a network of users to create, update, query, and trade via a distributed ledger that tracks the performance of an asset as determined by a performance metric.
  • FIG. 3 illustrates an industrial asset performance token
  • user accounts 310 are user accounts 310 .
  • FIG. 4 illustrates an implementation 400 of performance token contracts in accordance with some embodiments.
  • a virtual machine 410 may contain registers (e.g, rl and r2), a storage element 410, and an instruction pointer that interacts with contract code 420 to manage and/or update an account 430.
  • registers e.g, rl and r2
  • FIG. 5 contains global states 500 associated with performance tokens, including key usages 510 (e.g, to transfer currency or coin between accounts), performance models 520 associated with industrial assets, and unique signatures 530 that may be used to verify transactions and/or performance models.
  • key usages 510 e.g, to transfer currency or coin between accounts
  • performance models 520 associated with industrial assets
  • unique signatures 530 may be used to verify transactions and/or performance models.
  • a flow of transactions 540 may use past, previous, and next signatures to verify an exchange of contracts, coins, input data, etc.
  • Some embodiments described herein may utilize smart contracts associated with“performance coins” that use blockchain currencies to track the performance of an asset as a function of its usage.
  • a unified representation of the performance as currency in a distributed ledger like blockchain, may help create a fungible commodity that can be used to quantify, track, and/or trade asset performance in a marketplace of assets.
  • Such a system may include three main elements: a contract that dictates the rules for updating the currency balance, a performance model that accurately predicts asset performance, and a distributed ledger that records the value of a contract at each transaction.
  • FIG. 6 is a high-level process diagram 600 including a blockchain network 650 associated with battery performance in accordance with some embodiments.
  • the blockchain network 650 might be utilized by warranty owners, battery owners, engineers, attorneys, etc.
  • the system 600 may allow for contract creation 610 in accordance with rules and a performance model.
  • A“life model contract” for an industrial asset battery might include, for example, a contract balance (e.g . , a number of tokens or coins) representing remining battery life.
  • contract rules maybe defined as warranty agreements and key consumption parameters of the battery life may be stored in blockchain along with a reference to battery life models.
  • Sensor data 622 may be collected from the field and used by a performance model 620 to update the contract 620. Users may then query the blockchain (via contract execution 630) to determine the remining life of battery along with a description of past usage.
  • events associated with key life stages may be emitted when appropriate.
  • A“model management contract” may include signatures of the battery life model stored in blockchain so that verification of performance models may be provided.
  • the blockchain network 650 may also be used to exchange or trade performance contracts 640 (or coins associated with performance contracts) between users.
  • FIG. 7 is an energy storage system component and user diagram 700 including a blockchain network 750 according to some embodiments.
  • one or more contracts may be created.
  • two smart contracts might be created to manage the storage life and a performance model used for predictions.
  • the first contract may be associated with a“life model” and include a contract balance that represents the remaining life of storage, contract rules defined as warranty agreements, key consumption parameters stored in the blockchain network 750, a reference to associated life models stored in the blockchain network 750, battery usage and remaining life (that can be queried 720 through the smart contract), etc.
  • key battery events e.g., stage of the life, consumption of the life
  • the second contract may be associated with“model management” and include signatures of the battery life model stored in the blockchain network 750 (to support model verification).
  • contract creation 710 initially stores a life model contract charged with 100 ethers (full life) and model contract in the blockchain network 750.
  • the balance (representing remining life of the storage) of the life model contract is updated each time unit with battery usage data 734 (and, if applicable, sensor data), and the life models’ signatures are calculated and stored in the model management contract (e.g., via off chain calculations 732).
  • An entity may then retrieve the contract balance with usage data (as remining life) from the blockchain network via a query 720.
  • events may emanate from the contract to be captured from a network for life management.
  • FIG. 8 is a system 800 implementing performance tokens with blockchain validation according to some embodiments.
  • a cloud-based integrity monitor 810 may provide performance contract and/or token integrity data via a web browser and exchange information with a blockchain 820 and a token creation request 850 via Representational State Transfer (“REST”) web services.
  • the REST web services may, for example, provide interoperability between computer systems on the Internet (e.g, by allowing requesting systems to access and manipulate textual representations of web resources using a uniform, predefined set of stateless operations).
  • portions of the token creation request 850 may be associated with a MySQL database. In this way, the token creation request 850 and blockchain 820 can be used to provide transaction level verification for a client 840.
  • token creation request 850 may be a client to the blockchain 820 and all token creation, important data storage, and verification may occur in the blockchain 830.
  • FIG. 8 illustrates a system 800 with a single blockchain 820 and token creation request 850, note that embodiments may employ other topologies. For example,
  • FIG. 9 is a system 900 implementing performance tokens with multiple token creation requests 950, 952 in accordance with some embodiments.
  • an additional blockchain 922 and token creation request 952 may provide protection for an additional client 942.
  • each token creation request 950, 952 may be associated with multiple blockchains 920, 922 providing additional protection for the system 900 (e.g, by storing information at multiple, geographically disperse nodes making attacks impractical). That is, each verifier (e.g, token creation engine) may commit a brief summary to an independent data store and, once recorded, the information cannot be changed without detection to provide a tamper-proof System of Records (“SoR”) for a cloud-based token exchange 910.
  • SoR System of Records
  • an energy storage life coin may use blockchain currency/coins to model storage life, and the consumption of life may be derived from life model based on usages.
  • a warranty may be created at 1010 based on battery usage status, and battery life cycle may be managed at 1020 by sending important life events through the distributed blockchain network 750.
  • battery life may be analyzed at 1030 by trusted usage data, legal disputes may be resolved by the retrieval and leveraging of trusted data at 1040, and financial products might be created at 1050 based on the life coins.
  • FIG. 11 is a create life model contract and contract creation result display 1100 according to some embodiments.
  • a first portion 1110 of the display 1100 may be used to enter an initial capacity, threshold, and total number of coins for a performance token contract.
  • a“Create” icon 1120 e.g ., via a computer mouse pointer or touchscreen
  • a second portion 1130 may display the contract that was created along with a contract address associated with the information.
  • FIG. 12 is a storage life update display 1200 in accordance with some embodiments.
  • a portion 1210 of the display may be used to enter industrial asset parameters for a contract address, such as a start period, temperature, voltage, depth of charge, slope of charge, etc. and a user may select an“Update” icon 1220 to apply the entered values to the contract.
  • FIG. 13 is a tablet computer 1300 with a contract update result display 1310 according to some embodiments (reflecting the data entered in FIG. 12).
  • FIG. 14 is a query balance and query balance result display 1400 in accordance with some embodiments.
  • a first portion 1410 of the display 1400 may be used to enter a contract address for a performance token contract.
  • a“Query” icon 1420 e.g., via a computer mouse pointer or touchscreen
  • a second portion 1430 may display the current balance of that performance token contract.
  • FIG. 15 is a query usage and query usage results display 1500 according to some embodiments.
  • a first portion 1510 of the display 1500 may be used to enter a contract address and start period for a performance token contract.
  • a second portion 1530 may display usage for that contract address (e.g, a battery temperature, voltage, depth of charge, slope of charge, etc.).
  • usage for that contract address e.g, a battery temperature, voltage, depth of charge, slope of charge, etc.
  • One embodiment may comprise a battery lifing example referred to as a“life coin.” As a battery is used, the storage capacity of the energy storage system typically degrades until battery replacements are required to maintain a minimum capacity. The battery replacement schedule is typically covered under a service contract with fixed terms and conditions.
  • the industrial asset is an energy storage device, and the performance metric is the remaining useful life expressed as a percent of initial capacity.
  • the architecture may comprise two smart contracts, an Ethereum network, a battery lifing model, and battery testing data.
  • the smart contracts may comprise a contract to manage the storage life and a contract to manage the lifing model.
  • the life coin contracts may be created, for example, to replace the traditional service contract and allow a user to query asset usage, remaining useful life, contract value, and/or the model identity/history at any time during the contract life.
  • the first smart contract may manage the accounting of the performance metric.
  • the terms for updating the remaining useful life and any associated guarantees may be specified.
  • key battery events e.g, stage of the life, consumption of the life
  • the performance contract might include, for example:
  • the second smart contract may manages the performance model.
  • the model used to calculate the remaining useful life may be specified.
  • Key model events (such as revisions, updated parameter tunings, etc.) may emanate from smart contract.
  • the performance model contract might include, for example:
  • the use case in the life coin embodiment demonstrates the creation, update, query, and exchange of battery performance contracts stored in an Ethereum blockchain network.
  • the workflows of four actions may be available to system users:
  • a battery lifing contract and lifing model contract may be created when energy storage starts operation.
  • the battery lifing balance may, for example, be charged with 100 ethers (full life).
  • the battery lifing balance may be updated at the specific frequency based on the remaining useful life using the specified lifing model and usage data and the specified exchange rate. Note that the value of the contract decreases with increased usage of the battery system.
  • Contract Query The battery lifing balance may be queried for human-driven or algorithmic decision making. For example, based on the contract terms when the value of the contract hits a threshold limit, additional might need must be fielded to restore the battery back to its initial capacity. This might be done, for example, according to a cost in Ethereum negotiated in the contract.
  • Ethereum may be traded between two operators.
  • FIG. 16 contains graphs 1600 illustrating capacity and life coin values over time for various use cases in accordance with some embodiments.
  • a first graph 1610 shows capacity 1612 (solid line) and life coin 614 (dotted line) for a light use scenario where the battery experiences a light duty cycle and is discharged at rest.
  • a second graph 1620 shows capacity 1622 and life coin 1624 for a moderate use scenario where the battery experiences a moderate duty cycle and is partially discharged at rest.
  • a third graph 1630 shows capacity 1632 and life coin 1634 for a heave use scenario where the battery
  • the graphs 1610, 1620, 1630 show the impact of usage, contract rules for maintaining capacity, and the battery degradation estimate on a battery lifing contract. As can be seen, a user that uses the battery in a“light use” duty cycle 1610 consumes the value of their battery lifing contract more slowly than that of a“heavy use” duty cycle 1630.
  • the graphs 1610, 1620, 1630 in FIG. 16 show that the amount of battery life used during the contract is fixed, but that the timeframe and duty cycle of the contract is variable.
  • This type of contract is in contrast to a fixed duty cycle, fixed timeframe guarantee in that it lets the asset owner use the asset as they choose while the guarantor and the asset owner both have full visibility on the usage impact on the battery lifing contract.
  • the asset owner with the heavy use duty cycle could purchase a contract extension directly from the asset owner with the light use duty cycle or through an Ethereum purchase/exchange.
  • the service contract can be managed more efficiently through direct exchanges between asset owners without involving the asset supplier.
  • the performance model estimates the cost of storing a quantity of energy for a fixed duration is referred to as a“capacity coin.”
  • a“capacity coin” battery storage capacity and the impact of storage over time is converted to a performance metric using a combination of a performance and lifing model. In general, the longer a battery is required to hold a quantity of energy, the more the battery degrades.
  • FIG. 17 is a method 1700 associated with capacity coin according to some embodiments.
  • the capacity coin embodiment may let the energy trader to open an account with the storage supplier at 1710, charge the account with capacity coin at 1720, and then store energy on demand as the account is decremented by the performance model at 1730 according to an agreed upon price.
  • th capacity coin may convert battery storage capacity and the impact of storage over time is into a performance metric using a combination of a
  • the capacity coin architecture might include two smart contracts, an Ethereum network, a battery lifing and performance model, and battery testing data.
  • the smart contracts might comprise a contract to manage the capacity coin account and a contract to manage the lifing and performance models. These contracts might have similar attributes as the life coin contracts.
  • FIG. 18 contains a graph 1800 illustrating capacity coin values over time for various scenarios in accordance with some embodiments.
  • the graph 1800 shows a collection of scenarios for capacity coin consumption for three different energy traders.
  • a first scenario 1810 (Trader 1)
  • the trader needs to store 10 MW for 4 hours per day at an off-peak time with respect to the battery capacity.
  • Trader 1 has a negotiated rate for storage in terms of capacity coin and the contract value is automatically updated with each storage transaction.
  • Trader 2 has a more intensive storage requirement, requiring 10 MW to be stored for 18 hours per day at an off-peak capacity time for the battery. This causes more damage to the battery system and costs the trader more capacity coin for each storage transaction.
  • Trader 3 requires 10 MW to be stored for 18 hours per day during a peak capacity time for the battery.
  • the storage capacity is at a premium and costs the most capacity coin.
  • the scenarios 1810, 1820, 1830 are fixed capacity/fixed time frame simulations, it follows that an actual trader could behave like a composite of these and other contract scenarios. Some embodiments may allow for a buyer and seller to use, quantify, track, and/or trade available storage in substantially real time.
  • FIG. 19 is a distributed ledger reference architecture 1900 according to some embodiments.
  • the architecture 1900 includes ledger services and an event stream 1910 that may contain network security service information (e.g ., from a performance token creation node).
  • Membership services 1920 e.g, including registration, identity managements, and/or an auditability process
  • Blockchain services 1930 may manage the distributed ledger through a P2P protocol built on HTTP to maintain a single state that replicated at many nodes to support blockchains 1960 and transactions 1970.
  • Chaincode services 1940 e.g, secure container and/or a secure registry associated with a smart contract may help
  • FIG. 20 illustrates a platform 2000 that may be, for example, associated with the systems 100, 600 of FIGS. 1 and 6, respectively (as well as other systems described herein).
  • the platform 2000 comprises a processor 2010, such as one or more commercially available Central Processing Units (“CPUs”) which may be in the form of one-chip microprocessors, coupled to a communication device 2020 configured to communicate via a communication network (not shown in FIG. 20).
  • the communication device 2020 may be used to communicate, for example, with one or more secure, distributed ledgers, consumers, or token exchange engines.
  • communications exchanged via the communication device 2020 may utilize security features, such as those between a public internet user and an internal network of an insurance enterprise.
  • the security features might be associated with, for example, web servers, firewalls, and/or PCI infrastructure.
  • the platform 2000 further includes an input device 2040 (e.g ., a mouse and/or keyboard to enter information about a battery, a consumer, a distributed ledger, etc.) and an output device 2050 (e.g., to output energy reports, generate energy status messages, etc.).
  • an input device 2040 e.g a mouse and/or keyboard to enter information about a battery, a consumer, a distributed ledger, etc.
  • an output device 2050 e.g., to output energy reports, generate energy status messages, etc.
  • the processor 2010 also communicates with a storage device 2030.
  • the storage device 2030 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g. , a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices.
  • the storage device 2030 stores a program 2012 and/or performance token tool or application for controlling the processor 2010.
  • the processor 2010 performs instructions of the program 2012, and thereby operates in accordance with any of the embodiments described herein.
  • the processor 2010 may receive information about the industrial asset performance model and access a set of industrial asset parameters associated with the industrial asset.
  • An industrial asset performance prediction, associated with at least one performance metric may then be determined by the processor 2010 based on the industrial asset performance model and industrial asset parameters.
  • the processor 2010 may then create a performance token contract in accordance with the industrial asset performance prediction and record information about the performance token contract via a secure, distributed transaction ledger.
  • the program 2012 may be stored in a compressed, uncompiled and/or encrypted format.
  • the program 2012 may furthermore include other program elements, such as an operating system, a database management system, and/or device drivers used by the processor 2010 to interface with peripheral devices.
  • information may be“received” by or“transmitted” to, for example: (i) the platform 2000 from another device; or (ii) a software application or module within the platform 2000 from another software application, module, or any other source.
  • the storage device 2030 further stores a user account database 2060 (e.g . , associated with asset owners, service providers, etc.), a models and parameters database 2070 (e.g., storing performance models and details about particular industrial asset), and a performance token contract database 2100.
  • a user account database 2060 e.g . , associated with asset owners, service providers, etc.
  • a models and parameters database 2070 e.g., storing performance models and details about particular industrial asset
  • a performance token contract database 2100 e.g., storing performance models and details about particular industrial asset
  • An example of a database that might be used in connection with the platform 2000 will now be described in detail with respect to FIG. 21.
  • the databases described herein are only examples, and additional and/or different information may be stored therein.
  • various databases might be split or combined in accordance with any of the embodiments described herein.
  • the databases 2060, 2070, 2100 might be combined and/or linked to each other within the program 2012.
  • a table that represents the performance token contracts database 2100 that may be stored at the platform 2000 in accordance with some embodiments.
  • the table which contains a list of smart contracts, may include, for example, entries identifying performance token contracts that may be stored in blockchain.
  • the table may also define fields 2102, 2104, 2106, 2108, 2110, 2112, 2114 for each of the entries.
  • the fields 2102, 2104, 2106 may, according to some embodiments, specify: a performance token contract identifier 2102, a description 2104, a creation date (and time) 2106, a performance model identifier 2108, an initial capacity 2110, a number of total tokens 2112, and a contract address 2114.
  • the performance token contracts database 2100 may be created and updated, for example, based on information electrically received from remote token contract creation platforms.
  • the performance token contract identifier 2102 may be, for example, a unique alphanumeric code identifying an industrial asset to be associated with performance tokens.
  • the description 2104 may describe the asset (e.g, model number, year of manufacture, software version, etc.), and the creation date (and time) 2106 may indicate when the smart contract was initially created.
  • the performance model identifier 2108 might define (or link to) an algorithm that takes asset parameters as inputs and generates a performance prediction as an output.
  • the initial capacity 2110 might indicate an initial ability or capacity of the asset (e.g, as a percentage) and the number of total tokens 2112 may divide that ability or capacity into sub-units.
  • the contract address 2114 may indicate where in a blockchain the smart contract can be located ( e.g ., for verification, queries, etc.).
  • embodiments may help create performance guarantees based on performance models that are tracked in a distributed ledger creating a universally trusted, transparent source of information. Moreover, embodiments may manage asset performance by sending important operating events to a distributed ledger and/or analyze asset performance using universally trusted usage data. According to some embodiments, legal disputes may be resolved with universally trusted usage data and use-based performance guarantees (whose value is tracked and updated in real-time) can be made. In addition, some embodiments might be used to create fungible forms of performance guarantees that can be traded between network assets.

Abstract

Un système peut comprendre un noeud de création de jeton de performance associé à un actif industriel. Le noeud de création de jeton de performance peut recevoir des informations concernant le modèle de performance d'actif industriel et accéder à un ensemble de paramètres d'actifs industriels associés à l'actif industriel. Une prédiction de performance d'actif industriel, associée à au moins une métrique de performance, peut ensuite être déterminée sur la base du modèle de performance d'actif industriel et de paramètres d'actif industriel. Le noeud de création de jeton de performance peut ensuite créer un contrat de jeton de performance en conformité avec la prédiction de performance d'actif industriel, et enregistrer des informations concernant le contrat de jeton de performance par le biais d'un registre de transaction distribué sécurisé.
PCT/US2018/054534 2018-10-05 2018-10-05 Jeton de performance associé à un actif industriel utilisant un grand livre distribué sécurisé WO2020072069A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2018/054534 WO2020072069A1 (fr) 2018-10-05 2018-10-05 Jeton de performance associé à un actif industriel utilisant un grand livre distribué sécurisé

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2018/054534 WO2020072069A1 (fr) 2018-10-05 2018-10-05 Jeton de performance associé à un actif industriel utilisant un grand livre distribué sécurisé

Publications (1)

Publication Number Publication Date
WO2020072069A1 true WO2020072069A1 (fr) 2020-04-09

Family

ID=64051691

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/054534 WO2020072069A1 (fr) 2018-10-05 2018-10-05 Jeton de performance associé à un actif industriel utilisant un grand livre distribué sécurisé

Country Status (1)

Country Link
WO (1) WO2020072069A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017004527A1 (fr) * 2015-07-02 2017-01-05 Nasdaq, Inc. Systèmes et procédés de provenance sécurisée pour des bases de données de transactions distribuées
WO2017007806A1 (fr) * 2015-07-09 2017-01-12 Ouisa, LLC Systèmes et procédés permettant de négocier, accepter et régler des transactions de titres à l'aide d'une technologie de chaîne de blocs
WO2018127923A1 (fr) * 2017-01-08 2018-07-12 Eyal Hertzog Procédés d'échange et d'évaluation de monnaie virtuelle

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017004527A1 (fr) * 2015-07-02 2017-01-05 Nasdaq, Inc. Systèmes et procédés de provenance sécurisée pour des bases de données de transactions distribuées
WO2017007806A1 (fr) * 2015-07-09 2017-01-12 Ouisa, LLC Systèmes et procédés permettant de négocier, accepter et régler des transactions de titres à l'aide d'une technologie de chaîne de blocs
WO2018127923A1 (fr) * 2017-01-08 2018-07-12 Eyal Hertzog Procédés d'échange et d'évaluation de monnaie virtuelle

Similar Documents

Publication Publication Date Title
Andoni et al. Blockchain technology in the energy sector: A systematic review of challenges and opportunities
Thukral Emergence of blockchain-technology application in peer-to-peer electrical-energy trading: A review
Shen et al. Secure sharing of big digital twin data for smart manufacturing based on blockchain
US20220179378A1 (en) Blockchain-Based Transactive Energy Systems
Yap et al. Blockchain technology for distributed generation: A review of current development, challenges and future prospect
Dzobo et al. Proposed framework for blockchain technology in a decentralised energy network
US20190386968A1 (en) Method to securely broker trusted distributed task contracts
CN116385164B (zh) 一种基于区块链的碳资产交易系统及方法
EP3614326A1 (fr) Système et procédé permettant de cartographier un modèle de construction virtuel
Cali et al. Cybersecure and scalable, token-based renewable energy certificate framework using blockchain-enabled trading platform
US20230352938A1 (en) Methods, systems, apparatuses, and devices for facilitating managing interconnection processes on a power transmission network
Junaidi et al. Blockchain-based management of demand response in electric energy grids: A systematic review
CN113706312A (zh) 基于区块链的光伏电交易方法和装置
Kim et al. Online risk analytics on the cloud
JP7219612B2 (ja) 故障検知システム
CN116703600A (zh) 一种基于区块链的电力交易数据处理系统及方法
WO2020072069A1 (fr) Jeton de performance associé à un actif industriel utilisant un grand livre distribué sécurisé
CN114529376A (zh) 能源兑换数据处理方法、装置、计算机设备和存储介质
US20230259992A1 (en) Methods and systems for real-time composite performance score assessment for a system comprising lib assets
CN112365362A (zh) 基于电网现有it域资产数据采用区块链技术进行保护的方法
WO2020145964A1 (fr) Transactions sécurisées
US11853316B1 (en) System and method for the creation and management of privacy-preserving audits
Miehle Distributed Ledger Technologies in the Automotive Value Chain
Karandikar Blockchain based energy transactions for a prosumer community
US20240111273A1 (en) Performance-based smart contracts in industrial automation

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: 18796186

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18796186

Country of ref document: EP

Kind code of ref document: A1