Patent Application
20240104553
This disclosure generally relates to content management systems, and policy systems for management of rights for access to and use of content, typically copies of creative works.
The computer programs disclosed in this patent application are subject to copyright protection under the copyright laws of the United States and of other countries. As of the first effective filing date of the present application, this material is protected as published material, and to the extent not already subject to protection for published material, as unpublished material. However, permission to copy the computer programs is hereby granted to the extent that the owner of the copyright rights has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure, as it appears in the United States Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The concepts of “content” and “creative work” are often used interchangeably when referring to creative works. However, there are important distinctions that should be kept in mind.
When creative works become fixed in a tangible medium, the creators become imbued with a number of legal rights including the rights of: reproduction; public display; public performance; distribution by sale or other transfer of ownership or by rental, lending, or leasing; and transmission, depending upon the type of work involved. In most cases, in the exercise of those rights, a physical version of the work that can be transmitted or itself reproduced is made. This physical version of a work is content, and in the digital age content is digital data symbolizing a creative work.
While creators initially own all of the rights in a creative work, those rights can be transferred above so that the exercise of one or more of the rights can be undertaken by a transferee such as an assignee or licensee. Further, content embodying the creative work can be distributed without affecting the ownership of the rights in the corresponding creative work, as mentioned above. Thus, ownership of content is distinct from ownership of the intellectual property rights to the corresponding creative work. In this way content, e.g., in the form of copies of artwork, images, songs, etc. can be distributed on a blockchain, without transfer of ownership rights to the underlying creative work.
Content typically is served to consumers through a number of channels, most often controlled by vendors, or alternatively controlled by the owner or licensee through a singular channel (e.g. on their own website or their own hardware). If the content owner, or licensee chooses to distribute content through their own medium, access to that content is restricted to that channel and therefore distribution is severely limited. Alternatively, third party mediums may be hardware products such as Sony Corporation's Walkman®, or software products/platforms such as Spotify® and YouTube®. The relationship between the creator/owner/licensee and consumer is intermediated by the vendor since the vendor hardware or platform controls the code which implements the access policy (price, access time, ability to sub-license) of the content. Content owners or licensees must adhere to this policy or find another vendor to distribute the content.
The challenge addressed herein is that there is no method by which a creative work owner or licensee can associate the access policy implementation with the distributed content in a way such that a single access policy can be self-administered by the content itself independently of the vendor hardware or software. Digital rights management (DRM) software/solutions do not solve this as DRM is by definition software and/or hardware created and controlled by a vendor (or group of vendors) and not by each individual creative work owner or licensee, which in many cases is the creator.
The present disclosure provides one or more inventions concerning methods, systems, and computer products for distributing content via a computer network, e.g., the Internet, using a standalone program rather than merely a data file to be interpreted by a vendor program. This allows self-administered access to content, and distribution of the content or access to the content onto an unbounded number of third party platforms while continuing to perform that self-administration (including, e.g. royalty accounting and price control). The containerization and distribution scheme involves inverting the conceptual model of a piece of content such that all programmatic dependencies for serving the content are content deployer controlled (rather than vendor controlled). The process preferably is as follows:
Analogous to a digital vending machine, this arrangement and process enables content to vend on behalf of the creator or content owner, on any property, rather than a singular property owned by the creator or a single vendor. A container includes the smart contract program and the access policy implementation and distributes a single machine interface (e.g. the blockchain address) to an unbounded number of target properties on which the machine may vend in perpetuity using the access policy specified by the creator or content owner.
Note that Ethereum® is an example blockchain but the disclosed invention is not limited to Ethereum®, for example, Polygon™ transactions also qualify as a transactional source of truth which can be read by the distribution microservice. In addition to persisting the license grant, this program directs funds from the transaction to the owner of the program (the program is the smart contract). The contract allows the owner to perform administrative operations such as withdrawals or updates to the storage locations. The contract implements a standard interface such as the Ethereum® Request for Comment Number 721 (ERC-721) which many vendors may support. Within the interface, the distribution service URI which conditionally renders content based on the contract state is exposed through a standard function exposed in the contract interface.
This is made possible by taking advantage of ERC-721 token metadata standard including the use of the uniform resource indicators (URIs) in the metadata. This disclosure introduces a layer which uses this metadata interface as a transaction-based interlock between content owner and consumer at every observable entry point of the content. As a result, the following code can be executed from any server: “Check if entity N paid what the creative work owner has asked for”, and “provide access to the content.” This code requires very limited stateful behavior to have a massive impact: confirming financial transactions and updating state variables readable by decentralized content delivery (distribution) networks.
The output of the system described above is a standalone content-related container that includes an access policy that can be executed by any vendor with access to a blockchain. The result of executing the policy in adherence with the creator's specified terms (e.g., paying the specified price), is that decrypted content data bytes are streamed through the contract's standard interface to the consumer. One reason this is possible is that the code executes on decentralized infrastructure rather than on vendor-controlled hardware. In other words, it would not be possible to ship custom access policy code to Spotify®, YouTube®, and Apple Music® servers for server-side execution since each has a different system architecture and system administration policy. In these cases the creator or the creator's assignee or licensee is bound to the per-vendor access policies specified in each of the vendors respective Terms-Of-Service (ToS), where the ToS are codified and executed within the vendor controlled environment. There is no runtime environment in which a single set of access policy instructions codified by the creator or the creator's assignee or licensee could be allowed to execute in a traditional distribution model.
However, by executing the policy code on a blockchain, the vendor can invoke the content container program safely and comply with creator-controlled access terms, codified in the content container contract. This migration of access policy code from a vendor-controlled execution environment into a creator-controlled execution environment can be called “access inversion”—the content does not depend on vendor access policies (such as the price per stream), rather the inverse is true.
The concept of a pay-for-access (PFA) smart contract is especially helpful. This is akin to a rental or leasing contract. The price per access (e.g. a view or listen) can be set to zero as it is today for nearly all non-fungible tokens (NFTs). However, it can also be set to a non-zero value. This means that content will exist which cannot be observed or accessed until a micro-payment is recorded on the blockchain. It is important to note that this disclosure is distinct from gating access to content based on token ownership, e.g. it does not require the licensee or consumer to own any token in exchange for access—rather it is based on microtransaction records stored in the state of the PFA smart contract. In order to enable high-volume transactions at low cost, the present principles are best implemented on scaling solutions such as the Polygon® Proof-of-Stake (PoS) sidechain, however they will support implementation on additional chains, and new Etherium® Virtual Machine (EVM) compatible zero knowledge (ZK) rollups as they launch.
Unlockable PFA experiences at scale can create immense impact for content owners/creators. At high volume, micro payment transactions on observables are much more sustainable than trying to sell a single NFT for a high price to one buyer. Rallying a community to establish value around an NFT can be a stressful endeavor for artists, and an alternative model is to charge a creator-specified price for the ability to experience the art. Putting more content monetization options (PFA, pricing, and sponsor revenue) into the hands of content owners/creators, enables them to choose which combination of models work best for their business.
The following terminology is employed herein:
“Accessing” in the context of “accessing content” or “accessing the content” means gaining the ability to experience the work corresponding to or embodied in the content. This is time bound and the time is specified by the creative work owner.
“API” means an application programming interface. APIs are code which enable applications to exchange data and functionality.
“Blockchain” means any sufficiently decentralized network of processors or computers which provides the ability to transact, and to execute code, with consensus on the resulting world state transitions by a set of decentralized actors.
“Code” means computer processor executable instructions.
“Container” means a jointly compiled smart contract and application programming interface that together control access to content and contract storage associated with the smart contract.
“Content” means digital data symbolizing a creative work, and which is in an accessible digital file format such as WAV, MOV, MPEG, MP3, MP4, ALAC, FLAC, EPUB, JPEG, GLB, 3MF, PNG, TIFF, etc.
“Content Container” means a container and distribution service program which backs the container to conditionally render content to a user or vendor application based on a state of the container smart contract.
“Content data” means and comprises the content, one or more portions of the content, e.g., snippet(s), or preview(s), and/or metadata of the content.
“Content deployer” means a natural person who or juridical entity which deploys content together with an access policy for or criteria for accessing the deployed content. A Content Deployer preferably is the creator, assignee, licensee, or other controller of rights to the creative work which is embodied in the content.
“Contract owner” means the natural person who or juridical entity which controls a smart contract.
“Contract storage” means processor readable data storage medium for storing data establishing a state of an associated smart contract.
“Core content” means the content embodying the creative work when it is deployed with other content data.
“Distribution microservice” means processor executable instructions or code that read container contract storage data and render content controlled by the container directly or indirectly to a user application when permitted by the container.
“Experience the work” means to view, read, listen to or otherwise use the corresponding content, dependent upon the type of work being experienced.
“IP” means Internet Protocol.
“Processor” means one or more devices that process or execute programming instructions or code to effect a function dictated by the instructions or code.
“Smart Contract” means an immutable computer program which verifies and executes its terms upon the occurrence of predetermined events. A smart contract can run deterministically in the context of a decentralized world computer. The ownership of a smart contract is mutable and the address(es) of the contract owner(s) are mutable for that purpose.
In an embodiment, non-transient processor readable storage medium contains processor executable instructions that when executed by the processor cause the processor to:
In an embodiment, the instructions cause the processor to render previously selected bytes of the content to the user application when the state of the smart contract does not permit access to all of the content to the user.
In an embodiment, the processor executable instructions cause the processor to render the content to an endpoint having an IP address using the HTTPS protocol.
In an embodiment, the processor executable instructions cause the processor to conditionally stream the content to an endpoint having an IP address using the HTTPS protocol.
In an embodiment, the non-transient processor readable storage is not located on a block chain.
In an embodiment, the processor executable instructions cause the processor to render the content to an address provided by a token URI function or its equivalent.
In an embodiment, the programming instructions comprise a distribution microservice.
In an embodiment, the programming instructions are mutable.
In an embodiment, the programming instructions cause the processor to decrypt the bytes of the content.
In an embodiment, a non-transient processor readable storage medium of a blockchain network contains processor executable instructions that when executed by the processor cause the processor to:
In an embodiment, the container is addressable by an identifier of the blockchain and an address on the blockchain.
In an embodiment, the programming instructions cause the API to communicate with a user application and the distribution microservice and to render bytes of the content to the user application.
In an embodiment, the executable instructions initialize the API with data concerning:
In an embodiment, the executable instructions enable the distribution microservice to call for information as to when access to the content was granted and information as to when a license was granted to access the content.
In an embodiment, the executable instructions enable a user application to:
In an embodiment, the executable instructions enable the API to render the bytes of the content to a user application via a token URI function.
In an embodiment, the contract program includes data establishing a price to access the content and a total time to live in which access to the content is open.
In an embodiment, the contract program includes data establishing a price to access the content and a total time to live in which access to the content is open.
In an embodiment, a content distribution systems comprises:
In an embodiment, the computer application is an intermediary application that can communicate between the API and a user application.
In an embodiment, the computer application is a user application.
In an embodiment, the API is initialized by the smart contract program with:
In an embodiment, the API is configured to provide:
In an embodiment, the API renders the bytes of the data using the token URI function or its equivalent.
In an embodiment, the distribution microservice confirms an identity of the user using a signed message which uses a private key associated with user.
In an embodiment, a method comprises:
In an embodiment, the content is encrypted while stored.
In an embodiment, the distribution microservice decrypts the bytes of the content when rendering the bytes.
In an embodiment, the method also comprises storing the container on a blockchain network.
In an embodiment, the method also comprises storing the distribution microservice on a non-blockchain network.
In an embodiment, the container is accessed using a blockchain network identifier and an address on the blockchain by the distribution microservice and a user application.
In an embodiment, the container includes contract program storage with data indicating the state of the smart contract program.
Other systems, methods, features, and advantages of the one or more disclosed inventions will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the invention, and be protected by the accompanying claims.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an implementation of the system disclosed herein, together with the description, explain the advantages and principles of the disclosed system. In the drawings:
Reference will now be made in detail to one or more implementations or embodiments consistent with the principles disclosed herein with reference to the accompanying drawings.
Referring to
Ethereum® is a decentralized, open-source blockchain with smart contract functionality. The Ethereum® blockchain is a permissionless, non-hierarchical network of computers (nodes) that build and come to a consensus on an ever-growing series of “blocks”, or batches of transactions. Each block contains an identifier of the chain that must precede it if the block is to be considered valid. Whenever a node adds a block to its chain, it executes the transactions in the block in the order they are listed, thereby altering cryptocurrency balances (in Ether (ETH)) and other storage values of accounts.
At the same time that the container 26 is deployed, the deployment service 16 deploys the content data 10 to a storage provider or hosting service 22 which can be, for example, a cloud service or an IPFS service. Preferably, content snippet(s) and/or preview(s) and/or metadata is(are) not encrypted, but the core content is encrypted by an encryption service or application 20 at storage time.
The container 26 thus has a contract program or code 28 which implements the access policy 12 and a container API 30. The container API 30 of the container 26 controls which distribution microservice or program 24 backs the content 12. It is mutable by the contract owner, preferably the content deployer. The container API 30 serves content to a user application 40 with a standard function token URI. However, the actual content streamed is conditional based on a contract state, which is verified by the distribution microservice 24 at streaming time.
The distribution microservice or program 24 is optionally spawned for each piece of content or per-N-contents where N is the size of some collection of content, by the deployment service 16. This backs the container 26 and is what conditionally renders the content or other content data to the user application 40 based on contract state. This service 24 can be spawned by the content deployer (e.g. in this diagram it is provided as a service). The code of the microservice 24 may run on a platform as a process in memory, which is a non-transient (also known as non-transitory) computer or processor readable medium which stores programming code.
The content of the content data 10, may become accessible in plaintext (i.e., unencrypted) in random access memory, which is available to a consumer or their application 40 at runtime. The core content may be transmitted over an encrypted channel, using for example, a Secure Sockets Layer (SSL) and then decrypted via the API 30. The container program 28 logic executes on ownerless infrastructure on a blockchain, imposing no additional technical requirement on the distributee. The implication of this method is that all content administration is alleviated from the host and delegated to the owner of the contract program 28, preferably the content deployer, which preferably is the creator, and assignee or licensee.
The code of the microservice 24, which may be interpreted by a runtime machine, e.g. Node.js which is a JavaScript® runtime built on Chrome's V8 JavaScript engine, and interacts with the access policy code 12 complied into the container 26 and the content data 10 to decrypt and serve the core content of content data 10. The code of the microservice 24 can also later remove the decrypted core content after time-to-live (TTL) is reached, with TTL established by the access policy code 12.
Applications 40 and users actuate the stored content data or core content by executing the access policy in the container contract program 28. This may include the use or the user application 40 paying the container 26 directly per the access policy. The container 26 can receive digital currency directly since it executes on a blockchain.
In
Also illustrated in block form is the container API 30, which includes code for the endpoint of the content or core content via the function token URI 30a, access function 30b, license 30c, and another other optional functions 30d.
As illustrated in
In
Smart contract API callers implicitly supply their unique identity in the form of a 160-bit blockchain address 50. This identity is proven by the distribution microservice 24 (
The container API 30 restricts access to certain functions based on the identity of a user invoking the function from a given user application, 40 (
The contract owner call function 60 initializes the following the parameters, token URI, price per access, the time to live (TTL), whether a license can be granted using the following code:
The code called by the distribution microservice 24 includes:
The consumer application interacts with the API 30 by invoking the following functions to understand the terms for use of the content and transacting with the contract container 26:
As can be appreciated, with a container 26 configured with this API 30 and with the microservice 24 which backs the container 26, each content is self-contained and self-administered independent of the application layer. That is to say, the container 26 and the microservice provide a content container. Core content of the content data 10 is uniquely and universally identified using the blockchain address of the container program 28, along with the blockchain identifier. For example, the identifying information can include a 2-tuple, e.g. a finite ordered list of two elements, where the elements comprise the blockchain address and the numeral which corresponds with the identifier of the blockchain. The Ethereum blockchain has identifier 1 while the Polygon blockchain has identifier 137.
In
As can be seen in
With this structure, an unbounded number of vendor applications can have legal access to an unbounded number of the distributed containers, which in this exemplary embodiment are four in number, 26a-26d. All are able to execute the access policy which resides on a blockchain. All are able to route the resulting content stream to any user, and route royalty revenues to the contract owner.
In its final form, a container such as the container 26 (
As can be appreciated, the content data (and specifically the core content) is not itself physically persisted onto the blockchain but rather that access to the content data is exposed through a contract function. The process by which the content data (core content, snippet(s), preview(s), and/or metadata) is packaged with a container smart contract and associated distribution service begins with the deployment application 14 that accepts the content access policy 14 from the content deployer and codifies or complies that information to send to the deployment service 16. The deployment service 16 can also run within a frontend application, but in one embodiment (e.g. a preferred embodiment), can be run in a server that can handle many contract deployments. For each created container 26, the deployment service 16 will spawn a distribution microservice 24 as well as compile the smart contract program 28. Below is code, replete with explanatory comments, which can send the configuration of the initial access policy 12 to the deployment service 16, e.g. it enables the content deployer to specify, e.g., the asset title, data file, associated royalty splits, target blockchain, price per access, owner, and access grant time TTL (among other attributes):
The distribution microservice 24 which “backs” the content is designed such that it can be deployed and maintained by anyone/any service with non-transient computer or processor readable storage medium for storing the microservice processor executable code. These distribution microservices, which are a collection of services that interact with their respective smart contracts, we call a Decentralized Distribution Network. Decentralization is not achieved by enforcing that the content deployer run their own distribution service for the container, but rather by the fact that the container contract allows (only) the owner, preferably the content deployer, to update the contract to point to a different distribution service at any time with no impact to downstream consumers or vendors interacting with the contract program 28. Exemplary code for a distribution microservice such as a microservice 24, replete with explanatory comments, which verifies user/requester identity using cryptographic signatures and verifies access policy adherence by reading contract state on the blockchain is provided below:
In the select implementation above, specifically getGrantTimestampFromBridge, demonstrated is the issuance of a non-blockchain based access token to user/consumers by installing an opt-in encrypted token (cookie) onto a consumer device that is mapped to the contract state server side. This token is effectively an ephemeral decentralized identity. This method can be called “bridging”.
In one embodiment, a trusted application layer may pay the contract for the ability to sub-license the content to the user uniquely identified by the hardware based identity token, in exchange for consumer payment to the application for the service and associated sub-license. This transaction is atomic, e.g. the application is paid by the consumer and the contract is paid by the application, or the transaction does not complete. This method, which is an optional application specific layer of the larger distribution method disclosed, elides the requirement of the consumer using a digital wallet to transact with the content container contract.
Below, is exemplary code, replete with explanatory comments, that can be implemented as the deployment service 16 within the deployment server, the deployment server comprising non-transient computer or processor readable storage medium for storing deployment service executable code. The deployment server compiles the contract given the access policy configuration and content data and also spawns an embodiment of the distribution service 24 that is initially bound to the contract (though this server can be changed by the creator at any time). Effectively, this deployment server performs the containerization method.
The benefits of the disclosed containerization and distribution method can be best understood by considering the number of properties onto which a piece of digital content may be legally distributed with perpetual royalty revenue flow to the content deployers of the digital content, the speed of the royalty revenue flow from consumer to /content deployer or whomever is designated in the smart contract code, and the boolean quantity of whether the access policy (price and term length) may be controlled by the contract owner using a single implementation which applies to all properties.
As illustrated in
In contrast, as illustrated in
Aspects of the technology disclosed herein may be used to protect and monetize all digital content, such as audio, video, photo and text. News article monetization could be a derivative application of this technology. Additionally, this technology can be used for companies to improve internal privacy standards. By handling inbound data in the proposed format, rather than arbitrarily structured strings and binary blobs, terms of service and other access considerations can be directly encoded into the data and self-maintained by the content owner.
Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and should not be interpreted in an idealized and/or overly formal sense unless expressly so defined herein.
This detailed description has been presented for various purposes of illustration and description, but is not intended to be fully exhaustive and/or limited to this disclosure in various forms disclosed. Many modifications and variations in techniques and structures will be apparent to skilled artisans, without departing from a scope and spirit of this disclosure as set forth in various claims that follow. Accordingly, such modifications and variations are contemplated as being a part of this disclosure. A scope of this disclosure is defined by various claims, which include known equivalents and unforeseeable equivalents at a time of filing of this disclosure.
