DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/02/2026 has been entered.
Response to Amendment
Applicant’s “Amendment” filed on 06/22/2026 has been considered.
Claims 1, 11, and 17 are amended. Claims 4-6, 8, 12, 14, and 18 are canceled. Claims 1-3, 7, 9-11, 13, 15-17, and 19-20 remain pending in this application and an action on the merits follow.
Applicant’s response by virtue of amendment to claims has not overcome the Examiner’s rejection under 35 USC § 101.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 11, and 17 recites the limitation "retrieving…metadata from the database for each exception rule", “comprises threshold values...”, and “retrieving exception rules from the database” There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 USC 101. The claimed invention is directed to non-statutory subject matter because claims 1, 11, and 17 are directed to an abstract idea without significantly more. Claims 2-3, 7, 9-10, 13, 15-16, and 19-20 fail to remedy these deficiencies.
The claims 1, 11, and 17 recite receives data from the plurality of data sources, extracts data elements from the data according to a definition, validates the data elements by confirming that asset of data elements is complete and that a set of data elements comprises necessary data elements, retrieves metadata comprising threshold values for the extracted data elements, retrieves the exception rules from the database, validating the exception rules, retrieving metadata from the database for each exception rule, retrieving exception rules from the database, training a machine learning model with historical data from the plurality of data sources to set rules that are used to identify exceptions and to set values that are thresholds for triggering an exception, applies the exception rules to the data elements by comparing values for the data elements to corresponding threshold values, identifies an exception based on the value for one of the data elements breaching the corresponding threshold value, wherein the exception predicts the occurrence of a future issue, and performs automatic exception resolution on the data associated with the one data element by replacing the data at one or more of the plurality of data sources by sending an event.
The Claims 1, 11, and 17 recite extracting, validating, checking, training, applying, identifying, and performing steps as drafted, are processes that under broadest reasonable interpretation, cover performance of managing personal behavior, but for the recitation of generic computer components. That is, other than reciting “a plurality of data sources, a database, an orchestrator computer program executed by an electronic device, and one or more computer processors”, nothing in the claim element precludes the steps from practically being performed by organizing human activity. For example, but for the “the plurality of data sources, the database, the orchestrator computer program executed by the electronic device, and the one or more computer processors” in the context of these claims encompasses a person manually extracts data elements, validates the data elements by confirming the set of data elements is compete and necessary, validates the exceptions rules by checking if the exception rules applies to the data itself, applies the retrieved exceptions rules to compare the values of the data to threshold values, identifies an exception, and performs automatic exception resolution/correction by replacing the data by sending an event. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation by managing personal behavior but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
The limitation of training and setting rule steps as drafted, are processes that under broadest reasonable interpretation, cover performance of the limitation by utilizing mathematical algorithms/functions but for the recitation of generic computer components. That is, other than reciting ““the plurality of data sources, the database, the orchestrator computer program executed by the electronic device, and the one or more computer processors”, nothing in the claim element precludes the steps from practically being performed by utilizing mathematical algorithms. For example, but for the “the plurality of data sources, the database, the orchestrator computer program executed by the electronic device, and the one or more computer processors” language, in the context of these claims encompasses a user manually trains a machine learning model to set rules and values for triggering an exception. Training a machine learning model and apply this trained model is generic data process. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation by utilizing mathematical algorithms/functions but for the recitation of generic computer components, then it falls within the “Mathematical Concepts” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because receiving and retrieving step is recited at a high level of generality (i.e., as a general means of receiving and retrieving data, metadata, and exception rules) and amounts to mere data gathering, which is a form of insignificant extra-solution activity. This judicial exception is not integrated into a practical application because the claims as a whole merely describe how to generally “apply” the concept of receiving, extracting, validating, checking, training, retrieving, applying, identifying, and performing in a computer environment. The claimed computer components such as the plurality of data sources, the database, the electronic device, and the one or more computer processors are recited at a high level of generality and are merely invoked as tools to perform receiving, extracting, validating, checking, training, retrieving, applying, identifying, and performing steps. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims 1, 11, and 17 are directed to an abstract idea.
The claims 1, 11, and 17 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using the plurality of data sources, the database, the electronic device, and the one or more computer processors to perform receiving, extracting, validating, checking, training, retrieving, applying, identifying, and performing steps amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Therefore, the claims do not amount to significantly more than the recited abstract idea (Step 2B: NO). The claims 1, 11, and 17 are not patent eligible.
Claims 2-3, 7, 9-10, 13, 15-16, and 19-20, disclose insignificant helpful content to further describe content, such as accounting data, Generally Accepted Accounting Principles, and the different embodiments of the automatic exception resolution, which are merely descriptive content to further limit the abstract idea but not make it less abstract. Thus, the claims 2-3, 7, 9-10, 13, 15-16, and 19-20 are directed to an abstract idea.
This judicial exception is not integrated into a practical application because descriptive content in claims 2-3, 7, 9-10, 13, 15-16, and 19-20 further limit the abstract idea but not make it less abstract. Thus, the claims 2-3, 7, 9-10, 13, 15-16, and 19-20 are directed to an abstract idea.
There are no additional claim element limitations recited in the claims 2-3, 7, 9-10, 13, 15-16, and 19-20. Therefore, the claim does not amount to significantly more than the recited abstract idea (Step 2B: NO). The claims 2-3, 7, 9-10, 13, 15-16, and 19-20 are not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 7, 9-11, 13, 15-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2015/0332199 to Olson et al., in view of U.S. Patent Application Publication No. 2024/0119458 to Hoiles, and further in view of U.S. Patent Application Publication No. 2023/0222113 to Singh et al.
With regard to claims 1, 11, and 17, Olson discloses a method for trial balance analytics security maintenance, comprising:
receiving, by an orchestrator computer program, data from a plurality of data sources (paragraphs 12-13, Enterprises utilizing financial data receive data from various sources. For example, the financial data may include consumer information from customer sources and credit information from credit sources.);
extracting, by the orchestrator computer program, data elements from the data according to a definition (paragraph 16, data sources 10 may apply quality assurance rules to data as data sources 10 are generating the data);
validating, by the orchestrator computer program, the data elements by confirming that a set of the data elements is complete and by confirming that a set of data elements comprises necessary data elements for application of the exception rules (paragraph 16, For example, quality assurance rules may be applied to ensure that data is accurate and complete.);
retrieving, by the orchestrator computer program, metadata comprising threshold values for the extracted data elements (paragraph 26, Memory 20 may also include historical data 32. Historical data 32 represents previously communicated data that reporting module 14 stores. Furthermore, reporting module 14 may store historical data 32 for a certain time period (e.g., historical data 32 may contain only the past 60 months of communicated data or any other appropriate length of time).),
retrieving, by the orchestrator computer program, exception rules from a database (paragraph 25, Memory 20 may include QC rules 28. QC rules 28 facilitate the determination of whether data received from one of the data sources 10 contains an exception.);
retrieving, by the orchestrator computer program, metadata from the database for each exception rule, wherein the metadata is retrieved specifically for the exception rule and comprises threshold values for the extracted data elements (paragraph 38, For example, if a data record is not updated in one or more external modules 16 within a certain time period (e.g., three months), then one or more external modules 16 may communicate to module 14 or enterprise 18 via network 12 that the data record is outdated), retrieving exception rules from the database (paragraph 24-25, Memory 20 may be a database that stores, either permanently or temporarily, received data, quality control (“QC”) rules 28, exception rules 30, historical rules 32, any other suitable data, or any combination of the preceding);
applying, by the orchestrator computer program, the exception rules to the data elements by comparing values for the data elements to corresponding threshold values for the metadata (paragraphs 25-26 and 33, An exception may occur if data received by reporting module 14 does not comply with QC rules 28 or is inconsistent with historical data 32. Processor 24 may be configured to compare data received from data sources 10 to determine inconsistencies between the received data and historical data 32. In an embodiment, reporting module 14 may compare the received data to historical data 32. Historical data 32 may be used to ensure that the received data is consistent with previously received data);
identifying, by the orchestrator computer program, an exception based on the value for one of the data elements breaching the corresponding threshold value, (paragraph 34, reporting module 14 may use exception rules 30 and processor 24 to determine whether the exception is a warning exception or a fatal exception. For example, reporting module 14 may use exception rules 30 and processor 24 to generate a fatal exception, which may indicate that reporting module 14 should prevent communicating the received data to external modules 16. For example, exception rules 30 may instruct processor 24 or other suitable components of reporting module 14 to generate a fatal exception if one field of the received data indicates that an account is current and another field of the received data indicates that the customer missed a payment. As a further example, exception rules 20 may instruct processor 24 or other suitable components of reporting module 14 to generate a warning exception when a customer's name differs between the received data and historical data 32.); and
performing, by the orchestrator computer program, automatic exception resolution on the data (paragraph 36, While still complying with appropriate affiliate sharing rules, the common exceptions report may be communicated to any number of data sources 10, including a broadcast message to all of the data sources 10. One or more data sources 10 may then utilize the common exceptions report to correct errors and/or inconsistencies in data. This allows for data sources 10 to increase data accuracy.).
However, Olson does not disclose validating, by the orchestrator computer program, the exception rules by checking if the exception rules applies to the data itself and validating that a type of the exception rules is applied to a type of the data; wherein the exception rules are based on historical exception analysis, and training a machine learning engine with historical data from the plurality of data sources and results of the orchestrator computer program to set rules that are used to identify exceptions and to set values that are thresholds for triggering an exception; wherein the exception predicts the occurrence of a future issue if one or more trends of the data continue; performing, automatic exception resolution on the data by replacing the data at one or more of the plurality of data sources by sending an event.
However, Hoiles teaches validating, by the orchestrator computer program, the exception rules by checking if the exception rules applies to the data itself and validating that a type of the exception rules is applied to a type of the data ( the system and method described herein can use historical transactional data and can automatically identify new rules that would improve consistency of transaction entries. at input device 102) receive 330 user input indicating that the rules are to be applied. For example, the system may display one or more of the rules to user 100 via the display screen 103, and user 100 may elect to make the displayed rule or rules active in the system., paragraphs 71 and 82);
wherein the exception rules are based on historical exception analysis, and training a machine learning engine with historical data from the plurality of data sources and results of the orchestrator computer program to set rules that are used to identify exceptions and to set values that are thresholds for triggering an exception (Various embodiments described herein provide improved functionality for using machine learning to generate rules for identifying potentially erroneous transactions based on the specific accounting operations of a business. In some embodiments, a method for identifying potentially erroneous transactions may include, at a hardware processing device, receiving user data indicative of historical actions taken by a user relative to transactions, automatically processing the user data to generate a plurality of rules, and automatically applying the rules to a transaction to determine that the transaction is likely to be erroneous. The transaction may have a plurality of attributes, each of which falls within one of a plurality of categories. Automatically processing the user data may include analyzing historical actions of the user relative to historical transactions that also have the same or similar attributes. Automatically applying the rules to the transaction may include comparing the attributes of the transaction with the rules. There is, however, a significantly more powerful method that can be used to increase the consistency and robustness of financial transactions in the form of “smart rules.” In at least one embodiment, the system and method described herein can use historical transactional data and can automatically identify new rules that would improve consistency of transaction entries. One common method to surface a potential error in accounting data is to provide an anomaly detection method that can raise an alert to a human operator for further action. Such anomaly detection methods often focus on identifying a pattern (statistical distribution) suggested by the majority of observations, and then classifying as anomalous any observation that does not follow the learned pattern., paragraphs 5, 7, 61, 71, and 162-164).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Olson to include, validating, by the orchestrator computer program, the exception rules by checking if the exception rules applies to the data itself and validating that a type of the exception rules is applied to a type of the data; wherein the exception rules are based on historical exception analysis, and training a machine learning engine with historical data from the plurality of data sources and results of the orchestrator computer program to set rules that are used to identify exceptions and to set values that are thresholds for triggering an exception, as taught in Hoiles, in order to identify potential errors in accounting entries (Hoiles, paragraph 1).
However, Singh teaches the exception predicts the occurrence of a future issue if one or more trends of the data continue (Accordingly, prediction 308 generated by machine learning component 302 trained by embodiments of training data 304 for a given failed validation rule can be a prediction (e.g., probability) of failure for one or more future transaction types performed using the database that failed the validation. Accordingly, prediction 308 generated by machine learning component 302 trained by embodiments of training data 304 for a given failed validation rule can be suggested solution for the failed validation rule based on one or more trends present in training data 304. paragraphs 35-36); performing, automatic exception resolution on the data by replacing the data at one or more of the plurality of data sources by sending an event (Embodiments of the validator and defined validation rules can instruct or suggest that the customer select a correct value., paragraph 53).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Olson to include, the exception predicts the occurrence of a future issue if one or more trends of the data continue; performing, automatic exception resolution on the data by replacing the data at one or more of the plurality of data sources by sending an event, as taught in Singh, in order to predict errors using database validation rules and machine learning (Singh, paragraph 1).
With regard to claim 2, Olson discloses the data comprises accounting data (paragraph 12, This data may include consumer data or credit data. Consumer data may include, but is not limited to, consumer deposits or any other suitable type of data. Credit data may include, but is not limited to, consumer credit cards, home loans, mortgages, auto loans, small business credit cards, recovery, military data, any other suitable type of data, or any combination of the preceding.).
With regard to claim 3, Olson discloses the definition is based on Generally Accepted Accounting Principles (paragraphs 16 and 31, Quality assurance rules are generally applied by data sources 10 and may be applied as data sources 10 create a data file. Quality assurance rules ensure that data meets certain requirements before being communicated to reporting module 14. Examiner notes that GAAP definition is a well-known definition/rule applied in a accounting technology field. By definition, GAAP stands for generally accepted accounting principles, which set the standard accounting rules for preparing, presenting, and reporting financial statements in the U.S. The goal of GAAP is to ensure that a company's financial statements are complete, consistent, and comparable).
With regard to claims 7 and 13, the combination of references discloses and teaches the exception rules are based on historical exception analysis (Hoiles, paragraphs 5, 7, 61, 71, and 162-164).
With regard to claims 9, 15, and 19, the combination of references discloses and teaches the automatic exception resolution comprises sending an event with corrected data to a downstream system (Singh, paragraph 53).
With regard to claims 10, 16, and 20, the combination of references discloses and teaches the automatic exception resolution comprises closing out an exception in response to a set of data elements following a pattern similar to a previously reviewed set of data elements having a closed exception (Hoiles, paragraph 175, It may allow automated generation of new rule recommendations based on each business's unique transaction patterns. Use cases include detection of transactional abnormalities in the General Ledger, Accounts Payable, Accounts Receivable, etc., and automated construction of associated accounting rules to improve the consistency of transactions in these respective ledgers. Singh, paragraphs 24 and 93, In this example, feedback can be received about the suggestions, such as whether the user accepted and implemented the suggested solution. In some embodiments, a machine learning model implemented by suggested solution engine 112 can also be trained based on previous observations (e.g., solution data 406) to generate a suggested solution. For example, ADJ with calculated parameters may not encounter an error, whereas other similar transactions may be at risk for error, such as the original next transaction.).
Response to Arguments
Applicants' amendments and arguments filed on 06/22/2026 have been fully considered but they are not fully persuasive especially in light of the new prior art applied in the rejections.
Applicants remark that “the combination of references does not disclose validating, by the orchestrator computer program, the exception rules by checking if the exception rules applies to the data itself and validating that a type of the exception rules is applied to a type of the data; retrieving, by the orchestrator computer program, metadata from the database for each exception rule, wherein the metadata is retrieved specifically for the exception rule and comprises threshold values for the extracted data elements, retrieving exception rules from the database, wherein the exception rules are based on historical exception analysis, and training a machine learning engine with historical data from the plurality of data sources and results of the orchestrator computer program to set rules that are used to identify exceptions and to set values that are thresholds for triggering an exception; wherein the exception predicts the occurrence of a future issue if one or more trends of the data continue”.
Examiner directs Applicants' attention to the office action above.
Conclusion
Please refer to form 892 for cited references.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARIEL J YU whose telephone number is (571)270-3312. The examiner can normally be reached 11AM - 7PM (M-F).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Obeid Fahd A can be reached on 571-270-3324. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ARIEL J YU/Primary Examiner, Art Unit 3627
Prosecution Insights