USE RIGHT PROTECTION DEVICE, USE RIGHT PROTECTION METHOD, USE RIGHT PROTECTION PROGRAM, AND DISTRIBUTED FILE SYSTEM

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

[Technical Field]

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

[0002] The right to use traditional digital data is protected by 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. 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 modify 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.

[0003] Patent Document 1 proposes a method for ensuring transparency and security 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. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 6983794 Summary of the Invention [Problem to be solved by the invention]

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

[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. [Means for solving the problem]

[0007] The usage right protection device of the present disclosure comprises: The distributed file system unit 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. [Effects of the Invention]

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

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

[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] Embodiment 1 The following describes a method for protecting the right to use digital data with reference to FIGS. 1 to 11. FIG.

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

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

[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 usage right 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 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.

[0021] 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 device such as the auxiliary storage device 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 the blockchain.

[0024] FIG. 2 shows the functional configuration of the rights protection device 100. As shown in FIG. 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.

[0025] The configuration of the network system 400 will be described with reference to FIG. The network system 400 includes a plurality of license 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).

[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 blockchain.

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

[0028] 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 the file. 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 usage 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 have to be fragmented.

[0030] 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 called an "other terminal."

[0031] In step S101, the user 401 inputs a file request into the user terminal using the user interface. The user interface is, for example, a screen required to operate the user terminal, a function to accept commands, etc. The user interface is controlled by a UI unit 260.

[0032] A file request is a request for a file to a user terminal. The requested file is called the 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. 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 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 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).

[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. That is, the request unit 221 of the user terminal requests multiple fragments of the request file from another 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. 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 requested 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 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.

[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 (fragment thereof), the requested file (fragment thereof) 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 storage for the distributed file system 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.

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

[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 acquires 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. 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.

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

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

[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 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 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 will not be decrypted correctly.

[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. The request unit 221 of the user terminal then receives the decrypted one or more 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 obtaining multiple fragments of the request file, 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 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.

[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 forming unit 223 of the user terminal, requesting the formation of the request file.

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

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

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

[0076] ***Effects of the First Embodiment*** The first embodiment relates to protection of usage rights for distributed digital data. The first embodiment aims to enable only the content owner 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 in the distributed file system.

[0077] The file (fragments) are encrypted and sent using the file owner's public key, so that only the file owner can view the file. 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.

[0078] In the first embodiment, files (fragments) are stored in the distributed file system without being encrypted. Then, files (fragments) are encrypted when they are sent. This enables the transfer of ownership using NFT. 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 each 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. 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.

[0079] ***Supplement to the first embodiment*** Based on Figure 8, we will provide some additional information about blockchain. 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.

[0080] Based on Figure 9, we will add some details about user account information. Solid arrows represent input and output. 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 the account ID. Public and private keys are used when issuing and receiving transactions. When a transaction is issued, 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 .

[0081] A supplementary note about distributed file systems. IPFS is a well-known distributed file system. IPFS stands for Inter Planet File System. IPFS is designed so that a device whose ID (256 bits) is close to the hash value (256 bits) of a file remembers the ID of the device that owns the file. This allows nearby devices to be searched for based on the file's hash value, making it possible to quickly find the desired file.

[0082] Figure 10 shows an example of file management in IPFS. The top row of shapes represents files. 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 (the file's hash value), link information between fragments called "Links," and the data content called "Data." Link information is necessary to form 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, which is why it has always been less scarce than physical objects (e.g., gold and diamonds). However, the emergence of NFTs, which allow users to manage ownership of digital data (content) using blockchain technology, 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 a completely different value, 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 an 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. All NFT registration and transfer is achieved through blockchain smart contracts, making it highly reliable, transparent, and tamper-resistant. In other words, it is highly reliable because it is executed automatically by a program without human intervention. In addition, all transactions are recorded and made public, making it highly transparent. Furthermore, recorded transactions are difficult to reverse, making it highly tamper-resistant. 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.

[0084] Figure 11 shows the main data items managed by 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, it is necessary to obtain the public key from the transaction signature.

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

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

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

[0088] In step S201, the user 401 uses the user interface to specify an upload file to the user terminal. An uploaded file is a file that you want 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. 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.

[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 distribution unit 270 of the user terminal receives 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 multiple fragments of the uploaded file to the selected one or more other terminals. That is, the file distribution unit 270 of the user terminal requests the distributed file system to store 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. 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.

[0094] In step S207, the file distribution unit 270 of the other terminal receives one or more fragments of the uploaded file. Then, the file diffusion 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.

[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. Then, the file management unit 250 of the other terminal 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. 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.

[0101] The spread of downloaded files will be explained based on FIG. A download file is a file (or pieces of a file) obtained from a distributed file system. In step S151 (see the first embodiment), 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.

[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 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, file diffusion works in the second embodiment, which distributes files and ensures file availability and permanence.

[0104] Embodiment 3 The following describes a mode in which a file contains public data and private data, mainly with respect to differences from the first and second embodiments, with reference to FIGS. 15 to 17. FIG.

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

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

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

[0108] 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 to 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 one or more fragments of the request file will not be encrypted.

[0109] The access management unit 280 of the user terminal determines whether the fragments obtained from the distributed file system have private flags attached. If a private flag has been added to the multiple fragments obtained from the distributed file system, the decryption unit 222 of the user terminal decrypts the encrypted multiple 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.

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

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

[0112] ***Supplement to embodiment 3***

[0113] Based on Figure 16, we will provide additional information about private files. 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 operations are performed. If the Encryption attribute is false, the encryption and decryption processes are not performed.

[0114] Based on Figure 17, we will provide additional information about NFTs. The holder 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 field provides 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.

[0115] Files managed by NFT may contain metadata in addition to the index data managed by the blockchain (see Figure 11) and the 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.

[0116] In FIG. 17, in the blockchain, the hash value of the metadata is recorded in the TokenURI field, and the hash value of the target data is recorded in the image field 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.

[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 explanation of implementation form***

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

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

[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." [Explanation of symbols]

[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 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

1. 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; If the private key of the user is a 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. Usage rights protection device.

2. the usage right protection device includes a storage for a distributed file system and is connected to the distributed file system; The distributed file system unit receives a request from a user terminal for a file that has been split into multiple fragments and stored in the distributed file system without encryption, obtains at least one fragment of a request file that is the file requested by the user terminal from the distributed file system storage, encrypts the obtained one or more fragments using a public key of the owner of the request file, and transmits the encrypted one or more fragments to the user terminal.

2. The device for protecting usage rights according to claim 1.

3. a blockchain unit that acquires the public key of the owner of the request file requested from the user terminal from a blockchain; 3. The device for protecting usage rights according to claim 2.

4. The fragments of each file are stored in the distributed file system unencrypted and flagged as public or private; The distributed file system unit acquires from the distributed file system storage the at least one fragment of the request file requested by the user terminal, and if the private flag is attached to the acquired one or more fragments, encrypts the acquired one or more fragments using the public key of the owner of the request file, and transmits the encrypted one or more fragments with the private flag attached to the user terminal.

3. The device for protecting usage rights according to claim 2.

5. The distributed file system unit receives a designation of an uploaded file, divides the uploaded file into a plurality of fragments, and transmits the plurality of fragments of the uploaded file to one or more terminals connected to the distributed file system, requesting the distributed file system to store the plurality of fragments of the uploaded file.

2. The device for protecting usage rights according to claim 1.

6. The distributed file system unit receives a designation of a file attribute of the uploaded file, and if the uploaded file is a private file, assigns a private flag to the uploaded file and transmits the plurality of fragments of the uploaded file to the one or more terminals.

6. The device for protecting usage rights according to claim 5.

7. The distributed file system unit divides the request file into a plurality of fragments, transmits the plurality of 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 plurality of fragments of the request file. The usage right protection device according to any one of claims 1 to 6.

8. A usage right protection method, in which a usage right protection device 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 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, If the private key of the user is a 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. How to protect your rights.

9. A distributed file system process that receives a request from a user for a file that is 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. It is a usage right protection program that allows a computer to execute the If the private key of the user is a 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. Rights Protection Program.

10. A distributed file system including a plurality of terminals, in which files are split into a plurality of fragments and stored unencrypted, comprising: 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.

Images