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 .
DETAILED ACTION
1. This office action is in response to an amendment received on 3/9/26 for patent application 18/915,845.
2. Claims 1, 11, 13-14, 20 are amended.
3. Claims 1-20 are pending.
Response to Arguments
Applicant argues #1
Objections to the Claims
The Non-Final Office Action objects to claim 14 under 37 C.F.R. § 1.75 as being a substantial duplicate of claim 13. In response, Applicant has amended claims 13 and 14 as set forth above and respectfully requests that this objection be withdrawn.
Examiner Response
The objection to claims 14 has been withdrawn.
Applicant argues#2
III. Double Patenting Rejection
Claims 1, 11, and 20 stand rejected under the judicially created doctrine of obviousness type double patenting as being unpatentable over claims 1, 10, and 20 of copending U.S. Application No. 18/918,443 (hereinafter "the '443 app"). Applicant respectfully traverses this rejection.
While Applicant does not concede the propriety of this rejection, Applicant respectfully requests that this rejection be held in abeyance until all other rejections are withdrawn.
Examiner Response
Examiner respectfully disagrees.
Application is pointed to the MPEP:
MPEP Section 804 states:
1. Provisional Nonstatutory Double Patenting Rejections
A complete response to a nonstatutory double patenting (NDP) rejection is either a reply by applicant showing that the claims subject to the rejection are patentably distinct from the reference claims or the filing of a terminal disclaimer in accordance with 37 CFR 1.321 in the pending application(s) with a reply to the Office action (see MPEP § 1490 for a discussion of terminal disclaimers). Such a response is required even when the nonstatutory double patenting rejection is provisional.
As filing a terminal disclaimer, or filing a showing that the claims subject to the rejection are patentably distinct from the reference application’s claims, is necessary for further consideration of the rejection of the claims, such a filing
should not be held in abeyance. Only objections or requirements as to form not necessary for further consideration of the claims may be held in abeyance until allowable subject matter is indicated
Therefore, the Double Patenting rejection is maintained.
Applicant argues#3
Step 2A, Prong One - The Claims Do Not Recite an Abstract Idea
Under Step 2A, Prong of the Alice framework, the Non-Final Office Action alleges that the pending claims are directed to an abstract idea. The Non-Final Office Action alleges that the claims are directed to the "certain methods of organizing human activity" subject matter grouping of abstract ideas and to "a commercial interaction." Non-Final Office Action at page 5. Applicant respectfully submits that the claimed subject matter does not fall into one of the enumerated subject matter groupings, e.g., mathematical groupings, certain methods of organizing human activity, and mental processes. See MPEP § 2106.04(a) (specifying enumerated subject matter groupings).
More specifically, under Step 2A, Prong One of the framework set forth in Alice, Applicant respectfully submits that the claims are not directed to certain methods of organizing human activity, including fundamental economic principles, commercial
interactions, or mental processes. For example, independent claim 1 has been amended to recite:
1. A method for collaborative fraud prevention, the method comprising the steps of:
receiving, by a processor, merchant data pertaining to a user;
receiving, by the processor, issuer data pertaining to the user; receiving, by the processor, third party metrics data pertaining to the user, wherein the third party metrics data comprises at least one selected from the group of bot detection data and phone ownership checks;
receiving, by the processor, mobile device data for a mobile device associated with the user;
applying, by the processor, a machine learning model to the merchant data, issuer data, third-party metrics, and mobile device data to make a fraud prediction;
receiving, by the processor, feedback on the fraud prediction, wherein the feedback comprises one or more transaction decisions received from at least one selected from the group of a merchant and a user; and
updating, by the processor, the machine learning model using the feedback as an input.
Applicant submits that claim 1 is not directed to fundamental economic principles or practices, commercial interactions, or a mental process. Instead, claim 1 recites a method for collaborative fraud prevention where a processor perform as specific method including the steps of "receiving merchant data pertaining to a user," "receiving issuer data pertaining to the user," "receiving third party metrics data pertaining to the user, wherein the third party metrics data comprises at least one selected from the group of bot detection data and phone ownership checks," and "receiving mobile device data for a mobile device associated with the user," "applying a machine learning model to the merchant data, issuer data, third-party metrics, and mobile device data to make a fraud prediction," "receiving feedback on the fraud prediction, wherein the feedback comprises one or more transaction decisions received from at least one selected from the group of a merchant and a user," and "updating, by the processor, the machine learning model using the feedback as an input."
These operations are not methods of organizing human activity such as commercial interactions, fundamental economic activities, or mental processes.
Examiner Response
Examiner respectfully disagrees.
The limitations (receiving, merchant data pertaining to a user; receiving, issuer data pertaining to the user; receiving, third party metrics data pertaining to the user, wherein the third party metrics data comprises at least one selected from the group of bot detection data and phone ownership checks; receiving, mobile device data; applying, to the merchant data, issuer data, third-party metrics, and mobile device data to make a fraud prediction; receiving, feedback on the fraud prediction, wherein the feedback comprises one or more transaction decisions received from at least one selected from the group of a merchant and a user) are part of the identified abstract idea, a commercial interaction, steps for fraud prediction.
The rejection is maintained.
Applicant argues#4
For example, and stated without limitation, a person cannot perform the steps of "applying, by the processor, a machine learning model to the merchant data, issuer data, third-party metrics, and mobile device data to make a fraud prediction," "receiving, by the processor, feedback on the fraud prediction, wherein the feedback comprises one or more transaction decisions received from at least one selected from the group of a merchant and a user," and "updating, by the processor, the machine learning model using the feedback as an input." Moreover, while claim 1 includes, inter alia, references to a "collaborative fraud prevention" and "fraud prediction" these words alone do not establish that the claims recite fundamental economic practices or commercial interactions.
MPEP § 2106.04(a)(2)(II) states that "methods of organizing human activity" relate to "fundamental economic principles or practices (including hedging, insurance, mitigating risk)," "commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations)," and "managing personal behavior or relationships or interactions between people, (including social activities, teaching, and following rules or instructions)." Claim 1 is directed to a specific system implementation for machine-learning basis fraud prevention, not any of the above-noted methods of organizing human activity.
MPEP § 2106.04 provides that, if the claimed subject matter does not fall into one of the subject matter groupings noted above, then the claim is patent eligible except in rare circumstances as in MPEP § 2106.04(III)(C). Applicant submits that claim 1 is patent eligible.
Examiner Response
Examiner respectfully disagrees.
The limitations ("applying, to the merchant data, issuer data, third-party metrics, and mobile device data to make a fraud prediction," "receiving, feedback on the fraud prediction, wherein the feedback comprises one or more transaction decisions received from at least one selected from the group of a merchant and a user”) is part of the identified abstract idea.
The additional elements (applying by the processor a machine learning model and updating the machine learning model using the feedback as input) is the machine learning model operating at a high level of generality, and operating in its ordinary capacity, and being used as a tool to implement the steps of the identified abstract idea, see MPEP 21065.05(f).
Furthermore, Examiner submits that detecting fraud associated with transactional data associated with a user is a business relation (a subcategory of Commercial interactions), where the user is interacting with a system/computer for the purposes of fraud detection.
Furthermore, the Federal circuit in the Alice decision, stated that fraud detection is a
long-standing business practice.
The rejection is maintained.
Applicant argues#5
Contrary to the allegations in the Non-Final Office Action the claimed subject matter includes additional elements that improve upon conventional systems and methods using identification based payment instruments in a non-conventional manner. See, e.g., Specification, paragraphs [0003]-[0007]. The method of claim 1, for example, provides for collaborative fraud prevention by which issuers may shift liability to consumer transaction fraud from merchants, who currently bear the ultimate burden of transaction fraud, to issuers, who may be comfortable bearing this risk if fraud if detection systems are sufficiently robust so as to reduce instances of transaction fraud to acceptable levels. Specification, paragraph [0040]. However, a fundamental requirement of creating a robust fraud detection and prevention system is having enough relevant data to make an informed decision. Id. While merchants have access to a large amount of relevant data that might be used to prevent such fraud, this data is not necessarily collected and not shared with the issuers making the fraud determination. As explained by the instant specification, the present application addresses these and other issues:
[00041] The present invention creates a method and system for merchants to collect and share relevant transaction and user-based data with issuers, thereby allowing for more accurate fraud predicting. The present invention incentivizes merchants to collect and share this data by issuers shifting liability for transaction fraud onto the issuers once instances of fraud are reduced to some defined level.
[00042] Further, the present invention employs a machine learning algorithm to analyze and relate the merchant data with issuer data, as well as any other data available to an issuer. The machine learning algorithm predicts the likelihood of fraud based on all of the available data and also may provide the rationale for the prediction. Use of a machine learning algorithm to predict fraud may reduce demands on traditional computer systems used for card authorization (e.g. credit card networks). Additionally, the machine learning algorithm may promote system efficiency by reducing the demands on backend systems over time to improve the functioning of computers and conserve system resources when dealing with large volumes of transaction data.
Specification, paragraphs [0041] and [0042].
Accordingly, even if claim 1 recites additional elements at a high level (which Applicant does not concede), claim 1 recites a specific technical implementation of a combination of elements that improve upon another technology or technical field. See BASCOM Global Internet Servs. V. AT&T Mobility LLC, 827 F.3d 1341, 1350, 119 USPQ2d 1236, 1242 (Fed. Cir. 2016) (inventive concept may be found in the non- conventional and non-generic arrangement of components that are individually well- known and conventional). As such, Applicant respectfully submits that the combined features above integrate the alleged abstract idea into a practical application thereof.
Examiner Response
Examiner respectfully disagrees.
Applicant argued the claims present a technical improvement. Examiner does not find this argument persuasive. Applicant’s claims do not improve technology; the underlying technology remains unaffected by the claims. Applicant is addressing a business problem (determining transactional fraud associated with a user) with a business solution. Applicant is merely using existing technology (for its intended purpose) to implement the business solution. Any improvements lie in the abstract idea itself, not in underlying technology.
The rejection is maintained.
Applicant argues#6
Step 2B - The Claims Include "Significantly More"
As noted above, the claims recite a combination of elements that improve upon another technology or technical field. The specification discloses the conventional
problem of bearing liability for fraud. Specification, paragraphs [0002] and [0003]. As discussed above, the method of claim 1, for example, provides a method for collaborative fraud prevention by which issuers may shift liability to consumer transaction fraud from merchants to issuers if fraud if detection systems are sufficiently robust so as to reduce instances of transaction fraud to acceptable levels. Specification, paragraph [0040]. The present application addresses the need to create a robust fraud detection and prevention system through, for example, the specific implementation recited by claim 1. See id.; see also id., paragraphs [0041] and [0042].
The system of claim 1 can therefore provide an improved technical solution for the use of identification-based payment instruments. Accordingly, this specific combination of features recited by claim 1, when viewed together, amount to significantly more than any alleged abstract idea and make claim 1 subject matter eligible under 35 U.S.C. § 101.
Examiner Response
Examiner respectfully disagrees.
There are no additional elements, individually or in combination that amount to significantly more than the identified abstract idea.
Also see the Response to Applicant argues#4-5 above.
The rejection is maintained.
Applicant argues#7
Applicant further respectfully requests that the rejections of claims 11 and 20 also be withdrawn, for at least the reasons discussed with respect to claim 1 and due to the subject matter recited by claims 11 and 20. In addition, Applicant respectfully requests that the rejection of claims 2-10 and 12-19 be withdrawn, at least by virtue of their dependency upon claims 1 and 11 and due to the subject matter recited by claims 2-10 and 12-19.
Examiner Response
This argument has been addressed above with respect to claim 1 above, see the Responses to Applicant argues#1-6 above.
The rejection is maintained.
Applicant argues#8
Claim Rejections - 35 U.S.C. § 102
Claims 1-4, 7, 9-11, 15, 16, and 20 stand rejected under 35 U.S.C. § 102(a)(1) as being anticipated by United States Patent Application Publication No. 2023/0059064 to Benkreira et al. (hereinafter "Benkreira"). Applicant respectfully traverses this rejection.
Applicant submits that Benkreira does not teach or suggest all features of claims 1- 4, 7, 9-11, 15, 16, and 20. For example, claim 1 has been amended to recite, inter alia, that "the third party metrics data comprises at least one selected from the group of bot detection data and phone ownership checks" and that "the feedback comprises one or more transaction decisions received from at least one selected from the group of a merchant and a user." Applicant submits that Benkreira does not teach or suggest at least these features of claim 1.
Benkreira is directed to systems and methods for fraud detection, assessment, and the transmission of fraud-prevention notifications. Benkreira, paragraphs [0001]. The Non-Final Office Action cites Benkreira as allegedly describing "receiving, by the processor, third party metrics data pertaining to the user." Non-Final Office Action at page 10, citing Benkreira, paragraphs [0062], [0099], and [0100]. However, Applicant submits that Benkreira does not teach or suggest that "the third party metrics data comprises at least one selected from the group of bot detection data and phone ownership checks," as recited by claim 1.
In addition, the Non-Final Office Action cites Benkreira as allegedly describing "receiving, by the processor, feedback on the fraud prediction," as recited by claim 1. Non- Final Office Action at pages 13-14, citing Benkreira paragraph [0070]. However, Applicant submits that Benkreira does not teach or suggest that "the feedback comprises one or more transaction decisions received from at least one selected from the group of a merchant and a user," as recited by claim 1.
For at least these reasons, Applicant submits that Benkreira does not teach or suggest all features of claim 1. Accordingly, Applicant respectfully requests that the rejection of claim 1 be withdrawn. Applicant further respectfully requests that the rejections of claims 11 and 20 also be withdrawn, for at least the reasons discussed with respect to claim 1 and due to the subject matter recited by claims 11 and 20. In addition, Applicant respectfully requests that the rejection of claims 2-4, 7, 9, 10, 15, and 16 be withdrawn, at least by virtue of their dependency upon claims 1 and 11 and due to the subject matter recited by claims 2-4, 7, 9, 10, 15, and 16.
Examiner Response
Examiner respectfully disagrees.
Para 70 of Benkreira does disclose the limitation ("the feedback comprises one or more transaction decisions received from at least one selected from the group of a merchant and a user):
[0070] The predictive models described herein can be trained on one or more training datasets, each of which can comprise one or more types of data. The training data can comprise of a plurality of transaction data (e.g. transactions submitted from one or more issuer systems between one or merchant payment system for the payment of a good or service using a payment instrument) from a plurality of different users and payment instruments, and personal and other information associated with the users. In some examples, the training datasets can comprise previously-collected data, such as data collected from previous uses of the same type of systems described herein and data collected from different types of systems. In other examples, the training datasets can comprise continuously-collected data, including continuously collected transaction, personal, and other related data. In some examples, the training dataset can include anticipated data, such as the anticipated fraudulent transactions, and other transactions and related data. In other examples, the training datasets can include previous fraud predictions for the instant system and other types of system, and can further include results data indicative of the accuracy of the previous fraud predictions. In accordance with these examples, the predictive models described herein can be training prior to use and the training can continue with updated data sets that reflect additional information
Para 70 of Benkreira discloses the training data includes data that includes plurality of transaction data submitted from one or more issuer systems for the payment of a good or service ( to execute a payment a transaction decision has to be made), and where the training can continue with updated data sets that reflect additional information.
Based on the amendment to the claim a new ground of rejection is applied, see the section 103 rejection below.
Therefore, the combination of Benkreira and Murali (US 2023/021967) are disclosing the limitations from claim 1.
The rejection is maintained.
Applicant argues#9
Claims 15 and 17 Are Not Obvious in View of Benkreira and Gupta
Claims 5 and 17 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Benkreira in view of United States Patent Application Publication No. 2018/0068395 to Gupta et al. (hereinafter "Gupta"). Applicant respectfully traverses this rejection.
Applicant submits that Benkreira and Gupta do not teach or suggest all features of claims 15 and 17, at least by virtue of their dependency upon claim 11 and due to the subject matter recited by claims 15 and 17. Accordingly, Applicant respectfully requests that the rejection of claims 15 and 17 be withdrawn.
Examiner Response
Based on the amendment to the claim a new ground of rejection is applied, see the section 103 rejection below.
Applicant argues#10
Claims 6 and 18 Are Not Obvious in View of Benkreira and Babu
Claims 6 and 18 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Benkreira in view of United States Patent Application Publication No. 2023/0186308 to Babu (hereinafter "Babu"). Applicant respectfully traverses this rejection.
Applicant submits that Benkreira and Babu do not teach or suggest all features of claims 6 and 18, at least by virtue of their dependency upon claims 1 and 11 and due to the subject matter recited by claims 6 and 18. Accordingly, Applicant respectfully requests that the rejection of claims 6 and 18 be withdrawn.
Examiner Response
Based on the amendment to the claim a new ground of rejection is applied, see the section 103 rejection below.
Applicant argues#11
Claims 8 and 19 Are Not Obvious in View of Benkreira and Gisolfi
Claims 8 and 19 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Benkreira in view of United States Patent Application Publication No. 2024/0086918 to Gisolfi et al. (hereinafter "Gisolfi"). Applicant respectfully traverses this rejection.
Applicant submits that Benkreira and Gisolfi do not teach or suggest all features of claims 8 and 19, at least by virtue of their dependency upon claims 1 and 11 and due to the subject matter recited by claims 8 and 19. Accordingly, Applicant respectfully requests that the rejection of claims 8 and 19 be withdrawn.
Examiner Response
Based on the amendment to the claim a new ground of rejection is applied, see the section 103 rejection below.
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 obviousness- type 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 Omum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and 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 a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).3. Claims 1, 11, 20 are rejected under the judicially created doctrine of obviousness type double patenting as being unpatentable over claims 1, 10,20 of copending US application no. 18/918,443, herein the *443 app.4. Although the conflicting claims are not identical, they are not patentably distinct from each other.Claims 1, 11, 20 of the instant application does not disclose “receiving by a processor, a user-based allegation of a fraudulent transaction”.
However, claim 2 of the instant application discloses, wherein the merchant data is based on a transaction request initiated by the user”.
Claims 1,10,20 of the *443 app do not disclose, “receiving by the processor, third party metrics data pertaining to the user; receiving by the processor, mobile device data for a mobile device associated with the user”.
However, claims 4&6 of the *443 app are disclosing these limitations.
Therefore it would have been obvious to a person of ordinary skill in the art to modify claims 1,10,20 of the *443 application to include the limitation, “receiving by the processor, third party metrics data pertaining to the user; receiving by the processor, mobile device data for a mobile device associated with the user”, thereby resulting in the claims of the instant application, since the claims of the instant application and the claims recited in the *443 patent indeed do perform a similar function (methods for fraud prediction).
Claim Rejections- 35 U.S.C § 101
Claim Rejections- 35 U.S.C § 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.
1. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1, 11, 20 are directed to a system, method and computer readable medium which are statutory categories of invention. (Step 1: YES).
Representative claim 1 recites the limitations of:
A method for collaborative fraud prevention, the method comprising the steps of:
receiving, by a processor, merchant data pertaining to a user;
receiving, by the processor, issuer data pertaining to the user;
receiving, by the processor, third party metrics data pertaining to the user, wherein the third party metrics data comprise at least one selected from the group of bot detection data and phone ownership checks;
receiving, by the processor, mobile device data for a mobile device associated with the user;
applying, by the processor, a machine learning model to the merchant data, issuer data, third-party metrics, and mobile device data to make a fraud prediction;
receiving, by the processor, feedback on the fraud prediction, wherein the feedback comprises one or more transactions received from at least one selected from the group of a merchant and a user; and
updating, by the processor, the machine learning model using the feedback as an input.
These limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity.
The claim recites elements that are in bold above, which covers performance of the limitation as a commercial interaction, steps for fraud prediction (e.g., receiving, merchant data pertaining to a user; receiving issuer data pertaining to the user; receiving, third party metrics data pertaining to the user, wherein the third party metrics data comprise at least one selected from the group of bot detection data and phone ownership checks; receiving, mobile device data; applying, to the merchant data, issuer data, third-party metrics, and mobile device data to make a fraud prediction; receiving, feedback on the fraud prediction, wherein the feedback comprises one or more transactions received from at least one selected from the group of a merchant and a user).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a Commercial Interaction, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas.
Claims 11,20 are abstract for similar reasons.
(Step 2A-Prong 1: YES. The claims are abstract).
This judicial exception is not integrated into a practical application. Limitations that are not indicative of integration into a practical application include: (1) Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05.f), (2) Adding insignificant extra solution activity to the judicial exception (MPEP 2106.05.g), (3) Generally linking the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05.h).
Claims 1, 11, 20 includes the following additional elements:
A processor
A mobile device
A machine learning model
A non-transitory computer readable medium
The processor, mobile device, machine learning model and non-transitory computer readable medium are recited at a high level of generality and are being used in their ordinary capacity and are being used as a tool for implementing the steps of the identified abstract idea, see MPEP 2106.05(f), where applying a computer or using a computer as a tool to perform the abstract idea is not indicative of a practical application.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea
Therefore claims 1, 11, 20 are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, there are no additional elements recited in the claim beyond the judicial exception.
Mere instructions to implement an abstract idea, on or with the use of generic computer components, or even without any computer components, cannot provide an inventive concept - rendering the claim patent ineligible. Thus claims 1,11, 20 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 2-10, 12-19 further define the abstract idea that is present in their respective independent claims 1,11, 20 and thus correspond to Certain Methods of Organizing Human Activity and hence are abstract for the reasons presented above.
Claim 9 further defines the identified abstract idea as recited in claim 1. The additional element of the communication hub is recited a high level of generality, operating in its ordinary capacity, and are being used as a tool to implement the steps of the identified abstract idea, see MPEP 2106.05(f)
Therefore, the dependent claims do not include any 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. Therefore, the dependent claims (2-10, 12-19) are directed to an abstract idea. Thus, the claims 1-20 are not patent-eligible.
Claim Rejections- 35 U.S.C § 103
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.
2. Claims 1-4, 7, 9-11, 15-16, 20 are being rejected under 35 U.S.C 103(a) as unpatentable over US 2023/0059064 to Benkreira et al, herein Benkreira in view of US 2023/0216967 to Murali et al, herein Murali.
Regarding claim 1, Benkreira discloses:
A method for collaborative fraud prevention, the method comprising the steps of:
receiving, by a processor, merchant data pertaining to a user (At least: [0089]- [0090]:
[0089] Reference is now made to FIG. 3, which depicts an exemplary process for a fraud monitoring and notification system. FIG. 3 may reference the same or similar components, and data as the system 100 in FIG. 1A, the user device 125 in FIG. 1B, the first issuer system in FIG. 1C, the process illustrated in FIG. 2 and the sequences illustrated in FIG. 4. The sequence diagram 400 At step 301 the first issuer system can receive a transaction request associated with a particular user’s payment instrument from a merchant payment system. The transaction request can be received from the merchant payment system to the first issuer system upon an attempt to conduct a transaction with the payment instrument.
[0090] At step 302, the first issuer system can extract characteristics from the transaction request. Characteristics can include, for example, payment instrument type, transaction amount, absolute location, location relative to home address, merchant name, merchant type, other merchant details, transaction name (e.g. the name of the good or service transacted for), transaction type (e.g. the type of good or service which the transaction request pertains to), merchant payment system type (e.g., type of POS system, ATM/kiosk, or internet provider), time, date last transaction date and time, and transaction frequency of use.
receiving, by the processor, issuer data pertaining to the user (At least: [0091]; Fig 3 and associated text:
[0091] At step 303, the first issuer system may identify relevant user data pertaining to the user associated with the payment instrument in the received transaction request. The relevant user data may include one or more types of transaction data, personal data, fraud data, and financial data. First issuer system may choose only the relevant user data needed by the fraud model to generate accurate and efficient predictions as to the likelihood of fraud and necessity of alerting other issuers associated with the user. The amount of user data needed depends on the fraud model. Specifically, the extent that the fraud model is tailored to the particular user. The fraud model can advantageously have already been created by the first issuer system before the transaction request is received.
;
receiving, by the processor, third party metrics data pertaining to the user (At least: [0062], [0099],[0100]);
[0062] The first issuer system 105 can have differentiated access to other third party systems (such as one or more second issuer system 135, which can, for example, be associated with different financial entities, or different lines of business of the same financial institution (or other entity) associated with the first issuer system 105), including public data source systems via private APIs. The first issuer system 105 can also have differentiated access to user devices (e.g., the user devices 125) via private device APIs. The first issuer system 105 can make calls to the private APIs utilizing a token to provide a secure communication channel between the first issuer system 105 and other third party systems. The device APIs can also provide a secure communication between the user device 125 and the first issuer system 105.
[0099] The fraud action can also include automatically transmitting a fraud notification to one or more second issuer system associated with the user. The first issuer system can determine to perform such a fraud action if the notification value exceeds a first notification threshold value. The one or more second issuers to be notified can be specified in the user’s fraud preferences. The fraud notification transmitted to the one or more second issuers can include an identification of the user, the fraud severity value, and fraud severity information, in order to alert the one or more second issuer systems of the severity of suspected fraud. The fraud severity information can include, for example, an identification and/or description of the characteristics of the transaction request which caused the first issuer system to assign a relatively high notification value thereto and other information relevant to the one or more second issuer system in determining an appropriate fraud action for a related payment instrument of the user. The fraud notification can be transmitted directly to each of the one or more second issuers, if specified in the fraud preferences, or can be transmitted to all entities associated with a financial consortium network.
[0100] One or more second issuer systems can thereafter perform a fraud action based on the fraud notification. The fraud actions of the one or more second issuer systems can be the same as the ones described with respect to the first issuer system.
Benkreira does not disclose, Murali in the same field of endeavor discloses, wherein the third party metrics data comprise at least one selected from the group of bot detection data and phone ownership checks (At least: [0015]:
[0015] To illustrate, given a single device identified by its IMSI, one feature that may be extracted from the relationship graph may comprise a number of devices that have used the same SIM card as the original device on the telecommunication network. Another feature may comprise the identities of such other device(s) (e.g., the IMEI or IMEIs of such other device(s)). Still another feature may comprise information regarding whether such other IMEI(s) are associated with multiple phone numbers, and so forth. In one example, when an existing customer applies for a new mobile device or tries to complete a sales transaction, the request may be sent via a sales front-end system to an anti-fraud platform. In one example, the anti-fraud platform may initially query a database of existing customers to obtain a list of current CTNs/IMSIs and/or IMEIs associated with the customer. The anti-fraud platform may then pass this list to the relationship graph. Features associated with the phone number(s) or device identifier(s) of the list may be extracted from the relationship graph. The features may be applied as inputs to a fraud detection/prediction model which may be configured to output a fraud score, or fraud probability, such as a machine learning model (MLM), regression model, or the like. In one example, the prediction model may take other inputs as well, such as additional information regarding a customer from other records of the telecommunication network (e.g., billing address information, which may be substantially different from an area code of a phone number currently or previously associated with the account, and so forth), third party information (such as creditworthiness, a cardholder name for a credit card used for paying account charges, etc.), and so forth. The fraud score may be passed back to the anti-fraud platform, which may be used to make a decision about whether to let a customer proceed with an application or transaction. For instance, the anti-fraud platform may alert order fulfillment services when a suspected fraud-associated phone number or device identifier aligns with significant account events, such as an upgrade or an account change (e.g., changing or adding an authorized user), or may generate reports for network personnel to identify fraud rings and the members thereof, (e.g., linked phone numbers and/or device identifiers). The anti-fraud platform may also be invoked for sales of new or added mobile phone lines in an existing or newly established account and/or where a port-in number is specified (e.g., in the case where the customer is porting a number from another carrier). In addition, the anti-fraud platform may flag certain port-in numbers for disallowing such port-ins or monitoring such port-ins, or may specify elevated risks for such port-in numbers, and so forth.
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Benkreira’s invention to include wherein the third party metrics data comprise at least one selected from the group of bot detection data and phone ownership checks in order to ensure that a fraud score can be determined by comparing additional information of a phone customer to the additional information previously associated with ther user account (Murali: [0015]).
Benkreira further discloses:
receiving, by the processor, mobile device data for a mobile device associated with the user (At least: [0045], [0047]:
[0045] The user device 125 can be any device capable of communicating via, for example, Bluetooth technology, NFC technology, WiFi Direct technology, and/or the like. The user device 125 can be associated with a user and can be configured to execute various functions to transmit and receive user data (e.g., security questions, answers to security questions, card number, account type, account balance, account limits, budget data, recent transactions, and/or the like). For example, the user device 125 could be an iPhone, iPod, iPad, and/or Apple Watch from Apple® or other mobile device running Apple’s iOS operating system, devices running Google’s Android® operating system, including, for example, smartphones running the Android® operating system and other wearable mobile devices, such as Google Glass® or Samsung Galaxy® Gear Smartwatch, devices running Microsoft’s Windows® Mobile operating system, and/or any other smartphone, smartwatch, tablet, or like device, which can include personal assistant devices incorporating systems, such as Alexa, Siri, Google Assistant, and Microsoft Cortana, including home assistant devices such as Amazon Echo, Google Home, and the like.
[0047] A current location of the user device 125 can be determined using many different technologies such as Global Positioning System (GPS) technology, Internet-based technology, etc., which can utilize location data. By way of example, location data can include, but is not limited to GPS data, assisted GPS data, IP address data, cell identification data, received signal strength indication (RSSI) data, wireless fingerprinting data, inertial sensor data (e.g., compass or magnetometer data, accelerometer data, and/or gyroscope data), barometer data, ultrasonic data (e.g., radio-frequency identification (RFID) data, near-field communication (NFC) data), Bluetooth data, and/or terrestrial transmitter data.
applying, by the processor, a machine learning model to the merchant data, issuer data, third-party metrics, and mobile device data to make a fraud prediction (At least: [0058], [0092]; claim 20:
[0092] At step 304, the first issuer system may determine a fraud severity value and a notification value by using the extracted characteristics of the transaction request and the identified relevant user data as inputs to the fraud model.
[0058] The AI engine 145 can receive transaction data (e.g. transaction requests, and completed transactions), associated personal, financial and fraud information from data storage 108 and/or database 120 and/or server 115, as depicted in FIG. 1A. AI engine can alternatively, or in addition to, receive such data from one of user device, one or more second issuers, and/or financial consortium network. AI engine 145 can utilize AI technologies to parse and process transaction, personal, fraud, and/or financial data to extract conditionally relevant meaning from such data. For example, the AI engine 145 can identify and format various fields of data (e.g. merchant names, transaction items, and the like in transaction data), and can utilize natural language processing technologies to process the data to extract conditionally relevant meaning from the data. The AI engine 145 can combine processed transaction, financial, fraud, and personal data from a plurality of users and payment instruments into a training dataset to a fraud machine learning model.
Claim 20:
20. A non-transitory computer-accessible medium having stored thereon computer-executable instructions, wherein the computer arrangement comprises a processor, and wherein, upon execution of the instructions, the computer arrangement is configured to perform procedures comprising: receiving a transaction request associated with a first instrument of a user; identifying a plurality of data fields in a received transaction request, the plurality of data fields representing a plurality of transaction characteristics comprising a merchant name, a merchant location, one or more transaction items, and a transaction amount; extracting a data value for each of the plurality of transaction characteristics; identifying user data from data extracted from the transaction request; retrieving one or more fraud application data from a user device, the user device being identified from the user data identified from the transaction request, wherein the fraud application data comprises current and historical location data associated with the first instrument of the user; determining a fraud severity value and a fraud notification value based on inputting the data values for the plurality of transaction characteristics, the one or more fraud application data and user data into a fraud machine learning model;
receiving, by the processor, feedback on the fraud prediction, wherein the feedback comprises one or more transaction decisions received from at least one selected from the group of a merchant and a user (At least: [0070]:
[0070] The predictive models described herein can be trained on one or more training datasets, each of which can comprise one or more types of data. The training data can comprise of a plurality of transaction data (e.g. transactions submitted from one or more issuer systems between one or merchant payment system for the payment of a good or service using a payment instrument) from a plurality of different users and payment instruments, and personal and other information associated with the users. In some examples, the training datasets can comprise previously-collected data, such as data collected from previous uses of the same type of systems described herein and data collected from different types of systems. In other examples, the training datasets can comprise continuously-collected data, including continuously collected transaction, personal, and other related data. In some examples, the training dataset can include anticipated data, such as the anticipated fraudulent transactions, and other transactions and related data. In other examples, the training datasets can include previous fraud predictions for the instant system and other types of system, and can further include results data indicative of the accuracy of the previous fraud predictions. In accordance with these examples, the predictive models described herein can be training prior to use and the training can continue with updated data sets that reflect additional information
; and
updating, by the processor, the machine learning model using the feedback as an input (At least: [0070]: the predictive models described herein can be training prior to use and the training can continue with updated data sets that reflect additional information.
Regarding claim 2, Benkreira and Murali disclose the method of claim 1. Benkreira further discloses wherein the merchant data is based on a transaction request initiated by the user (At least: [0089]).
Claim 15 is being rejected using the same rationale as claim 2.
Regarding claim 3, Benkreira and Murali disclose the method of claim 1. Benkreira further discloses wherein the merchant data includes the mobile device data (At least: [0047]).
Claim 16 is being rejected using the same rationale as claim 3.
Regarding claim 4, Benkreira and Murali disclose the method of claim 1. Benkreira further discloses wherein the processor sends a request for one or both of the mobile device data and the third party metrics data (At least: [0045]).
Regarding claim 7, Benkreira and Murali discloses the method of claim 1. Benkreira further discloses further comprising, sending, via the processor, a fraud notification to the mobile device associated with the user (At least: [0061], [0093]).
Regarding claim 9, Benkreira and Murali disclose the method of claim 1. Benkreira further discloses further comprising, receiving, via a communication hub, supplemental user data from a plurality of issuers (At least: [0046], [0029], [0058]).
Regarding claim 10, Benkreira and discloses the method of claim 9. Benkreira further discloses further comprising, sending, via the processor, the fraud prediction to the communication hub (At least: [0046], [0029], [0072]).
Regarding claim 11, Benkreira discloses:
A system for collaborative fraud prevention, the system comprising: a memory storing issuer data for a user; and a processor configured to (At least: [0011]) :
receive merchant data pertaining to a user (At least:[0089]-[0090]);
receive the issuer data for the user (At least: [0091], Fig 3 and associated text); receive third party metrics data pertaining to the user (At least:[0062], [0099]-[0100]);
Benkreira does not disclose, Murali in the same field of endeavor discloses, wherein the third party metrics data comprise at least one selected from the group of bot detection data and phone ownership checks (At least: [0015]).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Benkreira’s invention to include wherein the third party metrics data comprise at least one selected from the group of bot detection data and phone ownership checks in order to ensure that a fraud score can be determined by comparing additional information of a phone customer to the additional information previously associated with ther user account (Murali: [0015]).
Benkreira further discloses:
receive mobile device data for a mobile device associated with the user (At least:[0045], [0047]);
apply a machine learning model to the merchant data, issuer data, third-party metrics, and mobile device data to make a fraud prediction (At least: [0058], [0092], claim 20);
receive feedback on the fraud prediction, wherein the feedback comprises one or more transaction decisions received from at least one selected from the group of a merchant and a user (At least: [0070]); and
update the machine learning model using the feedback as an input (At least: [0070]).
Regarding claim 20, Benkreira discloses:
A computer-readable non-transitory medium comprising computer-executable instructions that, when executed by at least one processor, perform procedures comprising the steps of (At least: [0032], [0036]:
receiving, by a processor, merchant data pertaining to a user (At least: [0089]-[0090];
receiving, by the processor, issuer data pertaining to the user (At least; [0091]; Fig 3 and associated text);
receiving, by the processor, third party metrics data pertaining to the user (At least: [0062], [0099]-[0100]);
Benkreira does not disclose, Murali in the same field of endeavor discloses, wherein the third party metrics data comprise at least one selected from the group of bot detection data and phone ownership checks (At least: [0015]).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Benkreira’s invention to include wherein the third party metrics data comprise at least one selected from the group of bot detection data and phone ownership checks in order to ensure that a fraud score can be determined by comparing additional information of a phone customer to the additional information previously associated with ther user account (Murali: [0015]).
receiving, by the processor, mobile device data for a mobile device associated with the user (At least: [0045], [0047]);
applying, by the processor, a machine learning model to the merchant data, issuer data, third-party metrics, and mobile device data to make a fraud prediction (At least: [0058], [0092], claim 20);
receiving, by the processor, feedback on the fraud prediction, wherein the feedback comprises one or more transaction decisions received from at least one selected from the group of a merchant and a user (At least: [0070]); and
updating, by the processor, the machine learning model using the feedback as an input (At least: [0070]).
Regarding claim 12, Benkreira and Murali disclose the system of claim 11. Benkreira further discloses wherein the mobile device data comprises a plurality of an internet protocol address, a geo-location, and a unique device identifier (ID) (At least: [0045],[0047]).
3. Claims 5,17 are being rejected under 35 U.S.C 103(a) as being unpatentable over Benkreira in view of Murali and further in view of US 2018/0068395 to Gupta et al, herein Gupta.
Regarding claim 5, Benkreira and Murali discloses the method of claim 2. Benkreira does not disclose, Gupta in the same field of endeavor discloses wherein the transaction request is approved or denied based on the fraud prediction (At least: [0047]).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Benkreira’s invention to include wherein the transaction request is approved or denied based on the fraud prediction in order to authorize the transaction for completion (Gupta: [0044]).
Claim 17 is being rejected using the same rationale as claim 5.
4. Claims 6,18 are being rejected under 35 U.S.C 103(a) being unpatentable over Benkreira in view of Murali and further in view of US 2023/0186308 to Babu.
Regarding claim 6, Benkreira and Murali discloses the method of claim 2. Benkreira does not disclose, Babu in the same field of endeavor discloses wherein a user authentication requirement is stepped up based on the fraud prediction (At least: Fig 4: 406,408 and associated text).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Benkreira’s invention to include wherein a user authentication requirement is stepped up based on the fraud prediction in order to ensure that the network transaction is verified in a flexible manner (Babu:[0075]).
Claim 18 is being rejected using the same rationale as claim 6.
5. Claims 8,19 are being rejected under 35 U.S.C 103(a) as being unpatentable over Benkreira in view of Murali and further in view of US 2024/0086918 to Gisolfi et al, herein Gisolfi.
Regarding claim 8, Benkreira and Murali disclose the method of claim 1. Benkreira does not disclose, Gisolfi in the same field of endeavor discloses wherein upon fraud at a merchant reaching a threshold level, an issuer associated with the processor accepts liability for fraudulent transactions at the merchant (At least: [0032], [0044]).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Benkreira’s invention to include wherein upon fraud at a merchant reaching a threshold level, an issuer associated with the processor accepts liability for fraudulent transactions at the merchant in order to ensure that by using 3D secure protocol the merchant can shift liability to the issuer (Gisolfi: [0032]).
Claim 19 is being rejected using the same rationale as claim 8.
6. Claims 13-14 are being rejected under 35 U.S.C 103(a) as being unpatentable over Benkreira in view of Murali and further in view of US 2022/0383323 to Burke et al, herein Burke.
Regarding claim 13, Benkreira and Murali disclose the system of claim 11. Benkreira further discloses wherein the merchant data comprises a plurality of a user name, a user email address, and a user physical address (At least: [0022], [0048], [0060], [0075], [0080], [0058], [0075],
Benkreira does not disclose, Burke in the same field of endeavor discloses a user phone number (At least: [0026], [0031]).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Benkreira’s invention to include a user phone number in order to ensure that by including the various characteristics associating with the merchant data, the system is useful in helping users prevent making payments to fraudulent people who are posing as trusted billers (such as the user's utility companies, bank, etc. (At least: Burke: [0038]).
Regarding claim 14, Benkreira and Murali discloses the system of claim 11. Benkreira further discloses wherein the merchant data comprises a plurality of a list of historical merchant transactions, a frequency of merchant purchases, a total number of items (At least: [0048], [0060], [0075], [0080], [0058], [0075], [0059]).
Benkreira does not disclose, Burke discloses wherein the merchant data comprises a plurality of an account age for a merchant account associated with a user, recurring order information, shipping information and a merchant risk score (At least: [0022], [0028], [0038], [0025], [0026]).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to modify Benkreira’s invention to include wherein the merchant data comprises a plurality of an account age for a merchant account associated with a user, recurring order information, shipping information and a merchant risk score in order to ensure that by including the various characteristics associating with the merchant data, the system is useful in helping users prevent making payments to fraudulent people who are posing as trusted billers (such as the user's utility companies, bank, etc. (At least: Burke: [0038]).
CONCLUSION
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD Z SHAIKH whose telephone number is (571)270-3444. The examiner can normally be reached M-T, 9-600; Fri, 8-11, 3-5.
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.
/MOHAMMAD Z SHAIKH/Primary Examiner, Art Unit 3694 5/21/2026
Prosecution Insights