JP7805534B2 - USE RIGHT PROTECTION DEVICE, USE RIGHT PROTECTION METHOD, USE RIGHT PROTECTION PROGRAM, AND DISTRIBUTED FILE SYSTEM - Google Patents

Description

This disclosure relates to protecting the right to use digital data.

Conventional rights to use digital data are protected by a digital rights management technology known as DRM.
DRM works as follows: A DRM license server distributes decryption keys to licensed users, who can then decrypt and view the encrypted digital data using the decryption keys.
In this way, the right to use digital data is protected by a centralized control device called a DRM license server.
However, since the administrator of the DRM license server can alter the license information or shut down the server, centralization lacks transparency and security regarding the rights to use digital data.
DRM is an abbreviation for Digital Rights Management.

Patent Document 1 proposes a method for ensuring transparency and safety by implementing the functions of a DRM license server using a blockchain.
The use of blockchain ensures transparency by allowing anyone to verify the copyright management process and security by preventing data tampering.

Patent No. 6983794

The proposal in Patent Document 1 makes it possible to achieve decentralization by using blockchain for license management.
However, since the content is not managed in a distributed manner, if the content distribution server stops, the content may not be viewable.
In addition, the content distributor can modify the content.

The purpose of this disclosure is to ensure that only file owners can access files in a system where files (digital data) and file ownership are managed in a decentralized manner.

The usage right protection device of the present disclosure comprises:
The system includes a distributed file system unit that receives a request from a user for a file that has been split into multiple fragments and stored unencrypted in a distributed file system, requests the multiple fragments of a request file, which is the file requested by the user, from one or more terminals connected to the distributed file system, receives the multiple fragments encrypted using the public key of the owner of the request file from the one or more terminals, decrypts the multiple fragments from the encrypted multiple fragments using the private key of the user, and forms a file using the decrypted multiple fragments.
If the private key of the user is the private key paired with the public key of the owner of the request file, the fragments of the request file are decrypted to form the request file.

This disclosure ensures that only the owner of the file (digital data) can access the file.

FIG. 1 is a configuration diagram of a rights protection device 100 according to a first embodiment. FIG. 2 is a functional configuration diagram of a rights protection device 100 according to the first embodiment. FIG. 1 is a configuration diagram of a network system 400 according to the first embodiment. FIG. 10 is a sequence diagram of a usage right protection method (viewing) according to the first embodiment. FIG. 10 is a sequence diagram of a usage right protection method (viewing) according to the first embodiment. FIG. 10 is a sequence diagram of a usage right protection method (viewing) according to the first embodiment. FIG. 10 is a sequence diagram of a usage right protection method (viewing) according to the first embodiment. FIG. 1 is a diagram showing an example of the configuration of a blockchain according to the first embodiment. FIG. 4 is a diagram for explaining user account information according to the first embodiment. FIG. 2 is a diagram showing an example of file management according to the first embodiment. FIG. 1 is a diagram showing main data items of an NFT in the first embodiment. FIG. 11 is a functional configuration diagram of a rights protection device 100 according to a second embodiment. FIG. 11 is a sequence diagram of a usage right protection method (upload) according to the second embodiment. FIG. 11 is a sequence diagram for explaining the diffusion of downloads in the second embodiment. FIG. 11 is a functional configuration diagram of a rights protection device 100 according to a third embodiment. FIG. 11 is a diagram for explaining a private file in the third embodiment. FIG. 11 is a diagram for explaining metadata of an NFT in the third embodiment. FIG. 2 is a hardware configuration diagram of a rights protection device 100 according to an embodiment.

In the embodiments and drawings, the same or corresponding elements are given the same symbols. Explanations of elements given the same symbols as previously described elements will be omitted or simplified as appropriate. Arrows in the figures primarily indicate the flow of data or processing.

Embodiment 1.
A method for protecting the right to use digital data will be described with reference to FIGS. 1 to 11. FIG.

***Configuration Description***
The configuration of the rights protection device 100 will be described with reference to FIG.
The usage right protection device 100 is a computer such as a personal computer, a tablet, or a smartphone.

The usage rights protection device 100 comprises hardware such as a processor 101, a memory 102, an auxiliary storage device 103, a communication device 104, and an input/output interface 105. These pieces of hardware are connected to each other via signal lines.

The processor 101 is an IC that performs arithmetic processing and controls other hardware. For example, the processor 101 is a CPU.
IC is an abbreviation for Integrated Circuit.
CPU is an abbreviation for Central Processing Unit.

The memory 102 is a volatile or non-volatile storage device. The memory 102 is also called a primary storage device or a main memory. For example, the memory 102 is a RAM. Data stored in the memory 102 is saved in the secondary storage device 103 as needed.
RAM is an abbreviation for Random Access Memory.

The auxiliary storage device 103 is a non-volatile storage device. The auxiliary storage device 103 is also called storage. For example, the auxiliary storage device 103 is a ROM, a HDD, a flash memory, or a combination thereof. Data stored in the auxiliary storage device 103 is loaded into the memory 102 as needed.
ROM is an abbreviation for Read Only Memory.
HDD is an abbreviation for Hard Disk Drive.

The communication device 104 is a receiver and a transmitter. For example, the communication device 104 is a communication chip or a NIC. The communication of the rights protection device 100 is performed using the communication device 104.
NIC is an abbreviation for Network Interface Card.

The input/output interface 105 is a port to which an input device and an output device are connected. For example, the input/output interface 105 is a USB terminal, the input devices are a keyboard and a mouse, and the output device is a display. Input and output of the rights protection device 100 are performed using the input/output interface 105.
USB is an abbreviation for Universal Serial Bus.

The usage rights protection device 100 comprises elements such as a distributed file system unit 200 and a blockchain unit 300. These elements are realized in software.

The auxiliary storage device 103 stores a usage right protection program for causing a computer to function as the distributed file system unit 200 and the block chain unit 300. The usage right protection program is loaded into the memory 102 and executed by the processor 101.
The auxiliary storage device 103 also stores an OS. At least a part of the OS is loaded into the memory 102 and executed by the processor 101.
The processor 101 executes the usage rights protection program while executing the OS.
OS is an abbreviation for Operating System.

The data of the rights-protected program (for example, input/output data) is stored in the storage unit 190 .
The memory 102 functions as the storage unit 190. However, a storage unit such as the auxiliary storage unit 103, a register in the processor 101, or a cache memory in the processor 101 may function as the storage unit 190 instead of or together with the memory 102.

The usage rights protection program can be recorded (stored) in a computer-readable manner on a non-volatile recording medium such as an optical disk or flash memory.

The auxiliary storage device 103 is used as storage for the distributed file system and blockchain.

FIG. 2 shows the functional configuration of the rights protection device 100 .
The distributed file system unit 200 comprises elements such as a data access unit 210, a file receiving unit 220, a file transmitting unit 230, a network management unit 240, a file management unit 250, and a UI unit 260. UI is an abbreviation for user interface.
The file receiving unit 220 includes elements such as a request unit 221 , a decryption unit 222 , and a file forming unit 223 .
The file transmission unit 230 includes elements such as a response unit 231 and an encryption unit 232 .
The blockchain unit 300 includes elements such as a data management unit 310 , an account management unit 320 , and a network management unit 330 .

The configuration of the network system 400 will be described with reference to FIG.
The network system 400 includes a plurality of rights protection devices 100 .
A plurality of usage right protection devices 100 communicate with each other by forming a P2P network, thereby realizing a distributed file system and a blockchain. P2P is an abbreviation for peer-to-peer.
The distributed file system unit 200 allows the usage right protection device 100 to function as a part of the distributed file system.
The block chain unit 300 allows the usage right protection device 100 to function as a part of the block chain.
The network management unit 330 has a function of realizing P2P connections between blockchain clients (usage right protection devices 100).

The usage right protection device 100 may include only one of the distributed file system unit 200 and the block chain unit 300 .
The usage right protection device 100 that constitutes the distributed file system may be different from the usage right protection device 100 that constitutes the blockchain.

***Explanation of Operation***
The operation procedure of the rights protection device 100 corresponds to a rights protection method, and also corresponds to a processing procedure by a rights protection program.

The usage right protection method (browsing) will be described with reference to FIGS.
The usage right protection method (view) is a method by which the user 401 can view a file.
A user 401 is the owner of the file and has the right to view the file.
A file is digital data. A file is also called content.

In a distributed file system, each file is divided into multiple fragments, and the multiple fragments of each file are stored in one or more usage rights protection devices 100. However, files do not necessarily have to be fragmented. For example, if the file size is small, the file does not have to be fragmented.

The rights protection device 100 used by the user 401 is called a "user terminal."
The rights protection device 100 other than the user terminal is referred to as an "other terminal."

In step S101, the user 401 inputs a file request into the user terminal using the user interface.
The user interface includes, for example, a screen required for operating the user terminal, a function for accepting commands, etc. The user interface is controlled by a UI unit 260.

A file request is a request for a file to a user terminal.
The requested file is called the request file.

In step S102, the UI unit 260 of the user terminal receives the file request and passes the file request of the user terminal to the request unit 221.

In step S103, the request unit 221 of the user terminal receives the file request and passes the file request to the file management unit 250 of the user terminal.

In step S104, the file management unit 250 of the user terminal receives the file request.
Then, the file management unit 250 of the user terminal searches the distributed file system storage of the user terminal for multiple fragments of the requested file.
If multiple fragments of the request file are found, the process proceeds to step S105.
If multiple fragments of the requested file are not found, the process proceeds to step S111.

In step S105, the file management unit 250 of the user terminal returns a plurality of fragments of the requested file to the request unit 221 of the user terminal.
Then, the request unit 221 of the user terminal receives a plurality of fragments of the request file.
After step S105, the process proceeds to step S161 (see FIG. 7).

In step S111, the file management unit 250 of the user terminal returns a search result to the request unit 221 of the user terminal indicating that multiple fragments of the requested file were not found.

In step S112, the request unit 221 of the user terminal selects another terminal connected via the P2P network, and transmits a file request to the selected other terminal.
That is, the request unit 221 of the user terminal requests multiple fragments of the request file from another terminal.

In step S113, the response unit 231 of the other terminal receives the file request and passes the file request to the file management unit 250 of the other terminal.

In step S114, the file management unit 250 of the other terminal receives the file request.
Then, the file management unit 250 of the other terminal searches the distributed file system storage of the other terminal to find multiple fragments of the request file.
If at least one fragment of the requested file is found, the process proceeds to step S131 (see FIG. 5).
If no fragment of the requested file is found, the process proceeds to step S121.

In step S121, the file management unit 250 of the other terminal returns a search result indicating that no fragments of the requested file were found to the response unit 231 of the other terminal.

In step S122, the response unit 231 of the other terminal inquires of the network management unit 240 of the other terminal about the connected terminal information.
The connected terminal information is data indicating one or more other terminals connected to the own terminal in the P2P network, and is stored in advance in the own terminal.

In step S123, the network management unit 240 of the other terminal returns the connected terminal information to the response unit 231 of the other terminal.

In step S124, the response unit 231 of the other terminal returns the connection terminal information to the user terminal.

After step S124, the request unit 221 of the user terminal receives the connection terminal information, selects a new other terminal by referring to the received connection terminal information, and transmits a file request to the selected other terminal (step S112).
Even if the other terminal does not have the request file (fragment thereof), the request file (fragment thereof) can be found by continuing the file search based on the connection terminal information of the other terminal.

The processes from step S112 to step S124 are repeated until the encrypted file is transmitted from the other terminal to the user terminal.
The encrypted file is a file obtained by encrypting at least one fragment of the request file.
After step S124, the process proceeds to step S131 (see FIG. 5).

In step S131, the file management unit 250 of the other terminal acquires at least one fragment of the request file from the distributed file system storage of the other terminal.
Then, the file management unit 250 of the other terminal passes at least one fragment of the request file to the response unit 231 of the other terminal.

In step S132, the response unit 231 of the other terminal receives at least one fragment of the request file and requests the encryption unit 232 of the other terminal to encrypt at least one fragment of the request file.

In step S133, the encryption unit 232 of the other terminal receives at least one fragment of the request file.
Then, the encryption unit 232 of the other terminal requests the data access unit 210 of the other terminal to acquire the public key of the owner of the request file.

In step S134, the data access unit 210 of the other terminal requests the data management unit 310 of the other terminal to obtain the public key of the owner of the request file.

In step S135, the data management unit 310 of the other terminal obtains the public key of the owner of the request file from the blockchain.

In step S136, the data management unit 310 of the other terminal returns the public key of the owner of the requested file to the data access unit 210 of the other terminal.

In step S137, the data access unit 210 of the other terminal receives the public key of the owner of the request file and returns the public key of the owner of the request file to the encryption unit 232 of the other terminal.

In step S138, the encryption unit 232 of the other terminal receives the public key of the owner of the request file.
The encryption unit 232 of the other terminal then uses the received public key to encrypt at least one of the fragments of the request file, thereby obtaining an encrypted file.

In step S139, the encryption unit 232 of the other terminal returns the encrypted file to the response unit 231 of the other terminal.

In step S140, the response unit 231 of the other terminal receives the encrypted file and returns the encrypted file to the user terminal.
Then, the request unit 221 of the user terminal receives the encrypted file.
After step S140, the process proceeds to step S141 (see FIG. 6).

In step S141, the request unit 221 of the user terminal requests the decryption unit 222 of the user terminal to decrypt the encrypted file.

In step S142, the decryption unit 222 of the user terminal receives the encrypted file.
Then, the decryption unit 222 of the user terminal requests the data access unit 210 of the user terminal to acquire the private key of the user 401 .

In step S143, the data access unit 210 of the user terminal requests the account management unit 320 of the user terminal to acquire the private key of the user 401.
The private key and public key of the user 401 are managed by the account management unit 320 as part of the account information of the user 401 .

In step S144, the account management unit 320 of the user terminal obtains the private key of the user 401 from the auxiliary storage device 103 of the user terminal.

In step S145, the account management unit 320 of the user terminal returns the private key of the user 401 to the data access unit 210 of the user terminal.

In step S146, the data access unit 210 of the user terminal receives the private key of the user 401 and returns the private key of the user 401 to the decryption unit 222 of the user terminal.

In step S 147 , the decryption unit 222 of the user terminal receives the private key of the user 401 .
The decryption unit 222 of the user terminal then uses the private key of the user 401 to decrypt one or more fragments from the encrypted file.

The user 401 is the owner of the request file. Therefore, the private key of the user 401 is the private key paired with the public key of the owner of the request file. In this case, all fragments of the request file are decrypted.
If user 401 is not the owner of the request file, the request file fragments will not be decrypted correctly because user 401's private key will not pair with the request file owner's public key.

In step S148, the decoding unit 222 of the user terminal returns the one or more decoded fragments to the request unit 221 of the user terminal.
The request unit 221 of the user terminal then receives the decrypted one or more fragments.

Steps S112 to S148 are executed while changing the other terminal to which the request is made until multiple fragments of the request file are obtained.
After obtaining multiple fragments of the request file, the process proceeds to step S151.

In step S151, the request unit 221 of the user terminal requests the file management unit 250 of the user terminal to store multiple fragments of the request file.

In step S152, the file management unit 250 of the user terminal receives multiple fragments of the requested file.
Then, the file management unit 250 of the user terminal stores the multiple fragments of the request file in the distributed file system storage of the user terminal.

In step S153, the file management unit 250 of the user terminal returns the storage result to the request unit 221 of the user terminal.
After S153, the process proceeds to step S161 (see FIG. 7).

In step S161, the request unit 221 of the user terminal passes multiple fragments of the request file to the file creation unit 223 of the user terminal and requests the creation of the request file.

In step S162, the file forming unit 223 of the user terminal receives a plurality of fragments of the request file.
Then, the file forming unit 223 of the user terminal forms a request file using the received multiple fragments.

In step S163, the file creation unit 223 of the user terminal returns the request file to the request unit 221 of the user terminal.

In step S164, the request unit 221 of the user terminal receives the request file and returns the request file to the UI unit 260 of the user terminal.

In step S 165 , the UI unit 260 of the user terminal receives the request file and outputs the request file to the user 401 .
For example, the UI unit 260 of the user terminal displays the request file on a display.
Then, the user 401 views the request file.

***Features of the First Embodiment***
The usage right protection device 100 includes a data access unit 210, a file transmission unit 230, and a file reception unit 220, and protects the usage right of the distributed digital data.
The data access unit 210 obtains the private key of its own account and the public key of the owner of the digital data from the blockchain.
In response to a file request from another terminal, the file transmission unit 230 encrypts the file using the public key of the owner of the file and transmits the encrypted file.
The file receiving unit 220 uses the private key of its own account to decrypt the encrypted file sent from the other terminal.

***Effects of First Embodiment***
The first embodiment relates to protection of the right to use distributed digital data.
The first embodiment aims to enable only the owner of the content to access the correct content.
According to the first embodiment, only users (owners) who have ownership rights and are managed by the blockchain can access files managed by the distributed file system.

The files (fragments) are encrypted and sent using the file owner's public key, so that only the file owner can view them.
If the user is not the owner of the file, they will not be able to decrypt the encrypted file (fragments) because the private key on the user's device does not match the public key used to encrypt the file (fragments).
Even if a malicious user sends some fragments of a file unencrypted, only some fragments of the file are unencrypted, while many fragments of the file are encrypted, so that only the file owner can retrieve the complete file.
Even if a malicious user sends file fragments encrypted using a public key different from the file owner's public key, the file owner can still obtain the complete file for the following reasons: In this case, when the file fragments are decrypted using the file owner's private key, the hash value of the requested file fragment will be different from the hash value of the decrypted file fragment. Alternatively, an attempt to decrypt the file fragments using the file owner's private key will fail. As a result, the file owner will realize that the transmitted file fragments have been encrypted with a different public key, and will be able to obtain the file fragments from another device and obtain the complete file.

In the first embodiment, files (fragments) are stored in the distributed file system without being encrypted. The files (fragments) are then encrypted when they are transmitted. This enables ownership to be transferred using NFTs. NFT is an abbreviation for Non-Fungible Token.
On the other hand, in a method in which a file (or a group of fragments) is encrypted and stored using the public key of the new owner each time the owner changes, the file (or a group of fragments) must be re-encrypted and stored every time ownership is transferred, which results in the loss of file uniqueness.
In a distributed file system, a re-encrypted file is treated as a different file from the original file. Ensuring file uniqueness is important because unique file ownership has value precisely because the content ID (the file hash value) is immutable.
In the first embodiment, the uniqueness of a file is guaranteed by handling the file in the distributed file system without encrypting it.

*** Supplement to the first embodiment ***
Based on FIG. 8, the blockchain will be explained in more detail.
In a blockchain network, multiple blocks of data are shared.
Block data is data that is managed as a "block" by bundling multiple transactions issued by each terminal into one.
The data management unit 310 has a function of managing each block data.

The user's account information will be explained further based on Figure 9. Solid arrows represent input and output, while dotted arrows represent copying.
A public key and a private key are used as the user's account information.
The public key is used as an account ID.
Public and private keys are used when issuing and receiving transactions.
When a transaction is issued, in order to prove that a user with a valid account ID is the issuer of the transaction, a digital signature is attached to the transaction details included in the transaction using a private key, and the digital signature and public key are included in the transaction.
When a transaction is received, the public key in the transaction is used to decrypt the hash value from the digital signature in the transaction, and the decrypted hash value is checked to see if it matches the hash value of the transaction details.
This verifies that the issuer of the transaction is a legitimate user who holds the private key that pairs with the public key in the transaction.
The account management unit 320 has a function of managing the public key and private key that constitute the user's account information.
The data management unit 310 has a function of managing transactions.
The data access unit 210 has a function of obtaining the public key in a transaction stored in block data from the data management unit 310. The public key in the transaction is not the public key of a user managed by the account management unit 320, but the public key of the transaction issuer.
The data access unit 210 has a function of obtaining the user's private key from the account management unit 320 .

A supplementary note about distributed file systems.
IPFS is a well-known distributed file system. IPFS is an abbreviation for Inter Planet File System.
IPFS is designed so that a device whose terminal ID (256 bits) is close to the file's hash value (256 bits) remembers the ID of the terminal that has the file. This allows the target file to be found quickly by searching for nearby terminals based on the file's hash value.

An example of file management in IPFS is shown in Figure 10. The topmost figure represents a file. Circles represent data objects, and squares represent file fragments.
Large files are split into multiple pieces and managed.
Files are managed in the form of data objects. A file consists of a CID (a hash value of the file), link information between fragments called "Links," and data contents called "Data."
Link information is necessary to form a file. By tracing the link information, you can reach the data content, and by combining files according to the link information, a single file is created.

A bit more information about NFTs.
Digital data can be easily copied, which is why it has always been less scarce than physical objects (e.g., gold and diamonds).
However, the emergence of NFTs, which use blockchain to manage ownership of digital data (content), has given digital data value, allowing it to be bought and sold at high prices.
NFTs are managed by linking the identifier of the digital data (basically the hash value of the digital data) with the owner's identifier (wallet address), which allows NFTs to guarantee ownership of the digital data.
The hash value of digital data is unique to that digital data. Therefore, if even one bit of the digital data is altered, the hash value will become completely different, making it possible to verify that the digital data is different.
The unique identifier is designed to be immutable by smart contract, ensuring that you own a unique piece of digital data.
Digital data is managed based on file hash values in a distributed file system called IPFS. When the hash value of a file recorded in NFT is entered, the file is retrieved by collecting the fragments from multiple devices. IPFS stands for InterPlanetary File System.
When ownership is bought or sold, crypto assets (virtual currencies) are paid via a blockchain smart contract, which transfers ownership.
Since the registration and transfer of NFTs is all achieved through blockchain smart contracts, they are highly reliable, transparent, and tamper-resistant. In other words, they are highly reliable because they are executed automatically by a program without human intervention. In addition, they are highly transparent because all transactions are recorded and made public. Furthermore, they are highly tamper-resistant because recorded transactions are difficult to reverse. This ensures safety.
NFTs guarantee ownership of digital data. However, the digital data is not protected, so people without ownership can download and view the digital data. They can also copy and distribute the downloaded digital data.
In the physical world, there is a scarcity value of things, such as things that cannot be replicated and can only be handled by their owner. However, NFTs alone cannot impart the scarcity value of things to digital data.
Therefore, technology to protect the digital data itself is needed.

FIG. 11 shows the main data items managed by the NFT.
Using the smart contract address and token ID, you can obtain the content ID and owner address. The content ID is the hash value of the content or the hash value of the content metadata. The owner address corresponds to the owner's public key.
Ethereum is a well-known blockchain. In Ethereum, the owner address is the hash value of the public key. Therefore, the public key must be obtained from the transaction signature.

Embodiment 2.
The file distribution mode will be described below, focusing mainly on the differences from the first embodiment, with reference to FIGS. 12 to 14. FIG.

***Configuration Description***
The configuration of the rights protection device 100 will be described with reference to FIG.
In the rights protection device 100 , the distributed file system unit 200 includes an element called a file distribution unit 270 .

***Explanation of Operation***
The usage right protection method (upload) will be described with reference to FIG.
The usage right protection method (upload) is a method for the user 401 to upload a file. In other words, the usage right protection method (upload) is a method for storing a file in the distributed file system.

In step S201, the user 401 uses the user interface to specify an upload file on the user terminal.
An uploaded file is a file that you want to store in the distributed file system.

In step S202, the UI unit 260 of the user terminal passes the uploaded file to the file management unit 250 of the user terminal.

In step S203, the file management unit 250 of the user terminal receives the uploaded file.
Then, the file management unit 250 of the user terminal fragments the uploaded file according to the size of the uploaded file.
This will give you multiple fragments of the uploaded file.

In step S204, the file management unit 250 of the user terminal requests the file spreading unit 270 of the user terminal to spread multiple fragments of the uploaded file.

In step S205, the file spreader 270 of the user terminal receives a plurality of fragments of the uploaded file.
Then, the file spreading unit 270 of the user terminal selects one or more other terminals connected in the P2P network, and transmits a plurality of fragments of the uploaded file to the selected one or more other terminals.
That is, the file spreading unit 270 of the user terminal requests the distributed file system to store multiple fragments of the uploaded file.

In step S206, the file management unit 250 of the other terminal receives one or more fragments of the uploaded file.
Then, the file management unit 250 of the other terminal requests the file distribution unit 270 of the other terminal to store one or more fragments of the uploaded file.

In step S207, the file spreading unit 270 of the other terminal receives one or more fragments of the uploaded file.
Then, the file spreading unit 270 of the other terminal stores one or more fragments of the uploaded file in the storage for the distributed file system of the other terminal.

In step S208, the file distribution unit 270 of the other terminal returns the storage result to the file management unit 250 of the other terminal.

In step S209, the file management unit 250 of the other terminal receives the storage result.
Then, the file management unit 250 of the other terminal returns the storage result to the user terminal.

If storage fails, steps S205 to S209 are executed for another terminal.

In step S210, the file distribution unit 270 of the user terminal receives storage results from one or more other terminals and returns distribution results corresponding to the storage results to the file management unit 250 of the user terminal.

In step S211, the file management unit 250 of the user terminal receives the diffusion result and returns the upload result corresponding to the diffusion result to the UI unit 260 of the user terminal.

In step S212, the UI unit 260 of the user terminal receives the upload result.
Then, the UI unit 260 of the user terminal outputs the upload result to the user 401 .
For example, the UI unit 260 of the user terminal displays the upload result on a display.

The diffusion of the download file will be described with reference to FIG.
A download file is a file (or pieces of a file) obtained from a distributed file system.
In step S151 (see embodiment 1), the request unit 221 of the user terminal requests the file management unit 250 of the user terminal to store a plurality of fragments of a downloaded file.
Steps S204 to S211 are then performed for the multiple fragments of the downloaded file.

***Features of the Second Embodiment***
The rights protection device 100 includes a file spreading unit 270 .
The file spreading unit 270 spreads fragments of a file to be uploaded or downloaded to neighboring terminals.

***Effects of the Second Embodiment***
In a distributed file system, files are spread within the network as each terminal acquires the files.
In the usage rights protection method, only the owner can decrypt the file. Therefore, the file is unlikely to be spread, and the availability and permanence of the file may not be guaranteed. For example, if the owner's device is damaged, the file may be lost forever.
However, in the second embodiment, file diffusion works, which distributes files and ensures the availability and permanence of files.

Embodiment 3.
The following describes a configuration in which a file contains public data and private data, focusing mainly on the differences from the first and second embodiments, with reference to FIGS. 15 to 17. FIG.

***Configuration Description***
The configuration of the rights protection device 100 will be described with reference to FIG.
In the rights protection device 100 , the distributed file system unit 200 includes an element called an access management unit 280 .

***Explanation of Operation***
The user 401 specifies the file attribute (public file or private file) of the uploaded file (step S201).
A public file is a file that is not restricted in terms of viewing.
A private file is a file whose access is restricted.

The file management unit 250 of the user terminal assigns a public flag or a private flag to the multiple fragments of the uploaded file (step S203).
If the uploaded file is a public file, the fragments of the uploaded file are flagged as public.
If the uploaded file is a private file, the fragments of the uploaded file are flagged as private.

The access management unit 280 of the other terminal determines whether a non-public flag has been added to one or more fragments of the request file.
If a private flag is set for one or more fragments of the request file, the encryption unit 232 of the other terminal encrypts the one or more fragments of the request file (step S138), and then transmits the encrypted file with the private flag set to the user terminal (step S139).
If one or more fragments of the request file are flagged as public, then the one or more fragments of the request file are not encrypted.

The access management unit 280 of the user terminal determines whether the fragments obtained from the distributed file system have been flagged as private.
If the multiple fragments obtained from the distributed file system have private flags attached, the decryption unit 222 of the user terminal decrypts the multiple encrypted fragments (step S147).
If multiple fragments obtained from the distributed file system are flagged as public, no decryption process is required for the multiple fragments.

***Features of the Third Embodiment***
The rights protection device 100 includes a file management unit 250 and an access management unit 280 .
The file management unit 250 adds a public flag or a private flag to the data object of the file to be stored.
The access management unit 280 determines whether or not a fragment of a file needs to be encrypted/decrypted based on the public or private flag of the data object.

***Effects of the Third Embodiment***
According to the third embodiment, even if public files and private files are mixed in a distributed file system, it is possible to control that public files can be viewed by anyone, while private files can only be accessed by their owners.

***Additional information for embodiment 3***

A supplementary explanation of private files will be given based on FIG.
A distributed file system stores both data that requires access control (private files) and data that does not require access control (public files).
The access management unit 280 puts an Encryption attribute (private flag) into the data object of the private file.
If the Encryption attribute is true, encryption and decryption processes are performed.
If the Encryption attribute is false, the encryption and decryption processes are not executed.

Based on FIG. 17, the NFT will be explained in more detail.
The owner address is expressed, for example, as a 42-digit hexadecimal number.
The TokenURI is information indicating the location of the metadata.
Name indicates the name of the NFT.
The description column shows a description of the NFT.
The image column indicates the URL of the target data.
The target data is, for example, an image, text, or video.

Files managed by NFT may contain metadata in addition to index data managed by the blockchain (see Figure 11) and target data (content files) managed by the distributed file system.
Metadata is data that describes the content and is managed by a distributed file system.

In FIG. 17, in the blockchain, the hash value of the metadata is recorded in the TokenURI column, and the hash value of the target data is recorded in the image column of the metadata.
Access to the data must be controlled so that only the owner can view it.
On the other hand, if the metadata is encrypted, the identity of the target data cannot be determined and the target data has no value.
In other words, metadata should not be access-controlled.
In addition, a hash value of thumbnail data of the target data may be registered in the metadata, and it is desirable that the thumbnail data be accessible to anyone. This allows users to check the thumbnail before purchasing ownership of an image. For example, if the target data is an image, the thumbnail data is image data with reduced resolution, and if the target data is video, the thumbnail data is still image data.

The third embodiment may be implemented in combination with the second embodiment.
That is, in the third embodiment, the rights protection device 100 may include a file spreading unit 270. The request file is spread in the same way as the uploaded file.

***Additional information on implementation form***

The hardware configuration of the rights protection device 100 will be described with reference to FIG.
The rights protection device 100 comprises a processing circuit 109 .
The processing circuit 109 is hardware that realizes the distributed file system unit 200 and the blockchain unit 300 .
The processing circuitry 109 may be dedicated hardware, or may be a processor 101 that executes a program stored in memory 102 .

When processing circuitry 109 is dedicated hardware, processing circuitry 109 may be, for example, a single circuit, a multiple circuit, a programmed processor, parallel programmed processors, an ASIC, an FPGA, or a combination thereof.
ASIC is an abbreviation for Application Specific Integrated Circuit.
FPGA is an abbreviation for Field Programmable Gate Array.

The usage rights protection device 100 may be provided with multiple processing circuits that replace the processing circuit 109.

In the processing circuit 109, some functions may be realized by dedicated hardware, and the remaining functions may be realized by software or firmware.

In this way, the functions of the usage rights protection device 100 can be realized by hardware, software, firmware, or a combination of these.

Each embodiment is an example of a preferred embodiment and is not intended to limit the technical scope of the present disclosure. Each embodiment may be implemented in part or in combination with other embodiments. Procedures described using flowcharts, etc. may be modified as appropriate.

The "part" of each element of the usage rights protection device 100 may also be read as "processing," "step," "circuit," or "circuitry."

100 Usage rights protection device, 101 Processor, 102 Memory, 103 Auxiliary storage device, 104 Communication device, 105 Input/output interface, 109 Processing circuit, 190 Memory unit, 200 Distributed file system unit, 210 Data access unit, 220 File receiving unit, 221 Request unit, 222 Decryption unit, 223 File formation unit, 230 File transmission unit, 231 Response unit, 232 Encryption unit, 240 Network management unit, 250 File management unit, 260 UI unit, 270 File distribution unit, 280 Access management unit, 300 Blockchain unit, 310 Data management unit, 320 Account management unit, 330 Network management unit, 400 Network system, 401 User.

Claims (10)

a distributed file system unit that receives from a user a request for a file that has been split into multiple fragments and stored in a distributed file system without encryption, requests the multiple fragments of a request file that is the file requested by the user from one or more terminals connected to the distributed file system, receives the multiple fragments encrypted using a public key of an owner of the request file from the one or more terminals, decrypts the multiple fragments from the encrypted multiple fragments using a private key of the user, and forms a file using the decrypted multiple fragments;
a usage rights protection device for decrypting the fragments of the request file to form the request file when the private key of the user is a private key paired with the public key of the owner of the request file; the usage right protection device includes a storage for a distributed file system and is connected to the distributed file system;
The usage rights protection device described in claim 1, wherein the distributed file system unit receives a request from a user terminal for a file that has been divided into multiple fragments and stored in the distributed file system without encryption, obtains at least one fragment of the request file, which is the file requested by the user terminal, from the distributed file system storage, encrypts the obtained one or more fragments using the public key of the owner of the request file, and transmits the encrypted one or more fragments to the user terminal. The usage right protection device according to claim 2 , further comprising a block chain unit that acquires the public key of the owner of the request file requested from the user terminal from a block chain. The fragments of each file are stored in the distributed file system unencrypted and flagged as public or private;
The usage rights protection device described in claim 2, wherein the distributed file system unit obtains at least one fragment of the request file requested by the user terminal from the distributed file system storage, and if the one or more obtained fragments have the private flag attached, encrypts the one or more obtained fragments using the public key of the owner of the request file, and transmits the encrypted one or more fragments attached with the private flag attached to the user terminal. The usage rights protection device described in claim 1, wherein the distributed file system unit accepts a specification of an uploaded file, divides the uploaded file into multiple fragments, sends the multiple fragments of the uploaded file to one or more terminals connected to the distributed file system, and requests the distributed file system to store the multiple fragments of the uploaded file. The usage rights protection device described in claim 5, wherein the distributed file system unit accepts specification of file attributes of the uploaded file, and if the uploaded file is a private file, assigns a private flag and transmits the multiple fragments of the uploaded file to the one or more terminals. The usage rights protection device described in any one of claims 1 to 6, wherein the distributed file system unit divides the request file into multiple fragments, sends the multiple fragments of the request file to one or more terminals connected to the distributed file system, and requests the distributed file system to store the multiple fragments of the request file. A usage right protection method, comprising: a usage right protection device receiving a request from a user for a file that is divided into multiple fragments and stored in a distributed file system without encryption; requesting the multiple fragments of a request file, which is the file requested by the user, from one or more terminals connected to the distributed file system; receiving the multiple fragments encrypted using a public key of an owner of the request file from the one or more terminals; decrypting the multiple fragments from the encrypted multiple fragments using a private key of the user; and forming a file using the decrypted multiple fragments,
A usage rights protection method, wherein the multiple fragments of the request file are decrypted to form the request file if the private key of the user is a private key paired with the public key of the owner of the request file. a usage rights protection program that causes a computer to execute a distributed file system process that receives a request from a user for a file that has been split into multiple fragments and stored in a distributed file system without encryption, requests the multiple fragments of a request file that is the file requested by the user from one or more terminals connected to the distributed file system, receives the multiple fragments encrypted using a public key of an owner of the request file from the one or more terminals, decrypts the multiple fragments from the encrypted multiple fragments using a private key of the user, and forms a file using the decrypted multiple fragments;
a usage rights protection program for decrypting the fragments of the request file to form the request file if the private key of the user is a private key paired with the public key of the owner of the request file; A distributed file system including a plurality of terminals, in which files are split into a plurality of fragments and stored unencrypted,
A user terminal used by a user among the plurality of terminals requests a plurality of fragments of a request file, which is a file requested by the user, from one or more other terminals included in the distributed file system;
the one or more other terminals encrypt the plurality of fragments using a public key of the owner of the request file;
the user terminal receives the encrypted fragments from the one or more other terminals, decrypts the encrypted fragments using the user's private key, and forms a file using the decrypted fragments;
If the user's private key is a private key paired with the public key of the owner of the request file, the encrypted fragments are decrypted to form the request file.
Distributed file system.