DETAILED ACTION
This non-final office action is in response to the claims filed on 11/24/2025.
Claims 1, 2, 11, 16, and 17 are amended.
Claims 1 – 20 are pending and have been examined on the merits.
Notice of Pre-AIA or AIA Status
The present application, filed on or after 16 March 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
USC 103 Rejection
Applicant's arguments filed 11/24/2025 with respect to claim(s) 1-20 have been considered but are not pervasive.
Applicant argues: Thomson does not teach “dynamic harvesting thresholds” or thresholds specific to a transaction facilitator.
Not persuasive – Thomson expressly teaches merchant-specific (i.e. facilitator-specific) thresholds, including thresholds based on transaction counts, aggregate amounts, and time intervals. “merchant transaction is to be declined if the merchant has attempted to obtain authorization of a threshold number of transactions (e.g., 100) in a given time interval (e.g., one hour if the merchant has attempted to obtain authorization of transactions exceeding some amount in the aggregate (e.g., $1,000,000) in a given time interval (¶ 0005).” Thomson further teaches generating facilitator-specific monitoring reports and calibrating rules based on merchant decline behavior “merchants with authorization declines above some threshold percentage (e.g., 15%) of the merchants' transactions (¶ 0137).” Therefore, Thomson teaches facilitator-specific thresholds that change based on merchant performance data (e.g., decline %), which reasonably corresponds to “dynamic” thresholds.
Applicant argues: Thomson does not teach fraud harvesting.
Not persuasive – Thomson repeatedly teaches fraud-risk rules that trigger declines based on suspicious patterns. Thomson explicitly states: “an acquirer can provide a rule stating that a merchant transaction is to be declined” when met (¶ 0005). Thomson provides multiple fraud-like indicators such as abnormal low-dollar authorization requests in high volume within a time period: “authorization requests for individual transactions less than a threshold amount (e.g., $1) in a volume greater than a default number of transactions (e.g., five) in a given interval of time (e.g., one day) (¶ 0137).”
Applicant argues: Thomson does not teach using transaction characteristics to adjust thresholds.
Not persuasive – Thomson discloses adjusting fraud rules based on transaction/merchant attributes (“transaction characteristics”) including: BIN constraints, country of issuance, card brand/type, authentication level, environment, IP address, etc. Thomson lists example characteristics such as: “the payment account used to conduct the transaction has a bank identification number (BIN) (¶ 0116),” “issued in a particular country (¶ 0116),” “card present, card not present (¶ 0128),” and “specified internet protocol (IP) address (¶ 0128).” Thus, Thomson supports that thresholds/rules can be configured using transaction characteristics, matching the claim’s use of transaction characteristics in thresholding logic.
Applicant argues: Muthukrishnan does not teach modifying response codes.
Not persuasive – Muthukrishnan expressly teaches redirecting the user via an error code and changing the code after a predetermined number of failures, which is consistent with returning a selected response once a condition/threshold is met. Muthukrishnan recites: “the request to redirect the user is in the form of an error code (Claim 1.4).” Muthukrishnan further teaches changing the error code after a threshold number of failed attempts: “transmitting a second error code to the merchant after a predetermined number of payment attempts have failed (Claim 14.12).”
Applicant argues: The claim requires sending a selected transaction request response instead of one of more original transaction request response codes.
Not persuasive – Thomson teaches declining and transmitting a decline response when thresholds are met. Muthukrishnan teaches transmitting an error code and the transmitting a second error code after a predetermined number of failed attempts. This is a clear form of response code selection and substitution once a threshold is satisfied (i.e., once a failure/attempt count is satisfied).
Applicant argues: No motivation to combine Thomson and Muthukrishnan.
Not persuasive – Thomson already teaches rule/threshold-based transaction declines at the gateway/acquirer level. Muthukrishnan teaches how to communicate a controlled response (error code redirect) and change that response after a predetermined number of failures. Therefore, a person of ordinary skilled in the art would be motivated to combine the references to enforce Thomson’s risk-based decline logic while controlling downstream behavior, reduce repeated failed attempts/feedback, and standardize how merchants/client flows handle declines via a response-code mechanism.
Applicant argues: This combination would change the principle of operation / teaches away.
Not persuasive – Thomson’s principle of operation remains the same: apply acquirer/gateway rules and decline transactions when thresholds are met. Adding Muthukrishnan’s error-code redirect merely changes how the decline is surfaced/handled, not whether Thomson’s rule triggers. Muthukrishnan does not require removing or disabling Thomson’s decline logic-rather, it provides an additional messaging mechanism for declined events.
Claim Rejections - 35 USC § 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.
The factual inquires set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1066), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Thomson et al. (US20220108331A1) hereinafter Thomson, in view of Muthukrishnan et al. (US20190279174A1) hereinafter Muthukrishnan.
Regarding Claims 1, 11, and 16. Thomson teaches:
identifying, from interactions between a set of client devices and a set of transaction facilitator network devices for a plurality of transaction facilitators, a set of network transaction requests comprising multiple account numbers and transaction request response codes in response to the set of network transaction requests;
Thomson - each of the transaction records including a primary account number (PAN) and an issuer response code indicating whether the transaction was authorized or declined by a respective issuer of the plurality of issuers. receive, via the payment processing network, a real-time stream of electronic messages generated in response to transactions initiated at a plurality of online merchant portals, each of the electronic messages including the PAN (Claim 1).
determining, utilizing a transaction request fraud detection model, dynamic harvesting thresholds for the plurality of transaction facilitators by:
Thomson - apply a detection…trained to detect…that a velocity of the transactions for a …exceeds a threshold (Claim 1). merchant transaction is to be declined if the merchant has attempted to obtain authorization of a threshold number of transactions (e.g., 100) in a given time interval (e.g., one hour if the merchant has attempted to obtain authorization of transactions exceeding some amount in the aggregate (e.g., $1,000,000) in a given time interval (¶ 0005).
determining a first dynamic harvesting threshold specific to a first transaction facilitator from the plurality of transaction facilitators by utilizing [1] a historical number of declined transaction request response codes of the first transaction facilitator over a time period,
Thomson - a standard or expected velocity…may be determined and pre-defined based upon analysis of a plurality of historical transactions (historical basis) (¶ 0024). the detection models may be further trained to identify anomalously high velocities accompanied by anomalously high numbers of declines relative to approvals/authorizations (¶ 0028). merchants with authorization declines above some threshold percentage (e.g., 15%) of the merchants' transactions (¶ 0137).
[2] a number of network transaction requests corresponding to the first transaction facilitator, and
Thomson - The detection models may monitor the transaction streams for anomalously high BIN-merchant velocities, in which an anomalously high number of transactions are attempted at a single merchant (e.g., BIN-merchant velocities that exceed a pre-defined threshold level, such as one or two standard deviations above a standard velocity or a percentage higher than a standard velocity). These events may be even more strongly indicative of a BIN attack than only monitoring BIN velocities (¶ 0026).
[3] one or more transaction characteristics of the first transaction facilitator with the transaction request fraud detection model; and
Thomson - standard BIN velocities may not be a stagnant value but may fluctuate based upon various factors, such as a date, season, and the like. For example, most standard BIN velocities may increase during a time of year when purchase levels increase (e.g., around Christmas or other major holidays) (¶ 0025).
determining a second dynamic harvesting threshold specific to a second transaction facilitator from the plurality of transaction facilitators by utilizing one or more additional transaction characteristics of the second transaction facilitator with the transaction request fraud detection model;
Thomson - the detection models also monitor velocities for BIN-merchant… at a single merchant (¶ 0026). standard BIN velocities may not be a stagnant value but may fluctuate based upon various factors, such as a date, season (¶ 0025).
determining, utilizing the transaction request fraud detection model, that a subset of network transaction requests from the set of network transaction requests comprise one or more declined network transaction request codes for the first transaction facilitator, from the plurality of transaction facilitators, corresponding to a first subset of transaction facilitator network devices;
Thomson - identify anomalously high velocities accompanied by anomalously high numbers of declines (¶ 0028). the detection models also monitor velocities for BIN-merchant pairs, which may enable more precise BIN attack monitoring and/or detection. The detection models may monitor the transaction streams for anomalously high BIN-merchant velocities, in which an anomalously high number of transactions are attempted at a single merchant (e.g., BIN-merchant velocities that exceed a pre-defined threshold level, such as one or two standard deviations above a standard velocity or a percentage higher than a standard velocity). These events may be even more strongly indicative of a BIN attack than only monitoring BIN velocities (¶ 0026).
detecting an account number harvesting incident for the first transaction facilitator based on determining the one or more declined network transaction request codes in the subset of network transaction requests from the set of client devices within the time period satisfies the first dynamic harvesting threshold for the first transaction facilitator; and
Thomson - A BIN attack may also be referred to as an account- or card-testing attack (¶ 0013). when a BIN attack is detected (either an ongoing BIN attack or a previous BIN attack detected at a later time), ADR computing device 106 is configured to retrieve all transactions that may be associated with the BIN attack. Specifically, ADR computing device 106 identifies a time period associated with the BIN attack and retrieves transactions initiated during that time period. In some embodiments, when the BIN attack is detected, ADR computing device 106 appends an attack identifier flag to the transaction records of the transactions associated with the BIN attack (e.g., initiated during the time period associated with the BIN attack). ADR computing device 106 may append the attack identifier flag to all transaction records of transactions initiated during the time period associated with the BIN attack (¶ 0062).
Thomson does not teach, however Muthukrishnan discloses:
based on satisfying the first dynamic harvesting threshold indicating the account number harvesting incident: modifying responses to additional declined network transaction requests from one or more original transaction request response codes indicating declined-reason information for the additional declined network transaction requests to a masked response code to mask the declined-reason information; and
Muthukrishnan - the user is usually not informed about the reason the card was declined, only that the transaction did not go through (¶ 0005). the payment service provider sends an error code, as part of the API response, to the merchant (¶ 0013). The same code can be passed to the merchant multiple times when the same failure happens after the payment is attempted with a new funding source. When the failure exceeds a certain number of times (e.g., 3-5), the payment service provider can choose to limit the attempts by sending a different error code to indicate that the payment cannot be recovered (i.e. a selected return code instead of the original decline detail once a threshold is hit) (¶ 0045). the request to redirect the user is in the form of an error code (masked response code – decline reasons are not provided) (Claim 7.4). transmitting a second error code…after a predetermined number of payment attempts have failed (14.12).
sending the masked response code to the set of client devices instead of the one or more original transaction request response codes.
Muthkrishnan - When a payment processor declines a transaction, an error code is sent to a merchant (Abstract). transmitting a second error code to the merchant after a predetermined number of payment attempts have failed (Claim 14.12).
Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to modify the gateway side decline of Thomson with the error-code signaling of Muthkrishnan because when Thomson rule triggers the threshold, the systems returns a selected code that avoids leaking issuer reasons and orchestrates safe retry and redirect behavior.
Regarding Claim 2. The combination of Thomson and Muthukrishnan further discloses:
The computer-implemented method of claim 1, further comprising, based on the subset of network transaction requests satisfying the first dynamic harvesting threshold indicating the account number harvesting incident, pausing a transmission of electronic communication alerts to client devices corresponding to one or more account numbers from the account numbers of the subset of network transaction requests.
Thomson - Accordingly, the ADR computing device extracts a PAN from each transaction record associated with an authorized transaction. These PANs are considered compromised as successfully “tested” by fraudsters. The ADR computing device generates a fraud attack alert that includes all of these compromised PANs and transmits the fraud attack alert to the issuer (or, in some cases, issuers) of the compromised PANs. In the example embodiment, the fraud attack alert includes instructions that cause the issuer to record or flag all of the PANs identified in the fraud attack alert as compromised or potentially compromised. Accordingly, any time a compromised/potentially compromised PAN is used to initiate a future or subsequent transaction, that transaction will undergo enhanced authentication before being authorized. Enhanced authentication may include, for example, two-factor authentication that requires an additional authentication data element be provided by a user that initiated the transaction, such as a one-time password, biometric sample, and the like. This enhanced authentication requirement imposed on the compromised/potentially compromised PAN enables a true cardholder (or other user of the payment card) to continue using the same PAN while preventing fraudulent use thereof (¶ 0035).
Regarding Claim 3. The combination of Thomson and Muthukrishnan further discloses:
The computer-implemented method of claim 1, wherein the one or more original transaction request response codes indicate an original transaction request response to the additional declined network transaction requests.
Thomson - (a) detecting an occurrence of an account range fraud attack in which a set of primary account numbers (PANs), each associated with a respective payment card, that share a common bank identification number (BIN) are subject to potential fraud; (b) retrieve a plurality of transaction records associated with a respective plurality of transactions initiated during a time period associated with the fraud attack; (c) for each transaction of the plurality of transactions, determine an issuer response that indicates whether the respective transaction was authorized or declined; (d) for each authorized transaction of the plurality of transactions, extract the PAN from the transaction record associated with the respective authorized transaction; (e) identify a respective issuer of the payment card associated with each extracted PAN; and (f) transmit a fraud attack alert to an issuer of the extracted PANs, the fraud attack alert identifying the fraud attack, the time period associated with the fraud attack, and the PANs associated with the authorized transactions, wherein the fraud attack alert causes the issuer to record the PANs as compromised (¶ 0044).
Regarding Claim 4. The combination of Thomson and Muthukrishnan further discloses:
The computer-implemented method of claim 1, wherein the transaction request response codes comprise codes for an incorrect information decline response, a fraud alert decline response, or a user reported decline response.
Thomson - (a) the compromise flag, and (b) the authentication result of the enhanced authentication, such that issuer computing device 110 may use the compromise flag and/or authentication result to determine whether to authorize the transaction (or proceed with another process associated with the transaction message). In some cases, issuer computing device 110 may use these data elements in its own authentication procedures or, where the authentication result indicates the transaction is likely genuine, may forego its own authentication procedures. Moreover, it is contemplated that, in some embodiments, ADR computing device 106 may decline (or cause to be declined) any transaction message associated with a compromised PAN (¶ 0068).
Regarding Claim 5. The combination of Thomson and Muthukrishnan further discloses:
The computer-implemented method of claim 4, wherein: the incorrect information decline response comprises a response indicating an incorrect security pin corresponding to the account number, a response indicating an incorrect expiration date corresponding to the account number, a response indicating the account number as an incorrect account number, or a response indicating an incorrect address corresponding to the account number; the fraud alert decline response comprises a response indicating fraudulent activity corresponding to the account number or a response indicating an irregular transaction; and the user reported decline response comprises a response indicating a user reported lost card corresponding to the account number or a response indicating a user reported theft of the account number.
Thomson - Method 500 further includes, for each authorized transaction, extracting 508, the PAN from the transaction record associated with the respective authorized transaction, identifying 510 a respective issuer (e.g., an issuer associated with issuer computing device 110, shown in FIG. 1) of the payment card associated with each extracted PAN, and transmitting 512 a fraud attack alert to each identified issuer. The fraud attack alert identifies (e.g., includes data elements representing) the occurrence of the fraud attack, the time period associated with the fraud attack, and the PANs associated with the authorized transactions. The fraud attack alert causes the issuer to record or flag the PANs as compromised. For example, the fraud attack alert includes instructions, generating by ADR computing device 106, that causes issuer computing device 110 (associated with the issuer) to activate and associate a flag with each of the PANs within the computing system of the issuer (e.g., one or more databases, fraud modelling systems, etc.) (¶ 0085).
Regarding Claim 6. The combination of Thomson and Muthukrishnan further discloses:
The computer-implemented method of claim 1, further comprising: determining the first dynamic harvesting threshold by utilizing a percentage threshold indicating a percentage of historical declined network transaction request codes over a total number of historical network transaction request codes corresponding to network transactions of the first transaction facilitator
Thomson - For example, the pre-defined threshold level may include one or two standard deviations above the standard BIN velocity, a particular percentage higher (e.g., 100%, 200%, 500%) than a standard BIN velocity, and the like. It should be understood that standard BIN velocities may not be a stagnant value but may fluctuate based upon various factors, such as a date, season, and the like. For example, most standard BIN velocities may increase during a time of year when purchase levels increase (e.g., around Christmas or other major holidays) (¶ 0025).
Regarding Claim 7. The combination of Thomson and Muthukrishnan further discloses:
The computer-implemented method of claim 1, further comprising determining, utilizing the transaction request fraud detection model, the first dynamic harvesting threshold based on one or more transaction characteristics of the first transaction facilitator by modifying the first dynamic harvesting threshold based on transaction types, transaction amounts, or transaction velocities corresponding to the first transaction facilitator.
Thomson - Payment card transaction processors, such as payment networks and issuing banks, may monitor payment card transactions for signs of fraudulent activity. At least some known fraud detection systems monitor payment card transactions one payment card transaction at a time to determine whether the payment card transaction is potentially fraudulent. Such systems may not be able to detect certain types of widespread fraud attacks, such as the above-described common BIN fraud attacks. Moreover, these systems lack processes and infrastructure to effectively respond to these BIN attacks (¶ 0003).
Regarding Claim 8. The combination of Thomson and Muthukrishnan further discloses:
The computer-implemented method of claim 1, further comprising identifying, utilizing the transaction request fraud detection model, an indication of the account number harvesting incident by comparing a percentage of the one or more declined network transaction request response codes from the subset of network transaction requests determined over the time period to the first dynamic harvesting threshold.
Thomson - ADR computing device 106 derives issuer response codes and primary account numbers (PANs) for each transaction from the returned transaction records (step 204). Thereafter, ADR computing device 106 extracts the PANs associated with transactions that include issuer response codes of “approved” or “authorized”, indicating the attempted (fraudulent) transaction was successful (step 206) (¶ 0072).
Regarding Claim 9. The combination of Thomson and Muthukrishnan further discloses:
The computer-implemented method of claim 1, further comprising identifying, utilizing the transaction request fraud detection model, matching numbers at designated positions within the multiple account numbers as an indication of the account number harvesting incident.
Thomson - . If the subject PAN matches any PAN stored in the compromised account database, the ADR computing device may flag the incoming transaction message with a compromise flag before transmitting the transaction message to the issuer. The compromise flag causes the issuer to automatically initiate enhanced authentication of the associated transaction. Additionally or alternatively, the ADR computing device automatically performs the enhanced authentication on behalf of the issuer, and transmits the transaction message to the issuer appended with (a) the compromise flag (¶ 0040).
Regarding Claim 10. The combination of Thomson and Muthukrishnan further discloses:
The computer-implemented method of claim 1, further comprising modifying a fraud detection sensitivity, based on the subset of network transaction requests satisfying the first dynamic harvesting threshold indicating the account number harvesting incident, for one or more account numbers corresponding to the subset of network transaction requests for tracking of additional network transaction requests corresponding to the one or more account numbers.
Thomson- As the detection models are applied to the real-time transaction streams, these models detect anomalously high BIN velocities (i.e., levels of transaction traffic) as BIN velocities that exceed a pre-defined threshold level above a standard velocity for a BIN. For example, the pre-defined threshold level may include one or two standard deviations above the standard BIN velocity, a particular percentage higher (e.g., 100%, 200%, 500%) than a standard BIN velocity, and the like. It should be understood that standard BIN velocities may not be a stagnant value but may fluctuate based upon various factors, such as a date, season, and the like. For example, most standard BIN velocities may increase during a time of year when purchase levels increase (e.g., around Christmas or other major holidays) (¶ 0025).
Regarding 12. The combination of Thomson and Muthukrishnan further discloses:
The non-transitory computer-readable medium of claim 11, further comprising instructions that, when executed by the at least one processor, cause the computing device to, based on the subset of network transaction requests satisfying the first dynamic harvesting threshold indicating the account number harvesting incident, electronic communication alerts to client devices corresponding to one or more account numbers from the account numbers of the subset of network transaction requests.
Thomson - the ADR computing device extracts a PAN from each transaction record associated with an authorized transaction. These PANs are considered compromised as successfully “tested” by fraudsters. The ADR computing device generates a fraud attack alert that includes all of these compromised PANs and transmits the fraud attack alert to the issuer (or, in some cases, issuers) of the compromised PANs. In the example embodiment, the fraud attack alert includes instructions that cause the issuer to record or flag all of the PANs identified in the fraud attack alert as compromised or potentially compromised (¶ 0035).
Regarding Claim 13. The combination of Thomson and Muthukrishnan further discloses:
The non-transitory computer-readable medium of claim 11, further comprising instructions that, when executed by the at least one processor, cause the computing device to, based on the subset of network transaction requests satisfying the first dynamic harvesting threshold indicating the account number harvesting incident, transmit an electronic communication for the indicated account number harvesting incident to a recipient computing device of the first transaction facilitator corresponding to the set of network transaction requests.
Thomson - the ADR computing device extracts a PAN from each transaction record associated with an authorized transaction. These PANs are considered compromised as successfully “tested” by fraudsters. The ADR computing device generates a fraud attack alert that includes all of these compromised PANs and transmits the fraud attack alert to the issuer (or, in some cases, issuers) of the compromised PANs. In the example embodiment, the fraud attack alert includes instructions that cause the issuer to record or flag all of the PANs identified in the fraud attack alert as compromised or potentially compromised (¶ 0035).
Regarding Claim 14. The combination of Thomson and Muthukrishnan further discloses:
The non-transitory computer-readable medium of claim 11, further comprising instructions that, when executed by the at least one processor, cause the computing device to, based on the subset of network transaction requests satisfying the first dynamic harvesting threshold indicating the account number harvesting incident, block the first transaction facilitator corresponding to the set of network transaction requests from subsequent network transaction requests.
Thomson - each of the transaction records including a primary account number (PAN) and an issuer response code indicating whether the transaction was authorized or declined by a respective issuer of the plurality of issuers. receive, via the payment processing network, a real-time stream of electronic messages generated in response to transactions initiated at a plurality of online merchant portals, each of the electronic messages including the PAN (Claim 1).
Regarding Claim 15. The combination of Thomson and Muthukrishnan further discloses:
The non-transitory computer-readable medium of claim 11, further comprising instructions that, when executed by the at least one processor, cause the computing device to: detect an additional account number harvesting incident for the second transaction facilitator based on the second dynamic harvesting threshold; and based on the second transaction facilitator corresponding to a database of excluded transaction facilitators and the detected additional account number harvesting incident, transmitting original transaction request responses for the second transaction facilitator.
Thomson - each of the transaction records including a primary account number (PAN) and an issuer response code indicating whether the transaction was authorized or declined by a respective issuer of the plurality of issuers. receive, via the payment processing network, a real-time stream of electronic messages generated in response to transactions initiated at a plurality of online merchant portals, each of the electronic messages including the PAN (Claim 1).
Regarding Claim 17. The combination of Thomson and Muthukrishnan further discloses:
The system of claim 16, wherein the transaction request response codes comprise codes for an incorrect information decline response.
Thomson - the ADR computing device transmits the fraud attack alert, or an alternative alert message, to cardholders or accountholders associated with the compromised PANs. In some such embodiments, the cardholders/accountholders may decide whether to prompt their issuer to issue a new PAN or whether to impose the enhanced authentication requirement on the compromised PAN. Accordingly, the ADR computing device may receive user input indicating a user selection of how the issuer is to proceed, and may transmit instructions to the issuer that cause the issuer to implement the user selection (¶ 0039).
Regarding Claim 18. The combination of Thomson and Muthukrishnan further discloses:
The system of claim 16, further comprising instructions that, when executed by the at least one processor, cause the system to identify, utilizing the transaction request fraud detection model, an indication of the account number harvesting incident by comparing a percentage of the one or more declined network transaction request response codes from the subset of network transaction requests determined over the time period to the first dynamic harvesting threshold.
Thomson - As the detection models are applied to the real-time transaction streams, these models detect anomalously high BIN velocities (i.e., levels of transaction traffic) as BIN velocities that exceed a pre-defined threshold level above a standard velocity for a BIN. For example, the pre-defined threshold level may include one or two standard deviations above the standard BIN velocity, a particular percentage higher (e.g., 100%, 200%, 500%) than a standard BIN velocity, and the like. It should be understood that standard BIN velocities may not be a stagnant value but may fluctuate based upon various factors, such as a date, season, and the like. For example, most standard BIN velocities may increase during a time of year when purchase levels increase (e.g., around Christmas or other major holidays) (¶ 0025).
Regarding Claim 19. The combination of Thomson and Muthukrishnan further discloses:
The system of claim 18, further comprising instructions that, when executed by the at least one processor, cause the system to determine the first dynamic harvesting threshold by utilizing a percentage threshold indicating a percentage of historical declined network transaction request codes over a total number of historical network transaction request codes corresponding to network transactions of the first transaction facilitator.
Thomson - ADR computing device 106 is configured to monitor transaction streams (e.g., transaction messages processed over payment processing network 102, such as authorization request messages and/or account status inquiries) using artificial intelligence and/or machine learning algorithms to detect a BIN attack. The artificial intelligence and/or machine learning algorithms may include one or more detection models 112 trained to identify anomalously high levels of transaction traffic in a common account range or with a common BIN (e.g., a common BIN 56). In particular, a standard or expected velocity associated with any BIN may be pre-defined, stored (e.g., in database 108), and provided to detection models 112. These standard velocities may be determined and pre-defined based upon analysis of a plurality of historical transactions (e.g., hundreds, thousands, tens of thousands, hundreds of thousands, etc., of historical transactions) initiated using PANs sharing a same BIN (¶ 0059).
Regarding Claim 20. The combination of Thomson and Muthukrishnan further discloses:
The system of claim 16, further comprising instructions that, when executed by the at least one processor, cause the system to determine, utilizing the transaction request fraud detection model, the first dynamic harvesting threshold based on characteristics of the first transaction facilitator by modifying the first dynamic harvesting threshold based on transaction amounts corresponding to transactions facilitated by the first transaction facilitator.
Thomson - Additionally or alternatively, the detection models monitor the transaction streams for anomalously high PAN velocities (e.g., PAN velocities that exceed a pre-defined threshold level, such as one or two standard deviations above a standard velocity or a percentage higher than a standard velocity). Specifically, where a same PAN is used to attempt an anomalously high number of transactions, including transactions attempted with varying (e.g., sequential or random) expirations dates and/or security codes, a BIN attack (e.g., a card- or account-testing attack) may be occurring (¶ 0027).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Banerjee et al. US10721336.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINA C STEVENSON whose telephone number is (571)270-7280. The examiner can normally be reached M-F 8am-5pm.
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, Patrick Mcatee can be reached at 571-272-7575. 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.
/C.C.S./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698