Use right protection device, use right protection method, and use right protection program

Abstract

A distributed file system unit (200) receives, from a user, a request for a file divided into a plurality of fragments and stored unencrypted in a distributed file system, requests the plurality of fragments of the requested file requested by the user from one or more terminals connected to the distributed file system, receives the plurality of fragments, which are encrypted using a public key belonging to the owner of the requested file, from the one or more terminals, decrypts the plurality of fragments from the encrypted plurality of fragments using a secret key belonging to the user, and forms a file using the plurality of decrypted fragments.

Description

Right of use protection device, right of use protection method, and right of use protection program

[0001] The present disclosure relates to the protection of usage rights of digital data.

[0002] Conventional digital data usage rights 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. Encrypted digital data can be decrypted and viewed using the decryption key. In this way, digital data usage rights are protected by a centralized control device known as a DRM license server. However, the administrator of the DRM license server can modify the license information or shut down the server, and centralization lacks transparency and security regarding digital data usage rights. DRM is an abbreviation for Digital Rights Management.

[0003] Patent Literature 1 proposes a method for ensuring transparency and security by implementing the functions of a DRM license server using a blockchain. The use of a blockchain ensures transparency, allowing anyone to check the copyright management process, and security, preventing data tampering.

[0004] Patent No. 6983794

[0005] The proposal in Patent Document 1 achieves decentralization by using blockchain for license management. However, since content is not managed in a decentralized manner, if the content distribution server stops, the content may not be viewable. In addition, the content distributor may be able to modify the content.

[0006] The present disclosure aims to enable only the owner of a file to access the file in a system in which files (digital data) and ownership of the files are managed in a distributed manner.

[0007] The usage right protection device of the present disclosure includes a distributed file system unit that receives a request from a user for a file that is divided into multiple fragments and stored unencrypted in a distributed file system, requests the multiple fragments of the 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 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 a private key that forms a pair with the public key of the owner of the request file, the multiple fragments of the request file are decrypted to form the request file.

[0008] According to the present disclosure, only the owner of a file (digital data) can access the file.

[0009] 1 is a configuration diagram of a usage right protection device 100 according to a first embodiment. FIG. 2 is a functional configuration diagram of the usage right protection device 100 according to the first embodiment. FIG. 3 is a configuration diagram of a network system 400 according to the first embodiment. FIG. 4 is a sequence diagram of a usage right protection method (viewing) according to the first embodiment. FIG. 5 is a sequence diagram of a usage right protection method (viewing) according to the first embodiment. FIG. 6 is a sequence diagram of a usage right protection method (viewing) according to the first embodiment. FIG. 7 is a diagram showing an example of the configuration of a blockchain according to the first embodiment. FIG. 8 is a diagram for explaining user account information according to the first embodiment. FIG. 9 is a diagram showing an example of file management according to the first embodiment. FIG. 10 is a diagram showing main data items of an NFT according to the first embodiment. FIG. 11 is a functional configuration diagram of a usage right protection device 100 according to a second embodiment. FIG. 12 is a sequence diagram of a usage right protection method (uploading) according to the second embodiment. FIG. 13 is a sequence diagram for explaining the diffusion of downloads according to the second embodiment. FIG. 14 is a functional configuration diagram of a usage right protection device 100 according to a third embodiment. FIG. 15 is a diagram for explaining a private file according to the third embodiment. FIG. 16 is a diagram for explaining NFT metadata according to the third embodiment. FIG. 17 is a hardware configuration diagram of a usage right protection device 100 according to an embodiment.

[0010] In the embodiments and drawings, the same or corresponding elements are denoted by the same reference numerals. The description of elements denoted by the same reference numerals as those already described will be omitted or simplified as appropriate. Arrows in the drawings primarily indicate the flow of data or the flow of processing.

[0011] First Embodiment A mode for protecting the right to use digital data will be described with reference to FIGS.

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

[0013] The 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 one another via signal lines.

[0014] 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.

[0015] 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.

[0016] 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 of these. 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.

[0017] 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.

[0018] 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 is performed using the input / output interface 105. USB is an abbreviation for Universal Serial Bus.

[0019] The usage right protection device 100 includes elements such as a distributed file system unit 200 and a block chain unit 300. These elements are realized by software.

[0020] The auxiliary storage device 103 stores a usage right protection program for causing the 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 portion of the OS is loaded into the memory 102 and executed by the processor 101. The processor 101 executes the usage right protection program while executing the OS. OS is an abbreviation for Operating System.

[0021] Data (e.g., input / output data) of the usage right protection program 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.

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

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

[0024] 2 shows the functional configuration of the usage right protection device 100. The distributed file system unit 200 includes 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 formation unit 223. The file transmitting 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.

[0025] The configuration of a network system 400 will be described with reference to FIG. 3. The network system 400 includes multiple usage right protection devices 100. The multiple usage right protection devices 100 form a P2P network, communicate with each other, and realize a distributed file system and a blockchain. P2P is an abbreviation for peer-to-peer. The distributed file system unit 200 causes the usage right protection device 100 to function as part of the distributed file system. The blockchain unit 300 causes the usage right protection device 100 to function as part of the blockchain. The network management unit 330 has a function of realizing P2P connections between blockchain clients (usage right protection devices 100).

[0026] 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 block chain.

[0027] ***Explanation of Operation*** The operation procedure of the rights protection device 100 corresponds to a rights protection method. Also, the operation procedure of the rights protection device 100 corresponds to a processing procedure by a rights protection program.

[0028] The usage right protection method (viewing) will be described with reference to Figures 4 to 7. The usage right protection method (viewing) is a method for a user 401 to view a file. The 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.

[0029] 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 rights protection devices 100. However, a file does not necessarily have to be fragmented. For example, if the file size is small, the file does not need to be fragmented.

[0030] The rights protection device 100 used by the user 401 is called a "user terminal." A rights protection device 100 other than the user terminal is called an "other terminal."

[0031] In step S101, the user 401 inputs a file request into the user terminal using a 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 the UI unit 260.

[0032] A file request is a request for a file to a user terminal. The requested file is called a request file.

[0033] 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.

[0034] 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.

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

[0036] In step S105, the file management unit 250 of the user terminal returns multiple fragments of the request file to the request unit 221 of the user terminal. The request unit 221 of the user terminal then receives the multiple fragments of the request file. After step S105, the process proceeds to step S161 (see FIG. 7).

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

[0038] 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. In other words, the request unit 221 of the user terminal requests multiple fragments of the requested file from the other terminal.

[0039] 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.

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

[0041] 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.

[0042] In step S122, the response unit 231 of the other terminal inquires about connected terminal information from the network management unit 240 of the other terminal. 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.

[0043] 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.

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

[0045] 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 requested file (a fragment of the requested file), the request file (a fragment of the requested file) can be found by continuing the file search based on the connection terminal information of the other terminal.

[0046] 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).

[0047] 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, and then passes the at least one fragment of the request file to the response unit 231 of the other terminal.

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

[0049] In step S133, the encryption unit 232 of the other terminal receives at least one fragment of the request file and requests the data access unit 210 of the other terminal to obtain the public key of the owner of the request file.

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

[0051] 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.

[0052] 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.

[0053] 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.

[0054] In step S138, the encryption unit 232 of the other terminal receives the public key of the owner of the request file. Then, the encryption unit 232 of the other terminal encrypts at least one fragment of the request file using the received public key. This results in an encrypted file.

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

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

[0057] 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.

[0058] In step S142, the decryption unit 222 of the user terminal receives the encrypted file and requests the data access unit 210 of the user terminal to obtain the private key of the user 401.

[0059] 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.

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

[0061] 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.

[0062] 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.

[0063] In step S147, 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.

[0064] User 401 is the owner of the request file. Therefore, the private key of user 401 is a private key that pairs 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 private key of user 401 does not pair with the public key of the owner of the request file, and therefore the fragments of the request file are not correctly decrypted.

[0065] 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. Then, the request unit 221 of the user terminal receives the one or more decoded fragments.

[0066] 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 multiple fragments of the request file are obtained, the process proceeds to step S151.

[0067] In step S151, 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 the request file.

[0068] In step S152, the file management unit 250 of the user terminal receives the multiple fragments of the request file, and stores the multiple fragments of the request file in the distributed file system storage of the user terminal.

[0069] 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).

[0070] In step S161, the request unit 221 of the user terminal passes a plurality of fragments of the request file to the file creation unit 223 of the user terminal, requesting the creation of the request file.

[0071] In step S162, the file forming unit 223 of the user terminal receives the plurality of fragments of the request file, and then forms the request file using the received plurality of fragments.

[0072] In step S163, the file forming unit 223 of the user terminal returns the request file to the request unit 221 of the user terminal.

[0073] 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.

[0074] In step S165, 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. The user 401 then views the request file.

[0075] ***Features of 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 rights of 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 file owner and transmits the encrypted file. The file reception unit 220 decrypts the encrypted file sent from the other terminal using the private key of its own account.

[0076] ***Effects of First Embodiment*** The first embodiment relates to the protection of usage rights for distributed digital data. The purpose of the first embodiment is to ensure that only the owner of the content can access the correct content. With the first embodiment, only users (owners) who have ownership rights managed by the blockchain can access files managed in the distributed file system.

[0077] A file (or fragments of a file) is encrypted and sent using the file owner's public key. This allows only the file owner to view the file. If a user is not the file owner, they cannot decrypt the encrypted file (or fragments) because the private key on the user's device does not match the public key used to encrypt the file (or fragments). Even if a malicious user sends some fragments of a file without encryption, only some fragments of the file are unencrypted, while most fragments of the file are encrypted. Therefore, only the file owner can obtain 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 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 differ 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. Therefore, the file owner may notice that the transmitted file fragments were encrypted with a different public key and obtain the complete file by obtaining the file fragments from another device.

[0078] In the first embodiment, files (fragments) are stored in the distributed file system without encryption. 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 (fragments) is encrypted and stored using the public key of the new owner each time the owner changes, the file (fragments) must be re-encrypted and stored each time ownership is transferred. As a result, the uniqueness of the file is lost. In a distributed file system, a re-encrypted file is treated as a different file from the original file. It is precisely because the content ID (hash value of the file) is immutable that unique file ownership has value, so it is important to ensure the uniqueness of the file. In the first embodiment, the uniqueness of the file is ensured by handling files in the distributed file system without encryption.

[0079] *** Supplementary Note to First Embodiment *** Based on FIG. 8, a supplementary note on blockchain will be provided. In a blockchain network, multiple block data are shared. Block data is data that is managed as a "block" by bundling multiple transactions issued by each terminal. Data management unit 310 has a function to manage each block data.

[0080] Based on Figure 9, the user's account information will be explained in more detail. Solid arrows represent input and output. Dotted arrows represent copies. A public key and a private key are used as the user's account information. The public key is used as an account ID. The public key and private key are used when issuing and receiving transactions. When issuing a transaction, 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 the private key, and the digital signature and public key are included in the transaction. When receiving a transaction, a hash value is decrypted from the digital signature in the transaction using the public key in the transaction, and it is confirmed whether the decrypted hash value matches the hash value of the transaction details. This confirms that the issuer of the transaction is a legitimate user who possesses the private key that pairs with the public key in the transaction. The account management unit 320 has the function of managing the public key and private key that constitute the user's account information. The data management unit 310 has the function of managing transactions. The data access unit 210 has the 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 the public key of the transaction issuer, not the user's public key managed by the account management unit 320. The data access unit 210 has a function to obtain the user's private key from the account management unit 320.

[0081] A bit more 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 terminal 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 you to quickly find the desired file by searching for nearby terminals based on the file's hash value.

[0082] Figure 10 shows an example of file management in IPFS. The shape at the top represents a file. The circles represent data objects, and the squares represent file fragments. Large files are split into multiple fragments and managed. Files are managed in the form of data objects. A file consists of a CID (the file's hash value), link information between fragments called "Links," and data content called "Data." Link information is necessary to create a file. By following the link information, you can reach the data content, and by combining files according to the link information, a single file is created.

[0083] A bit more about NFTs: Digital data can be easily replicated. Therefore, digital data has historically been less scarce than physical objects (e.g., gold and diamonds). However, the emergence of NFTs, which allow for the management of ownership of digital data (content) using blockchain technology, has made digital data valuable and led to its sale at high prices. NFTs are managed by linking the digital data's identifier (basically the digital data's hash value) with the owner's identifier (wallet address). This allows NFTs to guarantee ownership of 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 becomes a completely different value, confirming that the digital data is unique. The unique identifier is designed to be immutable using a smart contract. This guarantees ownership of unique digital data. Digital data is managed based on the file's hash value in a distributed file system called IPFS. When the hash value of a file recorded in an NFT is entered, the file is retrieved by collecting the fragments from multiple devices. IPFS is an abbreviation for InterPlanetary File System. When ownership is bought or sold, crypto assets (virtual currencies) are paid via a blockchain smart contract, which transfers ownership. Because NFT registration and transfer are all achieved through blockchain smart contracts, they are highly reliable, transparent, and tamper-resistant. In other words, they are highly reliable because they are automatically executed by a program without human intervention. Furthermore, 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 security. NFTs guarantee ownership of digital data. However, digital data is not protected, so people without ownership can download and view the digital data. Furthermore, people without ownership can copy and distribute downloaded digital data.In the physical world, there is a scarcity value in 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 required.

[0084] Figure 11 shows the main data items managed by NFT. The content ID and owner address can be obtained using the smart contract address and token ID. 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, it is necessary to obtain the public key from the transaction signature.

[0085] Second Embodiment A file distribution mode will be described below, focusing mainly on the differences from the first embodiment, with reference to Figs.

[0086] ***Description of Configuration*** The configuration of the usage right protection device 100 will be described with reference to Fig. 12. In the usage right protection device 100, the distributed file system unit 200 comprises an element called a file diffusion unit 270.

[0087] ***Explanation of Operation*** The usage right protection method (upload) will be described with reference to Fig. 13. 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.

[0088] In step S201, the user 401 uses the user interface to specify an upload file on the user terminal. The upload file is a file that the user wishes to store in the distributed file system.

[0089] 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.

[0090] In step S203, the file management unit 250 of the user terminal receives the uploaded file and then fragments the uploaded file according to the size of the uploaded file, thereby obtaining multiple fragments of the uploaded file.

[0091] In step S204, the file management unit 250 of the user terminal requests the file spreading unit 270 of the user terminal to spread a plurality of fragments of the uploaded file.

[0092] In step S205, the file diffusion unit 270 of the user terminal receives the multiple fragments of the uploaded file. Then, the file diffusion unit 270 of the user terminal selects one or more other terminals connected via the P2P network and transmits the multiple fragments of the uploaded file to the selected one or more other terminals. In other words, the file diffusion unit 270 of the user terminal requests the distributed file system to store the multiple fragments of the uploaded file.

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

[0094] In step S207, the file diffusion unit 270 of the other terminal receives one or more fragments of the uploaded file and stores the one or more fragments of the uploaded file in the distributed file system storage of the other terminal.

[0095] 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.

[0096] In step S209, the file management unit 250 of the other terminal receives the storage result and returns the storage result to the user terminal.

[0097] If the storage fails, steps S205 to S209 are executed for another terminal.

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

[0099] In step S211, the file management unit 250 of the user terminal receives the distribution result and returns an upload result corresponding to the distribution result to the UI unit 260 of the user terminal.

[0100] In step S212, the UI unit 260 of the user terminal receives the upload result and 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.

[0101] The diffusion of a downloaded file will be described with reference to Figure 14. The downloaded file is a file (or multiple fragments thereof) 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 the multiple fragments of the downloaded file. Thereafter, steps S204 to S211 are executed for the multiple fragments of the downloaded file.

[0102] ***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.

[0103] ***Effects of the Second Embodiment*** In a distributed file system, files are spread within the network as each terminal acquires the file. With the usage rights protection method, only the owner can decrypt the file. This makes it difficult for files to spread, and there is a possibility that the availability and permanence of the file may not be guaranteed. For example, if the owner's terminal is damaged, the file may be lost forever. However, in the second embodiment, file spreading works. This allows files to be distributed, and the availability and permanence of the file are guaranteed.

[0104] Third Embodiment A third embodiment in which a file contains public data and private data will be described, focusing mainly on the differences from the first and second embodiments, with reference to Figs.

[0105] ***Description of Configuration*** The configuration of the usage right protection device 100 will be described with reference to Fig. 15. In the usage right protection device 100, the distributed file system unit 200 comprises an element called an access management unit 280.

[0106] ***Description 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 whose access is not restricted. A private file is a file whose access is restricted.

[0107] 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 multiple fragments of the uploaded file are assigned a public flag. If the uploaded file is a private file, the multiple fragments of the uploaded file are assigned a private flag.

[0108] The access management unit 280 of the other terminal determines whether one or more fragments of the request file have been flagged as private. If one or more fragments of the request file have been flagged as private, the encryption unit 232 of the other terminal encrypts one or more fragments of the request file (step S138). Then, the encryption unit 232 of the other terminal transmits the encrypted file with the private flag to the user terminal (step S139). If one or more fragments of the request file have been flagged as public, one or more fragments of the request file are not encrypted.

[0109] The access management unit 280 of the user terminal determines whether the multiple fragments obtained from the distributed file system have private flags attached. If the multiple fragments obtained from the distributed file system have private flags attached, the decryption unit 222 of the user terminal decrypts the encrypted multiple fragments (step S147). If the multiple fragments obtained from the distributed file system have public flags attached, decryption processing for the multiple fragments is not required.

[0110] ***Features of Embodiment 3*** The usage 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 fragments of the file need to be encrypted / decrypted based on the public flag or private flag of the data object.

[0111] ***Effects of embodiment 3*** Embodiment 3 makes it possible to control that even if public and private files are mixed in a distributed file system, public files can be viewed by anyone, while private files can only be accessed by their owners.

[0112] *** Supplementary information for embodiment 3 ***

[0113] Based on FIG. 16 , a supplementary explanation about private files will be provided. The 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 sets an Encryption attribute (private flag) in the data object of the private file. If the Encryption attribute is true, encryption and decryption processes are executed. If the Encryption attribute is false, encryption and decryption processes are not executed.

[0114] Further information about NFTs will be provided based on FIG. 17 . The owner address is expressed, for example, as a 42-digit hexadecimal number. The Token URI is information indicating the location of the metadata. The name indicates the name of the NFT. The description field indicates a description of the NFT. The image field indicates the URL of the target data. The target data is, for example, an image, text, or video.

[0115] 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 the distributed file system.

[0116] 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 target data must be controlled so that only the owner can view it. On the other hand, if the metadata is encrypted, the target data is unknown and has no value. In other words, access to the metadata should not be controlled. Also, a hash value of thumbnail data of the target data may be registered in the metadata, and it is desirable that anyone can access the thumbnail data. This makes it possible 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.

[0117] 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.

[0118] ***Supplementary information on implementation form***

[0119] The hardware configuration of the usage right protection device 100 will be described with reference to Fig. 18. The usage right protection device 100 includes a processing circuit 109. The processing circuit 109 is hardware that implements the distributed file system unit 200 and the block chain unit 300. The processing circuit 109 may be dedicated hardware, or may be a processor 101 that executes a program stored in the memory 102.

[0120] When the processing circuit 109 is dedicated hardware, the processing circuit 109 may be, for example, a single circuit, a multiple circuit, a programmed processor, a parallel programmed processor, 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.

[0121] The rights protection device 100 may include a plurality of processing circuits that replace the processing circuit 109 .

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

[0123] Thus, the functions of the rights protection device 100 can be realized by hardware, software, firmware, or a combination of these.

[0124] 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.

[0125] The "unit" of each element of the rights protection device 100 may be read as a "process," a "step," a "circuit," or a "circuitry."

[0126] 100 Usage right 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 diffusion 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

1. A usage right protection device includes a distributed file system unit that receives a request from a user for a file stored in a distributed file system without being encrypted and divided into a plurality of fragments, requests the plurality of fragments of a requested file, which is the file requested by the user, from one or more terminals connected to the distributed file system, receives the plurality of fragments encrypted using the public key of the owner of the requested file from the one or more terminals, decrypts the plurality of fragments from the encrypted plurality of fragments using the secret key of the user, and forms a file using the decrypted plurality of fragments. When the secret key of the user is a secret key that pairs with the public key of the owner of the requested file, the plurality of fragments of the requested file are decrypted and the requested file is formed.

2. The usage right protection device according to claim 1 includes storage for a distributed file system, is connected to the distributed file system, and the distributed file system unit receives a request for a file stored in the distributed file system without being encrypted and divided into a plurality of fragments from a user terminal, obtains at least one fragment of a requested file, which is the file requested by the user terminal, from the storage for the distributed file system, encrypts the obtained one or more fragments using the public key of the owner of the requested file, and transmits the encrypted one or more fragments to the user terminal.

3. The usage right protection device according to claim 2 includes a blockchain unit that obtains the public key of the owner of the requested file requested from the user terminal from a blockchain.

4. A plurality of fragments of each file are stored in the distributed file system without being encrypted with a public flag or a non-public flag attached. The distributed file system unit acquires at least one fragment of the requested file from the storage for the distributed file system upon a request from the user terminal, and encrypts the acquired one or more fragments with the public key of the owner of the requested file when the non-public flag is attached to the acquired one or more fragments, and transmits the encrypted one or more fragments with the non-public flag attached to the user terminal. The usage right protection device according to claim 2 or claim 3.

5. The distributed file system unit receives a designation of an upload file, divides the upload file into a plurality of fragments, and transmits the plurality of fragments of the upload file to one or more terminals connected to the distributed file system to request storage of the plurality of fragments of the upload file in the distributed file system. The usage right protection device according to any one of claims 1 to 4.

6. The distributed file system unit receives a designation of file attributes of the upload file, and when the upload file is a non-public file, attaches a non-public flag and transmits the plurality of fragments of the upload file to the one or more terminals. The usage right protection device according to claim 5.

7. The distributed file system unit divides the request file into a plurality of fragments, and transmits the plurality of fragments of the request file to one or more terminals connected to the distributed file system to request storage of the plurality of fragments of the request file in the distributed file system. The usage right protection device according to any one of claims 1 to 6.

8. A usage right protection method that receives from a user a request for a file stored in a distributed file system without being encrypted and divided into a plurality of fragments, requests the plurality of 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 plurality of fragments encrypted using the public key of the owner of the request file from the one or more terminals, decrypts the plurality of fragments from the encrypted plurality of fragments using the secret key of the user, and forms a file using the decrypted plurality of fragments. When the secret key of the user is a secret key that pairs with the public key of the owner of the request file, the plurality of fragments of the request file are decrypted and the request file is formed.

9. A usage right protection program for causing a computer to execute a distributed file system process that receives from a user a request for a file stored in a distributed file system without being encrypted and divided into a plurality of fragments, requests the plurality of 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 plurality of fragments encrypted using the public key of the owner of the request file from the one or more terminals, decrypts the plurality of fragments from the encrypted plurality of fragments using the secret key of the user, and forms a file using the decrypted plurality of fragments. When the secret key of the user is a secret key that pairs with the public key of the owner of the request file, the plurality of fragments of the request file are decrypted and the request file is formed.

Images