CTFR 18/936,463 CTFR 87298 DETAILED ACTION Notice to Applicant The following is a FINAL Office action upon examination of application number 18/936,463 filed on 11/04/2024. Claims 1-20 are pending in this application, and have been examined on the merits discussed below. 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Response to Amendment In the response filed April 14, 2026, Applicant amended claims 1-4, 7, 9-13, 16, and 18-20, and did not cancel any claims. No new claims were presented for examination. Applicant's amendments to claim 1 are hereby acknowledged. The amendments are sufficient to overcome the previously issued claim objection; accordingly, this objection has been removed. Applicant's amendments to claim 2 are hereby acknowledged. The amendments are sufficient to overcome the previously issued rejection of claims 2-8 under 35 U.S.C. 112(b); accordingly, this rejection has been withdrawn. Applicant's amendments to claims 1, 10, and 19 are hereby acknowledged. The amendments are not sufficient to overcome the previously issued claim rejection under 35 U.S.C. 101; accordingly, this rejection has been maintained. Response to Arguments Applicant's arguments filed April 14, 2026, have been fully considered. Applicant submits “In this case, even assuming, arguendo, the present claims recite an abstract idea, as the Office Action suggests, the present claims are patent eligible at least at Step 2A Prong Two because the claims recite additional elements, and those elements integrate the abstract idea into a practical application as the claim improves the technical field of enterprise resource planning (ERP) applications.” [Applicant’s Remarks, 04/14/2026, page 8] In response to Applicant’s argument that “the present claims are patent eligible at least at Step 2A Prong Two because the claims recite additional elements, and those elements integrate the abstract idea into a practical application as the claim improves the technical field of enterprise resource planning (ERP) applications,” it is noted that the additional elements in amended claim 1 are: a correction system coupled to an enterprise resource planning system and a plurality of point-of-service transaction devices via a network, a point-of-service transaction device among the plurality of point-of-service transaction devices, a transaction store located at the correction system, and a user interface, which merely serve to tie the abstract idea to a particular technological environment (computer-based operating environment) via generic computing hardware, software/instructions, which is not sufficient to amount to a practical application, as noted in MPEP 2106.05. Applicant has provided no facts/evidence, cited any portion of the Specification, nor provided a persuasive line of reasoning showing how the additional elements are integrated with the abstract idea to integrate the abstract idea into a practical application. It is also noted that the claims are devoid of any discernible change, transformation, or improvement to a computer (software or hardware) or any existing technology. Applicant has not shown that any specific technological improvement is achieved within the scope of the claims. It bears emphasis that no correction system, enterprise resource planning system, devices, user interface, or technological elements are modified or improved upon in any discernible manner. Instead, the result produced by the claims is simply information relating to corrected records, which is not a technical result or improvement thereof. Furthermore, the additional elements fail to integrate the abstract idea into a practical application because they fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. In response to Applicant’s argument that “the present claims are patent eligible at least at Step 2A Prong Two because the claims recite additional elements, and those elements integrate the abstract idea into a practical application as the claim improves the technical field of enterprise resource planning (ERP) applications,” it is noted the claim does not recite a specific technical improvement to ERP systems themselves. Instead, it merely automates a business/ data processing workflow. Lastly, in response to Applicant’s argument that “To address these vulnerabilities in conventional ERP applications, a "correction system" is provided "to check the transactions provided by one or more POS devices to the ERP system to check for (e.g., detect) errors in the POS transactions.' Importantly, the correction system can detect errors in the POS transaction data "before the transactions are provided to the ERP system" and even "correct (or at least flag) the errors in the POS transactions," thereby saving resources that are traditionally consumed handling errors within ERP applications” [Remarks at page 9], it is noted that the claim does not recite a specific technological improvement to ERP systems or computer functionality, but instead describes shifting the location of error detection and correction within a transaction workflow (i.e., detecting or flagging errors prior to ERP ingestion). This amounts to an abstract data processing and workflow technique implemented using generic computing components, without any improvement to computer operation or data structures. For the reasons above, this argument is found unpersuasive. Applicant submits “The additional elements listed above (i.e., "receiving, by a correction system coupled to an enterprise resource planning system and a plurality of point-of-service transaction devices via a network, one or more records via the network from a point-of-service transaction device among the plurality of point-of-service transaction devices"; "storing the received one or more records in a transaction store located at the correction system, the transaction store further including a plurality of records"; "retrieving at least a first record from the transaction store"; "when the first error is detected in the first record, generating a user interface that presents an indication of the first error; "receiving, via the user interface, a user confirmation that the first error is truly an error"; and "passing the first record and the one or more second records as corrected records to the enterprise resource planning system via the network.") do not fall within any of the enumerated groupings of abstract ideas-mathematical concepts, certain methods of organizing human activity, or mental processes. Regarding mental processes, in particular, these additional elements recite inherently technical operations that require a data processor for implementation, such that the human mind cannot practically perform the operations.” [Applicant’s Remarks, 04/14/2026, page 10] The Examiner respectfully disagrees. In response to Applicant’s argument it is noted that reciting implementation on a data processor does not remove the claim from the mental process abstract idea grouping. The claim limitations related to receiving and storing records, retrieving data, detecting errors, obtaining a user confirmation, and transmitting corrected records recites information handling and evaluation that can be performed by a human with the aid of pen and paper. The claim still falls under the “Mental Processes” abstract idea grouping because the steps can be performed in the human mind using pen and paper or a spreadsheet, such as by reviewing records, identifying errors, and applying corrections manually. For the reasons above, this argument is found unpersuasive. Applicant submits “Srivastava and Straten, either alone or in combination, fail to disclose and would not have rendered obvious: "A computer-implemented method comprising: receiving, by a correction system coupled to an enterprise resource planning system and a plurality of point-of-service transaction devices via a network, one or more records via the network from a point-of-service transaction device among the plurality of point-of- service transaction devices; storing the received one or more records in a transaction store located at the correction system, the transaction store further including a plurality of records; retrieving at least a first record from the transaction store; checking the first record for a first error in the first record; when the first error is detected in the first record, generating a user interface that presents an indication of the first error; receiving, via the user interface, a user confirmation that the first error is truly an error; identifying, for the first error in the first record, a first correction in response to receiving the user confirmation; applying the first correction to the first record; identifying in the plurality records one or more second records with the first error; applying the first correction to the identified one or more second records; and passing the first record and the one or more second records as corrected records to the enterprise resource planning system via the network," as recited in claim 1, and similarly recited in claims 1, 10, and 19 (as amended).” [Applicant’s Remarks, 04/14/2026, pages 12-13] In response to the Applicant’s argument that “Srivastava and Straten, either alone or in combination, fail to disclose and would not have rendered obvious: "A computer-implemented method comprising: receiving, by a correction system coupled to an enterprise resource planning system and a plurality of point-of-service transaction devices via a network, one or more records via the network from a point-of-service transaction device among the plurality of point-of- service transaction devices; storing the received one or more records in a transaction store located at the correction system, the transaction store further including a plurality of records; retrieving at least a first record from the transaction store; checking the first record for a first error in the first record; when the first error is detected in the first record, generating a user interface that presents an indication of the first error; receiving, via the user interface, a user confirmation that the first error is truly an error; identifying, for the first error in the first record, a first correction in response to receiving the user confirmation; applying the first correction to the first record; identifying in the plurality records one or more second records with the first error; applying the first correction to the identified one or more second records; and passing the first record and the one or more second records as corrected records to the enterprise resource planning system via the network," as recited in claim 1, and similarly recited in claims 1, 10, and 19 (as amended),” it is noted that this argument is a mere allegation of patentability by the Applicant with no supporting rationale or explanation. Merely stating that the claims do not teach a feature does not offer any insight as to why the specific sections of the prior art relied upon by the Examiner fail to disclose the claimed features. Applicant's arguments amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Moreover, the Examiner notes the limitations being argued by Applicant as being newly amended to the claims in the response filed 04/14/2026, which have been addressed in the updated rejection below. Applicant’s argument has been considered, but it pertains to amendments to independent claim 1 that are believed to be addressed via the updated ground of rejection under §103 set forth in the instant Office action, which incorporates new citations to address the amended limitations in claim and supports a conclusion of obviousness of the amended claims. Applicant submits “Srivastava does not disclose that the graphical user interface receives a user confirmation that an error detected in a record is truly an error, as presently claimed. While Srivastava teaches that a user can approve of a suggested corrective action, Srivastava is entirely silent with regard to the user confirming that a detected error is, in fact, an error.” [Applicant’s Remarks, 04/14/2026, pages 13-14] The Examiner respectfully disagrees. With respect to the §103 rejection of independent claim 1, Applicant argues that Srivastava does not disclose “receiving, via the user interface, a user confirmation that the first error is truly an error.” However, in at least paragraphs 0228 and 0264, Srivastava teaches the newly presented limitation. Srivastava is not silent regarding user confirmation of a detected transaction issue. For instance. Paragraph 0264 describes that the screening microservice send a request to a user device asking whether a transaction is a duplicate and receives a response from the user device indicating whether the transaction is a duplicate, which constitutes user confirmation of the detected condition. Moreover, paragraph 0228 discloses that the screening microservice may communicate with users to confirm whether a transaction object is a duplicate prior to removal, indicating user validation of the identified issue. Thus, given the broadest reasonable interpretation consistent with the specification in construing the claimed invention, it is Examiner’s position that the disclosure of Srivastava teaches the disputed limitation. For the reasons above, this argument is found unpersuasive. Applicant submits “Furthermore, because Srivastava does not teach a user confirmation that an error detected in a record is truly an error received via a user interface, Srivastava necessarily cannot teach that a correction for the detected error is identified in response to receiving the user confirmation, as presently claimed. Srivastava teaches in paragraph [0014] that an "electronic communication may indicate a suggested corrective action," as noted above, but the identification of the corrective action is not performed in response to receiving a user confirmation that an error detected in a record is truly an error. Consequently, Srivastava may suggest a corrective action for an error that is not actually an error, since the error was not vetted by a user prior to the corrective action being suggested.” [Applicant’s Remarks, 04/14/2026, page 14] The Examiner respectfully disagrees. With respect to the §103 rejection of independent claim 1, Applicant argues that Srivastava does not disclose “ identifying, for the first error in the first record, a first correction in response to receiving the user confirmation.” However, in at least paragraphs 0067, 0216, 0228, 0264, Srivastava teaches the newly presented limitation. Srivastava. As discusses with respect to the “receiving, via the user interface, a user confirmation that the first error is truly an error” limitation, paragraphs 0264 and 0228 disclose requesting suer input via a user interface and receiving a user response confirming whether the identified duplicate or error condition is correct. This constitutes user confirmation of the detected issue. Moreover, paragraphs 0067 and 0216 disclose that after identifications and validation of an issue, the system generates or applies a corrective action (i.e., updating, removing, or modifying transaction records, or applying remedial actions based on review results). These corrective actions are performed in response to the detected and confirmed issue. Thus, given the broadest reasonable interpretation consistent with the specification in construing the claimed invention, it is Examiner’s position that the disclosure of Srivastava teaches the disputed limitation. For the reasons above, this argument is found unpersuasive. Applicant’s remaining arguments either logically depend from the above-rejected arguments, in which case they too are unpersuasive for the reasons set forth above, or they are directed to features which have been newly added via amendment. Therefore, this is now the Examiner's first opportunity to consider these limitations and as such any arguments regarding these limitations would be inappropriate since they have not yet been examined. A full rejection of these limitations will be presented later in this Office Action. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The eligibility analysis in support of these findings is provided below, in accordance with MPEP 2106. With respect to Step 1 of the eligibility inquiry (as explained in MPEP 2106 ), it is first noted that the method (claims 1-9), system (claims 10-18), and non-transitory computer-readable storage medium (claims 19-20), are directed to at least one potentially eligible category of subject matter (i.e., process, machine, and article of manufacture, respectively). Thus, Step 1 of the Subject Matter Eligibility test for claims 1-20 is satisfied. With respect to Step 2A Prong One , it is next noted that the claims recite an abstract idea that falls into the “ Certain Methods of Organizing Human Activity ” abstract idea set forth in MPEP 2106 because the claims recite steps for managing a business process, which encompasses activity for managing personal behavior or relationships or interactions (e.g., following rules or instructions), and steps that can be performed in the human mind (including observation, evaluation, judgment, opinion), and therefore fall under the “ Mental Processes ” abstract idea grouping. With respect to independent claim 1, the limitations reciting the abstract idea are indicated in bold below: receiving , by a correction system coupled to an enterprise resource planning system and a plurality of point-of-service transaction devices via a network, one or more records via the network from a point-of-service transaction device among the plurality of point-of-service transaction devices; storing the received one or more records in a transaction store located at the correction system, the transaction store further including a plurality of records; retrieving at least a first record from the transaction store; checking the first record for a first error in the first record; when the first error is detected in the first record , generating a user interface that presents an indication of the first error; receiving , via the user interface, a user confirmation that the first error is truly an error; identifying, for the first error in the first record, a first correction in response to receiving the user confirmation; applying the first correction to the first record; identifying in the plurality records one or more second records with the first error; applying the first correction to the identified one or more second records; and passing the first record and the one or more second records as corrected records to the enterprise resource planning system via the network. The claim recites limitations that fall under the “Certain Methods of Organizing Human Activity” abstract idea grouping because the limitations focus on receiving transaction records, storing them, retrieving a first record, checking for errors, presenting an indication of an error, identifying corrections, applying corrections, and passing corrected errors, which are activities that reflect a business process for managing and correcting transactional data, which is a form of organizing human activity. The claim also falls under the “Mental Processes” abstract idea grouping because the steps can be performed in the human mind using pen and paper or a spreadsheet, such as reviewing records, identifying errors, and applying corrections manually. Therefore, because the limitations above set forth activities falling within the “Certain methods of organizing human activity” and “Mental Processes” abstract idea groupings described in MPEP 2106, the additional elements recited in the claims are further evaluated, individually and in combination, under Step 2A Prong Two and Step 2B below. Independent claims 10 and 19 recite similar limitations as those discussed above and are therefore found to recite the same or substantially the same abstract idea as claim 1. With respect to Step 2A Prong Two , the judicial exception is not integrated into a practical application . With respect to the independent claims, the additional elements are: a correction system coupled to an enterprise resource planning system and a plurality of point-of-service transaction devices via a network, a point-of-service transaction device among the plurality of point-of-service transaction devices, a transaction store located at the correction system, the transaction store further including a plurality of records, and generating a user interface (claim 1), at least one processor, at least one memory including instructions, a correction system coupled to an enterprise resource planning system and a plurality of point-of-service transaction devices via a network, a point-of-service transaction device among the plurality of point-of- service transaction devices, a transaction store located at the correction system, the transaction store further including a plurality of records, and generating a user interface (claim 10), a non-transitory computer-readable storage medium including code, at least one processor, a correction system coupled to an enterprise resource planning system and a plurality of point-of-service transaction devices via a network, a point-of-service transaction device among the plurality of point-of-service transaction devices, a transaction store located at the correction system, the transaction store further including a plurality of records, and generating a user interface (claim 19). These additional elements have been evaluated, but fail to integrate the abstract idea into a practical application because they amount to using generic computing elements or computer-executable instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), and merely serve to link the use of the judicial exception to a particular technological environment. See MPEP 2106.05(f) and 2106.05(h). Even if the “receiving ,” “ storing ,” and “ retrieving ” steps are evaluated as additional elements, these steps amount at most to insignificant extra-solution activity, which is not indicative of a practical application, as noted in MPEP 2106.05(g). In addition, these limitations fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception. With respect to Step 2B of the eligibility inquiry , it has been determined that the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception . With respect to the independent claims, the additional elements are: a correction system coupled to an enterprise resource planning system and a plurality of point-of-service transaction devices via a network, a point-of-service transaction device among the plurality of point-of-service transaction devices, a transaction store located at the correction system, the transaction store further including a plurality of records, and generating a user interface (claim 1), at least one processor, at least one memory including instructions, a correction system coupled to an enterprise resource planning system and a plurality of point-of-service transaction devices via a network, a point-of-service transaction device among the plurality of point-of- service transaction devices, a transaction store located at the correction system, the transaction store further including a plurality of records, and generating a user interface (claim 10), a non-transitory computer-readable storage medium including code, at least one processor, a correction system coupled to an enterprise resource planning system and a plurality of point-of-service transaction devices via a network, a point-of-service transaction device among the plurality of point-of-service transaction devices, a transaction store located at the correction system, the transaction store further including a plurality of records, and generating a user interface (claim 19). These elements have been considered individually and in combination, but fail to add significantly more to the claims because they amount to using generic computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), and merely serve to link the use of the judicial exception to a particular technological environment and does not amount to significantly more than the abstract idea itself. Notably, Applicant’s Specification suggests that virtually any type of computing device under the sun can be used to implement the claimed invention (Specification at paragraph [0051]: “In some implementations of the current subject matter, the processor 510 can be a single-threaded processor. Alternately, the processor 510 can be a multi-threaded processor…”). Accordingly, the generic computer involvement in performing the claim steps merely serves to generally link the use of the judicial exception to a particular technological environment, which does not add significantly more to the claim. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976.). With respect to the “receiving ,” “ storing ,” and “ retrieving ” steps, these steps amount to insignificant extra-solution activity, which does not amount to a practical application (MPEP 2106.05(g)), nor add significantly more because such activity has been recognized as well-understood, routine, and conventional and thus insufficient to add significantly more to the abstract idea. See MPEP 2106.05(d)(i). - Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network). See MPEP 2106.05(d)(iv). Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93. In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrate the abstract idea into a practical application. Their collective functions merely provide generic computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that, as an ordered combination, amount to significantly more than the abstract idea itself. Dependent claims 2-9, 11-18, and 20 recite the same abstract idea as recited in the independent claims, and when evaluated under Step 2A Prong One are found to merely recite details that serve to narrow the same abstract idea recited in the independent claims accompanied by the same generic computing elements or software as those addressed above in the discussion of the independent claims, which is not sufficient to amount to a practical application or add significantly more, or other additional elements that fail to amount to a practical application or add significantly more, as noted above. In particular, dependent claims 2-9 recite “further comprising sending the plurality of records for additional storage,” “wherein the plurality of records have not been corrected,” “retrieves the first record from in response to initiation of an audit of the plurality of records,” “performs one or more checks on the first record,” “wherein the one or more checks comprise a unit of measure check and/or an article identifier check,” “wherein the user confirmation received is used to detect the first error,” “wherein the one or more checks further comprise including the first error to enable confirmation of the first error,” “wherein the one or more checks further comprise detecting the first error,” “wherein the first correction is identified,” however these limitations cover activity for managing personal behavior or relationships or interactions (e.g., following rules or instructions) , which is part of the same abstract idea as addressed in the independent claims that falls within the “Certain Methods of Organizing Human Activity” abstract idea grouping and also recite steps that may also be accomplished mentally such as via human observation and perhaps with the aid of pen and paper. The dependent claims recite additional elements of: the correction system, the enterprise resource planning system, an un-audited store located at the enterprise resource planning system (claims 2, 11, 20), the correction system (claims 3-4, 12-14), the correction and the transaction store (claims 4, 13), the user interface and train a machine learning model (claims 7, 16), a machine learning model, wherein the machine learning model comprises a convolutional neural network trained using records with errors and records without errors (claims 8, 17), and a machine learning model (claims 9, 18). However, when evaluated under Step 2A Prong Two and Step 2B, these additional elements do not amount to a practical application or significantly more since they merely require generic computing devices (or computer-implemented instructions/code) which as noted in the discussion of the independent claims above is not enough to render the claims as eligible. Even if the machine learning model , training , and the convolutional neural network were evaluated as elements beyond software/code for a generic computer to execute, it is noted that that the claimed use of machine learning, “train , ” and a convolutional neural network is recited at a high level of generality these elements amount to well-understood, routine, and conventional activity in the art, which fails to add significantly more to the claims. See, e.g., Magdon-Ismail et al ., US 2009/0055270 (paragraph 0039: “ Both local and central engines may incorporate analysis techniques, such as artificial intelligence, machine learning and other techniques, which are well known in the art. ”). See also Temple, US 2023/0214630 (paragraph 0067: “c onventional convolutional neural networks are trained on a specific set of data that may represent typical input data provided to the conventional convolutional neural networks to solve intended task(s) . ”). The ordered combination of elements in the dependent claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide generic computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to a practical application or significantly more than the abstract idea itself. For more information, see MPEP 2106. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 18. 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. 07-20-aia AIA 19. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. 07-23-aia AIA 20. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. 07-21-aia AIA 21. Claim s 1-5, 8-14, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Srivastava et al., Pub. No.: US 2024/0289809 A1, [hereinafter Srivastava], in view of Straten, Pub. No.: US 2013/0219268 A1, [hereinafter Straten] . As per claim 1 , Srivastava teaches a computer-implemented method (paragraph 0047: “Various aspects discussed herein may be embodied as a method, a computing device, a data processing system, or a computer program product.”; paragraphs 0048, 0077) comprising : receiving, by a correction system coupled to a system and a plurality of point-of-service transaction devices via a network, one or more records via the network from a point-of-service transaction device among the plurality of point-of-service transaction devices (paragraph 0012, discussing that the transaction exchange platform may receive a plurality of transaction objects, with each of the plurality of transaction objects being associated with a transaction…In addition to performing a field-by-field check, the streaming data platform (SDP) may also determine whether the format of the received transaction object is valid; paragraph 0014, discussing that if any issues are identified in the received transaction object, the streaming data platform may perform a remedial action to correct the defect with the received transaction object; paragraph 0049, discussing a transaction exchange platform implemented using a streaming data platform (SDP) and a plurality of microservices to process transactions according to workflows corresponding to different transaction types. Microservices on the transaction exchange platform may be configured to retrieve transactions...The microservice may perform one or more steps of the approval/review workflow for the type of transaction, update the status of the object, and put it back to the SDP; paragraph 0079, discussing that the system may receive a transaction object and add it to the streaming data platform. The transaction object may be received from a transaction origination source [i.e., point-of-service transaction device] and may be received from an enterprise intermediary service, such as enterprise transaction intermediary service. The transaction object may be received via one or more APIs of the transaction exchange platform; paragraph 0218, discussing that the streaming data platform may analyze the received transaction object for any potential errors that may cause processing of the received transaction object to stall and/or fail; paragraph 0063); storing the received one or more records in a transaction store located at the correction system, the transaction store further including a plurality of records (paragraph 0079, discussing that the system may receive a transaction object and add it to the streaming data platform. The transaction object may be received from a transaction origination source…The transaction object may be added to the SDP in an initialization stage, which may be implemented through setting a current workflow stage of the transaction object's transaction metadata to an initialization value; paragraph 0136, discussing a snapshot microservice that may operate on transaction exchange platform to maintain a record of the data values of each transaction object on the streaming data platform, and track how the transaction objects change during processing on the platform. Snapshot data may be stored in snapshot database…Snapshot microservice and snapshot database may be configured to store differential snapshots of a transaction object; paragraph 0170, discussing storing an initial record for new transaction objects on the SDP); retrieving at least a first record from the transaction store (paragraph 0049, discussing a transaction exchange platform implemented using a streaming data platform (SDP) and a plurality of microservices to process transactions according to workflows corresponding to different transaction types. Microservices on the transaction exchange platform may be configured to retrieve transactions... The microservice may perform one or more steps of the approval/review workflow for the type of transaction, update the status of the object, and put it back to the SDP; paragraph 0063, discussing identifying and retrieving transaction objects; paragraph 0066, discussing retrieving transaction objects...In this manner, the microservice may extract transaction objects from SDP; paragraph 0170, discussing retrieving new transactions as they are added; paragraph 0067); checking the first record for a first error in the first record (paragraph 0014, discussing that if any issues are identified in the received transaction object, the streaming data platform may perform a remedial action to correct the defect with the received transaction object. The remedial action object may be determined using the one or more machine learning models. Additionally or alternatively, the streaming data platform may generate an alert indicating the defect with the received transaction object. The alert may include sending an electronic communication to one or more parties associated with the received transaction object. The electronic communication may indicate the defect [i.e., error] and a suggested corrective action; paragraph 0067, discussing that processing of the transaction object by the microservice may comprise any of: retrieving the transaction object; reviewing values and other characteristics of the transaction object; paragraph 0217, discussing techniques for detecting errors with transactions; paragraph 0218, discussing that the streaming data platform may analyze the received transaction object for any potential errors that may cause processing of the received transaction object to stall and/or fail; paragraph 0079); when the first error is detected in the first record, generating a user interface that presents an indication of the first error (paragraph 0014, discussing that if any issues are identified in the received transaction object, the streaming data platform may generate an alert (e.g., a notification) indicating the defect with the received transaction object. The alert may include sending an electronic communication (e.g., message) to one or more parties associated with the received transaction object. The electronic communication may indicate the defect and a suggested corrective action. In response to the electronic communication, the one or more parties may perform one or more steps to remediate the defect with the received transaction object. In some instances, remediating the defect may comprise approving the suggested corrective action; paragraph 0067, discussing presenting the transaction for manual or other review; paragraph 0093, discussing that flagging the transaction object for further review may comprise flagging the transaction object for manual review by a user; paragraph 0113, discussing that the system may provide a graphical user interface to facilitate users entering modifications); receiving, via the user interface, a user confirmation that the first error is truly an error (paragraph 0067, discussing that the microservice, having retrieved one or more transaction objects may perform its corresponding workflow step on the transaction object. The workflow step may comprise suitable processing of the transaction object…Processing of the transaction object by the microservice may comprise any of: retrieving the transaction object; reviewing values and other characteristics of the transaction object;…; comparing values or characteristics to rules, regulations, policies, and the like; adding, removing, updating, or otherwise changing any aspect of the transaction addenda data or transaction metadata; generating reports and/or alerts; presenting the transaction for manual or other review…Processing may comprise determining that the transaction details, addenda data, and/or transaction metadata fail at least one rule; flagging the transaction object for further review; and holding the transaction object in the current workflow stage pending the further review, where updating the current workflow stage of the transaction object to the third workflow stage is based on determining that the further review is completed. Flagging the transaction object for further review may comprise flagging the transaction object for manual review by a user and/or setting the current workflow stage of the transaction object to a current workflow stage associated with another microservice, other than the microservice that typically processes transactions after the first microservice; paragraph 0092, discussing that the transaction details may be immutable and may not change while the transaction object is on the streaming data platform. The processing, by the first microservice, of the transaction object may comprise verifying a value of the transaction details, addenda data, and/or transaction metadata against at least one rule. Processing of the transaction object by the first microservice may comprise verifying a value of the transaction details, addenda data, and/or transaction metadata against a watchlist. Processing of the transaction object by the second microservice may comprise determining that the transaction details, addenda data, and/or transaction metadata fail at least one rule, flagging the transaction object for further review, and holding the transaction object in the second workflow stage pending the further review. Updating the current workflow stage of the transaction object to the third workflow stage may be based on determining that the further review is completed. Flagging the transaction object for further review may comprise flagging the transaction object for manual review by a user; paragraph 0228, discussing that transaction objects associated with duplicate transactions may be removed from transaction exchange platform, while transaction objects associated with non-duplicate transactions may be processed according to an associated workflow. In some instances, the screening microservice may communicate with one or more users to confirm whether transaction object is a duplicate, for example, prior to removing transaction object from the transaction exchange platform; paragraph 0264, discussing that when the first transaction details overlap with second transaction details, the screening microservice may send a request to a first user device. The request may inquire whether the first transaction is a duplicate of the second transaction. That is, a user may be asked to confirm (or deny) whether the first transaction is a duplicate of a second transaction. The screening microservice may receive a response from the first user device. The screening microservice may determine whether the response indicates that the first transaction object is a duplicate of an earlier (second) transaction. If the first transaction is a duplicate of an earlier transaction, the first transaction object may be removed from the SDP); identifying, for the first error in the first record, a first correction in response to receiving the user confirmation (paragraph 0067, discussing that the microservice, having retrieved one or more transaction objects may perform its corresponding workflow step on the transaction object. The workflow step may comprise suitable processing of the transaction object…Processing of the transaction object by the microservice may comprise any of: retrieving the transaction object; reviewing values and other characteristics of the transaction object;…; comparing values or characteristics to rules, regulations, policies, and the like; adding, removing, updating, or otherwise changing any aspect of the transaction addenda data or transaction metadata; generating reports and/or alerts; presenting the transaction for manual or other review…Processing may comprise determining that the transaction details, addenda data, and/or transaction metadata fail at least one rule; flagging the transaction object for further review; and holding the transaction object in the current workflow stage pending the further review, where updating the current workflow stage of the transaction object to the third workflow stage is based on determining that the further review is completed. Flagging the transaction object for further review may comprise flagging the transaction object for manual review by a user and/or setting the current workflow stage of the transaction object to a current workflow stage associated with another microservice, other than the microservice that typically processes transactions after the first microservice; paragraph 0187, discussing that subsequent to implementing the corrective action, the watchdog microservice may determine that successful processing is completed. Or the watchdog microservice may determine that processing has failed, and may output the transaction for further review (manually and/or automatically), and may generate another recommended action; paragraph 0264, discussing that when the first transaction details overlap with second transaction details, the screening microservice may send a request to a first user device. The request may inquire whether the first transaction is a duplicate of the second transaction. That is, a user may be asked to confirm (or deny) whether the first transaction is a duplicate of a second transaction. The screening microservice may receive a response from the first user device. The screening microservice may determine whether the response indicates that the first transaction object is a duplicate of an earlier (second) transaction. If the first transaction is a duplicate of an earlier transaction, the first transaction object may be removed from the SDP; paragraph 0216, discussing that spreadsheet row checking requires a user to manually correct identified errors); identifying, for the first error in the first record, a first correction (paragraph 0014, discussing that if any issues are identified in the received transaction object, the streaming data platform may perform a remedial action [i.e., first correction] to correct the defect with the received transaction object. The remedial action object may be determined using the one or more machine learning models. Additionally or alternatively, the streaming data platform may generate an alert indicating the defect with the received transaction object. The alert may include sending an electronic communication to one or more parties associated with the received transaction object. The electronic communication may indicate the defect and a suggested corrective action; paragraph 0210, discussing determining a corrective action for the transaction object; paragraph 0217, discussing that the disclosure discusses remedial measures when errors are detected; paragraph 0140); applying the first correction to the first record (paragraph 0011, describes solutions to detect and prevent duplicate transactions in transaction files and detect errors with transactions. These solutions ensure efficient processing of transaction files by downstream processors. Moreover, the disclosure describes taking remedial action (e.g., corrective action), for example, if one or more transactions, or transaction files, are rejected by a downstream processor; paragraph 0014, discussing that if any issues are identified in the received transaction object, the streaming data platform may perform a remedial action [i.e., first correction] to correct the defect with the received transaction object; paragraph 0187, discussing that subsequent to implementing the corrective action, the watchdog microservice may determine that successful processing is completed; paragraph 0217, discussing that by detecting errors and taking remedial measures to cure any detected defects, the disclosure ensures that transactions are processed in a timely manner by downstream processors; paragraph 0218); passing the first record as a corrected record to the system via the network (paragraph 0049, discussing a transaction exchange platform implemented using a streaming data platform (SDP) and a plurality of microservices to process transactions according to workflows corresponding to different transaction types. Microservices on the transaction exchange platform may be configured to retrieve transactions...The microservice may perform one or more steps of the approval/review workflow for the type of transaction, update the status of the object, and put it back to the SDP; paragraph 0063, discussing that once the microservice completes its processing of the transaction object, the microservice can put the transaction object back to the SDP with an updated current workflow stage indicating that the microservice completed its processing). Srivastava does not explicitly teach that the correction system is coupled to an enterprise resource planning system via a network; identifying in the plurality records one or more second records with the first error ; applying the first correction to the identified one or more second records ; and passing the first record and the one or more second records as corrected records to the enterprise resource planning system via the network . Straten in the analogous art of error handling systems teaches: a correction system coupled to an enterprise resource planning system via a network (paragraph 0033, discussing that the exemplary document error handling system includes an application layer, which may be, for example, a client-server based application layer of an integrated ERP software program or module. The application layer is configured to receive and process one or more electronic documents from among a plurality of electronic documents to thereby identify one or more errors associated with one or more of these electronic documents. In particular, the application layer is configured to initiate or execute a document error handling method to thereby identify one or more of these errors, such as by identifying a number of errors associated with various data fields contained within the various documents; paragraph 0040, discussing a document error handling process of the present technology is an add-on or module for an integrated enterprise resource planning software program or module platform (such as a customer relationship management software program or module platform)…Moreover, in one embodiment, the communication between such a document error handling add-on or module and a backend system takes place through (1) function modules provided by integrated ERP software and (2) access to a shared database; paragraph 0110, discussing that an exemplary method of document error handling includes processing the electronic document in response to a document processing input and based on the plurality of data fields. Exemplary method of document error handling also includes saving a change to the electronic document in a data storage unit in response to a document update command, wherein the change reflects the editing of the data field. To illustrate, consider the example where one or more changes to the electronic document are saved in a data storage unit (such as, for example, in a central ERP database) in response to the document update command; paragraphs 0081). identifying in the plurality records one or more second records with the first error (paragraph 0033, discussing that the exemplary document error handling system includes an application layer, which may be, for example, a client-server based application layer of an integrated ERP software program or module. The application layer is configured to receive and process one or more electronic documents from among a plurality of electronic documents to thereby identify one or more errors associated with one or more of these electronic documents. In particular, the application layer is configured to initiate or execute a document error handling method to thereby identify one or more of these errors, such as by identifying a number of errors associated with various data fields contained within the various documents; paragraph 0075, discussing that an error selected in an error list updates a field selection...In particular, once an error is selected in the error list, then a number of data fields that correspond to the selected error are identified in field editor. Various data fields, which are labeled in FIG. 5 as Fields 1 through N (wherein N is an integer value), may include different amounts of data. If a listed data field is editable, and the data field is edited such that the selected error is corrected, then the selected error will be removed from error list); applying the first correction to the identified one or more second records (paragraph 0075, discussing that an error selected in an error list updates a field selection...In particular, once an error is selected in the error list, then a number of data fields that correspond to the selected error are identified in field editor. Various data fields, which are labeled in FIG. 5 as Fields 1 through N (wherein N is an integer value), may include different amounts of data. If a listed data field is editable, and the data field is edited such that the selected error is corrected, then the selected error will be removed from error list; paragraph 0080, discussing that a selection of add icon or button enables a user to add a group of data segments…A selection of call icon or button enables a menu to call a linked transaction... A selection of summarize icon or button enables a user to switch the current error display mode between a summarized mode to a detailed mode. When in the summarized mode, the error list summarizes errors and allows the user to correct multiple errors in a single step; paragraph 0112, discussing automatically identifying one or more other data fields from among the plurality of data fields that correspond to the one or more other errors, respectively, automatically editing the one or more other data fields based on the editing of the data field to thereby enable an elimination of the one or more other errors…); and passing the first record and the one or more second records as corrected records to the enterprise resource planning system via the network (paragraph 0081, discussing that the exemplary editor screen contains one or more fields to help the user to resolve the currently selected error. For example, these fields may allow the user to resolve an error by using this data to identify and change corresponding data in an ERP database (e.g., a purchase order or master data). Additionally, it is noted that the fields and their attributes may be specified in a predefined configuration, and that, pursuant to one exemplary configuration, it is possible to link data to a call transaction menu so as to submit displayed data to the called transaction; paragraph 0110, discussing that an exemplary method of document error handling includes processing the electronic document in response to a document processing input and based on the plurality of data fields. Exemplary method of document error handling also includes saving a change to the electronic document in a data storage unit in response to a document update command, wherein the change reflects the editing of the data field. To illustrate, consider the example where one or more changes to the electronic document are saved in a data storage unit (such as, for example, in a central ERP database) in response to the document update command). Examiner notes that Straten, in addition to Srivastava as cited above, also teaches generating a user interface that presents an indication of the first error (paragraph 0047, discussing that the user would be able to manually manipulate data within a number of these data fields so as to correct the identified errors; paragraph 0068, discussing that it is noted that a user may manually provide error editing input so as to correct a selected error by editing a selected data field from among data fields. It is further noted that many possible solutions may exist with regard to editing a selected error…The user is provided with the ultimate decision as to which data field is to be edited as well as how such data field is to be edited; paragraph 0096, discussing that an embodiment provides a user with the option of manually navigating through advanced editor with a data node list (which may be positioned, for example, on a left side of the graphical user interface) and manually editing with either field editor or list view editor (which may be positioned, for example, on a right side of the graphical user interface)). Srivastava is directed towards a system and method for processing transactions according to review and approval workflows. Straten is directed towards a system and method for error handling. Therefore they are deemed to be analogous as they both are directed towards error handling systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Srivastava with Straten because the references are analogous art because they are both directed to solutions for error handling and correction, which falls within applicant’s field of endeavor (error review and correction system), and because modifying Srivastava to include Straten’s features for including a correction system coupled to an enterprise resource planning system via a network, identifying in the plurality records one or more second records with the first error, applying the first correction to the identified one or more second records, and passing the first record and the one or more second records as corrected records to the enterprise resource planning system via the network, in the manner claimed, would serve the motivation of allowing users to focus on error handling and allowing business to track information of interest, such as, but not limited to, information pertaining to finance/accounting operations, human resources, manufacturing, supply chain management, project management, customer relationship management, sales and services (Straten, paragraphs 0003, 0030); and further obvious because 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. As per claim 2 , the Srivastava-Straten combination teaches the computer-implemented method of claim 1 . Although not explicitly taught by Srivastava, Straten in the analogous art of error handling systems teaches further comprising sending, from the correction system, the plurality of records to the enterprise resource planning system for additional storage in an un-audited store located at the enterprise resource planning system (paragraph 0029, discussing providing highly useful IDoc error handling functionality to customers. For example, an integrated ERP system, software program or module, or a subsystem, software program or module integrated therewith (e.g., a software add-on), which may be referred to as a document error handling process or method, is implemented to provide IDoc error handling as a base functionality. This may be accomplished, for example, by loading IDocs in error from a database, such as a central database (e.g., a central database of the integrated ERP system, software program or module), into a program or application layer that provides a user with a graphical user interface. It is noted that this application layer may be an application layer of an integrated ERP software program or module with which a document error handling process or method of the present technology is integrated. It is further noted that, in an embodiment, unique functionality is added (e.g., to an integrated ERP software program or module) so as to simplify and accelerate the error handling process; paragraph 0034, discussing that the exemplary document error handling system optionally includes or is integrated with a database, wherein the database may be configured to store application layer such that the application layer may be accessed from the database, such as by a communication interface. The database may also be configured to store plurality of electronic documents such that application layer may be configured to receive or access plurality of electronic documents from the database. Indeed, in one embodiment, the application layer is launched locally and the database is a central database (e.g., a central ERP database) located remotely; paragraph 0040, discussing that in an embodiment, a document error handling process of the present technology, such as the document error handling method, is an add-on or module (e.g., an advanced business application programming software add-on) for an integrated enterprise resource planning software program or module platform (such as a customer relationship management software program or module platform) and/or any other system including electronic document (e.g., IDoc) processing capabilities. Moreover, in one embodiment, the communication between such a document error handling add-on or module and a backend system takes place through function modules provided by integrated ERP software and access to a shared database; paragraph 0070). Srivastava is directed towards a system and method for processing transactions according to review and approval workflows. Straten is directed towards a system and method for error handling. Therefore they are deemed to be analogous as they both are directed towards error handling systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Srivastava with Straten because the references are analogous art because they are both directed to solutions for error handling and correction, which falls within applicant’s field of endeavor (error review and correction system), and because modifying Srivastava to include Straten’s feature for including sending, from the correction system, the plurality of records to the enterprise resource planning system for additional storage in an un-audited store located at the enterprise resource planning system, in the manner claimed, would serve the motivation of allowing users to focus on error handling and allowing business to track information of interest, such as, but not limited to, information pertaining to finance/accounting operations, human resources, manufacturing, supply chain management, project management, customer relationship management, sales and services (Straten, paragraphs 0003, 0030); and further obvious because 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. As per claim 3 , the Srivastava-Straten combination teaches the computer-implemented method of claim 2 . Srivastava further teaches wherein the plurality of records have not been corrected by the correction system (paragraph 0012, discussing that the transaction exchange platform may receive a plurality of transaction objects, with each of the plurality of transaction objects being associated with a transaction. A streaming data platform may determine whether each of the plurality of transaction objects are associated with a prior transaction object. The streaming data platform may render the determination by performing a field-by-field check. That is, the streaming data platform may compare the fields of a received transaction object with data stored in a database…; paragraph 0066, discussing retrieving transaction objects...In this manner, the microservice may extract transaction objects from SDP (streaming data platform); paragraph 0079, discussing that the system may receive a transaction object and add it to the streaming data platform. The transaction object may be received from a transaction origination source…The transaction object may be added to the SDP in an initialization stage, which may be implemented through setting a current workflow stage of the transaction object's transaction metadata to an initialization value; paragraph 0136, discussing a snapshot microservice that may operate on transaction exchange platform to maintain a record of the data values of each transaction object on the streaming data platform, and track how the transaction objects change during processing on the platform. Snapshot data may be stored in snapshot database…Snapshot microservice and snapshot database may be configured to store differential snapshots of a transaction object; paragraph 0138, discussing that the snapshot microservice may store an initial snapshot of a transaction object in the initialization stage, then update a current workflow stage of the transaction object to indicate that the initialization processing has completed...Alternatively, the snapshot microservice may treat transaction objects [i.e., plurality of records] in the first workflow stage as being subject to initialization (as new objects), and may determine that an initial, new snapshot should be recorded in the snapshot database; paragraph 0170, discussing storing an initial record for new transaction objects on the SDP; paragraphs 0166, 0218). As per claim 4 , the Srivastava-Straten combination teaches the computer-implemented method of claim 2 . Srivastava further teaches wherein the correction system retrieves the first record from the transaction store in response to initiation of an audit of the plurality of records (paragraph 0049, discussing a transaction exchange platform implemented using a streaming data platform (SDP) and a plurality of microservices to process transactions according to workflows corresponding to different transaction types. Microservices on the transaction exchange platform may be configured to retrieve transactions...The microservice may perform one or more steps of the approval/review workflow for the type of transaction, update the status of the object, and put it back to the SDP; paragraph 0063, discussing identifying and retrieving transaction objects; paragraph 0066, discussing retrieving transaction objects...In this manner, the microservice may extract transaction objects from SDP (streaming data platform); paragraph 0170, discussing retrieving new transactions as they are added; paragraph 0204, discussing that in response to determining, by a watchdog microservice and via the streaming data platform, that the current workflow stage of the transaction object has changed, the method may comprise: retrieving, by the watchdog microservice and from the streaming data platform, the transaction object based on determining that the current workflow stage has changed and storing, by the watchdog microservice, workflow tracking data corresponding to the transaction object and the changed current workflow stage; paragraphs 0067, 0238). As per claim 5 , the Srivastava-Straten combination teaches the computer-implemented method of claim 2 . Srivastava further teaches wherein the correction system performs one or more checks on the first record (paragraph 0014, discussing that if any issues are identified in the received transaction object, the streaming data platform may perform a remedial action to correct the defect with the received transaction object. The remedial action object may be determined using the one or more machine learning models. Additionally or alternatively, the streaming data platform may generate an alert indicating the defect with the received transaction object. The alert may include sending an electronic communication to one or more parties associated with the received transaction object. The electronic communication may indicate the defect and a suggested corrective action; paragraph 0067, discussing that processing of the transaction object by the microservice may comprise any of: retrieving the transaction object; reviewing values and other characteristics of the transaction object; paragraph 0217, discussing techniques for detecting errors with transactions; paragraph 0218, discussing that the streaming data platform may analyze the received transaction object for any potential errors that may cause processing of the received transaction object to stall and/or fail; paragraph 0079, discussing that objects in the initialization stage may be subject to various system processes on the transaction exchange platform, such as format or other verifications, standardization, snapshots, and the like). As per claim 8 , the Srivastava-Straten combination teaches the computer-implemented method of claim 5 . Srivastava further teaches wherein the one or more checks further comprise detecting by a machine learning model the first error, wherein the machine learning model comprises a convolutional neural network trained using records with errors and records without errors (paragraph 0014, discussing that if any issues are identified in the received transaction object, the streaming data platform may perform a remedial action to correct the defect with the received transaction object. The remedial action object may be determined using the one or more machine learning models. Additionally or alternatively, the streaming data platform may generate an alert indicating the defect with the received transaction object. The alert may include sending an electronic communication to one or more parties associated with the received transaction object. The electronic communication may indicate the defect and a suggested corrective action. In response to the electronic communication, the one or more parties may perform one or more steps to remediate the defect with the received transaction object. In some instances, remediating the defect may comprise approving the suggested corrective action; paragraph 0227, discussing that the screening microservice may determine whether the payment transaction is a duplicate of a previously received transaction using one or more machine learning models. In this regard, the one or more machine learning models may be trained to identify duplicate transactions. The one or more machine learning models may comprise a neural network, such as a convolutional neural network (CNN), a recurrent neural network, a recursive neural network, a long short-term memory (LSTM), a gated recurrent unit (GRU), an unsupervised pre-trained network, a space invariant artificial neural network, a generative adversarial network (GAN), or a consistent adversarial network (CAN)…Additionally or alternatively, the one or more machine learning models may comprise one or more decision trees. The one or more machine learning models may be trained using supervised learning, unsupervised learning, back propagation, transfer learning, stochastic gradient descent, learning rate decay, dropout, max pooling, batch normalization, long short-term memory, skip-gram, or any equivalent deep learning technique. Once the one or more machine learning models are trained, the one or more machine learning models may be exported and/or deployed in screening microservice, which may use the one or more machine learning models to identify duplicate transactions). As per claim 9 , the Srivastava-Straten combination teaches the computer-implemented method of claim 1 . Srivastava further teaches wherein the first correction is identified using a machine learning model (paragraph 0014, discussing that if any issues are identified in the received transaction object, the streaming data platform may perform a remedial action to correct the defect with the received transaction object. The remedial action object may be determined using the one or more machine learning models. Additionally or alternatively, the streaming data platform may generate an alert indicating the defect with the received transaction object. The alert may include sending an electronic communication to one or more parties associated with the received transaction object. The electronic communication may indicate the defect and a suggested corrective action. In response to the electronic communication, the one or more parties may perform one or more steps to remediate the defect with the received transaction object. In some instances, remediating the defect may comprise approving the suggested corrective action; paragraph 0227, discussing that the screening microservice may determine whether the payment transaction is a duplicate of a previously received transaction using one or more machine learning models. In this regard, the one or more machine learning models may be trained to identify duplicate transactions. The one or more machine learning models may comprise a neural network, such as a convolutional neural network (CNN), a recurrent neural network, a recursive neural network, a long short-term memory (LSTM), a gated recurrent unit (GRU), an unsupervised pre-trained network, a space invariant artificial neural network, a generative adversarial network (GAN), or a consistent adversarial network (CAN)…Additionally or alternatively, the one or more machine learning models may comprise one or more decision trees. The one or more machine learning models may be trained using supervised learning, unsupervised learning, back propagation, transfer learning, stochastic gradient descent, learning rate decay, dropout, max pooling, batch normalization, long short-term memory, skip-gram, or any equivalent deep learning technique. Once the one or more machine learning models are trained, the one or more machine learning models may be exported and/or deployed in screening microservice, which may use the one or more machine learning models to identify duplicate transactions; paragraph 0185). Claim 10 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 1, as discussed above. Further, as per claim 10, the Srivastava-Straten combination teaches a system comprising: at least one processor (Srivastava, paragraph 0045: “computing device 101 may include a processor 111, RAM 113, ROM 115, network interface 117, input/output interfaces 119 (e.g., keyboard, mouse, display, printer, etc.), and memory 121. Processor 111 may include one or more computer processing units (CPUs), graphical processing units (GPUs), and/or other processing units such as a processor adapted to perform computations associated with machine learning. I/O 119 may include a variety of interface units and drives for reading, writing, displaying, and/or printing data or files. I/O 119 may be coupled with a display such as display 120.”; paragraph 0258: “a transaction exchange platform may comprise a streaming data platform, a plurality of microservices, at least one processor, and memory…The memory may store instructions…”) ; and at least one memory including instructions which when executed by the at least one processor causes operations (paragraph 0045: “Memory 121 may store software for configuring computing device 101 into a special purpose computing device in order to perform one or more of the various functions discussed…”; paragraph 0258: “a transaction exchange platform may comprise a streaming data platform, a plurality of microservices, at least one processor, and memory…The memory may store instructions…”). Claims 11 and 20 recite substantially similar limitations that stand rejected via the art citations and rationale applied to claim 2, as discussed above. Claim 12 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 3, as discussed above. Claim 13 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 4, as discussed above. Claim 14 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 5, as discussed above. Claim 17 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 8, as discussed above. Claim 18 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 9, as discussed above. Claim 19 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 1, as discussed above. Further, as per claim 19, the Srivastava-Straten combination teaches a non-transitory computer-readable storage medium including code which when executed by at least one processor causes operations (Srivastava, paragraph 0047: “One or more aspects discussed herein may be embodied in computer-usable or readable data and/or computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices as described herein. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The modules may be written in a source code programming language that is subsequently compiled for execution, or may be written in a scripting language such as (but not limited to) HTML or XML. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, RAM…Various aspects discussed herein may be embodied as a method, a computing device, a data processing system, or a computer program product.”) . 07-21-aia AIA 22. Claim s 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Srivastava in view of Straten, in further view of Alfaras et al., Pub. No.: US 2024/0281419 A1, [hereinafter Alfaras] . As per claim 6 , the Srivastava-Straten combination teaches the computer-implemented method of claim 5 . Srivastava further teaches wherein the one or more checks comprise a unit of measure check and/or an identifier check (paragraph 0015, discussing that once any defects with the received transaction object are rectified and/or remediated, or if no defects are detected with the received transaction object, the streaming data platform may generate a unique identifier for the received transaction object. The unique identifier may be an alphanumeric string generated using a hash function, such as SHA256. After the received transaction object is assigned a unique identifier, the received transaction object may be processed by one or more microservices in accordance with a workflow associated with the received transaction object. In some instances, a microservice may perform a validation check on the received transaction object. The validation check may access a client register to determine whether the transaction associated with the received transaction object is allowed. If the transaction is not allowed, the received transaction object may be removed from the streaming data platform or other remedial actions may be taken. However, if the transaction is allowed to proceed, a client identifier may be appended to the unique identifier. The combination of the client identifier and the unique identifier may create a 1:1 link with the 15-digit tracking identifier used in the transaction file that is routed to the downstream processor. Accordingly, any subsequent attempt by this client to inject the same transaction, or a duplication of the transaction, may spawn write error logs based on the 1:1 link between the tracking identifier and the combined the client identifier and the unique identifier; paragraph 0222, discussing that one or more aspects described may provide for detecting duplicate transactions, as well as other flaws or errors associated with transactions. The techniques described may provide one or more techniques for remediating duplicate transactions, or other errors, that may cause processing of the transactions to fail. Additionally, the techniques described provide for the generation of a unique transaction identifier. The unique transaction identifier may be generated by concatenating a version number and an identification token associated with the transaction identifier. The unique transaction identifier may be used by both the transaction exchange platform and downstream processors, to ensure that the transaction is not rejected for being a duplicate of another transaction; paragraph 0019). The Srivastava-Straten combination does not explicitly teach wherein the one or more checks comprise a unit of measure check and/or an article identifier check . However, Alfaras in the analogous art of data quality management systems teaches this concept. Alfaras teaches: wherein the one or more checks comprise a unit of measure check and/or an article identifier check (paragraph 0006, discussing systems and methods for operating a data platform across various cloud and legacy environments to provide increased data visibility and quality management; paragraph 0239, discussing that the data validation logic can include consistency checks to identify discrepancies, anomalies, or duplicates within the data. These checks compare data values across different records, fields, or sources to detect inconsistencies or deviations from expected patterns. For example, the data validation logic may flag records with duplicate customer IDs, inconsistent product codes, or conflicting address information, allowing organizations to address data quality issues proactively). The Srivastava-Straten combination describes features related to error review and correction. Alfaras is directed towards a data visibility and quality management platform. Therefore they are deemed to be analogous as they both are directed towards data management and error handling systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Srivastava-Straten combination with Alfaras because the references are analogous art because they are both directed to solutions for error handling and correction, which falls within applicant’s field of endeavor (error review and correction system), and because modifying Srivastava-Straten combination to include Alfaras’ feature for including wherein the one or more checks comprise a unit of measure check and/or an article identifier check, in the manner claimed, would serve the motivation of maintaining the integrity and reliability of the data stored and ensuring that users can trust the accuracy and consistency of the information they access for decision-making and analysis (Alfaras, paragraph 0003); and further obvious because 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. Claim 15 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 6, as discussed above . 07-21-aia AIA 23. Claim s 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Srivastava in view of Straten, in further view of Rizvi et al., Pub. No.: US 2023/0359901 A1, [hereinafter Rizvi] . As per claim 7 , the Srivastava-Straten combination teaches the computer-implemented method of claim 5 . Srivastava further teaches train a machine learning model to detect the first error (paragraph 0227, discussing that the screening microservice may determine whether the payment transaction is a duplicate of a previously received transaction using one or more machine learning models. In this regard, the one or more machine learning models may be trained to identify duplicate transactions. The one or more machine learning models may comprise a neural network, such as a convolutional neural network (CNN), a recurrent neural network, a recursive neural network, a long short-term memory (LSTM), a gated recurrent unit (GRU), an unsupervised pre-trained network, a space invariant artificial neural network, a generative adversarial network (GAN), or a consistent adversarial network (CAN)…Additionally or alternatively, the one or more machine learning models may comprise one or more decision trees. The one or more machine learning models may be trained using supervised learning, unsupervised learning, back propagation, transfer learning, stochastic gradient descent, learning rate decay, dropout, max pooling, batch normalization, long short-term memory, skip-gram, or any equivalent deep learning technique. Once the one or more machine learning models are trained, the one or more machine learning models may be exported and/or deployed in screening microservice, which may use the one or more machine learning models to identify duplicate transactions). The Srivastava-Straten combination does not explicitly teach wherein the user confirmation received via the user interface is used to train a machine learning model to detect the first error . However, Rizvi in the analogous art of validation systems teaches this concept. Rizvi teaches: wherein the user confirmation received via the user interface is used to train a machine learning model to detect the first error (paragraph 0004, discussing that the online system samples a subset of the item updates based on the error likelihood scores and passes these sampled item updates to a human reviewer system. The human reviewer system labels each of the sampled item updates with an error label indicating whether or not the corresponding item update is actually erroneous. The online system determines whether to update the item database with the full set of received item updates based on the error labels. If the online system determines to update the item database (e.g., because an error rate of the sampled item updates is below some threshold), the online system updates one or more item entries in the item database based on the item updates. If the online system determines not to update the item database, the online system may perform a corrective action, such as sending the item updates back to the item update system to be reviewed and corrected; paragraph 0053, discussing that the update review module validates item updates using a machine-learning model to identify item updates that need independent review. The online system maintains an item database that has item entries for items on the online system. The update review module receives item updates from an item update system and applies an error prediction model to the item updates to generate an error likelihood score for each item update. The update review module samples a subset of the item updates based on the error likelihood scores and passes these sampled item updates to a human reviewer system. The human reviewer system labels each of the sampled item updates with an error label indicating whether the corresponding item update is actually erroneous; paragraph 0060, discussing that the online concierge system uses the error labels from the human reviewer system to generate additional training examples for the error prediction model. For example, the online concierge system may generate a training example for each item update in the sample subset of item updates, and may label each training example using the error label from the human review system. The online concierge system may retrain the error prediction model based on the additional training examples). The Srivastava-Straten combination describes features related to error review and correction. Rizvi is directed towards a validation system. Therefore they are deemed to be analogous as they both are directed towards data management systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Srivastava-Straten combination with Rizvi because the references are analogous art because they are both directed to solutions for error handling and correction, which falls within applicant’s field of endeavor (error review and correction system), and because modifying Srivastava-Straten combination to include Rizvi’s feature for including wherein the user confirmation received via the user interface is used to train a machine learning model to detect the first error, in the manner claimed, would serve the motivation of further refining the error prediction model (Rizvi, paragraph 0005); and further obvious because 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. Claim 16 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 7, as discussed above . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Abdelaal et al., Pub. No.: US 2025/0348470 A1 – describes that the role of the data owner is streamlined and focused. The data owner can, for example, focus on validating the generated rules and/or corrections, if necessary, and labeling data samples to train ML models used for data validation or correction. Schumann, Michael A., et al. "Modeling human-in-the-loop security analysis and decision-making processes." IEEE Transactions on Software Engineering 40.2 (2014): 154-166 – describes an application of computer-assisted formal methods for systematically specifying, documenting, statically and dynamically checking, and maintaining human-centered workflow processes. This approach provides for end-to-end verification and validation of process workflows, which is needed for process workflows that are intended for use in developing and maintaining high-integrity systems. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL . 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 extension fee 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 DARLENE GARCIA-GUERRA whose telephone number is (571) 270-3339. The examiner can normally be reached M-F 7:30a.m.-5:00p.m. 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, Brian M. Epstein can be reached on (571) 270-5389. 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. /Darlene Garcia-Guerra/ Primary Examiner, Art Unit 3625 Application/Control Number: 18/936,463 Page 2 Art Unit: 3625 Application/Control Number: 18/936,463 Page 3 Art Unit: 3625 Application/Control Number: 18/936,463 Page 4 Art Unit: 3625 Application/Control Number: 18/936,463 Page 5 Art Unit: 3625 Application/Control Number: 18/936,463 Page 6 Art Unit: 3625 Application/Control Number: 18/936,463 Page 7 Art Unit: 3625 Application/Control Number: 18/936,463 Page 9 Art Unit: 3625 Application/Control Number: 18/936,463 Page 10 Art Unit: 3625 Application/Control Number: 18/936,463 Page 11 Art Unit: 3625 Application/Control Number: 18/936,463 Page 12 Art Unit: 3625 Application/Control Number: 18/936,463 Page 13 Art Unit: 3625 Application/Control Number: 18/936,463 Page 14 Art Unit: 3625 Application/Control Number: 18/936,463 Page 15 Art Unit: 3625 Application/Control Number: 18/936,463 Page 16 Art Unit: 3625 Application/Control Number: 18/936,463 Page 17 Art Unit: 3625 Application/Control Number: 18/936,463 Page 18 Art Unit: 3625 Application/Control Number: 18/936,463 Page 19 Art Unit: 3625 Application/Control Number: 18/936,463 Page 20 Art Unit: 3625 Application/Control Number: 18/936,463 Page 21 Art Unit: 3625 Application/Control Number: 18/936,463 Page 22 Art Unit: 3625 Application/Control Number: 18/936,463 Page 23 Art Unit: 3625 Application/Control Number: 18/936,463 Page 24 Art Unit: 3625 Application/Control Number: 18/936,463 Page 25 Art Unit: 3625 Application/Control Number: 18/936,463 Page 26 Art Unit: 3625 Application/Control Number: 18/936,463 Page 27 Art Unit: 3625 Application/Control Number: 18/936,463 Page 28 Art Unit: 3625 Application/Control Number: 18/936,463 Page 29 Art Unit: 3625 Application/Control Number: 18/936,463 Page 30 Art Unit: 3625 Application/Control Number: 18/936,463 Page 31 Art Unit: 3625 Application/Control Number: 18/936,463 Page 32 Art Unit: 3625 Application/Control Number: 18/936,463 Page 33 Art Unit: 3625 Application/Control Number: 18/936,463 Page 34 Art Unit: 3625 Application/Control Number: 18/936,463 Page 35 Art Unit: 3625 Application/Control Number: 18/936,463 Page 36 Art Unit: 3625 Application/Control Number: 18/936,463 Page 37 Art Unit: 3625 Application/Control Number: 18/936,463 Page 38 Art Unit: 3625 Application/Control Number: 18/936,463 Page 39 Art Unit: 3625 Application/Control Number: 18/936,463 Page 40 Art Unit: 3625 Application/Control Number: 18/936,463 Page 41 Art Unit: 3625 Application/Control Number: 18/936,463 Page 42 Art Unit: 3625 Application/Control Number: 18/936,463 Page 43 Art Unit: 3625 Application/Control Number: 18/936,463 Page 44 Art Unit: 3625 Application/Control Number: 18/936,463 Page 45 Art Unit: 3625
Prosecution Insights