DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The office action is being examined in response to the application filed by the Applicant on February 6, 2024.
Claims 1-20 are pending and have been examined.
This action is made NON-FINAL.
The Examiner would like to note that this application is now being handled by examiner Ivonnemary Rivera González.
The Examiner also acknowledge DO/EO acceptance filed on January 21, 2025 for this PCT national stage application in accordance to 35 U.S.C. 371 Application and MPEP 1801 and 1893.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on February 6, 2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
The references cited in the PCT international search reports on the issue date of February 6, 2024 and as listed in the DO/EO acceptance file received in January 21, 2025 have been considered.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 - 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The analysis of this claimed invention recited in the claims begins in view of independent claim 1, the most representative claim of the independent claims set 1, 16 and 20, as follows:
At Step 1: Claims 1 - 15 falls under statutory category of a machine, while claims 16 - 19 are directed to a process and claim 20 is directed to an article of manufacture.
At Step 2A Prong 1: Claim 1 (representative of claims 16 and 20) recites an abstract idea in the following limitations:
…create and store in the non-transitory storage media in an internal data interchange format…incorporating: plural asset data sets (ADS), each including: a registered asset owner and/or its designated third party (RAO) identifier, a geographic location identifier, and carbon content specifications required to record physical characteristics and quantity of sequestered carbon; and also incorporating RAO access credentials for accessing…;
generate a new ADS…, in response to a user request to become an RAO, the user request communicated…communicating RAO access credentials to the user and now recognizing the user as an RAO;
…which for each ADS:
upon initial registration of a new ADS, defines initial baseline data needed to quantify the physical characteristics and quantity of sequestered carbon at the registered location;
communicates a request for the defined initial baseline data to and receives them from the RAO or its designated third parties…and conforms the received initial baseline data to its internal data interchange format;
periodically communicates with the RAO or its designated third parties…to receive and collect new data for an existing ADS, including any changes in any one or more of: quantity of sequestered carbon attributable to physical processes of additional sequestration from and/or release of either previously sequestered or new carbon sources into the environment, and/or transformation of physical properties, and/or transport into or away from the registered sequestration location and/or ownership thereof, conforms the newly received data to its internal data interchange format, and updates the ADS;
communicates with the RAO or its designated third parties…requesting new data to update the existing ADS to conform with modification of ADS specifications or requirements used in operation of the continuous monitoring engine, receives the new data from the RAO, conforms the newly received data to its internal data interchange format, and updates the ADS;
when required for the ADS, assigns one or more stock keeping units (SKU) to sub-units of the sequestered carbon to monitor material transformation and/or transport thereof in stream of commerce and communicates the SKU data to the RAO…;
generates carbon sequestration asset units (SCAUs), linked to each ADS, each SCAU including quantity, quality, characteristics, origination location and current location of sequestered carbon;
…to collect component input data in native format;
transforms data throughout the continuous monitoring process…that uses one or more structured transformation models (STMs) specified in object code representing both Gaussian and logical transforms;
stores STMs as self-referencing data objects that expose input-output metadata such that …can automatically load the relevant STMs for a given set of data for a combination of ADS and SCAU such that…will read the stored data objects and perform Gaussian and logical transforms at runtime;
specifies STMs that perform Gaussian and logical transformations on the input data to support physical property calculations, legal compliance tests, and accounting allocations;
transforms ADS component data to normalized elements for aggregation and analysis using…that specifies normalizations specific to data input source and data elements;
aggregates and analyzes plural ADS, SKU and SCAU data to derive any temporal changes in ownership, quantity and/or physical properties of sequestered carbon attributable to: additional sequestration from, and/or release of previously sequestered carbon, and/or introduction of new carbon sources into the environment, transformation of physical properties of the sequestered carbon, and/or transport of sequestered carbon into or away from the registered sequestration location using applied STMs…;
updates each ADS, SKU and SCAU data in a continuous feedback loop; and
create…in the non-transitory storage media…storing the SCAU data in codified data structures that are in compliance with governmental requirements for the generation of tradeable carbon credits…updating, in a continuous feedback loop…, the SCAU data, and the codified data structures for compliance with changes in the governmental requirements
Generally, and as disclosed in the specification in ¶0060, this claimed invention provides “carbon monitoring system architecture” that “facilitates registration and tracking of sequestered carbon with the asset transfer and accounting functions used in traditional commodities, so that the positive environmental byproduct of agricultural photosynthesis, and other atmospheric carbon-removal solutions, and their inherent carbon sequestration, can be quantified, measurably commoditized, and effectively applied as a direct environmental offset against CO2 emissions, while paying the agricultural producers who remove CO2” (i.e. facilitating a “sequestered carbon credit registration, validation, and commodity management system”; see ¶0010 from Applicant disclosure). However, the abstract idea(s) of a certain method of organizing human activity (See MPEP 2106.04(a)(2), subsection II) are/is recited in claim 1 in the form of “commercial or legal interactions”. Specifically because, the abstract idea is recited in the steps directed in part to “create and store” in “an internal data interchange format” that is related to “plural asset data sets (ADS)” that at least includes “a registered asset owner and/or its designated third party (RAO) identifier” to register these ownership data directed to carbon sequestration and other carbon content specifications per asset that are further monitored per “RAO or its designated third parties” requests received to consolidate the registry data as well “monitor material transformation and/or transport thereof in stream of commerce” based on “stock keeping units (SKU) to sub-units of the sequestered carbon” assigned and “analyze” each asset corresponding “ownership” changes while “storing” the related data (i.e. in “SCAU data in codified data structures”) that is “in compliance with governmental requirements for the generation of tradeable carbon credits”. Thus, these limitation steps at least encompass commercial and legal interactions related to agreements in the form of contracts; legal obligations and/or marketing or sales activities or behaviors (i.e. providing services for asset ownership transfers via carbon credit sales/trading that comply with carbon sequestration regulations and policies).
The steps of “generate a new ADS…in response to a user request to become an RAO…”, “upon initial registration of a new ADS, defines initial baseline data needed to quantify the physical characteristics and quantity of sequestered carbon at the registered location”, all the steps directed to “conforms” of the “received initial baseline data” or ”newly received data” to “its internal data interchange format” (i.e. complying data according to rules), “when required for the ADS, assigns one or more stock keeping units (SKU) to sub-units of the sequestered carbon to monitor material transformation and/or transport thereof in stream of commerce…”, “generates carbon sequestration asset units (SCAUs), linked to each ADS, each SCAU…”, “specifies STMs that perform Gaussian and logical transformations on the input data…”, the steps directed in part to “transforms” “data throughout the continuous monitoring process…” (i.e. for data in a specific format) and “ADS component data to normalized elements…” fall under the abstract idea of mental processes that can be practically be performed in the human mind or in pen and paper (See MPEP 2106.04(a)(2), subsection III). Because at least generating and registering new ADS based on user requests, define initial baseline data for the quantification of physical characteristics and sequestered carbon at a registered location, conform these two types of data with internal data interchange format for compliance, assign SKUs to sequestered carbon sub-units and generate SCAUs that are linked to each ADS and SCAU encompass observation, evaluation and judgement. Finally, the step for “specifying STMs” or structured transformation models for data input transformation is directed to evaluation and judgement. Because these steps can either be done with the help of physical aid such as pen and paper or can be performed by humans without or with the assistance (e.g. tool) a computer. Thus, the steps do not negate and further still reads in the mental nature of the limitation(s), when evaluating the CO2 sequestration units, baseline and ADS data, as well as the concept is merely claimed to be performed on a generic computer and is merely using a computer as a tool to perform the concept of checking if the obtained/registered data is in compliance “with governmental requirements for the generation of tradeable carbon credits”, as later claimed (see MPEP 2106.04(a)(2)(III)(B & C)).
As for the steps directed in part to “transforms” “data throughout the continuous monitoring process…” (i.e. for data in a specific format) and “ADS component data to normalized elements…” fall under the abstract idea of mathematical concepts (See MPEP 2106.04(a)(2), subsection I). Because these steps encompass mathematical concepts. Because although these steps are performed by a computer, “transforming” data for data formatting (see ¶0074 from Applicant’s disclosure) and ADS data normalization (see ¶0093 from Applicant’s disclosure) requires specific mathematical calculations (e.g. “STMs that perform Gaussian and logical transformations on the input data” as further claimed, when “specifying” the STMs) in order for the computer to use the models with a “model-based interpreter” to “perform Gaussian and logical transforms at runtime”, as later claimed (which invokes “apply it” or instructions to apply by the computer).
At Step 2A Prong 2: For independent claims 1, 16 and 20, The judicial exception(s) or abstract idea previously identified is not integrated into a practical application (see MPEP 2106.04 (d)). The claims recite the additional element(s) of a server including one or more processors, a registration database, a portal of the server, an application programming interface (API) or enterprise resource planning ERP software operating on a communication device of the user, a continuous monitoring engine, external data services, including both sensors and external computer accounting systems, a model- based interpreter and a digital ledger (from claims 1, 16 and 20); a first non-transitory, computer- readable storage medium and a second non-transitory storage media (from claim 20). These additional elements, individually and in combination, and while considering the claims as a whole, are merely used as a tool to perform the abstract idea (See MPEP 2106.05(f)). Specifically, these claim steps are recited as being performed by the computer. The computer that operates a “continuous monitoring engine” and uses “model- based interpreter” are recited at a high level of generality that is being used as a tool to perform the generic computer functions for to obtain user requests, generate new ADS and recognize user RAO, “transform” and normalize data related to CO2 sequestration in products and its activities to analyze the data in compliance to governmental requirements for the generation of tradeable carbon credits. Thus, these steps mentioned above are further describing and applying the abstract idea without placing any limits on how the technological components are being improved, while distinguishing in the claim language, the performing limitations from functions that generic computer components can perform.
As for the steps directed in part to “transforms” “data throughout the continuous monitoring process…” (i.e. for data in a specific format) and “ADS component data to normalized elements…” are also broadly recited and are performed to generally to apply the abstract idea without placing any limits on how the “transform” of the data for data formatting (see ¶0074 from Applicant’s disclosure) and ADS data normalization (see ¶0093 from Applicant’s disclosure) is performed distinctively from generic computer components and without the function being generally invoked as an “apply it” to a computer. Also, the Examiner notes that the specifications broadly describe (as cited above) the “transformation” of data for data formatting and normalization via the use of a “a model- based interpreter” which invokes “apply it” by the general computer to perform the functions using such “interpreter”.
Moreover, The step of “create a digital ledger” for “storing the SCAU data in codified data structures that are in compliance with governmental requirements for the generation of tradeable carbon credits” and “updating, in a continuous feedback loop in conjunction with the continuous monitoring engine, the SCAU data, and the codified data structures…”, is also “merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application” (MPEP 2106.05(h)). In this case, the creation of a ledger for storing and updating “codified data structures” related to CO2 sequestration in compliance with regulation requirements is broadly recited and lacks details on how this ledger creation is specifically and distinctively performed from general distributed ledgers at the time of filling and is simply limited to storing/updating data on a blockchain that attempts to limit the use of the abstract idea to computer environments and/or blockchain technology (see MPEP 2106.05(h) for examples (ix) and (x)). Therefore, this is indicative of the fact that the claim set has not integrated the abstract idea into a practical application and therefore, the claims are found to be directed to the abstract idea identified by the Examiner.
Finally, the steps of “create and store in the non-transitory storage media in an internal data interchange format …”, “generate a new ADS in the registration database, in response to a user request to become an RAO…communicating RAO access credentials to the user…”, “communicates a request for the defined initial baseline data to and receives them from the RAO or its designated third parties…”, “periodically communicates with the RAO or its designated third parties, via its user communication device, to receive and collect new data for an existing ADS, including any changes…”, “communicates with the RAO or its designated third parties, via its user communication device, requesting new data to update the existing ADS to conform with modification of ADS specifications or requirements used…receives the new data from the RAO…and updates the ADS”, “when required for the ADS… and communicates the SKU data to the RAO…”, “communicates with external data services…to collect component input data in native format”, “stores STMs as self-referencing data objects that expose input-output metadata…”, “aggregates and analyzes plural ADS, SKU and SCAU data…”, “updates each ADS, SKU and SCAU data…” and “…storing the SCAU data in codified data structures that are in compliance with governmental requirements for the generation of tradeable carbon credits…updating, in a continuous feedback loop…, the SCAU data, and the codified data structures…” in the representative claim is really nothing more than links to computer for implementing the use of ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general-purpose computer or computer components (refer to MPEP 2106.05 f (2)). Thus, in these limitation steps, the computer is used to perform an abstract idea, as discussed above in Step 2A, Prong One, such that it amounts to no more than mere instructions to apply the exception using a generic computer.
Therefore, this analysis is indicative of the fact that even when viewed in combination, the claims’ additional elements do not integrate the abstract idea or judicial exception into a practical application.
Step 2B: For independent claims 1, 16 and 20, these claims do not provide an inventive concept. The recited additional elements of the claim(s) are the following: a server including one or more processors, a registration database, a portal of the server, an application programming interface (API) or enterprise resource planning ERP software operating on a communication device of the user, a continuous monitoring engine, external data services, including both sensors and external computer accounting systems, a model- based interpreter and a digital ledger (from claims 1, 16 and 20); a first non-transitory, computer- readable storage medium and a second non-transitory storage media (from claim 20). including the steps of “transforms” data and ADS component data. These additional elements are not sufficient to amount significantly more than the judicial exception or abstract idea (see MPEP 2106.05). Because, as indicated in Step 2A Prong 2, these additional element(s) claimed are merely, instructions to “apply” the abstract ideas, which cannot provide an inventive concept. Thus, even when considered in combination, these additional elements represent mere instructions to implement an abstract idea or other exception on a computer, which do not provide an inventive concept at Step 2B.
For dependent claims 2-15 and 17-19, the same analysis is incorporated. Due to their dependency to the independent claims analyzed, these claims cover or fall under the same abstract idea(s) of a method of organizing human activity, mental processes and mathematical concepts. They describe additional limitations steps of:
Claims 2-15 and 17-19: further describes the abstract idea of the method for monitoring and generating asset data sets (ADS) concerning properties and characteristics of sequestered carbon, and archiving the same, wherein further updates ADS data and creates/revise SKUs associated to the ADS, tag each SCAU and related data with a compliance code, runs the object specific Gaussian and logical models for allocation of SCAU credits, calculation and allocation of direct or indirect carbon sequestration or emission and for logical assertion of compliance with a given authority, periodically reinitializes the baseline data definition, communicates new baseline data requests, receiving reporting data for updates, permitting credentialed users access to designated ADS, SKU and SCAU data and facilitating trading of sequestered carbon credits. Thus, being directed to the abstract idea group of “commercial interactions” related to agreements in the form of contracts; legal obligations and/or marketing or sales activities or behaviors as well as falling in the groups of mental processes and mathematical concepts when requiring evaluation of the CO2 related data of a product.
Step 2A Prong 2 and Step 2B: For dependent claims 4, 10 – 11 and 17, these claims recite the additional elements of: an accounting system (from claim 4); a user portal (from claim 10) and a carbon continuous settlement engine (from claims 11 and 17), also known as a “digital wallet” (see ¶0012 from Applicant disclosure). These additional elements recited are invoking computers merely used as a tool to perform or “apply” the abstract idea(s) to the existing process of to settle the SCAU and related data tagged and mapped, permit user access and facilitate trading of sequestered carbon credits associated with the SCAU data by modifying/updating data ownership or offset sequestered CO2 consumption. Thus, amounting to no more than mere instructions to “apply” the exception using a generic computer component (MPEP 2106.05(f) and (f)(2)). Accordingly, for the same reasons stated above, these additional element(s) claimed cannot provide an inventive concept at Step 2B.
Finally, the additional elements previously mentioned above, are nothing more than descriptive language about the elements that define the abstract idea, and these claims remain rejected under 101 as well.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Wollack (U.S. Pub No. 20220237628 A1) in view of Zimmerman (U.S. Pub No. 20040158478 A1).
Regarding claims 1, 16 and 20:
Wollack teaches:
a server including one or more processors coupled to one or more computer-readable, non-transitory storage media, the media including therein instructions to operate when executed by the one or more processors, to cause the server to: (In ¶0071; Fig. 6 (606, 614 and 650): teaches “the computing system 604 includes a processing unit 606” that “may communicate to and from memory 614 and may provide output information for the display 626 via the input/output device interface 612”.)
create and store in the non-transitory storage media in an internal data interchange format, a registration database incorporating: plural asset data sets (ADS), each including: a registered asset owner and/or its designated third party (RAO) identifier, a geographic location identifier, and carbon content specifications required to record physical characteristics and quantity of sequestered carbon; and also incorporating RAO access credentials for accessing the server; (In ¶0039 – 40; Fig. 1C (150, 150a - 150c, 162 and 164): teaches that “the fabricator 162 may be responsible for generating the unique product identifiers and may send the unique product identifiers to the blockchain 150, e.g., as part of the third packet 150 c” wherein the “Packet 150 c may include information such as the unique product identifiers (also referred to as blockchain numbers) applied to the products, the type of product, the number of units, the production date, the expected lifetime of the product, and the ship date. In some embodiments, the packet 150 c may additionally include mileage, fuel consumed, and/or other data associated with shipment and other movement of the product and its component parts up to the shipment of the product 168.” The “first, second, and third packets 150 a, 150 b, and 150 c may include and enable tracking of additional information” such as “water usage at each stage of production, energy usage at each stage of production, other environmental impacts at each stage of production, ownership history (e.g., of the raw, intermediate, or end materials), etc.” as well as inputs that include “facility address, electricity purchased, steam purchased, natural gas used, light fuel oil used, heavy fuel oil used, propane used, water withdrawn, water discharged, net water use, the amount of air emissions by type” (see ¶0042 and ¶0044). Refer to ¶0076 for an example wherein “A finished polymer data packet” in a “JSON file” format that contains its identifiers which further includes “manufacture_location” and “user921”. See ¶0079 wherein these data packets assembled and recorded by a “remote computing device based on production data recorded in an automated process via communication between the remote computing device and a plurality of physical sensors”.)
generate a new ADS in the registration database, in response to a user request to become an RAO, the user request communicated to a portal of the server, via an application programming interface (API) or enterprise resource planning ERP software operating on a communication device of the user, the server communicating RAO access credentials to the user and now recognizing the user as an RAO; (In ¶0062 – 63: teaches that “users may claim ownership of the carbon-credits by providing the product identifiers of goods they have purchased (e.g., as described in connection with FIG. 4A) and by providing suitable account or identification information such as a digital wallet identifier (or suitable information that identifies a third party beneficiary, such as a non-profit organization)”. “After a user claims ownership of the carbon-credits, ownership of the proper amount of carbon-credits may be transferred to the user, such as by adding a record of the carbon-credits in a digital wallet of the user and making a corresponding record in the blockchain and/or making a corresponding deduction from a digital wallet of a producer or fabricator (who may temporarily hold such carbon-credits in their digital wallets until claimed by users)”. Further, in ¶0063, the “user interface may enable a user to claim ownership of a given product having a product identifier provided by the user via the user interface, which may be used in connection with functionality that enables a finder of the product to have the product returned to the owner” (i.e. interpreted as the portal of the server via an API interface or ERP software from a user communication device; see ¶0064 also) wherein “data stored in association with the user's account or digital wallet may include the user's name and/or contact information” and “an account identifier of the owner may be stored in the blockchain in association with the given product identifier, where a separate database may securely store the contact information, name and/or other account information associated with the account identifier” for access. Thus, the separate database is directed to the registration database. Another example is the “blockchain nodes” that are different computing systems with “separate copies of a distributed ledger” corresponding to the access user/owner/parties (see ¶0052) wherein “requests may come via an API”.)
operate a continuous monitoring engine, created and stored in the non-transitory storage media, in communication with the registration database, which for each ADS: upon initial registration of a new ADS, defines initial baseline data needed to quantify the physical characteristics and quantity of sequestered carbon at the registered location; (In ¶0082: teaches after a “result of the production of a physical product”, a first data packet is assembled by the computer system based on “production data recorded in an automated process via communication between the remote computing device and a plurality of physical sensors or data inputs” and the packet further includes at least an “other quantifiable environmental or social improvement from the baseline created as a result of the production of the physical product” and stored in a “first ledger entry”, in accordance to initial baseline data example given in ¶0092 from Applicant’s disclosure.)
communicates a request for the defined initial baseline data to and receives them from the RAO or its designated third parties, via its user communication device, and conforms the received initial baseline data to its internal data interchange format; (In ¶0058 – 59; Figs. 1A – 1C and 4A – 4B: teaches that a “ user of at least one unit of product made from the materials, as described herein in connection with FIGS. 1A-1C, or another interested party, may be able to verify an amount of carbon-credits associated with the unit (or units)” wherein the verification of carbon credits per blockchain entry include “an amount of carbon credit associated with the produced carbon-sequestering raw materials as a function of some measurable quantity such as volume or weight (e.g., the blockchain entry may indicate that every 100 grams of raw material is associated with a specified amount of carbon credits, which may be based on average production values for greenhouse gas consumption and power consumption)” (see ¶0058). Refer to ¶0059 – 60 and “FIGS. 4A and 4B illustrate example techniques for providing unique product identifiers to a blockchain system and illustrate an example response that the blockchain system may provide, including an indication of a verified amount of carbon credit associated with the provided unique product identifiers”.)
periodically communicates with the RAO or its designated third parties, via its user communication device, to receive and collect new data for an existing ADS, including any changes in any one or more of: quantity of sequestered carbon attributable to physical processes of additional sequestration from and/or release of either previously sequestered or new carbon sources into the environment, and/or transformation of physical properties, and/or transport into or away from the registered sequestration location and/or ownership thereof, conforms the newly received data to its internal data interchange format, and updates the ADS; (In ¶0055; Fig. 306 (306): teaches that when having “multiple stages of intermediary goods, blocks 306 and 308 may be repeated for each stage of fabrication. In these and other embodiments, a final iteration of blocks 306 and 308 may be performed for the fabrication of final goods from the final intermediary product. In this manner, the final goods (and any intermediary goods) can be traced back to an associated entry stored in block 304, thus facilitating tracking of carbon sequestered in the final goods (and any intermediary goods).” Also, refer to ¶0052 and step 306 in Fig. 3 wherein such “second data packets” are received from a “blockchain node” or a “computing system” of a user/owner/party. Further, any of these blockchain nodes, “may be configured to respond to requests to retrieve information from the blockchain if sufficient information (such as authorization information, if required in the given embodiment) has been provided in association with the request, according to known methods in the field of blockchains and other distributed ledgers” (see ¶0052).)
generates carbon sequestration asset units (SCAUs), linked to each ADS, (In ¶0033: teaches that the “vendor 130 may send a materials packet such as second 150 b. Second packet 150 b may include any desired information including, but not limited to, the identity of the vendor (sometimes referred to as a fabricator), a unit count, an indication of the amount of polymer used, an indication of the amount of resins products, a production date, a ship date, a type of carbon-sequestering material or resin produced, and an amount of power consumed by the vendor during processing of the polymer”.)
each SCAU including quantity, quality, characteristics, origination location and current location of sequestered carbon; (In ¶0038 – 39: teaches that the “Fabricator 162 may, if desired, apply unique product identifiers to each product produced from the carbon-sequestering resins or, alternatively, may include unique product identifiers in materials (e.g., manuals, inserts, etc.) included with each product or the packaging applied to each product” that can be “unique code” embedded which serves to “identify (such as indirectly, by being capable of serving as a lookup key in a blockchain), for each unit of product, a respective amount of carbon-credits associated with that unit of product (e.g., where the amount is based on the amount of carbon-credits generated by the production of the batch of carbon-sequestering polymer forming the identified unit of product and also based on the percentage of that batch that is incorporated into a single unit of product)” wherein the “amount of carbon-credits associated” per unit of product is directed to the SCAU that is linked to each ADS or “first/second/third packets”, in accordance to the SCAU definition given in ¶0016 and ¶0072 from Applicant disclosure. Finally, the “fabricator” can generate and send these “unique product identifiers” or “blockchain numbers 164” within the packets and all the linked information to the blockchain. Refer to ¶0077 – 78 for examples.)
communicates with the RAO or its designated third parties, via its user communication device, requesting new data to update the existing ADS to conform with modification of ADS specifications or requirements used in operation of the continuous monitoring engine, receives the new data from the RAO, conforms the newly received data to its internal data interchange format, and updates the ADS; (In ¶0043 – 44: teaches that “data from the blockchain 150 (such as data associated with the first, second, and third packets 150 a, 150 b, and 150 c) for a particular product may be provided to a life-cycle analysis system 170, which may be operated by or associated with a life-cycle analysis service or auditor” wherein “the blockchain 150 may store sufficient data in some embodiments that a life-cycle analysis auditing service may complete a life-cycle analysis for the product based on the verified data within the blockchain. The result of the life-cycle analysis 174 as generated by the life-cycle analysis system 170 may also be placed in the blockchain 150 and associated with the corresponding unique product identifier, such as including a certificate or other verified information reflecting the results of the lifecycle analysis”. See ¶0061 also. Refer to ¶0077 wherein a “finished materials data packet may be sent after material has been made and shipped to fabricator. The trigger for sending may be that a material team or entity has shipped new material to a fabricator”.)
when required for the ADS, assigns one or more stock keeping units (SKU) to sub-units of the sequestered carbon to monitor material transformation and/or transport thereof in stream of commerce and communicates the SKU data to the RAO, via its user communication device; (In ¶0040 – 42: teaches this conditional limitation as “At some point in the fabrication process, fabricator 162 may send a packet such as third packet 150 c to the blockchain 150 (e.g., via an API or other method that results in one or more blockchain nodes writing to the node's copy of a distributed ledger)”. Wherein the “Packet 150 c may include information such as the unique product identifiers (also referred to as blockchain numbers) applied to the products” along with “the number of units” of the product and additional information such as “other data associated with shipment and other movement of the product and its component parts up to the shipment of the product 168” which is directed to assigning SKUs to new products produced from “raw carbon-sequestering materials”, in accordance to the example of assigning SKUs to a new lumber pallet in ¶0015 from Applicant disclosure.)
communicates with external data services, including both sensors and external computer accounting systems, associated with specific ADS in the registration database, to collect component input data in native format; (In ¶0082; Fig. 6 (608, 604, 602 and 640): teaches an example wherein “the first data packet is assembled by the remote computing device based on production data recorded in an automated process via communication between the remote computing device and a plurality of physical sensors or data inputs”. Also, in ¶0073, “the network interface 608 may provide connectivity to one or more networks or computing systems, and the processing unit 606 may receive information and instructions from other computing systems or services via one or more networks”.)
aggregates and analyzes plural ADS, SKU and SCAU data to derive any temporal changes in ownership, quantity and/or physical properties of sequestered carbon attributable to: additional sequestration from, and/or release of previously sequestered carbon, and/or introduction of new carbon sources into the environment, transformation of physical properties of the sequestered carbon, and/or transport of sequestered carbon into or away from the registered sequestration location using applied STMs in the model-based interpreter; updates each ADS, SKU and SCAU data in a continuous feedback loop; and (In ¶0055; Fig. 306 (306): teaches the aggregation and analysis of data for temporal changes as in the example when having “multiple stages of intermediary goods, blocks 306 and 308 may be repeated for each stage of fabrication. In these and other embodiments, a final iteration of blocks 306 and 308 may be performed for the fabrication of final goods from the final intermediary product. In this manner, the final goods (and any intermediary goods) can be traced back to an associated entry stored in block 304, thus facilitating tracking of carbon sequestered in the final goods (and any intermediary goods).” Also, refer to ¶0052 and step 308 in Fig. 3 wherein “one or more of the blockchain nodes may store, in their copy of the blockchain ledger, at least one entry that identifies a per-unit amount of carbon credit associated with each of the produced goods. In at least some embodiments, the per-unit amount of carbon credit is determined based on what fraction of the raw materials are incorporated into each unit of goods and based on other relevant factors such as the amount of greenhouse gases produced during production of the goods. Additionally, the entry stored in block 308 may include one or more unique product identifiers and may be tied to the entry stored in block 304”. Further, any of these blockchain nodes, “may be configured to respond to requests to retrieve information from the blockchain if sufficient information (such as authorization information, if required in the given embodiment) has been provided in association with the request, according to known methods in the field of blockchains and other distributed ledgers” (see ¶0052).)
create a digital ledger, in the non-transitory storage media, which is in communication with the continuous monitoring engine, the digital ledger storing the SCAU data in codified data structures that are in compliance with governmental requirements for the generation of tradeable carbon credits, (In ¶0051; Figs. 1A – 1C (150); Fig. 2 (212); Fig. 3 (304): teaches “At block 212, information associated with the production of the products (produced in step 210) is recorded via at least one entry into the blockchain ledger”. See ¶0022 wherein “monitoring the production process and recording information related to carbon-credits and production of the materials” occur “in a blockchain 150 in an automated manner.”)
the digital ledger updating, in a continuous feedback loop in conjunction with the continuous monitoring engine, the SCAU data, and the codified data structures for compliance with changes in the governmental requirements (In ¶0055; Fig. 306 (306): teaches the digital ledger updates in a continuous feedback loop with the system or “blockchain nodes” (see ¶0052 also), as in the example when having “multiple stages of intermediary goods, blocks 306 and 308 may be repeated for each stage of fabrication. In these and other embodiments, a final iteration of blocks 306 and 308 may be performed for the fabrication of final goods from the final intermediary product. In this manner, the final goods (and any intermediary goods) can be traced back to an associated entry stored in block 304, thus facilitating tracking of carbon sequestered in the final goods (and any intermediary goods).”)
Wollack teaches that the data from the “data packets” related to the polymer product and its materials are formatted in “JavaScript Object Notation (JSON) or similar format” by using “an HTTP POST method” when sending these packets over the network (see ¶0075; Wollack). However, Wollack does not explicitly teach the abilities of transforming data using a specific model- based interpreter that uses structured transformation models (STMs) specified in object code representing both Gaussian and logical transforms to store the STMs as self-referencing data objects for automatic loading and reading of stored data, specifies the STM that performs the Gaussian and logical transformations and transforms ADS component data to normalized elements. However, Zimmerman teaches:
transforms data throughout the continuous monitoring process using a model- based interpreter that uses one or more structured transformation models (STMs) specified in object code representing both Gaussian and logical transforms; (In ¶0029; Fig. 1 (50): teaches obtaining “General data 12, preferably with at least some site-specific data 14, are used to determine the approximate change in the level of carbon storage in a media over a specified time period 40 through the application of a carbon sequestration model” wherein “the standardized CERCs” or “standardized carbon emission reduction credits” (see ¶0017) and “reserve CERCs are determined 50 through the application of an uncertainty analysis”. This “uncertainty analysis” is run by the system as conducting a “number of simulations” by employing “a Monte Carlo uncertainty analysis” (although “a variety of other methods may be used”) that include “input variables that affect the result are randomly assigned values that follow a particular distribution, such as Gaussian, although other distributions may be used, if more appropriate” which results in an “actual distribution U of values arising from the uncertainty in the key variables” being determined (see ¶0055 – 56). Further, an example for quantifying “the number of standardized CERCs for a land parcel” as an asset is provided wherein “if C is chosen to equal 0.95, then for a normal two-tailed Gaussian distribution, f(0.95)=2S and the standardized CERCs would be equal to X−2S, and the reserve CERCs would be equal to 2S. In that example, one may characterize the standardized CERC in terms of being 95% confident that one metric ton of carbon is or will be actually stored in the soil.” Examiner notes that the use of an interpreted with different STMs which are models that are logical transformations by nature (i.e. gaussian transform) is directed to utilizing a model with integrated algorithms or equations, based on the interpreter examples given in ¶0031, ¶0045 and ¶0074 from Applicant disclosure.)
stores STMs as self-referencing data objects that expose input-output metadata such that the model-based interpreter can automatically load the relevant STMs for a given set of data for a combination of ADS and SCAU such that the interpreter will read the stored data objects and perform Gaussian and logical transforms at runtime; (In ¶0057; Fig. 5 (140): teaches that the “analysis may be immediately set up using standard Gaussian input distributions”, by the system, as well as the “preferred function to calculate P=f(C)” can be chosen by the user when generating the number of simulations (see ¶0059). See ¶0052 wherein the “invention recognizes that the use of an uncertainty analysis can allow the use of general data for input variables into carbon sequestration models to determine the approximate change in the level of carbon compounds in soil over specified time periods”. Refer to ¶0106 wherein a “customized data base, such as a general database” can be included to “to define important controlling variables, a producer-accessible interface for project-specific data, linkages to data processors adapted to run numerical models and data processors adapted to run uncertainty analyses.”)
specifies STMs that perform Gaussian and logical transformations on the input data to support physical property calculations, legal compliance tests, and accounting allocations; transforms ADS component data to normalized elements for aggregation and analysis using a model-based interpreter that specifies normalizations specific to data input source and data elements; (In ¶0081 – 82: teaches the specification of STM on the input data and transforms the ADS component data to normalized elements when the “system can take the information inputted from the landowner, identify and obtain relevant information from the database, submit the landowner and database information into a carbon sequestration modeling program” (that uses the “Monte Carlo uncertainty analysis” model; see ¶0080), “submit the results to an uncertainty analysis program, calculate accrued and projected standardized CERCs available for trade, as well as accrued and projected reserve CERCs, and generate a report for the landowner.” Further, in ¶0085 as another example that further explains the program used by the system: “when the landowner submits a request to quantify the standardized CERCs, the database transfers the landowner's input data in a specific format to a specific directory on the computer running the carbon sequestration model. A daemon in that computer watches for information to appear and, when finding data in the input directory, initiates a master script program. The master script program calls a geographic information system routine to process the site location of the land parcel and obtain stored values in the database for general data, such as soil texture, climate and general land use history. These obtained values are placed in a data directory and control is returned to the master script. The master script then calls a set of Perl scripts which parse the appropriately formatted input files required by the carbon sequestration model. The master script calls the carbon sequestration model to perform its program and then the uncertainty analysis program to perform its program. The results are placed into a special output directory in specifically formatted files and the master script deletes the input files to prevent the initiation of another run. A different daemon watches for output files to appear and, when such output files are found, it calls a script to parse and interpret the results and a final report file containing the standardized CERCs and uncertainty is produced.” Refer to ¶0090 also for system’s “data processor” details.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Wollack to provide the abilities of transforming data using a specific model- based interpreter that uses structured transformation models (STMs) specified in object code representing both Gaussian and logical transforms to store the STMs as self-referencing data objects for automatic loading and reading of stored data, specifies the STM that performs the Gaussian and logical transformations and transforms ADS component data to normalized elements, as taught by Zimmerman in order to “determine the approximate change in the level of carbon compounds in soil over specified time periods” which is “advantageous for data for years dating back into time, such as prior to 1990 and back as far as 1900 or earlier, for which site-specific data may be difficult or impossible to document.”(¶0052; Zimmerman). Further, such data standardization by using these specific STMs models, “allow individual landowners, or groups of landowners, to input requested information and receive reports quantifying accrued and projected standardized CERCs, as well as CERCs to be held in reserve.” (¶0086; Zimmerman), see also MPEP 2143.I.G.
Regarding claim 2:
The combination of Wollack and Zimmerman, as shown in the rejection above, discloses the limitations of claim 1.
Wollack further teaches:
further comprising the continuous monitoring engine updating the carbon content specifications of an ADS of a geographic location to: add additional carbon sequestered at or transported into the location, subtract previously sequestered carbon transported to other locations or released into the environment, and subtract additional carbon released into the atmosphere at the location. (In ¶0040: teaches under the broadest reasonable interpretation (BRI), the updates of carbon content specifications of an ADS of a geographic location with addition of carbon sequestered at a location and subtraction of additional carbon released at the location, as when “At some point in the fabrication process, fabricator 162 may send a packet such as third packet 150 c to the blockchain 150 (e.g., via an API or other method that results in one or more blockchain nodes writing to the node's copy of a distributed ledger)” wherein the packet can include additional data “associated with shipment and other movement of the product and its component parts up to the shipment of the product 168” that can be automated by the fabricator’s “sensors”. See ¶0042 for additional information stored related to environmental impacts of the sequestered carbon data and ¶0061 for retrieving “life-cycle analysis results” that includes “various steps in the life of the product to this point may be shown, as retrieved from the blockchain”.)
Regarding claim 3:
The combination of Wollack and Zimmerman, as shown in the rejection above, discloses the limitations of claim 2.
Wollack further teaches:
further comprising the continuous monitoring engine updating the carbon content specifications of an ADS attributable to physical transformation of the sequestered carbon into other compositions of matter or other physical forms and creating or revising SKUs associated with the updated ADS. (In ¶0055; Fig. 3 (306 – 308): teaches “In embodiments with multiple stages of intermediary goods, blocks 306 and 308 may be repeated for each stage of fabrication. In these and other embodiments, a final iteration of blocks 306 and 308” for receiving a “second data packet” related to goods fabrication from raw materials and storing entries of a “per-unit carbon credit associated to each of the goods”, may be “performed for the fabrication of final goods from the final intermediary product. In this manner, the final goods (and any intermediary goods) can be traced back to an associated entry stored in block 304, thus facilitating tracking of carbon sequestered in the final goods (and any intermediary goods).” See ¶0058 also for another example.)
Regarding claim 4:
The combination of Wollack and Zimmerman, as shown in the rejection above, discloses the limitations of claim 3.
Wollack further teaches:
further comprising the continuous monitoring engine tagging an SCAU, its related data set, and its related ADS with a mapping to a downstream good represented as a SKU in an accounting system such that tradeable carbon credits can be settled as the good changes hands. (In ¶0049 ¶0062: teaches under BRI, as in an example wherein “after a user claims ownership of the carbon-credits, ownership of the proper amount of carbon-credits may be transferred to the user, such as by adding a record of the carbon-credits in a digital wallet of the user” (i.e. directed to tagging the SCAU and its related asset data with a downstream mapping) and “making a corresponding record in the blockchain and/or making a corresponding deduction from a digital wallet of a producer or fabricator (who may temporarily hold such carbon-credits in their digital wallets until claimed by users)”. See ¶0051 wherein the “block 212, information associated with the production of the products (produced in step 210) is recorded via at least one entry into the blockchain ledger. As examples, the blockchain entries recorded at block 212 may include any unique product identifiers, the type of product, the number of units of product produced, the production date, the ship date, etc. The blockchain entries may also be tied to (or otherwise associated with) the blockchain entries recorded at blocks 204 and 208. In particular, the blockchain entries may be tied together such that an entity may be able to use the unique product identifier for a given unit of product to identify the blockchain entry for that unit (or for the batch of units including that unit) and identify the corresponding entry (or entries) for the intermediate resin and the original polymer. In some embodiments, the carbon-credits associated with production of the polymer may be tracked and split (or even combined) such that amount of carbon-credit associated with a single unit can be determined” which is directed to the mapping of SCAUs as an accounting system’s SKU.)
Regarding claim 5:
The combination of Wollack and Zimmerman, as shown in the rejection above, discloses the limitations of claim 4.
Wollack does not explicitly teach the ability of having the continuous monitoring engine executing runtime-interpreted, object specific Gaussian and logical models. However, Zimmerman further teaches:
further comprising the continuous monitoring engine executing runtime-interpreted, object specific Gaussian and logical models for allocation of SCAU credits to different derived, downstream SKUs in the supply chain. (In ¶0029; Fig. 1 (50); Fig. 5 (140): teaches that the system applies “a carbon sequestration model” wherein “the standardized CERCs” or “standardized carbon emission reduction credits” (see ¶0017) and “reserve CERCs are determined 50 through the application of an uncertainty analysis”. This “uncertainty analysis” is run by the system as conducting a “number of simulations” by employing “a Monte Carlo uncertainty analysis” (although “a variety of other methods may be used”) that include “input variables that affect the result are randomly assigned values that follow a particular distribution, such as Gaussian” (i.e. interpreted as specific Gaussian and logical models) which results in an “actual distribution U of values arising from the uncertainty in the key variables” being determined to “quantify the number of standardized CERCs for a land parcel” (see ¶0055 – 56). See ¶0064 wherein an example is provided wherein the “uncertainty analysis” calculations can be used to take the resulting “up to 95 standardized CERCs” which “could be certified for trade”, for example. The Examiner notes that the purpose claimed for allocating SCAU credits to SKUs, to run the object specific Gaussian and logical models in the system is non-functional descriptive matter.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Wollack to provide the ability of having the continuous monitoring engine executing runtime-interpreted, object specific Gaussian and logical models, as taught by Zimmerman in order to “determine the approximate change in the level of carbon compounds in soil over specified time periods” which is “advantageous for data for years dating back into time, such as prior to 1990 and back as far as 1900 or earlier, for which site-specific data may be difficult or impossible to document.”(¶0052; Zimmerman). Further, such data standardization by using these specific STMs models, “allow individual landowners, or groups of landowners, to input requested information and receive reports quantifying accrued and projected standardized CERCs, as well as CERCs to be held in reserve.” (¶0086; Zimmerman), see also MPEP 2143.I.G.
Regarding claim 6:
The combination of Wollack and Zimmerman, as shown in the rejection above, discloses the limitations of claim 1.
Wollack teaches that the system receives a “first data package” which includes “other quantifiable environmental or social improvement from the baseline created as a result of the production of the physical product” as baseline data, and in “the first ledger entry identifies a quantifiable environmental or social improvement from the baseline associated with the physical product” (see ¶0082 and ¶0058; Wollack) However, Wollack does not explicitly teach the ability of specifically periodically reinitialize the baseline data definition for an existing ADS through a request for a new baseline data to update the ADS and its related information. However, Zimmerman further teaches:
further comprising: the continuous monitoring engine periodically reinitializes the baseline data definition for an existing ADS, communicates a request to the RAO for new baseline data, updates the ADS with the new baseline data, and updates each SKU and SCAU associated with the updated ADS. (In ¶0096 – 97: teaches an example wherein “potential CERC producer accesses a website that includes background and reference material, as well as an interactive interface capable of receiving and transmitting data”. In response to an “inquiry, the potential CERC producer identifies a parcel of land by geographic location” that is further utilized to “identify the specific land parcel and the total area of the land parcel” by obtaining “general data relevant to carbon sequestration in soil for that land parcel from a database containing geographically referenced general data relevant to carbon sequestration in soil, such as land use history, climate and soil texture. A baseline level of business as usual carbon emissions is also obtained, preferably from a database of such baseline levels referenced by geographic location and/or type of activity, such as farming”, in accordance to an example given in ¶00109 from Applicant disclosure. Refer to ¶0079 wherein “information from the landowner may be entered into the carbon sequestration modeling program in a variety of ways, preferably data input is automated”. Thus, the “system receives site-specific data from the landowner, determines or obtains the geographic location of the parcel of land, identifies the site-specific data, if any, and the general data relevant to that parcel of land stored in the database, identifies the business as usual scenario for the land parcel” (directed to periodically re-initializing the baseline data definition) and “submits the collected information to the carbon sequestration modeling program”. See more details about the baseline definition in ¶0018 – 19 wherein the “baseline generally refers to the level of greenhouse gas emissions from continuing current management practices in that particular industry. In the case of farmers, business as usual typically is defined as conventional tillage agriculture.”)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Wollack to provide the ability of specifically periodically reinitialize the baseline data definition for an existing ADS through a request for a new baseline data to update the ADS and its related information, as taught by Zimmerman in order to “further compare the data inputted by the landowner with the data from the database to identify potential errors or mis-entries, which preferably may be flagged for independent review”(¶0079; Zimmerman), see also MPEP 2143.I.G.
Regarding claim 7:
The combination of Wollack and Zimmerman, as shown in the rejection above, discloses the limitations of claim 1.
Wollack further teaches:
further comprising the continuous monitoring engine receives reporting data from a third party associated with an RAO's user credentials, concerning ongoing carbon consumption, emission, physical transformation, or transportation associated with an ADS, and updates the ADS and each SKU and SCAU associated therewith. (In ¶0043 – 44: teaches that “data from the blockchain 150 (such as data associated with the first, second, and third packets 150 a, 150 b, and 150 c) for a particular product may be provided to a life-cycle analysis system 170, which may be operated by or associated with a life-cycle analysis service or auditor” wherein “the blockchain 150 may store sufficient data in some embodiments that a life-cycle analysis auditing service may complete a life-cycle analysis for the product based on the verified data within the blockchain. The result of the life-cycle analysis 174 as generated by the life-cycle analysis system 170 may also be placed in the blockchain 150 and associated with the corresponding unique product identifier, such as including a certificate or other verified information reflecting the results of the lifecycle analysis”. See ¶0061 also.)
Regarding claim 8:
The combination of Wollack and Zimmerman, as shown in the rejection above, discloses the limitations of claim 7.
Wollack further teaches:
the reporting data comprising indirect carbon emission associated with consumption of one or more of electric power, fuel, or products associated with a carbon sequestration process occurring at the location associated with the ADS. (In ¶0040: teaches that “At some point in the fabrication process, fabricator 162 may send a packet such as third packet 150 c to the blockchain 150 (e.g., via an API or other method that results in one or more blockchain nodes writing to the node's copy of a distributed ledger” wherein the packet may further include “mileage, fuel consumed, and/or other data associated with shipment and other movement of the product and its component parts up to the shipment of the product 168”.)
Regarding claim 9:
The combination of Wollack and Zimmerman, as shown in the rejection above, discloses the limitations of claim 8.
Wollack does not explicitly teach the ability of having the continuous monitoring engine executing runtime-interpreted, object specific Gaussian and logical models. However, Zimmerman further teaches:
further comprising the continuous monitoring engine executing runtime-interpreted, object specific Gaussian and logical models for calculation and allocation of direct or indirect carbon sequestration or emission. (In ¶0029; Fig. 1 (50); Fig. 5 (140): teaches that the system applies “a carbon sequestration model” wherein “the standardized CERCs” or “standardized carbon emission reduction credits” (see ¶0017) and “reserve CERCs are determined 50 through the application of an uncertainty analysis”. This “uncertainty analysis” is run by the system as conducting a “number of simulations” by employing “a Monte Carlo uncertainty analysis” (although “a variety of other methods may be used”) that include “input variables that affect the result are randomly assigned values that follow a particular distribution, such as Gaussian” (i.e. interpreted as specific Gaussian and logical models) which results in an “actual distribution U of values arising from the uncertainty in the key variables” being determined to “quantify the number of standardized CERCs for a land parcel” (see ¶0055 – 56). See ¶0036 – 38 wherein an example is provided wherein “Several different carbon models are available to determine the available carbon reservoir, if any, within the soil and/or vegetation located on a particular land parcel. The type and level of detail of the required data are dependent on the carbon model employed, although typically such data may be characterized as general and site-specific”. Refer to ¶0081 wherein the “results of the analysis can be communicated to the landowner, preferably in a report and more preferably in a report directly through the interface. Preferably, the system can allow the landowner an opportunity to run the analysis multiple times for future scenarios, with the landowner or another selectively changing one or more of the variables, in order to determine the impact of the change on the generation of standardized CERCs”. The Examiner notes that the purpose claimed for calculation and allocation of direct or indirect carbon sequestration or emission, to run the object specific Gaussian and logical models in the system is non-functional descriptive matter.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Wollack to provide the ability of having the continuous monitoring engine executing runtime-interpreted, object specific Gaussian and logical models, as taught by Zimmerman in order to “determine the approximate change in the level of carbon compounds in soil over specified time periods” which is “advantageous for data for years dating back into time, such as prior to 1990 and back as far as 1900 or earlier, for which site-specific data may be difficult or impossible to document.”(¶0052; Zimmerman). Further, such data standardization by using these specific STMs models, “allow individual landowners, or groups of landowners, to input requested information and receive reports quantifying accrued and projected standardized CERCs, as well as CERCs to be held in reserve.” (¶0086; Zimmerman), see also MPEP 2143.I.G.
Regarding claim 10:
The combination of Wollack and Zimmerman, as shown in the rejection above, discloses the limitations of claim 1.
Wollack further teaches:
further comprising a user portal coupled to the registration database, and/or the continuous monitoring engine and/or the digital ledger selectively permitting credentialed users access to designated ADS, SKU and SCAU data. (In ¶0062 – 63; Fig. 2 (214); Fig. 4A and 4B: teaches that “users (e.g., owners of one or more goods produced as discussed herein) may have an account, digital wallet, or other mechanism that allows them to claim ownership of carbon-credits uniquely associated with the production of goods purchased by the users. The users may claim ownership of the carbon-credits by providing the product identifiers of goods they have purchased (e.g., as described in connection with FIG. 4A) and by providing suitable account or identification information such as a digital wallet identifier (or suitable information that identifies a third party beneficiary, such as a non-profit organization”. Refer to ¶0060 – 61 wherein “identifier may be entered into a text field within a software application or website that communicates on the backend with a blockchain node, where the software application of website then generated a response discussed below with respect to FIG. 4B.” See ¶0052 also.)
Regarding claims 11 and 17:
The combination of Wollack and Zimmerman, as shown in the rejection above, discloses the limitations of claims 1 and 16, respectively.
Wollack further teaches:
further comprising the digital ledger in communication with a carbon continuous settlement engine for facilitating trading of sequestered carbon credits associated with the SCAU data in the digital ledger, and the digital ledger modifying SCAU data to reflect changes in ownership of and/or offsetting consumption of sequestered carbon. (In ¶0062: teaches that “after a user claims ownership of the carbon-credits, ownership of the proper amount of carbon-credits may be transferred to the user, such as by adding a record of the carbon-credits in a digital wallet of the user and making a corresponding record in the blockchain and/or making a corresponding deduction from a digital wallet of a producer or fabricator (who may temporarily hold such carbon-credits in their digital wallets until claimed by users).” See ¶0049 for another example.)
Regarding claims 12, 14 and 18:
The combination of Wollack and Zimmerman, as shown in the rejection above, discloses the limitations of claims 11, 1 and 17, respectively.
Wollack further teaches:
further comprising the continuous monitoring engine tagging an SCAU, its related data set, and its related ADS with a compliance code that it complies with one or more governmental requirements for the generation of tradeable carbon credits. (In ¶0043 – 44; Fig. 1C (162, 150 and 170): teaches under BRI, that “the blockchain 150 may store sufficient data in some embodiments that a life-cycle analysis auditing service may complete a life-cycle analysis for the product based on the verified data within the blockchain. The result of the life-cycle analysis 174 as generated by the life-cycle analysis system 170 may also be placed in the blockchain 150 and associated with the corresponding unique product identifier, such as including a certificate or other verified information reflecting the results of the lifecycle analysis” which are based on “environmental impacts associated with the life of the product as determined from the information included in a plurality of ledger entries associated with the corresponding unique product identifier stored in the ledger(s)”, in accordance to the example of compliance code given in ¶0108 from Applicant disclosure. Also, refer to ¶0036 wherein “information regarding environmental impacts associated with the receiving 165 and shipment 168 processes (such as mileage tracking and/or fuel consumed in transporation) may be tracked and provided to the blockchain 150 for subsequent use in a life-cycle analysis performed by the life-cycle analysis system 170”. Also, “other environmental attributes” may be assigned, “such as a quantifiable and product-specific credit associated for reductions in water, energy, and/or other environmentally impactful inputs or impacts.” (see ¶0037).)
Wollack does not explicitly teach the ability of specifically having the continuous monitoring engine system tagging SCAUs and their related data for regulatory compliance, but. However, Zimmerman further teaches that its system can include “modules” wherein a “specific module would be designed to define the CERC production and uncertainty to normalize their value and document their compliance with regulatory requirements” as well as other modules that “can be added to quantify CERCs that will meet the regulatory requirements for documenting CERC generation for those applications” (see ¶0108 – 109; Zimmerman).
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Wollack to provide the ability of specifically having the continuous monitoring engine system tagging SCAUs and their related data for regulatory compliance, as taught by Zimmerman as the implementation of these modules in the system “reduces and preferably eliminates uncertainty for the potential CERC purchaser, thereby increasing the value of the CERC to the CERC producer” wherein such uncertainty comes from buying “relatively expensive insurance for protection against the carbon storage being less than expected” (¶0109 and ¶0066; Zimmerman), see also MPEP 2143.I.G.
Regarding claim 13:
The combination of Wollack and Zimmerman, as shown in the rejection above, discloses the limitations of claim 12.
Wollack does not explicitly teach the ability of having the continuous monitoring engine with an application, executing runtime-interpreted, object specific Gaussian and logical models. However, Zimmerman further teaches:
further comprising the application of runtime- interpreted, object specific Gaussian and logical models for logical assertion of compliance with a given authority. (In ¶0029; Fig. 1 (50); Fig. 5 (140): teaches that the system applies “a carbon sequestration model” wherein “the standardized CERCs” or “standardized carbon emission reduction credits” (see ¶0017) and “reserve CERCs are determined 50 through the application of an uncertainty analysis”. This “uncertainty analysis” is run by the system as conducting a “number of simulations” by employing “a Monte Carlo uncertainty analysis” (although “a variety of other methods may be used”) that include “input variables that affect the result are randomly assigned values that follow a particular distribution, such as Gaussian” (i.e. interpreted as specific Gaussian and logical models) which results in an “actual distribution U of values arising from the uncertainty in the key variables” being determined to “quantify the number of standardized CERCs for a land parcel” (see ¶0055 – 56). Also, in ¶0085 this model is run through a “master script” program that “calls a set of Perl scripts which parse the appropriately formatted input files required by the carbon sequestration model. The master script calls the carbon sequestration model to perform its program and then the uncertainty analysis program to perform its program”. See ¶0097 wherein an example is provided wherein the “relevant general data is input into a carbon sequestration model to determine whether the carbon reservoir of the soil is full. If it is full, the soil is not capable of satisfying the requirement of additivity and CERCs will not be generated. If the carbon reservoir is not full, the potential CERC producer is prompted to provide additional site-specific data” and see ¶0109 wherein “Modules can be added to quantify CERCs that will meet the regulatory requirements for documenting CERC generation for those applications”. The Examiner notes that the purpose claimed for allocating SCAU credits to SKUs, to run the object specific Gaussian and logical models in the system is non-functional descriptive matter.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Wollack to provide the ability of having the continuous monitoring engine with an application, executing runtime-interpreted, object specific Gaussian and logical models, as taught by Zimmerman in order to “determine the approximate change in the level of carbon compounds in soil over specified time periods” which is “advantageous for data for years dating back into time, such as prior to 1990 and back as far as 1900 or earlier, for which site-specific data may be difficult or impossible to document.”(¶0052; Zimmerman). Further, such data standardization by using these specific STMs models, “allow individual landowners, or groups of landowners, to input requested information and receive reports quantifying accrued and projected standardized CERCs, as well as CERCs to be held in reserve.” (¶0086; Zimmerman), see also MPEP 2143.I.G.
Regarding claims 15 and 19:
The combination of Wollack and Zimmerman, as shown in the rejection above, discloses the limitations of claims 14 and 17, respectively.
Wollack does not explicitly teach the ability of having the continuous monitoring engine executing runtime-interpreted, object specific Gaussian and logical models. However, Zimmerman further teaches:
further comprising the continuous monitoring engine executing runtime-interpreted, object specific Gaussian and logical models for logical assertion of compliance with a given authority. (In ¶0029; Fig. 1 (50); Fig. 5 (140): teaches that the system applies “a carbon sequestration model” wherein “the standardized CERCs” or “standardized carbon emission reduction credits” (see ¶0017) and “reserve CERCs are determined 50 through the application of an uncertainty analysis”. This “uncertainty analysis” is run by the system as conducting a “number of simulations” by employing “a Monte Carlo uncertainty analysis” (although “a variety of other methods may be used”) that include “input variables that affect the result are randomly assigned values that follow a particular distribution, such as Gaussian” (i.e. interpreted as specific Gaussian and logical models) which results in an “actual distribution U of values arising from the uncertainty in the key variables” being determined to “quantify the number of standardized CERCs for a land parcel” (see ¶0055 – 56). Also, in ¶0085 this model is run through a “master script” program that “calls a set of Perl scripts which parse the appropriately formatted input files required by the carbon sequestration model. The master script calls the carbon sequestration model to perform its program and then the uncertainty analysis program to perform its program”. See ¶0097 wherein an example is provided wherein the “relevant general data is input into a carbon sequestration model to determine whether the carbon reservoir of the soil is full. If it is full, the soil is not capable of satisfying the requirement of additivity and CERCs will not be generated. If the carbon reservoir is not full, the potential CERC producer is prompted to provide additional site-specific data” and see ¶0109 wherein “Modules can be added to quantify CERCs that will meet the regulatory requirements for documenting CERC generation for those applications”. The Examiner notes that the purpose claimed for allocating SCAU credits to SKUs, to run the object specific Gaussian and logical models in the system is non-functional descriptive matter.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Wollack to provide the ability of having the continuous monitoring engine executing runtime-interpreted, object specific Gaussian and logical models, as taught by Zimmerman in order to “determine the approximate change in the level of carbon compounds in soil over specified time periods” which is “advantageous for data for years dating back into time, such as prior to 1990 and back as far as 1900 or earlier, for which site-specific data may be difficult or impossible to document.”(¶0052; Zimmerman). Further, such data standardization by using these specific STMs models, “allow individual landowners, or groups of landowners, to input requested information and receive reports quantifying accrued and projected standardized CERCs, as well as CERCs to be held in reserve.” (¶0086; Zimmerman), see also MPEP 2143.I.G.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ashtekar (U.S. Pub No. 20220138767 A1) is pertinent because it “relates in general to the field of regenerative agricultural practices, and more specifically to methods and systems for carbon footprint determination, monitoring, and verification for agricultural parcels based on implementation of regenerative management practices.”
McEntire (U.S. Patent No. 11715024 B1) is pertinent because it “relates to a system and method for estimating soil chemistry at different crop field locations. More specifically, the system and method blend and optimize a first interpolation training model that prioritizes spatial smoothing over accuracy and a second interpolation training model that prioritizes accuracy over spatial smoothing.”
Feierstein (U.S. Pub No. 20110208621 A1) is pertinent because it is “a computer implemented method for creating carbon neutral products.”
Silverstein (U.S. Pub No. 20210224819 A1) is pertinent because it “relates generally to the field of reduction of greenhouse gas emissions, and more particularly to carbon footprint tracking.”
Gupta (U.S. Pub No. 20200111105 A1) is pertinent because it “relates to the tracking and using of carbon credits via a blockchain, specifically the use of a blockchain and associated currency to incentivize and track the sequestration of carbon dioxide in the atmosphere.”
Soestbergen (U.S. Pub No. 20020143693 A1) is pertinent because it “relates to a method and system for the banking and trading of emission reduction credits (ERC's). Specifically, the invention relates to a method and system for a global online venue for the issuing of ERC's to renewable energy systems, for their reduction or their need for fossil fuels, and the transferring of ERC's to systems in need of ERC's.”
Wang, Blockchain Technology and Its Role in Enhancing Supply Chain Integration Capability and Reducing Carbon Emission: A Conceptual Framework (17 December 2020) is pertinent because it “presents a conceptual framework to understand the role of blockchain in a low carbon supply chain management.”
Shakhbulatov, Blockchain Implementation for Analysis of Carbon Footprint across Food Supply Chain (02 January 2020) is pertinent because it “presents a new implementation of blockchain for tracking of carbon footprint on food production and transportation stages.”
Woo, Applying blockchain technology for building energy performance measurement, reporting, and verification (MRV) and the carbon credit market: A review of the literature (30 July 2021) is pertinent because it discusses “the literature of the BEP audit programs, the carbon credit market for the building sector, the possibility of adopting Blockchain technology to a digital BEP MRV. The study found that the digital MRV system, which climate action projects require, can be applied to the building sector with the adoption of Blockchain technology. Next, because a few blockchain carbon credit markets are already running, a blockchain digital MRV system needs to be developed to help the building sector participate in the carbon credit markets.”
Varouchakis, Gaussian Transformation Methods for Spatial Data (1 May 2021) is pertinent because it “presents alternative methods for data transformation and revisits the applicability of a modified version of the well-known Box-Cox technique” which “was tested in average rainfall data and detrended rainfall data (fluctuations), in groundwater level data, in Total Organic Carbon wt% residuals and using random number generator simulating potential experimental results. It was found that the Modified Box-Cox technique competes successfully in data transformation. On the other hand, it improved significantly the normalization of negative sign data or fluctuations. The coding of the method is presented by means of a Graphical User Interface format in MATLAB environment for reproduction of the results and public access.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ivonnemary Rivera Gonzalez whose telephone number is (571)272-6158. The examiner can normally be reached Mon - Fri 9:00AM - 5:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nathan Uber can be reached at (571) 270-3923. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/IVONNEMARY RIVERA GONZALEZ/Examiner, Art Unit 3626
/NATHAN C UBER/Supervisory Patent Examiner, Art Unit 3626
Prosecution Insights