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 .
Acknowledgments
The application filed on 10/10/2025 is acknowledged.
Status of Claims
Claims 1-20 are pending.
Claims 1-20 are rejected.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) and/or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Specifically, Applicant claims priority under 35 U.S.C. 120 to U.S. application no. 18/189,952 filed on 03/24/2023 (parent of the instant application), and under 35 U.S.C. 119(e) to provisional application no. 63/404,868 filed on 09/08/2022 (grandparent of the instant application, and parent of U.S. application no. 18/189,952). The instant application is identified by Applicant in the Application Data Sheet (filed 10/10/2025) as a continuation-in-part of parent application no. 18/189,952.
The instant claims, namely, claims 1-20 of instant application no. 19/355,101, are not entitled to the benefit of the filing date of either of the above-indicated applications (namely, 18/189,952 and 63/404,868), because the above-indicated applications, whether considered singly or collectively, do not disclose the content of instant claims 1-20; the disclosure in the above-indicated applications does not comply with 35 U.S.C. 112(a) in respect of instant claims 1-20.1 Explanation is provided below.
Although parent application no. 18/189,952 and grandparent application no. 63/404,868 disclose part of the content of independent claims 1, 11 and 20, they do not disclose the entirety of independent claims 1, 11 and 20. For example,
provisional application no. 63/404,868 discloses:
streaming data sources, batch data sources, engineering streaming features, engineering batch features, integrated batch/streaming features, and scoring (Drawings, “Deposit_Fraud_Drawing.pdf,” slide 3 (page 4 of PDF as filed))
features (specification 001, 007 and 013)
nonprovisional application no. 18/189,952 discloses:
a list of features (Fig. 18) and description of the individual features in the list (specification 0088-0092)
receiving a processed action from a user via a mobile, ATM, or teller channel; inputting the processed action into a deposit fraud model; and generating, as output from the model, a risk indicator indicating the probability of unauthorized activity (Fig. 10; 0049-0054)
a trained machine learning model receives processed action data as inputs and generates a risk indicator as an output (Fig. 15; 0081)
However, parent application no. 18/189,952 and grandparent application no. 63/404,868 do not disclose or provide support under 35 U.S.C. 112(a) for at least the limitation of:
transmit [transmitting] a notification, via a network, to a user interface device when the updated unauthorized activity score differs from the initial unauthorized activity score by a predetermined enrichment threshold
as recited in independent claims 1, 11 and 20 of instant application no. 19/355,101. Since dependent claims 2-10 and 12-19 of instant application no. 19/355,101 depend from independent claim 1 or 11, it follows a fortiori that parent application no. 18/189,952 and grandparent application no. 63/404,868 do not disclose or provide support under 35 U.S.C. 112(a) for dependent claims 2-10 and 12-19.
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 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-20 are directed to a computer system, method, or non-transitory computer-readable medium, which are/is one of the statutory categories of invention. (Step 1: YES)
Claims 1, 11 and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite a computer system, method, and non-transitory computer-readable medium for determining whether a transaction is fraudulent.
For claims 1, 11 and 20 (claim 1 being deemed representative), the limitations (indicated below in bold) of:
one or more processors configured to:
determine, using a machine learning model, an initial unauthorized activity score for a processed action occurring on a transaction channel computing device;
receive streaming data from at least one streaming data source and batch data from at least one batch data source, wherein the streaming data and the batch data correspond to the processed action occurring on the transaction channel computing device;
process the streaming data to generate at least one engineered streaming feature corresponding to the processed action;
process the batch data to generate at least one engineered batch feature corresponding to the processed action;
generate an integrated feature based on the at least one engineered streaming feature and the at least one engineered batch feature;
calculate, using the machine learning model, an updated unauthorized activity score for the processed action based on the integrated feature; and
transmit a notification, via a network, to a user interface device when the updated unauthorized activity score differs from the initial unauthorized activity score by a predetermined enrichment threshold.
as drafted, constitute a process that, under the broadest reasonable interpretation, covers "certain methods of organizing human activity," specifically, "fundamental economic practices or principles" and/or "commercial or legal interactions." The Examiner notes that "fundamental economic practices" or "fundamental economic principles" describe concepts relating to the economy and commerce, including hedging, insurance, and mitigating risks, and "commercial interactions" or "legal interactions" include agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. MPEP 2106.04(a)(2)II.A.,B. If a claim limitation, under its broadest reasonable interpretation, covers "fundamental economic practices or principles" and/or "commercial or legal interactions," then it falls within the "certain methods of organizing human activity" grouping of abstract ideas. Accordingly, claims 1, 11 and 20 recite an abstract idea. (Step 2A - Prong 1: YES. The claims recite an abstract idea.)
This judicial exception is not integrated into a practical application. Claims 1, 11 and 20 recite the additional elements of a machine learning model; a transaction channel computing device; a network; and a user interface device (the foregoing recited in claims 1, 11 and 20); one or more processors configured to: (the foregoing recited in claim 1); at least one processor (the foregoing recited in claim 11); and a non-transitory computer-readable medium storing a set of instructions for identifying unauthorized activity using a machine learning model, the set of instructions comprising: one or more instructions that, when executed by at least one processor of a computing system, cause the computing system to: (the foregoing recited in claim 20), that implement the abstract idea. These additional elements are not described by the applicant and they are recited at a high level of generality (i.e., one or more generic computer elements performing generic computer functions, or generally linking the use of a judicial exception to a particular technological environment or field of use), such that they amount to no more than mere instructions to apply the exception using generic computer elements (namely, all of the additional elements), or such that they amount to no more than generally linking the use of a judicial exception to a particular technological environment or field of use (namely, a machine learning model). Accordingly, even in combination these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (Step 2A - prong 2: NO. The additional elements do not integrate the abstract idea into a practical application.)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a machine learning model; a transaction channel computing device; a network; and a user interface device (the foregoing recited in claims 1, 11 and 20); one or more processors configured to: (the foregoing recited in claim 1); at least one processor (the foregoing recited in claim 11); and a non-transitory computer-readable medium storing a set of instructions for identifying unauthorized activity using a machine learning model, the set of instructions comprising: one or more instructions that, when executed by at least one processor of a computing system, cause the computing system to: (the foregoing recited in claim 20), to perform the noted steps amount to no more than mere instructions to apply the exception using generic computer elements or generally linking the use of a judicial exception to a particular technological environment or field of use. Mere instructions to apply an exception using generic computer elements or generally linking the use of a judicial exception to a particular technological environment or field of use cannot provide an inventive concept ("significantly more"). Accordingly, even in combination, these additional elements do not provide significantly more. As such, claims 1, 11 and 20 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more.)
Dependent claims 2-10 and 12-19 are similarly rejected because they further define/narrow the abstract idea of independent claims 1, 11 and 20 as discussed above, and/or do not integrate the abstract idea into a practical application or provide an inventive concept such as would render the claims eligible, whether each is considered individually or as an ordered combination.
As for further defining/narrowing the abstract idea:
Dependent claims 3 and 13 merely further describe wherein the at least one streaming data source includes at least one of ….
Dependent claims 4 and 14 merely further describe wherein the at least one engineered streaming feature includes transaction history.
Dependent claims 5 and 15 merely further describe enriching the processed action by appending additional input data in real-time, wherein the additional input data includes the at least one engineered streaming feature.
Dependent claims 6 and 16 merely further describe wherein the at least one batch data source includes at least one of ….
Dependent claims 7 and 17 merely further describe wherein the at least one engineered batch feature includes at least one of account information, customer information, check information, or device information.
Dependent claims 8 and 18 merely further describe enriching the processed action by appending additional input data in real-time, wherein the additional input data includes the at least one engineered batch feature.
Dependent claims 9 and 19 merely further describe enriching the processed action by appending additional input data in real-time, wherein the additional input data includes the at least one engineered streaming feature and the at least one engineered batch feature.
Dependent claim 10 merely further describes enrich the processed action by appending additional input data in real-time, wherein the additional input data includes the integrated feature.
As for additional elements:
Dependent claims 2 and 12 recite "wherein the one or more processors further includes an operational data store." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Dependent claims 3 and 13 recite “a virtual terminal solution, a document processing system, an operations support function module, or a returned items processing system.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Dependent claim 5 recites "wherein the one or more processors is further configured to." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Dependent claims 6 and 16 recite a core banking system, a plastics processing system, a master data processing system, a returned items processing system, a document processing system, or an operations support function module. This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Dependent claim 8 recites "wherein the one or more processors is further configured to." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Dependent claim 9 recites "wherein the one or more processors is further configured to." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Dependent claim 10 recites "wherein the one or more processors is further configured to." This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Dependent claims 4, 7, 14, 15 and 17-19 do not recite any additional elements, and accordingly, for the reasons provided above with respect to the independent claims, are not patent eligible.
Therefore, dependent claims 2-10 and 12-19 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.
The factual inquiries set forth in Drapeau v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1-4, 6, 7, 11-14, 16, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Drapeau et al. (U.S. Patent Application Publication No. 2024/0161115 A1), hereafter Drapeau, in view of Duncan et al. (U.S. Patent Application Publication No. 2012/0203698 A1), hereafter Duncan.
Regarding Claims 1, 11 and 20
Drapeau teaches:
(claim 1) A computing system for identifying unauthorized activity using a machine learning model (0040) comprising: one or more processors (e.g., Fig. 5, 510, 0020) configured to: (Figs. 1-2, 110, 115, (0020-0023), Fig. 5 (0061-0069), 0040)
(claim 11) A computer-implemented method for identifying unauthorized activity using a machine learning model (0040), the method being performed by at least one processor (e.g., Fig. 5, 510, 0020) and comprising: (Figs. 1-2, 110, 115, (0020-0023), Fig. 5 (0061-0069), 0040)
(claim 20) A non-transitory computer-readable medium storing a set of instructions (e.g., 0062, 0065, 0081) for identifying unauthorized activity using a machine learning model (0040), the set of instructions comprising: one or more instructions that, when executed by at least one processor (e.g., Fig. 5, 510, 0020) of a computing system, cause the computing system to: (Figs. 1-2, 110, 115, (0020-0023), Fig. 5 (0061-0069), 0040, 0081)
…
receive streaming data from at least one streaming data source and batch data from at least one batch data source, wherein the streaming data and the batch data correspond to the processed action occurring on the transaction channel computing device; (Regarding receive streaming data from at least one streaming data source …, wherein the streaming data … correspond to the processed action occurring on the transaction channel computing device: 0030, 0035, Fig. 3, 303, 0047, Fig. 4, 401, “a request to perform a transaction” is received/detected (0035, 0047) by fraud detection system 115 of commerce platform 110 (0030); one of ordinary skill in the art understands that such request includes real-time (streaming) data, see also 0047 “For the transaction, payment information is provided by the customer user device to the merchant system in satisfaction of the transaction”; under broadest reasonable interpretation, Drapeau’s real-time transaction data teaches streaming data2; regarding receive … batch data from at least one batch data source, wherein … the batch data correspond to the processed action occurring on the transaction channel computing device: 0026-0027, 0031-0034 “The one or more batch features are historical features that are pre-identified using historical transaction data over a period of time. The one or more batch features also include features that correspond to disparate data sources that are expensive to compute online.” (0026); “the batch features may be computed based [sic, on an] aggregation of a batch of historical data.” (0031, 0032); “The batch features may also include features that correspond to disparate data sources that are too expensive to compute online. For example, the batch features may also include merchant statistics, which may include statistic information for every merchant that updates every day from multiple data sources. The batch features may be used to join multiple data sources in a way which is too computationally intensive to do in a short period of time online. For example, the batch features may be computed based on different data tables from different data sources. The different data tables may include data about cardholders, data about merchants, data about transactions, etc. The different data tables from different data sources may be joined together to generate the batch features. For example, some merchants may have a list of trusted customers or have an allow list, the batch features may be generated based on the allow list to help to decide that certain transactions are not risky, e.g., for other merchants.” (0034) – one of ordinary skill in the art understands that (in order for the system, e.g., 115, to generate the batch features) the data here mentioned, from which the batch features are generated, is received (by the system, e.g., 115) from the data sources (e.g., merchants) here mentioned; regarding the transaction channel computing device: 0020-0023, 0047 the “customer user device” teaches the transaction channel computing device)
process the streaming data to generate at least one engineered streaming feature corresponding to the processed action; (0035 “At processing block 304, one or more real time (streaming) features corresponding to the transaction may be determined. The one or more real time features may be computed online based on current data (streaming data) of a current session.”, 0048, 0012)
process the batch data to generate at least one engineered batch feature corresponding to the processed action; (0032 “The one or more batch features are historical features that are pre-identified using historical transaction data [batch data] over a period of time. … the batch features may be computed based [sic, on an] aggregation of a batch of historical data. … The batch features may be computed based on historical data for the latest 10 sessions of the transaction.”; 0049-0050, 0036-0037)
generate an integrated feature based on the at least one engineered streaming feature and the at least one engineered batch feature; (0013 “Combined features [integrated feature] based on both the batch features and the real time feature may be generated. For example, the combined features may represent the difference between the user's typical behavior [batch feature] and the behavior on the current session in real time [real-time/streaming feature].”; 0028 “a combined feature generator 216 to generate one or more combined features based on the one or more real time features and the one or more batch features.”; 0031 “one or more combined features based on a combination of the real time features and the batch features may be constructed or generated”; Fig. 3, 308, 0039 “one or more combined features based on both the batch features and the real time feature may be generated. … For example, … [a] combined feature Z score” (see 0039 for details regarding the combined feature Z score); 0054 “generate one or more combined features that correspond to the combination of the one or more real time features and the one or more batch features. In one embodiment, the combined features may represent a difference between the historical behavior of the customer and the behavior of the customer in real time”; 0043, 0056)
calculate, using the machine learning model (0040), an … unauthorized activity score for the processed action based on the integrated feature; and (0028 “a fraud probability score unit to determine a fraud probability score [unauthorized activity score] of the transaction based on the one or more real time features, the one or more batch features and the one or more combined features.”; (see also 0031 “The detecting model may evaluate whether the payment is fraudulent based on the combination of the real time features and the batch features”); Fig. 3, 310, 0040 “The fraud probability score may be determined based on the real time features, the batch features and the combined features using a machine learning model.”; 0055 “determine a fraud probability score based on the combination of the one or more real time features and the one or more batch feature”)
transmit a notification, via a network, to a user interface device when the updated unauthorized activity score … a predetermined enrichment threshold. (0029, Fig. 3, 312, 314, 0041 “At block 312, a potential fraud is determined based on the fraud probability score. For example, determination that the payment within the transaction is potentially fraudulent is determined in response to the fraud probability score being higher than a predetermined threshold.”, 0042 “At block 314, one or more remediation actions are taken in response to determining potential fraud within the transaction. For example, the one or more remediation actions may include blocking the transaction, flagging the transaction as potentially fraudulent, or requiring additional authentication action to be performed by one of the transaction parties.” – note that requiring additional authentication action to be performed by one of the transaction parties entails transmitting a notification to one of the parties; Fig. 4, 404, 405, 0052-0055, 0057-0058 teach content similar to that of Fig. 3, 312, 314, 0041-0042)
As indicated above, Drapeau teaches calculating, using the machine learning model, an unauthorized activity score for the processed action based on the integrated feature. However, Drapeau does not explicitly disclose determining, using a machine learning model, an initial unauthorized activity score for a processed action occurring on a transaction channel computing device, and, therefore, does not explicitly disclose that the unauthorized activity score calculated based on the integrated feature is “updated.”
Again, as indicated above, Drapeau teaches transmitting a notification, via a network, to a user interface device when the updated unauthorized activity score exceeds a predetermined enrichment threshold. Drapeau also teaches that the integrated feature may be a difference between a streaming feature and a batch feature. However, Drapeau does not explicitly disclose transmitting a notification, via a network, to a user interface device when the updated unauthorized activity score differs from the initial unauthorized activity score by a predetermined enrichment threshold.
Nonetheless, Duncan remedies these deficiencies of Drapeau. Duncan teaches the claim language not taught by Drapeau as well as additional claim language providing the context for the claim language not taught by Drapeau. Specifically, Duncan teaches:
determine, using a machine learning model, an initial unauthorized activity score for a processed action occurring on a transaction channel computing device; (claim 1 “a) … a first transaction score”; 0009 “first transaction score”; 0015; 0036 “the last evaluation or within a predetermined amount of time”; 0043-0047 and 0050 (glossary of relevant terminology providing clarification); 0084 “In step 112 [Fig. 4], the delta trigger may evaluate a first transaction score associated with the current transaction”; 0097 “a transaction score of the current transaction”; regarding occurring on a transaction channel computing device: 0062, client computer 2050 (Fig. 1) or mobile device)
calculate, using the machine learning model, an updated unauthorized activity score for the processed action …; (claim 1 “b) … a second transaction score”; 0009 “second transaction score”; 0015; 0036; 0043-0047 and 0050 (glossary of relevant terminology providing clarification); 0084 “In step 112 [Fig. 4], the delta trigger may evaluate a first transaction score associated with the current transaction and a second score since the last refresh was set. … The last refresh may be the previous transaction or the last time a score was provided.” Thus, where the case is a refresh case, the “second score” (0084) can be “the last time a score was provided” (0084), that is, the last time a score was provided in the same (fraud analysis process of the) existing (same) transaction case. Thus, the second score can be an updated score for the same transaction (an updated unauthorized activity score for the processed action). That the second score is for the same transaction is further demonstrated by other, related portions of Duncan, as follows. As per 0081, 0083, Fig. 4, 101, 103, 105 the status of a case received at 101 is checked at 103, and the case can be determined to be a refresh case rather than a new case. A refresh case is an “existing transaction case in fraud analysis process” (0081). 0092-0094 provide further detail on examples of refresh cases. 0095 provides further clarification that a refresh case can be a case that is “not closed … and has been analyzed before” and is being refreshed for further analysis due to a new event / activity having occurred prior to the case being closed (as similarly described in 0093 “The refresh trigger may wake up the case's sleeping alert and a refresh will be performed which will then take the new data into consideration to determine if a change is required …”). Finally, as per 0097, with reference to Fig. 6, “when a transaction case is determined to not be closed (step 301), a transaction score delta may be determined based on a transaction score of the current transaction compared to a previous transaction score, and the transaction score delta Is [sic, is] checked whether it is greater than a transaction score delta threshold ….” Again, this “previous transaction score” can be a score previously calculated for the current transaction, as explained above with respect to 0084, 0081, 0083, 0092-0095. Note: under broadest reasonable interpretation, “unauthorized activity score for the processed action” refers to any such score used “for” the processed action (transaction), that is, any score used to determine whether the action is unauthorized (e.g., fraudulent). Thus, the score taught by the prior art is not required to be a score “of” (the particular transaction data of) the particular transaction. Rather, the claimed score covers a score that is being used to determine whether the particular transaction is fraudulent even if that score is not the score “of” the particular transaction. Based on this broadest reasonable interpretation, even in a case where Duncan’s “second transaction score”/”refresh score”/”previous transaction score” refers to a transaction score of a previous transaction, that score still teaches an updated unauthorized activity score for the processed action, because that score is still being used as a transaction score “for” the current transaction, that is, is still being used to determine whether the current transaction is fraudulent (i.e., in this case the transaction score of the previous transaction is being used as a transaction score for the current transaction))
transmit a notification, via a network, to a user interface device when the updated unauthorized activity score differs from the initial unauthorized activity score by a predetermined enrichment threshold. (Regarding when the updated unauthorized activity score differs from the initial unauthorized activity score by a predetermined enrichment threshold: claim 1 (b), c)), claim 8; 0009, 0015, 0036, 0043-0047 and 0050 (glossary of relevant terminology providing clarification), 0084 “In step 112 [Fig. 4], the delta trigger may evaluate a first transaction score associated with the current transaction and a second score since the last refresh was set. … The last refresh may be the previous transaction or the last time a score was provided. … If the transaction score delta between the second transaction score and the first transaction score exceeds a threshold transaction score delta, then the delta trigger may fire or be met.”; 0097 (with reference to Fig. 6) “when a transaction case is determined to not be closed (step 301), a transaction score delta may be determined based on a transaction score of the current transaction compared to a previous transaction score, and the transaction score delta Is [sic, is] checked whether it is greater than a transaction score delta threshold ….”; regarding transmit a notification, via a network, to a user interface device when …: 0009-0010, 0015, 0050, 0052, 0085 “If the delta threshold is exceeded, then the system may evaluate whether a block should be placed on the account. The current alert may then be terminated and a new alert created, as shown in step 113. The new alert may inform the system to leave a voice mail or engage in notification, or other actions, as shown by the dotted line back to step 106. In one embodiment of the invention, the consumer may be notified ….” 0098, claims 1 (g)), 2, 6)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified Drapeau's systems and methods for fraud detection using batch and streaming/real-time features, by incorporating therein these teachings of Duncan regarding determining if a transaction is fraudulent based on whether a delta/difference between an updated fraud score and an initial fraud score exceeds a threshold (specifically, substituting Duncan’s transaction score delta (see, e.g., 0009, 0015, 0036, 0084, 0085, 0097) for Drapeau’s fraud probability score (see, e.g., 0029, 0041)), because Duncan teaches that any of various criteria -- e.g., the transaction score delta, the immediate transaction score (which is equivalent or comparable to Drapeau’s fraud probability score), etc. -- may be used (e.g., compared with a threshold) as an effective/reliable criterion indicating fraud, and so while Drapeau uses a criterion equivalent or comparable to Duncan’s immediate transaction score, Duncan’s transaction score delta could be used instead of Drapeau’s fraud probability score, because this is merely a simple substitution of one known element for another to obtain predictable results. MPEP 2143.I.(B).
Regarding Claims 2 and 12
Drapeau in view of Duncan teaches the limitations of base claims 1 and 11 as set forth above. Duncan further teaches:
wherein the one or more processors further includes an operational data store. (0014 “the server computer may comprise a database to store transaction data associated with the transaction case in the database.”; 0060 “the server computer may be a database server”3)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified Drapeau's systems and methods for fraud detection using batch and streaming/real-time features, as modified by these teachings of Duncan regarding determining if a transaction is fraudulent based on whether a delta/difference between an updated fraud score and an initial fraud score exceeds a threshold, by incorporating therein these further teachings of Duncan regarding a server including a database, because this centralization of the database at the server would facilitate/streamline authorized access to the data, backup of the data, and protection of the data (preventing unauthorized access to the data).
Regarding Claims 3 and 13
Drapeau in view of Duncan teaches the limitations of base claims 1 and 11 as set forth above. Drapeau further teaches:
wherein the at least one streaming data source includes at least one of a virtual terminal solution, a document processing system, an operations support function module, or a returned items processing system. (Per 0012, 0035, 0047, Fig. 1 (see also 0002) one of ordinary skill in the art understands that the server computer system, e.g., 115 of 110 (Fig. 1), receives real-time (streaming) data of a current transaction from a merchant system; inasmuch as a merchant system such as taught by Drapeau (1) performs online card-not-present transactions (see 0047 “Such transactions, however, often occur between unknown parties, over a network between remote systems, etc.”) ,(2) supports payment transaction operations, and (3) processes returned items, a merchant system teaches a virtual terminal solution, an operations support function module, and a returned items processing system, respectively)
Regarding Claims 4 and 14
Drapeau in view of Duncan teaches the limitations of base claims 1 and 11 as set forth above. Drapeau further teaches:
wherein the at least one engineered streaming feature includes transaction history. (Per 0012-0013, 0031-0032, 0039, the real-time (streaming) features and the batch features represent the same data but different values of it, i.e., the real-time features represent current values of this data, whereas the batch features represent historical values of this data (the batch features may represent an aggregation of historical values, e.g., a mean value or the like); it is by virtue of this fact that it is possible to compare the real-time and batch features, and to determine the difference between real-time and batch features, see 0013 (“The batch features may be compared to the real time features to detect anomalies. … the combined features may represent the difference between the user's typical behavior and the behavior on the current session in real time”), 0039 (“The combined features may represent the difference between the user's typical behavior and the behavior on the current session in real time. For example, a combined feature, such as a Z score, may be generated based on one or more batch features, e.g., at least one of the mean value or the standard deviation of an attribute of a transaction [e.g., a mean over 10 transaction sessions (0032)], and a real time feature, e.g., a value of the attribute of the [current] transaction. … The combined feature Z score may be expressed as” the real time value of the attribute minus the mean value of the attribute, divided by the standard deviation of the attribute.). Therefore, although Drapeau does not elaborate on specific examples of the real-time (streaming) features, since the real-time features and the batch features represent the same data, it follows that the real-time features are the same, in terms of the type of data, as the batch features. Thus, the specific examples of the types of data that batch features can be (as taught, e.g., in 0033) are also examples of the types of data that real-time features can be. One of the specific examples of the types of data that batch features can be is “a number of fraudulent payment disputes associated with the card” (0033). This data type constitutes transaction history. Thus, since a real-time feature can be the same data type as a batch feature, it follows that since a batch feature can be “a number of fraudulent payment disputes associated with the card” (which is transaction history), so too a real-time feature can be “a number of fraudulent payment disputes associated with the card” (which is transaction history).)
Regarding Claims 6 and 16
Drapeau in view of Duncan teaches the limitations of base claims 1 and 11 as set forth above. Drapeau further teaches:
wherein the at least one batch data source includes at least one of a core banking system, a plastics processing system, a master data processing system, a returned items processing system, a document processing system, or an operations support function module. (0026, 0033-0034, 0036-0037 batch features are generated based on historical transaction data (e.g., transaction attributes, such as merchant id, credit card number) from various disparate data sources, including, e.g., merchant systems; inasmuch as a merchant system (1) processes credit card transactions, (2) supports payment transaction operations, and (3) processes returned items, a merchant system teaches a plastics processing system, an operations support function module, and a returned items processing system, respectively)
Regarding Claims 7 and 17
Drapeau in view of Duncan teaches the limitations of base claims 1 and 11 as set forth above. Drapeau further teaches:
wherein the at least one engineered batch feature includes at least one of account information, customer information, check information, or device information. (0033-0034, e.g., the various data related to payments/transactions (0033) teaches account information under broadest reasonable interpretation, and “data about cardholders” (0034) teaches customer information)
Claims 5, 8-10, 15, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Drapeau et al. (U.S. Patent Application Publication No. 2024/0161115 A1), hereafter Drapeau, in view of Duncan et al. (U.S. Patent Application Publication No. 2012/0203698 A1), hereafter Duncan, and further in view of Vitucci et al. (U.S. Patent Application Publication No. 2026/0024090 A1), hereafter Vitucci.
Regarding Claims 5 and 15
Drapeau in view of Duncan teaches the limitations of base claims 1 and 11 as set forth above. Drapeau does not explicitly disclose but Vitucci teaches:
wherein the one or more processors is further configured to enrich the processed action by appending additional input data in real-time, wherein the additional input data includes the at least one engineered streaming feature. (Per Abstract, 0052-0053, 0174, Vitucci teaches (real-time) reprocessing of declined payment transactions, including, per 0120, 0189, (real-time (synchronous)) enrichment of the incoming transaction payload (enrich the processed action by appending additional input data in real-time). Note that although, as per 0052-0053, the default assumption in Vitucci’s disclosure is real-time processing, non-real-time processing is also taught. Accordingly, ingestion/receipt of incoming transaction payloads occurs either as real-time streaming, see 0175 (“gRPC streams, or message queue ingestion (e.g., AMQP, Kafka)”), or as batch intake, see 0175 (RESTful JSON payloads), 0105 (“In certain implementations, Payment-Decline Intake API 815 may support batch submission of declined transactions, …”; note 0105 reflects an exception to the default assumption). (Likewise, enrichment can be performed in real-time or not, see 0120 (“synchronously or asynchronously”), 0189.) Per 0118-0128, the enrichment is performed by Data-Enrichment Layer 830 (Fig. 8). Per 0189-0198, the enrichment is performed by Data-Enrichment Layer 830 at data enrichment step 915 (Fig. 9) of a method of reprocessing a declined transaction. Per 0118-0128 and 0189-0198 (e.g., 0126, 0128, 0189, 0195), the enrichment process enriches the incoming transaction payloads with features. Since the incoming transaction payloads may be received as streaming data or as batch data, the features that are generated (engineered) and used to enrich the incoming transaction payloads (as per 0118-0128 and 0189-0198) may be either streaming features (i.e., features generated from streaming data) or batch features (i.e., features generated from batch data) (wherein the additional input data includes the at least one engineered streaming feature). Likewise, per 0192, features generated may be streaming features (i.e., features generated from streaming data) or batch features (i.e., features generated from batch data): “the system computes a set of behavioral and velocity features derived from historical system activity. For example, the number of distinct cards used with the same billing address over the past 24 hours, or the number of failed transactions from the same device fingerprint across all merchants within a trailing time window, may be included in the feature vector. These values [i.e., the foregoing features included in the feature vector] are typically computed [generated/engineered] using pre-aggregated [batch data] or stream-processed [streaming data] logs ….”) (wherein the additional input data includes the at least one engineered streaming feature). (Note, in Vitucci’s discussion of generating features and enriching the transaction payload with the generated features (0118-0128 and 0189-0198), Vitucci frequently speaks of various data that are being used as (and hence constitute) features, e.g., 0121-0123, 0127-0128, 0190-0191, 0193, and relatedly, Vitucci uses various alternative terminology that, under broadest reasonable interpretation, is deemed to teach features, e.g., “signals,” “fingerprints,” “attributes,” “context,” “patterns,” “indicators.”))
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified Drapeau's systems and methods for fraud detection using batch and streaming/real-time features, as modified by these teachings of Duncan regarding determining if a transaction is fraudulent based on whether a delta/difference between an updated fraud score and an initial fraud score exceeds a threshold, by incorporating therein these teachings of Vitucci regarding enriching an incoming transaction payload by appending feature data to it, because this ensures data alignment by keeping the features bound to the transaction (prevents mismatched features and transaction during fast processing), reduces latency/number of hops/number of database lookups by passing the combined payload (features and transaction) in a single operation, and simplifies logging, auditing and debugging (by providing a simplified/single data structure for features and transaction). Note, in Drapeau, the fraud determination is made by analysis of the features, and Drapeau does not indicate that the features at this stage are combined with (appended to) the transaction payload. Thus, the combination provides advantages to the arrangement that Drapeau discloses.
Regarding Claims 8 and 18
Drapeau in view of Duncan teaches the limitations of base claims 1 and 11 as set forth above. Drapeau does not explicitly disclose but Vitucci teaches:
wherein the one or more processors is further configured to enrich the processed action by appending additional input data in real-time, wherein the additional input data includes the at least one engineered batch feature. (Per Abstract, 0052-0053, 0174, Vitucci teaches (real-time) reprocessing of declined payment transactions, including, per 0120, 0189, (real-time (synchronous)) enrichment of the incoming transaction payload (enrich the processed action by appending additional input data in real-time). Note that although, as per 0052-0053, the default assumption in Vitucci’s disclosure is real-time processing, non-real-time processing is also taught. Accordingly, ingestion/receipt of incoming transaction payloads occurs either as real-time streaming, see 0175 (“gRPC streams, or message queue ingestion (e.g., AMQP, Kafka)”), or as batch intake, see 0175 (RESTful JSON payloads), 0105 (“In certain implementations, Payment-Decline Intake API 815 may support batch submission of declined transactions, …”; note 0105 reflects an exception to the default assumption). (Likewise, enrichment can be performed in real-time or not, see 0120 (“synchronously or asynchronously”), 0189.) Per 0118-0128, the enrichment is performed by Data-Enrichment Layer 830 (Fig. 8). Per 0189-0198, the enrichment is performed by Data-Enrichment Layer 830 at data enrichment step 915 (Fig. 9) of a method of reprocessing a declined transaction. Per 0118-0128 and 0189-0198 (e.g., 0126, 0128, 0189, 0195), the enrichment process enriches the incoming transaction payloads with features. Since the incoming transaction payloads may be received as streaming data or as batch data, the features that are generated (engineered) and used to enrich the incoming transaction payloads (as per 0118-0128 and 0189-0198) may be either streaming features (i.e., features generated from streaming data) or batch features (i.e., features generated from batch data) (wherein the additional input data includes the at least one engineered batch feature). Likewise, per 0192, features generated may be streaming features (i.e., features generated from streaming data) or batch features (i.e., features generated from batch data): “the system computes a set of behavioral and velocity features derived from historical system activity. For example, the number of distinct cards used with the same billing address over the past 24 hours, or the number of failed transactions from the same device fingerprint across all merchants within a trailing time window, may be included in the feature vector. These values [i.e., the foregoing features included in the feature vector] are typically computed [generated/engineered] using pre-aggregated [batch data] or stream-processed [streaming data] logs ….”) (wherein the additional input data includes the at least one engineered batch feature). (Note, in Vitucci’s discussion of generating features and enriching the transaction payload with the generated features (0118-0128 and 0189-0198), Vitucci frequently speaks of various data that are being used as (and hence constitute) features, e.g., 0121-0123, 0127-0128, 0190-0191, 0193, and relatedly, Vitucci uses various alternative terminology that, under broadest reasonable interpretation, is deemed to teach features, e.g., “signals,” “fingerprints,” “attributes,” “context,” “patterns,” “indicators.”))
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified Drapeau's systems and methods for fraud detection using batch and streaming/real-time features, as modified by these teachings of Duncan regarding determining if a transaction is fraudulent based on whether a delta/difference between an updated fraud score and an initial fraud score exceeds a threshold, by incorporating therein these teachings of Vitucci regarding enriching an incoming transaction payload by appending feature data to it, because this ensures data alignment by keeping the features bound to the transaction (prevents mismatched features and transaction during fast processing), reduces latency/number of hops/number of database lookups by passing the combined payload (features and transaction) in a single operation, and simplifies logging, auditing and debugging (by providing a simplified/single data structure for features and transaction). Note, in Drapeau, the fraud determination is made by analysis of the features, and Drapeau does not indicate that the features at this stage are combined with (appended to) the transaction payload. Thus, the combination provides advantages to the arrangement that Drapeau discloses.
Regarding Claims 9 and 19
Drapeau in view of Duncan teaches the limitations of base claims 1 and 11 as set forth above. Drapeau does not explicitly disclose but Vitucci teaches:
wherein the one or more processors is further configured to enrich the processed action by appending additional input data in real-time, wherein the additional input data includes the at least one engineered streaming feature and the at least one engineered batch feature. (Per Abstract, 0052-0053, 0174, Vitucci teaches (real-time) reprocessing of declined payment transactions, including, per 0120, 0189, (real-time (synchronous)) enrichment of the incoming transaction payload (enrich the processed action by appending additional input data in real-time). Note that although, as per 0052-0053, the default assumption in Vitucci’s disclosure is real-time processing, non-real-time processing is also taught. Accordingly, ingestion/receipt of incoming transaction payloads occurs either as real-time streaming, see 0175 (“gRPC streams, or message queue ingestion (e.g., AMQP, Kafka)”), or as batch intake, see 0175 (RESTful JSON payloads), 0105 (“In certain implementations, Payment-Decline Intake API 815 may support batch submission of declined transactions, …”; note 0105 reflects an exception to the default assumption). (Likewise, enrichment can be performed in real-time or not, see 0120 (“synchronously or asynchronously”), 0189.) Per 0118-0128, the enrichment is performed by Data-Enrichment Layer 830 (Fig. 8). Per 0189-0198, the enrichment is performed by Data-Enrichment Layer 830 at data enrichment step 915 (Fig. 9) of a method of reprocessing a declined transaction. Per 0118-0128 and 0189-0198 (e.g., 0126, 0128, 0189, 0195), the enrichment process enriches the incoming transaction payloads with features. Since (per, e.g., 0175) the incoming transaction payloads may be received as streaming data and/or4 as batch data, the features that are generated (engineered) and used to enrich the incoming transaction payloads (as per 0118-0128 and 0189-0198) may be both streaming features (i.e., features generated from streaming data) and batch features (i.e., features generated from batch data) (wherein the additional input data includes the at least one engineered streaming feature and the at least one engineered batch feature). Likewise, per 0192, features generated may be both streaming features (i.e., features generated from streaming data) and batch features (i.e., features generated from batch data): “the system computes a set of behavioral and velocity features derived from historical system activity. For example, the number of distinct cards used with the same billing address over the past 24 hours, or the number of failed transactions from the same device fingerprint across all merchants within a trailing time window, may be included in the feature vector. These values [i.e., the foregoing features included in the feature vector] are typically computed [generated/engineered] using pre-aggregated [batch data] or [i.e., and/or] stream-processed [streaming data] logs ….”) (wherein the additional input data includes the at least one engineered streaming feature and the at least one engineered batch feature). (Note, in Vitucci’s discussion of generating features and enriching the transaction payload with the generated features (0118-0128 and 0189-0198), Vitucci frequently speaks of various data that are being used as (and hence constitute) features, e.g., 0121-0123, 0127-0128, 0190-0191, 0193, and relatedly, Vitucci uses various alternative terminology that, under broadest reasonable interpretation, is deemed to teach features, e.g., “signals,” “fingerprints,” “attributes,” “context,” “patterns,” “indicators.”))
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified Drapeau's systems and methods for fraud detection using batch and streaming/real-time features, as modified by these teachings of Duncan regarding determining if a transaction is fraudulent based on whether a delta/difference between an updated fraud score and an initial fraud score exceeds a threshold, by incorporating therein these teachings of Vitucci regarding enriching an incoming transaction payload by appending feature data to it, because this ensures data alignment by keeping the features bound to the transaction (prevents mismatched features and transaction during fast processing), reduces latency/number of hops/number of database lookups by passing the combined payload (features and transaction) in a single operation, and simplifies logging, auditing and debugging (by providing a simplified/single data structure for features and transaction). Note, in Drapeau, the fraud determination is made by analysis of the features, and Drapeau does not indicate that the features at this stage are combined with (appended to) the transaction payload. Thus, the combination provides advantages to the arrangement that Drapeau discloses.
Regarding Claim 10
Drapeau in view of Duncan teaches the limitations of base claim 1 as set forth above. Drapeau further teaches:
wherein the one or more processors is further configured to enrich the processed action by appending additional input data in real-time, wherein the additional input data includes the integrated feature. (Per Abstract, 0052-0053, 0174, Vitucci teaches (real-time) reprocessing of declined payment transactions, including, per 0120, 0189, (real-time (synchronous)) enrichment of the incoming transaction payload (enrich the processed action by appending additional input data in real-time). Note that although, as per 0052-0053, the default assumption in Vitucci’s disclosure is real-time processing, non-real-time processing is also taught. Accordingly, ingestion/receipt of incoming transaction payloads occurs either as real-time streaming, see 0175 (“gRPC streams, or message queue ingestion (e.g., AMQP, Kafka)”), or as batch intake, see 0175 (RESTful JSON payloads), 0105 (“In certain implementations, Payment-Decline Intake API 815 may support batch submission of declined transactions, …”; note 0105 reflects an exception to the default assumption). (Likewise, enrichment can be performed in real-time or not, see 0120 (“synchronously or asynchronously”), 0189.) Per 0118-0128, the enrichment is performed by Data-Enrichment Layer 830 (Fig. 8). Per 0189-0198, the enrichment is performed by Data-Enrichment Layer 830 at data enrichment step 915 (Fig. 9) of a method of reprocessing a declined transaction. Per 0118-0128 and 0189-0198 (e.g., 0126, 0128, 0189, 0195), the enrichment process enriches the incoming transaction payloads with features. Regarding wherein the additional input data includes the integrated feature: 0123 “In some configurations, the system constructs hashed fingerprints derived from combinations of transaction attributes, such as customer email address, billing ZIP code, IP address, and card BIN. These fingerprints are used to query historical behavioral data across the platform or within merchant-specific scopes. The results of such queries may reveal patterns including prior transaction volumes, success and decline ratios, device re-use frequency, and deviations from typical geographic usage. These context signals are converted into structured data [features] and appended to the transaction payload.” – Under broadest reasonable interpretation, the “fingerprints” and/or the “attributes” are features; the “patterns” (results of historical behavioral data queried across the platform/merchants) are batch features; and the “context signals … converted into structured data” are features appended to the transaction to enrich the transaction. Since (per, e.g., 0175) the incoming transaction payloads may be received as streaming data and/or5 as batch data, the “fingerprints” and/or the “attributes” may be both streaming features (i.e., features generated from streaming data) and batch features (i.e., features generated from batch data). As per the explanation of 0123, the “context signals … converted into structured data” have been generated using/based on the “fingerprints,” “attributes,” and patterns, i.e., using/based on streaming features and batch features; therefore, the “context signals … converted into structured data” are features generated using/based on streaming features and batch features and hence are integrated features. (wherein the additional input data includes the integrated feature) (Note, in Vitucci’s discussion of generating features and enriching the transaction payload with the generated features (0118-0128 and 0189-0198), Vitucci frequently speaks of various data that are being used as (and hence constitute) features, e.g., 0121-0123, 0127-0128, 0190-0191, 0193, and relatedly, Vitucci uses various alternative terminology that, under broadest reasonable interpretation, is deemed to teach features, e.g., “signals,” “fingerprints,” “attributes,” “context,” “patterns,” “indicators.”))
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified Drapeau's systems and methods for fraud detection using batch and streaming/real-time features, as modified by these teachings of Duncan regarding determining if a transaction is fraudulent based on whether a delta/difference between an updated fraud score and an initial fraud score exceeds a threshold, by incorporating therein these teachings of Vitucci regarding enriching an incoming transaction payload by appending feature data to it, because this ensures data alignment by keeping the features bound to the transaction (prevents mismatched features and transaction during fast processing), reduces latency/number of hops/number of database lookups by passing the combined payload (features and transaction) in a single operation, and simplifies logging, auditing and debugging (by providing a simplified/single data structure for features and transaction). Note, in Drapeau, the fraud determination is made by analysis of the features, and Drapeau does not indicate that the features at this stage are combined with (appended to) the transaction payload. Thus, the combination provides advantages to the arrangement that Drapeau discloses.
Conclusion
The prior art made of record and not relied upon, as set forth in the accompanying Notice of References Cited (PTO-892), is considered pertinent to applicant's disclosure. Among the cited references:
Hoh (US-20210373914-A1) teaches batch to stream processing in a feature management platform, including retrieving first event data for a batch processing job, generating batch features from the batch data, when there is no more event data for batch processing then saving a maximum timestamp of the event data/feature data, handing off to a stream processing job that starts where the batch processing job left off based on the maximum timestamp (the maximum timestamp determines from which event data to start the stream processing job), retrieving second event data for the stream processing job (the second event data having timestamp greater than the maximum timestamp of the batch processing job), and generating stream features from the stream data, wherein the features are generated by applying a transform to event data, e.g., using a configuration file, which specifies which data sources to retrieve event data from, what type of transforms to perform in the event data, how far back to retrieve event data, where to provide the feature vectors, etc., wherein the features can include stateful features (aggregating data over time) and stateless features (using the latest-in-time value), and wherein the use of the maximum timestamp to determine from when to start retrieving the second event data serves both to prevent duplication of feature data and to process events without gaps between the first and second event data, and wherein the features can be feature vectors used to create and train a machine learning model. See e.g., Abstract, 0003, 0004, 0006, 0022, 0027, 0029, 0030, 0032-0034.
Dan (US-20250348783-A1) teaches a data store for feature engineering including receiving batch and streaming data; generating a preliminary set of calculated features from the batch and streaming data; receiving a request to score input data; based on the request, identifying a model and input features; using the preliminary calculated features, generating input features; applying the model to the input features to generate output features, wherein the feature engineering optimizes machine learning model performance by transforming raw data into meaningful features and selecting relevant features for a specific predictive task and model type. See, e.g., 0002-0006.
Chen (US-20190147430-A1) teaches customizing payment sessions with machine learning models, including receiving batch data and streaming data, generating features from the batch data, selecting batch features to be also used as features to be generated from the streaming data, and creating machine learning models using the features to predict fraud probabilities, see, e.g., Fig. 5.
Kaczynski (US-20220414541-A1) teaches a Feature Storage Manager, including batch features and online/real-time features (Fig. 18A), creating multiple feature sets (which may have different periodicity of aggregation of data for the feature (e.g., daily, hourly, monthly)), where a feature set can be deployed in batch or real-time for receiving the data (e.g., a database icon can indicate the feature set is deployed and evaluated in batch on a schedule, and line icons indicate that features are evaluated on real-time data on production streams), and combining one or more features (Fig. 21A, 2122).
Cho (US-20220188556-A1) teaches a method and apparatus that detects whether biometric information is spoofed, comprising combining a static feature and a dynamic feature by concatenating (or calculating a weighted sum of) an embedding vector corresponding to the static feature and an embedding vector corresponding to the dynamic feature, and a multi-stage decision logic / cascade score fusion process, including an early stage decision/score and a final decision score, and including determining a first score based on a first feature and a second score based on a second feature and fusing the first and second scores, and including making a decision as to spoofing based on score information based on combined feature information, thereby permitting a neural network to determine if biometric information is spoofed based on processing a relatively small amount of information, therefore conserving processing resources and time.
He (US-20160292163-A1) teaches proactive identification of content items for a member of a social network, including generating static features and dynamic features and merging them into a single set of features, generating feature affinity scores, and combining the feature affinity scores to determine an affinity score.
Du (US-20230095870-A1) teaches IoT security event correlation, wherein static and dynamic attributes (features) are aggregated/merged, and a similarity score is updated over time as additional security events are received, and if the score exceeds a threshold an alert is generated and remedial action is taken.
Yu (US-20210150534-A1) teaches a novel ensemble method for face recognition deep learning models, including inter alia determining two scores from two feature vectors, respectively, combining the scores to obtain an ensemble score, comparing the ensemble score to a threshold, and obtaining a prediction result based on the comparison.
McCormick (US-9652658-B1) teaches systems and methods of fingerprinting checks to reduce check fraud, comprising having a customer who is attempting to cash a check impress their fingerprint on the surface of the check being cashed, receiving a digital image of a surface of the check, where the digital image includes an image of the customer’s fingerprint; using the fingerprint image to determine an initial match score for the fingerprint; making changes to the fingerprint image; calculating a quality metric of the fingerprint image, the quality metric being a number based on the changes made to the fingerprint image; adjusting the initial match score based on the quality metric to create an adjusted match score; and presenting an alert when the adjusted match score exceeds an alert threshold.
Baker (US-20250342476-A1) teaches systems and methods for fraud controls for an automated transaction machine (ATM), comprising determining that one or more initial products (e.g., mircoloans) is valid by (1) comparing updated user account data, updated factors (i.e., factors associated with the user, which may include a user credit score, a user income, a user transaction history, and/or information associated with the first transaction), and/or a new set of generated products (e.g., at the time that the user accesses the ATM) with initial user account data, initial factors, and initial products and (2) determining whether a difference between the initial/updated account data, factors, and/or products satisfies an acceptability threshold (e.g., falls within an acceptable range of differing values, exceeds an acceptability threshold, sufficiently overlap, and/or otherwise are generated based on the same data); and responsive to determining that the one or more initial products is valid, presenting the initial products and performing a further transaction, or alternatively determining that the one or more initial products is invalid by comparing the new set of generated products with the initial products and determining whether the product difference does not satisfy the acceptability threshold or the like described above.
Bailey (US-9230066-B1) teaches a technique for assessing risk for third-party data collectors, comprising determining an initial value of a risk-based authentication factor for a transaction; determining a corroborating value from an independent information source to corroborate the initial value of the risk-based authentication factor; generating a collector risk score for the electronic device based on a difference between (i) the initial value of the risk-based authentication factor and (ii) the corroborating value obtained from the independent information source; receiving an authentication request to authenticate the user, the authentication request including a new value of the risk-based authentication factor; in response to the authentication request, authenticating the user based on (i) the new value of the risk-based authentication factor, (ii) the initial value of the risk-based authentication factor, and (iii) the corroborating value obtained from the independent information source; wherein authenticating the user includes: inputting (i) the new value of the risk-based authentication factor and (ii) the collector risk score into a risk score engine, and generating an aggregate risk score as an output of the risk score engine, the aggregate risk score indicating an overall level of risk that the user is fraudulent; providing an authentication result indicating (i) successful authentication when the aggregate risk score is less than a predetermined risk score threshold, and (ii) unsuccessful authentication when the aggregate risk score exceeds the predetermined risk score threshold; and further comprising wherein the risk score engine includes a collector risk score engine and a data risk score engine, the collector risk score engine being configured to produce the collector risk score, the data risk score being configured to produce a data risk score, the aggregate risk score being a combination of the collector risk score and the data risk score; wherein generating the aggregate risk score includes: producing the data-based risk score based on the new value of the risk-based authentication factor and the initial value of the risk-based authentication factor, and generating, as the aggregate risk score, a combination of the data risk score and the collector risk score, the aggregate risk score indicating an overall level of risk that the user is fraudulent; wherein generating the collector risk score for the electronic device includes: adjusting a configuration of the collector risk engine based on the corroborating value; wherein the collector risk score engine includes a Bayesian weight corresponding to the electronic device; and wherein adjusting the configuration of the collector risk score engine includes: increasing a value of the Bayesian weight when the difference between the initial value of the risk-based authentication factor and the corroborating value obtained from the independent information source is larger than a threshold difference, and decreasing a value of a Bayesian weight when the difference between the initial value of the risk-based authentication factor and the corroborating value obtained from the independent information source is smaller than a threshold difference.
Raman (US-20200242611-A1) and Liu (US-20200242610-A1) teach methods and apparatus for fraud detection comprising generating an initial fraud determination strategy based on features and including at least one rule, generating a modified fraud determination strategy based on features that may be different features, wherein the modified fraud determination strategy includes a second more expansive rule requiring that the output of a classifier exceed a threshold.
Anderson (US-20250029121-A1) teaches systems and methods for prioritizing fraud cases using artificial intelligence, comprising receiving a plurality of fraud cases where each fraud case is associated with transaction data and an initial priority score; determining an updated priority score for each fraud case based on the transaction data and case prioritization data, where the case prioritization data includes a set of rules developed using a machine learning model; assigning each fraud case to a queue; assigning at least one fraud case to a fraud agent responsive to determining that its updated priority score is at or above a threshold, by moving the at least one fraud case to a cache; receiving an input from the fraud agent regarding a disposition of the at least one fraud case; and restructuring the case prioritization data based on the input.
Austraat (US-20240232765-A1) teaches systems and methods for audio signal processing and dynamic natural language understanding, featuring dynamic risk scoring based on natural language understanding of unstructured data from various communication channels, comprising receiving a textual communication from a user, the textual communication comprising a first grouping of unstructured transcript data and a second grouping of unstructured transcript data; applying the first grouping of unstructured transcript data to one or more trained artificial intelligence models and based thereon identifying risk elements from the first grouping of unstructured transcript data; based on the identified risk elements, assigning an initial risk score that ranks inherent risk of the textual communication; applying the second grouping of unstructured transcript data to one or more trained artificial intelligence models and based thereon identifying additional risk elements from the second grouping of unstructured transcript data; dynamically adjusting the initial risk score to generate an aggregate risk score based on one or more additional risk elements identified; and performing a risk analysis on the textual communication, where the risk analysis includes comparing the risk score to a threshold, see, e.g., 0006, Figs. 10, 11.
Barry (“StreamMLOps: Operationalizing Online Learning for Big Data Streaming & Real-Time Applications”) teaches inter alia feature engineering for stream processing including engineering streaming features that include transaction history, for a use case of detecting credit card fraud.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS W PINSKY whose telephone number is (571) 272-4131. The examiner can normally be reached on 8:30 am - 5:30 pm ET.
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, Jessica Lemieux can be reached on 571-270-3445. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DOUGLAS W PINSKY/
Examiner, Art Unit 3626
1 Note: compliance with the best mode requirement of 35 U.S.C. 112(a) is not being considered in this regard, as it is not required in this regard.
2 One of ordinary skill in the art understands that Drapeau’s “real-time” transaction data and features are “streaming” transaction data and features. See, e.g., Maheshwari (“Lambda Architecture: Where Batch Meets Stream and Magic Happens”), e.g., p. 3 (“Stream Layer: Processes incoming data in real-time.”)
3 Note a database server is a server that includes a database, see Grasdal (MCSE (Exam 70-293) Study Guide:
Planning and Maintaining a Windows Server 2003 Network Infrastructure: Exam 70-293, Chapter 2 “Planning Server Roles and Server Security”), p. 68 (“Database servers are used to store and manage databases that are stored on the server …. A large number of the databases used in your organization can be kept on one server ….”)
4 As per 0255, “The term “or” is, unless indicated otherwise, non-exclusive, i.e., encompassing both “and” and “or.”” Therefore, inasmuch as Vitucci teaches the disjunction (namely, receiving incoming transactions as streaming “or” batch data) (e.g., 0175, 0192), Vittuci also teaches the conjunction (namely, receiving incoming transactions as streaming “and” batch data).
5 As per 0255, “The term “or” is, unless indicated otherwise, non-exclusive, i.e., encompassing both “and” and “or.”” Therefore, inasmuch as Vitucci teaches the disjunction (namely, receiving incoming transactions as streaming “or” batch data) (e.g., 0175, 0192), Vittuci also teaches the conjunction (namely, receiving incoming transactions as streaming “and” batch data).
Prosecution Insights