JP6610814B2 - COMMUNICATION METHOD, DEVICE, AND PROGRAM - Google Patents

Description

  The present invention relates to a communication method, apparatus, and program for communicating files in a distributed file sharing network.

  A distributed file sharing technique for sharing information of an electronic file by peer-to-peer communication between client terminals and IoT (Internet of Things) devices has been proposed. As the format of the electronic file, HTML (Hyper Text Markup Language), PDF (Portable Document Format), or the like is used.

As a specific implementation example of the distributed file sharing technology, an Interplanetary File System (IPFS) is known. IPFS is a distributed WEB technology that extends a distributed file sharing system based on peer-to-peer communication as a WWW (World Wide Web) service, and is a software technology that was announced by Juan Benet in 2015 and has been made open source. IPFS enables file access using an HTTP (Hyper Text Transfer Protocol) communication method in a distributed environment. Furthermore, in IPFS, a unique hash value address is assigned to content instead of an HTTP server address, and address specification is performed in the URL (Uniform Resource Locator) format specifying a hash value as in the following example. .
Content address example: QmRvPJi7GmNAFbJnVeEEhMCGtJsDEaJYVa4a52J9bqn1AN
Address specification method: http: // localhost: 8080 / ipfs / QmRvPJi7GmNAFbJnVeEEhMCGtJsDEaJYVa4a52J9bqn1AN /

  As a result, IPFS enables high-speed content file search and acquisition. IPFS can solve the problems of content distribution by servers deployed in the conventional cloud, etc., waste of network resources and fault tolerance, and it is a serverless content distribution technology that can be perpetuated only by distributed clients. Can provide content.

JP 2011-70557 A JP 2013-105227 A

  However, the conventional distributed file sharing system described above has a problem that there is no authentication mechanism associated with the user regarding file issuance and access, and if only an application is installed, the distributed file sharing network can be accessed.

  Accordingly, an object of one aspect of the present invention is to construct a highly secure file sharing space in a distributed file sharing system.

  An example of the aspect is a communication method executed by a node device included in a distributed file sharing network, wherein information related to an event occurring in a terminal is shared between the node devices included in the distributed file sharing network using a block chain. Then, a file including information on the event is generated, and the generated file is held in any node device included in the distributed file sharing network.

  In a distributed file sharing system, a highly secure file sharing space can be constructed.

It is a figure which shows the example of the use case which this embodiment makes object. It is a figure which shows the structural example which implement | achieves a highly secure information sharing service by a cloud service in distributed file sharing systems, such as IPFS. It is explanatory drawing of the basic concept of this embodiment. It is explanatory drawing of a block chain. It is a figure which shows the structural example of the communication system in this embodiment. It is a sequence diagram which shows the example of a process of file issuance. It is a figure which shows the data format example of the transaction used by the process example of file issuance. It is a figure which shows the data format example of a portal file. It is a sequence diagram which shows the other process example of file issuance. It is a sequence diagram which shows the process example of a file access. It is a figure which shows the data format example of the transaction used by the example of a file access process. It is a figure which shows the hardware structural example of this embodiment. It is a flowchart which shows the example of a process of file issuance. It is a flowchart which shows the other process example of file issuance. It is a flowchart which shows the process example of file access.

  Hereinafter, modes for carrying out the present invention (hereinafter referred to as “the present embodiment”) will be described in detail with reference to the drawings. FIG. 1 is a diagram illustrating an example of a use case targeted by the present embodiment. This embodiment realizes the following services using distributed file sharing technology that shares electronic file information such as HTML, PDF, text, etc. by peer-to-peer communication of a client terminal or IoT device which is one of node devices. To do. For example, as shown in FIG. 1A, information A to E collected from each IoT device is autonomously distributed on a distributed file sharing network 101 formed by each IoT gateway integrated with or separated from each IoT device 103. WEB service and shared. Alternatively, as shown in FIG. 1B, product process information A to E from procurement of raw materials and parts in the supply chain to manufacturing, inventory management, sales, and delivery is formed at the client terminal 104 of the organization involved in distribution. To be shared on the distributed file sharing network 101. Information shared on the distributed file sharing network can be arbitrarily checked 102 from the user's terminal.

  The distributed file sharing network 101 in this embodiment is realized by, for example, the above-described IPFS. However, IPFS has the following problems.

  1. There is no authentication mechanism linked to users regarding file issuance and access, and if you install only an application, you can access the distributed file sharing network.

  2. Although there is a file search function by addressing by hash value and address designation, there is no repository function that centrally manages the relationship between services and addresses, or a function that can manage WEB access, data history (log), and the like.

  3. Anyone or anywhere can register a WEB file, and there is no function that can guarantee the uniqueness of content.

  The above IPFS or the like is a distributed file sharing system developed mainly for sharing files by any IoT gateway or client terminal on the Internet, for example. In order to realize a highly secure information sharing service in which user authentication, file registration and file access trail (log) are managed on such a distributed file sharing system, the following functions are required. . First, a user authentication function relating to file issuance and file access by the user is required. In addition, a function that guarantees the uniqueness of the content that is the file issuer is required. Furthermore, a function for managing file registration and access logs is required. In addition, a function for centrally managing the relationship between the service information provided by the file and the address is required.

  FIG. 2 is a diagram illustrating a configuration example in which a highly secure information sharing service is realized by a cloud service in a distributed file sharing system such as IPFS. In this configuration example, a cloud service is provided via the Internet or the carrier network 203 to the distributed WEB network 201 that is a closed network based on IPFS configured by the client terminal 222 and the IoT gateway 221. This cloud service 202 provides a service having the following functions.

  1. Authentication function: A service that provides access and data history (log) management. For example, a RADIUS (Remote Authentication Dial In User Service) server 201 provides a service that executes network availability (authentication) and usage fact recording (accounting).

  2. Service repository function: A service that manages the relationship between a service and a URL is provided by a portal server 212 such as a WEB portal site.

  3. Content uniqueness guarantee function: A service that guarantees the uniqueness of a corresponding file by issuing a license code and a content ID (identifier) by the server 213 and registering the content in the content file when the content is registered. Is provided.

  4). Log management function: The server 214 provides a service for recording file registration and file access logs.

  However, as shown in FIG. 2, when the above-described functions 1 to 4 are realized by the cloud service 202 for a distributed file sharing system such as IPFS, the following problems occur. The amount of traffic exchanged in the Internet or carrier network 203 connecting the distributed WEB network 201 and the cloud service 202 increases. As a result, there arises a problem that the advantages of the distributed file sharing system such as serverless processing realized by edge nodes such as the client terminal 222 and the IoT gateway 221 and immediate file sharing cannot be enjoyed.

  Therefore, in this embodiment described below, while maintaining a distributed file sharing system, it supports access authentication, guarantee of uniqueness of file contents, management of access log and trail information of file registration, and highly secure file Implement a shared system. FIG. 3 is an explanatory diagram of the basic concept of the present embodiment.

  In the present embodiment, first, the above four functions are realized under a distributed environment on a distributed file sharing network realized by peer-to-peer communication represented by IPFS. Therefore, in this embodiment, a communication method called a block chain is used. In the present embodiment, information related to an event that has occurred in a terminal is shared between node devices included in a distributed file sharing network using a block chain. Then, a file including information regarding the event is generated, and this file is held in any node device of the distributed file sharing network. As a result, the authentication and validity guarantee of transactions (transactions) in a distributed environment and the function of transaction history management that cannot be tampered with are applied and expanded. Conceptually, in this embodiment, as shown in FIG. 3A, when each node 307 communicates with the distributed file sharing network 301, first, the distributed type realized by the extension of the block chain is used. Access the authentication / trail management network 302. Thereafter, access is made to the distributed file sharing network 301 configured to be included in the authentication / trail management network 302.

  More specifically, the present embodiment has a configuration shown in FIG. In the configuration of FIG. 3B, the block chain application 303 (“BC” in the figure) is installed in the IoT gateway 305 or the client terminal 306. The block chain application 303 is software that processes a transaction using a block chain. An authentication / trail management network 302 is formed by the block chain application 303 operating on the IoT gateway 305 or the client terminal 306. In addition, an IPFS application 304 (“IPFS” in the figure) is installed in the IoT gateway 305 or the client terminal 306. The IPFS application 304 is software that provides a file registration (holding) or access function to the distributed file sharing network 301. A distributed file sharing network 301 is formed by the IPFS application 304 operating on the IoT gateway 305 or the client terminal 306. Hereinafter, the client terminal refers to a terminal operated by the client or the client itself.

  In the present embodiment, when an event such as sensor detection occurs or is received by the IoT gateway 305 and a file registration request for event information (information related to the event) corresponding thereto is generated, first, the block chain application 303 is first executed by the IoT gateway 305. Executed. The block chain application 303 causes the IPFS application 304 to register the event information file in the distributed file sharing network 301 by executing the IPFS application 304. At this time, the block chain application 303 operating on the IoT gateway 305 executes functions such as authentication for the user of the IoT gateway 305, guarantee of uniqueness of content, service repository, data history (log) management (trail management), and the like. . Thereby, the registration of the event information file to the distributed file sharing network 301 is executed with high security.

  In this embodiment, when a file browsing request is generated from the client terminal 306, the block chain application 303 is executed on the client terminal 306. The block chain application 303 causes the IPFS application 304 to execute file request processing to the distributed file sharing network 101 by executing the IPFS application 304. At this time, the block chain application 303 running on the client terminal 306 executes functions such as authentication of the user of the client terminal 306 or a group to which the user belongs, file access control, access log management (trail management), and the like. Thereby, file browsing on the distributed file sharing network 301 is executed in a highly secure manner.

  As described above with reference to FIG. 3B, in this embodiment, the block chain application 303 operates as a proxy for accessing the distributed file sharing network 301 via the IPFS application 304. As a result, a highly secure distributed file sharing closed network space is constructed.

  Here, blockchain is a technology for sharing “information (ledgers)” among users. By publishing a ledger with various transaction information (transactions), all users check their validity. It is a distributed ledger system that fulfills contracts without fraud.

  FIG. 4 is an explanatory diagram of a block chain. In the block chain, user authentication is performed by using a digital certificate technology. When the user first registers an account in the block chain, as shown in FIG. 4A, first, a secret key and a public key corresponding to the secret key are generated, and a user ID is further generated. It is issued against. Furthermore, an electronic certificate is issued to the user based on these private key and public key. The block chain has an authentication function that a user who has the electronic certificate can use the block chain. In this embodiment, this authentication function is utilized.

  A user issues a transaction by using three pieces of information: a secret key, a public key, and a user ID. Consider a case where a transaction Tx2 is issued from B to C, assuming that the issuer is B. In this case, the block chain has a function of issuing a new transaction with the transaction Tx1 sent to itself as an input. As described above, in the blockchain, a new transaction is issued based on an approved transaction, so that the reliability of the transaction can be improved.

  As shown in FIG. 4B, the public key of the destination user C is designated as the destination information of the transaction Tx2. A hash value is calculated for an unsigned transaction Tx2 including the hash value of the approved transaction Tx1, and an electronic signature is calculated using the private key of the user B for the hash value, and the electronic signature is calculated. Is added as information of the issuer of the transaction Tx2.

  When such a transaction Tx2 is broadcast to the blockchain network, another user belonging to the blockchain network verifies the signature of the transaction Tx2 as follows. As shown in FIG. 4B, a hash value is calculated from the unsigned part of the transaction Tx2. In addition, a hash value generated by generating the electronic signature of the user B attached as the issuer of the transaction Tx2 is calculated using the public key of the user B. Then, these two hash values are compared, and if the two hash values match, a verification result that the transaction Tx2 is issued by the correct user B is obtained.

  In this way, the blockchain improves the reliability of the transaction itself by issuing a new transaction with the hash value as input while verifying the past approved transaction with an electronic signature. Has a mechanism. Each block in the blockchain records “information about the block immediately before that block” and “a list of all transactions performed within a certain period of time (= summarizing individual transactions)” Composed of transactions. As a result, all transactions performed within a certain period of time are recorded in the transaction of each block.

  In the block chain, a specific check node called a minor in the block chain network executes a process of determining a block of a transaction newly issued from an arbitrary node. By this confirmation processing, highly secure ledger management can be realized, and all the history information of the transaction issuance is shared and managed on the distributed ledger.

  FIG. 4C is an explanatory diagram of the determination process. Minor is an unapproved three-part information consisting of the hash value of the previous block and the hash value of the root of the Merkle tree that summarizes the transaction list plus information called a nonce value that is randomly generated by itself. A hash value is calculated for the block. The minor finds a nonce value such that the hash value satisfies a specific condition (for example, a value such that a certain number of zeros or more are arranged at the beginning) while randomly changing the nonce value. As a result, the minor determines (approves) the unapproved block in a form that cannot be tampered with, based on the three pieces of information including the found nonce value. Miners who execute this confirmation process can earn rewards. The miner broadcasts the determined block to all users in the block chain network. With the block confirmation mechanism, a block having a hash value that does not satisfy the specific condition (for example, a state in which a certain number of zeros or more are arranged at the beginning) in the block chain network has been confirmed (approval). Is not considered a block. Unapproved blocks that have not been finalized cannot be used as input to the next block.

  The other user who receives the nonce value of the block first verifies whether or not the electronic signature of each transaction included in the block is correct. Further, the user verifies whether or not the hash value calculated from the block satisfies the above-described specific condition (for example, a state where a certain number of zeros or more are arranged at the beginning). Then, if there is no problem with the two verifications, the user adds an approved block to the end of his block chain in the procedure described with reference to FIG.

  When trying to falsify information in this block, a data structure that cannot be falsified can be constructed by creating a data structure so that the three pieces of information in the block and the entire block chain are inconsistent. By having a “single block chain” throughout the network, the entire transaction history can be shared.

  In the present embodiment, the block chain application 303 in FIG. 3B operating in the block chain network having the above mechanism operates as a proxy for accessing the distributed file sharing network 301 via the IPFS application 304. As described above, in the present embodiment, information related to an event that has occurred in a terminal is shared between node devices included in the distributed file sharing network using a block chain.

  FIG. 5 is a diagram illustrating a configuration example of the communication system 500 in the present embodiment. The communication system 500 includes a sensor device or client terminal (hereinafter “sensor device / client terminal”) 501 including a transaction issuing application (hereinafter “transaction issuing application”) 510. The communication system 500 includes a sensor edge node or client terminal (hereinafter referred to as “sensor edge node / client terminal”) having a block chain application (hereinafter “block chain application”) 511 and a distributed file sharing application (hereinafter “distributed file sharing application”) 512. )) 502. The combination of the sensor device 501 and the sensor edge node 502 is used in the sensor network use case of the IoT service example of FIG. The combination of the client terminal 501 and the client terminal 502 is used in the use case of the example supply chain in FIG. The sensor device / client terminal 501 and the sensor edge node / client terminal 502 may be an IoT gateway or a client terminal (hereinafter “IoT gateway / client terminal”) 503 that is an integrated node device. That is, the IoT gateway / client terminal 503 includes a transaction issuing application 510, a block chain application 511, and a distributed file sharing application 512. These applications may be deployed in a node device other than the node device including an IoT gateway or a client terminal. In the following description, the sensor device / client terminal 501 and the sensor edge node / client terminal 502 will be described together as an IoT gateway / client terminal 503.

  Further, the communication system 500 includes a client terminal 504 including a transaction issuing application 510, a block chain application 511, and a distributed file sharing application 512. For example, the client terminal 504 may have only the transaction issuing application 510, and the block chain application 511 and the distributed file sharing application 512 in the client terminal 504 may be installed in different node devices.

  In addition, the communication system 500 includes a block chain authentication node 505 and a block chain node 506. The authentication unit logs in a user or group to the authentication trail management block network 521 and issues a service permission transaction that is an initial transaction of the block chain.

  The transaction issuing application 510 includes an authentication unit that communicates with the block chain authentication node 505 to authenticate a user or group that operates the IoT gateway / client terminal 503 or the client terminal 504.

  The IoT gateway / client terminal 503 corresponds to the IoT gateway 103 or the client terminal 104 in FIG. 1 or the IoT gateway 305 in FIG. That is, the IoT gateway / client terminal 503 outputs sensor information, or outputs process information of products from procurement of raw materials / parts input by a terminal operator to manufacturing, inventory management, sales, and delivery.

  The IoT gateway / client terminal 503, the client terminal 504, the block chain authentication node 505, and the block chain node 506 form an authentication / trail management proxy network 521. The authentication / trail management proxy network 521 is included in the block chain network. The IoT gateway / client terminal 503 and the client terminal 504 form a distributed file sharing network 522.

  Details of the operation of the communication system 500 in the present embodiment having the configuration of FIG. 5 will be described below. FIG. 6 is a sequence diagram showing an example of file issuance processing in the communication system 500 of FIG. 5, and FIG. 7 is a diagram showing an example of a data format of each transaction used in the example of file issuance processing of FIG.

First, an example of file issue processing will be outlined.
<STEP1: Execution of user authentication>
First, user authentication for the sensor device / client terminal 501 in the IoT gateway / client terminal 503 is performed using an electronic certificate used in existing block chain software.

<STEP 2: Execution of trail management for file registration>
When the sensor device / client terminal 501 detects an event, the transaction issuing application 510 in FIG. 6 executes the following processing. The transaction issuing application 510 issues an event transaction (transaction related to an event) from the sensor device / client terminal 501 (userID #X) to a specific user (userID #Y) or a shared service (groupID #Z). This event transaction inputs a hash value of a service authorization transaction and includes event information.

<STEP3: Creation / Registration of Event Information File and Guarantee of Content Uniqueness>
After the block including the event transaction is confirmed by the check node, the block chain application 511 newly issues a file generation transaction (transaction for generating a file) for generating a file including the event information included in the event transaction. . When the file chain transaction is issued, the block chain application 511 embeds the hash value information of the event transaction as an ID for guaranteeing the uniqueness of the content, and automatically generates an event information file including the event information. The block chain application 511 registers the event information file in the distributed file sharing network 522 such as IPFS via the distributed file sharing application 512. At this time, the event information file may be given time stamp information that issued the event transaction.

<STEP4: Provision of repository function by updating portal file>
The block chain application 511 acquires, via the distributed file sharing application 512, file address information (hashed address in the case of IPFS) issued when the event information file is registered in the distributed file sharing network 522. The block chain application 511 receives a hash value of a file generation transaction as an input, and from the sensor device / client terminal 501 (userID #X) describing the file address, a specific user (userID #Y) or a shared service (groupID #Z) Issue a service registration transaction to the destination. This service registration transaction includes the hash value of the file generation transaction, the address information of the event information file, and the service information. When the service registration transaction is issued, the block chain application 511 adds / updates information in which content, for example, a service name and a file address are linked to a portal file indicating a portal site published on the distributed file sharing network 522. , Re-register.

  With the above procedure, it becomes possible to manage authentication and trail information related to file registration in the distributed file sharing network 522 and guarantee of the uniqueness of content in a block chain. At the same time, it is possible to provide a repository function for associating the relationship between a file address and content, for example, service information, and managing them as a portal file on the distributed file sharing network 522.

Next, details of the file issue processing example of FIG. 6 will be described.
First, the IoT gateway / client terminal 503 activates the transaction issuing application 510 in its own device when an event such as sensor output or terminal input from a sensor in its own device occurs. The transaction issuing application 510 accesses an existing authentication unit in the block chain application 511 executed by the own apparatus using a user account previously assigned to the own apparatus, and executes login (S601).

  The authentication unit of the block chain application 511 in the IoT gateway / client terminal 503 performs authentication for the login access while communicating with the block chain authentication node 505 in the authentication / trait management proxy network 521 (S602). ).

  When the authentication is successful, the authentication unit notifies the transaction issuing application 510 of the hash value of a predetermined service authorization transaction, and authorizes the user to log in to the authentication / trail network (block chain) 302 ( S603).

  Subsequently, the transaction issuing application 510 in the IoT gateway / client terminal 503 includes event information (sensor output information or process information, etc.) corresponding to an event that has occurred in its own device, and a hash value of the service authorization transaction. An event transaction is issued (S604). At this time, the transaction issuing application 510 sets the user ID of the own device and the public key information corresponding thereto as the issuer information in the event transaction. The transaction issuing application 510 also sets, in the event transaction, the user ID or group ID previously assigned to the file registration processing service and the corresponding public key information as destination information.

  This event transaction is notified to all the block chain nodes 506 forming the authentication / trait management proxy network 521 that is a block chain (S605). One or more nodes of the block chain node 506 operate as the check node (minor) described in FIG. 4C, and verify the electronic signature described in the notified transaction and determine the block. The process to be executed is executed. As a result, one of the check nodes executes a confirmation process on the event transaction block and issues a confirmation notification (S606).

  When receiving the event transaction issuance notification (S604) and the corresponding confirmation notification (S606), the block chain application 511 being executed by the IoT gateway / client terminal 503 executes the following processing. The block chain application 511 issues a file generation transaction (S607). This file generation transaction includes the hash value of the event transaction corresponding to the confirmed block and the event information included in the event transaction, and executes the file generation process. At this time, the block chain application 511 sets the user ID of the sensor device / client terminal 501 (see FIG. 5) set in the event transaction in the file generation transaction. This user ID is information of the issuer. Further, the block chain application 511 sets a user ID or group ID previously assigned to the file registration processing service set in the event transaction as destination information in the file generation transaction.

  This file generation transaction is notified to all the block chain nodes 506 forming the authentication / trait management proxy network 521 which is a block chain (S608). One check node in the block chain node 506 executes a confirmation process on the notified block of the file generation transaction and issues a confirmation notification (S606).

  When the block chain application 511 being executed by the IoT gateway / client terminal 503 receives the file generation transaction issuance notification (S607) and the confirmation notification corresponding to the block (S609), it executes the following processing.

  The block chain application 511 executes a file generation process (S610) for generating an event information file including event information in the received event transaction. At the same time, the block chain application 511 embeds the hash value of the event transaction set in the file generation transaction corresponding to the confirmed block in the event information file as an ID that guarantees the uniqueness of the content. The event information file may be given time stamp information when an event transaction is issued. Further, in order to improve the confidentiality of the file itself, the block chain application 511 uses the public key corresponding to the destination user ID or group ID set in the file generation transaction to register the event information file in the distributed file system. May be encrypted. In this case, only a user or group having a secret key corresponding to the public key of the user ID or group ID can view information on the corresponding event information file registered in the distributed file sharing system. Thereafter, the block chain application 511 activates the distributed file sharing application 512 in the own apparatus (S610).

  The distributed file sharing application 512 executes a file registration process including S611 and S612 below on the generated event information file. In the file registration process, the distributed file sharing application 512 first registers the event information file in the distributed file sharing network 522 (S611). Then, the distributed file sharing application 512 acquires the hash value of the event information file registered from the registration destination node as address information, and notifies the address information to the block chain application 511 in its own device (S612).

  When acquiring the address information corresponding to the event information file, the block chain application 511 issues a service registration transaction with the hash value of the file generation transaction as an input (S613). At this time, the block chain application 511 sets the hash value (address information) of the event information file acquired in S612 and the service information of the event corresponding to the event information file in the service registration transaction. Further, the block chain application 511 sets the user ID of the sensor device / client terminal 501 (see FIG. 5) set in the file generation transaction as issuer information in the service registration transaction. Further, the block chain application 511 sets a user ID or a group ID assigned in advance to the file registration processing service set in the file generation transaction as destination information in the service registration transaction.

  This service registration transaction is notified to all block chain nodes 506 forming the authentication / trait management proxy network 521 which is a block chain (S614). One check node in the block chain node 506 executes a confirmation process on the notified block of the service registration transaction and issues a confirmation notification (S615).

  Upon receiving the service registration transaction issuance notification (S613) and the confirmation notification (S615) corresponding to the block, the block chain application 511 being executed by the IoT gateway / client terminal 503 executes the following service registration processing. The block chain application 511 first accesses the distributed file sharing application 512 of its own device, and acquires a portal file from the distributed file sharing network 522 (S616). Subsequently, the block chain application 511 obtains information obtained by associating the hash value (address information) corresponding to the event information file acquired in S612 with the information including the service content corresponding to the event information file. Add to file and update. Then, the block chain application 511 accesses the distributed file sharing application 512 of the own device to re-register the updated portal file in the distributed file sharing network 522 (S617).

  In the portal file update process, the distributed file sharing application 512 in the IoT gateway / client terminal 503 executes exclusive control in order to avoid simultaneous update of portal files from other IoT gateway / client terminals 503. Also good. In this case, the distributed file sharing application 512 does not allow simultaneous update of the portal file, and performs control such that only one user is given update authority and other users are locked. In addition, an API for notifying the portal file manager of the relationship between the content and the file address is provided, and the distributed file sharing application 512 in the IoT gateway / client terminal 503 executes control to entrust the portal file manager to update the portal file. May be.

  With the above control processing, authentication and trail information relating to file registration in the distributed file sharing network 522, and guarantee of content uniqueness can be managed by the authentication / trait management proxy network 521 which is a block chain.

  In addition, the relationship between the content and the file address is linked, and the portal file on the distributed file sharing system can be centrally managed by the block chain. FIG. 8 is a diagram illustrating a data format example of the portal file processed in S616 and S617. In the portal file, a service value corresponding to the event information file and a file name of the event information file are associated with a hash value (address information) corresponding to the event information file.

  Next, details of a data format example of each transaction used in the file issuing process illustrated in FIG. 6 shown in FIG. 7 will be described.

  The event transaction issued by the transaction issuing application 510 of the IoT gateway / client terminal 503 in S604 of FIG. 6 has a data format illustrated in FIG. As shown in FIG. 7A, in the event transaction, the hash value of the service authorization transaction notified in S603 is set as an input transaction of the block chain. In the event transaction, event information corresponding to a sensor event that has occurred in the device itself is set. Further, in the event transaction, as the issuer information, the user ID (“userID #X” in FIG. 7A) of the sensor device / client terminal 501 (see FIG. 5) and the corresponding public key information are set. Is done. In the event transaction, as destination information, a user ID (“userID #Y” in FIG. 7A) assigned in advance to the file registration processing service or a group ID (“ groupID #Z ") and corresponding public key information are set.

  The file generation transaction issued by the block chain application 511 of the IoT gateway / client terminal 503 in S607 of FIG. 6 has a data format illustrated in FIG. 7B. As shown in FIG. 7B, the hash value of the event transaction corresponding to the block confirmed by the confirmation notification in S606 is set as the input transaction of the block chain in the file generation transaction. In the file generation transaction, event information set in the event transaction is set. Furthermore, in the file generation transaction, as the issuer information, the user ID of the sensor device / client terminal 501 (see FIG. 5) set in the event transaction (“userID #X” in FIG. 7B) and Corresponding public key information is set. Further, in the file generation transaction, as destination information, a user ID (“userID #Y” in FIG. 7B) or a group ID (in FIG. 7B) assigned in advance to the file registration processing service. “GroupID #Z”) and corresponding public key information are set.

  The service registration transaction issued by the block chain application 511 of the IoT gateway / client terminal 503 in S613 in FIG. 6 has a data format illustrated in FIG. 7C. As shown in FIG. 7C, the hash value of the file generation transaction corresponding to the block confirmed by the confirmation notification in S609 is set as the block chain input transaction in the service registration transaction. In the service registration transaction, the hash value (address information) corresponding to the event information file acquired in S612 and the service information of the event corresponding to the event information file are set. Further, in the service registration transaction, as the issuer information, the user ID of the sensor device / client terminal 501 (see FIG. 5) set in the file generation transaction (“userID #X” in FIG. 7C) Is set. In addition, in a service registration transaction, as destination information, a user ID (“userID #Y” in FIG. 7C) or a group ID (in FIG. 7C) assigned in advance to the file registration processing service. "GroupID #Z") is set.

The data format of the integrated transaction in FIG. 7D will be described later.
FIG. 9 is a sequence diagram illustrating another processing example of file issuance in the communication system 500 of FIG. In FIG. 6 described above, there are two file generation transactions for executing the file generation processing (S610) and file registration processing (S611, S612) and two service registration transactions for executing the service registration processing (S616, S617). It was divided into two. On the other hand, in FIG. 9, the file generation process (S610), the file registration process (S611, S612), and the service registration process (S616, S617) are continuously triggered by the confirmation of one transaction block. It is executed differently.

  Specifically, in FIG. 9, the sequence given the same reference number as in FIG. 6 is the same process as in FIG. 6. Only portions where the sequence of FIG. 9 is different from the sequence of FIG. 6 will be described below.

  When the block chain application 511 being executed by the IoT gateway / client terminal 503 receives the event transaction issuance notification (S604) and the corresponding confirmation notification (S606) in the same manner as the sequence of FIG. 6, the following processing is performed. Execute. The block chain application 511 issues an integrated transaction shown in the data format example of FIG. In this integrated transaction, the hash value of the event transaction corresponding to the block confirmed by the confirmation notification in S606 is set. In addition, event information included in the event transaction is set in the integrated transaction. In the integrated transaction, service information corresponding to the event information is set. Furthermore, the user ID (“userID #X” in FIG. 7D) set in the event transaction is set as the issuer information in the integrated transaction. In addition, in the integrated transaction, as destination information, a user ID (“userID #Y” in FIG. 7D) or a group ID (“groupID # in FIG. 7D) set in the event transaction” is set. Z ") is set.

  This integrated transaction is notified to all block chain nodes 506 forming the authentication / trait management proxy network 521 which is a block chain (S902). One check node in the block chain node 506 executes a confirmation process on the notified block of the file generation transaction and issues a confirmation notification (S903).

  When receiving the integrated transaction issue notification (S901) and the corresponding confirmation notification (S903), the block chain application 511 being executed by the IoT gateway / client terminal 503 executes the following processing. The block chain application 511 continuously executes the file generation process (S610), the file registration process (S611, S612), and the service registration process (S616, S617) described in the sequence of FIG.

  FIG. 10 is a sequence diagram showing an example of file access processing in the communication system 500 of FIG. 5, and FIG. 11 is a diagram showing an example of a data format of transactions used in the example of file access processing of FIG.

First, an example of file access processing will be outlined.
<STEP1: Execution of user authentication>
First, authentication of a user who performs file access from the client terminal 504 is performed using an electronic certificate issued by an existing block chain.

<STEP 2: Execution of File Access Trail Management>
In order for the user to access the file, the transaction issuing application 510 in the client terminal 504 issues a file browsing transaction including the address of the portal file of the portal site using the hash value of the service authorization transaction as an input. The issuer of this file browsing transaction is the user (userID #W) of the client terminal 504, the destination is a specific user (userID #Y) or a shared service (groupID #Z), and public key information corresponding thereto. The transaction issuing application 510 acquires the portal file information of the service that manages the shared space from the distributed file sharing network 522 via the block chain application 511 and the distributed file sharing application 512 in the client terminal 504. As a result, the user browses information on the portal site.

<STEP3: Execution of file access and execution of trail management of file access>
In the client terminal 504, the user selects a file described in the portal site. As a result, the transaction issuing application 510 in the client terminal 504 receives the hash value of the service authorization transaction as an input, and issues a file browsing transaction including the address of the file selected by the user. The issuer of this file browsing transaction is the user of the client terminal 504 (userID #W), the destination is the specific user (userID #Y) or the shared service (groupID #Z) and the public key information corresponding to them. The transaction issuing application 510 acquires the corresponding file from the distributed file sharing network 522 via the block chain application 511 and the distributed file sharing application 512 in the client terminal 504. As a result, the user can browse the corresponding file.

  Through the above processing, file access authentication and trail information on the distributed file sharing network 522 can be realized by utilizing the block chain function. This information may be used for service billing. Further, until the user obtains the requested file information, it waits for the issuance of a file access transaction for file access, and the relevant transaction may be issued after the file acquisition is confirmed. Each transaction is not executed until the block confirmation process in the block chain is completed, and the node that executes the block confirmation may be its own node or another node.

Next, details of the file access processing example of FIG. 10 will be described.
First, when a file browsing request event occurs, the client terminal 504 activates the transaction issuing application 510 in its own device. The transaction issuing application 510 accesses the existing authentication unit in the block chain application 511 of the client terminal 504 using a user account previously assigned to the client terminal 504, and executes login (S1001).

  The authentication unit of the block chain application 511 in the client terminal 504 executes authentication for the login access while communicating with the block chain authentication node 505 in the authentication / trait management proxy network 521 (S1002).

  When the authentication is successful, the authentication unit notifies the transaction issuing application 510 of the hash value of a predetermined service authorization transaction and authorizes login (S1003).

  Subsequently, the transaction issuing application 510 in the client terminal 504 includes the hash value (address information) of the portal file specified by the file browsing request generated in the own device and the hash value of the service authorization transaction. 1 file browsing transaction is issued (S1004). At this time, the transaction issuing application 510 sets the user ID of the client terminal 504 as the issuer information in the first file browsing transaction. Further, the transaction issuing application 510 sets a user ID or a group ID assigned in advance to the file registration processing service as destination information in the first file browsing transaction.

  This first file browsing transaction is notified to all block chain nodes 506 forming the authentication / trait management proxy network 521 which is a block chain (S1005). One check node in the block chain node 506 executes a confirmation process on the notified block of the first file browsing transaction and issues a confirmation notification (S1006).

  When the block chain application 511 being executed on the client terminal 504 receives the first file browsing transaction issuance notification (S1004) and the corresponding confirmation notification (S1006), it executes the following processing. The block chain application 511 issues a portal file request specifying the hash value (address information) of the portal file included in the first file browsing transaction to the distributed file sharing application 512 in the client terminal 504 (S1007).

  As a result, the distributed file sharing application 512 in the client terminal 504 accesses the distributed file sharing network 522 using the hash value, acquires a portal file, and transmits the portal file to the block chain application 511 in the client terminal 504. The block chain application 511 transmits the contents of the portal file to the transaction issuing application 510 in the client terminal 504 (S1008). As a result, a list of service names, event information file names, and hash values (address information) of the event information files illustrated in FIG. It becomes possible.

  Subsequently, the user of the client terminal 504 designates the hash value of the event information file corresponding to one of the service names while viewing the list on the display. As a result, the transaction issuing application 510 in the client terminal 504 receives the hash value (address information) of the event information file specified in the file browsing request generated in the own device and the service authorization transaction acquired in S1003. A second file browsing transaction including the hash value is issued (S1009). At this time, the transaction issuing application 510 sets the user ID of the client terminal 504 and the public key information corresponding thereto as the issuer information in the second file browsing transaction. In addition, the transaction issuing application 510 sets a user ID or a group ID assigned in advance to the file registration processing service and public key information corresponding thereto as destination information in the second file browsing transaction.

  This second file browsing transaction is notified to all block chain nodes 506 forming the authentication / trait management proxy network 521 which is a block chain (S1010). One check node in the block chain node 506 executes a confirmation process on the notified block of the second file browsing transaction and issues a confirmation notification (S1011).

  When the block chain application 511 being executed on the client terminal 504 receives the second file browsing transaction issuance notification (S1009) and the corresponding confirmation notification (S1011), the blockchain application 511 executes the following processing. The block chain application 511 issues a file request specifying the hash value (address information) of the event information file included in the second file browsing transaction to the distributed file sharing application 512 in the client terminal 504 (S1012).

  As a result, the distributed file sharing application 512 in the client terminal 504 accesses the distributed file sharing network 522 using the hash value, acquires an event information file, and transmits it to the block chain application 511 in the client terminal 504. The block chain application 511 transmits the contents of the event information file to the transaction issuing application 510 in the client terminal 504 (S1013). As a result, the contents of the event information file are displayed on the client terminal 504, particularly a display (not shown), and can be browsed by the user.

  Next, details of a data format example of a transaction used in the file access processing example illustrated in FIG. 10 illustrated in FIG. 11 will be described.

  The first or second file browsing transaction issued by the transaction issuing application 510 of the client terminal 504 in S1004 or S1009 of FIG. 10 has a data format illustrated in FIG. As shown in FIG. 11, the hash value of the service authorization transaction notified in S1003 is set as the input transaction of the block chain in the file browsing transaction. In the file browsing transaction, a hash value (address information) of the portal file or event information file corresponding to the portal file or event information file browsing request generated in the own apparatus is set. Further, in the event transaction, the user ID of the client terminal 504 (“userID #W” in FIG. 11) and the corresponding public key information are set as issuer information. Further, in the file browsing transaction, as destination information, a user ID (“userID #Y” in FIG. 11) or a group ID (“groupID #Z in FIG. 11) assigned in advance to the file browsing processing service described above is used. ]) And public key information corresponding to them. This user ID or group ID is the same as the destination user ID or group ID shown in FIG. 7, which is assigned in advance to the above-described file registration processing service.

  Through the above file access processing, file access authentication and trail information in the distributed file system on the distributed file sharing network 522 can be realized by utilizing the block chain function. This information may be used for service billing or the like.

  Further, until the user obtains the requested file information, it waits for the issuance of a file browsing transaction, and the transaction may be issued after the file acquisition is confirmed.

  FIG. 12 is a diagram illustrating an example of a hardware configuration of a computer that can realize the function of the IoT gateway / client terminal 503 or the client terminal 504 of FIG. 5 as software processing.

  A computer shown in FIG. 12 includes a CPU (Central Processing Unit) 1201, a memory 1202, an input device 1203, an output device 1204, an external storage device 1205, a portable recording medium driving device 1206 into which a portable recording medium 1209 is inserted, And a communication interface 1207, which are connected to each other by a bus 1208. The configuration shown in FIG. 12 is an example of a computer that can realize the function of the IoT gateway / client terminal 503 or the client terminal 504, and such a computer is not limited to this configuration.

  The CPU 1201 controls the entire computer. The memory 1202 is a memory such as a RAM that temporarily stores a program or data stored in the external storage device 1205 (or the portable recording medium 1209) when executing a program, updating data, or the like. The CUP 1201 performs overall control by reading the program into the memory 1202 and executing it.

  The input device 1203 detects an input operation by a user using a keyboard, a mouse, or the like, and notifies the CPU 1201 of the detection result.

  The output device 1204 outputs data sent under the control of the CPU 1201 to a display device or a printing device.

  The external storage device 1205 is, for example, a hard disk storage device. Mainly used for storing various data and programs.

  The portable recording medium driving device 1206 accommodates a portable recording medium 1209 such as an SD card, a compact flash (registered trademark), a CD-ROM, a DVD, and an optical disk, and has a role of assisting the external storage device 1205. .

  The communication interface 1207 is a device for connecting, for example, a LAN (local area network) or WAN (wide area network) communication line.

  The functions of the IoT gateway / client terminal 503 or the client terminal 504 in FIG. 5 are realized by the CPU 1201 executing a program equipped with functions realized by the flowcharts in FIGS. 13 to 15 described below. The program may be distributed by being recorded in, for example, the external storage device 1205 or the portable recording medium 1209, or may be acquired from the network by the communication interface 1207.

  FIG. 13 is a flowchart showing an example of file issuance processing executed when the IoT gateway / client terminal 503 of FIG. 5 is implemented as a computer having the hardware configuration example of FIG. 12, and a processing example of a check node corresponding thereto. It is. This processing is a diagram showing processing when the file issuing processing of the IoT gateway / client terminal 503 shown in the sequence example of FIG. 6 described above is executed by the computer of the hardware configuration example of FIG. This process is a process in which the CPU 1201 in FIG. 12 executes a file issuance process program loaded from the external storage device 1205 or the like into the memory 1202.

  In FIG. 13, steps S1301 and S1302 are processes executed by the transaction issuing application 510 implemented by the IoT gateway / client terminal 503 in FIG. The processes in steps S1305 and S1308 to S1310, and S1313 and S1314 are processes executed by the block chain application 511 installed in the IoT gateway / client terminal 503 in FIG. Further, the processes in steps S1311 and S1312, and S1319 and S1320 are processes executed by the distributed file sharing application 512 implemented by the IoT gateway / client terminal 503 in FIG. Further, the processes in steps S1303 and S1304, S1306 and S1307, and S1315 and S1316 are processes executed by a CPU (not shown) of the check node.

  First, the CPU 1201 executes user authentication processing for its own device (step S1301). This process is an existing authentication process of the block chain, and is a process for executing the sequence from S601 to S603 in FIG.

  Next, the CPU 1201 executes event transaction issuing processing (step S1302). This process is a process for executing the sequence of S604 in FIG.

  As a result of the processing in step S1302, a transaction notification (S605 in FIG. 6) is transmitted from the CPU 1201 to the inspection node on the authentication / trait management proxy network 521 (see FIG. 5) on the LAN via the communication interface 1207. As a result, the CPU of the check node acquires an event transaction (step S1303), determines a block including the event transaction, and returns a confirmation notification of the block to the IoT gateway / client terminal 503 (step S1304). This process is a process for executing the sequence of S606 in FIG.

  When the CPU 1201 of the IoT gateway / client terminal 503 receives the confirmation notification via the communication interface 1207, the CPU 1201 executes a file generation transaction issuing process (step S1305). This process is a process for executing the sequence of S607 in FIG.

  As a result of the processing in step S1305, a transaction notification (S608 in FIG. 6) is transmitted from the CPU 1201 to the inspection node on the authentication / trait management proxy network 521 (see FIG. 5) via the communication interface 1207. As a result, the CPU of the check node acquires the file generation transaction (step S1306), determines the block including the file generation transaction, and returns a notification of the block determination to the IoT gateway / client terminal 503 (step S1307). . This process is a process for executing the sequence of S609 in FIG.

  When the CPU 1201 of the IoT gateway / client terminal 503 receives the confirmation notification via the communication interface 1207, the CPU 1201 starts executing the processing logic executed in response to the file generation transaction corresponding to the confirmed block ( Step S1308).

  In this processing logic, the CPU 1201 first executes a file generation process (step S1309). This process is a process for executing the sequence of S610 in FIG.

  In the above processing logic, the CPU 1201 next executes a file registration process (step S1310). This process is a process for executing the sequence of S611 in FIG.

  As a result, the CPU 1201 executes an event information file registration process for the distributed file sharing network 522 on the LAN via the communication interface 1207 (step S1311). This process is a process for executing the sequence of S611 in FIG.

  As a result of the file registration process in step S1311, the CPU 1201 issues the hash value of the event information file as address information (step S1312). As a result, the CPU 1201 executes processing such as acquiring the issued address information and storing it in the memory 1202 (step S1313). The processes in steps S1312 and S1313 are processes for executing the sequence of S612 in FIG.

  Subsequently, the CPU 1201 executes a service registration transaction issue process (step S1314). This process is a process for executing the sequence of S613 in FIG.

  As a result of the processing in step S1314, a transaction notification (S614 in FIG. 6) is transmitted from the CPU 1201 to the inspection node on the authentication / trait management proxy network 521 (see FIG. 5) via the communication interface 1207. As a result, the CPU of the inspection node obtains the service registration transaction (step S1315), confirms the block including the service registration transaction, and returns a confirmation notification of the block of the service registration transaction to the IoT gateway / client terminal 503. (Step S1316). This process is a process for executing the sequence of S615 in FIG.

  When the CPU 1201 of the IoT gateway / client terminal 503 receives the confirmation notification via the communication interface 1207, the CPU 1201 starts execution of processing logic executed in response to the service registration transaction corresponding to the confirmed block ( Step S1317).

  In this processing logic, the CPU 1201 first executes portal file acquisition processing on the block chain application 511 (step S1318). As a result, the CPU 1201 executes the distributed file sharing application 512 to access the portal file on the distributed file sharing network 522 and acquire it (step S1319). The processing in steps S1318 and S1319 is processing for executing the sequence in S616 in FIG.

  In the above processing logic, the CPU 1201 next executes a portal file update process (step S1320). Here, the CPU 1201 executes the block chain application 511. As a result, the CPU 1201 adds, to the acquired portal file, information obtained by associating the hash value (address information) corresponding to the event information file acquired in step S1313 with the information including the service content corresponding to the event information file. And update. Thereafter, the CPU 1201 shifts execution from the block chain application 511 to the distributed file sharing application 512. The CPU 1201 re-registers the portal file updated in step S1320 in the distributed file sharing network 522 (step S1321). The processing in steps S1320 and S1321 is processing for executing the sequence in S617 in FIG.

  The file issuing process illustrated in the flowchart of FIG. 13 is executed by the computer of the hardware configuration example of FIG. 12, whereby the file issuing process of the sequence illustrated in FIG. 6 by the IoT gateway / client terminal 503 is realized. The

  FIG. 14 shows another example of file issuance processing executed when the IoT gateway / client terminal 503 in FIG. 5 is implemented as a computer having the hardware configuration example in FIG. It is a flowchart to show. This processing is a diagram showing processing when another file issuing processing of the IoT gateway / client terminal 503 shown in the sequence example of FIG. 9 described above is executed by the computer of the hardware configuration example of FIG. This process is a process in which the CPU 1201 in FIG. 12 executes another WEB issue process program loaded from the external storage device 1205 or the like into the memory 1202.

  In FIG. 13 described above, two transactions are issued in addition to the event transaction issuance (S1302) corresponding to the sequence example described in FIG. One of them is a file generation transaction issuance (S1305) for executing a file generation process (S1309) and a file registration process (S1310, S1311). The other is a service registration transaction issuance (S1314) for executing the service registration process (S1318 to S1321). On the other hand, in FIG. 14, the series of processes (S1309 to S1311, S1318 to S1321) correspond to the sequence example described above with reference to FIG. It is executed differently.

  Specifically, in FIG. 14, steps denoted by the same reference numerals as in FIG. 13 are the same processing as in FIG. 13. Only portions where the steps of FIG. 14 are different from the steps of FIG. 13 will be described below.

  In the execution of the block chain application 511, the CPU 1201 executes the following process when receiving the block confirmation notification (S1304) corresponding to the event transaction, as in the case of FIG. The CPU 1201 executes integrated transaction issuance processing (step S1401). This process is a process for executing the sequence of S901 in FIG.

  As a result of the processing in step S1401, a transaction notification (S902 in FIG. 9) is transmitted from the CPU 1201 to the inspection node on the authentication / trait management proxy network 521 (see FIG. 5) via the communication interface 1207. As a result, the CPU of the check node acquires the integrated transaction (step S1402), determines the block including the integrated transaction, and returns a confirmation notification of the block corresponding to the integrated transaction to the IoT gateway / client terminal 503 ( Step S1403). This process is a process for executing the sequence of S903 in FIG.

  When the CPU 1201 of the IoT gateway / client terminal 503 receives the confirmation notification via the communication interface 1207, the CPU 1201 starts execution of processing logic executed corresponding to the integrated transaction corresponding to the confirmed block (step). S1401).

  In this processing logic, the CPU 1201 executes a series of processes from Steps S1309 to S1313 as in the case of FIG. 13, and further continuously executes a series of processes from Steps S1318 to S1321. These processes are processes in which a series of sequences from S610 to S612 in FIG. 9 are executed, and a series of sequences in S616 and S617 are executed successively.

  The other file issuance processing illustrated in the flowchart of FIG. 14 is executed by the computer of the hardware configuration example of FIG. 12, so that another WEB issuance of the sequence illustrated in FIG. 9 by the IoT gateway / client terminal 503 is performed. Processing is realized.

  FIG. 15 is a flowchart illustrating an example of file access processing executed when the client terminal 504 of FIG. 5 is implemented as a computer having the hardware configuration example of FIG. 12, and a processing example of a check node corresponding thereto. This processing is a diagram showing processing when the file access processing of the client terminal 504 shown in the above-described sequence example of FIG. 10 is executed by the computer of the hardware configuration example of FIG. This process is a process in which the CPU 1201 in FIG. 12 executes a file access processing program loaded from the external storage device 1205 or the like into the memory 1202.

  15, steps S1501, S1502, and S1508 are processes executed by the transaction issuing application 510 implemented by the client terminal 504 in FIG. Steps S1505 and S1506, and S1511 and S1512 are processes executed by the block chain application 511 implemented by the client terminal 504 in FIG. Further, the processing in steps S1507 and S1513 is processing executed by the distributed file sharing application 512 implemented by the client terminal 504 in FIG. Further, the processes of steps S1503 and S1504 and S1509 and S1510 are processes executed by a CPU (not shown) of the check node.

  First, the CPU 1201 executes user authentication processing for the client terminal 504 (step S1501). This process is an existing authentication process of the block chain, and is a process for executing the sequence from S1001 to S1003 in FIG.

  Next, the CPU 1201 executes a first file browsing transaction issuing process (step S1502). This process is a process for executing the sequence of S1004 in FIG.

  As a result of the processing in step S1502, a transaction notification (S1005 in FIG. 10) is transmitted from the CPU 1201 to the inspection node on the authentication / trait management proxy network 521 on the LAN (see FIG. 5) via the communication interface 1207. As a result, the CPU of the inspection node acquires the first file browsing transaction (step S1503), determines the block including the first file browsing transaction, and returns a confirmation notification of the block to the client terminal 504 ( Step S1504). This process is a process for executing the sequence of S1006 in FIG.

  When the CPU 1201 of the client terminal 504 receives the confirmation notification via the communication interface 1207, the CPU 1201 starts execution of the processing logic executed for the first file browsing transaction corresponding to the confirmed notification block (Step S1). S1505).

  With this processing logic, the CPU 1201 first executes a portal file request process using the hash value (address information) of the portal file from the block chain application 511 to the distributed file sharing application 512 in the client terminal 504 (step S1506). As the hash value (address information) of the portal file, the one specified in the first file browsing transaction is used. This process is a process for executing the sequence of S1007 in FIG.

  As a result, the CPU 1201 accesses the distributed file sharing network 522 using the hash value on the distributed file sharing application 512, acquires a portal file, and transmits the portal file to the transaction issuing application 510 via the block chain application 511. As a result, the CPU 1201 displays a list of service names, event information file names, and hash values (address information) of the event information files illustrated in FIG. The user can browse. This process is a process for executing the sequence of S1008 in FIG.

  Subsequently, the user of the client terminal 504 designates the hash value of the event information file corresponding to one of the service names while viewing the list on the display. As a result, the CPU 1201 executes the second file browsing transaction issuing process including the hash value (address information) of the event information file specified by the file browsing request generated in the own device on the transaction issuing application 510. (S1508). This process is a process for executing the sequence of S1009 in FIG.

  As a result of the processing in step S1508, a transaction notification (S1010 in FIG. 10) is transmitted from the CPU 1201 to the inspection node on the authentication / trait management proxy network 521 (see FIG. 5) via the communication interface 1207. As a result, the CPU of the inspection node acquires the second file browsing transaction (step S1509), determines the block including the second file browsing transaction, and returns a confirmation notification of the block to the client terminal 504 ( Step S1510). This process is a process for executing the sequence of S1011 in FIG.

  When the CPU 1201 of the client terminal 504 receives the confirmation notification via the communication interface 1207, the CPU 1201 starts executing the processing logic executed in response to the second file browsing transaction corresponding to the confirmed block ( Step S1511).

  With this processing logic, the CPU 1201 first executes file request processing using the hash value (address information) of the event information file from the block chain application 511 to the distributed file sharing application 512 in the client terminal 504 (step S1512). As the hash value (address information) of the event information file, the one specified in the second file browsing transaction is used. This process is a process for executing the sequence of S1012 in FIG.

  As a result, the CPU 1201 accesses the distributed file sharing network 522 using the hash value on the distributed file sharing application 512, acquires an event information file, and transmits the event information file to the transaction issuing application 510 via the block chain application 511. As a result, the contents of the event information file are displayed on the client terminal 504, particularly a display (not shown), and can be browsed by the user. This process is a process for executing the sequence of S1013 in FIG.

  As described above, in this embodiment, information related to an event that has occurred in a terminal is shared between node devices included in a distributed file sharing network using a block chain. Then, a file including information regarding the event is generated, and this file is held in any node device of the distributed file sharing network. Thereby, in the distributed file sharing system, it is possible to construct a highly secure file sharing space that is a closed network space. In the present embodiment, when a file registration request for event information based on sensor detection, terminal input, or the like occurs in the IoT gateway / client terminal 503 or a file browsing request occurs from the client terminal 504, the following Control is executed. In this case, the block chain application 511 is executed by the IoT gateway / client terminal 503 and the client terminal 504, and the block chain application 511 executes (kicks) the distributed file sharing application 512. Thereby, the distributed file sharing application 512 executes registration and access of the event information file to the distributed file sharing network 522. In this case, the block chain application 511 of the IoT gateway / client terminal 503 and the client terminal 504 executes user / group authentication, guarantee of content uniqueness, service repository, file data / access log management, and file access control. To do. Thereby, the registration / access of the event information file to the distributed file sharing network 522 and the access of the portal file are executed with high security.

  Specifically, in this embodiment, an authentication function provided in the block chain can provide an authentication function in units of users and groups in the distributed file sharing network.

  In this embodiment, in the file generation process, the hash value of the event transaction is embedded in the event information file as identification information that guarantees the uniqueness of the content. As a result, according to the present embodiment, it is possible to provide a function for guaranteeing the uniqueness of the content of the event information file on the distributed file sharing network.

  Furthermore, in the present embodiment, information in which information including service contents is associated with the address information of the event information file registered in the distributed file sharing network is registered in the portal file on the distributed file sharing network. Thus, according to the present embodiment, it is possible to provide a repository function that centrally manages the relationship between the service and the address of the event information file on the distributed file sharing network.

  In addition, in the present embodiment, the registration and access process of the event information file is recorded in the block chain. Thereby, according to the present embodiment, it is possible to provide a trail management function such as data history (log) recording at the time of file registration in the distributed file sharing network and access history (log) recording at the time of file access. Become.

  As described above, in this embodiment, it is possible to integrate a distributed file sharing network such as a distributed WEB system based on IPFS, for example, in a robust network space formed by a block chain. Thereby, for example, it is possible to easily and securely realize an IoT gateway / client terminal that can perform file service of a huge amount of sensor information output and client terminal input.

  As a use case to which the present embodiment is applied, a system that senses a state of “thing” in physical distribution, records information of “thing” such as occurrence of abnormality, and publishes it can be considered.

  More specifically, according to the present embodiment, a self-organizing network that creates sensor information output and file service of client terminal input is realized only by peer-to-peer communication between the IoT gateway / client terminal.

  In addition, according to the present embodiment, security functions such as user authentication, guaranteeing the uniqueness of content including data copyright, and access trail can be realized by applying and expanding blockchain technology to create a robust closed space. Type security platform is realized.

  Further, the communication system according to the present embodiment can be developed from a small start of a specific industry / organization to a place of service co-creation connecting a plurality of industries / organizations, and a co-creation space of IoT information expanded from the small start. Is realized.

Regarding the above embodiment, the following additional notes are disclosed.
(Appendix 1)
A communication method executed by a node device included in a distributed file sharing network,
Sharing information about events that occur in the terminal between the node devices included in the distributed file sharing network using a block chain,
Generate a file containing information about the event;
Holding the generated file in any of the node devices included in the distributed file sharing network;
A communication method characterized by the above.
(Appendix 2)
After the node device holds the file, the node device adds, to the portal file, information in which information including service contents corresponding to the file is associated with the address information of the file held in the distributed file sharing network. , Holding the portal file in the distributed file sharing network,
The communication method according to supplementary note 1, wherein:
(Appendix 3)
The node device is
By issuing a transaction for generating the file after determining a block corresponding to a transaction including information on the event, the hash value of the determined transaction is embedded in the file as identification information that guarantees the uniqueness of content.
The communication method according to appendix 1 or 2, characterized in that:
(Appendix 4)
The node device manages the data history when the file is held in the distributed file sharing network by the block chain.
The communication method according to any one of appendices 1 to 3, characterized in that:
(Appendix 5)
At least one of the node devices is
Authenticate and issue a blockchain transaction that specifies the address information of the portal file as a first file browsing transaction,
When the first file browsing transaction is issued, the portal file is acquired from the distributed file sharing network based on the address information of the portal file,
Issuing a block chain transaction specifying the address information of the file of information related to the event corresponding to the service content selected on the acquired portal file as a second file browsing transaction;
Triggering the issuance of the second file browsing transaction, the information file related to the event is acquired from the distributed file sharing network based on the address information of the file related to the event.
The communication method according to Supplementary Note 2, wherein
(Appendix 6)
The node device is
Issuing a blockchain transaction that specifies the file address information related to the event information as a file browsing transaction,
Triggering the issuance of the file browsing transaction, the information file related to the event is acquired from the distributed file sharing network based on the address information of the file related to the event.
The communication method according to supplementary note 1, wherein:
(Appendix 7)
The node device manages an access history when accessing the distributed file sharing network by the block chain.
The communication method according to appendix 5 or 6, characterized in that:
(Appendix 8)
The node device is
Set user account information including a set of user public key and user secret key for each user who operates the node device,
For each group to which a plurality of users belong, set group account information including a group public key and a group secret key shared among the plurality of users belonging to the group,
When generating the file, encrypt the file with a user public key or group public key corresponding to the destination user or group set in the transaction in the blockchain;
The communication method according to any one of appendices 1 to 7, characterized in that:
(Appendix 9)
The node device periodically updates each value of the set of the user public key and the user secret key, or each value of the set of the group public key and the group secret key, with an expiration date.
The communication method according to appendix 8, characterized by:
(Appendix 10)
Issuing information related to the event as a transaction of the block chain, and generating a file including information related to the event triggered by the issue of the transaction,
The communication method according to any one of appendices 1 to 9, characterized in that:
(Appendix 11)
At least one of the generation of the file, the holding of the file, or the holding of the portal file is executed by the different node device.
The communication method according to any one of appendices 1 to 10, characterized in that:
(Appendix 12)
The distributed file sharing network configures an interplanetary file system as a distributed file system, and specifies the address information as a hyperlink including a hash value of the held file as a content address.
The communication method according to any one of appendices 1 to 11, characterized in that:
(Appendix 13)
A communication device included in a distributed file sharing network,
Means for sharing information about an event occurring at a terminal between node devices included in the distributed file sharing network using a block chain;
Means for generating a file containing information about the event;
Means for holding the generated file in any of the node devices included in the distributed file sharing network;
A communication apparatus comprising:
(Appendix 14)
In the node device computer included in the distributed file sharing network,
Information related to the event that occurred in the terminal is shared between the node devices included in the distributed file sharing network using a block chain,
Generate a file containing information about the event;
Holding the generated file in any of the node devices included in the distributed file sharing network;
A program to make things happen.

101, 301, 522 Distributed file sharing network 103 IoT device 104, 222, 306, 504 Client terminal 201 Distributed WEB network 202 Cloud service 203 Internet or carrier network 221, 305 IoT gateway 302 Authentication / trail management network 303 Block chain application 304 IPFS Application 307 Node 500 Communication system 501 Sensor device / client terminal 502 Sensor edge node / client terminal 503 IoT gateway / client terminal 505 Block chain authentication node 506 Block chain node 510 Transaction issuing application 511 Block chain application 512 Distributed file sharing application 521 Authentication Trail management proxy network 1201 CPU
1202 Memory 1203 Input device 1204 Output device 1205 External storage device 1206 Portable recording medium driving device 1207 Communication interface 1208 Bus 1209 Portable recording medium

Claims (6)

A distributed file contained in a shared network, and the distributed file that share the other device and the data to participate in a shared network node apparatus,
Terminal transmitting the file request triggered by the issuance of a file browsing transaction block chain specifying the data held in the distributed file sharing network
With
It said node device receives the file request from the terminal, communication system and transmits the data specified by the file request to the terminal. The file browsing transaction, communication system according to claim 1, characterized in that based on the information about the data retained with the approval result of block chain network to the distributed file sharing network, issued . The information about the data includes address information of the data,
3. The communication according to claim 2, wherein information in which information including service contents corresponding to the data is associated with address information of the data is held in the distributed file sharing network as information on the data. System. Communication system according to claim 3 in which the address information of the data is the data history as it is held in the distributed file sharing network, managed by the block chain, and wherein the. It said node device, the distributed file access history during access to the shared network, communication system as claimed in any one of claims 1 to 4 wherein the managing by the block chain, and wherein the. The node device is included in the distributed file sharing network and shares data with other devices participating in the distributed file sharing network.
Terminal transmits file request triggered by the issuance of file browsing transaction block chain specifying the data held in the distributed file sharing network,
When the node device receives the file request from the terminal, the node device transmits data specified by the file request to the terminal .