REAL-TIME RENEWABLE ENERGY CREDITS

Abstract

A system is provided for matching real-time renewable resource credits with energy loads. The system generates real-time renewable energy credits (RECs) in real time with one or more attributes. A real-time REC is evidence of production of a base amount of electricity with attributes that may include actual time of production, location of production, and power type. When a supplier generates a base amount of electricity using renewable energy, the supplier is issued a real-time REC indicating actual time and production location. A consumer may purchase the real-time REC from that supplier based on matching the consumer's consumption to the real-time REC, make a claim, and then retire the real-time REC. As a result of this matching of production and consumption based on actual time and location, suppliers of electricity generated using renewable energy may be incentivized to build renewable energy plants near consumers, resulting in less pollution and less loss of energy during transmission.

Claims

1. A method performed by a computing device for matching real-time renewable energy credits with real-time energy loads, each real-time renewable energy credit being generated in real time and having one or more attributes, the method comprising: accessing production messages that each indicate production of renewable energy by a supplier, each production message indicating time of production; for each production message, generating a real-time renewable energy credit with attributes indicating the supplier and time of the production; accessing real-time energy loads that each indicate consumption of energy by a consumer, each real-time energy load being generated in real time and having attributes indicating the consumer and time of consumption; matching real-time renewable energy credits with real-time energy loads based on time of production and time of consumption; and for each matched real-time renewable energy credit and real-time energy load, allocating that real-time renewable energy credit to the consumer of that real-time energy load.

2. The method of claim 1 wherein the real-time renewable energy credits and the real-time energy loads are stored as transactions in a blockchain.

3. The method of claim 2 wherein the matching and allocating are performed by a smart contract recorded in the blockchain.

4. The method of claim 1 wherein the production messages are generated by devices of suppliers.

5. The method of claim 1 further comprising accessing consumption messages from consumers and generating a real-time energy load for each consumption message.

6. The method of claim 1 wherein each real-time renewable energy credit includes an attribute indicating location of production of renewable energy and each real-time energy load includes an attribute indicating location of consumption of energy and wherein the matching is further based on location of production and location of consumption.

7. The method of claim 1 wherein the matching is performed by conducting an auction in which consumers submit bids for matching their real-time energy loads to real-time renewable energy credits.

8. The method of claim 1 wherein the matching is performed by applying an optimization technique that attempts to maximize the differences between prices at which suppliers are willing to sell real-time energy credits and prices that consumers are willing to pay for real-time energy credits.

9. The method of claim 1 wherein the real-time renewable energy credits and the real-time energy loads are stored as records in a database that is not a distributed ledger.

10. One or more computing systems for matching real-time renewable energy credits with real-time energy loads, the one or more computing systems comprising: one or more computer-readable storage mediums for storing computer-executable instructions for controlling the one or more computing systems to: generate real-time renewable energy credits with attributes indicating a supplier and time of the production; match real-time renewable energy credits with real-time energy loads, each real-time energy load having attributes indicating a consumer and time of consumption, the matching based on time of production and time of consumption; and for each matched real-time renewable energy credit and real-time energy load, allocate that real-time renewable energy credit to the consumer of that real-time energy load; and one or more processors for executing the computer-executable instructions stored in the one or more computer-readable storage mediums.

11. The one or more computing systems of claim 10 wherein the real-time renewable energy credits and the real-time energy loads are stored as transactions in a blockchain.

12. The one or more computing systems of claim 11 wherein the matching and allocating are performed by a smart contract recorded in the blockchain.

13. The one or more computing systems of claim 10 wherein the computer-executable instructions further control the one or more computing systems to receive production messages that are generated by devices of suppliers and wherein a production message indicates amount of production, each real-time renewable energy credit having an amount of production.

14. The one or more computing systems of claim 13 wherein the computer-executable instructions further control the one or more computing systems to receive consumption messages that are generated by devices of consumers and wherein a consumption message indicates amount of consumption.

15. The one or more computing systems of claim 14 wherein the matching is further based on matching amount of production with amount of consumption.

16. The one or more computing systems of claim 10 wherein the computer-executable instructions further control the one or more computing systems to access consumption messages from consumers and generate a real-time energy load for each consumption message.

17. The one or more computing systems of claim 10 wherein each real-time renewable energy credit includes an attribute indicating location of production of renewable energy and each real-time energy load includes an attribute indicating location of consumption of energy and wherein the matching is further based on location of production and location of consumption.

18. The one or more computing systems of claim 10 wherein the matching is performed by conducting an auction in which consumers submit bids for matching their real-time energy loads to real-time renewable energy credits.

19. The one or more computing systems of claim 10 wherein the matching is performed by applying an optimization technique that attempts to maximize the differences between prices at which suppliers are willing to sell real-time energy credits and prices that consumers are willing to pay for real-time energy credits.

20. The one or more computing systems of claim 10 wherein the real-time renewable energy credits and the real-time energy loads are stored as records in a database that is not a distributed ledger.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG. 1 is a diagram that illustrates the real-time power generation and consumption of a residence equipped with a rooftop solar system in some embodiments.

[0015] FIG. 2 is a diagram that illustrates the matching of unmatched power generation to consumers.

[0016] FIG. 3 is a diagram that illustrates the time-based matching of solar power with a consumer who does not generate solar power.

[0017] FIG. 4 is a diagram that illustrates time-based matching of solar power with a consumer who does not generate solar power.

[0018] FIG. 5 is a diagram that illustrates power generation for different types of renewable energy.

[0019] FIG. 6 is a diagram that illustrates the matching of renewable energy with a commercial consumer.

[0020] FIG. 7 is a flow diagram that illustrates the processing of a component that matches real-time RECs to real-time ELs in some embodiments.

[0021] FIG. 8 is a block diagram that illustrates components of the real-time REC system in some embodiments.

[0022] FIG. 9 is a flow diagram that illustrates the processing of a receive production message component of a real-time REC smart contract in some embodiments.

[0023] FIG. 10 is a flow diagram that illustrates the processing of a create real-time REC component in some embodiments.

[0024] FIG. 11 is a flow diagram that illustrates the processing of a receive consumption message component of the real-time REC system in some embodiments.

[0025] FIG. 12 is a flow diagram that illustrates the processing of a create real-time EL component of the real-time REC system in some embodiments.

[0026] FIG. 13 is a flow diagram that illustrates the processing of a matching component of the real-time REC system in some embodiments.

[0027] FIG. 14 is a flow diagram that illustrates the processing of a receive bid request component of a consumer smart contract in some embodiments.

DETAILED DESCRIPTION

[0028] Methods and systems are provided for matching real-time renewable resource credits with real-time energy loads. In some embodiments, a real-time REC system generates real-time renewable energy credits in real time with one or more attributes. A real-time REC is evidence of production of a base amount of electricity (e.g., 1 kWh) that is generated in real time with attributes that may include actual time of production (e.g., start time of production, such as 1:00 PM, and end time of production, such as 1:57 PM), location of production (e.g., Global Positioning System coordinates of wind farm), power type (e.g., solar, wind, or hydro), supplier of the electricity, and so on. When a supplier generates a base amount of electricity using renewable energy, the supplier is issued a real-time REC indicating actual time and location of production such as 12:00-1:06 PM on August 1 in New York City. A consumer in New York City who uses the base amount of electricity between 12:00 and 1:06 PM (referred to as an energy load) may want to claim that it consumed electricity produced by renewable energy at the same time and location. Such a consumer may purchase the real-time REC from that supplier (or third-party broker, retail energy company, and so on), make the claim, and then retire the real-time REC. As a result of this matching of production and consumption based on actual time and location, suppliers of electricity generated using renewable energy may be incentivized to build renewable energy plants near consumers, resulting in less pollution and less loss of energy during transmission. The real-time RECs are real time in the sense that are created in real time as the power is generated, in contrast to conventional RECs, which may be considered to be created offline sometime after the power is generated. The real-time REC system also overcomes problems of prior RECs in that the real-time REC system ensures that one real-time REC is not transferred to multiple consumers.

[0029] In some embodiments, the real-time REC system may employ a distributed ledger (such as a blockchain) to track production and consumption of electricity, control issuing of real-time RECs, match real-time RECs to real-time energy loads (ELs), trade real-time RECs, retire real-time RECs, and so on. Each supplier of electricity generated using renewable energy may have a production monitoring device that monitors production and, when the base amount of electricity is produced, effects the recording of a transaction in the blockchain as evidence of a real-time REC issued to the supplier. The production monitoring device may send a production message to an issuance smart contract recorded in the blockchain that is responsible for issuing real-time RECs and recording the real-time REC transactions in the blockchain. Each consumer of electricity who wants to consume electricity produced using renewable energy may have a consumption monitoring device that monitors consumption and, when the base amount of electricity is consumed, records a real-time EL in the blockchain as evidence of the consumption.

[0030] The real-time REC system may record a matching smart contract in the blockchain that is responsible for matching real-time RECs with real-time ELs based on their attributes such as time and location of production and consumption. The matching smart contract may execute on a periodic basis (e.g., upon receiving a message from an oracle) and match real-time RECs with real-time ELs. For example, the matching smart contract may execute once a day and, for each time slot (e.g., hour), match real-time RECs with real-time ELs with times during that time slot. The matching smart contract may employ an off-blockchain program that employs various optimization techniques to match real-time RECs to real-time ELs to, for example, minimize the overall differences in time of production and consumption and the overall distance between location of production and consumption. The off-blockchain program may employ an objective function that is based on several of the attributes of the real-time RECs and real-time ELs. Alternatively, the matching smart contract code may conduct an auction to match real-time RECs to real-time ELs. To conduct an auction, the matching smart contract code (or a corresponding off-blockchain program) may send bid request messages to bidding smart contracts of consumers to submit a bid to purchase that real-time REC to be matched with a real-time EL of a consumer. Once the bids for a real-time REC are received from the consumers, the matching smart contract code may select the real-time EL with the highest bid and match that real-time EL with the real-time REC by recording a transaction in the blockchain. The consumer of the real-time EL can then base a claim based on the real-time REC. Because a transaction matching the real-time REC with the real-time EL is recorded in the blockchain, that real-time REC cannot be matched to another real-time EL as the basis of a claim. This provides a technical solution to a problem of traditional RECs in that a supplier of a traditional REC could sell the same REC to multiple consumers, who could each make claims. The use of a distributed ledger by the real-time REC system provides indisputable proof of ownership and prevents the same real-time REC from being transferred to multiple owners (e.g., prevents it from being double-spent).

[0031] In some embodiments, each consumer may record a bidding smart contract in the blockchain to submit bids on behalf of that consumer. A bidding smart contract may have access to rules of the consumer for controlling the placing of bids. The rules may be recorded in the blockchain and updated periodically. The rules may, for example, base the bid amount on the difference between the time and location of a real-time REC and a real-time EL. Alternatively, the bidding smart contract for a consumer may employ off-blockchain code to generate bids for the consumer.

[0032] Many different countries and regions use renewable energy credits to incentivize production of renewable energy, although they may use different terminology to refer to REC-like concepts. For example, in the European Union the concept is referred to as Guarantee of Origin (GO), in Australia the concept is referred to as Large-scale Generation Certificate (LGC) and Small-scale Technology Certificate (STC), and in India the concept is referred to as the Renewable Purchase Obligation (RPO). The real-time REC system may be employed in these countries and regions and even in countries and regions that currently do not employ REC-like concepts.

[0033] FIG. 1 is a diagram that illustrates the real-time power generation and consumption of a residence equipped with a rooftop solar system in some embodiments. At any given time interval, the solar system may generate more electricity than is consumed at the residence. Graph 100 includes an x-axis of hours (0-24) and a y-axis of power (kW). Line 101 represents the power consumed by the residence, and line 102 represents the power generated by the solar system. Area 103 represents the unmatched consumption, that is, power consumed in excess of power generated at the residence. Area 104 represents unmatched generation, that is, power generated in excess of consumption at the residence. Area 105 represents matched generation, that is, power generated but not consumed at the residence. The consumption monitoring device at the residence (or at the point at where the power enters the grid) directs that a real-time REC transaction be recorded in the blockchain each time a base amount of power is generated in excess of consumption.

[0034] FIG. 2 is a diagram that illustrates the matching of unmatched power generation to consumers. Graph 200 illustrates the matching to consumers 1, 2, and 3. Areas 201, 202, and 203 are matched to consumers 1, 2, and 3, respectively. The consumption monitoring device of each consumer records a real-time EL transaction in the blockchain each time the consumer consumes the base amount of power in excess of consumption. The matching smart contract then matches the real-time RECs of the residence with the real-time ELs of the consumers, resulting in the matching illustrated by graph 200.

[0035] FIG. 3 is a diagram that illustrates the time-based matching of solar power with a consumer who does not generate solar power. Graph 300 illustrates the power consumed by the consumer. Area 301 represents power that is consumed during the nighttime, and thus the corresponding real-time ELs cannot be matched to real-time RECs representing solar power when time of day is a matching criterion. Area 302 represents power that is consumed during the daytime, and thus the corresponding real-time ELs can be matched to real-time RECs representing solar power. FIG. 4, like FIG. 3, is a diagram that illustrates time-based matching of solar power with a consumer who does not generate solar power.

[0036] Different renewable energy resources generate energy at different times of the day. For example, wind generation is high during the nighttime and low during the daytime. Solar generation exists only during the daytime and is nonexistent during the nighttime. Hydroelectric generation is constant throughout the day. When matching a real-time EL to a real-time REC based only on time, the real-time REC system matches based on times of generation and consumption irrespective of type of power. When matching based on both time and type of power, the real-time REC system matches based on both times of generation and consumption and types of power generated and specified by the consumer.

[0037] FIG. 5 is a diagram that illustrates power generation for different types of renewable energy. Graph 500 illustrates the power generated. Area 501 represents hydroelectric power, which is constant throughout the day. Area 502 represents wind power, which varies throughout the day. Area 503 represents solar power, which is only available during the daytime and varies throughout the day. The real-time RECs are recorded by the suppliers of the hydroelectric, wind, and solar energy, which are then matched with the real-time ELs recorded by consumers based on time of production and time of consumption.

[0038] FIG. 6 is a diagram that illustrates the matching of renewable energy with a commercial consumer. Graph 600 illustrates the consumption and types of power to which the consumption is matched. Line 605 represents the energy consumed or load. Graph 500 (FIG. 5) illustrates the available power that is matched to the load of line 605. In this example, the supply 501-503 matches loads 601-603. Area 604 represents consumption that is unmatched by the generation of graph 500 during hours 15-22. The real-time REC system may match real-time RECs from energy storage charged by a renewable source to real-time ELs during hours 15-22. The real-time REC system may employ various algorithms when matching to real-time RECs from energy storage. For example, the real-time REC system may give preference to matching real-time RECs for non-storage sources over storage sources because the cost of storage sources can be much higher than the cost of non-storage. Nevertheless, the real-time REC system may match to storage sources to ensure that real-time EIs are matched to the extent possible 24/7/365.

[0039] The real-time REC system can interface with (e.g., via an application programming interface or client-side software) production and consumption devices to collect operational data at a relatively high rate such as periodically (e.g., hourly), when a base amount of energy is produced or consumed, or some other criteria is satisfied. The operational data may include generation measurements and load measurements. A real-time REC, whether recorded in a blockchain or in a conventional database, may contain:

[0040] Asset ID

[0041] Unique serial ID of real-time REC record

[0042] Start Time

[0043] End Time

[0044] Duration

[0045] Unit

[0046] Amount

[0047] Location

[0048] Value

[0049] Other Attributes

Once data is gathered via the metering/measurement technology, a record can be created using the above data points. Such records can then be used to match in real time to a load customer's usage records. The recording/accounting process can be implemented with relational databases or distributed ledgers.

[0050] The monitoring devices may interface with or be embedded in revenue-grade meters, smart meters, current transformers, inverters, smart Internet of Things (IoT) devices, and other devices. The production and consumption monitoring devices may be secure devices that execute software in a secure enclave such as the Software Guard eXtension (SGX) of Intel Corporation. The secure enclave (i.e., using a hardware private key) may attest to the software that is executing, and the executing software may use its private key for signing transactions recorded in the blockchain. Because the real-time REC system creates real-time RECs at a higher frequency than conventional RECs, real-time RECs provide a more granular accounting of energy production and consumption, which enables better matching of production to consumption.

[0051] FIG. 7 is a flow diagram that illustrates the processing of a component that matches real-time RECs to real-time ELs in some embodiments. The component 700 accesses production messages and generates real-time RECs and matches them to real-time ELs. The component may be invoked periodically, such as once a day. In block 701, the component accesses the next production message generated by a supplier of electricity. In decision block 702, if all the production messages have already been selected, then the component continues at block 704, else the component continues at block 703. In block 703, the component generates a real-time REC corresponding to the accessed production message and continues to block 701. In block 704, the component selects the next real-time EL. In decision block 705, if all the real-time ELs have already been selected, then the component completes, else the component continues at block 706. In block 706, the component matches the selected real-time EL with a real-time REC. The determination as to whether a real-time EL matches a real-time REC may be based on matching criteria associated with the real-time EL. The matching criteria may be stored as metadata (e.g., as a transaction in a blockchain) for the real-time EL. The matching criteria may be based on certain variables such as type of renewable, time of day, location, and so on. The matching criteria may also specify a weight for the variables, such as a weight indicating a strong preference for solar power and a weight indicating generated in a wide geographic area surrounding the location. In block 707, the component allocates the matched real-time REC to the consumer of the real-time EL and loops to block 704 to select the next real-time EL.

[0052] FIG. 8 is a block diagram that illustrates components of the real-time REC system in some embodiments. The real-time REC system includes production monitoring devices 801 of suppliers and consumption monitoring devices 802 of consumers. Each consumer may record a receive bid request component 803 of a smart contract in the blockchain. The real-time REC smart contract 810 may include a receive production message component 811, a receive consumption message component 812, a matching component 813, and a receive bid response component 814. The various devices and components may communicate via a communications channel 820.

[0053] The computing systems (e.g., network nodes or collections of network nodes) on which the real-time REC system may be implemented may include a central processing unit, input devices, output devices (e.g., display devices and speakers), storage devices (e.g., memory and disk drives), network interfaces, graphics processing units, cellular radio link interfaces, global positioning system devices, and so on. The input devices may include keyboards, pointing devices, touch screens, gesture recognition devices (e.g., for air gestures), head and eye tracking devices, microphones for voice recognition, and so on. The computing systems may include desktop computers, laptops, tablets, e-readers, personal digital assistants, smartphones, gaming devices, servers, and so on. The computing systems may access computer-readable media that include computer-readable storage media and data transmission media. The computer-readable storage media are tangible storage means that do not include a transitory, propagating signal. Examples of computer-readable storage media include memory such as primary memory, cache memory, and secondary memory (e.g., DVD) and other storage. The computer-readable storage media may have recorded on them or may be encoded with computer-executable instructions or logic that implements the real-time REC system. The data transmission media are used for transmitting data via transitory, propagating signals or carrier waves (e.g., electromagnetism) via a wired or wireless connection. The computing systems may include a secure cryptoprocessor as part of a central processing unit for generating and securely storing keys and for encrypting and decrypting data using the keys.

[0054] The real-time REC system may be described in the general context of computer-executable instructions, such as program modules and components, executed by one or more computers, processors, or other devices. Generally, program modules or components include routines, programs, objects, data structures, and so on that perform tasks or implement data types of the real-time REC system. Typically, the functionality of the program modules may be combined or distributed as desired in various examples. Aspects of the real-time REC system may be implemented in hardware using, for example, an application-specific integrated circuit (ASIC) or field programmable gate array (FPGA).

[0055] FIG. 9 is a flow diagram that illustrates the processing of a receive production message component of a real-time REC smart contract in some embodiments. The receive production message component 900 receives a production message from a supplier of renewable energy that includes attributes of the production. In decision block 901, if the signature on the production message is valid, that is, signed by the private key of the supplier, then the component continues at block 902, else the component completes. In block 902, the component invokes a create real-time REC component, passing an indication of the production message and receiving a real-time REC in response. In block 903, the component creates a transaction that includes the real-time REC. In block 904, the component signs the created transaction with the private key of a certifying authority. In block 905, the component records the signed transaction in the blockchain and then completes.

[0056] FIG. 10 is a flow diagram that illustrates the processing of a create real-time REC component in some embodiments. The create real-time REC component 1000 is passed a production message and creates a real-time REC by setting its attributes based on the production message. In block 1001, the component sets the asset ID to that of the asset (e.g., wind farm) that generated the base amount of electricity indicated by the production message. In block 1002, the component sets the serial number to a uniquely generated serial number. In blocks 1003-1006, the component sets various attributes of the real-time REC. In block 1007, the component sets the type (e.g., solar) based on the asset. In block 1008, the component sets the location based on the location of the asset. The component then completes with an indication of the real-time REC. In some embodiments, the component may use different sets of attributes (e.g., more, less, or different attributes).

[0057] FIG. 11 is a flow diagram that illustrates the processing of a receive consumption message component of the real-time REC system in some embodiments. The receive consumption message component 1100 is provided a consumption message and generates and records a real-time EL. In decision block 1101, if the signature of the consumption message is valid, that is, signed by the consumer's private key, then the component continues at block 1102, else the component completes. In block 1102, the component invokes a create real-time EL component, passing the consumption message, to generate a real-time EL. In block 1103, the component creates a transaction that contains the real-time EL. In block 1104, the component signs the transaction. The transaction may need to be sent off-blockchain to be signed. In block 1105, the component records the signed transaction in the blockchain and then completes.

[0058] FIG. 12 is a flow diagram that illustrates the processing of a create real-time EL component of the real-time REC system in some embodiments. The create real-time EL component 1200 is provided a consumption message and generates a real-time EL. In block 1201, the component sets the asset ID. In blocks 1202-1206, the component sets other attributes of the real-time EL and then completes. In some embodiments, the component may use different sets of attributes (e.g., more, less, or different attributes).

[0059] FIG. 13 is a flow diagram that illustrates the processing of a matching component of the real-time REC system in some embodiments. The matching component 1300 is provided a reconciliation message indicating that it is time to match or reconcile real-time RECs to real-time ELs. In block 1301, the component selects the next time slot. In decision block 1302, if all the time slots have already been selected, then the component completes, else the component continues at block 1303. In block 1303, the component selects the next real-time REC. In decision block 1304, if all the real-time RECs have already been selected, then the component loops to block 1301 to select the next time slot, else the component continues at block 1305. In decision block 1305, if there are unmatched real-time ELs, then the component continues at block 1306, else the component loops to block 1303 to select the next real-time REC. In block 1306, the component selects the next real-time EL. In decision block 1307, if all the real-time ELs have already been selected, then the component continues at block 1310, else the component continues at block 1308. In block 1308, the component sends a bid request to the smart contract of the consumer of the real-time EL. In block 1309, the component receives a bid response from the smart contract and then loops to block 1306 to select the next real-time EL. In block 1310, the component records a transaction in the blockchain matching the selected real-time REC to the real-time EL with the highest bid. The component then loops to block 1303 to select the next real-time REC.

[0060] FIG. 14 is a flow diagram that illustrates the processing of a receive bid request component of a consumer smart contract in some embodiments. The receive bid request component 1400 is provided a bid request message that identifies a real-time REC and a real-time EL. In block 1401, the component selects the next matching rule of the consumer. In decision block 1402, if all the matching rules have already been selected, then the component continues at block 1406, else the component continues at block 1403. In block 1403, the component applies the condition of the selected rule to the real-time REC and the real-time EL. In decision block 1404, if the condition of the rule is satisfied, indicating that a bid can be placed to match the real-time REC to the real-time EL, then the component continues at block 1405, else the component loops to block 1401 to select the next rule. In block 1405, the component sets the bid to the maximum of the highest bid so far and the bid indicated by the rule and then loops to block 1401 to select the next rule. In block 1406, the component records a transaction indicating the bid in the blockchain and then sends a bid response message to the real-time REC smart contract and then completes.

[0061] The following paragraphs describe various embodiments of aspects of the real-time REC system. An implementation of the real-time REC system may employ any combination of the embodiments. The processing described below may be performed by a computing device with a processor that executes computer-executable instructions stored on a computer-readable storage medium that implements the real-time REC system.

[0062] In some embodiments, a method performed by a computing device matches real-time renewable energy credits with energy loads. Each real-time renewable energy credit is generated in real time and has one or more attributes. The method accesses production messages that each indicate production of renewable energy by a supplier. Each production message indicates time of production. For each production message, the method generates a real-time renewable energy credit with attributes indicating the supplier and time of the production. The method accesses real-time energy loads that each indicate consumption of energy by a consumer. Each real-time energy load is generated in real time and has attributes indicating the consumer and time of consumption. The method matches real-time renewable energy credits with real-time energy loads based on time of production and time of consumption. For each matched real-time renewable energy credit and real-time energy load, the method allocates that real-time renewable energy credit to the consumer of that real-time energy load. In some embodiments, the real-time renewable energy credits and the real-time energy loads are stored as transactions in a blockchain. In some embodiments, the matching and allocating are performed by a smart contract recorded in the blockchain. In some embodiments, the production messages are generated by devices of the suppliers. In some embodiments, the method further accesses consumption messages from consumers and generates a real-time energy load for each consumption message. In some embodiments, each real-time renewable energy credit includes an attribute indicating the location of production of renewable energy and each real-time energy load includes an attribute indicating the location of consumption of energy, and the matching is further based on location of production and location of consumption. In some embodiments, the matching is performed by conducting an auction in which consumers submit bids for matching their real-time energy loads to real-time renewable energy credits. In some embodiments, the matching is performed by applying an optimization technique that attempts to maximize the differences between prices at which suppliers are willing to sell real-time energy credits and prices that consumers are willing to pay for real-time energy credits. In some embodiments, the real-time renewable energy credits and the real-time energy loads are stored as records in a database that is not a distributed ledger.

[0063] In some embodiments, one or more computing systems for matching real-time renewable energy credits with energy loads are provided. The one or more computing systems comprise one or more computer-readable storage mediums for storing computer-executable instructions and one or more processors for executing the computer-executable instructions stored in the one or more computer-readable storage mediums. The instructions control the one or more computing systems to generate real-time renewable energy credits with attributes indicating the supplier and time of the production. The instructions control the one or more computing systems to match real-time renewable energy credits with real-time energy loads. Each real-time energy load has attributes indicating a consumer and time of consumption. The matching is based on time of production and time of consumption. For each matched real-time renewable energy credit and real-time energy load, the instructions control the one or more computing systems to allocate that real-time renewable energy credit to the consumer of that real-time energy load. In some embodiments, the real-time renewable energy credits and the real-time energy loads are stored as transactions in a blockchain. In some embodiments, the instructions for matching and allocating are instructions of a smart contract recorded in the blockchain. In some embodiments, the computer-executable instructions further control the one or more computing systems to receive production messages that are generated by devices of the suppliers, wherein a production message indicates the amount of production. Each real-time renewable energy credit has an amount of production. In some embodiments, the computer-executable instructions further control the one or more computing systems to receive consumption messages that are generated by devices of the consumers, wherein a consumption message indicates the amount of consumption. In some embodiments, the matching is further based on matching the amount of production with the amount of consumption. In some embodiments, the computer-executable instructions further control the one or more computing systems to access consumption messages from consumers and generate a real-time energy load for each consumption message. In some embodiments, each real-time renewable energy credit includes an attribute indicating the location of production of the renewable energy, each real-time energy load includes an attribute indicating the location of consumption of the energy, and the matching is further based on the location of production and the location of consumption. In some embodiments, the matching is performed by conducting an auction in which consumers submit bids for matching their real-time energy loads to real-time renewable energy credits. In some embodiments, the matching is performed by applying an optimization technique that attempts to maximize the differences between the prices at which suppliers are willing to sell real-time energy credits and the prices that consumers are willing to pay for real-time energy credits. In some embodiments, the real-time renewable energy credits and the real-time energy loads are stored as records in a database that is not a distributed ledger.

[0064] Although the subject matter has been described in language specific to structural features and/or acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. For example, when trusted code of a node encrypts transactions for storage in the portion of the real-time REC stored at the node, the trusted code may use a symmetric key (i.e., that functions as both the encryption key and decryption key) rather than a public/private keypair. Accordingly, the invention is not limited except as by the appended claims.