DETAILED ACTION
Case Status
This office action is in response to remarks and amendments of 7/22/2026. Claims 1 and 3-21 have been examined.
Pertinent Prior Art
Prior art that is considered pertinent to applicant's disclosure but not currently relied upon:
US 20210241043
Pars. 37, 41-42, 47-54
Machine learning model trained on validation history for financial data, notifications, results database
US 11270375 B1
Abstract
Aggregating financial data from multiple sources, training a machine learning model on historical profiles and presenting results
US 20220114483
Pars. 26-28, 40-53
Event triggered real time aggregation from multiple sources, data change detection, and machine learning pipeline
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 and 3-21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-19 of U.S. Patent No. 12346307 B2, hereinafter ‘307 patent, in view of Bonar et al., Pub. No.: US 20100124196 A1, hereinafter Bonar. Although the claims at issue are not identical, they are not patentably distinct from each other as shown below.
All limitations and elements in claims 1, 14, 19, and 21 of the instant application are found in claims 1, 14 and 19 of the ‘307 patent except for determining, based on capabilities of one or more registered validators, an operational mode associated with distribution of the aggregated resource, and the subject matter of claim 21. However, Bonar, pars. 30-31, 110-113 discloses these limitations as determining push, pull, and cooperative push modes as possible determinations of how data is distributed to a receiving device based on device capability information. It would be obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, with the teachings of the ‘307 patent and Bonar before them, to determine an operational mode for distributing the ‘307 patent’s aggregated validation input based on a registered validator’s capabilities because this would permit validation data to be provided using a distribution mode supported by the particular validator and this allows for the support of validators with different communication capabilities
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 3-7, 10-16 and 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over Akyol et al., US 20200127973 A1, hereinafter Akyol, in view of Huang et al., Pub. No.: US 20080162272 A1, hereinafter Huang, and further in view of Bonar.
As per claim 1, Akyol discloses A computer-implemented method comprising:
determining training data comprising: a history of validation requests, wherein each historical validation request identifies one or more resources to be aggregated and validated (see pars. 66-71, 90 wherein multiple instances of command validation activity are used to structure training data, including infrastructure commands 403, controller state data 405, asset state data 407 and command validation results 411); and
an indication of validation results corresponding to each historical validation request (see rejection above including pars. 70 and 90 for validations results corresponding to each of the multiple instances of command validation activity);
generating a trained machine learning model by training, using the training data, a machine learning model to perform validation of input aggregated resources (at least pars. 46-49, 72-77, 97 disclose generating and training a machine learning models);
aggregating […] data of one or more resources to generate an aggregated resource (pars. 23, 25, 36, 48, 80 disclose sending packet/commands along with associated metadata as model input to command validation models, providing the received command and other relevant data to a central agent for validation, that the command validator can use asset data and state/status data in addition to the input (i.e. the command, metadata, relevant data, state/status information are aggregated data from resources that form the input resource to be validated));
Akyol does not expressly disclose, however Huang discloses that aggregation is performed based on determining that a metric corresponding to activity of an application satisfies a threshold corresponding to a change in status of the application (Huang, abstract, fig.’s 1, 3A-3B and corresponding portions in the detailed description disclose monitoring application performance (i.e. status) using performance metrics, determining a difference between a recent application performance value and a historical one, and comparing the difference in view of a performance threshold, which if exceeded, causes trace data collection (i.e. determining that a metric corresponding to activity of an application satisfies a threshold corresponding to a change in status of the application)).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of the cited references because Huang would have allowed Akyol to selectively obtain relevant validation data in response to detected deviations in application behavior which would provide validation data when an application’s operation changes significantly.
The combination does not expressly disclose, however Bonar discloses determine, based on capabilities of one or more registered validators, an operational mode associated with distribution of the aggregated resources (Bonar, pars. 30-31, 110-113 disclose determining push, pull, and cooperative push modes as possible determinations of how data is distributed to a receiving device based on device capability information and Aykol, at least pars. 26-27, 39, 74-77 disclose registered validators).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of the cited references because Bonar would have allowed Akyol to determine the operational mode for distributing its aggregated validation input based on Akyol’s registered validator capabilities because this would permit the validation data to be provided using a distribution mode supported by the particular validator and this allows for the support of validators with different communication capabilities.
causing, based on the operational mode, distribution of the aggregated resource to the one or more registered validators (Akyol, pars. 25-29, 77 disclose sending commands and associated metadata to registered command validation models for validation and Bonar as cited above discloses transmitting data based on an operational mode);
validating the aggregated resource by: providing, to the trained machine learning model, at least a portion of the aggregated resource (Akyol, pars. 23, 48, 77, 80); and
determining, based on output of the trained machine learning model, validation results (Akyol, pars. 23, 29, 77, 80-81, 107); and
writing the validation results to a results database (Akyol, pars. 83, 85, 90).
As per claim 14, Akyol discloses A computing device comprising:
one or more processors; and memory storing instructions that, when executed by the one or more processors (pars. 109-120), configure the computing device to: determine training data comprising: a history of validation requests, wherein each historical validation request identifies one or more resources to be aggregated and validated (see pars. 66-71, 90 wherein multiple instances of command validation activity are used to structure training data, including infrastructure commands 403, controller state data 405, asset state data 407 and command validation results 411); and
an indication of validation results corresponding to each historical validation request (see rejection above including pars. 70 and 90 for validations results corresponding to each of the multiple instances of command validation activity);
generate a trained machine learning model by training, using the training data, a machine learning model to perform validation of input aggregated resources (at least pars. 46-49, 72-77, 97 disclose generating and training a machine learning models);
aggregating […] data of one or more resources to generate an aggregated resource (pars. 23, 25, 36, 48, 80 disclose sending packet/commands along with associated metadata as model input to command validation models, providing the received command and other relevant data to a central agent for validation, that the command validator can use asset data and state/status data in addition to the input (i.e. the command, metadata, relevant data, state/status information are aggregated data from resources that form the input resource to be validated));
Akyol does not expressly disclose, however Huang discloses that aggregation is performed based on determining that a metric corresponding to activity of an application satisfies a threshold corresponding to a change in status of the application (Huang, abstract, fig.’s 1, 3A-3B and corresponding portions in the detailed description disclose monitoring application performance (i.e. status) using performance metrics, determining a difference between a recent application performance value and a historical one, and comparing the difference in view of a performance threshold, which if exceeded, causes trace data collection (i.e. determining that a metric corresponding to activity of an application satisfies a threshold corresponding to a change in status of the application)).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of the cited references because Huang would have allowed Akyol to selectively obtain relevant validation data in response to detected deviations in application behavior which would provide validation data when an application’s operation changes significantly.
The combination does not expressly disclose, however Bonar discloses determine, based on capabilities of one or more registered validators, an operational mode associated with distribution of the aggregated resources (Bonar, pars. 30-31, 110-113 disclose determining push, pull, and cooperative push modes as possible determinations of how data is distributed to a receiving device based on device capability information and Aykol, at least pars. 26-27, 39, 74-77 disclose registered validators).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of the cited references because Bonar would have allowed Akyol to determine the operational mode for distributing its aggregated validation input based on Akyol’s registered validator capabilities because this would permit the validation data to be provided using a distribution mode supported by the particular validator and this allows for the support of validators with different communication capabilities.
causing, based on the operational mode, distribution of the aggregated resource to the one or more registered validators (Akyol, pars. 25-29, 77 disclose sending commands and associated metadata to registered command validation models for validation and Bonar as cited above discloses transmitting data based on an operational mode);
validate the aggregated resource by: providing, to the trained machine learning model, at least a portion of the aggregated resource (Akyol, pars. 23, 48, 77, 80); and
determining, based on output of the trained machine learning model, validation results (Akyol, pars. 23, 29, 77, 80-81, 107); and
generate a notification based on the validation results (Akyol, pars. 83, 85, 90).
As per claim 19, it is analogous to claim 14 and therefore likewise rejected.
As per claim 3, Akyol discloses The computer-implemented method of claim 1, further comprising: detecting, by an event monitor, a change of a data resource; and aggregating the data of the one or more resources based on the detected change of the data resource (pars. 71, 79 disclose real-time input data received by model generator and the pipeline is triggered by command receipt (event monitor detecting data resource change triggering aggregation)).
As per claim 4, Akyol discloses The computer-implemented method of claim 1, further comprising: aggregating data of the one or more resources to generate a second aggregated resource (see rejection of aggregating limitation of claim 1 and at least par. 69 and note that the aggregation is done repeatedly (i.e. second aggregated resource));
distributing, based on a second validator identifier, the second aggregated resource to one or more registered validators associated with the second validator identifier (pars. 25-27, 56-59, 73-76 disclose multiple identifiable registered models (i.e. registered validators) and a message bus for distributing as claimed);
validating the second aggregated resource to determine one or more other corresponding validation results (pars. 23, 29, 48, 77, 107);
retrieving, from the one or more registered validators, the one or more other corresponding validation results (pars. 23, 29, 48, 77, 107); and
writing the one or more other corresponding validation results to the results database (pars. 85, 90).
As per claim 5, Akyol as modified discloses The computer-implemented method of claim 1, further comprising: aggregating data of the one or more resources to generate a second aggregated resource; validating the second aggregated resource to determine one or more other corresponding validation results; and writing the validation results to the results database (see at least fig. 4B wherein multiple separate models each receive and validate separate aggregated resources with results written to database).
As per claim 6, Akyol as modified discloses The computer-implemented method of claim 1, further comprising: fetching the data of the one or more resources (par. 23 discloses data fetched from kernel queues; pars. 66-68 disclose that the data is obtained).
As per claim 7, Akyol as modified discloses The computer-implemented method of claim 1, wherein the aggregating the data of the one or more resources is based on a resource request (par. 25 discloses that the agent sends packets to models based on received command/request which means aggregation is based on a resource request).
As per claim 10, Akyol as modified discloses The computer-implemented method of claim 1, wherein aggregating the data of the one or more resources comprises: accessing the one or more resources to retrieve the data; and aggregating the retrieved data to generate the aggregated resource (see rejection of claim 1 and at least pars. 66-68).
As per claim 11, Akyol as modified discloses The computer-implemented method of claim 10, wherein the one or more resources comprises a data source accessible using an application programming interface (API) (pars. 44-45, 123-125, fig.’s 7-8).
As per claim 12, Akyol as modified discloses The computer-implemented method of claim 1, wherein the aggregating the data of the one or more resources is based on an event trigger (see rejection of claim 1 and at least pars. 71, 79, 84, 91).
As per claim 13, Akyol as modified discloses The computer-implemented method of claim 1, further comprising: receiving, by a user interface and from a user, request for the aggregated resource (par. 99 wherein the manual administrator command is done by means of a “user interface”).
As per claim 15, Akyol as modified discloses The computing device claim 14, wherein the instructions, when executed by the one or more processors, further configure the computing device to write the validation results to a results database (pars. 85, 90). Analogous claim 20 is likewise rejected.
As per claim 16, Akyol as modified discloses The computing device claim 14, wherein the instructions, when executed by the one or more processors, further configure the computing device to: retrieve the validation results (pars. 23, 29, 48, 77, 107); and write the validation results to a results database (pars. 83, 85, 90).
As per claim 18, Akyol as modified discloses The computing device claim 14, wherein the one or more registered validators comprise one or more predefined validation rules, the validation results being determined based on the one or more predefined validation rules (pars. 25-27, 56-59, 73-76).
As per claim 21, Akyol as modified discloses The method of claim 1, wherein the operational mode comprises one of: a provision mode that causes a resource change listener to retrieve the aggregated resource from a resource aggregator and provide the aggregated resource to the one or more registered validators (see rejection of claim 1 including Akyol, pars. 25-29, 77, and Bonar, par. 30-31); and a validator access mode that causes the one or more registered validators to retrieve the aggregated resource from the resource aggregator (see rejection above including Bonar, pars. 30-31).
Claims 8, 9 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Akyol as modified and further in view of Singh et al., Pub. No.: US 20210233045 A1, hereinafter Singh.
As per claim 8, Akyol as modified discloses The computer-implemented method of claim 1. Akyol as modified does not disclose, however, the combination in view of Singh obviates wherein a Lambda function is configured to distribute the aggregated resource to the one or more registered validators (See Singh, par. 44 and Akyol as cited in the rejection of claim 1).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of the cited references because Singh would have allowed Akyol to use lambda functions because “lambda functions … can allow computing resources for processing data to be used more efficiently, because it does not require computing resources to be continuously running. The serverless architecture can enable large volumes of data to be efficiently processed” (Singh, par. 44).
As per claim 9, Akyol as modified discloses the computer-implemented method of claim 8, wherein the aggregated resource is generated by the Lambda function (See Singh, par. 44 and Akyol as cited in the rejection of claim 1 and above-provided rationale to combine).
As per claim 17, Akyol as modified discloses The computing device claim 14. Akyol as modified does not disclose, however the combination in view of Singh obviates wherein a Lambda function is configured to validate the aggregated resource to determine one or more corresponding validation results (See Singh, par. 44 and Akyol as cited in the rejection of claim 1).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of the cited references because Singh would have allowed Akyol to use lambda functions because “lambda functions … can allow computing resources for processing data to be used more efficiently, because it does not require computing resources to be continuously running. The serverless architecture can enable large volumes of data to be efficiently processed” (Singh, par. 44).
Response to Arguments
Applicant's arguments filed 7/22/2026 have been fully considered. Regarding the prior art rejection, the Huang and Bonar references have been applied in view of claim amendments. The 35 USC 101 rejection is withdrawn in view of the argument that the claimed invention integrates the abstract idea into a practical application that provides an improvement to a technical field. It is noted that the claims themselves reflect the disclosed improvement. That is, the claims include the components or steps of the invention that provide the improvement described in the specification. MPEP § 2106.04(d)(1).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED HASAN whose telephone number is (571)270-5008. The examiner can normally be reached M-F 8am - 5 pm.
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, Boris Gorney can be reached at (571)270-5626. 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.
/SYED H HASAN/Primary Examiner, Art Unit 2154
