DETAILED ACTION
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 02/10/2026 has been entered.
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the RCE filed on 02/10/2026.
Claims 1, 5, and 12 have been amended and are hereby entered.
Claims 1-20 are currently pending and have been examined.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant’s arguments, see pages 7-8, filed 02/10/2026, with respect to claims 1-11 rejected under 35 USC 101 have been fully considered and are persuasive. The 101 rejection of claims 1-11 has been withdrawn. However, claims 12-20 stand rejected under 35 USC 101 due the difference in scope of the claims and claim 12 fails to integrate the idea into a practical application as it merely is monitoring the latency, akin to Limiting the abstract idea of collecting information, analyzing it, and displaying certain results of the collection and analysis to data related to the electric power grid, because limiting application of the abstract idea to power-grid monitoring is simply an attempt to limit the use of the abstract idea to a particular technological environment, Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016);., further in Example 40 of the PEG, the invention varied the amount of network traffic based on monitored events in the network by only collecting data when an abnormal condition was detected, specifically, the method limits collection of additional Netflow protocol data to when the initially collected data reflects an abnormal condition, which avoids excess traffic volume on the network and hindrance of network performance, providing a specific improvement over prior systems, resulting in improved network monitoring, here claim 12 is merely collecting data related to the latency but fails to use that data in a way that results in a technical improvement.
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 12-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more, and fails step 2 of the analysis because the focus of the claims is not on the devices themselves or a practical application but rather directed towards an abstract idea, the analysis is provided below.
Step 1 (Statutory Categories) - The claims pass step 1 of the subject matter eligibility test (see MPEP 2106(III)) as the claims are directed towards a method.
Step 2A – Prong One (Do the claims recite an abstract idea?)
Claim 12 recites an idea, in part, by:
calculating, from transaction data, a statistical change in data entries corresponding to a type of transaction;
modeling, in response to the calculation, a transaction rule for normalizing the statistical change by changing an acceptance standard of the type of transaction;
activating the transaction rule, wherein the transaction rule includes categorizing data entered into a database; and
monitoring a latency of the database for a data storage performance of the transaction rule.
The steps recited above under Step 2A Prong One of the analysis under the broadest reasonable interpretation covers commercial or legal interactions (including advertising, marketing or sales activities or behaviors; business relations) but for the recitation of generic computer components. That is other than reciting a computing system, database and an offline system nothing in the claim elements are directed towards anything other than commercial or legal interactions for modeling and activating transactions rules for categorizing data based on statistical calculations. If a claim limitation, under its broadest reasonable interpretation, covers commercial or legal interactions, then it falls within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas. Accordingly, the claims recite an abstract idea.
Step 2A – Prong Two (Does the claim recite additional elements that integrate the judicial exception into a practical application?) - This judicial exception is not integrated into a practical application. In particular, the claims only recite the additional elements of a computing system, database and an offline system are recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply the judicial exception using generic computer components is not indicative of a practical application (see MPEP 20106.05(f)). Accordingly, 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. The claims are directed towards an abstract idea.
Step 2B (Does the claim recite additional elements that amount to significantly more than the judicial exception?) - The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, with respect to integration of the abstract idea into a practical application, using the additional elements of a computing system, database and an offline system to perform the steps recited in Step 2A Prong One of the analysis amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components does not provide an inventive concept. The additional elements have been considered separately, and as an ordered combination, and do not add significantly more (also known as an “inventive concept”) to the judicial exception. Further, MPEP 2106.05(d)(ii) provides that receiving and transmitting data over a network (see buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), and Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 224-26, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts", "create electronic records, track multiple transactions, and issue simultaneous instructions"); Performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims."); are well-understood routine and conventional, similar to the instant application claims which recites and sending and receiving data over network, and analyzing transaction date for modeling and activating transactions rules for categorizing data based on statistical calculations. The claims are not patent eligible.
The dependent claims have been given the full analysis including analyzing the additional limitations both individually and in combination as a whole. For instance, claim 13-20 further define the abstract idea and are all steps that fall within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas similar to discussed above, amounting to mere instructions to apply the idea with generic components. The Dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 for the same reasoning as above and the additional recited limitations fail to establish that the claims are not directed to an abstract idea. The additional limitations of the dependent claims when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
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 Graham 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.
Claim 1-16 are rejected under 35 U.S.C. 103 as being unpatentable over Manapat, et al. (US Patent 10867303), “Manapat” in view of Thiruvengadathan, et al. (US Patent Application Publication 20220215303), “Thiruvengadathan”.
As per claim 1, Manapat discloses:
A system comprising: col. 20 lines 20-35
a processor; and col. 20 lines 20-35
a non-transitory computer-readable medium having stored thereon instructions that are executable by the processor to cause the system to perform operations comprising: col. 28 line 59 - col. 29 line 12
detecting, from a segment of transaction data, a trend of a type of transaction, the segment corresponding to a set of transaction attributes; col. 10 lines 23-44, col. 11 lines 20-35, col. 18 lines 10-24, wherein the trend is the features contributing to the transaction being fraudulent, which Manapat discloses may change over time, According to particular embodiments therefore, the system analyzes the random forest model generated via the machine learning algorithms and derives a most likely explanation from the random forest for the fraud likelihood score generated. For instance, according to one embodiment, the random forest possesses a large number of features or attributes, such that every time a transaction is fraud likelihood scored, a multitude of such features are considered by the model. According to such an embodiment, the features correspond to attributes such as the card type (e.g., Mastercard, Visa, Discover, American Express, etc.) or the number of times that card has been utilized in the past N days across all users associated with the system, etc. According to one embodiment, in order to generate an explanation for the decision to reject or process the transaction, the system determines which of the many properties contributed a greatest amount to the resulting fraud likelihood score… According to particular embodiments, an explanation engine 284 identifies the most likely one or more reasons contributing to a transaction rejection with increased granularity. For instance, the model may output an explanation for the transaction being marked as fraudulent because, by way of example, (a) the credit card brand was American Express and additionally (b) because the user of the credit card was in country x and (c) additionally because the credit card user swiped that identical credit card more than 10 times in the past day… Further still, as fraud patterns change over time, the user will be advised automatically by the recommendation engine of the system as to those rules that should be modified or canceled, despite having been effective in the past, as they are no longer effective in the future and consequently may be costing the business valid sales opportunities. Helpful graphs and trend lines may additionally be provided to the user via the GUI to aid in the analysis of the effectivity and accuracy of the rule and to aid the user in reaching a determination as to whether or not to retain the rule in question.
determining, using a machine learning model trained with the transaction data, a transaction rule for reversing the trend and that incorporates transaction features determined from the set of transaction attributes; col. 13 lines 5-30, col. 17 line 66 – col. 18 line 33, wherein the Examiner interprets the trend to be that rule is no longer accurate, and the systems suggests cancelling or modify the rule to make it accurate and effective again (i.e. reversing the trend) Because scoring an explanation involves the analytics engine 280 iterating over a training set, a heuristic set is utilized to prioritize or curate those explanations considered more promising. Therefore, according to such an embodiment, through an iterative approach, the “best” explanation is built for the entire training set, removing all positive cases already handled, and repeating until the entire set is covered or stopping when a useful explanation is attained. According to such an embodiment, negative cases caught are retained to enable more accurate assessment of the precision of future rules. Retaining the negatives permits the minimizing of false positives for future rules, even when another explanation has reported a false positive. According to certain embodiments, the risk model 286 is implemented via a tree model, although other types of models are feasible… With such statistics gathered, the recommendation engine can then provide feedback to the user regarding the effectiveness and accuracy of the rule. For instance, the recommendation engine may provide feedback to the user stating that of all the X charges blocked by this rule, Y % were fraudulent (optionally with a confidence indicator) and this rule blocks Z % of total fraudulent transactions associated with the user's account. With these metrics and some comparison thresholds the recommendation engine may then additionally surface suggested actions to the user, such as cancel the rule, retain the rule, modify the rule, etc… Further still, as fraud patterns change over time, the user will be advised automatically by the recommendation engine of the system as to those rules that should be modified or canceled, despite having been effective in the past, as they are no longer effective in the future and consequently may be costing the business valid sales opportunities. Helpful graphs and trend lines may additionally be provided to the user via the GUI to aid in the analysis of the effectivity and accuracy of the rule and to aid the user in reaching a determination as to whether or not to retain the rule in question… Further still, as fraud patterns change over time, the user will be advised automatically by the recommendation engine of the system as to those rules that should be modified or canceled, despite having been effective in the past, as they are no longer effective in the future and consequently may be costing the business valid sales opportunities. Helpful graphs and trend lines may additionally be provided to the user via the GUI to aid in the analysis of the effectivity and accuracy of the rule and to aid the user in reaching a determination as to whether or not to retain the rule in question.
monitoring a test performance of the transaction rule on an offline system; col.22 lines 18-55, col. 29 lines 32-40 Once created, the user may either cancel or “test” the rule by selecting the test button at the bottom, which will check to determine if the rule structure is syntactically correct and additionally present the historical analysis showing the affects of such a rule on past transactions as if the rule had been in effect for a past historical period of time… FIG. 4G depicts an alternative view of the historical analysis and testing GUI 409 transmitted or displayed by the system when a user submits a rule for testing or submits a proposed rule to the system. In particular, the GUI 409 at the tablet computing device 403 shows the rule submitted in the top portion indicating that a transaction is to be blocked if the amount in U.S. dollars exceeds or is equal to $200.00. In the middle section the GUI 409 indicates that 56 payments, or 1.4%, of the user's transactions over the past six months would have matched the proposed rule, with a breakdown additionally depicting that of those 56 payments that match the proposed but not yet active rule, nine (9) would have been authorized, one (1) would have been refunded as fraud or disputed… A historical analytics 765 module 713 generates simulated data presenting a “what if” scenario for rules that are proposed or tested against the system but not yet active. The Rule monitor 785 provides rule monitoring for rules submitted and activated by the system
monitoring a performance of the transaction rule on the live transaction platform, Col. 3 lines 21-26, receiving an input from the user to activate the received rule at the system; monitoring performance of the activated rule; and transmitting a recommendation to the user to retain or cancel the activated rule based on the monitored performance of the activated rule.
Manapat does not expressly disclose the following, Thiruvengadathan, however discloses:
translating the transaction rule for a live transaction platform that includes a real-time database system in response to the test performance satisfying a test threshold; [0042], [0073] On the other hand, if the rules/models execution testing platform 110 determines that the aggregated results do not exceed a difference threshold ( ) the rules/models execution testing platform 110 may cause the corresponding rules and/or models to be released to a production environment. The rules/models execution testing platform 110 may release one or more rules and/or models to production by transmitting the rules and/or models to a database or library, such as the rules/model library 150, that stores business rules and models for use in production. In some instances, where the business rule or the model may already be stored in the rules/library 150 as a test rule or model, the rules/models execution testing platform 110 may cause a version number, or another identifier for identifying the business rule or model as a production rule or model, to be updated. The rules/models execution testing platform 110 may transmit, to a computing device (such as the local user computing device 105a or the remote user computing device 105b), information notifying of the release to production… At step 338, the transaction streaming data platform 140 may stream or otherwise publish, the data received from the production rules executing computing device 130, for use by one or more devices or systems for real-time analytical, testing, or other purposes. The data may be streamed via a communication interface (e.g., the communication interface 211) of the transaction streaming platform 140.
pushing the translated transaction rule to the live transaction platform; and [0042], [0120-0121] If the aggregated results do not exceed any of the one or more difference threshold, at step 538, the rules/models execution testing platform 110 may cause the corresponding rules and/or models to be released to a production environment by transmitting the rules and/or models to the rules/model library 150… The rules/models execution testing platform 110 may release one or more rules and/or models to production by transmitting the rules and/or models to a database or library, such as the rules/model library 150, that stores business rules and models for use in production.
wherein the performance includes a database latency performance of the real-time database system in response to applying the transaction rule in categorizing data for the real-time database system. [0027], [0079], [0083], [0087], wherein the data is categorized as risk or fraud, The data aggregation and analysis module 112i may cause or enable the rules/models execution testing platform 110 to analyze the received production data and the data associated with the test job session to determine other metrics as well—such as, but not limited to, an average latency for processing a transaction authorization request or executing one or more of the rules in test and in production;… Difference threshold values may be set for other aggregated results as well... An average latency difference threshold may be set for determining whether an average latency for processing the transaction authorization requests during a test job session differs by more than a threshold amount from an average latency for processing corresponding transaction authorization requests in production. Difference thresholds may be set for determining whether an average latency for processing a particular business rule or calculating a model score differs between test and production by more than a threshold amount… For instance, the machine learning datasets may link data such as a transaction amount, a transaction date, a transaction type, spending patterns of the consumer, a credit limit for the consumer, an average spend amount for the merchant or the like to outputs, such as risk/fraud determinations and/or model scores… On the other hand, if the rules/models execution testing platform 110 determines that the aggregated results do not exceed a difference threshold ( ) the rules/models execution testing platform 110 may cause the corresponding rules and/or models to be released to a production environment. The rules/models execution testing platform 110 may release one or more rules and/or models to production by transmitting the rules and/or models to a database or library, such as the rules/model library 150, that stores business rules and models for use in production.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Manapat with the ability to use business rules based on the average latency threshold for processing the transaction authorization taught by John, doing so further allows latency to be used as a metric in determining the rules [0083].
As per claim 2, Manapat discloses:
wherein the machine learning model is trained with one or more machine learning schemes using the transaction data to take transaction attributes as inputs and identify transaction features of the type of transaction corresponding to the trend. Col. 32 lines 52-67, col. 10 line 6-22 According to one embodiment the explanation engine 284 is system configurable to select which explanation from many available explanations is chosen. For instance, between the predicates in an explanation and the number of possible features and splits for each predicate, there is a combinatorial explosion of possible explanations which may be attempted. While this quantity is theoretically feasible, exhausting all possible combinations is not computationally practical in terms of time and cost for the desired end result of returning a user explanation for a given transaction responsive to an inquiry. Because scoring an explanation involves the analytics engine 280 iterating over a training set, a heuristic set is utilized to prioritize or curate those explanations considered more promising. Therefore, according to such an embodiment, through an iterative approach, the “best” explanation is built for the entire training set, removing all positive cases already handled, and repeating until the entire set is covered or stopping when a useful explanation is attained. According to such an embodiment, negative cases caught are retained to enable more accurate assessment of the precision of future rules. Retaining the negatives permits the minimizing of false positives for future rules, even when another explanation has reported a false positive. According to certain embodiments, the risk model 286 is implemented via a tree model, although other types of models are feasible… According to particular embodiments therefore, the system analyzes the random forest model generated via the machine learning algorithms and derives a most likely explanation from the random forest for the fraud likelihood score generated. For instance, according to one embodiment, the random forest possesses a large number of features or attributes, such that every time a transaction is fraud likelihood scored, a multitude of such features are considered by the model. According to such an embodiment, the features correspond to attributes such as the card type (e.g., Mastercard, Visa, Discover, American Express, etc.) or the number of times that card has been utilized in the past N days across all users associated with the system, etc. According to one embodiment, in order to generate an explanation for the decision to reject or process the transaction, the system determines which of the many properties contributed a greatest amount to the resulting fraud likelihood score.
As per claim 3, Manapat disclose:
wherein generating the transaction rule further comprises producing the transaction rule that satisfies a failure rate threshold with respect to the transaction data. Col. 17 line 66 – col. 18 line 9 With such statistics gathered, the recommendation engine can then provide feedback to the user regarding the effectiveness and accuracy of the rule. For instance, the recommendation engine may provide feedback to the user stating that of all the X charges blocked by this rule, Y % were fraudulent (optionally with a confidence indicator) and this rule blocks Z % of total fraudulent transactions associated with the user's account. With these metrics and some comparison thresholds the recommendation engine may then additionally surface suggested actions to the user, such as cancel the rule, retain the rule, modify the rule, etc.
As per claim 4, Manapat:
wherein the operations further comprise retiring the transaction rule based on the performance falling below a performance threshold that includes a database performance threshold. Col. 17 line 66 – col. 18 line 9, col. 30 lines 44-46 With such statistics gathered, the recommendation engine can then provide feedback to the user regarding the effectiveness and accuracy of the rule. For instance, the recommendation engine may provide feedback to the user stating that of all the X charges blocked by this rule, Y % were fraudulent (optionally with a confidence indicator) and this rule blocks Z % of total fraudulent transactions associated with the user's account. With these metrics and some comparison thresholds the recommendation engine may then additionally surface suggested actions to the user, such as cancel the rule, retain the rule, modify the rule, etc… Main memory 804 additionally includes a rule monitor 823 to monitor submitted and activated rules on an on-going basis including performing statistical sampling and analysis on an ongoing basis. Main memory 804 further includes the risk model 825, such as a random forest of trees (e.g., in compressed form) by which a risk analyzer may evaluate and generate fraud likelihood scores for transactions and from which explanations may be derived and provided to users which inquire or dispute a particular transaction. Main memory 804 and its sub-elements are operable in conjunction with processing logic 826 and processor 802 to perform the methodologies discussed herein.
As per claim 5, Manapat discloses:
A non-transitory computer-readable medium having stored thereon instructions that are executable by a processor of a computing system to cause the computing system to perform operations comprising: col. 28 line 59 - col. 29 line 12
identifying, from a portion of transaction data, a trend of a type of transaction, the portion corresponding to a set of transaction attributes; col. 10 lines 23-44, col. 11 lines 20-35, col. 18 lines 10-24, wherein the trend is the features contributing to the transaction being fraudulent, which Manapat discloses may change over time, According to particular embodiments therefore, the system analyzes the random forest model generated via the machine learning algorithms and derives a most likely explanation from the random forest for the fraud likelihood score generated. For instance, according to one embodiment, the random forest possesses a large number of features or attributes, such that every time a transaction is fraud likelihood scored, a multitude of such features are considered by the model. According to such an embodiment, the features correspond to attributes such as the card type (e.g., Mastercard, Visa, Discover, American Express, etc.) or the number of times that card has been utilized in the past N days across all users associated with the system, etc. According to one embodiment, in order to generate an explanation for the decision to reject or process the transaction, the system determines which of the many properties contributed a greatest amount to the resulting fraud likelihood score… According to particular embodiments, an explanation engine 284 identifies the most likely one or more reasons contributing to a transaction rejection with increased granularity. For instance, the model may output an explanation for the transaction being marked as fraudulent because, by way of example, (a) the credit card brand was American Express and additionally (b) because the user of the credit card was in country x and (c) additionally because the credit card user swiped that identical credit card more than 10 times in the past day… Further still, as fraud patterns change over time, the user will be advised automatically by the recommendation engine of the system as to those rules that should be modified or canceled, despite having been effective in the past, as they are no longer effective in the future and consequently may be costing the business valid sales opportunities. Helpful graphs and trend lines may additionally be provided to the user via the GUI to aid in the analysis of the effectivity and accuracy of the rule and to aid the user in reaching a determination as to whether or not to retain the rule in question
providing a notification of the identified trend; col. 24 lines 6-50, According to one embodiment, if the charge is sampled for statistical purposes and permitted to go through in violation of the user's rule, then the operator of the system (e.g., Stripe) will cover the cost of any chargeback associated with the transaction if a charge back results. However, if the transaction is processed in violation of the user rule and ultimately is determined to be a good (e.g., not fraudulent) transaction, then user benefits from the statistical sampling rule bypass. Nevertheless, by sampling a small fraction of the charges in violation of the user rule, such as letting through 2% of such charges despite the rule, then it is possible for the system to evaluate such transactions to determine if they are actually fraudulent, or what portion of them are fraudulent, or if none of them result in fraudulent charges. With such ongoing monitoring, the system is then enabled to surface recommendations to the user to advise the user as to the accuracy and effectiveness of the active rule, and thus permit the user to make changes to the rule, keep the rule active, or to cancel the rule. For instance, the system may surface a recommendation to the user advising that of the 2% of transactions which bypassed the rule for statistical sampling purposes, a large percentage, such as 80% of such transactions, actually charged back as being fraudulent. In such a case, the user is likely to keep such a rule active. However, it may be that of such transactions sampled, none of the transactions, or a very low percentage of transactions were fraudulent, and therefore, perhaps the user's rule is no longer effective.
generating, using a trained machine learning model, a transaction rule for changing the trend, that passes a first performance threshold on an offline system; col. 13 lines 5-30, col. 17 line 66 – col. 18 line 33, col.22 lines 18-55, col. 25 lines 30-40, col. 29 lines 32-40 wherein the Examiner interprets the trend to be that rule is no longer accurate, and the systems suggests cancelling or modify the rule to make it accurate and effective again (i.e. reversing the trend) Because scoring an explanation involves the analytics engine 280 iterating over a training set, a heuristic set is utilized to prioritize or curate those explanations considered more promising. Therefore, according to such an embodiment, through an iterative approach, the “best” explanation is built for the entire training set, removing all positive cases already handled, and repeating until the entire set is covered or stopping when a useful explanation is attained. According to such an embodiment, negative cases caught are retained to enable more accurate assessment of the precision of future rules. Retaining the negatives permits the minimizing of false positives for future rules, even when another explanation has reported a false positive. According to certain embodiments, the risk model 286 is implemented via a tree model, although other types of models are feasible… With such statistics gathered, the recommendation engine can then provide feedback to the user regarding the effectiveness and accuracy of the rule. For instance, the recommendation engine may provide feedback to the user stating that of all the X charges blocked by this rule, Y % were fraudulent (optionally with a confidence indicator) and this rule blocks Z % of total fraudulent transactions associated with the user's account. With these metrics and some comparison thresholds the recommendation engine may then additionally surface suggested actions to the user, such as cancel the rule, retain the rule, modify the rule, etc… Further still, as fraud patterns change over time, the user will be advised automatically by the recommendation engine of the system as to those rules that should be modified or canceled, despite having been effective in the past, as they are no longer effective in the future and consequently may be costing the business valid sales opportunities. Helpful graphs and trend lines may additionally be provided to the user via the GUI to aid in the analysis of the effectivity and accuracy of the rule and to aid the user in reaching a determination as to whether or not to retain the rule in question… Further still, as fraud patterns change over time, the user will be advised automatically by the recommendation engine of the system as to those rules that should be modified or canceled, despite having been effective in the past, as they are no longer effective in the future and consequently may be costing the business valid sales opportunities. Helpful graphs and trend lines may additionally be provided to the user via the GUI to aid in the analysis of the effectivity and accuracy of the rule and to aid the user in reaching a determination as to whether or not to retain the rule in question…A historical analytics 765 module 713 generates simulated data presenting a “what if” scenario for rules that are proposed or tested against the system but not yet active. The Rule monitor 785 provides rule monitoring for rules submitted and activated by the system... At block 620, processing logic receives the rule at the system from the user, in which the rule specifies conditions defined by the user by which the system is to accept or reject purchase transactions for the user matching the conditions regardless of the fraud likelihood score generated by the system. At block 625, processing logic transmits a historical analysis to the user based on the received rule.
enabling the transaction rule on a live system in response to passing the first performance threshold; and col. 3 lines 48-65, col. 20 line 61 thru col. 21 line 10, Depicted at the top are snapshot data points including volume rejected by the rule 435 over a particular time period (e.g., 90 days), transactions affected 440 by the rule had it been activated over that period, customers affected 445 by the rule had it been in effect, and percentage of total volume 450 affected by the rule had it been in effect. The graph depicts funds on the vertical axis over time on the horizontal axis according to the key at the bottom showing the attempted payments by outcome 430 in which there are authorized—normal risk 410 transactions, authorized—elevated risk 415 transactions, transactions declined by the issuer 420, transactions blocked by the system 425, and those transactions rejected by the merchant rule 465. Once the user reviews the historical view chart 413 showing the “what if” results of the proposed but not yet activated user rule, the user may then either cancel 475 the proposed rule without activation or the user may activate the user rule 470…. The fraud risk assessment and actioning system uses machine learning to assess the risk of each attempted transaction and automatically blocks those transactions predicted to have an excessive risk of fraud, by comparing a generated fraud likelihood score (also referred to herein as a ‘fraud score’)—a numerical estimate of the probability that an attempted transaction is fraudulent—for the transaction to a permissible threshold. The mechanisms described herein provide users the ability to develop customizable rules to leverage their specialized and local knowledge while collecting statistical information on an ongoing basis for such rules and the transactions matching those rules, with the statistics forming the basis of making recommendations and providing feedback to the users with the ability to provide a continuous feedback loop by routing the gathered statistics and sample transactions back into the machine learning model to continuously improve the performance of the fraud detection system.
disabling the transaction rule based on failing a second performance threshold Col. 9 lines 10-27, col. 20 line 9-14, col. 30 lines 41-55, It is possible that many transactions will have a rule which matches the transaction but specifies the same action as the default behavior of the system, thus, a user rule may specify to allow a transaction already allowed by the system 210 and in a similar way, the merchant use rule may specify to reject a transaction already rejected by the system 210. Such occurrences are tracked by the system as part of ongoing monitoring and performance for an active rule and the system 210 may recommend to the user that a particular rule is not necessary because, for example, the system already rejects or accepts transactions in the same manner as specified by the user rule, and thus, it is not necessary to override the system's default behavior. For example, the system 210 may recommend that a particular rule be removed because it has not been used to override the default system behavior over a certain period (e.g., 180 days)… The system will then monitor the activated rule, collecting statistics and actual usage results, and then surface recommendations to the user with regard to the effectivity of the rule, again permitting the user to either keep or cancel the rule based on the system feedback… Main memory 804 includes a historical analysis 824 module to generate a simulated historical analysis GUI by which a user may test or evaluate a proposed rule. Main memory 804 additionally includes a rule monitor 823 to monitor submitted and activated rules on an on-going basis including performing statistical sampling and analysis on an ongoing basis. Main memory 804 further includes the risk model 825, such as a random forest of trees (e.g., in compressed form) by which a risk analyzer may evaluate and generate fraud likelihood scores for transactions and from which explanations may be derived and provided to users which inquire or dispute a particular transaction.
Manapat does not expressly disclose the following, Thiruvengadathan, however discloses:
wherein the transaction rules includes categorizing data entered into a database [0027-0029], [0042], [0073] The operational data store 175 may be configured to store features, e.g., historical data about a merchant or consumer account and previous transactions associated therewith. For instance, as a non-limiting example, the features may include average spend amounts for the merchant and/or consumer, spending patterns of the consumer, credit limits, etc. The features may be used together with additional information in the transaction authorization determination process… On the other hand, if the rules/models execution testing platform 110 determines that the aggregated results do not exceed a difference threshold ( ) the rules/models execution testing platform 110 may cause the corresponding rules and/or models to be released to a production environment. The rules/models execution testing platform 110 may release one or more rules and/or models to production by transmitting the rules and/or models to a database or library, such as the rules/model library 150, that stores business rules and models for use in production. In some instances, where the business rule or the model may already be stored in the rules/library 150 as a test rule or model, the rules/models execution testing platform 110 may cause a version number, or another identifier for identifying the business rule or model as a production rule or model, to be updated. The rules/models execution testing platform 110 may transmit, to a computing device (such as the local user computing device 105a or the remote user computing device 105b), information notifying of the release to production… At step 338, the transaction streaming data platform 140 may stream or otherwise publish, the data received from the production rules executing computing device 130, for use by one or more devices or systems for real-time analytical, testing, or other purposes. The data may be streamed via a communication interface (e.g., the communication interface 211) of the transaction streaming platform 140.
wherein the second performance threshold includes a database latency performance threshold for the database. [0027], [0079], [0083], [0087], wherein the data is categorized as risk or fraud, The data aggregation and analysis module 112i may cause or enable the rules/models execution testing platform 110 to analyze the received production data and the data associated with the test job session to determine other metrics as well—such as, but not limited to, an average latency for processing a transaction authorization request or executing one or more of the rules in test and in production;… Difference threshold values may be set for other aggregated results as well... An average latency difference threshold may be set for determining whether an average latency for processing the transaction authorization requests during a test job session differs by more than a threshold amount from an average latency for processing corresponding transaction authorization requests in production. Difference thresholds may be set for determining whether an average latency for processing a particular business rule or calculating a model score differs between test and production by more than a threshold amount… For instance, the machine learning datasets may link data such as a transaction amount, a transaction date, a transaction type, spending patterns of the consumer, a credit limit for the consumer, an average spend amount for the merchant or the like to outputs, such as risk/fraud determinations and/or model scores… On the other hand, if the rules/models execution testing platform 110 determines that the aggregated results do not exceed a difference threshold ( ) the rules/models execution testing platform 110 may cause the corresponding rules and/or models to be released to a production environment. The rules/models execution testing platform 110 may release one or more rules and/or models to production by transmitting the rules and/or models to a database or library, such as the rules/model library 150, that stores business rules and models for use in production.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Manapat with the ability to use business rules based on the average latency threshold for processing the transaction authorization taught by John, doing so further allows latency to be used as a metric in determining the rules [0083].
As per claim 6, Manapat discloses:
wherein the trained machine learning model is trained to generate the transaction rule that incorporates a set of transaction features identified from the set of transaction attributes. Col. 32 lines 52-67, col. 10 line 6-22 According to one embodiment the explanation engine 284 is system configurable to select which explanation from many available explanations is chosen. For instance, between the predicates in an explanation and the number of possible features and splits for each predicate, there is a combinatorial explosion of possible explanations which may be attempted. While this quantity is theoretically feasible, exhausting all possible combinations is not computationally practical in terms of time and cost for the desired end result of returning a user explanation for a given transaction responsive to an inquiry. Because scoring an explanation involves the analytics engine 280 iterating over a training set, a heuristic set is utilized to prioritize or curate those explanations considered more promising. Therefore, according to such an embodiment, through an iterative approach, the “best” explanation is built for the entire training set, removing all positive cases already handled, and repeating until the entire set is covered or stopping when a useful explanation is attained. According to such an embodiment, negative cases caught are retained to enable more accurate assessment of the precision of future rules. Retaining the negatives permits the minimizing of false positives for future rules, even when another explanation has reported a false positive. According to certain embodiments, the risk model 286 is implemented via a tree model, although other types of models are feasible… According to particular embodiments therefore, the system analyzes the random forest model generated via the machine learning algorithms and derives a most likely explanation from the random forest for the fraud likelihood score generated. For instance, according to one embodiment, the random forest possesses a large number of features or attributes, such that every time a transaction is fraud likelihood scored, a multitude of such features are considered by the model. According to such an embodiment, the features correspond to attributes such as the card type (e.g., Mastercard, Visa, Discover, American Express, etc.) or the number of times that card has been utilized in the past N days across all users associated with the system, etc. According to one embodiment, in order to generate an explanation for the decision to reject or process the transaction, the system determines which of the many properties contributed a greatest amount to the resulting fraud likelihood score.
As per claim 7, Manapat discloses:
wherein generating the transaction rule further comprises tuning the set of transaction features. Col. 3 lines 41-65, see also col. 17 lines 25-38, The systems, methods, and apparatuses described herein protect users from fraudulent charges and additionally provide such users with tools and data to optimize their use of the system for their business. Provided tools reduce the user's operational burden of fraud while permitting such users to create customizable rules to fine-tune, and therefore override, the system's default fraud detection behaviors where desirable. The fraud risk assessment and actioning system uses machine learning to assess the risk of each attempted transaction and automatically blocks those transactions predicted to have an excessive risk of fraud, by comparing a generated fraud likelihood score (also referred to herein as a ‘fraud score’)—a numerical estimate of the probability that an attempted transaction is fraudulent—for the transaction to a permissible threshold. The mechanisms described herein provide users the ability to develop customizable rules to leverage their specialized and local knowledge while collecting statistical information on an ongoing basis for such rules and the transactions matching those rules, with the statistics forming the basis of making recommendations and providing feedback to the users with the ability to provide a continuous feedback loop by routing the gathered statistics and sample transactions back into the machine learning model to continuously improve the performance of the fraud detection system.
As per claim 8, Manapat discloses:
wherein the transaction rule determines whether to accept or decline a new transaction based on the set of transaction features. Col. 24 lines 7-22, An optional feature is therefore provided for the user's creating such rules. Such users may opt-in to participating in the ongoing evaluation feature for their active rules by selecting a check box at the rule creation GUI or by other agreement or acknowledgement means. If the user does not wish to participate, then all transactions matching their specified criteria are rejected or accepted without further processing. Conversely, for users participating in the evaluation feature, the system performs rule bypass for statistical sampling 525 in proportion to the evaluated fraud likelihood score generated for such transactions. For instance, if the user's rule specifies to reject all transactions originating from Russia, then a small fraction of these charges matching the user's rule will actually be permitted to go through and be processed by the system, bypassing the user's rule for the purposes of statistical sampling.
As per claim 9, Manapat discloses:
wherein enabling the transaction rule further comprises mapping a set of transaction features of the transaction rule to corresponding features on a live transaction platform. Col. 18 lines 41-62, col. 20 lines 29-40, For example, business owners obviously want to eliminate fraudulent transactions, however, increasingly strict filters will prevent an increasing number of legitimate transactions, and thus harm profitability, despite eliminating some risk of fraud. Evaluating the fraud rate for a given merchant in the context of that merchant's margin can therefore determine what level of fraud risk is ideal for maximum profitability of the merchant's business… Nonetheless, by providing ongoing monitoring at no cost to the users and gathering statistically relevant data as to the effectiveness and accuracy of the user's custom rules, it is possible to provide recommendations to the users to eliminate those rules which are not effective… Consider for instance a merchant wishing to institute a particular block for transactions originating via credit card transactions from, e.g., Singapore, or conversely, expressly permitting transactions originating from Singapore. Such a user may specify filter criteria 420 specifying that transactions specifically associated with that user's account which originate in Singapore and which match any additionally specified criteria (e.g., amount, number of times card used, card present or not present, branding, fraud likelihood score range, etc.) will either be affirmatively permitted, or rejected, regardless of the risk determination by the system.
As per claim 10, Manapat discloses:
wherein the first performance threshold is based on the transaction data. Col. 22 lines 29-31, A user may choose to set such a threshold if, for example, the average purchase made is small (e.g., $15), such that very large purchases are likely to be fraudulent.
As per claim 11, Manapat discloses:
wherein the second performance threshold is based on a live transaction platform. Col. 9 lines 10-27, col. 20 line 9-14 It is possible that many transactions will have a rule which matches the transaction but specifies the same action as the default behavior of the system, thus, a user rule may specify to allow a transaction already allowed by the system 210 and in a similar way, the merchant use rule may specify to reject a transaction already rejected by the system 210. Such occurrences are tracked by the system as part of ongoing monitoring and performance for an active rule and the system 210 may recommend to the user that a particular rule is not necessary because, for example, the system already rejects or accepts transactions in the same manner as specified by the user rule, and thus, it is not necessary to override the system's default behavior. For example, the system 210 may recommend that a particular rule be removed because it has not been used to override the default system behavior over a certain period (e.g., 180 days)… The system will then monitor the activated rule, collecting statistics and actual usage results, and then surface recommendations to the user with regard to the effectivity of the rule, again permitting the user to either keep or cancel the rule based on the system feedback
As per claim 12, Manapat discloses:
A computer-implemented method comprising: col. 27 lines 6-25
calculating, by a computing system from transaction data, a statistical change in data entries corresponding to a type of transaction; col. 3 lines 50-65, col. 27 lines 50-60, According to another embodiment of method 600, performing statistical sampling and statistical analysis of the plurality of purchase transactions matching the active rule; in which the statistical sampling includes permitting at least a portion of the purchase transactions matching the active rule to be processed without rejection in violation of the active rule; and in which performing the statistical analysis includes determining whether purchase transactions processed without rejection in violation of the active rule are subsequently determined to have a final transaction state as either fraudulent or non-fraudulent… The mechanisms described herein provide users the ability to develop customizable rules to leverage their specialized and local knowledge while collecting statistical information on an ongoing basis for such rules and the transactions matching those rules, with the statistics forming the basis of making recommendations and providing feedback to the users with the ability to provide a continuous feedback loop by routing the gathered statistics and sample transactions back into the machine learning model to continuously improve the performance of the fraud detection system.
modeling, by the computing system on an offline system in response to the calculation, a transaction rule for normalizing the statistical change by changing an acceptance standard of the type of transaction; and col. 3 lines 50-65, col. 27 lines 50-60, col. 14 lines 1-12, col. 22 lines 32-45 col. 30 lines 41-53 The mechanisms described herein provide users the ability to develop customizable rules to leverage their specialized and local knowledge while collecting statistical information on an ongoing basis for such rules and the transactions matching those rules, with the statistics forming the basis of making recommendations and providing feedback to the users with the ability to provide a continuous feedback loop by routing the gathered statistics and sample transactions back into the machine learning model to continuously improve the performance of the fraud detection system… A fitness function may additionally be utilized to normalize covariance between the explanation engine's 284 output and the risk model's 286 predications, weighted by its precision according to the exemplary formula:
f(E)=(covariance(E,prediction)/variance(prediction))*pr(E)
(80) The normalized covariance returns a value in [−1, 1], higher if E changes with the predictions and in which any explanation having a positive value is deemed a reasonable explanation. Similarly, pr(E) will be in [0, 1], and it is therefore expected that f (E) will be in [0, 1] as well….
Main memory 804 includes a historical analysis 824 module to generate a simulated historical analysis GUI by which a user may test or evaluate a proposed rule. Main memory 804 additionally includes a rule monitor 823 to monitor submitted and activated rules on an on-going basis including performing statistical sampling and analysis on an ongoing basis. Main memory 804 further includes the risk model 825, such as a random forest of trees (e.g., in compressed form) by which a risk analyzer may evaluate and generate fraud likelihood scores for transactions and from which explanations may be derived and provided to users which inquire or dispute a particular transaction… FIG. 4G depicts an alternative view of the historical analysis and testing GUI 409 transmitted or displayed by the system when a user submits a rule for testing or submits a proposed rule to the system. In particular, the GUI 409 at the tablet computing device 403 shows the rule submitted in the top portion indicating that a transaction is to be blocked if the amount in U.S. dollars exceeds or is equal to $200.00. In the middle section the GUI 409 indicates that 56 payments, or 1.4%, of the user's transactions over the past six months would have matched the proposed rule, with a breakdown additionally depicting that of those 56 payments that match the proposed but not yet active rule, nine (9) would have been authorized, one (1) would have been refunded as fraud or dispute
activating, by the computing system, the transaction rule, col. 21 line 5-10, Once the user reviews the historical view chart 413 showing the “what if” results of the proposed but not yet activated user rule, the user may then either cancel 475 the proposed rule without activation or the user may activate the user rule 470.
Manapat does not expressly disclose the following, Thiruvengadathan, however discloses:
wherein the transaction rule includes categorizing data entered into a database [0028-0029], [0042], [0073] The operational data store 175 may be configured to store features, e.g., historical data about a merchant or consumer account and previous transactions associated therewith. For instance, as a non-limiting example, the features may include average spend amounts for the merchant and/or consumer, spending patterns of the consumer, credit limits, etc. The features may be used together with additional information in the transaction authorization determination process… On the other hand, if the rules/models execution testing platform 110 determines that the aggregated results do not exceed a difference threshold ( ) the rules/models execution testing platform 110 may cause the corresponding rules and/or models to be released to a production environment. The rules/models execution testing platform 110 may release one or more rules and/or models to production by transmitting the rules and/or models to a database or library, such as the rules/model library 150, that stores business rules and models for use in production. In some instances, where the business rule or the model may already be stored in the rules/library 150 as a test rule or model, the rules/models execution testing platform 110 may cause a version number, or another identifier for identifying the business rule or model as a production rule or model, to be updated. The rules/models execution testing platform 110 may transmit, to a computing device (such as the local user computing device 105a or the remote user computing device 105b), information notifying of the release to production… At step 338, the transaction streaming data platform 140 may stream or otherwise publish, the data received from the production rules executing computing device 130, for use by one or more devices or systems for real-time analytical, testing, or other purposes. The data may be streamed via a communication interface (e.g., the communication interface 211) of the transaction streaming platform 140.
monitoring a latency of the database for a data storage performance of the transaction rule. [0027], [0079], [0083], [0087] The data aggregation and analysis module 112i may cause or enable the rules/models execution testing platform 110 to analyze the received production data and the data associated with the test job session to determine other metrics as well—such as, but not limited to, an average latency for processing a transaction authorization request or executing one or more of the rules in test and in production;… Difference threshold values may be set for other aggregated results as well... An average latency difference threshold may be set for determining whether an average latency for processing the transaction authorization requests during a test job session differs by more than a threshold amount from an average latency for processing corresponding transaction authorization requests in production. Difference thresholds may be set for determining whether an average latency for processing a particular business rule or calculating a model score differs between test and production by more than a threshold amount… For instance, the machine learning datasets may link data such as a transaction amount, a transaction date, a transaction type, spending patterns of the consumer, a credit limit for the consumer, an average spend amount for the merchant or the like to outputs, such as risk/fraud determinations and/or model scores. The model score may indicate an overall degree of risk associated with the transaction, the consumer, and/or the merchant associated with the transaction authorization request. The model score may be used together with additional information in the transaction authorization determination process to evaluate the transaction and make predictions about the level of risk associated with the transaction in order to make an authorization determination.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Manapat with the ability to use business rules based on the average latency threshold for processing the transaction authorization taught by John, doing so further allows latency to be used as a metric in determining the rules [0083].
As per claim 13, Manapat discloses:
wherein the statistical change in data entries corresponds to an upward trend of loss transactions and the transaction rule decreases an acceptance rate of risky transactions. Col. 17 line 66 – col. 18 line 32, With such statistics gathered, the recommendation engine can then provide feedback to the user regarding the effectiveness and accuracy of the rule. For instance, the recommendation engine may provide feedback to the user stating that of all the X charges blocked by this rule, Y % were fraudulent (optionally with a confidence indicator) and this rule blocks Z % of total fraudulent transactions associated with the user's account. With these metrics and some comparison thresholds the recommendation engine may then additionally surface suggested actions to the user, such as cancel the rule, retain the rule, modify the rule, etc… According to another embodiment the user provides their margin as an input and the recommendation engine then provides guidance or feedback indicating an how a less restrictive or a more restrictive rule may perform in terms of business profitability. For example, business owners obviously want to eliminate fraudulent transactions, however, increasingly strict filters will prevent an increasing number of legitimate transactions, and thus harm profitability, despite eliminating some risk of fraud. Evaluating the fraud rate for a given merchant in the context of that merchant's margin can therefore determine what level of fraud risk is ideal for maximum profitability of the merchant's business.
As per claim 14, Manapat discloses:
wherein the statistical change in data entries corresponds to a downward trend of completed transactions and the transaction rule increases an acceptance rate of risky transactions. Col. 17 line 66 – col. 18 line 32, With such statistics gathered, the recommendation engine can then provide feedback to the user regarding the effectiveness and accuracy of the rule. For instance, the recommendation engine may provide feedback to the user stating that of all the X charges blocked by this rule, Y % were fraudulent (optionally with a confidence indicator) and this rule blocks Z % of total fraudulent transactions associated with the user's account. With these metrics and some comparison thresholds the recommendation engine may then additionally surface suggested actions to the user, such as cancel the rule, retain the rule, modify the rule, etc… According to another embodiment the user provides their margin as an input and the recommendation engine then provides guidance or feedback indicating an how a less restrictive or a more restrictive rule may perform in terms of business profitability. For example, business owners obviously want to eliminate fraudulent transactions, however, increasingly strict filters will prevent an increasing number of legitimate transactions, and thus harm profitability, despite eliminating some risk of fraud. Evaluating the fraud rate for a given merchant in the context of that merchant's margin can therefore determine what level of fraud risk is ideal for maximum profitability of the merchant's business.
As per claim 15, Manapat discloses:
wherein the transaction data corresponds to historical data from a live environment. col. 20 lines 53-60 FIG. 4B depicts a GUI 402 via which a user may activate a new user rule 470. In particular, there is depicted the GUI 402 at the tablet computing device 403 depicting a historical view chart 413. Within the chart there is depicted a “what if” analysis showing the historical view of what would have occurred if the newly created rule from FIG. 4A were actually in place and activated over a past historical period of time.
As per claim 16, Manapat discloses:
wherein modeling the transaction rule further comprises testing the transaction rule, using the transaction data, for changing the acceptance standard to achieve a desired acceptance rate. Col. 22 lines 18-23, col. 25 line 55 – col. 26 line 20, col. 29 lines 14-40 In accordance with particular embodiments, the system permits the user to “test” or view the historical impact of the rule upon past transactions for a specified period. However, in other embodiments the user having submitted a rule for activation must first view historical analysis before being permitted to advance and actually activate the newly proposed rule. Therefore, according to another embodiment of method 600, the user rule is received in an inactive state and the system simulates purchase transaction data affected during a specified historical period by applying the user rule to the simulated transaction data without activating the user rule within the system. According to such an embodiment, transmitting the historical analysis to the user includes transmitting a Graphical User Interface (GUI) to the user including at least a historical view chart displaying the simulated purchase transaction data… According to the depicted embodiment, the system 700 includes the processor 790 and the memory 795 to execute instructions at the system 700; an analytics engine 750 provides analytics to generate fraud likelihood score(s) 743 for transactions handled by the system indicative of a level of risk. A request interface 725 is enabled to receive incoming requests, for instance, from users and user devices interacting with the system to submit rule requests, utilize the system's dashboard, etc. The request may be via web interfaces, API calls, etc. A historical analytics 765 module 713 generates simulated data presenting a “what if” scenario for rules that are proposed or tested against the system but not yet active. The Rule monitor 785 provides rule monitoring for rules submitted and activated by the system. According to certain embodiments, rule monitor may additionally perform statistical sampling and analysis in support of the methodologies described herein.
Claim 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Manapat, et al. (US Patent 10867303), “Manapat” in view of Thiruvengadathan, et al. (US Patent Application Publication 20220215303), “Thiruvengadathan” in view of John, et al. (US Patent Application Publication 20240272906), “John”.
As per claim 17, does not expressly disclose the following, John, however discloses:
wherein activating the transaction rule further comprises enabling the transaction rule in a live environment by translating the transaction rule for a syntax of the live environment. [0010], [0050] The authorizer server 160 is a server that applies various policies set forth by a client of the ontology management operator 105 to approve or deny various transactions in real-time as the transaction server 150 forwards the transaction data payload to the authorizer server 160. The authorizer server 160 communicates with the policy management server 110 to retrieve policies for transaction approval and related data for the authorizer server 160 to make the approval decisions… receiving the definition of the policy includes: providing a list of candidate actions and/or conditions for a domain, each action or condition corresponding to a machine-code subroutine object that is stored: receiving, from the domain, a selection of actions and/or conditions to define the policy, wherein a selected action or condition corresponds to a component of the policy, and wherein generating the machine-code syntax tree includes: selecting a set of machine-code subroutine objects that correspond to the selection of actions and/or conditions that define the policy.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Manapat with the ability to define the policies as machine-code syntax trees as taught by John, doing so allows the workflows to be implemented using syntax trees so that the workflows are reusable and can be implemented in a highly scalable fashion [0038].
As per claim 18, Manapat discloses:
monitoring, by the computing system, a performance of the transaction rule in the live environment, wherein the performance includes a database performance for the database in the live environment. Col. 3 lines 21-26, Col. 17 line 66 – col. 18 line 9, col. 30 lines 44-46, receiving an input from the user to activate the received rule at the system; monitoring performance of the activated rule; and transmitting a recommendation to the user to retain or cancel the activated rule based on the monitored performance of the activated rule… With such statistics gathered, the recommendation engine can then provide feedback to the user regarding the effectiveness and accuracy of the rule. For instance, the recommendation engine may provide feedback to the user stating that of all the X charges blocked by this rule, Y % were fraudulent (optionally with a confidence indicator) and this rule blocks Z % of total fraudulent transactions associated with the user's account. With these metrics and some comparison thresholds the recommendation engine may then additionally surface suggested actions to the user, such as cancel the rule, retain the rule, modify the rule, etc… Main memory 804 additionally includes a rule monitor 823 to monitor submitted and activated rules on an on-going basis including performing statistical sampling and analysis on an ongoing basis. Main memory 804 further includes the risk model 825, such as a random forest of trees (e.g., in compressed form) by which a risk analyzer may evaluate and generate fraud likelihood scores for transactions and from which explanations may be derived and provided to users which inquire or dispute a particular transaction. Main memory 804 and its sub-elements are operable in conjunction with processing logic 826 and processor 802 to perform the methodologies discussed herein.
As per claim 19, Manapat discloses:
providing a notification regarding the performance of the transaction rule. col. 24 lines 6-50, According to one embodiment, if the charge is sampled for statistical purposes and permitted to go through in violation of the user's rule, then the operator of the system (e.g., Stripe) will cover the cost of any chargeback associated with the transaction if a charge back results. However, if the transaction is processed in violation of the user rule and ultimately is determined to be a good (e.g., not fraudulent) transaction, then user benefits from the statistical sampling rule bypass. Nevertheless, by sampling a small fraction of the charges in violation of the user rule, such as letting through 2% of such charges despite the rule, then it is possible for the system to evaluate such transactions to determine if they are actually fraudulent, or what portion of them are fraudulent, or if none of them result in fraudulent charges. With such ongoing monitoring, the system is then enabled to surface recommendations to the user to advise the user as to the accuracy and effectiveness of the active rule, and thus permit the user to make changes to the rule, keep the rule active, or to cancel the rule. For instance, the system may surface a recommendation to the user advising that of the 2% of transactions which bypassed the rule for statistical sampling purposes, a large percentage, such as 80% of such transactions, actually charged back as being fraudulent. In such a case, the user is likely to keep such a rule active. However, it may be that of such transactions sampled, none of the transactions, or a very low percentage of transactions were fraudulent, and therefore, perhaps the user's rule is no longer effective.
As per claim 20, Manapat does not expressly disclose the following, John, however discloses:
wherein translating the transaction rule further comprises converting the transaction rule into a tree structure, and converting the tree structure based on the syntax of the live environment. [0010], [0050] The authorizer server 160 is a server that applies various policies set forth by a client of the ontology management operator 105 to approve or deny various transactions in real-time as the transaction server 150 forwards the transaction data payload to the authorizer server 160. The authorizer server 160 communicates with the policy management server 110 to retrieve policies for transaction approval and related data for the authorizer server 160 to make the approval decisions… receiving the definition of the policy includes: providing a list of candidate actions and/or conditions for a domain, each action or condition corresponding to a machine-code subroutine object that is stored: receiving, from the domain, a selection of actions and/or conditions to define the policy, wherein a selected action or condition corresponds to a component of the policy, and wherein generating the machine-code syntax tree includes: selecting a set of machine-code subroutine objects that correspond to the selection of actions and/or conditions that define the policy.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Manapat with the ability to define the policies as machine-code syntax trees as taught by John, doing so allows the workflows to be implemented using syntax trees so that the workflows are reusable and can be implemented in a highly scalable fashion [0038].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY S CUNNINGHAM II whose telephone number is (313)446-6564. The examiner can normally be reached Mon-Fri 8:30am-4pm.
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, Bennett Sigmond can be reached at 303-297-4411. 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.
GREGORY S. CUNNINGHAM II
Primary Examiner
Art Unit 3694
/GREGORY S CUNNINGHAM II/Primary Examiner, Art Unit 3694
Prosecution Insights