DETAILED ACTION
Status of the Claims
The following is a Final Office Action in response to amendments and remarks filed 08 October 2025.
Claims 1 and 20 have been amended.
Claim 6 has been cancelled.
Claims 1-5 and 7-20 are pending and have been examined.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 08 October 2025 have been fully considered but they are not persuasive.
Applicant argues that the references do not teach the amended aspects of “execute a local pre-validation of the REC claim request for the plurality of renewable energy production datasets acquired from the renewable energy metering and monitoring device using one or more defined checkpoints prior to verification of the REC claim request by the first third-party system associated with the renewable energy verifier entity” (similar to those in claim 6); however the Examiner respectfully disagrees for a plurality of reasons. Firstly, Applicant is arguing much more narrowly than actually claimed. The claimed “execute a local pre-validation... using one or more defined checkpoints prior to verification of the REC claim request” only requires a local pre-validation using one or more checkpoints prior to verification of the REC. To put another way, the pre-validation only need to occur prior to the REC validation, at some sort of check point “local” to the system, which under the broadest reasonable interpretation, is any validation occurring between the actual meter itself generating the data and the verification of the REC. Secondly, the “local pre-validation” is very broad such that any type of verify/processing/validation/standardizing of or with received data (such as formatting, identifying source of the energy data, time stamp etc.) that occurs locally (such as a local area network) will read upon the claim limitation. And lastly, Miller discusses this ability as previously cited. Miller discusses the ability to have an ingestion engine perform validation operations on the energy records “The transaction store service 200 is configured to receive an energy data record (representing a specific unit of energy) transmitted from the broker 190, identify the source of the energy data record (e.g., whether it originated from a specific energy generation facility 101A, a specific consumption facility 101B), and perform validation operations on the energy data record (Miller ¶36)” which occurs before any validation via blockchain as verifiable energy blocks. The entirety of Miller is able to be implemented as a cloud service (Miller ¶50) or as a local area network (Miller ¶82). As such, this argument is not persuasive, and the rejection not withdrawn.
In response to arguments in reference to any depending claims that have not been individually addressed, all rejections made towards these dependent claims are maintained due to a lack of reply by the Applicants in regards to distinctly and specifically pointing out the supposed errors in the Examiner's prior office action (37 CFR 1.111). The Examiner asserts that the Applicants only argue that the dependent claims should be allowable because the independent claims are unobvious and patentable over the prior art.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-5 and 7-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Miller et al. (US PG Pub. 2021/0141761) and further in view of Orsini (US PG Pub. 2018/0299852).
As per claims 1 and 20, Miller discloses system and method of immutable electronic processing of renewable energy production data for issuing Digital Renewable Energy Certificates (DIGIRECs) for electricity, the system comprising: a central cloud server configured to (system, server, Miller ¶80; on-demand clout computing service, ¶50):
periodically acquire a plurality of renewable energy production datasets from a renewable energy metering and monitoring device located at a renewable energy production source site (FIG. 3A depicts an exemplary energy layer providing data to an exemplary energy tracking and processing infrastructure system. Energy layer 60 includes multiple energy generating facilities 101A, energy consumption facilities 101B, energy storage facilities 101S, and energy transmission facilities 101T. Energy facilities generate energy, transmit (e.g., schedule and deliver) energy, consume energy, or some combination thereof, and may be collectively referred to as facilities 101. Exemplary generation facilities 101A depicted include, by way of example and not limitation, a hydroelectric generation facility, a wind generation facility (e.g., one or more wind turbines), a solar generation facility (e.g., one or more solar panels or heat engine (such as Stirling engine) units). Each generation facility 101A is provided with a corresponding energy generation meter 105A. Exemplary energy consumption facilities 101B depicted include, by way of example and not limitation, an office building, a factory or other industrial facility, a warehouse or other distribution or storage related facility. Each consumption facility 101B is provided with at least one corresponding energy consumption meter 105B, Miller ¶28; As applied herein, individual source energy data records/entries are placed into the tree in an order. The order in which entries are inserted into the Merkle trie may cause different tree structures, even for the same underlying collection of entries (which may function as an “audit trail” for security and verification). The transaction store service 200 (which may be a tree microservice) may record the order in which the entries are placed into the tree, as well as the associated energy record hash that changed the state of the tree resulting in a new Merkle root. In various embodiments, one or more Merkle tries are specifically configured and operably coupled to various engine(s) and service(s) to store hashes of energy data records (e.g., energy generation data record(s), also referred to as EGDRs). Such Merkle tries may, for example, not store information relating to state, including blockchain record states, but instead store at least a hash of the information itself, ¶38;);
assign a timestamp and a hash value to each renewable energy production dataset of the plurality of renewable energy production datasets (hash of specific energy records, Miller ¶37; The block service 220 executes aggregation operations to aggregate individual energy data records to generate a block according to a predetermined block type or block size. Accordingly, for example, the system may request data from device 105A for 12 PM on Oct. 31, 2019, and with the hashing functionality, create an hour block of energy, that is a hash of hashes (Merkle trie). Similarly, the system may receive a plurality of EGDRs from a generation metering device 105A, hash the individual records (each representing a quantity of energy generated over a duration in time) and store them on individual leaf nodes in the Merkle trie, and then aggregate the individual records and generate a corresponding energy block representing a predetermined quantum of energy (e.g., 1 MWh). Accordingly, easily transferrable and verifiable energy blocks may be generated corresponding to discrete energy quanta and validated by individual hashed energy data stored at least in a Merkle trie, Miller ¶40);
generate an electronically verifiable span data package from the plurality of renewable energy production datasets and process the electronically verifiable span data package to generate a renewable energy certificate (REC) claim request in a defined taxonomy compatible to be read by an application programming interface (API) of a first third-party system associated with a renewable energy verifier entity (FIGS. 4-5, methods for verifying energy generation, transmission, and consumption in an energy tracking and processing infrastructure system is described. Finally, the document discusses further embodiments, exemplary applications and aspects relating to verifiable energy generation, transmission, and consumption tracking, Miller ¶21; API engine, dashboard engine, ¶54-¶55);
execute a local pre-validation of the REC claim request for the plurality of renewable energy production datasets acquired from the renewable energy metering and monitoring device using one or more defined checkpoints prior to verification of the REC claim request by the first third-party system associated with the renewable energy verifier entity (The transaction store service 200 is configured to receive an energy data record (representing a specific unit of energy) transmitted from the broker 190, identify the source of the energy data record (e.g., whether it originated from a specific energy generation facility 101A, a specific consumption facility 101B), and perform validation operations on the energy data record, Miller ¶36; local area network, ¶82);
communicate the REC claim request to the first third-party system along with a portion of the electronically verifiable span data package as evidence (Accordingly, easily transferrable and verifiable energy blocks may be generated corresponding to discrete energy quanta and validated by individual hashed energy data stored at least in a Merkle trie, Miller ¶40; for registered facilities, ¶55) (Examiner interprets a registered facility/registrant as some sort of user device at a facility or source site that is registering/has registered for the service, requesting devices be registered and thus claims be submitted or requested);
acquire a identifier of a first REC associated with a REC issuing entity from the first third-party system when the REC claim request is successfully verified (consumption related token identifiers, Miller ¶58; FIG. 3C depicts an exemplary attribution engine of the exemplary processing and validation engine of FIG. 3B. Once oracle service 310 has processed a specific block of data it then generates an energy attribution credit 335. In the depicted example, the attribution credit 335 is the origin of five distinct digital assets: digital renewable energy data 355, digital RECs 360, digital CO2e assets or liabilities 365, digital CO2e allowances 375, and digital energy efficiency credits 370. Digital renewable energy data 355 may, for example, advantageously enable accelerated settlement of purchased energy via transfer of digital currency between parties. Digital RECs 360 are digital renewable energy data assets aggregated into bundles representing discrete predetermined energy quanta (e.g., 1 MWh). Digital RECs may, for example, advantageously be used directly by a user for internal purposes, or be used for third-party exchange, ¶46) and
generate an interactive digital renewable energy certificate (DIGIREC) asset based on predefined REC-taxonomy metadata and the acquired unique identifier, wherein the interactive DIGIREC asset is associated with an ownership to a registered entity of the renewable energy production source site (Accordingly, various embodiments may, for example, advantageously generate secure, immutable, verifiable digital energy data assets such as, by way of example and not limitation, blockchain tokens. Such tokens may, for example, advantageously provide negotiable instruments representing, by way of example and not limitation, physical energy quanta, carbon intensity, environmental impact, energy efficiency, other appropriate energy-related attributes, or some combination thereof. For example, digital asset token may be used to advantageously securely track and attribute sustainable energy generation and usage, for the beneficial purpose of powering and supporting various green energy-focused technological systems and processes (often referred to as “Green-Tech”), Miller ¶26; digital RECs generated, ¶46, ¶49).
Miller does not expressly disclose does not expressly disclose a unique identifier of a first REC associated with a REC issuing entity.
However, Orsini teaches a unique identifier of a first REC associated with a REC issuing entity (devices and users can be issued a unique identifier, Orsini ¶36; Distributed applications operate devices which are connected to the network in a secure, autonomous and auditable manner. The TAG elements which comprise the network are physically embedded in, or securely connected to, devices that comprise or connect to a utility grid. TAG elements locate, uniquely identify, control, monitor, secure, validate and transact, in a peer-to-peer fashion, any value that a device on a utility grid can generate, consume, curtail, store or transport across a utility grid, ¶21).
Both the Orsini and Miller references are analogous in that both are directed towards/concerned with monitoring and validating energy generation and consumption. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to use Orsini’s ability to utilize unique identifiers in Miller’s system to improve the system and method with reasonable expectation that this would result in a sustainable energy tracking system that is able to record and track energy generation, transmission, and consumption data.
The motivation being that secure and automated control of distributed energy and computation systems is critical to the growth and function of the global economy. Current SCADA, IEC 61850, IEEE 1547 and various IP-based smart grid control systems are vulnerable to cyber security attacks, physical attacks or malicious operators within the network. The proliferation of consumer-owned energy smart grid technologies, distributed energy resources and powerful computation systems present an opportunity for sharing-economy based, peer-to-peer control and payments for the production, curtailment, use or benefits of smart grid devices. The integration of these and other smart grid assets improve reliability, resiliency, flexibility, and efficiency of the electric delivery system and our economy (Orsini ¶3).
As per claim 2, Miller and Orsini disclose as shown above with respect to claim 1. Miller further discloses wherein the renewable energy metering and monitoring device at the renewable energy production source site is communicatively coupled to a corresponding data port of one or more inverters located at the renewable energy production source site (Similarly, various metering devices may, by way of example and not limitation, transmit when a predetermined quanta of energy is reached (e.g., 1 kilowatt-hour). The energy data transmitted to the Transport Protocols 140 and IOT/Meter Connect 160 may include device static data (e.g., device serial number, manufacturer, installer, installation date, permission to operate date, geo-location credentials (lat/long), device streaming data (power output), energy output, inverter output, etc.), or some combination thereof. In at least one example, a given metering device 105 may transmit meter power readings to the transport protocols 140 and IOT/Meter Connect 160, Miller ¶33).
As per claim 3, Miller and Orsini disclose as shown above with respect to claim 2. Miller further discloses wherein an amount of renewable energy produced by a list of renewable energy generation devices at the renewable energy production source site when converted to alternating current (AC) for electricity via the one or more inverters is read directly by the renewable energy metering and monitoring device in a secured device-to-device communication between the renewable energy metering and monitoring device and the one or more inverters (electrical receiving and distribution stations, substations, transformers, converters, and other components, Miller ¶30; Incoming energy generation, transmission, and consumption data, once processed by transport protocols 140 or IoT/Meter Connect 160, is then processed by ingest engine 175. Ingestion service(s) 180 is operably coupled to and configured to process data from transport protocols 140. IoT ingestions service(s) 185 is operably coupled to and configured to process data from IoT/Meter connect service(s) 160. At least some portion of ingestion engine 175 may be implemented as a function-as-a-service, utilizing serverless functions in cloud computing systems that executes extract-transform-load (ETL) operations to transform data from various data sources (e.g., various metering devices 105) into one or more predetermined data structures for use by processing and validation engine 65. The ingest engine 175 may also perform various data normalization operations to normalize the received energy data, by way of example and not limitation, into a standardized and easy-to-use format, ¶34; units of energy, ¶75).
As per claim 4, Miller and Orsini disclose as shown above with respect to claim 1. Miller further discloses wherein the generation of the REC claim request is triggered when the plurality of renewable energy production datasets periodically acquired from the renewable energy metering and monitoring device indicates that an individual inverter of one or more inverters has generated a defined amount of renewable energy equal to or greater than a threshold amount or a defined amount of time of renewable energy equal to or greater than a threshold amount (Digital CO2e assets or liabilities 365 may represent a predetermined site-specific measure of carbon benefit or burden. These digital CO2e assets/liabilities 365 may advantageously, by way of example and not limitation, enable internal attestations, such as with respect to carbon neutrality or intensity, and may serve as the starting point for energy consuming facilities for the creation of digital energy efficiency credits 370. Digital energy efficiency credits 370 may represent a calculated difference between the measured carbon intensity of a consumption site versus mandated thresholds (for example, carbon intensity in excess of mandated thresholds are liabilities, and intensity measures below mandated thresholds are assets). The digital energy efficiency credits 370 may, by way of example and not limitation, advantageously be used internally across a registrant's portfolio, and may be available for third-party exchange, Miller ¶47).
As per claim 5, Miller and Orsini disclose as shown above with respect to claim 4. Miller further discloses wherein the generation of the REC claim request is triggered when the plurality of renewable energy production datasets periodically acquired from the renewable energy metering and monitoring device indicates that the one or more inverters collectively at the renewable energy production source site has generated a defined amount of renewable energy equal to or greater than a threshold amount or a defined amount of time of renewable energy equal to or greater than a threshold amount (Digital CO2e assets or liabilities 365 may represent a predetermined site-specific measure of carbon benefit or burden. These digital CO2e assets/liabilities 365 may advantageously, by way of example and not limitation, enable internal attestations, such as with respect to carbon neutrality or intensity, and may serve as the starting point for energy consuming facilities for the creation of digital energy efficiency credits 370. Digital energy efficiency credits 370 may represent a calculated difference between the measured carbon intensity of a consumption site versus mandated thresholds (for example, carbon intensity in excess of mandated thresholds are liabilities, and intensity measures below mandated thresholds are assets). The digital energy efficiency credits 370 may, by way of example and not limitation, advantageously be used internally across a registrant's portfolio, and may be available for third-party exchange, Miller ¶47).
As per claim 6, Miller and Orsini disclose as shown above with respect to claim 1. Miller further discloses wherein the central cloud server is further configured to execute a local pre-validation of the REC claim request for the plurality of renewable energy production datasets acquired from the renewable energy metering and monitoring device using one or more defined checkpoints prior to verification of the REC claim request by the first third-party system associated with the renewable energy verifier entity (perform validation operations on the energy records, Miller ¶36).
As per claim 7, Miller and Orsini disclose as shown above with respect to claim 1. Miller further discloses wherein the central cloud server is further configured to embed ancillary information in an encrypted form in the interactive DIGIREC asset, and wherein the ancillary information comprises a production location, a production date and a timestamp indicative of where and when the interactive DIGIREC asset and related unit of renewable energy is produced (The digital energy data assets 352 may, by way of example and not limitation, be stored in blockchain wallets, such as wallets for digital renewable energy data 355, digital RECs 360, digital CO2e assets or liabilities 365, digital CO2e allowances 375, and digital energy efficiency credits 370. Each block in blockchain layer 340 may be a blockchain-verifiable record that may, for example, advantageously be used to securely track energy generation, transmission, and usage (e.g., of renewable/sustainable energy) for a wide variety of energy generation, transmission, and consumption sites and facilities, Miller ¶51; Predetermined transmission and consumption validation rules 530 are executed on the energy block representing validated digital renewable energy consumed by a facility. If the consumption and transmission data is validated 535 (e.g., that the renewable energy block is confirmed as transmitted to and consumed by a given facility), the digital renewable energy credit token is associated (or “enriched”) 540 with the associated transmission and consumption data. Otherwise, the process ends, ¶61).
As per claim 8, Miller and Orsini disclose as shown above with respect to claim 1. Miller further discloses wherein the central cloud server is further configured to: track a redeemed status of the interactive DIGIREC asset based on one or both of: a confirmation from an electronic renewable energy exchange platform that indicates a successful redemption or an expiry of a defined validity period, and tagging the interactive DIGIREC asset as no longer available at the central cloud server or the renewable energy exchange platform for further use after receiving the confirmation of the successful redemption or after the expiry of the defined validity period (Predetermined transmission and consumption validation rules 530 are executed on the energy block representing validated digital renewable energy consumed by a facility. If the consumption and transmission data is validated 535 (e.g., that the renewable energy block is confirmed as transmitted to and consumed by a given facility), the digital renewable energy credit token is associated (or “enriched”) 540 with the associated transmission and consumption data. Otherwise, the process ends, ¶61; with the use of smart contracts, ¶26) (Examiner notes the use of smart contracts as including defining validity periods/expiry status as terms and conditions of a contract).
As per claim 9, Miller and Orsini disclose as shown above with respect to claim 1. Miller further discloses wherein the electronically verifiable span data package comprises a first type of data item comprising REC claim information details, a claim date of the REC claim request, a checkpoint source, a data structure related to the defined taxonomy, a fuel type indicative of a type of renewable energy used, a production capacity of renewable energy production source site, an identifier of the renewable energy production source site, and account information associated with the renewable energy production source site assigned by the renewable energy verifier entity (energy generation data records EGDRs, Miller ¶38 and ¶56-¶57 With this discrete energy block of data consolidated and all necessary energy records compiled, the block service 220 then interfaces with metadata service broker 225 and metadata service(s) 230, as well as with oracle broker 305. The metadata service(s) 230 enriches the data in the block service 220 with various metadata (e.g., time and location-specific grid emission factor, weather data and various other environmental data). In addition, metadata service 230 interfaces with energy market link services 235. The metadata service 230 is dynamic. As the use of the technology becomes more prolific, the metadata service 230 may, for example, be expanded to incorporate metadata elements not yet requested, Miller ¶41).
As per claim 10, Miller and Orsini disclose as shown above with respect to claim 9. Miller further discloses wherein the electronically verifiable span data package further comprises a second type of data item comprising a plurality of device identities (IDs) and corresponding energy production data associated with each device ID over a specified period as source evidence (Generation data 12 is collected (e.g., by a smart meter) and transferred to an energy tracking and processing infrastructure (ETPI) 22. The ETPI 22 processes the generation data 12 to create an energy generation data record (EGDR), which is hashed 24. The hash 24 is stored in a leaf node on a Merkle trie 26. One or more leaf nodes of the Merkle trie 26 are aggregated to represent a predetermined quantum of energy (e.g., 1 megawatt-hour [MWh]). An energy block on a blockchain 30 is generated and at least one root of the Merkle trie (a hash of hashes) corresponding to the aggregated leaf nodes is recoded in the energy block, Miller ¶22; Each generation facility 101A is provided with a corresponding energy generation meter 105A. Exemplary energy consumption facilities 101B depicted include, by way of example and not limitation, an office building, a factory or other industrial facility, a warehouse or other distribution or storage related facility. Each consumption facility 101B is provided with at least one corresponding energy consumption meter 105B, ¶28; time intervals, ¶33).
As per claim 11, Miller and Orsini disclose as shown above with respect to claim 1. Miller further discloses wherein the central cloud server is further configured to generate an audit trail accessible remotely via an audit user interface (UI) to allow remote or on-site auditing by an authorized auditor to prove one or more renewable energy certificate (REC) claims, and wherein the audit trail is generated based on the plurality of renewable energy production datasets acquired periodically from the renewable energy metering and monitoring device located at the renewable energy production source site (audit trail, Miller ¶38; A smart contract may, for example, be created to allow simple interaction in which a user can query by time to get at least one Merkle root which can then be used to validate Merkle proofs and audit energy, ¶39).
As per claim 12, Miller and Orsini disclose as shown above with respect to claim 11. Miller further discloses wherein the audit trail is generated further based on local sensor data that influence production of renewable energy at each renewable energy production source site obtained from one or more renewable energy metering and monitoring devices at each renewable energy production source site (audit trail, Miller ¶38; A smart contract may, for example, be created to allow simple interaction in which a user can query by time to get at least one Merkle root which can then be used to validate Merkle proofs and audit energy, ¶39).
As per claim 13, Miller and Orsini disclose as shown above with respect to claim 1. Miller further discloses wherein the central cloud server is further configured to obtain a registration request for a list of renewable energy generation devices and one or more inverters at the renewable energy production source site from a user device via a front-end interface rendered at the user device and communicatively coupled to the central cloud server (registrant at a facility, Miller ¶52) (Examiner interprets a registrant as some sort of user device at a facility or source site that is registering for the service and requesting devices be registered).
As per claim 14, Miller and Orsini disclose as shown above with respect to claim 13. Miller further discloses wherein the central cloud server is further configured to form a renewable energy tracking database comprising, for each renewable energy production source site, the plurality of renewable energy production datasets indicative of an amount of renewable energy generated, a date and duration when the renewable energy is generated along with supplementary information comprising a location of the renewable energy production source site, a fuel type indicative of a type of renewable energy used, an evidence type, and device information of the list of renewable energy generation devices and the one or more inverters registered at the central cloud server for each renewable energy production source site (energy generation data records EGDRs, Miller ¶38 and ¶56-¶57 With this discrete energy block of data consolidated and all necessary energy records compiled, the block service 220 then interfaces with metadata service broker 225 and metadata service(s) 230, as well as with oracle broker 305. The metadata service(s) 230 enriches the data in the block service 220 with various metadata (e.g., time and location-specific grid emission factor, weather data and various other environmental data). In addition, metadata service 230 interfaces with energy market link services 235. The metadata service 230 is dynamic. As the use of the technology becomes more prolific, the metadata service 230 may, for example, be expanded to incorporate metadata elements not yet requested, Miller ¶41).
As per claim 15, Miller and Orsini disclose as shown above with respect to claim 14. Miller further discloses wherein the device information comprises two or more of: a unique device identifier of each registered device of the list of renewable energy generation devices and the one or more inverters, a unique identifier of the renewable energy metering and monitoring device, a Media Access Control (MAC) or Internet protocol (IP) address of one or more renewable energy metering and monitoring devices at the renewable energy production source site, a make and a model of each of the list of renewable energy generation devices, or a grid connection status of the renewable energy production source site (Similarly, various metering devices may, by way of example and not limitation, transmit when a predetermined quanta of energy is reached (e.g., 1 kilowatt-hour). The energy data transmitted to the Transport Protocols 140 and IOT/Meter Connect 160 may include device static data (e.g., device serial number, manufacturer, installer, installation date, permission to operate date, geo-location credentials (lat/long), device streaming data (power output), energy output, inverter output, etc.), or some combination thereof. In at least one example, a given metering device 105 may transmit meter power readings to the transport protocols 140 and IOT/Meter Connect 160, Miller ¶33).
As per claim 16, Miller and Orsini disclose as shown above with respect to claim 14. Miller further discloses wherein the renewable energy tracking database further comprises, for each renewable energy production source site, geographical information of the renewable energy production source site including one or more of: satellite-sensed solar irradiation measurements, weather forecast information, site-specific sensed weather condition information, wind speed information, air temperature information, atmospheric pressure information, air quality or pollution information, relative humidity (RH) information, site-specific rainfall information, precipitable water information, snow days information, Cooling Degree Days (CDDs) information; Heating Degree Days (HDDs) information, terrain information, or data from local weather stations associated with each renewable energy production source site, and wherein the central cloud server is further configured to predict an amount of energy loss for a given geographical location of the renewable energy production source site for a given time period and co-relate with the plurality of renewable energy production datasets (With this discrete energy block of data consolidated and all necessary energy records compiled, the block service 220 then interfaces with metadata service broker 225 and metadata service(s) 230, as well as with oracle broker 305. The metadata service(s) 230 enriches the data in the block service 220 with various metadata (e.g., time and location-specific grid emission factor, weather data and various other environmental data). In addition, metadata service 230 interfaces with energy market link services 235. The metadata service 230 is dynamic. As the use of the technology becomes more prolific, the metadata service 230 may, for example, be expanded to incorporate metadata elements not yet requested, Miller ¶41).
As per claim 17, Miller and Orsini disclose as shown above with respect to claim 1. Miller further discloses wherein the central cloud server is further configured to acquire, from one or more renewable energy metering and monitoring devices at the renewable energy production source site, sensor information indicative of on-the-ground ambient conditions that exist during renewable energy production at the renewable energy production source site influencing production of renewable energy at each renewable energy production source site (Incoming energy generation, transmission, and consumption data, once processed by transport protocols 140 or IoT/Meter Connect 160, is then processed by ingest engine 175. Ingestion service(s) 180 is operably coupled to and configured to process data from transport protocols 140. IoT ingestions service(s) 185 is operably coupled to and configured to process data from IoT/Meter connect service(s) 160. At least some portion of ingestion engine 175 may be implemented as a function-as-a-service, utilizing serverless functions in cloud computing systems that executes extract-transform-load (ETL) operations to transform data from various data sources (e.g., various metering devices 105) into one or more predetermined data structures for use by processing and validation engine 65. The ingest engine 175 may also perform various data normalization operations to normalize the received energy data, by way of example and not limitation, into a standardized and easy-to-use forma, Miller ¶34; wherein the IoT devices can include sensors, ¶84; In various embodiments, the rate of digital RECs 360 and digital energy efficiency credits 370 generated may often be dependent on the level of energy a given facility 101A/B is using, generating, or transmitting. For example, a small array of solar panels on top of an office building may take several days to produce a single REC 360, while a large wind farm on hundreds of acres of land may generate multiple RECs 360 in an hour timespan, ¶49; see also predetermined CO2e intensity determination rules 545 are executed on one or more consumed energy blocks containing verifiable data corresponding to a particular consumption facility. If the CO2e intensity standards are met 550, one or more digital energy efficiency credit tokens are generated 555. Otherwise, the process ends, ¶62).
As per claim 18, Miller and Orsini disclose as shown above with respect to claim 17. Miller further discloses wherein the central cloud server is further configured to determine an on-the ground performance for each renewable energy generation device of a list of renewable energy generation devices based on the sensor information indicative of the on-the-ground ambient conditions that exist during renewable energy production at the renewable energy production source site (efficiency, Miller ¶8; In various embodiments, the rate of digital RECs 360 and digital energy efficiency credits 370 generated may often be dependent on the level of energy a given facility 101A/B is using, generating, or transmitting. For example, a small array of solar panels on top of an office building may take several days to produce a single REC 360, while a large wind farm on hundreds of acres of land may generate multiple RECs 360 in an hour timespan, ¶49).
As per claim 19, Miller and Orsini disclose as shown above with respect to claim 1. Miller further discloses wherein the central cloud server is further configured to: calculate an amount of green and clean electricity achieved from a total amount of renewable energy verifiably produced over a defined period at the renewable energy production source site, based on a tracking of the plurality of renewable energy production datasets acquired from the renewable energy metering and monitoring device; and generate a verifiable green and clean electricity report based on the calculated amount of DIGIRECs produced, wherein the verifiable green and clean electricity report is accessible for independent third-party verification (In various embodiments, the rate of digital RECs 360 and digital energy efficiency credits 370 generated may often be dependent on the level of energy a given facility 101A/B is using, generating, or transmitting. For example, a small array of solar panels on top of an office building may take several days to produce a single REC 360, while a large wind farm on hundreds of acres of land may generate multiple RECs 360 in an hour timespan, Miller ¶49).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW B WHITAKER whose telephone number is (571)270-7563. The examiner can normally be reached on M-F, 8am-5pm, EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynda Jasmin can be reached on (571) 272-6782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANDREW B WHITAKER/Primary Examiner, Art Unit 3629