Blockchain-based systems and methods for communicating, storing, and processing data via a blockchain network
The blockchain-based method secures and incentivizes timely content submission by linking transactions to product/service acquisition, preventing unauthorized submissions and ensuring authentic data transmission in review systems.
Patent Information
- Application Number
- JP2025171499
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2017-09-18
- Filing Date
- 2025-10-10
- Publication Date
- 2026-01-14
AI Technical Summary
Existing communication systems lack secure and efficient methods for transmitting data over blockchain networks, particularly in scenarios where only authorized nodes should be able to communicate and store data, such as customer reviews and feedback, to prevent manipulation and ensure authenticity.
A blockchain-based method and system that utilizes transaction scripts to ensure only authorized users can submit content, such as reviews, by linking transactions to product/service acquisition and requiring predefined actions before content submission, including time constraints and incentives for timely posting.
Ensures secure and efficient transmission of data, preventing unauthorized submissions and manipulation, while incentivizing timely and authentic content posting, thereby enhancing the reliability and transparency of review and feedback systems.
Smart Images

Figure 2026004584000001_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates generally to secure communication systems, and more particularly to systems and methods for communicating data / content to nodes of a network using a blockchain ledger in a secure manner that allows only authorized nodes to communicate requested data / content, which may be provided and stored in digital form and may include various types of data or information in various forms. [Background technology]
[0002] The term "blockchain" is used herein to encompass all forms of electronic, computer-based, and distributed ledgers, including, but not limited to, blockchain technology and transaction chain technology, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. While reference may be made to Bitcoin for convenience and purposes of explanation herein, it should be noted that the present invention is not limited to use in connection with the Bitcoin blockchain, and multiple alternative blockchain implementations and protocols are within the scope of the present invention.
[0003] A blockchain is a consensus-based electronic ledger implemented as a computer-based decentralized distributed system composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets among multiple participants in the blockchain system and includes at least one input and at least one output. Each block includes a hash of the previous block, thereby chaining the blocks together to form a permanent, immutable record of all transactions written to the blockchain since inception. Transactions contain small programs known as scripts embedded in the transaction inputs and outputs, which specify how and who can access the transaction outputs. In the Bitcoin platform, these scripts are written using a stack-based scripting language.
[0004] For a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform tasks to ensure that each transaction is valid and that invalid transactions are rejected by the network. Software clients installed on these nodes perform this validation on unspent transactions (UTXOs) by running locking and unlocking scripts. If the locking and unlocking scripts evaluate to TRUE, the transaction is valid and is written to the blockchain. Thus, for a transaction to be written to the blockchain, it (i) must be validated by the first node that receives it; if so, that first node relays the transaction to other nodes in the network; (ii) it must be added to a new block constructed by miners; and (iii) it must be mined, i.e., added to the public ledger of past transactions. Once recorded, the data in any block cannot be retroactively changed without changing all subsequent blocks and without the collusion of a majority of the network.
[0005] A transaction involves the transfer of one or more tokens from one node to another. The tokens may represent future control of network resources. In some cases, the tokens may represent an asset or price, but this is not necessarily the case. For example, in some cases, the tokens may be understood as cryptocurrencies. However, the present application is not limited to implementations related to cryptocurrencies, but may be understood more broadly as relating to blockchain networks for the decentralized transfer of control tokens.
[0006] Blockchains function as public ledgers that can record transactions between multiple parties in a verifiable and permanent manner. Blockchains have many properties, such as the irrevocability of information stored in a chain and trust relationships established by decentralized consensus, that make them suitable for use in a variety of different types of applications. For example, blockchains can find practical use as a platform for recording and publishing digital content.
[0007] In one non-limiting example, this may be customer feedback, such as user reviews of products, services, and / or their providers. Customer feedback, for example, in the form of reviews or numerical rankings, influences customer trust in products and services while also informing the quality assurance efforts of manufacturers, retailers, and service providers. Businesses, by their nature, are economically incentivized to strive for positive customer feedback, which creates the potential for various parties to engage in review manipulation. Blockchain can provide a suitable environment for discouraging review / feedback manipulation (such as review freezing and deletion) by enabling reviews / feedback to be publicly and permanently recorded in a public, distributed ledger without relying on a central authority to verify the reviews / feedback.
[0008] While the potential for deploying a content aggregation platform using blockchain is attractive, numerous challenges remain to be addressed, such as preventing content mass submission, encouraging content providers to contribute, and protecting user privacy. Modern platforms for aggregating content, such as customer reviews of products and services, are typically implemented using input interfaces (e.g., graphical user interfaces) with which users (content providers) can interact to submit their content. These input interfaces can be found, for example, on merchant websites or mobile applications, or on shared platforms that aggregate content submissions for multiple different aggregators, such as merchants. Examples include customer report websites, eBay, and the like. The input interface for submitting content can be as simple as GUI elements corresponding to a numerical or descriptive ranking (e.g., a "Like" button or a set of buttons representing a five-star ranking scale), or the input interface can be presented to the content provider in the form of a text box for receiving input text. Once posted, items of content are processed by associated computer systems for a platform, such as servers owned by a merchant or servers used to operate an online marketplace (e.g., Amazon). In the case of reviews, submitted reviews will often be processed "behind-the-scenes" by intermediaries at the reviewed party or review aggregation platform before being published for public access. For example, there may be a delay between the posting of a particular comment and the publication of that comment.This "black box" model of processing, in which review content is merely posted as input to a network of computers controlled by parties with a personal interest in that content, can ostensibly be difficult to solve. In particular, such a model may potentially present an opportunity for someone to tamper with content or selectively publish certain items, such as positive reviews, thereby establishing a distorted and inaccurate perception of that person and / or their product / service.
[0009] In a review posting scenario, as more reviews are collected for a particular product / service, a greater diversity of opinions can be represented, reducing the impact of biased or idiosyncratic impressions on the overall product / service quality and user experience. The benefits of collecting more reviews for a product / service can be enhanced by ensuring that only those who have actually purchased and / or used the product / service can submit messages / data. Accepting only reviews submitted by past purchasers and users can add greater authenticity to the review content and create a useful connection between the service provider and actual customers. Meanwhile, verifying the validity of reviews (i.e., ensuring that reviews are from authorized sources) can involve a cumbersome process that can prevent users from submitting reviews altogether.
[0010] The problems that exist in review and feedback posting systems are not limited to such systems. Indeed, similar problems exist in various types of systems. The above problems may apply to messaging systems in general, and therefore it is desirable to provide an improved messaging or communication transmission system that limits or restricts the ability of unauthorized senders to participate. Such an improved messaging system could be used, for example, in a content aggregation system or other system that relies on messaging. Such a messaging system could, for example, limit the parties that are allowed to submit messages and prevent or prohibit unwanted or unauthorized messages, such as spam.
[0011] It would therefore be desirable to provide methods and systems that provide improved messaging techniques, such as those that can be used to collect and / or transmit digital content and / or data in a transparent and reliable manner.
[0012] Such an improved solution has now been devised. Summary of the Invention
[0013] According to the present invention there are provided methods and devices as defined in the accompanying claims.
[0014] The present invention may provide a computer-implemented method and corresponding system. The method / system may be described as a blockchain-implemented method / system. The present invention may be described as a security method or encryption method / system. The present invention may provide for the secure transfer or transmission of digital assets, such as cryptocurrency fractions or amounts. Additionally or alternatively, the present invention may provide a control mechanism for controlling the transfer of digital assets, such as cryptocurrency fractions or amounts.
[0015] Additionally or alternatively, this application describes a computer-implemented method for providing secure messaging. The invention may be described as a secure communication solution and / or transmission solution (method / system). For example, this application may describe a computer-implemented method for transferring, transmitting, or communicating data to a blockchain. Data may be posted to a blockchain for an entity. The data may be digital content or some other digital resource. The invention may relate to an entity, organization, product, or service. For convenience, the terms "data," "digital resource," or "feedback" may be used herein in place of "content." The terms "feedback" or "review" are not intended to be limiting. The term "submitting" may be used herein in place of "transmitting" or "communicating."
[0016] The method may be implemented in a first node, which may include adding a first transaction (T c ), wherein the first transaction (T c ) commits and transfers a first number (x) of tokens to a second node associated with the entity (which may be a node), and completes the first transaction (T c ) has a first output; generating a first portion of data (hereinafter referred to as "content") for transmission to the blockchain; and transmitting a second transaction (T f1 ) and transmitting the second transaction (T f1) returns a second number (d) of the first number (x) of committed tokens to an address associated with the first node, and completes the second transaction (T f1 ) takes as input the first transaction (T c ) the first output of the first transaction (T c ) is used to unlock the first output of
[0017] In some implementations, the second transaction (T f1 ) may include the first content.
[0018] In some implementations, the first transaction (T c ) may include a set of allowed data ("content") entries, and the first content corresponds to one of the allowed content entries. In some implementations, the set of allowed content entries includes a hash of one or more allowed data ("content") values.
[0019] In some implementations, the method may further include receiving, at the first node, an indication of the one or more permitted content values, and generating the first content includes selecting one of the permitted content values.
[0020] In some implementations, the second transaction (T f1 ) may include a signature corresponding to a public key associated with the first node.
[0021] In some implementations, the one or more permitted content values may include one or more discrete rankings.
[0022] In some implementations, the second transaction (T f1 ) may include identifiers associated with products offered by the entity.
[0023] In some implementations, the first transaction (T c ) may have a second output different from the first output, and the method may include taking as input the first transaction (T c ) has been sent to the blockchain by a first time point (nLockTime); and in response to the determination, adding a third transaction (T f2 ), and f2 ) transfers a third number (xd) of the first number (x) of committed tokens to an address associated with the first node. In some implementations, the third transaction (T f2 ) includes a transaction parameter (nLockTime), and the transaction parameter (nLockTime) is f2 ) becomes eligible for submission to the blockchain. In some implementations, the transaction parameter (nLockTime) specifies the time when the first transaction (T c ) is sent to the blockchain (T), a fixed length of time (s).
[0024] In some implementations, the third transaction (T f2 ) to the blockchain. c ) may be created and signed by the entity prior to transmission.
[0025] In some implementations, the third number (xd) may be equal to the difference between the first number (x) and the second number (d).
[0026] Additionally or alternatively, the present application describes a computing device for participating in a process for transmitting content (which may be, for example, feedback) for an entity to a blockchain, the computing device including a processor, memory, a network interface providing network connectivity, and a blockchain application including computer-executable instructions that, when executed by the processor, cause the processor to perform the methods described herein.
[0027] Additionally or alternatively, the present application describes a non-transitory processor-readable medium storing processor-executable instructions for participating in a process of submitting content to a blockchain, which, when executed by a processor, cause the processor to perform the methods described herein.
[0028] Some implementations may be used to provide a secure messaging (i.e., communication or transmission) system that implements constraints on nodes sending messages. For example, a node sending a message containing content (which may simply be feedback) may be required to perform a predefined action before being authorized to send such content. For example, a node may be required to complete a first transaction (T) before being allowed to send a message containing content. c ) may be required to send the first transaction (T c ) submission may also only allow nodes to submit content for a single item (such as a single review), which prevents spam.
[0029] This application describes blockchain-based systems and methods that facilitate secure and efficient implementation of schemes for encrypting, verifying, and broadcasting reviews submitted by users participating in review platforms. In some implementations, this application provides protocols designed to prevent unrestricted submissions by malicious actors from affecting the effectiveness of product and / or service reviews. [Brief explanation of the drawings]
[0030] Any feature described in connection with one aspect or implementation of the invention may also be used in connection with one or more other aspects / implementations. These and other aspects of the invention will be apparent from and elucidated with reference to the implementations described herein. One implementation of the invention is described below, by way of example only, with reference to the accompanying drawings, in which:
[0031] [Figure 1] 1 illustrates an exemplary blockchain network of nodes. [Figure 2] 1 illustrates a schematic representation of an exemplary incentivized content submissions protocol (CSP) according to an implementation of the present application. [Figure 3] 1 illustrates, in flowchart form, an overview of an exemplary CSP according to an implementation of the present application. [Figure 4] 1 illustrates, in flowchart form, an exemplary method for posting content about an entity to a blockchain according to one implementation of the present application. [Figure 5]1 illustrates, in flowchart form, another exemplary method for posting content about an entity to a blockchain, according to one implementation of the present application. [Figure 6] 1 illustrates, in block diagram form, an exemplary blockchain node. DETAILED DESCRIPTION OF THE INVENTION
[0032] In this application, the term "and / or" is intended to cover all possible combinations and subcombinations of the listed elements, including any one of the listed elements alone, any subcombination, or all of the elements, without necessarily excluding additional elements.
[0033] In this application, the phrase "at least one of ... or ..." is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any subcombination, or all of the listed elements, without necessarily excluding any additional elements, and without necessarily requiring all of the listed elements.
[0034] In this application, the term “entity” refers to an entity that receives or is capable of receiving content, such as feedback (e.g., customer feedback in the form of reviews, rankings, ratings, comments, etc.). An “entity” may additionally or alternatively refer to a representative authorized to receive content on behalf of an entity. For example, an “entity” may be an organization, such as a retailer, service provider, or product manufacturer; a representative of an organization (e.g., a company's customer service department); or an individual (e.g., a reseller or independent contractor). In the context of the content transmission protocols described herein, an entity may be represented by one or more nodes in a blockchain network. In some cases, an entity may invite users and purchasers of the entity's products / services to post reviews, feedback, or other content. Reviews / feedback / content about an entity are posted by users, represented as participating nodes, and publicly disclosed by being broadcast to the blockchain ledger.
[0035] In this application, a "reviewer" refers to an organization or individual that posts content, such as feedback about an entity and / or a review of the entity's product / service. A reviewer may be, for example, a participant in a Content Submission Protocol (CSP) disclosed herein. A "reviewing node" is a node (in a blockchain network) associated with a particular reviewer, and a "user node" is a node associated with a user of a product / service who posts an appropriate review of the product / service in accordance with the CSP disclosed herein.
[0036] However, the term "reviewer" is used herein merely for the context of the selected exemplary embodiment. More generally, a "reviewer" is essentially a provider of some content / message. As such, the term "provider" is used herein as a more general term for a "reviewer."
[0037] Reference is first made to FIG. 1, which illustrates in block diagram form an example blockchain network 100 associated with a blockchain. A blockchain network is a peer-to-peer open membership network in which anyone can join without an invitation or the consent of other members. Distributed electronic devices may participate in the blockchain network 100 by running instances of a blockchain protocol according to which the blockchain network 100 operates. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol or other cryptocurrency.
[0038] The electronic devices that execute the blockchain protocol and form the nodes 102 of the blockchain network 100 may be various types of electronic devices, including, for example, computers such as desktop computers, laptop computers, tablet computers, servers, mobile devices such as smartphones, wearable computers such as smart watches, or other electronic devices.
[0039] The nodes 102 of the blockchain network 100 are connected to one another using suitable communication technologies, which may include wired and wireless communication technologies. In many cases, the blockchain network 100 is implemented at least in part by the Internet, and some of the individual nodes 102 may be located in geographically dispersed locations.
[0040] Nodes 102 maintain a global ledger of all transactions in the blockchain. The global ledger is a distributed ledger, and each node 102 may store a full or partial copy of the global ledger. Transactions by nodes 102 that affect the global ledger are verified by multiple other nodes 102, thereby maintaining the validity of the global ledger. Details of the implementation and operation of blockchain networks, such as networks using the Bitcoin protocol, will be understood by those skilled in the art.
[0041] Each transaction typically has one or more inputs and one or more outputs. Scripts embedded in the inputs and outputs specify how and who can access the outputs of the transaction. The output of a transaction may be an address to which tokens are transferred as a result of the transaction. The tokens are then associated with that output address as available transaction outputs. In the context of cryptocurrencies, similar to Bitcoin, available transaction outputs may be referred to as unspent transaction outputs (UTXOs). Subsequent transactions may then reference that address as an input to transfer those tokens to one or more other addresses.
[0042] Nodes 102 may be of different types or categories depending on their functionality. It has been suggested that there are four basic functions associated with a node 102: wallet, mining, full blockchain maintenance, and network routing. Variations on these functions may exist. A node 102 may have more than one of these functions. For example, a "full node" provides all four functions. A lightweight node may be implemented, for example, as a digital wallet and may feature only wallet and network routing functions. Rather than storing the entire blockchain, a digital wallet may keep track of block headers, which serve as an index when querying blocks. Nodes 102 communicate with each other using a connection-oriented protocol such as TCP / IP (Transmission Control Protocol).
[0043] In most blockchain networks, regardless of the governance protocol, it is advantageous to ensure that new transactions are propagated quickly through the network so that all nodes that maintain a pool of unconfirmed transactions (commonly called a "mempool") have an up-to-date and accurate database of transactions waiting to be included in a new block. Mining nodes use this pool of unconfirmed transactions to construct potential new blocks. In some cases, mining nodes maintain a complete mempool locally, allowing them to aggregate multiple unconfirmed transactions into a new block for mining. In some implementations, the mempool may be managed and maintained by a separate network of multiple nodes (which may be called validating nodes, etc.), which may send a set of unconfirmed transactions from the mempool to the mining node so that the mining node can attempt to mine a block. In some implementations, the mempool may be stored in a hash table that is distributed among multiple nodes. Regardless of its structure, it is desirable to propagate any new transactions through the network so that they reach the necessary nodes as quickly as possible, and it is also desirable to propagate any new successfully mined blocks through the network as quickly as possible so as to reduce the occurrence of orphan blocks.
[0044] In the current implementation of the Bitcoin network, as one example, each node that receives a new transaction validates the transaction and then transmits it to all of its connected nodes if they have not already received the transaction. In the case of Bitcoin, the nodes use TCP / IP (Transmission Control Protocol). A node that receives a new transaction sends an INV message with data about one or more available new transactions to each of its peer nodes and receives a GETDATA message from each node that is interested in receiving the new transaction or transactions. The node then transmits the transaction in a (separate) TCP message to each of the nodes that requested the transaction.
[0045] The present disclosure provides a blockchain-based messaging protocol that can be used, for example, for posting / sending content. When the messaging protocol is used for content posting, the messaging protocol may be referred to as a content posting protocol. An example used for illustrative purposes is posting review or feedback content. However, the present invention is not limited to this application, and other types of digital content or messages are intended to fall within the scope of the present invention.
[0046] More specifically, for illustrative purposes, a protocol is disclosed for posting content, such as feedback about an entity or reviews of the entity's products / services, using a blockchain ledger. According to one exemplary implementation of the protocol, when a user acquires a product or receives a service from an entity, the user node posts a review of the product / service within a specified time period. The review itself is inserted directly into a script that unlocks the blockchain transaction created by the user. By linking the blockchain transaction performed to acquire a particular product / service from an entity and the blockchain transaction performed to post a review of that product / service, the protocol ensures that only authorized participants (i.e., actual users and purchasers of the entity's products / services) can post their own reviews, which can then be publicly broadcast and stored on the blockchain. In this way, the protocol can help prevent scenarios where an unauthorized user controls multiple different identities to artificially influence those reviews and attempt to manipulate perceptions about a product / service (e.g., by posting multiple fake reviews aimed at intentionally damaging an entity's / product's reputation).
[0047] The proposed protocol utilizes blockchain concepts to provide a system / platform for collecting customer reviews or other messaging, which requires timely posting of content / messages, only accepts messages / content originating from authorized sources, and adds transparency to the process of collecting content and messaging.
[0048] In the description herein, the terms "user node," "input address," and "output address" may be used. Reference to the "address" of a node is not intended to refer to the network address of the physical node. Rather, the "address" is an address specified by a transaction in the blockchain that has an allocation of tokens that the physical node can claim ownership of by having a key corresponding to a signature in the transaction. In that sense, an "output address" is not the address of the user node, but rather a blockchain transaction output address owned by or associated with the user node. Similarly, an "input address" is the address of an available transaction output (corresponding to the term UTXO in the case of cryptocurrencies) owned by or associated with the user node.
[0049] The terms "feedback" and "review" may be used interchangeably throughout the specification and are understood to refer to a suitably formatted expression of a reaction or impression (e.g., numerical or descriptive ranking, comments, etc.) regarding one or more attributes (e.g., perceived quality, etc.) of an entity and / or its products / services.
[0050] Content Submissions Protocol (CSP) This application describes a method and system for posting customer reviews and feedback using blockchain. In particular, this application proposes a Content Submissions Protocol (CSP), which utilizes blockchain concepts to allow users to post content and messages, such as product and service reviews, and publicly and persistently record those reviews on a distributed ledger. The CSP is designed to encourage the posting of content, such as product and service reviews, by offering users the possibility to claim certain incentives directly linked to transactions for acquiring the product / service. In this way, the CSP ensures that only "approved" content, i.e., content such as reviews originating from authorized users, such as purchasers and past users of the product / service, is accepted and considered for publication on the blockchain ledger. Furthermore, by facilitating the publication of content (such as reviews and feedback), the CSP can help prevent any manipulation of content posted by a party.
[0051] Reference is now made to Figure 2, which shows a schematic representation of one exemplary implementation of a CSP. The CSP includes one or more user nodes (corresponding to users / reviewers) and at least one entity node (which may correspond to an entity receiving feedback or an entity whose product / service is being reviewed). For example, the provider (i.e., the reviewer / content contributor) may be a customer purchasing or using the product / service, and the entity may be at least one of a manufacturer, distributor, or service provider involved in providing the product / service.
[0052] To acquire a product or receive a service, a user node transfers a fixed number of tokens to an entity node associated with the entity providing the product / service. In particular, the user node transfers a transaction T c ) to transfer a fixed number x of digital assets (i.e., tokens) to an entity node in exchange for acquiring a product / service from that entity. According to several exemplary implementations of the CSP, an “acquire” transaction T c has one or more transaction outputs. The first output includes a number d of tokens, which represent incentive tokens offered to users for posting content, such as reviews, about acquired products or services. That is, a portion of the number x of tokens committed for transfer to the entity node is reserved for use as an incentive for customers / users (i.e., user nodes) of the product or service to post content, such as reviews. A "discount" amount may be agreed upon by the user and the entity and redeemed by the user node upon posting content (e.g., a review). T c The second output of contains xd tokens and represents a discounted transfer of tokens that can be redeemed by entity nodes when authorized user nodes post content. Notably, the total number of tokens actually transferred to entity nodes may be smaller than the initially committed number x, thereby providing appropriate incentives to user nodes that post content, such as product / service reviews, in the form of a "return" transfer of tokens.
[0053] Reference is now made to FIG. 3, which shows a flowchart 300 summarizing one exemplary implementation of a CSP. Flowchart 300 illustrates various blockchain transactions that are created to implement the CSP. A user acquires a product or receives a service offered by an entity. In step 302, an entity node communicates content guidelines, such as feedback guidelines for a product / service, to a user node. More precisely, the entity node conveys a set of acceptable content values for the product / service to the user node. For example, the content value options may be numeric (e.g., a numbered scale) or a descriptive ranking (e.g., "excellent-good-average-poor") that the entity has predefined as acceptable for a user's posting about a particular product / service.
[0054] In step 306, the user node commits and transfers x tokens to the entity via a commitment transaction as payment for an acquired product or received service. After this initial commitment transaction, the user node and the entity node can independently redeem their respective shares of the committed number x of tokens (d and xd, respectively) in steps 308 and 310, respectively. In particular, the user node can collect d tokens as an "incentive" for posting appropriate content, such as appropriate reviews, about products / services offered by the entity, and the entity node can request a "discount" payment of xd from the user on the sale of the product / service.
[0055] In at least some implementations, each user node and entity node may have a fixed time frame during which they are allowed to collect their respective share of the x initially committed tokens. For example, there may be a time constraint on when a user node must post content, such as a review about a product / service, to be eligible to receive incentive tokens. The time constraint can help ensure that content is posted to the blockchain in a timely manner, e.g., not too long after the time of acquiring the product or receiving the service. Similarly, an entity node may have a time constraint on when it must claim a “discount” payment for the sale of a product / service. In some cases, user nodes and entity nodes may have the same time frame of eligibility for claiming their respective share of committed tokens. For example, each user node and entity node may be allowed to redeem their respective share only within a fixed length of time (e.g., one month) after the time of the initial commitment of tokens in the “acquire” transaction. 3, if any of the respective shares are not claimed by one of the nodes (or are not claimed within the appropriate time frame), the other node may collect the unclaimed number of tokens. More specifically, if the entity node does not claim the "discount" payment, the user node may redeem the full amount of the x committed tokens in step 314, Similarly, if a user node fails to post a proper review or other content for a product / service (within a specified time frame), the entity node may collect the allocated number of tokens as an "incentive" in step 312, thereby receiving full payment of the x committed tokens for the product / service.
[0056] Referring now to FIG. 4, FIG. 4 illustrates, in flowchart form, an exemplary method 400 for posting content, such as feedback, about an entity to a blockchain. Method 400 may be performed by a node (e.g., a “user node”) in a blockchain network, such as network 100 of FIG. 1. In particular, the node may be associated with a user of a product / service who wishes to participate in a CSP. In some implementations, the user node is a wallet or other such blockchain entity. Method 400 may be suitable for a system / platform for collecting reviews of products and services offered by various different business entities (e.g., manufacturers, retailers, service providers, etc.). For example, method 400 may be incorporated into a content posting platform, such as a feedback posting platform for an online marketplace. An entity offering a product / service may enable past purchasers and users to post reviews using transactions that are recorded on a blockchain based, at least in part, on the operation of method 400.
[0057] In operation 402, a user node receives a first transaction T c Submit the first transaction T ccommits a first number x of tokens to transfer to a second node associated with that entity. This initial commitment of tokens may represent, for example, a full transfer of tokens for a product / service acquired from that entity. c is created by the user node and contains a public and private key pair (Pk U ,Sk U ) in its first transaction T c The first transaction T c has two outputs. The first output corresponds to incentive tokens, which are forwarded to the user node for posting content, such as a review about a product / service. The first output may represent, for example, a "discount" on full payment for the product / service, which is forwarded back to the user node. In some implementations, the locking script for the first output may specify multiple conditions related to other content or reviews that are acceptable for a particular product / service. For example, the locking script may include a set of predefined content values (e.g., review values) that are considered appropriate for the product / service. The locking script imposes restrictions on the first output such that it can be unlocked by a transaction that includes both (1) a signature that is valid for a public key associated with the user node and (2) content that is included in the set of predefined content values (e.g., review values included in the set of predefined review values). The second output is different from the first output and includes an associated public and private key pair (Pk SP ,Sk SP) a "discounted" number of tokens. In particular, the "discounted" number of tokens represents the difference between the first number x of tokens and the incentive number d of tokens for that user. The second output is then locked by a locking script that allows the entity node to claim the discounted number of tokens using a signature generated from a private key associated with that entity node.
[0058] At operation 404, a first content (e.g., a first review / feedback) is generated for posting to the blockchain. The content may be a review related to the entity and / or the entity's products / services obtained by a user associated with the node. At operation 406, a second transaction T f1 is posted to the blockchain, and its second transaction T f1 returns a second number d of the first number x of committed tokens to an address associated with the user node. f1 takes as input the first (commitment) transaction T c In other words, the second transaction T f1 is a transaction that transfers incentive tokens to a user node for posting appropriate content, such as appropriate reviews of products / services obtained from an entity. To ensure that content is only accepted from authorized users, the first output associated with the "incentive" for content posting is locked by specifying multiple conditions that must be met to spend d tokens of the "incentive." In particular, the first content is transferred in a first transaction T cThat is, the incentive tokens may be obtained by the user node only upon successful posting of appropriate content (such as an appropriate review of a product / service the user obtained or received from the entity). For example, in some implementations, the second transaction T (transferring an "incentive" amount to the user) f1 The unlocking script may include the first content (or a hash of the first content). By directly inserting the first content into the unlocking script, the first content can be persistently broadcast on the blockchain once the second transaction is posted to the blockchain by the user node (i.e., when claiming the incentive tokens). In some implementations, the unlocking script of the second transaction may also include a signature corresponding to a public key associated with the user node. Additionally, the metadata for the second transaction may include an identifier for a particular product or service offered by the entity, linking content such as a review post to the associated product or service.
[0059] To facilitate the process of verifying the validity of user-submitted content (e.g., reviews, etc.) and to make tracking of the submitted content manageable, in some implementations, an entity may decide to allow only a limited number of predefined content values (e.g., numerical rankings, descriptive words, etc.) for its products / services. That is, the entity may specify a predetermined set of one or more permitted content values that would be considered valid. In such a case, a first transaction T cThe script for locking the first output may include a set of allowed content entries, such as one or more discrete rankings. The first content would then need to correspond to one of the multiple allowed content entries to be accepted as a valid post. In some implementations, the set of allowed content entries may include hashes of one or more allowed content values. In other words, each possible content value may be hashed and used in the locking script to lock the first output (incentive tokens). The first output may then be unlocked in multiple ways by posting content corresponding to at least one of the hash values in the script for locking the first output. In this manner, appropriate content (such as appropriate review / feedback) may be generated simply by selecting one of multiple allowed content values (which may be referred to as feedback values or review values) specified by the entity. For example, a user node may receive an indication of one or more allowed content values, select content corresponding to one of these allowed options, and post it to the blockchain by the user node.
[0060]
[0033] Referring now to Figure 5, Figure 5 illustrates, in flowchart form, another exemplary method 500 for posting content about an entity. Method 500 may be performed by a node in a blockchain network, such as network 100 of Figure 1. In particular, the node may be associated with a user of a product / service ("user node") who intends to participate in a CSP. In some implementations, the node is a wallet or other such blockchain entity.
[0061] Operations 502, 504, and 506 correspond to and are similar in scope to operations 402, 404, and 406, respectively, of method 400. As explained above, first transaction Tc commits an initial number x of tokens representing full payment for a product / service for transfer to an entity, and the first transaction has two outputs: a first output representing an "incentive" for posting content / reviews, and a second output representing a "discounted" payment to the entity. For example, if an entity values the accumulation of reviews about its product / service from actual purchasers and users, the entity will likely agree to a lower final receipt amount for the product or service (i.e., lower than the "sticker" price).
[0062] In operation 508, a first transaction T c The user node determines whether a transaction having a second output of xd has been posted to the blockchain by a first time point nLockTime. In particular, the user node may check whether an entity node (e.g., a service provider) has collected a "discounted" payment xd before a certain time point. For example, the node may directly communicate with a second node associated with the entity, or may initiate a search of the blockchain to determine whether a transaction transferring a UTXO of the second output to an address associated with the entity node has been posted to the blockchain.
[0063] If the entity has not claimed its share of the committed number x of tokens by a predetermined time, then in operation 510 the node initiates a third transaction T f1 and post the third transaction T f1 transfers a number xd of tokens to an address associated with that user node. In particular, a third transaction T f2performs a time lock, allocating a sufficient amount of time to allow the entity to claim the "discounted" payment. That is, the third transaction includes a transaction parameter nLockTime that specifies the point in time at which the third transaction becomes eligible for posting to the blockchain. This parameter may be selected by the user, by the entity, or by mutual agreement to strike a reasonable balance between providing a sufficient amount of time for the parties to claim their respective shares of the committed number x of tokens and ensuring that reviews or other content are posted by user nodes in a timely manner. In some implementations, the transaction parameter nLockTime may specify a point in time that is a fixed length of time (s) after the point in time (T) at which the first transaction is posted to the blockchain (i.e., when the initial number x is committed). That is, nLockTime=T+s (1) These parameters are likely to be agreed upon by the entity and its end users (i.e., customers) prior to their transactions, so the first commitment transaction T c Before posting, a third transaction T is sent by the entity directing an unclaimed "discounted" payment to the user node. f2 and then create a third transaction T f2 That is, the entity node may include a time lock on the third transaction and make the third transaction accessible to the user node, whereby the user node may post the third transaction and unlock a number xd of tokens using the user's signature.
[0064] As an example, a commitment transaction T c1 illustrates an exemplary locking script for a first output of a user node. For example, the locking script may specify a set of descriptive rankings (e.g., "poor-average-good-excellent") as acceptable content values (i.e., acceptable review or feedback values). A user node can unlock a number (d) of tokens associated with the first output by posting content, such as a review, that corresponds to one of the acceptable content values. Thus, the locking script would present four options to release those tokens. The script evaluates an unlocking script, which checks whether the content posted by the user node corresponds to one of the four permitted rankings and checks that the signature provided by the user node corresponds to the user's public key, thereby including the content the locking script means to unlock. The unlocking script may specify additional options corresponding to entity redemption transactions. In a schematic form, the options of the locking script can be read as follows: Refund: OP_2 <pubkey U><pubkey S p > OP_2 OP_CHECKMULTISIG Ranking 1: OP_HASH160<H(poor)> OP_EQUALVERIFY<pubkey U> OP_CHECKSIG Ranking 2: OP_HASH160<H(average)> OP_EQUALVERIFY<pubkey U> OP_CHECKSIG Ranking 3: OP_HASH160<H(good)> OP_EQUALVERIFY<pubkey U> OP_CHECKSIG Ranking 4: OP_HASH160<H(excellent)> OP_EQUALVERIFY<pubkey U> OP_CHECKSIG This becomes:
[0065] Just as a user node can collect a "discount" payment that an entity node has not claimed, an entity node may be able to claim the entire initially committed number x of tokens if the user node has not posted appropriate content, such as an appropriate review, before a certain point in time. That is, if appropriate content, such as an appropriate review / feedback about a product or service, is not posted by the user node within a predefined time period, the entity node can collect the user's share (i.e., content submission "incentive"). In particular, an entity node may collect a refund transaction T f3 You may post the refund transaction T f3 transfers to the entity node those d tokens that have been allocated as incentive tokens. This redemption transaction may include a parameter indicating when the redemption transaction can be posted to the blockchain. The redemption transaction T f3 and a refund transaction T f3 In particular, the user node signs a refund transaction T f3 Prepare the refund transaction T f3 Then, the entity node signs the refund transaction T f3 whereby the entity node provides the refund transaction T to the blockchain network after the expiration of the time lock. f3 It is possible to post.
[0066] Methods 400 and 500 may be implemented as part of a blockchain-based content aggregation platform, such as a blockchain-based review and feedback aggregation platform. In particular, a platform 520 (not shown) may be provided for aggregating reviews shared by blockchain transactions. The platform 520 may, for example, collect and organize posted content / feedback / reviews about a particular entity or multiple different reviewed entities. The platform 520 may be implemented as a web portal, computer software, and / or mobile software module. The platform 520 may provide a variety of different functions, such as sorting, organizing, and searching blockchain transactions that include reviews of multiple entities and their products / services. For example, information such as transaction script metadata, input addresses, and output addresses may be used to perform a blockchain search to locate those transactions that include embedded reviews and feedback. Search results (i.e., blockchain transactions) may be sorted, for example, by the entity being reviewed, the type of product / service, the product / service ID, the review posting technique, a numerical ranking from highest to lowest, or a ranking from lowest to highest, etc.
[0067] Additionally, in some implementations, platform 520 may enable filtering of content, such as reviews, to identify potentially invalid or fake reviews or other content. For example, in the proposed techniques of methods 400 and 500, a node posts content, such as a review, by including it in a transaction script of a transaction that returns a certain number of “incentive” tokens to the node. If an unauthorized user gains access to information about a commitment transaction that transfers payment for a product / service to an entity, the user may post a transaction that meets multiple conditions in the locking script for the commitment transaction and, as a result, post an invalid review of the entity and / or the entity's products / services. Platform 520 may be used to remove such unauthorized reviews based on criteria communicated to platform 520 by the entity being reviewed. For example, platform 520 may be configured to detect reviewers who have not purchased products / services from the entity and discard reviews posted by nodes associated with those unauthorized reviewers.
[0068] 6, which illustrates in block diagram form one simplified example of a node 600, which may be a participant node and / or an entity node in the context of this disclosure. Node 600 includes a processor 602, which may include one or more microprocessors, application specific integrated chips (ASICs), microcontrollers, or similar computing devices. Node 600 further includes memory 604, which may include persistent and non-persistent memory for storing values, variables, and, in some cases, processor-executable program instructions, and a network interface 606 for providing network connectivity over a wired or wireless network.
[0069] The node 600 includes a processor-executable blockchain application 608 that includes processor-executable instructions that, when executed, cause the processor 602 to perform one or more of the functions or operations described herein.
[0070] It will be understood that standard computer programming techniques and languages may be used to implement any modules, routines, processes, threads, applications, or other software components that implement the devices and processes described herein, and the described methods / processes for configuring a blockchain node. The present application is not limited to particular processors, computer languages, computer programming conventions, data structures, or other such implementation details.
[0071] It should be noted that the implementations mentioned above are illustrations of the present invention, not limitations thereon, and that a person skilled in the art will be able to design many alternative implementations without departing from the scope of the present invention, which is defined by the appended claims. In the claims, reference signs placed in parentheses shall not be construed as limiting the claims. The words "comprise" and "comprises" and the like do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. As used herein, "comprise" means "comprising or consisting of" and "comprising" means "comprising or consisting of." A singular reference to an element does not exclude a plurality of references to such elements, and vice versa. The invention may also be implemented by means of hardware comprising several distinct elements and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be realized by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
Claims
1. 1. A computer-implemented method for submitting data to a blockchain, the method comprising: submitting a first transaction to the blockchain, the first transaction committing a first number of tokens to transfer to a second node associated with an entity, the first transaction having a first output and a second output; the first output includes a second number of the committed first number of tokens, the second number being sent to an address associated with the first node; the second output includes a third number of the first number of committed tokens, the third number being sent to an address associated with the second node; generating, by the first node, first content for transmission to the blockchain, the first transaction includes a locking script for the first output, the locking script for the first output specifying a condition associated with the first content, whereby the first content is used to unlock the first output of the first transaction; determining that a transaction having the second output of the first transaction as an input has been sent to the blockchain by a first time point; in response to the determination, sending a third transaction to the blockchain, the third transaction transferring the third number of the committed first number of tokens to an address associated with the second node; method.
2. 2. The method of claim 1, comprising: sending a second transaction to the blockchain, the second transaction returning a second number of the first committed number of tokens to an address associated with the first node, the second transaction having the first output of the first transaction as an input, and a script for unlocking the second transaction including the first content.
3. The method of claim 2 , wherein the first content corresponds to one of a set of permitted content entries.
4. The method of claim 3 , wherein the set of allowed content entries includes a hash of one or more allowed content values.
5. receiving an indication of the one or more permitted content values; The method of claim 4 , wherein generating the first content comprises selecting one of the permitted content values.
6. 3. The method of claim 2, wherein the script for unlocking the second transaction includes a signature corresponding to a public key associated with the first node.
7. The method of claim 4 , wherein the one or more permitted content values include one or more discrete rankings.
8. The method of claim 2 , wherein the metadata for the second transaction includes an identifier associated with a product offered by the entity.
9. 10. The method of claim 1, wherein the third transaction includes a transaction parameter, the transaction parameter specifying a point in time when the third transaction becomes eligible for submission to the blockchain.
10. 10. The method of claim 9, wherein the transaction parameters specify a point in time that is a fixed length of time after the point in time that the first transaction is sent to the blockchain.
11. 10. The method of claim 1, wherein the third transaction is created and signed by the entity prior to submission of the first transaction to the blockchain.
12. The method of claim 1 , wherein the third number is equal to the difference between the first number and the second number.
13. A computing device participating in a process of sending content for an entity to a blockchain, the computing device performing the method of any one of claims 1 to 12.
14. 13. A non-transitory processor-readable storage medium storing processor-executable instructions for participating in a process of submitting content for an entity to a blockchain, the processor-executable instructions, when executed by a processor, causing the processor to perform the method of any one of claims 1 to 12.