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 .
Status of Claims
This is the final office action in response to the applicant’s arguments/remarks filed on December 10, 2025.
Claims 1-2, 4, 11-12, and 14 have been amended.
Claims 1-20 are pending and have been examined.
Priority
The applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
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. The applicant's submission filed on 07/01/2025 has been entered.
Responses to Arguments/Remarks
35 U.S.C. 101 rejection:
Regarding the 101 rejection, the applicant contends that the technical advantages of the amended claims, further described by the presented paragraphs of the specification, integrate the judicial exception into a practical application. The examiner agrees, and 101 rejection has been withdrawn.
35 U.S.C. 103 rejection:
The secondary reference, Gauld, discloses receiving, from the user conducting the transaction with the resource provider (i.e., a retailer), a user blockchain associated with the user. (See paragraph [0034], “[e]ach of the consumers 102 may have a portable computing device 110A, 110B. 110N (collectively portion computing devices 110)”; paragraph [0038], “[t]he consumer 102A may want to spend rewards credits from retailer 102A at retailer 102B”; Fig. 3; paragraphs [0045]-[0046], “[t]he method may begin at stage 302 where a copy of the consumer ledger may be received. As disclosed herein, the consumer ledger may be received by the computing device 200”; paragraph [0049], “[f]or example, as transactions are verified, the ledger can be updated and transmitted to other entities on the network 108. For instance, a retailer, such as retailer 104B, may verify a transaction between retailer 104B and consumer 102A”; and claim 8, “receiving, at a computing device and from a portable computing device, a copy of the consumer ledger and a transaction posted to the consumer ledger.” These citations indicate that a retailer computer receives from a consumer a consumer ledger and a transaction request between the retailer and the consumer.)
Regarding the amended claim 4, the cited reference, Green, discloses assigning a weight value to one or more factors associated with the plurality of transaction records; and determining the level of risk for the transaction based on at least in part on the assigned weight value. (See col. 4, lines 4-15, “[f]or example, the scoring system may assign a score to each considered factor, such as failure rate, transaction value, value trends, dispute rate, or other suitable factors. The scores may be proportional to a percentage of transactions conforming to each factor. For example, a score for the dispute rate may be proportional to the percentage of total transactions that are disputed”; col. 6, lines 35-52, “[i]sing one or more of the described factors affecting the proposed transaction, the risk rating system can generate a transaction risk rating…. The transaction risk rating may be a calculated score based on scores assigned to one or more of the factors affecting the transaction risk.”)
The applicant’s amendments have overcome the 35 U.S.C. § 103 rejection. However, there are new grounds of rejection necessitated by the applicant’s amendments as detailed in the 35 U.S.C. § 103 rejection section.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 7-15, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Smith et al. (US 20170317997 A1) in view of Gauld (US 20180247320 A1), and further in view of Kurani et al. (US 11188918 B1) and Green et al. (US 8788420 B1).
Claims 1 and 11:
Smith discloses the following:
a resource provider computer (i.e., a device/computer associated with a merchant)/a system comprising: one or more processors; and a memory including instructions that, when executed by the one or more processors, cause the resource provider computer/the one or more processors to. (See paragraph [0076]; Fig. 1; paragraph [0175], “[v]erifier 160 may be a merchant, a bank, or other entity in need of verification of user identities”; and paragraph [0205], “[t]he merchant verifies the existence of the attestation transaction at the attestation address in the centralized or distributed ledger in step 790. In one embodiment, the merchant additionally verifies that the transaction is in the unspent transaction output (UTXO) cache and therefore is still valid and has not been revoked.”)
receive a request to complete a transaction between the resource provider computer and a user, the request including at least information related to the user. (See Fig. 7; paragraphs [0204]-[0205], “[i]n the exemplary embodiment, the business transaction is a purchase transaction, and the commercial website is a merchant website…. In step 730 of FIG. 7, the merchant website receives the user information necessary in order to complete the purchase. In one embodiment, receiving information comprises receiving from the attestor the information of the user. The merchant website may then verify the information using the verification protocol described earlier above”; Fig. 9; and paragraph [0210], “[a] communication channel is set up between the user's device and the merchants' server in order for all data to be passed across…. In step 910, the merchant receives a code which represents its save information of the user, wherein the code is provided by an output device for a processor associated with the user, and wherein the information has been previously attested to in an attestation transaction stored within a centralized or distributed ledger at an attestation address.”)
generating a hashed electronic identifier (i.e., an attestation address) associated with the user. (An attestation address is generated by applying a hash function to a public attest key. The public attest key is generated based on the information received from a user and a user’s private key. The generated attestation address is used for accessing a distributed ledger/blockchain for transactions. See paragraphs [0011]-[0012], “[i]n some embodiments, generating the attestation address for a single signature transaction includes applying a second hash function to the public attest key. The second hash function can include the P2PKH algorithm”; paragraphs [0204]-[0205], “[i]n step 770, the merchant derives a public attest key using the information received from the user and the user's private key, as described in the methods herein. In step 780, the merchant further derives an attestation address using the public attest key, and the other public keys received, as described in the methods herein. The merchant verifies the existence of the attestation transaction at the attestation address in the centralized or distributed ledger in step 790.”)
wherein the user blockchain is generated from one or more transaction records; access the user blockchain associated with the user using the generated hashed electronic identifier, wherein the user blockchain is generated by a validation node server (i.e., a computer/device associated with an attestor) and comprises a plurality of transaction records. (Smith discloses that a verifier can be a merchant; a verifier may have a copy or subset of the distributed ledger including the user’s attestation transactions; the subset of the distributed ledger may be provided by an attestor; and a verifier/merchant accesses the distributed ledger for locating transaction(s) associated with the user. See paragraph [0011], “[i]n some embodiments, generating the attestation address for a single signature transaction includes applying a second hash function to the public attest key. The second hash function can include the P2PKH algorithm”; paragraph [0080], “[i]n some embodiments, the computer system is further configured by machine-readable instructions to maintain a database of attestation transactions, each attestation transaction relating to one or more items of information of the user, the attestation transaction includes an attestation address based on a public attest key, and wherein the public attest is derived by combining a hash of the information with a user's public key generated for the information”; Figs. 1-2; paragraphs [0175]-[0176], “[v]erifier 160 may be a merchant, a bank, or other entity in need of verification of user identities…. Some or all of the participants may have access to a centralized or distributed ledger 150. Centralized or distributed ledger 150 is an electronic ledger which contains a list of verified transactions of digital cryptocurrency”; paragraph [0179], “[t]he centralized or distributed ledger 150 may be accessed from a cached offline store. A relevant subset of the centralized or distributed ledger 150 may be provided by an attestor 120”; paragraph [0185], “[t]his signed attestation transaction is communicated to the network by the attestor 120, for storage in the centralized or distributed ledger 150. The signed attestation transaction may include the user's public attest key, and is stored at an attestation address”; Fig. 7; paragraphs [0204]-[0205], “[i]n step 770, the merchant derives a public attest key using the information received from the user and the user's private key, as described in the methods herein. In step 780, the merchant further derives an attestation address using the public attest key, and the other public keys received, as described in the methods herein. The merchant verifies the existence of the attestation transaction at the attestation address in the centralized or distributed ledger in step 790. In one embodiment, the merchant additionally verifies that the transaction is in the unspent transaction output (UTXO) cache and therefore is still valid and has not been revoked”; paragraph [0209], “[t]he verifier can consult its own cached copy or subset of the centralized or distributed ledger database that may contain the user's attestation transactions”; and paragraph [0229], “[i]n step 1510, the attestor creates an attestation address based on the public attest key. In step 1512, the attestor generates a signed transaction and broadcasts the transaction to a centralized or distributed ledger.” Examiner’s Note: Smith discloses that a relevant subset of the distributed ledger may be provided by the attestor. This indicates that the relevant subset is formed/generated by the attestor. The attestor provides a relevant subset of the distributed ledger, which can be a blockchain, to other entities, such as a verifier/merchant. The verifier/merchant performs the validation based on the subset of the distributed ledger.)
verify at least one transaction record of the plurality of transaction records using the information related to the user, information included in the at least one transaction record, and a public key associated with the validation node server. (See Fig. 7; paragraphs [0204]-[0205], “[i]n one embodiment, the information requested from the user may include the user's public key, and the public keys of the attestor and any third-party cosigners of the attested information. In one embodiment, the merchant may request the public keys of the user, the attestor, and any one or more third-party cosigners from a digital wallet…. In step 770, the merchant derives a public attest key using the information received from the user and the user's private key, as described in the methods herein. In step 780, the merchant further derives an attestation address using the public attest key, and the other public keys received, as described in the methods herein. The merchant verifies the existence of the attestation transaction at the attestation address in the centralized or distributed ledger in step 790.”)
determining, upon verifying the at least one transaction record, (a verification result); and complete the transaction upon determining that […] (the verification result meets a degree of confidence). (See Fig. 7; paragraphs [0204]-[0205], “[i]n step 790, the existence of the attestation transaction at the attestation address in the centralized or distributed ledge is verified. In step 792, upon verification of the existence of the attestation address, the purchase transaction is completed…. The merchant may now have a high degree of confidence that the information provided by the user is valid. The merchant may proceed to complete the purchase transaction in step 792, without necessarily having to re-verify the information through additional fraud detection and prevention steps.”)
Smith does not disclose receiving, from the user conducting the transaction with the resource provider computer, a user blockchain associated with the user, wherein the user blockchain is generated from one or more transaction records received from the resource provider computer; wherein the user blockchain comprises a plurality of transaction records received from the resource provider computer, wherein the user blockchain is uneditable by the user; determining a level of risk for the transaction based on the plurality of transaction records and completing the transaction upon determining that the level of risk for the transaction is below a threshold level of risk.
However, Gauld, an analogous art of processing transactions via a blockchain, discloses receive, from the user conducting the transaction with the resource provider computer (i.e., a retailer), a user blockchain associated with user; wherein the user blockchain is generated from one or more transaction records received from the resource provider computer; and wherein the user blockchain comprises a plurality of transactions records received from the resource provider computer, wherein the user blockchain is uneditable by the user. (See paragraph [0016], “[a]s disclosed herein, implementing a consumer loyalty scheme using Blockchain technology has a number of unique features and advantages…. As such, this transacting economy needs to be supported by a transaction or payments system and have an immutable record or ledger of loyalty points ownerships by its members and also record all transactions”; paragraph [0034], “[e]ach of the consumers 102 may have a portable computing device 110A, 110B. 110N (collectively portion computing devices 110)”; paragraph [0038], “[t]he consumer 102A may want to spend rewards credits from retailer 102A at retailer 102B”; Fig. 3; paragraphs [0045]-[0046], “[t]he method may begin at stage 302 where a copy of the consumer ledger may be received. As disclosed herein, the consumer ledger may be received by the computing device 200”; paragraph [0049], “[f]or example, as transactions are verified, the ledger can be updated and transmitted to other entities on the network 108. For instance, a retailer, such as retailer 104B, may verify a transaction between retailer 104B and consumer 102A”; and claim 8, “receiving, at a computing device and from a portable computing device, a copy of the consumer ledger and a transaction posted to the consumer ledger.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Gauld in the Smith system. Moreover, in order to improve the transaction process in the Smith system, one of ordinary skill in the art would have been motivated to let a user/consumer provide a consumer ledger to a resource provider, so that the transaction can be effectively validated based on the consumer ledger provided by the user without accessing other resources.
The combination of Smith and Gauld discloses the claimed invention but does not disclose determining a level of risk for the transaction based on the plurality of transaction records and completing the transaction upon determining that the level of risk for the transaction is below a threshold level of risk.
However, Kurani, an analogous art of validating a transaction via a blockchain, discloses the following:
determine a level of risk for the transaction based on the plurality of transaction records. (See col. 2, lines 1-20, “[t]he customer score relates to a likelihood that a MBC payment from the customer to the merchant will be verified…. The transaction database includes a history of all transactions associated with the MBC. The method includes identifying, by the processor, transactions associated with the customer address in the transaction database. The method further includes calculating, by the processor, the customer score for the customer based at least in part on the transactions associated with the customer address”; Fig. 1; and col. 7, line 46 – col. 8, line 8, “[t]he transaction database may, for example, be the MBC blockchain 116…. To calculate the score, transactions associated with the provided customer address are located at 312.”)
complete the transaction upon determine that the level of risk for the transaction satisfies a threshold level of risk. (See col. 8, lines 35-56, “[r]ather, the merchant can set internal customer score thresholds and independently decide whether to allow the customer to leave with the goods or services or to make the customer wait until the pending MBC transaction is verified by the MBC verification nodes 112.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Kurani in the Smith system as modified. Moreover, in order to improve the practicality of the transaction processing of the Smith system as modified, one of ordinary skill in the art would have been motivated to determine a customer score based on the transaction history, so that the transaction can be processed based on the comparison of a predetermined threshold with the determined customer score.
The score can be used to indicate the level of trust or the level of risk. The examiner introduces another reference to disclose that a score can be used as a level of trust or a level of risk, so that the satisfaction of a threshold can be higher or lower than the threshold based on whether the score is for the level of trust or for the level of risk.
Green, an analogous art of validating a transaction based on the transaction history, discloses determining a score for level of risk or level of trust. (See col. 1, lines 41-62, “[i]f the user is familiar with the payor, then the user may feel comfortable accepting the payment from the payor and that the transaction will be completed. However, if a third person with which the user is not familiar attends the meal, the user may desire to know if the transaction is likely to be successful before accepting a P2P payment…. In another example, a user may desire to sell an item to a payor, such as at a flea market or on an Internet commerce site such as CRAIGSLIST…. The user would like to know that a transaction has a high likelihood of being completed before giving the purchased item to the payor”; col. 11, lines 30-41, “[t]he risk rating system 130 may additionally or alternatively score each transaction and combine the transaction scores to create the counter-party rating…. The counter-party risk rating may be provided as a risk rating or as a trustworthiness rating. For example, a 100 score in a 1-100 scoring system may indicate a perfect level of trust for a rating. Alternatively, a 100 score in a 1-100 scoring system may indicate a highest possible riskiness level”; and col. 14, lines 11-34, “[a] score may be assigned to each transaction in the selected history of the counter-party. The scores may be summed or averaged into a transaction risk rating or in any other suitable manner associated with a transaction risk rating.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Green in the Smith system as modified. Moreover, in order to improve the flexibility of the transaction processing of the Smith system as modified, one of ordinary skill in the art would have been motivated to determine a risk score as the level of trust or the level of risk, so that the transaction can be validated and processed flexibly based on different business requirements.
Examiner’s Note: The cited validation node server is out of scope of the claimed resource provider computer of claim and/or the claimed system of claim 11. Whether the user blockchain is generated by a validation node server or by any other node/server/device does not impact the scope of the claim when the validation node server is out of scope of the claimed resource provider computer and/or the claimed system.
Claims 2 and 12:
Smith in view of Gauld, Kurani, and Green discloses the limitations shown above.
Smith further discloses wherein the at least one transaction record of the plurality of transaction records is signed using a private key associated with the validation node server. (See paragraph [0007]; paragraph [0152], “[a]s this data is attested to, the site is able to verify the information using the verification protocol, and then knows it is getting authenticated information (the information is authenticated by the attestor who signed the attestation transaction on the distributed ledger)”; paragraph [0161], “[t]he attestation transaction should spend some amount to the attestation address, confirming that the transaction is signed by a trusted attestor's key, which affirms that the transaction in the centralized or distributed ledger is valid, and that the proffered user information is authentic”; and paragraph [0231], “[i]n step 1510, the attestor creates an attestation address based on the public attest key, as previously described. In step 1512, the generates a signed transaction using their private key, and broadcasts the transaction to the centralized or distributed network.”)
Claims 3 and 13:
Smith in view of Gauld, Kurani, and Green discloses the limitations shown above.
Smith discloses wherein the instructions further cause the resource provider computer to determine a verification result that meets a degree of confidence. (See Fig. 7; paragraphs [0204]-[0205], “[i]n step 790, the existence of the attestation transaction at the attestation address in the centralized or distributed ledge is verified. In step 792, upon verification of the existence of the attestation address, the purchase transaction is completed…. The merchant may now have a high degree of confidence that the information provided by the user is valid. The merchant may proceed to complete the purchase transaction in step 792, without necessarily having to re-verify the information through additional fraud detection and prevention steps.”)
Green further discloses determining a level of trust for each transaction record of the plurality of transaction records. (See col. 14, lines 11-34, “[a] score may be assigned to each transaction in the selected history of the counter-party. The scores may be summed or averaged into a transaction risk rating or in any other suitable manner associated with a transaction risk rating.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Green in the Smith system as modified. Moreover, in order to improve the accuracy of the transaction processing of the Smith system as modified, one of ordinary skill in the art would have been motivated to determine a score for each transaction included in the transaction history, so that the transaction can be accurately validated based on transaction history.
Claims 4 and 14:
Smith in view of Gauld, Kurani, and Green discloses the limitations shown above.
Smith discloses wherein the instructions further cause the resource provider computer to determine a verification result that meets a degree of confidence. (See Fig. 7; paragraphs [0204]-[0205], “[i]n step 790, the existence of the attestation transaction at the attestation address in the centralized or distributed ledge is verified. In step 792, upon verification of the existence of the attestation address, the purchase transaction is completed…. The merchant may now have a high degree of confidence that the information provided by the user is valid. The merchant may proceed to complete the purchase transaction in step 792, without necessarily having to re-verify the information through additional fraud detection and prevention steps.”)
Green further discloses assigning a weight value to one or more factors associated with the plurality of transaction records; and determining the level of risk for the transaction based at least in part on the assigned weight value. (See col. 4, lines 4-15, “[f]or example, the scoring system may assign a score to each considered factor, such as failure rate, transaction value, value trends, dispute rate, or other suitable factors. The scores may be proportional to a percentage of transactions conforming to each factor. For example, a score for the dispute rate may be proportional to the percentage of total transactions that are disputed”; col. 6, lines 35-52, “[i]sing one or more of the described factors affecting the proposed transaction, the risk rating system can generate a transaction risk rating…. The transaction risk rating may be a calculated score based on scores assigned to one or more of the factors affecting the transaction risk.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Green in the Smith system as modified. Moreover, in order to improve the accuracy of the transaction processing of the Smith system as modified, one of ordinary skill in the art would have been motivated to determine the risk rating based on a weight value assigned to each transaction, so that the transaction can be accurately validated based on transaction history.
Claims 5 and 15:
Smith in view of Gauld, Kurani, and Green discloses the limitations shown above.
Green further discloses wherein the weight value is assigned to the at least one transaction record of the plurality of transaction records based on a type of the at least one transaction record. (See claim 5, “wherein the determination of the risk rating for the proposed transaction based on the scores assigned to the transactions related to the proposed transaction is calculated by a weighted average of the scores assigned to the transactions related to the proposed transaction”; and claim 13.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Green in the Smith system as modified. Moreover, in order to improve the accuracy of the transaction processing of the Smith system as modified, one of ordinary skill in the art would have been motivated to determine weight value based on the type of the transaction, so that the transaction can be accurately validated based on transaction history.
Claims 7 and 17:
Smith in view of Gauld, Kurani, and Green discloses the limitations shown above.
Smith discloses wherein a blockchain network associated with the user blockchain comprises a plurality of nodes, and wherein the plurality of nodes includes at least a plurality of acceptance nodes. (See paragraph [0134], “[t]he distributed ledger is replicated among many different nodes in a peer-to-peer network, and a consensus algorithm ensures that each node's copy of the ledger is identical to every other node's copy.” A blockchain network comprises a plurality of nodes, and any node in the blockchain network can be an acceptance node.)
Examiner’s Note: A blockchain network associated with the user blockchain is out of scope of the claimed resource provider computer and/or the claimed system.
Claims 8 and 18:
Smith in view of Gauld, Kurani, and Green discloses the limitations shown above.
Smith discloses wherein an acceptance node server is a computer operated by a resource provider. (See paragraph [0020], “receiving at a processor associated with a verifier the information of the user; sending a cryptographic challenge nonce”; Fig. 1; and paragraph [0175], “[v]erifier 160 may be a merchant, a bank, or other entity in need of verification of user identities.” The device/computer associated with the verifier, such as a merchant, can be an acceptance node server.)
Examiner’s Note: An acceptance node server is out of scope of the claimed resource provider computer and/or the claimed system.
Claims 9 and 19:
Smith in view of Gauld, Kurani, and Green discloses the limitations shown above.
Smith discloses wherein the user blockchain network comprises a plurality of nodes. (See paragraph [0134].)
Kurani further discloses wherein a blockchain network associated with the user blockchain comprises a plurality of nodes, and wherein the plurality of nodes includes at least a plurality of validation nodes. (See Fig. 1; col. 4, lines 19-43, “[o]nce verified by the MBC verification nodes 112, the transaction is recorded in a MBC blockchain 116. The MBC blockchain 116 is a chronological and public ledger of all MBC transactions that have been executed.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Kurani in the Smith system as modified. Moreover, in order to improve the practicality of the Smith system as modified, one of ordinary skill in the art would have been motivated to include a plurality of validation nodes in a blockchain network, so that the transaction can be validated by the validation nodes after it is broadcast to the blockchain network.
Examiner’s Note: A blockchain network associated with the user blockchain is out of scope of the claimed resource provider computer and/or the claimed system.
Claims 10 and 20:
Smith in view of Gauld, Kurani, and Green discloses the limitations shown above.
Kurani further discloses generating a new transaction record related to the transaction in the transaction request; and transmitting the new transaction record to a validation node to be appended to the user blockchain. (See col. 4, lines 19-44, “[t]he MBC verification nodes 112 verify that the customer's address has enough MBC to complete the pending transaction and that the customer has authorized the pending transaction by cryptographically verifying the encrypted transaction. Once verified by the MBC verification nodes 112, the transaction is recorded in a MBC blockchain 116”; col. 10, lines 25-44, “[a]fter creating a MBC transaction and embedding the guarantee identifier in the MBC transaction, the MBC transaction is broadcast to the MBC verification nodes 112 at 412. The financial institution computing system 120 broadcasts the MBC transaction to the MBC verification nodes 112 via the network 114.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Kurani in the Smith system as modified. Moreover, in order to improve the practicality of the Smith system as modified, one of ordinary skill in the art would have been motivated to generate a transaction record and transmit the transaction record to a validation node to be included in the blockchain, so that the transaction information can be immutably stored in the blockchain.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Smith et al. (US 20170317997 A1) in view of Gauld (US 20180247320 A1), and further in view of Kurani et al. (US 11188918 B1), Green et al. (US 8788420 B1), and Iannace et al. (US 20160260104 A1).
Claims 6 and 16:
Smith in view of Gauld, Kurani, and Green discloses the limitations shown above.
None of Smith, Gauld, Kurani, and Green discloses wherein the weight value is assigned to the at least one transaction record of the plurality of transaction records based on an origination entity associated with the at least one transaction record.
However, Iannace, an analogous art of calculating a score based on the transactions, discloses wherein the weight value is assigned to the at least one transaction record of the plurality of transaction records based on an origination entity associated with the at least one transaction record. (See paragraphs [0041]-[0042], “[t]he calculated member estimation score may be based upon data related to each of the transaction data entries within a consumer transaction set…. For instance, transactions that take place at a point of sale device physically located at an entity location are weighted more heavily (i.e., they are indicative of a higher likelihood that the consumer is a member of the entity) than transactions associated with point of sale identifiers located at a distance from the entity location.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Iannace in the Smith system as modified. Moreover, in order to improve the accuracy of the transaction processing of the Smith system as modified, one of ordinary skill in the art would have been motivated to determine weight value based on the merchant associated with the transaction, so that the transaction can be accurately validated based on transaction history.
Conclusion
The prior art, made of record and not relied upon, is considered pertinent to the applicant’s disclosure.
Egner et al. (US 10194320 B1) discloses that a resource provider accesses the transaction history associated with a client system and determines whether the transaction history meets a threshold trust requirement.
Jagadeesan et al. (US 20180181751 A1) discloses determining a reputation score associated with the transactions stored in the distributed ledger and determining whether the current reputation score is greater than a threshold reputation score.
Haldenby et al. (US 10762481 B2) discloses that a terminal device may determine to authorize the current data exchange in real-time based on cryptographically secure distributed ledger data, e.g., a block-chain ledger, maintained by a client device and provided to the terminal device across the direct communications channel.
Belyi et al. (US 20050080716 A1) discloses a risk system that performs a risk assessment of a financial transaction to obtain a risk score. The risk system may approve or authorize financial transactions that generally fail standard risk assessments that use a cut-off risk score to divide the financial transactions into either approved or declined groups.
Eyges et al. (US 9652772 B1) discloses determining whether the requested transaction should be approved or declined based on the fraud score and the transaction data. If the fraud score for the customer transaction is below the threshold, then the transaction will be approved.
Haldenby et al. (US 20180276666 A1) discloses that a terminal device may determine to authorize the current data exchange in real-time based on cryptographically secure distributed ledger data maintained by the client device and provided to the terminal device across the direct communications channel.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). An 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 CHUNLING DING, whose telephone number is (571)270-3605. The examiner can normally be reached 9:30 - 7:30 M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, an 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, Neha Patel, can be reached on 571-270-1492. 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.
/CHUNLING DING/Primary Examiner, Art Unit 3699