WO2018186391A1 - 検査システム、検査方法、およびコンピュータプログラム - Google Patents

検査システム、検査方法、およびコンピュータプログラム Download PDF

Info

Publication number
WO2018186391A1
WO2018186391A1 PCT/JP2018/014256 JP2018014256W WO2018186391A1 WO 2018186391 A1 WO2018186391 A1 WO 2018186391A1 JP 2018014256 W JP2018014256 W JP 2018014256W WO 2018186391 A1 WO2018186391 A1 WO 2018186391A1
Authority
WO
WIPO (PCT)
Prior art keywords
inspection
inspector
block chain
result
client
Prior art date
Application number
PCT/JP2018/014256
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 EP18781236.7A priority Critical patent/EP3608819B1/en
Priority to JP2018557060A priority patent/JP6457165B1/ja
Priority to CN202310810821.0A priority patent/CN116821908A/zh
Priority to CN201880021436.5A priority patent/CN110462619B/zh
Publication of WO2018186391A1 publication Critical patent/WO2018186391A1/ja
Priority to US16/591,915 priority patent/US11074343B2/en
Priority to US17/354,481 priority patent/US11741229B2/en
Priority to US18/351,697 priority patent/US20230359735A1/en

Links

Images

Classifications

    • 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/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/561—Virus type analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
    • 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/3236—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 using cryptographic hash functions
    • H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/034—Test or assess a computer or a system

Definitions

  • the present invention relates to data processing technology, and more particularly to an inspection system, an inspection method, and a computer program.
  • Patent Document 1 In recent years, information security has been regarded as important, and anti-virus software has been introduced into many computers (for example, see Patent Document 1).
  • anti-virus software Although the introduction of anti-virus software is in progress, in reality, it is not possible to detect all malware (computer viruses, Trojan horses, spyware, etc.) with a single anti-virus software. In addition, it is very expensive to install a plurality of types of anti-virus software having different vendors and characteristics into one computer.
  • the present invention has been made in view of the above-mentioned problems, and one object is to provide a technique for supporting inspection of electronic data.
  • an inspection system includes a first device that records inspection target data in a predetermined area and a user who is operated by a user who checks whether the inspection target data is illegal. And a third device that uses the inspection result for the inspection target data.
  • the second device acquires the inspection object data recorded by the first device, records the inspection result for the inspection object data in a predetermined area, and the third device performs the inspection recorded by the second device. Get the result.
  • This inspection system includes a client apparatus operated by an inspection requester, one or more inspector apparatuses operated by one or more inspectors, and a block chain accessible to the requester apparatus and the inspector apparatus.
  • the requester device records the inspection object data in a predetermined area and records the inspection reward in the block chain system.
  • the inspector device acquires the inspection object data recorded by the requester device, and the inspection object data
  • the client apparatus acquires the inspection result recorded by the inspector apparatus, and blocks the data of the correct answerer who is the inspector whose inspection result is recognized as correct by the client. Recording to the system, the blockchain system distributes the inspection reward to the correct answerer.
  • Still another aspect of the present invention is an inspection method.
  • the first device records the inspection target data in a predetermined area
  • the second device operated by the user who inspects whether the inspection target data is illegal is recorded by the first device.
  • inspection of electronic data can be supported.
  • the inspection system includes a block chain network that is a distributed network in which it is difficult to falsify data.
  • FIG. 1 shows the configuration of the inspection system 10 of the first embodiment.
  • the inspection system 10 includes a client apparatus 12, an inspector apparatus 14, a viewer apparatus 16, and a file server 18. 1 are connected via a communication network 20 including a LAN, a WAN, the Internet, and the like.
  • the requester apparatus 12 is an information processing apparatus operated by a user (hereinafter also referred to as “requester”) who requests an external inspection of electronic data (electronic file in the embodiment).
  • the electronic file to be inspected (hereinafter also referred to as “test file”) may be an electronic file suspected of having malware or an electronic file whose safety is to be confirmed.
  • the inspector apparatus 14 is an information processing apparatus operated by a user (hereinafter also referred to as “inspector”) that inspects the validity of the test file (in other words, the presence or absence of fraud, the presence or absence of malware).
  • the inspector may be an expert in information security technology, for example.
  • the browser device 16 is an information processing device operated by a user who browses the examination result for the test file (hereinafter also referred to as “browser”), and also performs information processing using the examination result. It is.
  • the client device 12, the examiner device 14, and the viewer device 16 may be, for example, a PC, a tablet terminal, or a smartphone.
  • the inspector apparatus 14, and the viewer apparatus 16 a library and an application (hereinafter also referred to as “inspection App”) for forming and using the block chain network 22 are introduced.
  • the client device 12, the inspector device 14, and the viewer device 16 execute P2P (Peer to Peer) communication based on a known block chain mechanism to form the block chain network 22.
  • P2P Peer to Peer
  • the client device 12 in the examination of the test file A may become the examiner apparatus 14 or the viewer apparatus 16 in another examination of the test file B.
  • the inspector device 14 in the examination of the test file C may become the client device 12 or the viewer device 16 in another examination of the test file D.
  • the requester and the viewer may be the same, that is, the requester device 12 and the viewer device 16 may be the same.
  • the client device 12, the inspector device 14, and the viewer device 16 of FIG. 1 are collectively referred to as “user device 24”.
  • the file server 18 is an information processing apparatus that registers a test file from the client apparatus 12 and provides the registered test file to the inspector apparatus 14.
  • the above inspection App is not introduced into the file server 18. That is, the file server 18 is a device that does not participate in the block chain network 22, in other words, a device that exists outside the block chain network 22.
  • the file server 18 may be composed of a plurality of servers.
  • each block shown in the block diagram of the present specification can be realized in terms of hardware by an element such as a CPU / memory of a computer or a mechanical device, and in terms of software, it can be realized by a computer program or the like. Then, the functional block realized by those cooperation is drawn. Those skilled in the art will understand that these functional blocks can be realized in various forms by a combination of hardware and software.
  • FIG. 2 is a block diagram showing a functional configuration of the file server 18 of FIG.
  • the file server 18 includes a test data holding unit 30, a test data receiving unit 32, and a test data providing unit 34.
  • the test data holding unit 30 stores the test data in association with an address (for example, a URL character string, also referred to as “test file address”) indicating the storage position.
  • an address for example, a URL character string, also referred to as “test file address”
  • the test data receiving unit 32 receives a test file registration request from the requester apparatus 12.
  • the test data receiving unit 32 stores the test file included in the registration request in the test data holding unit 30.
  • the test data receiving unit 32 transmits the test file address to the requester apparatus 12 as a response to the registration request.
  • the test data providing unit 34 receives a test file provision request from the inspector device 14.
  • the test file provision request includes designation of an address (test file address) indicating a specific test file.
  • the test data providing unit 34 transmits the test file specified by the designated test file address among the plurality of test files stored in the test data holding unit 30 to the inspector device 14.
  • FIG. 3 is a block diagram showing a functional configuration of the user device 24 of FIG. 1 (that is, the requester device 12, the inspector device 14, and the viewer device 16).
  • the user device 24 includes an input unit 40, a display unit 42, and a control unit 44.
  • the input unit 40 receives a user operation and inputs the operation content to the control unit 44.
  • the display unit 42 displays the image data output from the control unit 44 on the screen.
  • the control unit 44 executes various data processing, and includes a request processing unit 46, an inspection processing unit 48, and a browsing processing unit 50.
  • the functions of these blocks may be realized by the CPU of the user device 24 executing the inspection App 52 stored in the memory of the user device 24.
  • Each of the request processing unit 46, the inspection processing unit 48, and the browsing processing unit 50 includes a plurality of modules as will be described later, but all or some of the modules are different from the file server 18 or the file server 18. The configuration may be implemented on a new server.
  • the request processing unit 46 mainly executes processing in the requester apparatus 12.
  • the request processing unit 46 includes a test data registration unit 54, an SC generation unit 56, and an index update unit 58.
  • the test data registration unit 54 registers the test file in the file server 18 by transmitting the test file to the file server 18.
  • the test data registration unit 54 acquires a test file address (for example, a URL character string) indicating a storage position in the file server 18 from the file server 18 when registering the test file.
  • a test file address for example, a URL character string
  • the SC generation unit 56 generates a smart contract including attribute information regarding the test file registered in the file server 18 by the test data registration unit 54.
  • a smart contract can be said to be an agent program that runs on a blockchain. This smart contract is, for example, an instance of a “VirusContract” class described later, and is hereinafter referred to as “VC” in the meaning of the virus contract.
  • the attribute information regarding the test file includes a test file address in the file server 18.
  • the SC generation unit 56 registers the generated VC in the block chain network 22. In other words, the generated VC is added to the data of the blockchain network 22 (also referred to as ledger data).
  • the index update unit 58 acquires from the block chain network 22 a smart contract including a plurality of VC addresses (that is, position information on the block chain network 22).
  • This smart contract is an instance of an “IndexContract” class, which will be described later, and is hereinafter referred to as “IC” in the meaning of the index contract.
  • the index update unit 58 adds the address of the VC generated by the SC generation unit 56 and the identification information (a hash value in the embodiment) of the test file to the acquired IC.
  • the inspection processing unit 48 mainly executes processing in the inspector apparatus 14.
  • the inspection processing unit 48 includes an index acquisition unit 60, an SC acquisition unit 62, a test data acquisition unit 64, and an SC update unit 66.
  • the index acquisition unit 60 acquires an IC from the block chain network 22.
  • the SC acquisition unit 62 acquires the address of the VC associated with the identification information (in the embodiment, the hash value of the test file) of the test file designated by the examiner from the IC.
  • the SC acquisition unit 62 acquires the VC specified by the address from the block chain network 22.
  • the test data acquisition unit 64 acquires a test file address from the VC.
  • the test data acquisition unit 64 accesses the file server 18 and downloads the test file specified by the test file address from the file server 18.
  • the SC update unit 66 records the inspection result in the VC of the test file after the test file is inspected by the inspector.
  • the SC update unit 66 registers the VC of the test file after the inspection result is recorded in the block chain network 22.
  • the SC update unit 66 reflects the inspection result by the inspector in the VC of the test file stored on the block chain network 22.
  • the browsing processing unit 50 includes an index acquisition unit 68, an SC acquisition unit 70, an inspection result acquisition unit 72, a remittance unit 74, and an inspection result output unit 76.
  • the index acquisition unit 68 acquires an IC from the block chain network 22.
  • the SC acquisition unit 70 acquires the address of the VC associated with the identification information (in the embodiment, the hash value of the test file) specified by the viewer from the IC.
  • the SC acquisition unit 70 acquires the VC specified by the address from the block chain network 22.
  • the inspection result acquisition unit 72 acquires the inspection result of the test file from the VC acquired by the SC acquisition unit 70. In other words, the inspection result acquisition unit 72 acquires the inspection result of the test file stored on the block chain network 22.
  • the remittance unit 74 performs remuneration payment to both the inspector and the client in synchronization with the timing at which the inspection result is acquired. For example, the remittance unit 74 may execute remittance (transfer) processing from the browser account to the inspector's account, and may execute remittance processing from the viewer account to the client account.
  • the inspection result acquisition unit 72 may acquire the inspection result of the test file on the condition that the remittance process by the remittance unit 74 has been successful.
  • the remittance unit 74 records information on remittance from the viewer to the client and remittance from the viewer to the inspector in the ledger data of the block chain network 22 (or other block chain for money exchange). May be. Thereby, the certainty of remuneration payment can be improved and tampering of the payment amount can be prevented.
  • the inspection result output unit 76 outputs the inspection result data acquired by the inspection result acquisition unit 72 to the display unit 42 and causes the display unit 42 to display the inspection result.
  • the inspection App 52 including the request processing unit 46, the inspection processing unit 48, and the browsing processing unit 50 is introduced into the requester device 12, the inspector device 14, and the viewer device 16.
  • an examination App including only the function of the request processing unit 46 may be introduced into the client apparatus 12.
  • an inspection App including only the function of the inspection processing unit 48 may be introduced into the inspector device 14, and an inspection App including only the function of the browsing processing unit 50 may be introduced into the viewer device 16.
  • FIG. 4A and 4B show VC conceptual program code (VirusContract.java) ("java” is a registered trademark).
  • FIG. 4B shows a continuation of FIG.
  • FIG. 5 shows a conceptual program code (IndexContract.java) of the IC.
  • FIG. 6 shows a conceptual program code (FlowTest.java) of a test App52 using VC and IC.
  • FIG. 7 is a flowchart showing the operation of the client apparatus 12.
  • the test data registration unit 54 of the requester apparatus 12 registers the test file in the file server 18.
  • the test data registration unit 54 acquires the test file address in the file server 18 from the file server 18 (S12).
  • the test data registration unit 54 passes the test file and the test file address to the SC generation unit 56.
  • the SC generation unit 56 uses the address of the requester apparatus 12 on the block chain network 22, the test file address, and the hash value of the test file as parameters, and the smart contract for the test file ( Hereinafter, “VC”) is generated (S14).
  • the hash function used for generating the hash value may be, for example, MD5.
  • the SC generation unit 56 further registers the generated VC instance in the block chain network 22 and acquires the address of the VC instance on the block chain network 22.
  • the index update unit 58 acquires an index smart contract (hereinafter referred to as “IC”) as indicated by a code 82 in FIG. Actually, the index update unit 58 calls the API of the block chain network 22 and acquires the IC registered in the block chain network 22. The index updating unit 58 adds the hash value (key) of the test file and the address (value) of the VC to the address map (addressMap in FIG. 5) of the acquired IC (S16). If an operation for designating a test file is not input (N in S10), S12 to S16 are skipped, and the flow of this figure is terminated.
  • IC index smart contract
  • FIG. 8 is a flowchart showing the operation of the inspector apparatus 14.
  • the index acquisition unit 60 of the inspector device 14 acquires an IC registered in the block chain network 22 (S22). .
  • the inspector specifies the hash value of the test file to be acquired.
  • the SC acquisition unit 62 acquires the VC address of the test file from the IC using the hash value of the test file as a key, as indicated by a code 84 in FIG. Then, the SC acquisition unit 62 acquires the VC of the test file registered in the block chain network 22 using the VC address as a key (S24).
  • the test data acquisition unit 64 acquires the test file address in the file server 18 from the VC as indicated by a code 86 in FIG. Then, the test data acquisition unit 64 acquires a test file from the file server 18 using the test file address as a key (S26). If an operation requesting acquisition of the test file is not input (N in S20), S22 to S26 are skipped.
  • the inspector who has acquired the test file uses the inspector device 14 or another device to inspect whether the test file is illegal (for example, whether malware is included). For example, the inspector may perform the inspection using existing anti-virus software. The examiner may manually analyze the binary of the test file.
  • the inspector inputs inspection result information including a determination result, additional information, and an inspection method.
  • the SC update unit 66 When the inspector requests registration of the inspection result for the test file (Y in S28), the SC update unit 66, on the block chain network 22, as indicated by the code 88 in FIG. 6 and the code 90 in FIG. The address of the inspector and the inspection result information are added to the VC of the test file (S30). Although not shown in the code 88, the SC update unit 66 further registers the VC to which the inspection result information is added in the block chain network 22. If an operation requesting registration of the inspection result is not input (N in S28), S30 is skipped and the flow of this figure is ended.
  • FIG. 9 is a flowchart showing the operation of the viewer device 16.
  • the index acquisition unit 68 of the viewer device 16 acquires the IC registered in the block chain network 22.
  • the examiner specifies the hash value of the test file to be examined.
  • the SC acquisition unit 62 acquires the VC address of the test file from the IC using the hash value of the test file as a key, as indicated by a code 92 in FIG. Then, the SC acquisition unit 62 acquires the VC of the test file registered in the block chain network 22 using the VC address as a key (S44).
  • the test result acquisition unit 72 acquires a list of inspectors who registered the test results for the test file, and the test result output unit 76 displays the list of inspectors on the display unit 42. (S46). Wait until the viewer selects a specific inspector to display the inspection result (N in S48). When the viewer selects a specific inspector (Y in S48), the inspection result acquisition unit 72 acquires the inspection result by the selected inspector (S50). Specifically, as shown in the code 96 in FIG. 6 and the code 98 in FIG. 4A, the test result acquisition unit 72 specifies the address of the viewer and the address of the selected tester as parameters, An inspection result associated with the inspector's address is acquired.
  • the remittance unit 74 executes remittance processing from the viewer to the requester and remittance processing from the viewer to the inspector as indicated by a code 98 in FIG. Further, in the embodiment, the remittance unit 74 executes remittance processing from the viewer to the administrator of the inspection system 10 (S52). That is, a reward is paid to the three parties of the requester, the inspector, and the manager when the viewer browses the inspection result.
  • the inspection result output unit 76 causes the display unit 42 to display the inspection result acquired by the inspection result acquisition unit 72, as indicated by the code 100 in FIG. 6 (S54). If the test file to be examined is not selected (N in S40), S42 to S54 are skipped, and the flow of this figure is ended.
  • the operation of the inspection system 10 relating to the inspection of one test file is a flow of registration of the test file, inspection of the test file, and inspection result inspection. Therefore, in the examination of one test file, the process of FIG. 7 by the client apparatus 12, the process of FIG. 8 by the examiner apparatus 14, and the process of FIG. 9 by the viewer apparatus 16 are sequentially executed. In the actual inspection system 10, processes for a plurality of test files are executed in parallel.
  • the requester device 12, the inspector device 14, and the viewer device 16 always execute synchronization processing of data (VC, IC, etc.) in the block chain network 22.
  • one or more inspectors on the network inspect the validity of the electronic data uploaded by the client, and viewers (including the client) can check the inspection results. Become. This makes it possible to improve the accuracy of malware detection with the cooperation of other users for the detection of malware that is difficult to say with anti-virus software alone.
  • the attribute information and inspection results of the test file are transmitted / received via the block chain network 22.
  • the test file itself having a relatively large data size can be transmitted / received outside the block chain network 22, thereby suppressing the load on the block chain network 22.
  • the inspection system 10 when the viewer browses the inspection result, a reward is paid to the client and the inspector.
  • inspection of a test file can be provided.
  • the viewer can specify the inspection result to be viewed in units of the inspector. That is, the viewer can selectively browse the inspection result by a desired inspector such as an inspector with high accuracy of the inspection result, a reliable inspector, or the like. Thereby, the payee of the reward is limited to the inspector selected by the viewer, and an incentive for registering an accurate inspection result can be provided to the inspector.
  • test file is managed by the file server 18, while various attribute information (address, test result, etc.) relating to the test file is formed by the client device 12, the tester device 14, and the viewer device 16.
  • attribute information address, test result, etc.
  • the chain network 22 Managed by the chain network 22.
  • both a test file and attribute information related to the test file may be centrally managed by a single device (referred to herein as an “examination support device”).
  • the inspection support apparatus may have both the function of the file server 18 of the embodiment and the function of the block chain network 22 of the embodiment.
  • the test support apparatus includes the test result holding unit, the test result receiving unit, the test result in addition to the test data holding unit 30, the test data receiving unit 32, and the test data providing unit 34 in the file server 18 of the embodiment. You may provide a provision part.
  • the inspection result holding unit may store the inspection result in association with the test data (for example, the test data address).
  • the inspection result reception unit may receive information indicating the inspection result for the test file transmitted from the inspector device 14 and store the information in the inspection result holding unit.
  • the test result providing unit may provide the browser device 16 with a test result corresponding to the test file specified by the viewer device 16 among the test results stored in the test result holding unit.
  • the requester device 12, the inspector device 14, and the viewer device 16 may be devices that automatically execute the process for examining the test file without depending on a human operation. For example, when the client device 12 detects the presence of an electronic file whose validity is difficult to determine, the client device 12 uploads the electronic file to the file server 18 as a test file, generates an SC of the test file, and further updates the IC. You may perform the process to perform automatically.
  • the client device 12 of the second modification may be an e-mail server, and the test file may be an attached file to the e-mail.
  • the e-mail server may upload an attached file whose abnormality is not detected by local anti-virus software to the file server 18 as a test file.
  • the e-mail server uploads to the file server 18 an attached file whose file type, size, name, etc. deviates from a predetermined standard (white list, etc.), although no abnormality is detected by the local anti-virus software. May be.
  • the viewer device 16 of the second modification may delete the test file according to the test result instead of displaying the test result of the test file.
  • the viewer device 16 may stop the predetermined data processing based on the test file.
  • the viewer device 16 may be an e-mail server.
  • the e-mail server may stop transferring the e-mail attached with the test file or discard the e-mail.
  • FIG. 10 shows the configuration of the inspection system of the third modification.
  • the test file is registered in the file server 18.
  • the inspection system 10 does not include the file server 18, and the test file is registered in the P2P network 26 (dashed line in FIG. 10) different from the block chain network 22 (broken line in FIG. 10).
  • a known library and application (hereinafter also referred to as “P2P module”) for exchanging the test file by P2P communication may be introduced into each of the user devices 24 of the third modification.
  • the test data registration unit 54 of the user device 24 (in other words, the client device 12) may register the test file (or the test file and its hash value) in the P2P network 26 using the P2P module (FIG. 7). S12).
  • the test data registration unit 54 may transmit a test file to each of the other user devices 24.
  • test data acquisition unit 64 of the user device 24 may acquire the test file registered in the P2P network 26 using the P2P module (S26 in FIG. 8).
  • the test data acquisition unit 64 may acquire the test file corresponding to the hash value from the storage in the P2P network 26 using the hash value of the test file acquired from the block chain network 22 as a key.
  • another user device 24 may acquire or refer to the test file registered in the local storage of a certain user device 24 (requester device 12).
  • the test file can be exchanged between different user devices 24 without providing the file server 18.
  • test system that supports the test of electronic data (hereinafter also referred to as “specimen”) is proposed using block chain technology.
  • the sample of the second example corresponds to the test file of the first example.
  • the specimen is an electronic file suspected of having malware or an electronic file whose safety is to be confirmed, but may be various electronic data to be inspected.
  • the same elements as those described in the first embodiment will be described with the same reference numerals. Further, the description already described in the first embodiment will be omitted as appropriate.
  • FIG. 11 shows the configuration of the inspection system 101 of the second embodiment.
  • the inspection system 101 includes a client apparatus 12, an inspector apparatus 14a, an inspector apparatus 14b, an inspector apparatus 14c, a viewer apparatus 16, a file server 18, and a portal server 102. These devices are connected via the communication network 20.
  • the inspector device 14a, the inspector device 14b, and the inspector device 14c are information processing devices operated by different inspectors.
  • the portal server 102 is a web application server that provides various information related to the inspection system 101 to the requester device 12, the inspector device 14, and the viewer device 16.
  • the inspection system 101 includes a block chain system 104 corresponding to the block chain network 22 of the first embodiment.
  • the client device 12, the inspector device 14, and the viewer device 16 are installed with libraries and applications for forming and using the blockchain system 104.
  • the block chain system 104 is also called a distributed database system (distributed ledger system), and is built on Ethereum, which is one of the block chain platforms.
  • the block chain system 104 includes three smart contract programs, a virus SC 106, a token SC 108, and an actor SC 110. These smart contracts can be accessed from the client device 12, the examiner device 14, the viewer device 16, and the portal server 102, and are synchronized between these devices.
  • the virus SC 106 is a smart contract that executes data storage and data processing related to specimen testing.
  • the token SC 108 is a smart contract that executes data storage and data processing related to a token that is a virtual currency in the inspection system 101.
  • the actor SC110 is a smart contract that executes data storage and data processing regarding actors (mainly requesters and inspectors) of the inspection system 101.
  • one client device 12 and one viewer device 16 are drawn.
  • the inspection system 101 may include a plurality of client devices 12 of different clients and a plurality of browser devices 16 of different viewers. Good.
  • one user can participate in the inspection system 101 from any position of a client, an inspector, and a viewer.
  • one information processing apparatus may function as the client apparatus 12, the inspector apparatus 14, and the viewer apparatus 16.
  • each apparatus is performed by one application program as described in the first embodiment (FIG. 3). May be provided. Further, the function of each device may be exhibited by each device executing a web application program provided by a predetermined web server (for example, portal server 102).
  • a predetermined web server for example, portal server 1012.
  • FIG. 12 is a block diagram showing functional blocks of the requester apparatus 12 of FIG.
  • the client apparatus 12 includes an input unit 40, a display unit 42, a control unit 44, and a communication unit 112.
  • the communication unit 112 communicates with an external device according to a predetermined communication protocol.
  • the control unit 44 transmits / receives data to / from the file server 18 and the portal server 102 via the communication unit 112.
  • the control unit 44 includes a sample search unit 120, a sample registration unit 122, an examination request unit 124, a report acquisition unit 126, a nonce registration unit 128, and a result commit unit 130.
  • the specimen search unit 120 acquires information on one or more specimens during and after the examination from the portal server 102.
  • the sample registration unit 122 registers the sample to be examined in the file server 18.
  • the examination request unit 124 registers a specimen examination request in the block chain system 104. For example, the inspection request unit 124 records the inspection reward in the block chain system 104.
  • the report acquisition unit 126 acquires an evaluation report indicating the evaluation result of the specimen by the examiner from the file server 18.
  • the report acquisition unit 126 acquires a plurality of evaluation reports created by the plurality of examiners from the file server 18.
  • the result of the evaluation by the examiner is at least “white” indicating that the sample is valid (eg, not malware) and “black” indicating that the sample is invalid (eg, malware). "Is included.
  • the evaluation report created by the inspector includes a step-wise score indicating the degree of confidence of the inspector with respect to the evaluation result (the inspector himself evaluates the accuracy that the evaluation result is correct) May be included. For example, “white; 80%” indicates that the examiner determines that the specimen is valid, and the examiner thinks that the accuracy is 80%.
  • the degree of confidence of the inspector with respect to the evaluation result may be the above-described stepwise score, or may be a stepwise evaluation such as “confident”, “somewhat confident”, “no confident”.
  • the nonce registration unit 128 registers a nonce (in other words, a random number) generated by a predetermined random number generator (hereinafter also referred to as “result nonce”) in the portal server 102.
  • the result commit unit 130 executes result commit processing in cooperation with the virus SC 106.
  • the result commit unit 130 may call a result commit processing method implemented in the virus SC 106.
  • calling the smart contract method may be replaced by issuing a transaction to the smart contract by another known method.
  • FIG. 13 is a block diagram showing functional blocks of the inspector apparatus 14 of FIG.
  • the control unit 44 of the inspector apparatus 14 includes a request search unit 140, a sample acquisition unit 142, a sample collation unit 144, a report registration unit 146, an evaluation commit unit 148, a nonce acquisition unit 150, a result confirmation unit 152, and a final commit unit 154. Prepare.
  • the request search unit 140 acquires information on one or more registered inspection requests from the portal server 102.
  • the sample acquisition unit 142 acquires the sample selected by the examiner from the file server 18.
  • the sample collation unit 144 confirms the validity of the sample acquired by the sample acquisition unit 142 (in other words, there is no falsification) by comparing the hash values.
  • the report registration unit 146 registers in the file server 18 an evaluation report created by the examiner examining the specimen.
  • the evaluation commit unit 148 executes an evaluation commit process in cooperation with the virus SC 106.
  • the result commit unit 130 may call an evaluation commit method implemented in the virus SC 106.
  • the nonce acquisition unit 150 acquires the result nonce registered in the portal server 102.
  • the result confirmation unit 152 determines whether the client finally determines that the sample is valid (“white”) or illegal (“black”) (hereinafter also referred to as “black and white determination result”). Execute the process to confirm.
  • the final commit unit 154 executes final commit processing in cooperation with the virus SC 106. For example, the final commit unit 154 may call a final commit method implemented in the virus SC 106.
  • FIG. 14 is a block diagram showing functional blocks of the viewer device 16 of FIG.
  • the control unit 44 of the browser device 16 includes a sample search unit 160, a browsing execution unit 162, and a requester evaluation unit 164.
  • the specimen search unit 160 acquires information on one or more specimens during and after the examination from the portal server 102.
  • the browsing execution unit 162 executes processing for browsing the test result of the sample selected by the viewer in cooperation with the virus SC 106.
  • the requester evaluation unit 164 executes processing for evaluating the requester in cooperation with the virus SC 106. For example, the requester evaluation unit 164 may call a method for browsing processing implemented in the virus SC 106.
  • FIG. 15 is a block diagram showing functional blocks of the block chain system 104 of FIG. As described above, the block chain system 104 includes the virus SC 106, the token SC 108, and the actor SC 110.
  • the token SC 108 includes a user account holding unit 170, a request account holding unit 172, an organizer account holding unit 174, and a browsing account holding unit 175.
  • the user account holding unit 170 includes information on an account (requester account) held by the client, information on a plurality of accounts (tester account) held by a plurality of examiners, and an account (viewer account) held by a viewer. The information is memorized.
  • each user has a token that is a virtual currency determined by the inspection system 101.
  • the balance of tokens held by each user is recorded.
  • Each user's account is identified by each user's address.
  • the request account holding unit 172 stores information on a plurality of accounts (inspection request accounts) corresponding to a plurality of inspection requests.
  • the examination request account is identified by the hash value of the specimen to be examined.
  • a new inspection request account is opened each time a new inspection request is registered.
  • the organizer account holding unit 174 stores information on an account held by the organizer of the inspection system 101.
  • the organizer is a company that provides the file server 18, the portal server 102, and the block chain system 104.
  • the browsing account holding part 175 memorize
  • the browsing account is identified by the browser address.
  • Actor SC110 includes a score holding unit 176.
  • the score holding unit 176 stores the client's score and the scores of each of the plurality of examiners.
  • the client score is changed according to the evaluation result of the client by the viewer, and affects the amount of the commission to the organizer who pays when registering the inspection request. Specifically, the lower the client's score, the higher the fee.
  • the inspector score is changed according to whether or not the evaluation result of the inspector is correct (in the embodiment, whether or not the answer is correct by the client), and affects the reward distribution rate. Specifically, the examiner with a relatively high score has a relatively high distribution rate.
  • the actor SC110 may include a transaction history holding unit (not shown).
  • the transaction history holding unit checks the number of requests registered by the client, the number of paid payments, the number of unpaid rewards, the total amount of registration fees, etc., the number of registered evaluation reports, the number of correct answers, the number of incorrect answers, and the evaluation results.
  • the average value of the stepwise score indicating the degree of confidence of the person, the accumulated amount of rewards obtained, the number of times of browsing, etc. are stored and updated according to the processing in this inspection system.
  • the client's score and the examiner's score may be calculated and updated based on the values stored in the transaction history holding unit.
  • the virus SC 106 includes a test information holding unit 178, a request processing unit 180, an evaluation commit processing unit 182, a result commit processing unit 184, a final commit processing unit 186, a browsing processing unit 192, and a requester evaluation processing unit 194.
  • the inspection information holding unit 178 stores inspection information generated for each inspection request from the client.
  • the examination information includes a plurality of items relating to examination requests or specimens.
  • FIG. 16 shows an example of inspection information.
  • the hash value of the specimen is a key for each examination information.
  • the requester setting item 200 and the requester setting item 202 are information items set by the requester device 12 that has registered the examination request for the sample ⁇ .
  • the inspector setting item 204 and the inspector setting item 206 are items set by the plurality of inspector apparatuses 14 that have evaluated the sample ⁇ .
  • the user address is unique data (ID) for each user to be paid out when the user registers an account in the inspection system 101.
  • ID unique data
  • the request processing unit 180 executes processing at the time of the inspection request in response to the call from the requester apparatus 12.
  • the evaluation commit processing unit 182 executes processing at the time of evaluation commit in response to a call from the inspector device 14.
  • the result commit processing unit 184 executes processing at the time of result commit in response to the call from the requester apparatus 12.
  • the final commit processing unit 186 executes processing at the time of final commit in response to a call from the inspector device 14.
  • the final commit processing unit 186 includes an inspector evaluation unit 188 and a token transfer unit 190.
  • the inspector evaluation unit 188 adjusts the inspector's score stored in the score holding unit 176 of the actor SC110.
  • the token transfer unit 190 executes token transfer between accounts stored in the token SC108.
  • the browsing processing unit 192 executes processing during browsing in response to a call from the browser device 16.
  • the requester evaluation processing unit 194 executes processing at the time of requester evaluation in response to a call from the browser device 16.
  • FIG. 17 is a flowchart showing an operation related to an inspection request.
  • the sample search unit 120 of the requester apparatus 12 transmits a sample search request using the hash value of the sample of the examination candidate specified by the requester as a key to the portal server 102 (S100).
  • the portal server 102 searches the examination information stored in the virus SC 106 using the hash value specified in the search request as a key.
  • the portal server 102 transmits a search result indicating whether there is a sample corresponding to the hash value (that is, being examined or completed) or not (that is, not yet examined) to the inspector device 14 (S102).
  • the requester apparatus 12 displays the search result on the screen.
  • the requester inputs an operation for instructing an inspection request for the sample to the requester apparatus 12 if the sample of the inspection candidate has not been tested.
  • the specimen registration unit 122 of the requester apparatus 12 transmits a registration request including the specimen data to the file server 18 (S104).
  • the file server 18 stores the sample data transmitted from the client apparatus 12 in a predetermined storage area (S106).
  • the file server 18 issues a sample URI (Uniform Resource Identifier) that is a unique ID in the file server 18 to the stored sample, and transmits the sample URI to the requester apparatus 12 (S108).
  • the sample registration unit 122 of the requester apparatus 12 acquires the sample URI transmitted from the file server 18.
  • the examination request unit 124 of the requester apparatus 12 calls the examination request method of the virus SC 106 using a plurality of attribute data relating to the specimen as parameters (S110).
  • the plurality of attribute data related to the sample includes a sample hash value, a requester address, a sample URI, a test deadline, and a reward amount (that is, a token amount).
  • the client arbitrarily determines the inspection deadline and the remuneration amount.
  • the request processing unit 180 of the virus SC 106 records the inspection information (requester setting item 200) including the plurality of attribute data in the inspection information holding unit 178 (S112). At this time, the status of the inspection information is set during the inspection.
  • the request processing unit 180 of the virus SC 106 records the account information (inspection request account) corresponding to the current inspection request in the request account holding unit 172 of the token SC 108.
  • the request processing unit 180 transfers the token of the reward amount, the token of the fee to the organizer, and the token of the deposit of the client from the client account of the token SC 108 to the inspection request account (S114).
  • the virus SC 106 may cause the token SC 108 to execute token transfer processing by an external call.
  • the token SC 108 determines the amount of the fee to the organizer according to the client score stored in the actor SC 110. In the embodiment, the higher the client score, the lower the fee, and the lower the client score, the higher the fee. This gives the client an incentive to increase the client score.
  • FIG. 18 is a flowchart showing an operation related to the execution of the inspection.
  • the process of FIG. 18 is executed by each of the plurality of inspector apparatuses 14.
  • the request search unit 140 of the inspector apparatus 14 transmits an inspection request search request to the portal server 102 (S120).
  • the portal server 102 refers to the inspection information of the virus SC 106 and transmits information related to the inspection request whose status is under inspection to the inspector apparatus 14 as a search result (S122).
  • the information related to the test request includes the sample hash value, the deadline, the reward, the number of evaluation completed testers (the number of testers recorded in the test information), the sample URI included in the test information of the virus SC 106, and is further recorded in the actor SC110. And the score of the inspector who has completed the evaluation.
  • the inspector device 14 displays the search result on the screen.
  • the examiner confirms the search result and determines the sample to be examined (hereinafter referred to as “target sample”).
  • the sample acquisition unit 142 of the inspector apparatus 14 downloads the target sample from the file server 18 based on the sample URI of the target sample (S124).
  • the file server 18 transmits the data of the target specimen to the examiner device 14 (S126).
  • the sample collation unit 144 of the inspector apparatus 14 acquires the hash value of the target sample data acquired from the file server 18 and confirms the identity with the hash value of the target sample acquired from the portal server 102 (S128). As a result, it is confirmed that the data of the target specimen acquired from the file server 18 has not been falsified, that is, the original data.
  • the inspector examines whether or not the target sample is malware, and creates an evaluation report including at least data indicating whether the target sample is malware (“black”) or not (“white”).
  • the report registration unit 146 of the inspector apparatus 14 encrypts the evaluation report with the requester's public key (S130).
  • the report registration unit 146 uploads the evaluation report to the file server 18 (S132).
  • the file server 18 stores the evaluation report data transmitted from the inspector device 14 in a predetermined storage area (S134).
  • the file server 18 issues a report URI that is a unique ID in the file server 18 to the stored evaluation report, and transmits the report URI to the inspector device 14 (S136).
  • the report registration unit 146 of the inspector device 14 acquires a report URI.
  • the evaluation commit unit 148 of the inspector device 14 acquires a nonce generated by a predetermined random number generator (S138).
  • the evaluation commit unit 148 calls the evaluation commit method of the virus SC 106 using a plurality of attribute data related to the evaluation as parameters (S140).
  • a plurality of attribute data related to evaluation includes a hash value of the evaluation report, a hash value of data obtained by combining a value indicating whether the target specimen is “white” or “black” and a nonce (also referred to as “evaluation hash value”), a report URI. including.
  • the evaluation commit processing unit 182 of the virus SC 106 updates the inspection information based on the plurality of attribute data, and records, for example, the inspector setting item 204 or the inspector setting item 206 (S142). At this time, the final commit flag of the inspector setting item is set to “uncommitted”. Further, the evaluation commit processing unit 182 of the virus SC 106 transfers a predetermined amount of token from the inspector account of the token SC 108 to the inspection request account as the inspector's deposit (S144).
  • FIG. 19 is a flowchart showing an operation related to the result determination of the client.
  • the report acquisition unit 126 of the requester apparatus 12 refers to the test information of the virus SC 106 and acquires the report URI associated with the sample (sample hash value) requested for the test. .
  • the report acquisition unit 126 requests an evaluation report specified by the report URI from the file server 18 (S150).
  • the file server 18 transmits the evaluation report data requested from the client apparatus 12 to the client apparatus 12 (S152).
  • the report acquisition unit 126 of the requester apparatus 12 decrypts the evaluation report with the requester's private key (S154).
  • the report acquisition unit 126 inputs the decrypted evaluation report data to the hash function to acquire a hash value, and acquires the hash value of the evaluation report recorded in the inspection information of the virus SC 106.
  • the report acquisition unit 126 confirms the identity of both hash values (S156). This confirms that the evaluation report has not been tampered with.
  • the requester apparatus 12 repeats the processing of S150 to S156 by the number of examiners who have evaluated the sample, in other words, the number of evaluation reports for the sample.
  • the client confirms the contents of one or more evaluation reports from one or more examiners, and comprehensively determines whether or not the specimen to be examined is malware (ie, black or white). Hereinafter, this determination is also referred to as “monochrome determination”.
  • the requester inputs an operation for instructing the result commit for registering the result of the black and white determination to the inspector device 14.
  • the nonce registration unit 128 of the inspector 14 generates a result nonce to be added to the result of the black and white determination (S158), and transmits the sample hash value and the result nonce to the portal server 102 (S160).
  • the portal server 102 stores the sample hash value and the result nonce in association with each other (S162).
  • the result commit unit 130 of the requester apparatus 12 calls the result commit method of the virus SC 106 using a plurality of attribute data related to the black and white determination result as parameters (S164).
  • the plurality of attribute data related to the black and white determination result includes a hash value of data obtained by combining a value indicating whether the specimen is “white” or “black” and the result nonce (hereinafter also referred to as “result hash value”), and the correct person's address. And a viewing fee for viewing the black and white determination result.
  • the correct answerer is an inspector whose evaluation result is recognized as a correct answer by the client, in other words, an inspector who gave the same evaluation as the monochrome determination of the client.
  • the browsing fee is arbitrarily determined by the client.
  • the result commit processing unit 184 of the virus SC 106 updates the examination information based on the plurality of attribute data, and records the requester setting item 202 of FIG. 16, for example (S166).
  • FIG. 20 is a flowchart showing an operation related to the final commit by the inspector. It can be said that the final commit is the approval of the requester's black and white determination result.
  • the nonce acquisition unit 150 of the inspector apparatus 14 requests the result nonce from the portal server 102 using the hash value of the sample evaluated by the inspector as a key (S170).
  • the portal server 102 permits the provision of the result nonce if the inspector who requested the result nonce is recorded in the inspection information of the virus SC 106 using the sample hash value as a key, that is, if it is a valid inspector. (S172).
  • the portal server 102 transmits the result nonce to the inspector device 14 of a valid inspector (S174).
  • the nonce acquisition unit 150 of the inspector device 14 acquires the result nonce.
  • the result confirmation unit 152 of the inspector device 14 acquires a result hash value from the inspection information of the virus SC 106.
  • the result confirmation unit 152 includes a hash value of data obtained by combining the result nonce with a predetermined “white” value, a hash value of data obtained by combining the result nonce with a predetermined “black” value, and a result hash By comparing the value, it is determined whether the monochrome determination result of the client is “white” or “black” (S176). That is, the result confirmation unit 152 identifies that the requester has determined “white” when the hash value of the data obtained by combining the result nonce with the predetermined “white” value matches the result hash value. In addition, when the hash value of the data obtained by combining the result nonce with the predetermined “black” value matches the result hash value, the result confirmation unit 152 identifies that the requester has determined “black”.
  • the result confirmation unit 152 may display on the screen whether the client has determined that the sample is valid (“white”) or malware (“black”).
  • the result confirming unit 152 acquires the correct answerer address array from the virus SC 106 test information and displays it on the screen.
  • the result confirmation unit 152 may display on the screen whether or not the address of the inspector of the inspector device 14 is included in the array of correct answerer addresses.
  • the inspector confirms that his / her address is included in the array of correct answerer addresses when the black and white determination result of the client is the same as his / her evaluation result, that is, when he / she is the correct answerer.
  • the inspector inputs an operation to instruct the final commit to the inspector device 14.
  • the final commit unit 154 of the inspector apparatus 14 calls the final commit method of the virus SC 106 using parameters including the sample hash value and the inspector address (S178).
  • the final commit processing unit 186 of the virus SC 106 updates the inspection information based on the parameters transmitted from the inspector device 14 (S180). For example, the final commit processing unit 186 changes the final commit flag of the inspector setting item to “committed”.
  • the inspector evaluation unit 188 of the final commit processing unit 186 refers to the correct answerer address of the inspection information, and determines whether the inspector who made the final commit (also referred to as “target inspector”) is the correct answerer.
  • the score of the subject examiner is adjusted (S182). For example, when the target inspector is a correct answerer, the inspector evaluation unit 188 changes the score of the target inspector recorded in the actor SC 110 to a larger value than before. If the target inspector is not the correct answerer, the inspector evaluation unit 188 changes the score of the target inspector to a smaller value than before.
  • the virus SC 106 may update the score recorded in the actor SC 110 by an external call.
  • the token transfer unit 190 of the final commit processing unit 186 transfers the inspector's deposit recorded in the inspection request account to the inspector's account based on the inspector address transmitted from the inspector device 14 (S184). ). In other words, the token transfer unit 190 returns the token deposited from the inspector at the time of registering the evaluation report to the inspector's account at the time of final commit.
  • the token transfer unit 190 when there is a plurality of examiners for one specimen, the token transfer unit 190 at the time of the last commit by the last examiner, if there is one examiner, at the time of the last commit by the one examiner Further, the following processing is executed. (1) The token transfer unit 190 distributes a reward to an inspector who is recognized as a correct answerer. In this case, the token transfer unit 190 refers to the actor SC110, refers to the score of each correct answerer, and assigns a relatively large reward to an inspector with a relatively high score. (2) The token transfer unit 190 transfers the fee recorded in the inspection request account to the host account.
  • the token transfer unit 190 transfers the requester's deposit recorded in the inspection request account to the requester's account. In other words, the token transfer unit 190 returns the token deposited from the client at the time of the inspection request to the client's account. Further, the final commit processing unit 186 updates the status in the requester setting item to “inspection completed”. Note that the final commit processing unit 186 determines that all examiners of the sample are final when the final commit flags in one or more examiner setting items recorded in the examination information of a sample are all committed. It may be detected that a commit has been made.
  • FIG. 21 is a flowchart showing the operation at the time of inspection result browsing.
  • the specimen search unit 160 of the browser device 16 transmits a search request for a specimen that is a browsing candidate to the portal server 102 (S190).
  • the portal server 102 transmits the search result including the sample information whose status is already tested to the viewer device 16 (S192).
  • the sample information includes a sample hash value, status, browsing fee, requester address, one or more examiner addresses, and one or more correct answerer addresses included in the test information of the virus SC 106. Further, the client score and the examiner score recorded in the actor SC 110 are included.
  • the browsing execution unit 162 of the browsing device 16 calls the browsing processing method of the virus SC 106 using parameters including the sample address and the browsing address (S194).
  • the browsing processing unit 192 of the virus SC 106 transfers tokens for the browsing fee from the browser account to the client account in the token SC 108. Also, the browsing processing unit 192 transfers tokens for a predetermined fee from the viewer account to the organizer account. Also, the browsing processing unit 192 records the current browsing account in the token SC 108, and transfers a predetermined amount of tokens from the browsing account to the current browsing account as a browser deposit (S196). .
  • the browsing execution unit 162 of the browsing device 16 transmits a browsing request including the sample address and the browsing address to the portal server 102.
  • the portal server 102 uses the browser address to confirm that the viewer has paid the viewing fee (S198). If the viewer has paid the viewing fee, the portal server 102 transmits the result nonce (result nonce stored in S162) associated with the sample address to the viewer device 16 (S200).
  • the browsing execution unit 162 of the browser device 16 acquires the result nonce.
  • the browsing execution unit 162 of the browser device 16 acquires the result hash value of the browsing target sample from the examination information of the virus SC 106.
  • the browsing execution unit 162 has a hash value of data obtained by combining the result nonce with a predetermined “white” value, a hash value of data obtained by combining the result nonce with a predetermined “black” value, and a result hash By comparing with the value, it is determined whether the black and white determination result for the browsing target specimen is “white” or “black” (S202).
  • the black and white determination result here is a final determination result by the requester of the sample to be browsed.
  • the browsing execution unit 162 may display on the screen whether the monochrome determination result of the browsing target specimen is “white” or “black”.
  • the viewer after confirming the black and white determination result, evaluates the requester and inputs the evaluation result to the viewer device 16. Typically, the viewer sets a high evaluation value if the requester's monochrome determination result is correct, while setting a low evaluation value if the requester's monochrome determination result is incorrect.
  • the requester's black-and-white determination result is incorrect, for example, the client determines that the sample to be browsed is valid ("white"), but the sample to be browsed is actually malware ("black”) Or, conversely, the client determines that the browsing target sample is malware (“black”), but the browsing target sample is actually valid (“white”).
  • the client evaluation unit 164 of the browser device 16 calls the client evaluation method of the virus SC 106 using the browser address and the client evaluation value as parameters (S204).
  • the client evaluation processing unit 194 of the virus SC 106 adjusts the client's score based on the client's evaluation value transmitted from the browser device 16 (S206). For example, when the evaluation value of the client is high, the client evaluation processing unit 194 may change the client score recorded in the actor SC 110 to a value larger than that. On the contrary, when the evaluation value of the client is low, the client evaluation processing unit 194 may change the client score recorded in the actor SC 110 to a value smaller than that. Further, the requester evaluation processing unit 194 transfers the browser deposit recorded in the browsing account to the browser account (S208). In other words, the client evaluation processing unit 194 returns the token deposited from the viewer at the time of browsing execution to the browser account at the time of client evaluation.
  • FIG. 22 shows a configuration of a modified inspection system 101.
  • the inspection system 101 includes a sponsor device 210 in addition to the configuration of the second embodiment.
  • the sponsor device 210 is an information processing device operated by the sponsor.
  • the sponsor is a user who sponsors the examination of the sample registered by the client, in other words, a user who requests the examination of the same specimen together with the client. Note that a sponsor for a test of a certain sample may be a client, a tester, or a viewer in the test of another sample.
  • FIG. 23 shows an example of inspection information in the modified example.
  • the client device 12 and the virus SC 106 further set a sponsorship approval / disapproval flag and a reward upper limit when registering the examination request.
  • the sponsorship permission / prohibition flag is set to either allow the sponsorship of another person (“sponsorship is allowed”) or prohibit the sponsorship of another person (“sponsorship is not allowed”).
  • the remuneration upper limit is set when the sponsorship permission / inhibition flag is sponsorable.
  • the remuneration upper limit is the upper limit of the remuneration amount added by the sponsor.
  • the purpose of sponsors to support specimen testing is to increase the willingness of the examiner by increasing the remuneration amount, to encourage active evaluation, and to receive a distribution of the viewing fee.
  • the token transfer unit 190 of the virus SC 106 distributes the sum of the requester's remuneration amount and the sponsor's addition amount to one or more correct answerers. Further, the token transfer unit 190 distributes the viewing fee paid by the viewer according to the share of the reward between the client and the sponsor. For example, when the client's reward amount is 80 tokens, the sponsor's additional amount is 20 tokens, and the viewing fee is 10 tokens, the token transfer unit 190 transfers 8 tokens from the browser account to the client account. The token may be transferred from the viewer's account to the sponsor's account.
  • the client can obtain 10 tokens per view, but since there is a sponsor, the revenue per visit is 8 tokens. Further, in order for the viewer to obtain 10 tokens per viewing, the viewing fee needs to be about 13 tokens, but there is a possibility that the number of viewers may decrease.
  • Setting items for adjusting such a decrease in revenue are a sponsorship propriety flag and a reward upper limit. For example, the client can arbitrarily adjust the earnings per browsing by adjusting the reward amount, the upper limit of reward, and the viewing fee. The client sets the sponsorship approval / disapproval flag and the remuneration upper limit amount by comparing the activation of the inspection with his own profit.
  • FIG. 24 is a block diagram showing functional blocks of the sponsor device 210 of FIG.
  • the sponsor device 210 includes the client device 12, the display unit 42, the communication unit 112, and the control unit 44.
  • the control unit 44 includes a request search unit 212 and a sponsor unit 214.
  • the request search unit 212 acquires information on one or more registered inspection requests from the portal server 102. For example, the request search unit 212 transmits an inspection request search request to the portal server 102.
  • the portal server 102 refers to the inspection information of the virus SC 106 and transmits information related to the inspection request whose status is under inspection to the sponsor device 210 as a search result.
  • the information related to the test request includes the sample hash value, the time limit, the reward, the number of evaluation completed testers (the number of testers recorded in the test information), and the sample URI included in the test information of the virus SC 106. Furthermore, the client score recorded in the actor SC 110 and the score of the evaluation completion inspector are included.
  • the portal server 102 may transmit only the information of the inspection request in which the sponsorship permission / prohibition flag is set to sponsorship to the sponsor apparatus 210.
  • the sponsor device 210 displays the search result on the screen.
  • the sponsoring unit 214 calls the sponsoring processing method of the virus SC 106 using a parameter that designates an inspection request selected as a sponsor object by the sponsor.
  • the parameters include a sample hash value, which is a key for a sponsored test request, and a reward addition amount (that is, an amount added to a predetermined reward).
  • a sponsor processing unit (not shown) of the virus SC 106 updates the examination information specified by the sample hash value using the above parameters. For example, the sponsor processing unit of the virus SC 106 sets the sponsor setting item 220 in FIG. 23 in the examination information. In addition, since the sponsor does not need the result commit, a deposit as an incentive for the result commit is also unnecessary.
  • the configuration and operation of the inspection system 101 described in the second embodiment and the modification can be expressed as follows.
  • the requester apparatus 12 records the inspection target data in a predetermined area, and records the inspection reward in the block chain system 104.
  • Each of the one or more inspector apparatuses 14 acquires the inspection object data recorded by the client apparatus 12, and records the inspection result (for example, evaluation report) for the inspection object data in a predetermined area.
  • the requester apparatus 12 acquires one or more inspection results recorded by the one or more inspector apparatuses 14, and data of correct answerers (for example, correct answers) that are inspectors whose inspection results are recognized as correct by the requester.
  • the user address array is recorded in the block chain system 104.
  • the blockchain system 104 (for example, the virus SC 106) distributes the test reward to the correct answerer.
  • the client can obtain a test result of electronic data by one or more inspectors, and a correct answerer among one or more inspectors can realize a business model that can obtain a reward.
  • the client can easily perform remittance (in other words, transfer of value) even if the client does not have confidence in each inspector.
  • repeated remittance can be easily realized.
  • tampering with respect to payment of remuneration can be prevented.
  • the blockchain system 104 (eg, actor SC110) stores the score of each of one or more examiners. The score of each inspector is changed according to whether or not the inspection result (for example, white or black evaluation result) is correct.
  • the block chain system 104 distributes a relatively high reward to an inspector who has a relatively high score among one or more inspectors whose test results are correct. According to this configuration, it is possible to provide an incentive for the inspector to create a correct evaluation result, in other words, to evaluate in good faith.
  • Each of the one or more inspector apparatuses 14 obtains correct answerer data from the blockchain system 104, and if the correct answerer data is approved by the inspector (for example, final commit), the correct answerer approval is blocked. Record to chain system 104.
  • the blockchain system 104 distributes the inspection reward to the correct answerer when the correct answerer's approval is recorded from all the inspector devices 14. The reward is distributed to the correct answerer on the condition that all the inspectors corresponding to the inspection request by the client approve it. This makes it possible to realize a reward distribution that is satisfactory to each inspector.
  • the requester apparatus 12 When recording the inspection object data (for example, at the time of inspection request), the requester apparatus 12 records at least a part of the currency (for example, token) held by the requester as a deposit in the block chain system 104 (for example, token SC108). .
  • the blockchain system 104 returns the deposit to the requester when all the inspector apparatuses 14 record the approval of the correct answerer.
  • the incentive to respond seriously to the objection from the inspector by returning the deposit to the requester on condition that all the inspectors who responded to the inspection request by the client are approved. Can be provided to clients.
  • the inspector makes an appeal to the client.
  • the client Upon receiving this, the client performs operations such as including the inspector in the array of correct answerer addresses.
  • Each of the one or more inspector apparatuses 14 records at least a part of the currency held by the inspector as a deposit in the block chain system 104 (for example, the token SC 108) when recording the inspection result (for example, at the time of evaluation commit). To do.
  • the blockchain system 104 returns the deposit to the inspector corresponding to the inspector device 14 when the approval of the correct answerer is recorded from the inspector device 14.
  • An inspector who has made an incorrect answer may neglect to approve the correct answerer's recognition by the client.
  • Each of the one or more inspector apparatuses 14 blocks the hash value (for example, the evaluation hash value in FIG. 16) of data obtained by combining the inspection result and the random number value when recording the inspection result (for example, black and white determination result). Record to chain system 104.
  • the hash value for example, the evaluation hash value in FIG. 16
  • the random number value when recording the inspection result (for example, black and white determination result). Record to chain system 104.
  • one or more inspector apparatuses 14 can prove their own evaluation results after storing each random value, and record the hash value in the block chain system 104. Thus, alteration of the inspection result can be prevented.
  • the client device 12 records the inspection result (for example, black and white determination result) and the inspection fee for the inspection result in the block chain system 104 (for example, the virus SC 106).
  • the viewer device 16 causes the block chain system 104 to execute a process of paying the requester a viewing fee from the currency held by the viewer. Since the client can increase the profit by viewing the inspection result, the client can provide an incentive to request the inspection to the client. In addition, tampering with the payment of the viewing fee can be prevented.
  • the requester apparatus 12 records a hash value (for example, the result hash value in FIG. 16) of data obtained by combining the inspection result and the random number in the block chain system 104 (for example, the virus SC 106) and notifies the portal server 102 of the random number. To do. When the browsing fee is paid from the viewer to the requester, the portal server 102 notifies the browser device 16 of the random number so that the inspection result can be identified in the viewer device 16. Since the smart contract of the block chain system 104 is shared by each device of the inspection system 101, each device of the inspection system 101 can obtain data of the inspection result from the smart contract. However, with the above configuration, it is possible to prevent a test result (that is, whether the specimen is white or black) from being confirmed without paying a viewing fee.
  • a test result that is, whether the specimen is white or black
  • the client apparatus 12 When the client apparatus 12 records the inspection object data, the client apparatus 12 records at least a part of the currency held by the client to the block chain system 104 as a fee.
  • the block chain system 104 stores the client's score and determines the fee according to the client's score.
  • the browser device 16 records the client's evaluation input by the viewer in the block chain system 104, thereby adjusting the client's score stored in the block chain system 104. According to this configuration, it is possible to give the client an incentive to improve his / her score in order to reduce the fee, that is, to give the client an incentive to appropriately determine the black and white of the specimen.
  • the browser device 16 When acquiring the inspection result, the browser device 16 records at least a part of the currency held by the viewer in the block chain system 104 as a deposit. When the evaluation of the client is recorded from the inspector device 14, the block chain system 104 returns the deposit to the viewer. According to this configuration, it is possible to give the viewer an incentive to evaluate the client.
  • the sponsor device 210 records the added amount of the inspection reward in the block chain system 104 (for example, the virus SC 106).
  • the block chain system 104 distributes the added reward to the correct answerer among the inspectors who have performed the inspection. According to this configuration, by providing a mechanism for adding the remuneration amount, it is possible to arouse the examiner's motivation and activate the inspection.
  • the client device 12 records the upper limit of the reward in the block chain system 104 when recording the inspection target data.
  • the additional amount of reward by the sponsor device 210 is limited by the above upper limit.
  • the block chain system 104 distributes the viewing fee paid by the viewer according to the share of the reward between the client and the sponsor. According to this configuration, the client can arbitrarily adjust the share of the viewing fee, in other words, the distribution rate of the viewing fee with the sponsor, by setting the upper limit of the reward.
  • the inspection system 101 may be configured not to include the client device 12, that is, only the plurality of examiner devices 14 and the viewer device 16.
  • the inspector may monitor an inspection target such as communication data (for example, data such as a packet) on a daily or regular basis.
  • the inspector may, for example, extract illegal data communication or unauthorized access, that is, a pattern that is different from a predetermined pattern or policy, and define a rule, in other words, define an abnormal pattern.
  • the inspector device 14 may record the rule (in other words, the abnormal pattern) in the evaluation report as a signature, and register the information sharing offer including the evaluation report and the amount of remuneration necessary for the inspection report in the block chain system 104. .
  • the inspector may voluntarily perform a search and register an evaluation report including the inspection result, countermeasure method, and the like in the block chain system 104.
  • the viewer pays the remuneration amount set by the inspector by browsing the information sharing offer by the same mechanism as in the second embodiment. If the content of the viewed signature is valid, the viewer may give a good rating to the inspector or pay an additional reward. If the viewed signature is not valid, the viewer may give a bad rating to the inspector, or the viewing fee paid by the viewer may be collected by the organizer. In addition, you may make it provide the sponsor apparatus 210 in this structure.
  • the inspector proactively inspects illegal specimens, security defects, etc. and discloses information for a fee, or unauthorized access as described above It is possible to create a signature for detecting and provide information for a fee.
  • a viewer for example, a security software provider
  • the inspector will be more eager to monitor detection of illegal data and information access by obtaining rewards.
  • inspection system 10 inspection system, 12 requester device, 14 inspector device, 16 viewer device, 18 file server, 22 blockchain network, 54 test data registration unit, 64 test data acquisition unit, 72 test result acquisition unit, 74 remittance unit, 76 inspection result output unit, 101 inspection system, 102 portal server, 104 block chain system, 210 sponsor device.
  • the present invention can be applied to a system for inspecting electronic data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Virology (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Bioethics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

依頼者装置１２は、検査対象データをファイルサーバ１８へ登録する。検査対象データが不正か否かを検査する検査者により操作される検査者装置１４は、依頼者装置１２により登録された検査対象データをファイルサーバ１８から取得して、検査対象データに対する検査結果をブロックチェーンネットワーク２２へ登録する。閲覧者装置１６は、検査者装置１４により登録された検査結果をブロックチェーンネットワーク２２から取得して、その検査結果に基づくデータ処理を実行する。

Description

検査システム、検査方法、およびコンピュータプログラム
　本発明はデータ処理技術に関し、特に検査システム、検査方法、およびコンピュータプログラムに関する。
　近年、情報セキュリティが重要視されており、多くのコンピュータにアンチウイルスソフトウェアが導入されている（例えば、特許文献１参照）。
特開２０１７－０２１７７９号公報
　アンチウイルスソフトウェアの導入は進んでいるが、現実的に、１つのアンチウイルスソフトウェアで全てのマルウェア（コンピュータウイルス、トロイの木馬、スパイウェア等）を検出することはできない。また、１つのコンピュータに、ベンダーや特性が異なる複数種類のアンチウイルスソフトウェアを導入することには、多大なコストがかかる。
　本発明は、上記課題に鑑みてなされたものであり、１つの目的は、電子データの検査を支援する技術を提供することにある。
　上記課題を解決するために、本発明のある態様の検査システムは、検査対象データを所定領域へ記録する第１の装置と、検査対象データが不正か否かを検査するユーザにより操作される第２の装置と、検査対象データに対する検査結果を使用する第３の装置と、を備える。第２の装置は、第１の装置により記録された検査対象データを取得して、検査対象データに対する検査結果を所定領域へ記録し、第３の装置は、第２の装置により記録された検査結果を取得する。
　本発明の別の態様もまた、検査システムである。この検査システムは、検査の依頼者により操作される依頼者装置と、一人以上の検査者により操作される一つ以上の検査者装置と、依頼者装置と検査者装置とがアクセス可能なブロックチェーンシステムと、を備える。依頼者装置は、検査対象データを所定領域へ記録するとともに、検査の報酬をブロックチェーンシステムへ記録し、検査者装置は、依頼者装置により記録された検査対象データを取得して、検査対象データに対する検査結果を所定領域へ記録し、依頼者装置は、検査者装置により記録された検査結果を取得し、依頼者により検査結果が正解と認定された検査者である正解者のデータをブロックチェーンシステムへ記録し、ブロックチェーンシステムは、正解者に対して検査の報酬を分配する。
　本発明のさらに別の態様は、検査方法である。この方法は、第１の装置が、検査対象データを所定領域へ記録するステップと、検査対象データが不正か否かを検査するユーザにより操作される第２の装置が、第１の装置により記録された検査対象データを取得するステップと、第２の装置が、検査対象データに対する検査結果を所定領域へ記録するステップと、検査対象データに対する検査結果を使用する第３の装置が、第２の装置により記録された検査結果を取得するステップと、を備える。
　本発明のさらに別の態様もまた、検査方法である。この方法は、検査の依頼者により操作される依頼者装置が、検査対象データを所定領域へ記録するとともに、検査の報酬をブロックチェーンシステムへ記録するステップと、一人以上の検査者により操作される一つ以上の検査者装置のそれぞれが、依頼者装置により記録された検査対象データを取得して、検査対象データに対する検査結果を所定領域へ記録するステップと、依頼者装置が、一つ以上の検査者装置により記録された検査結果を取得し、依頼者により検査結果が正解と認定された検査者である正解者のデータをブロックチェーンシステムへ記録するステップと、ブロックチェーンシステムが、正解者に対して検査の報酬を分配するステップと、を備える。
　なお、以上の構成要素の任意の組合せ、本発明の表現を、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
　本発明によれば、電子データの検査を支援することができる。
第１実施例の検査システムの構成を示す図である。 図１のファイルサーバの機能構成を示すブロック図である。 図１のユーザ装置の機能構成を示すブロック図である。 ＶＣの概念的なプログラムコードを示す図である。 ＶＣの概念的なプログラムコードを示す図である。 ＩＣの概念的なプログラムコードを示す図である。 検査Ａｐｐの概念的なプログラムコードを示す図である。 依頼者装置の動作を示すフローチャートである 検査者装置の動作を示すフローチャートである。 閲覧者装置の動作を示すフローチャートである。 変形例３の検査システムの構成を示す図である。 第２実施例の検査システムの構成を示す図である。 図１１の依頼者装置の機能ブロックを示すブロック図である。 図１１の検査者装置の機能ブロックを示すブロック図である。 図１１の閲覧者装置の機能ブロックを示すブロック図である。 図１１のブロックチェーンシステムの機能ブロックを示すブロック図である。 検査情報の例を示す図である。 検査の依頼に関する動作を示すフローチャートである。 検査の実施に関する動作を示すフローチャートである。 依頼者の結果判定に関する動作を示すフローチャートである。 検査者による最終コミットに関する動作を示すフローチャートである。 検査結果閲覧時の動作を示すフローチャートである。 変形例の検査システムの構成を示す図である。 変形例における検査情報の例を示す図である。 図２２の協賛者装置の機能ブロックを示すブロック図である。
　（第１実施例）
　第１実施例では、正当性が不明の電子ファイルをユーザがネットワーク上にアップロードすると、ネットワークに接続された他のユーザが当該電子ファイルの正当性を検査する情報処理システム（後述の検査システム）を実現する技術を提案する。正当性が不明の電子ファイルは、マルウェアを含みうる電子ファイルとも言える。実施例の検査システムは、データの改ざんが困難な分散型ネットワークであるブロックチェーンネットワークを含む。
　図１は、第１実施例の検査システム１０の構成を示す。検査システム１０は、依頼者装置１２、検査者装置１４、閲覧者装置１６、ファイルサーバ１８を備える。図１の各装置は、ＬＡＮ・ＷＡＮ・インターネット等を含む通信網２０を介して接続される。
　依頼者装置１２は、電子データ（実施例では電子ファイル）の検査を外部に依頼するユーザ（以下「依頼者」とも呼ぶ。）により操作される情報処理装置である。検査対象となる電子ファイル（以下「被験ファイル」とも呼ぶ。）は、マルウェアの存在が疑われる電子ファイル、または、安全性を確認したい電子ファイルであってもよい。
　検査者装置１４は、被験ファイルの正当性（言い換えれば不正の有無、マルウェアの有無）を検査するユーザ（以下「検査者」とも呼ぶ。）により操作される情報処理装置である。検査者は、例えば、情報セキュリティ技術の専門家でもよい。閲覧者装置１６は、被験ファイルに対する検査結果を閲覧するユーザ（以下「閲覧者」とも呼ぶ。）により操作される情報処理装置であり、また、検査結果を用いたデータ処理を実行する情報処理装置である。依頼者装置１２、検査者装置１４、閲覧者装置１６は、例えばＰＣ、タブレット端末、スマートフォンであってもよい。
　依頼者装置１２、検査者装置１４、閲覧者装置１６には、ブロックチェーンネットワーク２２を形成し、利用するためのライブラリおよびアプリケーション（以下「検査Ａｐｐ」とも呼ぶ。）が導入される。言い換えれば、依頼者装置１２、検査者装置１４、閲覧者装置１６は、公知のブロックチェーンの仕組みに基づいてＰ２Ｐ（Peer to Peer）通信を実行し、ブロックチェーンネットワーク２２を形成する。
　なお、実際には、多くのユーザが、依頼者、検査者、閲覧者のいずれかの立場で検査システム１０に参加することができる。また、各ユーザは、依頼者、検査者、閲覧者のいずれになることもできる。例えば、被験ファイルＡの検査における依頼者装置１２は、別の被験ファイルＢの検査では、検査者装置１４になるかもしれないし、閲覧者装置１６になるかもしれない。また、被験ファイルＣの検査における検査者装置１４は、別の被験ファイルＤの検査では依頼者装置１２になるかもしれないし、閲覧者装置１６になるかもしれない。さらにまた、依頼者と閲覧者は同一でもよく、すなわち、依頼者装置１２と閲覧者装置１６は同一でもよい。以下、図１の依頼者装置１２、検査者装置１４、閲覧者装置１６を総称する場合、「ユーザ装置２４」と呼ぶ。
　ファイルサーバ１８は、依頼者装置１２から被験ファイルが登録され、登録された被験ファイルを検査者装置１４へ提供する情報処理装置である。ファイルサーバ１８には、上記の検査Ａｐｐは導入されない。すなわち、ファイルサーバ１８は、ブロックチェーンネットワーク２２に参加しない装置であり、言い換えれば、ブロックチェーンネットワーク２２の外部に存在する装置である。なお、ファイルサーバ１８は、複数台のサーバで構成されてもよい。
　以下、検査システム１０の構成要素をブロック図を使用して説明する。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵ・メモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
　図２は、図１のファイルサーバ１８の機能構成を示すブロック図である。ファイルサーバ１８は、被験データ保持部３０、被験データ受付部３２、被験データ提供部３４を備える。被験データ保持部３０は、被験データを、その記憶位置を示すアドレス（例えばＵＲＬ文字列でもよく、以下「被験ファイルアドレス」とも呼ぶ。）に対応付けて記憶する。
　被験データ受付部３２は、被験ファイルの登録要求を依頼者装置１２から受信する。被験データ受付部３２は、登録要求に含まれる被験ファイルを被験データ保持部３０に格納する。被験データ受付部３２は、登録要求への応答として、被験ファイルアドレスを依頼者装置１２へ送信する。
　被験データ提供部３４は、被験ファイルの提供要求を検査者装置１４から受信する。被験ファイルの提供要求は、特定の被験ファイルを示すアドレス（被験ファイルアドレス）の指定を含む。被験データ提供部３４は、被験データ保持部３０に格納された複数の被験ファイルのうち、指定された被験ファイルアドレスで特定される被験ファイルを検査者装置１４へ送信する。
　図３は、図１のユーザ装置２４（すなわち依頼者装置１２、検査者装置１４、閲覧者装置１６）の機能構成を示すブロック図である。ユーザ装置２４は、入力部４０、表示部４２、制御部４４を備える。入力部４０は、ユーザの操作を受け付け、操作内容を制御部４４へ入力する。表示部４２は、制御部４４から出力された画像データを画面に表示する。
　制御部４４は、各種データ処理を実行し、依頼処理部４６、検査処理部４８、閲覧処理部５０を備える。これらのブロックの機能は、ユーザ装置２４のＣＰＵが、ユーザ装置２４のメモリに格納された検査Ａｐｐ５２を実行することにより実現されてもよい。依頼処理部４６、検査処理部４８、閲覧処理部５０のそれぞれは、後説するように、複数のモジュールからなるものの、その全部又は一部のモジュールについてはファイルサーバ１８又はファイルサーバ１８とは異なる新たなサーバに実装する構成であってもよい。
　以降の説明におけるブロックチェーンネットワーク２２からのデータの取得、および、ブロックチェーンネットワーク２２上のデータの更新は、ユーザ装置２４にインストールされたブロックチェーンネットワーク２２のライブラリが備えるＡＰＩ（Application Programming Interface）を呼び出すことにより実現される。実際には、ブロックチェーンネットワーク２２のデータは、依頼者装置１２、検査者装置１４、閲覧者装置１６で分散管理され、ブロックチェーンネットワーク２２の基盤アプリケーションにより、装置間でのデータ同期が実現される。
　依頼処理部４６は、主に依頼者装置１２における処理を実行する。依頼処理部４６は、被験データ登録部５４、ＳＣ生成部５６、インデックス更新部５８を含む。
　被験データ登録部５４は、被験ファイルをファイルサーバ１８へ送信することにより、被験ファイルをファイルサーバ１８に登録する。被験データ登録部５４は、被験ファイルの登録時に、ファイルサーバ１８における記憶位置を示す被験ファイルアドレス（例えばＵＲＬ文字列）をファイルサーバ１８から取得する。
　ＳＣ生成部５６は、被験データ登録部５４によりファイルサーバ１８に登録された被験ファイルに関する属性情報を含むスマートコントラクトを生成する。スマートコントラクトは、ブロックチェーン上で動作するエージェントプログラムとも言える。このスマートコントラクトは、例えば後述の「VirusContract」クラスのインスタンスであり、ウイルスコントラクトの意味で以下「ＶＣ」と呼ぶ。被験ファイルに関する属性情報は、ファイルサーバ１８における被験ファイルアドレスを含む。ＳＣ生成部５６は、生成したＶＣをブロックチェーンネットワーク２２に登録する。言い換えれば、ブロックチェーンネットワーク２２のデータ（台帳データとも言える）に、生成したＶＣを追加する。
　インデックス更新部５８は、複数のＶＣのアドレス（すなわちブロックチェーンネットワーク２２上での位置情報）を含むスマートコントラクトをブロックチェーンネットワーク２２から取得する。このスマートコントラクトは、例えば後述の「IndexContract」クラスのインスタンスであり、インデックスコントラクトの意味で以下「ＩＣ」と呼ぶ。インデックス更新部５８は、取得したＩＣに、ＳＣ生成部５６により生成されたＶＣのアドレスと、被験ファイルの識別情報（実施例ではハッシュ値）とを追加する。
　検査処理部４８は、主に検査者装置１４における処理を実行する。検査処理部４８は、インデックス取得部６０、ＳＣ取得部６２、被験データ取得部６４、ＳＣ更新部６６を含む。
　インデックス取得部６０は、ブロックチェーンネットワーク２２からＩＣを取得する。ＳＣ取得部６２は、検査者により指定された被験ファイルの識別情報（実施例では被験ファイルのハッシュ値）に対応付けられたＶＣのアドレスをＩＣから取得する。ＳＣ取得部６２は、アドレスにより特定されるＶＣをブロックチェーンネットワーク２２から取得する。被験データ取得部６４は、ＶＣから被験ファイルアドレスを取得する。被験データ取得部６４は、ファイルサーバ１８にアクセスし、被験ファイルアドレスにより特定される被験ファイルをファイルサーバ１８からダウンロードする。
　ＳＣ更新部６６は、検査者による被験ファイルの検査後に、その検査結果を被験ファイルのＶＣに記録する。ＳＣ更新部６６は、検査結果記録後の被験ファイルのＶＣをブロックチェーンネットワーク２２に登録する。言い換えれば、ＳＣ更新部６６は、ブロックチェーンネットワーク２２上に保存された、被験ファイルのＶＣに、検査者による検査結果を反映する。
　閲覧処理部５０は、インデックス取得部６８、ＳＣ取得部７０、検査結果取得部７２、送金部７４、検査結果出力部７６を含む。
　インデックス取得部６８は、ブロックチェーンネットワーク２２からＩＣを取得する。ＳＣ取得部７０は、閲覧者により指定された被験ファイルの識別情報（実施例では被験ファイルのハッシュ値）に対応付けられたＶＣのアドレスをＩＣから取得する。ＳＣ取得部７０は、アドレスにより特定されるＶＣをブロックチェーンネットワーク２２から取得する。検査結果取得部７２は、ＳＣ取得部７０により取得されたＶＣから被験ファイルの検査結果を取得する。言い換えれば、検査結果取得部７２は、ブロックチェーンネットワーク２２上に保存された、被験ファイルの検査結果を取得する。
　送金部７４は、検査結果が取得されるタイミングと同期して、検査者と依頼者の両方への報酬支払を実行する。例えば、送金部７４は、閲覧者の口座から検査者の口座への送金（振込）処理を実行するとともに、閲覧者の口座から依頼者の口座への送金処理を実行してもよい。なお、検査結果取得部７２は、送金部７４による送金処理が成功したことを条件として、被験ファイルの検査結果を取得してもよい。
　また、送金部７４は、閲覧者から依頼者への送金、および、閲覧者から検査者への送金に関する情報をブロックチェーンネットワーク２２（もしくは金銭交換用の他のブロックチェーン）の台帳データに記録してもよい。これにより、報酬支払の確実性を高め、また、支払金額の改ざんを防止することができる。
　検査結果出力部７６は、検査結果取得部７２により取得された検査結果のデータを表示部４２へ出力し、その検査結果を表示部４２に表示させる。なお、実施例では、依頼処理部４６、検査処理部４８、閲覧処理部５０を含む検査Ａｐｐ５２が、依頼者装置１２、検査者装置１４、閲覧者装置１６に導入される。変形例として、依頼処理部４６の機能のみを含む検査Ａｐｐが依頼者装置１２に導入されてもよい。また、検査処理部４８の機能のみを含む検査Ａｐｐが検査者装置１４に導入され、また、閲覧処理部５０の機能のみを含む検査Ａｐｐが閲覧者装置１６に導入されてもよい。
　図４（ａ）と図４（ｂ）は、ＶＣの概念的なプログラムコード（VirusContract.java）（「java」は登録商標）を示す。図４（ｂ）は、図４（ａ）の続きを示している。図５は、ＩＣの概念的なプログラムコード（IndexContract.java）を示す。図６は、ＶＣおよびＩＣを利用する検査Ａｐｐ５２の概念的なプログラムコード（FlowTest.java）を示す。これらのプログラムコードは、後述のフローチャートの説明で適宜参照する。
　以上の構成による検査システム１０の動作を説明する。
　図７は、依頼者装置１２の動作を示すフローチャートである。検査Ａｐｐ５２のＧＵＩにおいて検査対象となる被験ファイルを依頼者が指定した場合（Ｓ１０のＹ）、依頼者装置１２の被験データ登録部５４は、被験ファイルをファイルサーバ１８へ登録する。それとともに被験データ登録部５４は、ファイルサーバ１８における被験ファイルアドレスをファイルサーバ１８から取得する（Ｓ１２）。被験データ登録部５４は、被験ファイルと、被験ファイルアドレスとをＳＣ生成部５６に渡す。
　ＳＣ生成部５６は、図６のコード８０に示すように、ブロックチェーンネットワーク２２上での依頼者装置１２のアドレス、被験ファイルアドレス、被験ファイルのハッシュ値をパラメータとして、被験ファイル用のスマートコントラクト（以下「ＶＣ」）を生成する（Ｓ１４）。ハッシュ値の生成に使用するハッシュ関数は、例えばＭＤ５でもよい。コード８０では不図示だが、ＳＣ生成部５６はさらに、生成したＶＣインスタンスをブロックチェーンネットワーク２２に登録するとともに、ＶＣインスタンスのブロックチェーンネットワーク２２上でのアドレスを取得する。
　インデックス更新部５８は、図６のコード８２に示すように、インデックス用のスマートコントラクト（以下「ＩＣ」）を取得する。実際には、インデックス更新部５８は、ブロックチェーンネットワーク２２のＡＰＩをコールして、ブロックチェーンネットワーク２２に登録されたＩＣを取得する。インデックス更新部５８は、取得したＩＣが持つアドレスマップ（図５のaddressMap）に、被験ファイルのハッシュ値（キー）と、ＶＣのアドレス（値）を追加する（Ｓ１６）。被験ファイルを指定する操作が入力されなければ（Ｓ１０のＮ）、Ｓ１２～Ｓ１６をスキップして本図のフローを終了する。
　図８は、検査者装置１４の動作を示すフローチャートである。検査Ａｐｐ５２のＧＵＩにおいて特定の被験ファイルの取得を検査者が要求した場合（Ｓ２０のＹ）、検査者装置１４のインデックス取得部６０は、ブロックチェーンネットワーク２２に登録されたＩＣを取得する（Ｓ２２）。実施例では、検査者は取得すべき被験ファイルのハッシュ値を指定する。ＳＣ取得部６２は、図６のコード８４に示すように、被験ファイルのハッシュ値をキーとして、被験ファイルのＶＣのアドレスをＩＣから取得する。そしてＳＣ取得部６２は、ＶＣのアドレスをキーとして、ブロックチェーンネットワーク２２に登録された被験ファイルのＶＣを取得する（Ｓ２４）。
　被験データ取得部６４は、図６のコード８６に示すように、ファイルサーバ１８における被験ファイルアドレスをＶＣから取得する。そして被験データ取得部６４は、被験ファイルアドレスをキーとして、ファイルサーバ１８から被験ファイルを取得する（Ｓ２６）。被験ファイルの取得を要求する操作が入力されなければ（Ｓ２０のＮ）、Ｓ２２～Ｓ２６をスキップする。被験ファイルを取得した検査者は、検査者装置１４または他の装置を使用して、被験ファイルが不正か否か（例えばマルウェアが含まれるか否か）を検査する。例えば、検査者は、既存のアンチウイルスソフトウェアを使用して検査を実行してもよい。また、検査者は、被験ファイルのバイナリを手動で解析してもよい。
　検査Ａｐｐ５２のＧＵＩにおいて、検査者は、判定結果、付加情報、検査方法を含む検査結果情報を入力する。被験ファイルに対する検査結果の登録を検査者が要求した場合（Ｓ２８のＹ）、ＳＣ更新部６６は、図６のコード８８、図４（ｂ）のコード９０に示すように、ブロックチェーンネットワーク２２上での検査者のアドレスと、検査結果情報とを被験ファイルのＶＣに追加する（Ｓ３０）。コード８８では不図示だが、ＳＣ更新部６６はさらに、検査結果情報を追加したＶＣをブロックチェーンネットワーク２２に登録する。検査結果の登録を要求する操作が入力されなければ（Ｓ２８のＮ）、Ｓ３０をスキップして本図のフローを終了する。
　図９は、閲覧者装置１６の動作を示すフローチャートである。検査Ａｐｐ５２のＧＵＩにおいて検査結果を閲覧する対象の被験ファイルを閲覧者が選択した場合（Ｓ４０のＹ）、閲覧者装置１６のインデックス取得部６８は、ブロックチェーンネットワーク２２に登録されたＩＣを取得する（Ｓ４２）。実施例では、検査者は、検査結果閲覧対象の被験ファイルのハッシュ値を指定する。ＳＣ取得部６２は、図６のコード９２に示すように、被験ファイルのハッシュ値をキーとして、被験ファイルのＶＣのアドレスをＩＣから取得する。そしてＳＣ取得部６２は、ＶＣのアドレスをキーとして、ブロックチェーンネットワーク２２に登録された被験ファイルのＶＣを取得する（Ｓ４４）。
　図６のコード９４に示すように、検査結果取得部７２は、被験ファイルに対する検査結果を登録した検査者の一覧を取得し、検査結果出力部７６は、検査者の一覧を表示部４２に表示させる（Ｓ４６）。検査結果を表示すべき特定の検査者を閲覧者が選択するまで待機する（Ｓ４８のＮ）。特定の検査者を閲覧者が選択した場合（Ｓ４８のＹ）、検査結果取得部７２は、選択された検査者による検査結果を取得する（Ｓ５０）。具体的には、図６のコード９６、図４（ａ）のコード９８に示すように、検査結果取得部７２は、閲覧者のアドレスと、選択された検査者のアドレスをパラメータとして指定し、その検査者のアドレスに対応付けられた検査結果を取得する。
　送金部７４は、図４（ａ）のコード９８に示すように、閲覧者から依頼者への送金処理を実行するとともに、閲覧者から検査者への送金処理を実行する。さらに実施例では、送金部７４は、閲覧者から検査システム１０の管理者への送金処理を実行する（Ｓ５２）。すなわち、閲覧者が検査結果を閲覧することを契機として、依頼者・検査者・管理者の３者へ報酬が支払われる。検査結果出力部７６は、図６のコード１００に示すように、検査結果取得部７２により取得された検査結果を表示部４２に表示させる（Ｓ５４）。検査結果を閲覧する対象の被験ファイルが未選択であれば（Ｓ４０のＮ）、Ｓ４２～Ｓ５４をスキップして本図のフローを終了する。
　１つの被験ファイルの検査に関する検査システム１０の動作は、被験ファイルの登録、被験ファイルの検査、検査結果の閲覧という流れになる。したがって、１つの被験ファイルの検査では、依頼者装置１２による図７の処理、検査者装置１４による図８の処理、閲覧者装置１６による図９の処理が順次実行される。実際の検査システム１０では、複数の被験ファイルに対する処理が並行して実行される。なお、依頼者装置１２、検査者装置１４、閲覧者装置１６は、ブロックチェーンネットワーク２２におけるデータ（ＶＣ、ＩＣ等）の同期処理を常時実行する。
　実施例の検査システム１０によると、依頼者がアップロードした電子データの正当性を、ネットワーク上の１人以上の検査者が検査し、その検査結果を閲覧者（依頼者を含む）が確認可能になる。これにより、アンチウイルスソフトウェアだけでは万全とは言い難いマルウェアの検出について、他のユーザの協力によりマルウェアの検出精度を向上することができる。
　また、検査システム１０では、被験ファイルの属性情報および検査結果は、ブロックチェーンネットワーク２２を介して送受信される。これにより、被験ファイルの属性情報および検査結果を改ざんすることが困難となり、セキュリティの強度を一層高めることができる。また、比較的データサイズが大きい被験ファイル自体は、ブロックチェーンネットワーク２２の外で送受信することにより、ブロックチェーンネットワーク２２の負荷を抑制できる。
　また、検査システム１０では、閲覧者が検査結果を閲覧するときに、依頼者および検査者へ報酬が支払われる。これにより、検査システム１０に対する被験ファイルのアップロードと、被験ファイルの検査に対するインセンティブを提供できる。また、閲覧者は、閲覧する検査結果を検査者の単位で指定可能である。すなわち、閲覧者は、検査結果の正確性が高い検査者、信頼する検査者等、所望の検査者による検査結果を選択的に閲覧できる。これにより、報酬の支払先が閲覧者により選択された検査者に限定され、また、正確な検査結果を登録するインセンティブを検査者へ提供できる。
　以上、本発明を第１実施例をもとに説明した。この第１実施例は例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
　（変形例１）
　上記実施例では、被験ファイルをファイルサーバ１８で管理する一方、被験ファイルに関する様々な属性情報（アドレスや検査結果等）を依頼者装置１２、検査者装置１４、閲覧者装置１６により形成されるブロックチェーンネットワーク２２で管理した。変形例として、被験ファイルと、被験ファイルに関する属性情報の両方を１つの装置（ここでは「検査支援装置」と呼ぶ。）が集中的に管理してもよい。
　検査支援装置は、実施例のファイルサーバ１８の機能と、実施例のブロックチェーンネットワーク２２の機能の両方を備えてもよい。具体的には、検査支援装置は、実施例のファイルサーバ１８における被験データ保持部３０、被験データ受付部３２、被験データ提供部３４に加えて、検査結果保持部、検査結果受付部、検査結果提供部を備えてもよい。検査結果保持部は、被験データ（例えば被験データアドレス）と対応付けて検査結果を記憶してもよい。検査結果受付部は、検査者装置１４から送信された、被験ファイルに対する検査結果を示す情報を受信して検査結果保持部へ格納してもよい。検査結果提供部は、検査結果保持部に記憶された検査結果のうち、閲覧者装置１６により指定された被験ファイルに対応する検査結果を閲覧者装置１６へ提供してもよい。
　（変形例２）
　依頼者装置１２、検査者装置１４、閲覧者装置１６は、被験ファイルの検査のための処理を、人の操作に依存せず、自動実行する装置であってもよい。例えば、依頼者装置１２は、正当性の判別が困難な電子ファイルの存在を検出すると、その電子ファイルを被験ファイルとしてファイルサーバ１８へアップロードし、その被験ファイルのＳＣを生成し、さらにＩＣを更新する処理を自動的に実行してもよい。
　変形例２の依頼者装置１２は、電子メールサーバでもよく、被験ファイルは、電子メールへの添付ファイルであってもよい。電子メールサーバは、ローカルのアンチウイルスソフトウェアでは異常が検出されない添付ファイルを被験ファイルとしてファイルサーバ１８へアップロードしてもよい。また、電子メールサーバは、ローカルのアンチウイルスソフトウェアでは異常が検出されないが、ファイルの種類・サイズ・名称等が所定の基準（ホワイトリスト等）を逸脱する添付ファイルを被験ファイルとしてファイルサーバ１８へアップロードしてもよい。
　また、変形例２の閲覧者装置１６は、被験ファイルの検査結果を表示することに代えて、検査結果に応じて被験ファイルを削除してもよい。また、検査結果が被験ファイルの不正を示す場合、閲覧者装置１６は、被験ファイルに基づく所定のデータ処理を中止してもよい。例えば、閲覧者装置１６は、電子メールサーバでもよい。この電子メールサーバは、被験ファイルが不正と判定された場合、被験ファイルが添付された電子メールの転送を中止してもよく、当該電子メールを破棄してもよい。
　（変形例３）
　図１０は、変形例３の検査システムの構成を示す。上記実施例の検査システム１０では、被験ファイルは、ファイルサーバ１８に登録された。変形例３では、検査システム１０は、ファイルサーバ１８を備えず、被験ファイルは、ブロックチェーンネットワーク２２（図１０の破線）とは異なるＰ２Ｐネットワーク２６（図１０の一点鎖線）に登録される。
　変形例３のユーザ装置２４のそれぞれには、被験ファイルをＰ２Ｐ通信で交換するための公知ライブラリおよびアプリケーション（以下「Ｐ２Ｐモジュール」とも呼ぶ。）が導入されてもよい。ユーザ装置２４（言い換えれば依頼者装置１２）の被験データ登録部５４は、Ｐ２Ｐモジュールを利用して、Ｐ２Ｐネットワーク２６に被験ファイル（もしくは被験ファイルおよびそのハッシュ値）を登録してもよい（図７のＳ１２）。例えば、被験データ登録部５４は、他の複数のユーザ装置２４のそれぞれへ被験ファイルを送信してもよい。
　また、ユーザ装置２４（言い換えれば検査者装置１４）の被験データ取得部６４は、Ｐ２Ｐモジュールを利用して、Ｐ２Ｐネットワーク２６に登録された被験ファイルを取得してもよい（図８のＳ２６）。例えば、被験データ取得部６４は、ブロックチェーンネットワーク２２から取得した被験ファイルのハッシュ値をキーとして、Ｐ２Ｐネットワーク２６内のストレージからそのハッシュ値に対応する被験ファイルを取得してもよい。
　変形例３の別態様として、あるユーザ装置２４（依頼者装置１２）のローカルストレージに登録された被験ファイルを、別のユーザ装置２４（検査者装置１４）が取得もしくは参照する構成でもよい。変形例３の構成によると、ファイルサーバ１８を設けることなく、異なるユーザ装置２４間で被験ファイルを交換することができる。
　（第２実施例）
　第２実施例においても、ブロックチェーン技術を活用して、電子データ（以下「検体」とも呼ぶ。）の検査を支援する検査システムを提案する。第２実施例の検体は、第１実施例の被験ファイルに相当する。典型的には、検体は、マルウェアの存在が疑われる電子ファイル、または、安全性を確認したい電子ファイルであるが、検査対象となる様々な電子データであってもよい。以下、第１実施例で説明した要素と同じ要素には同じ符号を付して説明する。また、第１実施例で説明済みの内容は再度の説明を適宜省略する。
　図１１は、第２実施例の検査システム１０１の構成を示す。検査システム１０１は、依頼者装置１２、検査者装置１４ａ、検査者装置１４ｂ、検査者装置１４ｃ、閲覧者装置１６、ファイルサーバ１８、ポータルサーバ１０２を備える。これらの装置は、通信網２０を介して接続される。
　検査者装置１４ａ、検査者装置１４ｂ、検査者装置１４ｃは、異なる検査者により操作される情報処理装置である。検査者装置１４ａ、検査者装置１４ｂ、検査者装置１４ｃを総称する場合、検査者装置１４と呼ぶ。ポータルサーバ１０２は、検査システム１０１に関する各種情報を依頼者装置１２、検査者装置１４、および閲覧者装置１６へ提供するウェブアプリケーションサーバである。
　また、検査システム１０１は、第１実施例のブロックチェーンネットワーク２２に相当するブロックチェーンシステム１０４を備える。依頼者装置１２、検査者装置１４、閲覧者装置１６には、ブロックチェーンシステム１０４を形成し、利用するためのライブラリおよびアプリケーションが導入される。
　ブロックチェーンシステム１０４は、分散型データベースシステム（分散型台帳システム）とも言え、ブロックチェーンのプラットフォームの１つであるイーサリアム上に構築される。ブロックチェーンシステム１０４は、３つのスマートコントラクトのプログラムであるウイルスＳＣ１０６、トークンＳＣ１０８、アクターＳＣ１１０を含む。これらのスマートコントラクトは、依頼者装置１２、検査者装置１４、閲覧者装置１６、ポータルサーバ１０２のそれぞれからアクセス可能であり、これらの装置間で同期される。
　ウイルスＳＣ１０６は、検体の検査に関するデータ保存およびデータ処理を実行するスマートコントラクトである。トークンＳＣ１０８は、検査システム１０１内での仮想通貨であるトークンに関するデータ保存およびデータ処理を実行するスマートコントラクトである。アクターＳＣ１１０は、検査システム１０１のアクター（主に依頼者および検査者）に関するデータ保存およびデータ処理を実行するスマートコントラクトである。
　図１１では、依頼者装置１２および閲覧者装置１６を１つ描いたが、検査システム１０１は、異なる依頼者の複数の依頼者装置１２、異なる閲覧者の複数の閲覧者装置１６を備えてもよい。また、第１実施例でも説明したが、１人のユーザは、依頼者、検査者、閲覧者のいずれの立場でも検査システム１０１に参加できる。例えば、１つの情報処理装置が、依頼者装置１２、検査者装置１４、および閲覧者装置１６として機能してもよい。
　以下、依頼者装置１２、検査者装置１４、閲覧者装置１６の機能ブロックを別個に説明するが、各装置の機能は、第１実施例（図３）で説明したように１つのアプリケーションプログラムにより提供されてもよい。また、各装置の機能は、所定のウェブサーバ（例えばポータルサーバ１０２）が提供するウェブアプリケーションプログラムを各装置が実行することにより発揮されてもよい。
　図１２は、図１１の依頼者装置１２の機能ブロックを示すブロック図である。依頼者装置１２は、入力部４０、表示部４２、制御部４４、通信部１１２を備える。通信部１１２は、所定の通信プロトコルにしたがって外部装置と通信する。制御部４４は、通信部１１２を介して、ファイルサーバ１８とポータルサーバ１０２とデータを送受信する。
　制御部４４は、検体検索部１２０、検体登録部１２２、検査依頼部１２４、レポート取得部１２６、ノンス登録部１２８、結果コミット部１３０を備える。検体検索部１２０は、検査中および検査完了済の１つ以上の検体に関する情報をポータルサーバ１０２から取得する。検体登録部１２２は、検査対象の検体をファイルサーバ１８に登録する。検査依頼部１２４は、検体の検査依頼をブロックチェーンシステム１０４に登録する。例えば、検査依頼部１２４は、検査の報酬をブロックチェーンシステム１０４へ記録する。
　レポート取得部１２６は、検査者による検体の評価結果を示す評価レポートをファイルサーバ１８から取得する。依頼者が登録した検体の検査に複数の検査者が参加している場合、レポート取得部１２６は、それら複数の検査者が作成した複数の評価レポートをファイルサーバ１８から取得する。検査者による評価結果は、少なくとも、検体が正当なものであること（例えばマルウェアではないこと）を示す「白」と、検体が不正なものであること（例えばマルウェアであること）を示す「黒」のいずれかを含む。
　なお、検査者が作成した評価レポートには、検査者による評価結果に加えて、評価結果に対する検査者の自信の度合いを示す段階的なスコア（評価結果が正解である確度に関して検査者自らが評価した値）が含まれるようにしてもよい。例えば、「白；80％」であれば、検査者が検体を正当なものであると判断し、その確度は80％であると検査者が考えていることを示す。評価結果に対する検査者の自信の度合いは、前述の段階的なスコアであってもよいし、「自信あり」「やや自信あり」「自信なし」のような段階的な評価であってもよい。
　ノンス登録部１２８は、所定の乱数発生器が生成したノンス（言い換えれば乱数）（以下「結果ノンス」とも呼ぶ。）をポータルサーバ１０２に登録する。結果コミット部１３０は、ウイルスＳＣ１０６と連携して、結果コミット処理を実行する。例えば、結果コミット部１３０は、ウイルスＳＣ１０６に実装された結果コミット処理用のメソッドを呼び出してもよい。なお、本実施例において、スマートコントラクトのメソッドを呼び出すことは、他の公知の方法によりスマートコントラクトに対してトランザクションを発行することに置き換えてもよい。
　図１３は、図１１の検査者装置１４の機能ブロックを示すブロック図である。検査者装置１４の制御部４４は、依頼検索部１４０、検体取得部１４２、検体照合部１４４、レポート登録部１４６、評価コミット部１４８、ノンス取得部１５０、結果確認部１５２、最終コミット部１５４を備える。
　依頼検索部１４０は、登録された１つ以上の検査依頼に関する情報をポータルサーバ１０２から取得する。検体取得部１４２は、検査者により選択された検体をファイルサーバ１８から取得する。検体照合部１４４は、ハッシュ値を照合することにより、検体取得部１４２が取得した検体の正当性（言い換えれば改ざんがないこと）を確認する。レポート登録部１４６は、検査者が検体を検査して作成した評価レポートをファイルサーバ１８へ登録する。
　評価コミット部１４８は、ウイルスＳＣ１０６と連携して、評価コミット処理を実行する。例えば、結果コミット部１３０は、ウイルスＳＣ１０６に実装された評価コミット用のメソッドを呼び出してもよい。
　ノンス取得部１５０は、ポータルサーバ１０２に登録された結果ノンスを取得する。結果確認部１５２は、依頼者が最終的に検体を正当なもの（「白」）と判定したか、不正なもの（「黒」）と判定したか（以下「白黒判定結果」とも呼ぶ。）を確認する処理を実行する。最終コミット部１５４は、ウイルスＳＣ１０６と連携して、最終コミット処理を実行する。例えば、最終コミット部１５４は、ウイルスＳＣ１０６に実装された最終コミット用のメソッドを呼び出してもよい。
　図１４は、図１１の閲覧者装置１６の機能ブロックを示すブロック図である。閲覧者装置１６の制御部４４は、検体検索部１６０、閲覧実行部１６２、依頼者評価部１６４を備える。
　検体検索部１６０は、検査中および検査完了済の１つ以上の検体に関する情報をポータルサーバ１０２から取得する。閲覧実行部１６２は、ウイルスＳＣ１０６と連携して、閲覧者により選択された検体の検査結果を閲覧するための処理を実行する。依頼者評価部１６４は、ウイルスＳＣ１０６と連携して依頼者を評価するための処理を実行する。例えば、依頼者評価部１６４は、ウイルスＳＣ１０６に実装された閲覧処理用のメソッドを呼び出してもよい。
　図１５は、図１１のブロックチェーンシステム１０４の機能ブロックを示すブロック図である。既述したように、ブロックチェーンシステム１０４は、ウイルスＳＣ１０６、トークンＳＣ１０８、アクターＳＣ１１０を備える。
　トークンＳＣ１０８は、ユーザ口座保持部１７０、依頼口座保持部１７２、主催者口座保持部１７４、閲覧口座保持部１７５を含む。ユーザ口座保持部１７０は、依頼者が保有する口座（依頼者口座）の情報、複数の検査者が保有する複数の口座（検査者口座）の情報、閲覧者が保有する口座（閲覧者口座）の情報を記憶する。第２実施例では、各ユーザは、検査システム１０１で定められた仮想通貨であるトークンを保有する。各ユーザの口座情報には、各ユーザが保有するトークンの残高が記録される。各ユーザの口座は、各ユーザのアドレスにより識別される。
　依頼口座保持部１７２は、複数の検査依頼に対応する複数の口座（検査依頼口座）の情報を記憶する。検査依頼口座は、検査対象となる検体のハッシュ値により識別される。検査システム１０１では、新たな検査依頼が登録されるたびに新たな検査依頼口座が開設される。主催者口座保持部１７４は、検査システム１０１の主催者が保有する口座の情報を記憶する。例えば、主催者は、ファイルサーバ１８、ポータルサーバ１０２、ブロックチェーンシステム１０４を提供する企業である。閲覧口座保持部１７５は、閲覧ごとに開設される口座（閲覧口座）の情報を記憶する。閲覧口座は、閲覧者アドレスにより識別される。
　アクターＳＣ１１０は、スコア保持部１７６を含む。スコア保持部１７６は、依頼者のスコアと、複数の検査者それぞれのスコアを記憶する。依頼者スコアは、後述するように、閲覧者による依頼者の評価結果に応じて変更され、検査依頼登録時に支払う主催者への手数料の額に影響する。具体的には、依頼者のスコアが低いほど、手数料は高額になる。検査者スコアは、検査者の評価結果が正解か否か（実施例では依頼者により正解とされたか否か）に応じて変更され、報酬の分配率に影響する。具体的には、相対的にスコアが高い検査者は、相対的に高い分配率となる。
　また、アクターＳＣ１１０は、図示しない取引履歴保持部を含むようにしてもよい。取引履歴保持部は、依頼者の依頼登録回数、報酬の支払い回数、報酬の未払い回数、登録報酬の累計額等と、検査者の評価レポート登録回数、正解回数、不正解回数、評価結果に対する検査者の自信の度合いを示す段階的なスコアの平均値、獲得した報酬の累計額、閲覧された回数等を記憶し、本検査システムでの処理に応じて更新される。依頼者のスコアと、検査者のスコアは、取引履歴保持部に記憶される値に基づいて計算・更新されるようにしてもよい。
　ウイルスＳＣ１０６は、検査情報保持部１７８、依頼処理部１８０、評価コミット処理部１８２、結果コミット処理部１８４、最終コミット処理部１８６、閲覧処理部１９２、依頼者評価処理部１９４を含む。検査情報保持部１７８は、依頼者からの検査依頼ごとに生成される検査情報を記憶する。検査情報は、検査依頼または検体に関する複数の項目を含む。
　図１６は、検査情報の例を示す。検体のハッシュ値は、各検査情報のキーである。依頼者設定項目２００および依頼者設定項目２０２は、検体αの検査依頼を登録した依頼者装置１２により設定される情報項目である。検査者設定項目２０４および検査者設定項目２０６は、検体αを評価した複数の検査者装置１４により設定される項目である。ユーザのアドレスは、当該ユーザが検査システム１０１にアカウントを登録した際に払い出されるユーザごとにユニークなデータ（ＩＤ）である。
　図１５に戻り、依頼処理部１８０は、依頼者装置１２からの呼び出しに応じて、検査依頼時の処理を実行する。評価コミット処理部１８２は、検査者装置１４からの呼び出しに応じて、評価コミット時の処理を実行する。結果コミット処理部１８４は、依頼者装置１２からの呼び出しに応じて、結果コミット時の処理を実行する。
　最終コミット処理部１８６は、検査者装置１４からの呼び出しに応じて、最終コミット時の処理を実行する。最終コミット処理部１８６は、検査者評価部１８８とトークン振替部１９０を含む。検査者評価部１８８は、アクターＳＣ１１０のスコア保持部１７６に記憶された検査者のスコアを調整する。トークン振替部１９０は、トークンＳＣ１０８に記憶された口座間でのトークンの振替を実行する。
　閲覧処理部１９２は、閲覧者装置１６からの呼び出しに応じて、閲覧時の処理を実行する。依頼者評価処理部１９４は、閲覧者装置１６からの呼び出しに応じて、依頼者評価時の処理を実行する。
　以上の構成による検査システム１０１の動作を説明する。
　図１７は、検査の依頼に関する動作を示すフローチャートである。依頼者装置１２の検体検索部１２０は、依頼者により指定された検査候補の検体のハッシュ値をキーとする検体検索の要求をポータルサーバ１０２へ送信する（Ｓ１００）。ポータルサーバ１０２は、検索要求で指定されたハッシュ値をキーとして、ウイルスＳＣ１０６に記憶された検査情報を検索する。ポータルサーバ１０２は、ハッシュ値に該当する検体が存在するか（すなわち検査中または検査完了済）、存在しないか（すなわち未検査）を示す検索結果を検査者装置１４へ送信する（Ｓ１０２）。依頼者装置１２は、検索結果を画面に表示させる。
　依頼者は、検査候補の検体が未検査であれば、当該検体の検査依頼を指示する操作を依頼者装置１２へ入力する。依頼者装置１２の検体登録部１２２は、検体そのもののデータを含む登録要求をファイルサーバ１８へ送信する（Ｓ１０４）。ファイルサーバ１８は、依頼者装置１２から送信された検体のデータを所定の記憶領域に保存する（Ｓ１０６）。ファイルサーバ１８は、保存した検体に対してファイルサーバ１８におけるユニークなＩＤである検体ＵＲＩ（Uniform Resource Identifier）を発行し、検体ＵＲＩを依頼者装置１２へ送信する（Ｓ１０８）。依頼者装置１２の検体登録部１２２は、ファイルサーバ１８から送信された検体ＵＲＩを取得する。
　依頼者装置１２の検査依頼部１２４は、検体に関する複数の属性データをパラメータとして、ウイルスＳＣ１０６の検査依頼メソッドを呼び出す（Ｓ１１０）。検体に関する複数の属性データは、検体のハッシュ値、依頼者アドレス、検体ＵＲＩ、検査期限、報酬額（すなわちトークン量）を含む。検査期限および報酬額は、依頼者が任意に決定する。ウイルスＳＣ１０６の依頼処理部１８０は、上記複数の属性データを含む検査情報（依頼者設定項目２００）を検査情報保持部１７８に記録する（Ｓ１１２）。この際、検査情報のステータスは、検査中に設定される。
　また、ウイルスＳＣ１０６の依頼処理部１８０は、トークンＳＣ１０８の依頼口座保持部１７２に今回の検査依頼に対応する口座情報（検査依頼口座）を記録する。依頼処理部１８０は、報酬額のトークンと、主催者への手数料のトークンと、依頼者のデポジットのトークンを、トークンＳＣ１０８の依頼者口座から検査依頼口座へ振り替える（Ｓ１１４）。ウイルスＳＣ１０６は、エクスターナルコールにより、トークンの振替処理をトークンＳＣ１０８に実行させてもよい。また、トークンＳＣ１０８は、主催者への手数料の額を、アクターＳＣ１１０に記憶された依頼者スコアに応じて決定する。実施例では、依頼者スコアが高いほど手数料を低額にし、依頼者スコアが低いほど手数料を高額にする。これにより、依頼者スコアを高めようというインセンティブを依頼者に与える。
　図１８は、検査の実施に関する動作を示すフローチャートである。図１８の処理は、複数の検査者装置１４のそれぞれで実行される。検査者装置１４の依頼検索部１４０は、検査依頼の検索要求をポータルサーバ１０２へ送信する（Ｓ１２０）。ポータルサーバ１０２は、ウイルスＳＣ１０６の検査情報を参照して、ステータスが検査中の検査依頼に関する情報を検索結果として検査者装置１４へ送信する（Ｓ１２２）。検査依頼に関する情報は、ウイルスＳＣ１０６の検査情報に含まれる検体ハッシュ値、期限、報酬、評価完了検査者数（検査情報に記録された検査者数）、検体ＵＲＩを含み、さらに、アクターＳＣ１１０に記録された依頼者スコアと評価完了検査者のスコアを含む。検査者装置１４は検索結果を画面に表示させる。
　検査者は、検索結果を確認し、自分が検査する検体（以下「対象検体」と呼ぶ。）を決定する。検査者装置１４の検体取得部１４２は、対象検体の検体ＵＲＩをもとに、対象検体をファイルサーバ１８からダウンロードする（Ｓ１２４）。ファイルサーバ１８は、対象検体のデータを検査者装置１４へ送信する（Ｓ１２６）。検査者装置１４の検体照合部１４４は、ファイルサーバ１８から取得した対象検体のデータのハッシュ値を取得し、ポータルサーバ１０２から取得した対象検体のハッシュ値との同一性を確認する（Ｓ１２８）。これにより、ファイルサーバ１８から取得した対象検体のデータが改ざんされていないこと、すなわち、オリジナルのデータであることを確認する。
　検査者は、対象検体がマルウェアか否かを検査し、対象検体がマルウェアか（「黒」）否か（「白」）を示すデータを少なくとも含む評価レポートを作成する。検査者が評価コミットを指示する操作を検査者装置１４へ入力すると、検査者装置１４のレポート登録部１４６は、評価レポートを依頼者の公開鍵で暗号化する（Ｓ１３０）。レポート登録部１４６は、評価レポートをファイルサーバ１８へアップロードする（Ｓ１３２）。ファイルサーバ１８は、検査者装置１４から送信された評価レポートのデータを所定の記憶領域に保存する（Ｓ１３４）。ファイルサーバ１８は、保存した評価レポートに対してファイルサーバ１８におけるユニークなＩＤであるレポートＵＲＩを発行し、レポートＵＲＩを検査者装置１４へ送信する（Ｓ１３６）。検査者装置１４のレポート登録部１４６は、レポートＵＲＩを取得する。
　検査者装置１４の評価コミット部１４８は、所定の乱数発生器が生成したノンスを取得する（Ｓ１３８）。評価コミット部１４８は、評価に関する複数の属性データをパラメータとして、ウイルスＳＣ１０６の評価コミットメソッドを呼び出す（Ｓ１４０）。評価に関する複数の属性データは、評価レポートのハッシュ値、対象検体が「白」か「黒」を示す値とノンスとを結合したデータのハッシュ値（「評価ハッシュ値」とも呼ぶ。）、レポートＵＲＩを含む。評価レポートのハッシュ値を含めることにより、将来、検査者が、当該評価レポートを作成していないと否認することができないようにする。
　ウイルスＳＣ１０６の評価コミット処理部１８２は、上記複数の属性データをもとに検査情報を更新し、例えば、検査者設定項目２０４または検査者設定項目２０６を記録する（Ｓ１４２）。この際、検査者設定項目の最終コミットフラグは、「未コミット」に設定される。また、ウイルスＳＣ１０６の評価コミット処理部１８２は、検査者のデポジットとして、所定量のトークンを、トークンＳＣ１０８の検査者口座から検査依頼口座へ振り替える（Ｓ１４４）。
　図１９は、依頼者の結果判定に関する動作を示すフローチャートである。検査依頼において指定した期限に達すると、依頼者装置１２のレポート取得部１２６は、ウイルスＳＣ１０６の検査情報を参照して、検査依頼した検体（検体ハッシュ値）に対応付けられたレポートＵＲＩを取得する。レポート取得部１２６は、レポートＵＲＩにより特定される評価レポートをファイルサーバ１８に要求する（Ｓ１５０）。ファイルサーバ１８は、依頼者装置１２から要求された評価レポートのデータを依頼者装置１２へ送信する（Ｓ１５２）。依頼者装置１２のレポート取得部１２６は、評価レポートを依頼者の秘密鍵で復号する（Ｓ１５４）。
　レポート取得部１２６は、復号した評価レポートのデータをハッシュ関数へ入力してハッシュ値を取得するとともに、ウイルスＳＣ１０６の検査情報に記録された当該評価レポートのハッシュ値を取得する。レポート取得部１２６は、両者のハッシュ値の同一性を確認する（Ｓ１５６）。これにより、評価レポートが改ざんされていないことを確認する。依頼者装置１２は、Ｓ１５０～Ｓ１５６の処理を、検体を評価した検査者の数、言い換えれば、当該検体に対する評価レポートの数だけ繰り返す。依頼者は、１人以上の検査者による１つ以上の評価レポートの内容を確認して、検査依頼対象の検体がマルウェアか否か（すなわち黒か白か）を総合的に判定する。以下、この判定を「白黒判定」とも呼ぶ。
　依頼者は、白黒判定の結果を登録するための結果コミットを指示する操作を検査者装置１４へ入力する。検査者装置１４のノンス登録部１２８は、白黒判定の結果に付加する結果ノンスを生成し（Ｓ１５８）、検体ハッシュ値と結果ノンスとをポータルサーバ１０２へ送信する（Ｓ１６０）。ポータルサーバ１０２は、検体ハッシュ値と結果ノンスとを対応付けて保存する（Ｓ１６２）。
　依頼者装置１２の結果コミット部１３０は、白黒判定結果に関する複数の属性データをパラメータとして、ウイルスＳＣ１０６の結果コミットメソッドを呼び出す（Ｓ１６４）。白黒判定結果に関する複数の属性データは、検体が「白」か「黒」かを示す値と結果ノンスとを結合したデータのハッシュ値（以下「結果ハッシュ値」とも呼ぶ。）、正解者のアドレスの配列、白黒判定結果を閲覧するための閲覧料を含む。正解者は、依頼者により評価結果が正解と認定された検査者であり、言い換えれば、依頼者の白黒判定と同じ評価を下した検査者である。また、閲覧料は、依頼者が任意に決定する。ウイルスＳＣ１０６の結果コミット処理部１８４は、上記複数の属性データをもとに検査情報を更新し、例えば、図１６の依頼者設定項目２０２を記録する（Ｓ１６６）。
　図２０は、検査者による最終コミットに関する動作を示すフローチャートである。最終コミットは、依頼者の白黒判定結果の承認とも言える。検査者装置１４のノンス取得部１５０は、検査者が評価した検体のハッシュ値をキーとしてポータルサーバ１０２に結果ノンスを要求する（Ｓ１７０）。ポータルサーバ１０２は、結果ノンス要求元の検査者が、上記検体ハッシュ値をキーとするウイルスＳＣ１０６の検査情報に記録されている場合、すなわち正当な検査者である場合、結果ノンスの提供を許可する（Ｓ１７２）。ポータルサーバ１０２は、正当な検査者の検査者装置１４へ結果ノンスを送信する（Ｓ１７４）。検査者装置１４のノンス取得部１５０は、結果ノンスを取得する。
　検査者装置１４の結果確認部１５２は、ウイルスＳＣ１０６の検査情報から、結果ハッシュ値を取得する。結果確認部１５２は、予め定められた「白」の値に結果ノンスを結合したデータのハッシュ値と、予め定められた「黒」の値に結果ノンスを結合したデータのハッシュ値と、結果ハッシュ値とを比較することにより、依頼者の白黒判定結果が「白」か「黒」かを判定する（Ｓ１７６）。すなわち、結果確認部１５２は、予め定められた「白」の値に結果ノンスを結合したデータのハッシュ値が結果ハッシュ値に一致する場合、依頼者が「白」と判定したことを識別する。また、結果確認部１５２は、予め定められた「黒」の値に結果ノンスを結合したデータのハッシュ値が結果ハッシュ値に一致する場合、依頼者が「黒」と判定したことを識別する。
　結果確認部１５２は、依頼者が検体を正当なもの（「白」）と判定したか、マルウェア（「黒」）と判定したかを画面に表示させてもよい。またＳ１７６において、結果確認部１５２は、ウイルスＳＣ１０６の検査情報から、正解者アドレスの配列を取得し、画面に表示させる。結果確認部１５２は、検査者装置１４の検査者のアドレスが正解者アドレスの配列に含まれるか否かを画面に表示させてもよい。
　検査者は、依頼者の白黒判定結果が自分の評価結果と同じである場合、すなわち自分が正解者である場合、自分のアドレスが正解者アドレスの配列に含まれていることを確認する。依頼者の白黒判定結果および正解者の認定を承認する場合、検査者は、最終コミットを指示する操作を検査者装置１４へ入力する。検査者装置１４の最終コミット部１５４は、検体ハッシュ値および検査者アドレスを含むパラメータを用いて、ウイルスＳＣ１０６の最終コミットメソッドを呼び出す（Ｓ１７８）。
　ウイルスＳＣ１０６の最終コミット処理部１８６は、検査者装置１４から送信されたパラメータをもとに検査情報を更新する（Ｓ１８０）。例えば、最終コミット処理部１８６は、検査者設定項目の最終コミットフラグを「コミット済」に変更する。
　最終コミット処理部１８６の検査者評価部１８８は、検査情報の正解者アドレスを参照し、最終コミットを行った検査者（「対象検査者」とも呼ぶ。）が正解者か否かに応じて、対象検査者のスコアを調整する（Ｓ１８２）。例えば、対象検査者が正解者である場合、検査者評価部１８８は、アクターＳＣ１１０に記録された対象検査者のスコアをそれまでより大きい値に変更する。また、対象検査者が正解者でない場合、検査者評価部１８８は、対象検査者のスコアをそれまでより小さい値に変更する。ウイルスＳＣ１０６は、エクスターナルコールにより、アクターＳＣ１１０に記録されたスコアを更新してもよい。
　最終コミット処理部１８６のトークン振替部１９０は、検査者装置１４から送信された検査者アドレスをもとに、検査依頼口座に記録された当該検査者のデポジットを当該検査者の口座へ振り替える（Ｓ１８４）。言い換えれば、トークン振替部１９０は、評価レポート登録時に検査者から預かったトークンを、最終コミット時に当該検査者の口座へ返還する。
　なお、１つの検体に対して複数の検査者がいる場合の最後の検査者による最終コミット時、検査者が１人であればその１人の検査者による最終コミット時、トークン振替部１９０は、さらに以下の処理を実行する。（１）トークン振替部１９０は、正解者と認定された検査者に報酬を分配する。この場合、トークン振替部１９０は、アクターＳＣ１１０を参照して、各正解者のスコアを参照し、相対的にスコアが高い検査者に対して、相対的に大きい報酬を割り当てる。また、（２）トークン振替部１９０は、検査依頼口座に記録された手数料を主催者の口座へ振り替える。
　また、（３）トークン振替部１９０は、検査依頼口座に記録された依頼者のデポジットを依頼者の口座へ振り替える。言い換えれば、トークン振替部１９０は、検査依頼時に依頼者から預かったトークンを、依頼者の口座へ返還する。また、最終コミット処理部１８６は、依頼者設定項目におけるステータスを「検査完了済」に更新する。なお、最終コミット処理部１８６は、或る検体の検査情報に記録された１つ以上の検査者設定項目における最終コミットフラグが全てコミット済になった場合に、その検体の全ての検査者が最終コミットを行ったことを検出してもよい。
　図２１は、検査結果閲覧時の動作を示すフローチャートである。閲覧者装置１６の検体検索部１６０は、閲覧候補となる検体の検索要求をポータルサーバ１０２へ送信する（Ｓ１９０）。ポータルサーバ１０２は、ステータスが検査完了済の検体情報を含む検索結果を閲覧者装置１６へ送信する（Ｓ１９２）。上記の検体情報は、ウイルスＳＣ１０６の検査情報に含まれる検体ハッシュ値、ステータス、閲覧料、依頼者アドレス、１つ以上の検査者アドレス、１つ以上の正解者アドレスを含む。さらに、アクターＳＣ１１０に記録された依頼者スコアと検査者スコアを含む。
　閲覧者装置１６の閲覧実行部１６２は、検体アドレスおよび閲覧者アドレスを含むパラメータを用いて、ウイルスＳＣ１０６の閲覧処理メソッドを呼び出す（Ｓ１９４）。ウイルスＳＣ１０６の閲覧処理部１９２は、トークンＳＣ１０８において、閲覧料分のトークンを閲覧者口座から依頼者口座へ振り替える。また、閲覧処理部１９２は、予め定められた手数料分のトークンを閲覧者口座から主催者口座へ振り替える。また、閲覧処理部１９２は、今回の閲覧用の口座をトークンＳＣ１０８に記録し、閲覧者のデポジットとして、予め定められた量のトークンを、閲覧者口座から今回の閲覧用口座へ振り替える（Ｓ１９６）。
　また、Ｓ１９４において、閲覧者装置１６の閲覧実行部１６２は、検体アドレスおよび閲覧者アドレスを含む閲覧要求をポータルサーバ１０２へ送信する。ポータルサーバ１０２は、閲覧者アドレスを用いて、閲覧者が閲覧料を支払い済みであることを確認する（Ｓ１９８）。閲覧者が閲覧料を支払い済みであれば、ポータルサーバ１０２は、検体アドレスに対応付けられた結果ノンス（Ｓ１６２で保存した結果ノンス）を閲覧者装置１６へ送信する（Ｓ２００）。閲覧者装置１６の閲覧実行部１６２は、結果ノンスを取得する。
　閲覧者装置１６の閲覧実行部１６２は、ウイルスＳＣ１０６の検査情報から、閲覧対象検体の結果ハッシュ値を取得する。閲覧実行部１６２は、予め定められた「白」の値に結果ノンスを結合したデータのハッシュ値と、予め定められた「黒」の値に結果ノンスを結合したデータのハッシュ値と、結果ハッシュ値とを比較することにより、閲覧対象検体に対する白黒判定結果が「白」か「黒」かを判定する（Ｓ２０２）。ここでの白黒判定結果は、閲覧対象検体の依頼者による最終的な判定結果である。閲覧実行部１６２は、閲覧対象検体の白黒判定結果が「白」か「黒」かを画面に表示させてもよい。
　閲覧者は、白黒判定結果を確認後、依頼者を評価し、評価結果を閲覧者装置１６へ入力する。典型的には、閲覧者は、依頼者の白黒判定結果が正しい場合、高い評価値を設定する一方、依頼者の白黒判定結果が誤っている場合、低い評価値を設定する。依頼者の白黒判定結果が誤っているとは、例えば、依頼者が閲覧対象検体を正当なもの（「白」）と判定しながら、実際には閲覧対象検体がマルウェア（「黒」）だった場合や、逆に、依頼者が閲覧対象検体をマルウェア（「黒」）と判定しながら、実際には閲覧対象検体が正当なもの（「白」）だった場合である。閲覧者装置１６の依頼者評価部１６４は、閲覧者アドレスおよび依頼者の評価値をパラメータとして、ウイルスＳＣ１０６の依頼者評価メソッドを呼び出す（Ｓ２０４）。
　ウイルスＳＣ１０６の依頼者評価処理部１９４は、閲覧者装置１６から送信された依頼者の評価値をもとに、依頼者のスコアを調整する（Ｓ２０６）。例えば、依頼者の評価値が高い場合、依頼者評価処理部１９４は、アクターＳＣ１１０に記録された依頼者スコアをそれまでより大きい値に変更してもよい。逆に、依頼者の評価値が低い場合、依頼者評価処理部１９４は、アクターＳＣ１１０に記録された依頼者スコアをそれまでより小さい値に変更してもよい。また、依頼者評価処理部１９４は、閲覧用口座に記録された閲覧者のデポジットを閲覧者の口座へ振り替える（Ｓ２０８）。言い換えれば、依頼者評価処理部１９４は、閲覧実行時に閲覧者から預かったトークンを、依頼者評価時に閲覧者口座へ返還する。
　以上、本発明を第２実施例をもとに説明した。この第２実施例は例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
　変形例を説明する。第２実施例では言及していないが、検査システム１０１は、ある依頼者が登録した検査依頼に対して、他者が協賛可能な仕組みを備えてもよい。図２２は、変形例の検査システム１０１の構成を示す。検査システム１０１は、第２実施例の構成に加えて、協賛者装置２１０を備える。協賛者装置２１０は、協賛者により操作される情報処理装置である。協賛者は、依頼者が登録した検体の検査に協賛するユーザであり、言い換えれば、依頼者とともに同じ検体の検査を依頼するユーザである。なお、或る検体の検査に対する協賛者は、他の検体の検査では依頼者、検査者、または閲覧者になることもある。
　図２３は、変形例における検査情報の例を示す。本変形例では、依頼者装置１２およびウイルスＳＣ１０６は、検査依頼登録時に、協賛可否フラグと報酬上限額をさらに設定する。協賛可否フラグは、他者の協賛を許可すること（「協賛可」）、または、他者の協賛を禁止すること（「協賛不可」）のいずれかに設定される。報酬上限額は、協賛可否フラグが協賛可の場合に設定される。報酬上限額には、協賛者により加算後の報酬額の上限である。
　協賛者が検体の検査に協賛する目的は、報酬額を上げることによって検査者の意欲を向上させ、活発な評価を促すことと、閲覧料の分配を受けることである。全ての検査者が最終コミットを行った際、ウイルスＳＣ１０６のトークン振替部１９０は、依頼者の報酬額と協賛者の加算額の合計を、１人以上の正解者に対して分配する。また、トークン振替部１９０は、閲覧者が支払った閲覧料を、依頼者と協賛者との間で報酬の分担率に応じて分配する。例えば、依頼者の報酬額が８０トークン、協賛者の加算額が２０トークン、閲覧料が１０トークンの場合、トークン振替部１９０は、８トークンを閲覧者の口座から依頼者の口座へ振り替え、２トークンを閲覧者の口座から協賛者の口座へ振り替えてもよい。
　上記の例において、協賛者がいなければ、依頼者は１回の閲覧あたり１０トークンを得ることができたが、協賛者がいるため、１回の閲覧あたりの収益は８トークンとなる。また、閲覧者が１回の閲覧あたり１０トークンを得るためには、閲覧料を約１３トークンにする必要があるが、そうすると閲覧者が減少する可能性がある。このような収益の減少を調整するための設定項目が、協賛可否フラグと報酬上限額である。例えば、依頼者は、報酬額、報酬上限額、および閲覧料を調整することで、１回の閲覧あたりの収益を任意に調整することができる。依頼者は、検査の活発化と、自身の収益とを比較衡量して、協賛可否フラグおよび報酬上限額を設定する。
　図２４は、図２２の協賛者装置２１０の機能ブロックを示すブロック図である。協賛者装置２１０は、依頼者装置１２、表示部４２、通信部１１２、制御部４４を備える。制御部４４は、依頼検索部２１２と協賛部２１４を含む。
　依頼検索部２１２は、登録された１つ以上の検査依頼に関する情報をポータルサーバ１０２から取得する。例えば、依頼検索部２１２は、検査依頼の検索要求をポータルサーバ１０２へ送信する。ポータルサーバ１０２は、ウイルスＳＣ１０６の検査情報を参照して、ステータスが検査中の検査依頼に関する情報を検索結果として協賛者装置２１０へ送信する。検査依頼に関する情報は、ウイルスＳＣ１０６の検査情報に含まれる検体ハッシュ値、期限、報酬、評価完了検査者数（検査情報に記録された検査者数）、検体ＵＲＩを含む。さらに、アクターＳＣ１１０に記録された依頼者スコアと評価完了検査者のスコアを含む。なお、ポータルサーバ１０２は、協賛可否フラグが協賛可に設定された検査依頼の情報のみを協賛者装置２１０へ送信してもよい。協賛者装置２１０は、検索結果を画面に表示させる。
　協賛部２１４は、協賛者により協賛対象として選択された検査依頼を指定するパラメータを用いて、ウイルスＳＣ１０６の協賛処理メソッドを呼び出す。上記パラメータは、協賛対象の検査依頼のキーである検体ハッシュ値と、報酬加算額（すなわち既定の報酬への上乗せ額）を含む。ウイルスＳＣ１０６の協賛処理部（不図示）は、検体ハッシュ値により特定される検査情報を、上記パラメータを用いて更新する。例えば、ウイルスＳＣ１０６の協賛処理部は、図２３の協賛者設定項目２２０を検査情報に設定する。なお、協賛者は、結果コミットが不要であるため、結果コミットのインセンティブとなるデポジットも不要である。
　第２実施例および変形例に記載の検査システム１０１の構成と動作は次のように表現することができる。
［項目１］
　依頼者装置１２は、検査対象データを所定領域へ記録するとともに、検査の報酬をブロックチェーンシステム１０４へ記録する。一つ以上の検査者装置１４のそれぞれは、依頼者装置１２により記録された検査対象データを取得して、検査対象データに対する検査結果（例えば評価レポート）を所定領域へ記録する。依頼者装置１２は、一つ以上の検査者装置１４により記録された一つ以上の検査結果を取得し、依頼者により検査結果が正解と認定された検査者である正解者のデータ（例えば正解者アドレスの配列）をブロックチェーンシステム１０４へ記録する。ブロックチェーンシステム１０４（例えばウイルスＳＣ１０６）は、正解者に対して検査の報酬を分配する。
　この構成によると、依頼者は、一人以上の検査者による電子データの検査結果を得ることができ、一人以上の検査者のうち正解者は、報酬を得ることができるビジネスモデルを実現できる。また、報酬の支払いにブロックチェーンシステムを利用することで、依頼者は、個々の検査者への信用を持たない場合でも簡単に送金（言い換えれば価値の移転）を行うことができる。また、少額の送金の繰り返しも容易に実現できる。また、報酬の支払いに関する改ざんも防止することができる。
［項目２］
　ブロックチェーンシステム１０４（例えばアクターＳＣ１１０）は、一人以上の検査者それぞれのスコアを記憶する。各検査者のスコアは、検査結果（例えば白または黒の評価結果）が正解か否かに応じて変更される。ブロックチェーンシステム１０４は、検査結果が正解となった一人以上の検査者の中で、スコアが相対的に高い検査者に対して相対的に高い報酬を分配する。
　この構成によると、検査者に対して、正しい評価結果を作成すること、言い換えれば、誠実に評価することへのインセンティブを提供できる。
［項目３］
　一つ以上の検査者装置１４のそれぞれは、正解者のデータをブロックチェーンシステム１０４から取得し、正解者のデータが検査者により承認（例えば最終コミット）された場合、正解者承認の旨をブロックチェーンシステム１０４へ記録する。ブロックチェーンシステム１０４は、全ての検査者装置１４から正解者承認の旨が記録された場合、正解者に対して検査の報酬を分配する
　この構成によると、依頼者による正解者の認定を、当該依頼者による検査依頼に対応した全ての検査者が承認したことを条件として、正解者へ報酬を分配する。これにより、各検査者にとって納得のいく報酬分配を実現できる。
［項目４］
　依頼者装置１２は、検査対象データを記録する際（例えば検査依頼時）、依頼者が保有する通貨（例えばトークン）の少なくとも一部を預り金としてブロックチェーンシステム１０４（例えばトークンＳＣ１０８）へ記録する。ブロックチェーンシステム１０４は、全ての検査者装置１４から正解者承認の旨が記録された場合、預り金を依頼者へ返還する。
　この構成によると、依頼者による検査依頼に対応した全ての検査者の承認を条件として依頼者へデポジットを返還することにより、検査者からの異議申立に対して真摯に対応することへのインセンティブを依頼者に提供できる。例えば、或る検査者の評価結果が正解（依頼者の白黒判定結果と同じ）であったにも関わらず、依頼者が認定した正解者の中に当該検査者が含まれなかった場合、当該検査者は依頼者へ異議申し立てを行う。これを受けた依頼者は、当該検査者を正解者アドレスの配列に含める等の作業を行う。
［項目５］
　一つ以上の検査者装置１４のそれぞれは、検査結果を記録する際（例えば評価コミット時）、検査者が保有する通貨の少なくとも一部を預り金としてブロックチェーンシステム１０４（例えばトークンＳＣ１０８）へ記録する。ブロックチェーンシステム１０４は、或る検査者装置１４から正解者承認の旨が記録された場合、その検査者装置１４に対応する検査者へ預り金を返還する。
　不正解となった検査者は、依頼者による正解者の認定に対する承認を怠ることが考えられるが、その承認をデポジット返還の条件とすることで、依頼者による正解者の認定に対して承認を行うことへのインセンティブを検査者に提供できる。これにより、全ての検査者の納得の下、検査者のスコアを調整し、また、報酬を分配することができる。
［項目６］
　一つ以上の検査者装置１４のそれぞれは、検査結果（例えば白黒判定結果）を記録する際に、検査結果と乱数値とを結合したデータのハッシュ値（例えば図１６の評価ハッシュ値）をブロックチェーンシステム１０４へ記録する。
　この構成によると、一つ以上の検査者装置１４は、各々の乱数値を保存しておくことで自身の評価結果を事後に証明でき、また、上記ハッシュ値をブロックチェーンシステム１０４へ記録することにより検査結果の改ざんを防止することができる。
［項目７］
　依頼者装置１２は、検査結果（例えば白黒判定結果）と、検査結果の閲覧料とをブロックチェーンシステム１０４（例えばウイルスＳＣ１０６）へ記録する。閲覧者装置１６は、閲覧者が保有する通貨から閲覧料を依頼者に支払う処理をブロックチェーンシステム１０４に実行させる。
　依頼者は、検査結果の閲覧により収益を上げることができるため、検査を依頼することへのインセンティブを依頼者に提供できる。また、閲覧料の支払いに関する改ざんも防止することができる。
［項目８］
　依頼者装置１２は、検査結果と乱数とを結合したデータのハッシュ値（例えば図１６の結果ハッシュ値）をブロックチェーンシステム１０４（例えばウイルスＳＣ１０６）へ記録するとともに、上記乱数をポータルサーバ１０２へ通知する。ポータルサーバ１０２は、閲覧者から依頼者へ閲覧料が支払われた場合、上記乱数を閲覧者装置１６へ通知することにより、閲覧者装置１６において検査結果を識別可能にする。
　ブロックチェーンシステム１０４のスマートコントラクトは、検査システム１０１の各装置で共有されるため、検査システム１０１の各装置は、スマートコントラクトから検査結果のデータを得ることができる。しかし、上記構成とすることで、閲覧料を支払わずに検査結果（すなわち検体が白か黒か）が確認されてしまうことを防止できる。
［項目９］
　依頼者装置１２は、検査対象データを記録する際、依頼者が保有する通貨の少なくとも一部を手数料としてブロックチェーンシステム１０４へ記録する。ブロックチェーンシステム１０４は、依頼者のスコアを記憶し、上記手数料を依頼者のスコアに応じて決定する。閲覧者装置１６は、閲覧者により入力された依頼者の評価をブロックチェーンシステム１０４へ記録することにより、ブロックチェーンシステム１０４に記憶された依頼者のスコアを調整させる。
　この構成によると、手数料を低額にするために自身のスコアを良くしようとするインセンティブを依頼者に与え、すなわち、検体の白黒を適切に判定することへのインセンティブを依頼者に与えることができる。
［項目１０］
　閲覧者装置１６は、検査結果を取得する際、閲覧者が保有する通貨の少なくとも一部を預り金としてブロックチェーンシステム１０４へ記録する。ブロックチェーンシステム１０４は、検査者装置１４から依頼者の評価が記録された場合、預り金を閲覧者へ返還する。
　この構成によると、依頼者の評価を行うことへのインセンティブを閲覧者に与えることができる。
［項目１１］
　協賛者装置２１０は、検査の報酬の上乗せ額をブロックチェーンシステム１０４（例えばウイルスＳＣ１０６）へ記録する。ブロックチェーンシステム１０４は、上乗せ後の報酬を、当該検査を行った検査者のうち正解者に対して分配する。
　この構成によると、報酬額を加算する仕組みを設けることにより、検査者の意欲を喚起し、検査の活発化を実現することができる。
［項目１２］
　依頼者装置１２は、検査対象データを記録する際、報酬の上限額をブロックチェーンシステム１０４へ記録する。協賛者装置２１０による報酬の上乗せ額は、上記の上限額により制限される。ブロックチェーンシステム１０４は、閲覧者が支払った閲覧料を、依頼者と協賛者との間で報酬の分担率に応じて分配する。
　この構成によると、依頼者は、報酬の上限額を設定することにより、閲覧料の取り分、言い換えれば、協賛者との閲覧料の分配率を任意に調整することができる。
［項目１３］
　検査システム１０１は、依頼者装置１２を含まない構成、すなわち複数の検査者装置１４と閲覧者装置１６のみで構成してもよい。この構成では、検査者は、日常的あるいは定期的に通信データ（例えばパケット等のデータ）等の検査対象を監視してもよい。検査者は、例えば、不正なデータ通信や不正なアクセス、すなわち所定のパターンやポリシーとは異なるパターンを抽出してルール化してもよく、言い換えれば、異常パターンを定義してもよい。検査者装置１４は、上記ルール（言い換えれば上記異常パターン）をシグネチャとして評価レポートに記録し、評価レポートとその閲覧に必要な報酬額を含む情報共有オファーをブロックチェーンシステム１０４に登録してもよい。すなわち、検査者は依頼を受けなくても、自発的に検索を実施して検査結果や対策方法等を含む評価レポートをブロックチェーンシステム１０４に登録してもよい。閲覧者は、上記第２実施例と同様の仕組みにより、情報共有オファーを閲覧して検査者が設定した報酬額を支払う。閲覧したシグネチャの内容が有効であれば、閲覧者は、検査者に良い評価を付与し、または、追加の報酬を支払ってもよい。閲覧したシグネチャが有効でない場合、閲覧者は検査者に悪い評価を付与してもよく、または、閲覧者が支払った閲覧料が主催者に回収されるようにしてもよい。なお、この構成に、協賛者装置２１０が備わるようにしてもよい。
　項目１３の構成によると、依頼者の検査依頼がなくても、検査者が主体的に不正な検体やセキュリティ上の欠陥等を検査して有償で情報公開したり、あるいは上記のように不正アクセスを検知するためのシグネチャを作成して有償で情報提供したりすることが可能になる。閲覧者（例えばセキュリティソフトウェア提供企業等）は、効率的にセキュリティ対策することが可能になる。また、検査者は、報酬を得られることで、より意欲的に不正なデータや情報アクセスの検知を監視するようになることが期待される。
　上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。
　１０　検査システム、　１２　依頼者装置、　１４　検査者装置、　１６　閲覧者装置、　１８　ファイルサーバ、　２２　ブロックチェーンネットワーク、　５４　被験データ登録部、　６４　被験データ取得部、　７２　検査結果取得部、　７４　送金部、　７６　検査結果出力部、　１０１　検査システム、　１０２　ポータルサーバ、　１０４　ブロックチェーンシステム、　２１０　協賛者装置。
　本発明は、電子データを検査するシステムに適用できる。

Claims (20)

  1. 　検査対象データを所定領域へ記録する第１の装置と、
    　前記検査対象データが不正か否かを検査するユーザにより操作される第２の装置と、
    　前記検査対象データに対する検査結果を使用する第３の装置と、
    　を備え、
    　前記第２の装置は、前記第１の装置により記録された検査対象データを取得して、前記検査対象データに対する検査結果を所定領域へ記録し、
    　前記第３の装置は、前記第２の装置により記録された検査結果を取得することを特徴とする検査システム。
  2. 　前記第１の装置は、前記検査対象データに関する属性情報を所定のブロックチェーンネットワークへ記録し、
    　前記第２の装置は、前記ブロックチェーンネットワークから前記属性情報を取得し、取得した属性情報に基づいて前記検査対象データを取得することを特徴とする請求項１に記載の検査システム。
  3. 　前記第１の装置は、前記検査対象データを前記ブロックチェーンネットワークの外部の装置に記録し、
    　前記第２の装置は、前記属性情報が示すアドレスに基づいて、前記外部の装置から前記検査対象データを取得することを特徴とする請求項２に記載の検査システム。
  4. 　前記第２の装置は、前記検査結果を所定のブロックチェーンネットワークへ記録し、
    　前記第３の装置は、前記ブロックチェーンネットワークから前記検査結果を取得することを特徴とする請求項１から３のいずれかに記載の検査システム。
  5. 　前記第３の装置は、前記検査結果を取得する場合に、前記第１の装置のユーザと、前記第２の装置のユーザへの報酬支払処理を実行することを特徴とする請求項１から４のいずれかに記載の検査システム。
  6. 　検査の依頼者により操作される依頼者装置と、
    　一人以上の検査者により操作される一つ以上の検査者装置と、
    　前記依頼者装置と前記検査者装置とがアクセス可能なブロックチェーンシステムと、
    　を備え、
    　前記依頼者装置は、検査対象データを所定領域へ記録するとともに、検査の報酬を前記ブロックチェーンシステムへ記録し、
    　前記検査者装置は、前記依頼者装置により記録された検査対象データを取得して、検査対象データに対する検査結果を所定領域へ記録し、
    　前記依頼者装置は、前記検査者装置により記録された検査結果を取得し、依頼者により検査結果が正解と認定された検査者である正解者のデータを前記ブロックチェーンシステムへ記録し、
    　前記ブロックチェーンシステムは、正解者に対して検査の報酬を分配することを特徴とする検査システム。
  7. 　前記ブロックチェーンシステムは、一人以上の検査者それぞれのスコアを記憶し、各検査者のスコアは、検査結果が正解か否かに応じて変更されるものであり、
    　前記ブロックチェーンシステムは、検査結果が正解となった一人以上の検査者の中で、スコアが相対的に高い検査者に対して相対的に高い報酬を分配することを特徴とする請求項６に記載の検査システム。
  8. 　前記一つ以上の検査者装置のそれぞれは、正解者のデータを前記ブロックチェーンシステムから取得し、正解者のデータが検査者により承認された場合、正解者承認の旨を前記ブロックチェーンシステムへ記録し、
    　前記ブロックチェーンシステムは、全ての検査者装置から正解者承認の旨が記録された場合、正解者に対して検査の報酬を分配することを特徴とする請求項６または７に記載の検査システム。
  9. 　前記依頼者装置は、検査対象データを記録する際、依頼者が保有する通貨の少なくとも一部を預り金として前記ブロックチェーンシステムへ記録し、
    　前記ブロックチェーンシステムは、全ての検査者装置から正解者承認の旨が記録された場合、預り金を依頼者へ返還することを特徴とする請求項８に記載の検査システム。
  10. 　前記一つ以上の検査者装置のそれぞれは、検査結果を記録する際、検査者が保有する通貨の少なくとも一部を預り金として前記ブロックチェーンシステムへ記録し、
    　前記ブロックチェーンシステムは、或る検査者装置から正解者承認の旨が記録された場合、前記或る検査者装置に対応する検査者へ預り金を返還することを特徴とする請求項８または９に記載の検査システム。
  11. 　前記一つ以上の検査者装置のそれぞれは、検査結果を記録する際に、検査結果と乱数値とを結合したデータのハッシュ値を前記ブロックチェーンシステムへ記録することを特徴とする請求項８から１０のいずれかに記載の検査システム。
  12. 　検査結果の閲覧者により操作される閲覧者装置をさらに備え、
    　前記依頼者装置は、検査結果と、検査結果の閲覧料とを前記ブロックチェーンシステムへ記録し、
    　前記閲覧者装置は、閲覧者が保有する通貨から閲覧料を依頼者に支払う処理を前記ブロックチェーンシステムに実行させることを特徴とする請求項６から１１のいずれかに記載の検査システム。
  13. 　管理装置をさらに備え、
    　前記依頼者装置は、前記検査結果として、前記検査結果と乱数とを結合したデータのハッシュ値を前記ブロックチェーンシステムへ記録するとともに、前記乱数を前記管理装置へ通知し、
    　前記管理装置は、閲覧者から依頼者へ閲覧料が支払われた場合、前記乱数を前記閲覧者装置へ通知することにより、前記閲覧者装置において検査結果を識別可能にすることを特徴とする請求項１２に記載の検査システム。
  14. 　前記依頼者装置は、検査対象データを記録する際、依頼者が保有する通貨の少なくとも一部を手数料として前記ブロックチェーンシステムへ記録し、
    　前記ブロックチェーンシステムは、依頼者のスコアを記憶し、前記手数料を依頼者のスコアに応じて決定し、
    　前記閲覧者装置は、閲覧者により入力された依頼者の評価を前記ブロックチェーンシステムへ記録することにより、前記ブロックチェーンシステムに記憶された依頼者のスコアを調整させることを特徴とする請求項１２または１３に記載の検査システム。
  15. 　前記閲覧者装置は、検査結果を取得する際、閲覧者が保有する通貨の少なくとも一部を預り金として前記ブロックチェーンシステムへ記録し、
    　前記ブロックチェーンシステムは、前記閲覧者装置から依頼者の評価が記録された場合、預り金を閲覧者へ返還することを特徴とする請求項１４に記載の検査システム。
  16. 　前記検査対象データの検査に協賛する協賛者により操作される協賛者装置をさらに備え、
    　前記協賛者装置は、検査の報酬の上乗せ額を前記ブロックチェーンシステムへ記録し、
    　前記ブロックチェーンシステムは、上乗せ後の報酬を正解者に対して分配することを特徴とする請求項６から１５のいずれかに記載の検査システム。
  17. 　前記依頼者装置は、検査対象データを記録する際、報酬の上限額を前記ブロックチェーンシステムへ記録し、
    　前記協賛者装置による報酬の上乗せ額は、前記上限額により制限され、
    　前記ブロックチェーンシステムは、閲覧者が支払った閲覧料を、依頼者と協賛者との間で報酬の分担率に応じて分配することを特徴とする請求項１６に記載の検査システム。
  18. 　第１の装置が、検査対象データを所定領域へ記録するステップと、
    　前記検査対象データが不正か否かを検査するユーザにより操作される第２の装置が、前記第１の装置により記録された検査対象データを取得するステップと、
    　前記第２の装置が、前記検査対象データに対する検査結果を所定領域へ記録するステップと、
    　前記検査対象データに対する検査結果を使用する第３の装置が、前記第２の装置により記録された検査結果を取得するステップと、
    　を備えることを特徴とする検査方法。
  19. 　検査の依頼者により操作される依頼者装置が、検査対象データを所定領域へ記録するとともに、検査の報酬をブロックチェーンシステムへ記録するステップと、
    　一人以上の検査者により操作される一つ以上の検査者装置のそれぞれが、前記依頼者装置により記録された検査対象データを取得して、検査対象データに対する検査結果を所定領域へ記録するステップと、
    　前記依頼者装置が、前記一つ以上の検査者装置により記録された検査結果を取得し、依頼者により検査結果が正解と認定された検査者である正解者のデータを前記ブロックチェーンシステムへ記録するステップと、
    　前記ブロックチェーンシステムが、正解者に対して検査の報酬を分配するステップと、
    　を備えることを特徴とする検査方法。
  20. 　第１の装置から検査対象データを受け付ける機能と、
    　受け付けた検査対象データを、前記検査対象データが不正なデータか否かを検査するユーザにより操作される第２の装置へ提供する機能と、
    　前記第２の装置から前記検査対象データに対する検査結果を受け付ける機能と、
    　前記検査対象データに対する検査結果を要求した第３の装置へ前記検査結果を提供する機能と、
    　をコンピュータに実現させるためのコンピュータプログラム。
PCT/JP2018/014256 2017-04-03 2018-04-03 検査システム、検査方法、およびコンピュータプログラム WO2018186391A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
EP18781236.7A EP3608819B1 (en) 2017-04-03 2018-04-03 Checking system, checking method, and computer program
JP2018557060A JP6457165B1 (ja) 2017-04-03 2018-04-03 検査システムおよび検査方法
CN202310810821.0A CN116821908A (zh) 2017-04-03 2018-04-03 检测系统、检测方法、以及计算机程序
CN201880021436.5A CN110462619B (zh) 2017-04-03 2018-04-03 检测系统、检测方法、以及计算机程序
US16/591,915 US11074343B2 (en) 2017-04-03 2019-10-03 Inspection system, inspection method, and computer program
US17/354,481 US11741229B2 (en) 2017-04-03 2021-06-22 Inspection system, inspection method, and computer program
US18/351,697 US20230359735A1 (en) 2017-04-03 2023-07-13 Inspection system, inspection method, and computer program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017073830 2017-04-03
JP2017-073830 2017-04-03

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/591,915 Continuation US11074343B2 (en) 2017-04-03 2019-10-03 Inspection system, inspection method, and computer program

Publications (1)

Publication Number Publication Date
WO2018186391A1 true WO2018186391A1 (ja) 2018-10-11

Family

ID=63712236

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/014256 WO2018186391A1 (ja) 2017-04-03 2018-04-03 検査システム、検査方法、およびコンピュータプログラム

Country Status (5)

Country Link
US (3) US11074343B2 (ja)
EP (1) EP3608819B1 (ja)
JP (3) JP6457165B1 (ja)
CN (2) CN116821908A (ja)
WO (1) WO2018186391A1 (ja)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020149177A1 (ja) * 2019-01-16 2020-07-23 株式会社医療情報技術研究所 文書管理システム
JP2020166872A (ja) * 2020-05-27 2020-10-08 重政 河合 祭祀方法、コンピュータプログラム、及び祭祀審査装置
JP2020166381A (ja) * 2019-03-28 2020-10-08 重政 河合 祭祀方法、コンピュータプログラム、及び祭祀審査装置
JP2020190874A (ja) * 2019-05-21 2020-11-26 株式会社医療情報技術研究所 文書管理システム
JP2021182315A (ja) * 2020-05-20 2021-11-25 株式会社リーチ・ビデオジャパン Ｓｎｓにおける動画・画像コンテンツ投稿管理システム
JP2022516160A (ja) * 2018-12-31 2022-02-24 ザ インダストリー アンド アカデミック コオペレーション イン チュンナム ナショナル ユニバーシティー（アイエーシー） スマートコントラクト基盤の論文審査システム
WO2022074874A1 (ja) * 2020-10-05 2022-04-14 エヌ・ティ・ティ・コミュニケーションズ株式会社 情報取引管理システム、方法およびプログラム
WO2022195643A1 (ja) * 2021-03-13 2022-09-22 株式会社クエスト ブロックチェーンシステム、記憶装置及び管理装置
JP7260236B1 (ja) * 2022-11-28 2023-04-19 大学共同利用機関法人情報・システム研究機構 情報処理装置、情報処理システム、プログラムおよび情報処理方法
WO2023063392A1 (ja) * 2021-10-13 2023-04-20 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、サーバ、プログラム、及び、セキュリティ分析システム

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10650141B2 (en) * 2016-08-03 2020-05-12 Sophos Limited Mitigation of return-oriented programming attacks
WO2018186391A1 (ja) 2017-04-03 2018-10-11 株式会社野村総合研究所 検査システム、検査方法、およびコンピュータプログラム
WO2018189656A1 (en) * 2017-04-11 2018-10-18 nChain Holdings Limited Secure re-use of private key for dynamic group of nodes
JP7473911B2 (ja) 2020-04-21 2024-04-24 清水建設株式会社 施工情報管理システム、及び施工情報管理方法
JP7478440B2 (ja) 2021-03-25 2024-05-07 国立研究開発法人産業技術総合研究所 情報処理方法及び情報処理システム
JP7187085B1 (ja) * 2022-03-03 2022-12-12 株式会社Robot Consulting 情報処理システム、情報処理方法及びプログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160260095A1 (en) * 2015-03-02 2016-09-08 Dell Products, Lp Containerized Computational Task Execution Management Using a Secure Distributed Transaction Ledger
US20160261690A1 (en) * 2015-03-02 2016-09-08 Dell Products L.P. Computing device configuration and management using a secure decentralized transaction ledger
JP2017021779A (ja) 2015-06-30 2017-01-26 エーオー カスペルスキー ラボＡＯ Ｋａｓｐｅｒｓｋｙ Ｌａｂ ランダムアクセスメモリ内の悪質なコードを検出するためのシステムおよび方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4049740B2 (ja) * 2003-12-18 2008-02-20 富士通株式会社 ファイル転送結果のチエック方法、ファイル転送システム及びそのクライアント端末
US8756683B2 (en) * 2006-12-13 2014-06-17 Microsoft Corporation Distributed malicious software protection in file sharing environments
CN101399553B (zh) * 2008-11-12 2012-03-14 清华大学 一种可在线编程的准循环ldpc码编码器装置
US20150220928A1 (en) * 2014-01-31 2015-08-06 Robert Allen Platform for the purchase and sale of digital currency
CN106295333B (zh) * 2015-05-27 2018-08-17 安一恒通（北京）科技有限公司 用于检测恶意代码的方法和系统
US10223685B2 (en) * 2016-02-26 2019-03-05 Arithmetic Operations Incorporated Systems, methods, and media for pay-per-access micropayment-based web browsing and server applications
US10063572B2 (en) * 2016-03-28 2018-08-28 Accenture Global Solutions Limited Antivirus signature distribution with distributed ledger
US11651368B2 (en) * 2016-11-14 2023-05-16 American Express Travel Related Services Company, Inc. System and method for automated linkage of enriched transaction data to a record of charge
WO2018186391A1 (ja) 2017-04-03 2018-10-11 株式会社野村総合研究所 検査システム、検査方法、およびコンピュータプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160260095A1 (en) * 2015-03-02 2016-09-08 Dell Products, Lp Containerized Computational Task Execution Management Using a Secure Distributed Transaction Ledger
US20160261690A1 (en) * 2015-03-02 2016-09-08 Dell Products L.P. Computing device configuration and management using a secure decentralized transaction ledger
JP2017021779A (ja) 2015-06-30 2017-01-26 エーオー カスペルスキー ラボＡＯ Ｋａｓｐｅｒｓｋｙ Ｌａｂ ランダムアクセスメモリ内の悪質なコードを検出するためのシステムおよび方法

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
KAWAGUCHI, NOBUTAKA: "Queuing network model of anti-malware user support system", IPSJ JOURNAL, vol. 53, no. 11, 15 November 2012 (2012-11-15), pages 2584 - 2598, XP009517073, ISSN: 1882-7764 *
MAKOWSKI PAUL : "[Swarm Market. The first decentralized threat intelligence market]", 31 December 2017 (2017-12-31), pages 1 - 44, XP009519179, Retrieved from the Internet <URL:http://www.bigdatacon.jp/wp-content/uploads/sites/4/2017/10/Makowski_Swarm_JA.pdf> [retrieved on 20180607] *
NOYES, C. ET AL., FAST ANTI-MALWARE BY DISTRIBUTED BLOCKCHAIN CONSENSUS AND FEEDFORWARD SCANNING, 7 January 2016 (2016-01-07), XP055557844, Retrieved from the Internet <URL:https://arxiv.org/pdf/1601.01405.pdf> [retrieved on 20180607] *
RISA TAKAGI: "[Will the day when "anti-virus software" becomes open source come?: Vendors who advocate "anti-virus in blockchain" have appeared-we talked to the up-and-coming US startups Swarm and Panjiva]", @ITAGILE / DEVOPSCODING EDGEADVOCATING "ANTIVIRUS WITH BLOCKCHAIN METHOD" ..., 29 November 2017 (2017-11-29), pages 1 - 3, XP009517713, Retrieved from the Internet <URL:http://www.atmarkit.co.jp/ait/articles/1711/29/news099.html> [retrieved on 20180607] *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022516160A (ja) * 2018-12-31 2022-02-24 ザ インダストリー アンド アカデミック コオペレーション イン チュンナム ナショナル ユニバーシティー（アイエーシー） スマートコントラクト基盤の論文審査システム
JP7255820B2 (ja) 2018-12-31 2023-04-11 ザ インダストリー アンド アカデミック コオペレーション イン チュンナム ナショナル ユニバーシティー（アイエーシー） スマートコントラクト基盤の論文審査システム
JP2020113152A (ja) * 2019-01-16 2020-07-27 株式会社医療情報技術研究所 文書管理システム
WO2020149177A1 (ja) * 2019-01-16 2020-07-23 株式会社医療情報技術研究所 文書管理システム
JP2020166381A (ja) * 2019-03-28 2020-10-08 重政 河合 祭祀方法、コンピュータプログラム、及び祭祀審査装置
JP2020190874A (ja) * 2019-05-21 2020-11-26 株式会社医療情報技術研究所 文書管理システム
JP2021182315A (ja) * 2020-05-20 2021-11-25 株式会社リーチ・ビデオジャパン Ｓｎｓにおける動画・画像コンテンツ投稿管理システム
JP2020166872A (ja) * 2020-05-27 2020-10-08 重政 河合 祭祀方法、コンピュータプログラム、及び祭祀審査装置
JP7269655B2 (ja) 2020-05-27 2023-05-09 重政 河合 祭祀方法、コンピュータプログラム、及び祭祀審査装置
WO2022074874A1 (ja) * 2020-10-05 2022-04-14 エヌ・ティ・ティ・コミュニケーションズ株式会社 情報取引管理システム、方法およびプログラム
JP2022060822A (ja) * 2020-10-05 2022-04-15 エヌ・ティ・ティ・コミュニケーションズ株式会社 情報取引管理システム、方法およびプログラム
WO2022195643A1 (ja) * 2021-03-13 2022-09-22 株式会社クエスト ブロックチェーンシステム、記憶装置及び管理装置
WO2023063392A1 (ja) * 2021-10-13 2023-04-20 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、サーバ、プログラム、及び、セキュリティ分析システム
JP7260236B1 (ja) * 2022-11-28 2023-04-19 大学共同利用機関法人情報・システム研究機構 情報処理装置、情報処理システム、プログラムおよび情報処理方法

Also Published As

Publication number Publication date
CN110462619A (zh) 2019-11-15
EP3608819B1 (en) 2024-03-20
US20230359735A1 (en) 2023-11-09
CN110462619B (zh) 2023-07-25
US11741229B2 (en) 2023-08-29
JP6457165B1 (ja) 2019-01-23
JP7166905B2 (ja) 2022-11-08
JP2019091464A (ja) 2019-06-13
CN116821908A (zh) 2023-09-29
JPWO2018186391A1 (ja) 2019-04-11
US20210319102A1 (en) 2021-10-14
JP2023002748A (ja) 2023-01-10
US20200034536A1 (en) 2020-01-30
EP3608819A4 (en) 2020-12-30
US11074343B2 (en) 2021-07-27
EP3608819A1 (en) 2020-02-12
JP7429755B2 (ja) 2024-02-08

Similar Documents

Publication Publication Date Title
JP6457165B1 (ja) 検査システムおよび検査方法
Das et al. Understanding security issues in the NFT ecosystem
US11695755B2 (en) Identity proofing and portability on blockchain
US20210110399A1 (en) Transaction assessment and/or authentication
US20200027089A1 (en) Blockchain transaction safety using smart contracts
JP6068506B2 (ja) オンライン不正行為の検出の動的採点集計のシステムおよび方法
US20190370813A1 (en) Decentralized safeguard against fraud
US8880435B1 (en) Detection and tracking of unauthorized computer access attempts
JP4954979B2 (ja) 詐欺監視、検出、および階層状ユーザ認証のためのシステムおよび方法
US20240064135A1 (en) Identity Proofing and Portability on Blockchain
JP2005062556A (ja) 認証システム、サーバおよび認証方法並びにプログラム
KR102219582B1 (ko) 블록체인에 기반하여 진료비 정보를 공유하기 위한 방법 및 장치
CN111046078A (zh) 基于区块链的征信查询方法、装置和电子设备
Menges et al. DEALER: decentralized incentives for threat intelligence reporting and exchange
Zhang et al. A hybrid trust evaluation framework for e-commerce in online social network: a factor enrichment perspective
Kaafarani et al. An Adaptive Decision-Making Approach for Better Selection of Blockchain Platform for Health Insurance Frauds Detection with Smart Contracts: Development and Performance Evaluation
JP7393343B2 (ja) 制御方法、コンテンツ管理システム、及び、プログラム
KR102540291B1 (ko) 블록체인 기반 공모전 출품작 관리 방법 및 장치
US20230396445A1 (en) Multi-signature wallets in public trust ledger actions via a database system
US20230394481A1 (en) Authorizing public trust ledger actions via a database system
US20230401553A1 (en) Crypto-bridge for automating recipient decision on crypto transactions
US20230401572A1 (en) Payment settlement via cryptocurrency exchange for fiat currency
Esche et al. Conformity assessment of photo-optical measurement data registration in legal metrology: Ensuring admissibility as evidence of measurement data retrieved from legacy utility meters

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2018557060

Country of ref document: JP

Kind code of ref document: A

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

Ref document number: 18781236

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018781236

Country of ref document: EP

Effective date: 20191104