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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on April 1, 2026 has been entered.
Status of Claims
• This action is in reply to the RCE filed on April 1, 2026.
• Claims 1, 9, and 17 have been amended and are hereby entered.
• Claims 1-20 are currently pending and have been examined.
• This action is made Non-FINAL.
Response to Arguments
Applicant’s arguments filed April 1, 2026 have been fully considered but they are not persuasive.
The Examiner is withdrawing the claim objections due to Applicant’s amendments.
Applicant’s arguments with respect to 35 USC § 101 have been fully considered and are not persuasive.
Regarding Applicant’s argument on pages 9-11, that the claims do not recite an abstract idea, the Examiner respectfully disagrees. As indicated in the 35 USC § 101 rejection below, the claimed inventions allows for testing payment rules to use in a transaction system. The Specification at [0023] states:
“Transaction processors play a critical role in ensuring that financial transactions are processed accurately and efficiently. However, testing transaction processors can be a complex and time-consuming process, often involving manual testing procedures that are prone to errors. This can result in inaccurate processing of financial transactions, which can lead to lost revenue, compliance issues, and reputational damage. Additionally, the increasing volume and complexity of financial transactions render traditional testing methods inadequate to simulate real-world scenarios. In some aspects, the present disclosure includes various methods and systems that provide a more efficient and effective transaction processor testing to help organizations ensure the accuracy and reliability of their financial transactions.”
The Specification and claims focus on an improvement to the process of testing payment rules to use in a transaction system to improve transaction processing including improving accuracy of processing financial transactions, which is a commercial and legal interaction including sales activities or behaviors which falls within the category of Certain Methods of Organizing Human Activity and therefore is an abstract idea.
Applicant further argues, on page 10-11, that the claims are directed to the solution of a dual-use transaction map architecture implementing a deterministic input generation and output parsing, and that the claims provide a concrete technical solution to a computer-centric testing problem. The argument is not persuasive. In response to this argument, the Examiner notes that testing transaction parameters to improve the accuracy and reliability of financial transactions (as described in the Specification at [0023]) does not describe a solution of a computer-centric or technological problem, but rather further describes an improvement to the abstract idea of testing payment rules to use in a transaction system to improve transaction processing including improving accuracy of processing financial transactions.
Regarding Applicant’s arguments on page 10, that the Examiner does not identify which sub-category applies, the Examiner respectfully disagrees and notes, as discussed in the 101 rejection below, the claims recite broadest reasonable interpretation, covers commercial and legal interactions, specifically a commercial and legal interaction including sales activities or behaviors.
Regarding Applicant’s arguments on pages 11-12, that the claims integrate a practical application, the Examiner respectfully disagrees. Under the Patent Subject Matter Eligibility analysis, Step 2A, prong two, integration into a practical application requires an additional element(s) or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. Limitations that are not indicative of integration into a practical application are those that generally link the use of the judicial exception into a particular technological environment or field of use-see MPEP 2106.05(h). Here the additional elements of claim 1 include a transaction processor; a transaction-processor tester system comprising a computer system having one or more computer processors, each having instructions stored thereon, that when executed cause the computer system to perform claim functions; a storage medium communicatively coupled with the rule generator; a rule selector communicatively coupled to the storage medium; a condition file. The additional elements of claim 9 include a transaction processor and a condition file. The additional elements of claim 17 include a transaction processor; a computer system having one or more computer processors, each having instructions stored thereon, that when executed cause the computer system to perform claim functions; and a condition file. The additional elements are such that they amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (e.g., a computer network) (see MPEP 2106.05(h)).
Furthermore, and regarding Applicant’s arguments on page 12 where Applicant argues the claims improve technology, in determining whether a claim integrates a judicial exception into a practical application, a determination is made of whether the claimed invention pertains to an improvement in the functioning of the computer itself or any other technology or technical field (i.e., a technological solution to a technological problem). Here, the claims recite generic computer components, i.e., a generic processor, a memory storing a computer program executable by the processor to perform the claimed method steps and system functions. The processor, memory and system are recited at a high level of generality and are recited as performing generic computer functions customarily used in computer applications.
Furthermore, the Specification describes a problem and improvement to a business or commercial process at least at [0023], stating:
“Transaction processors play a critical role in ensuring that financial transactions are processed accurately and efficiently. However, testing transaction processors can be a complex and time-consuming process, often involving manual testing procedures that are prone to errors. This can result in inaccurate processing of financial transactions, which can lead to lost revenue, compliance issues, and reputational damage. Additionally, the increasing volume and complexity of financial transactions render traditional testing methods inadequate to simulate real-world scenarios. In some aspects, the present disclosure includes various methods and systems that provide a more efficient and effective transaction processor testing to help organizations ensure the accuracy and reliability of their financial transactions.”
Regarding Applicant’s arguments on page 12-13 that the claims recite significantly more than the abstract idea, the Examiner respectfully disagrees. The limitations are directed to an abstract idea and when determining if the claims are directed to significantly more, the additional limitations of the claims in addition to the abstract idea are analyzed. In the instant application, the additional elements of claim 1 include a transaction processor; a transaction-processor tester system comprising a computer system having one or more computer processors, each having instructions stored thereon, that when executed cause the computer system to perform claim functions; a storage medium communicatively coupled with the rule generator; a rule selector communicatively coupled to the storage medium; a condition file. The additional elements of claim 9 include a transaction processor and a condition file. The additional elements of claim 17 include a transaction processor; a computer system having one or more computer processors, each having instructions stored thereon, that when executed cause the computer system to perform claim functions; and a condition file. The additional limitations, when considered both individually and in combination, do not affect an improvement to another technology or technological field; the claims do not amount to an improvement to the functioning of the computer itself; and the claims do not move beyond a general link of use of an abstract idea to a particular technological environment. Therefore, the claims merely amount to merely generally linking the use of the abstract idea to a particular technological environment or field of use (e.g., a computer network), and is considered to amount to nothing more than requiring a generic computer network to carry out the abstract idea itself. The specifics about the abstract idea do not overcome the rejection.
Regarding Applicant’s arguments on page 13, that Examiner has not cited to evidence establishing the specific ordered combination of the claims was well-understood, routine, and conventional at the time of filing, the argument is not persuasive. In response to the argument, the Examiner respectfully points out that the additional elements amount to mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea.-see MPEP 2106.05(f). This consideration is different than the Well Understood, Routine, and Conventional Consideration –See MPEP 2106.05(d).
Regarding Applicant’s arguments on page 13, that the Office Action dismisses dependent claims without individual analysis, the Examiner respectfully disagrees and notes that each claim was given the full and proper analysis under the test set forth by the Supreme Court and the Patent Subject Matter Eligibility analysis (see MPEP 2106). Furthermore, features of the dependent claims argued by the Applicant on page 13 (e.g., parameters of transaction data, unique identifiers, expected values) merely further describe the abstract idea.
The claims are not patent eligible.
For the reasons above, Applicant’s arguments are not persuasive.
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 recites an abstract idea without significantly more. Independent claims 1, 9, and 17 are directed to a system (claims 1 and 17) and a method (claim 9). Therefore, on its face, each independent claim 1, 9, and 17 are directed to a statutory category of invention under Step 1 of the Patent Subject Matter Eligibility analysis (see MPEP 2106.03).
Under Step 2A, Prong One of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), claims 1, 9, and 17 recite, in part, a system and a method of organizing human activity. Claim 1 recites a transaction-processor tester system for examining a transaction, the transaction-processor tester system comprising: create, by a rule generator, random transaction rules based on predefined transaction parameters and predefined limits associated with the predefined transaction parameters; receive and store the random transaction rules; receive an input indicative of at least one selected rule type at a rule selector; retrieve a subset of the random transaction rules based on the input at the rule selector; generate simulated transactions by a transaction generator based on a predefined transaction map and predefined transaction-parameter conditions, wherein the predefined transaction map defines parameter placements and parameter sizes for transaction fields, wherein generating the simulated transactions comprises populating the transaction fields according to the parameter placements and parameter sizes defined by the predefined transaction map, wherein each simulated transaction comprises a structured data record including fields positioned and sized according to the predefined transaction map, wherein the predefined transaction-parameter conditions are read, wherein generating the simulated transaction further comprises selecting simulated transactions by matching conditions from the condition file to parameters in the simulated transactions; determine, by the transaction generator, expected values associated with the processing of the simulated transactions based on the subset of the random transaction rules, wherein the expected values comprise, for each rule identifier of the subset of the random transaction rules matched to the simulated transactions, at least (i) an aggregate transaction count and (ii) an aggregate measure derived from a transaction parameter; output, by the transaction generator, expected values based on the simulated transactions that are in accordance with the subset of the random transaction rules; receive, at a payload parser, a payload, the payload comprising an output of the transaction processor from processing the subset of the simulated transactions; identify relevant fields in the payload, by the payload processor, using the predefined transaction map; extract, by the payload processor, actual values from the output of the transaction processor based on the relevant fields, wherein the actual value comprise, for each rule identifier, at least (i) a transaction count and (ii) an aggregate measure derived from the transaction parameter; and output, by a payload validator, a test result for the transaction processor based on the actual values and expected values, wherein the test results indicates a failure responsive to a mismatch between the actual values and expected values and indicates a success responsive to a match.
Claim 9 recites a method for testing, the method comprising: generating random transaction rules based on predefined transaction parameters and predefined limits associated with the predefined transaction parameters; determining a subset of the random transaction rules corresponding to at least one selected rule type; generating simulated transactions based on a predefined transaction map and predefined transaction-parameter conditions,
wherein generating the simulated transactions comprises populating transaction fields according to parameter placements and parameter sizes defined by the predefined transaction map, wherein each simulated transaction comprises a structured data record including fields positioned and sized according to the predefined transaction map, wherein the predefined transaction-parameter conditions are read and wherein generating further comprises selecting simulated transactions by matching the predefined transaction-parameter conditions to parameters in the simulated transactions; determining expected results associated with processing of the simulated transactions based on the subset of the random transaction rules, wherein determining expected results comprises generating, for each matched rule identifier, an expected aggregate transaction count and an expected aggregate measure derived from a transaction parameter , wherein determining expected values comprises, for each matched rule identifier, incrementing a transaction count and accumulating a transaction parameter aggregate responsive to each simulated transaction matched to the rule; receiving a payload resulting from an input of the simulated transactions and the subset of random transaction rules; identifying relevant fields in the payload using the predefined transaction map, wherein identifying relevant fields comprises querying a payload map to locate field boundaries in the payload; extracting test results from the payload of the transaction processor based on the relevant fields, wherein the test results comprise, for each rule identifier, at least (i) a transaction count and (ii) an aggregate measure derived from the transaction parameter ,wherein extracting test results comprises extracting, from the payload, the rule identifier, a transaction count, and an aggregate transaction parameter measure corresponding to transactions matched to the rule; and determining an operational state based on the expected results and actual results, wherein determining the operational state comprises indicating a successful state responsive to a match and a failed state responsive to a mismatch between the expected results and extracted test results.
Claim 17 recites a transaction-processor tester system for examining, the transaction-processor tester system comprising: create random transaction rules, by a rules generator, based on predefined transaction parameters and predefined limits associated with the predefined transaction parameters; receive, by a rule selector, an input indicative of at least one selected rule type; retrieve, by the rule selector, a subset of the random transaction rules based on the input; generate, by a transaction generator, simulated transactions based on a predefined transaction map and predefined transaction-parameter conditions; wherein the predefined transaction map defines parameter placements and parameter sizes for transaction fields, wherein generating the simulated transactions comprises populating the transaction fields according to the parameter placements and parameter sizes defined by the predefined transaction map, wherein each simulated transaction comprises a structured data record including fields positioned and sized according to the predefined transaction map, wherein the predefined transaction-parameter conditions are read, and wherein generating the simulated transactions further comprise selecting simulated transactions by matching conditions to parameters in the simulated transactions; determining, by a transaction generator, expected results associated with processing of the simulated transactions based on the subset of the random transaction rules, wherein the expected results comprise, for each rule identifier of the subset of the random transaction rules matched to the simulated transactions, at least (i) an aggregate transaction count and (ii) an aggregate measure derived from a transaction parameter; receive, by a payload parser, a payload from the transaction processor, the payload comprising an output of the transaction processor from processing the subset of the simulated transactions; identify, by the payload parser, relevant fields in the payload using the predefined transaction map; extract, by the payload parser, actual results from the output of the transaction processor based on the relevant fields, wherein the actual results comprise, for each rule identifier, at least (i) a transaction count and (ii) an aggregate measure derived from the transaction parameter; output, by a payload validator, test result based on the actual results and expected results, wherein the test result indicates a failure responsive to a mismatch between the test results and expected values and indicates a success responsive to a match.
The Specification at [0023] states:
“Transaction processors play a critical role in ensuring that financial transactions are processed accurately and efficiently. However, testing transaction processors can be a complex and time-consuming process, often involving manual testing procedures that are prone to errors. This can result in inaccurate processing of financial transactions, which can lead to lost revenue, compliance issues, and reputational damage. Additionally, the increasing volume and complexity of financial transactions render traditional testing methods inadequate to simulate real-world scenarios. In some aspects, the present disclosure includes various methods and systems that provide a more efficient and effective transaction processor testing to help organizations ensure the accuracy and reliability of their financial transactions.”
The limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers commercial and legal interactions (certain methods of organizing human activity), but for the recitation of generic computer components. The claims as a whole recite a method of organizing human activity. The claimed inventions allows for testing payment rules to use in a transaction system, which is a commercial and legal interaction including sales activities or behaviors. The mere nominal recitation of a transaction processor do not take the claim out of the methods of organizing human activity grouping. Thus, the claims recite an abstract idea.
Under Step 2A, Prong Two of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), the judicial exception is not integrated into a practical application. In particular, the additional elements of claim 1 include a transaction processor; a transaction-processor tester system comprising a computer system having one or more computer processors, each having instructions stored thereon, that when executed cause the computer system to perform claim functions; a storage medium communicatively coupled with the rule generator; a rule selector communicatively coupled to the storage medium; a condition file. The additional elements of claim 9 include a transaction processor and a condition file. The additional elements of claim 17 include a transaction processor; a computer system having one or more computer processors, each having instructions stored thereon, that when executed cause the computer system to perform claim functions; and a condition file. The additional elements are recited at a high-level of generality (i.e., as a generic computer performing generic computer functions of receiving input and generating simulated transactions and outing a result) such that it amounts to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (e.g., a computer network).-see MPEP 2106.05(h).
Accordingly, the combination of the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under Step 2B of the Patent Subject Matter Eligibility analysis (see MPEP 2106.05), the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the claims amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)). Generally linking the use of the judicial exception to a particular technological environment or field of use using generic computer components cannot provide an inventive concept.
The claims are not patent eligible.
The dependent claims have been given the full two part analysis including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. Dependent claims 2-8, 10-16, and 18-20 simply help to define the abstract idea. The additional limitations of the dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
Viewing the claim limitations as an ordered combination does not add anything further than looking at the claim limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea. Accordingly, claims 1-20 are ineligible.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 12106298 B1 (“Durieux”) discloses design, test, development, certification, deployment, and maintenance infrastructures for payment solutions are disclosed herein. A disclosed system includes a software binaries generator for generating an executable for a source code file. The source code file includes an EMV kernel. The disclosed system also includes a testing environment that accepts the executable and simulates the executable with a virtual payment processing hardware system in a simulation. The testing environment verifies EMV compliance for the executable via the simulation. The disclosed system also includes a security module that generates a proof of trust for the executable in response to the testing environment verifying EMV compliance for the executable and provides the proof of trust for the executable for an external EMV compliance authority.
US 20240020219 A1 (“Jain”) discloses determining test cases to be run upon changes in software application code. In one embodiment, a system receives a test suite containing multiple test cases designed to perform the testing of a software application, the software application containing one or more components. The system executes each test case to determine a corresponding sequence of components executed in the software application for the test case, and then stores a dependency data indicating for each test case the corresponding determined sequence of components. Upon determining that a first component has been changed, the system identifies a first set of test cases that cause execution of the first component by performing a reverse look-up in the dependency data. The system then includes the identified first set of test cases in the test cases to be run for re-testing the software application.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAVEN E YONO whose telephone number is (313)446-6606. The examiner can normally be reached Monday - Friday 8-5PM EST.
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, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/RAVEN E YONO/Primary Examiner, Art Unit 3694
Prosecution Insights