DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Final Office Action is responsive to Applicant's amendment filed on 8 April 2026. Applicant’s amendment on 8 April 2026 amended Claims 1, 3-8, 10-17, and 20. Currently Claims 1, 3-8, and 10-20 are pending and have been examined. Claims 2 and 9 has been canceled. The Examiner notes that the 101 rejection has been maintained.
Response to Arguments
Applicant's arguments filed 8 April 2026 have been fully considered but they are not persuasive.
The Applicant argues on pages 1-2 that “The Amended Claims Do Not Integrate the Abstract Idea Into a Practical Application That Improves a Technical System”.
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that the Applicant's argument that the amended claims integrate any alleged abstract idea into a practical application that improves the operation of a computer-implemented transaction platform and related simulation technology is not persuasive and the rejection is maintained. Under Step 2A, Prong Two, the Examiner evaluates whether the claim as a whole integrates the recited judicial exception into a practical application by determining, among other things, whether the additional elements reflect an improvement to the functioning of a computer or to another technology or technical field, or whether the claims instead merely use computers or other machinery as a tool to perform the recited abstract idea. See MPEP2106.04(d)(1); MPEP2106.05(a); August 4, 2025 Memorandum from Deputy Commissioner for Patents (hereinafter "August 2025 Memo"). Critically, this analysis requires a two-step inquiry: first, the specification must be evaluated to determine whether it provides sufficient detail such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement to the functioning of a computer or to another technology or technical field; and second, the claim itself must be evaluated to ensure that it reflects the disclosed improvement. MPEP2106.04(d)(1); MPEP2106.05(a); Ex Parte Desjardins. An important further consideration is the extent to which the claim covers a particular solution to a problem or a particular way to achieve a desired outcome, as opposed to merely claiming the idea of a solution or a desired outcome. MPEP2106.05(a); August 2025 Memo.
Applicant argues that the claimed invention improves a computer-implemented transaction platform and related simulation technology by describing a technical problem inherent in online transaction protocols namely, that fraud arises from previously unknown execution sequences that place platforms into invalid states and providing a technical solution rooted in computer technology. However, a careful evaluation of the specification and the amended claims reveals that the specification does not describe an improvement to the functioning of a computer or to simulation technology itself; rather, it describes the use of known computational tools graph modeling, graph embedding, large language model-based format conversion, and state-space simulation to address a financial fraud detection and remediation problem. The specification at par. [0028] characterizes the exploit remediation system as leveraging "a classical mathematics-based protocol modeling methodology," and at par. [0032] describes the large language model as implementing "a math-based language for modeling computer programs and systems (e.g., Temporal Logic of Actions, Plus (TLA+))." These characterizations establish that the computational components being used are known techniques applied to the domain of financial transaction analysis, not improvements to those computational technologies themselves. Where the specification describes the claimed components only in terms of their role in performing the abstract idea analyzing and remediating financial transaction exploits rather than in terms of how those components are technically improved, the specification does not establish the requisite improvement to computer functionality or to another technology or technical field. MPEP2106.05(a) (a bare assertion of improvement without the detail necessary to be apparent to a person of ordinary skill in the art is insufficient); Affinity Labs of Tex., LLC v. DirecTV, LLC.
Moreover, the amended claims themselves confirm this analysis. Amended claim 1 recites, at a high level of generality, accessing historical order data, generating transaction graphs, embedding those graphs, generating graph patterns, utilizing a large language model to convert graph patterns into a workflow, simulating that workflow by exploring a state space and checking invariants, identifying an invariant-violating sequence, and implementing a policy update or code enhancement. Not one of these limitations specifies a particular improvement to how the graph model operates, how the embedding is performed, how the large language model performs its conversion, or how the simulation engine conducts state-space exploration. The limitations are recited entirely in functional, result-oriented terms that encompass any manner of performing each step, without constraining the claim to a particular technical solution to any computer-technology problem. The August 2025 Memo makes clear that the relevant inquiry is whether the claim invokes computers merely as tools to perform an existing process, or whether the claim purports to improve computer capabilities or to improve an existing technology, and specifically cautions that the examiner must consider whether the claim "covers a particular solution to a problem or a particular way to achieve a desired outcome, as opposed to merely claiming the idea of a solution or outcome." August 2025 Memo. Here, the claim covers any method of performing each step using any graph model, any embedding technique, any large language model, any simulation approach, and any policy update and is therefore directed to the idea of detecting and remediating financial transaction exploits rather than to a particular technical solution to a problem in computer technology or simulation technology. This is precisely the type of broadly claimed functional process that Recentive Analytics, Inc. v. Fox Corp, addressed in finding that steps incidental to automating an abstract idea are not sufficient to confer eligibility, in contrast to cases such as USPTO Example 47 where the claim as a whole improved the technical field of network intrusion detection by reciting specific technical mechanisms. See August 2025 Memo. Accordingly, the rejection under 35 U.S.C.101 is maintained, and Applicant's argument at Step 2A, Prong Two is not persuasive and argument is maintained.
The Applicant argues on pages 2-3 that the Specification Does Not Identify a Concrete Technical Problem in a Computer-Implemented Transaction System Sufficient to Establish Patent Eligibility.
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that the Applicant's argument that the specification identifies a concrete technical problem inherent in computer-implemented transaction protocols specifically that fraud arises from previously unknown execution sequences that place platforms into invalid or unsafe states, and that such protocol-level vulnerabilities cannot be detected by conventional rule-based or statistical approaches has been carefully considered but does not overcome the rejection, and the rejection is maintained for the following reasons.
The Examiner acknowledges the well-established principle that a specification that identifies a technical problem and explains the details of an unconventional technical solution expressed in the claim can support a finding that the claim integrates a judicial exception into a practical application. See MPEP2106.05(a); McRO, Inc. v. Bandai Namco Games Am. Inc. However, the threshold requirement is not merely that the specification identifies a problem the specification must describe the claimed invention in a manner that would make an improvement to computer technology or to another technology or technical field apparent to one of ordinary skill in the art, and critically, the claim itself must reflect that disclosed improvement. MPEP2106.04(d)(1); MPEP2106.05(a); Ex Parte Desjardins. That two-part requirement is not satisfied here.
With respect to the first part of the inquiry whether the specification describes an improvement to a technology or technical field the present specification identifies a problem that is financial and economic in nature: fraudulent actors exploit sequences of permitted transactions to obtain net negative losses for platform operators (see, e.g., spec. at par. [0013]–[0018]). While Applicant characterizes this as a problem of "computer system reliability, correctness, and security," the specification's own framing reveals that the fundamental issue being addressed is the financial harm caused by exploitative transaction sequences, not a failure or deficiency in how any underlying computer component the graph model, the simulation engine, the LLM, or the online transaction platform functions as a computational system. The specification at par. [0018] identifies the problem as one where "payment protocol analysis is performed by hand and prone to errors" and where "actual implementation in the code may not match the theoretical equivalent of the language used to describe it" a description of a business process accuracy problem, not a technical deficiency in computer architecture, memory, processing, or network operations. The specification at par. [0019] characterizes the disclosed technology as an "artificial intelligence-based self-learning and self-testing process flow" that "can be used to analyze network based protocols" language describing the use of AI to perform a financial analysis function, not language describing an improvement to how AI, graph modeling, or simulation technology itself operates. This distinction is controlling: an improvement to the abstract idea itself here, an improved method of detecting and remediating financial fraud is not an improvement in technology. See MPEP2106.05(a); Trading Technologies Int'l v. IBG, (a claimed interface that provided a trader with more information to facilitate market trades improved the business process of market trading, but did not improve computers or technology); see also October 2019 Update, Appendix 1 (using a computer to automate abstract mental processes that humans previously performed does not improve computer functionality or other technology even if it improves the efficiency of the underlying process).
With respect to the second part of the inquiry whether the claims reflect any improvement that the specification does describe even assuming arguendo that the specification could be read to describe an improvement to simulation technology or protocol modeling through exhaustive state-space exploration, the amended claims do not recite any particular technical mechanism by which that simulation improvement is achieved. Amended claim 1 recites only that a simulation engine simulates a workflow "by exploring a state space comprising sequences of transactions represented in the workflow and checking for invariants at each step" language that covers any method of state-space exploration and invariant checking without specifying any particular technical architecture, algorithm, or structural improvement to how the simulation engine operates. This is precisely the type of broadly claimed functional language that fails to reflect a specific improvement disclosed in the specification. Compare Affinity Labs of Tex., LLC v. DirecTV, LLC, (claims ineligible where specification failed to provide details regarding the manner in which the invention accomplished the alleged improvement) with McRO, (claims eligible where the specific rules recited in the claim were the very mechanism by which the technological improvement in animation was achieved). Similarly, the specification's description at par. [0033] that the simulation process module "exhaustively searches each possible state spaces and prunes redundant or unnecessary repeat loops to avoid state space explosion" is a description of a functional goal of the simulation, not a disclosure of a novel technical mechanism for achieving improved simulation performance that is reflected in the claim. The claim contains no limitation corresponding to any particular state-space pruning technique, any specific invariant-checking mechanism, or any other technical detail that would tie the claim to a specific improvement in simulation technology.
In sum, the specification identifies a problem of financial fraud susceptibility in online transaction platforms and proposes using known computational tools graph modeling, embedding, LLM-based workflow generation, and formal state-space simulation to address that problem. Identifying a problem in the domain in which an abstract idea is applied, and then proposing to apply known computational tools to address that problem, does not transform the abstract idea into a patent-eligible improvement in computer technology or in any other technology or technical field. The rejection has been maintained.
The Applicant argues on pages 3-5 that the “Amended Claim 1 Does Not Recite a Technical Solution Rooted in Computer Technology”.
The Examiner respectfully disagrees.
With respect to the arguments the Examiner notes that the Applicant's argument that amended claim 1 recites a technical solution rooted in computer technology specifically through the sub-arguments that (1) the claim provides formal modeling of computer-executable transaction behavior via transaction graphs and historical graph embeddings, (2) the use of a large language model to convert graph patterns constitutes an automated transformation into a machine-executable formal workflow, and (3) the identification of violating execution sequences via state-space exploration and direct modification of platform execution behavior constitute a non-abstract technical implementation has been carefully considered but does not overcome the rejection, and the rejection is maintained for the following reasons.
At the outset, the Examiner acknowledges the important caution from Ex Parte Desjardins, as incorporated into revised MPEP2106.05(a), that examiners and panels "should not evaluate claims at such a high level of generality" that potentially meaningful technical limitations are dismissed without adequate explanation. The Examiner has applied this guidance and has carefully evaluated each of the three sub-arguments in turn, considering the claim limitations specifically and in ordered combination. The determination that the claims do not recite a technical solution rooted in computer technology is not a result of dismissing claim elements in isolation; it is based on the affirmative finding that, when each limitation is given its full weight and the claim is read as a whole, the additional elements do not reflect a disclosed improvement to any computer technology or technical field as required under MPEP2106.04(d)(1) and 2106.05(a).
With respect to Applicant's first sub-argument that the claim's recitation of accessing historical order data including journal entries, generating transaction graphs wherein accounts are nodes and transactions are edges, and embedding those graphs to generate historical graph embeddings constitutes "formal modeling of computer-executable transaction behavior" and not mere data gathering the Examiner is not persuaded. The relevant inquiry under MPEP2106.05(f) is whether the claim recites only the idea of a solution or outcome, failing to provide details of how that solution is accomplished, or whether it covers a particular technical solution to a problem. See MPEP2106.05(f). Here, the step of generating a transaction graph "wherein accounts are represented as nodes and transactions are represented as edges" is a functional recitation of a graph data structure that covers any implementation of that structure without specifying any particular technical architecture, algorithm, or mechanism for building or operating such a graph. Similarly, the step of "embedding, by a graph model, the transaction graphs to generate historical graph embeddings" recites only the outcome the generation of graph embeddings without specifying any particular graph model architecture, embedding algorithm, or technical mechanism by which the embedding is performed. This is directly analogous to the analysis in USPTO Example 47 (Claim 2), in which "using a trained ANN" was found to provide nothing more than mere instructions to implement an abstract idea on a generic computer because the claim omitted any details as to how the ANN operates to solve a technical problem and instead recited only the idea of a solution or outcome. See 2024 AI SME Update Examples at 10. The mere designation of a computational component a "graph model" to perform the embedding does not, without any recitation of the particular way that component operates to provide a technical improvement, transform the abstract idea into a patent-eligible technical solution. Enfish, (eligibility arose from the specific data structure recited in the claims in combination with the specification's discussion of how the claimed structure improved database performance not simply from the recitation that a database was used).
With respect to Applicant's second sub-argument that the use of a large language model to convert graph patterns "into a workflow corresponding to a format usable by a simulation engine" constitutes an automated transformation into a machine-executable formal workflow the Examiner similarly is not persuaded. Applicant argues this step is equivalent to the transformation recognized in McRO and Visual Memory as reflecting an improvement in how computers process information. This analogy fails for a critical reason: in McRO, the specific rules recited in the claim were themselves the technical mechanism that enabled the disclosed improvement the automation of animation tasks that previously could not be automated and the claims recited those specific rules with sufficient particularity that the claim covered only those solutions that used that particular rule structure. McRO. In Visual Memory, the claimed memory system with programmable operational characteristics configurable based on processor type was a specific technical architecture for memory management. Visual Memory. By contrast, amended claim 1's recitation of "utilizing a large language model to convert the graph patterns into a workflow corresponding to a format usable by a simulation engine" covers any large language model performing any conversion of any graph patterns into any workflow format without specifying any particular mechanism by which the LLM performs the conversion, what technical constraints govern the conversion, or how the resulting workflow format technically improves the simulation engine's operation. This is a functional result-oriented recitation the output is a workflow usable by a simulation engine without any technical detail of how that result is achieved. Claims that recite only the idea of a solution or a desired outcome, without specifying how that outcome is technically achieved, are precisely the type of claims that the Federal Circuit has found to amount to mere instructions to apply an exception, regardless of how sophisticated the named component (here, a large language model) may be in the abstract. See Electric Power Group, LLC v. Alstom S.A., (cautioning against claims "so result focused, so functional, as to effectively cover any solution to an identified problem").
With respect to Applicant's third sub-argument that the simulation step, the identification of an invariant-violating sequence, and the implementation of a policy update or code enhancement collectively constitute a technological solution through root-cause isolation and runtime system control the Examiner maintains the rejection for the same core reasons. The claim's recitation of "simulating, at the simulation engine, the workflow by exploring a state space comprising sequences of transactions represented in the workflow and checking for invariants at each step" covers any method of state-space exploration and invariant checking, using any simulation engine, without specifying any particular technical mechanism or novel architecture by which the simulation is performed. The step of "identifying a first sequence of transactions that led to the invariant violation" is a functional description of a desired output of the simulation identifying a specific transaction sequence without specifying how the identification is technically accomplished beyond performing the simulation. And the step of "implementing, on the online transaction platform, a policy update or a code enhancement corresponding to a fix based on the first sequence of transactions to modify execution of future transactions... to eliminate the exploit" is the broadest possible functional description of applying any remediation to a platform, covering any policy update or code change, implemented by any means, corresponding to any fix derived from the identified sequence, without specifying any technical mechanism by which the platform's execution logic is modified. This is fundamentally distinct from the eligible claim in Ex Parte Desjardins, where the specific claimed limitation "adjust the first values of the plurality of parameters to optimize performance of the machine learning model on the second machine learning task while protecting performance of the machine learning model on the first machine learning task" was found to reflect a disclosed improvement to how the machine learning model itself operates, specifically overcoming "catastrophic forgetting" in the model's technical architecture. Ex Parte Desjardins. The present claims contain no analogous limitation that reflects how the underlying computational components the graph model, the LLM, the simulation engine, or the transaction platform are technically modified or improved in their operation. The claim instead specifies what functions are to be performed and what results are to be achieved, without specifying the technical means by which those results are reached. Such result-oriented functional claiming, even when applied to a domain that involves complex computational steps, does not constitute a technical solution rooted in computer technology within the meaning of the applicable eligibility guidance and controlling case law. The rejection has been maintained.
The Applicant argues on page 5 that "The Office action’s characterization of the claims as “Apply It” is incorrect”.
The Examiner respectfully disagrees.
In response to the argument the Examiner notes that the Applicant argues that the Office Action improperly characterized the claims as merely "applying" an abstract idea using generic computer components, contending that the Office Action repeatedly divided the claims into "abstract" and "additional" elements and dismissed each technical feature as "insignificant extra-solution activity," inconsistently with Federal Circuit precedent requiring consideration of the claim as a whole. Applicant further argues that as a whole, amended claim 1 recites a combination of elements transaction graphs, executable workflows, state-space simulation, invariant enforcement, and automated platform modification that provides a technical improvement and is not properly characterized as an "apply it" claim. These arguments have been carefully considered but are not persuasive, and the rejection is maintained for the following reasons.
The Examiner first addresses Applicant's procedural objection regarding claim analysis methodology. The August 4, 2025 Memorandum from Deputy Commissioner for Patents expressly cautions that "examiners are cautioned not to oversimplify claim limitations and expand the application of the 'apply it' consideration." August 2025 Memo at 3. The Examiner has applied this guidance and has not dismissed the claim elements by reducing the claim to its broadest concept. Rather, as the guidance in MPEP2106.05(f) requires, the Examiner evaluated each additional element individually and in combination, applying the three governing considerations: (1) whether the claim recites only the idea of a solution or outcome without details of how that solution is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception. MPEP2106.05(f); August 2025 Memo at 3. Applying these three considerations carefully to the claim as a whole not in isolation confirms that the "apply it" characterization is correct, as demonstrated below.
With respect to consideration (1) whether the claim recites only the idea of a solution or outcome the Examiner maintains that each substantive step in amended claim 1 is recited at a level of generality that covers any means of achieving the stated functional result, without specifying the technical mechanism by which that result is achieved. The step of "generating, for each order of the plurality of orders, a transaction graph based on journal entries of the order, wherein accounts are represented as nodes and transactions are represented as edges" describes a desired output a transaction graph with a node-edge structure but does not specify any particular algorithm, architecture, or technical mechanism for constructing that graph. The step of "embedding, by a graph model, the transaction graphs to generate historical graph embeddings" recites the outcome of the embedding process without specifying any particular graph model type, embedding dimension, training methodology, or technical architecture that constrains how the embedding is performed. The step of "utilizing a large language model to convert the graph patterns into a workflow corresponding to a format usable by a simulation engine" recites the desired output a simulation-engine-compatible workflow without specifying any particular LLM architecture, prompt structure, output format specification, or conversion mechanism. The step of "simulating, at the simulation engine, the workflow by exploring a state space comprising sequences of transactions represented in the workflow and checking for invariants at each step" describes what the simulation engine does explore a state space and check invariants without specifying any particular state-space traversal algorithm, invariant specification language, or simulation architecture. And the step of "implementing, on the online transaction platform, a policy update or a code enhancement corresponding to a fix... to eliminate the exploit" describes the desired result elimination of the exploit through some unspecified policy or code change without specifying any particular implementation mechanism. Each of these limitations, precisely as in Electric Power Group, describes "the effect or result dissociated from any method by which" the result is accomplished, and a claim that "generically recites an effect of the judicial exception or claims every mode of accomplishing that effect, amounts to a claim that is merely adding the words 'apply it' to the judicial exception." MPEP2106.05(f); Electric Power Group, LLC v. Alstom S.A.
With respect to consideration (2) whether the claim invokes computers and machinery merely as tools to perform an existing process the claim's recitation of a "graph model," a "large language model," and a "simulation engine" does not alter this analysis because none of these components is described or claimed in any technically specific or non-generic manner. The graph model is recited generically as performing an embedding; the large language model is recited generically as performing a conversion; and the simulation engine is recited generically as performing simulation. These are precisely the circumstances described in the USPTO's 2024 AI SME Update Examples: where a "DNN is used to generally apply the abstract idea… without placing any limitation on how the component operates," the limitation amounts to mere instructions to implement an abstract idea on a generic computer. 2024 AI SME Update Examples at 20. Applicant's argument that naming multiple sophisticated computational components a graph model, an LLM, and a simulation engine removes the claim from the "apply it" category misapprehends the applicable analysis. The question is not whether the named components are sophisticated in the abstract, but whether the claim specifies how those components operate in any technically constrained or non-generic way. Here it does not, and the claim accordingly uses those components as tools to perform the abstract idea of financial fraud detection and remediation, not as elements of a technically improved system. See MPEP2106.05(f).
With respect to consideration (3) the particularity or generality of the application of the judicial exception the breadth of amended claim 1 further confirms the "apply it" characterization. The claim as written encompasses any online transaction platform, any historical order data format, any graph model performing any embedding technique, any large language model performing any format conversion, any simulation engine performing any state-space exploration methodology, any invariant specification, any policy update or code enhancement, and any mechanism for modifying platform execution. A claim of such breadth, covering every conceivable technical implementation of the abstract idea of detecting and remediating financial transaction exploits through graph-based modeling and simulation, cannot be said to impose a meaningful limit on the abstract idea. MPEP2106.05(f) (a "claim having broad applicability across many fields of endeavor may not provide meaningful limitations that integrate a judicial exception into a practical application or amount to significantly more"). The present claim is not analogous to DDR Holdings, where the claims specified precisely how Internet hyperlink protocol interactions were to be manipulated to override conventional behavior in a technically specific way the present claims specify no comparable technical constraint on how any of the named computational components operate.
Finally, the Examiner acknowledges Applicant's contention that the claim elements must be considered "as an ordered combination" per Alice Corp. The Examiner has considered the claim as an ordered combination throughout this analysis. Viewing the steps in sequence accessing data, building a graph, embedding it, generating graph patterns, converting patterns to a workflow via LLM, simulating the workflow, identifying violating sequences, and implementing a fix the ordered combination describes a pipeline for performing the abstract idea of financial exploit detection and remediation using a series of generic computational tools, each recited at a functional level of generality. The ordering of these steps does not add technical specificity to any individual step, does not constrain the technical implementation of any component, and does not create a non-generic technical interaction among the components that would distinguish the claim from a straightforward application of the abstract idea. Under both Alice and the USPTO's governing guidance, an ordered combination of steps that, individually and collectively, amount to instructions to apply an abstract idea using generic computational components does not overcome the "apply it" deficiency. See MPEP2106.04(d); MPEP2106.05(f). The rejection under 35 U.S.C.101 is accordingly maintained.
The Applicant argues on pages 5-6 that “the claims improve a technical field, not a business practice”.
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that the Applicant argues that the examiner's characterization of the claims as directed to "financial fraud detection" improperly oversimplifies the claims and that the focus of amended claim 1 is not a business decision but rather "computer-implemented protocol correctness, state-safety enforcement in transaction platforms, and automated remediation of execution-level vulnerabilities." Applicant further relies on Affinity Labs of Tex., LLC v. DIRECTV, LLC, contending that courts look to the "focus of the claimed advance over the prior art" and that the focus here is an improvement to how online transaction systems are modeled, verified, and controlled. These arguments have been carefully considered but are not persuasive, and the rejection is maintained for the following reasons.
At the outset, the Examiner's characterization of the underlying abstract idea is not a dismissive oversimplification of the claims it is a proper Step 2A, Prong One identification of the judicial exception recited in the claim. As the USPTO's training guidance makes clear, the relevant question in Step 2A, Prong One is whether the claim recites a judicial exception. The core concept that the claims revolve around identifying exploitative sequences of financial transactions on a payment platform and implementing corrective measures to prevent financial harm directly maps to the established category of "certain methods of organizing human activity," specifically fundamental economic principles or practices, including mitigating financial risk and detecting fraud in financial transactions. See MPEP2106.04(a)(2); Bozeman Financial LLC v. Federal Reserve Bank of Atlanta, (claims to methods for detecting fraud in financial transactions during a payment clearing process are directed to a fundamental economic principle or practice). This characterization is not altered by the sophistication of the computational tools used to implement the concept, nor by Applicant's choice of technical vocabulary to describe the concept. The term "fundamental" in this context does not require the concept to be old or well-known even new methods of achieving fundamentally economic goals, such as detecting and preventing fraudulent financial activity, fall within this category. See MPEP2106.04(a)(2) (citing OIP Techs., Inc. v. Amazon.com, Inc. Applicant's reframing of the claims as directed to "protocol correctness" and "state-safety enforcement" does not change the fundamental economic nature of the goal being pursued ensuring that a financial transaction platform does not suffer net losses as a result of exploitative transaction sequences is a financial risk mitigation objective, regardless of whether it is dressed in the vocabulary of formal verification or computer science.
With respect to Applicant's reliance on Affinity Labs for the proposition that courts look to the "focus of the claimed advance over the prior art" to determine the claim's character as a whole the Examiner agrees with this principle and has applied it. The Federal Circuit in Affinity Labs stated that courts look to "the focus of the claimed advance over the prior art, to determine... the claim's 'character as a whole,'" not to "a generalized description of the field." Affinity Labs. Applying this principle here, the focus of the claimed advance in amended claim 1 is the automated detection of exploitative transaction sequences in a financial payment platform and the automated implementation of corrections to prevent future financial harm. That is a financial fraud mitigation advance, not an advance in graph modeling technology, LLM architecture, simulation engine design, or any other underlying computer technology. The use of graph models, LLMs, and simulation engines as tools to achieve that financial objective does not shift the focus of the advance from the financial domain to the computer technology domain, any more than the use of a computer to implement intermediated settlement shifted the focus of the advance in Alice Corp. from financial settlement to computer technology. Alice Corp. Pty. Ltd. v. CLS Bank Int'l. The critical point, which Affinity Labs itself underscores, is that the court held the claims in that case ineligible despite Applicant's invocation of the case for support because limiting a concept to a particular technological environment (cellular telephones for out-of-region broadcast content delivery) did not transform the abstract idea into a patent-eligible improvement. Affinity Labs. Similarly, here, limiting the abstract idea of financial exploit detection and remediation to the technological environment of an online transaction platform with graph-based modeling and simulation does not transform the abstract idea into an improvement in computer technology or any other technology or technical field. See MPEP2106.05(h).
Moreover, the controlling principle from MPEP2106.05(a) is directly on point: "an improvement in the abstract idea itself (e.g., a recited fundamental economic concept) is not an improvement in technology." MPEP2106.05(a); see also Trading Technologies Int'l v. IBG, (a user interface that provided a trader with more information to facilitate market trades improved the business process of market trading, but did not improve computers or technology). Even crediting Applicant's characterization that the claimed pipeline improves how financial transaction systems are modeled and verified, any such improvement is an improvement to the financial fraud detection process itself an improvement to the abstract idea and not an improvement to the computer technology, graph modeling techniques, LLM performance, or simulation architectures that are used as tools to implement that process. See also In re Board of Trustees of Leland Stanford Junior Univ., (concluding that an improvement in "the accuracy of a mathematically calculated statistical prediction" was an improvement to the abstract idea rather than to another technology). Applicant's further assertion that the claims are directed to "computer-implemented protocol correctness" and "state-safety enforcement" is a characterization of the domain in which the abstract idea is applied, not a demonstration that the underlying computer technology the graph model, the LLM, or the simulation engine is itself improved. Labeling a financial fraud mitigation system as a "protocol correctness" system does not change the nature of the financial protection being achieved, nor does it supply the missing improvement to any computer or technical component that is required for patent eligibility under controlling precedent and USPTO guidance. The rejection under 35 U.S.C.101 is accordingly maintained.
The Applicant argues on pages 6 that “The Claims Do Not Recite an Inventive Concept Providing “Significantly More” (Step 2B)”.
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that Applicant argues, in the alternative, that even if the claims are directed to an abstract idea, they are patent-eligible under Step 2B because they include an inventive concept specifically, an ordered combination of limitations that is not well-understood, routine, or conventional, and that meaningfully transforms the alleged abstract idea into a specific technological implementation. Applicant invokes BASCOM Global Internet Servs., Inc. v. AT&T Mobility LLC, Berkheimer v. HP Inc., and Alice Corp., in support of this position, and contends that (A) the ordered combination is non-conventional, (B) the claims do more than apply an abstract idea on a generic computer, (C) the claimed combination is not well-understood, routine, or conventional, (D) the claims recite more than result-oriented functional language, and (E) the claims effect a technological transformation of the system. These arguments have been carefully considered but are not persuasive, and the rejection is maintained for the following reasons.
At the outset, the Examiner acknowledges the governing framework at Step 2B: the additional elements must be evaluated both individually and in combination to determine whether they amount to significantly more than the judicial exception. MPEP2106.05. The Examiner further acknowledges, consistent with BASCOM, that an inventive concept may be found in a non-conventional and non-generic arrangement of additional elements even where each element, when considered individually, is known and conventional. BASCOM, 827 F.3d at 1350–51. However, the BASCOM holding is not unlimited: the non-conventional arrangement must itself constitute a specific, technically meaningful departure from conventional computer implementation that provides a technical improvement in BASCOM, it was the specific installation of a filtering tool at a remote ISP server location, with customizable filtering features specific to each individual end-user, that created the non-conventional arrangement. Id. Here, no analogous specific, technically non-conventional arrangement is present in the amended claims, for the reasons set forth below.
The Applicant argues on page 7 that the “inventive concept can reside in a non-conventional combination”.
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that the Applicant argues that the specific pipeline comprising (i) formal transaction-graph construction, (ii) machine-generated executable workflows, (iii) state-space simulation with invariant checking, (iv) identification of violating execution sequences, and (v) automated modification of platform execution logic is neither conventional nor generic as an ordered combination. The Examiner does not dispute that this specific combination of steps may not have been previously employed in exactly this sequence in a single prior art reference. However, the MPEP and controlling case law are clear that the Step 2B inquiry is not a novelty analysis under 35 U.S.C.102. See MPEP2106.05 ("The search for an inventive concept is thus distinct from demonstrating102 novelty"). The critical question is not whether the combination is novel, but whether it amounts to more than the sum of generic components performing their generic functions in sequence. Alice, (the combination of additional elements adds "nothing... that is not already present when the steps are considered separately" where each step performs nothing more than its generic function). Here, each step in the claimed pipeline accessing historical data, generating transaction graphs, embedding those graphs, converting patterns via a large language model, simulating workflows, identifying violations, and implementing a fix individually performs its generic function in a generic manner, and the combination of these steps into a sequential pipeline does not create a non-conventional technical interaction among those components that departs from conventional computer operation. The combination amounts to a series of generic data processing steps applied sequentially to implement the abstract idea of financial fraud detection and remediation, which is precisely the combination the Supreme Court in Alice held insufficient to supply an inventive concept. The rejection is therefore maintained.
The Applicant argues on page 6 that the “the claims do more than Apply It on a generic computer”.
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that the Applicant argues that the Office Action's assertion that the claims merely apply an abstract idea using generic computing components is legally insufficient where the claim recites a specific technical implementation, and that amended claim 1 recites a "non-conventional architecture" for transaction-system verification and remediation that goes beyond generic data analysis. Specifically, Applicant contends that: (1) the claim does not merely analyze data but converts transaction behavior into executable workflows, performs state-space exploration with invariant enforcement, and feeds results back into the transaction platform to alter future execution; and (2) this constitutes a "control and remediation loop" rather than a generic data-processing task. These arguments have been carefully considered but are not persuasive, and the rejection is maintained for the following reasons.
The governing legal standard for the "apply it" consideration under MPEP 2106.05(f) is well-established: a claim that invokes computers or other machinery merely as tools to perform an existing process, without purporting to improve computer capabilities or an existing technology, does not provide significantly more than the abstract idea itself. MPEP 2106.05(f). The Examiner is required to evaluate whether the claim recites: (1) only the idea of a solution or outcome without the specific details of how that solution is accomplished; (2) computers or machinery merely as tools to perform an existing process rather than as improvements to those technologies; and (3) a specific or general application of the judicial exception. August 2025 Memo at 3; MPEP 2106.05(f). Applying each of these considerations to the amended claims confirms that the rejection is properly maintained.
With respect to consideration (1) whether the claim recites only the idea of a solution or outcome the Examiner has consistently found, and maintains, that each operative limitation of amended claim 1 is recited at a level of functional generality that covers any technical means of achieving the stated result, without constraining those means in any technically specific way. Applicant's characterization that the claim "converts transaction behavior into executable workflows" and "performs state-space exploration with invariant enforcement" accurately describes what the claim says at a functional level, but this description does not demonstrate that the claim specifies how those functions are technically accomplished. The step of "utilizing a large language model to convert the graph patterns into a workflow corresponding to a format usable by a simulation engine" names the component (a large language model) and the output format (simulation-engine-compatible workflow) without specifying any particular LLM architecture, conversion process, output grammar, or protocol specification that would constrain the claim to a specific technical implementation. The step of "simulating, at the simulation engine, the workflow by exploring a state space comprising sequences of transactions… and checking for invariants at each step" names the activity (state-space simulation with invariant checking) and the output (identification of an invariant violation) without specifying any particular state-space traversal algorithm, pruning heuristic, invariant specification language, or simulation architecture. These are functional descriptions of what the claim achieves, not specifications of how the claimed functions are technically accomplished and claims that describe only what result is to be achieved, without specifying the technical means of achieving it, fall squarely within the type of claims the Federal Circuit has identified as mere instructions to "apply it." See Electric Power Group, LLC v. Alstom S.A., (cautioning against claims "so result focused, so functional, as to effectively cover any solution to an identified problem"); Intellectual Ventures I LLC v. Capital One Fin. Corp., (claims held ineligible where additional limitations "provided only a result-oriented solution and lacked details as to how the computer performed the modifications, which was equivalent to the words 'apply it'").
With respect to consideration (2) whether the computers and machinery in the claim are invoked merely as tools to perform an existing process Applicant's contention that the claims recite a "non-conventional architecture" is not supported by the claim language. The claim does not recite any particular architecture it names components (a graph model, a large language model, a simulation engine, an online transaction platform) and describes what those components do at a functional level, but imposes no architectural constraint on how those components are arranged, how they communicate with one another, or how they are technically implemented. The named components are used in their ordinary functional capacities: the graph model performs graph embedding (as graph models are designed to do), the LLM performs format conversion (as LLMs are designed to do), the simulation engine performs simulation (as simulation engines are designed to do), and the transaction platform is updated to implement a fix (as transaction platforms are designed to receive updates). This is precisely the scenario the courts have consistently identified as invoking computers merely as tools to perform an existing process. See TLI Communications LLC v. AV Auto. LLC, (claims invoking telephone unit and server in their ordinary capacities to perform abstract steps found ineligible because the components were used merely as tools to execute the abstract idea); Versata Dev. Group, Inc. v. SAP Am., Inc., (generic computer performing its ordinary functions insufficient). Moreover, simply using the word "architecture" to describe the combination of pipeline steps, as Applicant does, does not create an unconventional technical architecture the substance of the claim language governs, not the characterization of that language in the applicant's brief.
Applicant's characterization of the claiming as a "control and remediation loop" contrasting it with a "generic data-processing task" is also unavailing. The "control and remediation loop" Applicant describes consists of: (a) detecting a problem (an invariant-violating transaction sequence), (b) identifying the source of the problem (the specific violating sequence), and (c) implementing a fix (a policy update or code enhancement to prevent recurrence). This is precisely the structure of the well-known detect-analyze-respond pattern found throughout security, fraud detection, and system monitoring contexts, and is the type of functional pattern courts have consistently found to reflect an abstract idea when claimed at the level of generality present here. See, e.g., FairWarning IP, LLC v. Iatric Sys., (claims to monitoring audit log data for anomalies and alerting users constituted a mental process performed on a generic computer); Bozeman Fin. LLC v. Fed. Reserve Bank of Atlanta, (fraud detection in financial transactions during a payment clearing process is a fundamental economic practice). The fact that Applicant labels this detect-analyze-respond pattern a "control and remediation loop" does not change its fundamental character as the application of an abstract detect-and-fix process to the domain of online financial transaction platforms. Merely adding the label of a "control loop" to a functionally described process does not supply the specific technical implementation necessary to move beyond "apply it." See MPEP 2106.05(f).
Furthermore, the Examiner notes that Applicant's characterization of the claim as creating "a non-conventional architecture for transaction-system verification and remediation" is not supported by the specification itself. As the Examiner has previously noted, the specification at par. [0028] characterizes the underlying methodology as "a classical mathematics-based protocol modeling methodology" not as a novel or non-conventional architecture. The use of the term "classical" in the specification directly undermines Applicant's assertion that the architecture is non-conventional, providing intrinsic evidence supporting the Examiner's position. See MPEP 2106.05(d)(I)(A); Intellectual Ventures I v. Symantec Corp. Accordingly, because the claims invoke the named computational components in their ordinary functional capacities to perform the abstract idea of financial fraud detection and remediation, without specifying any particular technical mechanism, architecture, or arrangement that departs from the conventional use of those components, the claims do not do more than apply the abstract idea on a generic computer. The rejection under 35 U.S.C. 101 is maintained.
The Applicant argues on page 8 that “the claimed combination is not well-understood, routine or conventional”.
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that the Applicant argues that the Office Action summarily concluded that the limitations are well-understood, routine, and conventional without providing sufficient factual support, and invokes Berkheimer for the proposition that such a determination is a question of fact requiring evidentiary support. The Examiner acknowledges that Berkheimer requires the conventional nature conclusion to be supported in writing by one of the options set forth in MPEP2106.05(d), subsection III. The present rejection satisfies this requirement through Option (A) citation to express statements in the specification itself. See MPEP2106.05(d)(I)(A). Specifically, the specification at par. [0028] expressly describes the exploit remediation system as leveraging "a classical mathematics-based protocol modeling methodology," directly characterizing the underlying computational approach as classical i.e., known and established. The specification at par. [0032] describes the large language model as implementing "a math-based language for modeling computer programs and systems (e.g., Temporal Logic of Actions, Plus (TLA+))," identifying the specific language used TLA+ as a known, established formal modeling tool, not a novel invention of the Applicant. The specification at par. [0033] describes the simulation process module as performing exhaustive state-space exploration and invariant checking, which are well-known techniques in the field of formal verification. These descriptions of the claimed components as implementing known, classical computational methodologies (mathematics-based protocol modeling, TLA+ formal specification, state-space exploration, invariant checking) directly demonstrate that the individual elements of the claimed combination, as described in the specification, are well-understood and conventional techniques in the relevant art. See MPEP2106.05(d)(I)(A); Intellectual Ventures I LLC v. Symantec Corp., ("The written description is particularly useful in determining what is well-known or conventional"). This intrinsic factual support is sufficient to sustain the well-understood, routine, and conventional finding for each of the individual additional elements.
The Combination of These Individually Conventional Elements Does Not Create a Non-Conventional Arrangement. Applicant's reliance on BASCOM for the proposition that a non-conventional ordered combination of individually conventional elements can supply an inventive concept is correct as a statement of law but does not apply to the facts here. The critical distinction between BASCOM and the present claims is that in BASCOM, the court identified a specific, technically unconventional aspect of the arrangement the placement of the filtering tool at the ISP server level, remote from end users, with per-user customizability that departed from what was conventional in the art and provided a specific technical improvement. BASCOM. The arrangement was non-conventional because conventional content filtering was not performed in that specific location with those specific capabilities in the prior art. Here, by contrast, Applicant has not identified and the claims do not recite any specific technical feature of the combination that constitutes a non-conventional departure from how these computational components (graph models, LLMs, simulation engines, and transaction platforms) are conventionally arranged or caused to interact. The sequential pipeline of: access data - generate graph - embed - generate patterns - convert via LLM - simulate - identify violation - implement fix, represents a conventional logical ordering of data processing and remediation steps in which each component performs its generic function without any non-conventional technical interaction between components. This is materially different from BASCOM, where the specific location and architecture of the filter not merely its sequential position in a data processing pipeline was the source of the non-conventional arrangement.
The Claims Recite Result-Oriented Functional Language, Not a Specific Non-Conventional Implementation. Applicant argues that amended claim 1 specifies "how" the result is achieved through concrete technical steps, and thus recites more than result-oriented functional language. However, as the Examiner has explained in connection with the Step 2A, Prong Two analysis above, each substantive limitation is recited at a level of functional generality that covers any technical implementation of the stated function. The implementing step "implementing, on the online transaction platform, a policy update or a code enhancement corresponding to a fix based on the first sequence of transactions to modify execution of future transactions... to eliminate the exploit" is a paradigmatic example of result-oriented functional claiming that specifies a desired outcome without constraining the technical means by which it is achieved. See Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348 (Fed. Cir. 2015) (a claim limitation that describes "the effect or result dissociated from any method by which" the result is accomplished does not provide a meaningful limitation). The claim covers any policy update or code enhancement, implemented by any mechanism, that eliminates the identified exploit. This is not a specific technical implementation; it is a broadly stated functional goal, and such broadly stated functional goals do not supply an inventive concept at Step 2B regardless of how they are characterized.
The Alleged Technological Transformation Does Not Supply the Required Inventive Concept. Finally, Applicant argues that Step 2B favors eligibility because amended claim 1 effects a technological transformation the identification of invariant-violating sequences leading directly to modification of platform execution logic. As previously explained, the "implementing" step is recited at a level of generality that covers any mechanism of platform modification, and the claim does not specify any technically non-conventional mechanism by which that modification is affected. Even under the most favorable reading of Alice, a claim that effects a transformation only through the execution of the abstract idea on a generic computing system, without any specific, unconventional technical mechanism for achieving that transformation, does not supply an inventive concept. Alice. The alleged transformation here applying the results of simulation to modify a platform is the natural result of performing the abstract idea, not a technically non-conventional step beyond the abstract idea. Accordingly, the rejection under 35 U.S.C.101 at Step 2B is maintained.
The Applicant argues on page 7 that the “Inventive Concept can reside in a non-conventional ordered combination”.
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that the Applicant argues that the rejection in the Office Action repeatedly evaluates individual claim elements in isolation characterizing embedding, simulation, and processors as generic or conventional and then fails to consider whether their particular arrangement creates an inventive concept, contrary to BASCOM Global Internet Servs., Inc. v. AT&T Mobility LLC. Applicant contends that amended claim 1 is not directed to any one generic technique, but to a specific pipeline that combines formal transaction-graph construction, machine-generated executable workflows, state-space simulation with invariant checking, identification of violating execution sequences, and automated modification of platform execution logic, and that this ordered combination is neither conventional nor generic. These arguments have been carefully considered but are not persuasive for the reasons set forth below, and the rejection is maintained.
As a threshold matter, the Examiner agrees with the principle, as stated in BASCOM and codified in MPEP2106.05, that an inventive concept may reside in a non-conventional and non-generic arrangement of known, conventional elements, even where each individual element, when considered in isolation, is well-understood, routine, and conventional. BASCOM, 827; MPEP2106.05. The Examiner further confirms that the claim elements have been considered both individually and as an ordered combination in the Step 2B analysis, consistent with the requirements of Alice Corp., and MPEP2106.05. However, Applicant's argument incorrectly conflates the existence of a specific sequential pipeline with the existence of a non-conventional arrangement in the BASCOM sense. These are not the same thing, and BASCOM does not support the proposition that any multi-step pipeline combining known computational components constitutes an inventive concept simply because the specific combination has not been previously employed in exactly that sequence.
The critical distinction BASCOM draws and the one that is dispositive here is not merely that a combination of elements is present, but that the combination must reflect a specific, technically unconventional arrangement that departs from the conventional way those components operate and that provides a concrete technical benefit as a result of that non-conventional arrangement. In BASCOM, the non-conventional arrangement was the specific architectural decision to install the content filter at the ISP server level remote from end users in a way that allowed the filter to be customized per individual user. This was technically unconventional because conventional content filtering placed filters locally, at the client level, and the ISP-level placement with per-user customizability was a specific technical departure that enabled the system to achieve a filtering capability that was not achievable through the conventional arrangement. BASCOM. The inventive concept arose from the specific non-conventional architecture, not merely from the sequential combination of known filtering, network, and server components.
By contrast, the ordered combination in amended claim 1 accessing historical transaction data, generating transaction graphs, embedding those graphs, generating graph patterns, converting patterns via LLM into simulation-compatible workflows, simulating the workflows to identify invariant violations, identifying the violating sequence, and implementing a corrective fix does not describe any non-conventional technical interaction or architectural arrangement among those components. Each component operates in its generic, conventional capacity: the graph model performs embedding (as graph models conventionally do), the LLM performs text/format conversion (as LLMs conventionally do), the simulation engine performs state-space exploration (as simulation engines conventionally do), and the transaction platform implements a remediation fix (as platforms conventionally respond to identified problems). The components are chained together in a logical sequence to serve the goal of financial fraud detection and remediation, but there is no claim language specifying any particular technical mechanism by which those components interact with one another in a non-conventional way, any particular architectural constraint on how the pipeline is structured that departs from conventional practice, or any specific technical benefit flowing from the arrangement of the components themselves as distinguished from the abstract goal those components collectively pursue. The combination adds nothing beyond what each component adds individually, which is precisely what Alice identified as insufficient: "the computer components… add nothing... that is not already present when the steps are considered separately." Alice Corp.
Furthermore, the specification itself does not support Applicant's assertion that the claimed combination is non-conventional. As the Examiner has previously noted, the specification at par. [0028] expressly characterizes the underlying approach as "a classical mathematics-based protocol modeling methodology." The use of the word "classical" directly signals that the computational approach, considered as a whole, is established and known in the field it is not an unconventional arrangement. The specification at par. [0032] identifies TLA+ formal specification language, a well-established and widely-used formal verification tool, as the specific instantiation of the "math-based language" component. These characterizations provide intrinsic support per MPEP2106.05(d)(I)(A) and Intellectual Ventures I LLC v. Symantec Corp., that the claimed combination as described in the specification is a conventional arrangement of conventional techniques applied to a financial fraud detection objective, not a non-conventional arrangement giving rise to an inventive concept.
Applicant's reliance on BASCOM is also distinguishable from a claim scope perspective. In BASCOM, the claims were sufficiently specific to identify the non-conventional arrangement the ISP-level installation of the filter with per-user customizability and to confine the claim to that specific arrangement. The present claims, by contrast, are not confined to any specific technical arrangement of the pipeline components. The claim covers any graph model performing any embedding, any LLM performing any conversion, any simulation engine performing any state-space exploration, and any platform modification implementing any fix. Because the claim does not constrain the technical implementation of the pipeline in any way that would identify a non-conventional arrangement among the components, there is no specific arrangement that can serve as the basis for an inventive concept in the BASCOM sense. A pipeline that is claimed at such a high level of generality that it encompasses every possible technical implementation of a multi-step fraud detection and remediation process cannot be said to recite a non-conventional arrangement of its components it recites only the abstract goal of that pipeline and leaves every technical detail of the arrangement to the implementer's discretion. See Electric Power Group; Recentive Analytics, Inc. v. Fox Corp., (steps incidental to automating an abstract idea are not sufficient to confer eligibility). Accordingly, the rejection under 35 U.S.C.101 at Step 2B is maintained, and Applicant's argument that the inventive concept resides in the ordered combination is not persuasive.
The Applicant argues on pages 7-8 that the “Claims Do Not Do More Than Apply the Abstract Idea on a Generic Computer”.
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that the Applicant argues that the Office Action's assertion that the claims merely apply an abstract idea using generic computing components is legally insufficient where the claim recites a specific technical implementation, and that amended claim 1 recites a "non-conventional architecture" for transaction-system verification and remediation that goes beyond generic data analysis. Specifically, Applicant contends that: (1) the claim does not merely analyze data but converts transaction behavior into executable workflows, performs state-space exploration with invariant enforcement, and feeds results back into the transaction platform to alter future execution; and (2) this constitutes a "control and remediation loop" rather than a generic data-processing task. These arguments have been carefully considered but are not persuasive, and the rejection is maintained for the following reasons.
The governing legal standard for the "apply it" consideration under MPEP2106.05(f) is well-established: a claim that invokes computers or other machinery merely as tools to perform an existing process, without purporting to improve computer capabilities or an existing technology, does not provide significantly more than the abstract idea itself. MPEP2106.05(f). The Examiner is required to evaluate whether the claim recites: (1) only the idea of a solution or outcome without the specific details of how that solution is accomplished; (2) computers or machinery merely as tools to perform an existing process rather than as improvements to those technologies; and (3) a specific or general application of the judicial exception. August 2025 Memo at 3; MPEP2106.05(f). Applying each of these considerations to the amended claims confirms that the rejection is properly maintained.
With respect to consideration (1) whether the claim recites only the idea of a solution or outcome the Examiner has consistently found, and maintains, that each operative limitation of amended claim 1 is recited at a level of functional generality that covers any technical means of achieving the stated result, without constraining those means in any technically specific way. Applicant's characterization that the claim "converts transaction behavior into executable workflows" and "performs state-space exploration with invariant enforcement" accurately describes what the claim says at a functional level, but this description does not demonstrate that the claim specifies how those functions are technically accomplished. The step of "utilizing a large language model to convert the graph patterns into a workflow corresponding to a format usable by a simulation engine" names the component (a large language model) and the output format (simulation-engine-compatible workflow) without specifying any particular LLM architecture, conversion process, output grammar, or protocol specification that would constrain the claim to a specific technical implementation. The step of "simulating, at the simulation engine, the workflow by exploring a state space comprising sequences of transactions… and checking for invariants at each step" names the activity (state-space simulation with invariant checking) and the output (identification of an invariant violation) without specifying any particular state-space traversal algorithm, pruning heuristic, invariant specification language, or simulation architecture. These are functional descriptions of what the claim achieves, not specifications of how the claimed functions are technically accomplished and claims that describe only what result is to be achieved, without specifying the technical means of achieving it, fall squarely within the type of claims the Federal Circuit has identified as mere instructions to "apply it." See Electric Power Group, LLC v. Alstom S.A., (cautioning against claims "so result focused, so functional, as to effectively cover any solution to an identified problem"); Intellectual Ventures I LLC v. Capital One Fin. Corp., (claims held ineligible where additional limitations "provided only a result-oriented solution and lacked details as to how the computer performed the modifications, which was equivalent to the words 'apply it'").
With respect to consideration (2) whether the computers and machinery in the claim are invoked merely as tools to perform an existing process Applicant's contention that the claims recite a "non-conventional architecture" is not supported by the claim language. The claim does not recite any particular architecture it names components (a graph model, a large language model, a simulation engine, an online transaction platform) and describes what those components do at a functional level, but imposes no architectural constraint on how those components are arranged, how they communicate with one another, or how they are technically implemented. The named components are used in their ordinary functional capacities: the graph model performs graph embedding (as graph models are designed to do), the LLM performs format conversion (as LLMs are designed to do), the simulation engine performs simulation (as simulation engines are designed to do), and the transaction platform is updated to implement a fix (as transaction platforms are designed to receive updates). This is precisely the scenario the courts have consistently identified as invoking computers merely as tools to perform an existing process. See TLI Communications LLC v. AV Auto. LLC, (claims invoking telephone unit and server in their ordinary capacities to perform abstract steps found ineligible because the components were used merely as tools to execute the abstract idea); Versata Dev. Group, Inc. v. SAP Am., Inc., (generic computer performing its ordinary functions insufficient). Moreover, simply using the word "architecture" to describe the combination of pipeline steps, as Applicant does, does not create an unconventional technical architecture the substance of the claim language governs, not the characterization of that language in the applicant's brief.
Applicant's characterization of the claiming as a "control and remediation loop" contrasting it with a "generic data-processing task" is also unavailing. The "control and remediation loop" Applicant describes consists of: (a) detecting a problem (an invariant-violating transaction sequence), (b) identifying the source of the problem (the specific violating sequence), and (c) implementing a fix (a policy update or code enhancement to prevent recurrence). This is precisely the structure of the well-known detect-analyze-respond pattern found throughout security, fraud detection, and system monitoring contexts, and is the type of functional pattern courts have consistently found to reflect an abstract idea when claimed at the level of generality present here. See, e.g., FairWarning IP, LLC v. Iatric Sys., (claims to monitoring audit log data for anomalies and alerting users constituted a mental process performed on a generic computer); Bozeman Fin. LLC v. Fed. Reserve Bank of Atlanta, (fraud detection in financial transactions during a payment clearing process is a fundamental economic practice). The fact that Applicant labels this detect-analyze-respond pattern a "control and remediation loop" does not change its fundamental character as the application of an abstract detect-and-fix process to the domain of online financial transaction platforms. Merely adding the label of a "control loop" to a functionally described process does not supply the specific technical implementation necessary to move beyond "apply it." See MPEP2106.05(f).
Furthermore, the Examiner notes that Applicant's characterization of the claim as creating "a non-conventional architecture for transaction-system verification and remediation" is not supported by the specification itself. As the Examiner has previously noted, the specification at par. [0028] characterizes the underlying methodology as "a classical mathematics-based protocol modeling methodology" not as a novel or non-conventional architecture. The use of the term "classical" in the specification directly undermines Applicant's assertion that the architecture is non-conventional, providing intrinsic evidence supporting the Examiner's position. See MPEP2106.05(d)(I)(A); Intellectual Ventures I v. Symantec Corp. Accordingly, because the claims invoke the named computational components in their ordinary functional capacities to perform the abstract idea of financial fraud detection and remediation, without specifying any particular technical mechanism, architecture, or arrangement that departs from the conventional use of those components, the claims do not do more than apply the abstract idea on a generic computer. The rejection under 35 U.S.C.101 is maintained.
The Applicant argues on page 8 that the “The Claimed Combination Is Well-Understood, Routine, and Conventional”.
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that the Applicant argues that the Office Action summarily concludes that the limitations are well-understood, routine, and conventional without providing adequate factual support, relying on Berkheimer v. HP Inc., for the proposition that such determinations are questions of fact that cannot be asserted without evidence. Applicant further contends that the specification describes technical deficiencies of prior systems and presents the claimed workflow as a solution to those deficiencies, and that nothing in the Office Action identifies evidence demonstrating that such a combination was conventional at the time of filing. These arguments have been carefully considered but are not persuasive, and the rejection is maintained for the following reasons.
The Examiner fully acknowledges the Berkheimer framework. Under Berkheimer and MPEP 2106.05(d), a conclusion that additional elements are well-understood, routine, and conventional must be expressly supported in writing by one of four recognized forms of factual support: (A) a citation to an express statement in the specification or a statement made by Applicant during prosecution; (B) a citation to court decisions recognizing the element as well-understood, routine, and conventional; (C) a citation to a publication demonstrating the element is widely prevalent or in common use; or (D) an official notice statement. MPEP2106.05(d), subsection III. The Examiner's finding that the additional elements are well-understood, routine, and conventional is supported under Option (A) citation to express statements in the specification which provides the required factual basis, as fully explained below.
The specification at par. [0028] expressly states that the exploit remediation system "generally leverages a classical mathematics-based protocol modeling methodology." The word "classical" directly and unambiguously characterizes the entire computational methodology underlying the claimed invention as being established, known, and longstanding in the field not novel, not unconventional, not cutting-edge, but classical. This statement, made by Applicant in the specification, is precisely the type of express characterization that qualifies under Option (A) of MPEP2106.05(d)(I)(A) to support a finding that the claimed elements are well-understood and conventional. See Intellectual Ventures I LLC v. Symantec Corp., ("The written description is particularly useful in determining what is well-known or conventional."). A specification that characterizes the underlying methodology of the claimed invention as "classical" demonstrates that the additional elements that implement that methodology are well-understood and conventional in the relevant art.
The specification at par. [0032] further identifies the specific formal modeling language used in the claimed large language model conversion step as "Temporal Logic of Actions, Plus (TLA+)," which is expressly described as "a math-based language for modeling computer programs and systems." TLA+ is a widely-known, extensively-documented, and broadly-deployed formal specification language in the field of computer science and formal verification, developed by Leslie Lamport and published in peer-reviewed literature spanning decades. By identifying TLA+ by name as the implementation mechanism for the LLM-based conversion step, without providing any further description of how TLA+ operates or what makes it suitable for this purpose, the specification treats TLA+ as a well-known tool so familiar to practitioners in the field that it requires no further explanation to satisfy 35 U.S.C.112(a). Under MPEP2106.05(d)(I)(A), a specification demonstrates the well-understood, routine, conventional nature of additional elements "in a manner that indicates that the additional elements are sufficiently well-known that the specification does not need to describe the particulars of such additional elements." The specification's bare identification of TLA+ without further explanation of how it works is precisely this type of treatment, and provides intrinsic factual support for the Examiner's conclusion.
The specification at par. [0033] describes the simulation process module as one that "exhaustively searches each possible state spaces and prunes redundant or unnecessary repeat loops to avoid state space explosion." Exhaustive state-space search, state-space exploration, and invariant checking are long-established techniques in the fields of formal verification and model checking methodologies that have been the subject of extensive academic and industrial research and deployment for decades. The specification's description of these techniques without providing any further technical detail as to how state-space exploration or invariant checking work confirms that these techniques are so well-known in the relevant art that they need not be explained to one of ordinary skill in the art, further satisfying the Option (A) standard under MPEP2106.05(d)(I)(A). See also In re Myers, ("A specification is directed to those skilled in the art and need not teach or point out in detail that which is well-known in the art."); Lindemann Maschinenfabrik GMBH v. Am. Hoist & Derrick Co., ("The specification need not disclose what is well known in the art.").
Applicant's argument that the specification describes "technical deficiencies of prior systems and presents the claimed workflow as a solution to those deficiencies" does not undermine the Examiner's well-understood, routine, and conventional finding. Identifying a problem with existing systems and proposing to use known computational tools to address that problem does not make those known computational tools unconventional. The relevant inquiry under MPEP2106.05(d) is whether the additional elements themselves the graph model, the LLM, the simulation engine are well-understood, routine, and conventional in the relevant field, not whether the specific application of those elements to the identified problem was previously disclosed in the prior art. As MPEP2106.05(d) expressly states: "an additional element (or combination of additional elements) that is known in the art can still be unconventional or non-routine," but that observation works in both directions an element described in the specification using language characteristic of known, classical, or established tools is properly characterized as conventional for Step 2B purposes regardless of whether the specific combination was previously rejected or previously published. The specification's own characterization of the underlying methodology as "classical" and its identification of TLA+ as the implementation vehicle, without further elaboration, demonstrates that the Applicant understood and represented these as well-known tools, not as novel inventions.
Furthermore, Applicant's argument that the rejection fails to "identify evidence demonstrating that such a combination was conventional at the time of filing" reflects a misunderstanding of the required standard. Under MPEP2106.05(d) and Berkheimer, the Examiner is not required to produce prior art demonstrating that the exact combination was previously implemented. Rather, the Examiner must support the finding that the individual elements are well-understood, routine, and conventional, and the Examiner has done so through the intrinsic evidence of the specification itself. Applicant has not provided a declaration under 37 CFR 1.132 demonstrating that the combination was not well-understood, routine, and conventional at the time of filing, and Applicant's arguments in the brief without supporting evidence do not overcome the factual record established by the specification's own characterizations. See MPEP2106.07(b)(2) (if applicant challenges a well-understood, routine, and conventional finding with specific argument but without evidence, the examiner should reevaluate but may maintain the rejection if the factual support remains adequate). Having reevaluated Applicant's challenge against the intrinsic record, the Examiner finds that the specification's express characterization of the claimed methodology as "classical" and its identification of TLA+ and state-space exploration as the implementation tools, without providing any detailed technical explanation of those tools, provides sufficient factual support under Option (A) of MPEP2106.05(d)(I)(A) to sustain the well-understood, routine, and conventional finding, and the rejection is accordingly maintained.
The Applicant argues on page 8 that the “the Claims Recite more than Result-Oriented Functional Language”.
The Examiner respectfully disagrees.
With respect to the arguments the Examiner notes that the Applicant argues that unlike claims found ineligible for merely reciting desired outcomes, amended claim 1 specifies "how" the result is achieved through concrete technical steps, pointing specifically to: (1) transaction graphs with explicit node-edge semantics; (2) generation of executable workflows via a language model; (3) simulation by exploring transaction sequences and checking invariants at each step; and (4) implementation of policy or code updates that modify future transaction execution. Applicant further contends that these limitations meaningfully restrict how the alleged abstract idea is practiced and prevent preemption of generic fraud-detection concepts. These arguments have been carefully considered but are not persuasive for the reasons set forth below, and the rejection is maintained.
The governing standard under MPEP2106.05(f) and controlling Federal Circuit precedent distinguishes between claims that recite a particular solution to a problem specifying the specific technical mechanism by which the desired result is achieved and claims that merely recite a desired result or outcome while leaving the mechanism for achieving that result entirely open. Electric Power Group, LLC v. Alstom S.A. The former may provide significantly more at Step 2B; the latter does not, as it is "equivalent to the words 'apply it.'" MPEP2106.05(f). The court in Intellectual Ventures I v. Capital One Fin. Corp., found claims ineligible even where they purported to recite concrete-sounding operations such as modifying an XML document because "nothing in the claims indicated what specific steps were undertaken other than merely using the abstract idea in the context of XML documents," and the additional limitations "provided only a result-oriented solution and lacked details as to how the computer performed the modifications." Applying this analysis to each of the elements Applicant now identifies as demonstrating concrete technical steps reveals that all four suffer from the same deficiency.
With respect to Applicant's first point that transaction graphs with "explicit node-edge semantics" provide concrete technical content the Examiner maintains that the limitation "generating, for each order of the plurality of orders, a transaction graph based on journal entries of the order, wherein accounts are represented as nodes and transactions are represented as edges" does specify a data structure type (a graph) and its general semantics (accounts as nodes, transactions as edges), but it does not specify any particular graph construction algorithm, any particular data structure representation, any particular storage format, or any particular technical mechanism for constructing the graph from journal entry data. The recitation that accounts are nodes and transactions are edges is the definition of any transaction graph it is the most generic possible specification of what a transaction graph is, not a particular technical implementation thereof. Contrast this with the claims in Enfish, which recited specific structural features of a self-referential database table (all entity types stored in a single table, rows containing column definition information) that constituted a specific, technically distinct data structure providing concrete performance benefits described in detail in the specification. Enfish. The present claim's recitation that a graph has nodes and edges is a functional definition of the graph data type itself, not a specific implementation of a novel data structure, and thus does not specify "how" the result is technically achieved in any meaningful way beyond naming the data type to be used.
With respect to Applicant's second point that "generation of executable workflows via a language model" specifies how the conversion is technically accomplished the Examiner maintains that the limitation "utilizing a large language model to convert the graph patterns into a workflow corresponding to a format usable by a simulation engine" specifies only: (a) what component is used (a large language model, recited at a high level of generality); (b) what is converted (graph patterns); and (c) what the output format requirement is (usable by a simulation engine). It does not specify how the large language model performs the conversion what prompting approach is used, what output grammar or schema governs the workflow format, what technical mechanism ensures the output is compatible with the simulation engine, or what architectural features of the LLM are relevant to the conversion. The specification at par. [0032] identifies TLA+ as the implementation but the claim itself does not recite TLA+ or any other specific formal language. Under the broadest reasonable interpretation, the claim covers any large language model performing any conversion of any graph pattern representation into any workflow format usable by any simulation engine a scope so broad that it covers every possible technical implementation of LLM-based workflow generation, which is the paradigmatic example of result-oriented functional language that claims the idea of a solution rather than a particular solution. See Internet Patents Corp. v. Active Network, Inc., (a claim reciting a result "dissociated from any method by which" the result is accomplished does not provide a meaningful limitation).
With respect to Applicant's third point that "simulation by exploring transaction sequences and checking invariants at each step" specifies how the fraud detection is achieved the Examiner maintains that this limitation, "simulating, at the simulation engine, the workflow by exploring a state space comprising sequences of transactions represented in the workflow and checking for invariants at each step," describes what the simulation engine does (explores a state space, checks invariants) without specifying any particular state-space traversal algorithm, any particular invariant specification language or mechanism, how the state space is represented internally, how invariant violations are detected computationally, or how the simulation engine handles state-space explosion. This is precisely the type of high-level functional description that the Federal Circuit has repeatedly found to constitute result-oriented language: the claim recites what the simulation achieves checking invariants across transaction sequences to identify violations but not how any aspect of the simulation is technically accomplished. Compare the eligible claims in USPTO Example 47 (Claim 3), where the claim recited specific technical mechanisms training using a backpropagation algorithm and gradient descent algorithm, detecting source addresses, dropping malicious packets, and blocking future traffic that constituted specific computer-implemented actions with defined technical content, and where the specification described how those specific mechanisms improved the technical field of network intrusion detection. The present claim recites no comparable technical specificity in any of its simulation steps.
With respect to Applicant's fourth point that "implementation of policy or code updates that modify future transaction execution" constitutes a concrete technical step that prevents preemption the Examiner maintains that this is the broadest of all the limitations at issue. The step of "implementing, on the online transaction platform, a policy update or a code enhancement corresponding to a fix based on the first sequence of transactions to modify execution of future transactions involving the online transaction platform to eliminate the exploit" specifies only: (a) where the fix is applied (on the online transaction platform); (b) what type of fix it is (a policy update or code enhancement, covering any conceivable type of platform modification); and (c) what result it must achieve (eliminating the exploit). It specifies no particular mechanism of implementation, no particular type of policy update, no particular code modification approach, and no particular technical protocol for applying the fix to the platform. This is not a concrete technical step specifying "how" the platform is modified it is a statement that the platform must be fixed in some unspecified way that achieves the desired outcome. As noted in prior responses, this is the paradigmatic form of result-oriented functional language that the courts and the USPTO guidance have consistently found to add nothing beyond the abstract idea itself. See Electric Power Group.
Finally, with respect to Applicant's preemption argument that the claim prevents preemption of generic fraud-detection concepts by specifying particular technical steps the Examiner notes that while preemption concerns motivate the eligibility analysis, preemption is not a standalone test and a claim that does not preempt every possible implementation of an abstract idea is not automatically eligible. Synopsys, Inc. v. Mentor Graphics Corp. Here, the claims do not prevent preemption of the abstract idea of detecting and remediating financial transaction exploits through graph-based modeling and simulation. The claims, as written, cover any implementation of the claimed pipeline using any graph model, any LLM, any simulation engine, and any remediation mechanism which is so broad as to effectively preempt any computational approach to automated financial exploit detection and remediation using graph-based transaction modeling. The fact that the claim uses specific vocabulary (transaction graphs, LLMs, simulation engines, invariant checking) does not narrow the claim to a specific technical implementation if those terms are themselves recited at a high level of functional generality that covers all implementations. Accordingly, the rejection under 35 U.S.C.101 is maintained.
The Applicant argues on page 9 that the “claims effect a technical transformation of the system…”
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that the Applicant argues under Step 2B that the claim effects a technological transformation to a computer system specifically, that the identification of invariant-violating transaction sequences leads directly to modification of transaction-platform execution logic, preventing recurrence of unsafe system states. Applicant contends that this goes beyond analysis and constitutes "computer system control and improvement," supplying the requisite inventive concept. These arguments have been carefully considered but are not persuasive, and the rejection is maintained for the following reasons.
As a threshold matter, the Examiner acknowledges that the "particular transformation" consideration under MPEP2106.05(c) is a recognized factor in both the Step 2A Prong Two and Step 2B analyses. Under that consideration, a claim that effects a transformation or reduction of a particular article to a different state or thing may integrate a judicial exception into a practical application or provide significantly more. MPEP2106.05(c). However, MPEP2106.05(c) also makes clear that "the transformation of an article" is "an important clue" but "not a stand-alone test for eligibility," and that a transformation must be evaluated against several factors including: (1) the particularity or generality of the transformation; (2) the degree to which the recited article is particular; (3) the nature of the transformation in terms of the type or extent of change; (4) the nature of the article transformed; and (5) whether the transformation is extra-solution activity or a field-of-use limitation. MPEP2106.05(c). Applying these factors to the amended claims reveals that the asserted transformation does not supply the inventive concept Applicant claims.
Factor 1 Particularity or Generality of the Transformation: The claimed transformation implementing "a policy update or a code enhancement corresponding to a fix based on the first sequence of transactions to modify execution of future transactions... to eliminate the exploit" is recited at the broadest possible level of generality. The claim covers any policy update or code enhancement, of any type, implemented by any mechanism, that modifies any aspect of future transaction execution, so long as the exploit is eliminated. There is no particularity whatsoever in how the transformation is accomplished the claim covers every conceivable technical mechanism by which a transaction platform could be modified in response to a detected exploit. MPEP2106.05(c) provides that "a more particular transformation would likely provide significantly more," and conversely, a broadly recited transformation covering any and all mechanisms of modification would not. The claimed transformation is maximally general.
Factor 2 Degree to Which the Recited Article Is Particular: The article subject to transformation is "the online transaction platform." Under the broadest reasonable interpretation, this term encompasses any computer-based system that facilitates financial transactions a description so broad as to encompass any banking platform, e-commerce platform, payment processor, or financial transaction system of any architecture. MPEP2106.05(c) provides that "a transformation applied to a generically recited article or to any and all articles would likely not provide significantly more." An online transaction platform, recited without any particular technical specification of its architecture, code structure, or protocol implementation, is a generically recited article, and a transformation applied to it at this level of generality does not provide significantly more.
Factor 3 Nature of the Transformation: Applicant characterizes the transformation as "modification of transaction-platform execution logic, preventing recurrence of unsafe system states." However, modifying a software system by applying a policy update or code enhancement is not a transformation in the patent law sense that carries weight under MPEP2106.05(c). The types of transformations recognized as meaningful under that provision involve changes in physical or chemical state such as the transformation of raw rubber into molded rubber products in Diamond v. Diehr, or the transformation of fat into fatty acids and glycerine in Tilghman v. Proctor or changes in electronic signal architecture or data encoding that result in a new technical structure. MPEP2106.05(c); see also MPEP2106.05(c) ("Purely mental processes in which thoughts or human based actions are 'changed' are not considered an eligible transformation. For data, mere 'manipulation of basic mathematical constructs... the paradigmatic "abstract idea,"' has not been deemed a transformation.") (quoting CyberSource v. Retail Decisions. Modifying a software system's policy parameters or code in response to a detected fraud vulnerability is a change in the software configuration of a platform it is not a transformation of a physical or tangible article to a different state. The change that results is in the platform's behavior (which transactions it allows or blocks going forward), not in a physical or technical structure of the platform hardware or a formally defined technical artifact. This type of change altering the operational behavior of software in response to detected conditions is exactly the type of abstract management function that the courts have declined to recognize as a transformative act for101 purposes.
Factor 4 Nature of the Article Transformed: Relatedly, the article alleged to be transformed is an "online transaction platform" a software system whose operational parameters are being modified. The modification of software behavior through policy updates or code enhancements is a modification of an intangible system, not a transformation of a physical or tangible article. MPEP2106.05(c) expressly states that "transformation of a physical or tangible object or substance is more likely to provide significantly more... than the transformation of an intangible concept such as a contractual obligation or mental judgment." The online transaction platform's execution logic the set of rules and code governing how transactions are processed is an intangible construct, and modifications to it through policy updates or code enhancements are modifications to intangible operational parameters, not transformations of physical articles. This factor weighs against finding a qualifying transformation.
Factor 5 Whether the Transformation Is Extra-Solution Activity or Field-of-Use: Even accepting arguendo that implementing a platform fix constitutes some form of transformation, the implementing step in amended claim 1 functions as a post-solution application step that takes the output of the claimed analytical process (the identified violating sequence and derived fix) and applies it to a field-of-use environment (an online transaction platform). MPEP2106.05(c) explicitly provides that "a transformation that contributes only nominally or insignificantly to the execution of the claimed method steps" such as a field-of-use limitation does not provide significantly more. The core analytical work of the claim is performed in the simulation and invariant-checking steps; the implementing step is a post-solution step that applies the result of that analysis to a system, in the same way that administering a drug to a patient was found to be merely a field-of-use limitation in Mayo Collaborative Servs. v. Prometheus Labs., Inc. The Supreme Court in Mayo explicitly rejected the argument that a transformation of a physical system (the patient's body) following the analytical steps of the claim supplied an inventive concept, finding it was merely a field-of-use limitation. The present case is analogous: the implementing step applies the results of the claimed analytical process to a platform it is field-of-use activity that does not supply the inventive concept.
Furthermore, and critically, even if the implementing step were deemed to constitute a meaningful transformation, the claimed transformation still arises entirely as a consequence of performing the abstract idea detecting an exploit through simulation and applying a known response rather than as a technical improvement to any computer technology. As the Examiner has previously noted, MPEP2106.05(a) provides that "an improvement in the abstract idea itself... is not an improvement in technology." The "improvement" Applicant identifies making the transaction platform more secure by eliminating a detected exploit is an improvement to the financial fraud protection objective (i.e., an improvement to the abstract idea itself), not an improvement to how the transaction platform, simulation engine, or any other computational component technically operates. Compare In re Board of Trustees of Leland Stanford Junior Univ., 989 F.3d 1367, 1373 (Fed. Cir. 2021) (an improvement in the accuracy of a mathematical prediction was an improvement to the abstract idea, not to a technological process). Because the claimed transformation is (a) recited at too general a level to constitute a particular transformation, (b) applied to a generically recited article, (c) a modification of an intangible software system rather than a physical article, (d) post-solution field-of-use activity, and (e) an improvement to the financial fraud prevention goal rather than to any computer technology, it does not supply the inventive concept required at Step 2B. The rejection under 35 U.S.C.101 is accordingly maintained.
The Applicant argues that "Cella does not teach the use of historical order-level journal entries to construct per-order transaction graphs that are embedded and then transformed, via a large language model, into formal simulation workflows for state-space exploration with invariant checking."
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that first, the argument impermissibly attacks Cella in isolation. It is well-established that a 103 rejection based on a combination of references must be evaluated as a whole, not reference-by-reference. In re Merck & Co., ("Non-obviousness cannot be established by attacking references individually where the rejection is based upon the teachings of a combination of references."). The Examiner does not rely on Cella alone for all limitations Arulkumaran provides the graph construction, embedding, and pattern generation elements that Cella does not explicitly detail. Applicant's argument therefore fails at the threshold by ignoring the combined teachings.
Second, applicant's characterization of Cella as lacking any teaching relevant to this limitation is an overstatement that applicant itself contradicts. In the same Response at pages 9-10, applicant concedes that "Cella broadly discusses enterprise platforms that use machine-learning models and large language models to generate, refine, and deploy workflows for governance, compliance, access control, and transaction execution." This concession is significant. Applicant cannot simultaneously argue that Cella teaches LLM-driven workflow generation broadly while arguing Cella has nothing to contribute to a claim requiring LLM-driven workflow generation. The LLM-to-workflow limitation is precisely what Cella provides to the combination.
Third, regarding the specific sub-element of "historical order-level journal entries": Cella discloses an enterprise access layer that processes transaction data including order information, financial records, and ledger data through its Data Services System and Transaction System components. Under the broadest reasonable interpretation, "historical order data including journal entries that record transactions between accounts" reads broadly on records of financial transactions between enterprise accounts which Cella's Transaction System (18750) and Data Services System (18720) process. Applicant's argument that "journal entries" necessarily connotes a narrow, specialized accounting record type that excludes Cella's transaction records is not supported by the specification, which uses the term broadly to mean records of transactions between accounts. See Spec. at [0029]: "each transactional order generates distinct records, commonly known as journal entries. Each journal entry records a financial transaction between two distinct accounts."
Fourth, regarding the "per-order" aspect of graph construction: Arulkumaran discloses constructing transaction graphs G = (V, E, F) where nodes represent accounts/users and edges represent transactional relationships. While Arulkumaran's primary embodiment builds an aggregate network, its graph construction methodology building graphs from transaction attributes linking accounts is directly applicable to per-order graph construction. A POSITA reading Arulkumaran's graph construction methodology would recognize that the same technique of representing accounts as nodes and transactions as edges can be applied on a per-order basis when the input data is organized per-order, as in Cella's Transaction System. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007) ("If a technique has been used to improve one device, and a person of ordinary skill in the art would recognize that it would improve similar devices in the same way, using the technique is obvious unless its actual application is beyond his or her skill.").
The combination of Cella's transaction data and LLM workflow generation with Arulkumaran's graph construction and embedding methodology provides all elements of this limitation. The argument is not persuasive and the rejection is maintained.
The Applicant argues that "Cella broadly discusses enterprise platforms...directed to orchestrating enterprise processes rather than modeling ledger-level transaction behavior or simulating possible sequences of financial transactions to detect invariant-violating exploits."
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that first, the argument improperly attempts to limit the claims by importing a purpose restriction that does not appear in the claim language. Amended claim 1 does not require that the online transaction platform be a payment-specific ledger system, nor does it require that the purpose of the system be "detecting invariant-violating exploits" as the exclusive goal. The claim recites functional steps accessing historical order data, generating transaction graphs, embedding, generating patterns, converting via LLM to a workflow, simulating, identifying a sequence, and implementing a fix. Whether Cella's platform is described as an "enterprise orchestration" system is legally irrelevant if its technical disclosures teach the claimed functional steps. In re Paulsen, (a reference can be relied upon for all it teaches to a POSITA, not merely the specific use for which it was developed).
Second, applicant's characterization that Cella is directed only to "orchestrating enterprise processes" understates what Cella actually discloses. Cella explicitly includes: a Transaction System (18750) with transaction execution and authorization components; a Fraud Report System (18783); a Compliance System (18782); a Planning and Simulation System (18794); and a Scoring System (18734) that processes transaction data for risk assessment. Cella's transaction system encompasses payment platforms and financial transaction execution these are not generically "enterprise processes" divorced from financial transaction behavior. Applicant's characterization of Cella as solely an enterprise access management platform ignores these explicit financial transaction components.
Third, the argument conflates the field of a reference with its technical teachings. Even if Cella's primary field is enterprise access management, its technical disclosures of LLM-driven workflow generation, planning and simulation systems, compliance checking, and transaction processing are applicable to the claimed invention regardless of the field label. The Federal Circuit has consistently held that a reference is prior art for all it teaches, not just its primary purpose. KSR, ("A person of ordinary skill is also a person of ordinary creativity, not an automaton.").
Fourth, regarding the "simulation of possible sequences of financial transactions to detect invariant-violating exploits": Applicant argues this specific combination is not taught by Cella. The Examiner acknowledges that Cella does not use the specific terminology of "invariant violations" in the context of payment protocol exploits. However, Cella's Planning and Simulation System (18794) in combination with its Compliance System (18782) and Decision Support System (18793) collectively disclose a system that simulates enterprise process execution and checks compliance conditions which reads on the functional concept of checking invariants (compliance conditions = invariants) during simulation. Moreover, the motivation to apply this simulation and compliance-checking architecture to financial transaction sequences for exploit detection is expressly suggested by Cella's Fraud Report System (18783), which demonstrates that Cella's inventors contemplated fraud detection as a use case within the same system architecture.
Fifth, applicant presents no evidence such as a 1.132 Declaration that a POSITA would not have recognized the applicability of Cella's simulation and compliance architecture to financial transaction protocol analysis. Mere attorney argument that Cella is "directed to a different problem" does not constitute evidence of non-obviousness. In re Geisler. The rejection is therefore maintained.
The Applicant argues that "Cella lacks any disclosure of graph-based modeling of journal entries, generation of historical graph embeddings or graph patterns, conversion of graph patterns into workflows, or simulation using the workflows that explores sequences of transactions to identify exploits based on invariant violations.
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that this argument is not persuasive against the combination, and the Examiner addresses each sub-element directly.
Regarding "graph-based modeling of journal entries and generation of historical graph embeddings": The Examiner expressly agrees that Cella does not teach these elements in isolation. These elements are taught by Arulkumaran. Arulkumaran explicitly discloses constructing a financial transaction graph G = (V, E, F) where nodes represent accounts/users and edges represent transactional relationships, and then applying multi-layer GCN processing to generate node embeddings H^(L) = GCN_L(GCN_{L-1}(...GCN_1(X))). These node embeddings are the "historical graph embeddings" of the claim. Applicant's argument that Arulkumaran does not teach this is simply incorrect it is Arulkumaran's primary technical contribution.
Regarding "conversion of graph patterns into workflows": Applicant correctly notes that Arulkumaran does not teach this. However, this is precisely the element taught by Cella. Cella's payments protocol module utilizes a large language model to convert transaction representations into executable workflows as applicant itself acknowledges at page 10 of the Response. The combination therefore provides: Arulkumaran's graph embeddings/patterns - input to Cella's LLM - converted to simulation workflow. Applicant's argument that the conversion step is untaught ignores that this is the exact element for which Cella was cited.
Regarding "simulation using the workflows that explores sequences of transactions to identify exploits based on invariant violations": The Examiner acknowledges this is the most contested element. However, it is important to note that the claim language itself, as amended, does not require a formal verification system in the TLA+ or model-checking sense it requires "simulating, at the simulation engine, the workflow by exploring a state space comprising sequences of transactions represented in the workflow and checking for invariants at each step." Cella's Planning and Simulation System (18794) explores execution states of workflows. Cella's Compliance System (18782) checks conditions which are functionally equivalent to "invariants" under the broadest reasonable interpretation. The combination of these two Cella components, operating on a workflow generated from Arulkumaran's graph embeddings, teaches the simulation and invariant-checking limitations.
Moreover, under KSR, it is not necessary for the prior art to teach the claimed combination explicitly. The question is whether a POSITA would have found it obvious to combine Cella's workflow simulation and compliance-checking with Arulkumaran's graph-based transaction representation to achieve the claimed result. Given that both references are in the same general field of automated transaction processing and security, and both address improving the security and reliability of financial transactions, a strong motivation to combine exists without any explicit suggestion in either reference. KSR, ("The combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results.").
Applicant's argument on this point is legally insufficient because it amounts to a claim that the prior art does not teach the invention which is not the standard for 103. The standard is whether the invention would have been obvious to a POSITA, and the Examiner maintains that the combination teaches or suggests all claimed limitations and the rejection is maintained.
The Applicant argues that “Arulkumaran is limited to fraud detection using graph convolutional networks for classification and anomaly scoring, rather than simulation and exploit remediation for transactions."
Expanded Examiner Response:
With respect to the argument the Examiner notes that the argument is not persuasive because it improperly restricts the teachings of a reference to its stated purpose and primary embodiment. It is well-settled that a prior art reference is not limited to its preferred embodiment or its stated goal. In re Mouttet, ("It is not necessary that the inventions of the references be physically combinable to render obvious the invention under review."); In re Kahn. What matters under 103 is what the reference teaches to a POSITA, not what the reference's authors intended to accomplish.
Arulkumaran's technical contribution to the combination is specifically and narrowly its graph construction and embedding methodology not its fraud classification output. Arulkumaran teaches: (1) representing financial transaction data as a graph G = (V, E, F) with accounts as nodes and transactions as edges; (2) applying GCN layers to compute node embeddings H^(l); and (3) generating graph-based representations of transaction behavior from those embeddings. These three teachings are directly applicable to the claimed limitations of generating transaction graphs, embedding them, and generating graph patterns regardless of what Arulkumaran does with those embeddings downstream.
The fact that Arulkumaran uses the embeddings for classification rather than workflow generation does not make its graph construction and embedding teachings inapplicable. A POSITA would recognize that graph embeddings of financial transaction data are a useful intermediate representation that can serve as input to multiple downstream systems including the LLM-based workflow generator taught by Cella. This is precisely the kind of "obvious to try" combination that KSR contemplates: taking a known technique (graph embedding of transactions from Arulkumaran) and feeding it into a known downstream system (LLM workflow generation from Cella) to achieve a predictable result (a workflow representing transaction behavior for simulation).
Furthermore, applicant's characterization that Arulkumaran is "limited to classification and anomaly scoring" overstates the case. Arulkumaran explicitly discloses: dynamic updating of transaction graphs in real time; adaptive thresholding based on evolving transaction patterns; and cloud-based fraud auditing, that stores flagged transactions for forensic investigation including identifying "organized fraud rings" and "fraud trends" which goes beyond simple binary classification. These disclosures suggest that Arulkumaran's inventors contemplated the system as providing actionable intelligence about transaction patterns, not merely assigning fraud probability scores. A POSITA reading Arulkumaran in light of Cella would find clear motivation to extend Arulkumaran's graph-based pattern representations into the workflow generation pipeline taught by Cella, therefore the rejection is maintained.
The Applicant argues that "Arulkumaran does not teach converting graph-derived representations into workflows using a large language model, performing state-space exploration over sequences of transactions using the workflows, checking invariants at each simulated step, or identifying an exploit as an invariant-violating transaction sequence that can then be used to update policy or code to eliminate reachability of the exploit."
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that This argument is correct as to Arulkumaran standing alone, but entirely irrelevant to the combination, and applicant's framing reveals a fundamental misunderstanding of how 103 rejections operate.
Applicant's argument essentially concedes the point the Examiner is making: Arulkumaran's graph construction and embedding teachings are admitted to be present, and applicant acknowledges the only missing elements are the LLM workflow conversion, state-space simulation, invariant checking, and platform remediation. These are precisely the elements supplied by Cella. The combination is complete not in spite of applicant's argument, but because of it.
The Examiner addresses each sub-element specifically:
Regarding the argued "converting graph-derived representations into workflows using a large language model": Cella explicitly discloses a payments protocol module that utilizes a large language model to convert transaction representations into workflows usable by a simulation engine. Applicant acknowledges this at page 10 of the Response. The combination is therefore: Arulkumaran produces graph embeddings and graph patterns - these are fed as input to Cella's LLM - Cella's LLM converts them to a simulation workflow. A POSITA would recognize that an LLM designed to convert transaction representations to workflows as Cella discloses can accept as input the graph pattern representations that Arulkumaran generates. There is no technical barrier to this combination, and applicant has identified none.
Regarding the argued "performing state-space exploration over sequences of transactions using the workflows": Cella's Planning and Simulation System (18794) simulates workflow execution. The claim does not require a formal model checker such as TLA+ it requires exploring "a state space comprising sequences of transactions represented in the workflow." Cella's simulation system, operating on the LLM-generated workflow derived from Arulkumaran's graph patterns, reads on this limitation. The fact that Cella's simulation system was not originally designed for payment protocol exploit detection does not prevent it from being combinable for that purpose under KSR.
Regarding the argued "checking invariants at each simulated step": Cella's Compliance System (18782) continuously checks compliance conditions during workflow execution. These compliance conditions are functional equivalents of "invariants" conditions that must be satisfied at each step of execution for the system to remain in a valid state. Under the broadest reasonable interpretation, checking compliance conditions during simulation reads on checking invariants at each step.
Regarding the argued "identifying an exploit as an invariant-violating transaction sequence that can be used to update policy or code": Cella's Fraud Report System (18783) and its governance systems identify problematic transaction patterns and generate reports for remediation. Cella's policy update mechanisms explicitly disclosed as modifying governance rules and compliance workflows read on the claimed "policy update or code enhancement." The connection between identifying a violating sequence and updating policy is inherent in Cella's governance architecture: when a compliance violation is identified in a simulated workflow, Cella's governance and policy systems are updated accordingly.
Applicant's argument that these elements together constitute a combination that is non-obvious fails to engage with the actual teachings of the combination. Under KSR, a combination of known elements using known methods to achieve predictable results is prima facie obvious. The burden shifts to applicant to provide objective evidence of non-obviousness which applicant has not done, the rejection is therefore maintained.
The Applicant argues that "As Cella and Arulkumaran, either alone or in combination, fail to teach or suggest the features of independent claim 1 and the claim is not obvious in view of the references."
The Examiner respectfully disagrees.
With respect to the argument the Examiner notes that the Applicant's blanket assertion that the combination "fails to teach or suggest the features of independent claim 1" is precisely the type of attorney argument that the Federal Circuit has repeatedly held insufficient to rebut a prima facie case of obviousness. In re Geisler; Newell Cos. v. Kenney Mfg. Co., ("Argument of counsel cannot take the place of evidence lacking in the record.").
To rebut a prima facie case of obviousness, applicant must do one or more of the following: (1) provide a Declaration under 37 C.F.R. 1.132 from a person skilled in the art establishing that the combination was non-obvious or that the claimed results were unexpected; (2) present evidence of secondary considerations such as long-felt but unresolved need, failure of others, commercial success, or copying by competitors; or (3) demonstrate that the Examiner has failed to establish a prima facie case by identifying specific claim limitations that are not taught or suggested by the combination and explaining why a POSITA would not have been motivated to combine. In re Piasecki.
Applicant has done none of these things. No 1.132 Declaration has been submitted. No evidence of secondary considerations has been presented. And applicant's identification of specific untaught limitations while more developed than this conclusory argument fails for the reasons detailed in the responses to Arguments 1-5 above.
Regarding the specific limitation of "implementing, on the online transaction platform, a policy update or a code enhancement corresponding to a fix based on the first sequence of transactions to modify execution of future transactions to eliminate the exploit": Cella explicitly discloses policy update and code enhancement mechanisms. Cella's governance systems (Custom Governance System 18788, Legal Governance System 18762) modify how transactions are executed on the enterprise platform. Cella's compliance and workflow management systems deploy updated rules that modify future transaction execution. These teachings, combined with Arulkumaran's identification of problematic transaction patterns, provide the full combination required. Applicant's argument that this limitation is untaught ignores Cella's explicit disclosure of automated policy deployment and transaction execution modification.
Furthermore, the claim's requirement that the policy update be "based on the first sequence of transactions" that caused the invariant violation is satisfied by the combination: Arulkumaran identifies the problematic transaction patterns (the sequence), and Cella's governance system deploys a policy update based on that identified pattern. The logical connection between identified exploit sequence and deployed policy fix is inherent in the combination and does not require explicit teaching of that connection KSR expressly holds that "a person of ordinary skill is also a person of ordinary creativity, not an automaton" who can supply the logical steps connecting known techniques, the rejection is therefore maintained.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter because the claim(s) as a whole, considering all claim elements both individually and in combination, do not amount to significantly more than an abstract idea. The claim(s) is/are directed to the abstract idea of detecting possible financial fraud behavior within payment processing. The claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more than the judicial exception itself. Claim(s) (1-20) is/are directed to an abstract idea without significantly more.
Step 1
Regarding Step 1 of the Subject Matter Eligibility Test for Products and Processes (from the January 2019 §101 Examination Guidelines), claim(s) (1-7) is/are directed to a computer storage medium, claim(s) (8-14) is/ are directed to a method, and claims(s) (15-20) is/are directed to a system and therefore the claims recites a series of steps and, therefore the claims are viewed as falling in statutory categories.
Step 2A Prong 1
The claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s) mental process. Specifically, the independent claims 1, 8, and 15 recite a mental process: as drafted, the claim recites the limitation of simulating a workflow to identify an exploit which is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting a processor, nothing in the claim precludes the determining step from practically being performed in the human mind. For example, but for the a processor” language, the claim encompasses the user determining exploits . The mere nominal recitation of a generic processor does not take the claim limitation out of the mental processes grouping. It has been established by ongoing guidance that claims that contain a generic processor are still viewed as mental process when they contain limitations that can practically be performed in the human mind, however this is different for instance when the human mind is not equipped to perform the claim limitations (network monitoring, data encryption for communication, and rendering images). Therefore, these limitations are viewed a mental process. Additionally, with regard to the instant application the Examiner has reviewed the disclosure and determined that the underlying claimed invention is described as a concept that is performed in the human mind and/or with the aid of a pen and paper, and thus it is viewed that the applicant is merely claiming that concept performed 1) on a generic computer, 2) in a computer environment or 3) is merely using a computer as a tool to perform the concept, and therefore is considered to recite a mental process.
Step 2A Prong 2
Specifically, the determined judicial exception is not integrated into a practical application because the generically recited computer elements do not add a meaningful limitation to the abstract idea because they amount to simply implementing the abstract idea on a computer and additionally that data embedding and utilizing steps required to use the simulating do not add a meaningful limitation to the method as they are insignificant extra-solution activity (including post solution activity).
The claim recites the additional element(s): that a processor is used to perform the simulating step. The processor in the steps is recited at a high level of generality, i.e., as a generic processor performing a generic computer function of processing data (detecting possible financial fraud behavior). This generic processor limitation is no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to the abstract idea.
The claim recites the additional element(s): embedding historical orders into a model, and utilizing a large language model to convert each transaction performs the simulating step. The embedding and utilizing steps are recited at a high level of generality (i.e., as a general means of embedding and utilizing data to provide the simulating step), and amounts to mere data management, which is a form of insignificant extra-solution activity. The processor that performs the simulating step is also recited at a high level of generality, and merely automates the simulation step. Each of the additional limitations is no more than mere instructions to apply the exception using a generic computer component (the processor).
The Examiner has further determined that the claims as a whole does not integrate a judicial exception into a practical application in order to provide an improvement in the functioning of a computer or an improvement to other technology or technical field. It has been determined that based on the disclosure does not provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. It has not been provided clearly in the disclosure that the alleged improvement would be apparent to one of ordinary skill in the art, but is instead in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art, and therefore does not improve the technology. Second, in the instance, where it is not clear that the specification sets forth an improvement in technology, the claim must reflect the disclosed improvement (the claims must include components or steps of the invention that provide the improvement described in the specification).
For further clarification the Examiner points out that the claim(s) 1-20 recite(s) embedding historical orders, utilizing a large language model to convert, and simulating the workflow which are viewed as an abstract idea in the form of a mental process. This judicial exception is not integrated into a practical application because the use of a computer for embedding, utilizing, and simulating which is the abstract idea steps of valuing an idea (detecting possible financial fraud behavior) in the manner of “apply it”.
Thus, the claims recites an abstract idea directed to a mental process (i.e. to detect possible financial fraud behavior). Using a computer to embedding, utilizing, and simulating the data resulting from this kind of mental process merely implements the abstract idea in the manner of “apply it” and does not provide 'something more' to make the claimed invention patent eligible. The claimed limitations of a computing device is not constraining the abstract idea to a particular technological environment and do not provide significantly more.
The detecting possible financial fraud behavior would clearly be to a mental activity that a company would go through in order to decide how to detect possible financial fraud behavior. The specification makes it clear that the claimed invention is directed to the mental activity data gathering and data analysis to determine detecting possible financial fraud behavior:
The dependent claims recite elements that narrow the metes and bounds of the abstract idea but do not provide ‘something more’.
The dependent claims do not remedy these deficiencies.
Claims 2, 3, 5, 6, 9, 10, 12, 13, 16, 18, and 19 recite limitations which further limit the claimed analysis of data.
Claims 4, 7, 11, 14, 17, and 20 recites limitations directed to claim language viewed insignificantly extra solution activity.
Using a computer to perform the data processing as claimed is merely implementing the abstract idea in the manner of “apply it” and does not provide significantly more. Additionally with respect to the Berkheimer the Examiner points out that the steps of the claim are viewed to be to nothing more than spell out what it means to apply it on a computer and cannot confer patent-eligibility as there are no additional limitations beyond applying an abstract idea, restricted to a computer. As the claims are merely implementing the abstract idea in the manner of “Apply It” the need for a Berkheimer analysis does not apply and is not required. With respect to the currently filed claims the implementing steps can be found in Cella and Arulkumaran which discloses how the claims alone and in combination are viewed to be well understood, routine and conventional based on point 3 of the Berkheimer memo and subsequent evidence, complying with and providing evidence.
No Claims are viewed to recites limitations directed to claim language viewed non-functional data labels.
Thus, the problem the claimed invention is directed to answering the question based on detecting possible financial fraud behavior. This is not a technical or technological problem but is rather in the realm of financial fraud detection and therefore an abstract idea.
Step 2B
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed with respect to Step 2A Prong Two, the additional element in the claim amounts to no more than mere instructions to apply the exception using a generic computer component.
The same analysis applies here in 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. This is the case because in order for the claims to be viewed as significantly more the claims must incorporate the integral use of a machine to achieve performance of a method, in contrast to where the machine is merely an object on which the method operates, which does not provide significantly more in order for a machine to add significantly more, it must play a significant part in permitting the claimed method to be performed, rather than function solely as an obvious mechanism for permitting a solution to be achieved more quickly. Whether its involvement is extra-solution activity or a field-of-use, i.e., the extent to which (or how) the machine or apparatus imposes meaningful limits on the claim. Use of a machine that contributes only nominally or insignificantly to the execution of the claimed method (e.g., in a data gathering step or in a field-of-use limitation) would not provide significantly more. Additionally, another consideration when determining whether a claim recites significantly more is whether the claim effects a transformation or reduction of a particular article to a different state or thing. "Transformation and reduction of an article ‘to a different state or thing’ is the clue to patentability of a process claim that does not include particular machines. All together the above analysis shows there is not improvement in computer functionality, or improvement to any other technology or technical field. The claim is ineligible.
Additionally, with respect to the Berkheimer as noted above the same analysis applies to the 2B where the claims are viewed as applying it and as such no further analysis is required. However, with respect to the current claims embedding and utilizing that are viewed as extra solution or post solution activity the Examiner notes that the claims are viewed as well-understood, routine, and conventional because a citation to a publication that demonstrates the well-understood, routine, conventional nature of the additional element(s). An appropriate publication such as the currently cited prior art Cella and Arulkumaran detecting possible financial fraud behavior provides those extra solution activities and is viewed as a form of publication which also includes a book, manual, review article, or other source that describes the state of the art and discusses what is well-known and in common use in the relevant industry. The claim is ineligible.
The dependent claims recite elements that narrow the metes and bounds of the abstract idea but do not provide ‘something more’. Specifically, the dependent claims do not remedy these deficiencies of the independent claims.
With respect to the legal concept of prima facie case being a procedural tool of patent examination, which allocates the burdens going forward between the examiner and the applicant. MPEP § 2106.07 discusses the requirements of a prima facie case of ineligibility. In particular, the initial burden was on the Examiner and believed to be properly provided as to explain why the claim(s) are ineligible for patenting because of the above provided rejection which clearly and specifically points out in accordance with properly providing the requirement satisfying the initial burden of proof based on the Guidance from the United States Patent and Trademark Office and the burden now shifts to the applicant.
Claim Rejections - 35 USC § 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 may not be obtained through the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over CELLA et al. (WO 2024/091682 A1) (hereafter Cella) in view of Arulkumaran (6 October 2023, Arulkumaran, Fraud Detection in Financial Transactions Using Relation-Aware Graph Convolutional Networks, International Journal of Innovations in Engineering and Science, Vol. 8, No. 7, 2023, pp 1-10) (hereafter Arulkumaran).
Referring to Claim 1, Cella teaches one or more computer storage media storing computer usable instructions that when used by one or more computer devices cause the one or more computing devices to perform operations, said method comprising:
accessing historical order data associated with a plurality of orders involving an online transaction platform, the historical order data including journal entries that record transactions between accounts for each order from the plurality of orders (see; par. [0221] of Cella teaches an online transaction (i.e. orders) are recorded in a ledger (i.e. historical record), par. [0222] this ledger can be accessed to provide historical transactions).
utilizing a large language model to convert the graph patterns into a workflow corresponding to a format usable by a simulation engine (see; par. [1195]-[1196] of Cella teaches an example of a machine learning model along with historical data to determine the current stats and utilizing simulation, par. [1198] to generate a mapping including workflows).
simulating, at the simulation engine, the workflow by exploring a state space comprising sequences of transactions represented in the workflow and checking for invariants at each step to identify an exploit in the workflow based on identification of an invariant violation (see; par. [1195]-[1196] of Cella teaches an example of a machine learning model along with historical data to determine the current stats and utilizing simulation, par. [1198] to generate a mapping including workflows, [2206] identifying exploits in the rework and provide updates to the process (i.e. workflow)).
identifying a first sequence of transactions that led to the invariant violation (see; par. [2204]-[2207] of Cella teaches determining updates needed based on exploits to the crypto currency transaction process).
implementing, on the online transaction platform, a policy update or a code enhancement corresponding to a fix based on the first sequence of transactions to modify execution of future transactions involving the online transaction platform to eliminate the exploit corresponding to the invariant violation (see; par. [2204]-[2207] of Cella teaches an example of an attempted exploit of a crypto currency transaction process and identifying exploits and a process to making protocol updates to address future transactions).
Cella does not explicitly disclose the following limitations, however,
Arulkumaran teaches generating, for each order of the plurality of orders, a transaction graph based on journal entries of the order, wherein accounts are represented as nodes and transactions are represented as edges (see; pg. 4, col. 1 1.0 Defining the graph representation – col. 2.0 of Arulkumaran teaches constructing a financial transaction graph G = (v, e, f) where nodes represent transaction and users, and edges capture relationships based on shared card numbers, similar merchant categories, and temporal proximity as nodes typically denote accounts or users, and edges represent relationships), and
embedding, by a graph model, the transaction graphs to generate historical graph embeddings (see; pg. 4, col. 2, 2.0 – pg. 5, col. 1 of Arulkumaran teaches the GCN architecture computes nodes embeddings thorugh multiple layers, stacking L layers. These are graph-based embeddings generated from transaction graph structures).
generating graph patterns representative of transaction behavior based on the historical graph embeddings (see; pg. 5, col. 1, 1.0 – col. 2 2.0 fraud risk scores of Arulkumaran teaches generating anomaly scores and fraud probability scores from GCN embeddings. These represent learned patterns of transaction behavior derived from embeddings).
The Examiner notes that Cella teaches similar to the instant application teaches techniques for securing, accessing, and interfacing with enterprise resources. Specifically, Cella discloses an intelligent system used to monitor transactions, as well as pool data, and report results and it is therefore viewed as analogous art in the same field of endeavor. Additionally, Arulkumaran teaches fraud detection in financial transactions using relation-aware graph convolutional networks and as it is comparable in certain respects to Cella which techniques for securing, accessing, and interfacing with enterprise resources as well as the instant application it is viewed as analogous art and is viewed as reasonably pertinent to the problem faced by the inventor. This provides support that it would be obvious to combine the references to provide an obviousness rejection.
Cella discloses the intelligent system used to monitor transactions, as well as pool data, and report results and it is therefore viewed as analogous art in the same field of endeavor. However, Cella fails to disclose generating, for each order of the plurality of orders, a transaction graph based on journal entries of the order, wherein accounts are represented as nodes and transactions are represented as edges, embedding, by a graph model, the transaction graphs to generate historical graph embeddings, and generating graph patterns representative of transaction behavior based on the historical graph embeddings.
Arulkumaran discloses generating, for each order of the plurality of orders, a transaction graph based on journal entries of the order, wherein accounts are represented as nodes and transactions are represented as edges, embedding, by a graph model, the transaction graphs to generate historical graph embeddings, and generating graph patterns representative of transaction behavior based on the historical graph embeddings.
It would be obvious to one of ordinary skill in the art to include in the task management
(system/method/apparatus) of Cella generating, for each order of the plurality of orders, a transaction graph based on journal entries of the order, wherein accounts are represented as nodes and transactions are represented as edges, embedding, by a graph model, the transaction graphs to generate historical graph embeddings, and generating graph patterns representative of transaction behavior based on the historical graph embeddings as taught by Arulkumaran since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additionally, Cella, and Arulkumaran teach the collecting and analysis of data in order to determine detect possible apparatus to detect possible financial fraud behavior and they do not contradict or diminish the other alone or when combined.
Referring to Claim 3, see discussion of claim 1 above, while Cella in view of Arulkumaran teaches the one or more computer storage media above, Cella further discloses the one or more computer storage media having the limitations of, however,
Upon determining the fix for the exploit, updating, by the graph model, the historical graph embeddings (see; par. [2435] of Cella teaches updating the workflow as part of the machine learning model (i.e. simulation), par. [2426] can example of work flows and interaction with simulations).
Referring to Claim 4, see discussion of claim 4 above, while Cella in view of Arulkumaran teaches the one or more computer storage media above, Cella further discloses the one or more computer storage media having the limitations of,
utilizing the large language model to update the workflow to provide an updated workflow (see; par. [2435] of Cella teaches updating the workflow as part of the machine learning model (i.e. simulation), par. [2426] can example of work flows and interaction with simulations, par. [0012] utilizing LLMs to train using data set as a workflow).
Referring to Claim 5, see discussion of claim 4 above, while Cella in view of Arulkumaran teaches the one or more computer storage media above, Cella does not explicitly discloses a computer storage media having the limitations of, however,
Arulkumaran teaches re-simulating, at the simulation engine, the updated workflow with a plurality of combinations of each transaction to determine if the exploit in the updated workflow has been eliminated (see; pg. 6, col. 2, par. 1 of Arulkumaran teaches an example of simulated data set to evaluate fraud tested to ensure the model identifies (i.e. workflow) the fraudulent financial transaction (i.e. eliminate exploit)).
The Examiner notes that Cella teaches similar to the instant application teaches techniques for securing, accessing, and interfacing with enterprise resources. Specifically, Cella discloses an intelligent system used to monitor transactions, as well as pool data, and report results and it is therefore viewed as analogous art in the same field of endeavor. Additionally, Arulkumaran teaches fraud detection in financial transactions using relation-aware graph convolutional networks and as it is comparable in certain respects to Cella which techniques for securing, accessing, and interfacing with enterprise resources as well as the instant application it is viewed as analogous art and is viewed as reasonably pertinent to the problem faced by the inventor. This provides support that it would be obvious to combine the references to provide an obviousness rejection.
Cella discloses the intelligent system used to monitor transactions, as well as pool data, and report results and it is therefore viewed as analogous art in the same field of endeavor. However, Cella fails to disclose re-simulating, at the simulation engine, the updated workflow with a plurality of combinations of each transaction to determine if the exploit in the updated workflow has been eliminated.
Arulkumaran discloses re-simulating, at the simulation engine, the updated workflow with a plurality of combinations of each transaction to determine if the exploit in the updated workflow has been eliminated
It would be obvious to one of ordinary skill in the art to include in the task management
(system/method/apparatus) of Cella the simulating, at the simulation engine, the workflow with a plurality of combinations of each transaction to identify an exploit in the workflow as taught by Arulkumaran since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additionally, Cella, and Arulkumaran teach the collecting and analysis of data in order to determine detect possible apparatus to detect possible financial fraud behavior and they do not contradict or diminish the other alone or when combined.
Referring to Claim 6, see discussion of claim 5 above, while Cella in view of Arulkumaran teaches the one or more computer storage media above, Cella does not explicitly discloses the one or more computer storage media having the limitations of, however,
Arulkumaran teaches determining the exploit in the updated workflow has been eliminated (see; pg. 6, col. 2 – col. 3 of Arulkumaran teaches a performance metrics show a validation of by updating the transaction graph in reel time by incrementally graphing updates and adaptively to detect fraudulent activities (i.e. exploits) to provide timely intervention (i.e. eliminated)).
The Examiner notes that Cella teaches similar to the instant application teaches techniques for securing, accessing, and interfacing with enterprise resources. Specifically, Cella discloses an intelligent system used to monitor transactions, as well as pool data, and report results and it is therefore viewed as analogous art in the same field of endeavor. Additionally, Arulkumaran teaches fraud detection in financial transactions using relation-aware graph convolutional networks and as it is comparable in certain respects to Cella which techniques for securing, accessing, and interfacing with enterprise resources as well as the instant application it is viewed as analogous art and is viewed as reasonably pertinent to the problem faced by the inventor. This provides support that it would be obvious to combine the references to provide an obviousness rejection.
Cella discloses the intelligent system used to monitor transactions, as well as pool data, and report results and it is therefore viewed as analogous art in the same field of endeavor. However, Cella fails to disclose determining the exploit in the updated workflow has been eliminated.
Arulkumaran discloses determining the exploit in the updated workflow has been eliminated.
It would be obvious to one of ordinary skill in the art to include in the task management
(system/method/apparatus) of Cella the determining the exploit in the updated workflow has been eliminated as taught by Arulkumaran since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additionally, Cella, and Arulkumaran teach the collecting and analysis of data in order to determine detect possible apparatus to detect possible financial fraud behavior and they do not contradict or diminish the other alone or when combined.
Referring to Claim 7, see discussion of claim 6 above, while Cella in view of Arulkumaran teaches the one or more computer storage media above, Cella does not explicitly discloses the one or more computer storage media8 having the limitations of, however,
wherein the policy update or the code enhancement corresponding to the fix are implemented in response to determining the exploit in the updated workflow has been eliminated (see; par. [2204]-[2207] of Cella teaches an example of an attempted exploit of a crypto currency transaction process and identifying exploits and a process to making protocol updates to address future transactions).
Referring to Claim 8, Cella in view of Arulkumaran teaches a computer-implemented method. Claim 8 recites the same or similar limitations as those addressed above in claim 1, Claim 8 is therefore rejected for the same reasons as set forth above in claim 1.
Referring to Claim 9, see discussion of claim 8 above, while Cella in view of Arulkumaran teaches the method above. Claim 9 recites the same or similar limitations as those addressed above in claim 2, Claim 9 is therefore rejected for the same or similar limitations as set forth above in claim 2.
Referring to Claim 10, see discussion of claim 9 above, while Cella in view of Arulkumaran teaches the method above. Claim 10 recites the same or similar limitations as those addressed above in claim 3, Claim 10 is therefore rejected for the same or similar limitations as set forth above in claim 3.
Referring to Claim 11, see discussion of claim 10 above, while Cella in view of Arulkumaran teaches the method above. Claim 11 recites the same or similar limitations as those addressed above in claim 4, Claim 11 is therefore rejected for the same or similar limitations as set forth above in claim 4.
Referring to Claim 12, see discussion of claim 11 above, while Cella in view of Arulkumaran teaches the method above. Claim 12 recites the same or similar limitations as those addressed above in claim 5, Claim 12 is therefore rejected for the same or similar limitations as set forth above in claim 5.
Referring to Claim 13, see discussion of claim 12 above, while Cella in view of Arulkumaran teaches the method above. Claim 13 recites the same or similar limitations as those addressed above in claim 6, Claim 13 is therefore rejected for the same or similar limitations as set forth above in claim 6.
Referring to Claim 14, see discussion of claim 13 above, while Cella in view of Arulkumaran teaches the method above. Claim 14 recites the same or similar limitations as those addressed above in claim 7, Claim 14 is therefore rejected for the same or similar limitations as set forth above in claim 7.
Referring to Claim 15, Cella in view of Arulkumaran teaches a system. Claim 15 recites the same or similar limitations as those addressed above in claim 1, Claim 15 is therefore rejected for the same reasons as set forth above in claim 1, except for the following noted exception.
one or more processors and one or more computer storage medium storing computer-usable instructions that, when used by the one or more processors, causes the computer system to perform operations (see; par. [0014] Cella teaches processors and memory).
Referring to Claim 16, see discussion of claim 15 above, while Cella in view of Arulkumaran teaches the method above. Claim 16 recites the same or similar limitations as those addressed above in claim 3, Claim 16 is therefore rejected for the same or similar limitations as set forth above in claim 3.
Referring to Claim 17, see discussion of claim 16 above, while Cella in view of Arulkumaran teaches the method above. Claim 17 recites the same or similar limitations as those addressed above in claim 4, Claim 17 is therefore rejected for the same or similar limitations as set forth above in claim 4.
Referring to Claim 18, see discussion of claim 17 above, while Cella in view of Arulkumaran teaches the method above. Claim 18 recites the same or similar limitations as those addressed above in claim 5, Claim 18 is therefore rejected for the same or similar limitations as set forth above in claim 5.
Referring to Claim 19, see discussion of claim 18 above, while Cella in view of Arulkumaran teaches the method above. Claim 19 recites the same or similar limitations as those addressed above in claim 6, Claim 19 is therefore rejected for the same or similar limitations as set forth above in claim 6.
Referring to Claim 20, see discussion of claim 19 above, while Cella in view of Arulkumaran teaches the method above. Claim 20 recites the same or similar limitations as those addressed above in claim 7, Claim 20 is therefore rejected for the same or similar limitations as set forth above in claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Yee et al. (U.S. Patent 10,726,424 B1) discloses a computer-based systems and platforms and computer-implemented methods configured for one or more technological applications involving reduction of false positive fraud detection incidents.
JASS (U.S. Patent Publication 2022/0138756 A1) discloses systems and methods for a context driven electronic transactions fraud detection.
Krame et al. (U.S. Patent Publication 2023/0316286 A1) discloses reducing false positive fraud alerts for online financial transactions.
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 STEPHEN S SWARTZ whose telephone number is (571)270-7789. The examiner can normally be reached Mon-Fri 9:00 - 6:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Boswell Beth can be reached at 571 272-6737. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/S.S.S/Examiner, Art Unit 3625 /BETH V BOSWELL/Supervisory Patent Examiner, Art Unit 3625
Prosecution Insights