Prosecution Insights
Last updated: April 19, 2026
Application No. 18/344,541

SYSTEM AND METHOD FOR BREAK RESOLUTION AUTOMATION

Non-Final OA §101§103§112
Filed
Jun 29, 2023
Examiner
YU, ARIEL J
Art Unit
3627
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
The Bank Of New York Mellon
OA Round
3 (Non-Final)
40%
Grant Probability
At Risk
3-4
OA Rounds
4y 3m
To Grant
67%
With Interview

Examiner Intelligence

Grants only 40% of cases
40%
Career Allow Rate
155 granted / 389 resolved
-12.2% vs TC avg
Strong +27% interview lift
Without
With
+27.4%
Interview Lift
resolved cases with interview
Typical timeline
4y 3m
Avg Prosecution
41 currently pending
Career history
430
Total Applications
across all art units

Statute-Specific Performance

§101
18.2%
-21.8% vs TC avg
§103
55.2%
+15.2% vs TC avg
§102
13.6%
-26.4% vs TC avg
§112
10.1%
-29.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 389 resolved cases

Office Action

§101 §103 §112
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 11/20/2025 has been entered. Response to Amendment Applicant’s “Amendment” filed on 11/11/2025 has been considered. Claims 1 and 15 are amended. Claims 1-[28 remain pending in this application and an action on the merits follow. Applicant’s response by virtue of amendment to claims has not overcome the Examiner’s rejection under 35 USC § 101. Information Disclosure Statement The information disclosure statement (IDS) submitted on 01/29/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 1 and 15 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The proposed limitations includes “the classification engine executes model inference on break data and applies rule-based validation logic to a classification result” and “the repair transaction comprising mapped data fields” which are not described or supported by the specification. Paragraph 15 describes embodiments described herein mitigate these issues with a reconciliation system that facilitates classification, validation, and resolution of breaks in an automated fashion. However, the specification does not describe how does the classification engine apply rule-based validation logic to a classification result. Paragraph 47 describes each classification is mapped to a workflow, such as by a lookup table. However, the specification does not describe the repair transaction comprising mapped data fields. 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-28 are rejected under 35 USC 101. The claimed invention is directed to non-statutory subject matter because claims 1 and 15 are directed to an abstract idea without significantly more. Claims 2-14 and 16-28 fail to remedy these deficiencies. The claims 1 and 15 recite receiving an indication of a break, identifying a set of transactions associated with the break, obtaining internal data, receiving external data, classifying the break using a combination of rule-based logic and one or more machine learning models, wherein the classification engine executes model inference on break data and applies rule-based validation logic to a classification result, determining a type of repair by selecting a predefined workflow path corresponding to the break classification, and initiating a break resolution by generating a repair transaction formatted according to a schema corresponding to a record source and transmitting the repair transaction to the corresponding record source through an application programming interface (API). Claims 1 and 15 recite receiving an indication of a break, identifying, determining a type of repair by selecting a predefined workflow, initiating a break resolution, generating, and transmitting through an application programming interface (API) steps as drafted, are processes that under broadest reasonable interpretation, cover performance of managing human activities, but for the recitation of generic computer components. That is, other than reciting “a computer having a processor and a memory, at least one record system, and one or more code sets stored in the memory and executed by the processor, which, when executed, configure the processor to”, nothing in the claim element precludes the steps from practically being performed by organizing human activity. For example, but for “a computer having a processor and a memory, at least one record system, and one or more code sets stored in the memory and executed by the processor, which, when executed, configure the processor to” in the context of these claims encompasses a person manually receives an indication of a break, identifies a set of transactions associated with the break, determines a type of repair by selecting a workflow path, initiates a break plan/resolution by generating a compatible format based on a schema, and transmits the break plan/resolution thru an interface. The ability of an application programming interface to transmit data is generic data process. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation by managing human activities but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea. The limitation of classifying the set of transactions by executing and applying a combination of rule-based logic and one or more machine learning models step as drafted, is a process that under broadest reasonable interpretation, cover performance of the limitation by utilizing mathematical algorithms/modeling but for the recitation of generic computer components. That is, other than reciting “a computer having a processor and a memory, at least one record system, and one or more code sets stored in the memory and executed by the processor, which, when executed, configure the processor to”, nothing in the claim element precludes the step from practically being performed by utilizing mathematical algorithms/modeling. Training a machine learning model and apply this trained model is generic data process. They do not describe any particular improvement in the manner a computer functions. In particular, the courts have found mathematical algorithms to be abstract ideas (e.g., a mathematical procedure for converting one form of numerical representation to another in Benson. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation by utilizing mathematical algorithms/modeling but for the recitation of generic computer components, then it falls within the “Mathematical Concepts” grouping of abstract ideas. Accordingly, the claims recite an abstract idea. This judicial exception is not integrated into a practical application because obtaining and receiving steps are recited at a high level of generality (i.e., as a general means of retrieving data) and amounts to mere data gathering, which is a form of insignificant extra-solution activity. This judicial exception is not integrated into a practical application because the claims as a whole merely describe how to generally “apply” the concept of receiving, identifying, obtaining, classifying, determining, initiating, generating, and transmitting in a computer environment. The claimed computer components such as the computer, the record system, the processor, and the memory are recited at a high level of generality and are merely invoked as tools to perform receiving, identifying, obtaining, classifying, determining, initiating, generating, and transmitting steps. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. 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 claims 1 and 15 are directed to an abstract idea. The claims 1 and 15 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 of using the computer, the record system, the processor, and the memory to perform receiving, identifying, obtaining, classifying, determining, initiating, generating, and transmitting steps amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Therefore, the claims do not amount to significantly more than the recited abstract idea (Step 2B: NO). The claims 1 and 15 are not patent eligible. Claims 2-5 and 16-19 disclose insignificant helpful content to further describe content, such as various types of breaks, metadata associated with the set of transactions, the external data from respective external application programming interfaces is used to confirm the accuracy of the internal data, which are merely descriptive content to further limit the abstract idea but not make it less abstract. Thus, the claims 2-5 and 16-19 are directed to an abstract idea. This judicial exception is not integrated into a practical application because descriptive content in claims 2-5 and 16-19 further limit the abstract idea but not make it less abstract. Thus, the claims 2-5 and 16-19 are directed to an abstract idea. There are no additional claim element limitations recited in the claims 2-5 and 16-19. Therefore, the claim does not amount to significantly more than the recited abstract idea (Step 2B: NO). The claims 2-5 and 16-19 are not patent eligible. The claims 6-7 and 20-21 recite applying the combination of rule-based logic and one or more machine learning models and identifying a characteristics of the break steps. Claims 6-7 and 20-21 recite applying and classifying steps as drafted, are processes that under broadest reasonable interpretation, cover performance of the limitation by utilizing mathematical algorithms/modeling but for the recitation of generic computer components. That is, other than reciting “the computer, the record system, the processor, and the memory”, nothing in the claim element precludes the steps from practically being performed by utilizing mathematical algorithms/modeling. In other words, the claimed method simply describes the concept of applying the combination of rule-based logic and one or more machine learning models to identify a characteristics of a break. Training a machine learning model and apply this trained model is generic data process. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation by utilizing mathematical algorithms/modeling but for the recitation of generic computer components, then it falls within the “Mathematical Concepts” grouping of abstract ideas. Accordingly, the claims recite an abstract idea. This judicial exception is not integrated into a practical application because the claims as a whole merely describe how to generally “apply” the concept of applying and identifying in a computer environment. The claimed computer component such as the computer, the record system, the processor, and the memory are recited at a high level of generality and is merely invoked as a tool to perform applying and identifying steps. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. 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 claims 6-7 and 20-21 are directed to an abstract idea. The claims 6-7 and 20-21 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 of using the computer, the record system, the processor, and the memory to perform applying and identifying steps amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Therefore, the claims do not amount to significantly more than the recited abstract idea (Step 2B: NO). The claims 6-7 and 20-21 are not patent eligible. The claims 8-11 and 22-25 recite determining a specific workflow, dispatching the specific workflow, determining properties of actions, constructing repair transactions to effectuate the repair, and selecting one or more of predefined mappings steps. Claims 8-11 and 22-25 recite determining, dispatching, constructing, and selecting steps as drafted, are processes that under broadest reasonable interpretation, cover performance of managing commercial interactions and fundamental economic practices, but for the recitation of generic computer components. That is, other than reciting “a computer having a processor and a memory; and one or more code sets stored in the memory and executed by the processor, which, when executed, configure the processor to”, nothing in the claim element precludes the steps from practically being performed by organizing human activity for commercial interactions and fundamental economic practices. For example, but for “a computer having a processor and a memory; and one or more code sets stored in the memory and executed by the processor, which, when executed, configure the processor to” in the context of these claims encompasses a person manually determines a specific workflow, dispatches the specific workflow, determines properties of actions, constructs repair transactions to effectuate the repair, and selects one or more of predefined mappings. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation by managing commercial interactions and fundamental economic practices but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea This judicial exception is not integrated into a practical application because the claims as a whole merely describe how to generally “apply” the concept of determining, dispatching, constructing, and selecting in a computer environment. The claimed computer component such as the computer, the processor, and the memory are recited at a high level of generality and is merely invoked as a tool to perform determining, dispatching, constructing, and selecting steps. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. 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 claims 8-11 and 22-25 are directed to an abstract idea. The claims 8-11 and 22-25 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 of using the computer, the processor, and the memory to perform determining, dispatching, constructing, and selecting steps amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Therefore, the claims do not amount to significantly more than the recited abstract idea (Step 2B: NO). The claims 8-11 and 22-25 are not patent eligible. The claims 12-14 and 26-28 recite updating a break status, determining an identifier, transmitting the identifier to a reconciliation utility, transmitting the repair transactions to at least one record system, receiving updated records of transactions, identifying repair transactions, match the repair transactions to the break based on the identifier, and determining whether the repair transactions revolves the break steps. Claims 12-14 and 26-28 recite updating, determining, transmitting, identifying, and matching steps as drafted, are processes that under broadest reasonable interpretation, cover performance of managing commercial interactions and fundamental economic practices, but for the recitation of generic computer components. That is, other than reciting “a system, a processor, a memory, and at least one record system”, nothing in the claim element precludes the steps from practically being performed by organizing human activity for commercial interactions and fundamental economic practices. For example, but for “a system, a processor, a memory, and at least one record system” in the context of these claims encompasses a person manually updates a break status, determines an identifier, transmits the identifier to a reconciliation utility, transmits the repair transactions to record, identifies repair transactions, matches the repair transactions to the break based on the identifier, and determines whether the repair transactions revolves the break. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation by managing commercial interactions and fundamental economic practices but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea This judicial exception is not integrated into a practical application because receiving step are recited at a high level of generality (i.e., as a general means of retrieving data) and amounts to mere data gathering, which is a form of insignificant extra-solution activity. This judicial exception is not integrated into a practical application because the claims as a whole merely describe how to generally “apply” the concept of updating, determining, transmitting, receiving, identifying, and matching in a computer environment. The claimed computer component such as the computer, the processor, the memory, and the record system are recited at a high level of generality and is merely invoked as a tool to perform updating, determining, transmitting, identifying, and matching steps. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. 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 claims 12-14 and 26-28 are directed to an abstract idea. The claims 12-14 and 26-28 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 of using the computer, the processor, the memory, and the record system to perform updating, determining, transmitting, identifying, and matching steps amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Therefore, the claims do not amount to significantly more than the recited abstract idea (Step 2B: NO). The claims 12-14 and 26-28 are not patent eligible. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1-28 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2020/0364801 to Basra, in view of U.S. Patent Application Publication No. 2009/0106578 to Dilman et al. With regard to claims 1 and 15, Basra discloses a system for identifying, evaluating, and repairing a break, comprising: a computer having a processor and a memory (paragraph 37); and one or more code sets stored in the memory and executed by the processor, which, when executed, configure the processor to (paragraph 37): receive an indication of a break that has occurred in a transaction system (paragraphs 37 and 48, cause the payment reconciliation engine to generate, in response to detecting at least one payment discrepancy between the expected contract payment amount and the second Payor paid amount, a first portion of claim discrepancy data. flag discrepancies between the payments made and the correlated transaction pricing); identify a set of transactions associated with the break (fig. 14, paragraphs 48 and 264, generate claim discrepancy data including at least claim identifications and discrepancy amounts, and provide access to the claim discrepancy data); obtain internal data pertaining to the break from at least one record system (fig. 14, paragraphs 48 and 264, the received inputs include contract data regarding transaction pricing and transaction data regarding specific transactions and related payments made. The received parsed transaction data with appropriate parsed contract data in the contract rules database. Examiner notes that contract data is considered as “internal data”); receive external data pertaining to the break from one or more external systems (fig. 14, paragraphs 48, 50, and 264, the transaction automation engine is configured to receive the transaction data. Payor payments made in the claim data can be compared with pricing information in the contract data. receive transaction data in a plurality of different formats from a plurality of different service providers. Examiner notes that transaction data is considered as “external data”); classifying, by a classification engine, using a combination of rule-based logic and one or more machine learning models, the break based on the set of transactions, the internal data, and the external data, wherein the classification engine executes model inference on break data and applies rule-based validation logic to a classification result (paragraphs 56, 59, 212, 225-229, 264-265, and 361, and claim 10, Client data can be in the form of contract files and claim files, among other forms of client data. Contract files can be input into the Contract Ingestion Engine 822 by way of a contract file input portal or terminal 811, while claim files can be input into the Claim Automation Engine 824 by way of a claim file input portal or terminal 813. A regular user accessing this GUI page can import external lists of claim numbers that can be assigned to the same case, which allows users to easily add more claims to an existing case. Examiner notes that Contract files can be imported from external sources which is considered as “classifying the break based on the external data”. The present disclosure relates in various embodiments to new transaction analysis and asset recovery systems and methods that are able to analyze massive amounts of complex transactions across many providers and payors to recover lost assets and establish improved rules for analyzing past, current, and future transactions. If there is a difference, the system can uncover reasons for the issue and link issue codes to payor transaction codes when identifying transactions that have been paid incorrectly. Similar mis-pays or other problems can then be put into specific groups. The learning process can use a previously trained Multiclass Neural Network model to perform the categorizations. For example, if a text block is categorized as “Amount Per Diem” the system knows to analyze that text block for a currency value and to parse it as a billing rate. In addition, the Contract Ingestion Engine may also analyze contracts and transaction properties to create machine learning insights for future contract data processing. discrepancies between payments made and pricing information can be flagged. At the next process step 1410, claim discrepancy data can be generated. The separated flagged discrepancies can be placed into categories. separate flagged discrepancies by payor, place the separated flagged discrepancies into categories, wherein the categories include one or more of denials, underpayments, unique short pays, systemic discrepancies of the same error type, or overcollections, and rebill each payor according to its respective flagged discrepancies. Formed contract rules can be validated to detect errors in the OCR processing or analysis by the Contract Ingestion Engine. Examiner notes that a Contract Ingestion Engine can be considered as “a classification engine”. Examiner notes that a Contract Ingestion Engine executes a machine learning process that categorizes each text element and applied the formed contract rules to validate and detect errors in the OCR processing or analysis, which is considered as “the classification engine executes model inference on break data and applies rule-based validation logic to a classification result”. Examiner notes that the flagged discrepancy transactions, the received payments/transaction, and the contract data/pricing (i.e., collected/imported from internal sources or external sources) are analyzed, thru the system rules and the machine learning model, to place the separated flagged discrepancies into specific categories/groups, wherein the categories include systemic discrepancies of the same error type, or overcollections, which is considered as “classify, using a combination of rule-based logic and one or more machine learning models, the break based on the set of transactions, the internal data, and the external data”); and generating a repair transaction comprising mapped data fields formatted according to a schema corresponding to a record source and transmitting the repair transaction to the corresponding record source through an application programming interface (API) (Paragraphs 35, 40, 48. 50, 178, 213, 226, 245, and 259, parse the normalized transaction data, and populate a transactions database with the parsed transaction data. correlate a set of specific transaction data portions with appropriate specific contract data portions. At a following process step 904, the accessed contract data can be normalized. This can involve logically organizing text fragments into rows and columns and correcting for any skew where needed. At a following process step 1104, the accessed claim data can be normalized. This can involve converting the claim data from an EDI file format as received to a more usable format for further processing, such as, for example, a JSON format. Examiner notes that the accessed claim data can be normalized to a normalized format, which is considered as “a repair transaction comprising mapped data fields formatted”. In particular, such transaction analysis and asset recovery systems and methods can include various specialized engines that can rapidly normalize, parse, analyze, and provide reports on massive amounts of data from many sources and in a wide variety of different original formats. Additional method(s), system(s) and/or computer program product(s) may be further operable to cause at least one processor to execute additional instructions to convert data from electronic data interchange (“EDI”) files to converted data of a different format. In at least one embodiment, the converted data is in JavaScript Object Notation (“JSON”) format. normalize the received transaction data into a format that is readily usable by the computing system. temporary storage and service function modules 850, 851, 852, which can be microservices on a serverless cloud architecture that convert data from an EDI format to a JavaScript Object Notation (“JSON”) format, among other functions, before then being stored as claim data sets in the Claims Database 825. The Payment Reconciliation Engine can thus tie benefit codes in the software of multiple parties, can fix a systemic mistake that concerns many clients, and can fix many missed or erroneous payments by payors. System 700 can include a system front end 710 having user terminals 711, 712, 713, 714 configured for inputting data and reviewing data analysis results, as well as a system back end 720 having multiple different engines performing functions on the input data. An application programming interface (“API”) layer 730 can facilitate communications between various disparate front end and back end components. Examiner notes that a fixed/correction transaction is generated/converted into a format that is readily usable by the computing system and the fixed/correction transaction can be transmitted/updated into the database thru An application programming interface (“API”) layer, which is considered as “generating a repair transaction formatted according to a schema corresponding to a record source and transmitting the repair transaction to the corresponding record source through an application programming interface (API)”). Basra does not disclose determine, by a workflow engine, a type of repair to perform based at least in part on the classification of the break by selecting a predefined workflow path corresponding to the break classification; and initiate, by a posting engine, a break resolution based on the determined type of repair. However, Dilman teaches determine, by a workflow engine, a type of repair to perform based at least in part on the classification of the break by selecting a predefined workflow path corresponding to the break classification ( computer 811 uses a mapping of failure types to repair types (see map 195 in FIGS. 1A-1C) to identify the repair types applicable to each specific failure in the selected highest level group. map 195 (FIGS. 1A-1C) associates each failure type with multiple repairs (as per act 421 in FIG. 4D), based on repair types that are mapped to the failure type in a predetermined map. In one example, a failure is that a block is corrupt, then the following three repairs are possible. groupings of failures are used to create repairs that are included in a repair plan, in other embodiments such groups are not used. For example, a repair template is associated in certain embodiments with a specific failure type only and with none others, in which case a repair is created (by instantiating the template) at the same time as the failure to which it corresponds. Act 313 of some embodiments chooses a repair description to include in each repair, from a set of predefined descriptions which are associated with the corresponding repair templates. Similarly, another repair plan 330M is also created in act 313, by use of the repair types 321M, 322M and 323M to identify the corresponding templates 324M, 325M and 326M and customize them with failure parameters of the failures being fixed to create the respective repairs. Fig. 3C, paragraphs 108, 113, 142, and 148); and initiate, by a posting engine, a break resolution based on the determined type of repair (performing act 360 to execute the selected plan, fig. 3D, paragraph 123). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Basra to include, determine, by a workflow engine, a type of repair to perform based at least in part on the classification of the break by selecting a predefined workflow path corresponding to the break classification; and initiate, by a posting engine, a break resolution based on the determined type of repair, as taught in Dilman, in order to automatically executes the selected repair(s), to generate corrected data to fix the selected failure(s) in said data storage system (Dilman, paragraph 10). With regard to claims 2 and 16, Basra discloses the break is one of: a trade break, a reconciliation break, a dividend break, a security position break, a trade settlement break, a corporate action break, a withholding tax break, a securities lending break, a short-term investment fund interest break, a custody fee break, a loan principal prepayment break, a loan interest prepayment break, or a management fee break (paragraphs 38 and 42, perform payment reconciliation analysis on a first set of claim records). With regard to claims 3 and 17, Basra discloses the internal data pertaining to the break comprises metadata associated with the identified set of transactions (paragraph 228, pricing information can be identified in the parsed contract data. Pricing information can be particularly useful in the formation of contract rules to be stored on the Contract Rules Database.). With regard to claims 4 and 18, Basra discloses the external data is received from the one or more external systems via respective external application programming interfaces (APIs) (paragraphs 158-160, API Interface(s) to Application Server System(s) (e.g., 546) which, for example, may be operable to facilitate and manage communications and transactions with API Interface(s) to Application Server System(s)). With regard to claims 5 and 19, Basra discloses the data received from the one or more external systems is used to confirm the accuracy of the internal data pertaining to the break (paragraphs 48 and 263-265, correlate the received parsed transaction data with appropriate parsed contract data in the contract rules database, compare payments made in the received parsed transaction data with transaction pricing in the correlated parsed contract data). With regard to claims 6 and 20, Basra discloses classifying the break comprises: applying the combination of rule-based logic and one or more machine learning models, to the internal data and the received external data (paragraphs 56, 59, 212, 225-229, 264-265, and 361, and claim 10). With regard to claims 7 and 21, the combination of references discloses classifying the break further comprises: identifying a characteristic of the break based on the application of the combination of rule-based logic and one or more machine learning models to the internal data and the received external data (Basra, paragraphs 56, 59, 212, 225-229, 264-265, and 361, and claim 10, Dilman, paragraphs 33, 39, and 101, Failures identified by data recovery advisor 100 are distinguished from errors that occur in data storage system 10 as follows. Each failure unambiguously describes a specific problem (which is one of several problems that are known to occur).). With regard to claims 8 and 22, Basra substantially discloses the claimed invention, however, Basra does not disclose determining a specific workflow path of a predefined set of workflow paths based at least in part on the classification. However, Dilman teaches determining a specific workflow path of a predefined set of workflow paths based at least in part on the classification (one of the repair types is automatically selected in act 313 for each failure type, and the selected repair type is used to prepare a repair plan, paragraph 109). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Basra to include, determining a specific workflow path of a predefined set of workflow paths based at least in part on the classification, as taught in Dilman, in order to automatically executes the selected repair(s), to generate corrected data to fix the selected failure(s) in said data storage system (Dilman, paragraph 10). With regard to claims 9 and 23, Basra substantially discloses the claimed invention, however, Basra does not disclose dispatching the specific workflow path to repair the break. However, Dilman teaches dispatching the specific workflow path to repair the break (Specifically repair type 321A requires no human involvement to execute steps for repair identified in a corresponding template 324A, paragraph 112). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of references to include, dispatching the specific workflow path to repair the break, as taught in Dilman, in order to automatically executes the selected repair(s), to generate corrected data to fix the selected failure(s) in said data storage system (Dilman, paragraph 10). With regard to claims 10 and 24, Basra substantially discloses the claimed invention, however, Basra does not disclose determining properties of one or more actions selected to perform the repair based on the specific workflow path; and constructing one or more repair transactions to effectuate the repair based on the one or more actions and their determined properties. However, Dilman teaches determining properties of one or more actions selected to perform the repair based on the specific workflow path; and constructing one or more repair transactions to effectuate the repair based on the one or more actions and their determined properties (each of repair templates 324A, 325A and 326A is customized with parameters 239 (FIG. 2E) of the corresponding failures being fixed, to create the corresponding repairs 331A, 332A and 333A. a repair 331A also includes a detailed description of the actions to be done for display to a human user (e.g. in act 359). Act 313 of some embodiments chooses a repair description to include in each repair, from a set of predefined descriptions which are associated with the corresponding repair templates. computer 811 uses the repair steps identified in a repair plan to generate a repair script for executing the repairs and store the script (as per act 359) in a repository on disk., paragraphs 112-113 and 122). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Basra to include, determining properties of one or more actions selected to perform the repair based on the specific workflow path; and constructing one or more repair transactions to effectuate the repair based on the one or more actions and their determined properties, as taught in Dilman, in order to automatically executes the selected repair(s), to generate corrected data to fix the selected failure(s) in said data storage system (Dilman, paragraph 10). With regard to claims 11 and 25, Basra substantially discloses the claimed invention, however, Basra does not disclose selecting one or more of predefined mappings or transformations based on a record system to which a given one of the repair transactions is to be posted to effectuate the repair; and applying, for at least one of the determined actions and its properties, the one or more predefined mappings or transformations to generate repair transaction information for the repair transaction in a schema of the record system. However, Dilman teaches selecting one or more of predefined mappings or transformations based on a record system to which a given one of the repair transactions is to be posted to effectuate the repair; and applying, for at least one of the determined actions and its properties, the one or more predefined mappings or transformations to generate repair transaction information for the repair transaction in a schema of the record system (One or more types of repairs are automatically identified in act 106, e.g. by use of map 195 which is implemented in some embodiments as a lookup table. The table (which implements map 195) is static and it is set up ahead of time in a memory of computer system 800, during initialization and startup of data recovery advisor 100. The computer uses a map that associates each failure type with repair types that are alternatives to one another, and uses another map that associates each repair type with a template that creates the repair when instantiated. In certain embodiments, repairs within a repair plan are consolidated, to avoid duplicates and redundancies. paragraphs 49, 107-109, abstract). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Basra to include, selecting one or more of predefined mappings or transformations based on a record system to which a given one of the repair transactions is to be posted to effectuate the repair; and applying, for at least one of the determined actions and its properties, the one or more predefined mappings or transformations to generate repair transaction information for the repair transaction in a schema of the record system, as taught in Dilman, in order to automatically executes the selected repair(s), to generate corrected data to fix the selected failure(s) in said data storage system (Dilman, paragraph 10). With regard to claims 12 and 26, Basra discloses upon completion of the break resolution, updating a break status of the break (paragraph 157, Status Tracking Component(s) (e.g., 512) which, for example, may be operable to automatically and/or dynamically determine, assign, and/or report updated transaction status). With regard to claims 13 and 27, Basra discloses determining an identifier corresponding to the break (paragraphs 48, contract data regarding transaction pricing and transaction data regarding specific transactions.); transmitting the identifier corresponding to the break to a reconciliation utility from which the indication of the break is received for association with the break (paragraph 48, the payment reconciliation engine is configured to receive parsed transaction data from the transaction instances database, correlate the received parsed transaction data with appropriate parsed contract data in the contract rules database. flag discrepancies between the payments made and the correlated transaction pricing); and transmitting one or more repair transactions for initiating the break resolution to at least one record system, the one or more repair transactions having transaction information including the identifier corresponding to the break (paragraphs 44, 57, and 60, rebill each payor according to its respective flagged discrepancies. establish new rules based on errors found in the data, and assist in recovering lost assets due to billing and payment errors found in the data. Still another type of claim recovery can be termed Over-Collections, which can involve an underbilled error on the part of the healthcare provider. These claims can simply be rebilled at the proper rate.). With regard to claims 14 and 28, Basra discloses the reconciliation utility: receives updated records of transactions including new transactions including the one or more repair transactions (paragraphs 48-49, the payment reconciliation engine is further configured to generate a message to trigger a new process when the new rule is created, the new process including comparing payments made in the received parsed transaction data with correlated transaction pricing in the parsed contract data for claims affected by the new rule); identifies repair transactions from other new transactions in the records of transactions based on inclusion of a break identifier in their transaction information; matches the one or more repair transactions to the break based on the identifier (paragraphs 49 and 51, store the newly created rule in the contract rules database; generate a message to trigger a new process when the new rule is created, wherein the new process includes compare payments made in the parsed transaction data with correlated transaction pricing in the parsed contract data for all claims affected by the new rule. The new transaction data being added to the system after creation of the new rule); and determines whether the one or more repair transactions, in combination with the set of transactions corresponding to the break, resolve the break (paragraphs 52 and 157, at least one operation to facilitate resolution of the at least one detected payment discrepancy associated with the second processed claim record. the status of a given transaction may be reported as one or more of the following (or combinations thereof): Completed). Response to Arguments Applicants' arguments filed on 11/11/2025 have been fully considered but they are not fully persuasive especially in light of the previously references applied in the rejections. Applicants remark that “the present invention improves how the system itself operates-enabling automated, adaptive, and verifiable break resolution through coordinated ML-driven classification, dynamic workflow execution, and schema-aware data transformation. Accordingly, when analyzed under the Alice framework and consistent with the guidance of Enfish and Desjardins, the amended claims recite a specific improvement to computer functionality. The claimed architecture performs specialized operations that cannot be carried out manually or by generic automation and transforms data in a way that changes the state of the system. For these reasons, the claims are not directed to an abstract idea but to a specific technological implementation that improves the functioning of computer systems.”. Examiner does not agree. The claim limitation does not, for example, purport to improve the functioning of the computer itself. Nor does it effects an improvement in any other technology or technical field. Training a combination of rule-based logic and one or more machine learning model and apply this trained model is generic data process. They do not describe any particular improvement in the manner a computer functions. Instead, the claim amounts to nothing significantly more than using machine learning techniques on a computer to classify the type of the transaction break and initiate a break solution. Under our precedents, that is not enough to transform an abstract idea into a patent-eligible invention. As we determine herein, the claims 1-28 are directed to achieving the result of managing a break resolution based on transaction break classification generated from the combination of the rule logic and the machine learning models, as distinguished from a technological improvement for achieving or applying that result. Although a machine learning model is used, such use is both generic and conventional. The object of the claims is to manage a break resolution, not to produce technology enabling a machine learning model to operate. The claims call for generic use of such a model in the manner such models conventionally operate. Simply reciting a particular technological module or piece of equipment in a claim does not confer eligibility. None of the limitations reflects an improvement in the functioning of a computer, or an improvement to other technology or technical field, applies or uses a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implements a judicial exception with, or uses a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim, effects a transformation or reduction of a particular article to a different state or thing, or applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Applicants remark that “neither Basra nor Christmas discloses or suggests classifying, by a classification engine, using a combination of rule-based logic and one or more machine learning models, the break based on the set of transactions, the internal data, and the external data, wherein the classification engine executes model inference on break data and applies rule-based validation logic to a classification result; determining, by a workflow engine, a type of repair to perform based at least in part on the classification of the break by selecting a predefined workflow path corresponding to the break classification; and transmitting the repair transaction to the corresponding record source through an application programming interface (API)”. Examiner directs Applicants' attention to the office action above. Conclusion Please refer to form 892 for cited references. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARIEL J YU whose telephone number is (571)270-3312. The examiner can normally be reached 11AM - 7PM (M-F). 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, Obeid Fahd A can be reached on 571-270-3324. 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. /ARIEL J YU/Primary Examiner, Art Unit 3627
Read full office action

Prosecution Timeline

Jun 29, 2023
Application Filed
May 19, 2025
Non-Final Rejection — §101, §103, §112
Jul 30, 2025
Response Filed
Sep 08, 2025
Final Rejection — §101, §103, §112
Nov 11, 2025
Response after Non-Final Action
Nov 20, 2025
Request for Continued Examination
Dec 05, 2025
Response after Non-Final Action
Mar 09, 2026
Non-Final Rejection — §101, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12579524
CRYPTOCURRENCY TERMINAL AND TRANSACTION PROCESSING
2y 5m to grant Granted Mar 17, 2026
Patent 12579526
TARGETED REMOTE PAYMENTS LEVERAGING ULTRA-WIDEBAND (UWB) AND MICRO-ELECTROMECHANICAL SYSTEMS (MEMS) SENSOR COMMUNICATIONS
2y 5m to grant Granted Mar 17, 2026
Patent 12493916
COLLECTION OF TRANSACTION RECEIPTS USING AN ONLINE CONTENT MANAGEMENT SERVICE
2y 5m to grant Granted Dec 09, 2025
Patent 12456091
Automated Package Delivery System
2y 5m to grant Granted Oct 28, 2025
Patent 12456107
CUSTOMIZABLE MEDIA CONTENT FOR POINT OF SALE (POS) TRANSACTIONS
2y 5m to grant Granted Oct 28, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
40%
Grant Probability
67%
With Interview (+27.4%)
4y 3m
Median Time to Grant
High
PTA Risk
Based on 389 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month