Patent Application
20180322259
The present disclosure generally relates to digital rights management systems, apparatus, and methods.
The advent of digital media and analog-to-digital conversion technologies (especially those that are usable on mass-market general-purpose personal computers) has vastly increased the concerns of owners of digital content, including copyright-owners and organizations. These concerns are particularly prevalent within the music and movie industries, because these sectors are partly or wholly dependent on the revenue generated from such works.
A blockchain is a distributed database that maintains a continuously growing list of ordered records called blocks. Blocks typically contain a timestamp and a link to a previous block. By design, blockchains are inherently resistant to modification of the data—once recorded, the data in a block cannot be altered retroactively. Blockchains are “an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way. The ledger itself can also be programmed to trigger transactions automatically.” (see Iansiti, et al, “The Truth About Blockchain”. Harvard Business Review. Harvard University. January 2017.) Note that sometimes the term “blockchain” as found in the art is a compounded version of the term “block chain”, which term might be found in earlier art.
As changes occur in a blockchain environment, for example, when transactions occur, records concerning ownership of assets are recorded in a first blockchain ledger. When changes are made to the first blockchain ledger, other copies of the blockchain ledger, located on other blockchain servers, are also updated to reflect the chain.
The present disclosure will be understood and appreciated more fully from the following detailed description, taken in conjunction with the drawings in which:
In one embodiment, an instruction is received at a blockchain server from a first digital rights management (DRM) client, the instruction including an instruction to transfer a DRM license to an encrypted content item to a second DRM client. A block to be recorded in a blockchain, is created, the block including a content item ID of said encrypted content item, one of a device ID of a device including the second DRM client or a user ID of a user of the second DRM client, DRM license information for said DRM license, and a DRM decryption key for decrypting said encrypted content item. The block is recorded in the blockchain. A confirmation message is sent to the second DRM client confirming that the block was written to the blockchain. Related systems, methods, and apparatuses are also described.
Reference is now made to
Each of the client devices 150, 160, 170 comprises a client-server interface 180 for communication with the service provider 110, and more specifically the DRM server 120 and the first blockchain server 125. The client-server interface 180 may comprise separate interfaces for communications with the DRM server 120 and the first blockchain server 125 at the service provider 110, or may be a single interface operative to communicate with the DRM server 120 and the first blockchain server 125 of the service provider 110. Alternatively, the client-server interface 180 may comprise one set of hardware and processes which are dedicated to communication with the DRM server 120 and a second set of hardware and processes which are dedicated to communication with the first blockchain server 125. These two sets of hardware and processes may share some resources which are common to the hardware and processes of the client-server interface 180.
Each of the client devices 150, 160, 170 typically further comprise a DRM client 185, which communicates with the DRM server 120 of the service provider 110 via the client-server interface 180 of that client device 150, 160, 170. User input to the client device 150, 160, 170, and particularly user input which pertains to the operation of the DRM client 185 is via an appropriate user interface (UI) 190 disposed in each client device 150, 160, 170, as will be described below.
The client device 150, 160, 170 may attempt to obtain a piece of content, such as content item 115. The content item 115 may be obtained via a proprietary cloud 193, which is maintained by the service provider 110, or, alternatively, the content item 115 may be obtained via a public or proprietary cloud 197 which is not in the service provider's 110 domain.
It is noted that among the blockchain servers 130, 140, 199 with which the first blockchain server 125 is operatively associated, some of the other blockchain servers, such as blockchain server 140, may be disposed in one of the client devices, such as third client device 170. Additionally, some of the plurality of other blockchain servers may include blockchain server 199, which is located in the public or proprietary cloud 197, or other location, as is known in the art.
Reference is now made to
The client-server interface 180 sends the request for the content item 115 to the service provider 110, and a request for the DRM license 210 to the DRM server 120. The DRM server 120 sends the DRM license 210 to the DRM client 185 of the client device 150, via the client-server interface 180. Additionally, the DRM server 120 sends a notification to the first blockchain server 125 so that the first blockchain server 125 adds a record in its blockchain that ownership, or a usage right (such as the DRM license 210 ), has been granted by the service provider 110 to the first client device 150. It is appreciated that, as is known in the art, when the first blockchain server 125 updates its blockchain, the first blockchain server 125 also synchronizes its blockchain with other blockchain servers 130, 140, 199.
The present discussion of the flow of data in the system 100 of
A device ID or a user ID with which the first client device 150 is associated;
A content item ID of the content item 115 with which the DRM license is associated;
A license expiry date—which may, in principle, be any given amount of time, or, alternatively, the license may never expire, in which case the license expiry date field may not be populated;
A decryption key which is used to decrypt the content item 115;
A blockchain ID which uniquely associates the blockchain to a single instance of the content item 115;
A block ID which identifies a block within the blockchain; and
Terms of use or ownership, which may include that the content item 115: may/may not be sold; may/may not be rented to a second user; may/may not be transferred to a second device; may/may not be given to a second user, and if given to a second user, for how long may it be given; and so forth; and Other relevant information, as is known in the art.
Returning to the discussion of
At the time when the DRM license 210 is transferred from the client device 150 to the client device 160, one or both of the DRM clients 185 of the first and second client devices 150, 160 notify the DRM server 120 or the first blockchain server 125 at the service provider 110 that the license is to be transferred. The first blockchain server 125 confirms to the second client device 160 that the license to the content item 115 is legitimately held by the first client device 150. Upon confirmation, the first blockchain server 125 then records in its blockchain that the DRM license 210 has been granted to the second client device 160. As noted above, when the first blockchain server 125 updates its blockchain, the first blockchain server 125 also synchronizes its blockchain with other blockchain servers 130, 140, 199.
Should an attempt to consume the content item 115 be executed on the first client device 150, the DRM client 185 on the first client device 150 will contact one of the blockchain servers 125, 130, 140, 199 of
In some embodiments, prior to purchase of an instance of the content item 115, a potential purchaser will verify with one of the blockchain servers 125, 130, 140, 199 of
On the other hand, when an attempt is made to consume the content item 115 on the second client device 160, the DRM client 185 on the second client device 160 will contact the service provider 110 DRM server 120 in an attempt to verify ownership of the content item 115. The DRM server 120 will execute a query of the first blockchain server 125 blockchain, and determine that the second client device 160 owns a valid DRM license 210 to the content item 115. The DRM server 120 will notify the DRM client 185 on the second client device 160 of the results of the query. Accordingly, the DRM client 185 on the second client device 160 will play out (i.e. consume) the content item 115. Should the second client device 160 not have a valid DRM license 210 to the content item 115, then the DRM server may grant a license to the content according to a business arrangement between the owner of the client device 160 and the owner of the content or the service provider 110 (
At still a later stage, either the owner of the second client device 160 returns the rights to the content item 115 (i.e., the DRM license 210) to the owner of the first client device 150, or the loan/rental of the DRM license 210 expires. Then in a mirror image of the description above, the first blockchain server 125 updates its blockchain so that the blockchain now indicates that the DRM license 210 has been granted to the second client device 160. As per the description above, the second client device 160 will now no longer be able to legitimately consume the content item 115, and the first client device 150 now is able to legitimately consume the content item 115. It is appreciated that, as is known in the art, when the first blockchain server 125 updates its blockchain, the first blockchain server 125 also synchronizes its blockchain with other blockchain servers 130, 140, 199.
The following table summarizes the above discussion.
The first blockchain server 125 may, from time-to-time, execute a house cleaning routine which would delete expired blocks from the blockchain, so that the blockchain in the step of “User of second client device 160 returns content to user of first client device 150 (or transfer expires)”, which appears above in Table 1 as:
<SP 110 gave rights to content item XXX to user AAA>,
Reference is now made to
The exemplary device 300 is suitable for implementing any of the systems, methods or processes described above. The exemplary device 300 comprises one or more processors, such as processor 301, providing an execution platform for executing machine-readable instructions such as software. One of the processors 301 may be a special purpose processor operative to perform the method for piracy detection described herein above. Processor 301 comprises dedicated hardware logic circuits, in the form of an application-specific integrated circuit (ASIC), field programmable gate array (FPGA), or full-custom integrated circuit, or a combination of such devices. Alternatively, or additionally, some or all of the functions of the processor 301 may be carried out by a programmable processor microprocessor or digital signal processor (DSP), under the control of suitable software. This software may be downloaded to the processor in electronic form, over a network, for example. Alternatively, or additionally, the software may be stored on tangible storage media, such as optical, magnetic, or electronic memory media.
Commands and data from the processor 301 are communicated over a communication bus 302. The system 300 also includes a main memory 303, that may include: a Random Access Memory (RAM) 304, where machine-readable instructions may reside during runtime; and/or a secondary memory 305. The secondary memory 305 includes, for example, a hard disk drive 307 and/or a removable storage drive 308, representing a floppy diskette drive, a magnetic tape drive, a compact disk drive, a flash drive, etc., or a nonvolatile memory where a copy of the machine-readable instructions or software may be stored. The secondary memory 305 may also include ROM (read only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM). In addition to software, data representing the content item 115 or the DRM license 210 discussed herein throughout, and without limiting the generality of the foregoing, or other similar data, may be stored in the main memory 303 and/or the secondary memory 305. The removable storage drive 308 reads from and/or writes to a removable storage unit 309 in a well-known manner.
A user can interface with the exemplary device 300 via a user interface (including user interface (UI) 190 of
A network interface 319 is provided for communicating with other systems and devices via a network. The network interface 319 typically includes a wireless interface for communicating with wireless devices in the wireless community. A wired network interface (e.g. an Ethernet interface) may be present as well. The exemplary device 300 may also comprise other interfaces, including, but not limited to Bluetooth, and HDMI. The network interface may be a part of the client-server interface 180 of
The DRM client 350, the use of which is described above with reference to
It will be apparent to one of ordinary skill in the art that one or more of the components of the exemplary device 300 may not be included and/or other components may be added as is known in the art. The exemplary device 300 shown in
The DRM server 120 of
The blockchain server 125, 130, 140, 199 (all of
It is appreciated that the user interface (UI) 190 of
Reference is now made to
Accordingly, when the second client device 160 receives the rights to view the content item 115 (depicted here as if the content item 115 itself were moving from the first consumer device 150 to the second consumer device 160), the second client device 160 receives at least k of the n shares distributed among the various blockchain servers 125, 130, 140, 199. For example, in
Techniques for sharing a secret by dividing it into portions are known in cryptography, and are described, for example, in Shamir, Adi (1979), “How to share a secret”, Communications of the ACM, 22 (11): 612-613. Dividing and delivering the decryption key might use a larger amount of communications resources than might be used if there was one version of the decryption key. On the other hand, an attack whereby a single server and single compromised client could extract all decryption keys for all content item items 115 is largely prevented. Additionally, using an embodiment where the decryption key is divided up into multiple portions enhances traceability as several blockchain servers 125, 130, 140, 199 have visibility to a rendering operation, and could audit the transactions to prevent abuse.
In some embodiments the blockchain servers 125, 130, 140, 199 comprise time servers which are able to provide the DRM client 185 with secure time. As is known in the art, it is useful in DRM to know the correct time, in order to know when a license is still valid and when the license has expired. Having the DRM client 185 connect to the blockchain servers 125, 130, 140, 199 can help provide the DRM client 185 with a trusted source of time. An attacker might be able to compromise one or more servers among the blockchain servers 125, 130, 140, 199, but given the security surrounding each of the blockchain servers 125, 130, 140, 199, it is highly unlikely that the attacker will successfully compromise enough servers among the blockchain servers 125, 130, 140, 199 to fool the DRM client 185. This is particularly true in a “k of n” embodiment, where a number of the blockchain servers 125, 130, 140, 199 would have to provide the same time for the DRM client 185 to rely on the time provided. Accordingly, a message received at the DRM client 185 from one of the blockchain servers 125, 130, 140, 199 comprising a time stamp may be used by the DRM client 185 as a secure timestamp.
The simple case of a loan in the non-virtual world is where a lender gives a book (or a CD of a movie) to a borrower, and the borrower decides when to return the book (or the CD). However, in embodiments described herein, the lender (i.e., the user of client device 150) can also “take back” the digital item when needed. For example, the lender may issue a command through the user interface 190 to retrieve the content item 115 back from the borrower (i.e. the user of client device 160). This embodiment will support a loan such as “This eBook is yours for 30 days, unless I need it sooner”. This embodiment can also support an escrow service by which a seller gives the sold content item 115 to the buyer, but if the buyer's payment does not clear, the seller will be able to retrieve the sold content item 115.
In some embodiments where the owner is able to preemptively cancel a loan of the content item 115 before the period of the loan ends, the lender may use the user interface 190 to have the DRM client 185 send a revocation message to one of the DRM servers 125, 130, 140, 199. The original transfer of the DRM license may include a flag or other indication that the DRM client 185 may (or may not) send such a revocation message to one of the of the DRM servers 125, 130, 140, 199.
In still another embodiment, if an owner of the content item 115 loans the content item 115 to two or more people, then one of the loaned copies of the content item 115 will continue to operate. In some embodiments, the originally loaned content item will continue to operate. Alternatively, the last loaned copy will copy which continues to operate.
Alternatively, if the terms of the original DRM license 210 are such that, for example, the content item may be consumed four times, (for example, a movie may be watched four times under the terms of such a DRM 210 license) the original holder of the license (i.e. the user of client device 150) may simultaneously lend out up to four copies of the content item 115, each one of which may be consumed once. It is appreciated that one of those four copies would be in lieu of the user of client device 150 maintaining his or her copy of the DRM license 210. In such a case, a block in the blockchain which indicates that the DRM license is for up to four copies of the content item 115 may spawn up to three child blocks.
Reference is now made to
At step 520, a block to be recorded in a blockchain is created, the block including a content item ID of said encrypted content item 115, one of a device ID of a device including the second DRM client 160 or a user ID of a user of the second DRM client 160, DRM license information for said DRM license and a DRM decryption key for decrypting said encrypted content item. The block is recorded in the blockchain (step 530).
At step 540, a confirmation message is sent to the second DRM client 160 confirming that the block was written to the blockchain.
It is appreciated that software components of the present invention may, if desired, be implemented in ROM (read only memory) form. The software components may, generally, be implemented in hardware, if desired, using conventional techniques. It is further appreciated that the software components may be instantiated, for example: as a computer program product or on a tangible medium. In some cases, it may be possible to instantiate the software components as a signal interpretable by an appropriate computer, although such an instantiation may be excluded in certain embodiments of the present invention.
It is appreciated that various features of the invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable sub-combination.
It will be appreciated by persons skilled in the art that the present invention is not limited by what has been particularly shown and described hereinabove. Rather the scope of the invention is defined by the appended claims and equivalents thereof:
