Control of digital content and method executed by block chain for distribution

Abstract

To provide a system that is mounted by a block chain for controlling a transmission and / or a distribution of a digital content, and a method.SOLUTION: In a system 1, a first node 15 transmits a request for providing a digital content episode to a second node 17, determines a payment transaction that is signed by a first secret key for transferring an encryption currency payment to a second user 7 having a second processing device, and transmits it to the second node. The second node receives a request for providing the digital content episode from the first node signed by the first secret key and the payment transaction, validates the payment transaction, validates that the payment transaction contains the encryption currency payment to the second user, provides an access to the digital content episode to the first node by a second processing device on the basis of the result, performs a corroborative signature of the payment transaction with a second secret key of the second user, and transmits the payment transaction of the corroborative signature to a dispersal ledger 9.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] TECHNICAL FIELD This disclosure relates to systems and methods for payment and distribution of digital content from a digital content series, and may be applied to digital rights management of online digital media, but is not limited in this respect. [Background technology]

[0002] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system composed of blocks. Blocks are in turn composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block, and blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs. Scripts specify how and by whom the output of a transaction can be accessed. On the Bitcoin platform, these scripts are written using a scripting language based on the stack.

[0003] In order for a transaction to be written to the blockchain, it must be "verified." Network nodes (miners) perform work to ensure that each transaction is valid, and invalid transactions are rejected from the network. A software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing its locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to true, then the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be verified by the first node that receives the transaction, and if the transaction is verified, the node relays the transaction to other nodes in the network, ii) be added to a new block constructed by miners, and iii) be mined, i.e., added to the public ledger of past transactions.

[0004] Although blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore the use of both the cryptocurrency security system on which Bitcoin is based, and the data that can be stored on the blockchain, to implement new systems. It would be highly advantageous if blockchain could be used for automated tasks and processes that are not limited to the cryptocurrency realm. Such solutions would be more diverse in their applications, while still being able to take advantage of the benefits of blockchain (e.g., permanent, tamper-resistant record of events, distributed processing, etc.).

[0005] One area of ​​current research is the use of blockchain for the implementation of "smart contracts." These are computer programs designed to automate the execution of machine-readable transactions or terms of agreements. Unlike traditional transactions, which may be written in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce an outcome and can cause actions to be performed depending on that outcome.

[0006] Another area of ​​interest related to blockchain is the use of "tokens" (or "colored coins") to represent and transfer real-world entities across the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. The tokens thus act as identifiers that allow the real-world items to be referenced from the blockchain.

[0007] Digital rights management relates to controlling copyright-enforced digital media and includes control techniques that limit the use, modification, and distribution of digital media. Digital media can include serialized content, such as magazines, newspapers, podcasts, time-based content such as soap operas, television series, etc.

[0008] Implementations of digital rights management may involve the management of copyrighted works through a large central system or multiple systems, with key exchange to create trust between nodes associated with each user. Such systems may be difficult to manage, and maintaining ongoing access rights may be difficult to achieve. As some alternatives, a trusted third party (such as a certificate authority) may be used to create a hierarchical structure. However, some of these systems may create large single points of failure that may be vulnerable to attack.

[0009] The term "blockchain" is used herein to include all forms of electronic, computer-based, distributed ledgers, including, but not limited to, consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned 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. Although Bitcoin is referred to herein for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0010] Throughout this specification, the terms "comprise" or variations such as "comprises" or "comprising" are understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

[0011] Any discussion of documents, acts, materials, devices, products, or the like included in the specification of this application should not be construed as an admission that any or all of those items form part of the prior art or were common general knowledge in the art relevant to the disclosure as they existed prior to the priority date of each claim of this application. Summary of the Invention

[0012] The present invention provides methods and systems as defined in the accompanying claims.

[0013] The present invention may provide a control method and corresponding system arranged to control the transmission and / or distribution of data. The transmission may be via or across a computer implemented or communication network. The data may be digital content. The present invention may provide a method / system incorporating cryptography and / or encryption techniques to secure the distribution / transmission of data. Thus, the present invention may provide an enhanced security solution for data communication.

[0014] In this specification, the term "episode" may be used synonymously with the term "portion." However, the digital content transmitted, distributed, and / or controlled by the present invention is not limited to a single instalment, a logical chapter or episode of broadcast media, or artistic content. The term "episode" in this specification and claims refers to a "portion" or "unit" or "amount" of digital content. Similarly, the term "series" in this specification simply refers to a series, in the sense of a broadcast series. A series may simply be a plurality of portions, groupings, or associations of digital content. "Series" is not necessarily limited to being sequential or chronological. Furthermore, the present invention is not limited with respect to the nature or format of the digital content. The digital content is not limited to entertainment media, but may relate to any type of digital content.

[0015] The invention may provide a system, where a first user is associated with a cryptocurrency amount in a common address. The cryptocurrency may be referred to as a "bond amount". The address may be an address on a network. The address may be a blockchain address. The address may be derived from or associated with a cryptographic key. Spending from the common address may require a (digital) signature of at least a first private key (V1) of the first user and a second private key (V2) of the second user. This may be specified by the use of a given type of blockchain transaction. The transaction type may be part of or defined in the blockchain protocol.

[0016] 1. A system comprising: a first node associated with a first user, the first node having a first processing device, (A) sending, via a communications network, a request to the second node to provide a digital content episode (i) from a digital content series; (B) a blockchain transaction (E i ) , the cryptocurrency payment (B2) being based on the number of episodes of digital content in the series of digital content requested by the first user; (C) transmitting the payment transaction (E i ) and then sign the payment transaction (E i ) to the second node; a second node associated with the second user, the second node having a second processing device, (I) transmitting, via the communications network, the digital content episode (i) signed with the first private key (V1) and the payment transaction (E i receiving the request from the first node to provide (II) configured to verify the payment transaction, including verifying that the payment transaction includes the cryptocurrency payment amount (B2) to the second user, and based on a result of the verification, the second processing device further: (III) providing access to the digital content episodes (i) to be made available to the first node via the communications network; (IV) a second node configured to co-sign the payment transaction with the second private key (V2) of the second user and transmit the co-signed payment transaction to a peer-to-peer distributed ledger; A system including:

[0017] In the system, the first processing device may be further configured to request a next digital content episode from the digital content series by repeating steps (A) to (D), and the second processing device may be further configured to receive the request and deliver the next digital content episode by repeating steps (I) to (III), wherein step (IV) of co-signing and sending the payment transaction to a peer-to-peer distributed ledger is performed for a payment transaction having a number of digital content episodes including the next episode. Advantageously, one of the advantages provided by the present invention is that each portion of digital content is encrypted together with the cryptographic key of (or associated with) the further or subsequent portion. Use of the key provides technical evidence that the portion of digital content has been decrypted. Thus, it can be determined that the digital content has been accessed, e.g., viewed or consumed / used in some way.

[0018] In the system, the first user may deposit the cryptocurrency guarantee amount to the common address, and the first processing device is configured to send a first data output (O1) via a communications network to record a first transaction of the cryptocurrency guarantee amount (B1) from the first user to the common address in a peer-to-peer distributed ledger (hereinafter sometimes simply referred to as a "blockchain").

[0019] In the system, after a designated time, the cryptocurrency guarantee amount (B1) may be refunded without a transaction of the cryptocurrency guarantee amount from the common address. The first processing device may be further configured to co-sign a second transaction transferring the cryptocurrency guarantee amount (B1) from the common address to the first user with a first private key (V1) of the first user. The second processing device may be further configured to co-sign a second transaction with the second private key (V2), the second transaction co-signed by both the first private key (V1) and the second private key (V2) being sent to a peer-to-peer distributed ledger and valid after a designated time to refund the cryptocurrency guarantee amount (B1), and to send the co-signed second transaction to the peer-to-peer distributed ledger before the designated time.

[0020] In the system, the second processing device transmits, via the communications network, episode secrets (S) associated with the digital content episodes from the digital content series available for request by the first user. i The first processing device may be further configured to transmit the episode secret (S i ) and receives the episode secret (S i ) to Episode Secret Hash (H i ) to transfer the cryptocurrency payment amount (B2) to the second user. iDetermining the episode secret hash (H i ) and a second public key (P2) that is a cryptographic pair with the second private key (V2) of the second user. i ), the second processing device verifies that the payment redeem script (RS1) matches the episode secret hash (H i ) and the second public key (P2).

[0021] In the system, the second processing device selects the next digital content episode (S i+1 ) associated with the next episode secret (S i+1 ) and determine the next episode secret (S i ) to the next episode secret hash (H i+1 During or after step (III) of transmitting the digital content episode, the second processing device may be further configured to determine a next episode secret (S i+1 The first processing device is further configured to transmit the episode secret (S i+1 ) and receives the episode secret (S i+1 ) to the next episode secret hash (H i+1 ) corresponding to the next payment transaction (E i+1 ) is the next episode secret hash (H i+1 ) and the second public key (P2), and the second processing device executes a next payment transaction (E i+1 ), the second processing device verifies that the next payment redeem script (RS2) is the next episode secret hash (H i+1) and the second public key (P2).

[0022] In the system, the payment transaction (E i ) further includes transferring a cryptocurrency change amount (B3) to the first user from the common address to the first user, the cryptocurrency change amount (B3) being based on the cryptocurrency guarantee amount (B1) less the cryptocurrency payment amount (B2).

[0023] In the system, the second processing device may be further configured to determine a common secret between the first node and the second node. Providing access to the digital content episodes over the communications network includes the second processing device encrypting one or more digital content episodes with a key based on the common secret to provide the one or more encrypted digital content episodes, and transmitting the one or more encrypted digital content episodes. The first processing device may be further configured to determine a common secret between the first node and the second node, receive the one or more encrypted digital content episodes over the communications network, and decrypt the one or more encrypted digital content episodes with a key based on the common secret to provide the one or more digital content episodes.

[0024] In the system, the second processing device receives the episode secret (S i ), and / or the next episode secret (S i+1 The first processing device may be further configured to determine an encrypted message based on the episode secret (S i ), and / or the next episode secret (S i+1 ).

[0025] 1. A computer-implemented method of receiving digital content, the method comprising: a first node associated with a first user receiving the digital content in exchange for a payment to a second user associated with a second node, the first user being associated with a cryptocurrency bond amount (B1) in a common address, and a spend from the common address requires a signature of both a first private key (V1) of the first user and a second private key (V2) of the second user, the method comprising: (A) transmitting, via the communications network to the second node, a request to provide a digital content episode (i) from a digital content series; (B) a payment transaction (E i ), wherein the cryptocurrency payment (B2) is based on a number of digital content episodes in the digital content series requested by the first user; (C) transmitting the payment transaction (E i ), then signing the payment transaction (E i ) to the second node to cause the second node to validate the payment transaction; Based on the second node verifying that the payment transaction includes the cryptocurrency payment amount (B2), the method further comprises: (D) accessing the digital content episode (i) via the communications network.

[0026] The method may further include the step of requesting a next digital content episode from the digital content series by repeating steps (A) through (D).

[0027] The method may further include the first user paying a deposit of the cryptocurrency guarantee amount (B1) to the common address by sending a first data output (O1) via a communications network to record a first transaction of the cryptocurrency guarantee amount (B1) from the first user to the common address on a peer-to-peer distributed ledger.

[0028] In another example of the method, the cryptocurrency guarantee amount (B1) is refunded after a designated time without a transaction of the cryptocurrency guarantee amount (B1) from the common address, the method further comprising the step of co-signing a second transaction transferring the cryptocurrency guarantee amount (B1) from the common address to the first user with the first private key (V1) of the first user, wherein the co-signed second transaction co-signed by the second user with the second private key (V2) is sent to the peer-to-peer distributed ledger and enabled to refund the cryptocurrency guarantee amount (B1) after the designated time.

[0029] The method further comprises receiving, via the communications network, an episode secret (S) associated with the digital content episode from the digital content series, the episode secret (S) being available for request by the first user. i ), and receiving the episode secret (S i ) to Episode Secret Hash (H i ) may further comprise the step of determining the payment transaction (E i The cryptocurrency payment (B2) to the second user in the episode secret hash (H i ) and a second public key (P2) that is a cryptographic pair with the second private key (V2) of the second user.

[0030] In the method, in or after step (D), the method further comprises transmitting, via the communication network, the next digital content episode (S i+1 ) associated with the next episode secret (S i+1 The step of requesting the next episode from the digital content series may further include receiving the next digital content episode (S i+1 ) to the next episode secret hash (H i+1 ), and determining a corresponding next payment transaction (E i+1 ) is the next episode secret hash (H i+1 ) and a next payment Redeem Script (RS2) based on the second public key (P2).

[0031] In the method, the payment transaction (E i ) may further include transferring a cryptocurrency change amount (B3) from the common address to the first user, the cryptocurrency change amount (B3) being based on the cryptocurrency guarantee amount (B1) less the cryptocurrency payment amount (B2).

[0032] The method may further include determining a common secret between the first node and the second node, and wherein accessing the digital content episode via the communications network includes receiving an encrypted digital content episode via the communications network; and decrypting the encrypted digital content episode with a key based on the common secret to provide the digital content episode.

[0033] The aforementioned Episode Secret (S i ), and / or the next episode secret (S i+1 Upon receiving the episode secret (S i), and / or the next episode secret (S i+1 ) may further comprise the step of determining

[0034] 1. A computer-implemented method of controlling distribution of digital content, the method comprising: a first node associated with a first user receiving digital content in exchange for a payment to a second user associated with a second node, the first user being associated with a cryptocurrency bond amount (B1) in a common address, and any spend from the common address requires a signature of both a first private key (V1) of the first user and a second private key (V2) of the second user, the method comprising: (I) receiving, via the communications network, from the first node a request to provide a digital content episode (i) from a digital content series; (II) a payment transaction (E) signed with the first private key (V) transferring a cryptocurrency payment amount (B) from the common address to the second user. i ), wherein the cryptocurrency payment (B2) is based on a number of digital content episodes in the digital content series requested by the first user; (III) verifying the payment transaction, the verification including verifying that the payment transaction includes the cryptocurrency payment amount (B2) to the second user; and based on a result of the verification, the method further comprising: (IV) providing access to the digital content episodes to the first node via the communications network; (V) co-signing the payment transaction with the second private key (V2) of the second user and sending the co-signed payment transaction to the peer-to-peer distributed ledger.

[0035] The method may further include delivering a next digital content episode from the digital content episodes by repeating steps (I) to (IV), where step (V) is performed for a payment transaction having a digital content episode number including the next episode.

[0036] In one example of the method, the cryptocurrency bond amount (B1) may be returned to the first user after a designated time without a transaction of the cryptocurrency bond amount from the common address. Accordingly, the method may further include co-signing a second transaction transferring the cryptocurrency bond amount (B1) from the common address to the first user with the second private key (V1) of the second user, where the co-signed second transaction co-signed by the first user with the first private key (V1) is sent to the peer-to-peer distributed ledger and enabled to return the cryptocurrency bond amount (B1) after the designated time. Furthermore, the step of sending the co-signed payment transaction to the peer-to-peer distributed ledger is performed before the designated time.

[0037] The method further comprises receiving, via the communications network, an episode secret (S) associated with the digital content episode from the digital content series, the episode secret (S) being available for request by the first user. i ), and transmitting the episode secret (S i ) to Episode Secret Hash (H i ) may further comprise the step of determining the payment transaction (E i ) is a step of verifying that a corresponding payment redeem script (RS1) for transferring the cryptocurrency payment (B2) to the second user matches the episode secret hash (H i ) and a second public key (P2) that is a cryptographic pair with the second private key (V2) of the second user.

[0038] The method further comprises: i+1 ) associated with the next episode secret (S i+1 ), and determining the next episode secret (S i ) to the next episode secret hash (H i+1 In or after step (IV), the method may further comprise the step of determining a next episode secret (S i+1 When validating a next payment transaction for the next episode, the method further includes transmitting a next payment redeem script (RS2) for forwarding the next cryptocurrency payment to the second user to the first node using the next episode secret hash (H i+1 ) and the second public key (P2).

[0039] In the method, the payment transaction (E i ) may further include transferring a cryptocurrency change amount (B3) to the first user from the common address to the first user, the cryptocurrency change amount (B3) being based on the cryptocurrency guarantee amount (B1) less the cryptocurrency payment amount (B2).

[0040] The method may further include determining a common secret between the first node and the second node. Providing access to the digital content episodes over the communications network may include encrypting the digital content episodes with a key based on the common secret, and transmitting the encrypted digital content episodes over the communications network.

[0041] In the method, the episode secret (S i ), and / or the next episode secret (S i+1The step of transmitting the episode secret (S i ), and / or the next episode secret (S i+1 ), determining an encrypted message encrypted with a key based on the common secret.

[0042] Any of the embodiments of the invention described above may include a method of determining a secret common to a first and a second node, and / or a system configured to perform the method, the method comprising: determining a first node second private key based on at least the first node master private key and the generator value; determining a second node second private key based on at least a second node master private key and the generator value; may include (or the system may be operable to perform the above steps), The step of determining the common secret (CS) at the first node may be based on the first node second private key and the second node second public key, and the step of determining the common secret (CS) at the second node may be based on the second node second private key and the first node second public key; The first node second public key and the second node second public key may be based on at least the first / second node master key and the generator value, respectively. The generator value may be a message or may be derived from a message. The generator value may be derived from metadata stored in a blockchain transaction (Tx).

[0043] An apparatus having a processing unit, the apparatus being adapted to carry out any one of the methods described above.

[0044] A computer program comprising machine readable instructions for causing a processing device to perform any one of the methods described above.

[0045] Any feature described with respect to one embodiment or aspect of the invention may be applied to one or more other embodiments / aspects of the invention, and any feature described in relation to a system of the invention may be applied to a method of the invention, and vice versa. [Brief description of the drawings]

[0046] Examples of the present disclosure will now be described with reference to the following drawings.

[0047] [Figure 1] 1 is a schematic diagram of an exemplary system for distributing digital content.

[0048] [Diagram 2] A diagram showing a transaction between a first user, a second user, and a common address.

[0049] [Diagram 3] 1 is a flowchart of a computer-implemented method for distributing and receiving digital content.

[0050] [Figure 4] 1 is a flowchart of a computer-implemented method for initiating and generating a refund transaction.

[0051] [Diagram 5] 4 is a detailed flowchart of a computer-implemented method for distributing and receiving digital content according to one example.

[0052] [Figure 6] 1 shows a simplified example of a processing device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0053] <Summary> Systems, devices and methods for controlling the distribution and transmission of digital content from one node and the reception of digital content from another node are described below. Figure 1 shows a system 1 including a first node 15 associated with a first user 5 in communication with a second node 17 associated with a second user 7 via a communications network 8. In this example, the first user 5 can request to receive digital content at the first node 15, and the second user provides access to the digital content via the second node 17. The second node 17 can provide access to the digital content in a number of ways, including transmitting the digital content from a first data store 18 to the first node 15, and making the digital content in a second data store 11 associated with a content server 3 available to the first node 15 via the communications network 8.

[0054] The first node 15 and / or the second node 17 communicate with a peer-to-peer distributed ledger (blockchain) 9 via a communication network 8. The blockchain 9 may be associated with one or more processors 19 for receiving and recording transactions. An example of a peer-to-peer distributed ledger includes the blockchain, which is a distributed ledger of transactions (Txs) based on the Bitcoin protocol. Thus, the processors 19 associated with the ledger may be processors used by or associated with "miners."

[0055] 2, a first user 5 may wish to purchase an unknown number of digital content from a digital content series from a second user 7. Before making the digital content available to the first user 5, the second user 7 requires a deposit to provide credit that the second user 7 will be paid for the digital content.

[0056] To provide a bond, the first user 5 may perform a first transaction 21 to transfer a cryptocurrency bond amount (B1) to the common address 23. The common address 23 may be a pay-to-script-hash (P2SH) address according to the Bitcoin protocol, and spending from the common address 23 requires the signature of both the first private key (V1) of the first user 5 and the second private key (V2) of the second user 7. That is, a transaction from the common address 23 must be signed by both the first user 5 and the second user 7. This allows both parties to have confidence that the bond will not be spent without approval from both parties. It is understood that alternative multi-signature methods may be used to authorize transactions from the common address 23.

[0057] In some examples, the bond may be time-limited, such that if the first user 5 does not request to receive the digital content episode within a specified time (and / or under other conditions), the bond is returned to the first user 5. An example of this is shown in FIG. 2 as a second transaction 25 that returns the cryptocurrency bond amount (B1) to the first user 5. In some examples, this can be accomplished by having both the first user 5 and the second user 7 co-sign a second transaction from a common address 23 to the first user 5, where the second transaction is only valid after the specified time, which may be d days in the future expressed in Unix time. This second transaction is then broadcast, where the second transaction becomes a valid transaction after the specified time.

[0058] Thus, if a competing transaction using the cryptocurrency bond amount from the common address is broadcast before the specified time, it becomes a valid transaction. It is in the second user 7's interest to broadcast a valid competing transaction after the specified time. After this, the cryptocurrency bond amount (B1) is refunded to the first user (5). In this example, these competing transactions are referred to as payment transactions 27, 27', 27'', as they represent transactions from which the second user 7 is paid.

[0059] A simple example of how to distribute digital content, including generating a payment transaction 27, is described below with reference to Figure 3. Figure 3 shows methods 100, 200 performed by the first node 15 and the second node 17, respectively.

[0060] When a first user 5 wishes to receive a digital content episode from a digital content series, the first user 5 generates a request for digital content using a first node 15. The first node 15 (which may be a computer, a mobile communications device, a television, etc.) includes a first processing device 23 that transmits (110) the request to a second node 15 to provide the digital content episode via the communications network 8.

[0061] The first node 15 further initiates a payment transaction (E i The second user 7 then determines 120 a payment amount (B2) for the digital content series requested by the first user 5. The payment amount (B2) is based on the number of digital content episodes in the digital content series requested by the first user 5. This may include episodes that have been previously requested (and received) but for which payment has not been received by the second user 7. In a simplified example, the second payment amount (B2) may be the number of episodes requested (i) multiplied by the price (p) of each episode.

[0062] The first node 15 then transmits the payment transaction (Ei )27 Signing 130. Payment Transaction (E i ) 27 is then sent to the second node 17. i This is still not a valid transaction because the original transaction (V1) is only signed with the first private key (V1) and requires the second node 17 to sign it with the second private key (V2).

[0063] Consider a second node 17 associated with a second user 7, the second node having a second processing device 23′, which may include a mainframe computer, a desktop computer, or the like. The second processing device of the second node 17 receives digital content episodes and a payment transaction (E) signed with a first private key (V1) from the first node 15 over the communications network 8. i ) is received 210.

[0064] Before the second node 17 can make the digital content episode available to the first node 15 and the first user 5, the second node 17 needs to determine that the second user 17 is able to receive payment. Thus, the second node 17 then initiates a payment transaction (E i ) 27. This is to validate the payment transaction (E i ) 27 includes the cryptocurrency payment amount (B2) to the second user 7. In a practical example, this may involve determining the exact amount of cryptocurrency and the exact destination.

[0065] Payment Transaction (E i ) (i.e., in particular, that the second user 7 has been paid), the second node 17 then provides 230 access to the digital content episodes made available to the first node 15 via the communications network 8. This also authorizes 140 the first node to access the digital content episodes.

[0066] Payment Transaction (E iTo execute the payment transaction (E) 27, the second node 17 then performs a payment transaction (E) with the second private key (V2) of the second user 5. i ) 27 and send the co-signed payment transaction to the blockchain 9. Thus, the cryptocurrency payment amount (B2) is transferred from the common address 23 that had the cryptocurrency margin amount (B1).

[0067] In some examples, the first user 5 may have an opportunity to request and receive additional episodes, and therefore the second user 17 may have an opportunity to receive more payment (from additional episodes provided to the first user 5) and may therefore delay co-signing and sending the co-signed payment transaction 240 to the blockchain 9 until closer to the designated time to return the deposit for the second transaction 25. An example of delivering the next episode is described below.

[0068] The first node 15 generates a request for the next digital content episode from the digital content series by repeating steps 110, 120, and 130 described above for the next episode. Importantly, the cryptocurrency payment amount is adjusted to take into account the next episode (and any previous episodes in the series for which payments have not been made). The second node 17 similarly receives the request and delivers the next digital content episode by repeating steps 210-230 described above.

[0069] Thus, the second node 17 has two payment transactions: a first payment transaction (E i ) 27 includes a cryptocurrency payment amount depending on the digital content episode, and a second payment transaction (E i+1 ) 27' includes a cryptocurrency payment amount due and including the next digital content episode. Since the second user 7 is interested in receiving the maximum payment amount, the second node 17 co-signs payment transaction 27' including the payment including the payment for the next episode, i.e., second payment transaction (E i+1) 27′. Therefore, the first payment transaction (E i ) 27 may be discarded by the second node 17.

[0070] The present disclosure may provide a system for communicating, transmitting, and / or distributing digital content with a lower level of trust. For example, the exposure of the first user 5 and / or the second user 7 to fraudulent activity may be minimized. In one example, if the second user 7 fails to meet their obligations, the exposure (e.g., potential loss) to the first user may be the price of one digital content episode (as the remaining amount is refunded).

[0071] The present disclosure also provides a system that does not rely on other third parties and hierarchical structures, such as certificate authorities, that may have single points of failure and vulnerability to attack. The use of cryptographic techniques enhances the security of the transmission / control arrangement provided by the present invention.

[0072] Detailed examples are set forth below for illustrative purposes.

[0073] <Initialization-Cryptographic Protocol> A first node 5 and a second node 7 establish secure communications 101, 201 with each other over a communications network 8. This may involve encrypted communications with a shared symmetric encryption key (S). In some examples, the symmetric encryption key is based on a shared common secret. A technique for determining this common secret may be as follows: determining a first node second private key based on at least the first node master private key and the generator value; determining a second node second private key based on at least the second node master private key and the generator value; The step of determining the common secret (CS) at the first node is based on the first node second private key and the second node second public key, and the step of determining the common secret (CS) at the second node is based on the second node second private key and the first node second public key. The first node second public key and the second node second public key are based on the first / second node master keys and a generator value, respectively.

[0074] The method for deriving keys based on a shared common secret is described in detail later in this specification.

[0075] <Cryptocurrency margin to a common address> To generate a bond in the first transaction 21 to a common address, the first node needs to determine the common address. In a pay to script hash (P2SH) system, this may be based on a public key (corresponding to the private key used for signing). In one example, this involves determining a first public key (P1) corresponding to a first private key (V1) of the first user 5 that should be known to the first node 5. This also involves determining a second public key (P2) of the second user 5, which may be determined by receiving the second public key (P2) from the second node 17, a third party, or a data store. The second public key (P2) does not necessarily have to be transmitted in a secure manner, but in some examples the second public key (P2) may be encrypted with a shared symmetric encryption key (S).

[0076] The cryptographic key bond amount (B1) may be an amount mutually agreed upon by the first and second users 5, 7. However, it is preferred that the cryptographic key bond amount (B1) is equal to the price of the maximum receivable number of digital content episodes in a digital content series. This ensures that the bond will be sufficient to pay for all episodes if the first user 5 decides to receive and watch all episodes. Thus, if a series has a number of episodes, n, and the price per episode is p, then the cryptographic key bond amount (B1) is n×p.

[0077] An example of a first transaction (A1) 21 transferring a cryptocurrency bond amount (B1) is shown in Tables 1 and 2 below.

[0078] [Table 1] First transaction (A1) [Table 1]

[0079] [Table 2] Redeem script for transaction (A1) [Table 2]

[0080] In this example, a first transaction (A1) 21 has an input from a previous blockchain transaction of a first user ("Alice") 5 (requiring the signature of the first user), and an output to a common address (23). In this example, the output is a hash based on a Redeem script that includes the public key of the first user (P1, "Alice's public key") and the public key of a second user (P2, "Bob's public key"). That is, redeeming the output of the first blockchain transaction (A1) 21 requires the signature of both the first user 5 with the first private key (V1) and the second user 7 with the second private key (V2).

[0081] The step of recording the first transaction (A1) 21 described above is illustrated in a method 100 performed by a first user 5 as shown in Figure 4, where the first node 15 sends a first data output (O1) via the communication network 8 to record the first transaction of the cryptocurrency bond amount from the first user 5 to a common address (23) on the blockchain 9.

[0082] <Generate a refund transaction> A second blockchain transaction 25 is then generated such that the cryptocurrency bond amount (B1) is returned after the specified time period has expired.

[0083] This may include the first node 15 generating a second transaction 25, including spending the cryptocurrency bond amount (B1) back to the first user 5 only after a specified time in the future. The specified time may include setting a lock time, expressed in Unix time, for the second transaction d days into the future.

[0084] An example of a second transaction (A2) 25 for refunding the cryptocurrency guarantee amount (B1) is shown in Table 3 below.

[0085] [Table 3] Second transaction (A2) [Table 3]

[0086] In this example, the second transaction (A2) 25 has an input from the first transaction (A1) 21. Unlocking the input from the common address (23) 23 requires both the signature of the first user with the first private key (V1) and the signature of the second user with the second private key (V2). In this example, the output refunds the cryptocurrency bond amount (np in this example) to the first user 5. The output is therefore based only on the hash of the first user's public key (P1, "Alice's public key"). That is, redeeming the output of the first blockchain transaction (A1) 21 only requires the signature of the first user 5 with the first private key (V1), since the first user 5 should be free to use their own refund cryptocurrency.

[0087] Importantly, the second transaction (A2) 25 is only valid after a specified time, which in this example is achieved by a lock time function that ensures that the transaction is only valid after a specified time, for example d days (expressed in Unix time).

[0088] The steps of recording the second transaction (A2) 25 are shown in Fig. 4 as steps 105, 107 performed by the first node 15 and steps 203, 205, 207 performed by the second node 17. The first node 15 co-signs 105 the second transaction with the first private key (V1) of the first user 5. This second transaction (A2) 25 is then sent 107 over the communication network 8 to the second node 17 to be signed with the second private key (V2). The second node 17 also receives 203 the second transaction (A2) 25. The second node 17 further co-signs 205 the second transaction (A2) 25 with the second private key (V2) of the second user 7. The second transaction (A2) 25, signed by both private keys, is then sent 207 to the blockchain 9 via the communications network 8, where it is validated after a specified time to refund the cryptocurrency guarantee amount (B1) if no other valid transactions (such as payment transaction 27) are sent before the specified time.

[0089] It should be understood that these steps may be performed in other orders. For example, the second node 17 may first sign the second transaction and then send it to the first node for signing. It is understood that either node may generate the second transaction (before signing) and either node may send the co-signed transaction to the blockchain 9. In other examples, the first and second nodes 15, 17 may send the transaction to other intermediate nodes, which in turn send the transaction to other nodes and / or to the blockchain 9.

[0090] <Re-request digital content and determine payment transaction> A method for reclaiming digital content and generating a payment transaction is described below with reference to FIG.

[0091] The second node 17, for each digital content episode (i), determines a corresponding episode secret (Si ) to decide the Episode Secret (S i ) can be used to identify episode (i) to those who know the secret, in particular the first user 5 and the second user 7. This can be useful to maintain privacy when information is sent to the blockchain 9.

[0092] The second node 17 transmits to the first node 17 an episode secret (S i ) 208. In this example, only the episode secrets of the next episode available to the first user 5 and the first node 15 are transmitted. Subsequent episode secrets are not revealed until the first node 15 has accessed the first episode. This ensures that episodes are accessed sequentially.

[0093] Episode Secret (S i ) 208, the second node 117 sends the episode secret (S i To maintain the secrecy of the episode secret (S i ) from the second node 17. i ) 108. The first node 15 then decrypts the encrypted message with the shared symmetric encryption key (S) to obtain the episode secret (S i ) is obtained.

[0094] The first node 15 stores an episode secret (S i) may be stored. If the specified time has not expired (i.e., is before day d), the method 100 includes sending 110, at the first node 15, a request over the communications network 8 to the second node 17 to provide the first digital content episode. The request involves a payment transaction 27 for the first episode, determined 120 at the first node, as described below.

[0095] <Determine payment transaction> Payment Transaction (E i ) 27, if valid, is used from the common address (23) (in particular the cryptocurrency bond amount (B1) therefrom) and therefore requires the signatures of both the first user 5 and the second user 7. i After determining the payment transaction (E i ) 27 and send it to a second node 17 to be co-signed before sending it to the blockchain 9.

[0096] The first node 15 first receives an episode secret (S i ) 121. This may involve using a hash function such as OP_HASG160 (where the input is hashed twice, once with SHA-256 and then with RIPEMD-160). It should be appreciated that other hash functions may be suitable.

[0097] Payment Transaction (E i ) 27 is in the form of P2SH in this example. i The step of determining the episode secret hash (H i ) and a second public key (P2) of the second user 7. i) indicates that this particular payment transaction contains an episode secret hash (H i ) and Episode Secret (S i )) access to a particular episode. Secondly, the second public key (P2) of the second user 7 ensures that only the second user 7 with the corresponding second private key (V1) can spend the payment.

[0098] Payment Transaction (E i The step of determining 120 the number of requests (B2) for the second node 7 further includes determining a cryptocurrency payment (B2) for the second node 7. In the case of the first episode, this payment is the price of the first episode. However, as the first user 5 generates further requests for subsequent episodes, the cryptocurrency payment (B2) will change based on the episodes requested. In a simple example, this may be the number of episodes multiplied by the price per episode.

[0099] In addition to the output to the second user 7, a payment transaction (E i ) 27 may include another output returned to the first user 5. This output returned to the first user 5 may represent change for the cryptocurrency guarantee amount (B1) returned to the first user. In one example, the cryptocurrency change amount (B3) to the first user 5 may be based on the cryptocurrency guarantee amount (B1) less the cryptocurrency payment amount (B2).

[0100] The method 100 then performs a payment transaction (E i ) 27 and then sends the payment transaction (E i ) 27 to the second node 17.

[0101] Payment Transaction (E i ) are shown in Tables 4 and 5.

[0102] [Table 4] Payment Transactions (E i ) [Table 4]

[0103] [Table 5] Output 1 Payment transaction (E i ) Redeem script [Table 5]

[0104] The inputs to this transaction include an unlock script that requires the signature of both the first private key (V1) of the first user 5 ("Alice's signature") and the signature of the second private key (V2) of the second user 7 ("Bob's signature"), because the payment transaction is being used from a common address (23).

[0105] “Output 1” shows the output of a cryptocurrency payment (B2) to a second user 7. This output can be redeemed by the Payment Redeem Script (RS1) shown in Table 5. Table 5 shows the output of the episode secret hash (H i ) and a second user's public key (P2) ("Bob's public key").

[0106] "Output 2" denotes the output which is the cryptocurrency change (B3) returned to the second user 7. Note that the output script is based on the first user's public key P1 (Alice's public key) since the first user should be free to use this cryptocurrency change (B3).

[0107] <Verify the payment transaction> The second node 17 receives 210 a request to provide the first digital content episode via the communications network 8. In response, the second node 17 further receives from the first node 15 a payment transaction (E i) is expected to be received.

[0108] Before agreeing to a request to provide the digital content episode, the second node may enter into a payment transaction (E i ) to verify.

[0109] The second node 17 is Episode Secret (S i ) to Episode Secret Hash (H i The second node then determines 121 the received payment transaction (E i ) contains the cryptocurrency payment (B2) to the second node 7 220. This may include verifying that the output value (such as the output value in “Output 1” in Table 4) is a correct value by verifying that the value is equal to the number of episodes requested multiplied by the price.

[0110] The step 220 of verifying determines whether the payment redeem script (RS1) contains the episode secret hash (H i ) and the second public key (P2). i ) output script (based on the Redeem script) in i ) and the corresponding hash of the known value (or a derivative of it) of the second public key (P2). This comparison ensures that the output script has the correct episode secret hash (H i ) and the second public key (P2), the second node 17 (and the second user 7) accepts the received payment transaction (E i ) can have bona fide credit.

[0111] The second node 17 receives payment transactions (E i ) 27 and send it to the blockchain 9 immediately, but the second user 7 may not wish to do so until closer to the specified time, since the first user 5 may generate further requests for further digital content episodes.

[0112] After successful verification, the second node 17 then provides the first node 15 with access to the requested episode, as well as a next episode secret so that the first node can request further content (which is the next episode).

[0113] <Determine the next episode secret> The second node 17 then searches for the next episode secret (S) of the next episode i+1 (which is the episode to be provided after episode (i)) in the digital content series until there are no more episodes in the series. i+1 ) from the data store 18. i+1 ) or generating a new secret. i+1 ) is the next episode secret hash (H i+1 ) is used to determine the next episode secret hash (H i+1 ) will be used in the next payment transaction if the first user 5 decides to generate a request for the next episode in the future.

[0114] Next Episode Secret (S i+1 ) may be provided to the first node 15 at the same time that the second node provides access to the currently requested digital content episode.

[0115] <Providing access to digital content> Payment Transaction (E iIf the shared key (S) 27 is verified, the second node 17 provides 230 access to the digital content episode to the first node 15. This can be accomplished in a number of ways. In one example, the second node 17 may encrypt the digital content episode with a shared symmetric encryption key (S) and transmit the encrypted digital content episode to the first node 15 over the communications network 8. In another example, the second node may provide the encrypted digital content episode in a data store 11 associated with the content server 3, such that the first node 15 can receive the encrypted episode from the data store 11 at a time appropriate for the first node 15. In yet another example, the second node 15 may provide an episode-specific encryption key to decrypt the episode.

[0116] In one example, the requested digital content episode (i) contains the next episode secret (S i+1 ) The concatenation may then be encrypted with a shared symmetric encryption key, and the second node 17 then provides access to the encrypted concatenation.

[0117] The second node 17 may then send a notification via the communications network 8 to the first node 15 indicating that the requested digital content episode (i) is available to be accessed.

[0118] Meanwhile, the first node 15 then accesses the encrypted concatenation (e.g., by downloading it from the data store 11 or directly from the second node 17, etc.) and decrypts it 140 with the shared symmetric encryption key. This means that the first node 15 obtains the digital content episode (i) and the next episode secret (S i+1 Importantly, this provides the next episode secret (S i+1 )) to the first user. The first node 15 stores the next episode secret (S i+1 ) can be stored 141.

[0119] It should be appreciated that in some alternatives, the next episode secret may be transmitted 223 from the second node 17 to the first node 15 at another time and is not concatenated with the digital content episode. This may involve transmitting the next episode secret (S i+1 ).

[0120] <Request next episode again> If the first user 5 wishes to watch the next episode i+1, the first node 15 may repeat steps 110 of sending a request for the digital content episode, step 120 of determining the next payment transaction, and step 130 of signing the next payment transaction, as described above. This involves storing the next episode secret (S i+1 ) and the corresponding determined next episode secret hash (H i+1 ) and the second node 15 repeats steps 210 of receiving the request and the next payment transaction, 220 of validating the next payment transaction, and 230 of providing access to the next episode.

[0121] These may be repeated until the entire digital content episode has been accessed by the first node 15, or when the specified time period d is approaching or has ended. In these circumstances, the second node 15 then performs the subsequent steps of effecting payment to the second user 7.

[0122] <Co-sign a payment transaction> Once all episodes in the digital content series have been accessed by the first node 15, the second user 7 may perform a final payment transaction (E iAlternatively, if the end of the specified time period is approaching, the second user 7 may co-sign the last payment transaction (E i )27''. More importantly, the payment transaction (E i ) is co-signed and the payment transaction (E i ) must be sent to the blockchain 9 before the specified time to ensure it is recorded.

[0123] Thus, the method 200 proceeds with the second node 17 executing the final payment transaction (E i ) 27″ and sending the co-signed payment transaction to the blockchain 9.

[0124] When a second user 7 wishes to spend the cryptocurrency payment (B2), the second node 17 receives the second user private key (V2) and the payment transaction (E i ) in the episode Secret Hash (H i ) corresponding episode secret (S i ) to unlock the transaction. This is shown in the unlock script in Table 6 below. The Redeem script in the format shown in Table 5 is sent by the second node 17 with the second user public key (P2) and the episode secret (S i Note that the episode secret (S i ) is the episode secret hash (H i ) is used to derive

[0125] [Table 6] Secondary users using cryptocurrency payments. [Table 6]

[0126] <Transformation> It will be understood by those skilled in the art that numerous variations and / or modifications may be made to the above-described embodiments without departing from the broad general scope of the present disclosure, The present embodiments are therefore considered in all respects to be merely illustrative and not restrictive.

[0127] In one exemplary variant, each payment transaction (E i ) may itself have a respective payment specification time before it is valid. For example, a payment specification time may be set for a payment transaction (E i ) may be a time (e.g., d-1 days) prior to the specified time (e.g., d days) of the second transaction (i.e., a refund transaction) such that the specified time (e.g., d days) prior to the second transaction.

[0128] Thus, in this variant, once the second node 17 verifies the payment transaction, it may immediately co-sign the payment transaction (Tx) and send it to the blockchain 9.

[0129] For the subsequent payment transactions, these subsequent payment transactions have their respective designated times (e.g., d-2 days) that are earlier than the designated times (e.g., d-1 days) of the preceding payment transactions. Thus, when the subsequent payment transactions are co-signed and sent to the blockchain 9, they precede the earlier payment transactions and the second (refund) transaction and are made valid. The advantage of this variation is that if the second node 17 has a failure at a time close to the designated time of the second (refund) transaction, the second user 7 will still receive the payment since the payment transaction has already been co-signed and sent to the blockchain 9.

[0130] <Shared symmetric key based on a shared common secret> A method for generating a common secret between two nodes is described below. The common secret may be used in the generation of cryptographic keys.

[0131] <Decide on a shared secret> The method allows for the generation of a common secret between two nodes without the need to transmit the common secret to and / or from any one of the nodes. Each node has an asymmetric cryptography pair (such as an elliptic curve cryptography pair), each pair including a master private key and a master public key. For example, the first node may have a master private key (V 1P ) and the master public key (P 1P ), and the second node may have a master private key (V 1E ) and the master public key (P 1E ). Each node's second private and public keys may be determined based on the master private key, the master public key, and the generator values. The generator values ​​(or messages used to derive the generator values) may be communicated to and / or from the nodes.

[0132] A common secret may be determined at each of the nodes based on the second private key and the public key. An example of determining a common secret between the first node and the second node is described below. Both the first and second nodes determine a generator value that is common to both nodes. The generator value may be received with the message or may be derived from the message.

[0133] At the first node, the common secret (CS) is (i) First node master private key (V 1P ) and the first node second private key (V 2P )and, (ii) Second node master public key (P 1E ) and the second node second public key (P 2E ) and is based on.

[0134] At the second node, the common secret (CS) is (iii) First node master public key (P 1P ) and the first node second public key (P 2P )and, (iv) Second node master private key (V 1E ) and the second node second private key (V 2E ) and is based on.

[0135] Therefore, the common secret is:

[0136] Common Secret (CS) = (V 2P ×P 2E )=(P 2P ×V 2E )

[0137] <Send information securely> The common secret can be used to encrypt information for secure transmission. For example, a symmetric key can be based on the common secret. Because both nodes have the same common secret, they can determine the same symmetric key that can be used to encrypt and decrypt information sent between the two nodes (e.g., over an insecure network).

[0138] <Processing equipment> As mentioned above, the first user 5 and the second user 7 are associated with the first node 15 and the second node 17, respectively. The first node 15 and the second node 17 may be electronic devices such as computers, tablet computers, mobile communication devices, computer servers, computer terminals, etc. Such electronic devices may include a processing device. Thus, the first node has a first processing device 23 and the second node 17 has a second processing device 23''. The electronic devices may also be associated with data stores 11, 18 and user interfaces. Examples of user interfaces include a keyboard, a mouse, a monitor, a touch screen display, etc. The blockchain 9 may also be associated with a number of processing devices 19.

[0139] 6 shows an example of a processing device 19, 23. The processing device 19, 23 includes a processor 1510, a memory 1520, and an interface device 1540, which communicate with each other via a bus 1530. The memory 1520 stores instructions and data for performing the above-mentioned methods 100, 200, and the processor 1510 executes the instructions (such as computer programs) from the memory 1520 to perform the methods 100, 200. The interface device 1540 may include a communication module that enables communication with the communication network 8 and, in some examples, with peripherals such as user interfaces and data stores 11, 18. It should be noted that the processing device 1510 may be an independent network element, but the processing device 1510 may be part of another network element. Furthermore, some functions performed by the processing device 19, 23 may be distributed among multiple network elements. For example, the first user 5 may be associated with multiple processing devices 23 (such as the first user's mobile communications device, a tablet, a desktop computer, a home media player, a television, etc.) and the steps of method 100 may be performed and distributed across more than one of these devices.

Claims

1. 1. A computer-implemented system configured to control the transmission and / or distribution of digital content, the system comprising: a first user associated with a bond amount in a common address; and usage from the common address is controlled by a first private key (V １ ) and a signature of a second private key of a second user, the system A first node associated with a first user, the first node having a first processing device, (A) sending a request to the second node over a communications network to provide a digital content episode from a digital content series; (B) determining a payment transaction to transfer a payment amount from the common address to the second user, the payment amount being based on a number of digital content episodes in the digital content series requested by the first user; (C) a first node that signs the payment transaction with the first private key and then transmits the payment transaction to the second node; and a second node associated with the second user, the second node having a second processing device, (I) receiving, via the communications network, the request from the first node to provide the digital content episode and the payment transaction signed with the first private key; (II) verifying the payment transaction, including verifying that the payment transaction includes the payment amount to the second user; and based on a result of the verification, the second processing device further: (III) providing access to the digital content episodes to be made available to the first node via the communications network; (IV) a second node configured to co-sign the payment transaction with the second private key of the second user and transmit the co-signed payment transaction to a blockchain; and A system including:

2. The first processing device is and further configured to request a next digital content episode from the digital content series by repeating steps (A) through (C); The second processing device is and further configured to receive the request and deliver the next digital content episode by repeating steps (I) to (III); The step (IV) of co-signing and sending the payment transaction to the blockchain is performed for a payment transaction having a number of digital content episodes including the next episode. The system of claim 1 .

3. The first user deposits the guarantee amount into the common address, and the first processing device:

3. The system of claim 1, configured to transmit a first data output via a communications network for recording on a blockchain a first transaction of the guarantee amount from the first user to the common address.

4. After a specified time, the guarantee amount is refunded without a transaction of the guarantee amount from the common address, and the first processing device: and co-signing a second transaction transferring the voucher amount from the common address to the first user with a first private key of the first user; The second processing device is co-signing the second transaction with the second private key, the second transaction co-signed with both the first private key and the second private key being sent to the blockchain and validated to refund the guarantee amount after the specified time; transmitting the co-signed payment transaction to the blockchain prior to the specified time; The system of claim 1 , further configured to:

5. The second processing device is and transmitting, via the communications network, an episode secret associated with the digital content episode from the digital content series that is available for request by the first user; The first processing device, receiving, via the communications network, the episode secret; determining an episode secret hash from the episode secret; Determining a payment transaction for transferring the payment amount to the second user includes the first processing device: the episode secret hash; and a second public key that is cryptographically paired with the second private key of the second user; and determining a payment redeem script based on the 5. The system of claim 1, wherein when the second processing device verifies the payment transaction, the second processing device is further configured to verify that the payment Redeem script is based on the episode secret hash and the second public key.

6. The second processing device is determining a next episode secret associated with a next digital content episode from said digital content series; determining a next episode secret hash from the next episode secret; In or after step (III), for transmitting the digital content episodes, the second processing device a second node configured to transmit a next episode secret to the first node via the communication network; The first processing device is receiving, via the communications network, the next episode secret; determining a next episode secret hash from the next episode secret; The corresponding payment transaction is the next episode secret hash; and The second public key; and The following payment Redeem script is based on 6. The system of claim 5, wherein when the second processing device verifies a next payment transaction, the second processing device is further configured to verify that the next payment Redeem script is based on the next episode secret hash and the second public key.

7. 7. The system of claim 1, wherein the payment transaction further comprises a transfer of a change amount from the common address to the first user, the change amount being based on the guarantee amount less the payment amount.

8. The second processing device is further configured to determine a common secret between the first node and the second node; To provide access to the digital content episodes over the communications network, the second processing device: encrypting one or more digital content episodes with a key based on the common secret to provide one or more encrypted digital content episodes; transmitting the one or more encrypted digital content episodes; The first processing device is determining a shared secret between the first node and the second node; receiving, via the communications network, the one or more encrypted digital content episodes; and further configured to decrypt the one or more encrypted digital content episodes with the key based on the common secret to provide the one or more digital content episodes. A system according to any one of claims 1 to 7.

9. The second processing device is and determining an encrypted message encrypted with a key based on the common secret based on the episode secret and / or the next episode secret; The first processing device is and determining the episode secret and / or the next episode secret by decrypting an encrypted message with a key based on the common secret. A system according to claim 8 dependent on claim 5.

10. The system comprises: determining a first node second private key based on at least the first node master private key and the generator value; determining a second node second private key based on at least a second node master private key and the generator value; and determining a secret common to the first node and the second node by determining the common secret at the first node based on the first node second private key and the second node second public key; determining the common secret at the second node based on the second node second private key and the first node second public key; the first node second public key and the second node second public key are based on at least the first / second node master key and the generator value, respectively; A system according to any one of claims 1 to 9.

11. 1. A computer-implemented method for receiving digital content, the method comprising: a first node associated with a first user receiving the digital content in exchange for a payment to a second user associated with a second node, the first user being associated with a bond amount at a common address, and any spend from the common address requires a signature of both a first private key of the first user and a second private key of the second user, the method comprising: (A) transmitting, via the communications network to the second node, a request to provide a digital content episode from a digital content series; (B) determining a payment transaction to transfer a payment amount from the common address to the second user, the payment amount being based on a number of digital content episodes in the digital content series requested by the first user; (C) signing the payment transaction with the first private key, then transmitting the payment transaction to the second node and having the second node verify the payment transaction; and based on the second node verifying that the payment transaction includes the payment amount, the method further comprises: (D) accessing the digital content episodes via the communications network.

12. 12. The method of claim 11, further comprising the step of requesting a next digital content episode from the digital content series by repeating steps (A) through (D).

13. The first user transmitting a first data output via a communications network to record on a blockchain a first transaction of the bond amount from the first user to the common address; The method according to claim 11 or 12, further comprising paying the guarantee amount to the common address by

14. After a designated time, the guarantee amount is refunded without a transaction of the guarantee amount from the common address, and the method further comprises:

14. The method of any one of claims 11 to 13, further comprising the step of co-signing a second transaction with the first private key of the first user to transfer the guarantee amount from the common address to the first user, wherein the co-signed second transaction co-signed with the second private key by the second user is sent to the blockchain and enabled to refund the guarantee amount after the specified time.

15. receiving, via the communications network, an episode secret associated with the digital content episode from the digital content series available for request by the first user; determining an episode secret hash from the episode secret; Further comprising: The payment amount to the second user in the payment transaction is: the episode secret hash; and a second public key that is cryptographically paired with the second private key of the second user; and The method of claim 11 , further comprising a payment Redeem script based on:

16. At or after step (D), the method further comprises: receiving, via the communications network, a next episode secret associated with the next digital content episode from the digital content series; The step of requesting the next episode from the digital content series includes determining a next episode secret hash from the next episode secret, and a corresponding next payment transaction is the next episode secret hash; and The second public key; and The method of claim 15, further comprising a next payment Redeem script based on:

17. 17. The method of claim 11, wherein the payment transaction further comprises a transfer of a change amount from the common address to the first user, the change amount being based on the guarantee amount less the payment amount.

18. determining a common secret between the first node and the second node; Accessing the digital content episodes via the communications network includes: receiving, via said communications network, an encrypted digital content episode; decrypting the encrypted digital content episode with a key based on the common secret to provide the digital content episode; 18. The method of any one of claims 11 to 17, comprising:

19. The step of determining a common secret between the first node and the second node comprises: determining a first node second private key based on at least the first node master private key and the generator value; determining a second node second private key based on at least a second node master private key and the generator value; Including, determining the common secret at the first node based on the first node second private key and the second node second public key; determining the common secret at the second node based on the second node second private key and the first node second public key; the first node second public key and the second node second public key are based on at least the first / second node master key and the generator value, respectively; 20. The method of claim 18.

20. The step of receiving the episode secret and / or the next episode secret includes:

19. A method according to claim 18 when dependent on claim 15, further comprising determining the episode secret and / or the next episode secret by decrypting an encrypted message with a key based on the common secret.

21. 1. A computer-implemented method of controlling the transmission and / or distribution of digital content, the method comprising: a first node associated with a first user receiving digital content in exchange for a payment to a second user associated with a second node, the first user being associated with a bond amount at a common address, and any spend from the common address requires a signature of both a first private key of the first user and a second private key of the second user, the method comprising: (I) receiving, via the communications network, from the first node a request to provide a digital content episode from a digital content series; (II) receiving a payment transaction signed with the first private key from the common address transferring a payment amount to the second user, the payment amount being based on a number of digital content episodes in the digital content series requested by the first user; (III) validating the payment transaction, the step including verifying that the payment transaction includes the payment amount to the second user; and and based on a result of the verification, the method further comprises: (IV) providing access to the digital content episodes to the first node via the communications network; (V) co-signing the payment transaction with the second private key of the second user and transmitting the co-signed payment transaction to the blockchain; The method further comprises:

22. Delivering a next digital content episode from said digital content series by repeating steps (I) to (IV), wherein step (V) is performed for a payment transaction having a number of digital content episodes including said next episode; 22. The method of claim 21 further comprising:

23. After a designated time, the guarantee amount is returned to the first user without a transaction of the guarantee amount from the common address, and the method further comprises: co-signing a second transaction with the second private key of the second user to transfer the guarantee amount from the common address to the first user, wherein the co-signed second transaction co-signed with the first private key by the first user is sent to the blockchain and enabled to refund the guarantee amount after the designated time; 23. The method of claim 21 or 22, wherein the step of sending the co-signed payment transaction to the blockchain is performed before the designated time.

24. transmitting, via the communications network, an episode secret associated with the digital content episode from the digital content series available for request by the first user; determining an episode secret hash from the episode secret; Further comprising: The step of validating the payment transaction may further comprise the step of: the episode secret hash; and a second public key that is cryptographically paired with the second private key of the second user; and 24. The method of claim 21, further comprising the step of verifying that the value is based on

25. determining a next episode secret associated with the next digital content episode from the digital content series; determining a next episode secret hash from the next episode secret; and wherein at or after step (IV), the method further comprises: transmitting a next episode secret to the first node via the communications network; When validating a next payment transaction of the next episode, the method further comprises: a Next Payment Redeem script for transferring the next payment amount to the second user, the next payment Redeem script comprising: the next episode secret hash; and The second public key; and 25. The method of claim 24, further comprising the step of verifying that the value is based on

26. 26. The method of any one of claims 21 to 25, wherein the payment transaction further comprises a transfer of a change amount to the first user from the common address to the first user, the change amount being based on the guarantee amount less the payment amount.

27. determining a common secret between the first node and the second node; Providing access to the digital content episodes over the communications network comprises: encrypting the digital content episode with a key based on the common secret; transmitting the encrypted digital content episode over the communications network; 27. The method of any one of claims 21 to 26, comprising:

28. The step of transmitting the episode secret and / or the next episode secret includes:

28. A method according to claim 27 when dependent on claim 24, further comprising determining an encrypted message encrypted with a key based on the common secret based on the episode secret and / or the next episode secret.

29. The step of determining a common secret between the first node and the second node comprises: determining a first node second private key based on at least the first node master private key and the generator value; determining a second node second private key based on at least a second node master private key and the generator value; Including, determining the common secret at the first node based on the first node second private key and the second node second public key; determining the common secret at the second node based on the second node second private key and the first node second public key; the first node second public key and the second node second public key are based on at least the first / second node master key and the generator value, respectively; 29. The method of claim 27 or 28.

Images