DETAILED ACTION
Acknowledgements
The amendment filed 10/16/2025 is acknowledged.
Claims 1-4 are pending.
Claims 1-4 have been examined.
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 .
Response to Amendment/Argument
Regarding the rejection of the claims under 35 USC 101, applicant states that the claims solve the specific technological problem of the lack of a real-time, cooperative fraud detection system that allows merchants to make technologically-informed decisions before submitting transactions to payment hosts, thereby improving efficiency and security of payment processing systems. Applicant also states that the claims recite a specific technological solution involving a novel API-blockchain architecture, that uses a cryptographic hash, involves real-time searching and updating of transaction records within a private blockchain, and provides a technological improvement to fraud detection systems.
Examiner notes, however, that a method of fraud detection that allows merchants to make more informed decisions about whether a transaction is likely to be fraudulent before they submit the transaction to payment hosts does not solve a technological problem, but rather addresses a business or commercial problem of detecting and reducing fraudulent transactions. The steps recited in the claims outline a process of performing pre-processing on a transaction to determine whether to send the transaction to the host for processing, by using transaction information to look up information regarding a payment instrument and applying risk prevention rules against the information to determine whether the transaction is likely to be fraudulent or not and thus whether it is likely to be denied or not, and based on this determination, the claims either submit the transaction for processing or deny the transaction, and update the status of the transaction in a record. This is an analysis of transaction information to make a business decision regarding proceeding with a transaction, rather than a technical solution to a technical problem. Further, the fact that technological tools are used to achieve this end also does not make this a solution to a technological problem. Rather, it only involves using technology or a computer as a tool to automate and/or implement the abstract business process.
Applicant further states that the claims recite specific technical elements working in combination, including a specialized API with integrated hashing algorithms, cryptographic processing of payment data, real-time blockchain searching and updating, and coordinated status management across a distributed network, which represents a specifical technological solution. Applicant further states that the additional elements integrate any abstract concept into a practical application because they improve computer network security and fraud detection systems by providing real-time cooperative fraud analysis capabilities, the claims recite a specific technical implementation such as how the API processes cryptographic hashes as keys, how the blockchain responds to searches, and how status updates are coordinated, and the these features provide technological benefits similar to the non-conventional content filtering in BASCOM.
Examiner notes, however, that the use of technological tools, such as the API, private blockchain, and network, only involves using a computer as a tool to automate and/or implement the abstract idea because these tools are only used to carry out the functions that correspond to the abstract idea, rather than carrying out functions that provide an improvement to the functioning of the technological tools themselves. Although the claims recite an API, the functions performed by the API correspond to the steps that are found to be part of the abstract idea, such as calculating the hash, collecting the transaction information and submitting it to the ledger, and using the hash as a key to search and update the ledger. The use of the API does not provide a technological improvement, but only recites the mechanism by which the abstract idea is carried out. Additionally, the claims are not directed to the private blockchain or any technical features of the private blockchain. Rather, the private blockchain is a tool used to carry out the business decision-making process. Therefore, the mere use of the private blockchain to carry out the abstract idea does not provide a practical application or significantly more than the abstract idea. Unlike in BASCOM where the claimed invention utilized a technical feature of the TCP/IP protocol to recognize the address of a particular user and used that to provide a technical improvement to the filtering of content on a remote server, the present claims do not provide an improvement to the technology of the API or blockchain, but rather use these tools to automate the business process of reducing fraud in financial transactions.
Further, applicant states that the claims provide significantly more than the abstract idea because the integration of cryptographic hashing within an API that directly interfaces with a blockchain represent a novel technical approach, the claims address specific computer security vulnerabilities, and the specification explains specific technical benefits of reducing host fees for payment transactions and minimizing risks of chargebacks for payment transactions.
Examiner notes, however, that as explained above, the functions performed by the API correspond to the steps that are found to be part of the abstract idea, such as calculating the hash, collecting the transaction information and submitting it to the ledger, and using the hash as a key to search and update the ledger. The use of the API does not provide a technological improvement, but only recites the mechanism by which the abstract idea is carried out. Therefore, the use of the API does not provide significantly more than the abstract idea. Additionally, the claims do not address computer security vulnerabilities, but only describe a process of analyzing business information to make a business decision regarding whether or not a transaction is likely to be fraudulent. Further, reducing host fees for payment transactions and minimizing risks of chargebacks for payment transactions is not technical benefit or improvement to a technology, but rather a business or commercial benefit.
In response to examiner’s remarks, applicant states that the API functions are not abstract because they are specific technological capabilities that improve computer security. Applicant also states that the blockchain is not merely a tool, but the claims recite how the blockchain maintains authenticated merchant cooperation and enables technical fraud detection through coordinated record searching and updating. Further, applicant states that hashing is applied in a specific technical context that improves fraud detection systems, not merely abstract mathematical processing.
Examiner notes that the functions performed by the API include calculating the hash, collecting the transaction information and submitting it to the ledger, and using the hash as a key to search and update the ledger. These are all steps that are part of the abstract idea. The fact that these steps are performed by using an API only involves using the API as a tool to automate the abstract idea, and thus does not provide significantly more than the abstract idea. Regarding the blockchain, examiner notes that the blockchain is only used to store and retrieve data, and is therefore a tool to automate and/or implement the abstract idea. The claims do not provide any technological improvement to blockchain technology itself. Additionally, the language of “wherein the private blockchain is maintained as a private blockchain arrangement that ensures participating merchants are authenticated and trusted, and which enables merchant-to-merchant cooperation to assess risk before submitting payment transactions to the host and wherein the records associated with the hash include customer-agnostic plain text for transactions, which can be updated based on transaction status and which can be provided as search results for evaluation based on customized fraud and risk rules, and wherein the hash serves as a key for searching the private blockchain and the private blockchain returns in response to the search the plaintext associated with records in the private blockchain” only describes the intended use of the blockchain, but does not require any steps to be performed by the blockchain as part of the claims method. Therefore, these limitations do not gain patentable weight. Further, the calculation of the hash using various information such as the account number and expiration date only involves performing a mathematical calculation. The resulting hash is used to look up information regarding prior transactions performed using the account, which is part of the abstract idea as it only involves looking up financial records. Thus, the use of a hash is not an additional element that provides significantly more than the abstract idea.
Election/Restrictions
Applicant’s election without traverse of Group I, claims 1-12, in the reply filed on 9/30/2019 is acknowledged.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-4 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-4 are directed to a method. Therefore, these claims fall within the four statutory categories of invention.
The claims describe predicting whether a host is going to accept or decline a transaction by obtaining payment information, transaction information, and risk prevention rules, calculating a value based on the payment information received during a transaction and using it and the transaction information to look up information about a payment instrument and performing a risk evaluation using rules, and then determining how to proceed with a transaction while keeping track of the status of the transaction, which is an abstract idea. Specifically, the claims recite “obtaining . . . identifying information associated with a payment instrument . . . during payment processing for a payment of the transaction being performed by a customer with a given retailer, . . . obtains the identifying information when the customer inserts a payment card into a card reader when the payment is due for the transaction . . .,” “before a host is provided the identifying information and transaction details of the transaction for completing the payment processing on behalf of the customer and the given retailer performing preprocessing to custom detect potential fraud associated with the transaction, comprising: obtaining risk prevention rules specific for the transaction that are specific to the given retailer,” “calculating a hash from the identifying information of a payment instrument by processing a cryptographic hashing algorithm on an account number obtained from the identifying information and an expiration date for the payment instrument obtained from the identifying information and producing the hash,” “wherein . . . includes a hashing algorithm for use with the transaction information,” “wherein . . . collects the transaction information and submits the transaction information for inclusion to a private [ledger],” “wherein . . . processes the hash as a key for searching and updating specific transactions within the private [ledger],” “submitting the hash and a plaintext comprising a date and time of the transaction, a retailer identifier, a known physical location of the terminal, a transaction amount, and a subset of digits from the account as a search to the private [ledger] to obtain records of prior transactions associated with the payment instrument,” “applying customizable risk prevention rules set by the given retailer against the records, wherein the risk prevention rules are customized and specific to the given retailer,” “assigning a pending status for the transaction indicating that the payment processing for the payment of the transaction is pending for a fraud review based on a comparison,” “based on applying processing one of: sending the identifying information and transaction details for the transaction to a host that performs the payment processing and obtains the payment on behalf of the given retailer; or sending a transaction denial . . . indicating that the payment processing cannot be performed for the transaction since fraud is present based on application of the risk prevention rules and without sending the identifying information and the transaction details to the host, wherein the host . . . processes the payment for the transaction based on the payment card,” and “providing the method as a pre-processing technique for the given retailer to make customized decisions as to whether the transaction is to be submitted to the host by utilizing the private [ledger] and allows the given retailer to predict in advance whether the host is going to accept or decline the transaction before the given retailer submits the transaction to the host, thereby reducing host fees for payment transactions and minimizing risks of chargebacks for payment transactions; wherein the private [ledger] is maintained as a private [ledger] arrangement that ensures participating merchants are authenticated and trusted, and which enables merchant-to-merchant cooperation to assess risk before submitting payment transactions to the host, wherein the records associated with the hash include customer-agnostic plain text for transactions, which can be updated based on transaction status and which can be provided as search results for evaluation based on customized fraud and risk rules, and wherein the hash serves as a key for searching the private [ledger] and the private [ledger] returns in response to the search the plaintext associated with records in the private [ledger]” and “updating . . . a status of the transaction within the private [ledger] from the pending status to one of a processed status when the identifying information and transaction details are sent to the host or a chargeback status when the transaction denial is sent to . . ., wherein the updated status is stored in the private [ledger] as part of a unique transaction record that comprises the hash, selective transaction information selected from the transaction details, and the updated status,” which is grouped within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 52, 54 (January 7, 2019)) because the claims describe a process for minimizing chargebacks for payment transactions and predicting whether or not a host is going to accept or decline a transaction by detecting potential fraud in a payment transaction by using transaction information to look up information regarding a payment instrument and applying risk prevention rules against the information, and updating a record storing the status of the transaction, which is a commercial or legal interaction. Further, the feature of “calculating a hash from identifying information of a payment instrument by processing a cryptographic hashing algorithm on an account number obtained from the identifying information and an expiration date for the payment instrument obtained from the identifying information and producing the hash,” is also grouped within the “mathematical concepts” grouping of abstract ideas because it only involves performing mathematical calculations. Accordingly, the claims recite an abstract idea (See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al., US Supreme Court, No. 13-298, June 19, 2014; 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 53-54 (January 7, 2019)).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 54-55 (January 7, 2019)), the additional elements of the claims such as executing, by a processor, of a server executable instructions obtained from a non-transitory computer-readable storage medium causing the processor to perform the recited operations, as well as the use of a terminal that comprises a POS terminal or a SST terminal, a first API, and a private blockchain, merely use a computer as a tool to perform an abstract idea. Specifically, these additional elements perform the steps or functions of “obtaining . . . identifying information associated with a payment instrument . . . during payment processing for a payment of the transaction being performed by a customer with a given retailer, . . . obtains the identifying information when the customer inserts a payment card into a card reader when the payment is due for the transaction . . .,” “before a host is provided the identifying information and transaction details of the transaction for completing the payment processing on behalf of the customer and the given retailer performing preprocessing to custom detect potential fraud associated with the transaction, comprising: obtaining risk prevention rules specific for the transaction that are specific to the given retailer,” “calculating a hash from the identifying information of a payment instrument by processing a cryptographic hashing algorithm on an account number obtained from the identifying information and an expiration date for the payment instrument obtained from the identifying information and producing the hash,” “wherein . . . includes a hashing algorithm for use with the transaction information,” “wherein . . . collects the transaction information and submits the transaction information for inclusion to a private [ledger],” “wherein . . . processes the hash as a key for searching and updating specific transactions within the private [ledger],” “submitting the hash and a plaintext comprising a date and time of the transaction, a retailer identifier, a known physical location of the terminal, a transaction amount, and a subset of digits from the account as a search to the private [ledger] to obtain records of prior transactions associated with the payment instrument,” “applying customizable risk prevention rules set by the given retailer against the records, wherein the risk prevention rules are customized and specific to the given retailer,” “assigning a pending status for the transaction indicating that the payment processing for the payment of the transaction is pending for a fraud review based on a comparison,” “based on applying processing one of: sending the identifying information and transaction details for the transaction to a host that performs the payment processing and obtains the payment on behalf of the given retailer; or sending a transaction denial . . . indicating that the payment processing cannot be performed for the transaction since fraud is present based on application of the risk prevention rules and without sending the identifying information and the transaction details to the host, wherein the host . . . processes the payment for the transaction based on the payment card,” and “providing the method as a pre-processing technique for the given retailer to make customized decisions as to whether the transaction is to be submitted to the host by utilizing the private [ledger] and allows the given retailer to predict in advance whether the host is going to accept or decline the transaction before the given retailer submits the transaction to the host, thereby reducing host fees for payment transactions and minimizing risks of chargebacks for payment transactions; wherein the private [ledger] is maintained as a private [ledger] arrangement that ensures participating merchants are authenticated and trusted, and which enables merchant-to-merchant cooperation to assess risk before submitting payment transactions to the host, wherein the records associated with the hash include customer-agnostic plain text for transactions, which can be updated based on transaction status and which can be provided as search results for evaluation based on customized fraud and risk rules, and wherein the hash serves as a key for searching the private [ledger] and the private [ledger] returns in response to the search the plaintext associated with records in the private [ledger]” and “updating . . . a status of the transaction within the private [ledger] from the pending status to one of a processed status when the identifying information and transaction details are sent to the host or a chargeback status when the transaction denial is sent to . . ., wherein the updated status is stored in the private [ledger] as part of a unique transaction record that comprises the hash, selective transaction information selected from the transaction details, and the updated status.” The use of a processor/computer as a tool to implement the abstract idea and does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 52, 56 (January 7, 2019)), the additional elements of executing, by a processor, of a server executable instructions obtained from a non-transitory computer-readable storage medium causing the processor to perform the recited operations, as well as the use of a terminal that comprises a POS terminal or a SST terminal, a first API, and a private blockchain, to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of predicting whether a host is going to accept or decline a transaction by obtaining payment information, transaction information, and risk prevention rules, calculating a value based on the payment information received during a transaction and using it and the transaction information to look up information about a payment instrument and performing a risk evaluation using rules, and then determining how to proceed with a transaction while keeping track of the status of the transaction. As discussed above, taking the claim elements separately, the additional elements perform the steps or functions of “obtaining . . . identifying information associated with a payment instrument . . . during payment processing for a payment of the transaction being performed by a customer with a given retailer, . . . obtains the identifying information when the customer inserts a payment card into a card reader when the payment is due for the transaction . . .,” “before a host is provided the identifying information and transaction details of the transaction for completing the payment processing on behalf of the customer and the given retailer performing preprocessing to custom detect potential fraud associated with the transaction, comprising: obtaining risk prevention rules specific for the transaction that are specific to the given retailer,” “calculating a hash from the identifying information of a payment instrument by processing a cryptographic hashing algorithm on an account number obtained from the identifying information and an expiration date for the payment instrument obtained from the identifying information and producing the hash,” “wherein . . . includes a hashing algorithm for use with the transaction information,” “wherein . . . collects the transaction information and submits the transaction information for inclusion to a private [ledger],” “wherein . . . processes the hash as a key for searching and updating specific transactions within the private [ledger],” “submitting the hash and a plaintext comprising a date and time of the transaction, a retailer identifier, a known physical location of the terminal, a transaction amount, and a subset of digits from the account as a search to the private [ledger] to obtain records of prior transactions associated with the payment instrument,” “applying customizable risk prevention rules set by the given retailer against the records, wherein the risk prevention rules are customized and specific to the given retailer,” “assigning a pending status for the transaction indicating that the payment processing for the payment of the transaction is pending for a fraud review based on a comparison,” “based on applying processing one of: sending the identifying information and transaction details for the transaction to a host that performs the payment processing and obtains the payment on behalf of the given retailer; or sending a transaction denial . . . indicating that the payment processing cannot be performed for the transaction since fraud is present based on application of the risk prevention rules and without sending the identifying information and the transaction details to the host, wherein the host . . . processes the payment for the transaction based on the payment card,” and “providing the method as a pre-processing technique for the given retailer to make customized decisions as to whether the transaction is to be submitted to the host by utilizing the private [ledger] and allows the given retailer to predict in advance whether the host is going to accept or decline the transaction before the given retailer submits the transaction to the host, thereby reducing host fees for payment transactions and minimizing risks of chargebacks for payment transactions; wherein the private [ledger] is maintained as a private [ledger] arrangement that ensures participating merchants are authenticated and trusted, and which enables merchant-to-merchant cooperation to assess risk before submitting payment transactions to the host, wherein the records associated with the hash include customer-agnostic plain text for transactions, which can be updated based on transaction status and which can be provided as search results for evaluation based on customized fraud and risk rules, and wherein the hash serves as a key for searching the private [ledger] and the private [ledger] returns in response to the search the plaintext associated with records in the private [ledger]” and “updating . . . a status of the transaction within the private [ledger] from the pending status to one of a processed status when the identifying information and transaction details are sent to the host or a chargeback status when the transaction denial is sent to . . ., wherein the updated status is stored in the private [ledger] as part of a unique transaction record that comprises the hash, selective transaction information selected from the transaction details, and the updated status.” These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of predicting whether a host is going to accept or decline a transaction by obtaining payment information, transaction information, and risk prevention rules, calculating a value based on the payment information received during a transaction and using it and the transaction information to look up information about a payment instrument and performing a risk evaluation using rules, and then determining how to proceed with a transaction while keeping track of the status of the transaction. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05 (f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 2-4 further describe the abstract idea of predicting whether a host is going to accept or decline a transaction by obtaining payment information, transaction information, and risk prevention rules, calculating a value based on the payment information received during a transaction and using it and the transaction information to look up information about a payment instrument and performing a risk evaluation using rules, and then determining how to proceed with a transaction while keeping track of the status of the transaction. Specifically, claim 2 further describes sending the identifying information and transaction details to the host, claim 3 describes creating a transaction record, and claim 4 further describes sending the transaction denial. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
Statement Regarding Prior Art
The closest prior art of Wright, et al. (US 2002/0194119) (“Wright”) discloses identifying information associated with a payment instrument from a terminal during payment processing for a payment of the transaction being performed by a customer with a given retailer on the terminal, wherein the terminal comprises a terminal of the given retailer (Wright ¶¶ 14-15, 58, 154, 161, 247, 252, 261, 226); before a host is provided the identifying information and transaction details of the transaction for completing the payment processing on behalf of the customer and the given retailer: obtaining risk prevention rules specific for the transaction that are specific to the given retailer (Wright ¶¶ 59, 152, 168-176, 178, 226, 263); calculating a hash from the identifying information of a payment instrument (Wright ¶¶ 256, 258-260); submitting the hash as a search to a transaction data structure that is maintained by, shared by, and accessible to the given retailer and other retailers over a network, and maintaining, by the given retailer and the other retailers, the transaction data structure for merchant-to-merchant cooperation in assessing risks for the transaction and other transactions of the given retailer and the other retailers (Wright ¶¶ 61, 154-158, 261-262, 264); obtaining, by the executable instructions results in response to the search (Wright ¶¶ 261-263); and evaluating the results against the risk prevention rules and based on the evaluating processing one of: sending the identifying information and the transaction details for the transaction to the host that performs the payment processing and obtains the payment on behalf of the given retailer; and sending a transaction denial to the terminal indicating that the payment processing cannot be performed for the transaction since fraud is present based on the evaluating and without sending the identifying information and the transaction details to the host (Wright ¶¶ 20, 154-158, 165, 267). Wright further discloses sending of the identifying information and the transaction details to the host further includes updating, by the executable instructions, the pending status to a processed status based on the sending of the identifying information and the transaction details to the host (Wright ¶¶ 61, 66, 158). Wright further discloses creating a unique transaction record that comprises the hash, selective transaction information that is selected from the transaction details, and the processed status and further adding the unique transaction record to the transaction data structure (Wright ¶¶ 258-265, 61). Wright also discloses that sending the transaction denial further includes updating the pending to a chargeback status based on the sending of the transaction denial to the terminal, creating a unique transaction record that comprises, the hash, selective transaction information that is selected from the transaction details, and the chargeback status, and further adding the unique transaction record to the transaction data structure (Wright ¶¶ 61, 63, 66, 158, 160). Wright further Wright discloses wherein the operations corresponding to the submitting further includes assigning the hash to a search key, providing the search key to the data structure, and obtaining the results from the data structure, wherein the results represent records prior transactions made with the payment instrument at one or more of the other retailers (Wright ¶¶ 61, 154-157, 256-257, 261-264). Wright additionally discloses the operations corresponding to the obtaining the results further includes obtaining identifying from the results prior transaction information for prior transactions made with the payment instrument at one or more of the other retailers (Wright ¶¶ 61, 256-257, 261-264). Also, Wright discloses the post pre-processing operations corresponding to the evaluating further include applying the risk prevention rules against the prior transaction information (Wright ¶¶ 168-176, 178, 263) and that the post pre-processing operations corresponding to the evaluating further include evaluating the results against the risk prevention rules during the transaction on behalf of the terminal (Wright ¶¶ 31, 78, 129, 151, 157). Wright further discloses that the post pre-processing operations corresponding to the evaluating during the transaction further include performing the evaluating before an existing payment process is performed for the transaction on behalf of the terminal to obtain the payment for the transaction (Wright ¶¶ 20, 154-158, 163, 165, 267). Finally, Wright discloses that the post pre-processing operations corresponding to the evaluating further include obtaining fraud rules defined by the risk prevention rules based on the given retailer and evaluating the fraud rules against transaction information returned with the results (Wright ¶¶ 168-176, 178, 263).
Christner (US 2015/0161609) additionally discloses that the terminal comprises a Point-Of-Sale (POS) terminal or a Self-Service Terminal (SST) of the given retailer (Christner ¶¶ 25, 30) and assigning a pending status for the transaction indicating that the payment processing for the payment of the transaction is pending for a fraud review (Christner ¶¶ 70-71). Durvasula, et al (US 2018/0075453) (“Durvasula”) discloses that the data structure is a private blockchain (Durvasula ¶¶ 10, 33, 38, 56-57).
However, the prior art does not disclose, neither singly nor in combination, the process of preprocessing a payment transaction to determine risk before sending the transaction to a host comprising the specific combination of steps which involve obtaining, via a first application programming interface (API), identifying information associated with a payment instrument from a terminal during payment processing for a payment of a transaction being performed by a customer with a given retailer on the terminal, wherein the terminal comprises a Point-Of-Sale (POS) terminal or a Self-Service Terminal (SST) of the given retailer, wherein the first API obtains the identifying information when the customer inserts a payment card into a card reader when the payment is due for the transaction at the POS terminal or the SST, and before a host is provided the identifying information and transaction details of the transaction for completing the payment processing, performing preprocessing to custom detect potential fraud associated with the transaction, comprising: obtaining risk prevention rules specific for the transaction that are specific to the given retailer, calculating a hash from the identifying information of a payment instrument, by processing a cryptographic hashing algorithm on an account number obtained from the identifying information and an expiration date for the payment instrument obtained from the identifying information and producing the hash, wherein the first API includes a hashing algorithm for use with the transaction information, wherein the first API collects the transaction information and submits the transaction information for inclusion to a private blockchain, wherein the first API processes the hash as a key for searching and updating specific transactions within the private blockchain, submitting the hash and plaintext comprising a date and time of the transaction, a retailer identifier, a known physical location of the terminal, a transaction amount, and a subset of digits from the account number as a search to the private blockchain to obtain records of prior transactions associated with the payment instrument, and applying customizable risk prevention rules set by the given retailer against the records, wherein the process next involves, based on applying processing either sending the identifying information and the transaction details for the transaction to the host that performs the payment processing, or sending a transaction denial to the terminal without sending the identifying information and the transaction details to the host, wherein the private blockchain is maintained as a private blockchain arrangement that ensures participating merchants are authenticated and trusted, and which enables merchant-to-merchant cooperation to assess risk before submitting payment transactions to the host and wherein the records associated with the hash include customer-agnostic plain text for transactions, which can be updated based on transaction status and which can be provided as search results for evaluation based on customized fraud and risk rules, and wherein the hash serves as a key for searching the private blockchain and the private blockchain returns in response to the search the plaintext associated with records in the private blockchain, and finally, updating, by the first API, a status of the transaction within the private blockchain from the pending status to one of a processed status when the identifying information and transaction details are sent to the host or a chargeback status when the transaction denial is sent to the terminal, wherein the updated status is stored in the private blockchain as part of a unique transaction record that comprises the hash, selective transaction information.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
de Oliveira, et al. (US 2011/0246369) (“de Oliveira”) for disclosing obtaining an account number and an expiration date for the payment instrument from the identifying information and calculating the hash by processing a cryptographic hashing algorithm on the account number obtained from the identifying information and the expiration date obtained from the identifying information and producing the hash (de Oliveira ¶¶ 75, 95).
Gailey, et al. (US 2002/0161647) (“Gailey”) for disclosing obtaining plaintext for a date and time of the transaction, a retailer identifier for the given retailer that is associated with the terminal, a known physical location associated with the terminal, a transaction amount for the transaction, the pending status, and a predefined number of first or last digits associated with the account number (Gailey ¶ 104).
Larkin (US 2012/0047072) (“Larkin”) for disclosing evaluating the results against the risk prevention rules using a plug-in to a web-based transaction interface (Larkin ¶¶ 70, 126, 128, 139-140).
Kennedy (US 2017/0132626) for disclosing hashing a primary account number to be used for verifying a payer (Kennedy ¶¶ 27, 49).
Eisen (US 2007/0234409) for disclosing assigning a pending status for the transaction indicating that the payment processing for the payment of the transaction is pending for a fraud review (Eisen ¶ 36).
THIS ACTION IS MADE FINAL. 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 A. Nilforoush whose telephone number is (571)270-5298. The examiner can normally be reached Monday-Friday 12pm-7pm.
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, John W. Hayes can be reached at 571-272-6708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Mohammad A. Nilforoush/Primary Examiner, Art Unit 3697