JP7281514B2 - Blockchain-enforced methods for control and distribution of digital content - Google Patents

Description

The present disclosure relates to systems and methods for payment and distribution of digital content from digital content series. This disclosure is applicable to digital rights management for online digital media, but is not limited in this respect.

A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, computer-based, distributed system composed of blocks. Also, a block is composed of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset between participants within a blockchain system and includes at least one input and at least one output. Each block contains the hash of the previous block, and blocks together form a chain, producing a permanent, immutable record of all transactions written to the blockchain since its inception. A transaction contains a small program known as a script embedded in its 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 stack-based scripting language.

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 a node performs this verification task on unused transactions (UTXO) by executing its own locking and unlocking scripts. If the execution of the lock and unlock scripts evaluates to true, the transaction is valid and the transaction is written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, the transaction must: i) be verified by the first node that received the transaction, and if the transaction is verified, the node will relay the transaction to other nodes in the network; ii) added to new blocks built by miners, and iii) mined, i.e. added to the public ledger of past transactions.

Blockchain technology is most widely known for its use in cryptocurrency implementations, but digital entrepreneurs are looking to implement new systems, including cryptocurrency security systems based on Bitcoin, and data that can be stored on blockchains. I'm starting to explore the use of both. It would be very advantageous if blockchain could be used for automated tasks and processes that are not limited to the realm of cryptocurrencies. Such solutions can take advantage of blockchains (e.g., permanent, tamper-resistant records of events, distributed processing, etc.) while being more diverse in their applications.

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 the terms of machine-readable transactions or agreements. Unlike traditional transactions, which can be described in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce results, and that can cause actions to be performed depending on those results. .

Another area of interest related to blockchains is the use of "tokens" (or "colored coins") to represent and transfer real-world entities via blockchains. Potentially confidential or secret items can be represented by tokens that have no discernible meaning or value. Tokens therefore act as identifiers that allow real-world items to be referenced from the blockchain.

Digital rights management relates to controlling digital media that is subject to copyright and includes control techniques that limit the use, modification and distribution of digital media. Digital media may include continuous content such as time-series content such as magazines, newspapers, podcasts, soap operas, television series, and the like.

Digital rights management implementations may involve managing copyrighted works through a large central system or multiple systems, with key exchanges to create trust between nodes associated with each user. Such systems can be difficult to administer, and ongoing access right maintenance can be difficult to achieve. In some alternatives, a trusted third party (such as a certificate authority) may be used to create the hierarchical structure. However, some of these systems present large single points of failure that can be vulnerable to attack.

The term "blockchain" is used herein to include any form of electronic, computer-based, distributed ledger. These include, but are not limited to, consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variants thereof. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. Although Bitcoin is referred to herein for convenience and descriptive purposes, the invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the invention. It should be noted that

Throughout this specification, the term "comprise" or variations such as "comprises" or "comprising" mean inclusion of the recited element, integer or step, or group of elements, integers or steps. It is understood, then, that it does not exclude any other elements, integers or steps, or groups of elements, integers or steps.

Any discussion of documents, acts, materials, apparatus, products, etc. contained herein may be based on the understanding that any or all of these items form part of the prior art basis or predate the priority of each claim of the present application. should not be construed as an acknowledgment that it was common general knowledge in the relevant field of this disclosure as existed in

The present invention provides a method and system as defined in the appended claims.

The present invention may provide control methods and corresponding systems configured to control the transmission and/or distribution of data. Transmission may be over or over a computer-implemented or communication network. The data can be digital content. The present invention may provide methods/systems that incorporate cryptography and/or encryption techniques to secure delivery/transmission of data. Accordingly, the present invention can provide enhanced security solutions for data communications.

As used herein, the term "episode" is sometimes used synonymously with the term "portion." However, the digital content transmitted, distributed, and/or controlled by the present invention is not limited to broadcast media episodes, logical chapters or episodes, or artistic content. The term "episode" in the specification and claims means a "portion" or "unit" or "amount" of digital content. Similarly, the term "series" as used herein in the sense of broadcast series simply means series. A series may simply be multiple pieces, groups or associations of digital content. "Series" is not necessarily limited to denoting sequential or chronological order. Furthermore, the invention is not limited with respect to the nature or format of the digital content. Digital content is not limited to entertainment media, but may relate to any kind of digital content.

The present invention may provide a system in which a first user is associated with a cryptocurrency amount at a common address. Cryptocurrencies are sometimes referred to as "guaranteed amounts." The address may be an address on the network. The address may be a blockchain address. Addresses may be derived from or associated with cryptographic keys. Usage from a common address may require a (digital) signature of at least the first private key (V ₁ ) of the first user and the second private key (V ₂ ) of the second user. This can be specified by using a given type of blockchain transaction. A transaction type may be part of or defined within a blockchain protocol.

a system,
A first node associated with a first user having a first processing unit,
(A) sending a request to said second node to provide digital content episode (i) from a digital content series over a communication network;
(B) determining and/or generating a blockchain transaction (E _i ) to transfer a cryptocurrency payment (B2) from a common address to said second user, said cryptocurrency payment (B2) being: Based on the number of episodes of digital content in the digital content series requested by the first user,
(C) a first node signing said payment transaction (E _i ) with said first private key (V ₁ ) and then sending said payment transaction (E _i ) to said second node;
a second node associated with the second user, having a second processing unit;
(I) from said first node for providing said digital content episode (i) and said payment transaction (E _i ) signed by said first private key (V ₁ ) over said communication network; receiving said request for
(II) configured to verify the payment transaction, including verifying that the payment transaction includes the cryptocurrency payment amount (B2) to the second user; The processing device further comprises:
(III) providing access to said digital content episode (i) to be made available to said first node via said communication network;
(IV) a second node configured to co-sign said payment transaction with said second private key ( _V2 ) of said second user and to send said co-signed payment transaction to a peer-to-peer distributed ledger;
system including.

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). The second processing device may be further configured to receive the request and distribute the next episode of digital content by repeating steps (I) to (III), co-signing the payment transaction and peer-to-peer processing. The step of sending to the distributed ledger (IV) is performed for payment transactions having a number of digital content episodes including said next episode.
Advantageously, one of the advantages provided by the present invention is that each portion of the digital content is encrypted together with (or associated with) a further or subsequent portion's encryption key. is. Use of the key provides technical proof that the piece of digital content has been decrypted. Accordingly, it can be determined that the digital content is being accessed, eg viewed or otherwise consumed/used.

In the system, the first user may deposit the cryptocurrency security amount at the common address, and the first processing device transfers the cryptocurrency from the first user to the common address via a communication network. configured to send a first data output (O ₁ ) to record a first transaction of a guaranteed amount (B1) on a peer-to-peer distributed ledger (hereinafter sometimes simply referred to as “blockchain”); be.

In the system, after a specified time, the cryptocurrency bond (B1) can be refunded without transaction of the cryptocurrency bond from the common address. Said first processing device is configured to co-sign a second transaction transferring said cryptocurrency security amount (B1) from said common address to said first user with said first user's first private key (V ₁ ). It can be further configured. The second processing device co-signs a second transaction with the second private key (V ₂ ) and co-signs with both the first private key (V ₁ ) and the second private key (V ₂ ). the signed second transaction is sent to the peer-to-peer distributed ledger and validated after a specified time to refund the cryptocurrency security amount (B1); and before the specified time, the co-signed second transaction. to the peer-to-peer distributed ledger.

In the system, the second processing device makes an episode secret associated with the digital content episode from the digital content series available for request by the first user over the communication network. It can be further configured to transmit (S _i ). The first processing unit may be further configured to receive the episode secret (S _i ) via the communication network and determine an episode secret hash (H _i ) from the episode secret (S _i ). Determining a payment transaction (E _i ) that transfers said cryptocurrency payment amount (B2) to said second user comprises: said first processing unit combining said episode secret hash (H _i ) with said second user's a second public key (P ₂ ) which is cryptographically paired with said second private key (V ₂ ); and further configured to determine a payment Redeem script (SR1). When the second processing device verifies the payment transaction (E _i ), the second processing device determines that the payment Redeem script (RS1) is the episode secret hash (H _i ) and the second public key (P _{2 )} . ).

In the system, the second processing device determines a next episode secret (S _{i+1 ) associated with the next digital content episode (S i+1 )} from the digital content series; It may be further configured to determine a next episode secret hash (H _i+1 ) from (S _i ), wherein at or after step (III) of transmitting said digital content episode, said second processing device comprises: It is further arranged to transmit the next episode secret (S _i+1 ) to the first node via the network. The first processing unit is further configured to receive the episode secret (S _i+1 ) via the communication network and determine a next episode secret hash (H i+ ₁ ) from the episode secret (S _i+1 ). good. The corresponding next payment transaction (E _i+1 ) includes the next payment Redeem script (RS2) based on said next episode secret hash (H _i+1 ) and said second public key (P ₂ ). When the second processing device verifies the next payment transaction (E _i+1 ), the second processing device determines that the next payment Redeem script (RS2) is the next episode secret hash (H _i+1 ) and the second It is further configured to verify that it is based on the public key (P ₂ ).

In said system, said payment transaction (E _i ) further comprises the transfer of a cryptocurrency change amount (B3) to said first user from said common address to said first user, said cryptocurrency change amount ( B3) is based on said cryptocurrency security amount (B1) less by said cryptocurrency payment amount (B2).

In the system, the second processing unit 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 communication network comprises: the second processing device encrypting one or more digital content episodes with a key based on the common secret; Providing a plurality of encrypted digital content episodes and transmitting the one or more encrypted digital content episodes. The first processing unit determines a common secret between the first node and the second node, receives the one or more encrypted digital content episodes via the communication network, Or it may be further configured to decrypt a plurality of encrypted digital content episodes with a key based on said common secret to provide said one or more digital content episodes.

In the system, the second processing unit determines an encrypted message based on the episode secret (S _i ) and/or the next episode secret (S _i+1 ) encrypted with a key based on a common secret. It can be further configured as follows. The first processing unit is further configured to determine the episode secret (S _i ) and/or the next episode secret (S _i+1 ) by decrypting an encrypted message with a key based on the common secret. good

A computer-implemented method of receiving digital content, wherein a first node associated with a first user receives the digital content in exchange for payment to a second user associated with a second node; A first user is associated with a cryptocurrency security amount (B1) at a common address, and usage from said common address includes said first user's first private key (V ₁ ) and said second user's second private key ( V ₂ ), the method comprising:
(A) sending a request to provide digital content episode (i) from a digital content series to said second node via said communication network;
(B) determining a payment transaction (E _i ) for transferring a cryptocurrency payment (B2) from said common address to said second user, said cryptocurrency payment (B2) being transferred from said based on the number of digital content episodes in said digital content series requested by a first user;
(C) signing said payment transaction (E _i ) with said first private key (V ₁ ), and then transmitting said payment transaction (E _i ) to said second node, causing a node to validate said payment transaction;
Based on the second node verifying that the payment transaction includes the cryptocurrency payment amount (B2), the method includes:
(D) accessing said digital content episode (i) via said communication network.

The method may further comprise requesting a next digital content episode from the digital content series by repeating steps (A) through (D).

The method comprises: for the first user, via a communication network, to record a first transaction of the cryptocurrency security amount (B1) from the first user to the common address on a peer-to-peer distributed ledger; The step of sending data output (O1) may further comprise paying said cryptocurrency security deposit (B1) to said common address as a deposit.

In another example of said method, after a specified time, said cryptocurrency security amount (B1) is refunded without transaction of said cryptocurrency security amount (B1) from said common address, said method comprising: co-signing, with said first private key (V ₁ ) of one user, a second transaction transferring said cryptocurrency security amount (B1) from said common address to said first user, said second user A co-signed second transaction co-signed with said second private key ( _V2 ) by is sent to said peer-to-peer distributed ledger and is effective after said specified time to refund said cryptocurrency security amount (B1). is performed.

The method receives an episode secret (S _i ) associated with the digital content episode available for request by the first user from the digital content series via the communication network. and determining an episode secret hash (H _i ) from the episode secret (S _i ). Said cryptocurrency payment amount (B2) to said second user in said payment transaction (E _i ) consists of said episode secret hash (H _i ) and said second user's second private key (V ₂ ) and a payment Redeem script (SR1) based on a second public key (P ₂ ) that is a cryptographic pair with .

In the method, in step (D) or thereafter, the method includes, via the communication network, a next episode secret associated with the next digital content episode (S _i+1 ) from the digital content series. receiving (S _i+1 ). Requesting the next episode from the digital content series includes determining a next episode secret hash (H i+1 ) from the next digital content episode (S _{i+ 1} ), and a corresponding next payment. Transaction (E _i+1 ) includes a next payment Redeem script (RS2) based on said next episode secret hash (H _i+1 ) and said second public key (P ₂ ).

In the method, the payment transaction (E _i ) may further comprise transferring a cryptocurrency change amount (B3) from the common address to the first user, wherein the cryptocurrency change amount (B3) is transferred from the Based on the cryptocurrency security amount (B1) less the cryptocurrency payment amount (B2).

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

Upon receipt of said episode secret (S _i ) and/or said next episode secret (S _i+1 ), said method decrypts an encrypted message with a key based on said common secret, whereby said episode secret (S _i ), and/or determining the next episode secret (S _i+1 ).

A computer-implemented method of controlling distribution of digital content, wherein a first node associated with a first user receives digital content in exchange for payment to a second user associated with a second node. , said first user is associated with a cryptocurrency security amount (B1) at a common address, and use from said common address includes said first user's first secret key (V ₁ ) and said second user's second secret Requires both signatures of the key (V ₂ ), the method comprising:
(I) receiving a request from said first node via said communication network to provide digital content episode (i) from a digital content series;
(II) receiving a payment transaction (E _i ) signed with said first private key (V ₁ ) transferring a cryptocurrency payment amount (B2) from said common address to said second user, said cryptocurrency payment amount (B2) is based on the number of digital content episodes in said digital content series requested by said first user;
(III) verifying the payment transaction, comprising verifying that the payment transaction includes the cryptocurrency payment amount (B2) to the second user; Based on the results, the method includes:
(IV) providing access to said digital content episode to said first node via said communications network;
(V) co-signing said payment transaction with said second private key (V ₂ ) of said second user and sending said co-signed payment transaction to said peer-to-peer distributed ledger.

The method comprises delivering a next digital content episode from the digital content episode by repeating steps (I) to (IV), wherein step (V) comprises a digital content episode containing the next episode. a step performed for payment transactions having a number of content episodes.

In one example of the method, after a specified time, the cryptocurrency bond (B1) may be refunded to the first user without transaction of the cryptocurrency bond from the common address. Accordingly, said method comprises co-signing, with said second private key (V ₁ ) of said second user, a second transaction transferring said cryptocurrency security amount (B1) from said common address to said first user. wherein the co-signed second transaction, co-signed by the first user with the first private key (V ₁ ), is transmitted to the peer-to-peer distributed ledger, after the specified time, Enabled to refund said cryptocurrency security deposit (B1). Further, the step of sending the co-signed payment transaction to the peer-to-peer distributed ledger is performed before the designated time.

The method transmits an episode secret (S _i ) associated with the digital content episode available for request by the first user from the digital content series over the communication network. and determining an episode secret hash (H _i ) from the episode secret (S _i ). The step of validating said payment transaction (E _i ) comprises: a corresponding payment Redeem script (RS1) transferring said cryptocurrency payment amount (B2) to said second user, said episode secret hash (H _i ); and a second public key ( _P2 ) that is cryptographically paired with said second private key ( _V2 ) of said second user.

The method includes determining a next episode secret (S _i+1 ) associated with a next digital content episode (S _{i +1} ) from a digital content series; determining an episode secret hash (H _i+1 ). In step (IV) or after, the method may further comprise transmitting a next episode secret (S _i+1 ) to the first node via the communication network. When verifying a next payment transaction for the next episode, the method further includes adding a next payment Redeem script (RS2) that transfers the next cryptocurrency payment amount to the second user to the next episode secret hash (H _i+1 ) and verifying that it is based on the second public key (P ₂ ).

In the method, the payment transaction (E _i ) may further comprise the transfer of a cryptocurrency change amount (B3) to the first user from the common address to the first user, wherein the cryptocurrency change amount is Amount (B3) is based on said cryptocurrency security amount (B1) less said cryptocurrency payment amount (B2).

The method may further comprise determining a common secret between the first node and the second node. Providing access to the digital content episode over the communication network comprises encrypting the digital content episode with a key based on the common secret; and sending the modified digital content episode.

In the method, the step of transmitting the episode secret (S _i ) and/or the next episode secret (S _i+1 ) comprises: 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 based on.

Any of the embodiments of the invention described above may include a method of determining a secret common to first and second nodes and/or a system configured to perform the method. The method includes:
determining a first node second secret key based on at least the first node master secret key and the generator value;
determining a second node second secret key based on at least the second node master secret key and the generator value;
(or the system may be operable to perform the above steps),
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; 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 derived from a message. Generator values can be derived from metadata stored in blockchain transactions (Tx).

Apparatus having a processing unit for performing any one of the above methods.

A computer program product comprising machine-readable instructions that cause a processing device to perform any one of the methods described above.

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. Any feature described in relation to the system of the invention may be applied to the method of the invention, and vice versa.

Examples of the disclosure are described with reference to the following drawings.

1 is a schematic diagram of an exemplary system for distributing digital content; FIG.

Fig. 3 shows a transaction between a first user, a second user and a common address;

1 is a flowchart of a computer-implemented method of distributing and receiving digital content.

Fig. 3 is a flowchart of a computer-implemented method of initializing and generating a refund transaction;

1 is a detailed flowchart of a computer-implemented method of distributing and receiving digital content according to an example;

1 shows a simplified example of a processing device;

<Overview>
Systems, apparatus, 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. FIG. 1 shows a system 1 comprising a first node 15 associated with a first user 5 communicating with a second node 17 associated with a second user 7 via a communication network 8 . In this example, a first user 5 can request to receive digital content at a first node 15 and a second user provides access to the digital content via a second node 17 . The second node 17 transmits the digital content from the first data store 18 to the first node 15 and transmits the digital content in the second data store 11 associated with the content server 3 to the first node 17 via the communication network 8 . Access to digital content may be provided in a number of ways, including making it available to node 15 .

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 . Blockchain 9 may be associated with one or more processing units 19 to receive and record transactions. One example of a peer-to-peer distributed ledger includes blockchain, which is a distributed ledger of transactions (Txs) based on the Bitcoin protocol. Accordingly, the processing device 19 associated with the ledger may be a processing device used by or associated with a "miner".

Referring to FIG. 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 requests a deposit to provide credit that the second user 7 will be paid for the digital content.

To provide a security deposit, first user 5 may perform a first transaction 21 to transfer a cryptocurrency security deposit (B1) to common address 23 . The common address 23 may be a P2SH (pay-to-script-hash) according to the Bitcoin protocol, and the use from the common address 23 consists of the first private key (V ₁ ) of the first user 5 and the second user 7 requires both signatures of the second private key (V ₂ ) of . This means that transactions 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 security deposit will not be used without approval from both parties. It is understood that alternative multi-signature methods may be used to authorize transactions from common address 23 .

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

Therefore, if a competing transaction using a cryptocurrency bond from a common address is broadcast before the specified time, the competing transaction becomes a valid transaction. It is in the interest of the second user 7 to broadcast valid conflicting transactions after a specified time. After this, the cryptocurrency guarantee 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 in which the second user 7 is paid.

A simple example of how to distribute digital content, including the generation of payment transactions 27, is described below with reference to FIG. FIG. 3 shows respective methods 100, 200 performed by the first node 15 and the second node 17. FIG.

When the first user 5 wishes to receive a digital content episode from the digital content series, the first node 15 is used to generate a request for the digital content. A first node 15 (which may be a computer, mobile communication device, television, etc.) sends a request to provide a digital content episode to a second node 15 via communication network 8 (110). A first processor 23 is included.

The first node 15 further determines 120 a payment transaction (E _i ) 27 that transfers the cryptocurrency payment amount (B2) from the common address 23 to the second user 7 . 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 previously requested (and received) but no payment received by the second user 7 . In a simplified example, the second payment (B2) may be the number of episodes requested (i) multiplied by the price (p) of each episode.

The first node 15 then signs 130 the payment transaction (E _i ) 27 with the first private key (V ₁ ). The payment transaction (E _i ) 27 is then sent to the second node 17 . This is still valid because the payment transaction (E _i ) is only signed with the first private key (V ₁ ) and requires the second node 17 to sign with the second private key (V ₂ ). not a valid transaction.

Considering the second node 17 associated with the second user 7, the second node has a second processing device 23', which may include a mainframe computer, a desktop computer, or the like. A second processing unit of the second node 17 provides the digital content episode and the payment transaction ( _Ei ) signed with the first private key ( _V1 ) from the first node 15 via the communication network 8. receive 210 a request for

Before the second node 17 makes 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 can receive payment. Accordingly, the second node 17 then validates 220 the payment transaction (E _i ) 27 . This involves verifying that the payment transaction (E _i ) 27 contains the cryptocurrency payment amount (B2) to the second user 7 . In a practical example, this may involve determining the correct amount of cryptocurrency and the correct destination.

Upon verification of the payment transaction ( _Ei ) (that is, in particular that the second user 7 is paid), the second node 17 is then made available to the first node 15 via the communication network 8. provide access 230 to digital content episodes. It also authorizes 140 the first node to access the digital content episode.

To execute the payment transaction (E _i ) 27, the second node 17 then co-signs 240 the payment transaction (E _i ) 27 with the second private key (V ₂ ) of the second user 5 and Send the signed payment transaction to the blockchain 9. Therefore, the cryptocurrency payment amount (B2) is transferred from the common address 23 with the cryptocurrency security amount (B1).

In some examples, first user 5 may have the opportunity to request and receive additional episodes. Accordingly, the second user 17 may have the opportunity to receive more payouts (from further episodes provided to the first user 5) and thus refund the security deposit for the second transaction 25 at a specified time. The step 240 of co-signing and sending the co-signed payment transaction to blockchain 9 can be delayed until a nearer time. An example of delivering the next episode is described below.

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 payout amount is adjusted to take into account the next episode (and previous episodes in the series that have not been paid for). The second node 17 similarly receives the request and delivers the next episode of digital content by repeating steps 210-230 described above.

Accordingly, the second node 17 has two payment transactions: a first payment transaction (E _i ) 27 includes a cryptocurrency payment amount dependent on the digital content episode, and a second payment transaction (E _i+1 ) 27 ′ , including cryptocurrency payments up to and including the next digital content episode. Since the second user 7 is interested in receiving the maximum payment amount, the second node 17 sends the co-signed payment transaction 27' containing the payment containing the payment for the next episode, the second payment transaction (E _i+1 ). 240 just sign and send 27'. Accordingly, the first payment transaction (E _i ) 27 can be discarded by the second node 17 .

The present disclosure may provide systems for communicating, transmitting, and/or distributing digital content with lower trust levels. For example, the first user's 5 and/or second user's 7 exposure to fraud can 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 is reduced to one piece of digital content (because the remaining amount is refunded). It can be the price of an episode.

The present disclosure can also provide systems that do not rely on other third parties and hierarchies, such as certificate authorities, which can be vulnerable to single points of failure and attacks. The use of cryptography enhances the security of the transmission/control arrangement provided by the present invention.

Detailed examples are provided below for illustrative purposes.

<Initialization - Encryption protocol>
A first node 5 and a second node 7 establish secure communication 101 , 201 with each other over a communication network 8 . This may involve cryptographic communication with a shared symmetric cryptographic key (S). In some examples, a symmetric cryptographic key is based on a shared common secret. Techniques for determining this common secret may be as follows:
determining a first node second secret key based on at least the first node master secret key and the generator value;
determining a second node second secret key based on at least the second node master secret key and the generator value;
Determining a common secret (CS) at the first node comprises determining a common secret (CS) at the second node based on the first node second private key and the second node second public key. Based on the 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 key and generator value, respectively.

Methods for deriving keys based on shared common secrets are detailed later in this specification.

<Cryptocurrency Deposit to Shared Address>
In order to generate a bond within the first transaction 21 to the common address, the first node needs to determine the common address. In P2SH (pay to script hash) systems, this can be based on the public key (corresponding to the private key used for signing). In one example, this involves determining the first public key (P ₁ ) corresponding to the first private key (V ₁ ) of the first user 5 which should be known to the first node 5 . This also includes determining the second public key ( _P2 ) of the second user 5, which can be determined by receiving the second public key ( _P2 ) from the second node 17, a third party, or a data store. include. The second public key ( _P2 ) need not necessarily be transmitted in a secure manner, but in some examples the second public key ( _P2 ) is encrypted with a shared symmetric encryption key (S). good.

The cryptographic key deposit amount (B1) may be an amount mutually agreed upon by the first and second users 5,7. However, the cryptographic key deposit amount (B1) is preferably equivalent to the price of the maximum number of digital content episodes that can be received in the digital content series. This ensures that the deposit is sufficient to pay for all episodes should the first user 5 decide to receive and watch all episodes. Thus, if a series has n episodes and the price per episode is p, then the cryptocurrency security amount (B1) is n×p.

An example of a first transaction (A ₁ ) 21 transferring a cryptocurrency security amount (B1) is shown in Tables 1 and 2 below.

[Table 1] First transaction (A ₁ )

[Table 2] Redeem script for transaction (A ₁ )

In this example, the first transaction (A ₁ ) 21 is the input (requiring the first user's signature) from the previous blockchain transaction of the first user (“Alice”) 5, to the common address (23). has an output of In this example, the output is a hash based on the Redeem script containing the first user's public key (P ₁ , "Alice's public key") and the second user's public key (P ₂ , "Bob's public key"). is. In other words, redeeming the output of the first blockchain transaction (A ₁ ) 21 is the first user 5 with the first private key (V ₁ ) and the second user 5 with the second private key (V ₂ ). Requires signatures from both users 7 .

The steps of recording the first transaction (A ₁ ) 21 described above are shown in method 100 performed by first user 5, as shown in FIG. Here, the first node 15 via the communication network 8 to record the first transaction of the cryptocurrency security amount from the first user 5 to the common address (23) on the blockchain 9. to transmit the first data output (O1).

<Generate Refund Transaction>
A second blockchain transaction 25 is then generated such that the cryptocurrency security amount (B1) is refunded after the specified time has expired.

This is the step of the first node 15 generating a second transaction 25, spending back to the first user 5 the cryptocurrency security amount (B1) only after a specified time in the future. can include steps including The specified time may include setting a lock time for the second transaction d days in the future expressed in Unix time.

An example of the second transaction ( _A2 ) 25 for refunding the cryptocurrency security amount (B1) is shown in Table 3 below.

[Table 3] Second transaction (A ₂ )

In this example, the second transaction (A ₂ ) 25 has input from the first transaction (A ₁ ) 21 . Unlocking the input from the common address (23) 23 requires both the first user's signature with the first private key (V ₁ ) and the second user's signature with the second private key (V ₂ ). do. In this example, the output refunds the first user 5 the cryptocurrency security deposit (np in this example). Therefore, the output is based only on the hash of the first user's public key (P ₁ , “Alice's public key”). That is, redeeming the output of the first blockchain transaction (A ₁ ) 21 requires the first private key (V ₁ ) requires only the signature of the first user 5.

Importantly, the second transaction (A ₂ ) 25 is valid only after a specified time. The specified time is achieved, in this example, by a lock time function that allows transactions to be valid only after the specified time. For example, d days (expressed in Unix time).

The steps of recording the second transaction (A ₂ ) 25 are shown in FIG. The first node 15 co-signs 105 the second transaction with the first private key (V ₁ ) of the first user 5 . This second transaction (A ₂ ) 25 is then sent 107 over the communication network 8 to the second node 17 to be signed with the second private key (V ₂ ). The second node 17 also receives 203 a second transaction (A ₂ ) 25 . Additionally, the second node 17 co-signs 205 the second transaction (A ₂ ) 25 with the second private key (V ₂ ) of the second user 7 . A second transaction (A ₂ ) 25 signed by both private keys is then transmitted 207 via communication network 8 to blockchain 9 where other Enabled after the specified time to refund the cryptocurrency security amount (B1) if no valid transaction is submitted before the specified time.

It should be appreciated 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 any node can generate a second transaction (before signing) and any node can send the co-signed transaction to the blockchain 9 . In other examples, the first and second nodes 15, 17 may send transactions to other intermediate nodes, which send the transactions to other nodes and/or the blockchain 9.

<Request digital content and determine payment transaction>
A method of re-requesting digital content and generating payment transactions is described below with reference to FIG.

The second node 17 determines for each digital content episode (i) a corresponding episode secret (S _i ). The episode secret (S _i ) can be used to identify the episode (i) to those who know the secret, especially the first user 5 and the second user 7 . This can be useful for maintaining privacy when information is sent to blockchain 9 .

The second node 17 sends 208 the episode secret (S _i ) of the first digital content episode in the digital content series to the first node 17 . In this example only the episode secrets of the following episodes 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 access to the first episode. This ensures that episodes are accessed sequentially.

Upon transmitting 208 the episode secret (S _i ), the second node 117 encrypts the episode secret (S _i ) with a shared symmetric encryption key (S) to keep the episode secret (S _i ) confidential. may generate and send an encrypted message by The first node 15 then receives 108 an encrypted message containing the episode secret (S _i ) from the second node 17 . The first node 15 then decrypts the encrypted message with the shared symmetric encryption key (S) to obtain the episode secret (S _i ).

The first node 15 may store the episode secret (S _i ) in a data store until the first user 5 accesses the first digital content episode. Assuming that the specified time has not expired (i.e., before d days), method 100 instructs first node 15 to provide a first digital content episode over communications network 8 to a second digital content episode. It includes a step 110 of sending the request to node 17 . This request is accompanied by a payment transaction 27 for the first episode determined 120 at the first node described below.

<Determine payment transaction>
The payment transaction (E _i ) 27, if valid, is used from the common address (23) (in particular, the cryptocurrency security amount (B1) therefrom) and is therefore signed by both the first user 5 and the second user 7. need. Therefore, after determining the payment transaction (E _i ) 27 , the first node 15 signs the payment transaction (E _i ) 27 to the second node 17 for co-signing before sending it to the blockchain 9 . need to send.

The first node 15 first determines 121 the episode secret hash (Hi) from the episode secret (S _i ). This may involve using a hash function such as OP_HASG160 (where the input is hashed twice, by SHA-256 and then by RIPEMD-160). It should be appreciated that other hash functions may be suitable.

Payment transactions (E _i ) 27 are in the form of P2SH in this example. Therefore, the step of determining the payment transaction (E _i ) 27 is a payment Redeem script (RS1) based in this example on the episode secret hash (H _i ) and the second public key (P ₂ ) of the second user 7. Further comprising determining a Redeem script. Including the Episode Secret Hash (H _i ) in the Redeem script ensures that this particular payment transaction is associated with access to a particular Episode (associated with the Episode Secret Hash (H _i ) and Episode Secret (S _i )). can be used as proof of Second, the second public key (P ₂ ) of the second user 7 ensures that only the second user 7 with the corresponding second private key (V ₁ ) can use the payment.

Determining 120 the payment transaction (E _i ) 27 further comprises determining the cryptocurrency payment amount (B2) of the second node 7 . For 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 amount (B2) changes based on the requested episodes. In a simple example, this could be the number of episodes multiplied by the price per episode.

In addition to outputs to the second user 7 , the payment transaction (E _i ) 27 may include other outputs returned to the first user 5 . This output returned to the first user 5 may represent the cryptocurrency security amount (B1) change returned to the first user. In one example, the cryptocurrency change amount (B3) to the first user 5 may be based on the cryptocurrency bond amount (B1) less the cryptocurrency payment amount (B2).

The method 100 then signs the payment transaction (E _i ) 27 with the first private key (V ₁ ) and subsequently signs the payment transaction (E _i ) 27 to have the second node 17 verify the payment transaction. 27 to the second node 17 .

An example of a payment transaction (E _i ) is shown in Tables 4 and 5.

[Table 4] Payment transaction (E _i )

[Table 5] Redeem script for output 1 payment transaction (E _i )

The inputs to this transaction are the signature of the first private key (V ₁ ) of the first user 5 ("Alice's signature") and the Include an unlock script that requires both signatures of the second private key (V ₂ ) (“Bob's signature”).

"Output 1" indicates the output of the cryptocurrency payment (B2) to the second user 7; This output can be redeemed by the Payment Redeem Script (RS1) shown in Table 5. Table 5 is based on the episode secret hash (H _i ) and the second user public key (P ₂ ) (“Bob's public key”) as described above.

"Output 2" indicates an output that 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 P ₁ (Alice's public key), since the first user should be free to use this cryptocurrency change amount (B3).

<Verify payment transaction>
A second node 17 receives 210 a request to provide a first episode of digital content via communication network 8 . Correspondingly, the second node 17 is also expected to receive from the first node 15 a payment transaction (E _i ) signed with the first private key (V ₁ ).

Before agreeing to the request to provide the digital content episode, the second node verifies the payment transaction (E _i ) so that the first user 7 can have credit for them to receive the payment.

The second node 17 determines 121 an episode secret hash (H _i ) from the episode secret (S _i ). This may involve using a hash function in the same manner as the first node 15 . The second node then verifies 220 that the received payment transaction (E _i ) contains the cryptocurrency payment amount (B2) to the second node 7 . This ensures that the output value (such as the output value in "Output 1" in Table 4) is the correct value by verifying that the value is equal to the number of episodes requested multiplied by the price. can include verifying that

Verifying 220 may further include verifying that the payment Redeem script (RS1) is based on the episode secret hash (H _i ) and the second public key (P ₂ ). It converts the output script (based on the Redeem script) in the received payment transaction (E _i ) to the known values (or derivatives thereof) of the episode secret hash (H _i ) and the second public key (P ₂ ). ) with the corresponding hash of . If this comparison indicates that the output script matches the expected Redeem script with the correct episode secret hash (H _i ) and second public key (P ₂ ), then second node 17 (and second user 7) , may have credit for the bona fide of the received payment transaction (E _i ).

While the second node 17 can sign the payment transaction (E _i ) 27 and send it immediately to the blockchain 9, the second user 7 does not want the first user 5 to generate further requests for further digital content episodes. I can, so I won't try to do that until it's close to the designated time.

After successful verification, the second node 17 then sends the next episode secret to the first node so that it can request access to the requested episode and further content (which is the next episode). to node 15.

<Determine the next episode secret>
The second node 17 then selects the next episode 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. Determine 221 the secret (S _i+1 ). This may involve retrieving the next episode secret (S _i+1 ) from the data store 18 or generating a new secret. The next episode secret (S _i+1 ) is used to determine the next episode secret hash (H _i+1 ). 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.

The next episode secret (S _i+1 ) can be provided to the first node 15 at the same time the second node provides access to the currently requested digital content episode.

<Provide access to digital content>
Once the payment transaction (E _i ) 27 is verified, the second node 17 provides 230 access to the digital content episode to the first node 15 . This can be achieved in a number of ways. In one example, second node 17 may encrypt the digital content episode with a shared symmetric encryption key (S) and transmit the encrypted digital content episode to first node 15 via communications network 8 . In another example, the second node may provide encrypted digital content episodes in data store 11 associated with content server 3 . First node 15 is thereby able to receive encryption episodes from data store 11 at a time appropriate for first node 15 . In yet another example, second node 15 may provide an episode-specific encryption key to decrypt the episode.

In one example, the requested digital content episode (i) can be concatenated with 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.

Second node 17 then sends a notification to first node 15 via communications network 8 indicating that the requested digital content episode (i) is available for access. good.

Meanwhile, the first node 15 then accesses the encrypted concatenation (eg, by downloading from the data store 11 or directly from the second node 17, etc.) and decrypts 140 with the shared symmetric encryption key. This provides the digital content episode (i) and the next episode secret (S _i+1 ) at the first node 15 . Importantly, this provides the first user with digital content episodes for consumption and for means of obtaining the next episode (ie, the next episode secret (S _i+1 )). The first node 15 may store 141 the next episode secret (S _i+1 ) for later use.

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 other times and not concatenated with the digital content episode. This may involve sending the next episode secret (S _i+1 ) as a separate encrypted message over the communication network.

<request next episode>
If the first user 5 wishes to watch the next episode i+1, the first node 15 performs step 110 of sending a request for the digital content episode, step 120 of determining the next payment transaction, and next , step 130 of signing the payment transaction can be repeated. This can be done with the next episode secret (S _i+1 ) and the corresponding determined next episode secret hash (H _i+1 ). The second node 15 also repeats steps 210 of receiving the request and the next payment transaction, verifying 220 the next payment transaction, and providing 230 access to the next episode.

These may be repeated until the entire digital content episode has been accessed by the first node 15 or when the specified time d days is nearing or ending. In these situations, the second node 15 then performs the subsequent steps of making payment to the second user 7 .

<Co-signing payment transactions>
When all the episodes in the digital content series have been accessed by the first node 15, there are no further payment transactions 27'', so the second user 7 has to wait until the last payment transaction to receive payment. Attempt to co-sign (E _i ) 27''. Alternatively, if the end of the specified time period is approaching, the second user 7 is unlikely to generate further requests, so the second user 7 may contribute to the final payment transaction (E _i ) 27''. try to sign More importantly, the payment transaction (E _i ) is co-signed and signed at a specified time to ensure that the payment transaction (E _i ) is recorded before the second transaction (the refund transaction) takes effect. must be sent to blockchain 9 before.

Accordingly, the method 200 proceeds to step 240 in which the second node 17 co-signs the final payment transaction (E _i ) 27 ″ with the second private key (V ₂ ) and transmits the co-signed payment transaction to the blockchain 9 . including.

When the second user 7 wishes to use the cryptocurrency payment amount (B2), the second node 17 creates the second user private key (V ₂ ) and the episode secret hash (H i ) in the payment transaction (E _{i ).} ) by signing the Redeem script shown in Table 5 by signing with the corresponding episode secret (S _i ). This is shown in the unlock script in Table 6 below. Note that a Redeem script in the format shown in Table 5 can be determined by the second node 17 based on the second user public key (P ₂ ) and the episode secret (S _i ). Here, the episode secret (S _i ) is used to derive the episode secret hash (H _i ).

[Table 6] Second user using cryptocurrency payment amount.

<deformation>
It will be appreciated 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 disclosure. Embodiments of the present invention are, therefore, to be considered in all respects only as illustrative and not restrictive.

In one exemplary variation, each payment transaction (E _i ) may itself have its own designated payment time before becoming effective. For example, the specified payment time is the specified time (e.g., d days) before the second transaction (i.e., the refund transaction) such that the payment transaction (E _i ) is a valid transaction before the second transaction ( For example, it may be d-1 days).

Thus, in this variant, the second node 17 may immediately co-sign the payment transaction (Tx) and send it to the blockchain 9 upon verifying the payment transaction.

For subsequent payment transactions, these subsequent payment transactions have respective specified times (eg, d−2 days) that are earlier than the specified times of the preceding payment transactions (eg, d−1 days). Thus, a subsequent payment transaction, when co-signed and sent to the blockchain 9, precedes and validates the earlier payment transaction and the second (refund) transaction. The advantage of this variant is that if the second node 17 has a failure at a time close to the specified time of the second (refund) transaction, the second user 7 will not be able to do so, since the payment transaction has already been co-signed and sent to the blockchain 9 . is still to receive payment.

<Shared Symmetric Key Based on Shared Common Secret>
A method for generating a common secret between two nodes is described below. A common secret may be used in the generation of cryptographic keys.

<Determine the common secret>
The method allows generation of a common secret between two nodes without having to have the common secret transmitted to and/or from any one of the nodes. Each node has its own asymmetric cryptography pair (such as an elliptic curve cryptography pair), each pair containing a master private key and a master public key. For example, a first node may have a master private key (V _1P ) and a master public key (P _1P ), and a second node may have a master private key (V _1E ) and a master public key (P _1E ). good to do A respective second private key and public key for each node can be determined based on the master private key, the master public key, and the generator value. Generator values (or messages used to derive generator values) are communicated to and/or from nodes.

A common secret can 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 a first node and a second node is described below. Both the first and second nodes determine a generator value common to both nodes. A generator value can be received with a message or can be derived from a message.

At the first node, the common secret (CS) is
(i) a first node second private key (V _2P ) based on the first node master private key (V _1P ) and the generator value (GV);
(ii) the second node master public key (P _1E ) and the second node second public key (P _2E ) based on the generator value (GV).

At the second node, the common secret (CS) is
(iii) a first node second public key (P _2P ) based on the first node master public key (P _1P ) and the generator value (GV);
(iv) a second node master private key (V _1E ) and a second node second private key (V _2E ) based on the generator value (GV).

The common secret is thus:

Common Secret (CS) = ( _V2P x _P2E ) = ( _P2P x _V2E )

<Transmitting information securely>
A common secret can be used to encrypt information for secure transmission. For example, a symmetric key can be based on a common secret. Since both nodes have the same common secret, they have the same symmetric key that can be used to encrypt and decrypt information sent between the two nodes (e.g., over an insecure network). can decide.

<Processing device>
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, and the like. Such electronic devices may include processing devices. Thus, the first node has a first processing unit 23 and the second node 17 has a second processing unit 23''. Electronic devices may also be associated with data stores 11, 18 and user interfaces. Examples of user interfaces include keyboards, mice, monitors, touch screen displays, and the like. Blockchain 9 may also be associated with multiple processing units 19 .

FIG. 6 shows an example of a processing device 19,23. Processing units 19 , 23 include processor 1510 , memory 1520 and interface device 1540 in communication with each other via bus 1530 . The memory 1520 stores instructions and data for performing the methods 100, 200 described above, and the processor 1510 executes the instructions (such as computer programs) from the memory 1520 to perform the methods 100, 200. do. Interface device 1540 may include communication modules that provide communication with peripherals such as communication network 8 and, in some examples, user interfaces and data stores 11 , 18 . It should be noted that although the processing unit 1510 may be a standalone network element, the processing unit 1510 may be part of another network element. Additionally, some functions performed by the processing units 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 communication device, tablet, desktop computer, home media player, television, etc.), and the steps of method 100 are , can be executed and distributed over more than one of these devices.

Claims (9)

A computer-implemented system configured to control the transmission and/or distribution of digital content, wherein a first user is associated with a cryptocurrency bond amount at a common address, and use from said common address is associated with said Requiring the signature of both the first user's first private key and the second user's second private key, the system:
A first node associated with the first user, the first node having a first processing unit,
(A) sending a request over a communication network to a second node to provide a digital content episode from the digital content series;
(B) determining a first payment transaction to transfer a cryptocurrency payment amount from a common address to said second user, said cryptocurrency payment amount being transferred to said series of digital content requested by said first user; based on the number of digital content episodes in the first payment transaction has a first specified time period before becoming effective;
(C) a first node signing said first payment transaction with said first private key and then transmitting said first payment transaction to said second node;
a second node associated with the second user, having a second processing unit;
(I) receiving, over the communication network, the request from the first node to provide the digital content episode and the first payment transaction signed by the first private key;
(II) configured to verify the first payment transaction, including verifying that the first payment transaction includes the cryptocurrency payment amount to the second user; 2 the processing device further comprises:
(III) providing access to said digital content episode to be made available to said first node via said communications network;
(IV) a second node configured to co-sign the first payment transaction with the second private key of the second user and send the co-signed payment transaction to a blockchain;
including
after a second specified time after the first specified time, the cryptocurrency security amount is refunded without a transaction of the cryptocurrency security amount from the common address;
the first processing device is further configured to co-sign, with the first user's first private key, a second payment transaction transferring the cryptocurrency security amount from the common address to the first user;
The second processing device co-signs the second payment transaction with the second private key, and co-signs the second payment transaction co-signed with both the first private key and the second private key to the sent to the blockchain and enabled to refund the cryptocurrency security amount after the second specified time;
sending the co-signed second payment transaction to the blockchain before the second specified time;
The system is further configured as: the first processing unit is further configured to request a next digital content episode from the digital content series by repeating steps (A)-(C);
the second processing device is further configured to receive the request and deliver the next episode of digital content by repeating steps (I)-(III);
2. The method of claim 1 , wherein step (IV) of co-signing and transmitting the first payment transaction to the blockchain is performed for payment transactions having a number of digital content episodes including the next episode. system. 3. The system of claim 2, wherein subsequent payment transactions after said first and second payment transactions have respective designated times prior to said first designated time. A computer-implemented method of receiving digital content, wherein a first node associated with a first user receives the digital content in exchange for payment to a second user associated with a second node; a first user is associated with a cryptocurrency security deposit at a common address, use from said common address requires signature of both said first user's first private key and said second user's second private key; The method includes:
(A) sending, by said first node, a request to provide a digital content episode from a digital content series to said second node over a communication network;
(B) determining, at said first node, a first payment transaction for transferring a cryptocurrency payment amount from said common address to said second user, said cryptocurrency payment amount being transferred to said first node; based on the number of digital content episodes in the digital content series requested by a user, the first payment transaction has a first specified time period before being validated;
(C) signing, at said first node, said first payment transaction with said first private key, and then transmitting said first payment transaction to said second node; verifying the first payment transaction;
and based on the second node verifying that the first payment transaction includes the cryptocurrency payment amount, the method comprises:
(D) accessing the digital content episode by the first node via the communication network;
after a second specified time after the first specified time, the cryptocurrency security amount is refunded without a transaction of the cryptocurrency security amount from the common address;
The method includes:
co-signing, at said first node, with said first private key of said first user, a second payment transaction transferring said cryptocurrency security amount from said common address to said first user; a second payment transaction co-signed by the second user with the second private key at a second node is sent to the blockchain to refund the cryptocurrency security amount after the second specified time; enabled to the step,
method including. requesting the next digital content episode from said digital content series by repeating steps (A)-(D);
5. The method of claim 4, further comprising: 6. The method of claim 5, wherein subsequent payment transactions after said first and second payment transactions have respective designated times prior to said first designated time. A computer-implemented method of controlling the transmission and/or distribution of digital content, wherein a first node associated with a first user distributes digital content in exchange for payment to a second user associated with a second node. and the first user is associated with a cryptocurrency security amount at a common address, and use from the common address is for both the first user's first private key and the second user's second private key. requiring a signature, the method comprising:
(I) receiving at the second node, via a communication network, a request from the first node to provide a digital content episode from a digital content series;
(II) receiving, at said second node, a first payment transaction signed by said first private key for transferring a cryptocurrency payment amount from said common address to said second user; a cryptocurrency payment amount is based on the number of digital content episodes in the digital content series requested by the first user, the first payment transaction having a first specified time period before being validated; a step;
(III) verifying, at the second node, the first payment transaction, including verifying that the first payment transaction includes the cryptocurrency payment amount to the second user; and,
and based on the results of the verification, the method includes:
(IV) providing, by said second node, access to said digital content episode over said communication network to said first node;
(V) co-signing, by said second node, said first payment transaction with said second private key of said second user, and sending said co-signed first payment transaction to a blockchain ;
further comprising
after a second specified time after the first specified time, without transaction of the cryptocurrency security amount from the common address, the cryptocurrency security amount is refunded to the first user;
The method includes:
co-signing, at said second node, with said second private key of said second user, a second payment transaction transferring said cryptocurrency security amount from said common address to said first user; further comprising the step of: said second payment transaction co-signed by one user with said first private key is validated to refund said cryptocurrency security amount after said second specified time;
The method, wherein the step of sending the co-signed second payment transaction to the blockchain is performed before the second specified time. delivering a next digital content episode from said digital content series by repeating steps (I)-(IV), wherein step (V) is the number of digital content episodes containing said next episode; A step that is performed for a payment transaction that is
8. The method of claim 7, further comprising: 9. The method of claim 8, wherein subsequent payment transactions after said first and second payment transactions have respective designated times prior to said first designated time.

Images