DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06/10/2026 has been entered.
Status of the Claims
This is a Non Final Office Action rejection prepared in response to Applicant’s correspondence filed on 06/10/2026.
Claims 1, 9 and 17 are amended.
Claims 3, 11 and 19 are cancelled.
Claims 1-2, 4-10, 12-18 and 20 are pending.
Claim Interpretation
Intended result/use language:
Regarding claims 2, 10 and 18, the claimed limitation “to update…” in “…used to update trust scoring for future transactions” consists entirely of language disclosing an intended result/use, which imparts neither structure nor functionality to the claimed method, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Nonfunctional language:
Regarding claims 1, 9 and 17, the claimed limitations “the digital identity data cryptographically signed by an identity provider…”, “the trust score is derived from previous transactions and a database of fraudulent activity” and “the first threshold being greater than the second threshold “ are non-functional material that does not move to distinguish over prior art as the description does not affect the positively recited steps in the method claim nor does the description affect the components either structurally nor functionally in the apparatus claims.
Regarding claims 7 and 15, the claimed limitation “the transaction details include at least one of the following: transaction amount, transaction date and time, location of the transaction, and type of transaction.” is non-functional material that does not move to distinguish over prior art as the description does not affect the positively recited step(s) in the method claim nor does the description affect the components either structurally nor functionally in the apparatus claim(s).
Regarding claims 8 and 16, the claimed limitation “the verified status indicator is based on a match between the digital identity data and user account data on a payment service of the transacting partner” is non-functional material that does not move to distinguish over prior art as the description does not affect the positively recited step(s) in the method claim nor does the description affect the components either structurally nor functionally in the apparatus claim(s).
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-2, 4-10, 12-18 and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-2 and 4-8 are directed to computer-implemented method (i.e., process). Claims 9-10 and 12-16 are directed to a system (i.e., machine, and manufacture). Claims 17-18 and 20 are directed to a computer-storage media (i.e., manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One: Claim 1, recites (i.e., sets forth or describes) an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
A computer-implemented method for generating a trust score for mobile payments, the method comprising:
receiving an indication, by a mobile wallet executing on a computing device, of a transaction between the mobile wallet and a transacting partner;
receiving, by the mobile wallet executing on the computing device, digital identity data from a computing device of the transacting partner, the digital identity data cryptographically signed by an identity provider and provided by a mobile wallet of the transacting partner;
encrypting, by the mobile wallet executing on the computing device, the digital identity data with a public key of a trust score service to create an encrypted identity;
transmitting, by the mobile wallet executing on the computing device, the encrypted identity to the trust score service;
receiving, by the mobile wallet executing on the computing device, a trust score from the trust score service, the trust score is derived from previous transactions and a database of fraudulent activity, the trust score including a cryptographic signature of the trust score service;
validating, by the mobile wallet executing on the computing device, the cryptographic signature of the trust score service using the public key of the trust score service;
comparing, by the mobile wallet executing on the computing device, the trust score to a first threshold and a second threshold, the first threshold being greater than the second threshold;
determining that the trust score is below the first threshold, but above the second threshold, and in response:
providing, by the mobile wallet executing on the computing device, a user interface, the user interface comprising the trust score, a countdown timer, and a selectable option to cancel the transaction: and
determining that a user has not selected the selectable option to cancel the transaction prior to expiration of the countdown timer, and in response, automatically performing the transaction.
Claim 1, recites (i.e., sets forth or describes) recites for processing a mobile transaction based on a trust score of the transacting partner. The claim achieves this by:
1) receiving an indication of a transaction
2) receiving identity data of the transacting partner
3) encrypting the identity data with a public key of a third party
4) transmitting the encrypted identity to the third party
5) receiving a trust score generated and signed by the third party based on stored transaction and fraudulent activity data related to the identity data
6) validating the signature on the score received from the third party using the public key of the third party
7) determining that the score is below a first threshold and above a second threshold
8) providing the score information to the user if the score exceeds the specified threshold and allowing predetermine amount of time to the user to review and cancel the transaction, if no answer is received by the user at the end of the predetermined amount of time
9) processing the transaction.
As such, the claim recites a certain method of organizing human activities (i.e., economic practices such as reducing risk and/or business relations). In regards to “encrypting, by the mobile wallet executing on the computing device, the digital identity data with a public key of a trust score service to create an encrypted identity;” and “validating, by the mobile wallet executing on the computing device, the cryptographic signature of the trust score service using the public key of the trust score service;” the examiner finds these to further recite an abstract idea as the recitations recite mathematical concept. Claims 9 and 17 are significantly similar to claim 1. As such claim 9 and 17 also recite an abstract idea.
Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to determine whether the claim recites additional elements that recite a practical application of the
abstract ideas. Here, the additional elements of a hardware processor, a memory, a computing device, a mobile wallet, a transacting mobile wallet, a trust score service, a user interface and a database merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Further, the additional element “digital” generally links the use of the judicial exception to a particular technological environment, that being of “digital data” (MPEP § 2106.05(h)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas.
Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims: Claims 2, 4-8, 10, 12-16 and 18 and 20 have also been analyzed for subject matter eligibility. However, claims 2-8, 10-16 and 18-20 also fail to recite patent eligible subject matter for the following reasons:
Claims 2, 10 and 18 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
providing feedback on the transaction to the trust score service, wherein the feedback is used to update trust scoring for future transactions.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” (i.e., fundamental economic practices) and “mathematical concepts” groupings of abstract ideas. The non-bolded additional element of “the trust score service” fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 4, 12 and 20 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
receiving an indication that the transacting partner has payment elements that do not match the digital identity data and in response canceling or blocking the transaction.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” (i.e., fundamental economic practices) grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Further, the additional element “digital” generally links the use of the judicial exception to a particular technological environment, that being of “digital data” (MPEP § 2106.05(h)).
Claims 5 and 13 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
displaying the digital identity data of the transacting partner on the mobile wallet executing on the computing device.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” (i.e., fundamental economic practices) grouping of abstract ideas. The non-bolded additional element of “the transacting mobile wallet” fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Further, the additional element “digital” generally links the use of the judicial exception to a particular technological environment, that being of “digital data” (MPEP § 2106.05(h)).
Claims 6 and 14 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
sending, by the mobile wallet executing on the computing device, transaction details to the trust score service, wherein the transaction details are used by the trust score service to create or update the trust score
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” (i.e., fundamental economic practices) and “mathematical concepts” groupings of abstract ideas. The non-bolded additional elements of “the trust score service” and “the transacting mobile wallet” fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 7 and 15 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the transaction details include at least one of the following: transaction amount, transaction date and time, location of the transaction, and type of transaction.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” (i.e., fundamental economic practices) grouping of abstract ideas.
Claims 8 and 16 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
receiving, by the mobile wallet executing on the computing device, a verified status indicator from the trust score service, wherein the verified status indicator is based on a match between the digital identity data and user account data on a payment service of the transacting partner.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” (i.e., fundamental economic practices) grouping of abstract ideas. The non-bolded additional elements of “a payment service”, the transacting mobile wallet” and “the trust score service” fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis. Further, the additional element “digital” generally links the use of the judicial exception to a particular technological environment, that being of “digital data” (MPEP § 2106.05(h)).
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.
Claims 1-2, 5-10 and 13-18 are rejected under 35 U.S.C. 103 as being unpatentable over Moy (Us 2025/0053985 A1) in view of Dhanoa (US 11,729,616 B1), in further view of Mardikar (US 20200311734 A1), in further view of Grant (US 10530776 B2), in further view of Caro (US 20230066232 A1).
Regarding claim 1, 9 and 17, Moy discloses:
receiving an indication, by a mobile wallet executing on a computing device, of a transaction between the mobile wallet and a transacting partner; receiving, by the mobile wallet executing on the computing device, digital identity data from a computing device of the transacting partner (Moy ¶0024, To initiate a new blockchain transaction, the requesting device 108 can receive the necessary data for a new blockchain transaction, which can include a destination blockchain address (e.g., generated by the public key of the participating device 110 and electronically transmitted to the requesting device 108) using a suitable communication network and method) and a cryptographic currency amount if the requesting device 108 is a payer, or digital signature and one or more unspent transaction outputs from the requesting device 108, a cryptographic currency amount, and a destination address generated by the public key of the requesting device's blockchain wallet if the requesting device 108 is a payee. Traditionally, the requesting device 108 can electronically transmit the transaction data for the new blockchain transaction to a blockchain node 106 in the blockchain network 104 for verification, confirmation, and addition to the blockchain using traditional methods. Moy ¶0062, In step 502, the requesting device 108 can receive data from a new blockchain transaction, which can include data from a recipient (e.g., participating device 110), such as a destination address, and data input by a user of the requesting device 108, such as a transaction amount and unspent transaction outputs
transmitting, by the mobile wallet executing on the computing device, the encrypted identity to the trust score service; (Moy ¶0025, In the system 100, the user of the requesting device 108 can be interested in having a fraud score generated for the new blockchain transaction prior to, or as part of, submission to the blockchain node 106. For instance, the user can be participating in a blockchain transaction with the participant device 110 for the first time, and may be interested in a fraud score to gauge the likelihood that the participating device 110 is genuine and not participating in fraud. To receive such a fraud score, the requesting device 108 can electronically transmit a scoring request to the processing server 102 using a suitable communication network and method, such as via an application program associated with the processing server 102, a web page, etc. In some cases, the requesting device 108 can submit the new blockchain transaction to a blockchain node 106 and, as part of the submission, request a fraud score, where the blockchain node 106 can electronically transmit the new blockchain transaction or data therefrom to the processing server 102 for scoring using a suitable communication network and method. Moy ¶0062, In step 504, the requesting device 108 can submit a scoring request for the new blockchain transaction to the processing server 102 using a suitable communication network and method. In some cases, the scoring request can be submitted to the processing server 102 by the requesting device 108 via a blockchain node 106 that is to add the new blockchain transaction to the blockchain if approved. In other cases, the scoring request can be submitted to the processing server 102 directly from the requesting device 108. In such cases, the scoring request can also include an identifier associated with the blockchain node 106 to be used by the requesting device 108 in adding the new blockchain transaction to the blockchain if approved. Moy ¶0063, In step 506, the receiving device 202 of the processing server 102 can receive the scoring request from the requesting device 108.)
receiving, by the mobile wallet executing on the computing device, a trust score from the trust score service, (Moy ¶0032, The processing server 102 can generate the fraud score for the new blockchain transaction and provide the fraud score in response to the score request. In some cases, the fraud score can be provided back to the requesting device 108 (e.g., directly by the processing server 102 or via the blockchain node 106 used by the requesting device 108). Moy ¶0064, In step 510, the scoring module 220 of the processing server 102 can apply the received new blockchain transaction data and identified applicable data to the identified fraud detection model to generate a fraud score for the new blockchain transaction. The fraud score can indicate a likelihood that the new blockchain transaction involves fraud, which can be indicated to be perpetrated by the requesting device 108, participating device 110 or blockchain node 106. In step 512, the transmitting device 222 of the processing server 102 can electronically transmit the generated fraud score to the requesting device 108 using a suitable communication network and method. The generated fraud score can be directly transmitted to the requesting device 108 by the processing server 102, or via the blockchain node 106, as applicable. Moy ¶0065, In step 514, the requesting device 108 can receive the fraud score generated for the new blockchain transaction from the processing server 102.)
the trust score is derived from previous transactions and a database of fraudulent activity, (Moy ¶0005, When the processing server receives transaction data for a new blockchain transaction, such as from the potential payer of the transaction, the processing server uses the fraud detection model and transaction data for past fiat-based payment transactions and blockchain transactions to generate a fraud score for the new blockchain transaction that indicates a likelihood of fraud for the new transaction. Moy ¶0026, The processing server 102 can receive data from a plurality of different data sources for use in generating the fraud detection model and/or fraud scores. As one data source, the processing server 102 can receive transaction data for a plurality of payment transactions that use fiat currency, such as traditional electronic payment transactions that utilize credit cards, debit cards, etc., which the processing server 102 can receive from a fiat transaction data provider 112. The fiat transaction data provider 112 can be any entity or system that collects transaction data for fiat currency based payment transactions, such as a financial institution, payment network, transaction processor, clearing house, etc. Moy ¶0031, The processing server 102 can receive data from a plurality of different data sources for use in generating the fraud detection model and/or fraud scores. As one data source, the processing server 102 can receive transaction data for a plurality of payment transactions that use fiat currency, such as traditional electronic payment transactions that utilize credit cards, debit cards, etc., which the processing server 102 can receive from a fiat transaction data provider 112. The fiat transaction data provider 112 can be any entity or system that collects transaction data for fiat currency based payment transactions, such as a financial institution, payment network, transaction processor, clearing house, etc… The processing server 102 can apply the transaction data to the fraud detection model and generate a fraud score for the new blockchain transaction that indicates a likelihood of fraud for the new blockchain transaction. The fraud score can be increased (e.g., indicating a higher likelihood of fraud) if the requesting device 108 or participating device 110 have been involved in past fraudulent blockchain transactions, if the blockchain node 106 has been involved in past fraudulent blockchain transactions, if the blockchain node 106 is in a cluster indicative of fraudulent activity in the graphical representation, if the transaction frequency for the requesting device 108, participating device 110, or blockchain node 106 is unusually low or high, if the users associated with the requesting device 108 or participating device 110 have been involved in past fraudulent transactions, if the transaction amount for the new blockchain transactions is significantly greater than the average transaction amount for past blockchain or fiat-based payment transactions for the requesting device 108 or participating device 110, if the geographic location for the requesting device 108 or participating device 110 in the new blockchain transaction is different from past geographic locations for the respective device, etc.)
providing by the mobile wallet executing on the computing device, a user interface (Moy ¶0032, In such cases, the requesting device 108 can prompt the user thereof to approve or deny the new blockchain transaction based on the fraud score. Moy ¶0065, In step 516, the requesting device 108 can display the received fraud score to a user thereof and prompt the user to approve the new blockchain transaction. If the fraud score is suitable to the user the user can approve the new blockchain transaction,)
Moy does not disclose, however Dhanoa teaches:
the digital identity data cryptographically signed by an identity provider and provided by a mobile wallet of the transacting partner; (Dhanoa col 1 lines 63-67 & col 2 lines 1-3, The digital credential may, alternatively or additionally, include or identify a digital key (or pointer thereto) associated with an ID issuer or other trusted entity, and/or information on a distributed ledger enabling, for example, verification of the digital credential using blockchain technology. The digital key and/or distributed ledger may indicate or demonstrate that the trusted entity has validated certain identity data of the user.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify Moy’s teaching with Dhanoa’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to ensure transaction security by providing only reliable and verifiable identity data to the transacting user.
The combination of Moy and Dhanoa do not disclose, however Mardikar teaches:
the trust score including a cryptographic signature of the trust score service (¶0003, The system may calculate a dynamic trust score for the transaction based on the transaction data, the third party data, and the user data. The system may transmit the dynamic trust score to the merchant, wherein the merchant utilizes the dynamic trust score to authorize the transaction. ¶0005, In various embodiments, the system may encrypt the dynamic trust score with a private key. ¶0048, The trust score provider may generate the asymmetric key pair using any suitable technique and asymmetric algorithm, such as, for example, RSA, DSA, elliptic curve cryptography, or the like. The trust score provider may encrypt and store the private key. The trust score provider may transmit the public key to the consumer device and/or the merchant, which may encrypt and store locally the public key. In various embodiments, the trust score provider may also encrypt and store locally the public key. In various embodiments, the trust score provider may write the digital identity entry to the digital identity management DLT network. In that regard, the public key may comprise a blockchain address. ¶0061, A network may be unsecure. Thus, communication over the network may utilize data encryption. Encryption may be performed by way of any of the techniques now available in the art or which may become available—e.g., Twofish, RSA, El Gamal, Schorr signature, DSA, PGP, PM, GPG (GnuPG), HPE Format-Preserving Encryption (FPE), Voltage, Triple DES, Blowfish, AES, MD5, HMAC, IDEA, RC6, and symmetric and asymmetric cryptosystems. Network communications may also incorporate SHA series cryptographic methods, elliptic-curve cryptography (e.g., ECC, ECDH, ECDSA, etc.), and/or other post-quantum cryptography algorithms under development.)
validating, by the mobile wallet executing on the computing device, the cryptographic signature of the trust score service using the public key of the trust score service; (¶0005, In various embodiments, the system may encrypt the dynamic trust score with a private key. The system may store the dynamic trust score on a digital identity management blockchain. The system may transmit a public key to the merchant. The public key may be associated with the private key. The merchant may use the public key to retrieve the dynamic trust score from the digital identity management blockchain. ¶0048, In various embodiments, the trust score provider may create an asymmetric key pair, including a private key and a public key. The trust score provider may generate the asymmetric key pair using any suitable technique and asymmetric algorithm, such as, for example, RSA, DSA, elliptic curve cryptography, or the like. The trust score provider may encrypt and store the private key. The trust score provider may transmit the public key to the consumer device and/or the merchant, which may encrypt and store locally the public key. In various embodiments, the trust score provider may also encrypt and store locally the public key.)
While Mardikar does not explicitly teach
encrypting, by the mobile wallet executing on the computing device, the digital identity data with a public key of a trust score service to create an encrypted identity;
Mardikar teaches the use of different cryptographic techniques (i.e. encrypting, signing, hashing) to secure data transmitted over the network (¶0061, A network may be unsecure. Thus, communication over the network may utilize data encryption. Encryption may be performed by way of any of the techniques now available in the art or which may become available—e.g., Twofish, RSA, El Gamal, Schorr signature, DSA, PGP, PM, GPG (GnuPG), HPE Format-Preserving Encryption (FPE), Voltage, Triple DES, Blowfish, AES, MD5, HMAC, IDEA, RC6, and symmetric and asymmetric cryptosystems. Network communications may also incorporate SHA series cryptographic methods, elliptic-curve cryptography (e.g., ECC, ECDH, ECDSA, etc.), and/or other post-quantum cryptography algorithms under development) and the computing device having the public key of the trust score service (¶0048, The trust score provider may transmit the public key to the consumer device and/or the merchant, which may encrypt and store locally the public key.) Therefore, it would have been obvious to one of ordinary skills in the art to encrypt the identity data with the public key of the trust score service prior to transmitting the data in order to protect sensitive/confidential information.
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify the combination of Moy and Dhanoa with Mardikar’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to prevent the score/identity data to be maliciously modified or falsified and to preserve the integrity of the score/identity data.
The combination of Moy, Dhanoa and Mardikar do not disclose, however Grant teaches:
comparing, by the mobile wallet executing on the computing device, the trust score to a first threshold and a second threshold, the first threshold being greater than the second threshold; determining that the trust score is below the first threshold, but above the second threshold, and in response: (col 14 lines 38-67 & col 15 lines 1-18, The access decision engine 128 receives the results of the evidence evaluation performed by the evidence analysis engine 126 and compares the confidence score to one or more threshold confidence scores to generate a final access decision. If the confidence score meets or exceeds a first threshold confidence score indicative of a correct candidate response, then the candidate response is selected as a final response to be utilized to either provide the requested access, deny the requested access, or elevate the requested access to a human administrator or other level of further evaluation. If the confidence score does not meet or exceed this first threshold, a determination may be made as to whether another second threshold confidence score is met or exceeded that is indicative of an “unsure” confidence level, i.e. there is some evidence that supports and some evidence that refutes the candidate response such that the first confidence score threshold is not met or exceeded, but there is sufficient evidence to support the candidate response such that it cannot be determined to most likely incorrect. In such a case, the evaluation may result in a request sent to a human administrator to intervene and make a determination as to whether access should be allowed or denied. The administrator interface engine 130 provides the logic and resources to generate notifications and user interfaces through which a human administrator is notified when intervention by a human administrator is determined to be necessary to process an access request. The operations of the administrator interface engine 130 may be instigated in response to the final result of the access decision engine being to elevate the access request processing to a level of evaluation involving a human administrator, when the second threshold confidence score is met or exceeded but the first threshold confidence score is not, i.e. it is unclear whether the candidate result of the access decision engine 128 is correct or not, or at any other time when the logic of the cognitive access control system 120 determines that human administrator intervention is warranted. The administrator interface engine 130 may generate outputs to an administrator computing device, e.g., computing device 112, and process responses from an administrator via their computing device 112 and network 102. In some cases, the administrator may be requested to confirm access of a requestor to particular content in which case the administrator interface engine 130 may send a notification or user interface to the computing device 112 identifying the requestor, the content, and the type of access requested along with user interface elements to confirm/deny the access. See claim 9)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify the combination of Moy, Dhanoa and Mardikar with Grant’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to ensure that the system provides the opportunity to the user to review and approve transactions that are not within the determine trust score threshold (i.e. transactions that have bigger potential to be fraudulent).
The combination of Moy, Dhanoa, Mardikar and Grant do not disclose, however Caro teaches:
the user interface comprising the trust score, a countdown timer, and a selectable option to cancel the transaction: and (¶0384, In some embodiments, before sending the communication including content corresponding to detected selections of communication-content options, the computer system (e.g., 100, 300, 500, or 600) displays a visual indication of a countdown (e.g., 610W) indicating a remaining time until the communication including content corresponding to detected selections of communication-content options will be sent (e.g., without further user input). Displaying a visual indication of a countdown indicating a remaining time until the communication will be sent provides the user with notice that the communication will be automatically sent without further input, which provides improved visual feedback. ¶0385, In some embodiments, before sending the communication including content corresponding to detected selections of communication-content options (e.g., while displaying the visual indication (e.g., text, a graphic, a color, and/or an animation) of the countdown indicating the remaining time until the communication including content corresponding to detected selections of communication-content options will be sent), the computer system displays a selectable cancel sending option (e.g., 608W) that, when selected, causes the computer system to forego sending the communication including content corresponding to detected selections of communication-content options. In some embodiments, the cancel sending option, when selected, causes the computer system to cease the countdown (e.g., cease display of the visual indication of the countdown). Displaying a selectable cancel sending option before sending the communication provides the user with an indication that sending the communication can be canceled and provides an efficient technique for canceling sending of the communication, with provides improved visual feedback and reduces the number of inputs needed to perform an operation. ¶0672, User interface 1518A includes indication 1518A1, countdown timer 1518A2, and cancel option 1518A3. Indication 1518A1 indicates that computer system 1500A will initiate a call to emergency services. Countdown timer 1518A2 displays an amount of time (e.g., a number of seconds) until computer system 1500A will automatically initiate a call to emergency services. A user can select cancel option 1518A3 (e.g., via a tap gesture) to end the countdown and prevent computer system 1500A from automatically initiating a call to emergency services.¶0701, In some embodiments, the computer system displays, concurrently with the countdown, a selectable option to cancel the countdown (e.g., if the option to cancel the countdown is selected before the countdown ends, the computer system does not automatically attempt to communicate). In some embodiments, the computer system displays the countdown, displays the option to cancel the countdown, and/or automatically attempts to communicate in accordance with a determination that a user of the computer system has fallen. Automatically attempting to communicate in response to detecting that a user has fallen provides a user with a means to communicate when the user is injured and/or unable to interact with the computer system (e.g., if the user is unable to initiate the communication), which reduces the number of inputs needed to perform an operation… In some embodiments, in response to detecting that a user has fallen, computer system displays user interface 1518A and initiates a countdown without first displaying menu user interface 1512A.)
determining that a user has not selected the selectable option to cancel the transaction prior to expiration of the countdown timer, and in response, automatically performing the transaction. (¶0277, In some embodiments, the countdown indicates a remaining time until a message (e.g., an emergency SOS message) is sent automatically via satellite communication. In some embodiments, the countdown indicates a remaining time until computer system 600 enters a mode for generating and sending an emergency communication via satellite communication (e.g., FIG. 6L1 or FIG. 6M). ¶0382,… in response to a determination that the predetermined time period has elapsed without detecting a selection of the send option, the computer system sends the communication including the content corresponding to the selection of the first communication-content option and the second communication-content option selected by the first set of one or more inputs and the second set of one or more inputs (e.g., automatically sending the communication once the countdown has expired). ¶0384, In some embodiments, before sending the communication including content corresponding to detected selections of communication-content options, the computer system (e.g., 100, 300, 500, or 600) displays a visual indication of a countdown (e.g., 610W) indicating a remaining time until the communication including content corresponding to detected selections of communication-content options will be sent (e.g., without further user input). ¶0672, Countdown timer 1518A2 displays an amount of time (e.g., a number of seconds) until computer system 1500A will automatically initiate a call to emergency services… If the countdown reaches zero before being cancelled, computer system 1500A automatically initiates a call to emergency services.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify the combination of Moy, Dhanoa, Mardikar and Grant with Caro’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to provide improved visual feedback and perform an operation when a set of conditions has been met without requiring further user input as stated by Caro.
Regarding claims 2, 10 and 18, Moy further discloses:
providing feedback on the transaction to the trust score service, wherein the feedback is used to update trust scoring for future transactions (Moy ¶0005, In some cases, the disposition of the new transaction can be used to further train the fraud detection model for use in future transactions. Moy ¶0035, In some cases, the requesting device 108 can provide feedback regarding the approval or denial of the new blockchain transaction, which can be used to modify the fraud detection model, such as the reasoning of the user for the approval or denial of the new blockchain transaction.)
Regarding claims 5 and 13, the combination of Moy, Dhanoa, Mardikar, Grant and Caro further teaches:
displaying the digital identity data of the transacting partner on the mobile wallet executing on the computing device. (Dhanoa col 29 lines 42-67 & col 30 lines 1-6, FIG. 15 shows a representation of an example user interface 1500 of a receiver device 170, according to example embodiments. The user interface 1500 may be targeted to a user of a user device 150 in potential implementations. The user interface 1500 may be presented via application layer 182, in various implementations. The user interface 1500 may be shown on a display screen of receiver device 170, for example, once the receiver device 170 detects a user (e.g., upon the user touching a touchscreen of the smart device or otherwise interacting with or engaging the smart device) and/or once the receiver device 170 detects a user device 150 (through, e.g., wireless communication with the user device 150 and/or through scanning of a code or other indicia displayed on a display screen of the user device 150). Additionally or alternatively, user interface 1500 may be an “always on” interface that is regularly displayed while the receiver device 170 is on. Receiver device 170 may, for example, display user interface 1500 as a welcome screen through which a user may gain access to or otherwise operate a smart device. User interface 1500 may indicate what identity attribute, such authorization from an owner or manager of the smart device, is requested by the receiver device 170 to grant access or enable functionality. User interface 1500 may also indicate why the identity attribute is being requested, such as for enabling a certain functionality (e.g., a smart vehicle enabling engine start, a smart home appliance enabling placement of an order for products, etc.), granting access to an area (e.g., a smart lock mechanism unlocking a user's home, office, warehouse, hotel room, etc.), or otherwise rendering the smart device usable (e.g., unlocking the device itself) with limited or unlimited functionality.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify the combination of Moy, Dhanoa, Mardikar, Grant and Caro with Dhanoa’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to add an additional layer of verification that allows the user to manually verify the transacting party based on the identity information displayed on the device .
Regarding claims 6 and 14, Moy further discloses:
sending, by the mobile wallet executing on the computing device, transaction details to the trust score service, wherein the transaction details are used by the trust score service to create or update the trust score. (Moy ¶0036, In some embodiments, the processing server 102 can be configured to update the fraud detection model when new data is received. For instance, the processing server 102 can receive new transaction data or new node connectivity data and can update the fraud detection model as a result. In some instances, the processing server 102 can update the fraud detection model any time new data is received. In other instances, the processing server 102 can update the fraud detection at regular intervals (e.g., hourly, daily, weekly, etc.).)
Regarding claims 7 and 15, Moy further discloses:
the transaction details include at least one of the following: transaction amount, transaction date and time, location of the transaction, and type of transaction. (Moy ¶0026, In some cases, the fiat transaction data provider 112 can also provide data associated with individual consumers with permission of the individual consumers, which can include personally identifiable information if approved by the consumer, which can include, for instance, name, address, email address, transaction account number, etc. The transaction data for the fiat currency based payment transactions can include transaction amounts, merchants, financial institutions, times and/or dates, transaction frequencies, geographic locations, currencies, point of sale identifiers, fraud determinations, etc. In some cases, the transaction data can be separated by individual transactions. In other cases, the processing server 102 can receive aggregated transaction data. In cases where approved by the consumer associated with the requesting device 108, the transaction data can include data for individual payment transactions involving the consumer. Moy ¶0031, The transaction data for the new blockchain transaction can include a transaction amount, one or more unspent transaction outputs associated with the payer of the blockchain transaction, the destination address of the payee of the blockchain transaction, identifying information for the blockchain node 106 to be used in confirming and adding the new blockchain transaction to the blockchain, and any other suitable data for use in performing the functions discussed herein, such as identifying information for the user of the requesting device 108 and/or user of the participant device 110 if approved by the respective users.)
Regarding claims 8 and 16, the combination of Moy, Dhanoa, Mardikar, Grant and Caro further teaches:
receiving, by the mobile wallet executing on the computing device, a verified status indicator from the trust score service, wherein (Dhanoa col 9 lines 4-7, The approach may involve sending a second transmission from the first server to the first device comprising a message indicating that the second set of identity data is verified.)
the verified status indicator is based on a match between the digital identity data and user account data on a payment service of the transacting partner. (Dhanoa col 8 lines 62-67 & col 9 lines 1-4, The verification may comprise comparing, at the first server, the second set of identity data to the first set of identity data. The verification may comprise determining whether the second set of identity data is associated with the same digital key as the first set of identity data. The verification may comprise determining whether the identity data in the first set sufficiently matches the identity data in the second set. A determination that the first and second sets match may be deemed a verification of the second set of identity data.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify the combination of Moy, Dhanoa, Mardikar, Grant and Caro with Dhanoa’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to enhance the system security by adding an additional level of user verification before performing the transaction.
Claims 4, 12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Moy, Dhanoa, Mardikar, Grant and Caro as applied to claims 1 and 9 above, and in further in view of Mayblum (US 2020/0042996 A1).
Regarding claims 4, 12 and 20, the combination of Moy, Dhanoa, Mardikar, Grant and Caro do not disclose, however Mayblum teaches:
receiving an indication that the transacting partner has payment elements that do not match the digital identity data and in response canceling or blocking the transaction (Mayblum ¶0018, In some embodiments, the transaction includes a digital signature of the first entity, wherein the indication of validity comprises an indication of validity of the digital signature of the first entity, wherein the computing node is further configured to receive, from the one or more computing nodes, an indication of invalidity of the new transaction block, wherein the indication of invalidity comprises an indication of invalidity of the digital signature of the first entity, and based on the indication of invalidity, deny the transaction and prevent insertion of the new transaction block into the private distributed ledger.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify the combination of Moy, Dhanoa, Mardikar, Grant and Caro with Mayblum’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to enhance the system security by automatically preventing to process transactions when the identity information does not match the payment information.
Response to Arguments
Claim Interpretation
Nonfunctional Language:
Applicant’s arguments that the claim interpretation in regards to the nonfunctional language presented in the previous office actions is inconsistent with In re Lowry and IOENGINE and that the examiner committed legal error by failing to address them has been fully considered but are not persuasive.
The examiner acknowledges the holdings of In re Lowry and IOENGINE. In Lowry, the court found that the claimed data structures imposed a specific physical organization on computer memory that improve the computer operation. Similarly, in IOENGINE it was found that the claimed encrypted program data stored on the portable device was not simply printed matter because this data was used by a processor to control the computer operations. However, the present claims are different from those presented in Lowry and/or IOENGINE. Here, the disputed claim limitations do not recite any functional use.
The determination of whether a claim limitation constitutes printed matter depends on whether the limitation is directed to the descriptive material itself and whether that content is functionally related to its substrate. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability. The critical question is whether there exists any new and unobvious functional relationship between the printed matter and the substrate (In re Ngai 367 F.3d 1336, 1339, 70 USPQ2d 1862 (Fed. Cir. 2004); Ex parte Nehls 88 USPQ2d 1883, 1888-1889 (BPAI 2008); In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994); MPEP § 2111.05; Cf. In re Gulack, 703 F.2d 1381, 1385, 217 USPQ 401, 404 (Fed. Cir. 1983)).
Further, the applicant asserts that “the examiner reasons that whether the digital identity data is cryptographically signed has no bearing on patentability… The identical logic would strip patentable weight from any limitation reciting that data is signed, encrypted or otherwise cryptographically secured across every application and every issued patent in the security space.” The examiner finds these assertions not persuasive and mischaracterized. The examiner does not ignore the cryptographic signature or suggests that authenticated data is technically identical to unauthenticated data. Rather, the cryptographic signature does not provide patentability because the claim only recites receiving the cryptographically signed digital identity data, encrypting the cryptographically signed digital identity data and transmitting the cryptographically signed digital identity data without utilizing the cryptographic signature for any purpose (i.e. verification, validation).
The applicant also argues that the examiner did not perform the pertinent analysis of the limitations at issue. The examiner respectfully disagrees and provides below an analysis of each of the disputed limitations. Based on this analysis and upon further review of the record, the examiner maintains the previously stated position.
“the digital identity data cryptographically signed by an identity provider and provided by a mobile wallet of the transacting partner” The signature used to cryptographically sign the digital identity data is not functionally used and the claims merely recite receiving digital identity data, encrypting the digital identity data and transmitting the encrypted digital identity data but do not recite any steps involving the use of the cryptographic signature on the digital identity data. The processor performs the same operations of receiving, encrypting and transmitting regardless if the digital identity data is cryptographically signed or not. Accordingly the recited limitation merely describes a characteristic of the received digital identity data.
“the trust score is derived from previous transactions and a database of fraudulent activity” The limitation merely recites information about how the trust score was derived and does not recite any functional use. The manner in which the trust score was derived does not affect any of the positively recited steps in the claim.
“the transaction details include at least one of the following: transaction amount, transaction date and time, location of the transaction, and type of transaction” The transaction details merely define the informational content of the transaction details and do not recite any functional use of these specific content that change the operation of the computer. Therefore, the computer performs the same steps regardless of the particular transaction details included.
“wherein the verified status indicator is based on a match between the digital identity data and user account data on a payment service of the transacting partner”. The limitation merely recites information about what the status indicator is based on and does not recite any functional use. The manner in which the status indicator is determined does not affect any of the positively recited steps in the claim as the claim only receives the status indicator and it is not further used or processed by any of the positively recited steps in the claims.
Intended use/result Language
The applicant asserts that the examiner improperly characterized the limitation “wherein the feedback is used to update trust scoring for future transactions” and such limitation is “more than the intended result of a process step; it is part of the process itself”. The examiner respectfully disagrees and maintains the previously stated position. The limitation recites the intended use of the feedback provided to the trust score service. The claimed system positively recited step is to provide the feedback on the transaction to the trust score service. The subsequent use of the feedback to update the trust scoring describes what the receiving service does with the feedback, not a functional limitation imposed on the claimed system.
Claim Rejections – 35 U.S.C. § 112
Claim rejections 35 U.S.C. § 112 in the previous final action dated 04/10/2026 are withdrawn in light of the claim amendments.
Claim Rejections – 35 U.S.C. § 101
The applicant presents several assertions in regards to claim rejection 101. The basis for these assertions are based on the applicant’s argument on pages 12-14.
First, the applicant asserts that “the examiner characterization of the claims as directed to fundamental economic principles are analogous to traditional credit risk financial scoring” mischaracterizes both the claim invention and the technical problem it solves and that “the claimed invention addresses a problem that arises only in the realm of mobile payment technology”. The examiner finds these assertions not persuasive and respectfully disagrees. The claim recites a process of receiving transaction related data, encrypting and transferring the data, receiving a score, comparing the score to a threshold to determine the trust of the transaction and proving a user the option to verify the score and cancel the transaction which is analogous to traditional credit risk financial scoring processes. The fact that the claim is implemented in a mobile wallet environment does not remove the claim from the realm of abstract ideas. Under 101 analysis the focus is not on the technological field in which the claim is applied, but on whether the claim as a whole is directed towards an abstract idea and whether it recites a technological improvement or solution. Here, the claim remain directed to determining a trust score based on the identity information received and using that score to determine whether to approve or cancel a transaction, which is a form of trust/risk assessment and it does not recite any technological improvement or solution to a pertinent computer technology.
Second, the applicant continues to compare the present claim with those in DDR Holdings and asserts that the present claim have no pre-mobile-payment analogous. The applicant asserts that traditional credit risk scoring is performed only by financial institutions well in advanced of credit decisions and it does not occur during real time mobile payment, does not involve real time cryptographic identity exchange between transacting parties, does not involve real-time public key encryption of identity data and does not involve threshold based modification of a transaction-control user interface providing a time bounded user intervention window. The examiner finds these assertions not persuasive and respectfully disagrees. The claim recites receiving identity information, evaluating the information, receiving a score and using the score to process a transaction which involves information analysis and risk assessment as previously mentioned. Further, the alleged real time processing does not affect the 101 determination because the speed or timing in which an abstract idea is performed does not transform the underlining abstract idea. Here, the claim does not recite any improvement to a computer technology, network or mobile wallet and merely utilize generic computing components to apply the abstract idea.
Third, the applicant asserts that the examiner’s characterization of the encrypting and validating steps as mental process and mathematical concepts is incorrect because public key cryptography involves mathematical operations performed on integers of hundred/thousands of bits which cannot be performed in the human mind or using pen and paper. The examiner finds this assertion persuasive and agrees that the recited limitations of “encrypting…” and “validating…”do not recite mental processes because such cryptographic operations cannot be practically performed in the human mind. However, this does change the eligibility analysis as the limitations continue to recite mathematical concepts because encryption with a public key and validation of a cryptographic signature are implemented by applying a mathematical algorithms to numerical data as stated by the applicant. The fact that these algorithms require to be process by a computer due to their complexity does not change their mathematical nature.
Finally, the applicant asserts that the claims integrate any abstract idea into a practical application by reciting a specific improvement to the user interface and operation of mobile wallet applications and alleges that the claims are similar to those found in Core Wireless Licensing. The examiner finds these assertions not persuasive and respectfully disagrees. Unlike in Core Wireless Licensing that is directed to an improved user interface for small-screen devices, here the claims do not improve the functioning of the computer or user interface. The claims merely display the risk score based on one or more thresholds to the user with an option to cancel the transaction. In other words, the interface performs its normal operation of displaying information and receiving user input and does not recite any new improvement to the interface or computer functionality. Therefore, the claims do not integrate the abstract idea into a practical application as asserted by the applicant.
As such the claims remain within an abstract idea and rejection is maintained based on the
newly amended claims.
Claim Rejections – 35 U.S.C. § 103
Applicant submits remarks and arguments geared toward the amendments. Examiner has carefully reviewed and considered Applicant’s remarks, however they ARE MOOT in light of the fact that they are geared towards the newly added claimed expression in the amendments.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's
disclosure:
US 20250278576 A1 to Kumar discloses: This disclosure describes methods, non-transitory computer readable storage media, and systems that use intelligent digital content analysis and large language models to resolve transaction disputes. The disclosed system selects appropriate digital content analysis tools for analyzing digital documentation including details of a transaction in response to a transaction dispute. The disclosed system utilizes data extracted from the digital documentation to generate a number and type(s) of model prompts to provide to a large language model based on attributes of the transaction dispute. The disclosed system uses responses generated by the large language model for the model prompts to determine a dispute resolution operation (e.g., approval, denial, or agent review). Furthermore, the disclosed system provides a response to the request to one or more computing devices associated with the request in response to execution of the dispute resolution operation.
US 11188740 B2 to Huang discloses: Methods, systems, and devices for object detection are described. A device may receive an image, and detect, via a first stage of a cascade neural network, object recognition information over one or more angular orientations during a first pass. The device may determine, via a second stage of the cascade neural network, a confidence score associated with one or more of the candidate object in the image, the candidate bounding box associated with the candidate object in the image, or one or more object features of the candidate object in the image, or an orientation of the candidate object in the image, or a combination thereof. The device may identify, via a third stage of the cascade neural network, whether to detect the object recognition information during a second pass based on the confidence score satisfying a threshold.
US 20190180039 A1 to Considine discloses: A computerized method is provided for automatically authorizing an access request from a user to perform a task with respect to a computing application of an application lifecycle management (ALM) system. The computerized method includes receiving, by a computing device, the access request from the user to perform the task with respect to the application in the ALM system and calculating, by the computing device, a risk score associated with the access request. Calculating the risk score includes determining a plurality of factors including: (i) at least one factor associated with the application indicative of an importance level of the application and (ii) at least one factor characterizing technical experience of the user, and computing the risk score as a weighted sum of the plurality of factors. The method further includes determining, by the computing device, whether to authorize the user access request based on the risk score.
US 20220382838 A1 to Sozzani discloses: Techniques are disclosed relating to computing security and privacy. In some embodiments, a computing device provides, to a service computing system, a service request that identifies an action and includes an anonymous identifier for a user of the computing device. The computing device receives, from the service computing system, a score request for a trustworthiness score indicative of the user's trustworthiness. In response to receiving the score request from the service computing system, the computing device provides information indicative of the user's identity to a scoring computing system and receives the trustworthiness score and a corresponding score signature from the scoring computing system. In response to receiving the score and the score signature from the scoring computing system, the computing device provides the score to the service computing system.
US 20230252456 A1 to Rapowitz discloses: Systems and methods for recovery access to lost blockchain wallet seed phrases are disclosed. The systems and methods can store seed phrases for users for future retrieval. In some examples, a decentralized oracle creates an oracle private key that can be used to authenticate a user who is requesting the seed phrase. In some examples, the oracle creates a private/public key pair that can be used to transmit and store an encrypted version of the seed phrase. The authentication steps described herein also include knowledge-based authentication questions about the wallet, e.g., prior transactions using the wallet, value of the wallet, and the like.
US 8285648 B2 to Goodin discloses: In an electronic transaction, the invention provides a process and system for blocking a user's account until a verifier verifies the identity of the user. The process comprises pre-enrolling the user and the user's personal communication device. Optionally, one or more of the user's accounts are enrolled. At the time a transaction is initiated, the verifier sends an identification verification request to the portable communication device of the person initiating the electronic-transaction. The person then verifies his/her identity as the user. Optionally, the user authorizes the amount of the transaction. Optionally, the verifier issues to the user a proxy transaction card which the user uses to initiate electronic transactions that will be billed to one of the user's pre-enrolled accounts. Using information obtained from the user's proxy transaction card, the retailer/merchant's bank opens a communications link to the verifier, and the verifier then verifies the user's identity.
CN 110557751 B to Li et al. discloses: The invention claims an authentication based on server trust evaluation. The invention claims techniques for enabling a user to activate a new device using a mobile network operator (MNO) without providing a user with a MNO authentication credential that is easily forgotten. The user uses the credentials from the MNO trusted (associated with the user) of the existing device and also uses the trust score provided by the third party server that is aware of the relevance between the user and the existing device to activate the new device. The new device may be a supplemental device, such as a supplemental wearable device as a supplemental cellular telephone, wherein the two devices still can access the service provided by the MNO after using the MNO activation new device. The new device may also be a replacement device, such as a new telephone, a tablet computer or a wearable device, wherein the new device replaces the service provided by the MNO for the existing device.
US 20190318359 A1 to Arora discloses: A method for determining fraud for a transaction via blockchain includes: receiving blockchain data for a blockchain including a plurality of blocks, each block being comprised of a block header and data values, each data value corresponding to a declined payment transaction and including an account identifier, timestamp, and point of sale identifier; receiving payment credentials associated with a transaction account, the payment credentials including an account number; identifying one or more data values where the account identifier is the account number; determining a decline of a payment transaction involving the transaction account based on transaction data for the payment transaction and data included in the one or more data values; and transmitting a timestamp, the account number, and a device identifier to a node associated with the blockchain.
US 20170300898 A1 to Campero et al. discloses: Disclosed are techniques that use devices with corresponding identity wallet applications that execute on an electronic processor device of the devices, and which identity wallets store identity information and encrypt the stored identity information. A distributed ledger system, and a broker system that interfaces to the wallet and the distributed ledger are used for various information exchange scenarios in which a requesting system and user devices, the distributed ledger system, the broker system and the requesting system are interconnected via an electronic network through respective network interface devices.
US 20150019443 A1 to Sheets et al. discloses: Embodiments of the present invention are directed to methods, apparatuses, computer readable media and systems for securely processing remote transactions. One embodiment of the invention is directed to a method of processing a remote transaction initiated by a mobile device comprising a server computer receiving a payment request including encrypted payment information. The encrypted payment information being generated by a mobile payment application of the mobile device and being encrypted using a third party key. The method further comprises decrypting the encrypted payment information using the third party key, determining a transaction processor public key associated with the payment information, and re-encrypting the payment information using the transaction processor public key. The method further comprises sending a payment response including the re-encrypted payment information to a transaction processor. The transaction processor decrypts the re-encrypted payment information using a transaction processor private key and initiates a payment transaction.
US 11605090 B2 to Bhusri et al. discloses: Systems for securing transactions based on merchant trust score are disclosed. The system may receive information identifying a merchant from a user device and, in response, retrieve transaction data associated with the merchant and receive website data in response to receiving information identifying the merchant. The system may use a machine learning model to generate a merchant trust score for the merchant, and determine whether the merchant trust score is less than a predetermined threshold. The system may also generate or retrieve an alternative payment method and provide related information or a recommendation to the user device.
US8327131 to Hardjono discloses: A target machine can be verified prior to being granted access to a resource on a network by interrogating and analyzing digests of various elements of the target machine. The digests can be collected into an integrity report and provided to a Trust Scoring Service. The Trust Scoring Service receives the integrity report and compares the digests with signatures stored in a signature database. A trust score certificate can then be issued to the target machine. The Trust Scoring Service can include a Score Evaluation Server which can interact with a Kerberos Authentication Server and a Ticket Granting Server to embed a trust score within a Kerberos Ticket to enforce a richer set of access policies. The integrity of a web server can be verified and a Trust Score Certificate Logo can be displayed on a corresponding home page of a merchant. By clicking on the Trust Score Certificate Logo, a user can verify the integrity of the merchant's web servers prior to completing a transaction with the merchant.
US 9160742 B1 to Ackerman et al. discloses: An improved technique involves sending a user's authentication information to a local authentication device that computes a risk score and sends the risk score to a remote authentication server that determines whether the user is able to be authenticated. When the user makes an authentication or transaction request from an electronic device such as a computer or smartphone, the electronic device sends predictor values such as geo location and wireless signal strength to the local authentication device. The local authentication device then computes a risk score based on the received predictor values and historical predictor values. The local authentication device sends this risk score to a remote authentication server which determines from this risk score and other factors whether the user is able to be authenticated.
WO 2018164684 A1 to Krishnan et al. discloses: Embodiments of the disclosure are directed to methods, systems, and devices for the use of portable devices, such as a vehicle driven by a user, that are distinctive physical objects and can be presented to an authentication system for authentication purposes. More specifically, the portable device may be used as a source of information for the authentication system that can be verified. Images may be captured of the portable devices in order to determine their distinctive features for comparison to other physical objects registered to the user. The portable devices may also be a source of metadata, or additional contextual information associated with those portable devices or their interaction with the authentication system. The image data and/or the metadata associated with a portable device can be verified for fraud or risk analysis.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
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.
/J.L./Examiner, Art Unit 3698
/STEVEN S KIM/Primary Examiner, Art Unit 3698
Prosecution Insights