DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 02/17/2026.
Claims 1, 5, 7-8, 11, 13-18, and 20-25 are amended.
Claim 2, 3, 9, 12 and 19 cancelled.
Claims 1, 4-8, 10, 11, 13-18, and 20-27 are pending.
Claims 1, 4-8, 10, 11, 13-18, and 20-27 have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 02/17/2026 have been fully considered but they are not persuasive.
101
The claim does currently recite an additional element but the additional element does not integrate the judicial exception into a practical application.
According to the disclosure (¶ 79, 84, 159, 179, 202), “the trust score determination module 300 may generate scoring features for cryptocurrency addresses and generate one or more scoring models based on the scoring features and other data (e.g., labeled fraud data). In these implementations, the trust score determination module 300 may generate one or more local trust scores for blockchain addresses using one or more scoring models and the scoring features associated with the blockchain addresses… The consensus determination module 310 can generate a local trust score list 406 (“trust score list 406”) based on the local trust scores received from other nodes n block 1208, the scoring model generation module 1108 generates one or more scoring models based on the scoring features and other data (e.g., labeled fraud data).… The blockchain processing module 1102-2 can determine a variety of values based on the acquired blockchain data. The trust module 300 (e.g., the score generation module 1116) can use the determined values as scoring features for determining trust scores…For example, the trust module 300 may generate local trust scores using scoring functions (e.g., weighted scoring functions) and/or heuristic models that generate local trust scores according to rules.” From the disclosure, the scores appear to be an assessment of values and be numerically based, which could be abstract dependent on the mathematical concepts/calculations or even that they can be done by the human mind, which includes the generation of the trust scores. Therefore, the assessed additional element does not integrate the abstract idea into a practical application.
Additionally, the “consensus trust score” is described to be a summation of received scores.
Secondly, “triggering, by the at least one trust device of the set of trust devices, the smart contract to control execution of the blockchain transaction…” is not an additional element as first, the disclosure does not provide any information or context as to a trust device “triggering” a smart contract. According to the disclosure(¶ 87-90), “The consensus determination modules may be configured to determine a consensus trust score in response to one or more consensus triggers associated with the candidate trust scores. For example, the consensus determination modules may be configured to determine a consensus trust score if greater than a threshold number/fraction of candidate trust scores are in agreement (e.g., within a threshold variance).” The only trigger mentioned is in regards to determining trust scores, a mathematical calculation. Given that a smart contract acts as a program that is executed, running a program on a device is not an additional element. Therefore, the recited “trigger” of the smart contract is also not an additional element and does not integrate the judicial exception into a practical application.
Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The rejection is maintained.
103
Narang teaches generating, by the set of trust devices, a plurality of local trust scores for the blockchain address, wherein each of the local trust scores indicates a respective likelihood that the blockchain address is associated with fraudulent transactions, wherein at least two of the plurality of local trust scores have different values, wherein each of the local trust scores is generated by a separate trust device of the set of trust devices based on a corresponding subset of the blockchain ledger of the blockchain network that is accessible to the separate trust device (¶ 54, 56, 59, 77-87, 100, 140; claim 1);
Narang - Each node may compute and/or verify the metrics and generate an attribution score based on the metrics and input data at 340. The attribution score can be used to indicate a confidence level in the attribution claim (i.e., the confidence level in linking the rightsholder to the submitted work). Generally, a higher attribution score corresponds to a higher degree of confidence, however other scoring mechanisms can also be used (e.g., lower score indicates higher confidence). In some embodiments with a permissioned blockchain, the consensus mechanism may allow all authorized entities, external data sources and community members to validate the attribution claims. In some embodiments with a public blockchain, generally only the nodes of the blockchain can validate the attribution. (¶ 82)
receiving, by at least one trust device of the set of trust devices, the plurality of local trust scores(¶ 54, 56, 59, 77-82, 100, 140; claim 1);
Narang - the device receives the plurality of attribution responses from the plurality of nodes and computes a consensus attribution score based on the initial attribution score computed by the device and the re-computed attribution scores received from the plurality nodes… receiving a plurality of attribution responses from the plurality of nodes, each attribution response comprising a respective attribution score computed by the respective node based on the at least one metric (¶ 140; claim 1)
determining, by the at least one trust device of the set of trust devices, a consensus trust score based on the plurality of local trust scores, wherein the consensus trust score indicates a consensus value, the consensus value being based on a degree of consensus of the plurality of local trust scores (¶ 62, 68, 82, 83, 108, 109, 113, 140-143, 151; claim 1);
Claim Interpretation- “wherein the consensus trust score is based on both the local node trust score based on the at least one transaction included in the plurality of cryptocurrency transactions acquired at the particular node server and the at least one additional trust score generated by the another node server based on the different plurality of cryptocurrency transactions executed on the blockchain network that are accessible to the another node server and the consensus trust score indicates a consensus value for the local node trust score”. According to the disclosure(¶ 5, 36-39, 48, 51), “The trust network 100 may determine the consensus trust scores based on data retrieved from various data sources (e.g., fraud/custody data) along with blockchain data upon which the cryptocurrency is based. A trust score (e.g., a consensus trust score) may be a number (e.g., a decimal or integer) that indicates a likelihood that the blockchain address is involved in fraudulent activity… The one or more processing units are configured to determine a consensus trust score based on the local node trust score and the plurality of additional local trust scores. The consensus trust score indicates a consensus value for the local node trust score….” For the purpose of claim interpretation and the disclosure, the consensus score appears to be based on local trust scores.
Narang - each of the plurality of nodes re-computes the attribution score based on the at least one metric received in the attribution request, and transmits its recomputed attribution score back to the requesting device in an attribution response. In some embodiments, a subset of the nodes may perform the computation. In some embodiments, the re-computed attribution score may be transmitted to a subset of the nodes. In embodiments where the attribution request included an initial attribution score, the nodes may simply verify that the initial attribution score is computed correctly…. the device receives the plurality of attribution responses from the plurality of nodes and computes a consensus attribution score based on the initial attribution score computed by the device and the re-computed attribution scores received from the plurality nodes… computing a consensus attribution score based on the plurality of respective attribution scores in the plurality of attribution responses;… The attribution score can be used to indicate a confidence level in the attribution claim (i.e., the confidence level in linking the rightsholder to the submitted work). Generally, a higher attribution score corresponds to a higher degree of confidence, however other scoring mechanisms can also be used (e.g., lower score indicates higher confidence). (¶ 82, 139, 140; claim 1)
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 4-8, 10, 11, 13-18, and 20-27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Subject Matter Eligibility Standard
When considering subject matter eligibility under 35 U.S.C. § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter (101 Analysis: Step 1). Even if the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea) (101 Analysis: Step 2a(Prong 1), and if so, Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception. (101 Analysis: Step 2a (Prong 2). If additional elements does not integrate the exception into a practical application of the exception, claim still requires an evaluation of whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception. If the claim as a whole amounts to significantly more than the exception itself (there is an inventive concept in the claim), the claim is eligible. If the claim as a whole does not amount to significantly more (there is no inventive concept in the claim), the claim is ineligible. (101 Analysis: Step 2b).
The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter: a) Mathematical concepts b) Certain methods of organizing human activity and c) Mental processes
Analysis
In the instant case, claim 1 is directed to a method, and claims 11 and 21 are directed to an article of manufacture.
Step 2a.1– Identifying an Abstract Idea
The claims recite the steps of “monitoring, … a blockchain ledger … verifying, … receipt of a trust fee payment … generating … trust scores… receiving … trust scores… determining… trust score… distributing, …. the updated distributed consensus ledger … and …. triggering… smart contract… initiating…smart contract…” The claim recites an abstract idea that is directed towards certain methods of organizing human activity, in this case, mitigating risk by receiving transaction information, assessing the information for trustworthiness and updating the information in a ledger. Accordingly, the claims recites an abstract idea.
See MPEP 2106.
Step 2a.2 – Identifying a Practical Application
The claim does currently recite an additional element but the additional element does not integrate the judicial exception into a practical application.
First, the recitation of a distributed ledger or blockchain does not preclude the claim from reciting an abstract idea as the blockchain recites functions of a generic computer component, such as storing the transaction information.
According to the disclosure (¶ 79, 84, 159, 179, 202), “the trust score determination module 300 may generate scoring features for cryptocurrency addresses and generate one or more scoring models based on the scoring features and other data (e.g., labeled fraud data). In these implementations, the trust score determination module 300 may generate one or more local trust scores for blockchain addresses using one or more scoring models and the scoring features associated with the blockchain addresses… The consensus determination module 310 can generate a local trust score list 406 (“trust score list 406”) based on the local trust scores received from other nodes n block 1208, the scoring model generation module 1108 generates one or more scoring models based on the scoring features and other data (e.g., labeled fraud data).… The blockchain processing module 1102-2 can determine a variety of values based on the acquired blockchain data. The trust module 300 (e.g., the score generation module 1116) can use the determined values as scoring features for determining trust scores…For example, the trust module 300 may generate local trust scores using scoring functions (e.g., weighted scoring functions) and/or heuristic models that generate local trust scores according to rules.” From the disclosure, the score appear to be an assessment of values and be numerically based, which could be abstract dependent on the mathematical concepts/calculations or even that they can be done by the human mind. Therefore, the assessed additional element does not integrate the abstract idea into a practical application.
Additionally, the “consensus trust score” is described to be a summation of received scores.
Secondly, “triggering, by the at least one trust device of the set of trust devices, the smart contract to control execution of the blockchain transaction…” is not an additional element as first, the disclosure does not provide any information or context as to a trust device “triggering” a smart contract. According to the disclosure(¶ 87-90), “The consensus determination modules may be configured to determine a consensus trust score in response to one or more consensus triggers associated with the candidate trust scores. For example, the consensus determination modules may be configured to determine a consensus trust score if greater than a threshold number/fraction of candidate trust scores are in agreement (e.g., within a threshold variance).” The only trigger mentioned is in regards to determining trust scores.
Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Mere instructions to apply the exception using generic computer components and limitations to a particular field of use or technological environment do not amount to practical applications. The claim in directed to an abstract idea.
Step 2b
The claim limitations recite mostly generic steps that are not additional elements and they amount to no more than mere instructions to apply the exception using a generic computer component. For the same reason these elements are not sufficient to provide an inventive concept. This is also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs, court decision cited in MPEP 2106.05(d)(II) indicates that mere receipt or transmission of data over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here. Therefore, when considering the additional elements alone, and in combination, there is no inventive concept in the claim and thus the claim is not eligible.
Viewed as a whole, instructions/method claims recite the concept of mitigating risk as performed by a generic computer. The claims do not currently recite any additional elements or combination of additional elements that amount to significantly more than the judicial exception. The elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea in a network, and/or merely uses a network as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular environment.
Dependent claims 4-8, 13-18, and 22-27 provide descriptive language about the data stored in the ledger, they discuss the details of a smart contract ex. terms, fees etc., and the explanations of what the scores mean ex. thresholds.
Claims 10 and 20 discuss the receipt of the smart contract information.
The claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Therefore, based on case law precedent, the claims are claiming subject matter similar to concepts already identified by the courts as dealing with abstract ideas. See Alice Corp. Pty. Ltd., 573 U.S. 208 (citing Bilski v. Kappos, 561, U.S. 593, 611 (2010)).
The claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Conclusion
The claim as a whole, does not amount to significantly more than the abstract idea itself. This is because the claim does not affect an improvement to another technology or technical filed; the claim does not amount to an improvement to the functioning of a computer system itself; and the claim does not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, the Examiner concludes that there are no meaningful limitations in the claim that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
Dependent claims do not resolve the deficiency of independent claims and accordingly stand rejected under 35 USC 101 based on the same rationale.
Dependent claims 4-8, 10, 13-18, 20 and 22-27 are also rejected.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 4-8, 10, 11, 13-18, and 20-27 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 11 and 21 recite “monitoring, by a set of trust devices of a trust network, a blockchain ledger of a blockchain network for a trust request from a smart contract that controls a blockchain transaction involving a blockchain address…responsive to detecting the trust request, verifying, by the set of trust devices, receipt of a trust fee transaction from the smart contract that controls the blockchain transaction….”According to the disclosure(¶ 228-240), “ To acquire a trust score, the smart contract 1810 may generate a contract trust request for the receiver address. The contract trust request may be a request for a trust report for the receiver address (e.g., one or more trust scores for the receiver address)… the trust network/system 1802 may receive trust fee payments for providing trust reports…The trust network/system 1802 can monitor the instantiated contract address to verify trust fee payments and monitor the blockchain ledger 1808 for a contract trust request”. The disclosure allows for monitoring or scanning for trust requests. There is no disclosure support for “detecting” a trust request and “responsive to detecting the trust request, verifying, by the set of trust devices, receipt of a trust fee transaction from the smart contract that controls the blockchain transaction, wherein the trust fee transaction is to a designated blockchain address, wherein the trust fee transaction is associated with the trust request”. There is no written description support for the recited limitations. Dependent claims 4-8, 10, 13-18, 20 and 22-27 are also rejected.
Claims 1, and 21 recite “trigger the smart contract that controls execution of the blockchain transaction on the blockchain network based on the consensus trust score for the blockchain address specified in the trust request.” Claim 11 recites “initiate, using the smart contract that controls execution of the blockchain transaction on the blockchain network….” According to the disclosure(¶ 87-90), “The consensus determination modules may be configured to determine a consensus trust score in response to one or more consensus triggers associated with the candidate trust scores. For example, the consensus determination modules may be configured to determine a consensus trust score if greater than a threshold number/fraction of candidate trust scores are in agreement (e.g., within a threshold variance).” The disclosure makes mention of triggering “consensus determination modules” to determine a trust score, there is no support in the disclosure for triggering a smart contact “that controls execution of the blockchain transaction on the blockchain network based on the consensus trust score for the blockchain address specified in the trust request.” Additionally, the disclosure provides no support for a smart contract that “controls” the execution of a blockchain transaction. The limitation does not have disclosure support. Dependent claims 4-8, 10, 13-18, 20 and 22-27 are also rejected.
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, 4-8, 11, 14-18, 21, 26 and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Narang et al. (US 2020/0012676) (“Narang”) and further in view of Ramakrishnan et al. (US 20190205886) (“Ramakrishnan”).
Regarding claim 1, Narang discloses monitoring, by a set of trust devices of a trust network, a blockchain ledger of a blockchain network for a trust request from a smart contract that controls a blockchain transaction involving a blockchain address (¶ 53, 73-82, 100, 140-147; claim 1);
Claim Interpretation- According to the disclosure(¶ 228-240), “ To acquire a trust score, the smart contract 1810 may generate a contract trust request for the receiver address. The contract trust request may be a request for a trust report for the receiver address (e.g., one or more trust scores for the receiver address)… the trust network/system 1802 may receive trust fee payments for providing trust reports…The trust network/system 1802 can monitor the instantiated contract address to verify trust fee payments and monitor the blockchain ledger 1808 for a contract trust request”. For the purpose of claim interpretation, the trust scores are sent when requested and the fee is paid for a trust report, there is no “detection” of a trust request.
Narang - Workflow 300 begins with a submitter of a digital media work submitting the digital media work to an attestation server at 310… In a first stage of the review process, the attestation server may trigger an automated process (e.g., smart contract) in the master attribution ledger for each similar work. (¶ 73, 76)
generating, by the set of trust devices, a plurality of local trust scores for the blockchain address, wherein each of the local trust scores indicates a respective likelihood that the blockchain address is associated with fraudulent transactions, wherein at least two of the plurality of local trust scores have different values, wherein each of the local trust scores is generated by a separate trust device of the set of trust devices based on a corresponding subset of the blockchain ledger of the blockchain network that is accessible to the separate trust device (¶ 54, 56, 59, 77-87, 100, 140; claim 1);
Narang - Each node may compute and/or verify the metrics and generate an attribution score based on the metrics and input data at 340. The attribution score can be used to indicate a confidence level in the attribution claim (i.e., the confidence level in linking the rightsholder to the submitted work). Generally, a higher attribution score corresponds to a higher degree of confidence, however other scoring mechanisms can also be used (e.g., lower score indicates higher confidence). In some embodiments with a permissioned blockchain, the consensus mechanism may allow all authorized entities, external data sources and community members to validate the attribution claims. In some embodiments with a public blockchain, generally only the nodes of the blockchain can validate the attribution. (¶ 82)
receiving, by at least one trust device of the set of trust devices, the plurality of local trust scores(¶ 54, 56, 59, 77-82, 100, 140; claim 1);
Narang - the device receives the plurality of attribution responses from the plurality of nodes and computes a consensus attribution score based on the initial attribution score computed by the device and the re-computed attribution scores received from the plurality nodes… receiving a plurality of attribution responses from the plurality of nodes, each attribution response comprising a respective attribution score computed by the respective node based on the at least one metric (¶ 140; claim 1)
determining, by the at least one trust device of the set of trust devices, a consensus trust score based on the plurality of local trust scores, wherein the consensus trust score indicates a consensus value, the consensus value being based on a degree of consensus of the plurality of local trust scores (¶ 62, 68, 82, 83, 108, 109, 113, 140-143, 151; claim 1);
Claim Interpretation- “wherein the consensus trust score is based on both the local node trust score based on the at least one transaction included in the plurality of cryptocurrency transactions acquired at the particular node server and the at least one additional trust score generated by the another node server based on the different plurality of cryptocurrency transactions executed on the blockchain network that are accessible to the another node server and the consensus trust score indicates a consensus value for the local node trust score”. According to the disclosure(¶ 5, 36-39, 48, 51), “The trust network 100 may determine the consensus trust scores based on data retrieved from various data sources (e.g., fraud/custody data) along with blockchain data upon which the cryptocurrency is based. A trust score (e.g., a consensus trust score) may be a number (e.g., a decimal or integer) that indicates a likelihood that the blockchain address is involved in fraudulent activity… The one or more processing units are configured to determine a consensus trust score based on the local node trust score and the plurality of additional local trust scores. The consensus trust score indicates a consensus value for the local node trust score….” For the purpose of claim interpretation and the disclosure, the consensus score appears to be based on local trust scores.
Narang - each of the plurality of nodes re-computes the attribution score based on the at least one metric received in the attribution request, and transmits its recomputed attribution score back to the requesting device in an attribution response. In some embodiments, a subset of the nodes may perform the computation. In some embodiments, the re-computed attribution score may be transmitted to a subset of the nodes. In embodiments where the attribution request included an initial attribution score, the nodes may simply verify that the initial attribution score is computed correctly…. the device receives the plurality of attribution responses from the plurality of nodes and computes a consensus attribution score based on the initial attribution score computed by the device and the re-computed attribution scores received from the plurality nodes… computing a consensus attribution score based on the plurality of respective attribution scores in the plurality of attribution responses;… The attribution score can be used to indicate a confidence level in the attribution claim (i.e., the confidence level in linking the rightsholder to the submitted work). Generally, a higher attribution score corresponds to a higher degree of confidence, however other scoring mechanisms can also be used (e.g., lower score indicates higher confidence). (¶ 82, 139, 140; claim 1)
distributing, by the at least one trust device of the set of trust devices, an updated distributed consensus ledger including the consensus trust score among the trust network; and (¶ 68, 80, 81, 83, 92, 142);
Narang - Based on the outcome of the exception handling process, a new attribution score can be computed and registered in the master attribution ledger and/or communicated to the system participants… the device may attribute the media data item to one or more rightsholders in an attribution database at 940, and may transmit a notification of the attribution to the plurality of nodes to do likewise. The attribution database may be the local copy of the attribution ledger kept by each device or node. (¶ 68, 142)
triggering, by the at least one trust device of the set of trust devices, the smart contract to control execution of the blockchain transaction associated with the trust request on the blockchain network, wherein the smart contract determines whether to allow the execution of the blockchain transaction based on the consensus trust score (¶ 68, 72-92);
Narang - Based on the outcome of the exception handling process, a new attribution score can be computed and registered in the master attribution ledger and/or communicated to the system participants… An exceptions smart contract may be configured to manage the exception handling process associated with a work, or a claim to a work. For example, if a person, “Jane Doe,” submits a claim to a given book and the attribution score fails to meet the predefined threshold, the exceptions smart contract may be triggered to execute based on the exception handling process described elsewhere herein. (¶ 68, 90)
Narang does not disclose responsive to detecting the trust request, verifying, by the set of trust devices, receipt of a trust fee transaction from the smart contract that controls the blockchain transaction, wherein the trust fee transaction is to a designated blockchain address, wherein the trust fee transaction is associated with the trust request.
Ramakrishnan teaches responsive to detecting the trust request, verifying, by the set of trust devices, receipt of a trust fee transaction from the smart contract that controls the blockchain transaction, wherein the trust fee transaction is to a designated blockchain address, wherein the trust fee transaction is associated with the trust request (¶ 45-49);
Ramakrishnan - In such embodiments, a risk determination fee system may be implemented where system provider devices 412 are incentivized to perform risk determinations…. If the payers and/or payees in those crypto currency transactions satisfy the risk criteria, those crypto currency transactions may be rebroadcast to second system provider devices who will add those crypto currency transactions to the transaction memory pool, and group those crypto currency transactions in an attempt to add them to a block in the crypto currency public ledger, and also receive a fee for doing so… As such, system provider devices may perform risk determinations for crypto currency transaction (for a fee in some embodiments) and, if the payer and/or payee in those crypto currency transactions satisfy risk criteria, then attempt to create a block for addition to the crypto currency public ledger. (¶ 48, 49)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Narang (¶ 5), which teaches “computing at least one metric based on the media data item; transmitting an attribution request comprising the at least one metric to a plurality of nodes of the media management system” and Ramakrishnan (¶ 4), which teaches “ distributed network of computing devices that operate to confirm transfers of the crypto currency between payers and payees ” in order to provide assurance in a cryptocurrency transaction by utilizing risk determination (Ramakrishnan; ¶ 4).
Regarding claims 4 and 14, Narang discloses further comprising configuring, by the set of trust devices, the smart contract, wherein the smart contract is configured to perform steps including: comparing the consensus trust score to a contract trust threshold (¶ 71, 86, 90; claim 9); determining whether the blockchain address is sufficiently trustworthy based on the comparing (¶ 82, 90); and sending a transaction to a sender address when the blockchain address is not sufficiently trustworthy (¶ 86, 141-145). Ramakrishnan teaches amount of cryptocurrency (¶ 41-47, 60-67)
Regarding claims 5 and 15, Narang discloses wherein the smart contract executing on the blockchain network is further configured to: determine that the blockchain address is sufficiently trustworthy when the consensus trust score is greater than the contract trust threshold; and determine that the blockchain address is not sufficiently trustworthy when the consensus trust score is not greater than the contract trust threshold (¶ 71, 82, 83, 93, 141-145).
Regarding claims 6 and 16, Narang discloses wherein the smart contract is configured to receive the contract trust threshold while executing on the blockchain network (¶ 76, 82, 90; claim 9).
Regarding claims 7 and 17, Narang discloses wherein the smart contract specify for the consensus trust score (¶ 82, 83, 85, 86, 90). Ramakrishnan teaches a trust fee amount (¶ 45-49).
Regarding claims 8 and 18, Narang discloses wherein the smart contract is configured to on the blockchain network (¶ 76, 83, 84, 86, 90, 91; claim 15, 16). Ramakrishnan teaches wherein the smart contract is further configured to pay the trust fee amount for the consensus trust score by sending funds to the designated blockchain address (¶ 45-49).
Regarding claim 11, Narang discloses one or more memory components configured to store blockchain data for a blockchain address on a blockchain network that is independent of the trust network, the blockchain data including a plurality of cryptocurrency transactions involving the blockchain address; and one or more processing units configured to execute computer-readable instructions that cause the one or more processing units to: (¶ 73-82, 110-120, 127-131);
Narang - Processor 705 is coupled, via a computer data bus (not shown), to volatile memory 720 and non-volatile memory 725 (¶ 119)
monitor a blockchain ledger on the blockchain network for a trust request from a smart contract that controls execution of a blockchain transaction involving the blockchain address on the blockchain network, the trust request specifying the blockchain address (¶ 53, 73-82, 100, 140-147; claim 1);
Claim Interpretation- According to the disclosure(¶ 228-240), “ To acquire a trust score, the smart contract 1810 may generate a contract trust request for the receiver address. The contract trust request may be a request for a trust report for the receiver address (e.g., one or more trust scores for the receiver address)… the trust network/system 1802 may receive trust fee payments for providing trust reports…The trust network/system 1802 can monitor the instantiated contract address to verify trust fee payments and monitor the blockchain ledger 1808 for a contract trust request”. For the purpose of claim interpretation, the trust scores are sent when requested and the fee is paid for a trust report, there is no “detection” of a trust request.
Narang - Workflow 300 begins with a submitter of a digital media work submitting the digital media work to an attestation server at 310… In a first stage of the review process, the attestation server may trigger an automated process (e.g., smart contract) in the master attribution ledger for each similar work. (¶ 73, 76)
receive, from other devices within the trust network, a plurality of local trust scores for the blockchain address, wherein each of the plurality of local trust scores indicates a respective likelihood that the blockchain address is associated with fraudulent transactions, wherein at least two of the plurality of local trust scores have different values, wherein each of the local trust scores is generated by a separate trust device of the set of trust devices based on a corresponding subset of the blockchain ledger of the blockchain network that is accessible to the separate trust device (¶ 54, 56, 59, 77-87, 100, 130-140; claim 1);
Narang - Each node may compute and/or verify the metrics and generate an attribution score based on the metrics and input data at 340. The attribution score can be used to indicate a confidence level in the attribution claim (i.e., the confidence level in linking the rightsholder to the submitted work). Generally, a higher attribution score corresponds to a higher degree of confidence, however other scoring mechanisms can also be used (e.g., lower score indicates higher confidence). In some embodiments with a permissioned blockchain, the consensus mechanism may allow all authorized entities, external data sources and community members to validate the attribution claims. In some embodiments with a public blockchain, generally only the nodes of the blockchain can validate the attribution the device receives the plurality of attribution responses from the plurality of nodes and computes a consensus attribution score based on the initial attribution score computed by the device and the re-computed attribution scores received from the plurality nodes… receiving a plurality of attribution responses from the plurality of nodes, each attribution response comprising a respective attribution score computed by the respective node based on the at least one metric (¶ 82, 140; claim 1)
determine a consensus trust score based on the plurality of local trust scores, wherein the consensus trust score indicates a consensus value, the consensus value being based on a degree of consensus of the plurality of local trust scores (¶ 62, 68, 82, 83, 108, 109, 113, 130-143, 151; claim 1);
Claim Interpretation- “wherein the consensus trust score is based on both the local node trust score based on the at least one transaction included in the plurality of cryptocurrency transactions acquired at the particular node server and the at least one additional trust score generated by the another node server based on the different plurality of cryptocurrency transactions executed on the blockchain network that are accessible to the another node server and the consensus trust score indicates a consensus value for the local node trust score”. According to the disclosure(¶ 5, 36-39, 48, 51), “The trust network 100 may determine the consensus trust scores based on data retrieved from various data sources (e.g., fraud/custody data) along with blockchain data upon which the cryptocurrency is based. A trust score (e.g., a consensus trust score) may be a number (e.g., a decimal or integer) that indicates a likelihood that the blockchain address is involved in fraudulent activity… The one or more processing units are configured to determine a consensus trust score based on the local node trust score and the plurality of additional local trust scores. The consensus trust score indicates a consensus value for the local node trust score….” For the purpose of claim interpretation and the disclosure, the consensus score appears to be based on local trust scores.
Narang - each of the plurality of nodes re-computes the attribution score based on the at least one metric received in the attribution request, and transmits its recomputed attribution score back to the requesting device in an attribution response. In some embodiments, a subset of the nodes may perform the computation. In some embodiments, the re-computed attribution score may be transmitted to a subset of the nodes. In embodiments where the attribution request included an initial attribution score, the nodes may simply verify that the initial attribution score is computed correctly…. the device receives the plurality of attribution responses from the plurality of nodes and computes a consensus attribution score based on the initial attribution score computed by the device and the re-computed attribution scores received from the plurality nodes… computing a consensus attribution score based on the plurality of respective attribution scores in the plurality of attribution responses;… The attribution score can be used to indicate a confidence level in the attribution claim (i.e., the confidence level in linking the rightsholder to the submitted work). Generally, a higher attribution score corresponds to a higher degree of confidence, however other scoring mechanisms can also be used (e.g., lower score indicates higher confidence). (¶ 82, 139, 140; claim 1)
update a distributed consensus ledger with the consensus trust score, wherein the distributed consensus ledger is a distributed ledger (¶ 68, 80, 81, 83, 92, 142);
Narang - Based on the outcome of the exception handling process, a new attribution score can be computed and registered in the master attribution ledger and/or communicated to the system participants… (¶ 68)
distribute the updated distributed consensus ledger to the other devices within the trust network and (¶ 68, 80, 81, 83, 92, 142);
Narang - Based on the outcome of the exception handling process, a new attribution score can be computed and registered in the master attribution ledger and/or communicated to the system participants… the device may attribute the media data item to one or more rightsholders in an attribution database at 940, and may transmit a notification of the attribution to the plurality of nodes to do likewise. The attribution database may be the local copy of the attribution ledger kept by each device or node. (¶ 68, 142)
initiate, using the smart contract that controls execution of the blockchain transaction on the blockchain network, a smart contract function that determines whether to allow the execution of the blockchain transaction on the blockchain network based on the consensus trust score for the blockchain address specified in the trust request (¶ 68, 72-92);
Narang - Based on the outcome of the exception handling process, a new attribution score can be computed and registered in the master attribution ledger and/or communicated to the system participants… An exceptions smart contract may be configured to manage the exception handling process associated with a work, or a claim to a work. For example, if a person, “Jane Doe,” submits a claim to a given book and the attribution score fails to meet the predefined threshold, the exceptions smart contract may be triggered to execute based on the exception handling process described elsewhere herein. (¶ 68, 90)
Narang does not disclose responsive to detecting the trust request, verifying receipt of a trust fee transaction at a designated blockchain address on the blockchain network, wherein the trust fee transaction is associated with the trust request.
Ramakrishnan teaches responsive to detecting the trust request, verifying receipt of a trust fee transaction at a designated blockchain address on the blockchain network, wherein the trust fee transaction is associated with the trust request (¶ 45-49);
Ramakrishnan - In such embodiments, a risk determination fee system may be implemented where system provider devices 412 are incentivized to perform risk determinations…. If the payers and/or payees in those crypto currency transactions satisfy the risk criteria, those crypto currency transactions may be rebroadcast to second system provider devices who will add those crypto currency transactions to the transaction memory pool, and group those crypto currency transactions in an attempt to add them to a block in the crypto currency public ledger, and also receive a fee for doing so… As such, system provider devices may perform risk determinations for crypto currency transaction (for a fee in some embodiments) and, if the payer and/or payee in those crypto currency transactions satisfy risk criteria, then attempt to create a block for addition to the crypto currency public ledger. (¶ 48, 49)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Narang (¶ 5), which teaches “computing at least one metric based on the media data item; transmitting an attribution request comprising the at least one metric to a plurality of nodes of the media management system” and Ramakrishnan (¶ 4), which teaches “ distributed network of computing devices that operate to confirm transfers of the crypto currency between payers and payees ” in order to provide assurance in a cryptocurrency transaction by utilizing risk determination (Ramakrishnan; ¶ 4).
Regarding claim 21, Narang discloses one or more memory components configured to store blockchain data for a blockchain address on a blockchain network that is independent of the trust network, the blockchain data including a plurality of cryptocurrency transactions involving the blockchain address; and one or more processing units configured to execute computer-readable instructions that cause the one or more processing units to: (¶ 73-82, 110-120, 127-131);
Narang - Processor 705 is coupled, via a computer data bus (not shown), to volatile memory 720 and non-volatile memory 725 (¶ 119)
monitor a blockchain ledger on the blockchain network for a trust request from a smart contract that controls execution of a blockchain transaction involving the blockchain address on the blockchain network, the trust request specifying the blockchain address (¶ 53, 73-82, 100, 140-147; claim 1);
Claim Interpretation- According to the disclosure(¶ 228-240), “ To acquire a trust score, the smart contract 1810 may generate a contract trust request for the receiver address. The contract trust request may be a request for a trust report for the receiver address (e.g., one or more trust scores for the receiver address)… the trust network/system 1802 may receive trust fee payments for providing trust reports…The trust network/system 1802 can monitor the instantiated contract address to verify trust fee payments and monitor the blockchain ledger 1808 for a contract trust request”. For the purpose of claim interpretation, the trust scores are sent when requested and the fee is paid for a trust report, there is no “detection” of a trust request.
Narang - Workflow 300 begins with a submitter of a digital media work submitting the digital media work to an attestation server at 310… In a first stage of the review process, the attestation server may trigger an automated process (e.g., smart contract) in the master attribution ledger for each similar work. (¶ 73, 76)
receive, from the set of trust devices, a plurality of local trust scores for the blockchain address, wherein each of the plurality of local trust scores indicates a respective likelihood that the blockchain address is associated with fraudulent transactions, wherein each of the plurality of local trust scores is generated by a separate trust device of the set of trust devices based on a subset of the blockchain ledger of the blockchain network, wherein at least two of the plurality of local trust scores have different values (¶ 54, 56, 59, 77-87, 100, 130-140; claim 1);
Narang - Each node may compute and/or verify the metrics and generate an attribution score based on the metrics and input data at 340. The attribution score can be used to indicate a confidence level in the attribution claim (i.e., the confidence level in linking the rightsholder to the submitted work). Generally, a higher attribution score corresponds to a higher degree of confidence, however other scoring mechanisms can also be used (e.g., lower score indicates higher confidence). In some embodiments with a permissioned blockchain, the consensus mechanism may allow all authorized entities, external data sources and community members to validate the attribution claims. In some embodiments with a public blockchain, generally only the nodes of the blockchain can validate the attribution the device receives the plurality of attribution responses from the plurality of nodes and computes a consensus attribution score based on the initial attribution score computed by the device and the re-computed attribution scores received from the plurality nodes… receiving a plurality of attribution responses from the plurality of nodes, each attribution response comprising a respective attribution score computed by the respective node based on the at least one metric (¶ 82, 140; claim 1)
determine a consensus trust score based on the plurality of local trust scores, wherein the consensus trust score is based on the plurality of local trust scores including the at least two of the plurality of local trust scores that have the different values (¶ 62, 68, 82, 83, 108, 109, 113, 130-143, 151; claim 1);
Claim Interpretation- “wherein the consensus trust score is based on both the local node trust score based on the at least one transaction included in the plurality of cryptocurrency transactions acquired at the particular node server and the at least one additional trust score generated by the another node server based on the different plurality of cryptocurrency transactions executed on the blockchain network that are accessible to the another node server and the consensus trust score indicates a consensus value for the local node trust score”. According to the disclosure(¶ 5, 36-39, 48, 51), “The trust network 100 may determine the consensus trust scores based on data retrieved from various data sources (e.g., fraud/custody data) along with blockchain data upon which the cryptocurrency is based. A trust score (e.g., a consensus trust score) may be a number (e.g., a decimal or integer) that indicates a likelihood that the blockchain address is involved in fraudulent activity… The one or more processing units are configured to determine a consensus trust score based on the local node trust score and the plurality of additional local trust scores. The consensus trust score indicates a consensus value for the local node trust score….” For the purpose of claim interpretation and the disclosure, the consensus score appears to be based on local trust scores.
Narang - each of the plurality of nodes re-computes the attribution score based on the at least one metric received in the attribution request, and transmits its recomputed attribution score back to the requesting device in an attribution response. In some embodiments, a subset of the nodes may perform the computation. In some embodiments, the re-computed attribution score may be transmitted to a subset of the nodes. In embodiments where the attribution request included an initial attribution score, the nodes may simply verify that the initial attribution score is computed correctly…. the device receives the plurality of attribution responses from the plurality of nodes and computes a consensus attribution score based on the initial attribution score computed by the device and the re-computed attribution scores received from the plurality nodes… computing a consensus attribution score based on the plurality of respective attribution scores in the plurality of attribution responses;… The attribution score can be used to indicate a confidence level in the attribution claim (i.e., the confidence level in linking the rightsholder to the submitted work). Generally, a higher attribution score corresponds to a higher degree of confidence, however other scoring mechanisms can also be used (e.g., lower score indicates higher confidence). (¶ 82, 139, 140; claim 1)
update a distributed consensus ledger with the consensus trust score, wherein the distributed consensus ledger is a distributed ledger (¶ 68, 80, 81, 83, 92, 142);
Narang - Based on the outcome of the exception handling process, a new attribution score can be computed and registered in the master attribution ledger and/or communicated to the system participants… (¶ 68)
distribute the updated distributed consensus ledger to the trust network; and and (¶ 68, 80, 81, 83, 92, 142);
Narang - Based on the outcome of the exception handling process, a new attribution score can be computed and registered in the master attribution ledger and/or communicated to the system participants… the device may attribute the media data item to one or more rightsholders in an attribution database at 940, and may transmit a notification of the attribution to the plurality of nodes to do likewise. The attribution database may be the local copy of the attribution ledger kept by each device or node. (¶ 68, 142)
trigger the smart contract that controls execution of the blockchain transaction on the blockchain network based on the consensus trust score for the blockchain address specified in the trust request (¶ 68, 72-92);
Narang - Based on the outcome of the exception handling process, a new attribution score can be computed and registered in the master attribution ledger and/or communicated to the system participants… An exceptions smart contract may be configured to manage the exception handling process associated with a work, or a claim to a work. For example, if a person, “Jane Doe,” submits a claim to a given book and the attribution score fails to meet the predefined threshold, the exceptions smart contract may be triggered to execute based on the exception handling process described elsewhere herein. (¶ 68, 90)
Narang does not disclose responsive to detecting the trust request, verifying receipt of a trust fee payment at a designated blockchain address on the blockchain network, wherein the trust fee payment is associated with the trust request.
Ramakrishnan teaches responsive to detecting the trust request, verifying receipt of a trust fee payment at a designated blockchain address on the blockchain network, wherein the trust fee payment is associated with the trust request (¶ 45-49);
Ramakrishnan - In such embodiments, a risk determination fee system may be implemented where system provider devices 412 are incentivized to perform risk determinations…. If the payers and/or payees in those crypto currency transactions satisfy the risk criteria, those crypto currency transactions may be rebroadcast to second system provider devices who will add those crypto currency transactions to the transaction memory pool, and group those crypto currency transactions in an attempt to add them to a block in the crypto currency public ledger, and also receive a fee for doing so… As such, system provider devices may perform risk determinations for crypto currency transaction (for a fee in some embodiments) and, if the payer and/or payee in those crypto currency transactions satisfy risk criteria, then attempt to create a block for addition to the crypto currency public ledger. (¶ 48, 49)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Narang (¶ 5), which teaches “computing at least one metric based on the media data item; transmitting an attribution request comprising the at least one metric to a plurality of nodes of the media management system” and Ramakrishnan (¶ 4), which teaches “ distributed network of computing devices that operate to confirm transfers of the crypto currency between payers and payees ” in order to provide assurance in a cryptocurrency transaction by utilizing risk determination (Ramakrishnan; ¶ 4).
Regarding claim 26, Narang discloses wherein the set of trust devices is a single trust device (¶ 108).
Regarding claim 27, Narang discloses wherein the set of trust devices comprises a plurality of trust devices (¶ 108).
Claims 10, 13, 20 and 22-25 are rejected under 35 U.S.C. 103 as being unpatentable over Narang et al. (US 2020/0012676) (“Narang”), in view of Ramakrishnan et al. (US 20190205886) (“Ramakrishnan”) and further in view of Tang et al. (CA2933407) (“Tang”).
Regarding claims 10, and 20, Neither Narang nor Ramakrishnan teach wherein the one or more processing units are configured to receive an address of the smart contract executing on the blockchain network, and wherein monitoring the blockchain ledger comprises scanning for activity on the blockchain ledger associated with the address of the smart contract that controls execution of the blockchain transaction. Tang teaches wherein the one or more processing units are configured to receive an address of the smart contract executing on the blockchain network, and wherein monitoring the blockchain ledger comprises scanning for activity on the blockchain ledger associated with the address of the smart contract that controls execution of the blockchain transaction (Page 6, 8, 11, 17). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Narang, Ramakrishnan and Tang (Page 6), which teaches “a user wishing to obtain a score for a Bitcoin account inputs information containing a unique identifier of the account, typically a Bitcoin address or a hash of the address (310)” in order to provide a means for creating trust in transactions in correlation with blockchain networks (Tang; Page 1-4).
Regarding claim 13, Tang discloses wherein the smart contract is configured to receive the consensus trust score for the blockchain address when the smart contract is executing on the blockchain network (Page 6, 7, 9, 10, 13, 18).
Regarding claims 22 and 24, Tang teaches wherein, the at least two of the plurality of local trust scores that have the different values are associated with different jurisdictions (Page 16-18).
Claim Interpretation- According to the disclosure(¶ 81), “For example, the local trust scores may differ when nodes have access to different fraud and custody data. In a specific example, nodes located in different jurisdictions (e.g., countries) may have access to data sources that are blocked in other jurisdictions. In another specific example, some nodes may access information at different rates.” The limitation recites information that some nodes have information based on their location that other node might not have. The claim recites non-functional descriptive material and is therefore given no patentable weight.
Regarding claims 23 and 25, Tang teaches wherein, the at least two of the plurality of local trust scores that have the different values are associated with different information collection rates (Page 7-9, 11, 12).
Claim Interpretation- According to the disclosure(¶ 81), “For example, the local trust scores may differ when nodes have access to different fraud and custody data. In a specific example, nodes located in different jurisdictions (e.g., countries) may have access to data sources that are blocked in other jurisdictions. In another specific example, some nodes may access information at different rates.” The claim recites non-functional descriptive material and is therefore given no patentable weight.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Family Applications, ex. 16/429,562, 16/295,153 etc. (double patenting)
Santos(US 20210036868) – teaches the trust scores, nodes generating trust score, and generating consensus trust scores.
Ronca (20150363783)
Rampton (20170270527)
EP 3633964 – generate a reputation score and the blockchain is updated with the score.
Caldera (2018/089789) (“Caldera”)- teaches smart contracts and trust scores.
Park et al. (2018/0027001) (“Park”) – A trust fee
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 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, NEHA H 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.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699
Prosecution Insights