ASSISTED TASK MINING USING LARGE LANGUAGE MODELS

§101 §102 §103 §112

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 . 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 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. DETAILED ACTION This Final Office Action is in response Applicant communication filled on 08/20/2026. Status of Claims Claims 1,3,4,8,10,11,15,17,18 were amended by Applicant’s 08/20/2026 amendment. Claims 2,9,16 have been cancelled by Applicant’s 08/20/2026 amendment. Claims 1,3-8,10-15 and 17-20 are currently pending and have been rejected as follows. IDS The information disclosure statement filed on 05/29/2026 complies with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 and is considered by the Examiner. Response to Amendments / Arguments Applicant’s 08/20/2026 amendment necessitated new grounds of rejection in this action. I. Response to Applicant’s rebuttal on 35 USC 112 (a) and (b) rejections - dependent claims 6,13,20 - Remarks 08/20/2026 p.7 ¶3-¶7 argues that DOT language grammar in dependent claims 6,13,20 is a recognized term of art and acronym for DAG (directed acyclic graph) of tomorrow, as explicitly defined in the claims and at Original Specification ¶ [0032], with the Applicant further citing https://en.wikipedia.org/wiki/DOT_(graph_description_ language) as evidence for its ordinary and customary meaning. Accordingly, Applicant argues that the term DOT language grammar in claims 6,13,20 refers to a graph description language and is not a temporal limitation covering unsupported subject matter for a date subsequent to the filing date. Examiner fully considered the argument but respectfully disagrees finding it unpersuasive. Examiner points to MPEP 2111 III. ¶2 noting that “the best source for determining the meaning of a claim term is the specification – the greatest clarity is obtained when the specification serves as a glossary for the claim terms”. Here, since the Original Specification does not provide such clarity, the Applicant needed to rely on an external source, namely Wikipedia.org. The Applicant’s reliance on Wikipedia.org is problematic given that the USPTO restricted the use of Wikipedia in 2006 due to concerns over its open-editing, fluid nature, and lack of anonymous author verification, as evidenced by at least the following publication incorporated herein USPTO blocks use of Wikipedia, October 9th, 2006. Yet, even accepting, in the arguendo, the Wikipedia source, or any other source for that matter, as evidence for the ordinarily and customary meaning for expression directed acyclic graph of tomorrow, this would not rebut the 112 grounds of rejection, because reliance on a ordinarily and customary term, under the claim interpretation test MPEP 2111, is not necessarily an exemption or carte blanche from clearly pointing out to the metes and bounds of the claimed invention, as required by MPEP 2173 and enunciated by Non-Final Act 05/27/2026 p.2-p.3. Here, when tested per MPEP 2171 ¶3, the purported ordinary and customary, directed acyclic graph of tomorrow, still fails to clearly inform the public of the boundaries of what would constitute infringement of a hypothetical patent granted on the current Application. More specifically, the metes and bounds tests reveals at least four problematic scenarios: (i) First, it is uncertain which future subject matter of a directed acyclic graph of tomorrow, AFTER the filling date of the current Application, would infringe upon the directed acyclic graph of tomorrow covered by the hypothetical patent granted on the current Applicant, and which future subject matter by another would not infringe upon the directed acyclic graph of tomorrow covered by the hypothetical patent of the current Applicant. (ii) Second, a hypothetical practitioner having used a directed acyclic graph of tomorrow, BEFORE the effective filling date of the current Application, would not clearly ascertain of the metes and bounds of what would constitute infringement of the hypothetical patent granted from the current Application. (iii) Third, a hypothetical practitioner having been hypothetically licensed the subject matter of a directed acyclic graph of tomorrow, resulting from the issuance of a hypothetical patent of the current Application, would not clearly ascertain of the metes and bounds of what would constitute infringement of the subject matter of the licensed patent granted from the current Application. (iii) Fourth, and conversely, a hypothetical Applicant having been granted a hypothetical patent with its Application filled BEFORE the effective filling date of the current Application, would not clearly assesses the metes and bounds of the subject matter directed acyclic graph of tomorrow, to clearly ascertain whether or not the current’s Applicant’s own recitation of a directed acyclic graph of tomorrow, would infringe upon the EARLIER filled subject matter of the hypothetical patent granted to the hypothetical Applicant other than the current Applicant. Based on the preponderance of evidence and the rationales above, the Examiner submits that expression directed acyclic graph of tomorrow still fails the MPEP 2173 test and as such the Applicant’s rebuttal argument is found unpersuasive. II. Response to Applicant’s rebuttal on 35 USC 101 rejection Step 2A prong one: Remarks 08/20/2026 p. 9 -p.10 ¶2 argues that amended independent claim 1 does not only provide for the evaluation or analysis of information, but it also provides for the transformation of unstructured natural language descriptions into structured definitions of a graph using a language model, and does not fall within mathematical concept, a certain method of organizing human activity, or a mental process. Step 2A prong one argument has been fully considered but is unpersuasive. Non-Final Act 05/27/2026 p.4 reincorporated herein, followed on the broadest reasonable interpretation of MPEP 2111 test, and found that given the breadth of the claims, they recite, describe or set forth the abstract assisted task mining, as summarized by the Application’s own Title and read in light of the Original Specification ¶ [0002] 1st sentence as : “Task mining is the process of automatically capturing and analyzing user indications with a computer system to understand how tasks are performed in real-world scenarios”. Thus the current claims still pertain to cognitive processes of understanding or judgment (MPEP 2106.04(a)(2) III ¶2) of how tasks are performed in real-world scenarios based on equally abstract processes of capturing and analyzing user indications, given the breath of the claims as capturing or “receiving 1) a natural language description of a workflow and 2) a description of one or more APIs (application programming interfaces) for performing the workflow” and “receiving a natural language description of one or more modifications to the workflow”, which are observed for subsequent computer-aided evaluation of “generating a structured definition of a graph of the workflow using a language model based on the natural language description of the workflow and the description of the one or more APIs, one or more nodes in the structured definition of the graph of the workflow being mapped to at least one of the one or more APIs” and “modifying the structured definition of the graph of the workflow using the language model based on the natural language description of the one or more modifications to the workflow”. Thusly, when tested per MPEP 2106.04(a)(2) III ¶2, the Examiner finds that such capturing, analyzing and understanding are examples of observations, evaluations and judgements, which according to MPEP 2106.04(a)(2) III ¶2, still set forth the abstract exception of mental processes. Further, as explained by MPEP 2106.04(a)(2) III C #2, #3, the fact that such processes are computer-aided as tools (MPEP 2106.04(a)(2) III C #3) and are pertinent to a computer environment (MPEP 2106.04(a)(2) III C #2), does not necessarily preclude such processes to set forth the abstract exception. Here, use of “language model” at Claims 1,2,5,7-9,12,14-16,19 can be argued as an example of such as tool or aid (MPEP 2106.04(a)(2) III C #3) for “generating a structured definition” [thus cognition] “of a graph of the workflow” (independent Claims 1,8,15, dependent Claims 5,12,19) and “modifying the structured definition of the graph of the workflow” “based on the natural language description” [or cognition] of the modifications to the workflow” (now independent Claims 1,8,16). Similarly, recitations “wherein the modifications to the workflow comprise an addition of one or more steps to the workflow” (dependent Claims 3,10,17) and “wherein the modifications to the workflow comprise highlighting one or more steps of the workflow” (dependent Claims 4,11,18) fall within the implementation by computer aids, if not simply by pen and paper, to “add” (dependent Claims 3,10,17) and “highlight” (dependent Claims 4,11,18) “of the workflow”. Also here, “description of one or more APIs” at independent Claims 1,8,15 and dependent Claims 5,12,19, can be argued as an example of a computer environment (MPEP 2106.04(a)2 III C#2) upon which the abstract process is performed. Thus here, neither the “description of one or more APIs”, nor the recitation of “using a language model based on the natural language description of the workflow” does preclude the current claims to recite, describe or set forth the computer-aided mental processes. Thus, the claims do recite, or at a minimum describe or set forth the abstract exception. Next with respect to the Applicant’s alleged transformation raised at Remarks 08/20/2026 p.9, the Examiner reminds the Applicant that the “101 inquiry must focus on language of Asserted Claims themselves” as in “Synopsys, Inc. v Mentor Graphics Corp, U.S. Court of Appeals Federal Circuit, No 2015-1599, October 17 2016 2016 BL 344522 839 F3d 1138” citing “Accenture Global Servs., GmbH PNG media_image1.png 1 1 media_image1.png Greyscale v PNG media_image1.png 1 1 media_image1.png Greyscale . Guidewire Software, Inc. 728 PNG media_image1.png 1 1 media_image1.png Greyscale F.3d PNG media_image1.png 1 1 media_image1.png Greyscale 1336, 1345 108 USPQ2d 1173 Fed Cir. 2013: admonishing that the important inquiry for a 101 analysis is to look to the claim”, citing “Content Extraction & Transmission LLC PNG media_image1.png 1 1 media_image1.png Greyscale v. PNG media_image1.png 1 1 media_image1.png Greyscale Wells Fargo Bank Nat’l Ass’n 776 PNG media_image1.png 1 1 media_image1.png Greyscale F3d PNG media_image1.png 1 1 media_image1.png Greyscale 1343, 1346 113 USPQ2d 1354 (Fed. Cir. 2014): We focus here on whether the claims of the asserted patents fall within the excluded category of abstract ideas”, cert. denied, 136 S Ct 119, 193 L. Ed. 2d 208 2015). This is consistent with MPEP 2103 I.C stating that “claims define the property rights provided by patent, thus require careful scrutiny. The goal of claim analysis is to identify boundaries of protection sought by applicant and to understand how claims relate to and define what applicant indicated is the invention. USPTO personnel must first determine the scope of a claim by thoroughly analyzing the language of claim before determining if claim complies with each statutory requirement for patentability”. Simply said “[T]he name of the game is the claim”. This finding is of paramount importance because here, the purported transformation of unstructured natural language descriptions into structured definitions of a graph using a language model, as alleged by Applicant Remarks 08/20/2026 p.9, is not recited in the actual claims. At most the independent claims 1,8,15 recite manipulations of “the structured definition of the graph of the workflow” as evidenced by the two limitations of: “generating a structured definition of a graph of the workflow using a language model based on the natural language description of the workflow and the description of the one or more APIs” and “modifying the structured definition of the graph of the workflow using the language model based on the natural language description of the one or more modifications to the workflow”. Yet MPEP 2106.05(c) ¶5 is clear that manipulation of basic constructs has not been deemed by the Courts as patent eligible transformation. Therefore here, far from a patent eligible transformation, the argued claims merely recite abstract or manipulative forms of information in accordance with the two limitations of “generating” and “modifying” “the structured definition” based on various “descriptions”. Such manipulations fall well within the cognitive capabilities of observation, evaluation and judgment as enumerated by MPEP 2106.04(a)(2) II ¶2, and implementable either manually or, if not manually, still implementable using aids such as by use of pen and paper, in drawing and modifying the drawing of a graph based on descriptions at the argued limitations of independent claims 1,8,15. However, MPEP 2106.04(a)(2) III B is clear that use of pen and paper does not preclude the claims to still recite, describe or set forth the abstract exception. Additionally, or alternatively such manipulations are still implementable using computer aids, such as computer aided design CAD, in drawing and modifying the drawing of a graph based on descriptions at the argued limitations of independent claims 1,8,15. Yet, MPEP 2106.04(a)(2) III C #1,#2,#3 is clear that using the computer aids as tools or computer environments, also does not preclude the claims to still recite, describe or set forth the abstract exception. Equally important, the fact that the various descriptions used in the two limitations of “generating” and “modifying” “the structured definition”, happed to be “natural language description of the workflow and the description of the one or more APIs”, does not automatically render said claims less abstract and eligible, because, they would at most represent a mere computer environment, or context of such computer environment, upon which the mental processes are being performed, and MPEP 2106.04(a)(2) III C #2 is clear that situations where the mental processes are performed in a computer environment are still considered to recite the broad abstract grouping of mental processes of MPEP 2106.04(a)(2) III. Accordingly, there is a preponderance of legal evidence showing that the claims still recite, or at a minimum describe or set forth the abstract exception, and, as such, the Applicant’s Step 2A prong one rebuttal argument is found unpersuasive. Step 2A prong two: Remarks 08/20/2026 p.10 ¶5 argues the claims are integrated into the practical application of an improvement to task mining systems for automatically visualizing and modifying workflows. Specifically, Remarks 08/20/2026 p.11 ¶1 argues the present invention provides for a technical solution to the technical problem of automatically generating and modifying a workflow, by providing for a language model that is not merely used as a generic tool for data analysis, but performs a specific transformation of a natural language description of the workflow that is in a format that is conceptually understandable by a user into a structured definition of a graph of the workflow that is in a format that is computer readable enabling various computer operations and processing to be performed automatically on the workflow, such as, e.g., visualizing the workflow or modifying the workflow, by a language model using natural language input describing, for example, the modifications to the workflow in similar manner to Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016). Specifically, Remarks 08/20/2026 p.11 ¶ 2 argues that such improvements are reflected in independent Claim 1 by: - “generating a structured definition of a graph of the workflow using a language model based on the natural language description of the workflow and the description of the one or more APis, one or more nodes in the structured definition of the graph of the workflow being mapped to at least one of the one or more APIs” and - “modifying the structured definition of the graph of the workflow using the language model based on the natural language description of the one or more modifications to the workflow”. Step 2A prong two argument has been fully considered but is unpersuasive. Examiner reincorporates herein all findings and rationales at the prior prong one above. Examiner resubmits that here, the purported transformation of unstructured natural language descriptions into structured definitions of a graph using a language model, is not recited in the actual claims. At most the independent claims 1,8,15 recite manipulations of “the structured definition of the graph of the workflow” such as: “generating a structured definition of a graph of the workflow using a language model based on the natural language description of the workflow and the description of the one or more APIs” and “modifying the structured definition of the graph of the workflow using the language model based on the natural language description of the one or more modifications to the workflow” as now also emphasized at Remarks 08/20/2026 p.11 ¶2. Yet, MPEP 2106.05(c) ¶5 is clear that manipulation of basic constructs has not been deemed by the Courts as patent eligible transformation. Thus here, far from a patent eligible transformation, said claims merely recite “generating” and “modifying” “the structured definition” based on various “descriptions”, which fall well within the cognitive capabilities of observation, evaluation and judgment as enumerated by the abstract grouping of at MPEP 2106.04(a)(2) II ¶2, implementable using aids such as the computer aids of MPEP 2106.04(a)(2) III C, if not outright performable manually by pen and paper, when equally tested per MPEP 2106.04(a)(2) III B. Equally important, the fact that such descriptions, happed to be “based on the natural language description of the workflow and the description of the one or more APIs”, would at most represent a mere computer environment, or the context of a computer environment upon which the mental processes are being performed. Yet, MPEP 2106.04(a)(2) III C #2 is clear that situations where the mental processes are performed in a computer environment are still considered to recite the broad abstract grouping of mental processes. It then follows that here, any purported improvement in such processes as alleged by Applicant at Remarks 08/20/2026 p.11 would correspond to an improvement in the abstract idea. Yet, MPEP 2106.05(a) is clear that mere automation of manual processes, including accelerating a process of analyzing audit log data when the increased speed comes from the capabilities of a general-purpose computer, are insufficient to show improvement in computer functionality. This finding is especially important because, as highlighted by MPEP 2106.05(a) II ¶2, an improvement in the abstract idea itself is not improvement in technology. Similarly, MPEP 2106.04 I. cites Myriad, 569 U.S. at 591, 106 USPQ2d at 1979: to state that even a “groundbreaking, innovative, or even brilliant discovery does not by itself satisfy the §101 inquiry”. Examiner further investigates “Myriad”, cited by MPEP 2106.04 I. above, and finds that the “Myriad” rationale was also corroborated in “SAP Am, Inc v InvestPic” which, at its turn, was cited by MPEP 2106.04(a)(2) I.C(i). Examiner digs deeper, into the Court’s rationale in “SAP, and again finds that “even if one assumes that the techniques claimed are groundbreaking, innovative, or even brilliant those features are not enough for eligibility because their innovation is innovation in ineligible subject matter. An advance of that nature is ineligible for patenting”. Specifically, the patent at issue in SAP proposed utilized resampled statistical methods for data analysis which did not assume a normal probability distribution. One such method is a bootstrap method, which estimated the distribution of data in a pool (a sample space) by repeated sampling of the data in the pool. Data samples were drawn from the sample space with replacement: samples where drawn from the sample space and then returned to the pool before the next sample is drawn. SAP also described using a bias parameter to specify degree of randomness in resampling process. Examiner reasons that, since the generation and modification of spaces of data pools, which were structured based on bias parameters and bootstrap descriptors were ineligible in SAP, it follows that here the analogous manipulations of “the structured definition of the graph of the workflow” by “generating a structured definition of a graph of the workflow using a language model based on the natural language description of the workflow and the description of the one or more APIs” and “modifying the structured definition of the graph of the workflow using the language model based on the natural language description of the one or more modifications to the workflow” as argued by Applicant at Remarks 08/20/2026 p.11 ¶2, would follow a similar ineligible path. Even, if considered in the arguendo as part of the additional elements, at Step 2A prong two of analysis, they would still represent mere invocation of computer components to apply existing or abstract processes, or, would represent a technological environment upon which the manipulation or combination of collecting, analyzing and displaying certain results of the collection and analysis is performed. None of these scenarios as respectively tested on MPEP 2106.05(f)(2) and MPEP 2106.05(h)(vi) would integrate the abstract exception into a practical application. Finally, with respect to Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016), as raised by Applicant at Remarks 08/20/2026 p.11 ¶1, the Examiner finds that the Applicant’s argued limitations are irreconcilably different than those found eligible by the Federal Circuit in Enfish. This is because at no point do the current claims provide anything remotely analogous to the classification of structures for repeated extraction and the importing as required precursors to archive a self-referential technological improvement, as was the case in Enfish, 822 F.3d 1327,1336,118 USPQ2d 1684, 1689 (Fed. Cir. 2016), as cited by MPEP 2106.04(a). Based on the above findings the Examiner submits that here, there is a preponderance of legal evidence showing that the claims still recite, or at a minimum set forth or describe the abstract exception, with no additional computer-based elements capable to integrate the abstract exception into a practical application. Thus, the Step 2A prong two argument is unpersuasive. Step 2B: Remarks 08/20/2026 p. 12 ¶3 relies upon the same limitations of: “generating a structured definition of a graph of the workflow using a language model based on the natural language description of the workflow and the description of the one or more APIs, one or more nodes in the structured definition of the graph of the workflow being mapped to at least one of the one or more APIs" and “modifying the structured definition of the graph of the workflow using the language model based on the natural language description of the one or more modifications to the workflow” of independent Claims 1,8,15 to now argue that they are not taught by the prior art, and thus, are not well understood, routine, or conventional. Further, Remarks 08/20/2026 p.12 ¶4 argues that the amended claims provide for an inventive concept for automatically translating a natural language description of a workflow that is in a format that is conceptually understandable by a user into a structured definition of a graph of the workflow that is in a format that is computer readable. The structured definition of the graph enables the modifying of the workflow by a natural language description of one or more modifications to the workflow. As such, it is argued that the claimed combination of elements provides a technological solution that is qualitatively different from merely organizing or presenting information. Step 2B argument has been fully considered but is unpersuasive. As per the Applicant’s allegation at Remarks 08/20/2026 p.12 ¶3 that the limitations of “generating” and “modifying” “the structured definition of the graph” are not well understood, routine, or conventional, because they are not taught by the prior art, the Examiner responds, in arguendo, that the argued limitations, even if purportedly novel (35 USC 102) and non-obviousness (35 USC 103), they would still pertain to features that are, for the most part, abstract, and thus incapable to integrate the abstract exception into a practical application or provide significantly more than what was already identified as the abstract exception. Simply said, these argued feature(s) do not render the claims patent eligible (35 USC 101) no matter of their purported novelty (35 USC 102) and non-obviousness (35 USC 103) over the prior art. See for example MPEP 2106.04 I ¶5, 3rd sentence citing Mayo, 566 U.S. 71, 101 USPQ2d at 1965); Flook, 437 U.S. at 591-92, 198 USPQ2d at 198 the novelty…is not a determining factor at all. Also MPEP 210.604(a)(2) II has established that building blocks of innovation, remain fundamental, not in the sense of whether or not they are old or well known, but rather as ineligible subject matter. Here, given the breadth of the claims and the broadest reasonable interpretation, as tested per MPEP 2111, the Examiner finds that the two limitations argued by Remarks 08/20/2026 p. 12 ¶3, would represent such building blocks of ineligible subject matter, regardless of whether or not their underlining solution would be old, well-known, as taught by the prior art. Simply said, as demonstrated by MPEP 2106.04(d)(1), “improvement in the judicial exception itself is not an improvement in technology”. Similarly, MPEP 2106.04 I. cites “Myriad, 569 U.S. at 591, 106 USPQ2d at 1979” to underline that even a “groundbreaking, innovative, or even brilliant discovery does not by itself satisfy the §101 inquiry" as corroborated by “SAP Am, Inc v InvestPic, LLC, No 2017-2081, 2018 BL 275354 (Fed. Cir.Aug.02, 2018)”: “even if one assumes that the techniques claimed are groundbreaking, innovative, or even brilliant those features are not enough for eligibility because their innovation is innovation in ineligible subject matter”. “An advance of that nature is ineligible for patenting”. This finding was corroborated by “Versata Dev Grp, Inc v SAP Am, Inc 115 USPQ2d 1681 Fed Cir 2015” undelaying the difference between improvement to the abstract exception versus improvement to actual technology. MPEP 2106.04. As per the Applicant’s argument at Remarks 08/20/2026 p.12 ¶4 argues that the amended claims provide for an inventive concept for automatically translating a natural language description of a workflow that is in a format that is conceptually understandable by a user into a structured definition of a graph of the workflow that is in a format that is computer readable, the Examiner reincorporates all findings and rationales above showing that here, the purported translating or transformation of unstructured natural language descriptions into structured forma, is not recited in the actual claims. At most the generating and modifying limitations of independent Claims 1,8,15, would provide for a manipulation of basic constructs, which, as revealed by MPEP 2106.05(c) ¶5, has not been deemed by the Courts as patent eligible transformation. In conclusion, given the breath of the claims and the broadest reasonable interpretation, the Examiner finds that the claims still recite, or at minimum set forth or describe the abstract exception, with no additional computer-based elements capable to integrate the abstract exception into a practical application or provide significantly more than what was already identified as the abstract exception. Accordingly, the Step 2B argument is unpersuasive. III. Response to Applicant’s rebuttal on 35 USC 102 and 103 rejections - independent Claims 1,8,15 - Prior art argument 1: Remarks 08/20/2026 p.14 ¶3-p.15 ¶1 argues Hattami US 20230385026 A1 disclose a sequence of steps in a text format but is silent on a “graph” Prior art argument 1 has been fully considered but is unpersuasive. MPEP 2131 is clear: While “the elements must be arranged as required by the claim, “this is not an ipsissimis verbis test, that is identity of terminology is not required”1. First, as an issue of claim construction and claim interpretation, Examiner applies the broadest reasonable interpretation per MPEP 2111, and interprets the term “graph” as contested by Applicant above to include but not limited to synonyms such as : diagram, drawing, illustration, plot, table ,chart, figure, flow, workflow, or any other forms of visual or graphical representation Based on such claim construction and interpretation, the examiner submits that Hattami’s Figs.2,3,5 extracted below teaches the term “graph” as contested by Applicant above. PNG media_image2.png 852 702 media_image2.png Greyscale PNG media_image3.png 622 922 media_image3.png Greyscale Hattami Fig.3 (left) and Fig.5 (right) in support of rejection arguments PNG media_image4.png 998 730 media_image4.png Greyscale Hattami Fig.2 in support of rejection arguments Hattami ¶ [0016] 1st-2nd,8th,9th sentences: flow description 120 is mandatory text input that describes either entire, partial flow, or single step (e.g., a single action in a flow). Flow description 120 comprises a step description that can be a known description or any other semantically equivalent description (e.g., Create record and Add a record to a table will both generate the same flow step. In various embodiments, input aggregator 102 determines a flow description based on flow description 120 and the output of flow-to-text converter 104 and combines this with context information that is a text output of context-to-text converter 106. In some embodiments, there is a specified order [or structure] in which the information is combined because starting with the elements that have more influence on the output of text-to-text model 110 can lead to better results. ¶ 0022] 1st -2nd sentences: In the example illustrated, flow embeddings 126 is another optional input. Flow embeddings 126 includes a list of previously learned flow embeddings. In various embodiments, flow embeddings 126 comprises embeddings that have been based on existing flows and that can be used to condition text-to-text model 110. Such conditioning can tailor text-to-text model 110's output to resemble previously created flows. Hattami ¶ [0027] 9th, 11th sentences: … text-to-text model 110 can understand the positionality of steps and the composition of a flow. In the flow examples disclosed herein, a flow starts with a trigger (e.g., “when an email is received…. For example, text-to-text model 110 would produce [or generate] the same flow for “Create an incident record when an email is received” and “When an email is received, create an incident record. Hattami ¶ [0029] In the example illustrated, text-to-API converter 112 converts a text output of text-to-text model 110 to API format. In some embodiments, text-to-API converter 112 uses a defined one-to-one mapping [or structured] from step descriptions to API calls. In various embodiments, if output of text-to-text model 110 includes out-of-domain step description, text-to-API converter 112 removes the out-of-domain step and logs an event for a monitoring system. Thus, text-to-API converter 112 would only execute API calls for valid steps. ¶ [0030] 6th sentence: Handling a new builder application includes creating the step descriptions used as the output of text-to-text model 110 and updating text-to-API converter 112 with new API calls (e.g., creating one-to-one mapping updates). ¶ [0038] 1st-4th sentences: Flow 520 of Fig.5C is the flow that has been generated based on the flow description submitted via text box 512. In the example shown, the format of flow 520 is same as the formats for flow 200 of FIG. 2 and flow 300 of Fig.3. In the example shown, the When an issue submission is created portion of the flow description maps to trigger portion 522 of flow 520 and the other portions of the flow description map to corresponding action steps. ¶ [0030] 2nd, 6th sentences: Flow builder application 114 is instructed to create a flow via API calls. Handling a new builder application includes creating the step descriptions used as the output of text-to-text model 110 and updating text-to-API converter 112 with new API calls (e.g., creating one-to-one mapping updates). Hattami Figs.5A-C ¶ [0037] Figs. 5A-C are diagrams illustrating user interface examples associated with automatically implementing a computerized flow based on text input….The text in text box 512 is utilized for flow generation. In the example shown, this text reads: “When an issue submission is created, then for every impacted area, create a compliance Issue task record and send a notification”. In the example shown, the user is able to click on submit button 514 to submit the flow description in text box 512 for automatic generation of a flow based on the submitted flow description. In some embodiments, text-to-text model 110 of Fig.1 is utilized to convert the flow description to API calls to generate a corresponding flow. In the example shown, submission of the flow description occurs within the same user interface used to generate flows graphically. Stated alternatively, in this example, instead of submitting a text description in text box 512, the same flow can be generated by adding a trigger and actions via the graphical user interface using add trigger button 516 and add action button 518. Hattami Figs.5C ¶ [0038] 4th-6th sentences the user is able to add additional action steps to the generated flow graphically and manually by clicking on add action button 524. In the example shown, the user is also able to examine details of the trigger by clicking on trigger portion 522. This brings up user interface element 526, which includes information about the trigger, including the slot value generated for the trigger. In this case, the slot value is table 528. Accordingly, Hattami provides many examples teaching the contested features and thus the Applicant’s prior art argument 1 is found unpersuasive. Prior art argument 2: Remarks 08/20/2026 p.15 ¶2 admits Hattami US 20230385026 A1 discloses text-to-API converter 112 that converts a sequence of steps in text format to API calls but contests Hattami teaching “one or more nodes in the structured definition of the graph of the workflow being mapped to at least one of the one or more APIs”. Prior art argument 2 has been fully considered but is unpersuasive. Hattami Fig.2 above and ¶ [0032] 2nd-4th sentences: flow 200 is comprised of a trigger and 13 action steps [or nodes] in response to the trigger…. a flow could automate the following process: “When an email is received, create an incident record.” Here, the email reception is the trigger and creating the incident record is the step that is to be executed when the trigger condition is met. ¶ [0019] 1st-2nd sentences: Suppose the existing steps are Send Email and Create Incident Record, with Incident being a step parameter that represents a table name. The current position would be 3rd position and indicates the insertion point. In various embodiments, flow-to-text converter 104 first serializes existing steps by converting each one from name to description using a one-to-one mapping and extracting any existing step parameter. Hattami ¶ [0029] In the example illustrated, text-to-API converter 112 converts a text output of text-to-text model 110 to API format. In some embodiments, text-to-API converter 112 uses a defined one-to-one MAPPING from step descriptions to API calls. In various embodiments, if output of text-to-text model 110 includes out-of-domain step description, text-to-API converter 112 removes the out-of-domain step and logs an event for a monitoring system. Thus, text-to-API converter 112 would only execute API calls for valid steps. Hattami ¶ [0030] 6th sentence: Handling a new builder application includes creating the step descriptions used as the output of text-to-text model 110 and updating text-to-API converter 112 with new API calls (e.g., creating one-to-one mapping updates).¶ [0038] 1st-4th sentences: Flow 520 of Fig.5C is the flow that has been generated based on the flow description submitted via text box 512. In the example shown, the format of flow 520 is same as the formats for flow 200 of Fig. 2 and flow 300 of Fig.3. In the example shown, the When an issue submission is created portion of the flow description maps to trigger portion 522 of flow 520 and the other portions of the flow description map to corresponding action steps. Hattami thus provides many examples teaching the contested features of “one or more nodes in the structured definition of the graph of the workflow being mapped to at least one of the one or more APIs”. Accordingly, the prior argument 2 is found unpersuasive. Prior art argument 3: Remarks 08/20/2026 p.15 ¶3 admits Hattami US 20230385026 A1 discloses disclose a text-to-text model 100 that outputs a sequence of steps of a flow in a text format and a text-to-API converter 112 that outputs API calls but still contests Hattami teaching - “outputting the structured definition of the graph of the workflow” as claimed. Prior art argument 3 has been fully considered but is unpersuasive. Examiner relies on the same Fis 2-3, 5 as extracted above for the contested “outputting”. Hattami ¶ [0026] 7th- 9th,11th sentences: For example, from the model perspective, “create an incident record” is similar to “create a record in the incident table” because of the natural language similarity. Slot value format variations in date and time values are encountered during training and thus can be handled. For example, in various embodiments, text-to-text model 110 is trained to extract the same time value from 8 pm, 20 h, and 8 p.m. By utilizing natural language pre-training, the amount of training data required to achieve reliable performance is reduced. Hattami ¶ [0038] 1st -2nd sentences: Flow 520 of Fig.5C below is the flow generated based on the flow description submitted via text box 512. In the example shown, the format of flow 520 is the same as the formats for flow 200 of Fig. 2 and flow 300 of Fig.3. Specifically In the example illustrated, at Figs. 2-3, as stated by ¶ [0029] 1st-2nd sentences: text-to-API converter 112 converted a text output of text-to-text model 110 to API format. In some embodiments, text-to-API converter 112 uses a defined one-to-one mapping from step descriptions to API calls. Hattami ¶ [0038] 3rd-5th sentences: In the example illustrated, the user is able to add additional action steps to the generated flow graphically and manually by clicking on add action button 524. In the example shown, the user is also able to examine details of the trigger by clicking on trigger portion 522. This brings up user interface element 526, which includes info about the trigger, including the slot value generated for the trigger. In this case, the slot value is table 528. PNG media_image2.png 852 702 media_image2.png Greyscale PNG media_image3.png 622 922 media_image3.png Greyscale Hattami Fig.3 (left) and Fig.5 (right) in support of rejection arguments Hattami Fig.3 and ¶ [0034] 9th-12th sentences : For example, suppose the following verbose flow description: “When an incident record is created, if the caller contains chief then update the incident record else if the caller's country is Brazil then update the incident record else if the caller is a VP then update the incident record. After that, classify the incident case. If the confidence is greater than 80% then update the incident record.” Flow 300 [depicted above] is a flow predicted using the techniques disclosed herein for the above flow description [or definition]. Hattami Fig.5C and ¶ [0018] 4th sentence: noting another rexample where builder current state 122 includes two items: 1) existing steps: the steps already created by the user in the builder either by using a user interface or a previous call to text-to-flow unit 100; and 2) current position: the position from which the user had requested to generate the flow (stated alternatively, the index in the existing steps list). ¶ [0030] 6th sentence: Handling a new builder application includes creating the step descriptions used as the output of text-to-text model 110 and updating text-to-API converter 112 with new API calls (e.g., creating one-to-one mapping updates). Hattami ¶ [0038] 1st-4th sentences: Flow 520 of Fig.5C [above] is the flow that has been generated based on the flow description [or definitions] submitted via text box 512. In the example shown, the format of flow 520 is same as the formats for flow 200 of Fig.2 and flow 300 of Fig.3. In the example shown, the When an issue submission is created portion of the flow description maps to trigger portion 522 of flow 520 and the other portions of the flow description map to corresponding action steps. Thus, Hattami provides many examples teacing the broad recitation of “outputting the structured definition of the graph of the workflow”, and hence the prior argument 3 is unpersuasive. Prior art argument 4: Remarks 08/20/2026 p.16 ¶1 admits Hattami US 20230385026 A1 teaches free form natural language of the steps of a workflow but still contests that this natural language description of Hattami is not of one or more modifications to the workflow. Remarks 08/20/2026 p.16 ¶2 further admits that Hattami ¶ [0025] teaches when the flow description includes' communicate via SMS, If the user adds a 'Send SMS' step to the list of possible steps, text-to-text model 110 would output 'Send SMS' as evidence of outputting a newly added step Send SMS, but still contests that such citation of Hattami teaches “modifying the structured definition of the graph of the workflow” as amended at each of independent claims 1,8,15 Prior art argument 4 has been fully considered but is unpersuasive. Examiner notes that the Applicant has not provide an explicit definition, for the term Modifying. In the absence of such an explicit definition, the Examiner follows the broadest reasonable interpretation per MPEP 2111, and broadly interprets the term “modifying” to include, but not limited to addition of actions or steps, removal or actions or steps, highlighting of steps, or any other suitable modification to the workflow, consistent with Original Specification ¶ [0047] last two sentences and the examples of dependent claims 3-4, 10-11,17-18. Based on such claim construction and claim interpretation, based on the broadest reasonable interpretation, the examiner submits that Hattami addition of new steps to the flow teaches the contested limitation of “modifying the structured definition of the graph of the workflow” as amended at each of independent claims 1,8,15. see Hattami Figs. 2-3 and ¶ [0025] 10th-12th sentence: text-to-text model 110 use newly added steps that match flow descriptions. For example, assume the flow description includes communicate via SMS. If the user adds a Send SMS step to the list of possible steps, text-to-text model 110 would output Send SMS. Hattami ¶ [0025] also teaches the modification of the flow by removal or a step, insert of anew step, each and all consistent with the broadest reasonable interpretation established above. Hattami Fig.5B ¶ [0037] 8 sentence add trigger & actions via interface using add trigger button 516 and action button 518 Hattami ¶ [0038] 4th sentence similarly teaches addition of additional action steps to the generated flow graphically by clicking on add action button 524. Accordingly, it is submitted that based on the broadest reasonable interpretation, Hattami teaches the broad recitation of “modifying the structured definition of the graph of the workflow”, and hence the prior argument 4 is unpersuasive. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), first paragraph: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 6,13,20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. MPEP 2173 ¶2-¶3 states:…A … purpose is to provide a clear measure of what the inventor or a joint inventor regards as the invention so that it can be determined whether the claimed invention meets all the criteria for patentability and whether the specification meets the criteria of 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph with respect to the claimed invention. It is of utmost importance that patents issue with definite claims that clearly and precisely inform persons skilled in the art of the boundaries of protected subject matter…. Here, Claims 6,13,20 are dependent and each recite among others: “wherein the structured definition of the graph of the workflow is in DOT (DAG (directed acyclic graph) of tomorrow) language grammar”. [bolded emphasis added]. Original Disclosure provides support for subject matter at the time of the filling of the Application not to a subsequent date such as “tomorrow”. Thus, the Original Disclosure does not precisely inform persons skilled in the art of the boundaries of the subject matter, and does not provide clear, deliberate and sufficient support show Applicant had possession for “wherein the structured definition of the graph of the workflow is in DOT (DAG (directed acyclic graph) of tomorrow) language grammar” at claims 6,13,20. Claims 6,13,20 are recommended to be amended to each recite, among others: wherein the structured definition of the graph of the workflow is in DOT (DAG (directed acyclic graph) ) language grammar”. Clarification and/or correction is/are required. 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 6,13,20 are 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 pre-AIA the applicant regards as the invention. Claims 6,13,20 are dependent and each recite among others: “wherein the structured definition of the graph of the workflow is in DOT (DAG (directed acyclic graph) of tomorrow) language grammar”. [emphasis added]. Examiner follows MPEP 2173 ¶2-¶3: In patent examining parlance, the claim language must be “definite” to comply with 35 USC. 112(b) or pre-AIA 35 USC 112, second paragraph. Conversely, a claim that does not comply with this requirement of 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph is “indefinite.” The primary purpose of this requirement of definiteness of claim language is to ensure that the scope of the claims is clear so the public is informed of the boundaries of what constitutes infringement of the patent….. It is of utmost importance that patents issue with definite claims that clearly and precisely inform persons skilled in the art of the boundaries of protected subject matter. Therefore, claims that do not meet this standard must be rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph as indefinite. This finding is further corroborated by MPEP 2173.02. Claims 6,13,20 are rendered vague and indefinite because expression “of tomorrow” does not clearly and precisely inform persons skilled in the art of the boundaries of protected subject matter. Also, expression “of tomorrow”, does not ensure that the scope of the claims is clear so the public is informed of the boundaries of what would constitute infringement of an ensuing patent. Claims 6,13,20 are recommended to be amended to each recite, among others: wherein the structured definition of the graph of the workflow is in DOT (DAG (directed acyclic graph) ) language grammar”. Clarification and/or correction is/are required. 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,3-8,10-15 and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea, here abstract idea) without significantly more. The claim(s) recite(s) describe or set forth the abstract assisted task mining as summarized by the Application’1 Title as read in light or Original Specification ¶ [0002] 1st sentence: “Task mining is the process of automatically capturing and analyzing user indications with a computer system to understand how tasks are performed in real-world scenarios”. Such capturing, analyzing and understanding are examples of observations, evaluations and judgements, which according to MPEP 2106.04(a)(2) III ¶2, set forth the abstract exception of mental processes. Further, as explained by MPEP 2106.04(a)(2) III C #2, #3, the fact that such processes are computer-aided as tools (MPEP 2106.04(a)(2) III C #3) and are pertinent to a computer environment (MPEP 2106.04(a)(2) III C #2), does not necessarily preclude such processes from setting forth the abstract exception. Here, the use of “language model” at Claims 1,2,5,7-9,12,14-16,19 can be argued as an example of such as tool or aid (MPEP 2106.04(a)(2) III C #3) for “generating a structured definition” [thus cognition] “of a graph of the workflow” (independent Claims 1,8,15, dependent Claims 5,12,19) and “modifying the structured definition of the graph of the workflow” “based on the natural language description” [or cognition] of the modifications to the workflow” (independent Claims 1,8,15). Similarly, recitations “wherein the one or more modifications to the workflow comprise an addition of one or more steps to the workflow” (dependent Claims 3,10,17) and “wherein the one or more modifications to the workflow comprise highlighting one or more steps of the workflow” (dependent Claims 4,11,18) fall within the implementation by computer aids, if not simply by pen and paper, to “add” (dependent Claims 3,10,17) and “highlight” (dependent Claims 4,11,18) “of the workflow”. Also here, “description of one or more APIs (application programming interfaces)” at independent Claims 1,8,15 and dependent Claims 5,12,19, can be argued as an example of a computer environment (MPEP 2106.04(a)2 III C#2) upon which the abstract process is performed. Thus here, neither the “description of one or more APIs”, nor the recitation of “using a language model based on the natural language description of the workflow” does preclude the current claims from reciting, describing or setting froth the computer-aided mental processes. MPEP 2106.04 I mid-¶3 corroborates that narrow forms of abstract idea that have limited applications were still held ineligible. As one example, MPEP 2106.04(a)(2) III A, 5th bullet, cites Electric Power Group v Alstom, S.A 830 F.3d 1350, 1353-54,119 USPQ2d 1739, 1741-42 (Fed Cir 2016) to state that a claim of collecting information, analyzing it, and displaying certain results of tcollection and analysis, recites abstract mental processes. This is consistent with the abstract observations, evaluations and judgements, of MPEP 2106.04(a)(2) III ¶2 mentioned above. - Here, such collection and/or observation of information is/are set forth by: “receiving 1) a natural language description of a workflow and 2) a description of one or more APIs (application programming interfaces) for performing the workflow” (independent Claims 1,8,15 and dependent Claims 5,12,19) “comprises receiving an example comprising a natural language description of an exemplary workflow and a corresponding structured definition of a graph of the exemplary workflow” (dependent Claims 5,12,19), “receiving a natural language description of modifications to the workflow” (independent Claims 1,8,15). - Here, such analysis and/or evaluation for subsequent judgment is set forth by: “generating a structured definition of a graph of the workflow using a language model based on the natural language description of the workflow and the description of the one or more APIs, one or more nodes in the structured definition of the graph of the workflow being mapped to at least one of the one or more APIs” (independent Claims 1,8,15). - Here, such displaying of certain results of collection and analysis is set forth by: “outputting the structured definition of the graph of the workflow” (independent Claims 1,8,15), “outputting the modified structured definition of the graph of the workflow” (Claims 1,8,15). Thus, there is preponderance of legal evidence showing that the claims recite, describe or set forth the abstract exception. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This judicial exception is not integrated into a practical application because per Step 2A prong two, no individual or combination of the additional, computer-based elements integrate the abstract idea into a practical application. Specifically, according to MPEP 2106.05(f)(2) ¶1, 2nd sentence, use of a computer or other machinery in its ordinary capacity for tasks to receive, store, or transmit data, does not integrate a judicial exception into a practical application. Here, the “memory” instruct[ed] “processor” of independent Claims 8,15, are found to merely apply the aforementioned abstract processes as identified above, as mere invocation of tools, which, according to MPEP 2106.05(f)(2)(i), do not integrate the abstract idea into a practical application. The same analysis and results apply to “using a language model” of independent Claims 1,8,15 and independent Claims 1,8,15 and dependent Claims 5,12,19, and then narrowed as “large language model” at dependent Claims 7,14, which, if not already considered as computer aid of the abstract idea, as argued above, it would at most represent, an example of an algorithm executed on a computer, which according to MPEP 2106.05(f)(2)(i), is an invocation of machinery or tool which, that would not integrate the abstract idea into a practical application. Also, as ruled by the Federal Circuit in Recentive Analytics, Inc. v. Fox Corp., 134 F.4th 1205, 1212 (Fed. Cir. 2025 and cited by PTAB in its decision on Appeal 2025-003304: “The requirements that the machine learning model be ‘iteratively trained’ or dynamically adjusted…do not represent a technological improvement” at least because they are “incident to the very nature of machine learning”. Thus here, “using the language model based on the natural language description of the modifications to the workflow” [for adjusting, or] “modifying the structured definition of the graph of the workflow” as recited at independent Claims 1,8,15, would similar to Recentive Analytics, not provide a technological improvement to integrate the abstract idea into a practical application. The same rationale applies to the narrowing of the “language model” or algorithm to “a large language model” (dependent Claims 7,14) and the narrowing of “the structured definition of the graph of the workflow” to a “DOT (DAG (directed acyclic graph) of tomorrow) language grammar” (dependent Claims 6,13,20) when similarly tested per the execution of the computer algorithm of MPEP 2106.05(f)(2)(i) above. Also, Applicant has not invented DOT (DAG (directed acyclic graph) of tomorrow) language grammar (dependent Claims 6,13,20) nor is Applicant alleging as much. Next, as per the capabilities of the “processor” in “generating a structured definition of a graph of the workflow” (independent Claims 1,8,15, dependent Claims 5,12,19) and “modifying the structured definition of the graph of the workflow” “based on the natural language description of the modifications to the workflow” (independent Claims 1,8,15), “wherein the one or more modifications to the workflow comprise an addition of one or more steps to the workflow” (dependent Claims 3,10,17) and “wherein the one or more modifications to the workflow comprise highlighting one or more steps of the workflow” (dependent Claims 4,11,18), the Examiner points to MPEP 2106.05(f)(2) (iii), (v) which find that processes for monitoring audit log data, executed on a computer2, and use of software to tailor information and provide it to user on the computer3, represent, mere invocation of computers or machinery that do not integrate the abstract idea into a practical application. Alternatively, given the claims’ breadth, the computerized environment of any additional elements, when tested per MPEP 2106.05(h) would represent a mere narrowing of the abstract idea, to a field of use or technological environment, which would not integrate it into practical application. For example, MPEP 2106.05(h) vi. cites the same Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016), to state that narrowing the combination of collecting information, analyzing it, and displaying certain results of the collection and analysis to data related to a field of use or technological environment does not integrate the abstract ide into a practical application. It would then follow that here, narrowing the combination of collecting information, analyzing it, and displaying certain results of the collection and analysis, as identified and mapped above, to data related to a “description of the one or more APIs” would similarly not integrate the abstract idea into a practical application. Thus, Examiner has provided a preponderance of legal evidence showing no additional computer-based elements, capable to integrate the abstract idea into a practical application. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as shown above, the additional computer-based elements merely apply the already recited abstract idea, [see MPEP 2106.05(f)] and/or provide a narrowing of the abstract idea to a field of user or technological environment [MPEP 2106.05(h)]. Specifically, Examiner points to MPEP 2106.05 (d) II and carries over the finings tested per MPEP 2106.05 (f) and (h) to submit that the additional computer-based elements also do not provide significantly more. Examiner submits that the above tests show the applying of the abstract idea [MPEP 2106.05 (f)] and narrowing the abstract idea to a field of use or technological environment [MPEP 2106.05 (h)], suffice in showing that the additional computer-based elements also do not provide significantly more without having to rely on the conventionality test [MPEP 2106.05(d)]. Yet assuming arguendo that further evidence would be required to demonstrate conventionality of the additional, computer-based elements, Examiner would further point to MPEP 2106.05(d) to demonstrate that said additional elements remain well-understood, routine, conventional. In that case, Examiner would rely as evidence on: Per MPEP 2106.05(d)(I)(2) to point to Applicant’s own Original Specification, as follows: - Original Specification ¶ [0023] 3rd sentence: “Processor(s) 110 may be any type of general or specific purpose processor, including a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Graphics Processing Unit (GPU), multiple instances thereof, and/or any combination thereof” - Original Specification ¶ [0032] reciting at high level of generality: “Embodiments described herein provide for assisted task mining using LLMs. Such assisted task mining generates a structured definition of a graph of a workflow, for example, in the DOT (DAG (directed acyclic graph) of tomorrow) language grammar, based on a natural language description of the workflow. Each node of the structured definition of the graph, which corresponds to a step of the workflow, is mapped to at least one corresponding API for performing that step. Advantageously, embodiments described herein provide for the automatic translation of natural language descriptions of workflows into a structured definition of a graph, thereby facilitating visualization and manipulation of the workflows”. - Original Specification ¶ [0055] reciting at high level of generality: “The steps and sub-steps disclosed herein, including process steps and sub-steps performed in FIG. 2, may be performed by a computer program, encoding instructions for the processor(s) to perform at least part of the process(es) described in FIG. 2, in accordance with embodiments of the present invention. The computer program may be embodied on a non-transitory computer-readable medium. The computer-readable medium may be, but is not limited to, a hard disk drive, a flash device, RAM, a tape, and/or any other such medium or combination of media used to store data. The computer program may include encoded instructions for controlling processor(s) of a computing system (e.g., processor(s) 110 of computing system 100 of FIG. 1) to implement all or part of the process steps and sub-steps described with respect to FIG. 2, which may also be stored on the computer-readable medium”. - Original Specification ¶ [0056] reciting at high level of generality: “The computer program can be implemented in hardware, software, or a hybrid implementation. The computer program can be composed of modules that are in operative communication with one another, and which are designed to pass information or instructions to display. The computer program can be configured to operate on a general purpose computer, an ASIC, or any other suitable device”. - Original Specification ¶ [0057] reciting at high level of generality: “It will be readily understood that the components of various embodiments of the present invention, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the detailed description of the embodiments of the present invention, as represented in the attached figures, is not intended to limit the scope of the invention as claimed, but is merely representative of selected embodiments of the invention”. - Original Specification ¶ [0061] reciting at high level of generality: “One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims”. All of these fail to provide anything significantly more than what is already well-understood, routine and conventional in light MPEP 2106.05(d). In conclusion, Claims 1,3-8,10-15 and 17-20 although directed to statutory categories (here “method” or process at Claims 1, 3-7, “system” or machine at Claims 8, 10-14, “non-transitory computer-readable storage medium” or computer product at Claims 15, 17-20) they still recite, or at least set forth the abstract idea (Step 2A prong one), with their additional, computer based elements not integrating the abstract idea into a practical application (Step 2A prong two) or providing significantly more (Step 2B). Claims 1,3-8,10-15 and 17-20 are thus not patent eligible. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Claim Rejections - 35 USC § 102 The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 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. (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. Claims 1,3-5,7-8,10-12,14-15,17-19 are rejected under 35 U.S.C. 102(a)(1) or 102 (a)(2) or both, as being anticipated by: Hattami et al, US 20230385026 A1 hereinafter Hattami. As per, Claims 1,8,15 Hattami teaches “A computer-implemented method comprising”: / “A system comprising: a memory storing computer program instructions; and at least one processor configured to execute the computer program instructions, the computer program instructions configured to cause the at least one processor to perform operations of:” / “A non-transitory computer-readable medium storing computer program instructions, the computer program instructions, when executed on at least one processor, cause the at least one processor” (Hattami ¶ [0044] -¶ [0051]) “to perform operations comprising:” - “receiving 1) a natural language description of a workflow” (Hattami ¶ [0013] 7th-8th sentences: users use free-form natural language to instantiate steps of workflows, which can be displayed as visual steps in graphical user interface. Stated alternatively, automation flows can be generated from natural language descriptions. ¶ [0040] At 602, a user provided text description of at least a portion of a desired workflow is received. In some embodiments, the user provided text description is flow description 120 of Fig.1. the user provided text description is a natural language input from the user. ¶ [0037] 4th-5th sentences: The text in text box 512 is utilized for flow generation. In example shown, this text reads: When an issue submission is created, then for every impacted area, create a compliance Issue task record and send a notification) “and 2) a description of one or more APIs (application programming interfaces) for performing the workflow” (Hattami ¶ [0030] 2nd-3rd, 6th sentences: Flow builder application 114 is instructed to create a flow via API calls. An example of flow builder is ServiceNow Flow Designer Platform. Handling a new builder application includes creating the step descriptions used as output of text-to-text model 110 and updating text-to-API converter 112 with new API calls (creating one-to-one mapping updates); - “generating a structured definition of a graph of the workflow using a language model based on the natural language description of the workflow and the description of the one or more APIs, one or more nodes in the structured definition of the graph of the workflow being mapped to at least one of the one or more APIs”; (Hattami ¶ [0016] 1st-2nd,8th,9th sentences: flow description 120 is mandatory text input that describes either entire, partial flow, or single step (e.g., a single action in a flow). Flow description 120 comprises a step description that can be a known description or any other semantically equivalent description (e.g. Create record and Add a record to a table will both generate the same flow step. In various embodiments, input aggregator 102 determines a flow description based on flow description 120 and the output of flow-to-text converter 104 and combines this with context information that is a text output of context-to-text converter 106. In some embodiments, there is a specified order [thus structure] in which the information is combined because starting with the elements that have more influence on the output of text-to-text model 110 lead to better results. Hattami ¶ [0019] 1st-6th sentences: Suppose the existing steps are Send Email and Create Incident Record, with Incident being a step parameter that represents a table name. The current position would be 3rd position and indicates the insertion point. In various embodiments, flow-to-text converter 104 first serializes existing steps by converting each one from name to description using a one-to-one mapping and extracting any existing step parameter. The output generated may be in format: “Existing Steps: step 1 [parameter 1], step 2,…, step N [parameter N] Current Position: X. In this format, Existing Steps and Current Position are prefixes that differentiate the existing steps from current position. This is needed because the output of flow-to-text converter 104 is in a text format. In various embodiments, text-to-text model 110, uses the existing steps to modulate the output when predicting partial flows, which is helpful for steps that are affected by previously created ones. Text-to-text model 110 verify how likely a specific step is to occur given the previous ones learned during the training phase of text-to-text model 110. Hattami ¶ [0023] In various embodiments, text-to-text model 110 predicts entire or partial flow based on flow description 120. Text-to-text model 110 also utilize inputs other than a user-provided flow description depending on builder current state 122 and context 124. Specifically, the prediction of text-to-text model 110 may be modulated by inputs such as context parameters, existing steps, and/or flow embeddings. In some embodiments, the flow is predicted by text-to-text model 110 in a text format as follows: Step description 1, Step description 2 [parameter 1], . …, Step description N [parameter 1,…, parameter M]. Depending on the user input, the output can include a single parameter, multiple parameters, or zero parameters. The architecture of text-to-text model 110 may be based on various machine learning architectures configured to perform end-to-end learning of semantic mappings from input to output, including transformers and recurrent neural networks (RNNs) (large language models (LLMs)). Text-to-text model 110 has been trained on text examples and is configured to receive a text input and generate a text output. In various embodiments, text-to-text model 110 has been trained by utilizing transfer learning. Transfer learning refers to first pre-training a model on a data-rich task and then fine-tuning the model on a downstream task. In some embodiments, text-to-text model 110 is an LLM that has an Encoder-Decoder architecture. In various embodiments, text-to-text model 110 has been pre-trained on a multi-task mixture of unsupervised and supervised tasks for which each task is converted into a text-to-text format. An example of an LLM model with an Encoder-Decoder architecture is the T5 model. Hattami ¶ [0029] In the example illustrated, text-to-API converter 112 converts a text output of text-to-text model 110 to API format. In some embodiments, text-to-API converter 112 uses a defined one-to-one mapping [thus structure] from step descriptions to API calls. In various embodiments, if output of text-to-text model 110 includes out-of-domain step description, text-to-API converter 112 removes the out-of-domain step and logs an event for a monitoring system. Thus, text-to-API converter 112 would only execute API calls for valid steps. ¶ [0030] 6th sentence: Handling a new builder application includes creating the step descriptions used as the output of text-to-text model 110 and updating text-to-API converter 112 with new API calls (e.g., creating one-to-one mapping updates). ¶ [0038] 1st-4th sentences: Flow 520 of Fig.5C is the flow that has been generated based on the flow description submitted via text box 512. In the example shown, the format of flow 520 is same as the formats for flow 200 of FIG. 2 and flow 300 of Fig.3. In the example shown, the When an issue submission is created portion of the flow description maps to trigger portion 522 of flow 520 and the other portions of the flow description map to corresponding action steps. In the example illustrated, the user is able to add additional action steps to the generated flow graphically and manually by clicking on add action button 524. In example shown, the user is also able to examine details of the trigger by clicking on trigger portion 522. This brings up user interface element 526, which includes infoabout the trigger, including the slot value generated for the trigger. In this case, the slot value is table 528) “and” - “outputting the structured definition of the graph of the workflow”. (Hattami ¶ [0032] Fig.2 is a diagram illustrating an example of a computerized flow. In the example shown, flow 200 is used to automate an information technology management process. In the example shown, flow 200 is comprised of a trigger and 13 action steps in response to the trigger. As illustrated, a step can be an action (single step), a sub-flow (a group of steps), or flow logic (e.g., an “if” statement). As another illustrative example, a flow could automate the following process: “When an email is received, create an incident record.” Here, the email reception is the trigger and creating the incident record is the step that is to be executed when the trigger condition is met. Flow 200 is also an example of a computerized flow created using a graphical user interface environment. To create a flow in such an environment, users may rely on a set of buttons to add or modify steps. For example, in the example illustrated, button 202 can be used to add an action, sub-flow, or flow logic. ¶ 0034] 1st sentence: Fig.3 is a diagram illustrating an example of an automatically implemented computerized flow that promotes best practices Hattami ¶ [0038] Flow 520 of Fig.5C is the flow that has been generated based on the flow description submitted via text box 512. In the example shown, the format of flow 520 is the same as the formats for flow 200 of FIG. 2 and flow 300 of Fig.3. In the example shown, the When an issue submission is created portion of the flow description maps to trigger portion 522 of flow 520, and the other portions of the flow description map to corresponding action steps. In the example illustrated, the user is able to add additional action steps to the generated flow graphically and manually by clicking on add action button 524. In the example shown, the user is also able to examine details of the trigger by clicking on trigger portion 522. This brings up user interface element 526, which includes information about the trigger, including the slot value generated for the trigger. In this case, the slot value is table 528) - “receiving a natural language description of modifications to the workflow” (Hattami ¶ [0013] 7th sentence: users use free-form natural language to instantiate steps of workflows, which can be displayed as visual steps in the graphical user interface. For example, at ¶ [0025] 9th sentence: a user can provide a new step in the list of possible steps); “and” - “modifying the structured definition of the graph of the workflow using the language model based on the natural language description of the modifications to the workflow”; (Hattami ¶ [0025] 10th-12th sentence: text-to-text model 110 use newly added steps that match flow descriptions. For example, assume the flow description includes communicate via SMS. If the user adds a Send SMS step to the list of possible steps, text-to-text model 110 would output Send SMS) “and” - “outputting the modified structured definition of the graph of the workflow”. (Hattami ¶ [0025] 12th sentence: If user adds a Send SMS step to the list of possible steps, text-to-text model 110 would output Send SMS. ¶ [0030] 6th sentence: Handling a new builder application includes creating the step descriptions used as the output of text-to-text model 110 and updating text-to-API converter 112 with new API calls (e.g. creating one-to-one mapping updates. ¶ [0036] 10th -11th sentences: the flow length indicates the number of steps that synthetic data generator 408 will take from variations 406 to construct a synthetic flow). Claims 3,10,17 Hattami teaches all the limitations in claims 1,8,15 above. Hattami further teaches “wherein the one or more modifications to the workflow comprise an addition of one or more steps to the workflow” (Hattami ¶ [0025] 10th -12th sentence: text-to-text model 110 use newly added steps that match flow descriptions. For example, assume the flow description includes communicate via SMS. If the user adds a Send SMS step to the list of possible steps, text-to-text model 110 would output Send SMS). Claims 4,11,18. Hattami teaches all the limitations in claims 1,8,15 above. Furthermore, Hattami teaches “the one or more modifications to the workflow comprise highlighting one or more steps of the workflow” (Hattami Fig.5B ¶ [0037] 8 sentence add trigger & actions via interface using add trigger button 516 and action button 518. ¶ [0038] 4th sentence: user adds additional action steps to the generated flow graphically by clicking on add action button 524 Fig.5C ¶ [0038] 5th-6th sentences: In example shown, the user examine details [or highlights] of trigger by clicking trigger portion 522. This brings up user interface element 526, which includes info about the trigger, including slot value [or highlight] generated for the trigger. In this case, slot value is table 528. ¶ [0026] 2nd sentence: For example, in the input “create an incident record,” the slot value is “incident,” which represents a table name where the record will be created) Claims 5,12,19 Hattami teaches all limitations in claims 1,8,15 above. Hattami further teaches - “receiving 1) a natural language description of a workflow” (Hattami ¶ [0013] 7th-8th sentences: users use free-form natural language to instantiate steps of workflows, which can be displayed as visual steps in graphical user interface. Stated alternatively, automation flows can be generated from natural language descriptions. ¶ [0040] At 602, a user provided text description of at least a portion of a desired workflow is received. In some embodiments, the user provided text description is flow description 120 of Fig.1. the user provided text description is a natural language input from the user. ¶ [0037] 4th-5th sentences: The text in text box 512 is utilized for flow generation. In example shown, this text reads: When an issue submission is created, then for every impacted area, create a compliance Issue task record and send a notification) “and 2) a description of one or more APIs (application programming interfaces) for performing the workflow” (Hattami ¶ [0030] 2nd-3rd, 6th sentences: Flow builder application 114 is instructed to create a flow via API calls. An example of a flow builder is ServiceNow Flow Designer Platform. Handling a new builder application includes creating the step descriptions used as output of text-to-text model 110 and updating text-to-API converter 112 with new API calls (creating one-to-one mapping updates); “comprises receiving an example comprising a natural language description of an exemplary workflow and a corresponding structured definition of a graph of the exemplary workflow” (Hattami ¶ [0013] 7th-8th sentences: The techniques disclosed herein allow users to use free-form natural language to instantiate steps of workflows, which can be displayed as visual steps in the graphical user interface. Stated alternatively, automation flows can be generated from natural language descriptions. ¶ [0026] 7th sentence: from the model perspective, create an incident record is similar to create a record in the incident table because of the natural language similarity. ¶ [0040] At 602, a user provided text description of at least a portion of a desired workflow is received. In some embodiments, the user provided text description is flow description 120 of Fig.1. In various embodiments, the user provided text description is a natural language input from the user); “and” - “generating a structured definition of a graph of the workflow using a language model based on the natural language description of the workflow and the description of the one or more APIs comprises generating the structured definition of the graph of the workflow based on the example”. (Hattami ¶ [0019] 1st-6th sentences: Suppose the existing steps are Send Email and Create Incident Record, with Incident being a step parameter that represents a table name. The current position would be 3rd position and indicates the insertion point. In various embodiments, flow-to-text converter 104 first serializes existing steps by converting each one from name to description using a one-to-one mapping and extracting any existing step parameter. The output generated may be in the format: “Existing Steps: step 1 [parameter 1], step 2,…, step N [parameter N] Current Position: X. In this format, Existing Steps and Current Position are prefixes that differentiate the existing steps from current position. This is needed because the output of flow-to-text converter 104 is in a text format. In various embodiments, text-to-text model 110, uses existing steps to modulate the output when predicting partial flows, which is helpful for steps that are affected by previously created ones. Text-to-text model 110 verify how likely a specific step is to occur given the previous ones learned during the training phase of text-to-text model 110. Hattami ¶ [0023] In various embodiments, text-to-text model 110 predicts entire or partial flow based on flow description 120. Text-to-text model 110 also utilize inputs other than a user-provided flow description depending on builder current state 122 and context 124. Specifically, the prediction of text-to-text model 110 may be modulated by inputs such as context parameters, existing steps, and/or flow embeddings. In some embodiments, the flow is predicted by text-to-text model 110 in a text format as follows: Step description 1, Step description 2 [parameter 1], . …, Step description N [parameter 1,…, parameter M]. Depending on the user input, the output can include a single parameter, multiple parameters, or zero parameters. The architecture of text-to-text model 110 may be based on various machine learning architectures configured to perform end-to-end learning of semantic mappings from input to output, including transformers and recurrent neural networks (RNNs) (large language models (LLMs)). Text-to-text model 110 has been trained on text examples and is configured to receive a text input and generate a text output. In various embodiments, text-to-text model 110 has been trained by utilizing transfer learning. Transfer learning refers to first pre-training a model on a data-rich task and then fine-tuning the model on a downstream task. In some embodiments, text-to-text model 110 is an LLM that has an Encoder-Decoder architecture. In various embodiments, text-to-text model 110 has been pre-trained on a multi-task mixture of unsupervised and supervised tasks for which each task is converted into a text-to-text format. An example of an LLM model with an Encoder-Decoder architecture is the T5 model) Claims 7,14 Hattami teaches all the limitations in claims 1,8 above. Hattami teaches “wherein the language model is a large language model” (Hattami ¶ [0014] 1st sentence: the techniques herein utilize large, pre-trained language models. Similarly mid-¶ [0023], ¶ [0027] last sentence). ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Rejections under 35 § U.S.C. 103 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 of this title, 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. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 6,13,20 are rejected under 35 U.S.C. 103 as being unpatentable over: Hattami as applied to claims 1,8,15, in view of Roper et al, US 20250217114 A1 hereinafter Roper. As per, Claims 6,13,20 Hattami teaches all the limitations in claims 1,8,15 above. Hattami does not explicitly recite: “wherein the structured definition of the graph of the workflow is in DOT (DAG (directed acyclic graph) of tomorrow) language grammar”. Roper however in analogous machine learning engine for workflow enhancement in digital workflows teaches or suggests: “wherein the structured definition of the graph of the workflow is in DOT (DAG (directed acyclic graph) of tomorrow) language grammar” (Roper ¶ [0053] the graph representations of sample digital thread orchestration scripts may be direct acyclic graphs (DAGs) ). It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Hattami’s “method” /”system non-transitory medium” to have included Roper’s teachings in order to have allowed generation of individual digital model files into executable splices with the benefit of being autonomously and securely linked, thus enabling the management of a large number of digital models as a unified digital thread (e.g., in a Directed Acyclic Graph (DAG) architecture). (Roper ¶ [0211] 2nd sentence, ¶ [0226] 1st sentence in view of MPEP 2143 G, C and/or D) Further, the claimed invention is merely a combination of old elements in a similar field of endeavor dealing with machine learning engine for workflow. In such combination each element merely would have performed the same definition, analysis and manipulation function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Hattami in view of Roper, the to be combined elements would have fitted together, like pieces of a puzzle in a logical, complementary and technologically feasible manner. Thus, it would have been reasoned that results of said combination would have been predictable (MPEP 2143 A). ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Conclusion The following art is made of record and considered pertinent to Applicant's disclosure: Lessons Learned from DAG based Workflow Orchestration, excerpt, TMLS youtube channel, Aug 17,2023 WO 2025030057 A1 teaching Machine learning engine for workflow enhancement in digital workflows US 20210073285 A1 Hybrid decentralized computing environment for graph-based execution environment US 20180315141 A1 System and method for business intelligence through data-driven contract analysis US 20180005186 A1 System and method for forming, storing, managing, and executing contracts US 20210073291 A1 Adaptive parameter transfer for learning models US 20210073287 A1 Dimensional reduction of categorized directed graphs US 10339481 B2 Systems and methods for generating user interface-based service workflows utilizing voice data US 20230376838 A1 Machine learning prediction of workflow steps US 20200201910 A1 System and Method for Providing a Graph Protocol for Forming a Decentralized and Distributed Graph Database US 11954102 B1 Structured query language query execution using natural language and related techniques US 20260017426 A1 Adaptive simulation planning and risk management system using real-time ai analysis US 20250258708 A1 Federated distributed graph-based computing platform with hardware management US 20250258937 A1 Federated distributed computational graph platform for advanced biological engineering and analysis US 20260010351 A1 Generative Artificial Intelligence (AI) for Digital Workflows US 20250315242 A1 System and method for automatically generating code for software code updates US 20250291698 A1 Multi-benchmark platforms for evaluation of machine learning models US 20250045304 A1 Method and system for interpreting inputted information US 20250390352 A1 AI Serving Hardware and Software Frontier Enhancements US 20260004030 A1 Artificial Intelligence (AI) Assisted Integration of New Digital Model Types and Tools into Integrated Digital Model Platform US 20250259082 A1 AI agent decision platform with deontic reasoning and quantum-inspired token management US 12222911 B1 String data error detection and repair US 12190416 B1 Method and apparatus for contextually intelligent graph generation 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 OCTAVIAN ROTARU whose telephone number is (571)270-7950. The examiner can normally be reached on 571.270.7950 from 9AM to 6PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICIA H MUNSON, can be reached at telephone number (571)270-5396. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form. /Octavian Rotaru/ Primary Examiner, Art Unit 3624 A September 28th, 2026 1 In re Bond, 910 F.2d 831, 15 USPQ2d 1566 (Fed. Cir. 1990). 2 FairWarning IP, LLC v. Iatric Sys., 839 F.3d 1089, 1095, 120 USPQ2d 1293, 1296 (Fed. Cir. 2016); 3 Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370-71, 115 USPQ2d 1636, 1642 (Fed. Cir. 2015)