DETAILED ACTION
1. The present application, filed on or after March 13, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2.. An Amendment was filed June 26, 2026 (hereinafter “Amendment”) and has been entered into the record and fully considered. The Amendment was filed in response to a Non-Final Rejection dated March 27, 2026.
Despite the Amendment to the Claims and Applicant’s remarks, the Rejection under §103 as set forth in the Non-Final Rejection is hereby maintained. However, the Rejections to the Claims under §103 are on NEW GROUNDS necessitated by the Amendment.
Furthermore, in view of the Amendment, the Rejection under §101 is hereby WITHDRAWN. A brief explanation of eligibility is set forth below.
An explanation of the maintained Rejections and a response to Applicant’s arguments are set forth below. Please see the “Conclusion” section of this Action below for important information regarding responding to this Action.
No new IDS was filed in this Application.
NOTE: interviews are welcome at any stage of prosecution. Please use the AIR form, the link for which can be found at the end of this action, to schedule the interview.
Objection to the Claims:
Claim 1 is objected to as containing capital letters. At least the words “Obtaining” and “Generating” are capitalized. Inasmuch as a Claim should be written as a single sentence, capitalized words are inappropriate.
See MPEP §608.01(m).
Correction is required.
Brief Explanation of Eligibility:
As noted above, in view of the Amendment, the Rejection in the Non-Final Rejection is hereby WITHDRAWN.
Claim 1 is illustrative of the eligibility of the Claims.
The Claim now recites with specificity the detailed steps in the workflow of detecting fraud in connection with transaction data and related events. That is, the claimed method implements a microservices-based, event-driven architecture which is configured to generate a “combined standardized transaction data structure.”
This combined and standardized data structure is achieved – as recited specifically in the Claim – by parsing the transaction data using a configuration file and extracting information about the format of the transaction. These extracted details are then added as supplemental data to the transaction data and is also transformed – along with the transaction data – into the standardized transaction data structure.
Thus, in this and other ways, the Claim is now analogous to the Federal Circuit decision in Enfish. The Amendment serves to incorporate a practical application into the Claim which recites an abstract idea. That is, although Claim 1 may recite a judicial exception (i.e., an abstract idea), viewing the claim as a whole and as an ordered combination, it is not directed to an abstract idea because it recites additional limitations which integrate a practical application into the judicial exception.
These additional limitations are specifically recited in Claim 1 as set forth below and are summarized above.
This recited method and system greatly improves the technology of using microservices to detect fraud in an event-driven system. This improvement constitutes an improvement to the technology of event-driven architectures and solves the problems discussed at [0003] of Applicant’s specification.
The other independent claims recite essentially identical additional limitations as Claim 1 and are therefore eligible for the same reasons as set forth above. The respective dependent claims are also eligible by virtue of depending from eligible independent claims.
Accordingly, Claims 1 – 31 are eligible under 35 U.S.C. § 101.
Status of the Claims:
Claims 1 – 31are pending in this Application.
Independent Claims 1, 16, and 26 were amended in substantially identical fashion.
None of the dependent claims were amended.
Therefore, the following explanation of the maintained rejection with regard to Claim 1 is considered explanatory of the Rejection as a whole.
With regard to the Amendment:
Claim 1 was amended as follows:
PNG
media_image1.png
670
726
media_image1.png
Greyscale
PNG
media_image2.png
678
664
media_image2.png
Greyscale
PNG
media_image3.png
502
657
media_image3.png
Greyscale
PNG
media_image4.png
701
678
media_image4.png
Greyscale
PNG
media_image5.png
588
688
media_image5.png
Greyscale
Summary of the Amendment and Broadest Reasonable Interpretation:
Claim terminology is to be given its plain and ordinary meaning to a person of ordinary skill in the art, consistent with the specification. This is true, unless the terms are given a special meaning. See MPEP §2111.01
Here, no special meaning is detected, with the possible exception of the claim term “onramp.” However, it seems clear from the specification that this term refers to the mere ingesting of a transaction into the workflow defined by the Claim. See 0041.
The remaining terms appear – subject to further consideration – to be defined in the specification based on their plain and ordinary meaning.
With regard to §103:
Applicant’s amendments and arguments necessitated a new grounds of Rejection:
New Grounds of Rejection:
Claim Rejections - 35 USC § 103
3. 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.
Claims 1 – 31 are rejected under 35 U.S.C. §103 as being unpatentable over U.S. Patent Publication No. 2019/0236695 to McKenna et al. (hereinafter “McKenna”) in view of U.S. Patent Publication No. 2024/0154993 to Andruikhin et al. (hereinafter “Andruikhin”).
McKenna has been cited and explained in detail in prior Office Actions and should be familiar to Applicant.
Andruikhin is directly on point with the claims as amended. It is in the same field of endeavor: event-driven, transaction-driven, microservices for the detection of security risks.
The Title reads as follows: Scalable reporting system for security analytics
The Abstract reads:
“The disclosure includes systems and methodologies for managing and evaluating the security posture of microservices in software development environments. The system addresses the challenges of fragmented and time-consuming security management processes by providing a unified and automated approach. It includes an abstraction process that transforms and standardizes security data from multiple Application Security tools into a centralized platform. The abstraction process simplifies the complexity of managing security across diverse microservices and enables efficient risk assessment and mitigation strategies. By integrating historical data and leveraging forecasting analysis, the system predicts potential security risks and trends, facilitating proactive vulnerability identification and resolution. The system's automation capabilities reduce manual effort, minimize human error, and streamline the security management workflow. It promotes collaboration among development and security teams, enhances overall security, and contributes to the production of more secure and reliable software products..” (Emphasis Added)
Accordingly, McKenna in view of Andruikhin teaches the features of Claim 1, including the features newly added by way of the Amendment, as follows:
1. (Currently Amended) A computer-implemented method comprising: (See at least Andruikhin: Fig. 1)
obtaining, by a processor, transaction data from a transaction onramp, wherein the transaction data was published to the transaction onramp by a transaction source using a real-time service;
(See at least 0022, wherein “security-related” data is received by the system. Such data is considered to constitute the recited term “event.” Thus, see 0022 – 0028. See 0039 as to real time.)
generating, by the processor, a combined standardized transaction data structure based on analysis of the transaction data by: (See at least 0022 – 0023 relating to the abstraction and extraction process.)
parsing the transaction data to extract details of the transaction data using a configuration file that contains information about the format of the transaction data;
(See at least 0008 relating to a standardized format for the data within a centralized platform.)
adding to the extracted details of the transaction data one or more supplemental data elements obtained from the transaction source to form a supplemental transaction data element; and (See at least 0009 – 0013 wherein the collection of data from various sources is plainly taught.)
transforming the supplemental transaction data element into the combined standardized transaction data structure to comply with a standard-based data structure; (See at least 0038 – 0039)
obtaining, by the processor event data from an event hub, the event data including: the transaction data, obtained from the transaction onramp; one or more events, published to the event hub from an event source by an event emitter; and one or more previously generated composite risk signals;
(See at least 0023 as to a centralized hub that receives the data – i.e. which acts as an “onramp” for the event and transaction data. See 0047 and 0083 as to an event-driven architecture and allows for real time analysis.
wherein the event data is obtained by a plurality of microservices, wherein each microservice from the plurality of microservices is configured to carry out a single task corresponding to a single event, wherein at least a first microservice and a second microservice of the plurality of microservices form[[s]] a first microservice stack and at least a third microservice and a fourth microservice of the plurality of microservices form[[s]] a second microservice stack, wherein the first microservice stack[[s]] supports a first type of software and the second microservice stack supports a second type of software;, the event data comprising: (See at least 0022 relating to diverse programming languages.)
the transaction data, obtained from the transaction onramp; one or more business events, which had been published to the event hub from an event source by an event emitter; and one or more previously generated composite risk signals; interpreting, by the processor, the event data obtained by the plurality of microservices with a plurality of topic listeners by: (See at least 0010 and 0025 as to the risk scores – i.e. risk signals – generated by the system. See also 0045 – 00465.)
creating or updating one or more composite risk signals based on an analysis of the event data by: (See at least McKenna, as explained in previous Actions, as to composite or combined risk or fraud scores.)
analyzing the event data using one or more internal logic rules to determine if the one or more composite risk signals need to be triggered or updated; (See at least 0089 as to internal rules. See also 0034 as to a “policy database” that houses security policies.)
storing the event data for enrichment [[of]] by retrieving additional data related to at least one of a party, an account, a device, or an entity from a high-performance cache; forming a plurality of discrete source signals based on the event data; and (See at least 0033 as to metadata about the microservices.)
aggregating the plurality of discrete source signals to create or update the one or more composite risk signals; (See at least McKenna as explained in prior Actions as to combined or composite risk signals or scores.)
generating, by the processor, one or more additional risk signals using machine learning based on the combined standardized transaction data structure, the one or more composite risk signals, and the event data; (See at least McKenna and Andruikhin: 0010)
obtaining, by the processor, one or more policy evaluation and execution results from a policy management module; (See at least 0031)
obtaining, by the processor, historic transaction data from a historical activities log; generating, by the processor, a heuristic behavior profile using one or more heuristic analysis methods, based on the historical transaction data; (See at least 0013)
assigning, by the processor, a fraudulent transaction probability score, using a decision engine, wherein the decision engine assigns the fraudulent transaction probability score based on inputs including: comprising:
the combined standardized transaction data;
the one or more composite risk signals;
the one or more additional risk signals;
the one or more policy evaluation and execution results; and the heuristic behavior profile; (See at least 0046 and many other teachings in Andruikhin relating to generating scores. A person of ordinary skill in the art would readily understand that such scores can be based on a combination of various types of data and metadata.)
generating, by the processor, a detection event based on the fraudulent transaction probability score; (See at least 0035 as to an alerting module.)
providing, by the processor, the detection event to the event hub as additional event data; and generating, by the processor, a transaction alert, indicating that a fraudulent activity has occurred, based on the detection event. (See at least 0042.)
Therefore, it would have been obvious to one of ordinary skill in the relevant art at the time of filing the claimed invention to have modified the combined or aggregated risk scoring system of McKenna with the many teachings of a standardized data structure or format features of Anduikhin. The motivation to do so comes from McKenna. It teaches, as set forth in previous Actions, that fraud scores can be generated from combined and aggregated data sources. It would greatly enhance the efficiency and accuracy of the system of McKenna to add the microservices security features of Andruikhin.
Therefore, the Rejection of Claim 1 and similar independent Claims is maintained. The Rejection of the dependent Claims is also maintained based at least on McKenna for the same reasons as set forth in prior Actions.
Response to Arguments
4. Applicant's arguments set forth in the Remarks section of the Amendment have been fully considered but they are not persuasive.
With regard to section 101 rejection, Applicant’s arguments are persuasive and that Rejection has been withdrawn as set forth above.
With regard to §103:
Applicant’s arguments with respect to the Rejections under §103 are moot in view of the new grounds of Rejection.
Conclusion
5. Applicant should carefully consider the following in connection with this Office Action:
A. Finality
THIS ACTION IS MADE FINAL. Applicant’s amendments to the Claims necessitated the new grounds of Rejection. See MPEP § 706.07. 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 date of this final action.
B. Search and Prior Art
The search conducted in connection with this Office Action, as well as any previous Actions, encompassed the inventive concepts as defined in the Applicant’s specification. That is, the search(es) included concepts and features which are defined by the pending claims but also pertinent to significant although unclaimed subject matter. Accordingly, such search(es) were directed to the defined invention as well as the general state of the art, including references which are in the same field of endeavor as the present application as well as related fields (e.g. the use of a microservices event-driven architecture to detect fraud). Indeed, there is a plethora of prior art in these fields.
Therefore, in addition to prior art references cited and applied in connection with this and any previous Office Actions, the following prior art is also made of record but not relied upon in the current rejection:
U.S. Patent Publication No. 2022/0070279 to Pang et al. This reference relates to the concept of using microservices in the detection of fraud.
U.S. Patent Publication No. 2024/0338439 to Golkar et al. This reference relates to the concept of an event-driven fraud detection system.
U.S. Patent Publication No. 2024/0144275 to Ammatanda et al. This reference relates to the concept of a microservices depot.
U.S. Patent Publication No. 2019/0333069 to Noble et al. This reference relates to the concept of microservices.
C. Responding to this Office Action
In view of the foregoing explanation of the scope of searches conducted in connection with the examination of this application, in preparing any response to this Action, Applicant is encouraged to carefully review the entire disclosures of the above-cited, unapplied references, as well as any previously cited references. It is likely that one or more such references disclose or suggest features which Applicant may seek to claim. Moreover, for the same reasons, Applicant is encouraged to review the entire disclosures of the references applied in the foregoing rejections and not just the sections mentioned.
D. Interviews and Compact Prosecution
The Office strongly encourages interviews as an important aspect of compact prosecution. Statistics and studies have shown that prosecution can be greatly advanced by way of interviews. Indeed, in many instances, during the course of one or more interviews, the Examiner and Applicant may reach an agreement on eligible and allowable subject matter that is supported by the specification.
Interviews are especially welcomed by this examiner at any stage of the prosecution process. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool (e.g. TEAMS).
To facilitate the scheduling of an interview, the Examiner requests the use of the AIR form as follows:
USPTO Automated Interview Request http://www.uspto.gov/interviewpractice.
Other forms of interview requests filed in this application may result in a delay in scheduling the interview because of the time required to appear on the Examiner's docket. Thus, the use of the AIR form is strongly encouraged.
E. Communicating with the Office
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM BUNKER whose telephone number is (571)272-0017. The examiner can normally be reached on M - F 8:30AM - 5:30PM, Pacific.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abhishek Vyas, can be reached at 571-270-1836. Information regarding the status of an application, whether published or unpublished, may be obtained from the “Patent Center” system. For more information about the Patent Center system, https://patentcenter.uspto.gov/
/William (Bill) Bunker/
U.S. Patent Examiner
AU 3691
william.bunker@uspto.gov
(571) 272-0017
August 28, 2026
/ABHISHEK VYAS/Supervisory Patent Examiner, Art Unit 3691
Prosecution Insights