DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 have been examined in this application. This communication is the first action on the merits.
Priority
Application 19/205,285 filed on May 12, 2025 is a CON of 17/947,956 09/19/2022.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. § 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. § 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. § 112(b) or 35 U.S.C. § 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
The scope of the independent claims is indefinite because it is unclear how the recited “indication that the first network operation should be blocked” corresponds to the subsequent step of “blocking . . . the second network operation.” The claim appears to require a blocking determination for a first network operation while performing the blocking action on a different, second network operation. However, the specification describes determining whether a particular potential transaction should be rejected and, if so, blocking that same transaction. In particular, the specification discloses “[0064] If it is determined that the potential transaction should be rejected, then at operation 412 the potential transaction is blocked. If it is determined that the potential rejection should be allowed, then at operation 414 the potential transaction is not blocked.” Therefore, it is unclear whether the claim intends the first and second network operations to be the same operation or different operations, rendering the scope of the claim uncertain.
Appropriate correction is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,327,250. Although the claims at issue are not identical, they are not patentably distinct from each other because as the claim table shows the application claims are broader and the entire scope of the reference claim falls within the scope of the examined claim.
Claim 1 of the present application 19/205,285 is broader and fully anticipated by claim 1 of U.S. Patent No. 12,327,250. The mapping of claim 1 of the present application 19/205,285 to claim 1 of U.S. Patent No. 12,327,250 is substantially similar to: the mapping of claim 8 of the present application 19/205,285 to claim 8 of U.S. Patent No. 12,327,250; and the mapping of claim 14 of the present application 19/205,285 to claim 15 of U.S. Patent No. 12,327,250 as noted below. Therefore, claims 8 and 14 of the present application 19/205,285 is rejected on similar grounds.
Application 19/205,285
US Patent No. 12,327,250
1. A computer-implemented method for dynamically configuring a network operation evaluation machine learning model comprising:
executing, by at least one processor, using historical network operation data associated with a set of computing infrastructures, the network operation evaluation machine learning model to predict whether to allow or block a first network operation based on whether a predicted likelihood of operational fraud satisfies a fraud detection threshold;
1. A method comprising:
accessing, by a device, historical data associated with historical network operations related to a set of computing infrastructures;
monitoring, by the at least one processor, one or more outcome indicators for the first network operation;
for each computing infrastructure of the set of computing infrastructures, extracting, by the device, one or more features from the historical data related to the computing infrastructure;
training, by the at least one processor, using at least the monitored one or more outcome indicators, a second machine learning model to generate a customized fraud detection threshold for the set of computing infrastructures;
passing, by the device, the one or more extracted features to a second machine learning algorithm to train a set of instances of a second machine learning model corresponding to each computing infrastructure of the set of computing infrastructures, each trained instance of the second machine learning model configured to output a determination of whether to allow or block a potential network operation based on (i) one or more features of the potential network operation, (ii) a decline score generated for the potential network operation by a first machine learning model, and (iii) a fraud tolerance threshold assigned to the computing infrastructure corresponding to the trained instance of the second machine learning model;
in response to receiving an indication of a second network operation, identifying, by the at least one processor, a computing infrastructure of the set of computing infrastructures that is associated with the second network operation;
executing, by the at least one processor, the second machine learning model using data associated with the identified computing infrastructure to receive a predicted customized fraud detection threshold;
in response to obtaining a request for a first network operation with a first computing infrastructure, accessing, by the device, the first machine learning model trained by a first machine learning algorithm, the first machine learning model trained to output a first decline score indicative of a probability that a potential network operation is fraudulent;
adjusting, by the at least one processor, the fraud detection threshold of the network operation evaluation machine learning model based on the predicted customized fraud detection threshold;
executing, by the at least one processor, the network operation evaluation machine learning model to predict whether to allow or block the second network operation; and
executing, by the service, a first instance of the second machine learning model corresponding to the first computing infrastructure to evaluate the first network operation, based on the first decline score and a first fraud tolerance threshold assigned to the first computing infrastructure; and
in response to an indication that the first network operation should be blocked, blocking, by the at least one processor, the second network operation.
in response to an indication from the first instance of the second machine learning model that the first network operation should be blocked, blocking, at the device, the first network operation such that the first network operation is prevented from proceeding externally outside of the device for further authentication processing.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. (MPEP 2106). The claims are directed to a method, system, and apparatus which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 1 recites the limitations of:
A computer-implemented method for dynamically configuring a network operation evaluation machine learning model comprising: executing, by at least one processor, using historical network operation data associated with a set of computing infrastructures, the network operation evaluation machine learning model to predict whether to allow or block a first network operation based on whether a predicted likelihood of operational fraud satisfies a fraud detection threshold;
monitoring, by the at least one processor, one or more outcome indicators for the first network operation;
training, by the at least one processor, using at least the monitored one or more outcome indicators, a second machine learning model to generate a customized fraud detection threshold for the set of computing infrastructures;
in response to receiving an indication of a second network operation, identifying, by the at least one processor, a computing infrastructure of the set of computing infrastructures that is associated with the second network operation;
executing, by the at least one processor, the second machine learning model using data associated with the identified computing infrastructure to receive a predicted customized fraud detection threshold;
adjusting, by the at least one processor, the fraud detection threshold of the network operation evaluation machine learning model based on the predicted customized fraud detection threshold;
executing, by the at least one processor, the network operation evaluation machine learning model to predict whether to allow or block the second network operation; and
in response to an indication that the first network operation should be blocked, blocking, by the at least one processor, the second network operation.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to determine a likelihood that a financial transaction is fraudulent or malicious (e.g., chargebacks or disputes) and to determine a suitable threshold for a merchant. Features utilized to make those determinations include time features (day of week, hour of day, timezone, etc.), customer data (email address, billing address, time since created, etc.), client data (Internet Protocol address, request headers, browser, operating system, session identification, etc.), card metadata (bank identification number (BIN), bank, country, prepaid, debit or credit, etc.), payment data (amount, currency, shipping address, etc.), and historical counters across many dimensions (card, email address, customer, merchant, IP address, etc.). This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Furthermore, the claims cover collecting, analyzing, and transmitting data to determine a likelihood that a financial transaction is fraudulent or malicious (e.g., chargebacks or disputes) and to determine a suitable threshold for a merchant. As the steps could be performed by a human without a computer, the claim limitations fall within the mental processes grouping, and the claim recites an abstract idea.
Finally, the claims recite the use of a network operation evaluation machine learning model and a second machine learning model to determine a likelihood that a financial transaction is fraudulent or malicious (e.g., chargebacks or disputes) and to determine a suitable threshold for a merchant. This is a mathematical calculation or concept.
In the alternative, the network operation evaluation machine learning model and second machine learning model is considered a technology that is recited at a high level of generality and merely applied as a tool to implement the abstract idea.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting a “A computer-implemented method for dynamically configuring a network operation evaluation machine learning model comprising:”, “at least one processor”, “a set of computing infrastructures”, “consuming application”, and “a second machine learning model”, to perform the steps of “executing”, “monitoring”, “training”, “adjusting”, and “blocking”, nothing in the claim elements preclude the steps from practically being a certain method of organizing human activity, mental process, or mathematical calculation. The claim as a whole does not integrate the judicial exception into a practical application. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to determine a likelihood that a financial transaction is fraudulent or malicious (e.g., chargebacks or disputes) and to determine a suitable threshold for a merchant in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the specification discloses “[00119] FIG. 8 is a block diagram illustrating components of a machine 800, according to some example embodiments, that is able to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, FIG. 8 shows a diagrammatic representation of the machine 800 in the example form of a computer system, within which instructions 810 (e.g., software, a program, an application, an applet, an app, or other executable code), for causing the machine 800 to perform any one or more of the methodologies discussed herein, may be executed. As such, the instructions 810 may be used to implement modules or components described herein. The instructions 810 transform the general, non-programmed machine 800 into a particular machine 800 programmed to carry out the described and illustrated functions in the manner described. In alternative
embodiments, the machine 800 operates as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine 800 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine 800 may comprise, but not be limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a personal digital assistant (PDA), an entertainment media system, a cellular telephone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the instructions 810, sequentially or otherwise, that specify actions to be taken by the machine 800. Further, while only a single machine 800 is illustrated, the term "machine" shall also be taken to include a collection of machines that individually or jointly execute the instructions 810 to perform any one or more of the methodologies discussed herein. [00120] The machine 800 may include processors 804 (including processors 808 and 812), memory/storage 806, and I/O components 818, which may be configured to communicate with each other such as via a bus 802. The memory/storage 806 may include a memory 814, such as a main memory or other memory storage, and a storage unit 816, both accessible to the processors 804 such as via the bus 802. The storage unit 816 and memory 814 store the instructions 810 embodying any one or more of the methodologies or functions described herein. The instructions 810 may also reside, completely or partially, within the memory 814, within the storage unit 816, within at least one of the processors 804 (e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine 800. Accordingly, the memory 814, the storage unit 816, and the memory of the processors 804 are examples of machine- readable media.”
Furthermore, the specification discloses “[0032] The first machine learning algorithm 312 may also be selected from among many other different potential supervised or unsupervised machine learning algorithms. Examples of supervised learning algorithms include artificial neural networks, Bayesian networks, instance- based learning, support vector machines, linear classifiers, quadratic classifiers, k-nearest neighbor, decision trees, and hidden Markov models. [0033] In an example embodiment, the first machine learning algorithm 312 is a supervised gradient boosted trees algorithm, such as an XG Boost machine learning algorithm. XG Boost supports a gradient boosting algorithm, stochastic gradient boosting, and regularized gradient boosting. It makes efficient use of compute time and memory resources and is sparse-aware (about to automatically handle missing data values), supporting block structure (which allows the parallelization of tree construction), and supporting retraining. [0034] In other example embodiments, the first machine learning algorithm 312 is a deep neural network, or a combination of deep neural network components and XG Boost components.” “[0040] The second machine learning algorithm 316 may also be selected from among many other different potential supervised or unsupervised machine learning algorithms. Examples of supervised learning algorithms include artificial neural networks, Bayesian networks, instance-based learning, support vector machines, linear classifiers, quadratic classifiers, k-nearest neighbor, decision trees, and hidden Markov models. [0041] In an example embodiment, the second machine learning algorithm 316 is a supervised gradient boosted trees algorithm, such as an XG Boost machine learning algorithm. XG Boost supports a gradient boosting algorithm, stochastic gradient boosting, and regularized gradient boosting. It makes efficient use of compute time and memory resources and is sparse-aware (about to automatically handle missing data values), supporting block structure (which allows the parallelization of tree construction), and supporting retraining. [0042] In other example embodiments, the second machine learning algorithm is a deep neural network, or a combination of deep neural network components and XG Boost components.”
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using ““A computer-implemented method for dynamically configuring a network operation evaluation machine learning model comprising:”, “at least one processor”, “a set of computing infrastructures”, “consuming application”, and “a second machine learning model”, to perform the steps of “executing”, “monitoring”, “training”, “adjusting”, and “blocking”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to determine a likelihood that a financial transaction is fraudulent or malicious (e.g., chargebacks or disputes) and to determine a suitable threshold for a merchant in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”.
Claims 8 and 14 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Claim 8 recites the additional elements of “A computer system for dynamically configuring a network operation evaluation machine learning model comprising a server configured to:”.
Claim 14 recites the additional elements of “A computer system for dynamically configuring a network operation evaluation machine learning model comprising a computer readable medium having a set of non-transitory instructions that when executed by a processor, cause the processor to:”.
For similar reasons as explained above with regard to claim 1, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 1.
Dependent claims 2-7, 9-13, and 15-20 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 1-20 are not patent-eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6, 8-11, 13, 14-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Hayman, U.S. Patent Application Publication Number 2021/0035119; in view of Horesh, U.S. Patent Application Publication Number 2021/0182877.
As per claim 1,
Hayman explicitly teaches:
A computer-implemented method for dynamically configuring a network operation evaluation machine learning model comprising: executing, by at least one processor, using historical network operation data associated with a set of computing infrastructures, the network operation evaluation machine learning model to predict whether to allow or block a first network operation based on whether a predicted likelihood of operational fraud satisfies a fraud detection threshold;
(Hayman US20210035119 at paras. 33-35, 129-135) ("[0035] If the fraudulent invoice detection model predicts a new invoice is not very likely to be fraudulent, the new invoice is passed along to the person being asked to pay the invoice and the person is allowed to pay the invoice without further analysis. However, if the fraudulent invoice detection model predicts a new invoice is very likely to be fraudulent, the new invoice is blocked, and the person is not allowed to pay the invoice, at least without further analysis. If the fraudulent invoice detection model predicts a new invoice is neither very likely or unlikely to be fraudulent, then the person being asked to pay the invoice can be alerted to the potentially fraudulent nature of the new invoice and advised to make sure that the new invoice is legitimate before making any payment associated with the invoice." "[0130] At operation 707, the historical invoice data of operation 705 is processed using any of the methods discussed herein with respect to FIGS. 1, 2, and 3 to identify and extract invoice feature data representing one or more invoice features for each of the plurality of invoices represented in the historical invoice data." "[0131] Once invoice feature data is identified and extracted for each of the plurality of invoices represented in the historical invoice data at operation 707, process flow proceeds to operation 709. [0132] At operation 709, the fraudulent merchant data of operation 703 is used to identify fraudulent invoice feature data representing invoice features associated with fraudulent merchant invoices using any of the methods discussed above with respect to FIG. 1. [0133] Once the fraudulent merchant data is used to identify fraudulent invoice feature data representing invoice features associated with fraudulent merchant invoices at operation 709, process flow proceeds to operation 711. [0134] At operation 711, the fraudulent invoice feature data of operation 709 is used to train a machine learning-based fraudulent invoice detection model, using any of the methods discussed herein with respect to FIGS. 1 and 4, to generate a fraudulent invoice score for subsequent invoice data. The fraudulent invoice score can indicate a determined probability that an invoice represented by the subsequent invoice data is fraudulent.")
monitoring, by the at least one processor, one or more outcome indicators for the first network operation;
(Hayman US20210035119 at paras. 42-43) ("[0043] As seen in FIG. 1, historical invoice database 112 also includes fraudulent merchant data 114. Fraudulent merchant data 114 can include a listing of known fraudulent merchants. Fraudulent merchant data 114 can be obtained from multiple sources including, but not limited to, the results of analysis of historical invoices determined to be fraudulent by human fraud detection analysts. In these cases, fraudulent merchant data 114 is obtained as a result of analysis of historical invoices that were determined to be fraudulent, typically after charges associated with these invoices were challenged by the owners of the payment accounts used to pay the fraudulent voices. In other cases, fraudulent merchant data 114 can be obtained from third parties, including various watchdog organizations or other third-party sources of fraudulent merchant data 114 indicating known fraudulent merchants, as discussed herein, or known in the art at the time of filing, or as become known after the time of filing. In other cases, fraudulent merchant data 114 can be obtained from data processed and generated by machine learning-based fraudulent invoice detection models, such as trained machine learning-based fraudulent invoice detection model 171.")
in response to receiving an indication of a second network operation, identifying, by the at least one processor, a computing infrastructure of the set of computing infrastructures that is associated with the second network operation;
(Hayman US20210035119 at paras. 92-95) ("[0092] As seen in FIG. 5, once received from merchant computing system 533, subsequent invoice data 513 is provided to invoice text identification and extraction module 121. Invoice text identification and extraction module 121 is discussed above with respect to FIG. 1 and is identically implemented in FIG. 5 to process subsequent invoice data 513 as discussed above. [0093] Therefore, at invoice text identification and extraction module 121 one or more methods are used to identify and extract invoice text data 522 associated with subsequent invoice data 513. Invoice text data 522 is similar to invoice text data 122 discussed above with respect to FIG. 1.")
executing, by the at least one processor, the network operation evaluation machine learning model to predict whether to allow or block the second network operation; and
(Hayman US20210035119 at paras. 17-20) ("[0018] Once the machine learning-based fraudulent invoice detection model is trained, it is deployed in a runtime environment to generate fraudulent invoice scores for subsequent, or new, invoices before those invoices are paid by, and in some cases before the invoices are provided to, the parties being asked to pay the invoices, i.e., the potential payors associated with the invoices. Once a fraudulent invoice score for a subsequent invoice is generated, the fraudulent invoice score for the subsequent invoice is compared with one or more threshold fraudulent invoice scores. The one or more threshold fraudulent invoice scores can be associated with one or more respective protective actions to be taken. [0019] For instance, if the fraudulent invoice score for a subsequent invoice is less than a first, or low, threshold fraudulent invoice score, the subsequent invoice is passed through to the indicated payor, or the payor is allowed to pay the invoice, without further analysis. However, if the fraudulent invoice score for a subsequent invoice is greater than a second, or high, threshold fraudulent invoice score, one or more of the following protective actions are taken: the merchant associated subsequent invoice is added to the known fraudulent merchant list of the fraudulent merchant data; the subsequent invoice is blocked, or the payor is not allowed to pay the invoice; all future invoices from the now identified fraudulent merchant are blocked; and all future attempted payments to the now identified fraudulent merchant are blocked.")
in response to an indication that the first network operation should be blocked, blocking, by the at least one processor, the second network operation.
(Hayman US20210035119 at paras. 17-20) ("[0018] Once the machine learning-based fraudulent invoice detection model is trained, it is deployed in a runtime environment to generate fraudulent invoice scores for subsequent, or new, invoices before those invoices are paid by, and in some cases before the invoices are provided to, the parties being asked to pay the invoices, i.e., the potential payors associated with the invoices. Once a fraudulent invoice score for a subsequent invoice is generated, the fraudulent invoice score for the subsequent invoice is compared with one or more threshold fraudulent invoice scores. The one or more threshold fraudulent invoice scores can be associated with one or more respective protective actions to be taken. [0019] For instance, if the fraudulent invoice score for a subsequent invoice is less than a first, or low, threshold fraudulent invoice score, the subsequent invoice is passed through to the indicated payor, or the payor is allowed to pay the invoice, without further analysis. However, if the fraudulent invoice score for a subsequent invoice is greater than a second, or high, threshold fraudulent invoice score, one or more of the following protective actions are taken: the merchant associated subsequent invoice is added to the known fraudulent merchant list of the fraudulent merchant data; the subsequent invoice is blocked, or the payor is not allowed to pay the invoice; all future invoices from the now identified fraudulent merchant are blocked; and all future attempted payments to the now identified fraudulent merchant are blocked.")
Hayman does not explicitly teach, however, Horesh does teach:
training, by the at least one processor, using at least the monitored one or more outcome indicators, a second machine learning model to generate a customized fraud detection threshold for the set of computing infrastructures;
(Horesh US20210182877 at paras. 69-72, 129-133) ("[0070] When probable business segment for the uncategorized merchant data 230 includes business segment probability data 231, the value or score indicated by business segment probability data 231 is compared at threshold compare module 250 to a predetermined threshold business segment probability represented by threshold business segment probability data 240. [0071] If a business segment probability or probability score for a specific business segment represented by business segment probability data 231 is greater than a threshold business segment probability or probability score represented by threshold business segment probability data 240, then the specific business segment is assigned to the previously uncategorized merchant at business segment assignment module 260." "[0132] At operation 607, the categorized merchant financial document training data is used to train a machine learning-based merchant business segment prediction model used to generate probable business segment data for subject merchants based on subject merchant financial document data associated with the subject merchants using any of the methods discussed above with respect to FIG. 1.")
executing, by the at least one processor, the second machine learning model using data associated with the identified computing infrastructure to receive a predicted customized fraud detection threshold;
(Horesh US20210182877 at paras. 66-67) ("[0066] As seen in FIG. 1, once uncategorized merchant financial document feature data 224 is generated, uncategorized merchant financial document feature data 224 is provided to trained machine learning-based merchant business segment prediction model 171. Trained machine learning-based merchant business segment prediction model 171 can be a machine learning-based merchant business segment prediction model trained as described above with respect to FIG. 1 and the description of model training environment 101. [0067] Once uncategorized merchant financial document feature data 224 is provided to trained machine learning-based merchant business segment prediction model 171, trained machine learning-based merchant business segment prediction model 171 generates probable business segment for the uncategorized merchant data 230. Probable business segment for the uncategorized merchant data 230 includes data indicating one or more business segments associated with the uncategorized merchant.")
adjusting, by the at least one processor, the fraud detection threshold of the network operation evaluation machine learning model based on the predicted customized fraud detection threshold;
(Horesh US20210182877 at paras. 69-72, 129-133) ("[0069] Probable business segment for the uncategorized merchant data 230 can also include business segment probability data 231 indicating the probability that the uncategorized merchant is associated with each specific business segment and/or business segment code indicated in probable business segment for the uncategorized merchant data 230. In various embodiments, business segment probability data 231 can represent a business segment probability score for each specific business segment and/or business segment code indicated in probable business segment for the uncategorized merchant data 230. [0070] When probable business segment for the uncategorized merchant data 230 includes business segment probability data 231, the value or score indicated by business segment probability data 231 is compared at threshold compare module 250 to a predetermined threshold business segment probability represented by threshold business segment probability data 240. [0071] If a business segment probability or probability score for a specific business segment represented by business segment probability data 231 is greater than a threshold business segment probability or probability score represented by threshold business segment probability data 240, then the specific business segment is assigned to the previously uncategorized merchant at business segment assignment module 260.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hayman and Horesh, because it allows for an improved system to use machine learning techniques to automatically and accurately determine the business segment associated with a merchant user of a data management system. (Horesh at Abstract and paras. 2-12).
As per claim 2,
Hayman explicitly teaches:
wherein monitoring the one or more outcome indicators comprises tracking a number of chargebacks or disputes associated with the first network operation.
(Hayman US20210035119 at paras. 38-44) ("[0043] As seen in FIG. 1, historical invoice database 112 also includes fraudulent merchant data 114. Fraudulent merchant data 114 can include a listing of known fraudulent merchants. Fraudulent merchant data 114 can be obtained from multiple sources including, but not limited to, the results of analysis of historical invoices determined to be fraudulent by human fraud detection analysts. In these cases, fraudulent merchant data 114 is obtained as a result of analysis of historical invoices that were determined to be fraudulent, typically after charges associated with these invoices were challenged by the owners of the payment accounts used to pay the fraudulent voices. In other cases, fraudulent merchant data 114 can be obtained from third parties, including various watchdog organizations or other third-party sources of fraudulent merchant data 114 indicating known fraudulent merchants, as discussed herein, or known in the art at the time of filing, or as become known after the time of filing. In other cases, fraudulent merchant data 114 can be obtained from data processed and generated by machine learning-based fraudulent invoice detection models, such as trained machine learning-based fraudulent invoice detection model 171.")
As per claim 3,
Hayman explicitly teaches:
further comprising: retraining, by the at least one processor, the network operation evaluation machine learning model using additional labeled data generated after allowing or blocking network operations.
(Hayman US20210035119 at paras. 104-110) ("[0105] At block payment to merchant/add merchant to fraudulent merchant list module 585, one or more of the following protective actions are taken: the merchant associated with the invoice represented by subsequent invoice data 513 is added to feedback/improvement data 191 and then to the known fraudulent merchant list of the fraudulent merchant data 114 of FIG. 1; the invoice represented by subsequent invoice data 513 is blocked from user computing system 593, and the payor is not allowed to pay the invoice represented by subsequent invoice data 513; all future invoices from the now identified fraudulent merchant of the invoice represented by subsequent invoice data 513 are blocked; and all future attempted payments to the now identified fraudulent merchant of the invoice represented by subsequent invoice data 513 are blocked. In addition, as discussed below, the subsequent invoice feature data 551 associated with subsequent invoice data 513, and other information about the invoice represented by subsequent invoice data 513, is collected in feedback/improvement data 191 and sent to model training environment 101 of FIG. 1 for use by model training module 170." "[0108] As seen in FIG. 5, the results of each of the processing modules 581, 583, and 585, along with relevant portions of the subsequent invoice feature data 551, and other data associated with subsequent invoices, such as the invoice represented by subsequent invoice data 513, is collected as feedback/improvement data 191 and then provided to model training environment 101 of FIG. 1. [0109] At model training environment 101 of FIG. 1, portions of feedback/improvement data 191 are provided to fraudulent merchant data 114 to update the list of fraudulent merchants in fraudulent merchant data 114, and to model training module 170. [0110] At model training module 170 feedback/improvement data 191, including newly defined or identified fraudulent invoice feature data 161 and fraudulent invoice determination labels, is used periodically re-train and iteratively update and improve trained machine learning-based fraudulent invoice detection model 171.")
As per claim 4,
Hayman explicitly teaches:
wherein the historical network operation data further comprise enriched features that include a geographic location associated with the first network operation.
(Hayman US20210035119 at paras. 42-43) ("[0053] Invoice feature list 200, in this specific illustrative example, also includes company or payee address present feature 209. Company or payee address present feature 209 is a Boolean feature directed to determining if an address is included in the invoice that is associated with the company or merchant purportedly generating the invoice. Company or payee address present feature 209 is included as an invoice feature because it is often the case that fraudulent invoices do not include a company or payee address. Consequently, the absence of a company or payee address i.e., a “false” invoice feature data entry or state for company or payee address present feature 209, can be indicative of a fraudulent invoice. [0054] Invoice feature list 200, in this specific illustrative example, also includes payor address present feature 211. Payor address present feature 211 is a Boolean feature directed to determining whether a given invoice includes an address for the party being presented with the invoice, i.e. the potential payor of the invoice. Payor address present feature 211 is included as an invoice feature because it is often the case that fraudulent invoices do not include a payor address. Consequently, the absence of a payor address i.e., a “false” invoice feature data entry or state for payor address present feature 211 can be indicative of a fraudulent invoice." "[0065] Invoice 300 also includes a partial company address of “US” and therefore is subject to a company or payee address present feature 209 data value of “false” because the company address is not a complete mailing address or a physical location. Likewise, invoice 300 is subject to a company website present feature 207 data value of “false” because no company website is present in invoice 300. Likewise, invoice 300 does not include an address for the listed “bill to” payor “Robin Singh” so a payor address present feature 211 data value of “false” is given.")
As per claim 6,
Hayman does not explicitly teach, however, Horesh does teach:
wherein the computing infrastructures are partitioned into a plurality of fraud tolerance segments, and executing the second machine learning model comprises supplying, as an input feature, a segment identifier associated with the identified computing infrastructure so that the predicted customized fraud detection threshold is generated in view of the fraud tolerance segment.
(Horesh US20210182877 at paras. 9-19, 69-72, 129-133) ("[0016] Therefore, the systems and methods of the present disclosure use machine learning techniques to automatically and accurately determine the business segment associated with a merchant user of a data management system. Unlike traditional systems which rely on self-reported business segment identification, using the systems and methods of the present disclosure, the business segment is identified using machine learning-based analysis of the actual financial documents generated by, and associated with, the merchant. Consequently, the systems and methods of the present disclosure provide a technical solution to the technical problem of automatically, accurately, effectively, and efficiently determining the business segment associated with a merchant user of a data management system." "[0069] Probable business segment for the uncategorized merchant data 230 can also include business segment probability data 231 indicating the probability that the uncategorized merchant is associated with each specific business segment and/or business segment code indicated in probable business segment for the uncategorized merchant data 230. In various embodiments, business segment probability data 231 can represent a business segment probability score for each specific business segment and/or business segment code indicated in probable business segment for the uncategorized merchant data 230. [0070] When probable business segment for the uncategorized merchant data 230 includes business segment probability data 231, the value or score indicated by business segment probability data 231 is compared at threshold compare module 250 to a predetermined threshold business segment probability represented by threshold business segment probability data 240. [0071] If a business segment probability or probability score for a specific business segment represented by business segment probability data 231 is greater than a threshold business segment probability or probability score represented by threshold business segment probability data 240, then the specific business segment is assigned to the previously uncategorized merchant at business segment assignment module 260.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hayman and Horesh, because it allows for an improved system to use machine learning techniques to automatically and accurately determine the business segment associated with a merchant user of a data management system. (Horesh at Abstract and paras. 1-19).
Claims 8 and 14 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Claims 9 and 15 are substantially similar to claim 2, thus, they are rejected on similar grounds.
Claims 10 and 16 are substantially similar to claim 3, thus, they are rejected on similar grounds.
Claims 11 and 17 are substantially similar to claim 4, thus, they are rejected on similar grounds.
Claims 13 and 19 are substantially similar to claim 6, thus, they are rejected on similar grounds.
Claims 5, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Hayman, U.S. Patent Application Publication Number 2021/0035119; in view of Horesh, U.S. Patent Application Publication Number 2021/0182877; in view of Jia, U.S. Patent Application Publication Number 2020/0134628.
As per claim 5,
Hayman and Horesh do not explicitly teach, however, Jia does teach:
wherein the second machine learning model is trained to optimize revenue.
(Jia US20200134628 at paras. 25-27, 57-58) ("[0025] In one aspect, for example, a payment system includes a merchant control action service having a plurality of integrated, machine learning models that suggest one or more merchant control actions to a merchant, in response to a purchase transaction received by the merchant. In particular, integrated, machine learning models are trained such that the suggested merchant control actions are likely to maximize profits for the merchant in association with the purchase transaction. Such merchant control actions may include, but are not limited to, actions associated with determining a risk associated with proceeding with a purchase transaction, determining a route for processing the purchase transaction, and/or determining whether to retry a declined purchase transaction or dispute (re-present) a chargeback issued on a settled purchase transaction. [0026] In an aspect, in the chain of events that happen during payment authorization/authentication and back office flow, the control actions available to the merchant are jointly/simultaneously optimized (i.e., co-optimized) by cooperating machine learning models of the present payment system to maximize profits. In an aspect, the merchant control action service optimizes the control actions together/jointly to leverage the statistical as well as causal dependencies between the success/failure of each of the control actions in matching corresponding target control actions that maximize profits of purchase transactions. Some aspects use supervised machine learning, semi-supervised machine learning, unsupervised machine learning, and/or a combination thereof to train the machine learning models to produce optimal decisions for each control action using the available features of the purchase transaction as well as the results of any previously taken control action. In an aspect, the cooperating models of the present payment system optimize a reward function associated with the expected profit from the purchase transaction. Such a reward function may account for parameters such as COGs, margins, chargeback fees, re-presentment fees, chargeback program penalties, etc." "[0057] Accordingly, in an aspect, for example, the number of risk score bins that have positive sub net revenue among the regular purchase transactions 125 is larger than the number of risk score bins that have positive sub net revenue among the retried purchase transactions 125. For example, in an aspect, assuming a higher risk score is indicative of a higher fraud risk, and assuming that each risk score is a number selected between 0 and 9999 such that when divided by 10000 provides the probability of fraud, a risk score lower than 3000 may retain a positive sub net revenue for regular purchase transactions 125, while by contrast, only a risk score lower than 700 may retain a positive sub net revenue for retried purchase transactions 125. Accordingly, in an aspect, a retry model 144 that properly re-scores the rejected purchase transactions 125 to select retry candidate purchase transactions 125 and retry payment processors 150 may significantly improve the bank acceptance rate and still maintain low fraud rate.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hayman, Horesh, and Jia, because it allows for an improved machine learning system for providing control actions. In particular, integrated, machine learning models are trained such that the suggested merchant control actions are likely to maximize profits for the merchant in association with the purchase transaction. Such merchant control actions may include, but are not limited to, actions associated with determining a risk associated with proceeding with a purchase transaction, determining a route for processing the purchase transaction, and/or determining whether to retry a declined purchase transaction or dispute (re-present) a chargeback issued on a settled purchase transaction. (Jia at Abstract and paras. 1-25).
Claims 12 and 18 are substantially similar to claim 5, thus, they are rejected on similar grounds.
Claims 7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hayman, U.S. Patent Application Publication Number 2021/0035119; in view of Horesh, U.S. Patent Application Publication Number 2021/0182877; in view of He, U.S. Patent Application Publication Number 2025/0021837.
As per claim 7,
Hayman and Horesh do not explicitly teach, however, He does teach:
wherein blocking the second network operation comprises rejecting the second network operation prior to submission to an authorization entity.
(He US20250021837 at paras. 123-125) ("[0124] At 970, the model can be implemented at the inference platform with the identified combination of the set of settings. For example, a combination of set of settings can include string operators in a first layer (e.g., a tokenizing process) assigned to CPUs, and matrix operators in rest layers (e.g., add or multiplication layers) assigned to GPUs. Further, a series of access requests requesting access to a resource can be forwarded to the model. The model can provide, for each access request, a determination of whether to grant access to the resource or deny access to the resource. Based on the determination by the model, access to a resource (e.g., a secure data element) can be provided to a specified entity (e.g., an authorizing entity as part of an authorization request message).")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hayman, Horesh, and He, because it allows for an improved machine learning system that can provide, for each access request, a determination of whether to grant access to the resource or deny access to the resource. Based on the determination by the model, access to a resource (e.g., a secure data element) can be provided to a specified entity (e.g., an authorizing entity as part of an authorization request message). (He at Abstract and paras. 1-7, 124).
Claim 7 is substantially similar to claim 20, thus, it is rejected on similar grounds.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9:00-5:00.
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, Christine Tran can be reached on 571-272-8103. 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.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights