Patent Description:
Digital media, for example digital books ("eBooks"), have gained popularity over the last two decades and continues to be a growing market. A common problem of this industry is the unauthorized copying and distribution of the digital media.

To prevent unauthorized copying and distribution of digital media many organizations utilize digital right management (DRM). DRM formats are various access control technologies that are used to restrict the usage of digital media in different ways. For example, some DRM formats restrict access to copy functionalities, which restricts what can be done with the digital media.

Unfortunately, organizations have struggled with the usage of DRM because DRM formats are not generally universally accepted. When used in a vertical market, for example, DRM often limits the portability of the digital media to other platforms outside of the vertical market.

Further, some opponents to these vertical market DRM contend there is no evidence that DRM helps prevent copyright infringement, and instead serves only to inconvenience legitimate customers.

Organizations attempting to build DRM formats that are transferable from one platform to another (therefore not linked to a specific vertical market) also encounter difficulties. Costs and technological difficulties of creating and maintaining such digital copyrights can be substantial.

There remains therefore a desire for DRM related technology that addresses some of the above inconveniences. <CIT> describes systems and methods for decentralizing commerce and rights management for digital assets using blockchain rights ledger. In a playback device, a processor receives a first new block created and distributed by a first blockchain management device, updates a decentralized blocking rights ledger with the first new block, obtains an encrypted digital media work, generates a digital representation of the digital media work, locates a platform license transaction corresponding to the digital representation, decrypts an encrypted content key using a private key of a public and private key pair associated with the platform, decrypts content from the digital media work using the decrypted content key, and plays back the decrypted content. <CIT> describes a system and a method for achieving authorization in confidential group communications in terms of an ordered list of data blocks representing a tamper-resistant chronological account of group membership updates. This method permits ad-hoc and decentralized group definition, dynamic and decentralized membership updates, open sharing, tamper resistance, and tracking of membership history. There are many applications of these techniques. One such application is enabling end-to-end encryption of instant messaging, content sharing, and streamed media. <CIT> describes a method, performed by a computer device, that includes receiving an indication that a first user has acquired rights to access a digital content; generating a key for the digital content; encrypting the digital content using the generated key to generate encrypted digital content; obtaining a first passcode; and providing the first passcode and the encrypted digital content to a user device associated with the first user. The method further includes receiving, from the user device, a request for the key, wherein the request includes the first passcode; determining that the first passcode is valid; determining that the key has not expired; and providing the key to the user device, in response to determining that the first passcode is valid and that the key has not expired.

It is thus an object of the present technology to ameliorate at least some of the inconveniences present in the prior art.

Developers of the present technology have developed embodiments thereof based on their realization of at least one technical problem associated with the prior art solutions for digital rights management.

In order to provide limited distributions of digital works and preventing illegal copying of such works, while keeping their portability through different platforms, the present technology integrates the digital right (the copyright) of a digital work, for example an eBook, into an existing distributed database called blockchain. Information about ownership or access rights, as well as a key for decrypting an encrypted copy, are encapsulated into a code to manage the digital rights which are then recorded to the blockchain. The blockchain provides a secure and accessible transaction record of ownership or rights, encapsulated separately from the digital document. As such, encrypted copies can be moved between devices or systems, but remain accessible to the rightful owner. This ensures that copyrights of the eBook are protected, while keeping the digital file portable and cost efficient.

The present technology provides systems and methods to support copyright management (creating, assigning, securing and modifying) of digital rights. For example, when a user buys an eBook, the digital media will activate the digital rights private and public keys, including in some cases a smart contract, in the blockchain and link the digital right to that user digital document representing the eBook. When a user opens their purchased eBook, the digital media validates through the blockchain its right of use by validating private and public keys. When the user wants to resell their digital right (the user wishes to sell their eBook to another user), a payment notification will be sent to the buyer email address and after processing the payment, the payment processor will send a notification to the blockchain in order to modify the private key and link it to the new owner of the digital right.

In the context of the present specification, unless specifically provided otherwise, a "server" is a computer program that is running on appropriate hardware and is capable of receiving requests (e.g. from client devices) over a network, and carrying out those requests, or causing those requests to be carried out. The hardware may be one physical computer or one physical computer system, but neither is required to be the case with respect to the present technology. In the present context, the use of the expression a "server" is not intended to mean that every task (e.g. received instructions or requests) or any particular task will have been received, carried out, or caused to be carried out, by the same server (i.e. the same software and/or hardware); it is intended to mean that any number of software elements or hardware devices may be involved in receiving/sending, carrying out or causing to be carried out any task or request, or the consequences of any task or request; and all of this software and hardware may be one server or multiple servers, both of which are included within the expression "at least one server".

In the context of the present specification, unless specifically provided otherwise, "user device" is any computer hardware that is capable of running software appropriate to the relevant task at hand. Thus, some (non-limiting) examples of user devices include personal computers (desktops, laptops, netbooks, etc.), smartphones, and tablets, as well as network equipment such as routers, switches, and gateways. It should be noted that a device acting as a user device in the present context is not precluded from acting as a server to other user devices. The use of the expression "a user device" does not preclude multiple client devices being used in receiving/sending, carrying out or causing to be carried out any task or request, or the consequences of any task or request, or steps of any method described herein.

In the context of the present specification, unless specifically provided otherwise, a "database" is any structured collection of data, irrespective of its particular structure, the database management software, or the computer hardware on which the data is stored, implemented or otherwise rendered available for use.

In the context of the present specification, unless specifically provided otherwise, the expression "information" includes information of any nature or kind whatsoever capable of being stored in a database. Thus information includes, but is not limited to audiovisual works (images, movies, sound records, presentations etc.), data (location data, numerical data, etc.), text (opinions, comments, questions, messages, etc.), documents, spreadsheets, etc..

In the context of the present specification, unless specifically provided otherwise, the words "first", "second", "third", etc. have been used as adjectives only for the purpose of allowing for distinction between the nouns that they modify from one another, and not for the purpose of describing any particular relationship between those nouns. Thus, for example, it should be understood that, the use of the terms "first server" and "third server" is not intended to imply any particular order, type, chronology, hierarchy or ranking (for example) of/between the server, nor is their use (by itself) intended imply that any "second server" must necessarily exist in any given situation. Further, as is discussed herein in other contexts, reference to a "first" element and a "second" element does not preclude the two elements from being the same actual real-world element. Thus, for example, in some instances, a "first" server and a "second" server may be the same software and/or hardware, in other cases they may be different software and/or hardware.

In the context of the present specification, unless specifically provided otherwise, a blockchain is a distributed database, meaning "a database in which storage devices are not all attached to a common processor. It may be stored in multiple computers, located in the same physical location; or may be dispersed over a network of interconnected computers" (source Wikipedia) or over any other devices, for example, over one or more devices of an internet of things.

Implementations of the present technology each have at least one of the above-mentioned object and/or aspects, but do not necessarily have all of them. It should be understood that some aspects of the present technology that have resulted from attempting to attain the above-mentioned object may not satisfy this object and/or may satisfy other objects not specifically recited herein.

The examples and conditional language recited herein are intended to aid the reader in understanding the principles of the present technology and not to limit its scope to such specifically recited examples and conditions. It will be appreciated that those skilled in the art may devise various arrangements which, although not explicitly described or shown herein, nonetheless embody the principles of the present technology and are included within its scope.

Moreover, all statements herein reciting principles, aspects, and implementations of the present technology, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof, whether they are currently known or developed in the future. Thus, for example, it will be appreciated that any flowcharts, flow diagrams, state transition diagrams, pseudo-code, and the like represent various processes which may be substantially represented in computer-readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

The functions of the various elements shown in the figures, including any functional block labeled as a "processor" may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. In some embodiments of the present technology, the processor may be a general purpose processor, such as a central processing unit (CPU) or a processor dedicated to a specific purpose, such as a graphics processing unit (GPU). Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage.

Referring to <FIG>, there is illustrated a system <NUM> suitable for implementing non-limiting embodiments of the present technology. It is to be expressly understood that the system <NUM> is depicted as merely as an illustrative implementation of the present technology and the following is intended to be only a description of illustrative examples of the present technology. This description is not intended to define the scope or set forth the bounds of the present technology.

The system <NUM> includes an electronic device <NUM>. The electronic device <NUM> is typically associated with a user (not depicted) and, as such, is also referred to as a "user device". It should be noted that the fact that the electronic device <NUM> is associated with the user does not need to suggest or imply any mode of operation - such as a need to log in, a need to be registered or the like.

In the methods presented herein below, the electronic or user device <NUM> is used to represent two distinct parties utilizing an electronic device such as the user device <NUM>: both an end user referred to as an "originator" and an end user simply referred to as "user. " While these are two different types of persons or companies utilizing the user device <NUM>, there is no substantial difference between the device <NUM> used by the two parties.

The implementation of the electronic device <NUM> is not particularly limited, but as an example, the electronic device <NUM> may be implemented as a personal computer (desktops, laptops, netbooks, etc.), a wireless electronic device (a cell phone, a smartphone, a tablet and the like), as well as network equipment (a router, a switch, or a gateway). The electronic device <NUM> includes at least a processor <NUM> for executing software, and a memory module <NUM>. The particular details of neither the processor <NUM> nor the memory module <NUM> are especially limiting, and will not be described further herein.

The system <NUM> includes a communication network <NUM>. In some non-limiting embodiments of the present technology, the communication network <NUM> can be implemented as the Internet. In other embodiments of the present technology, the communication network <NUM> can be implemented differently, such as any wide-area communication network, local-area communication network, a private communication network and the like. The electronic device <NUM> is coupled to the communication network <NUM> via a communication link. How the communication link is implemented is not particularly limited and will depend on how the electronic device <NUM> is implemented.

The system <NUM> also includes a server <NUM> connected to the network <NUM>. The server <NUM> can be implemented as a conventional computer server. The server <NUM> can be implemented in any other suitable hardware and/or software and/or firmware or a combination thereof. In the depicted non-limiting embodiment of present technology, the server <NUM> is a single server. In alternative non-limiting embodiments of the present technology, the functionality of the server <NUM> may be distributed and implemented via multiple servers. The server <NUM> is coupled to the communication network <NUM> via a communication link (not separately numbered). How the communication link is implemented is not particularly limited and will depend on how the server <NUM> is implemented.

The server <NUM> is operatively coupled to a memory module <NUM>. Memory module <NUM> may encompass one or more storage media and generally provide a place to store computer code (e.g., software and/or firmware). The memory module <NUM> can be implemented in various ways, including but not limited to: tangible computer-readable storage media including Read-Only Memory (ROM) and/or Random-Access Memory (RAM), one or more fixed storage devices such as hard disk drives (HDDs), solid-state drives (SSDs), flash-memory cards (e.g., Secured Digital or SD cards, embedded MultiMediaCard or eMMD cards). In some implementations, the memory module <NUM> could be replaced by a stand alone database operatively connected to the server <NUM>, via the network <NUM> or directly connected to the server <NUM>.

The memory module <NUM> stores inter alia a series of computer-readable instructions, which instructions when executed cause the processor <NUM> of the server <NUM> to execute the various operations and methods described herein.

In some non-limiting embodiments of the present technology, the system <NUM> includes a database <NUM> for data storage external to the user device <NUM> and the server <NUM> (but operatively connected thereto). In some implementations, the database <NUM> could be implemented as a cloud storage service. In other implementations, the database <NUM> could be one or more memory modules of a server or other computer-implemented system.

Both the user device <NUM> and the server <NUM> are operatively connected to a rights blockchain <NUM> via the network <NUM>. While the blockchain <NUM> is identified as a part of the physical system <NUM>, it should be noted that the blockchain <NUM> is in fact a large dataset acting as an open ledger for recording transactions, supported in servers and databases in a decentralized fashion. The server <NUM> is connected, via the network <NUM>, to the blockchain <NUM> through any one of many computer devices accessing or supporting the blockchain <NUM>.

Blockchain technology is most commonly known as the technology behind the popular cryptocurrency, Bitcoin. A blockchain creates a history of data deposits, messages, or transactions in a series of blocks where each block contains a hash (a mathematical summary) of the previous block. This creates a chain where any changes made to a block will change that block's hash, which must be recomputed and stored in the next block. This changes the hash of the next block, which must also be recomputed and so on until the end of the chain. Generally, this discourages changes to blocks due to the increasing difficulty created when the chain of blocks begins to have a significant length. Thus the blockchain is inherently resistant to modification of the data stored in the blocks.

The security of a blockchain is further increased by implementing it on a distributed network. This means a large number of users all have access to the blockchain and are all attempting to add blocks to the end of the chain. For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for validating new blocks. Once recorded, the data in any given block cannot be altered retroactively without the alteration of all subsequent blocks, which requires a consensus of the network majority.

Blockchains on a distributed network with sufficiently restrictive rules for creating valid blocks are fairly secure against unauthorized changes to the data stored in them. This makes blockchains particularly useful for recording transactions. In the present technology, the inventors have determined that such secure recording of transactions can help address the issues discussed above with respect to distributing media that is protected by copyright (for example), without resorting to some of the prior art Digital Rights Management (DRM) technologies with the inconveniences described above.

The blockchain <NUM> is illustrated as a separate entity from the server <NUM>, but it is contemplated that the server <NUM> may host a portion of the blockchain <NUM> in some implementations. The blockchain <NUM> used in the present technology can be either a public or private blockchain. The blockchain <NUM> can also be implemented as a blockchain maintained solely for the purposes of the present technology, as a private or public blockchain, or can be integrated into an existing blockchain entity, including but not limited to: Ethereum, Bitnation, and any other blockchain developed using blockchain platform development such as Hyperledger, Nuco, etc..

Given the architecture described above, as well as using the various examples provided above, it is possible to execute a method of providing limited distribution of digital media files, as well as methods of exchanging and accessing copies of digital media files.

Specifically, the methods described herein provide a way to distribute digital works, generally subject to copyright, in a way that allows approved users to access the digital work, while aiding in prevention of prohibited copying or distribution.

With reference to <FIG> and <FIG>, there is depicted a method <NUM> implemented in accordance with non-limiting embodiments of the present technology. The method <NUM> is executed by the processor <NUM> of the server <NUM>. To that end, the memory module <NUM> stores computer executable instructions, the instructions when executed cause the processor <NUM> to execute the method <NUM>.

The method <NUM> starts at step <NUM>, where the server <NUM> receives a digital media file from an originator using the user device <NUM>. Generally, the server <NUM> hosts a user interface, for example a web portal or platform, which the originator accesses using a web browser run on the user device <NUM>. In some implementations, the server <NUM> could receive the digital media file via a file transfer protocol (FTP). In other implementations, the server <NUM> could receive the digital media file from the database <NUM>, the originator having uploaded the digital media document to the database <NUM> from the user device <NUM>. It is also contemplated that the server <NUM> could receive the digital media file through an application, residing on the user device <NUM> or an other electronic device (computer, a mobile device, etc.) developed to create digital documents, the application including a functionality to connect with the server <NUM> in order to exchange the digital media file through an application programming interface (API).

The digital media file described herein generally applies to a digital literary document or work, such as an eBook in ePub3 format, but need not be so limited. The present technology can be applied to eBooks of different formats including but not limited to: any ePub format, Microsoft Word, Adobe PDF, Amazon digital file, Apple iBooks, and Open XML.

The digital media file could also be one or any number of different artistic works in electronic form. These works could include but are not limited to: audio books, digital music files, digital sound recordings in general, software and software code, poems, theses, other literary works, motion pictures, digitized visual arts such as paintings or drawings, digital photographs, industrial designs, and graphic designs.

The originator of the digital media file will generally be assumed to be an author of the work of the digital media file herein, but this is not necessarily the case. In some implementations, the originator could be the copyright owner, copyright assignee, or the exclusive licensee, for example. In the case of an eBook, for example, it is contemplated that the originator could be a publishing company that wishes to distribute electronic copies of an eBook containing a work of literature to which the publishing company owns the copyright. It is also contemplated, for example, that the originator could be a library which has procured the rights to lend copies of a particular eBook to its library members.

In some embodiments of the method <NUM>, the server <NUM> could query the user device <NUM> as to whether the digital media file should be stored on the server <NUM> (in the memory module <NUM>) and/or in the external database <NUM> upon receipt of the digital media file. If the originator sends, via the user device <NUM>, a confirmation that the digital media file should be stored by the server <NUM>, the server <NUM> could then save the digital media file to the memory module <NUM>. In some implementations, the server <NUM> could store the digital media file in the database <NUM>. It is also contemplated that in some embodiments of the method <NUM>, the server <NUM> could query the user device <NUM> as to whether the digital media file should be stored or recorded to the blockchain <NUM>. The digital media file could be recorded to a single block of the blockchain <NUM>. In some cases, the digital media file could be partitioned into subpackets of data and recorded to different blocks on the blockchain <NUM>. The method <NUM> would then further include creating an assembly key for reassembling the subpackets into the complete digital media file.

The method <NUM> then proceeds to executing step <NUM>.

The method <NUM> then continues to step <NUM>, where the server <NUM> encrypts the digital media file to create an encrypted version of the digital media file. The encryption can be carried out in a variety of methods, including but not limited to: AES, Triple DES, RSA, Blowfish, and Twofish.

As mentioned above, in some implementations the digital media file could be partitioned into subpackets and recorded to the blockchain <NUM>. It is contemplated that each of the subpackets of the digital media file could also be separately encrypted and then recorded to the blockchain <NUM>. In such a case, each encrypted subpacket would have corresponding public and private keys, in addition to the assembly key for reassembling the digital media file. As will be described in more detail below, the public key for each one of the subpackets could be separately recorded to the blockchain <NUM>.

It is contemplated that the encryption of the digital media file could include separately encrypting portions of the digital media file. For example, in implementations where the digital media file is an eBook, each chapter could be separately encrypted, allowing for the originator to provide access rights to only some of the portions of the digital media file. In another non-limiting example, the digital media file could be a music album, and the encryption could be carried out separately for each song of that album.

At step <NUM>, the server <NUM> creates multiple copies of the encrypted digital media file. The number of copies made in the method <NUM> corresponds to the number of copies that the originator desires to allow to circulate, as will be described in more detail below. In some implementations, the copies could be made by the user device <NUM>, and then encrypted.

At step <NUM>, the method <NUM> continues when the server <NUM> creates a plurality of rights tokens. The term "token" should be understood, in the context of the present technology, simply as a representation of a set of data linked to the right to access a given copy of the digital media file. The term "token" is used to reflect the exchangeable but unitary nature of the present technology to cryptocurrency, but it should be noted that the present technology is not cryptocurrency nor does it necessarily utilize the same methods, code and/or technology.

One rights token is created for each one of the encrypted copies of the digital media file, and the total quantity of rights tokens matches the number of encrypted copies. Each token contains a key for decrypting a corresponding one of the encrypted copies, and identifying information related to access rights for the encrypted copy.

Specifically, each token contains ownership information (who ever is allowed to decrypt the encrypted copy), and the key, password, or code necessary to decrypt it. It should be noted that the "ownership" recorded in the rights tokens are not limited to full, legal ownership, but may instead represent temporary access. For example, in the case where the rights tokens are used to manage lending in an electronic library system, the "ownership" detailed in the rights tokens could represent the user who has "checked out" the file and who has temporary access rights.

In some implementations of the present technology, the server <NUM> could query the user device <NUM> to determine a desired number of copies of the digital media file to allow for distribution, and the number of rights tokens and encrypted copies created then corresponds to that desired number of copies. It is also contemplated that the server <NUM> could query the user device <NUM> at earlier steps in the method <NUM>.

The key described herein is not meant to be limiting. Generally, the key of the rights token is a public key which has a corresponding private key embedded in the encrypted document. The encrypted copy can then be decrypted when the correct public key is extracted from the rights token. Generally, is in many implementations of a blockchain, the key received from the blockchain <NUM> (when attempting to decrypt the encrypted copy) is a hashed version of the Public key. The private key, incorporated with or encapsulated in the encrypted copy, is used to derived the public key from the hashed version.

In some implementations of the present technology, the method <NUM> could further include encapsulating a smart contract into the encrypted copies and/or the rights tokens. The smart contract for each digital media file includes code for managing its digital rights. The different controls that could be included in the smart contract for a given digital media file, or for a portion of the encrypted copies of a given digital media file, include (but are not limited to): expiry dates, limits on reselling, and limits on loaning or gifting. This will be described in more detail below.

The smart contracts are written in a JavaScript-style language called Solidity, but this is not meant to be limited. It is contemplated that different languages could be employed, including but not limited to: Java, Python, CSS, PHP, Ruby, C++, C, Shell, C#, Objective C, VmL, Go, and Perl.

In some implementations of the method <NUM>, the server <NUM> further receives, from the originator, information related to the desired controls to be placed on the plurality of encrypted copies to be embodied by the smart contract. In such implementations, the server <NUM> could receive the control information with the initial submission of the digital media file in step <NUM>. In other such implementations, the method <NUM> could also include querying the user device <NUM> about desired controls, and the originator, via the user device <NUM>, could provide the control information in response to the query. As mentioned above, the control information (received or requested from the user device <NUM>) could any number of variables related to access and use of one or more of the copies of the digital media file. The method <NUM> would then further include creating the smart contract for managing distribution of the plurality of copies of the digital media file based on and including the control information.

The method <NUM> would then continue with encapsulating the smart contract each one of the rights tokens. Encapsulating the smart contract into the rights tokens is generally performed using database commands. The specific commands generally could vary, depending on, for example, the database type the blockchain is using for a specific implementation. It is contemplated that the smart contract could be encapsulated with its corresponding encrypted copy in some non-limiting implementations.

While referred to as the "smart contract" herein, it is contemplated that in some implementations the "smart contract" may not be active code stored to the blockchain <NUM> (such as in the style of Blockchain <NUM>). Rather, it should be understood that the smart contract could, in some implementations, be limitations or conditions encoded into the rights token and/or encrypted document, without being an active, code-based smart contract in the blockchain <NUM>.

For aid in understanding some aspects of the smart contracts, one non-limiting example of an implementation is as follows. The smart contract could indicate an end date for the access rights for the digital media file. The method <NUM> would then further include receiving a request to access a given copy of the digital media file from an electronic device of an end consumer, determining that the request was sent after the end date recorded in the smart contract; and sending an indication to the end user device that the given copy of the digital media file cannot be accessed.

The method <NUM> then proceeds to step <NUM>.

At step <NUM>, the server <NUM> records, via the network <NUM>, the rights tokens to the rights blockchain <NUM>. As mentioned above, the blockchain <NUM> is an open (but encrypted) distributed ledger representative of actions related to distribution of the plurality of copies of the encrypted the digital media file, wherein the ownership of access rights for a particular digital work (and transactions related thereto) can be recorded and verified.

The rights tokens are recorded to one or more new blocks <NUM> of the blockchain <NUM>, (see <FIG>). As the rights tokens also include the key necessary to decrypt the encrypted files, the blockchain <NUM> also serves as a storage and access point for the decryption data. As such, utilizing the blockchain <NUM> allows both verification of the ownership or access rights and accessing the decryption key to be done in a compact manner. Further, by connecting the decryption information with the confirmation of ownership/access rights, the process of transferring the rights and the decryption key is also facilitated.

When the rights tokens are first created and recorded to the blockchain <NUM>, the ownership for each encrypted copy is assigned to the originator (as the originator is still the copyright holder at this time). Generally, the originator also receives the encrypted copies, or indications of the stored encrypted copies when the method <NUM> has completed.

In some implementations, the originator may also request that at least one encrypted copy to be stored directly to the rights blockchain <NUM>. The method <NUM> could include, in some cases, recording one or more encrypted copy to a block of the blockchain <NUM>.

In some implementations, the server <NUM> could determine that a file size of the encrypted copy exceeds a storage capacity of a block of the rights blockchain <NUM> and that the encrypted copy needs to be partitioned into multiple files in order to be recorded to the blockchain <NUM>.

The method <NUM> could then include subdividing the digital media file into a plurality of subpackets of information and encrypting each of subpackets of information. In some cases, the encryption could be carried out using the same methods as encrypting the full digital media file, or a different method could be used depending on the specific implementation or file. In such a case, each one of the subpackets would have a corresponding rights token (including its public key).

The method <NUM> would then include the server <NUM> creating an assembly key for reassembling the subpackets of information into a full document. The method <NUM> would then continue with recording the subpackets of information to the rights blockchain <NUM> over multiple blocks of the rights blockchain <NUM>. In such an implementation, the assembly key would be incorporated into the corresponding rights token for that encrypted copy.

As is mentioned above, in some implementations the digital media file itself could be first partitioned into subpackets, each subpacket then being encrypted and recorded to the blockchain <NUM>. In such an implementation, the public key for each one of the subpackets would be separately recorded to the blockchain <NUM> in its own rights token. The rights tokens corresponding to all of the subpackets would be linked, and ownership of all such rights tokens would be recorded for the originator. As such, the owner of the digital media file would have secure access to the stored digital media file via the blockchain <NUM> (in addition to the encrypted copies created for distribution by the method <NUM>).

As is described above, the number of rights tokens created is equal to the limited number of encrypted copies the originator desired to have to securely distribute. By recording the rights tokens to the blockchain <NUM>, the tokens may be exchanged (bought and sold) but they cannot be added (without recommencing the method <NUM>). Further, if unauthorized copies are made of the encrypted copies, no corresponding token will exist in the blockchain <NUM>, and the unauthorized copy will not be usable. As such, the originator is provided with a limited number of copies for distribution of the digital media file. If the originator decides to create more encrypted copies to increase distribution, similar to a second printing for physical book distribution, the method <NUM> can be recommenced and performed in addition iterations.

Further, as the rights token identifies the party that has access rights and is kept separate from the encrypted copy, the encrypted copy is fairly portable for the legitimate user of the copy. For example, the user can move the encrypted copy from a computer to a smart phone, and still be able to open and decrypt the encrypted copy. According to the present technology, the user could access their copy of the digital media file on any device that has a web browser and an internet connection.

The method <NUM> can then terminate. Alternatively, the method <NUM> can further include additional steps such as those that follow.

As discussed above, the encrypted copies can be stored in or by various systems. In some implementations of the method <NUM>, the server <NUM> could record the plurality of the encrypted copies to the rights blockchain <NUM>. In some implementations, the method <NUM> further includes storing the encrypted copies to the memory <NUM> of the server <NUM>. It is also contemplated that the method could further include storing, via the network <NUM>, the encrypted copies to the external database <NUM> operatively connected to the network <NUM>. In some such implementations, the method <NUM> could further include recording a link to the copies stored in the database <NUM> to the rights blockchain <NUM>, either with or separate from the rights token.

As mentioned above, in some implementations, the method <NUM> could also include querying the originator as to a desired storage location for the encrypted copies, as well as a desired number of encrypted copies to be made.

In various implementations of the method <NUM>, the server <NUM> could query the originator, via the user device <NUM>, for various options related to the distribution or the desired controls (as discussed above).

In implementations of the method <NUM> where the smart contract has been created, some implementations of the smart contract could indicate an end date for access rights, as discussed above. It is contemplated that the originator could be queried by the server <NUM> as to a desired end date at various steps in the method <NUM>. In some implementations, a start date or a limited period of use could be controlled or indicated in the smart contract.

In some implementations, the method <NUM> could also include querying the originator, via the user device <NUM>, as to whether any end users are to be allowed any one of the encrypted copies to be shared on any one of various social media platforms. Upon receiving a positive confirmation from the user device <NUM> to allow the encrypted copies to be shared on one or more social media platforms, the method <NUM> could further include encoding at least one encrypted copy of the digital media file for sharing over one or more social networking platforms. It is contemplated that the permissions to share on a social media platform could be incorporated into the smart contract.

In some implementations, the method <NUM> could also include querying the originator, via the user device <NUM>, whether to allow the encrypted copies to be rented, shared, or loaned. In such implementations, the method <NUM> could further include querying the originator about a desired price for loaning, a percentage of that price to be sent to the originator, to who the copy can be loaned, etc. It is also contemplated that the permissions for sharing or loaning could be incorporated into the smart contract.

In some implementations, the method <NUM> could also include querying the originator, via the user device <NUM>, as to whether an end user should be allowed to give away or gift their encrypted copy. This querying could further include querying to whom the end user is allowed to gift their encrypted copy. It is also contemplated that the permissions for gifting an encrypted copy could be incorporated into the corresponding smart contract.

In some implementations, the method <NUM> could further include querying the user, via the user device <NUM>, as to whether resale of a given encrypted copy is to be permitted. The querying could further include determining to whom it can be resold, at what cost, and what percentage of such a cost is to be redirected to the originator or a third party, etc. It is also contemplated that the resale permissions and conditions could be incorporated into the smart contract.

With the method <NUM> being completed as above, the originator has now been provided with a limited set of encrypted copies of the digital media file to distribute, where the rights are managed by the rights tokens recorded to the rights blockchain <NUM>. As mentioned above, the originator is generally recorded as the "owner" of each of the encrypted copies, and is now free to sell, rent, loan, share or gift each of the encrypted copies.

The method <NUM> can then, in some implementations, be continued or resumed for interactions with end users- specifically, consumers who have rented, bought, or otherwise acquired from the originator the access rights for a given encrypted copy of the digital media file. For instance, once the originator has sold access to one of the encrypted copies to an end consumer, the method <NUM> could continue as follows.

In order to distinguish from the user device <NUM> of the originator, the device <NUM> associated with a consumer shall be referred to hereafter as the reader device <NUM>. It should be noted, however, that the digital media file is not limited to literary documents and may be sound files, video files, etc..

First the server <NUM> receives, from the reader <NUM>, a request to access a given copy of the encrypted digital media file, the request including user identifying information related to the consumer utilizing the reader device <NUM>. The request could be received in various ways. For example, upon opening the encrypted copy on the reader device <NUM>, the reader device <NUM> could automatically send a request to the server <NUM> for the decryption key in order to display a decrypted version of the encrypted digital media file.

Then the server <NUM> verifies the access rights of the consumer by comparing the identifying information contained in a corresponding one of the plurality of rights tokens to the user identifying information. If the identifying information matches, the server <NUM> provides the reader device <NUM> with the key from the rights tokens for decrypting the encrypted copy of the digital media file on the reader device <NUM>.

It is contemplated that the steps described above, such as sending the identifying information and receiving the key could take place automatically, or nearly. For instance, in some implementations, the application for reading an eBook could prompt the reader to enter information, such as a password, in order to confirm identity information and the run the verification and decrypting in the background.

It is contemplated that the method <NUM> could include additional or different steps, either to perform additional functions and/or to perform the steps described above. Additionally, certain steps could be performed in an assortment of different sequences, depending on for example user preferences, and is not limited to the order set forth in the explanation above.

With reference to <FIG>, there is depicted a flow chart of a method <NUM>, the method <NUM> being implemented in accordance with additional non-limiting embodiments of the present technology. The method <NUM> is executed by the user device <NUM>, where the processor <NUM> executes the method <NUM>. In some implementations, the instructions for method <NUM> could be saved to the memory module <NUM> of the user device <NUM>. It is also contemplated that the instructions for the method <NUM> could be provided to the user device <NUM> via the network <NUM>.

It should be noted that while the method <NUM> is executed by the electronic device <NUM>, being a computer, tablet, smartphone, etc., as described above with respect to the system <NUM>, the user operating the user device <NUM> is distinct from the user discussed in regards to the method <NUM>. The operator of the user device <NUM> of the method <NUM> is an end user or consumer of at least one copy of the digital media file, for example a reader of an eBook, encrypted copies of the eBook having been created and distributed using the method <NUM> above. As such, the user device <NUM> of the method <NUM> will be referred to as a "reader device" <NUM>, to distinguish from the above.

The method <NUM> begins with step <NUM>, when the reader device <NUM> sends a request to gain access to the copy of the digital media file to a server, either the server <NUM> or some other server operatively connected to the blockchain <NUM>, via the network <NUM>.

In some implementations, the request from the reader device <NUM> includes either a payment or payment information in order to purchase the access rights for the encrypted copy of the digital media file. In some other implementations, the request could include subscription information for an electronic library system. In some implementations, the request can be sent from the reader device <NUM> via an online platform or portal.

The method <NUM> continues with step <NUM>, where the reader device <NUM> receives an indication of an encrypted version of the copy of the digital media file from the server of step <NUM>. The indication is any one of: a website address for accessing the encrypted version of the copy via the network <NUM>, a website address for downloading the encrypted version of the copy to the reader device <NUM>, and the encrypted version of the copy to be stored to the reader device <NUM>.

The method <NUM> then proceeds to step <NUM>.

The method <NUM> continues with step <NUM>, with the reader device <NUM> receiving, from the server, a confirmation of access rights. This confirmation generally includes information for exchanging the rights token associated with the copy. In some implementations, this information and/or confirmation includes the proof of payment from the step <NUM>. In implementations where the request of step <NUM> includes, for instance, subscription information for an eBook library, the information could include a confirmation of access rights based on the subscription.

The method <NUM> continues with step <NUM>, causing, by an application of the reader device <NUM>, the rights blockchain <NUM> to be updated to record the exchanging of the rights token. By recording the exchange of the rights token to the rights blockchain <NUM>, the ownership or access rights are transferred. By the present technology, access is controlled by confirming ownership through the blockchain <NUM> (and retrieving the decryption key therefrom once confirmed). Thus, the new owner or borrower can subsequently access/open/decrypt their purchased or borrowed copy of the digital media file thereafter.

As with most blockchain technology, exchanging the rights token includes recording that the rights token has been withdrawn from the previous owner, and recording rights token as having been given to the new owner, thereby adding new ownership information to the rights token's transaction history in the blockchain <NUM>.

The method <NUM> continues with step <NUM>, where the reader device <NUM> retrieves the decryption key for decrypting the encrypted version from the blockchain <NUM> over the network <NUM>, now that the rights token has transferred ownership. As is mentioned above, the decryption key encapsulated in the rights token may not be simply a decryption key, but may be part of a public/private key pair, or may be a code or password, for example, for decrypting the encrypted version.

With reference to <FIG>, there is depicted a flow chart of a method <NUM> implemented in accordance with non-limiting embodiments of the present technology. The method <NUM> is executed by the server <NUM>, where the processor <NUM> executes the method <NUM> and the instructions for method <NUM> are generally saved to the memory module <NUM>.

As with the method <NUM>, the user device <NUM> of the method <NUM> is the device <NUM> belonging or being used by the end consumer, and will therefore be referred to as the reader device <NUM>, in the context of the method <NUM>.

The method <NUM> starts at step <NUM>, where the server <NUM> receives a request from the reader device <NUM> to gain access to an encrypted copy of the digital media file. Generally, the server <NUM> hosts a web application or portal which the reader accesses via a web browser application of the reader device <NUM>. The request could include various types of information, including but not limited to: information identifying the digital media file to which the reader desires to gain access, identifying information related to the reader and/or the reader device, and subscription information.

It some implementations, the reader could utilize an application for document reading resident on the reader device <NUM>. In this case, the reader device <NUM> would act as the server <NUM> and the server <NUM> would therefore not required. In some situations, such as an eBook of format ePub <NUM>, the code could be integrated into the digital document itself. In such cases, there would be no need to access the server <NUM> and nor to have a specific application residing on the reader device <NUM>. The reader would simply open their browser to open the digital file and the code within the digital media file copy would perform the same tasks as if it were the server <NUM>.

The method <NUM> continues at step <NUM>, with the server <NUM> (or the user device <NUM>) retrieving an encrypted copy of the digital media file. The encrypted copy is retrieved from either the database <NUM> (connected to the server <NUM> or the user device <NUM> via the network <NUM>) or from one or more blocks of the rights blockchain <NUM>. In some implementations, the server <NUM> could also recover the encrypted copy from the memory module <NUM> of the server <NUM>. As described above, the encrypted copies of the digital media file may be recorded directly to the blockchain <NUM> (either in one block, or across different blocks depending on the file size). In some other cases, it may be preferable, either for the originator or for the final users, for one or more of the encrypted copies to be stored to the external database <NUM>.

In some implementations, retrieving the encrypted file could include sending the encrypted copy of the digital media file to the reader device <NUM>. It is also contemplated that the server <NUM> or the blockchain <NUM> could provide a link to the reader device <NUM> for the reader device <NUM> to retrieve the encrypted copy from the database <NUM>, an other cloud or remote storage service, etc..

The method <NUM> continues at step <NUM>, when the server <NUM> determines that the reader of the reader device <NUM> has access rights for the digital media file copy. The server <NUM> determines the access rights by querying and/or receiving confirmation from the blockchain <NUM>. The server <NUM> or the user device <NUM> using an application will determined if the public key matches the private key and determines the access rights. If the access rights are not provided (the keys do not match), reader will not be able to access the document as it will remain encrypted. If the reader has access rights (the keys match), the document will be decrypted by the server <NUM> or the application on the user device <NUM>. It is contemplated that the document could contain the code to manage some portion of the above.

Step <NUM> further includes retrieving information from the rights token associated with the copy of the digital media file. As is described in detail above, the rights token includes a key for decrypting the encrypted copy, which can only be extracted from the blockchain <NUM> when the server <NUM> determines that the ownership information of the rights token matches the user and/or user device <NUM> attempting to retrieve the key.

The method <NUM> continues at step <NUM> with causing the reader device <NUM> to display a decrypted copy of the digital media file.

This can be done in various ways. The server <NUM> can send a decrypted version to the reader device <NUM>, but generally the file would need to be provided in a way as to avoid copying or sharing of the decrypted version. More generally, the server <NUM> can provide the key to the reader device <NUM>, as discussed above, such that the reader device <NUM> can decrypt and show the decrypted version. In some implementations, the key could only be active while the server <NUM> and the reader device <NUM> are actively connected. In some implementations, the reader device <NUM> could display a version of the decrypted document online, accessible to the reader device <NUM> through a browsing application for example, while not saving or sending the decrypted document itself (for example, similar to a streaming service).

It should be expressly understood that not all technical effects mentioned herein need to be enjoyed in each and every embodiment of the present technology. For example, embodiments of the present technology may be implemented without the user enjoying some of these technical effects, while other embodiments may be implemented with the user enjoying other technical effects or none at all.

Some of these steps and signal sending-receiving are well known in the art and, as such, have been omitted in certain portions of this description for the sake of simplicity. The signals can be sent-received using optical means (such as a fibre-optic connection), electronic means (such as using wired or wireless connection), and mechanical means (such as pressure-based, temperature based or any other suitable physical parameter based).

Claim 1:
A computer-implemented method (<NUM>) of limiting a distribution of a digital media file, the method (<NUM>) being performed by a server (<NUM>) connected to a network (<NUM>), the server (<NUM>) comprising memory (<NUM>), the method (<NUM>) comprising:
receiving (<NUM>), by the server (<NUM>) from an originator, the digital media file to be distributed; and
encrypting (<NUM>), by the server (<NUM>), the digital media file to create an encrypted digital media file; and
defining, by the server, a key for decrypting the encrypted digital media file;
creating (<NUM>), by the server (<NUM>), a plurality of copies of the encrypted digital media file;
creating (<NUM>), by the server (<NUM>), a plurality of rights tokens, a quantity of the plurality of rights tokens being equal to a quantity of the plurality of copies of the encrypted digital media file, each one of the rights tokens containing at least:
the defined key for decrypting a corresponding one of the plurality of copies of the encrypted digital media file,
identifying information related to access rights for the digital media file;
recording (<NUM>), by the server (<NUM>) via the network (<NUM>), the plurality of rights tokens to a rights blockchain (<NUM>), the rights blockchain (<NUM>) being representative of actions related to distribution of the plurality of copies of the encrypted digital media file;
receiving, by the server (<NUM>) from the originator, a request to store at least one copy of the plurality of copies of the encrypted digital media file in the rights blockchain (<NUM>);
determining, by the server (<NUM>), that a file size of the at least one copy exceeds a storage capacity of a block of the rights blockchain (<NUM>);
subdividing, by the server (<NUM>), the digital media file into a plurality of subpackets of information;
encrypting, by the server (<NUM>), each one of the plurality of subpackets of information; creating, by the server (<NUM>), an assembly key for reassembling the plurality of subpackets of information; and
recording, by the server (<NUM>) via the network (<NUM>), the plurality of subpackets of information to the rights blockchain (<NUM>), the plurality of subpackets of information being recorded over a plurality of blocks of the rights blockchain (<NUM>); and
wherein:
a corresponding one of the plurality of rights tokens further includes the assembly key for the at least one copy.