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 following is a Final Office action in response to the communication filed on 06/04/2026. Claims 1—15 and 17—20 are currently pending.
Priority
The Applicant’s claim for benefit of US Provisional Patent Application 63/276,928 filed on 11/08/2021, has been received and acknowledged.
Information Disclosure Statement
Information Disclosure Statements received 3/23/2023 and 8/25/2025 have been reviewed and considered.
Response to Arguments
Applicant provided a statement directed to a double patenting rejection in view of Issued US Patent 10,636,521 B1. Examiner believes this may be a typographical error insofar as a double patenting rejection was not issued in the Non-Final Rejection dated 03/04/2026.
Applicant's amendments and arguments filed 06/04/2026 regarding the rejection of claims 1—20 under 35 U.S.C. 101 have been fully considered but they are not persuasive. The Response at page 8 discusses generating “an engineered input dataset having concrete oilfield-specific features,” which is directed to an abstract idea insofar as data manipulation constitutes a mental process, a mathematical concept, or a combination thereof. The Response continues at page 9 with identifying that the engineered dataset is used to train multiple forecast models to generate an optimized production forecast model. Examiner notes that while training a machine learning model constitutes an additional element rather than an abstract idea, the level of generality at which the training is recited does not provide for a practical application because the training is not recited in a specific enough manner to constitute more than well-known training as is known to be used with machine learning (e.g., this is discussed at page 5 of the Non-Final Office Action dated 03/04/2026). Furthermore, the generated model itself is directed to an abstract idea insofar as mathematical models are abstract.
The Response at page 9 further states the “optimized production forecast model… is explicitly used to adjust pumping schedule parameters for physical field components in a well field.” While utilizing the output from the model to perform physical adjustments to a piece of equipment constitutes an additional element directed to an application of the judicial exception, the level of generality at which the application is recited does not make for a practical application as set forth in the MPEP. Examples of limitations which do properly integrate the recited judicial exception into a practical application include the limitations of Diehr. For example, the MPEP states “[i]n contrast, the additional elements in Diamond v. Diehr as a whole provided eligibility and did not merely recite calculating a cure time using the Arrhenius equation ‘in a rubber molding process’. Instead, the claim in Diehr recited specific limitations such as monitoring the elapsed time since the mold was closed, constantly measuring the temperature in the mold cavity, repetitively calculating a cure time by inputting the measured temperature into the Arrhenius equation, and opening the press automatically when the calculated cure time and the elapsed time are equivalent. 450 U.S. at 179, 209 USPQ at 5, n. 5. These specific limitations act in concert to transform raw, uncured rubber into cured molded rubber. 450 U.S. at 177-78, 209 USPQ at 4.” (MPEP 2106.05(h)). Accordingly, the limitations of Diehr which integrated the abstract idea (e.g., calculations using the Arrhenius equation) into a practical application (e.g., opening the press automatically once the calculated cure time and elapsed time are equivalent) provided a more specific application which was directly tied to the outcome of the judicial exception than that of the instant claims. For example, Diehr did not merely state “calculating temperatures using the Arrhenius equation to adjust a rubber molding process.” Moreover, the limitation in the claims directed to adjusting a pump schedule is directed to an intended use of the model rather than providing for a positively recited limitation which requires the equipment is adjusted in a particular manner using a particular outcome from the optimized production forecast model.
The Response at page 9 further states “[t]his ordered combination of steps reflects a technical improvement to data-driven reservoir modeling and completion optimization…”. Examiner notes that an improvement to an abstract idea (e.g., improving the accuracy of a model by improving the data used to train the model) does not meet the threshold for providing for a technical improvement in a technical field. For example, the MPEP states “[n]otably, the court did not distinguish between the types of technology when determining the invention improved technology. However, it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology.” (MPEP 2106.05(a), Section II).
For the above provided reasons, the arguments and amendments set forth with respect to the subject matter eligibly of claims 1—15 and 17—20 are not persuasive and the rejection of the claims under 35 U.S.C. 101 is maintained as modified in view of the amendments.
Applicant's amendments and arguments filed 06/04/2026 regarding the rejection of claims 1—4, 6—11, 13—18, and 20 under 35 U.S.C. 102 have been fully considered but they are not persuasive. The Response at page 14 states “Sun does not disclose extracting raw field data for a plurality of well of the well field.” However, on page 13, the Response states the Sun retrieves production rates (e.g., historical production rates including oil rate, water rate, and gas rate as recited in para. [0038] of Sun) and well operation constraints (e.g., wellhead tubing pressure and choke size as recited in para. [0038] of Sun). Examiner notes that the recorded production rates, and the well operation constraints associated with those production rates, is raw field data. Moreover, Sun discloses the retrieval of the well site data (e.g., as discussed in para. [0034]) which includes temporal data (para. [0035]) and spatial data (para. [0040]) where the temporal and spatial data are measurements of what actually occurred on the well. Accordingly, the assertion that Sun does not disclose extracting raw field data as stated above is not persuasive because Sun does exactly that.
The Response at page 14 further states that Sun does not disclose “receiving, via a user interface, user-based data comprising expert domain knowledge associated with reservoir properties of the well field.” However, Sun explicitly discloses gathering raw well data (e.g., including reservoir properties) and performing exploratory data analysis based on domain knowledge. For example, Sun states:
“[a]fter the new database is created with the input data, the input data may be engineered and transformed. This may include performing exploratory data analysis and extracting preliminary insights from the input data. Features and responses may be extracted from the temporal data and features from the spatial data may be extracted based on domain knowledge in drilling, completion engineering, and reservoir and production engineering. The input data may then be scaled and divided into subsets including a training subset, a validation subset, and a test subset.” (Sun, para. [0036]); and
“[d]ata exploratory analysis may focus on identification of features that impact well production based on domain knowledge. As an example, if the input production rates indicate that there were frequent well shut-in and pressure build-up tests, this information should be used to train a model to learn underlying physics associated with one or more wells. This may assist in well production forecasting and allow one or more wells to be categorized into a group having similar rock and fluid properties.” (para. [0037]).
Accordingly, the assertion that Sun does not teach the generation and incorporation of data based on domain knowledge which is incorporated into the dataset used for training the machine learning model, is not persuasive because Sun does exactly that (e.g., para. [0034]—[0043] of Sun).
The Response at page 14 further states “Sun also does not disclose preprocessing the raw field data from the plurality of wells of the well field with the user-based data received from the user interface by embedding the expert domain knowledge into the raw field data through data preparation and feature engineering to generate an input dataset including one or more engineering features comprising at least one of fracturing design information, pumping schedule information, number of stages, fluid-system selection, wellhead tubing pressure, or choke size,” to which the Examiner does not agree. Sun expressly discloses preprocessing and analysing raw field data as set forth in para. [0036]—[0038] and as discussed above. For example, Sun art para. [0034]—[0043] discloses collecting/receiving raw data from data repositories located on the well site, performing data analysis using domain knowledge, performing feature engineering using domain knowledge, combining the various analyzed data (e.g., including both raw data and engineered data) to make a dataset, and splitting out the data into subset for the purpose of training a machine learning model. Moreover, the dataset of Sun discloses multiple instances of the features recited in the claims, for example, Sun discloses:
“[t]he temporal data may include well production response information such as oil rates, gas rates, and water rates. The temporal data also may include well operation constraint information such as wellhead or bottomhole pressure information and choke size information. Other input data may include drilling and well completion design information (e.g., fracturing design information and pumping schedule information), well interference test information, well logs, and seismic images. The input data may be obtained from one or more sources and stored in the new database. In one example, the input data may include wellhead tubing pressure and production rates for one or more wells.” (Sun, para. [0035]);
“[t]he temporal features may include… well operation constraints such as tubing head pressure, casing pressure, and choke size, and other information including hydraulic fracturing pumping schedule, real-time production surveillance, and multiple well interference test information.” (Sun, para. [0039]); and
“[a]dditionally, the spatial features may include laboratory data including routine core or special core analysis, chemical additives associated with the well including surfactant, microproppants, friction reducer, clay control, and other information.” (Sun, para. [0040]).
Accordingly, the assertion that Sun does not disclose generating a dataset based on preprocessing raw field data and incorporating expert domain knowledge, is not persuasive because Sun does exactly that (e.g., para. [0034]—[0043] of Sun).
For the foregoing reasons, the prior art rejection of claims 1—4, 6—11, 13—18, and 20 under 35 U.S.C. 102 to Sun is maintained as modified below in view of the provided amendments.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1—15 and 17—20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Independent claims 1, 8, and 15 recite the limitation “user-based data comprising expert domain knowledge associated with reservoir properties of the well field.” The term “expert” in the claim element “expert domain knowledge” as recited in claims 1, 8, and 15 is a relative term which renders the claim indefinite. The term “expert” in the claim element “expert domain knowledge” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Moreover, the level of experience required to render someone an expert such that their evaluation of the reservoir properties would generate expert domain knowledge is unclear therefore rendering the threshold for an expert indefinite. For the purposes of examination, “expert domain knowledge” (e.g., as it pertains to the reservoir properties of the well field), is understood to be any data which describes a reservoir property.
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.
Step 1 of the USPTO’s eligibility analysis entails considering whether the claimed subject matter falls within the four statutory categories of patentable subject matter identified by 35 U.S.C. 101: Process, machine, manufacture, or composition of matter.
Claims 1, 8, and 15 are directed to a method (process), non-transitory computer-readable storage media storing computer instructions (machine or manufacture), and a system (machine or manufacture), respectively. As such, the claims are directed to statutory categories of invention.
If the claim recites a statutory category of invention, the claim requires further analysis in Step 2A. Step 2A of the 2019 Revised Patent SUBJECT Matter Eligibility Guidance is a two-prong inquiry. In Prong One, examiners evaluate whether the claim recites a judicial exception
Claim 1 recites the following abstract limitations:
“receiving, via a user interface, user-based data comprising expert domain knowledge associated with reservoir properties of the well field” (e.g., mental process);
“preprocessing the raw field data from the plurality of wells of the well field with the user-based data received from the user interface by embedding the expert domain knowledge into the raw field data through data preparation and feature engineering to generate an input dataset” (e.g., mental process and/or mathematical concept); and
“generating an optimized production forecast model from the plurality of trained completion forecast models to adjust pumping schedule information for one or more physical field components in the well field adjustable based on the optimized production forecast model” (e.g., mental process and/or mathematical concept; Examiner notes the limitation directed to the adjustments to the pumping schedule is not positively recited and is merely an intended use of the optimized production forecast model. Accordingly, the equipment adjustment is not a required step of the claims, the optimized production forecast model must merely be configured to generate outputs for such a task).
Claim 8 recited the following abstract limitations:
“receiving, via a user interface, user-based data comprising expert domain knowledge associated with reservoir properties of the well field” (e.g., mental process);
“preprocessing the raw field data from the plurality of wells of the well field with the user-based data received from the user interface by embedding the expert domain knowledge into the raw field data through data preparation and feature engineering to generate an input dataset” (e.g., mental process and/or mathematical concept); and
“generating an optimized production forecast model from the plurality of trained completion forecast models to adjust pumping schedule information for one or more physical field components in the well field adjustable based on the optimized production forecast model” (e.g., mental process and/or mathematical concept; Examiner notes the limitation directed to the adjustments to the pumping schedule is not positively recited and is merely an intended use of the optimized production forecast model. Accordingly, the equipment adjustment is not a required step of the claims, the optimized production forecast model must merely be configured to generate outputs for such a task).
Claim 15 recites the following abstract limitations:
“receive, via a user interface, user-based data comprising expert domain knowledge associated with reservoir properties of the well field” (e.g., mental process);
“preprocess the raw field data from the plurality of wells of the well field with the user-based data received from the user interface by embedding the expert domain knowledge into the raw field data through data preparation and feature engineering to generate an input dataset” (e.g., mental process and/or mathematical concept); and
“generate an optimized production forecast model from the plurality of trained completion forecast models to adjust pumping schedule information for one or more physical field components in the well field adjustable based on the optimized production forecast model” (e.g., mental process and/or mathematical concept; Examiner notes the limitation directed to the adjustments to the pumping schedule is not positively recited and is merely an intended use of the optimized production forecast model. Accordingly, the equipment adjustment is not a required step of the claims, the optimized production forecast model must merely be configured to generate outputs for such a task).
Under the broadest reasonable interpretation, the above identified limitations cover abstract ideas directed to mental processes, mathematical concepts, and/or combinations thereof. For example, actions such as receiving data through an interface are actions which constitute mental processes insofar as a human brain can receive data by observing a user interface such as a screen. Actions such as preprocessing data (e.g., regardless of source or content of the data) to create a dataset for training a machine learning model is a mental process insofar as it may be performed in a human mind with or without the benefit of a mathematical concept. Furthermore, generating an optimized production forecast model is directed to a mental process, mathematical concept, or a combination thereof where:
mathematically and/or conceptually derived models, which model real-world operations, are inherently abstract ideas; and
optimizing such a model is merely optimizing an abstract idea.
The MPEP states the following regarding mental processes: “[t]he courts consider a mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). As the Federal Circuit explained, "methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas the ‘basic tools of scientific and technological work’ that are open to all.’… Accordingly, the ‘mental processes’ abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes include observations, evaluations, judgments, and opinions. A discussion of concepts performed in the human mind, as well as concepts that cannot practically be performed in the human mind and thus are not ‘mental processes’, is provided below with respect to point A.” (MPEP 2106.04(a)(2), Section III).
The MPEP states the following regarding mathematical calculations: “[a] claim that recites a mathematical calculation, when the claim is given its broadest reasonable interpretation in light of the specification, will be considered as falling within the ‘mathematical concepts’ grouping. A mathematical calculation is a mathematical operation (such as multiplication) or an act of calculating using mathematical methods to determine a variable or number, e.g., performing an arithmetic operation such as exponentiation. There is no particular word or set of words that indicates a claim recites a mathematical calculation. That is, a claim does not have to recite the word ‘calculating’ in order to be considered a mathematical calculation. For example, a step of ‘determining’ a variable or number using mathematical methods or ‘performing’ a mathematical operation may also be considered mathematical calculations when the broadest reasonable interpretation of the claim in light of the specification encompasses a mathematical calculation.” (MPEP 2106.04(a)(2), Section I, Subsection C).
Accordingly, the above identified limitations are directed to abstract ideas such that claims 1, 8, and 15 recite abstract ideas.
If the claim recites a judicial exception (i.e., an abstract idea enumerated in Section I of the 2019 Revised Patent Subject Matter Eligibility Guidance, a law of nature, or a natural phenomenon), the claim requires further analysis in Prong Two. In Prong Two, examiners evaluate whether the claim recites additional elements that integrate the exception into a practical application of that exception.
Claim 1 recites the following additional elements:
“extracting raw field data for a plurality of wells of the well field” (e.g., extra-solution activity directed to mere data gathering and/or data transfer); and
“training, based on the input dataset and utilizing a deep learning computing technique, a plurality of completion forecast models” (e.g., a model training step recited at a high level of generality is equivalent to reciting “apply it.”).
Claim 8 recites the following additional elements:
“one or more tangible non-transitory computer-readable storage media” (e.g., recitation of generic computer components is equivalent to reciting “apply it”);
“extracting raw field data for a plurality of wells of the well field” (e.g., extra-solution activity directed to mere data gathering and/or data transfer); and
“training, based on the input dataset and utilizing a deep learning computing technique, a plurality of completion forecast models” (e.g., a model training step recited at a high level of generality is equivalent to reciting “apply it.”).
Claim 15 recites the following additional elements:
“a waterflood completion optimization system having at least one processor” (e.g., recitation of generic computer components is equivalent to reciting “apply it”);
“extract raw field data for a plurality of wells of the well field” (e.g., extra-solution activity directed to mere data gathering and/or data transfer); and
“training, based on the input dataset and utilizing a deep learning computing technique, a plurality of completion forecast models” (e.g., a model training step recited at a high level of generality is equivalent to reciting “apply it.”).
The above identified limitations of claims 1, 8, and 15 constitute additional elements. However, for the reasons identified above, and discussed further below, the additional elements do not impose any meaningful limits on practicing the abstract idea. Accordingly, the above identified additional elements do not integrate the identified judicial exceptions into a practical application.
If the additional elements do not integrate the exception into a practical application, then the claim is directed to the recited judicial exception, and requires further analysis under Step 2B to determine whether they provide an inventive concept (i.e., whether the additional elements amount to significantly more than the exception itself).
Claims 1, 8, and 15 recite limitations directed to extracting raw field data for a plurality of wells of a well field which constitutes an additional element directed to mere data gathering or data transfer. Such limitations cannot provide for a practical application of the identified judicial exception because they constitute court-identified insignificant extra-solution activity. For example, the MPEP states:
“[t]he courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added))… iii. Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93.” (MPEP 2106.05 (d), Subsection II).
The MPEP further states “[b]elow are examples of activities that the courts have found to be insignificant extra-solution activity: Mere Data Gathering: ii. Testing a system for a response, the response being used to determine system malfunction, In re Meyers, 688 F.2d 789, 794; 215 USPQ 193, 196-97 (CCPA 1982); iv. Obtaining information about transactions using the Internet to verify credit card transactions, CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011); v. Consulting and updating an activity log, Ultramercial, 772 F.3d at 715, 112 USPQ2d at 1754.” (MPEP 106.05(f)). Accordingly, limitations directed to mere data gathering and/or data transfer, as identified above pertaining to claims 1, 8, and 15 do not provide for a practical application of the identified abstract ideas because the limitations are directed to insignificant extra-solution activity.
Claims 1, 8, and 15 recite limitations directed to “training, based on the input dataset and utilizing a deep learning computing technique, a plurality of completion forecast models,” which constitutes an additional element, but does not provide for a practical application of the identified judicial exceptions because the limitation is equivalent to a mere directive to apply the exception. For example, while the limitation is directed to training a machine learning algorithm, it is recited at a high level of generality and does not provide the level of particularity required to show a practical application. With respect to limitations which constitutes mere directives to apply the exception (e.g., equivalent to “apply it”) the MPEP states:
“[w]hen determining whether a claim simply recites a judicial exception with the words ‘apply it’ (or an equivalent), such as mere instructions to implement an abstract idea on a computer, examiners may consider the following: (1) Whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished. The recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words ‘apply it’. See Electric Power Group, LLC v. Alstom, S.A., 830 F.3d 1350, 1356, 119 USPQ2d 1739, 1743-44 (Fed. Cir. 2016); Intellectual Ventures I v. Symantec, 838 F.3d 1307, 1327, 120 USPQ2d 1353, 1366 (Fed. Cir. 2016); Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1417 (Fed. Cir. 2015). In contrast, claiming a particular solution to a problem or a particular way to achieve a desired outcome may integrate the judicial exception into a practical application or provide significantly more. See Electric Power, 830 F.3d at 1356, 119 USPQ2d at 1743.” (MPEP 2106.05(f)). In view of the foregoing, a generic model training step which applies a generically recited type of algorithm (e.g., a “deep learning computing technique” accounts for a whole class of algorithms which can provide either regression or classification outputs) to a dataset (e.g., raw and user data where selecting data based on source and or content does not provide for a practical application as set forth in MPEP 2106.05(g)) does not provide for an additional element with the level of specificity to show a practical application. Accordingly, the limitation directed to training a model does not provide for a practical application of the identified judicial exceptions.
Claim 8 recites the limitation “one or more tangible non-transitory computer-readable storage media” which constitute generically recited computer components and does not provide for a practical application of the judicial exception. For example, the MPEP states “[w]hen determining whether a claim simply recites a judicial exception with the words ‘apply it’ (or an equivalent), such as mere instructions to implement an abstract idea on a computer, examiners may consider the following… (2) Whether the claim invokes computers or other machinery merely as a tool to perform an existing process. Use of a computer or other machinery in its 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 after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, ‘claiming the improved speed or efficiency inherent with applying the abstract idea on a computer’ does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).” (MPEP 2106.05(f), Section 2). Accordingly, the limitations of claim 8 does not provide for a practical application of the judicial exception because the limitations are equivalent to a mere directive to apply the exception.
Claim 15 recites “a waterflood completion optimization system having at least one processor” which constitute generically recited computer components (e.g., the only physical component which defines the waterflood completion optimization system is the recited processor) and does not provide for a practical application of the judicial exception. For example, the MPEP states “[w]hen determining whether a claim simply recites a judicial exception with the words ‘apply it’ (or an equivalent), such as mere instructions to implement an abstract idea on a computer, examiners may consider the following… (2) Whether the claim invokes computers or other machinery merely as a tool to perform an existing process. Use of a computer or other machinery in its 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 after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). Similarly, ‘claiming the improved speed or efficiency inherent with applying the abstract idea on a computer’ does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).” (MPEP 2106.05(f), Section 2). Accordingly, the limitation of claim 15 does not provide for a practical application of the judicial exception because the limitations are equivalent to a mere directive to apply the exception.
Thus, even when viewed as an ordered combination, nothing in the claims add significantly more (i.e., an inventive concept) to the abstract idea.
Claims 2 and 9 recite the limitation “interpreting the plurality of completion forecast models…” which constitutes a mental process insofar as making an interpretation is an action performable in a human mind with or without the benefit of a mathematical concept or pen and paper. Performing the interpretation with the benefit of a computer would not take the claims out of the mental process grouping. As such, claims 2 and 9 are directed to an abstract idea.
Claims 3, 4, 10, 11, and 18 recite limitations directed to the above identified additional element of training the model; however, as discussed above, the limitations are recited at such a high level of generality that they do not provide for a practical application of the identified judicial exceptions. For example, merely stating the use of a specific common algorithm would not function to integrate the judicial exception into a practical application (e.g., because it would be identified as well understood, routine, and conventional); however, even that type of limitation is more specific than those provided in claims 3, 4, 10, 11, and 18. As such, while the claims do not recite any further judicial exceptions, they do not succeed in reciting limitations which provide for a practical application.
Claims 5, 12, and 19 are directed to a mental process insofar as “expanding data” using either a scatter or box plot is an action which is performable in the human mind with the benefit of either or both of: 1.) a pen and paper; and 2.) a mathematical concept. Additionally, performing the data expansion with the benefit of a computer would not take the claims out of the mental process and/or mathematical concept grouping. As such, claims 5, 12, and 19 are directed to an abstract idea.
Claims 6, 13, and 17 recite limitations directed to displaying a result generated from the model which is equivalent to reciting the limitation “apply it.” As addressed in MPEP 2106.05(f), mere instruction to apply an exception cannot provide for a practical application of the judicial exception. For example, the MPEP states “[t]he recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words ‘apply it'. See Electric Power Group, LLC v. Alstom, S.A., 830 F.3d 1350, 1356, 119 USPQ2d 1739, 1743-44 (Fed. Cir. 2016).” Examiner notes that merely presenting a result from a model fails to specifically implement any potential outcome from the model in any type of practical or tangible way which could reasonably provide for a practical application. As such, claims 6, 13, and 17 do not recite limitations which integrate the judicial exception into a practical application.
Claims 7, 14, and 20 recite limitations directed to the mathematical concept of repeatedly supplying a numerical dataset (e.g., measured production data is numerical data) to a model to generate a numerical prediction which constitutes an abstract idea (e.g., judicial exception). The claims do not recite any additional elements which function to integrate the judicial exceptions identified in the independent claims into a practical application. Moreover, claims 7, 14, and 20 themselves are exclusively directed to a judicial exception and therefore do not provide for a practical application.
Claim 16 recites the additional element of “wherein the user-based data is received from a user interface presented by a user device,” which amounts to mere data gathering as identified in MPEP 2106.05(g). Mere data gathering amounts to extra solution activity which cannot provide for a practical application of the judicial exception. Furthermore, providing user-based data through a computer amounts to electronic recordkeeping which the courts have identified as well-understood, routine, and conventional activity. For example, the MPEP states “[t]he courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity… iii. Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93…”. (MPEP 2106.05(d), Section II). Extra-solution activity which is determined to be well-understood, routine, and conventional cannot provide for a practical application of the identified judicial exception. As such the limitations of claim 16 do not integrate the judicial exception of claim 15 into a practical application.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1—4, 6—11, 13—18, and 20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Published US Patent Application to Sun et al., hereinafter “Sun” (US 20210010351 A1).
Regarding claim 1, Sun discloses [a] method for generating a forecast model of a well field (para. [0017], “[a] well productivity system may apply deep learning techniques such as long-short term memory (LSTM) or gated recurrent unit (GRU) and/or convolutional neural networks (CNN) to forecast well production rates and optimize corresponding development and completion strategies for one or more wells.”; para. [0046], “[t]he well productivity system 201 can be implemented for forecasting well productivity accurately and efficiently, in real-time, using deep learning neural networks as described herein. In this example, the well productivity system 201 can include compute components 202, a model development engine 204, a forecast engine 206, and a storage 208.), the method comprising:
extracting raw field data for a plurality of wells of the well field (para. [0034], “[i]n a first step, temporal and spatial data is collected. Production rates and well operation constraints and other optional temporal and spatial measurement data may be collected. The temporal and spatial data may be retrieved from available datasets from on-premise computing devices and/or cloud computing devices. A new database may be created that may store the temporal and the spatial data.”; para. [0035], “[t]he temporal data may include well production response information such as oil rates, gas rates, and water rates. The temporal data also may include well operation constraint information such as wellhead or bottomhole pressure information and choke size information. Other input data may include drilling and well completion design information (e.g., fracturing design information and pumping schedule information), well interference test information, well logs, and seismic images. The input data may be obtained from one or more sources and stored in the new database. In one example, the input data may include wellhead tubing pressure and production rates for one or more wells.”; para. [0040], “[t]he spatial features may include well trajectory information including true vertical depth, latitude, longitude, measured depth, horizontal well lateral length, multiple well spacing information, and parent-child well relationship information. In addition, the spatial features may include geological map information such as structural maps, formation top information, interpreted geomodel map information such as porosity and pressure. The spatial features also may include well log information including gamma ray, density, and resistivity information. Additionally, the spatial features may include laboratory data including routine core or special core analysis, chemical additives associated with the well including surfactant, microproppants, friction reducer, clay control, and other information.” Examiner notes that the above recited data including oil rates, gas rates, water rates, operation constraint information, and completion design information are raw field data insofar as these measurements are collected from actual measured events that occurred on the well.);
receiving, via a user interface, user-based data comprising expert domain knowledge associated with reservoir properties of the well field (para. [0036], “[a]fter the new database is created with the input data, the input data may be engineered and transformed. This may include performing exploratory data analysis and extracting preliminary insights from the input data. Features and responses may be extracted from the temporal data and features from the spatial data may be extracted based on domain knowledge in drilling, completion engineering, and reservoir and production engineering. The input data may then be scaled and divided into subsets including a training subset, a validation subset, and a test subset.”; para. [0037], “Data exploratory analysis may focus on identification of features that impact well production based on domain knowledge.”; para. [0038], “[h]istorical production rates (i.e., oil rates, gas rates, and water rates) may be used to determine gas-oil ratio information, water-oil information, and cumulative water/hydrocarbon production volume. Well operation constraints such as wellhead tubing pressure and choke size may be taken into consideration to handle complex production forecasting and well-development optimization tasks.” Examiner notes that the raw field data is assessed in view of domain knowledge pertaining to at least reservoir engineering where the assessed temporal and spatial features as recited in para. [0035] and [0040] include multiple reservoir properties.);
preprocessing the raw field data from the plurality of wells of the well field with the user-based data received from the user interface by embedding the expert domain knowledge into the raw field data through data preparation and feature engineering to generate an input dataset (see para. [0034]—[0042] which discusses gathering the raw data, analyzing the data to perform feature engineering, combining the relevant data pieces together to generate a dataset, and splitting out the dataset into test/train/validation datasets for model training) including one or more engineering features comprising at least one of fracturing design information (para. [0035] as provided above), pumping schedule information (para. [0035] and [0039]), number of stages, fluid-system selection (para. [0040]), wellhead tubing pressure (para. [0035] and [0039]), or choke size (both the raw field data and the engineered features as identified above in para. [0034]—[0036] are combined together to make a dataset. The features of the dataset read on the recited features of the claim including as recited in at least para. [0039], “oil rate, gas rate, and water rate, rate ratios such as water-oil ratio, gas-oil ratio, gas-liquid ratio, hydrocarbon-water ratio, cumulative production such as cumulative oil volume, cumulative gas volume, and cumulative water volume, well operation constraints such as tubing head pressure, casing pressure, and choke size, and other information including hydraulic fracturing pumping schedule, real-time production surveillance, and multiple well interference test information. The spatial features may be related to static data or images related to drilling and completion (i.e., well trajectory, spacing, true vertical depth), formation evaluation, well logs, cores, and laboratory measurement information.”);
training, based on the input dataset and utilizing a deep learning computing technique, a plurality of completion forecast models (para. [0019], “the system may use the training data subset, the validation data subset, and the test data subset to build and train a model using LSTM or GRU and/or CNN.” Examiner notes that long-short term memory (LSTM; e.g., a type of recurrent neural network), gated recurrent unit (GRU; e.g., a type of recurrent neural network architecture), and convolutional neural networks (CNN; e.g., a deep learning algorithm which is a feedforward neural network) are each distinct machine learning algorithms and architectures which, when utilized separately (e.g., “or”) or in combination (e.g., “and”), generate a plurality of models. As such, building a model using LSTM or GRU and/or CNN will generate a plurality of models.); and
generating an optimized production forecast model (forecast engine 206) from the plurality of trained completion forecast models to adjust pumping schedule information for one or more physical field components in the well field adjustable based on the optimized production forecast model (para. [0017], “[a] well productivity system may apply deep learning techniques such as long-short term memory (LSTM) or gated recurrent unit (GRU) and/or convolutional neural networks (CNN) to forecast well production rates and optimize corresponding development and completion strategies for one or more wells.”; para. [0056], “[t]he forecast engine 206 uses the model that is continually learning and receiving input data by the model development engine 204 to generate and provide output data comprising production rates for one or more wells. The production rates may include a gas rate, an oil rate, and a water rate for a particular period of time such as one day. In addition, the forecast engine may determine averaged reservoir pressure.”; para. [0057], “[t]he forecast engine 206 can be used to provide maintenance predictions and schedule maintenance for one or more wells and can be used to provide equipment failure diagnosis for the one or more wells. The forecast engine 206 also may be used to optimize well completion in order to maximize an oil recovery factor and/or a net present value (NPV) and/or other KPI of the one or more wells.).”; para. [0058], “the forecast engine 206 may be used to modify input constraints associated with the one or more wells such as a pumping schedule of hydraulic fracture treatment, a number of stages, and types of fluid systems (i.e., slick water with friction reducer, linear gel), among other input constraints. As another example, a water flooding field development plan can be optimized by modifying input constraints by the forecast engine 206 such as a water injection period or a water amount. Other modifications and adjustments to input constraints are possible.” Examiner notes the limitation directed to the adjustments to the pumping schedule is not positively recited and is merely an intended use of the optimized production forecast model. Accordingly, the equipment adjustment is not a required step of the claims, the optimized production forecast model must merely be configured to generate outputs for such a task).
Regarding claim 2, Sun discloses interpreting the plurality of completion forecast models based on one or more model- agnostic evaluation techniques (para. [0019], “[t]he system may perform history matching and model training and perform model evaluation based on prediction accuracy of the test data subset.” Examiner notes that performing evaluation based on prediction accuracy is model-agnostic insofar as the specifics of the model have no bearing on comparing the predicted production value to the actual production value.).
Regarding claim 3, Sun discloses wherein training of the plurality of completion forecast models comprises executing a plurality of different modeling techniques with the input dataset (para. [0019], “the system may use the training data subset, the validation data subset, and the test data subset to build and train a model using LSTM or GRU and/or CNN.” Examiner notes, LSTM, GRU, and CNN constitute distinct modeling techniques as discussed above with respect to the rejection of claim 1.).
Regarding claim 4, Sun discloses wherein the plurality of different modeling techniques is at least one of a tree-based modeling technique or a deep neural network technique (para. [0019], “the system may use the training data subset, the validation data subset, and the test data subset to build and train a model using LSTM or GRU and/or CNN.”; para. [0046], “[t]he well productivity system 201 can be implemented for forecasting well productivity accurately and efficiently, in real-time, using deep learning neural networks as described herein. In this example, the well productivity system 201 can include compute components 202, a model development engine 204, a forecast engine 206, and a storage 208. Examiner notes, convoluted neural networks (“CNN”) are a deep learning algorithm comprising a feedforward neural network as discussed above with respect to the rejection of claim 1.).
Regarding claim 6, Sun discloses displaying, on the user interface, a generated result of the optimized production forecast model based on a well completion dataset (para. [0046], “[i]n some implementations, the well productivity system 201 can also include a display device 210 for displaying data and graphical elements such as images, videos, text, simulations, and any other media or data content.” See FIG. 9 which depicts a forecasted production rate for gas 904, oil 902, and water 906 projected forward from time 908. Examiner notes the well or wells are completed insofar as the graph depicts historical production where the projection is made based on the production from the completed well thereby meeting the limitations of the claim.).
Regarding claim 7, Sun discloses recursively executing the optimized production forecast model to generate a completion prediction of a well of the well field (para. [0017], “[a] well productivity system may apply deep learning techniques such as long-short term memory (LSTM) or gated recurrent unit (GRU) and/or convolutional neural networks (CNN) to forecast well production rates and optimize corresponding development and completion strategies for one or more wells.”; para. [0076], “[a]fter the model is generated, the model may be deployed to a server computing device such as a cloud computing device including the virtual private cloud. Parameters such as operation constraints may be input and modified to determine an impact on well production responses. The well operation may be optimized based on an oil recovery factor and/or a net present value (NPV) and/or other KPI… Input constraints associated with pumping schedule… may be adjusted… In another example, a water-flooding field development plan may be optimized. Input constraints such as water injection period or amount could be adjusted.” Examiner notes that “adjusting” and “modifying” the input constraints requires generating a forecast utilizing a first operation constraint followed by generating an additional forecast using constraints which are modified from the first constraints thereby recursively executing the deployed model), the optimized production forecast model receiving measured production data from the raw field data (as disclosed with respect to claim 1, the forecast model is trained using production data and therefore has already received production data; however, the model may further take pumping schedules (e.g., related to artificial lift and therefore related to production data) or water-flooding data).
Regarding claim 8, Sun discloses [o]ne or more tangible non-transitory computer-readable storage media storing computer-executable instructions for performing a computer process on a computing system (para. [0090], “[m]ethods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can include, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or a processing device to perform a certain function or group of functions.” See also FIG. 11 and para. [0083]—[0087]), the computer process comprising:
extracting raw field data for a plurality of wells of the well field (para. [0034], “[i]n a first step, temporal and spatial data is collected. Production rates and well operation constraints and other optional temporal and spatial measurement data may be collected. The temporal and spatial data may be retrieved from available datasets from on-premise computing devices and/or cloud computing devices. A new database may be created that may store the temporal and the spatial data.”; para. [0035], “[t]he temporal data may include well production response information such as oil rates, gas rates, and water rates. The temporal data also may include well operation constraint information such as wellhead or bottomhole pressure information and choke size information. Other input data may include drilling and well completion design information (e.g., fracturing design information and pumping schedule information), well interference test information, well logs, and seismic images. The input data may be obtained from one or more sources and stored in the new database. In one example, the input data may include wellhead tubing pressure and production rates for one or more wells.”; para. [0040], “[t]he spatial features may include well trajectory information including true vertical depth, latitude, longitude, measured depth, horizontal well lateral length, multiple well spacing information, and parent-child well relationship information. In addition, the spatial features may include geological map information such as structural maps, formation top information, interpreted geomodel map information such as porosity and pressure. The spatial features also may include well log information including gamma ray, density, and resistivity information. Additionally, the spatial features may include laboratory data including routine core or special core analysis, chemical additives associated with the well including surfactant, microproppants, friction reducer, clay control, and other information.” Examiner notes that the above recited data including oil rates, gas rates, water rates, operation constraint information, and completion design information are raw field data insofar as these measurements are collected from actual measured events that occurred on the well.);
receiving, via a user interface, user-based data comprising expert domain knowledge associated with reservoir properties of the well field (para. [0036], “[a]fter the new database is created with the input data, the input data may be engineered and transformed. This may include performing exploratory data analysis and extracting preliminary insights from the input data. Features and responses may be extracted from the temporal data and features from the spatial data may be extracted based on domain knowledge in drilling, completion engineering, and reservoir and production engineering. The input data may then be scaled and divided into subsets including a training subset, a validation subset, and a test subset.”; para. [0037], “Data exploratory analysis may focus on identification of features that impact well production based on domain knowledge.”; para. [0038], “[h]istorical production rates (i.e., oil rates, gas rates, and water rates) may be used to determine gas-oil ratio information, water-oil information, and cumulative water/hydrocarbon production volume. Well operation constraints such as wellhead tubing pressure and choke size may be taken into consideration to handle complex production forecasting and well-development optimization tasks.” Examiner notes that the raw field data is assessed in view of domain knowledge pertaining to at least reservoir engineering where the assessed temporal and spatial features as recited in para. [0035] and [0040] include multiple reservoir properties.);
preprocessing the raw field data from the plurality of wells of the well field with the user-based data received from the user interface by embedding the expert domain knowledge into the raw field data through data preparation and feature engineering to generate an input dataset (see para. [0034]—[0042] which discusses gathering the raw data, analyzing the data to perform feature engineering, combining the relevant data pieces together to generate a dataset, and splitting out the dataset into test/train/validation datasets for model training) including one or more engineering features comprising at least one of fracturing design information (para. [0035] as provided above), pumping schedule information (para. [0035] and [0039]), number of stages, fluid-system selection (para. [0040]), wellhead tubing pressure (para. [0035] and [0039]), or choke size (both the raw field data and the engineered features as identified above in para. [0034]—[0036] are combined together to make a dataset. The features of the dataset read on the recited features of the claim including as recited in at least para. [0039], “oil rate, gas rate, and water rate, rate ratios such as water-oil ratio, gas-oil ratio, gas-liquid ratio, hydrocarbon-water ratio, cumulative production such as cumulative oil volume, cumulative gas volume, and cumulative water volume, well operation constraints such as tubing head pressure, casing pressure, and choke size, and other information including hydraulic fracturing pumping schedule, real-time production surveillance, and multiple well interference test information. The spatial features may be related to static data or images related to drilling and completion (i.e., well trajectory, spacing, true vertical depth), formation evaluation, well logs, cores, and laboratory measurement information.”);
training, based on the input dataset and utilizing a deep learning computing technique, a plurality of completion forecast models (para. [0019], “the system may use the training data subset, the validation data subset, and the test data subset to build and train a model using LSTM or GRU and/or CNN.” Examiner notes that long-short term memory (LSTM; e.g., a type of recurrent neural network), gated recurrent unit (GRU; e.g., a type of recurrent neural network architecture), and convolutional neural networks (CNN; e.g., a deep learning algorithm which is a feedforward neural network) are each distinct machine learning algorithms and architectures which, when utilized separately (e.g., “or”) or in combination (e.g., “and”), generate a plurality of models. As such, building a model using LSTM or GRU and/or CNN will generate a plurality of models.); and
generating an optimized production forecast model from the plurality of trained completion forecast models to adjust pumping schedule information for one or more physical field components in the well field adjustable based on the optimized production forecast model (para. [0017], “[a] well productivity system may apply deep learning techniques such as long-short term memory (LSTM) or gated recurrent unit (GRU) and/or convolutional neural networks (CNN) to forecast well production rates and optimize corresponding development and completion strategies for one or more wells.”; para. [0056], “[t]he forecast engine 206 uses the model that is continually learning and receiving input data by the model development engine 204 to generate and provide output data comprising production rates for one or more wells. The production rates may include a gas rate, an oil rate, and a water rate for a particular period of time such as one day. In addition, the forecast engine may determine averaged reservoir pressure.”; para. [0057], “[t]he forecast engine 206 can be used to provide maintenance predictions and schedule maintenance for one or more wells and can be used to provide equipment failure diagnosis for the one or more wells. The forecast engine 206 also may be used to optimize well completion in order to maximize an oil recovery factor and/or a net present value (NPV) and/or other KPI of the one or more wells.).”; para. [0058], “the forecast engine 206 may be used to modify input constraints associated with the one or more wells such as a pumping schedule of hydraulic fracture treatment, a number of stages, and types of fluid systems (i.e., slick water with friction reducer, linear gel), among other input constraints. As another example, a water flooding field development plan can be optimized by modifying input constraints by the forecast engine 206 such as a water injection period or a water amount. Other modifications and adjustments to input constraints are possible.” Examiner notes the limitation directed to the adjustments to the pumping schedule is not positively recited and is merely an intended use of the optimized production forecast model. Accordingly, the equipment adjustment is not a required step of the claims, the optimized production forecast model must merely be configured to generate outputs for such a task).
Regarding claim 9, Sun discloses the computer process further comprising: interpreting the plurality of completion forecast models based on one or more model- agnostic evaluation techniques (para. [0019], “[t]he system may perform history matching and model training and perform model evaluation based on prediction accuracy of the test data subset.” Examiner notes that performing evaluation based on prediction accuracy is model-agnostic insofar as the specifics of the model have no bearing on comparing the predicted production value to the actual production value.)..
Regarding claim 10, Sun discloses wherein training of the plurality of completion forecast models comprises executing a plurality of different modeling techniques with the input dataset (para. [0019], “the system may use the training data subset, the validation data subset, and the test data subset to build and train a model using LSTM or GRU and/or CNN.” Examiner notes, LSTM, GRU, and CNN constitute distinct modeling techniques as discussed above with respect to the rejection of claim 1.).
Regarding claim 11, Sun discloses wherein the plurality of different modeling techniques is at least one of a tree-based modeling technique or a deep neural network technique (para. [0019], “the system may use the training data subset, the validation data subset, and the test data subset to build and train a model using LSTM or GRU and/or CNN.” Examiner notes, convoluted neural networks (“CNN”) are a deep learning algorithm comprising a feedforward neural network as discussed above with respect to the rejection of claim 1.).
Regarding claim 13, Sun discloses the computer process further comprising: displaying, on the user interface, a generated result of the optimized production forecast model based on a well completion dataset (see FIG. 9 which depicts a forecasted production rate for gas 904, oil 902, and water 906 projected forward from time 908. Examiner notes the well or wells are completed insofar as the graph depicts historical production where the projection is made based on the production from the completed well thereby meeting the limitations of the claim.).
Regarding claim 14, Sun discloses recursively executing the optimized production forecast model to generate a completion prediction of a well of the well field (para. [0076], “[a]fter the model is generated, the model may be deployed to a server computing device such as a cloud computing device including the virtual private cloud. Parameters such as operation constraints may be input and modified to determine an impact on well production responses. The well operation may be optimized based on an oil recovery factor and/or a net present value (NPV) and/or other KPI… Input constraints associated with pumping schedule… may be adjusted… In another example, a water-flooding field development plan may be optimized. Input constraints such as water injection period or amount could be adjusted.” Examiner notes that “adjusting” and “modifying” the input constraints requires generating a forecast utilizing a first operation constraint followed by generating an additional forecast using constraints which are modified from the first constraints thereby recursively executing the deployed model), the optimized production forecast model receiving measured production data from the field data (as disclosed with respect to claim 1, the forecast model is trained using production data and therefore has already received production data; however, the model may further take pumping schedules (e.g., related to artificial lift and therefore related to production data) or water-flooding data).
Regarding claim 15, Sun discloses [a] system for generating a forecast model of a well field, the system comprising: a waterflood completion optimization system (para. [0058], “[a]s another example, a water flooding field development plan can be optimized by modifying input constraints by the forecast engine 206 such as a water injection period or a water amount.”) having at least one processor (processor 1110, see FIG. 11; para. [0090], “[m]ethods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can include, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or a processing device to perform a certain function or group of functions.” See also FIG. 11 and para. [0083]—[0087]) configured extract raw field data for a plurality of wells of the well field (para. [0034], “[i]n a first step, temporal and spatial data is collected. Production rates and well operation constraints and other optional temporal and spatial measurement data may be collected. The temporal and spatial data may be retrieved from available datasets from on-premise computing devices and/or cloud computing devices. A new database may be created that may store the temporal and the spatial data.”; para. [0035], “[t]he temporal data may include well production response information such as oil rates, gas rates, and water rates. The temporal data also may include well operation constraint information such as wellhead or bottomhole pressure information and choke size information. Other input data may include drilling and well completion design information (e.g., fracturing design information and pumping schedule information), well interference test information, well logs, and seismic images. The input data may be obtained from one or more sources and stored in the new database. In one example, the input data may include wellhead tubing pressure and production rates for one or more wells.”; para. [0040], “[t]he spatial features may include well trajectory information including true vertical depth, latitude, longitude, measured depth, horizontal well lateral length, multiple well spacing information, and parent-child well relationship information. In addition, the spatial features may include geological map information such as structural maps, formation top information, interpreted geomodel map information such as porosity and pressure. The spatial features also may include well log information including gamma ray, density, and resistivity information. Additionally, the spatial features may include laboratory data including routine core or special core analysis, chemical additives associated with the well including surfactant, microproppants, friction reducer, clay control, and other information.” Examiner notes that the above recited data including oil rates, gas rates, water rates, operation constraint information, and completion design information are raw field data insofar as these measurements are collected from actual measured events that occurred on the well.” Examiner notes the limitation directed to the adjustments to the pumping schedule is not positively recited and is merely an intended use of the optimized production forecast model. Accordingly, the equipment adjustment is not a required step of the claims, the optimized production forecast model must merely be configured to generate outputs for such a task);
receive, via a user interface, user-based data comprising expert domain knowledge associated with reservoir properties of the well field (para. [0036], “[a]fter the new database is created with the input data, the input data may be engineered and transformed. This may include performing exploratory data analysis and extracting preliminary insights from the input data. Features and responses may be extracted from the temporal data and features from the spatial data may be extracted based on domain knowledge in drilling, completion engineering, and reservoir and production engineering. The input data may then be scaled and divided into subsets including a training subset, a validation subset, and a test subset.”; para. [0037], “Data exploratory analysis may focus on identification of features that impact well production based on domain knowledge.”; para. [0038], “[h]istorical production rates (i.e., oil rates, gas rates, and water rates) may be used to determine gas-oil ratio information, water-oil information, and cumulative water/hydrocarbon production volume. Well operation constraints such as wellhead tubing pressure and choke size may be taken into consideration to handle complex production forecasting and well-development optimization tasks.” Examiner notes that the raw field data is assessed in view of domain knowledge pertaining to at least reservoir engineering where the assessed temporal and spatial features as recited in para. [0035] and [0040] include multiple reservoir properties.);
preprocess the raw field data from the plurality of wells of the well field with the user-based data received from the user interface by embedding the expert domain knowledge into the raw field data through data preparation and feature engineering to generate an input dataset (see para. [0034]—[0042] which discusses gathering the raw data, analyzing the data to perform feature engineering, combining the relevant data pieces together to generate a dataset, and splitting out the dataset into test/train/validation datasets for model training) including one or more engineering features comprising at least one of fracturing design information (para. [0035] as provided above), pumping schedule information (para. [0035] and [0039]), number of stages, fluid-system selection (para. [0040]), wellhead tubing pressure (para. [0035] and [0039]), or choke size (both the raw field data and the engineered features as identified above in para. [0034]—[0036] are combined together to make a dataset. The features of the dataset read on the recited features of the claim including as recited in at least para. [0039], “oil rate, gas rate, and water rate, rate ratios such as water-oil ratio, gas-oil ratio, gas-liquid ratio, hydrocarbon-water ratio, cumulative production such as cumulative oil volume, cumulative gas volume, and cumulative water volume, well operation constraints such as tubing head pressure, casing pressure, and choke size, and other information including hydraulic fracturing pumping schedule, real-time production surveillance, and multiple well interference test information. The spatial features may be related to static data or images related to drilling and completion (i.e., well trajectory, spacing, true vertical depth), formation evaluation, well logs, cores, and laboratory measurement information.”);
train a plurality of completion forecast models using a deep learning computing technique and based on the input dataset (para. [0019], “the system may use the training data subset, the validation data subset, and the test data subset to build and train a model using LSTM or GRU and/or CNN.” Examiner notes that long-short term memory (LSTM; e.g., a type of recurrent neural network), gated recurrent unit (GRU; e.g., a type of recurrent neural network architecture), and convolutional neural networks (CNN; e.g., a deep learning algorithm which is a feedforward neural network) are each distinct machine learning algorithms and architectures which, when utilized separately (e.g., “or”) or in combination (e.g., “and”), generate a plurality of models. As such, building a model using LSTM or GRU and/or CNN will generate a plurality of models.); and
generating an optimized production forecast model from the plurality of trained completion forecast models to adjust pumping schedule information for one or more physical field components in the well field adjustable based on the optimized production forecast model (para. [0017], “[a] well productivity system may apply deep learning techniques such as long-short term memory (LSTM) or gated recurrent unit (GRU) and/or convolutional neural networks (CNN) to forecast well production rates and optimize corresponding development and completion strategies for one or more wells.”; para. [0056], “[t]he forecast engine 206 uses the model that is continually learning and receiving input data by the model development engine 204 to generate and provide output data comprising production rates for one or more wells. The production rates may include a gas rate, an oil rate, and a water rate for a particular period of time such as one day. In addition, the forecast engine may determine averaged reservoir pressure.”; para. [0057], “[t]he forecast engine 206 can be used to provide maintenance predictions and schedule maintenance for one or more wells and can be used to provide equipment failure diagnosis for the one or more wells. The forecast engine 206 also may be used to optimize well completion in order to maximize an oil recovery factor and/or a net present value (NPV) and/or other KPI of the one or more wells.).”; para. [0058], “the forecast engine 206 may be used to modify input constraints associated with the one or more wells such as a pumping schedule of hydraulic fracture treatment, a number of stages, and types of fluid systems (i.e., slick water with friction reducer, linear gel), among other input constraints. As another example, a water flooding field development plan can be optimized by modifying input constraints by the forecast engine 206 such as a water injection period or a water amount. Other modifications and adjustments to input constraints are possible.”).
Regarding claim 16, Sun discloses wherein the user-based data is received from a user interface presented by a user device (para. [0048], “well productivity system 201 can be part of, or implemented by, one or more computing devices, such as one or more servers, one or more personal computers, one or more processors, one or more mobile devices (for example, a smartphone, a camera, a laptop computer, a tablet computer, a smart device, etc.), and/or any other suitable electronic devices.”; para. [0086], “[t]o enable user interaction with the computing device architecture 1100, an input device 1145 can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth… In some instances, multimodal computing devices can enable a user to provide multiple types of input to communicate with the computing device architecture 1100. The communications interface 1140 can generally govern and manage the user input and computing device output.”).
Regarding claim 17, Sun discloses wherein the user interface is configured to present a generated result of the optimized production forecast model based on a well completion dataset (para. [0046], “[i]n some implementations, the well productivity system 201 can also include a display device 210 for displaying data and graphical elements such as images, videos, text, simulations, and any other media or data content.” See FIG. 9 which depicts a forecasted production rate for gas 904, oil 902, and water 906 projected forward from time 908. Examiner notes the well or wells are completed insofar as the graph depicts historical production where the projection is made based on the production from the completed well thereby meeting the limitations of the claim.).
Regarding claim 18, Sun discloses wherein training of the plurality of completion forecast models comprises executing a plurality of different modeling techniques with the input dataset (para. [0019], “the system may use the training data subset, the validation data subset, and the test data subset to build and train a model using LSTM or GRU and/or CNN.” Examiner notes, LSTM, GRU, and CNN constitute distinct modeling techniques as discussed above with respect to the rejection of claim 1.).
Regarding claim 20, Sun discloses wherein waterflood completion optimization system recursively executes the optimized production forecast model to generate a completion prediction of a well of the well field (para. [0076], “[a]fter the model is generated, the model may be deployed to a server computing device such as a cloud computing device including the virtual private cloud. Parameters such as operation constraints may be input and modified to determine an impact on well production responses. The well operation may be optimized based on an oil recovery factor and/or a net present value (NPV) and/or other KPI… Input constraints associated with pumping schedule… may be adjusted… In another example, a water-flooding field development plan may be optimized. Input constraints such as water injection period or amount could be adjusted.” Examiner notes that “adjusting” and “modifying” the input constraints requires generating a forecast utilizing a first operation constraint followed by generating an additional forecast using constraints which are modified from the first constraints thereby recursively executing the deployed model), the optimized production forecast model receiving measured production data from the field data (as disclosed with respect to claim 1, the forecast model is trained using production data and therefore has already received production data; however, the model may further take pumping schedules (e.g., related to artificial lift and therefore related to production data) or water-flooding data).
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.
Claim(s) 5, 12, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Published US Patent Application to Sun et al., hereinafter “Sun” (US 20210010351 A1) as applied to claims 1, 8, and 15 above, and further in view of Published US Patent Application to Despinois et al., hereinafter “Despinois,” (US 20240133293 A1).
Regarding claim 5, while Sun at para. [0019] discloses “[t]he system may perform… model evaluation based on prediction accuracy of the test data subset,” Sun may not expressly disclose expanding the raw field data through one of a scatter plot of the raw field data or a box plot of the raw field data. However, generating a scatter plot (e.g., or cross plot) which plots an actual production value (e.g., raw production data categorized into the test dataset) versus a predicted production value (e.g., as generated by the model) is one manner in which the prediction accuracy of a model is assessed. The foregoing is taught by Despinois which is in the same field of endeavor as the instant application insofar as it is directed to generating machine-learning-based predictive models for hydrocarbon extraction operations. Specifically, Despinois at para. [1037] teaches “FIG. 9 presents a scatter plot on the validation set between actual and predicted concentrations. The points below the red line are underestimated and those above are overestimated. The distribution of points shows that the prediction model correctly estimates the real concentrations. The conical shape of the distribution shows that the error increases for higher lithium concentrations. This is due to the under-representation of wells with high lithium concentrations in the dataset, see class A in FIG. 4.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have utilized the scatter plot analysis technique as disclosed by Despinois as one of the specific methods for evaluating the model accuracy as generically disclosed by Sun. The replacement of the generic method disclosed by Sun for the specific method as taught by Despinois would render the predictable result of assessing which outcomes from the model were overestimated and/or underestimated relative to the actual production data (e.g., raw data).
Regarding claim 12, while Sun at para. [0019] discloses “[t]he system may perform… model evaluation based on prediction accuracy of the test data subset,” Sun may not expressly disclose expanding the raw field data through one of a scatter plot of the raw field data or a box plot of the raw field data. However, generating a scatter plot (e.g., or cross plot) which plots an actual production value (e.g., raw production data categorized into the test dataset) versus a predicted production value (e.g., as generated by the model) is one manner in which the prediction accuracy of a model is assessed. The foregoing is taught by Despinois which is in the same field of endeavor as the instant application insofar as it is directed to generating machine-learning-based predictive models for hydrocarbon extraction operations. Specifically, Despinois at para. [1037] teaches “FIG. 9 presents a scatter plot on the validation set between actual and predicted concentrations. The points below the red line are underestimated and those above are overestimated. The distribution of points shows that the prediction model correctly estimates the real concentrations. The conical shape of the distribution shows that the error increases for higher lithium concentrations. This is due to the under-representation of wells with high lithium concentrations in the dataset, see class A in FIG. 4.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have utilized the scatter plot analysis technique as disclosed by Despinois as one of the specific methods for evaluating the model accuracy as generically disclosed by Sun. The replacement of the generic method disclosed by Sun for the specific method as taught by Despinois would render the predictable result of assessing which outcomes from the model were overestimated and/or underestimated relative to the actual production data (e.g., raw data).
Regarding claim 19, while Sun at para. [0019] discloses “[t]he system may perform… model evaluation based on prediction accuracy of the test data subset,” Sun may not expressly disclose wherein waterflood completion optimization system expands the raw field data through one of a scatter plot of the raw field data or a box plot of the raw field data. However, generating a scatter plot (e.g., or cross plot) which plots an actual production value (e.g., raw production data categorized into the test dataset) versus a predicted production value (e.g., as generated by the model) is a known method for which the prediction accuracy of a model is assessed. The foregoing is taught by Despinois which is in the same field of endeavor as the instant application insofar as it is directed to generating machine-learning-based predictive models for hydrocarbon extraction operations. Specifically, Despinois at para. [1037] teaches “FIG. 9 presents a scatter plot on the validation set between actual and predicted concentrations. The points below the red line are underestimated and those above are overestimated. The distribution of points shows that the prediction model correctly estimates the real concentrations. The conical shape of the distribution shows that the error increases for higher lithium concentrations. This is due to the under-representation of wells with high lithium concentrations in the dataset, see class A in FIG. 4.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have utilized the scatter plot analysis technique as disclosed by Despinois as one of the specific methods for evaluating the model accuracy as generically disclosed by Sun. The replacement of the generic method disclosed by Sun for the specific method as taught by Despinois would render the predictable result of assessing which outcomes from the model were overestimated and/or underestimated relative to the actual production data (e.g., raw data).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 URSULA NORRIS whose telephone number is (703)756-4731. The examiner can normally be reached Monday to Friday, 7 AM to 4 PM.
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, TARA SCHIMPF can be reached at 571-270-7741. 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.
/U.L.N./Examiner, Art Unit 3676
/TARA SCHIMPF/Supervisory Patent Examiner, Art Unit 3676
Prosecution Insights