US20220300925A1

US20220300925A1 - Systems and methods for media codecs and containers

Info

Publication number: US20220300925A1
Application number: US17/835,497
Authority: US
Inventors: Zachary Casebolt
Original assignee: SertintyOne Corp
Current assignee: Sertainty Corp
Priority date: 2016-03-04
Filing date: 2022-06-08
Publication date: 2022-09-22
Also published as: WO2017152037A1; US11386409B2; US20170255912A1

Abstract

Systems and methods for enabling and enforcing cryptocurrency transactions associated with at least a portion of data are provided. Systems and methods may include a cryptocurrency transaction service, the cryptocurrency transaction service including one or more transaction servers and one or more ledger processing devices. At least one streaming server configured to associate at least a portion of data with a cryptocurrency transaction and to transmit the at least a portion of data may be provided. A client device may be provided, the client device being configured to receive the at least a portion of data from the streaming server, wherein at least one of the client device and at least one streaming server are configured to initiate a cryptocurrency transaction with the cryptocurrency transaction server based at least in part on the association between the at least a portion of data, the cryptocurrency transaction, and the cryptocurrency transaction service.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to and the benefit of U.S. provisional patent application Ser. No. 62/303,852, filed on Mar. 4, 2016 and entitled “SYSTEMS AND METHODS FOR MEDIA CODECS AND CONTAINERS,” the entire disclosure of which is hereby incorporated by reference.

FIELD OF THE INVENTION

The invention relates generally to the field of distribution of media assets, and, more specifically, to systems and methods for effecting payment for the consumption of media assets.

BACKGROUND OF THE INVENTION

The present disclosure relates generally to systems and methods for media codecs utilizing a cryptocurrency framework that delivers high-definition digital audio via streaming that simultaneously self-executes contractually agreed upon financial transactions in cryptocurrencies via cryptoeconomic state machines (e.g., block chain).
The advent of the transmission of media via digital streaming has altered the architecture of the inherent economic structure of the movie, television, and music industries. While consumers benefit from instantaneous consumption and ease of sharing and copying of media, the creators and rights holders of the artistic work that is being delivered are burdened with determining when, where, if, and how payment is due to a vast network of parties that may have monetary claim to the delivered intellectual property, but yet have no unified and timely system and method of receiving such payments.

SUMMARY OF THE INVENTION

Media codecs and containers consistent with embodiments of the present invention (e.g., those referred to herein as 1usf) serve to provide such systems and methods of identifying, initiating, sending, receiving and confirming said payments. By integrating stack-based, Turing complete, bytecode language-based instructions into the genetic code of the media codec and container format by which the artistic work is delivered to a consumer a contract code, contractually agreed upon financial transactions may be executed using cryptocurrencies via a cryptoeconomic state machine. This enables providing direct financial compensation to any party with legal monetary claim to any intellectual property delivered by the streaming audio codec and container format.
The present disclosure provides apparatuses, systems, and methods for the packetized transmission of temporal sequences of media data. The temporal sequences of media data may include, among others, audio, video, audio and video, text-based media, electronic documents, etc. over a streaming medium, such as the Internet, that involve monetary or token-associated transactions having a value (e.g., as set forth in a contractual agreement that is associated with and/or encoded with the media data), for execution in real-time, concurrent with the delivery of the media data through a system of one or more cryptoeconomic state machines and one or more cryptocurrencies.
In one aspect, a method for executing cryptocurrency-based transactions includes receiving, from a client device, a request to stream a data file (e.g., a media file) having one or more contractual restrictions associated therewith, initiating a cryptocurrency transaction with a cryptocurrency transaction server, wherein the cryptocurrency transaction enforces the one or more contractual restrictions associated with the portion of data, and providing the data file to the client device for streaming on the device.
In some embodiments, the data and the contractual restrictions are embedded within a single codec. The request to stream the data file may initiate execution of the codec, thereby initiating the cryptocurrency transaction as the data file initiates streaming on the client device. The contractual restrictions may include enforcement of intellectual property rights associated with the media file (e.g., royalties, etc.). In some instances, the codec comprises a first layer comprising temporally-arranged sequences of the data file, a second layer comprising instructions for accessing the cryptocurrency transaction server and executing cryptocurrency transfers thereon, and a third layer comprising packet header data.
Some versions may enforce the contractual restrictions associated with the data by recording the cryptocurrency transaction as one or more ordered records stored across a distributed database (e.g., a blockchain), and transferring financial assets (e.g., cryptocurrency such as BitCoin) from an account associated with a user of the client device. In some cases, the method also includes determining whether the account associated with a user of the client device holds sufficient financial assets to complete the cryptocurrency transaction. In such cases, streaming of data may be initiated prior to determining whether the account associated with a user of the client device holds sufficient financial assets to complete the cryptocurrency transaction, and the streaming is interrupted if such determination indicates the account associated with the user of the client device does not hold sufficient financial assets to complete the cryptocurrency transaction. However, in some embodiments a user may be permitted to add financial assets to the associated account during such interruption, thereby permitting the streaming of the data file to resume.
In another aspect, a system for executing cryptocurrency-based transactions includes at least one memory device storing computer-readable instructions, and at least one data processing device operable to execute the computer-readable instructions. The instructions, when executed, facilitate receiving, from a client device, a request to stream a data file having contractual restrictions associated therewith, initiating a cryptocurrency transaction with a cryptocurrency transaction server, wherein the cryptocurrency transaction enforces the contractual restrictions associated with the at least a portion of data, and providing the data file to the client device for streaming on the device.
In some embodiments, the data and the contractual restrictions are embedded within a single codec. The request to stream the data file may initiate execution of the codec, thereby initiating the cryptocurrency transaction as the data file initiates streaming on the client device. The contractual restrictions may include enforcement of intellectual property rights associated with the media file (e.g., royalties, etc.). In some instances, the codec comprises a first layer comprising temporally-arranged sequences of the data file, a second layer comprising instructions for accessing the cryptocurrency transaction server and executing cryptocurrency transfers thereon, and a third layer comprising packet header data.
Some versions may enforce the contractual restrictions associated with the data by recording the cryptocurrency transaction as one or more ordered records stored across a distributed database (e.g., a blockchain), and transferring financial assets (e.g., cryptocurrency such as BitCoin) from an account associated with a user of the client device. In some cases, the instructions also determine whether the account associated with a user of the client device holds sufficient financial assets to complete the cryptocurrency transaction. In such cases, streaming of data may be initiated prior to determining whether the account associated with a user of the client device holds sufficient financial assets to complete the cryptocurrency transaction, and the streaming is interrupted if such determination indicates the account associated with the user of the client device does not hold sufficient financial assets to complete the cryptocurrency transaction. However, in some embodiments a user may be permitted to add financial assets to the associated account during such interruption, thereby permitting the streaming of the data file to resume.
Numerous other objects, features, and advantages of the present invention will be readily apparent to those skilled in the art upon a reading of the following disclosure when taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary structure of a cryptoeconomic state machine in accordance with the present disclosure.

FIG. 2 illustrates an exemplary mathematical system of a Merkle Root in accordance with the present disclosure.

FIG. 3 illustrates an exemplary process flow in accordance with the present disclosure.

FIG. 4 is a block diagram illustrating an exemplary temporal architecture of the present disclosure.

FIG. 5 illustrates a flowchart representing an exemplary endo code sequence processing in accordance with the present disclosure.

FIG. 6 illustrates an exemplary structural architecture in accordance with the present disclosure.

FIG. 7 illustrates a flowchart providing an exemplary process flow in accordance with the present disclosure.

FIG. 8 illustrates an exemplary network configuration in accordance with the present disclosure.

FIGS. 9A-E illustrate exemplary packetized data formats and organization in accordance with exemplary embodiments of the present disclosure.

DETAILED DESCRIPTION OF THE INVENTION

While the making and using of various embodiments of the present invention are discussed in detail below, it should be appreciated that the present invention provides many applicable inventive concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed herein are merely illustrative of specific ways to make and use the invention and do not delimit the scope of the invention.
Referring generally to FIGS. 1-9, various exemplary systems, apparatuses, and associated methods according to the present disclosure are now described in detail. Where the various figures may describe embodiments sharing various common elements and features with other embodiments, similar elements and features are given the same reference numerals and redundant description thereof may be omitted below.
Various embodiments of an apparatus according to the present invention may provide systems and methods for a media codec utilizing a Turing-complete cryptocurrency framework that delivers high-definition digital media via streaming that permits simultaneous self-execution of contractually agreed-upon financial transactions in cryptocurrencies via cryptoeconomic state machines. Although described with reference to an artistic work, it should be appreciated that any form of streamed data may be implemented within the scope of the present disclosure. For example, various aspects of the present disclosure may be implemented in fields comprising time-based computational services, web services, one or more client applications or sets of data, or any other form of data capable of operating in accordance with the present disclosure.
Embodiments of the invention provide apparatuses, systems, and supporting methods for the packetized transmission of temporal sequences of media data. The temporal sequences of media data may include, among others, audio, video, audio and video, text-based media, electronic documents, etc. over a streaming medium, such as the Internet, that involve monetary or token-associated transactions having a value (e.g., as set forth in a contractual agreement that is associated with and/or encoded with the media data), for execution in real-time, concurrent with the delivery of the media data through a system of one or more cryptoeconomic state machines and one or more cryptocurrencies.
Cryptocurrency Blockchain
FIG. 1 illustrates an example of a cryptographic transaction state apparatus (referred to herein as “blockchain”). As illustrated, each block (102 a, 102 b and 102 c, generally “102”) may be linked to one or more other blocks 102 in a sequential manner (i.e., “chained” together). The sequence of blocks may contain transaction data 104 (e.g., as associated with a Merkle tree, an example tree of which is illustrated by FIG. 2 and described below). Each block in a traditional blockchain includes an associated block number (e.g., a height) and a hash value (e.g., a header hash). Typically, the blocks 102 are arranged temporally, with block transactions being performed in a sequential manner, and one or more blocks 102 of the blockchain 100 are configured to be stored and processed by a plurality of connected nodes.
A typical blockchain operates as a public ledger of transactions (e.g., cryptocurrency transactions). The plurality of connected nodes each receive broadcast transactions and may validate transactions, add the transactions to their local copies of ledgers, and broadcast ledger additions to other nodes. A plurality of transactions may be associated with a particular block, and additional blocks may be created, for example, at predetermined times or transaction quantities. In one arrangement, a plurality of accepted transactions may be associated with a particular block at a specified time period, and the block may then be published to the plurality of nodes for storage at their local ledger.
Merkle Tree
FIG. 2 illustrates an example of a Merkle tree 200 containing a plurality of transaction hashes. In a Merkle hash tree, each non-leaf node (e.g., a node with both a parent and child node) may be associated with a hash of labels or values associated with its child nodes. For example, the Merkle tree illustrated by FIG. 2 contains seven nodes, labeled H₁-H₇.
Node H₁represents a Merkle root (also referred to as a top hash, root hash, or master hash) having a hash value associated with values of both nodes H₂and H₃, its child nodes. The value associated with non-leaf node H₂represents a hash value of nodes H₄and H₅, its child nodes. The value associated with non-leaf node H₃represents a hash value of nodes H₆and H₇, its child nodes. Nodes H₄and H₅are respectively associated with transactions Tx A and Tx B. The value of node H₄relates to a hash value of Tx A, while the value of node N₅relates to a hash value of Tx B. Similarly, nodes H₆and H₇are respectively associated with transactions Tx C and Tx D. The value of node H₆relates to a hash value of Tx C, while the value of node H₇relates to a hash value of Tx D. Hash trees such as a Merkle tree permit quick and efficient verification of data contained within large datasets, such as transactions and blocks of transactions.
1usf Streaming Format
The 1usf streaming format comprises at least one of a codec and a container. As used herein, the term “codec” may refer to any particular arrangement of data, encapsulation of data, and/or compression or decompression process or protocol, without departing from the spirit and the scope of the present disclosure. In one exemplary embodiment, implementing the 1usf codec and container serves a two-fold purpose: (i) transmission to an end-user based receiving system all of the coded information necessary to digitally represent an artistic work to a consumer, and (ii) concurrent transmission to specified cryptographically secure addresses within a cryptoeconomic state machine, of cryptocurrency in pre-determined amounts to fulfill the financial agreements between the purchasing parties of the artistic work and the intellectual property (herein referred to as IP) rights holders.
In various exemplary embodiments, the 1usf codec and container are written in and/or are consistent with a Turing-complete programming language. In one exemplary embodiment, the Turing-complete programming language comprises an Ethereum programming framework, though implementations consistent with the present disclosure may be accomplished in association with any Turing-complete programming language.
During operation, a 1usf container is received by an end-user receiving system. A fiber layer (e.g., a header layer) associated with the 1usg grain contains information relating to at least one of declarative and structural information. In one exemplary embodiment, three or more headers enclosing execution information are associated with each header layer. In various embodiments, one or more header layers comprise an endo code layer. The endo code layer is configured in one embodiment to contain executive information (e.g., a smart contracts) that permit execution of predetermined transactions (such as financial or token transactions), and one or more operations corresponding to germ data. As used herein, the term “germ data” may refer to any media or other data configured to be delivered to a user in accordance with the present disclosure.
In one exemplary embodiment, an end user-based receiving system's operating system comprises a driver capable of reading the 1usf format, enabling realization of both the reproduction of the artistic work and the execution of one or more contract codes. The receiving system comprises at least one of a smartphone, smartwatch, tablet, set-top box, portable media listening/watching device, laptop computer, desktop computer, or any system capable of presenting streaming media. The driver for reading the 1usf format is contained, in one embodiment, in the operating system of the receiving system, such as iOS, Android, OSx, Windows, Linux, or any operating system capable of permitting the presentation of streaming media, either alone or in conjunction with additional software. Additionally or alternatively, the driver in accordance with various embodiments consistent with the present disclosure is not required to form a part of an operating system of the receiving system. Rather, the driver is capable of being remotely accessed and/or downloaded by the receiving device, and is not required to be either functionally or operatively linked to a particular operating system. In one embodiment, the driver is configured at least in part with a browser interface of the receiving system, such as an add-on, extension, or codec, which permits execution of the codec from within a browser application.
There are numerous ways with which to efficiently execute the transmission of 1usf-coded streaming media so as to be mutually beneficial to at least one of the consumer, the IP rights holders, and the streaming media service. Nevertheless, various embodiments implementing aspects of the present disclosure are configured to execute specified financial transactions pursuant to at least one of the consumer contract code data and the IP meta-data code contract data.
Consumer Contract Code
As part of an agreement between a consumer and a streaming media service, the consumer is assigned a cryptographically secure address within a blockchain that is accessible to both the consumer and the streaming media service (herein referred to as a public key). In various embodiments consistent with the present disclosure, the public key may be associated with at least one cryptocurrency or token source, such as bitcoin, ethereum, namecoin, dogecoin, coinye, or the like.
The consumer contract code is written into the endo code layer of data consistent with the 1usf format and may be used, at least in part, to execute a transfer of funds or tokens between a consumer's public key and a cryptographically-secure addresses within a cryptoeconomic state machine that are accessible to both the IP rights holders and the streaming media service. As used herein, these cryptographically-secure addresses within the cryptoeconomic state machine may be referred to as private keys.
A consumer's public key may be configured to contain a balance of cryptocurrency which may be used to execute the financial transactions required to fulfill a user agreement between a consumer and a streaming media service in one exemplary embodiment. Various exemplary embodiments are achieved by defining a flat monthly rate set between the streaming media service and the consumer, which allow for sufficient funds to cover any financial obligations between one or more streaming media services and any IP rights holder(s). Should the balance of a private key fail to cover a required financial obligation for a particular stream, an error may be returned and the media may not play. In other embodiments, deficient funds may be addressed through requesting such funds from the user, or, in some cases, credits, up to some predetermined threshold. In some implementations, deficient fund situations may be avoided with a flat monthly or annual fee paid to the streaming media service by the consumer that is pre-determined by the streaming media service for access to unlimited media.
Should a consumer's usage exceed what is available in their public key, the financial burden falls on the streaming media service to cover the difference in one embodiment (e.g., akin to cellular phone services setting rates for unlimited monthly phone or data usage by finding a mean price point for all of their customers that would take into account heavy users and light users to find a monthly fee that would satisfy the streaming media service's own financial obligations).
IP Meta-Data Contract Code
In one exemplary embodiment, the IP rights holders are assigned cryptographically secure addresses within the cryptoeconomic state machine that are accessible to both the IP rights holders and the streaming media service, for example as part of a licensing agreement between the IP rights holders of an artistic work and the streaming service contracted to stream the artistic work.
The IP rights holders' private keys may be configured to receive cryptocurrency from a consumer's public key at one or more predetermined location(s)/time(s) within the digital file containing the artistic work being streamed. The one or more predetermined location(s) may be defined as the moment of initial streaming, or may be defined as a moment of consumption at a specified time associated with the stream, so as to allow for instances of previewing works. Although described with reference to an artistic work, it should be appreciated that any form of streamed data may be implemented within the scope of the present disclosure. For example, various aspects of the present disclosure may be implemented in fields comprising time-based computational services, web services, one or more client applications or sets of data, or any other form of data capable of operating in accordance with the present disclosure.
If there were insufficient funds in the public key at the specified moment of transaction, the private key returns an error to the end user's receiving system and the streaming media would cease to stream. In some cases, the streaming media is paused to allow the end user to supplement funds in his account, such that the media may resume streaming with minimal or no interruption. In some cases, the media may continue streaming and include a message (via overly or otherwise) that the media will stop streaming in some period of time if funds are not added to the account by a particular timestamp or percentage viewed.
If somehow any party were able to circumvent the specified moment of transaction, a self-destructing instruction may be written into at least a portion of data corresponding to the 1usf format code that is configured to permit ceasing the streaming of the artistic work.
Germ Data Layer
Data corresponding to an artistic work is contained within a germ data layer. If the artistic work comprises solely audio data, then the entire artistic work may be configured to be contained in the germ data layer. If the work comprises multimedia data (such as audio or video data associated with metadata, or combined video and audio data, or any multimedia format or implementation), then the audio media of the artistic work is contained in the germ data layer, and any other media may contained on its own respective layer.
The media data codec can be written completely in the Turing-complete programming language corresponding to a 1usf file language (e.g., in relation to Ethereum). The media data codec or format may additionally or alternatively be any standardized audio codec such as mp3, ALAC, m4a, WAV, AIFF, etc. Implementations in accordance with the present disclosure may act as both a codec and a container format for an artistic work, or may comprise one or more of a codec and a container format in various embodiments.
Video data content, codec(s), or format(s) consistent with the present invention can be written completely in the Turing-complete programming language corresponding to a 1usf file language (e.g., in relation to Ethereum), or may, in one exemplary embodiment, take the form of any standardized video codec such as H.264, mp4, MOV, AVI, or the like. Certain implementations may act as both a codec and a container format |for an artistic work, or, in some embodiments, it can provide only the container format.
For example, a request is received to play media data (e.g., a song n) and streamed to an end user system (EUS). The EUS receives song n as a multi-layer media file in one embodiment, with one or more layers configured to provide declarative, structural, temporal, and executive information.
The song n may include three layers: a germ data layer, an endo code layer, and a fiber layer. In this embodiment, germ data comprises media data to be delivered (e.g., audio, video, etc.). The endo code layer includes codes configured to 1) access the streaming media services (SMS) account on the Ethereum blockchain (EB) and transfer cryptocurrency from the SMS to the Intellectual Property Rights Holder's (IPRH) account on the EB, and/or 2) access the end user's (EU) account on the EB and transfer cryptocurrency from the EU account to the SMS account on the EB. The fiber layer may include data packets containing headers for the Endo Code, Germ Data, and any other metadata.
Upon arriving at an EUS, song n is configured to execute one or more smart contracts associated with an endo code, and may, in one embodiment, return a binary (e.g., yes or no) condition indicator. If execution results in a “yes,” then song n is delivered and executed. If no, an error is reported to the SMS and playback will cease.
In one exemplary embodiment of an operating environment 300 illustrated by FIG. 3, an end user system (EUS) 304 may take the form of a digital media player, television, set-top box, ipod, iphone, Android phone, ipad, surface book, Kindle, or any electronic device capable of conveying streaming data to a user. The process may begin when the EUS 304 sends a request (data path 301) to a centralized host server 312, such as a streaming music service (SMS) to initiate a transmission of streaming media (e.g., a song, also referred to as a grain). The SMS 312 then initiates the transmission of the 1USF Harvest File (data path 316)—herein called 1USF to a cryptographic state machine (320). Information associated with one or more endo-code layers of a 1USF file may be used, at least in part, to access one or more harvest accounts of the SMS 312 and one or more relevant Intellectual Property Rights Holders 324 (herein referred to as IPRH) on a cryptoeconomic state machine 320 outlined in smart contracts written into the endo-code layer of the 1USF file via a public key 328 for the SMS 312 and a private key 332 for the IPRH 324. The endo-code may then be used to transfer monetary or token sums as defined in the smart contracts for predetermined values (e.g., associated with one or more cryptocurrencies) from the SMS account to the IPRH accounts (data flow 336). The cryptoeconomic state machine 320 returns a binary condition of Y or N to the endo code of the 1USF file (step 311) which in turn returns that condition to the SMS 312 (data flow 340) whereby streaming distribution either occurs if given a Y condition or is returned to the EUS as an error if given a N condition (decision step 344).
FIG. 4 illustrates one embodiment of the transmission of the 1USF file from the standpoint of the end user (EU) and follows the request to transmit streaming data throughout an exemplary computer architecture. In step 401, the EU requests the transmission of the 1USF file grain from the SMS via the EUS. The SMS remits the request to the 1USF file which activates the 1USF endo-code for that particular grain (step 403). The endo-code of the 1USF file then initiates a financial transaction in cryptocurrency between the SMS harvest account on the harvest cryptoeconomic state machine (herein referred to as H-CeSM) and the IPRH accounts on the H-CeSM (step 405). The H-CeSM then returns a condition to the 1USF file of Y if the transaction is successful, or N if the transaction is unsuccessful (step 407). The SMS then either initiates the transmission of the streaming file if the condition is Y, or returns an error to the EUS if the condition is N (step 409). In some cases, provision of the 1USF file grain may be suspended, allowing the user to add additional currency to his account, thus permitting the resumption of the delivery and streaming of the 1USF file grain.
FIG. 5 illustrates an alternative embodiment of the transmission of the 1USF file using a cryptoeconomic state machine in the Ethereum cryptocurrency framework (herein referred to as E-CeSM). In step 501, the endo code sequence is initiated by the EUS as a request to receive the 1USF grain and the header information is read from the sequence. The endo code accesses the EU harvest account in the E-CeSM (step 503). The endo code then transfers cryptocurrency from the EU harvest account to the IPRH's accounts in the E-CeSM (step 505). At decision step 5-7 the E-CeSM determines whether adequate funds are available, and returns a condition of Y to the 1USF file if the transaction is successful (step 509), or N if the transaction is unsuccessful (step 511).
FIG. 6 illustrates the anatomy of the 1USF grain file. Layer 601, herein referred to as the Germ Data, contains the temporal sequences of media data to be delivered via streaming. Layer 603, herein referred to as the Endo Code contains the Turing-complete code that accesses the SMS account on the H-CeSM or E-CeSM and transfers cryptocurrency from the SMS or EU to the IPRH account on the H-CeSM or E-CeSM. Layer 605, herein referred to as the Fiber Layer, contains data packets containing the headers for the endo code, germ data, and all other meta-data.
FIG. 7 is a flow-chart illustrating the broad logical data flow of embodiments of the present invention. In step 701 a, the EU requests playback of a 1USF grain file. The EUS reads the endo code header in the grain's fiber layer (step 701 b), and the smart contracts contained within the endo code layer are executed (step 703 a). The endo code layer then transfers cryptocurrency from the EU harvest account on the H-CeSM or the E-CeSM (step 703 b). The endo code returns a condition of either Y or N to the EUS (step 705 a). If the condition is Y, then the grain is delivered to the EUS. If the condition is N, then an error is returned to the EUS (step 705 b).
FIG. 8 illustrates an exemplary embodiment of a computer system 800 on which the methods and techniques described herein may be implemented. The system 800 includes one or more client electronic devices 810. The client electronic device 810 may include one or more of microprocessors 812, storage units 814, communications units 816, and a display unit 818. The communications unit 816 of the client electronic device 810 may be configured to connect to a network 850 via connection 811. Network 850 may be a public network (e.g., the internet), a private network, a combination of public and private networks, or any other communications medium capable of conveying electronic communications. Connection between the communications unit 816 and network 850 may be by wired interface, wireless interface, or a combination thereof. In operation, the client electronic device 810 stores instructions in the storage unit 814, which are executed by the microprocessor 812. The display unit 818 may be embodied within the client electronic device 810 or may be either wired or wirelessly-interfaced with the client electronic device 810.
In various exemplary embodiments, the client electronic device 810 may be a desktop computer, a laptop computer, a smart phone, or any other electronic device capable of executing instructions. The microprocessor 812 may take the form of a generic hardware processor, a special-purpose hardware processor, or a combination thereof. In embodiments having a generic hardware processor, the generic hardware processor may be converted to a special-purpose processor by means of executing a particular algorithm for providing a specific operation or result. Client electronic device 810 may be associated with a fixed location or may be capable of being transported, either during operation or while powered off. In one embodiment where the client electronic device 810 is a client's cellular telephone, the client electronic device 810 may be located at a client's premises. In various embodiments, the client electronic device 810 may be operated remotely, and may be configured to obtain or otherwise operate upon one or more instructions stored physically remote from the client electronic device 810 (e.g., via client-server communications and/or cloud-based computing).
Media streaming services may be provided by streaming servers 820. Each streaming server 820 may be connected to network 850 via communications link 821 and may comprise one or more of a microprocessor 822, a storage unit 824, a communications unit 826, and/or a display unit 828. Each of the microprocessor 822, storage unit 824, communications unit 826, and/or display unit 828 may respectively correspond to microprocessor 812, storage unit 814, communications unit 816, and/or display unit 818.
Each streaming server 820 may be associated with a fixed location or may be capable of being transported, either during operation or while powered off. In one embodiment, streaming server 820 may be located at a fixed location and comprise a server. In various embodiments, the streaming server 820 may be operated remotely, and may be configured to obtain or otherwise operate upon one or more instructions stored physically remote from the compliance server 820 (e.g., via client-server communications and/or cloud-based computing).
One or more transaction servers 830 consistent with the present disclosure may be provided by electronic devices. Each transaction server 830 may be connected to network 850 via communications link 831 and may comprise one or more of a microprocessor 832, a storage unit 834, a communications unit 836, and/or a display unit 838. Each of the microprocessor 832, storage unit 834, communications unit 836, and/or display unit 838 may respectively correspond to the previously-described microprocessor 812, storage unit 814, communications unit 816, and/or display unit 818 without departing from the spirit and the scope of the present disclosure.
Each transaction server 830 may be associated with a fixed location or may be capable of being transported, either during operation or while powered off. In one embodiment, one or more transaction servers 830 may be located at a fixed location and comprise a desktop computer, or may comprise a moveable laptop or tablet computer in another embodiment. In various embodiments, the transaction server 830 may be operated remotely, and may be configured to obtain or otherwise operate upon one or more instructions stored physically remote from the transaction server 830 (e.g., via client-server communications and/or cloud-based computing).
One or more ledger processing devices 840 form at least a part of a cryptocurrency processing network. Each ledger processing device 840 may be connected to network 850 via communications link 841 and may comprise a microprocessor 842, a storage unit 844, a communications unit 846, and/or a display unit 848. Each of the microprocessor 842, storage unit 844, communications unit 846, and/or display unit 848 may respectively correspond to microprocessor 812, storage unit 814, communications unit 816, and/or display unit 818 without departing from the spirit and the scope of the present disclosure.
Each ledger processing device 840 may be associated with a fixed location or may be capable of being transported, either during operation or while powered off. In one embodiment, ledger processing devices 840 may be located at a fixed location and comprise a desktop computer, or may comprise a moveable laptop or tablet computer in another embodiment. The ledger processing device 840 may be operated remotely, and may be configured to obtain or otherwise operate upon one or more instructions stored physically remote from the ledger processing device 840 (e.g., via client-server communications and/or cloud-based computing).
FIGS. 9A-9E illustrate packetized data used to implement the methods and systems described herein. FIG. 9A illustrates logical sections (e.g., packets) within a media stream 900. Media stream 900 includes one or more segments of media data B. Although described with reference to media data, it should be appreciated that the media data B may comprise at least one of audio data, visual data, metadata, or any other form of content or data and/or metadata associated with the content or data. As such, implementations consistent with the present disclosure are not limited to merely multimedia applications, but extend to any form of content and/or data without departing from the spirit and the scope of the invention.
For example, media data B may take the form of individual portions of data illustrated as media data B₀, B₁, . . . , B_N. Each individual portion of media data B may be configured to take the form of a fixed-sized data package, or may be of a variable size. In one exemplary embodiment, the media data B includes data having a predetermined fixed size, and a size of one or more portions of media data B are configured such that the media data B fits the predetermined fixed size.
FIG. 9B illustrates an exemplary embodiment of a packetized data set 910. Packetized data set 910 includes one or more portions of data (e.g., B₀, B₁, . . . , B_N), along with a header H₁. The header H₁includes data associated with each respective portion of media data B. In one exemplary embodiment, the header H₁takes the form an intellectual property (IP) contract code that, in some instances, includes a private key associated with an individual or entity.
FIG. 9C illustrates an exemplary embodiment of a packetized data set 920. Like the packetized data set 910, the packetized data set 920 includes one or more portions of media data (e.g., B₀, B₁, . . . , B_N) and a header H₁. The packetized data set 920 further includes one or more headers H₂. In one exemplary embodiment, the one or more headers H₂are associated with a consumer contract code relating to the respective portions of media data B. An exemplary consumer contract code may be referred to as a public key.
FIG. 9D illustrates an exemplary embodiment of a packetized data set 930. The packetized data set 930 illustrated in FIG. 9D includes one or more portions of media data (e.g., B₀, B₁, . . . , B_N) and headers H₁and H₂. The portions of media data B and headers H₁and H₂include features consistent with those described above with reference to FIGS. 9A-C. For example, in one embodiment the header H₁takes the form an intellectual property (IP) contract code, while one or more headers H₂are associated with a consumer contract code relating to the media data B. In the embodiment illustrated by FIG. 9D, the packetized data set 930 further includes at least one header H₃. The one or more headers H₃include data associated with headers H₁and H₂, for example, as data, metadata, data formatting information, or any other information. The information associated with headers H₃may include instructions to enable functionality consistent with the description herein.
FIG. 9E illustrates an exemplary embodiment providing a packetized data set 940 having the above-mentioned portions of media data B and headers H₁, H₂and H₃in a non-sequential data format. In one embodiment, at least a portion of information contained in header H₃includes data formatting information configured to enable a sender and/or receiver to organize or deconstruct a packetized data set 940. Although illustrated as a single packetized data set 940, it should be appreciated that the packetized data set 940 is capable of spanning multiple data packets or frames, for example by partitioning or in accordance with data formatting information contained within the packetized data set 940. Packetized data sets 910, 920, and 930 may likewise take the form of a plurality of data packets or frames.
During operation, packetized data is transmitted between one or more client electronic device 810, streaming server 820, transaction server 830, and ledger processing device 840. In one embodiment, the one or more portions of media data B are formed and transmitted from a streaming server 820 to a client electronic device 810. At least one of headers H₁, H₂, and H₃are configured to be inserted into or substantially concurrent with data transmitted by the streaming server 820. In one embodiment, the streaming server 820 appends at least one of headers H₁, H₂, and H₃to a stream of media data B during operation.
Either in addition or alternative to streaming server 820 appending header data, one or more intermediate servers may operate within network 850 to append or modify data transmitted from streaming server 820, or may independently transmit data to an intended recipient corresponding to the data transmitted from the streaming server 820. The data appended, modified, or independently transmitted is configured to correspond to the data transmitted from the streaming server 820 and may, in one exemplary embodiment, relate to at least a portion of media data B. In embodiments where streaming server 820 appends or modifies transmitted data, one or more software instructions stored at the storage unit 824 may be executed by the microprocessor 822 to append or modify in the described manner. The appended or modified data is transmitted in the embodiment via the communications unit 826 of one or more streaming servers 820.
During operation, the data transmitted from the one or more streaming servers 820 is received at one or more client electronic device 810. The storage unit 814 of the client electronic device 810 stores one or more sets of computer instructions executable by the microprocessor 812 to operate upon at least a portion of data received from the streaming server 820 by means of network 850 and connection 811. In one exemplary embodiment, data received from the streaming server 820 is configured to be parsed and interpreted according to at least one of instructions stored at the client electronic device 810 and/or information included in or associated with the data received from the streaming server 820. In various embodiments, operations associated with a client electronic device 810 may be performed by means of at least one of an application or software module stored either locally or externally to the client electronic device 810, by means of a hardware, software, or combined hardware and software driver associated with the client electronic device 810 and located either locally or externally to the client electronic device 810, and/or a distributed (e.g., cloud-based) service associated with the client electronic device 810.
At least one of when the streaming server 820 transmits data and when the client electronic device 810 receives and/or plays back data, one or more cryptocurrency transactions are configured to be performed. For example, in one embodiment cryptocurrency transactions associated with media data are performed at the client electronic device 810 by means of an application executing at the client electronic device parsing and processing data received from the streaming server 820 in accordance with a predetermined data format or codec, or in accordance with information contained within the received data relating at least in part to the received data (e.g., as included in header data).
Additionally or alternatively, one or more cryptocurrency transactions are configured to be initiated by the streaming server 820 or an intermediary server located at network 850 in one embodiment. Transactions initiated by the client electronic device 810, streaming server 820, and/or intermediary server at network 850 are associated with at least one of a user, an IP rights holder, a recording industry organization, or any other entity associated with a particular portion of data consumed or otherwise accessed by one or more client electronic devices 810.
Transactions described herein are configured, in one embodiment, to be executed by the one or more transaction servers 830 and one or more ledger processing devices 840. At least one of the transaction servers 830 and ledger processing devices 840 is associated with a cryptocurrency in one embodiment. Although described with reference to currency, it should be appreciated that the implementations consistent with the present disclosure may operate according to non-monetary denominations. For example, implementations consistent with the present disclosure operate using tokens rather than monetary currency in various embodiments, without departing from the spirit and the scope of the invention.
Transactions may be performed in various embodiments in association with one or more smart contracts. The one or more smart contracts comprise one or more entities that facilitate, verify, and/or enforce a negotiation or performance of a contract or operation. Smart contracts consistent with the present invention include both partially and fully self-executing and/or self-enforcing contracts associated with one or more portions of data (e.g., media data B). Smart contracts consistent with the present disclosure may be enforced with reference to one or more conditions associated with one or more of users, client electronic devices 810, streaming servers 820, transaction servers 830, ledger processing devices 840, recording industry organizations, recording artists, IP rights holders, or any other person or entity associated with particular data (such as media data B).

Claims

1.-22. (canceled)

23. A method for executing cryptocurrency-based transactions, the method comprising:

sending, from a client device to a host server, a request to receive a data file;

receiving, by the client device, a container comprising one or more layers and one or more headers, wherein the one or more headers comprises:

(a) a first header including an intellectual property contract code, the intellectual property contract code comprising a private key associated with an individual intellectual property rights holder, the private key being in the first header, and

(b) a second header associated with a consumer contract code;

sending, by the client device, cryptocurrency to an account associated with an intellectual property right holder identified in the intellectual property contract code for an execution of a cryptocurrency transaction; and

after executing the cryptocurrency transaction, playing, by the client device, at least a portion of the data file.

24. The method of claim 23, wherein the data file comprises a media file.

25. The method of claim 23, wherein the one or more layers comprise at least:

(i) a first layer comprising the data file,

(ii) a second layer comprising programmatic instructions that when executed on the client device, accesses a cryptocurrency transaction server and executes cryptocurrency transfers thereon, and

(iii) a third layer comprising the one or more headers.

26. The method of claim 25, wherein the execution of the programmatic instructions comprises:

initiating the cryptocurrency transaction for the requested data file with the cryptocurrency transaction server, and

enforcing one or more contractual restrictions associated with the data file, the one or more contractual restrictions being pursuant to the intellectual property contract code and the consumer contract code, the one or more contractual restrictions being in the data file.

27. The method of claim 26, wherein the enforcement of one or more contractual restrictions associated with the data file by the cryptocurrency transaction server comprises:

(i) recording the cryptocurrency transaction as one or more ordered records stored across a distributed database, and

(ii) transferring financial assets from an account associated with a user of the client device.

28. The method of claim 27, wherein the financial assets comprise cryptocurrency.

29. The method of claim 27 further comprising determining whether the account associated with a user of the client device holds sufficient financial assets required by the cryptocurrency transaction.

30. The method of claim 29, wherein receiving the container comprises streaming of the data file, wherein the streaming

(i) is initiated prior to determining whether the account associated with a user of the client device holds sufficient financial assets required by the cryptocurrency transaction, and

(ii) is interrupted when such determination indicates the account associated with the user of the client device does not hold sufficient financial assets required by the cryptocurrency transaction.

31. The method of claim 30 further comprising adding financial assets to the associated account during such interruption, and resuming the streaming of the data file.

32. A system for executing cryptocurrency-based transactions, the system comprising:

at least one memory device storing computer-readable instructions; and

at least one data processing device operable to execute the computer-readable instructions to perform operations including:

sending a request to receive a data file;

receiving a container comprising one or more layers and one or more headers, wherein the one or more headers comprises:

(b) a second header associated with a consumer contract code;

sending cryptocurrency to an account associated with an intellectual property right holder identified in the intellectual property contract code for an execution of a cryptocurrency transaction; and

33. The system of claim 32, wherein the data file comprises a media file.

34. The system of claim 32, wherein the one or more layers comprise at least:

(i) a first layer comprising the data file,

(iii) a third layer comprising the one or more headers.

35. The system of claim 34, wherein the execution of the programmatic instructions comprises:

36. The system of claim 35, wherein the enforcement of one or more contractual restrictions associated with the data file by the cryptocurrency transaction server comprises:

37. The system of claim 36, wherein the financial assets comprise cryptocurrency.

38. The system of claim 36, further comprising computer-readable instructions that when executed determines whether the account associated with a user of the client device holds sufficient financial assets required by the cryptocurrency transaction.

39. The system of claim 38, wherein receiving the container comprises streaming of the data file, wherein the streaming

40. The system of claim 39, further comprising computer-readable instructions that when executed adds financial assets to the associated account during such interruption, and resuming the streaming of the data file.