Detailed Action
Claims 1, 3-12, and 14-22 are pending and are examined.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2025-12-22 has been entered.
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 .
Status of Claims
Claims 1, 9, 12, 18, and 20 are currently amended.
Claims 21 and 22 are new.
Claims 2 and 13 are cancelled.
Response to Remarks
35 U.S.C. § 101
The applicant representative asserts “Claim 1 is directed to improving the functioning of data anomaly detection technology. As described at paragraph [0030] of the Specification, it is beneficial in real-time fraud detection systems to useful to process authentication requests in a more efficient manner and without increasing network traffic and processing load. When a computer system needs to process a large number of rules in in the context of a real time authentication request, the computer system may experience a delay in processing the request given the system has a limited amount of bandwidth processing power. The recitations of Claim 1 solve this problem by utilizing pattern recognition to generate rules for detecting potentially fraudulent requests transmitted in real-time via a payment processing system and then filtering the rules so that the overall number of rules executed for each request is reduced, and only the rules most likely to accurately identify anomalous requests are used (e.g., by reducing missed detections and/or false identification of transactions that are actually fraudulent). Because a fewer number of rules are used while maintaining the rules most likely to accurately detect anomaly, the computer system may more quickly process real time authentication requests using a given amount of bandwidth and processing power. Claim 1 therefore represents an improvement to computing technology itself.” (Applicant Arguments, 2025-12-22). Again, the office notes that the applicants ‘improved efficiency/reduced network traffic’ argument is not persuasive because the claim is results-oriented and does not recite a specific technical mechanism (e.g. particular data model, model architecture, protocol change, or resource-change technique) that achieves the asserted computing or networking improvement. Indeed, Applicant’s amendments to the previously presented claims have not overcome the current rejections. Accordingly, the current claims are rejected.
35 U.S.C. § 102 and § 103
Remark 1: Applicant argues “amended Claim 1 recites at least one processor configured to "compute one or more values associated with each of the plurality of rules, the one or more values corresponding to a strength of correlation between satisfaction of the rule by the corresponding transaction request and the corresponding transaction request including anomalous data," and "filter the plurality of rules based on one or more thresholds and on the one or more values associated with each of the plurality of rules to identify one or more rules associated with one or more values that meet the one or more thresholds." These recitations were not identified in the Office Action as being described in Gosset, and Applicant submits that, for the reasons presented during the interview, these recitations render Claim 1 allowable.” (Applicant Response, 2025-12-22).
Response to Remark 1: Examiner respectfully disagrees, as the cited reference (e.g. Gosset) still teaches the amended independent claims, as shown at least in paragraphs 37-38, 118-120, 123, 126, 130, and 149 of Gosset, and as further outlined in paragraph 43 of this action. Indeed, Gosset discloses an authentication platform that stores an authentication profile (e.g. rules) and collects authentication-request data across transactions, then analyzes the data using risk model/anchors/reason codes to identify cross-request relationships tied to suspicious/fraud-linked conditions and to generate quantitative risk outputs (e.g. risk score/categories/ that reflect the strength of those associations and are evaluated against thresholds. Using those threshold-based results and stored rules, the platform evaluates subsequent real-time authentication requests to flag potentially anomalous requests and transmits anomaly-indicating data (e.g. risk score/analysis/reason codes) to an external device. Accordingly, this contention is unpersuasive.
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-10:
Step 1
Claims 1-11, and 21-22 are directed to a computer-implemented authentication platform (i.e., machine, and manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 1 recites (i.e., sets forth or describes) an abstract idea of transaction authentication based on past transaction data. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. Claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
a memory device including an authentication profile; and
at least one processor coupled to the memory device, the at least one processor programmed to:
collect a plurality of authentication data from a plurality of transactions initiated by users attempting to perform a transaction over a computer network, wherein at least some of the transactions were fraudulent or compromised, and wherein the plurality of authentication data includes a plurality of authentication requests each including a plurality of data elements;
analyze the plurality of authentication data to detect a plurality of insights representing relationships between data elements of different authentication requests of the plurality of authentication requests;
generate a plurality of rules from the plurality of insights, each of the plurality of rules defining data elements identified as being associated with a likelihood of a corresponding transaction request including anomalous data;
compute one or more values associated with each of the plurality of rules, the one or more values corresponding to a strength of correlation between satisfaction of the rule by the corresponding transaction request and the corresponding transaction request including anomalous data;;
filter the plurality of rules based on one or more thresholds and on the one or more values associated with each of the plurality of rules to identify one or more rules associated with one or more values that meet the one or more thresholds; and
compare data elements of a plurality of subsequent authentication requests to the identified one or more rules to detect one or more potentially anomalous authentication requests from the plurality of subsequent authentication requests: and for each of the one or more potentially anomalous authentication requests, transmit data indicating the potential anomaly to at least one external computing device associated with the one or more potentially anomalous authentication requests.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 1 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 1, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 3-11 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claim 3 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of filtering transaction risk by user preference. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the at least one processor is further programmed to filter the plurality of rules further based on one or more user preferences.
Claim 4 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of determining risk from historical data. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas.
wherein the plurality of transactions are historical payment card transactions.
Claim 5 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of multiple transactions executed by a specific processor. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the plurality of transactions is associated with a single issuer processor.
Claim 6 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of transactions including a request for authentication. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the plurality of transactions are authentication requests.
Claim 7 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of determining fraud in a transaction. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas.
wherein the plurality of transactions includes whether or not the authentication requests were fraudulent.
Claim 8 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of accessing data. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the plurality of transactions are to access secure information over a computer network.
Claim 9 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of applying pattern recognition to transactions. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas.
wherein the plurality of insights each define a predefined relationship between (i) one or more parameters of an authentication request, and (ii) a likelihood of the authentication request including the one or more parameters being anomalous.
Claim 10 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of testing a new authentication request against existing rules. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas.
receive, in real-time, a current authentication request;
analyze the current authentication request based on the identified one or more rules; and
provide results of the analysis of the current authentication request.
Claim 11 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of adjusting transaction rules based on the outcome of an authentication request. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas.
receive a final outcome for the current authentication request; and
update the identified one or more rules based on the final outcome and the results of the analysis of the current authentication request.
Claim 21 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of claim 1. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas.
wherein the at least one processor is further configured to input the plurality of authentication data into a machine learning model configured output to the plurality of insights based on the plurality of authentication data, the machine learning model trained based on training data including (i) a plurality of previously processed authentication requests, and (ii) a status of each of the plurality of previously processed authentication requests as being anomalous or not anomalous.
Claim 22 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of claim 1. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas.
wherein the at least one processor is further configured to train the machine learning model based on the training data.
Claims 12-19:
Step 1
Claims 12-19 are directed to a computer-implemented method (i.e., process). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 12 recites (i.e., sets forth or describes) an abstract idea of transaction authentication based on past transaction data. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. Claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
A computer-implemented method for authenticating an online user, the method implemented on a computing device comprising a memory device coupled to at least one processor, and the method comprises:
collecting a plurality of authentication data from a plurality of transactions initiated by users attempting to perform a transaction over a computer network, wherein at least some of the transactions were fraudulent or compromised, and wherein the plurality of authentication data includes a plurality of authentication requests each including a plurality of data elements;
analyzing the plurality of authentication data to detect a plurality of insights representing relationships between data elements of different authentication requests of the plurality of authentication requests;
generating a plurality of rules from the plurality of insights, each of the plurality of rules defining data elements identified as being associated with a likelihood of a corresponding transaction request including anomalous data;
computing one or more values associated with each of the plurality of rules, the one or more values corresponding to a strength of correlation between satisfaction of the rule by the corresponding transaction request and the corresponding transaction request including anomalous data;
filtering the plurality of rules based on one or more thresholds and on the one or more values associated with each of the plurality of rules to identify one or more rules associated with one or more values that meet the one or more thresholds; and
comparing data elements of a plurality of subsequent authentication requests to the identified one or more rules to detect one or more potentially anomalous authentication requests from the plurality of subsequent authentication requests; and for each of the one or more potentially anomalous authentication requests, transmitting data indicating the potential anomaly to at least one external computing device associated with the one or more potentially anomalous authentication requests.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 12 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 12, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 14-19 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claim 14 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of filtering transaction risk by user preference. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the at least one processor is further programmed to filter the plurality of rules further based on one or more user preferences.
Claim 15 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of determining risk from historical data. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas.
wherein the plurality of transactions are historical payment card transactions.
Claim 16 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of multiple transactions. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas. The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the plurality of transactions is associated with a single issuer processor.
Claim 17 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of request authentication in based on the presence of fraud. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas.
wherein the plurality of transactions are authentication requests and wherein the plurality of transactions includes whether or not the authentication requests were fraudulent.
Claim 18 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of determining fraud based on pattern recognition. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas.
wherein the plurality of insights each define a predefined relationship between (i) one or more parameters of an authentication request, and (ii) a likelihood of the authentication request including the one or more parameters being anomalous.
Claim 19 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of determining the authenticity of a request based on preexisting rules. In other words, it recites limitations grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas.
receiving, in real-time, a current authentication request;
analyzing the current authentication request based on the identified one or more rules; and
providing results of the analysis of the current authentication request.
Claim 20:
Step 1
Claim 20 is directed to a non-transitory computer-readable medium (i.e., manufacture). Therefore, the claim falls within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 20 recites (i.e., sets forth or describes) an abstract idea of transaction authentication based on past transaction data. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. Claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
At least one non-transitory computer-readable storage media having computer-executable instructions embodied thereon for authenticating an online user, wherein when executed by at least one processor, the computer-executable instructions cause the at least one processor to:
collect a plurality of authentication data from a plurality of transactions initiated by users attempting to perform a transaction over a computer network, wherein at least some of the transactions were fraudulent or compromised, and wherein the plurality of authentication data includes a plurality of authentication requests each including a plurality of data elements;
analyze the plurality of authentication data to detect a plurality of insights representing relationships between data elements of different authentication requests of the plurality of authentication requests;
generate a plurality of rules from the plurality of insights, each of the plurality of rules defining data elements identified as being associated with a likelihood of fraud of a corresponding transaction request including anomalous data;
compute one or more values associated with each of the plurality of rules, the one or more values corresponding to a strength of correlation between satisfaction of the rule by the corresponding transaction request and the corresponding transaction request including anomalous data;
filter the plurality of rules based on one or more thresholds and on the one or more values associated with each of the plurality of rules to identify one or more rules associated with one or more values that meet the one or more thresholds; and
compare data elements of a plurality of subsequent authentication requests to the identified one or more rules to detect one or more potentially anomalous authentication requests from the plurality of subsequent authentication requests; and for each of the one or more potentially anomalous authentication requests, transmit data indicating the potential anomaly to at least one external computing device associated with the one or more potentially anomalous authentication requests.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 20 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 20, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-22 are rejected under 35 U.S.C. 102(a)(1) as lacking novelty in view of Gosset et al. (US 20190392450) (hereinafter “Gosset”).
As per Claim 1, 12, and 20, Gosset teaches:
An authentication platform for authenticating an online user, the authentication platform comprising: a memory device including an authentication profile; and at least one processor coupled to the memory device, the at least one processor programmed to: (“Described herein are computer systems such as authentication computer systems. As described herein, all such computer systems include a processor and a memory” (Para. 0062); “the authentication platform compares the RBA result data to a stored authentication profile. The authentication profile contains a plurality of rules for the processing of authentication requests.” (Para. 0037); “Method 900 includes storing 902 an authentication profile. The authentication profile contains a plurality of rules for the processing of authentication requests.” (Para. 0140); “A risk-based authentication enabled (RBA-enabled) directory server stores an authentication profile which includes rules for performing and routing authentication requests. The RBA-enabled directory server receives an authentication request message for a transaction” (Para. 0025; “The authentication profile contains a plurality of rules for the processing of authentication requests.” (Para. 0037); “The authentication platform includes a memory device and at least one processor coupled to the memory device.” (Para. 0008); “The authentication platform further generates, based at least in part on the extracted authentication data, risk-based authentication (RBA) result data that includes a risk score for the transaction. The authentication platform also determines that a risk of fraud in the transaction satisfies a risk threshold” (Para. 0008).
collect a plurality of authentication data from a plurality of transactions initiated by users attempting to perform a transaction over a computer network, wherein at least some of the transactions were fraudulent or compromised, and wherein the plurality of authentication data includes a plurality of authentication requests each including a plurality of data elements; (“Using 3DS 2 Protocol (or subsequent versions of the 3DS Protocol), payment networks see 100% of all authentication requests globally on all cards on their brands.” (Para. 0042); “The 3DS 2 Protocol (and subsequent versions of the 3DS Protocol) enables a market-wide level risk analysis of all transactions that reach directory server 510 . . . For example, a payment processor could indicate if a particular device is associated with fraud, and flag that device for issuers in future transactions. The issuer may then reject transactions involving that device or prompt for additional authentication (e.g., through two-factor authentication).” (Para. 0050); “The following Table 1 lists a number of the data elements that are used in the 3DS 2 Protocol for authentication. . . . Those of skill in the art will appreciate that the number of rich data elements could grow beyond those listed below (e.g., in future versions of the 3DS Protocol), and could include over one hundred and seventy data elements. . . The authentication data may also be divided by category, such as: transaction data (amount, currency, date, and time), device data (IP address, device info, and channel data), cardholder data (account number and shipping address), and merchant data (name, category, and country).” (Para. 0051); “The RBA methodology includes three components that work together to provide authentication of cardholders. First, the underlying data model is used to provide a basis for the authentication. The underlying data model may include 3DS data, which may include cardholder data, behavioral data, location data, merchant data, and device data. The underlying data model may also include interchange network data, such as, but not limited to, past risk scores, authentication approvals, authorization history, chargeback data, and fraud data.” (Para. 0044); “the RBA platform 34 provides enhanced meta-data collection to capture information, including meta-data from the payment transactions processed by the payment card system 20. The RBA platform 34 stores this meta-data to use to provide as historical data when performing an authentication process prior to performing an authorization process.” (Para. 0074); “Table 1 lists a number of the data elements that are used in the 3DS 2 Protocol for authentication. For example, at least some of these data elements may be included in the authentication data included in the AReq sent to directory server 510” (Para. 0051).
analyze the plurality of authentication data to detect a plurality of insights representing relationships between data elements of different authentication requests of the plurality of authentication requests, (“The measurement methodologies may include short term velocities and ratios, including measuring behavior consistency and changes, such as frequency, amount spent, time, location, and device.” (Para. 0045); “RBA allows issuers to examine every authentication request through transaction risk analysis, while focusing fraud prevention efforts on transactions that prevent the most risk. Further, RBA utilizes both behavioral and transactional inputs in conjunction with a risk engine to determine riskiness of a transaction. The RBA method of cardholder authentication dynamically calculates a risk assessment for any given e-commerce transaction in real time.” (Para. 0043); “The RBA methodology may then use the underlying data model and the measurement methodology in a rules engine. The rules engine may include thresholds for interpreting measurement results, rules for combining results of measurements, and rules for combining other data with models and measurements.” (Para. 0046); “For example, for the cardholder category, if RBA engine 612 determines that a shipping address for the transaction has been used with the PAN in past transactions and/or the shipping address is unchanged from prior transaction, RBA engine 612 may activate the shipping address anchor.” (Para. 0122); “The method also includes extracting the authentication data from the authentication request message. The method further includes generating, based at least in part on the extracted authentication data, risk-based authentication (RBA) result data that includes a risk score for the transaction.”. (Para. 0009); “the RBA result data generated by the RBA engine includes a risk score, a risk analysis, and at least one reason code. The risk score is a score representing a determined riskiness of the transaction, with lower scores indicating lower risk and higher scores indicating higher risk. In other words, the risk score represents a likelihood that the suspect cardholder (e.g., the person attempting to perform a transaction) is the legitimate cardholder having the privileges to use the payment card to perform a payment transaction. For example, the risk score may be represented by a number from 0-999 and/or by a risk threshold category from 0-19.”. (Para. 0033); “The risk analysis is a description of a level of risk corresponding to the risk score (e.g., low risk, medium risk, or high risk). Further the reason codes include one or more factors that influenced the risk score. In some embodiments, the reason codes are generated using reason code categories and anchors, as described herein. In some embodiments, the reason codes are affected by rules and/or a combination of the rules and the model”. (Para. 0034); “the authentication platform determines if the risk level is high risk. In the example embodiment, in the case of a high risk transaction, the authentication platform may deny the transaction. The authentication platform may transmit an authentication response (ARes) message including the denial to the 3DS server. The 3DS server may transmit the ARes message including the denial to the merchant, where the merchant determines whether or not to proceed with the authorization process. In these embodiments, where the merchant begins the authorization process after having received a denial, the transaction is considered to be merchant only authentication, where the merchant assumes the risk for the transaction.” (Para. 0039).
generate a plurality of rules from the plurality of insights, each of the plurality of rules defining data elements identified as being associated with a likelihood of fraud of a corresponding transaction request including anomalous data; (“The authentication profile contains a plurality of rules for the processing of authentication requests . . . issuer-provided risk level thresholds for the risk score and risk levels, decision making risk thresholds, and specialized rules (such as all cross-border transactions are to be submitted to the ACS).” (Para. 0037); “In some embodiments, the reason codes are generated based on a plurality of reason code categories and associated anchors” (Para. 0120); “For the merchant category, one or more anchors may be activated based fraud rates for the merchant, decline rates for the merchant, and non-cleared transaction rates for the merchant.” (Para. 0123); “The authentication profile contains a plurality of rules for the processing of authentication requests. In some embodiments, the authentication profile is provided by an issuer computing device associated with an issuer bank. Examples of the rules include, but are not limited to, how to proceed when the ACS is unavailable, information to include in the RBA, issuer-provided risk level thresholds for the risk score and risk levels, decision making risk thresholds, and specialized rules (such as all cross-border transactions are to be submitted to the ACS” (Para. 0037); “The RBA methodology may then use the underlying data model and the measurement methodology in a rules engine. The rules engine may include thresholds for interpreting measurement results, rules for combining results of measurements, and rules for combining other data with models and measurements.” (Para. 0046); “the authentication platform compares the risk score to one or more thresholds in the authentication profile to determine the risk level associated with the transaction. In other embodiments, the authentication platform compares the risk analysis, the reason codes, and/or any other combination of data from the RBA result data and potentially some or all of the authentication data to the authentication profile to determine the risk level associated with this transaction. For example, a risk score of 900 or less may be considered low risk, a risk score between 900 and 980 may be considered medium risk, and a risk score above 980 may be considered high risk. Those skilled in the art will appreciate that any suitable risk score thresholds and any number of risk levels may be used.”. (Para. 0038); “. . .in the case of a high risk transaction, the authentication platform may deny the transaction.” (Para. 0039); “The device used for the transaction. . . has been associated with a fraud event.” (Para 0128); “the reason codes include one or more factors that influenced the risk score” (Para. 0034).
compute one or more values associated with each of the plurality of rules, the one or more values corresponding to a strength of correlation between satisfaction of the rule by the corresponding transaction request and the corresponding transaction request including anomalous data; (“For example, the risk score may be represented by a number from 0-999 and/or by a risk threshold category from 0-19. In some embodiments, risks assessments that will be shared, such as through the authorization field of one or more messages will be quantified on a scale of 0-9. Those of skill in the art will appreciate that any suitable risk score may be used.” (Para. 0118); “For example, a risk score of 900 or less may be considered low risk, a risk score between 900 and 980 may be considered medium risk, and a risk score above 980 may be considered high risk. Those skilled in the art will appreciate that any suitable risk score thresholds and any number of risk levels may be used.” (Para. 0038); “The rules engine may include thresholds for interpreting measurement results, rules for combining results of measurements, and rules for combining other data with models and measurements.” (Para. 0046); “The risk score is a score representing a determined riskiness of the transaction, with lower scores indicating lower risk and higher scores indicating higher risk. In other words, the risk score represents a likelihood that the suspect cardholder (e.g., the person attempting to perform a transaction) is the legitimate cardholder having the privileges to use the payment card to perform a payment transaction. For example, the risk score may be represented by a number from 0-999 and/or by a risk threshold category.” (Para. 0118); “For example, if at least one anchor in the cardholder category is activated, a positive reason code (i.e., indicating relatively low risk) is generated. If, instead, at least one anchor in the cardholder category is activated and at least one anchor in the merchant category is also activated, a stronger positive reason code related to both categories is generated.” (Para. 0126); “By comparing the data points in each transaction, the risk model will indicate the amount of risk associated with each transaction based on the authentication data in the corresponding authentication requests. This allows the authentication platform 614 to analyze transactions when the ACS 512 is unavailable and perform authentication on these transactions to provide a response to the authentication request. Accordingly, the authentication platform 614 may determine that a received authorization request is substantially similar to a previous transaction that the ACS 512 scored at low risk. Thus allowing the authentication platform 614 to determine that the received transaction is low risk with a degree of certainty.” (Para. 0149)
filter the plurality of rules based on one or more thresholds on the one or more values associated with each of the plurality of rules to identify one or more rules associated with one or more values that meet the one or more thresholds; and (“In some embodiments, the authentication platform compares the risk score to one or more thresholds in the authentication profile to determine the risk level associated with the transaction.” (Para. 0038); “The RBA methodology may then use the underlying data model and the measurement methodology in a rules engine. The rules engine may include thresholds for interpreting measurement results, rules for combining results of measurements, and rules for combining other data with models and measurements.” (Para. 0046); “using an RBA-enabled directory server and RBA engine to perform RBA and filter the results to determine which authentications need to be forwarded to an ACS and to forward the results of the RBA to the ACS to enable the ACS to make an authentication decision.” (Para. 0060); “The 3DS Protocol (and subsequent versions of the 3DS Protocol) provides a number of benefits to cardholders, issuers, and merchants. It reduces risk of unauthorized transactions through an approach that incorporates a rich, comprehensive set of data to make authentication decisions. For cardholders, it provides a simple, secure, and familiar online authentication experience, regardless of payment channel or device. For issuers, it allows for “frictionless” authentication, in which an explicit cardholder step-up authentication is not required or performed. This enables more intelligent risk assessment decisions and the ability to selectively challenge the cardholder as needed.” (Para. 0047); “the authentication platform determines a risk level based on the RBA result data. If the risk level is low, the authentication platform embeds an indicator in the authentication response message indicating that the transaction is “fully authenticated.” (Para. 0054); “If the transaction is medium risk, the authentication platform may issue a step-up challenge to the cardholder”. (Para. 0040); “One goal of RBA is to minimize the number of transactions that require active (i.e., step-up) authentication, while keeping fraud to a minimum” (Para. 0049).)
compare data elements of a plurality of subsequent authentication requests to the identified one or more rules to detect one or more potentially anomalous authentication requests from the plurality of subsequent authentication requests: and for each of the one or more potentially anomalous authentication requests, transmit data indicating the potential anomaly to at least one external computing device associated with the one or more potentially anomalous authentication requests. (“Examples of the rules include, but are not limited to, how to proceed when the ACS is unavailable, information to include in the RBA, issuer-provided risk level thresholds for the risk score and risk levels, decision making risk thresholds.” (Para. 0037); “the authentication platform compares the risk score to one or more thresholds in the authentication profile to determine the risk level.” (Para. 0038); “RBA-enabled directory server 610 determines that the riskiness of the transaction is low by comparing at least one of the risk score and the risk analysis to a predetermined threshold.” (Para. 0130); “The RBA method of cardholder authentication dynamically calculates a risk assessment for any given e-commerce transaction in real time. The assessment can then be used to authenticate the cardholder in a frictionless manner.” (Para. 0043); “Transactions deemed safe or low risk are silently authenticated (i.e., so-called “frictionless” authentication), while higher risk transactions are subjected to step-up authentication.” (Para. 0047); “a payment processor could indicate if a particular device is associated with fraud, and flag that device for issuers in future transactions. The issuer may then reject transactions involving that device or prompt for additional authentication (e.g., through two-factor authentication).” (Para. 0050); “Transactions deemed safe or low risk are silently authenticated (i.e., so-called “frictionless” authentication), while higher risk transactions are subjected to step-up authentication. When a low risk transaction is silently authenticated, so much data has already been gathered that further authentication adds little to no value.” (Para. 0047); “The 3DS Protocol (and subsequent versions of the 3DS Protocol) provides a number of benefits to cardholders, issuers, and merchants. It reduces risk of unauthorized transactions through an approach that incorporates a rich, comprehensive set of data to make authentication decisions. For cardholders, it provides a simple, secure, and familiar online authentication experience, regardless of payment channel or device. For issuers, it allows for “frictionless” authentication, in which an explicit cardholder step-up authentication is not required or performed. This enables more intelligent risk assessment decisions and the ability to selectively challenge the cardholder as needed.” (Para. 0047); “the authentication platform determines a risk level based on the RBA result data. If the risk level is low, the authentication platform embeds an indicator in the authentication response message indicating that the transaction is “fully authenticated.” (Para. 0054); “If the transaction is medium risk, the authentication platform may issue a step-up challenge to the cardholder”. (Para. 0040); “One goal of RBA is to minimize the number of transactions that require active (i.e., step-up) authentication, while keeping fraud to a minimum” (Para. 0049).
As per Claim 3, Gosset teaches:
The authentication platform of Claim 1, wherein the at least one processor is further programmed to filter the plurality of rules furthur based on one or more user preferences. (“the RBA-enabled directory server provides a graphical user interface (GUI) to the regulators that provides an insight into fraud within their regulated market, and may allow the regulators to directly configure operational aspects of the RBA-enabled directory server, such as changing threshold values used in the conditional SCA process for their market. The GUI may allow the regulators to evaluate current performance of existing thresholds, displaying and comparing fraud data on transactions above or below the configured thresholds, such as the basis points of fraud lost during a particular period of time. The GUI may also allow regulators to evaluate potential threshold values, providing an estimate of fraud levels based on a set of prospective threshold values. As such, regulators may use such simulations to determine how they may set or change threshold value” (Para. 0029).; “the authentication profile may include regulator-imposed threshold values for risk categories or transaction threshold values for particular markets that define when SCA is mandated. The authentication profile is stored at the RBA platform, and can be accessed whenever a risk score is determined.” (Para. 0037);
As per Claim 4, Gosset teaches:
The authentication platform of Claim 1, wherein the plurality of transactions are historical payment card transactions. (“The RBA methodology includes three components that work together to provide authentication of cardholders. First, the underlying data model is used to provide a basis for the authentication. The underlying data model may include 3DS data, which may include cardholder data, behavioral data, location data, merchant data, and device data. The underlying data model may also include interchange network data, such as, but not limited to, past risk scores, authentication approvals, authorization history, chargeback data, and fraud data.”. (Para. 0044); “for authentication purposes, the authentication platform is capable of leveraging large volumes of historical transaction data for all transactions previously processed by the payment processing network” (Para. 0030);
As per Claim 5, Gosset teaches:
The authentication platform of Claim 4, wherein the plurality of transactions is associated with a single issuer processor. (“for authentication purposes, the authentication platform is capable of leveraging large volumes of historical transaction data for all transactions previously processed by the payment processing network (as compared to the relatively small number of transactions processed by a particular ACS).” (Para. 0030); “the authentication platform compares the RBA result data to a stored authentication profile. The authentication profile contains a plurality of rules for the processing of authentication requests. In some embodiments, the authentication profile is provided by an issuer computing device associated with an issuer bank.” (Para. 0037);
As per Claim 6, Gosset teaches:
The authentication platform of Claim 1, wherein the plurality of transactions are authentication requests. (“The authentication platform receives an authentication request message for a transaction involving a market regulated by a regulatory entity. The authentication request message includes authentication data and a transaction value. The authentication platform also extracts the authentication data from the authentication request message. The authentication platform further generates, based at least in part on the extracted authentication data, risk-based authentication (RBA) result data that includes a risk score for the transaction. The authentication platform also determines that a risk of fraud in the transaction satisfies a risk threshold established by the regulatory entity by evaluating the risk score relative to the risk threshold.”. (Para. 0008); “The RBA-enabled directory server receives an authentication request (AReq) message from a 3DS server.” (Para. 0032); “the authentication platform determines a risk level based on the RBA result data” (Para. 0054).
As per Claim 7, Gosset teaches:
The authentication platform of Claim 6, wherein the plurality of transactions includes whether or not the authentication requests were fraudulent. (“The method further includes generating, based at least in part on the extracted authentication data, risk-based authentication (RBA) result data that includes a risk score for the transaction. The method also includes determining that a risk of fraud in the transaction satisfies a risk threshold established by the regulatory entity by evaluating the risk score relative to the risk threshold. The method further includes determining that the transaction value is below a transaction limit set by the regulatory entity. The transaction limit identifies a threshold transaction value below which strong consumer authentication may be avoided for transactions satisfying the risk threshold.” (Para. 0009); “the RBA result data generated by the RBA engine includes a risk score, a risk analysis, and at least one reason code. The risk score is a score representing a determined riskiness of the transaction, with lower scores indicating lower risk and higher scores indicating higher risk. In other words, the risk score represents a likelihood that the suspect cardholder (e.g., the person attempting to perform a transaction) is the legitimate cardholder having the privileges to use the payment card to perform a payment transaction” (Para. 0033); “In the example embodiment, in the case of a high risk transaction, the authentication platform may deny the transaction. The authentication platform may transmit an authentication response (ARes) message including the denial to the 3DS server. The 3DS server may transmit the ARes message including the denial to the merchant, where the merchant determines whether or not to proceed with the authorization process” (Para. 0039).
As per Claim 8, Gosset teaches:
The authentication platform of Claim 1, wherein the plurality of transactions is to access secure information over a computer network. (“an authentication platform for authenticating an online user in a transaction without use of strong consumer authentication (SCA) is provided. The authentication platform includes a memory device and at least one processor coupled to the memory device.” (Para. 0016).; “the authentication platform determines a risk level based on the RBA result data. If the risk level is low, the authentication platform embeds an indicator in the authentication response message indicating that the transaction is “fully authenticated.” (Para. 0054); “The RBA-enabled directory server and the RBA engine facilitate evaluating transactions to determine when SCA is mandated, as described herein. The RBA-enabled directory server and the RBA engine may be operated, for example, by an interchange network (e.g., a payment processing network).” (Para. 0031).
As per Claim 9 and 18, Gosset teaches:
The authentication platform of Claim 1, wherein the plurality of insights each define a predefined relationship between (i) one or more parameters of an authentication request, and (ii) a likelihood of the authentication request including the one or more parameters being anomalous. (“Examples of the rules include, but are not limited to, how to proceed when the ACS is unavailable, information to include in the RBA, issuer-provided risk level thresholds for the risk score and risk levels, decision making risk thresholds.” (Para. 0037); “the authentication platform compares the risk score to one or more thresholds in the authentication profile to determine the risk level.” (Para. 0038); “RBA-enabled directory server 610 determines that the riskiness of the transaction is low by comparing at least one of the risk score and the risk analysis to a predetermined threshold.” (Para. 0130); “reduces risk of unauthorized transactions through an approach that incorporates a rich, comprehensive set of data to make authentication decisions.” (Para. 0016); “RBA methodology may use in the underlying data model in one or more measurement methodologies. The measurement methodologies may include short term velocities and ratios, including measuring behavior consistency and changes, such as frequency, amount spent, time, location, and device. The measurement methodologies may also include long term velocities and ratios, which include measurement of behavior and anomaly detection. The measurement methodologies may further include continuous measurement across the payment network.” (Para. 0045); “By comparing the data points in each transaction, the risk model will indicate the amount of risk associated with each transaction based on the authentication data in the corresponding authentication requests. This allows the authentication platform to analyze transactions when the ACS is unavailable and perform authentication on these transactions to provide a response to the authentication request. Accordingly, the authentication platform may determine that a received authorization request is substantially similar to a previous transaction that the ACS scored at low risk.” (Para. 0055); “the transaction fits within a typical behavioral and transaction pattern, and the shipping address has been used with the payment account number (PAN) and is the same as the last transaction. The cardholder buys a present to be delivered to his house. An example of a medium risk transaction may include, where the cardholder has a positive transaction history, is using an unknown device with no known association with the cardholder, the device is at a non-typical geolocation and IP address, but is typical behavioral, cardholder, and transaction pattern. For example, the cardholder is on travel and purchases Internet Access at a hotel. An example of a high risk transaction may include, where there are anomalous velocities detected with the cardholder in network, is using an unknown device with no known association with the cardholder, the device is at a non-typical geolocation and IP address, and there is anomalous behavior patterns detected” (Para. 0048).
As per Claim 10, Gosset teaches:
The authentication platform of Claim 1, wherein the at least one processor is further programmed to: receive, in real-time, a current authentication request; analyze the current authentication request based on the identified one or more rules; and provide results of the analysis of the current authentication request. (“The authentication platform receives an authentication request message for a transaction involving a market regulated by a regulatory entity. The authentication request message includes authentication data and a transaction value.” (Para. 0008); “The RBA-enabled directory server receives an authentication request (AReq) message from a 3DS server. The RBA-enabled directory server may evaluate the transaction to determine with which market(s) the transaction is associated (e.g., based on merchant, merchant bank, issuing bank, consumer, and so forth). If the transaction is associated with a regulated market that is configured for “conditional SCA” as described herein, then the RBA-enabled directory server compares the transaction value with the configured transaction value threshold set by the regulators of the associated market. If the transaction value is below the transaction value threshold, then the RBA engine evaluates the risk of the transaction using transaction data and other data available to the RBA-enabled directory server.” (Para. 0032); “the authentication platform determines a risk level based on the RBA result data. If the risk level is low, the authentication platform embeds an indicator in the authentication response message indicating that the transaction is “fully authenticated.” If the risk level is not low, the authentication platform embeds one or more indicators in the authentication response message indicating that the transaction is a merchant only transaction and that authentication was attempted.” (Para. 0054); “The risk analysis is a description of a level of risk corresponding to the risk score (e.g., low risk, medium risk, or high risk). Further the reason codes include one or more factors that influenced the risk score. In some embodiments, the reason codes are generated using reason code categories and anchors, as described herein. In some embodiments, the reason codes are affected by rules and/or a combination of the rules and the model. The RBA engine transmits the RBA result data to the RBA-enabled directory server.” (Para. 0034).
As per Claim 11, Gosset teaches:
The authentication platform of Claim 10, wherein the at least one processor is further programmed to: receive a final outcome for the current authentication request; and update the identified one or more rules based on the final outcome and the results of the analysis of the current authentication request. (“the authentication platform also compares the RBA result data to the authentication profile to determine the risk level associated with the transaction associated with the authentication request. In some embodiments, the authentication platform compares the risk score to one or more thresholds in the authentication profile to determine the risk level associated with the transaction. In other embodiments, the authentication platform compares the risk analysis, the reason codes, and/or any other combination of data from the RBA result data and potentially some or all of the authentication data to the authentication profile to determine the risk level associated with this transaction.” (Para. 0016); “The additional data included in the 3DS Protocol increases data exchange between merchants and issuers, and improves risk-based authentication (RBA) decisioning. RBA allows issuers to examine every authentication request through transaction risk analysis, while focusing fraud prevention efforts on transactions that prevent the most risk. Further, RBA utilizes both behavioral and transactional inputs in conjunction with a risk engine to determine riskiness of a transaction. The RBA method of cardholder authentication dynamically calculates a risk assessment for any given e-commerce transaction in real time. The assessment can then be used to authenticate the cardholder in a frictionless manner.” (Para. 0043); “The measurement methodologies may include short term velocities and ratios, including measuring behavior consistency and changes, such as frequency, amount spent, time, location, and device. The measurement methodologies may also include long term velocities and ratios, which include measurement of behavior and anomaly detection. The measurement methodologies may further include continuous measurement across the payment network.” (Para. 0045); “The authentication platform analyzes transactions that are authenticated by the ACS and compares these transactions with historical data to generate a risk model for each issuer. By comparing the data points in each transaction, the risk model will indicate the amount of risk associated with each transaction based on the authentication data in the corresponding authentication requests” (Para. 0055).
As per Claim 14, Gosset teaches:
The method of Claim 12 further comprising filtering the plurality of rules further based on one or more user preferences. (“the RBA-enabled directory server provides a graphical user interface (GUI) to the regulators that provides an insight into fraud within their regulated market, and may allow the regulators to directly configure operational aspects of the RBA-enabled directory server, such as changing threshold values used in the conditional SCA process for their market. The GUI may allow the regulators to evaluate current performance of existing thresholds, displaying and comparing fraud data on transactions above or below the configured thresholds, such as the basis points of fraud lost during a particular period of time. The GUI may also allow regulators to evaluate potential threshold values, providing an estimate of fraud levels based on a set of prospective threshold values. As such, regulators may use such simulations to determine how they may set or change threshold value” (Para. 0029).; “the authentication profile may include regulator-imposed threshold values for risk categories or transaction threshold values for particular markets that define when SCA is mandated. The authentication profile is stored at the RBA platform, and can be accessed whenever a risk score is determined.” (Para. 0037);
As per Claim 15, Gosset teaches:
The method of Claim 12, wherein the plurality of transactions are historical payment card transactions. (“The RBA methodology includes three components that work together to provide authentication of cardholders. First, the underlying data model is used to provide a basis for the authentication. The underlying data model may include 3DS data, which may include cardholder data, behavioral data, location data, merchant data, and device data. The underlying data model may also include interchange network data, such as, but not limited to, past risk scores, authentication approvals, authorization history, chargeback data, and fraud data.”. (Para. 0044); “for authentication purposes, the authentication platform is capable of leveraging large volumes of historical transaction data for all transactions previously processed by the payment processing network” (Para. 0030);
As per Claim 16, Gosset teaches:
The method of Claim 15, wherein the plurality of transactions is associated with a single issuer processor. (“for authentication purposes, the authentication platform is capable of leveraging large volumes of historical transaction data for all transactions previously processed by the payment processing network (as compared to the relatively small number of transactions processed by a particular ACS).” (Para. 0030); “the authentication platform compares the RBA result data to a stored authentication profile. The authentication profile contains a plurality of rules for the processing of authentication requests. In some embodiments, the authentication profile is provided by an issuer computing device associated with an issuer bank.” (Para. 0037);
As per Claim 17, Gosset teaches:
The method of Claim 12, wherein the plurality of transactions are authentication requests and wherein the plurality of transactions includes whether or not the authentication requests were fraudulent. (“The authentication platform receives an authentication request message for a transaction involving a market regulated by a regulatory entity. The authentication request message includes authentication data and a transaction value. The authentication platform also extracts the authentication data from the authentication request message. The authentication platform further generates, based at least in part on the extracted authentication data, risk-based authentication (RBA) result data that includes a risk score for the transaction. The authentication platform also determines that a risk of fraud in the transaction satisfies a risk threshold established by the regulatory entity by evaluating the risk score relative to the risk threshold.”. (Para. 0008); “The RBA-enabled directory server receives an authentication request (AReq) message from a 3DS server.” (Para. 0032); “the authentication platform determines a risk level based on the RBA result data” (Para. 0054); (“The method further includes generating, based at least in part on the extracted authentication data, risk-based authentication (RBA) result data that includes a risk score for the transaction. The method also includes determining that a risk of fraud in the transaction satisfies a risk threshold established by the regulatory entity by evaluating the risk score relative to the risk threshold. The method further includes determining that the transaction value is below a transaction limit set by the regulatory entity. The transaction limit identifies a threshold transaction value below which strong consumer authentication may be avoided for transactions satisfying the risk threshold.” (Para. 0009); “the RBA result data generated by the RBA engine includes a risk score, a risk analysis, and at least one reason code. The risk score is a score representing a determined riskiness of the transaction, with lower scores indicating lower risk and higher scores indicating higher risk. In other words, the risk score represents a likelihood that the suspect cardholder (e.g., the person attempting to perform a transaction) is the legitimate cardholder having the privileges to use the payment card to perform a payment transaction” (Para. 0033); “In the example embodiment, in the case of a high risk transaction, the authentication platform may deny the transaction. The authentication platform may transmit an authentication response (ARes) message including the denial to the 3DS server. The 3DS server may transmit the ARes message including the denial to the merchant, where the merchant determines whether or not to proceed with the authorization process” (Para. 0039).
As per Claim 19, Gosset teaches:
The method of Claim 12 further comprising: receiving, in real-time, a current authentication request; analyzing the current authentication request based on the identified one or more of rules; and providing results of the analysis of the current authentication request. (“The authentication platform receives an authentication request message for a transaction involving a market regulated by a regulatory entity. The authentication request message includes authentication data and a transaction value.” (Para. 0008); “The RBA-enabled directory server receives an authentication request (AReq) message from a 3DS server. The RBA-enabled directory server may evaluate the transaction to determine with which market(s) the transaction is associated (e.g., based on merchant, merchant bank, issuing bank, consumer, and so forth). If the transaction is associated with a regulated market that is configured for “conditional SCA” as described herein, then the RBA-enabled directory server compares the transaction value with the configured transaction value threshold set by the regulators of the associated market. If the transaction value is below the transaction value threshold, then the RBA engine evaluates the risk of the transaction using transaction data and other data available to the RBA-enabled directory server.” (Para. 0032); “the authentication platform determines a risk level based on the RBA result data. If the risk level is low, the authentication platform embeds an indicator in the authentication response message indicating that the transaction is “fully authenticated.” If the risk level is not low, the authentication platform embeds one or more indicators in the authentication response message indicating that the transaction is a merchant only transaction and that authentication was attempted.” (Para. 0054); “The risk analysis is a description of a level of risk corresponding to the risk score (e.g., low risk, medium risk, or high risk). Further the reason codes include one or more factors that influenced the risk score. In some embodiments, the reason codes are generated using reason code categories and anchors, as described herein. In some embodiments, the reason codes are affected by rules and/or a combination of the rules and the model. The RBA engine transmits the RBA result data to the RBA-enabled directory server.” (Para. 0034).
As per Claim 21, Gosset teaches:
The authentication platform of Claim 1, wherein the at least one processor is further configured to input the plurality of authentication data into a machine learning model configured output to the plurality of insights based on the plurality of authentication data, the machine learning model trained based on training data including (i) a plurality of previously processed authentication requests, and (ii) a status of each of the plurality of previously processed authentication requests as being anomalous or not anomalous. (“The authentication profile contains a plurality of rules for the processing of authentication requests . . . issuer-provided risk level thresholds for the risk score and risk levels, decision making risk thresholds, and specialized rules (such as all cross-border transactions are to be submitted to the ACS).” (Para. 0037); “In some embodiments, the reason codes are generated based on a plurality of reason code categories and associated anchors” (Para. 0120); “For the merchant category, one or more anchors may be activated based fraud rates for the merchant, decline rates for the merchant, and non-cleared transaction rates for the merchant.” (Para. 0123); “Examples of the rules include, but are not limited to, how to proceed when the ACS is unavailable, information to include in the RBA, issuer-provided risk level thresholds for the risk score and risk levels, decision making risk thresholds.” (Para. 0037); “the authentication platform compares the risk score to one or more thresholds in the authentication profile to determine the risk level.” (Para. 0038); “RBA-enabled directory server 610 determines that the riskiness of the transaction is low by comparing at least one of the risk score and the risk analysis to a predetermined threshold.” (Para. 0130).
As per Claim 22, Gosset teaches:
The authentication platform of Claim 21, wherein the at least one processor is further configured to train the machine learning model based on the training data. (“First, the underlying data model is used to provide a basis for the authentication. The underlying data model may include 3DS data, which may include cardholder data, behavioral data, location data, merchant data, and device data. The underlying data model may also include interchange network data, such as, but not limited to, past risk scores, authentication approvals, authorization history, chargeback data, and fraud data.”. (Para. 0044); “Examples of the rules include, but are not limited to, how to proceed when the ACS is unavailable, information to include in the RBA, issuer-provided risk level thresholds for the risk score and risk levels, decision making risk thresholds.” (Para. 0037); “the authentication platform compares the risk score to one or more thresholds in the authentication profile to determine the risk level.” (Para. 0038); “RBA-enabled directory server 610 determines that the riskiness of the transaction is low by comparing at least one of the risk score and the risk analysis to a predetermined threshold.” (Para. 0130).
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US Patent 11823190 (Gilbert), discussing methods for improved transaction security via review of underlying transaction data (e.g. “an issuer may select to utilize risk based decisioning (or ‘RBD) and an RBD service may be applied to transactions associated with that issuer”).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571)270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W. Hayes can be reached on 571-272-6708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Justin Jimenez/
Patent Examiner, Art Unit 3697
/JOHN W HAYES/Supervisory Patent Examiner, Art Unit 3697