WO2022079831A1 - 登録者端末、保有者端末、方法およびプログラム - Google Patents

登録者端末、保有者端末、方法およびプログラム Download PDF

Info

Publication number
WO2022079831A1
WO2022079831A1 PCT/JP2020/038779 JP2020038779W WO2022079831A1 WO 2022079831 A1 WO2022079831 A1 WO 2022079831A1 JP 2020038779 W JP2020038779 W JP 2020038779W WO 2022079831 A1 WO2022079831 A1 WO 2022079831A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
token
identifier
distributed ledger
chunk
Prior art date
Application number
PCT/JP2020/038779
Other languages
English (en)
French (fr)
Inventor
盛徳 大橋
篤 中平
滋 藤村
啓太 鈴木
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2020/038779 priority Critical patent/WO2022079831A1/ja
Priority to JP2022556752A priority patent/JP7452690B2/ja
Priority to US18/031,520 priority patent/US20230412385A1/en
Publication of WO2022079831A1 publication Critical patent/WO2022079831A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • Embodiments of the present invention relate to registrant terminals, holder terminals, methods and programs.
  • blockchain which is a type of decentralized distributed ledger technology, is used. Since blockchain has high robustness against tampering, it is being considered to be used for various purposes such as smart contracts that can execute various contracts or transactions in addition to cryptocurrencies.
  • transactions are not grouped in the above blocks, but there is also a distributed ledger that is expressed by the connection of transactions.
  • a distributed ledger is not suitable for managing the above files because it has a structure in which transactions for the past are left.
  • Non-Patent Document 1 As a method of distributed file management, there is a storage in which a file is managed by using a unique identifier (IDentifier) generated from a content hash or the like (for example,). See Non-Patent Document 1). There is also a method in which a file is registered in the storage and the ID of the file is recorded in the distributed ledger and managed (see, for example, Non-Patent Document 2).
  • IDentifier unique identifier
  • the file identifier When the file identifier is recorded in the distributed ledger, it is possible to specify the file after referring to the distributed ledger, but it is not possible to specify and refer to the corresponding distributed ledger information from the file.
  • the present invention has been made by paying attention to the above circumstances, and an object thereof is a registrant terminal, a holder terminal, a method, and a method in which information managed by a distributed ledger can be referred from a file. To provide a program.
  • the registrant terminal is a registrant terminal that can be connected to the distributed ledger network, generates a transaction related to the generation of a token in the distributed ledger network, and transmits the transaction to the distributed ledger network.
  • the token generation unit that generates the token in the distributed ledger network and the information in which the access information to the token is set in the file to be processed are generated, the identifier of the file to be processed is generated, and the said.
  • It includes a registration unit that generates a transaction related to registration of the identifier in the token and registers the identifier in the token by transmitting this transaction to the distributed ledger network.
  • the registrant terminal is a file holder terminal that can be connected to a distributed ledger network in which a token including an identifier of a file to be processed is held, and the file to be processed includes the token.
  • the acquisition unit that acquires the file identifier from the token by using the access information to the token described in the file to be processed, the file identifier of the file to be processed, and the file identifier of the file to be processed.
  • a determination unit for determining that the file identifier acquired by the acquisition unit matches the file identifier is provided.
  • the holder terminal is a file holder terminal capable of connecting to a distributed ledger network in which a token including a user identifier which is a legitimate user identifier of a file stored in a storage device is held.
  • a token including a user identifier which is a legitimate user identifier of a file stored in a storage device is held.
  • the request is related to the acquisition of the file stored in the storage device, and includes the identifier of the user who requested the request.
  • the acquisition unit that acquires the user identifier from the token by using the access information to the token described in the file stored in the storage device, the identifier included in the request, and the acquisition. It includes a transmission unit that transmits a file stored in the storage device to the request source when the user identifier acquired by the unit matches.
  • the registration method is a method performed by a registrant terminal that can connect to the distributed ledger network, generates a transaction related to the generation of a token in the distributed ledger network, and transfers the transaction to the distributed ledger.
  • the token is generated in the distributed ledger network, the information in which the access information to the token is set in the file to be processed is generated, and the identifier of the file to be processed is generated.
  • a transaction relating to the registration of the identifier in the token is generated, and the transaction is transmitted to the distributed ledger network to register the identifier in the token.
  • the information managed by the distributed ledger can be referred from the file.
  • FIG. 1 is a diagram showing an application example of a management system according to an embodiment of the present invention.
  • FIG. 2 is a diagram showing an application example of the management system according to the embodiment of the present invention.
  • FIG. 3 is a block diagram showing an example of the functional configuration of the file registrant terminal.
  • FIG. 4 is a block diagram showing an example of the functional configuration of the file holder terminal.
  • FIG. 5 is a block diagram showing an example of the functional configuration of the user terminal.
  • FIG. 6 is a diagram showing an example of information managed by a distributed ledger and information managed by a file used in one embodiment of the present invention.
  • FIG. 7 is a diagram showing an example of information managed by a distributed ledger and information managed by a file used in one embodiment of the present invention.
  • FIG. 1 is a diagram showing an application example of a management system according to an embodiment of the present invention.
  • FIG. 2 is a diagram showing an application example of the management system according to the embodiment of the present invention.
  • FIG. 3
  • FIG. 8 is a diagram showing a sequence for explaining an example of a file registration process for normal storage.
  • FIG. 9 is a diagram showing a sequence illustrating an example of a file registration process for a storage in which a file is converted to a DAG.
  • FIG. 10 is a diagram showing a sequence for explaining an example of file association verification processing for normal storage.
  • FIG. 11 is a diagram showing a sequence for explaining an example of the file association verification process for the storage in which the file is DAG-ized.
  • FIG. 12 is a diagram showing a sequence for explaining an example of the file pre-transmission verification process for the normal storage.
  • FIG. 13 is a diagram showing a sequence for explaining an example of the file pre-transmission verification process for the storage in which the file is DAG-ized.
  • FIG. 14 is a block diagram showing an example of a hardware configuration of a file registrant terminal according to an embodiment of the present invention.
  • FIG. 1 and 2 are diagrams showing an application example of the management system according to the embodiment of the present invention.
  • FIG. 1 shows an overall network configuration for a management system according to an embodiment of the present invention.
  • the file registrant terminal 1, the file holder terminal 2, and the user terminal 3 can be connected via a network, and each terminal can be connected. It is a system that can communicate with each other.
  • FIG. 2 shows a network configuration of an application program of a distributed ledger according to a management system according to an embodiment of the present invention.
  • the management system 100 according to the embodiment of the present invention includes a file registrant terminal 1, a file holder terminal 2, and a user terminal 3, and each terminal can communicate with each other. Is.
  • the file registrant terminal 1, the file holder terminal 2, and the user terminal 3 have an access function to the distributed ledger network 4, and the private key associated with each account (account) is the user and the file registrant. , And under the control of the file owner.
  • the location where the private key is stored is not specified.
  • the distributed ledger network 4 is composed of a plurality of terminals.
  • the file registrant terminal 1 and the file holder terminal 2 may have a node function for maintaining the distributed ledger network 4 with the user terminal 3. Further, a terminal that substitutes for the node function may be provided between each of the distributed ledger network 4, the file registrant terminal 1, the file holder terminal 2, and the user terminal 3.
  • the node function is a function for verifying and approving network transactions, and updating and holding ledger information (block information and state database, etc.).
  • the file holder terminal 2 or the user terminal 3 has a conversion function from a DAG (Directed acyclic graph) format file to a normal format file.
  • the file registrant terminal 1 and the file holder terminal 2 may be the same terminal.
  • a terminal that substitutes for the node function may exist in the distributed ledger network 4. This terminal is called another node.
  • another node 5 that maintains the distributed ledger network 4 may exist.
  • the file registrant terminal 1, the file holder terminal 2, and the user terminal 3 do not have to include the node function when another node 5 that substitutes for the node function exists.
  • a case where the file registrant terminal 1, the file holder terminal 2, and the user terminal 3 also execute the node function will be described.
  • FIG. 3 is a block diagram showing an example of the functional configuration of the file registrant terminal.
  • the file registrant terminal 1 has a file utilization unit 11, an access function unit 12, a node function unit 13, and a communication unit 14.
  • the file utilization unit 11 has a file management DB (database) 11a
  • the access function unit 12 has a key management DB 12a
  • the node function unit 13 has a network (NW) maintenance / identification information DB 13a.
  • NW network maintenance / identification information DB 13a.
  • the various databases in this embodiment are also referred to as storage.
  • the file usage unit 11 manages files, for example, creates, updates, or uses them, and stores the managed data in the file management DB 11a.
  • the file utilization unit 11 also manages the key required for managing the file.
  • the access function unit 12 issues transactions to the network and sends / receives files to / from other terminals. Further, the access function unit 12 stores the key information used in the access in the key management DB 12a.
  • the node function unit 13 executes the above-mentioned node function and stores information for network maintenance and identification in the process in the network (NW) maintenance / identification information DB 13a.
  • the communication unit 14 is responsible for communication with the outside.
  • FIG. 4 is a block diagram showing an example of the functional configuration of the file holder terminal.
  • the file holder terminal 2 has a file utilization unit 21, an access function unit 22, a node function unit 23, and a communication unit 24.
  • the file utilization unit 21 has a file management DB 21a
  • the access function unit 22 has a key management DB 22a
  • the node function unit 23 has a network (NW) maintenance / identification information DB 23a.
  • NW network
  • the file utilization unit 21 performs the same processing as the file utilization unit 11 described above, and stores the managed data in the file management DB 21a.
  • the access function unit 22 performs the same processing as the access function unit 12 described above, and stores the key information used in the access in the key management DB 22a.
  • the node function unit 23 executes the above-mentioned node function, and stores the above-mentioned information for network maintenance and identification in the network (NW) maintenance / identification information DB 23a.
  • the communication unit 24 is responsible for communication with the outside.
  • FIG. 5 is a block diagram showing an example of the functional configuration of the user terminal.
  • the user terminal 3 has a file utilization unit 31, an access function unit 32, a node function unit 33, and a communication unit 34.
  • the file utilization unit 31 has a file management DB 31a
  • the access function unit 32 has a key management DB 32a
  • the node function unit 33 has a network (NW) maintenance / identification information DB 33a.
  • NW network
  • the file utilization unit 31 performs the same processing as the file utilization unit 11 described above, and stores the managed data in the file management DB 31a.
  • the access function unit 32 performs the same processing as the access function unit 12 described above, and stores the key information used in the access in the key management DB 32a.
  • the node function unit 33 executes the above-mentioned node function, and stores the above-mentioned information for network maintenance and identification in the network (NW) maintenance / identification information DB 33a.
  • the communication unit 34 is responsible for communication with the outside.
  • FIG. 6 and 7 are diagrams showing an example of information managed by the distributed ledger and information managed by the file used in one embodiment of the present invention.
  • token C A and token C A' are managed, and the file hash F A , which is a file identifier, is managed in each token.
  • access information to token CA is embedded in the header of each file.
  • ID of the file (identifier created from the hash) is recorded in the token, so that the relationship between the correct token and the file can be confirmed.
  • the access information to the token is not limited to the example of being embedded in the header of the file as described above.
  • a folder structure is generated in the file, and the access information to the token is incorporated in this folder structure. Then, by performing archiving or compression processing by, for example, a tar method or a zip method, a file containing access information to the token may be generated.
  • token C A and token C A ⁇ are managed, and in each token, the chunk identifiers chunk hash FC A_1 , chunk hash FC A_2 , and chunk hash FC are managed. Multiple chunk hashes, including A_3 , are managed.
  • access information to token CA is embedded in each chunk, and a DAG format file is formed by the chunks in which the access information is embedded in this way.
  • the chunk ID (identifier created from the hash) is recorded in the token, so that the correct relationship between the token and the chunk can be confirmed.
  • the storage in which files are converted to DAG is, for example, IPFS (InterPlanetary File System).
  • IPFS InterPlanetary File System
  • the access information is stored at the beginning of the Data item of each IPFS object separately from the chunk information of the file body.
  • This registration process is a process in which the identifier related to the file to be processed is registered in the token on the distributed ledger network.
  • the storage used in each terminal is divided into normal storage and storage in which files are converted to DAG.
  • Normal storage is storage in which files are not DAG-ized.
  • FIG. 8 is a diagram showing a sequence for explaining an example of a file registration process for normal storage.
  • the file utilization unit 11 of the file registrant terminal 1 instructs the access function unit 12 to generate a token to the distributed ledger, which is a token related to the file to be processed, which is stored in the file management DB 11a (S11). ).
  • the access function unit 12 of the file registrant terminal 1 performs a token generation process for the distributed ledger (S12).
  • the access function unit 12 creates a transaction for generating a Token to the distributed ledger without including a file identifier, and broadcasts it to the distributed ledger network 4 via the communication unit 14. (S12-1).
  • the access function unit 12 sends a transaction result notification request to the node function unit 13 (S12-2).
  • the transaction is verified by the consensus algorithm in the distributed ledger network 4. If this transaction meets a predetermined requirement, this transaction is confirmed (S12-3).
  • the node function unit 13 When the node function unit 13 receives the transaction result from the distributed ledger network 4 via the communication unit 14, the node function unit 13 returns this result to the access function unit 12 (S12-4). In response to this result, the access function unit 12 creates "access information to Token" for the file to be processed (S12-5). As a result, the processing of S12 is performed. The access function unit 12 returns the created "access information to the Token" to the file usage unit 11 (S13).
  • the file utilization unit 11 records the "access information to Token" returned in S13 in the header (sometimes referred to as a file header) of the file to be processed, which is stored in the file management DB 11a. do.
  • a plurality of "access information to Token" may be recorded in the file header.
  • the file usage unit 11 generates a file identifier (for example, hash) of a file in which access information to the Token is recorded in the file header (S14).
  • a file identifier for example, hash
  • the file is transmitted to the file holder terminal 2, and the identifier used for file acquisition may be generated by the file holder terminal 2.
  • the file utilization unit 11 records the "access information to the Token" returned in S13 in an access information file different from the file to be processed, and then files.
  • a file to be processed and an access information file stored in the management DB 11a may be stored in the same folder, and a file may be created by archiving or compressing this folder to generate a file identifier of the file.
  • the file usage unit 11 sends a Token update, here an instruction to register a file identifier to the Token, to the access function unit 12 (S15).
  • the access function unit 12 performs a file identifier registration process in the Token related to the above-mentioned "access information to the Token" managed by the distributed ledger (S16).
  • the access function unit 12 creates a transaction for registering a file identifier in the Token managed by the distributed ledger network 4 and broadcasts it to the distributed ledger network 4 via the communication unit 14 (S16-1). ).
  • the access function unit 12 sends a transaction result notification request to the node function unit 13 (S16-2).
  • the transaction is verified by the concession algorithm in the distributed ledger network 4. If this transaction meets a predetermined requirement, this transaction is approved (S16-3).
  • the node function unit 13 When the node function unit 13 receives the transaction result from the distributed ledger network 4 via the communication unit 14, the node function unit 13 returns this result to the access function unit 12 (S16-4). As a result, the file identifier is recorded in the Token by S16. In response to this result, the access function unit 12 notifies the file utilization unit 11 of the Token update completion notification (S17).
  • FIG. 9 is a diagram showing a sequence illustrating an example of a file registration process for a storage in which a file is converted to a DAG.
  • the access function unit 12 is instructed to generate a token in the distributed ledger, as in the file registration process for the normal storage.
  • the token generation process for the distributed ledger is performed.
  • the created "access information to Token" is returned to the file usage unit 11.
  • the file utilization unit 11 records "access information to Token" in the header of the file to be processed (S111). Here, a plurality of "access information to Token” may be recorded. (3) The file utilization unit 11 removes the header of the file and divides the remaining portion into temporary chunks (S112). (4) The file utilization unit 11 updates the temporary chunks by adding the header of the file to each temporary chunk (S113).
  • the file utilization unit 11 records the "access information to the Token" returned in S13 in the access information file, and the file to be processed and the access information file stored in the file management DB 11a are the same. Create a file by storing it in a folder and archiving or compressing this folder.
  • the file utilization unit 11 restores the archived or compressed file to the original folder, removes the access information file stored in this folder, and divides the remaining portion into temporary chunks.
  • the file utilization unit 11 updates the temporary chunks by adding the access information to the Token recorded in the access information file stored in the above folder to each temporary chunk (S113).
  • the file utilization unit 11 creates a DAG-ized file based on the temporary chunks, and generates an identifier of each chunk forming the DAG-ized file. (S114).
  • the file utilization unit 11 records the "access information to the Token" returned in S13 in the access information file, and for each of the temporary chunks, the temporary chunk and the above access information.
  • this folder creates an archived or compressed file, creates a DAG file based on this file, and forms this DAG file for each chunk An identifier may be generated.
  • the file usage unit 11 sends a Token update, here an instruction to register a chunk identifier to the Token, to the access function unit 12 (S115).
  • the access function unit 12 performs a chunk identifier registration process for the Token related to the above-mentioned "access information to the Token" managed by the distributed ledger (S116).
  • the access function unit 12 creates a transaction for registering a chunk identifier in the Token managed by the distributed ledger network 4 and broadcasts it to the distributed ledger network 4 via the communication unit 14 (S116-1). ).
  • the access function unit 12 sends a transaction result notification request to the node function unit 13 (S116-2).
  • the transaction is verified by the concession algorithm in the distributed ledger network 4. If this transaction meets the predetermined requirements, this transaction is approved (S116-3).
  • the node function unit 13 When the node function unit 13 receives the transaction result from the distributed ledger network 4 via the communication unit 14, the node function unit 13 returns this result to the access function unit 12 (S116-4). As a result, the chunk identifier is recorded in the Token by S116. In response to this result, the access function unit 12 notifies the file utilization unit 11 of the Token update completion notification (S117).
  • the entire file including the header is divided into chunks, so chunks that do not include header information are generated.
  • a header including at least access information to the Token is added to each chunk.
  • FIG. 10 is a diagram showing a sequence for explaining an example of file association verification processing for normal storage.
  • the file usage unit 21 of the file holder terminal 2 acquires "access information to Token" described in the file header of the updated file to be processed (S41), and uses this access information. Then, the access function unit 22 is instructed to acquire the file identifier in the control information in the token managed by the distributed ledger network 4 (S42).
  • the file utilization unit 21 restores the archived or compressed file to the original folder. Then, the access information file stored in this folder is acquired, and the file identifier in the control information in the token managed by the distributed ledger network 4 is used by using the "access information to Token" recorded in this access information file. Is instructed to the access function unit 22 to acquire the file.
  • the access function unit 22 instructs the node function unit 23 to acquire the control information from the token (S43).
  • the node function unit 23 accesses the distributed ledger network 4 via the communication unit 24 to obtain control information from the token related to the above-mentioned "access information to Token" managed by the distributed ledger.
  • the file identifier is acquired from the control information, and this file identifier is returned to the access function unit 22 (S44).
  • the access function unit 22 returns this file identifier to the file utilization unit 21 (S45).
  • the file identifier of the updated file to be processed is stored and managed in the file management DB 21a.
  • the file utilization unit 21 acquires the file identifier of the updated file to be processed from the file management DB 21a, compares this file identifier with the file identifier returned in S45, and confirms that they match. (Verification) (S46).
  • the file utilization unit 21 restores the file to be processed to the original folder and then stores the file in this folder.
  • the file identifier of the updated file to be processed is acquired from the file management DB 21a, and this file identifier is compared with the file identifier returned in S45, and it is confirmed (verified) that they match.
  • FIG. 11 is a diagram showing a sequence for explaining an example of the file association verification process for the storage in which the file is DAG-ized.
  • the file usage unit 21 of the file holder terminal 2 acquires "access information to Token" described in the chunk of the file to be processed (S141), and acquires control information using this access information. Is instructed to the access function unit 22 (S142). In response to this instruction, the access function unit 22 instructs the node function unit 23 to acquire the control information from the token (S143).
  • the file utilization unit 21 is based on the archived or compressed file. Restore to the folder of, acquire the access information file stored in this folder, and use the "access information to Token" recorded in this access information file to control the tokens managed by the distributed ledger network 4. Instruct the access function unit 22 to acquire the file identifier in the information.
  • the node function unit 23 accesses the distributed ledger network 4 via the communication unit 24 to obtain control information from the token related to the above-mentioned "access information to Token" managed by the distributed ledger.
  • the chunk identifier is acquired from the control information, and the chunk identifier is returned to the access function unit 22 (S144).
  • the access function unit 22 returns the identifier of this chunk to the file utilization unit 21 (S145).
  • the chunk identifier of the chunk of the updated file, which is the processing target, is stored and managed in the file management DB 21a.
  • the file utilization unit 21 acquires the chunk identifier of the chunk of the updated file to be processed from the file management DB 21a, and uses this chunk identifier and the chunk identifier described in the control information returned in S145. Are compared, and it is confirmed (verified) that they match (S146).
  • the file utilization unit 21 restores the file to be processed to the original folder and then processes the file.
  • the chunk of the updated file stored in this folder is identified, the chunk identifier of this chunk is obtained from the file management DB 21a, and this chunk identifier is compared with the chunk identifier returned in S145. Confirm (verify) that these match.
  • the file header or each chunk contains access information to the Token, so that the Token is set for each file or chunk. It is possible to verify the validity of a file or chunk even if it is disjointed.
  • the pre-transmission verification process means that when the user terminal 3 requests the acquisition of a file or chunk held in the storage of the file holder terminal 2, the file corresponding to the user terminal 3 is used in response to the request. This is a process that verifies whether or not transmission is possible.
  • the token managed on the distributed ledger network 4 has an identifier such as a file held by the file holder terminal 2 and a use permitted to acquire this file or the like.
  • the user identifier which is the identifier of the person, is managed.
  • FIG. 12 is a diagram showing a sequence for explaining an example of the file association verification process for the normal storage.
  • the access function unit 32 of the user terminal 3 transmits a file acquisition request to the file owner terminal 2 to the file owner terminal 2 via the communication unit 34 according to the operation by the user.
  • This request includes at least the file identifier of the file to be requested and the user identifier given to the user of the user terminal 3.
  • the file usage unit 21 of the file holder terminal 2 receives a file acquisition request from the user via the communication unit 24 (S51).
  • the file utilization unit 21 of the file holder terminal 2 identifies a file specified to be acquired in the request received in S51 from the file stored in the file management DB 21a, and describes the file in the file header of this file.
  • the "access information to the Token" is acquired (S52), and the access function unit 22 is instructed to acquire the user identifier using this access information (S53).
  • the access function unit 22 instructs the node function unit 23 to acquire the control information from the token (S54).
  • the file utilization unit 21 is stored in the file management DB 21a and is archived or compressed. Access function to restore the file to the original folder, acquire the access information file stored in this folder, and use the "access information to Token" recorded in this access information file to acquire the user identifier. Instruct unit 22.
  • the node function unit 23 acquires control information from the token managed by the distributed ledger network 4, acquires a user identifier from the control information, and transfers this user identifier to the access function unit 22. Return (S55).
  • the access function unit 22 returns this user identifier to the file user unit 21 (S56).
  • the control information of the plurality of Tokens is acquired.
  • the file user unit 21 compares the user identifier returned in S56 with the user identifier included in the request from the user terminal 3, and these identifiers match, that is, the use included in the request. It is confirmed (verified) that the person identifier is a request from a user who is permitted to acquire the retained file (S57).
  • the file user unit 21 transmits the file specified by the request to the user terminal 3 via the communication unit 24.
  • the access function unit 32 of the user terminal 3 acquires the transmitted file via the communication unit 34 (S58).
  • FIG. 12 is a diagram showing a sequence for explaining an example of the file pre-transmission verification process for the storage in which the file is DAG-ized.
  • the access function unit 32 of the user terminal 3 transmits a chunk acquisition request to the file owner terminal 2 to the file owner terminal 2 via the communication unit 34 according to the operation by the user.
  • This request includes at least the chunk identifier of the chunk of the file to be requested and the user identifier given to the user of the user terminal 3.
  • the file usage unit 21 of the file holder terminal 2 receives a request for chunk acquisition from the user via the communication unit 24 (S151).
  • the file utilization unit 21 identifies the chunk specified to be acquired in the request received in S51 from the chunk of the file stored in the file management DB 21a, and the "access information to Token" described in this chunk. (S152), and instructing the access function unit 22 to acquire the user identifier using this access information (S153). In response to this instruction, the access function unit 22 instructs the node function unit 23 to acquire the control information from the token (S154).
  • the file utilization unit 21 stores the archive in the file management DB 21a.
  • the file management DB 21a identify the chunk specified to be acquired in the request received in S151, and access information stored in the folder together with this chunk.
  • the "access information to the Token" recorded in the file is acquired, and the access function unit 22 is instructed to acquire the user identifier using this access information.
  • the node function unit 23 acquires control information from the token managed by the distributed ledger network 4, acquires a user identifier from the control information, and transfers this user identifier to the access function unit 22. Return it (S155).
  • the access function unit 22 returns this user identifier to the file user unit 21 (S156).
  • the control information of the plurality of Tokens is acquired.
  • the file user unit 21 compares the user identifier returned in S56 with the user identifier included in the request from the user terminal 3, and these identifiers match, that is, are included in the request. It is confirmed (verified) that the user identifier is a request from a user who is permitted to acquire the retained file (S157).
  • the file user unit 21 transmits the chunk specified in the request to the user terminal 3 via the communication unit 24.
  • the access function unit 32 of the user terminal 3 acquires the transmitted chunk via the communication unit 34 (S158).
  • the access information to the Token is displayed in the file header or each chunk regardless of whether the state of the requested data is a normal file state or a DAG-ized file state. Since it is included, it is possible to control sharing of files or chunks even if the Tokens are different for each file or chunk.
  • the file to be processed is a file that includes the access information file and is archived or compressed, in these (2) and (3), from the chunk to the fragment of the file body and the access information file in the file. May be obtained and it may be confirmed that all access information files obtained from all chunks are the same.
  • the file to be processed includes the access information to the token on the distributed ledger, and the identifier of the file is included in the token. Therefore, the management system is managed by the distributed ledger. You can refer to the information to be created from the file.
  • FIG. 14 is a block diagram showing an example of the hardware configuration of the file registrant terminal according to the embodiment of the present invention.
  • the file registrant terminal 1 is configured by, for example, a server computer or a personal computer, and is a hardware processor 111 such as a CPU (Central Processing Unit). Has. Then, the program memory 111B, the data memory 112, the input / output interface 113, and the communication interface 114 are connected to the hardware processor 111 via the bus 120. .. The same applies to the file holder terminal 2 and the user terminal 3.
  • a hardware processor 111 such as a CPU (Central Processing Unit).
  • the program memory 111B, the data memory 112, the input / output interface 113, and the communication interface 114 are connected to the hardware processor 111 via the bus 120. ..
  • the communication interface 114 includes, for example, one or more wireless communication interface units, and enables information to be transmitted / received to / from the communication network NW.
  • the wireless interface an interface adopting a low power wireless data communication standard such as a wireless LAN (Local Area Network) can be used.
  • An input device (device) 130 and an output device 140 for an operator (operator) attached to the file registrant terminal 1 are connected to the input / output interface 113.
  • the input / output interface 113 captures operation data input by an operator through an input device 130 such as a keyboard, touch panel, touchpad, mouse, etc., and outputs data as liquid crystal or organic.
  • a process of outputting to an output device 140 including a display device using an EL (organic electro-luminescence) or the like and displaying the device is performed.
  • a device built in the file registrant terminal 1 may be used, and another information terminal capable of communicating with the file registrant terminal 1 via the communication network NW. Input and output devices of may be used.
  • the program memory 111B is a non-volatile memory such as an HDD (Hard Disk Drive) or SSD (Solid State Drive) that can be written and read at any time as a non-temporary tangible storage medium, and a ROM (Read Only Memory). It is used in combination with non-volatile memory such as, and stores programs necessary for executing various control processes according to one embodiment.
  • HDD Hard Disk Drive
  • SSD Solid State Drive
  • ROM Read Only Memory
  • the data memory 112 is used as a tangible storage medium, for example, in combination with the above-mentioned non-volatile memory and a volatile memory such as RAM (RandomAccessMemory), and various processes are performed. It is used to store various data acquired and created in the process.
  • RAM RandomAccessMemory
  • the file registrant terminal 1 has a file utilization unit 11, an access function unit 12, a node function unit 13, and a communication unit 14 shown in FIG. 3 as processing function units by software. Can be configured as a data processing device with.
  • the various databases shown in FIG. 3 can be configured using the data memory 112 shown in FIG.
  • the above various databases are not indispensable in the file registrant terminal 1, for example, an external storage medium such as a USB (Universal Serial Bus) memory, or a database server located in the cloud. ) Etc. may be provided in a storage device.
  • the processing function units in each of the file utilization unit 11, the access function unit 12, the node function unit 13, and the communication unit 14 shown in FIG. 3 all use the program stored in the program memory 111B as the hardware processor. It can be realized by reading and executing by 111. It should be noted that some or all of these processing functional units may be realized by other various formats including integrated circuits such as integrated circuits (ASICs) for specific applications or FPGAs (Field-Programmable Gate Arrays).
  • ASICs integrated circuits
  • FPGAs Field-Programmable Gate Arrays
  • the method described in each embodiment is, for example, a magnetic disk (floppy disk (registered trademark) disk (Floppy disk), hard disk (hard disk)) as a program (software means) that can be executed by a computer (computer).
  • Etc. stored in recording media such as optical discs (CD-ROM, DVD, MO, etc.), semiconductor memory (ROM, RAM, Flash memory, etc.), and transmitted and distributed by communication media.
  • the program stored on the medium side also includes a setting program for configuring the software means (including not only the execution program but also the table and the data structure) to be executed by the computer in the computer.
  • a computer that realizes this device reads a program recorded on a recording medium, constructs software means by a setting program in some cases, and executes the above-mentioned processing by controlling the operation by the software means.
  • the recording medium referred to in the present specification is not limited to distribution, and includes storage media such as magnetic disks and semiconductor memories provided in devices connected inside a computer or via a network.
  • the present invention is not limited to the above embodiment, and can be variously modified at the implementation stage without departing from the gist thereof.
  • each embodiment may be carried out in combination as appropriate, in which case the combined effect can be obtained.
  • the above-described embodiment includes various inventions, and various inventions can be extracted by a combination selected from a plurality of disclosed constituent requirements. For example, even if some constituent elements are deleted from all the constituent elements shown in the embodiment, if the problem can be solved and the effect is obtained, the configuration in which the constituent elements are deleted can be extracted as an invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computing Systems (AREA)

Abstract

一実施形態に係る登録者端末は、分散台帳ネットワークに接続可能な登録者端末であって、前記分散台帳ネットワークへのトークンの生成に関するトランザクションを生成し、前記トランザクションを前記分散台帳ネットワークに送信することで前記分散台帳ネットワークに前記トークンを生成するトークン生成部と、処理対象のファイルに前記トークンへのアクセス情報が設定された情報を生成し、前記処理対象のファイルの識別子を生成し、前記トークンへの前記識別子の登録に関するトランザクションを生成し、このトランザクションを前記分散台帳ネットワークに送信することで前記トークンに前記識別子を登録する登録部と、を有する。

Description

登録者端末、保有者端末、方法およびプログラム
　本発明の実施形態は、登録者端末、保有者端末、方法およびプログラムに関する。
　ビットコイン（bitcoin）（登録商標）に代表される暗号通貨の取引においては、非中央集権型の分散台帳技術の一種であるブロックチェーン（blockchain）が用いられている。ブロックチェーンは、改ざんに対して高い堅牢性を有する為、暗号通貨以外にも、種々の契約、又は取引を実行出来るスマートコントラクト（smart contract）等の様々な用途への利用が検討されている。
　スマートコントラクトを扱うことが出来るプログラマブル（programmable）なブロックチェーンとして、例えば、汎用的な分散型アプリケーションプログラム（application program）が実行出来るイーサリアム（Ethereum）がある。
　様々なスマートコントラクトを実現可能な分散台帳技術では、トランザクション（transaction）がブロック（block）に纏められる分散台帳が存在する。このような分散台帳では、ブロック間がハッシュ（hash）で連関されるデータ構造を有する為、データサイズ（data size）が大きなファイル（file）の管理には不向きである。
　また、分散台帳技術では、トランザクションが上記のブロックには纏められるのではなく、トランザクションの繋がりにより表現される分散台帳も存在する。しかし、このような分散台帳では、過去分のトランザクションが残される構造を有する為、上記のファイルの管理には不向きである。
　分散型のファイル管理の方法として、コンテンツハッシュ（content hash）等から生成されるユニーク（unique）な識別子（ＩＤ（IDentifier））が用いられてファイルが管理されるストレージ（storage）がある（例えば、非特許文献１参照）。また、当該ストレージにファイルが登録されて、ファイルのＩＤが分散台帳に記録されて管理される方法もある（例えば、非特許文献２参照）。
Juan Banet、"IPFS - Content Addressed, Versioned, P2P File System (DRAFT 3)"、［online］、［令和２年９月１０日検索］、インターネット〈URL：https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf〉 Micheal Chan、"Build a simple Ethereum + InterPlanetary File System (IPFS)+ React.js DApp."、［online］、［令和２年９月１０日検索］、インターネット〈URL：https://itnext.io/build-a-simple-ethereum-interplanetary-file-system-ipfs-react-js-dapp-23ff4914ce4e〉
　分散台帳にファイルの識別子が記録される場合、分散台帳を参照してからファイルを特定することは可能だが、ファイルから、対応する分散台帳の情報を特定して参照することはできない。
　例えば、分散台帳上にファイルのハッシュが記録されるときは、ファイルから、参照するべきトークンを特定することはできない。分散台帳上にチャンクのハッシュが記録される場合についても同様である。
　この発明は、上記事情に着目してなされたもので、その目的とするところは、分散台帳で管理される情報をファイルから参照することができるようにした登録者端末、保有者端末、方法およびプログラムを提供することにある。
　本発明の一態様に係る登録者端末は、分散台帳ネットワークに接続可能な登録者端末であって、前記分散台帳ネットワークへのトークンの生成に関するトランザクションを生成し、前記トランザクションを前記分散台帳ネットワークに送信することで前記分散台帳ネットワークに前記トークンを生成するトークン生成部と、処理対象のファイルに前記トークンへのアクセス情報が設定された情報を生成し、前記処理対象のファイルの識別子を生成し、前記トークンへの前記識別子の登録に関するトランザクションを生成し、このトランザクションを前記分散台帳ネットワークに送信することで前記トークンに前記識別子を登録する登録部と、を備える。
　本発明の一態様に係る登録者端末は、処理対象のファイルの識別子を含むトークンが保持される分散台帳ネットワークに接続可能なファイル保有者端末であって、前記処理対象のファイルには、前記トークンへのアクセス情報が記載され、前記処理対象のファイルに記載された、前記トークンへのアクセス情報を用いて、前記トークンからファイル識別子を取得する取得部と、前記処理対象のファイルのファイル識別子と、前記取得部により取得されたファイル識別子とが一致することを判定する判定部と、を備える。
　本発明の一態様に係る保有者端末は、記憶装置に記憶されるファイルの正当な利用者の識別子である利用者識別子を含むトークンが保持される分散台帳ネットワークに接続可能であるファイル保有者端末であって、前記記憶装置に記憶されるファイルには、前記トークンへのアクセス情報が記載され、前記記憶装置に記憶されるファイルの取得に関するリクエストであって、リクエスト元の利用者の識別子を含むリクエストに応じて、前記記憶装置に記憶されるファイルに記載される前記トークンへのアクセス情報を用いて、前記トークンから前記利用者識別子を取得する取得部と、前記リクエストに含まれる識別子と前記取得部により取得された利用者識別子とが一致する場合に、前記記憶装置に記憶されるファイルを前記リクエスト元に送信する送信部と、を備える。
　本発明の一態様に係る登録方法は、分散台帳ネットワークに接続可能な登録者端末により行なわれる方法であって、前記分散台帳ネットワークへのトークンの生成に関するトランザクションを生成し、前記トランザクションを前記分散台帳ネットワークに送信することで前記分散台帳ネットワークに前記トークンを生成することと、処理対象のファイルに前記トークンへのアクセス情報が設定された情報を生成し、前記処理対象のファイルの識別子を生成し、前記トークンへの前記識別子の登録に関するトランザクションを生成し、このトランザクションを前記分散台帳ネットワークに送信することで前記トークンに前記識別子を登録することと、を備える。
　本発明によれば、分散台帳で管理される情報をファイルから参照することができる。
図１は、本発明の一実施形態に係る管理システム（system）の適用例を示す図である。 図２は、本発明の一実施形態に係る管理システムの適用例を示す図である。 図３は、ファイル登録者端末の機能構成の一例を示すブロック図（block diagram）である。 図４は、ファイル保有者端末の機能構成の一例を示すブロック図である。 図５は、利用者端末の機能構成の一例を示すブロック図である。 図６は、本発明の一実施形態で用いられる分散台帳で管理される情報およびファイルで管理される情報の一例を示す図である。 図７は、本発明の一実施形態で用いられる分散台帳で管理される情報およびファイルで管理される情報の一例を示す図である。 図８は、通常ストレージに対するファイルの登録処理の一例を説明するシーケンス（sequence）を示す図である。 図９は、ファイルがDAG化されるストレージに対するファイルの登録処理の一例を説明するシーケンスを示す図である。 図１０は、通常ストレージに対するファイルの紐付け検証処理の一例を説明するシーケンスを示す図である。 図１１は、ファイルがDAG化されるストレージに対するファイルの紐付け検証処理の一例を説明するシーケンスを示す図である。 図１２は、通常ストレージに対するファイルの送信前検証処理の一例を説明するシーケンスを示す図である。 図１３は、ファイルがDAG化されるストレージに対するファイルの送信前検証処理の一例を説明するシーケンスを示す図である。 図１４は、本発明の一実施形態に係るファイル登録者端末のハードウエア（hardware）構成の一例を示すブロック図である。
　以下、図面を参照しながら、この発明に係わる一実施形態を説明する。　
　図１および図２は、本発明の一実施形態に係る管理システムの適用例を示す図である。図１では、本発明の一実施形態に係る管理システムに係るネットワーク（network）全体構成が示される。　
　図１に示されるように、本発明の一実施形態に係る管理システム１００では、ファイル登録者端末１、ファイル保有者端末２、および利用者端末３がネットワークを介して接続可能で、各端末が相互に通信可能なシステムである。
　図２では、本発明の一実施形態に係る管理システムに係る分散台帳のアプリケーションプログラムのネットワーク構成が示される。　
　図２に示される例では、本発明の一実施形態に係る管理システム１００は、ファイル登録者端末１、ファイル保有者端末２、および利用者端末３を含み、各端末が相互に通信可能なシステムである。　
　ファイル登録者端末１と、ファイル保有者端末２と、利用者端末３は、分散台帳ネットワーク４へのアクセス機能を有し、各アカウント（account）に紐付けられる秘密鍵が利用者、ファイル登録者、およびファイル保有者の管理下にある。秘密鍵が保存される場所は特に指定されない。
　分散台帳ネットワーク４は、複数の端末により構成される。ファイル登録者端末１とファイル保有者端末２を利用者端末３とは分散台帳ネットワーク４を維持するためのノード（node）機能を有してもよい。また、ノード機能を代替する端末が分散台帳ネットワーク４、ファイル登録者端末１、ファイル保有者端末２、および利用者端末３のそれぞれの間に設けられてもよい。
　ノード機能は、ネットワークのトランザクションの検証処理、承認処理、ならびに台帳情報（ブロック情報およびステートデータベース（state database）など）の更新および保持を行なう機能である。
　ファイル保有者端末２または利用者端末３は、DAG（Directed acyclic graph：有向非巡回グラフ）形式のファイルから通常形式のファイルへの変換機能を有する。ファイル登録者端末１とファイル保有者端末２は、同一端末であってもよい。
　なお、ファイル登録者端末１、ファイル保有者端末２、および利用者端末３以外にも、ノード機能を代替する端末が分散台帳ネットワーク４に存在してもよい。この端末は、別ノードと称される。図１および図２に示された例では、分散台帳ネットワーク４を維持する別ノード５が存在してもよい。
　ファイル登録者端末１、ファイル保有者端末２、および利用者端末３は、ノード機能を代替する別ノード５が存在する場合は、ノード機能を含まなくともよい。なお、本実施形態では、ファイル登録者端末１、ファイル保有者端末２、および利用者端末３もノード機能を実行する場合について説明する。
　図３は、ファイル登録者端末の機能構成の一例を示すブロック図である。
　図３に示されるように、ファイル登録者端末１は、ファイル利用部１１、アクセス機能部１２、ノード機能部１３、および通信部１４を有する。　
　ファイル利用部１１は、ファイル管理ＤＢ（データベース）１１ａを有し、アクセス機能部１２は、鍵管理ＤＢ１２ａを有し、ノード機能部１３は、ネットワーク（ＮＷ）維持・識別用情報ＤＢ１３ａを有する。本実施形態での各種データベースはストレージとも称される。
　ファイル利用部１１は、ファイルの管理、例えば生成、更新、または利用を行ない、管理されるデータをファイル管理ＤＢ１１ａに格納する。また、ファイル利用部１１は、ファイルの管理に必要な鍵の管理も行なう。
　アクセス機能部１２は、ネットワークへのトランザクション発行、および他端末とのファイル送受信を行なう。また、アクセス機能部１２は、アクセスにおいて用いられる鍵の情報を鍵管理ＤＢ１２ａに格納する。
　ノード機能部１３は、上記のノード機能を実行し、処理における、ネットワーク維持および識別用の情報をネットワーク（ＮＷ）維持・識別用情報ＤＢ１３ａに格納する。　
　通信部１４は、外部との通信を担う。
　図４は、ファイル保有者端末の機能構成の一例を示すブロック図である。
　図４に示されるように、ファイル保有者端末２は、ファイル利用部２１、アクセス機能部２２、ノード機能部２３、および通信部２４を有する。　
　ファイル利用部２１は、ファイル管理ＤＢ２１ａを有し、アクセス機能部２２は、鍵管理ＤＢ２２ａを有し、ノード機能部２３は、ネットワーク（ＮＷ）維持・識別用情報ＤＢ２３ａを有する。
　ファイル利用部２１は、上記のファイル利用部１１と同様の処理を行ない、管理されるデータをファイル管理ＤＢ２１ａに格納する。　
　アクセス機能部２２は、上記のアクセス機能部１２と同様の処理を行ない、アクセスにおいて用いられる鍵の情報を鍵管理ＤＢ２２ａに格納する。　
　ノード機能部２３は、上記のノード機能を実行し、上記のネットワーク維持および識別用の情報をネットワーク（ＮＷ）維持・識別用情報ＤＢ２３ａに格納する。　
　通信部２４は、外部との通信を担う。
　図５は、利用者端末の機能構成の一例を示すブロック図である。　
　図５に示されるように、利用者端末３は、ファイル利用部３１、アクセス機能部３２、ノード機能部３３、および通信部３４を有する。　
　ファイル利用部３１は、ファイル管理ＤＢ３１ａを有し、アクセス機能部３２は、鍵管理ＤＢ３２ａを有し、ノード機能部３３は、ネットワーク（ＮＷ）維持・識別用情報ＤＢ３３ａを有する。
　ファイル利用部３１は、上記のファイル利用部１１と同様の処理を行ない、管理されるデータをファイル管理ＤＢ３１ａに格納する。　
　アクセス機能部３２は、上記のアクセス機能部１２と同様の処理を行ない、アクセスにおいて用いられる鍵の情報を鍵管理ＤＢ３２ａに格納する。　
　ノード機能部３３は、上記のノード機能を実行し、上記のネットワーク維持および識別用の情報をネットワーク（ＮＷ）維持・識別用情報ＤＢ３３ａに格納する。　
　通信部３４は、外部との通信を担う。
　図６および図７は、本発明の一実施形態で用いられる分散台帳で管理される情報およびファイルで管理される情報の一例を示す図である。　
　図６に示された例では、分散台帳では、トークン（token）CAおよびトークンCA´が管理され、それぞれのトークンにおいてファイル識別子であるファイルハッシュFAが管理される。　
　本実施形態では、各ファイルのヘッダ（header）にトークンCAへのアクセス情報が埋め込まれる。　
　本実施形態では、ファイルのID（ハッシュから作られる識別子）がトークンに記録されることで、正しいトークンとファイルとの関係が確認され得る。
　例えば、トークンCAへのアクセス情報が用いられることで、このアクセス情報が埋め込まれたファイルから上記トークンCA内の識別子へのアクセスが可能であり、このトークンCAが正しいトークンであることが確認され得る。一方で、トークンCAへのアクセス情報が埋め込まれたファイルからは、上記トークンCA´内の識別子へのアクセスは行なえない。このことから、このトークンCA´は正しいトークンでないことが確認され得る。
　また、トークンへのアクセス情報は、上記のようにファイルのヘッダに埋め込まれる例に限らず、例えば、当該ファイルにフォルダ（folder）構成が生成され、このフォルダ構成にトークンへのアクセス情報が組み込まれた上で、例えばtar方式またはzip方式などによりアーカイブ（archive）または圧縮処理を行なうことで、トークンへのアクセス情報が含まれるファイルが生成されてもよい。
　また、図７に示された例では、分散台帳では、トークンCAおよびトークンCA´が管理され、それぞれのトークンにおいて、チャンク識別子であるチャンクハッシュFCA_1、チャンクハッシュFCA_2、およびチャンクハッシュFCA_3を含む複数のチャンクハッシュが管理される。
　図７に示された例では、各チャンクにトークンCAへのアクセス情報が埋め込まれ、このようにアクセス情報が埋め込み済みのチャンクでDAG形式のファイルが形成される。　
　本実施形態では、チャンクのID（ハッシュから作られる識別子）がトークンに記録されることで、トークンとチャンクとの正しい関係が確認され得る。
　ファイルがDAG化されるストレージは、例えばＩＰＦＳ（InterPlanetary File System）である。IPFSの例では、各IPFSオブジェクトのData項目内の先頭に、アクセス情報がファイル本体のチャンク情報とは区別されて格納される。
　＜ファイルの登録：通常ストレージ＞
　次に、本実施形態に係る管理システムでの、通常ストレージへのファイルの登録処理について説明する。この登録処理は、処理対象のファイルに係る識別子が分散台帳ネットワーク上のトークンに登録される処理である。本実施形態では、各端末で用いられるストレージは、通常のストレージと、ファイルがDAG化されるストレージとに区分される。通常のストレージは、ファイルがDAG化されないストレージである。
　図８は、通常ストレージに対するファイルの登録処理の一例を説明するシーケンスを示す図である。　
　（１）　ファイル登録者端末１のファイル利用部１１は、ファイル管理ＤＢ１１ａに記憶される、処理対象であるファイルに係るトークンである、分散台帳へのToken生成をアクセス機能部１２に指示する（Ｓ１１）。この指示を受けて、ファイル登録者端末１のアクセス機能部１２は、分散台帳へのToken生成処理を行なう（Ｓ１２）。
　具体的には、アクセス機能部１２は、分散台帳へのTokenを、ファイル識別子を含めずに生成するためのトランザクションを作成して、通信部１４を介して分散台帳ネットワーク４にブロードキャスト（broadcast）する（Ｓ１２－１）。アクセス機能部１２は、トランザクション結果の通知依頼をノード機能部１３に送る（Ｓ１２－２）。
　次に、ノード機能部１３からの要求により、分散台帳ネットワーク４において、コンセサンスアルゴリズム（consensus algorithm）により、トランザクションが検証される。このトランザクションが所定の要件を満たしていれば、このトランザクションが承認（confirm）される（Ｓ１２－３）。
　ノード機能部１３は、トランザクションの結果を分散台帳ネットワーク４から通信部１４を介して受信すると、この結果をアクセス機能部１２に返却する（Ｓ１２－４）。この結果を受けて、アクセス機能部１２は、処理対象のファイルに対する「Tokenへのアクセス情報」を作成する（Ｓ１２－５）。これによりＳ１２の処理がなされる。　
　アクセス機能部１２は、この作成された「Tokenへのアクセス情報」をファイル利用部１１に返却する（Ｓ１３）。
　（２）　ファイル利用部１１は、ファイル管理ＤＢ１１ａに記憶される、処理対象のファイルのヘッダ（ファイルヘッダと称されることもある）に、Ｓ１３で返却された「Tokenへのアクセス情報」を記録する。ここでは複数の「Tokenへのアクセス情報」がファイルヘッダに記録されてもよい。
　（３）　ファイル利用部１１は、Tokenへのアクセス情報がファイルヘッダに記録されたファイルのファイル識別子（例えばハッシュ）を生成する（Ｓ１４）。このＳ１４では、ファイル保有者端末２にファイルが送信され、ファイル取得にも用いられる識別子がファイル保有者端末２により生成されてもよい。
　また、これらの（２）および（３）では、ファイル利用部１１は、Ｓ１３で返却された「Tokenへのアクセス情報」を処理対象のファイルとは別のアクセス情報ファイルに記録し、そして、ファイル管理ＤＢ１１ａに記憶される、処理対象のファイルとアクセス情報ファイルとを同じフォルダに格納し、このフォルダをアーカイブまたは圧縮することでファイルを作成し、当該ファイルのファイル識別子を生成してもよい。
　（４）　ファイル利用部１１は、Tokenの更新、ここではTokenへのファイル識別子の登録指示をアクセス機能部１２に送る（Ｓ１５）。この指示を受けて、アクセス機能部１２は、分散台帳で管理される、上記「Tokenへのアクセス情報」に係るTokenへのファイル識別子登録処理を行なう（Ｓ１６）。
　具体的には、アクセス機能部１２は、分散台帳ネットワーク４で管理されるTokenにファイル識別子を登録するためのトランザクションを作成して通信部１４を介して分散台帳ネットワーク４にブロードキャストする（Ｓ１６－１）。アクセス機能部１２は、トランザクション結果の通知依頼をノード機能部１３に送る（Ｓ１６－２）。
　次に、ノード機能部１３からの要求により、分散台帳ネットワーク４において、コンセサンスアルゴリズムにより、トランザクションが検証される。このトランザクションが所定の要件を満たしていれば、このトランザクションが承認される（Ｓ１６－３）。
　ノード機能部１３は、トランザクションの結果を分散台帳ネットワーク４から通信部１４を介して受信すると、この結果をアクセス機能部１２に返却する（Ｓ１６－４）。これにより、Ｓ１６による、Tokenへのファイル識別子の記録がなされる。　
　この結果を受けて、アクセス機能部１２は、Tokenの更新完了通知をファイル利用部１１に通知する（Ｓ１７）。
　＜ファイル（チャンク）の登録：ファイルがDAG化されるストレージ（IPFS等）＞
　次に、本実施形態に係る管理システムでの、ファイルがDAG化されるストレージへのファイルの登録処理について説明する。図９は、ファイルがDAG化されるストレージに対するファイルの登録処理の一例を説明するシーケンスを示す図である。　
　（１）　まず、通常ストレージに対するファイルの登録処理と同様に、Ｓ１１で説明したように、分散台帳へのToken生成がアクセス機能部１２に指示される。次に、Ｓ１２で説明したように、分散台帳へのToken生成処理が行なわれる。　
　次に、Ｓ１３で説明したように、作成された「Tokenへのアクセス情報」がファイル利用部１１に返却される。
　（２）　ファイル利用部１１は、処理対象のファイルのヘッダに「Tokenへのアクセス情報」を記録する（Ｓ１１１）。ここでは、複数の「Tokenへのアクセス情報」が記録されてもよい。　
　（３）　ファイル利用部１１は、ファイルのヘッダを取り除き、残りの部分を仮チャンクに分割する（Ｓ１１２）。　
　（４）　ファイル利用部１１は、ファイルのヘッダを各仮チャンクに追加することで、仮チャンクをアップデート（update）する（Ｓ１１３）。
　また、これらの（２）、（３）、および（４）は、以下の（２ａ）、（３ａ）、および（４ａ）に置き換えられてもよい。　
　（２ａ）　ファイル利用部１１は、Ｓ１３で返却された「Tokenへのアクセス情報」をアクセス情報ファイルに記録し、そして、ファイル管理ＤＢ１１ａに記憶される、処理対象のファイルとアクセス情報ファイルとを同じフォルダに格納し、このフォルダをアーカイブまたは圧縮することでファイルを作成する。
　（３ａ）　ファイル利用部１１は、上記アーカイブまたは圧縮されたファイルを元のフォルダに復元し、このフォルダに格納されるアクセス情報ファイルを取り除き、残りの部分を仮チャンクに分割する。　
　（４ａ）　ファイル利用部１１は、上記フォルダに格納されるアクセス情報ファイルに記録された、Tokenへのアクセス情報を各仮チャンクに追加することで、仮チャンクをアップデートする（Ｓ１１３）。　
　（５）　（４）または（４ａ）の後、ファイル利用部１１は、仮チャンクをもとに、DAG化されたファイルを作成し、このDAG化されたファイルを形成する各チャンクの識別子を生成する（Ｓ１１４）。　
　上記（２）～（５）では、ファイル利用部１１は、Ｓ１３で返却された「Tokenへのアクセス情報」をアクセス情報ファイルに記録し、各仮チャンクの各々について、当該仮チャンクと上記アクセス情報ファイルとを同じフォルダに格納し、このフォルダがアーカイブまたは圧縮されたファイルを生成し、このファイルをもとに、DAG化されたファイルを作成し、このDAG化されたファイルを形成する各チャンクの識別子を生成してもよい。
　（６）　ファイル利用部１１は、Tokenの更新、ここではTokenへのチャンク識別子の登録指示をアクセス機能部１２に送る（Ｓ１１５）。この指示を受けて、アクセス機能部１２は、分散台帳で管理される、上記「Tokenへのアクセス情報」に係るTokenへのチャンク識別子登録処理を行なう（Ｓ１１６）。
　具体的には、アクセス機能部１２は、分散台帳ネットワーク４で管理されるTokenにチャンク識別子を登録するためのトランザクションを作成して通信部１４を介して分散台帳ネットワーク４にブロードキャストする（Ｓ１１６－１）。アクセス機能部１２は、トランザクション結果の通知依頼をノード機能部１３に送る（Ｓ１１６－２）。
　次に、ノード機能部１３からの要求により、分散台帳ネットワーク４において、コンセサンスアルゴリズムにより、トランザクションが検証される。このトランザクションが所定の要件を満たしていれば、このトランザクションが承認される（Ｓ１１６－３）。
　ノード機能部１３は、トランザクションの結果を分散台帳ネットワーク４から通信部１４を介して受信すると、この結果をアクセス機能部１２に返却する（Ｓ１１６－４）。これにより、Ｓ１１６による、Tokenへのチャンク識別子の記録がなされる。　
　この結果を受けて、アクセス機能部１２は、Tokenの更新完了通知をファイル利用部１１に通知する（Ｓ１１７）。
　通常は、ヘッダも含めたファイル全体がチャンクに分割されるため、ヘッダ情報を含まないチャンクが生成される。　
　一方で、本実施形態では、上記のように、ファイルがDAG化されたファイルに変換される際のチャンクへの分割において、少なくともTokenへのアクセス情報を含むヘッダが各チャンクに追加される。
　＜ファイルの紐付け検証：通常ストレージ＞
　次に、本実施形態に係る管理システムでの、通常ストレージに対するファイルの紐付け検証処理について説明する。この紐付け検証処理は、更新されたファイルに係る識別子と、当該ファイルの更新前に作成されて分散台帳ネットワークで管理される、更新前のファイルに係る識別子とが一致するか否かが確認されることにより、分散台帳ネットワーク４で管理されるトークンと、ファイル保有者端末２で管理される、トークンへのアクセス情報を有するファイルとの紐付けが検証される処理である。図１０は、通常ストレージに対するファイルの紐付け検証処理の一例を説明するシーケンスを示す図である。
　（１）　ファイル保有者端末２のファイル利用部２１は、処理対象である、更新されたファイルのファイルヘッダに記載された「Tokenへのアクセス情報」を取得し（Ｓ４１）、このアクセス情報を用いて、分散台帳ネットワーク４で管理されるトークン中の制御情報におけるファイル識別子の取得をアクセス機能部２２に指示する（Ｓ４２）。
　上記処理対象であるファイルが、上記アクセス情報ファイルとともにアーカイブまたは圧縮されてなるファイルである場合は、上記Ｓ４１およびＳ４２において、ファイル利用部２１は、上記アーカイブまたは圧縮されたファイルを元のフォルダに復元し、このフォルダに格納されるアクセス情報ファイルを取得し、このアクセス情報ファイルに記録された「Tokenへのアクセス情報」を用いて、分散台帳ネットワーク４で管理されるトークン中の制御情報におけるファイル識別子の取得をアクセス機能部２２に指示する。
　上記指示を受けて、アクセス機能部２２は、トークンからの制御情報の取得をノード機能部２３に指示する（Ｓ４３）。　
　この指示を受けて、ノード機能部２３は、通信部２４を介して分散台帳ネットワーク４にアクセスすることで、分散台帳で管理される、上記「Tokenへのアクセス情報」に係るトークンから制御情報を取得して、当該制御情報からファイル識別子を取得し、このファイル識別子をアクセス機能部２２に返却する（Ｓ４４）。アクセス機能部２２は、このファイル識別子をファイル利用部２１に返却する（Ｓ４５）。
　（２）　処理対象である、更新されたファイルのファイル識別子は、ファイル管理ＤＢ２１ａに記憶されて管理される。ファイル利用部２１は、処理対象である、更新されたファイルのファイル識別子をファイル管理ＤＢ２１ａから取得し、このファイル識別子と、Ｓ４５で返却されたファイル識別子とを比較し、これらが一致することを確認（検証）する（Ｓ４６）。
　上記処理対象のファイルが、上記アーカイブまたは圧縮されてなるファイルである場合は、上記Ｓ４６において、ファイル利用部２１は、処理対象のファイルを元のフォルダに復元した上で、このフォルダに格納される、処理対象である、更新されたファイルのファイル識別子をファイル管理ＤＢ２１ａから取得し、このファイル識別子と、Ｓ４５で返却されたファイル識別子とを比較し、これらが一致することを確認（検証）する。
　処理対象のファイルに、複数の「Tokenへのアクセス情報」が保持される場合、処理対象のファイルの識別子と、これら複数のTokenにおけるファイル識別子との紐付けが検証される。
　＜ファイル（チャンク）の紐付け検証：ファイルがDAG化されるストレージ＞
　次に、本実施形態に係る管理システムでの、ファイルがDAG化されるストレージに対するファイルの紐付け検証処理について説明する。図１１は、ファイルがDAG化されるストレージに対するファイルの紐付け検証処理の一例を説明するシーケンスを示す図である。
　（１）　ファイル保有者端末２のファイル利用部２１は、処理対象であるファイルのチャンクに記載された「Tokenへのアクセス情報」を取得し（Ｓ１４１）、このアクセス情報を用いて制御情報の取得をアクセス機能部２２に指示する（Ｓ１４２）。この指示を受けて、アクセス機能部２２は、トークンからの制御情報の取得をノード機能部２３に指示する（Ｓ１４３）。
　上記処理対象であるファイルのチャンクが、上記アクセス情報ファイルとともにアーカイブまたは圧縮されてなるファイルのチャンクである場合は、上記Ｓ１４１およびＳ１４２において、ファイル利用部２１は、上記アーカイブまたは圧縮されたファイルを元のフォルダに復元し、このフォルダに格納されるアクセス情報ファイルを取得し、このアクセス情報ファイルに記録された「Tokenへのアクセス情報」を用いて、分散台帳ネットワーク４で管理されるトークン中の制御情報におけるファイル識別子の取得をアクセス機能部２２に指示する。
　この指示を受けて、ノード機能部２３は、通信部２４を介して分散台帳ネットワーク４にアクセスすることで、分散台帳で管理される、上記「Tokenへのアクセス情報」に係るトークンから制御情報を取得して、当該制御情報からチャンクの識別子を取得し、このチャンクの識別子をアクセス機能部２２に返却する（Ｓ１４４）。アクセス機能部２２は、このチャンクの識別子をファイル利用部２１に返却する（Ｓ１４５）。
　（２）　処理対象である、更新されたファイルのチャンクのチャンク識別子は、ファイル管理ＤＢ２１ａに記憶されて管理される。ファイル利用部２１は、処理対象である、更新されたファイルのチャンクのチャンク識別子をファイル管理ＤＢ２１ａから取得し、このチャンク識別子と、Ｓ１４５で返却された、制御情報に記載された、チャンクの識別子とを比較し、これらが一致することを確認（検証）する（Ｓ１４６）。
　上記処理対象のファイルのチャンクが、上記アーカイブまたは圧縮されてなるファイルのチャンクである場合は、上記Ｓ１４６において、ファイル利用部２１は、処理対象のファイルを元のフォルダに復元した上で、処理対象である、このフォルダに格納される、更新されたファイルのチャンクを特定し、このチャンクのチャンク識別子をファイル管理ＤＢ２１ａから取得し、このチャンク識別子と、Ｓ１４５で返却されたチャンク識別子とを比較し、これらが一致することを確認（検証）する。
　処理対象のファイルのチャンクに、複数の「Tokenへのアクセス情報」が保持される場合、処理対象のファイルのチャンクの識別子と、これら複数のTokenにおけるチャンクの識別子との紐付けが検証される。
　本実施形態では、リクエスト対象のデータの状態が通常のファイルの状態でもDAG化されたファイルの状態でも、ファイルヘッダまたは各チャンクにTokenへのアクセス情報が含まれるため、ファイルまたはチャンク毎にTokenがバラバラでも、ファイルまたはチャンクの正当性の検証が可能である。
　＜ファイルの送信前検証：通常ストレージ＞
　次に、本実施形態に係る管理システムでの、通常ストレージに対するファイルの送信前検証処理について説明する。　
　送信前検証処理とは、ファイル保有者端末２のストレージで保有されるファイルまたはチャンクの取得が利用者端末３からリクエストされた場合に、このリクエストに応じて利用者端末３に該当のファイルなどの送信の可否が検証される処理である。
　この送信前検証処理が実行されるために、分散台帳ネットワーク４上で管理されるトークンには、ファイル保有者端末２で保有されるファイルなどの識別子とともに、このファイルなどの取得が許可された利用者の識別子である利用者識別子が管理される。
　図１２は、通常ストレージに対するファイルの紐付け検証処理の一例を説明するシーケンスを示す図である。　
　（１）　まず、利用者端末３のアクセス機能部３２は、利用者による操作に従って、ファイル保有者端末２へのファイル取得のリクエストを通信部３４を介してファイル保有者端末２に送信する。このリクエストには、少なくとも、リクエスト対象のファイルのファイル識別子、および利用者端末３のユーザに付与された利用者識別子を含む。ファイル保有者端末２のファイル利用部２１は、利用者からファイル取得のリクエストを通信部２４を介して受信する（Ｓ５１）。
　（２）　ファイル保有者端末２のファイル利用部２１は、ファイル管理ＤＢ２１ａに記憶されるファイルから、Ｓ５１で受信したリクエストで取得が指定されたファイルを特定し、このファイルのファイルヘッダに記載された「Tokenへのアクセス情報」を取得し（Ｓ５２）、このアクセス情報を用いて利用者識別子の取得をアクセス機能部２２に指示する（Ｓ５３）。この指示を受けて、アクセス機能部２２は、トークンからの制御情報の取得をノード機能部２３に指示する（Ｓ５４）。
　上記処理対象のファイルが、上記アクセス情報ファイルとともにアーカイブまたは圧縮されてなるファイルである場合は、上記Ｓ５２およびＳ５３において、ファイル利用部２１は、ファイル管理ＤＢ２１ａに記憶される、上記アーカイブまたは圧縮されたファイルを元のフォルダに復元し、このフォルダに格納されるアクセス情報ファイルを取得し、このアクセス情報ファイルに記録された、「Tokenへのアクセス情報」を用いて、利用者識別子の取得をアクセス機能部２２に指示する。
　この指示を受けて、ノード機能部２３は、分散台帳ネットワーク４で管理されるトークンから制御情報を取得して、当該制御情報から利用者識別子を取得し、この利用者識別子をアクセス機能部２２に返却する（Ｓ５５）。アクセス機能部２２は、この利用者識別子をファイル利用部２１に返却する（Ｓ５６）。ここで、アクセス情報に複数のTokenの記載があれば、複数のTokenの制御情報が取得される。
　（３）　ファイル利用部２１は、Ｓ５６で返却された利用者識別子と、利用者端末３からのリクエストに含まれる利用者識別子とを比較しこれらの識別子が一致する、つまり、リクエストに含まれる利用者識別子が上記保有されるファイルの取得が許可された利用者からのリクエストであることを確認（検証）する（Ｓ５７）。
　上記一致する場合は、ファイル利用部２１は、リクエストで指定されたファイルを通信部２４を介して利用者端末３へ送信する。利用者端末３のアクセス機能部３２は、この送信されたファイルを通信部３４を介して取得する（Ｓ５８）。
　＜ファイル（チャンク）の送信前検証：ファイルがDAG化されるストレージ＞
　次に、本実施形態に係る管理システムでの、ファイルがDAG化されるストレージに対するファイルの送信前検証処理について説明する。図１２は、ファイルがDAG化されるストレージに対するファイルの送信前検証処理の一例を説明するシーケンスを示す図である。
　（１）　まず、利用者端末３のアクセス機能部３２は、利用者による操作に従って、ファイル保有者端末２へのチャンク取得のリクエストを通信部３４を介してファイル保有者端末２に送信する。このリクエストには、少なくとも、リクエスト対象のファイルのチャンクのチャンク識別子、および利用者端末３のユーザに付与された利用者識別子が含まれる。ファイル保有者端末２のファイル利用部２１は、利用者からチャンク取得のリクエストを通信部２４を介して受信する（Ｓ１５１）。
　（２）　ファイル利用部２１は、ファイル管理ＤＢ２１ａに記憶されるファイルのチャンクから、Ｓ５１で受信したリクエストで取得が指定されたチャンクを特定し、このチャンクに記載された「Tokenへのアクセス情報」を取得し（Ｓ１５２）、このアクセス情報を用いて利用者識別子の取得をアクセス機能部２２に指示する（Ｓ１５３）。この指示を受けて、アクセス機能部２２は、トークンからの制御情報の取得をノード機能部２３に指示する（Ｓ１５４）。
　上記処理対象のファイルのチャンクが、上記アクセス情報ファイルとともにアーカイブまたは圧縮されてなるファイルのチャンクである場合は、上記Ｓ１５２およびＳ５３において、ファイル利用部２１は、ファイル管理ＤＢ２１ａに記憶される、上記アーカイブまたは圧縮されたファイルを元のフォルダに復元した上で、このフォルダに格納されるチャンクから、Ｓ１５１で受信したリクエストで取得が指定されたチャンクを特定し、このチャンクとともにフォルダに格納されるアクセス情報ファイルに記録された「Tokenへのアクセス情報」を取得し、このアクセス情報を用いて利用者識別子の取得をアクセス機能部２２に指示する。
　この指示を受けて、ノード機能部２３は、分散台帳ネットワーク４で管理されるトークンから制御情報を取得して、当該制御情報から利用者識別子を取得し、この利用者識別子をアクセス機能部２２に返却する（Ｓ１５５）。アクセス機能部２２は、この利用者識別子をファイル利用部２１に返却する（Ｓ１５６）。ここで、アクセス情報に複数のTokenの記載があれば、複数のTokenの制御情報が取得される。
　（３）　ファイル利用部２１は、Ｓ５６で返却された利用者識別子と、利用者端末３からのリクエストに含まれる利用者識別子とを比較し、これらの識別子が一致する、つまり、リクエストに含まれる利用者識別子が上記保有されるファイルの取得が許可された利用者からのリクエストであることを確認（検証）する（Ｓ１５７）。
　上記一致する場合は、ファイル利用部２１は、リクエストで指定されたチャンクを通信部２４を介して利用者端末３へ送信する。利用者端末３のアクセス機能部３２は、この送信されたチャンクを通信部３４を介して取得する（Ｓ１５８）。
　図１２および図１３に示されるように、本実施形態では、リクエスト対象のデータの状態が通常のファイルの状態でもDAG化されたファイルの状態でも、ファイルヘッダまたは各チャンクにTokenへのアクセス情報が含まれるため、ファイルまたはチャンク毎にTokenがバラバラでも、ファイルまたはチャンクの共有制御が可能である。
　＜DAG化されたファイルから通常のファイルへの変換処理＞
　ファイルがDAG化されるストレージから通常のファイルが取得される場合、DAG形式のファイルから通常のファイルへの変換が以下の処理によりなされる。この変換は、利用者端末３での利用前、またはファイル保有者端末２から利用者端末３への送信前になされる。
　（１）　DAGを形成する全てのチャンクが取得される。　
　（２）　チャンクからファイル本体の断片とファイルヘッダとが取得される。　
　（３）　全てのチャンクから取得された全てのファイルヘッダが同じであることが確認される。
　上記処理対象のファイルが、上記アクセス情報ファイルを含んでアーカイブまたは圧縮されてなるファイルである場合は、これら（２）および（３）では、チャンクからファイル本体の断片とファイル内のアクセス情報ファイルとが取得され、全てのチャンクから取得された全てのアクセス情報ファイルが同じであることが確認されてもよい。
　（４）　ファイル本体の断片が繋ぎ合わせられ、ファイルヘッダが付与される。　
　（５）　また、必要に応じて、上記の＜ファイルの紐付け検証：通常ストレージ＞の処理が実行される。
　上記のように、本発明の一実施形態に係る管理システムでは、処理対象のファイルに分散台帳上のトークンへのアクセス情報を含め、ファイルの識別子をトークンに含める構成としたので、分散台帳で管理される情報をファイルから参照することができる。
　図１４は、本発明の一実施形態に係るファイル登録者端末のハードウエア構成の一例を示すブロック図である。同図に示された例では、ファイル登録者端末１は、例えばサーバコンピュータ（server computer）またはパーソナルコンピュータ（personal computer）により構成され、ＣＰＵ（Central Processing Unit）等のハードウエアプロセッサ（hardware processor）１１１を有する。そして、このハードウエアプロセッサ１１１に対し、プログラムメモリ（program memory）１１１Ｂ、データメモリ（data memory）１１２、入出力インタフェース（interface）１１３及び通信インタフェース１１４が、バス（bus）１２０を介して接続される。ファイル保有者端末２、および利用者端末３についても同様である。
　通信インタフェース１１４は、例えば１つ以上の無線の通信インタフェースユニット（interface unit）を含んでおり、通信ネットワークＮＷとの間で情報の送受信を可能にする。無線インタフェースとしては、例えば無線ＬＡＮ（Local Area Network）などの小電力無線データ通信規格が採用されたインタフェースが使用され得る。
　入出力インタフェース１１３には、ファイル登録者端末１に付設される、オペレータ（operator）用の入力デバイス（device）１３０及び出力デバイス１４０が接続される。入出力インタフェース１１３は、キーボード（keyboard）、タッチパネル（touch panel）、タッチパッド（touchpad）、マウス（mouse）等の入力デバイス１３０を通じてオペレータにより入力された操作データを取り込むと共に、出力データを液晶または有機ＥＬ（organic electro-luminescence）等が用いられた表示デバイスを含む出力デバイス１４０へ出力して表示させる処理を行う。なお、入力デバイス１３０及び出力デバイス１４０には、ファイル登録者端末１に内蔵されたデバイスが使用されても良く、また、通信ネットワークＮＷを介してファイル登録者端末１と通信可能な他の情報端末の入力デバイス及び出力デバイスが使用されても良い。
　プログラムメモリ１１１Ｂは、非一時的な有形の記憶媒体として、例えば、ＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）等の随時書込み及び読出しが可能な不揮発性メモリと、ＲＯＭ（Read Only Memory）等の不揮発性メモリ（non-volatile memory）とが組み合わせて使用されたもので、一実施形態に係る各種制御処理を実行するために必要なプログラムが格納されている。
　データメモリ１１２は、有形の記憶媒体として、例えば、上記の不揮発性メモリと、ＲＡＭ（Random Access Memory）等の揮発性メモリ（volatile memory）とが組み合わせて使用されたもので、各種処理が行なわれる過程で取得及び作成された各種データが記憶されるために用いられる。
　本発明の一実施形態に係るファイル登録者端末１は、ソフトウエア（software）による処理機能部として、図３に示されるファイル利用部１１、アクセス機能部１２、ノード機能部１３、および通信部１４を有するデータ処理装置として構成され得る。
　また、図３に示された各種データベースは、図１２に示されたデータメモリ１１２を用いて構成され得る。ただし、上記の各種データベースはファイル登録者端末１内に必須の構成ではなく、例えば、ＵＳＢ（Universal Serial Bus）メモリなどの外付け記憶媒体、またはクラウド（cloud）に配置されたデータベースサーバ（database server）等の記憶装置に設けられたものであっても良い。
　上記の図３に示されたファイル利用部１１、アクセス機能部１２、ノード機能部１３および通信部１４の各部における処理機能部は、何れも、プログラムメモリ１１１Ｂに格納されたプログラムを上記ハードウエアプロセッサ１１１により読み出させて実行させることにより実現され得る。なお、これらの処理機能部の一部または全部は、特定用途向け集積回路（ＡＳＩＣ）またはＦＰＧＡ（Field-Programmable Gate Array）などの集積回路を含む、他の多様な形式によって実現されても良い。
　また、各実施形態に記載された手法は、計算機（コンピュータ）に実行させることができるプログラム（ソフトウエア手段）として、例えば磁気ディスク（フロッピー（登録商標）ディスク（Floppy disk）、ハードディスク（hard disk）等）、光ディスク（optical disc）（ＣＤ－ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ（Flash memory）等）等の記録媒体に格納し、また通信媒体により伝送して頒布され得る。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウエア手段（実行プログラムのみならずテーブル（table）、データ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスク、半導体メモリ等の記憶媒体を含むものである。
　なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。更に、上記実施形態には種々の発明が含まれており、開示される複数の構成要件から選択された組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、課題が解決でき、効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
　　１…ファイル登録者端末
　　２…ファイル保有者端末
　　３…利用者端末
　　４…分散台帳ネットワーク
　　１１，２１，３１…ファイル利用部
　　１２，２２，３２…アクセス機能部
　　１３，２３，３３…ノード機能部
　　１４，２４，３４…通信部
　　１００…管理システム

Claims (8)

  1. 　分散台帳ネットワークに接続可能な登録者端末であって、
    　前記分散台帳ネットワークへのトークンの生成に関するトランザクションを生成し、前記トランザクションを前記分散台帳ネットワークに送信することで前記分散台帳ネットワークに前記トークンを生成するトークン生成部と、
    　　処理対象のファイルに前記トークンへのアクセス情報が設定された情報を生成し、前記処理対象のファイルの識別子を生成し、
    　　前記トークンへの前記識別子の登録に関するトランザクションを生成し、このトランザクションを前記分散台帳ネットワークに送信することで前記トークンに前記識別子を登録する登録部と、
    　を備える登録者端末。
  2. 　前記登録部は、
    　　前記処理対象のファイルに前記トークンへのアクセス情報が設定された情報を生成する情報生成部と、
    　　前記処理対象のファイルからファイルヘッダを取り除き、各仮チャンクに分割するファイル分割部と、
    　　前記ファイルヘッダを仮チャンクのそれぞれに追加する追加部と、
    　　各仮チャンクを用いて有向非巡回グラフ化されたファイルを作成し、前記トークンへの、前記作成されたファイルを構成する前記仮チャンクの識別子を作成し、この識別子の登録に関するトランザクションを生成し、このトランザクションを前記分散台帳ネットワークに送信することで前記トークンに前記識別子を登録する識別子登録部と、
    　を含む、
    　請求項１に記載の登録者端末。
  3. 　処理対象のファイルの識別子を含むトークンが保持される分散台帳ネットワークに接続可能なファイル保有者端末であって、
    　前記処理対象のファイルには、前記トークンへのアクセス情報が記載され、
    　前記処理対象のファイルに記載された、前記トークンへのアクセス情報を用いて、前記トークンからファイル識別子を取得する取得部と、
    　前記処理対象のファイルのファイル識別子と、前記取得部により取得されたファイル識別子とが一致することを判定する判定部と、
    　を備える保有者端末。
  4. 　前記取得部は、
    　　前記処理対象のファイルのチャンクに記載された、前記トークンへのアクセス情報を用いて、前記トークンから前記識別子を取得し、
    　前記判定部は、
    　　前記処理対象のファイルのチャンクの識別子と、前記取得部により取得された識別子とが一致することを判定する、
    　請求項３に記載の保有者端末。
  5. 　記憶装置に記憶されるファイルの正当な利用者の識別子である利用者識別子を含むトークンが保持される分散台帳ネットワークに接続可能であるファイル保有者端末であって、
    　前記記憶装置に記憶されるファイルには、前記トークンへのアクセス情報が記載され、
    　前記記憶装置に記憶されるファイルの取得に関するリクエストであって、リクエスト元の利用者の識別子を含むリクエストに応じて、前記記憶装置に記憶されるファイルに記載される前記トークンへのアクセス情報を用いて、前記トークンから前記利用者識別子を取得する取得部と、
    　前記リクエストに含まれる識別子と前記取得部により取得された利用者識別子とが一致する場合に、前記記憶装置に記憶されるファイルを前記リクエスト元に送信する送信部と、
    　を備えるファイル保有者端末。
  6. 　前記記憶装置に記憶されるファイルのチャンクの正当な利用者の識別子である利用者識別子を含むトークンが保持される分散台帳ネットワークに接続可能であり、
    　前記記憶装置に記憶されるチャンクには、前記トークンへのアクセス情報が記載され、
    　前記取得部は、
    　　前記記憶装置に記憶されるチャンクの取得に関するリクエストであって、リクエスト元の利用者の識別子を含むリクエストに応じて、前記記憶装置に記憶されるチャンクに記載される前記トークンへのアクセス情報を用いて、前記トークンから前記利用者識別子を取得し、
    　前記送信部は、
    　　前記リクエストに含まれる識別子と前記取得部により取得された利用者識別子とが一致する場合に、前記記憶装置に記憶されるチャンクを前記リクエスト元に送信する、
    　請求項５に記載の保有者端末。
  7. 　分散台帳ネットワークに接続可能な登録者端末により行なわれる方法であって、
    　前記分散台帳ネットワークへのトークンの生成に関するトランザクションを生成し、前記トランザクションを前記分散台帳ネットワークに送信することで前記分散台帳ネットワークに前記トークンを生成することと、
    　処理対象のファイルに前記トークンへのアクセス情報が設定された情報を生成し、前記処理対象のファイルの識別子を生成し、前記トークンへの前記識別子の登録に関するトランザクションを生成し、このトランザクションを前記分散台帳ネットワークに送信することで前記トークンに前記識別子を登録することと、
    　を備える登録方法。
  8. 　請求項１もしくは２に記載の登録者端末の前記各部、または請求項３乃至６のいずれか１項に記載に保有者端末の前記各部としてプロセッサを機能させるプログラム。
PCT/JP2020/038779 2020-10-14 2020-10-14 登録者端末、保有者端末、方法およびプログラム WO2022079831A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2020/038779 WO2022079831A1 (ja) 2020-10-14 2020-10-14 登録者端末、保有者端末、方法およびプログラム
JP2022556752A JP7452690B2 (ja) 2020-10-14 2020-10-14 登録者端末、保有者端末、方法およびプログラム
US18/031,520 US20230412385A1 (en) 2020-10-14 2020-10-14 Registration terminal, holder terminal, method, and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/038779 WO2022079831A1 (ja) 2020-10-14 2020-10-14 登録者端末、保有者端末、方法およびプログラム

Publications (1)

Publication Number Publication Date
WO2022079831A1 true WO2022079831A1 (ja) 2022-04-21

Family

ID=81208952

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/038779 WO2022079831A1 (ja) 2020-10-14 2020-10-14 登録者端末、保有者端末、方法およびプログラム

Country Status (3)

Country Link
US (1) US20230412385A1 (ja)
JP (1) JP7452690B2 (ja)
WO (1) WO2022079831A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11954094B2 (en) * 2021-08-06 2024-04-09 Salesforce, Inc. Database system public trust ledger architecture

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019004118A1 (ja) * 2017-06-28 2019-01-03 特定非営利活動法人サイバー・キャンパス・コンソーシアムＴｉｅｓ ブロックチェーンにおけるコンテンツコントラクトならびにそれを用いるコンテンツの管理システムおよびコンテンツの提供方法
WO2020080537A1 (ja) * 2018-10-18 2020-04-23 スタートバーン株式会社 取扱管理装置
JP2020144586A (ja) * 2019-03-06 2020-09-10 日本電信電話株式会社 管理者端末、参加者端末、権利者端末、利用者端末、コンテンツ利用システム、管理者プログラム、参加者プログラム、権利者プログラム、利用者プログラムおよびステートデータのデータ構造

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11038672B2 (en) 2018-06-01 2021-06-15 Duality Technologies, Inc. Secure and distributed management of a proxy re-encryption key ledger

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019004118A1 (ja) * 2017-06-28 2019-01-03 特定非営利活動法人サイバー・キャンパス・コンソーシアムＴｉｅｓ ブロックチェーンにおけるコンテンツコントラクトならびにそれを用いるコンテンツの管理システムおよびコンテンツの提供方法
WO2020080537A1 (ja) * 2018-10-18 2020-04-23 スタートバーン株式会社 取扱管理装置
JP2020144586A (ja) * 2019-03-06 2020-09-10 日本電信電話株式会社 管理者端末、参加者端末、権利者端末、利用者端末、コンテンツ利用システム、管理者プログラム、参加者プログラム、権利者プログラム、利用者プログラムおよびステートデータのデータ構造

Also Published As

Publication number Publication date
US20230412385A1 (en) 2023-12-21
JPWO2022079831A1 (ja) 2022-04-21
JP7452690B2 (ja) 2024-03-19

Similar Documents

Publication Publication Date Title
EP3438903B1 (en) Hierarchical network system, and node and program used in same
US20180285839A1 (en) Providing data provenance, permissioning, compliance, and access control for data storage systems using an immutable ledger overlay network
JP2021506004A (ja) 分散型ストレージ方法及び装置、コンピュータ機器及び記憶媒体
US9075958B2 (en) Use of fingerprint with an on-line or networked auction
WO2018154698A1 (ja) ファイルストレージ、オブジェクトストレージ、およびストレージシステム
JP2017207979A (ja) 改ざん検知システム、及び改ざん検知方法
US20190372778A1 (en) Tracking provenance of digital data
CN102576371A (zh) 用于对内容进行可调分发的方法和系统
CN110597885A (zh) 信息处理方法、装置、区块链网络的节点及存储介质
KR102107438B1 (ko) 블록체인을 이용한 전자 문서 관리 장치 및 이의 동작 방법
JP7053031B2 (ja) 情報処理システム、情報処理装置、情報処理方法及び情報処理プログラム
WO2022079831A1 (ja) 登録者端末、保有者端末、方法およびプログラム
US20230232222A1 (en) User terminal, authentication terminal, registration terminal, management system and program
JP2014153583A (ja) 署名文書の管理方法及び署名サーバ
JP6931005B2 (ja) 一貫性を有する散在ストレージ・ネットワークにおけるデータの格納
WO2022079830A1 (ja) 登録者端末、保有者端末、方法およびプログラム
US20210182314A1 (en) Systems and methods for on-chain / off-chain storage using a cryptographic blockchain
EP3357188B1 (en) Code signing service
JP2023078577A (ja) 情報処理システム、情報処理方法、及びプログラム
JP6944317B2 (ja) ファイル転送システムおよびファイル転送方法
US11626986B1 (en) Method and system of rescinding access to blockchain data
US11880824B1 (en) Managing digital blockchains via digital tokens, systems, methods, and apparatus
JP7424490B2 (ja) 登録者端末、検証者端末、管理システムおよびプログラム
WO2022168192A1 (ja) データ移行装置、データ移行方法、及び、データ移行プログラム
US20220103372A1 (en) Communication apparatus and communication method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20957660

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022556752

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 18031520

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20957660

Country of ref document: EP

Kind code of ref document: A1