Control method, recording medium, and improper data detection system

Abstract

The control method is a control method of an improper data detection system including at least a plurality of authentication servers, detects whether data acquired from a device is improper data (S205), acquires first transaction data including information indicating the data (S202), in a case where it is detected that the data is not improper data (NO in S205), a first authentication server of the plurality of authentication servers performs verification of the acquired first transaction data (S210), and in a case where consensus is reached regarding the legitimacy of the first transaction data by a consensus algorithm (S213), a block including the first transaction data is recorded in a distributed ledger.

Description

Technical Field

[0001] This disclosure relates to control methods, recording media, and systems for detecting improper data. Background Technology

[0002] In recent years, systems for collecting, analyzing, and disseminating user and device data have been researched. Looking ahead, with the development of IoT (Internet of Things) and the widespread adoption of AI, even more data will be collected than ever before, leading to expectations for the utilization of this collected data.

[0003] For example, Non-Patent Document 1 discloses Society 5.0, a human-centered society that combines a system that highly integrates cyberspace (virtual space) and physical space (real space) to address both economic development and social problems.

[0004] According to Non-Patent Document 1, Society 5.0 describes the collection and use of personal data, for example, in tourism or health management.

[0005] Existing technical documents

[0006] Non-patent literature

[0007] Non-patent document 1: Strategy for Promoting Data Utilization to Realize Society 5.0, Internet<URL:https: / / www.keidanren.or.jp / en / policy / 2017 / 104.html?v=p> [Searched on May 20, 2020] Summary of the Invention

[0008] The problem that the invention aims to solve

[0009] However, even if collected data is recorded in an immutable state via blockchain or similar means and used when providing services, it cannot be used with complete peace of mind if the collected data was originally abnormal or improper. Furthermore, even if such data is used for services such as tourism or health management, appropriate services cannot be provided.

[0010] This disclosure is made in view of the above circumstances, with the aim of providing control methods, etc., that enable the safe use of data.

[0011] Methods used to solve problems

[0012] To achieve the above objectives, the control method disclosed herein is a control method for an improper data detection system having at least multiple authentication servers. The method involves detecting whether data obtained from a device is improper data; obtaining first transaction data, which contains information representing the data and is generated by the device; if the data is detected as not improper, a first authentication server among the multiple authentication servers verifies the obtained first transaction data; if the first authentication server confirms the legitimacy of the first transaction data through the verification, it executes a consensus algorithm with multiple second authentication servers (excluding the first authentication server) to reach a consensus on the legitimacy of the first transaction data; and if a consensus is reached on the legitimacy of the first transaction data through the consensus algorithm, the first authentication server records a block containing the first transaction data in a distributed ledger.

[0013] In addition, these inclusive or specific technical solutions can also be implemented by systems, methods, integrated circuits, computer programs or computer-readable CD-ROMs and other recording media, or by any combination of systems, methods, integrated circuits, computer programs and recording media.

[0014] Invention Effects

[0015] According to this disclosure, control methods that enable the secure use of data can be implemented. Attached Figure Description

[0016] Figure 1 This is a diagram illustrating an example of the overall structure for detecting improper data related to an implementation method.

[0017] Figure 2 This is a diagram illustrating an example of the overall structure of a dwelling according to an embodiment of the invention.

[0018] Figure 3 It means Figure 2 The block diagram shown is an example of the configuration of a controller.

[0019] Figure 4 This is a block diagram illustrating an example of the configuration of a terminal in relation to an implementation method.

[0020] Figure 5 This is a block diagram illustrating an example of the configuration of an authentication server for a particular implementation method.

[0021] Figure 6 This is an explanatory diagram representing the data structure of a blockchain.

[0022] Figure 7 This is a block diagram illustrating an example of the configuration of a detection server for a given implementation method.

[0023] Figure 8 This is a block diagram illustrating an example of the configuration of a service server for an implementation method.

[0024] Figure 9 This is a sequence diagram showing the overall implementation of the improper data detection system.

[0025] Figure 10 This is a sequence diagram illustrating the consent information registration process between the terminal and the authentication server in the implementation method.

[0026] Figure 11 This is a diagram showing the sequence of data registration and processing between the terminal, authentication server, and detection server in the implementation method.

[0027] Figure 12A This is a sequence diagram illustrating the data reference processing between the terminal, authentication server, detection server, and service server in the relevant implementation method.

[0028] Figure 12B This is a sequence diagram illustrating the data reference processing between the terminal, authentication server, detection server, and service server in the relevant implementation method.

[0029] Figure 13 This is a sequence diagram showing the smart contract registration process related to incentive payments between the authentication server and the service server in the implementation method. Detailed Implementation

[0030] One embodiment of the present disclosure is a control method for an improper data detection system having at least a plurality of authentication servers. The method involves detecting whether data obtained from a device is improper data; obtaining first transaction data, which includes information representing the data and is generated by the device; if the data is detected as not improper, a first authentication server among the plurality of authentication servers verifies the obtained first transaction data; if the first authentication server confirms the legitimacy of the first transaction data through the verification, it executes a consensus algorithm with a plurality of second authentication servers (excluding the first authentication server) to reach a consensus on the legitimacy of the first transaction data; and if a consensus is reached on the legitimacy of the first transaction data through the consensus algorithm, the first authentication server records a block containing the first transaction data in a distributed ledger.

[0031] In this way, data can be verified before being recorded in the distributed ledger, and information related to the data, along with proof that it is secure, can be recorded in the distributed ledger. Thus, blockchain technology can be used to ensure the security of acquired data. Therefore, data can be used with confidence using a distributed ledger.

[0032] Alternatively, the aforementioned improper data detection system may include a detection server; the detection server detects whether the data obtained from the aforementioned device is improper data; the detection server obtains the aforementioned first transaction data from the aforementioned device; if the detection server detects that the data is not improper data, it sends the aforementioned first transaction data to the aforementioned first authentication server; if the aforementioned first transaction data has been sent from the detection server as a result of detecting that the data is not improper data, the aforementioned first authentication server obtains the aforementioned first transaction data from the detection server and performs verification on the obtained aforementioned first transaction data.

[0033] Therefore, if the detection server determines that the data is not illegitimate, the first transaction data is sent to the first authentication server and recorded in the first authentication server's distributed ledger. Thus, it can be guaranteed that the data with information related to it recorded in the first authentication server's distributed ledger is secure, and therefore it can be used with confidence.

[0034] Alternatively, the first authentication server may detect whether the data obtained from the device is illegitimate; obtain the first transaction data from the device; and verify the first transaction data if the data is found to be illegitimate.

[0035] Therefore, if the first authentication server detects that the data is not illegitimate, it records the first transaction data in its distributed ledger. Thus, it can be guaranteed that the data with related information recorded in the first authentication server's distributed ledger is secure, and can be used with confidence.

[0036] Alternatively, the aforementioned improper data detection system may also include a service server; in the aforementioned control method, the service server generates second transaction data containing a data acquisition mandate and sends it to the first authentication server, the data acquisition mandate indicating an intention to acquire the aforementioned data; when the first authentication server acquires the aforementioned second transaction data, and it is determined, based on the consent information related to the use of the aforementioned data obtained from the aforementioned device, that the data can be provided to the service server, the aforementioned data is provided to the service server.

[0037] Alternatively, the first authentication server may obtain third transaction data containing the consent information from the device and acquire a smart contract. This smart contract is programmed to perform a process that determines whether the data can be provided based on the consent information. If the first authentication server has obtained the second transaction data, and determines, through executing the smart contract based on the obtained third transaction data, that the data can be provided to the service server, then the data is provided to the service server.

[0038] Alternatively, when detecting whether the above data is illegitimate, if the measured step count data is obtained from the above device and the measured step count data includes a number of steps within a predetermined period that are above a threshold, then the above data is detected as illegitimate.

[0039] Alternatively, when detecting whether the above data is illegitimate, if the step data obtained from the above device includes the measured number of steps and the location information at the time of measurement, and the step data contains steps in which the location information has not changed for a specified period of time, then the above data is detected as illegitimate.

[0040] Alternatively, when detecting whether the above data is illegitimate, if the step data obtained from the device includes the measured number of steps and the heart rate at the time of measurement, and the step data includes steps in which the heart rate has not changed for a specified period of time, then the above data is detected as illegitimate.

[0041] Alternatively, when detecting whether the above data is illegitimate, if the above data was obtained from the above device, or if information indicating an abnormality of the above device was obtained, the above data may be detected as illegitimate.

[0042] Alternatively, when detecting whether the aforementioned data is illegitimate, if the aforementioned data is not found to be illegitimate, the creditworthiness of the aforementioned data may also be determined, and the determined creditworthiness may be included in the information representing the aforementioned data in the first transaction data obtained.

[0043] Alternatively, in the above control method, if the data is detected to be illegitimate, the meaning of the illegitimate data is included in the information of the first transaction data to generate the fourth transaction data; if the data is detected to be illegitimate, the first authentication server verifies the fourth transaction data; if the first authentication server confirms the legitimacy of the fourth transaction data through the verification, it executes a consensus algorithm with the multiple second authentication servers to reach a consensus on the legitimacy of the fourth transaction data; if a consensus is reached on the legitimacy of the fourth transaction data through the consensus algorithm, the first authentication server records the block containing the fourth transaction data in the distributed ledger.

[0044] Alternatively, the first transaction data may include the aforementioned data or its hash value as information representing the aforementioned data.

[0045] Furthermore, one embodiment of the illegitimate data detection system disclosed herein is an illegitimate data detection system comprising multiple authentication servers and detection servers. The detection servers comprise: a detection unit that detects whether data obtained from a device is illegitimate data; and a data management unit that obtains first transaction data containing information representing the data and generated by the device, and sends the first transaction data to a first authentication server among the multiple authentication servers if the data is detected as not illegitimate. The first authentication server comprises: a transaction data verification unit that verifies the obtained first transaction data if the data is detected as not illegitimate; a block generation unit that, after confirming the legitimacy of the first transaction data through the verification, executes a consensus algorithm with multiple second authentication servers (excluding the first authentication server) among the multiple authentication servers to reach a consensus on the legitimacy of the first transaction data; and a recording unit that, after reaching a consensus on the legitimacy of the first transaction data through the consensus algorithm, records a block containing the first transaction data into a distributed ledger.

[0046] Hereinafter, embodiments will be described with reference to the accompanying drawings. Furthermore, the embodiments described below represent specific examples of this disclosure. Therefore, the numerical values, shapes, materials, constituent elements, arrangements and connection forms of constituent elements, steps, and order of steps shown in the following embodiments are examples of this disclosure and are not intended to limit this disclosure. In addition, constituent elements in the following embodiments that are not described in the independent claims representing an implementation of this disclosure are described as arbitrary constituent elements. Implementations of this disclosure are not limited to the existing independent claims and may also be expressed by other independent claims.

[0047] (Implementation Method)

[0048] First, the system configuration of this disclosure will be described.

[0049] [1. System Composition]

[0050] The disclosed illegitimate data detection system detects whether the acquired data is illegitimate before recording information related to the data in the distributed ledger, and records the relevant information of the data that is not illegitimate in the distributed ledger. Therefore, the disclosed illegitimate data detection system can utilize blockchain technology to ensure that the acquired data is secure, and thus allows for safe use of the data.

[0051] Hereinafter, an improper data detection system and the like will be described with reference to the accompanying drawings.

[0052] [1.1 Overall Structure of the Improper Data Detection System 10]

[0053] Figure 1 This diagram illustrates an example of the overall configuration of the improper data detection system 10 according to this embodiment. The improper data detection system is as follows: Figure 1 As shown, the system includes a residential unit 100, a terminal 110, authentication servers 200a, 200b, and 200c, a detection server 300, and a service server 400. They are connected via a communication network 500.

[0054] Authentication servers 200a, 200b, and 200c (hereinafter also referred to as authentication server 200) are connected to a storage device with a distributed ledger that electronically records blockchain transaction data and blocks. Alternatively, authentication server 200 may connect to the storage device via communication network 500 or have the storage device internally.

[0055] In addition, Figure 1The example shown is of an improper data detection system 10 with three authentication servers 200, but it is not limited to this. That is, the improper data detection system 10 can also have four or more authentication servers 200.

[0056] [1.2 Composition of Residential Building 100]

[0057] Figure 2 This is a diagram illustrating an example of the overall structure of the dwelling 100 according to this embodiment.

[0058] Residential Building 100 is an example of a device for acquiring or collecting data related to this disclosure. The data acquired or collected may include, for example, health management data such as user health diagnosis data, sleep data, blood pressure data, weight data, and exercise data, but is not limited to these. The data acquired or collected is not limited to health management data; it may also include user personal data including vital signs such as heart rate, measurement data, or device history information such as device action history or device operation history. Thus, the data acquired or collected can be any data that can be used by the service provider.

[0059] In this embodiment, such as Figure 2 As shown, the residence 100 includes a controller 101, a solar power generation device 102, a battery 103, an air conditioner 104, a body composition meter 105, and a blood pressure monitor 106. These are connected via a communication network.

[0060] <Controller 101>

[0061] The controller 101 controls indoor equipment such as the air conditioner 104, body composition meter 105, and blood pressure monitor 106. In addition, the control unit 1011 can also display the operating status of the solar power generation device 102 and the battery 103.

[0062] In addition, the controller 101 can also collect history information such as the operation history or function history of indoor equipment, and can also collect history information on the operation status of the solar power generation device 102 and the battery 103. Furthermore, the controller 101 can also collect measurement data measured by indoor equipment.

[0063] Furthermore, the controller 101 can also send the collected history information and measurement data to the detection server 300, and can also send the generated transaction data to the authentication server 200.

[0064] <Solar Power Generation Device 102>

[0065] The solar power generation device 102 is a device that uses solar cells to directly convert sunlight into electricity. The electricity generated by the solar power generation device 102 is used within the residence 100 or stored in the battery 103. Furthermore, the solar power generation device 102 is not an essential component and may not be present in the residence 100.

[0066] <Battery 103>

[0067] The storage battery 103 stores the electricity generated by the solar power generation device 102. Furthermore, the storage battery 103 is not a necessary component and may not be present in the residence 100.

[0068] <Air conditioner 104, body composition analyzer 105, and blood pressure monitor 106>

[0069] Air conditioner 104, body composition analyzer 105, and blood pressure monitor 106 are indoor devices used by users, and may also be examples of devices disclosed herein. For example, the motion history or operation history of air conditioner 104 is sent to detection server 300. Furthermore, the motion history or operation history of body composition analyzer 105 and blood pressure monitor 106, as well as measurement data such as the user's weight data measured by body composition analyzer 105 and / or the user's blood pressure data measured by blood pressure monitor 106, are also sent to detection server 300. This data can be sent to detection server 300 either via controller 101 or directly to detection server 300.

[0070] The following describes an example of the configuration of controller 101.

[0071] [1.3 Composition of Controller 101]

[0072] Figure 3 It means Figure 2 The block diagram shown is an example of the configuration of the controller 101.

[0073] The controller 101 includes a processor (not shown) and a memory (not shown) storing a program that causes the processor to perform predetermined processes. That is, the controller 101 is implemented by the processor using the memory to execute the predetermined program. In this embodiment, as... Figure 3 As shown, the controller 101 includes a control unit 1011, a transaction data generation unit 1012, an input unit 1013, a recording unit 1014, and a communication unit 1015.

[0074] <Control Department 1011>

[0075] The control unit 1011 can also control indoor equipment. Figure 2In the example shown, the control unit 1011 operates indoor appliances such as the air conditioner 104, body composition analyzer 105, and blood pressure monitor 106, or manages the operation history and status of these appliances. Furthermore, the control unit 1011 can also display the operating status of the solar power generation device 102 and the battery 103. For example, the control unit 1011 can also display the power generation status of the solar power generation device 102 or the charge storage status of the battery 103. Additionally, the control unit 1011 can also display the status of the indoor appliances or vital sign data measured by the body composition analyzer 105 or the blood pressure monitor 106.

[0076] In addition, the control unit 1011 can also collect historical information such as the operation history or maintenance history of indoor equipment, and can also collect historical information on the operating status of the solar power generation device 102 and the battery 103. Furthermore, the control unit 1011 can also collect measurement data measured by indoor equipment.

[0077] <Input Section 1013>

[0078] Input unit 1013 generates consent information related to the use of the acquired or collected data. Here, consent information is information indicating that the user agrees to the use of the acquired or collected data, and is generated based on the user's actions. Consent information can also be generated, for example, by selecting or deselecting from a list of service providers or a data list of data provision destinations provided by input unit 1013. In this case, the consent information includes the service providers that the user agrees to provide the data, or the data or types of data that the user agrees to provide. That is, the consent information includes the service providers that the user agrees to provide, or the data or types of data. Furthermore, the consent information may also include information indicating consent given in cases where a certain number of responses are received.

[0079] Furthermore, the input unit 1013 can also generate a smart contract based on the generated consent information. Here, the smart contract is programmed to perform a process that determines whether data can be provided. The smart contract may also contain the consent information generated by the input unit 1013.

[0080] Alternatively, the input unit 1013 may be an application installed in the controller 101. In this case, the installed application performs the functions described above for the input unit 1013.

[0081] <Transaction Data Generation Department 1012>

[0082] The transaction data generation unit 1012 generates transaction data in the blockchain. In this embodiment, the transaction data generation unit 1012 generates transaction data that includes consent information generated by the input unit 1013. More specifically, the transaction data generation unit 1012 generates transaction data that includes, for example, the user's blockchain address, consent information including the user's consent to the service provider or the type of data provided, and a signature. Additionally, the transaction data generation unit 1012 may also assign an identifier to generate the transaction data. The transaction data generation unit 1012 generates a signature using the user's individual signature generation key.

[0083] Furthermore, the transaction data generation unit 1012 can also generate transaction data that includes the smart contract generated by the input unit 1013. Additionally, the transaction data generation unit 1012 can also generate transaction data that includes the consent information and smart contract generated by the input unit 1013.

[0084] Furthermore, the transaction data generation unit 1012 can also generate transaction data containing information such as historical information or measurement data collected by the control unit 1011. In this case, the transaction data generation unit 1012 may simply generate transaction data containing, for example, the user's blockchain address, information representing data collected by the control unit 1011, and a signature. Here, the information representing the data may be, for example, the data itself collected by the control unit 1011, the hash value of the data, or the hash value of the data and the attribute information of the data.

[0085] The attribute information of the data may include, for example, the category of the sensor or device that collected the data. Furthermore, when the data is step count, weight, body fat percentage, or blood pressure, the attribute information may include data items indicating when, how, and in which the data was measured or collected. When the data is from home appliances or other indoor devices, it may include data items indicating their activity history, date and time of activity, etc.

[0086] The transaction data generation unit 1012 records the generated transaction data into the recording unit 1014. The transaction data generation unit 1012 then sends the data to the authentication server 200 or the detection server 300 via the communication unit 1015.

[0087] <Records Department 1014>

[0088] The recording unit 1014 records data such as resume information and measurement data collected by the control unit 1011. In addition, the recording unit 1014 records transaction data generated by the transaction data generation unit 1012. Furthermore, the recording unit 1014 can also record consent information and smart contracts generated by the input unit 1013.

[0089] <Communication Department 1015>

[0090] The communication unit 1015 communicates with the authentication server 200, the detection server 300, and the service server 400 via the communication network 500. This communication can also be conducted via TLS (Transport Layer Security). In this case, the encryption key used for TLS communication can also be maintained by the communication unit 1015.

[0091] Next, an example of the configuration of terminal 110 will be described.

[0092] [1.4 Composition of Terminal 110]

[0093] Figure 4 This is a block diagram illustrating an example of the configuration of the terminal 110 according to this embodiment. The terminal 110 is an example of the device disclosed in this disclosure, implemented by a processor executing a predetermined program using memory. Furthermore, the terminal 110 may be, for example, a device with a display and input section such as a smartphone, or a device that acquires user measurement data such as a wearable device.

[0094] In this embodiment, such as Figure 4 As shown, the terminal 110 includes a transaction data generation unit 1101, an input unit 1102, a data acquisition unit 1103, a recording unit 1104, and a communication unit 1105.

[0095] <Input Section 1102>

[0096] The input unit 1102 generates user consent information related to the use of data. As described above, the consent information indicates that the user agrees to the use of the data obtained or collected, and is generated based on the user's actions.

[0097] For example, consent information can be generated by selecting or deselecting from a list of service providers or a data list of data provision destinations provided by the input unit 1013. In this case, users can also select service providers of data provision destinations based on the purpose of data use, actual data use records, or feedback or incentives given to users due to data use. As an example of incentives or feedback, one could be that the service provider pays the user virtual currency or displays information that the user can enjoy when the user provides data to the service provider. Furthermore, as an example of incentives or feedback, one could be that when the user provides measurement data such as body composition analysis or blood pressure measurement records to a sports club, the user can enjoy free trials or membership fee reductions from the sports club, or display information that the user can enjoy.

[0098] Furthermore, the input unit 1102 can also generate a smart contract based on the generated consent information, which is programmed to perform processing to determine whether data can be provided.

[0099] <Transaction Data Generation Department 1101>

[0100] The transaction data generation unit 1101 generates transaction data in the blockchain. In this embodiment, the transaction data generation unit 1101 generates transaction data in the blockchain that includes consent information generated by the input unit 1102. More specifically, the transaction data generation unit 1101 generates transaction data that includes, for example, a blockchain address owned by the user, consent information including the user's consent to the service provider or the type of data or data provided, and a signature.

[0101] Alternatively, the transaction data generation unit 1101 can also generate transaction data by assigning an identifier. The transaction data generation unit 1101 only needs to generate a signature using a user-specific signature generation key.

[0102] Furthermore, the transaction data generation unit 1101 can also generate transaction data containing information representing the data obtained by the data acquisition unit 1103. In this case, the transaction data generation unit 1101 only needs to generate transaction data that includes, for example, the user-owned blockchain address, information representing the data obtained by the data acquisition unit 1103, and a signature. The information representing the data can be, for example, the data itself obtained by the data acquisition unit 1103, the hash value of the data, or the hash value of the data and the attribute information of the data.

[0103] Furthermore, the transaction data generation unit 1101 can also generate transaction data that includes the smart contract generated by the input unit 1102. Additionally, the transaction data generation unit 1101 can also generate transaction data that includes the consent information and smart contract generated by the input unit 1102.

[0104] The transaction data generation unit 1101 records the generated transaction data to the recording unit 1104. The transaction data generation unit 1101 then sends the generated transaction data to the authentication server 200 or the detection server 300 via the communication unit 1105.

[0105] <Data Acquisition Department 1103>

[0106] The data acquisition unit 1103 acquires data such as measurement data obtained from the sensors owned by the terminal 110. For example, if the terminal 110 has an accelerometer and a GPS sensor, the data acquisition unit 1103 acquires step count data, including the number of steps obtained from the accelerometer and the location information obtained from the GPS sensor, as measurement data. Furthermore, the data acquisition unit 1103 can acquire both blood pressure data and heart rate data as measurement data. In other words, the data acquisition unit 1103 acquires data that service providers can utilize.

[0107] The data acquisition unit 1103 records the acquired data into the recording unit 1104. The data acquisition unit 1103 can also send the data to the detection server 300 via the communication unit 1105.

[0108] <Records Department 1104>

[0109] The recording unit 1104 records the transaction data generated by the transaction data generation unit 1101. Additionally, the recording unit 1104 records the data acquired by the data acquisition unit 1103. Furthermore, the recording unit 1104 may also record consent information and smart contracts generated by the input unit 1102.

[0110] <Communication Department 1105>

[0111] The communication unit 1105 communicates with the authentication server 200 and the detection server 300 via the communication network 500. This communication can also be conducted via TLS. In this case, the encryption key used for TLS communication can also be held by the communication unit 1105.

[0112] Next, an example of the configuration of authentication server 200 will be explained.

[0113] [1.5 Authentication Server 200a Structure]

[0114] Figure 5 This is a block diagram illustrating an example of the configuration of authentication server 200a according to this embodiment. Authentication servers 200b and 200c have the same configuration. Therefore, authentication server 200a will be used as an example for explanation below.

[0115] like Figure 5 As shown, the authentication server 200a includes a transaction data verification unit 211, a block generation unit 212, a synchronization unit 213, a smart contract execution unit 214, a recording unit 215, and a communication unit 216. The authentication server 200a can be implemented by a processor using memory to execute a prescribed program. The following describes each component.

[0116] <Transaction Data Verification Department 211>

[0117] The transaction data verification unit 211 verifies the received transaction data. Specifically, if transaction data is received from a device such as a residence 100 or a terminal 110, the transaction data verification unit 211 verifies whether the format of the transaction data is correct and whether the signature is legitimate. For example, when verifying transaction data containing consent information, the transaction data verification unit 211 verifies whether the address, consent information, and signature contained in the transaction data are legitimate. Alternatively, when verifying transaction data containing information representing data, the transaction data verification unit 211 only needs to verify whether the address, information representing data, and signature contained in the transaction data are legitimate.

[0118] In this way, the transaction data verification unit 211 verifies the transaction data by confirming the legitimacy of the received transaction data.

[0119] If the transaction data verification unit 211 confirms the legitimacy of the transaction data, it records the transaction data in the recording unit 215. Here, if the transaction data is determined to be legitimate, it notifies the synchronization unit 213.

[0120] <Block Generation Section 212>

[0121] If the transaction data is successfully verified in the transaction data verification unit 211, the block generation unit 212 executes a consensus algorithm for the transaction data among multiple authentication servers 200. Here, the consensus algorithm can be either a consensus algorithm called PBFT (Practical Byzantine Fault Tolerance) or other well-known consensus algorithms such as PoW (Proof of Work).

[0122] In this embodiment, the block generation unit 212 executes a consensus algorithm among authentication servers 200a, 200b, and 200c. Specifically, the block generation unit 212 first generates blocks that contain data from one or more transactions. Then, the block generation unit 212 executes the consensus algorithm. Furthermore, if consensus is reached through the execution of the consensus algorithm, the block generation unit 212 records the generated blocks in the recording unit 215. The blocks generated by the block generation unit 212 are connected to and recorded on the blockchain by the recording unit 215.

[0123] Here, we will explain the data structure of blockchain.

[0124] Figure 6 This is an explanatory diagram representing the data structure of a blockchain.

[0125] A blockchain is constructed by linking blocks, which serve as its units of record, in a chain. Each block contains multiple transaction data points and the hash value of the preceding block. Specifically, block B2 contains the hash value of its preceding block B1. Furthermore, the hash value calculated based on the multiple transaction data points in block B2 and the hash value of block B1 is included as the hash value of block B2 in block B3. In this way, by including the content of previous blocks as hash values ​​and linking the blocks in a chain, tampering of the linked transaction data is effectively prevented.

[0126] If past transaction data is altered, the hash value of the block will become different from the value before the alteration. In order to make the tampered block appear as the correct block, all subsequent blocks must be remade, which is very difficult in reality.

[0127] <Synchronization Section 213>

[0128] The synchronization unit 213 synchronizes blockchain block or transaction data among multiple authentication servers 200 (authentication servers 200a to 200c).

[0129] In the synchronization unit 213 of the multiple authentication servers 200, blockchain transaction data is synchronized peer-to-peer. Furthermore, the synchronization unit 213 records the synchronized blockchain transaction data in the recording unit 215. For example, if the validity of transaction data is verified in the transaction data verification unit 211, the synchronization unit 213 forwards the verified transaction data to authentication servers 200b and 200c, which are other authentication servers 200. Additionally, when the synchronization unit 213 receives verified transaction data from other authentication servers 200, it records the received verified transaction data in the recording unit 215.

[0130] <Smart Contract Execution Department 214>

[0131] The smart contract execution unit 214 saves the smart contracts recorded in the distributed ledger to the working storage. The smart contract execution unit 214 executes the smart contracts saved in the working storage.

[0132] For example, if transaction data containing a data acquisition delegation is recorded in the distributed ledger—that is, if a block containing the transaction data is generated and recorded in the distributed ledger—the smart contract execution unit 214 saves the smart contract generated based on the user's consent information to the working memory. By executing the smart contract stored in the working memory, the smart contract execution unit 214 can determine whether the executed smart contract can provide the data. Furthermore, the executed smart contract can notify the user of the result of the determination of whether the data can be provided, or grant access rights to the blockchain address contained in the transaction data including the data acquisition delegation. Thus, the smart contract execution unit 214 can execute the smart contract, for example, triggered by an access from the service server 400, thereby enabling the service server 400 to manage access to the data owned by the detection server 300.

[0133] Furthermore, for example, if transaction data containing information related to incentive payments or feedback provision is recorded in the distributed ledger, the smart contract execution unit 214 saves the smart contract generated based on the incentive payment or feedback provision to the working memory. By executing the smart contract saved in the working memory, the smart contract execution unit 214 can enable the executed smart contract to provide incentive payments or feedback. The provision of incentive payments or feedback can be either a notification indicating that incentive payments or feedback have been provided, or it can be an incentive payment or feedback provided to a user.

[0134] <Records Department 215>

[0135] The recording unit 215 includes transaction data in blocks and records them to the distributed ledger of the authentication server 200a. This distributed ledger can be constructed either internally within the recording unit 215 or internally within the external storage device of the authentication server 200a.

[0136] In addition, the transaction data includes transaction data received from residence 100 or terminal 110.

[0137] In this embodiment, the recording unit 215 records a block containing the transaction data into the distributed ledger of the authentication server 200a after confirming the legitimacy of the transaction data received from the device of this disclosure. Alternatively, the blockchain block recorded in the distributed ledger may be disclosed to the service server 400, the residence 100, or the terminal 110.

[0138] <Communication Department 216>

[0139] The communication unit 216 communicates with the residence 100, terminal 110, authentication servers 200b and 200c, detection server 300, and service server 400. This communication can also be conducted via TLS. In this case, the encryption key used for TLS communication can also be maintained by the communication unit 216.

[0140] Thus, authentication server 200a performs processing for verifying the legitimacy of data obtained from residence 100 or terminal 110, managing the availability of data, or providing data to service server 400. It has been stated that data obtained from residence 100 or terminal 110 is recorded by detection server 300 and not by authentication server 200a, but this is not a limitation. Authentication server 200a may also record this data. In this case, it may also be recorded as transaction data containing this data in the distributed ledger of authentication server 200a.

[0141] Next, the detection server 300 will be explained.

[0142] [1.6 Detection Server 300 Composition]

[0143] Figure 7 This is a block diagram illustrating an example of the configuration of the detection server 300 according to this embodiment.

[0144] like Figure 7 As shown, the detection server 300 includes a data management unit 311, a detection unit 312, a transaction data generation unit 313, a recording unit 314, and a communication unit 315. The detection server 300 can be implemented by a processor executing a predetermined program using memory. The following describes each component.

[0145] <Data Management Department 311>

[0146] The data management unit 311 manages data obtained from the residence 100 or terminal 110. The data management unit 311 records data that is not deemed improper by the detection unit 312 into the recording unit 314. If the detection server 300 does not receive transaction data containing information representing the data from the residence 100 or terminal 110, the data management unit 311 sends attribute information, etc., of the data obtained from the residence 100 or terminal 110 to the transaction data generation unit 313. Furthermore, the data attribute information may also include, as described above, the type of sensor or device used to collect the data, or data items. Additionally, the data management unit 311 may assign a meaning indicating that data detected as improper by the detection unit 312 is improper data and record this information in the recording unit 314.

[0147] Furthermore, when the data management unit 311 receives a data provision request from the service server 400, it provides the user's data based on the consent information recorded in the distributed ledger of the authentication server 200. In this embodiment, assuming the execution of a smart contract generated by the authentication server 200 based on the consent information, the detection server 300 receives a notification from the authentication server 200 indicating that it can provide data. In this case, the data management unit 311 provides the user's data when it receives the data provision request from the service server 400. Alternatively, the data management unit 311 may also receive, along with the data provision request, the blockchain address corresponding to the data for which data provision is desired from the service server 400.

[0148] <Inspection Department 312>

[0149] The detection unit 312 detects whether the data obtained from devices such as the residence 100 or terminal 110 is illegitimate. For example, when measured step count data is obtained from devices such as the residence 100 or terminal 110, the detection unit 312 detects that the step count data is illegitimate if it includes a number of steps measured within a predetermined period that exceed a threshold. Specifically, the detection unit 312 detects that the step count data is illegitimate if it measures more than 10,000 steps within 10 minutes. This is because it is impossible for a user to walk 10,000 steps in 10 minutes; therefore, if more than 10,000 steps are measured within 10 minutes, it can be considered that improper behavior such as tampering with the step count data has occurred, and the step count data is illegitimate.

[0150] Furthermore, the detection unit 312 can detect that the step count data is illegitimate if it contains steps that increase by a certain percentage within a time period exceeding a threshold. This is because if the step count increases by a certain percentage within a time period exceeding the threshold, it can be considered that improper behavior has been carried out, such as using a oscillation to cause the sensor-equipped terminal 110 to move, and the step count data is therefore considered illegitimate.

[0151] Furthermore, for example, if step count data, including the measured number of steps and the location information at the time of measurement, is obtained from a device such as a residence 100 or a terminal 110, and the detection unit 312 detects that the step count data is illegitimate if it includes steps in which the location information has not changed for a specified period of time, then the step count data is considered illegitimate. This is because if the number of steps increases even though the location information does not change, it can be considered that improper behavior, such as using a oscillation to cause the terminal 110 or other devices equipped with sensors to move, has been carried out, and the step count data is considered illegitimate.

[0152] Alternatively, for example, if step data including the measured number of steps and the heart rate at the time of measurement is obtained from a device such as a residence 100 or a terminal 110, the detection unit 312 may detect that the step data is illegitimate if the step data includes steps in which the heart rate has not changed for more than a specified time.

[0153] Alternatively, for example, if step count data during measurement is obtained from a device such as terminal 110, the detection unit 312 may send a message to the terminal 110 or similar device to prompt the user to make certain inputs. Furthermore, the detection unit 312 may also detect that the obtained step count data is illegitimate if certain input results for the message cannot be obtained from the terminal 110.

[0154] Alternatively, if the body composition measurement data is obtained from a device such as a residence 100 or a terminal 110, and the detection unit 312 detects that the obtained measurement data is improper data if the measurement data includes a body composition measurement value that has changed by a value of more than a threshold relative to the previous body composition measurement value.

[0155] Furthermore, when body composition measurement data is obtained from devices such as residence 100 or terminal 110, if the detection unit 312 detects a change of more than a threshold within a certain period relative to the previous body composition measurement value, the measurement data may be deemed illegitimate. Specifically, the detection unit 312 may also detect a change of more than 30% in blood pressure measured within one minute compared to the previous blood pressure value, thus deeming the blood pressure measurement data illegitimate. Additionally, the detection unit 312 may also detect a change of more than 5 kg in body composition measurement measured within one day compared to the previous body composition measurement value, thus deeming the body composition measurement data illegitimate.

[0156] Alternatively, for example, if data is obtained from a device such as a residence 100 or a terminal 110, and information indicating an abnormality of the device is obtained, the detection unit 312 may detect that the obtained data is illegitimate.

[0157] In addition, the detection unit 312 can also detect abnormalities in devices such as the solar power generation device 102 or the battery 103 in the residence 100. For example, the detection unit 312 can obtain weather information from an external server (not shown) and detect an abnormality or malfunction of the solar power generation device 102 when the solar power generation is high even though the weather is not sunny. Furthermore, for example, the detection unit 312 can also detect an abnormality or malfunction of the battery 103 when devices such as the air conditioner 104 in the residence 100 are using the power of the battery 103 but the remaining power of the battery 103 has not decreased.

[0158] In addition to detecting whether the acquired data is illegitimate, the detection unit 312 can also detect abnormal or non-operational behavior caused by equipment malfunctions or other adverse conditions. Specifically, the detection unit 312 can also detect equipment malfunctions when it cannot receive data regularly from devices such as the solar power generation device 102 or the battery 103 in the residence 100, or when the acquired data is abnormal due to data corruption or other reasons.

[0159] Furthermore, the detection unit 312 can also use data from other terminals or other residences to detect abnormalities in devices such as the solar power generation device 102 or the battery 103 installed in the residence 100. For example, the detection unit 312 can use the power generation of the solar power generation device in a residence adjacent to the residence 100 to verify the power generation of the solar power generation device 102 obtained from the residence 100, and detect an abnormality or malfunction of the solar power generation device 102 if the power generation is above a threshold. In addition, data can also be verified based on data previously received from the terminal or devices in the residence, or data from users using the terminal.

[0160] Furthermore, if the detection unit 312 detects that the data obtained from the residence 100 or terminal 110 is not illegitimate, it sends the data to the data management unit 311 and records it in the recording unit 314.

[0161] On the other hand, if the detection unit 312 detects that the data obtained from the residence 100 or terminal 110 is illegitimate data, it can either discard the data or record it as illegitimate data in the recording unit 314. Furthermore, the detection unit 312 can also send the attribute information indicating that the data is illegitimate data to the transaction data generation unit 313.

[0162] In addition, if the detection unit 312 detects that the data obtained from the device is improper data or detects an abnormality in the device, it may also send a notification of this meaning to the terminal 110 or the controller 101 of the residence 100 to inquire with the user.

[0163] <Transaction Data Generation Department 313>

[0164] If the detection server 300 does not receive transaction data containing information representing the data from the residence 100 or terminal 110, but receives attribute information of the data from the data management unit 311, the transaction data generation unit 313 generates transaction data containing the attribute information of the data. The transaction data generation unit 313 records the generated transaction data in the recording unit 314. Furthermore, the transaction data generation unit 313 sends the generated transaction data to the authentication server 200 via the communication unit 315.

[0165] <Records Department 314>

[0166] When data is obtained from the devices of this disclosure, such as residence 100 or terminal 110, the recording unit 314 records the obtained data. Furthermore, the recording unit 314 records the detection results of the detection server 300, which checks whether the obtained data is illegitimate. Additionally, when transaction data is generated by the transaction data generation unit 313, the recording unit 314 records that transaction data.

[0167] <Communication Department 315>

[0168] The communication unit 315 communicates with the residence 100, terminal 110, authentication server 200, and service server 400 via the communication network 500. This communication can also be conducted via TLS. In this case, the encryption key used for TLS communication can also be maintained by the communication unit 315.

[0169] In this way, the detection server 300 detects whether the data obtained from the residence 100 or the terminal 110 is illegitimate, and records the data. For example, if the detection server 300 obtains step count data from the terminal 110, and detects that the step count data is not illegitimate, it records the data and records the information related to the data in the authentication server 200.

[0170] Furthermore, in this embodiment, the detection server 300 and the authentication server 200 are described as independent servers, but this is not a limitation. The functions of the detection server 300 may also be included in the authentication server 200 and operate therein.

[0171] Next, an example of the configuration of service server 400 will be explained.

[0172] [1.7 Composition of Server 400]

[0173] Figure 8 This is a block diagram illustrating an example of the configuration of the service server 400 in this embodiment.

[0174] Service server 400 is a server managed by a service provider to provide services, such as a sports club's server. In this embodiment, as... Figure 8 As shown, the service server 400 includes a service management unit 411, a user management unit 412, a transaction data generation unit 413, a recording unit 414, and a communication unit 415. The service server 400 can be implemented by a processor executing a predetermined program using memory. The following describes each component.

[0175] Service Management Department 411

[0176] Service Management Department 411 provides services using information about users managed by User Management Department 412. For example, Service Management Department 411 obtains data from the detection server 300, including measurement data such as the user's body composition or blood pressure, to provide new health management services or verify effectiveness.

[0177] The Service Management Department 411 uses the user information managed by the User Management Department 412 to generate a data acquisition request, indicating an intention to delegate data retrieval, and sends it to the Transaction Data Generation Department 413. The Service Management Department 411, for example, determines what kind of user data it wants to retrieve, and generates the data acquisition request based on the user's attribute information or the type of data to be retrieved. The data acquisition request may include, for example, a request specifying the user's identifier if the user's identifier has been determined beforehand, a request specifying a blockchain address, or a request specifying attributes. These attributes can be the type of device such as residence 100 or terminal 110, the type of data retrieved from the device, or user attributes.

[0178] Furthermore, upon acquiring data, the Service Management Department 411 generates information related to incentive payments or feedback provided to the user who acquired the data, as a reward for the acquired data, and sends this information to the Transaction Data Generation Department 413. Here, the information related to incentive payments or feedback may also include content regarding the payment of virtual currency to the user's blockchain address as a reward for the acquired data. Additionally, the Service Management Department 411 may also generate a smart contract based on the generated incentive payments or feedback. In this case, the smart contract may, for example, include a program for performing the following process: paying virtual currency to the user's blockchain address as a reward for the acquired data.

[0179] <User Management Department 412>

[0180] User Management Department 412 obtains information about users who are the recipients of services and manages the obtained user information.

[0181] <Transaction Data Generation Department 413>

[0182] The transaction data generation unit 413 generates transaction data that includes the data generated by the service management unit 411 to obtain the entrustment.

[0183] In addition, the transaction data generation unit 413 generates transaction data containing information related to incentive payments or feedback provided by the service management unit 411.

[0184] In addition, the transaction data generation unit 413 can also generate transaction data that includes smart contracts based on incentive payments or feedback generated by the service management unit 411.

[0185] <Records Department 414>

[0186] Recording unit 414 records user information or service information required for service provision. Additionally, recording unit 414 records transaction data generated by transaction data generation unit 413. Furthermore, recording unit 414 may also record data generated by service management unit 411 related to requests for authorization, incentive payments or feedback provision, and smart contracts.

[0187] <Communication Department 415>

[0188] The communication unit 415 communicates with the authentication server 200 and the detection server 300 via the communication network 500. This communication can also be conducted via TLS. In this case, the encryption key used for TLS communication can also be maintained by the communication unit 415.

[0189] [1.8 Overall Order of the Improper Data Detection System 10]

[0190] Next, the overall sequence of the improper data detection system 10 will be explained. Figure 9 This is an overall sequence diagram of the improper data detection system 10 according to this embodiment. Each process will be described later.

[0191] First, in step S100, consent information registration is performed between terminal 110, residence 100, and authentication servers 200a-200c. The consent information registration process described later will focus on the case where terminal 110 registers consent information. The same process applies when controller 101 of residence 100 registers consent information, so the description of controller 101 registering consent information is omitted.

[0192] Next, in step S200, data registration processing is performed between terminal 110, residence 100, authentication servers 200a-200c, and detection server 300. The data registration process described later will focus on registering data obtained from terminal 110. The same process applies to registering data for in-home devices in residence 100, so the description of registering in-home device data in residence 100 will be omitted.

[0193] Next, in step S300, data reference processing is performed between terminal 110, residence 100, authentication servers 200a-200c, detection server 300 and service server 400.

[0194] In addition, the data reference processing in step S300 can be performed after the user's consent information is registered in the consent information registration processing in step S100.

[0195] [1.8.1 Consent Information Registration and Processing]

[0196] Next, the process of registering consent information between terminal 110 and authentication servers 200a-200c will be explained.

[0197] Figure 10 This is a sequence diagram illustrating the consent information registration process between terminal 110 and authentication servers 200a-200c in this embodiment. Figure 10 The example shown illustrates the situation where terminal 110 registers consent information.

[0198] First, terminal 110 generates consent information based on the user's operation (S101). Here, it is preferable to import an application into terminal 110 as an input unit 1013, and the application generates consent information based on the user's operation. In this case, the user can enable terminal 110 to generate consent information simply by indicating selection or deselection from the list of service providers or data provided by the input unit 1013.

[0199] Additionally, when a user generates consent information through terminal 110, they can determine the amount of feedback from the service provider before generating consent information. For example, a user can decide on the data delivery destination (i.e., consent to data delivery) based on feedback such as being provided with virtual currency, coupons, or discounts in exchange for providing data to the service provider. Furthermore, for example, a user can also decide on the data delivery destination (i.e., consent to data delivery) based on feedback such as the amount of virtual currency or coupons / discounts provided in exchange for providing data to the service provider. The feedback can be made public by the service provider or recorded in the blockchain of the authentication server 200.

[0200] Next, terminal 110 generates a smart contract (S102) based on the consent information generated in step S101. This smart contract is programmed to perform a process that determines whether data can be provided. The smart contract may also include the consent information generated in step S101. Furthermore, the smart contract may also include a program that can perform a process that determines whether to provide data if the feedback is above a certain threshold.

[0201] Next, terminal 110 generates transaction data (hereinafter referred to as third transaction data) containing the generated consent information and smart contract (S103).

[0202] Next, terminal 110 sends the third transaction data generated in step S103 to authentication server 200a (S104). Additionally, in Figure 10In the example shown, terminal 110 sends the generated third transaction data to authentication server 200a, but it can also send it to authentication servers 200b and 200c. The same applies when sending it to authentication servers 200b and 200c.

[0203] Next, if the authentication server 200a obtains the third transaction data from the terminal 110 (S105), it verifies the obtained third transaction data (S106).

[0204] If the verification of the third transaction data fails in step S106 (S106 is marked "No"), the authentication server 200a sends a notification of this to the terminal 110 (S107).

[0205] On the other hand, if the verification of the third transaction data is successful in step S106 (marked as "Yes" in S106), authentication server 200a forwards the third transaction data to other authentication servers 200 (authentication servers 200b, 200c) (S108). Furthermore, the forwarded third transaction data is also verified in the other authentication servers 200.

[0206] Next, authentication servers 200a, 200b, and 200c execute the consensus algorithm (S109). If authentication servers 200a, 200b, and 200c verify that the third transaction data is legitimate (i.e., legitimate), they each generate a block containing the third transaction data. Furthermore, authentication servers 200a, 200b, and 200c record the block containing the third transaction data in the distributed ledger.

[0207] In this way, the smart contract and consent information created by terminal 110 are recorded in the distributed ledger.

[0208] Furthermore, a smart contract becomes executable and effective by being recorded in a distributed ledger (S110). Additionally, a smart contract becomes executable because it is recorded in the distributed ledger and stored in the working memory of an authentication server such as 200a.

[0209] [1.8.2 Data Registration and Processing]

[0210] Next, the data registration process between terminal 110, authentication servers 200a-200c and detection server 300 will be explained.

[0211] Figure 11 This is a sequence diagram illustrating the data registration process between the terminal 110, authentication servers 200a-200c, and detection server 300 in this embodiment. Figure 11The example shown illustrates the process of registering data obtained from terminal 110 into detection server 300.

[0212] First, terminal 110 acquires data such as measurement data obtained from sensors possessed by terminal 110 (S201). Terminal 110 is, for example, a wearable terminal, and when it has sensors, it acquires vital sign data such as step count or blood pressure data obtained from sensor-based measurement data as such data. In addition, as described above, this data is not limited to vital sign data such as step count or blood pressure data, but can be any data that can be used by service providers.

[0213] Next, terminal 110 generates transaction data (hereinafter referred to as first transaction data) containing information related to the data obtained in step S201 (S202). The information related to the data here is, for example, assumed to be the hash value and attribute information of the data. In this case, the first transaction data includes the blockchain address, hash value, attribute information, and signature.

[0214] Next, terminal 110 sends the data obtained in step S201 and the first transaction data generated in step S202 to detection server 300 (S203).

[0215] Next, if the detection server 300 obtains the first transaction data and data from the terminal 110 (S204), the detection server 300 detects whether the data obtained in step S201 is illegitimate data (S205).

[0216] In step S205, if the data obtained in step S201 is illegitimate ("Yes" in S205), the detection server 300 sends a notification of this meaning to the terminal 110 (S206).

[0217] On the other hand, in step S205, if the data obtained in step S201 is not illegitimate ("No" in S205), the detection server 300 sends the first transaction data obtained in step S204 to the authentication server 200a. Additionally, Figure 11 In the example shown, terminal 110 sends the first transaction data obtained in step S204 to authentication server 200a, but it can also send it to authentication servers 200b and 200c. The same applies when sending it to authentication servers 200b and 200c.

[0218] Next, the detection server 300 records the data obtained in step S201 (S208).

[0219] Next, if the authentication server 200a obtains the first transaction data from the detection server 300 (S209), it verifies the obtained first transaction data (S210). Alternatively, the order of steps S208 and S209 can be changed.

[0220] If the verification of the first transaction data fails in step S210 (S210 is marked as "No"), the authentication server 200a sends a notification of this to the detection server 300 (S211).

[0221] On the other hand, if the verification of the first transaction data is successful in step S210 (marked as "Yes" in S210), authentication server 200a forwards the first transaction data to other authentication servers 200 (authentication servers 200b, 200c) (S212). Furthermore, the forwarded first transaction data is also verified in the other authentication servers 200.

[0222] Next, authentication servers 200a, 200b, and 200c execute the consensus algorithm (S213). If authentication servers 200a, 200b, and 200c verify that the first transaction data is legitimate (i.e., legitimate), they each generate a block containing the first transaction data. Furthermore, authentication servers 200a, 200b, and 200c record the block containing the first transaction data in the distributed ledger.

[0223] In this way, the block containing the first transaction data containing information related to the data is recorded in the distributed ledger, and the data itself is recorded in the detection server 300.

[0224] Furthermore, in step S205, if the data obtained in step S201 is illegitimate ("Yes" in S205), the detection server 300 sends a notification of this intent to the terminal 110, but it may also send this notification of intent to the authentication server 200a. Moreover, when the detection server 300 also sends this notification of intent to the authentication server 200a, it may also generate transaction data indicating that the obtained data is illegitimate and send it to the authentication server 200a.

[0225] [1.8.3 Data Reference Processing]

[0226] Next, the data reference processing between terminal 110, authentication servers 200a-200c, detection server 300 and service server 400 will be explained.

[0227] Figure 12A and Figure 12BThis is a sequence diagram showing the data reference processing between the terminal 110, authentication servers 200a-200c, detection server 300, and service server 400 in this embodiment.

[0228] exist Figure 12A and Figure 12B The example shown illustrates the situation where the service server 400 obtains data from the detection server 300.

[0229] First, the service server 400, for example, decides to delegate the data retrieval after determining what kind of user data it wants to obtain (S301).

[0230] Next, the service server 400 generates a data retrieval delegate representing the data retrieval, and generates transaction data containing the data retrieval delegate (hereinafter referred to as the second transaction data) (S302).

[0231] Next, the service server 400 sends the generated second transaction data to the authentication server 200c (S303). Figure 12A In the example shown, the service server 400 sends the second transaction data generated in step S302 to the authentication server 200c, but it can also send it to authentication servers 200a and 200b. The same applies when sending it to authentication servers 200a and 200b.

[0232] Next, if the authentication server 200c obtains the second transaction data from the service server 400 (S304), it verifies the obtained second transaction data (S305).

[0233] If the verification of the second transaction data fails in step S305 (S305 is "No"), the authentication server 200c sends a notification of this to the service server 400 (S306).

[0234] On the other hand, if the verification of the second transaction data is successful in step S305 (marked as "Yes" in S305), the authentication server 200c forwards the second transaction data to the other authentication servers 200 (authentication servers 200a, 200b) (S307). Furthermore, the forwarded second transaction data is also verified in the other authentication servers 200.

[0235] Next, authentication servers 200a, 200b, and 200c execute the consensus algorithm (S308). If authentication servers 200a, 200b, and 200c verify that the second transaction data is legitimate (i.e., legitimate), they each generate a block containing the second transaction data. Furthermore, authentication servers 200a, 200b, and 200c record the block containing the second transaction data in the distributed ledger.

[0236] Next, authentication servers 200a, 200b, and 200c execute the smart contract recorded in the distributed ledger (S309). This smart contract is generated based on consent information and becomes executable by being recorded in the distributed ledger and stored in the working memory. Furthermore, the smart contract executed by authentication server 200, based on the consent information, determines whether the data entrusted by service server 400 can be provided. This smart contract sends a notification of the determination result to detection server 300 and service server 400 (S310).

[0237] Next, the detection server 300 and the service server 400 receive the notification sent in step S310 (S311). Here, it is assumed that the notification sent in step S310 indicates that the data entrusted by the service server 400 can be provided.

[0238] Next, the service server 400 delegates data provision to the detection server 300 (S312). Alternatively, the service server 400 may also access the detection server 300 to obtain data provision.

[0239] Next, if the detection server 300 obtains a data provision request from the service server 400 (S313), it confirms the notification received from the authentication server 200 in step S311 and determines whether it can provide the data requested by the service server 400 (S314). Alternatively, if in step S314 the notification received from the authentication server 200 in step S311 is confirmed and it is determined that the data requested by the service server 400 cannot be provided ("No" in S314), a notification indicating this is sent to the service server 400 (S315).

[0240] If in step S314 the notification received from the authentication server 200 in step S311 is confirmed and it is determined that the data entrusted by the service server 400 can be provided ("Yes" in S314), then the entrusted data is provided to the service server 400 (S316).

[0241] Next, the service server 400 obtains the entrusted data (S317).

[0242] Therefore, the service server 400 generates transaction data for the incentive payment (S318). More specifically, the service server 400 generates transaction data containing information related to the incentive payment.

[0243] Next, the service server 400 sends the transaction data generated in step S318 to the authentication server 200c (S319). Additionally, in Figure 12B In the example shown, service server 400 sends the generated transaction data to authentication server 200c, but it can also send it to authentication servers 200a and 200b. The same applies when sending the data to authentication servers 200a and 200b.

[0244] Next, if the authentication server 200c obtains transaction data from the service server 400 (S320), it verifies the obtained transaction data (S321).

[0245] If the verification of the transaction data fails in step S321 (S321 is marked as "No"), the authentication server 200c sends a notification of this to the service server 400 (S322).

[0246] On the other hand, if the transaction data is successfully verified in step S321 (marked as "Yes" in S321), the authentication server 200c forwards the transaction data to other authentication servers 200 (authentication servers 200a, 200b) (S323). Furthermore, the forwarded transaction data is also verified in the other authentication servers 200.

[0247] Next, authentication servers 200a, 200b, and 200c execute the consensus algorithm (S324). If authentication servers 200a, 200b, and 200c verify that the transaction data is legitimate (i.e., legitimate), they each generate a block containing that transaction data. Furthermore, authentication servers 200a, 200b, and 200c record the block containing the transaction data in the distributed ledger.

[0248] Next, authentication servers 200a, 200b, and 200c execute the smart contract related to incentive payments recorded in the distributed ledger (S325). This smart contract is generated based on incentive payments and becomes executable by being recorded in the distributed ledger and saved to the working memory. In this embodiment, the smart contract related to incentive payments can also provide incentive payments to users.

[0249] Furthermore, for example, the smart contract of authentication server 200a sends an incentive notification (S326) indicating that an incentive payment has been made to the user.

[0250] Alternatively, the service server 400 may generate transaction data containing information related to feedback provision in step S318. In this case, the smart contract related to feedback provision is executed in step S325.

[0251] In this way, data reference processing is performed between terminal 110, residence 100, authentication servers 200a-200c, detection server 300 and service server 400, and then incentive payment processing is performed.

[0252] In addition, Figure 12A In the example of data reference processing shown, the smart contract executed by the authentication server 200 sends its judgment result to the detection server 300 and the service server 400 in step S310, but it is not limited to this. The smart contract executed by the authentication server 200 may also send a notification to the user, i.e., the terminal 110, in step S310, indicating that the service server 400 has obtained the data.

[0253] In addition, Figure 12A In the example of data reference processing shown, in steps S311 and S312, after receiving the judgment result of the smart contract executed by the authentication server 200, the service server 400 delegates data provision and obtains data, but is not limited to this. Alternatively, in step S309, data recorded in the detection server 300 and delegated by the service server 400 can be provided to the service server 400 through the smart contract executed by the authentication server 200.

[0254] [1.8.4 Smart Contract Registration Processing Related to Incentive Payments]

[0255] Next, the registration and processing of smart contracts related to incentive payments between authentication servers 200a-200c and service server 400 will be explained.

[0256] Figure 13 This is a sequence diagram showing the smart contract registration process related to incentive payments between the authentication servers 200a-200c and the service server 400 in this embodiment.

[0257] First, the service server 400 generates a smart contract related to incentive payments (S401).

[0258] Next, the service server 400 generates transaction data (S402) containing the smart contract related to the incentive payment generated in step S401.

[0259] Next, the service server 400 sends the transaction data generated in step S402 to the authentication server 200a (S403). Figure 12AIn the example shown, service server 400 sends the transaction data generated in step S402 to authentication server 200a, but it can also send it to authentication servers 200b and 200c. The same applies when sending it to authentication servers 200b and 200c.

[0260] Next, if the authentication server 200a obtains transaction data from the service server 400 (S404), it verifies the obtained transaction data (S405).

[0261] If the verification of the transaction data fails in step S405 (S405 is "No"), the authentication server 200a sends a notification of this to the service server 400 (S406).

[0262] On the other hand, if the transaction data is successfully verified in step S405 (marked as "Yes" in S405), authentication server 200a forwards the transaction data to other authentication servers 200 (authentication servers 200b, 200c) (S407). Furthermore, the forwarded transaction data is also verified in the other authentication servers 200.

[0263] Next, authentication servers 200a, 200b, and 200c execute the consensus algorithm (S408). If authentication servers 200a, 200b, and 200c verify that the transaction data is legitimate (i.e., legitimate), they each generate a block containing the transaction data. Furthermore, authentication servers 200a, 200b, and 200c record the block containing the transaction data in the distributed ledger.

[0264] Next, the smart contract related to the incentive payment contained in the transaction data becomes executable and effective by being recorded in the distributed ledger (S409). Furthermore, the smart contract related to the incentive payment becomes executable because it is recorded in the distributed ledger and stored in the working memory of the authentication server 200a, etc.

[0265] [1.9 Effects of the Implementation Method]

[0266] As described above, according to the control method, recording medium, and improper data detection system of this disclosure, the data can be verified before information related to the acquired data is recorded in the distributed ledger, and the information related to the data, along with the meaning that the data is secure, can be recorded in the distributed ledger. Thus, blockchain technology can be used to ensure that the acquired data is secure. Therefore, data can be used with confidence using a distributed ledger.

[0267] Furthermore, according to this embodiment, user consent information can be securely recorded in a distributed ledger using blockchain technology. Moreover, according to this embodiment, only data collected from devices such as residence 100 or terminal 110 that is detected as not being improper can be provided to the service server 400 based on the user's consent. Thus, service providers can utilize user data that is guaranteed to be secure.

[0268] Furthermore, if the distributed ledger records information indicating that the data obtained from the home appliance or terminal 110 within the residence 100 is not illegitimate data, this also serves as proof that the home appliance or terminal 110 within the residence 100 is a device that provides data that is not illegitimate.

[0269] [2. Other variations]

[0270] Furthermore, this disclosure has been described based on the above embodiments, but it is not limited to the above embodiments. The following situations are also included in this disclosure.

[0271] (1) In the above embodiment, the body composition analyzer 105 and the blood pressure monitor 106 are connected to the controller 100 of the residence 100, but are not limited thereto. The body composition analyzer 105 and the blood pressure monitor 106 can also be wirelessly connected to the terminal 110. In this case, the terminal 110 can also collect the measurement data of the body composition analyzer 105 and the blood pressure monitor 106 and send the collected data to the detection server 300.

[0272] (2) In the above embodiments, the detection server 300 and the service server 400 have been described as different devices, but this is not a limitation. The detection server 300 and the service server 400 may also be the same device.

[0273] (3) In the above embodiment, the case of recording data obtained from the device in the detection server 300 has been described, but it is not limited thereto. A data collection server that collects data from devices such as the collection terminal 110 or the residence 100 may also be set up independently of the detection server 300.

[0274] In this case, the detection server 300 may also record only the data that is detected as not being illegitimate from the acquired data to the data collection server. Furthermore, the detection server 300 may also detect whether the data recorded by the data collection server is illegitimate.

[0275] (4) In the above embodiment, the detection unit 312 of the detection server 300 performs binary detection, such as detecting whether the data obtained from the device is illegitimate, but is not limited thereto. The detection server 300 may also assign a credit rating to the data if the data obtained from the device is not illegitimate. More specifically, the detection server 300 may also determine the credit rating of the data if it is detected that the obtained data is not illegitimate. Furthermore, the detection server 300 may include the determined credit rating in the information representing the data in the obtained first transaction data.

[0276] Here, the detection server 300 can use either a threshold to determine the creditworthiness of the data, or it can determine the proportion of data in the acquired data that is not illegitimate as the creditworthiness.

[0277] Furthermore, the detection server 300 can assign a credit score to some or all of the acquired data. For example, let 100 be the case that the acquired data is not illegitimate, and 0 be the case that the acquired data is illegitimate. In this case, the detection server 300 can also set the credit score to 100 if the value of the acquired step data changes by less than 3% compared to the value of the previously received step data, set the credit score to 90 if the change is less than 5%, and set the credit score to 30 if the change is more than 50%.

[0278] Furthermore, if the detection server 300 assigns a credit rating to data that is not detected as illegitimate, the service server 400 can also generate second transaction data containing the data that has been assigned the credit rating. Therefore, the service server 400 can only utilize data with high credit ratings among the non-illegitimate data.

[0279] In addition, the service server 400 can also change the incentives based on the creditworthiness of the provided data.

[0280] (5) In the above embodiment, the detection unit 312 of the detection server 300 is described as detecting whether the data obtained from the device is illegitimate data, but it is not limited thereto. The detection server 300 may also transfer the obtained data to other security servers different from the detection server 300, and receive the detection results of the security servers as to whether the data is illegitimate data.

[0281] Here, for example, the security server may not only have the same functions as the detection unit 312 of the detection server 300, but may also have the function of collecting data from other terminals and other devices, and verifying whether the data transferred from the detection server 300 is illegitimate or abnormal. Thus, the security server can verify data that cannot be verified as illegitimate or abnormal based solely on data obtained from a single terminal. Specifically, in cases where the weather in a certain area is bad, but there are discrepancies in the data from solar power generation devices obtained from residences in that area, the security server can verify that the transferred data from the solar power generation devices is illegitimate or abnormal. Furthermore, in cases where it is difficult to walk normally, such as during snowfall, but the step count data increases significantly, the security server can verify that the transferred step count data is illegitimate or abnormal. In this way, the security server can also perform verification using information other than the transferred data.

[0282] Furthermore, the security server may also have an input section and a display section. Data from the forwarded terminal 110 or residence 100 is displayed on the display section, and the forwarded data is judged to be illegitimate or abnormal based on the monitor's input to the input section. Additionally, the security server may assign a credibility rating to data determined not to be illegitimate based on the monitor's input to the input section.

[0283] (6) In the above embodiment, it is described that the detection server 300 performs the process of detecting whether the data obtained from the device is illegitimate only once, but it may also perform it multiple times. In this case, the detection server 300 may also generate transaction data indicating a change in the detection result if the content of the initial detection result changes, and send it to the authentication server 200. In addition, the transaction data generated at this time may contain an identifier of the data or information indicating a change in the detection result for the data. Furthermore, the detection server 300 may also notify the service server 400 of the information indicating a change in the detection result for the data.

[0284] (7) In the above embodiment, it was explained that the detection server 300 detects whether the data obtained from the device is illegitimate, but it is not limited thereto. The detection server 300 may also temporarily decide that the data is not illegitimate if the result of the first detection of whether the data obtained from the device is illegitimate is that the data is not illegitimate. Furthermore, if the result of the second (second) detection of whether the data is illegitimate is that the data is not illegitimate, the detection server 300 formally decides that the data is not illegitimate.

[0285] At this point, if a re-detection occurs after a certain period of time following the initial detection, and the data cannot be determined to be illegitimate, the detection server 300 formally decides that the data is not illegitimate. Here, the detection server 300 can also determine the time period or the number of re-detections based on the credibility of the data temporarily determined not to be illegitimate.

[0286] In addition, the detection server 300 can also perform detection again using data obtained in the past compared to this data or data obtained after the first detection.

[0287] (8) In the above embodiment, the description assumes that the terminal 110 generates consent information, but it is not limited to this. The terminal 110 may also set the level of data to be provided based on the consent information when generating consent information. Here, the level may also be a level of anonymization of the data that can be provided, as specified by the consent information. For example, regarding the level of data that can be provided, it may be specified that it can provide the data itself (all) collected from the terminal 110, or that it can provide the user's gender and age from the attributes of the collected data, but anonymize a portion of the collected data.

[0288] Furthermore, the consent information may specify the level of data that can be provided, including statistical data on the collected data, and may specify the anonymization of the data provider. In this case, for example, it may be assumed that the authentication server 200 or the detection server 300 records which data from the anonymized data provider was statistically analyzed. In this case, the service server 400 may also send incentives for providing the data to the authentication server 200 or the detection server 300, which in turn sends incentives to the anonymized data provider.

[0289] (9) In the above embodiment, it is explained that the detection server 300 detects whether the data obtained from the device is illegitimate, but it is not limited thereto. The detection server 300 may also refuse to receive data from the device if the device continuously detects illegitimate data.

[0290] (10) In the above embodiments, it is explained that the detection server 300 detects whether the data obtained from the device is illegitimate, but it is not limited thereto. The detection server 300 may also sign the data according to each device having a public key certificate and a private key, and judge the unsigned data as illegitimate.

[0291] (11) Specifically, each device in the above-described embodiments is a computer system composed of a microprocessor, ROM, RAM, hard disk unit, display unit, keyboard, mouse, etc. A computer program is recorded in the RAM or hard disk unit. Each device performs its function by having the microprocessor operate according to the computer program. Here, the computer program is composed of multiple command codes representing instructions for the computer in order to achieve the specified function.

[0292] (12) The devices described in the above embodiments may also be composed of a single system LSI (Large Scale Integration) as part or all of their constituent elements. A system LSI is a multifunctional LSI manufactured by integrating multiple components onto a single chip. Specifically, it is a computer system comprising a microprocessor, ROM, RAM, etc. The RAM stores a computer program. The system LSI performs its functions by having the microprocessor operate according to the computer program.

[0293] Furthermore, each of the constituent elements constituting the above-mentioned devices can be formed into a chip individually, or they can be included in part or all of them to form a chip.

[0294] Furthermore, while this is referred to as a system LSI, it is also called IC, LSI, Super LSI, or Very Large Scale LSI, depending on the level of integration. Moreover, the method of integrated circuitization is not limited to LSI; it can also be implemented using dedicated circuits or general-purpose processors. It can also utilize FPGAs (Field Programmable Gate Arrays) that can be programmed after LSI manufacturing, or reconfigurable processors that can reconfigure the connections or settings of the internal circuit cells of the LSI.

[0295] Furthermore, if advancements in semiconductor technology or other derived technologies lead to the development of integrated circuit technologies that replace LSIs, then these technologies can certainly be used for the integration of functional blocks. This could include applications in biotechnology, among others.

[0296] (13) Some or all of the constituent elements of the above-described devices may also be composed of IC cards or individual modules that can be detached from each device. The IC card or the module is a computer system composed of a microprocessor, ROM, RAM, etc. The IC card or the module may also include the aforementioned multi-functional LSI. The IC card or the module achieves its function by operating according to a computer program via a microprocessor. The IC card or the module may also be tamper-resistant.

[0297] (14) This disclosure may also be the method shown above. In addition, it may be a computer program that implements these methods by a computer, or a digital signal composed of the computer program described above.

[0298] Furthermore, the aforementioned computer program or digital signal can also be recorded onto a computer-readable recording medium, such as a floppy disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray Disc), semiconductor memory, etc. Alternatively, the aforementioned digital signal can also be recorded on these recording media.

[0299] Furthermore, the computer program or digital signal described above can also be transmitted via electrical communication lines, wireless or wired communication lines, networks such as the Internet, data broadcasting, etc.

[0300] Alternatively, this disclosure may also be a computer system having a microprocessor and a memory, wherein the memory records the computer program and the microprocessor operates according to the computer program.

[0301] Alternatively, the program or digital signal can be recorded in the recording medium and transferred, or the program or digital signal can be transferred via the network, etc., so that it can be implemented by an independent computer system.

[0302] (15) The above embodiments and the above variations can also be combined separately.

[0303] Industrial applicability

[0304] This disclosure can be used to control methods, procedures, and systems for detecting improper data. For example, it can be used to detect whether data such as a user's vital signs data or device history information is improper data, and to provide non-improper data to service providers to promote the use of data.

[0305] Label Explanation

[0306] 10 Improper Data Detection System

[0307] 100 residences

[0308] 101 Controller

[0309] 102 Solar power generation device

[0310] 103 Storage Battery

[0311] 104 Air Conditioner

[0312] 105 body composition

[0313] 106 Blood Pressure Monitor

[0314] 110 terminal

[0315] 200, 200a, 200b, 200c authentication servers

[0316] 211 Transaction Data Verification Department

[0317] 212 Block Generation Department

[0318] 213 Synchronization Department

[0319] 214 Smart Contract Execution Department

[0320] Records Department (numbers 215, 314, 414, 1014, 1104)

[0321] 216, 315, 415, 1015, 1105 Department of Communications

[0322] 300 Detection Server

[0323] 311 Data Management Department

[0324] 312 Testing Department

[0325] Transaction Data Generation Department (313, 413, 1012, 1101)

[0326] 400 Service Server

[0327] 411 Service Management Department

[0328] 412 User Management Department

[0329] 500 communication network

[0330] 1011 Control Department

[0331] Input sections 1013 and 1102

[0332] 1103 Data Acquisition Department

Claims

1. A control method of an improper data detection system having at least a detection server and a plurality of authentication servers, wherein The detection server acquires, from the device, data for use in a service and first transaction data including information indicating the data for use in the service and generated by the device, detects whether the data for use in the service is improper data, in a case where it is detected that the data for use in the service is not improper data, transmits the first transaction data to one of the plurality of authentication servers, the one of the plurality of authentication servers performs verification of the acquired first transaction data, in a case where the authenticity of the first transaction data is confirmed by the verification, executes, together with a plurality of other authentication servers other than the one of the plurality of authentication servers, a consensus algorithm for reaching a consensus on the authenticity of the first transaction data, in a case where a consensus on the authenticity of the first transaction data is reached by the consensus algorithm, records a block including the first transaction data in a distributed ledger, further, the one of the plurality of authentication servers acquires third transaction data including consent information related to use of data and a smart contract programmed to be able to perform processing of determining whether the data can be provided based on the consent information, performs verification of the acquired third transaction data, in a case where the authenticity of the third transaction data is confirmed by the verification, executes, together with the plurality of other authentication servers other than the one of the plurality of authentication servers, the consensus algorithm for reaching a consensus on the authenticity of the third transaction data, in a case where a consensus on the authenticity of the third transaction data is reached by the consensus algorithm, records a block including the third transaction data in the distributed ledger.

2. The control method of claim 1, wherein, In the control method, further, in a case where it is detected that the data is improper data, the detection server generates fourth transaction data in which the information of the first transaction data includes that the data is improper data, in a case where it is detected that the data is improper data, the one of the plurality of authentication servers performs verification of the fourth transaction data, in a case where the authenticity of the fourth transaction data is confirmed by the verification, the one of the plurality of authentication servers executes, together with the plurality of other authentication servers, the consensus algorithm for reaching a consensus on the authenticity of the fourth transaction data, in a case where a consensus on the authenticity of the fourth transaction data is reached by the consensus algorithm, the one of the plurality of authentication servers records a block including the fourth transaction data in the distributed ledger.

3. A control method in an improper data detection system having at least a plurality of authentication servers, wherein One of the plurality of authentication servers obtains, from the device, data for use in a service and first transaction data including information indicating the data for use in the service and generated by the device, detects whether the data for use in the service is illegitimate data, performs verification of the first transaction data in a case where it is detected that the data for use in the service is not illegitimate data, executes, in a case where the legitimacy of the first transaction data is confirmed by the verification, a consensus algorithm for reaching consensus on the legitimacy of the first transaction data together with a plurality of other authentication servers among the plurality of authentication servers other than the one authentication server, and records a block including the first transaction data in a distributed ledger in a case where consensus on the legitimacy of the first transaction data is reached by the consensus algorithm. Further, one of the plurality of authentication servers obtains third transaction data including consent information related to use of data and a smart contract programmed to be able to perform processing for determining whether the data can be provided based on the consent information, performs verification of the obtained third transaction data, executes, in a case where the legitimacy of the third transaction data is confirmed by the verification, a consensus algorithm for reaching consensus on the legitimacy of the third transaction data together with a plurality of other authentication servers among the plurality of authentication servers other than the one authentication server, and records a block including the third transaction data in a distributed ledger in a case where consensus on the legitimacy of the third transaction data is reached by the consensus algorithm.

4. The control method according to claim 1 or 3, wherein The illegitimate data detection system further includes a service server. In the control method, the service server generates second transaction data including a data acquisition request indicating a request to acquire the data, and transmits the second transaction data to one of the plurality of authentication servers. In a case where the one of the plurality of authentication servers has acquired the second transaction data, the data is provided to the service server when it is determined that the data can be provided to the service server by executing the smart contract based on the acquired third transaction data.

5. The control method according to claim 1 or 3, wherein In detecting whether the data is illegitimate data, in a case where the measured step count data is acquired from the device as the data, the data is detected as illegitimate data when the step count data includes a step count measured in a predetermined period that is equal to or greater than a threshold value.

6. The control method according to claim 1 or 3, wherein In detecting whether the data is illegitimate data, in a case where step count data including a measured step count and position information at the time of measurement is acquired from the device as the data, the data is detected as illegitimate data when the step count data includes a step count in a state where the position information does not change for a predetermined time or more.

7. The control method according to claim 1 or 3, wherein In detecting whether the data is not the improper data, in a case where the step count data including the counted step count and the heartbeat number at the time of counting is acquired from the device as the data, when the step count data including the step count in a state where the heartbeat number does not change for a predetermined time or more is included in the step count data, it is detected that the data is the improper data.

8. The control method according to claim 1 or 3, wherein In detecting whether the data is not the improper data, in a case where the data is acquired from the device, when the information indicating the abnormality of the device is acquired, it is detected that the data is the improper data.

9. The control method according to claim 1 or 3, wherein In detecting whether the data is not the improper data, in a case where it is detected that the data is not the improper data, the credit degree for the data is further determined, and the determined credit degree is included in the information indicating the data in the acquired first transaction data.

10. The control method according to claim 1 or 3, wherein In the first transaction data, the data or the hash value of the data is included as the information indicating the data.

11. A non-transitory recording medium readable by a computer on which a program is recorded, the program causing the computer to execute a control method in an improper data detection system having at least a plurality of authentication servers, wherein, The program causes a computer to execute the following processing: acquiring, from a device, data for a service and first transaction data including information indicating the data and generated by the device; detecting whether the data for the service is improper data; in a case where it is detected that the data is not improper data, one of a plurality of authentication servers performs verification of the acquired first transaction data; in a case where the one of the plurality of authentication servers confirms the legitimacy of the first transaction data by performing the verification, the one of the plurality of authentication servers executes, together with a plurality of other authentication servers other than the one of the plurality of authentication servers, a consensus algorithm for reaching consensus on the legitimacy of the first transaction data; in a case where consensus on the legitimacy of the first transaction data is reached by the consensus algorithm, the one of the plurality of authentication servers records a block including the first transaction data in a distributed ledger, and further, one of the plurality of authentication servers acquires third transaction data including consent information related to use of data and a smart contract programmed to execute processing for determining whether the data can be provided based on the consent information; performs verification of the acquired third transaction data; in a case where the legitimacy of the third transaction data is confirmed by performing the verification, executes, together with a plurality of other authentication servers other than the one of the plurality of authentication servers, a consensus algorithm for reaching consensus on the legitimacy of the third transaction data; and in a case where consensus on the legitimacy of the third transaction data is reached by the consensus algorithm, records a block including the third transaction data in the distributed ledger.

12. An improper data detection system provided with a plurality of authentication servers and a detection server, wherein The above-described detection server includes a detection unit that detects whether data for a service acquired from a device is improper data, and a data management unit that acquires first transaction data generated by the device that includes information indicating the data, and transmits the first transaction data to one of a plurality of authentication servers in a case where it is detected that the data is not improper data, the one of the plurality of authentication servers including a transaction data verification unit that performs verification of the acquired first transaction data in a case where it is detected that the data is not improper data, a block generation unit that executes, together with a plurality of other authentication servers of the plurality of authentication servers other than the one authentication server, a consensus algorithm for reaching a consensus regarding legitimacy of the first transaction data in a case where legitimacy of the first transaction data is confirmed by performing the verification, and a recording unit that records, by the one of the plurality of authentication servers, a block including the first transaction data in a distributed ledger in a case where a consensus regarding legitimacy of the first transaction data is reached by the consensus algorithm, further, one of the plurality of authentication servers acquires third transaction data including consent information regarding use of data and a smart contract programmed to be able to perform processing of determining whether the data can be provided based on the consent information, the transaction data verification unit performs verification of the acquired third transaction data, the block generation unit executes, together with a plurality of other authentication servers of the plurality of authentication servers other than the one authentication server, a consensus algorithm for reaching a consensus regarding legitimacy of the third transaction data in a case where legitimacy of the third transaction data is confirmed by performing the verification, and the recording unit records, in a case where a consensus regarding legitimacy of the third transaction data is reached by the consensus algorithm, a block including the third transaction data in the distributed ledger.

Images