Data distribution system, data distribution device, data distribution program, and data distribution method
The data distribution system tracks derivative data creation using a blockchain-based history management database to ensure effective utilization, preventing unnecessary distribution and reducing data leakage.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- KAGOSHIMA UNIV
- Filing Date
- 2022-09-14
- Publication Date
- 2026-07-24
Smart Images

Figure 0007894573000001 
Figure 0007894573000002 
Figure 0007894573000003
Abstract
Description
Technical Field
[0001] The present invention relates to a data distribution system, a data distribution device, a data distribution program, and a data distribution method.
Background Art
[0002] As disclosed in Patent Document 1, there is known a data distribution device that manages the history of data distribution using a history management database composed of a blockchain.
[0003] Each time data is distributed, this data distribution device registers in the history management database a data obtained by attaching the electronic signature of the provider who prepared the data to the hash value of the data and the metadata associated with the data. The metadata includes information for identifying the provider of the data, information for identifying the acquirer of the data, and information representing the date and time when the data was created.
Prior Art Documents
Patent Documents
[0004]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0005] In the method according to Patent Document 1, the provider of the data cannot grasp whether the distributed data is effectively utilized by the acquirer. In particular, when the data is used for creating a learned model or other derivative data, there may be a case where the provider wants to grasp whether the data is effectively utilized in order to prepare more useful data.
[0006] Furthermore, if the likelihood of the data being effectively utilized is low, it is desirable to stop distributing the data. Continuing to distribute data that is not effectively utilized unnecessarily increases the risk of data leakage. This invention was made in view of the circumstances described above.
[0007] The object of the present invention is to provide a technology that can determine whether or not distributed data is being effectively utilized, and that can stop the distribution of data that is unlikely to be effectively utilized. [Means for solving the problem]
[0008] The data distribution system according to the present invention is A data distribution device having a data distribution unit that intermittently distributes to users multiple sets of data with different content, one set of data at a time interval, A user registration device that, each time the data is distributed from the data distribution unit to the user and derivative data obtained using the data is created by the user, registers derivative data creation history information indicating that the derivative data was created by the user in a history management database for managing the history of the use of the data. Equipped with, The aforementioned data distribution device A derivative data creation history information monitoring unit checks whether the derivative data creation history information is registered in the history management database at a predetermined time, and if the derivative data creation history information is not registered in the history management database, it stops the subsequent distribution of the data from the data distribution unit to the user. It has.
[0009] The aforementioned data distribution device Each time the distribution of one set of data from the data distribution unit to the user is completed, the data distribution history information registration unit registers data distribution history information indicating that the distribution of the data to the user has been completed in the history management database. It may further have
[0010] The aforementioned data distribution history information includes: Provider identification information that identifies the provider who prepared the aforementioned data, The recipient identification information identifies the recipient, who is the user who received the data, Data identification information that identifies the data, To prove that the data was delivered from the provider to the recipient, the provider's digital signature and the recipient's digital signature, It may include
[0011] The aforementioned history management database is implemented using blockchain technology. The data distribution history information registration unit issues a transaction on the blockchain requesting verification that the distribution of the data to the user has been completed. The issued transaction may be verified by a miner on the blockchain, and the contents of the verified transaction may be finalized on the blockchain as data distribution history information, which is a non-fungible token, by a smart contract held on the blockchain.
[0012] The aforementioned derived data creation history information includes: Creator identification information that identifies the creator, who is the user who created the derived data, Derived data identification information that identifies the said derived data, The creator's digital signature to prove that the creator created the derived data, The data distribution history information, which indicates that the data used to create the derived data was distributed to the creator, is identified in the history management database as data usage identification information, It may include
[0013] Using the data distributed to the user from the data distribution unit and the parent derived data which is the derived data created in the past, child derived data which is derived data different from the parent derived data is created by the user, In the derived data creation history information about the child derived data, parent derived data identification information for identifying, within the history management database, the derived data creation history information indicating that the parent derived data used for creating the child derived data was created, may be included.
[0014] The history management database is realized by a blockchain, The user registration device issues, on the blockchain, a transaction requesting verification that the derived data was created by the user, The issued transaction is verified by a miner on the blockchain, and the content of the verified transaction is finalized on the blockchain as the derived data creation history information which is a non-fungible token by a smart contract held in the blockchain.
[0015] The history management database is realized by a blockchain, Every time the derived data created by the user is distributed externally, the user registration device issues, on the blockchain, a transaction requesting verification that the distribution of the derived data was performed, The issued transaction is verified by a miner on the blockchain, and the content of the verified transaction is finalized on the blockchain as the derived data distribution history information which is a non-fungible token by a smart contract held in the blockchain.
[0016] The history management database is realized by a blockchain, The data distribution device Whenever one set of the data is prepared by the provider in a state where it can be distributed to the user, a data preparation history information registration unit that registers, in the history management database, data preparation history information indicating that the data has been prepared by the provider further includes The data preparation history information registration unit issues, on the blockchain, a transaction requesting verification that the data has been prepared by the provider The issued transaction is verified by a miner on the blockchain, and the content of the verified transaction may be finalized on the blockchain as the data preparation history information, which is a non-fungible token, by a smart contract held on the blockchain
[0017] The data distribution device prepares the original data for each user by replicating a common set of original data into the same number of sets of original data as the number of users, and creates different data for each user by performing data processing unique to each user on each of the original data prepared for each user, a data processing unit further includes The data created for each user by the data processing unit may be distributed by the data distribution unit to the corresponding user
[0018] The data distribution device When the distribution of the data from the data distribution unit to the user is completed, or when sales report information indicating that the derivative data created using the data has been sold is obtained from the user who created the derivative data, a charging processing unit that performs a charging process for charging the user for the consideration of the data may further include
[0019] The data distribution device according to the present invention A data distribution unit that intermittently delivers multiple sets of data with different content to users, one set of data at a time interval, A history management database for managing the usage history of the aforementioned data, comprising: a derived data creation history information monitoring unit that accesses the history management database each time the aforementioned data is distributed from the data distribution unit to the user and derived data obtained using said data is created by said user, and a derived data creation history information indicating that said derived data was created by said user is registered in the history management database; Equipped with, The aforementioned derived data creation history information monitoring unit, At predetermined intervals, the system checks whether the derived data creation history information is registered in the history management database, and if the derived data creation history information is not registered in the history management database, it stops the subsequent distribution of the data from the data distribution unit to the user.
[0020] The data distribution program according to the present invention is On the computer, A data distribution function that intermittently delivers multiple sets of data with different content to users, one set of data at a time interval, A history management database for managing the usage history of the aforementioned data, comprising a derivative data creation history information monitoring function that accesses the history management database each time the aforementioned data is distributed to the user by the data distribution function and derivative data obtained using said data is created by said user, and derivative data creation history information indicating that said derivative data was created by said user is registered in the history management database. To make it happen, The aforementioned derived data creation history information monitoring function, At predetermined intervals, the system checks whether the derived data creation history information is registered in the history management database, and if the derived data creation history information is not registered in the history management database, it stops the subsequent distribution of the data to the user by the data distribution function.
[0021] The data distribution method according to the present invention is A data distribution step in which a data distribution device intermittently distributes to a user multiple sets of data with different content, one set of data at a time interval, The user registration device registers derived data creation history information in a history management database for managing the history of data usage, each time the data is distributed to the user from the data distribution device and derived data is created by the user using the data. The data distribution device checks at a predetermined time whether the derived data creation history information is registered in the history management database, and if the derived data creation history information is not registered in the history management database, it stops the subsequent distribution of the data to the user. It has. [Effects of the Invention]
[0022] According to the present invention, if a user fails to register the history of derivative data creation in the history management database, the distribution of data to that user will be stopped. Therefore, when data is used by a user to create derivative data, the user is prompted to register the history of derivative data creation in the history management database. As a result, the data provider can determine whether the distributed data is being effectively used by checking whether or not the history of derivative data creation is registered in the history management database.
[0023] Furthermore, if the distributed data is not used to create derivative data, the information about the creation of the derivative data will not be registered in the history management database, and thus the distribution of the data to the user will automatically stop. In this way, the distribution of data that is unlikely to be effectively utilized can be stopped. [Brief explanation of the drawing]
[0024] [Figure 1] A conceptual diagram showing the configuration of the data distribution system according to the first embodiment. [Figure 2] A conceptual diagram showing the relationship between data and derived data according to the first embodiment. [Figure 3] A conceptual diagram showing the configuration of the distribution destination management table according to the first embodiment. [Figure 4] A flowchart illustrating the procedure for creating data distribution history information according to the first embodiment. [Figure 5] A conceptual diagram showing the connections between data distribution history information and derived data creation history information within the history management database according to the first embodiment. [Figure 6] A flowchart illustrating the data distribution eligibility management process according to the first embodiment. [Figure 7] A flowchart illustrating the data distribution process according to the first embodiment. [Figure 8] A conceptual diagram showing the configuration of a data distribution device according to the first embodiment. [Figure 9] A conceptual diagram showing the configuration of the data processing unit according to the second embodiment. [Figure 10] A conceptual diagram showing the configuration of the data distribution system according to the third embodiment. [Figure 11] A conceptual diagram showing the configuration of the data distribution system according to the fourth embodiment. [Modes for carrying out the invention]
[0025] The data distribution system according to the embodiment will be described below with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals.
[0026] [First Embodiment] As shown in Figure 1, the data distribution system 300 according to this embodiment includes a data distribution device 100 that distributes data DTA used as material for creating derived data, and a first user registration device 200A, a second user registration device 200B, and a third user registration device 200C, each of which is communicably connected to the data distribution device 100 via a communication line CL.
[0027] The data distribution device 100 is provided by the provider who prepares and provides the data DTA. Even if the person who prepares the data DTA and the person who provides the prepared data DTA are different, they will be collectively referred to as the provider.
[0028] The first user registration device 200A, the second user registration device 200B, and the third user registration device 200C are provided to the first, second, and third users, respectively, who receive data DTA from the provider via distribution. Each of the first, second, and third users creates derived data using the data DTA obtained from the provider.
[0029] In this embodiment, Data DTA is measurement data representing the results of measuring objects such as the ocean and other environments, objects, and living organisms, and is used for processing, analysis, integration, etc., for the purpose of creating derived data. That is, derived data refers to data obtained based on Data DTA, specifically data obtained by using Data DTA as material and applying processing, analysis, integration, etc., to Data DTA. The concept of derived data also includes software programs.
[0030] Below, with reference to Figure 2, we will explain a specific example of data DTA and derived data.
[0031] As shown in Figure 2, the derived data DTB is specifically a trained model. The training data used to create this trained model is the data DTA mentioned above. That is, each of the first to third users mentioned above creates the derived data DTB as a trained model using supervised machine learning with the data DTA obtained from the provider as training data. Note that well-known algorithms such as neural networks can be used for machine learning.
[0032] The training data DTA includes input data DTAa and output data DTAb, which are correlated with each other.
[0033] The input data DTAa represents the ocean conditions at the time of fishing. Specifically, the ocean condition data includes data representing the geographical location where fishing took place, data representing the sea surface temperature at that location, data representing the ocean currents at that location, data representing the salinity of the seawater at that location, and data representing the tides and lunar phase at the time of fishing.
[0034] The output data DTAb represents the catch volume when fishing is carried out under the sea conditions described by the corresponding input data DTAa.
[0035] The provider acquires the aforementioned input data DTAa and output data DTAb during the fishing process using a fishing vessel equipped with observation equipment to monitor ocean conditions. Data DTA, which includes this input data DTAa and output data DTAb, is used as training data. As a result, derived data DTB is obtained as a trained model that outputs an estimated catch amount when data on ocean conditions is input.
[0036] Returning to Figure 1, let's continue the explanation. The data distribution device 100 has a data distribution unit 110 that distributes the data DTA described above. The data distribution unit 110 intermittently distributes to each of the first to third users, one set of data DTA at a time interval, constituting a collection of continuously generated data (hereinafter referred to as the streaming data group).
[0037] Here, "intermittently with a period of time" does not necessarily have to be periodic; in this embodiment, it means "every day or every few days." That is, the provider goes out to sea in a fishing boat equipped with observation equipment to observe sea conditions every day or every few days, and obtains one set of data DTA as training data using the observation equipment each time it goes out to sea. In this way, the provider prepares one new set of data DTA with different content from the previous one every day or every few days. Then, each time the provider prepares a new set of data DTA, it distributes that set of data DTA from the first user to the third user through the data distribution unit 110.
[0038] When the first user obtains the data DTA distributed by the data distribution unit 110, they use the first user registration device 200A to access the data distribution unit 110 via the communication line CL.
[0039] The data distribution unit 110 then displays a screen on the first user registration device 200A requesting the input of information to confirm that the user is the first user, specifically the first user's user ID and password. On that screen, the first user enters their user ID and password using the first user registration device 200A.
[0040] The data distribution unit 110 verifies that the user is the first user based on the entered user ID and password, and then allows the first user to download the data DTA. Subsequently, the first user begins creating the derived data DTB using the data DTA downloaded from the data distribution unit 110.
[0041] Similarly, the second and third users download the data DTA using the second user registration device 200B and the third user registration device 200C, respectively, and create derived data DTB using the downloaded data DTA.
[0042] The data distribution unit 110 includes a distribution destination management table 111 to confirm the distribution destination in the distribution of the data DTA described above. The configuration of the distribution destination management table 111 will be described below with reference to Figure 3.
[0043] As shown in Figure 3, the distribution destination management table 111 is data that associates each of the first to third users with a registered user ID 111a that identifies the user, a registered password 111b that proves the user's authenticity, and distribution eligibility information 111c. The registered user ID 111a and registered password 111b are registered in advance prior to the distribution of the data DTA.
[0044] The data distribution unit 110 can confirm that the person who accessed it is one of the first to third users by checking if the combination of user ID and password sent to it matches the combination of registered user ID 111a and registered password 111b registered in the distribution destination management table 111. The distribution eligibility information 111c will be described later.
[0045] Returning to Figure 1, let's continue the explanation. The data distribution device 100 also includes a data distribution history information registration unit 120 that registers in the history management database 400 each time the distribution of one set of data DTA is completed in the manner described above.
[0046] The history management database 400 is a database for managing the usage history of data DTA.
[0047] The history management database 400 may be a public database managed by a specific third party other than the data DTA provider and the first to third users. In that case, the history management database 400 is maintained by a server other than the data distribution device 100, the first user registration device 200A, the second user registration device 200B, and the third user registration device 200C, which are owned by that specific third party.
[0048] Furthermore, the history management database 400 may be a distributed database shared by multiple nodes participating in a network not shown, specifically a blockchain. In that case, the concept of nodes may also include the data distribution device 100, the first user registration device 200A, the second user registration device 200B, and the third user registration device 200C.
[0049] Specifically, each time the data distribution history information registration unit 120 completes the distribution of a set of data DTA from the data distribution unit 110 to any of the first user, second user, or third user, it registers data distribution history information 410 in the history management database 400 as evidence that the distribution of data DTA to that user has been completed.
[0050] When the data distribution history information 410 is registered in the history management database 400 by the data distribution history information registration unit 120, information that identifies the data distribution history information 410 within the history management database 400 (hereinafter referred to as the data distribution history information registration ID) is assigned to it. In other words, the data distribution history information 410 is registered in the history management database 400 together with the data distribution history information registration ID.
[0051] The data distribution history information 410 includes the following information (A)-(E). In the following, the first user, second user, and third user will be collectively referred to as "users."
[0052] (A) Provider identification information that identifies the provider who prepared the Data TTA. For example, provider identification information may include the provider's user ID. Provider identification information clarifies who distributed the Data TTA.
[0053] (B) Recipient identification information that identifies the recipient, who is the user who received the Data DTA. Examples of recipient identification information include the recipient's user ID. Recipient identification information clarifies who received the Data DTA.
[0054] (C) Data identification information that identifies the data DTA distributed from the provider to the recipient. For example, at least one of the following information (C1)-(C3) can be used as data identification information.
[0055] (C1) Hash value of the data DTA. (C2) Access location information representing the network access location of the data DTA or encrypted data DTA. Access location information is, for example, a URL. When encrypting the data DTA, it is preferable to include authentication information such as an access key and password to verify its contents. (C3) The encrypted data DTA itself. In this case as well, it is preferable to include authentication information to verify the contents of the encrypted data DTA.
[0056] Furthermore, as data identification information (C), in addition to at least one of the above information (C1)-(C3), at least one of the following information (C4) and (C5) may be used.
[0057] (C4) Data description information that explains the contents of the data DTA. Examples of data description information include text data that explains the contents of the data DTA in natural language. (C5) Information representing an identifier that describes the format of the data DTA. Examples of information representing this identifier include information representing the media type.
[0058] (D) Data delivery date and time information that identifies the date and time when the data DTA was delivered from the provider to the recipient. Examples of data delivery date and time information include timestamps.
[0059] (E) Previous data identification information that identifies the data distribution history information 410 for the previous set of data DTA that was distributed immediately before the current data DTA, within the history management database 400. The data distribution history information registration ID for the previous set of data DTA is used for this previous data identification information.
[0060] As previously described, the collection of multiple sets of data DTAs intermittently provided by the data distribution unit 110 constitutes a single streaming data group. Therefore, it is convenient if the data distribution history information 410 for the data DTAs that constitute a common streaming data group is correlated with each other in the history management database 400. For this reason, the data distribution history information 410 also includes information identifying the previous data.
[0061] (F) The provider's digital signature and the recipient's digital signature to prove that the Data Transcript (DTA) has been provided from the provider to the recipient. These digital signatures represent the mutual agreement between the provider and the recipient regarding the content of the information consisting of (A)-(E) above (hereinafter referred to as the Data Delivery Confirmation Information).
[0062] The procedure for obtaining the provider's and recipient's digital signatures will be explained below, referring to Figure 4. In the specific example described below, a public-key cryptography scheme will be used to form the digital signatures. As a prerequisite, it is assumed that the recipient already possesses the provider's public key in addition to their own private key. Similarly, it is assumed that the provider already possesses the recipient's public key in addition to their own private key.
[0063] As shown in Figure 4, first, the provider sends to the recipient a plaintext data distribution confirmation information consisting of the previously described information (A)-(E), and a first encrypted data distribution confirmation information obtained by encrypting the plaintext with the provider's private key (step S11). This first encrypted data distribution confirmation information corresponds to the provider's digital signature.
[0064] The encryption and transmission in step S11 are performed by the data distribution unit 110. The recipient is one of the user registration devices 200A to 200C owned by the acquirer (hereinafter referred to as user registration device 200).
[0065] Next, the recipient verifies the information transmitted by the provider using the provider's public key (step S12). Specifically, the recipient verifies the content of the plaintext representing the data distribution confirmation information described above, and verifies whether the hash value of that plaintext matches the hash value obtained by decrypting the first encrypted data distribution confirmation information described above using the provider's public key. Note that the operations in step S12, namely the calculation of the hash value, verification of the match, and decryption of the first encrypted data distribution confirmation information, are performed by the user registration device 200.
[0066] If the hash values are confirmed to match, the recipient sends back to the provider a plaintext data distribution confirmation and a second encrypted data distribution confirmation, which is the plaintext encrypted with the recipient's private key (step S13). This second encrypted data distribution confirmation corresponds to the recipient's digital signature. The reply in step S13 is made by the user registration device 200.
[0067] Next, the provider verifies the information returned by the recipient using the recipient's public key (step S14). Specifically, the provider verifies the content of the plaintext representing the data distribution confirmation information described above, and verifies whether the hash value of that plaintext matches the hash value obtained by decrypting the second encrypted data distribution confirmation information described above using the recipient's public key. Note that the operations in step S14, namely the calculation of the hash value, verification of the match, and decryption of the second encrypted data distribution confirmation information, are performed by the data distribution unit 110.
[0068] If it is confirmed that the hash values match, the provider registers the data distribution history information 410, which consists of the provider's own digital signature made up of the first encrypted data distribution confirmation information created in step S11, the recipient's digital signature made up of the second encrypted data distribution confirmation information obtained in step S14, and the aforementioned data distribution confirmation information, in the history management database 400 (step S15).
[0069] As previously described, the data distribution history information 410 is registered in the history management database 400 along with a data distribution history information registration ID used to identify the data distribution history information 410 within the history management database 400. This registration is performed by the data distribution history information registration unit 120.
[0070] Returning to Figure 1, let's continue the explanation. As described above, the data distribution history information 410 is registered in the history management database 400 by the data distribution history information registration unit 120, while the recipient who receives one set of data DTA from the data distribution unit 110 uses that set of data DTA to create the derived data DTB described above.
[0071] Furthermore, the user registration device 200 owned by the acquirer may be used to create the derived data DTB, or a device other than the user registration device 200 may be used.
[0072] As described above, the user registration device 200 registers derived data creation history information 420 in the history management database 400 as evidence that the derived data DTB has been created, each time that a set of data DTA is distributed to the acquirer from the data distribution unit 110 and a derived data DTB is created by the acquirer using that set of data DTA.
[0073] The derived data creation history information 420 includes the following information (a)-(e):
[0074] (a) Creator identification information that identifies the creator who created the derived data DTB. For example, creator identification information could include the creator's user ID. Creator identification information clarifies who created the derived data DTB.
[0075] (b) Derived data identification information that identifies the created derived data DTB. For example, at least one of the following information (b1)-(b3) can be used as derived data identification information.
[0076] (b1) The hash value of the derived data DTB. (b2) Access location information representing the network access location of the derived data DTB or encrypted derived data DTB. Access location information is, for example, a URL. When the derived data DTB is encrypted, it is preferable to include authentication information such as an access key and password to verify its contents. (b3) The encrypted derived data DTB itself. In this case as well, it is preferable to include authentication information to verify the contents of the encrypted derived data DTB.
[0077] Furthermore, as data identification information (b), in addition to at least one of the above information (b1)-(b3), at least one of the following information (b4) and (b5) may be used.
[0078] (b4) Derived data description information that explains the contents of the derived data DTB. Examples of derived data description information include text data that explains the contents of the derived data DTB in natural language. (b5) Information representing an identifier that expresses the format of the derived data DTB. Examples of information representing this identifier include information representing the media type.
[0079] (c) Derived data creation date and time information that identifies the date and time the derived data DTB was created. Examples of derived data creation date and time information include a timestamp.
[0080] (d) The creator's digital signature to prove that the creator created the derived data DTB. This digital signature represents the creator's own approval of the contents of the information consisting of (a)-(c) above (hereinafter referred to as the derived data creation confirmation information). Specifically, this creator's digital signature may use encrypted derived data creation confirmation information, which is obtained by encrypting the plaintext representing the derived data creation confirmation information with the creator's private key.
[0081] (e) Data usage identification information that identifies the data distribution history information 410 in the history management database 400, which represents evidence that the data DTA used to create the derived data DTB was delivered to its creator. The data distribution history information registration ID described above for the data DTA used to create the derived data DTB is used for this data usage identification information.
[0082] When the derivative data creation history information 420 described above is registered in the history management database 400 by the user registration device 200, information that identifies the derivative data creation history information 420 within the history management database 400 (hereinafter referred to as the derivative data creation history information registration ID) is assigned to it. In other words, the derivative data creation history information 420 is registered in the history management database 400 together with the derivative data creation history information registration ID.
[0083] Furthermore, the creator may use the data DTA obtained this time and previously created derived data DTB (hereinafter referred to as parent derived data) to create a derived data DTB (hereinafter referred to as child derived data) that is different from the parent derived data.
[0084] For example, consider the case where the DTA data acquired in this instance is used as training data to further train a pre-trained model as parent derived data, thereby obtaining child derived data as an updated pre-trained model. In such a case, the derived data creation history information 420 for the child derived data shall further include the following information (f).
[0085] (f) Parent derived data identification information that identifies the derived data creation history information 420 in the history management database 400, which indicates that the parent derived data used to create the child derived data has been created.
[0086] As a result, the derivative data creation history information 420 for multiple derivative data DTBs that have a parent-child relationship will be linked within the history management database 400. Here, "multiple derivative data DTBs that have a parent-child relationship" means not only child derivative data when a certain derivative data is viewed as a parent derivative data, but also grandchild derivative data which is child derivative data when that child derivative data is viewed as a parent derivative data, and great-grandchild derivative data which is child derivative data when that grandchild derivative data is viewed as a parent derivative data, and so on.
[0087] The following describes how the data distribution history information 410 and the derived data creation history information 420 are linked within the history management database 400, with reference to Figure 5.
[0088] As shown in Figure 5, first, the data distribution history information 410_j for the current set of data DTAs includes the previously described previous data identification information (E), which identifies the data distribution history information 410_j-1 for the previous set of data DTAs, and is registered as data distribution history information registration ID 411. Therefore, it becomes clear that the current set of data DTAs and the previous set of data DTAs constitute a common streaming data set.
[0089] Furthermore, each of the derived data creation history information 420_k-1 for the parent derived data and the derived data creation history information 420_k for the child derived data includes a data distribution history information registration ID 421, which is the aforementioned data usage identification information (e) that identifies the data distribution history information 410 for the data DTA used to create the derived data.
[0090] Furthermore, the derived data creation history information 420_k for the child derived data also includes the data distribution history information registration ID 422, which is the parent derived data identification information (f) described above, and identifies the derived data creation history information 420_k-1 for the parent derived data used to create that child derived data. In this way, multiple derived data DTBs that have a parent-child relationship are clearly linked.
[0091] Let's return to Figure 1 and continue the explanation. As explained above, users receive data DTA from the data distribution unit 110 through the user registration device 200. Whenever a user creates derived data DTB, the user registration device 200 registers derived data creation history information 420 in the history management database 400, which proves that the user created the derived data DTB.
[0092] On the other hand, the data distribution device 100 also includes a derived data creation history information monitoring unit 130 that performs data distribution eligibility management processing to manage whether or not data DTA can be distributed to users.
[0093] The data distribution availability management process checks whether the derived data creation history information 420 is registered in the history management database 400 at a predetermined time, and if the derived data creation history information 420 is not registered in the history management database 400, it stops the subsequent distribution of data DTA from the data distribution unit 110 to the user.
[0094] The following will specifically explain the data distribution eligibility management process performed by the derived data creation history information monitoring unit 130, with reference to Figure 6.
[0095] As shown in Figure 6, first, the derived data creation history information monitoring unit 130 determines whether a predetermined timing has arrived to confirm that the derived data creation history information 420 has been registered (step S21). If the predetermined timing has not arrived (step S21; NO), the derived data creation history information monitoring unit 130 returns to step S21.
[0096] In this embodiment, the “predetermined timing” refers to the time when a predetermined period (hereinafter referred to as the “derived data creation period”) has elapsed, calculated from the time when the data distribution unit 110 has most recently completed the distribution of data DTA to the user.
[0097] As previously described, the streaming data set is intermittently distributed by the data distribution unit 110, one set of data DTA at a time. The time interval between the distribution of one set of data DTA and the distribution of the next set of data DTA will be called the data distribution interval. The period required to create the derived data mentioned above is shorter than the data distribution interval. Specifically, in this embodiment, the period required to create the derived data is one day.
[0098] When the predetermined timing described above arrives (step S21; YES), the derived data creation history information monitoring unit 130 accesses the history management database 400 and checks whether a new registration of derived data creation history information 420, indicating that the derived data DTB was created by the user, has been made in the history management database 400 (step S22).
[0099] Here, "new registration" refers to the registration of derived data creation history information 420, which indicates that a derived data DTB has been created based on the data DTA most recently delivered to the user. In other words, the determination in step S22 corresponds to an operation to confirm whether or not the data DTA most recently delivered to the user was properly utilized by the user to create the derived data DTB.
[0100] If no new derived data creation history information 420 has been registered in the history management database 400 (step S22; NO), the derived data creation history information monitoring unit 130 will stop the distribution of data DTA from the data distribution unit 110 to the user, because the most recently distributed data DTA to the user has not been used to create derived data DTB (step S23).
[0101] Referring to Figure 3, the process of step S23 will be explained in detail. As previously described, the distribution destination management table 111 shown in Figure 3 is used by the data distribution unit 110 to authenticate whether the person who accessed it to request the distribution of data DTA is a genuine user.
[0102] This distribution destination management table 111 stores not only the registered user ID 111a and registered password 111b, which are used for user authentication, but also distribution permission information 111c, which indicates whether or not the distribution of data DTA to that user is permitted.
[0103] The data distribution unit 110 authenticates the user using the registered user ID 111a and registered password 111b, and then distributes the data DTA to the user only if the distribution permission information 111c indicates that the distribution of the data DTA to that user is permitted. If the distribution permission information 111c indicates that the distribution of the data DTA to that user is prohibited, the data distribution unit 110 does not distribute the data DTA to that user.
[0104] It is assumed that information indicating that the distribution of data DTA to users is permitted is stored in advance as distribution permission information 111c. Distribution permission information 111c is rewritten by the derived data creation history information monitoring unit 130.
[0105] In other words, in step S23 described above, the derived data creation history information monitoring unit 130 rewrites the distribution eligibility information 111c for the above user to prohibit the distribution of data DTA to that user. As a result, after the rewrite, the data distribution unit 110 stops distributing data DTA to that user.
[0106] Returning to Figure 6, let's continue the explanation. After the derivative data creation history information monitoring unit 130 rewrites the distribution eligibility information 111c in step S23, it returns to step S21 again.
[0107] Furthermore, if a new entry of derived data creation history information 420 has been made in the history management database 400 in step S22 (step S22; YES), the derived data creation history information monitoring unit 130 returns to step S21 without rewriting the distribution availability information 111c, because the most recently distributed data DTA to the above user has been used to create the derived data DTB.
[0108] Next, referring to Figure 7, the data distribution process performed by the data distribution unit 110 and the data distribution history information registration unit 120 will be explained.
[0109] As shown in Figure 7, when the data distribution unit 110 has completed the distribution of the previous set of data DTA and the data distribution interval described above has elapsed, and a new set of data DTA has been prepared by the provider (step S31; YES), it determines whether or not there is an access request from a user using the user registration device 200 (step S32).
[0110] When the data distribution unit 110 receives an access request from a user using the user registration device 200 (step S32; YES), it first determines whether the user is genuine or not (step S33). Specifically, the data distribution unit 110 determines whether the user ID and password entered by the user using the user registration device 200 match the registered user ID 111a and registered password 111b that are pre-stored in the distribution destination management table 111.
[0111] Next, the data distribution unit 110, after confirming that the user is genuine (step S33; YES), determines whether or not data distribution to that user is permitted (step S34). Specifically, the data distribution unit 110 determines whether or not the distribution permission information 111c stored in the distribution destination management table 111 indicates that data DTA distribution to that user is permitted.
[0112] Then, the data distribution unit 110 distributes the data DTA to the user only if the distribution permission information 111c indicates that it permits the distribution of the data DTA to that user (step S34; YES) (step S35). In other words, it permits the user to download the data DTA to the user registration device 200.
[0113] Next, the data distribution unit 110 obtains an electronic signature from the user in the manner described with reference to Figure 4, and then registers data distribution history information 410 in the history management database 400 indicating that the distribution of data DTA to the user has been completed (step S36). After that, the process returns to step S31.
[0114] Furthermore, if the data distribution unit 110 cannot confirm in step S33 that the user is genuine (step S33; NO), it cannot distribute the data DTA to that person, so it displays an error on the user registration device 200 (step S37) and returns to step S31.
[0115] Furthermore, if the data distribution unit 110 determines in step S34 that the distribution eligibility information 111c prohibits the distribution of data DTA to the user (step S34; NO), it cannot distribute the data DTA to that user, so it displays an error on the user registration device 200 (step S37) and returns to step S31.
[0116] The functions of the data distribution device 100 have been described above. Finally, the hardware configuration of the data distribution device 100 will be explained with reference to Figure 8.
[0117] As shown in Figure 8, the data distribution device 100 includes a communication device 100a that handles communication with external devices. Specifically, the communication device 100a is responsible for communication with the user registration device 200 shown in Figure 1, and for accessing the history management database 400.
[0118] Furthermore, the data distribution device 100 includes a storage device 100b that stores the aforementioned distribution destination management table 111 and data DTA. The provider prepares a new set of data DTA in the storage device 100b at each of the aforementioned data distribution intervals. In this way, one set of data DTA is uploaded to the storage device 100b at each data distribution interval. The storage device 100b also stores a data distribution program 100c that defines the functions of the data distribution device 100.
[0119] Furthermore, the data distribution device 100 includes a processor 100d that executes the data distribution program 100c. By the processor 100d executing the data distribution program 100c, the functions of the data distribution unit 110, the data distribution history information registration unit 120, and the derived data creation history information monitoring unit 130 shown in Figure 1 are realized, particularly the data distribution eligibility management process shown in Figure 6 and the data distribution process shown in Figure 7.
[0120] The first embodiment has been described above. According to the first embodiment, the following effects can be obtained.
[0121] Since the data distribution device 100 performs data distribution eligibility management processing, if a user fails to register the derivative data creation history information 420 in the history management database 400, the distribution of data DTA to that user will be stopped. Therefore, when data DTA is used by a user to create derivative data DTB, the user is prompted to register the derivative data creation history information 420 in the history management database 400. As a result, the provider of data DTA can determine whether the distributed data DTA is being effectively used by checking whether or not the derivative data creation history information 420 is registered in the history management database 400.
[0122] Furthermore, if the distributed data DTA is not used to create derived data DTB, the derived data creation history information 420 will not be registered in the history management database 400, and thus the distribution of the data DTA to users will automatically stop. In this way, the provider of data DTA can stop the distribution of data DTA that is unlikely to be effectively utilized. This contributes to suppressing the leakage of data DTA.
[0123] Furthermore, when a derived data DTB is created by a user, the derived data creation history information 420 registered in the history management database 400 includes data usage identification information (e) that identifies the data distribution history information 410 for the data DTA used to create that derived data DTB. Therefore, for each derived data DTB, the history management database 400 can properly manage the history of which data DTA was used to create that derived data DTB.
[0124] Furthermore, if a user creates a child derived data (DTB) that is different from the parent derived data (DTA) using the data (DTA) and the parent derived data (DTB) that was created in the past, the derived data creation history information 420_k for that child derived data includes parent derived data identification information (f) that identifies the derived data creation history information 420_k-1 for the parent derived data. Therefore, for each derived data (DTB), the history of which parent derived data it was derived from can be properly managed in the history management database 400.
[0125] Furthermore, each time the distribution of a set of data DTA from the data distribution unit 110 to a user is completed, data distribution history information 410 is registered in the history management database 400 as evidence that the data DTA was delivered to that user. Therefore, the history management database 400 can properly manage the history of which user each set of data DTA was transferred to.
[0126] Furthermore, the data distribution history information 410_j for this set of data DTAs includes previous data identification information (E) that identifies the data distribution history information 410_j-1 for the previous set of data DTAs. Therefore, the local temporal relationships and the global interconnected relationships of multiple data DTAs constituting the streaming data set can be properly managed in the history management database 400.
[0127] [Second Embodiment] In the first embodiment described above, when a set of data DTAs constituting the streaming data set was prepared by the provider, a copy of that set of data DTAs was distributed directly from the first user to the third user. In other words, when a set of data DTAs was prepared, the data DTAs distributed from the first user to the third user were identical to each other.
[0128] In contrast, it is also possible for the first user to deliver data Tactics Addresses (DTAs) to the third user that are essentially the same in content but formally different. Specific examples are given below.
[0129] As shown in Figure 9, the data distribution device 100 according to this embodiment further includes a data processing unit 140 that creates a different data DTA for each user using the original data DTO which is the source of the data DTA. Note that in Figure 9, for ease of understanding, the communication line CL interposed between the data distribution unit 110 and the user registration device 200 is not shown.
[0130] The data processing unit 140 prepares the original data for each user by duplicating a common set of original data DTOs into a number of sets equal to the number of users, i.e., three sets of original data DTOs in this embodiment. It then applies user-specific data processing to each of the original data DTOs prepared for each user, thereby creating a different data DTA for each user. The data DTA created in this way for each user is then distributed to the corresponding user by the data distribution unit 110.
[0131] Specifically, the data processing unit 140 comprises a first data processing unit 141, a second data processing unit 142, and a third data processing unit 143.
[0132] The first data processing unit 141 creates first user data DTA1 to be distributed to the first user by applying data processing specific to the first user to the original data DTO that has been duplicated for the first user. The first user data DTA1 is distributed to the first user's first user registration device 200A by the data distribution unit 110.
[0133] The second data processing unit 142 creates second user data DTA2 to be distributed to the second user by applying data processing specific to the second user to the original data DTO that has been duplicated for the second user. The second user data DTA2 is distributed to the second user's second user registration device 200B by the data distribution unit 110.
[0134] The third data processing unit 143 creates third-user data DTA3 to be distributed to the third user by applying data processing specific to the third user to the original data DTO that has been duplicated for the third user. The third-user data DTA3 is distributed to the third user's third-user registration device 200C by the data distribution unit 110.
[0135] The following describes a specific example of data processing performed by the data processing unit 140. The original data DTO includes geographic data for multiple points representing the points at sea where fishing took place, and fishing data that associates the catch amount at each point. The geographic data represents the latitude and longitude of each point.
[0136] In this case, the data processing performed by the data processing unit 140 refers to the operation of slightly shifting the latitude and longitude of each point represented by the geographic data within an acceptable margin of error. Specifically, the method of shifting, or more precisely, the combination of the latitude shift amount and the longitude shift amount that represent the shift amount as a vector, is made different between the first user and the second user.
[0137] In other words, the first user data DTA1 to the third user data DTA3, which are the result of shifting the geographic data from the original DTO (Data Set of Objects) (fishing data), have the same fishing data, but their geographic data is subtly different. Therefore, there is a one-to-one correspondence between the geographic data and the users. Consequently, there is a one-to-one correspondence between the data DTA and the users.
[0138] Furthermore, as previously described, the data distribution history information 410 registered in the history management database 400 shown in Figure 1 includes data identification information (C) that identifies the data DTA distributed to the user. This data identification information (C) has content that distinguishes each of the data DTA1 for the first user to the data DTA3 for the third user.
[0139] Therefore, evidence of which of the data for the first user DTA1 to the data for the third user DTA3 was delivered to each of the first, second, and third users is accumulated in the history management database 400 as data delivery history information 410.
[0140] Therefore, according to this embodiment, if any of the first to third users leaks the data DTA, the provider can use the leaked data DTA to identify which of the first to third users leaked it.
[0141] Specifically, the provider obtains data identification information (C) from the hash value of the leaked data DTA, and extracts data distribution history information 410 containing that data identification information (C) from the history management database 400. Then, the provider can identify whether the recipient of the data DTA is the first user, second user, or third user, based on the recipient identification information (B) contained in the extracted data distribution history information 410. Since there is a one-to-one correspondence between the data DTA and the recipient of the data DTA, the provider can identify which of the first user, second user, or third user leaked the data DTA.
[0142] As described above, according to this embodiment, if a user leaks data DTA, that user will be identified. Therefore, it is possible to suppress the leakage of data DTA by users. The other configurations and effects are the same as in the first embodiment.
[0143] [Third Embodiment] The data distribution system 300 according to the first embodiment shown in Figure 1 may further include a configuration in which the provider charges the user a fee for the data DTA each time the data DTA is distributed to the user, or each time the derived data DTB created by the user is sold. Specific examples are described below.
[0144] As shown in Figure 10, the data distribution device 100 according to this embodiment further includes a billing processing unit 150 that performs billing processing to charge users for data DTA. Specifically, billing processing refers to the process of sending a request to a server of a financial institution that manages the user's financial institution account to deduct the payment for data DTA from the user's account, and receiving confirmation of the deduction from that server.
[0145] The billing processing unit 150 performs billing processing to charge a user for the data DTA once the distribution of the data DTA from the data distribution unit 110 to the user is complete. In this case, the data distribution history information 410 may also include billing completion information indicating that the charge for the distributed data DTA has been completed.
[0146] Furthermore, when the billing processing unit 50 obtains sales report information from the user registration device 200 of a user who has created derived data DTB using data DTA, indicating that the derived data DTB has been sold, it performs billing processing to charge the user for the data DTA.
[0147] In this case, prior to billing, the billing processing unit 50 may access the derived data creation history information 420 stored in the history management database 400 and verify that the author of the derived data DTB is indeed the user using the author identification information (a), derived data identification information (b), and the author's digital signature (d), and also verify that the data DTA was indeed used to create the derived data DTB using the usage data identification information (e).
[0148] [Fourth Embodiment] The history management database 400 shown in Figure 1 may be a blockchain. In this specification, "database" refers to an organized collection of electronically stored and accessible data, and the concept includes blockchains.
[0149] If the history management database 400 is a blockchain, for example, transactions such as registering data distribution history information 410 and transactions registering derived data creation history information 420 may be broadcast to each node, combined into one or more blocks, and registered on the blockchain.
[0150] The following describes the specific case where the history management database 400 is a blockchain. Ethereum® is used as an example of a blockchain platform. In the following description of this embodiment, the history management database 400 as a blockchain will be simply referred to as blockchain 400.
[0151] As shown in Figure 11, in this embodiment, transactions TR1, TR2, TR3, and TR4 are issued on blockchain 400 at the following stages: (1) when the data DTA is ready for distribution, (2) when the data DTA is distributed, (3) when the derived data DTB is created, and (4) when the derived data DTB is distributed. Each stage will be described in detail below.
[0152] (1) First, in the data distribution device 100, each time a set of data DTA is prepared by the provider to be distributed to a user, transaction TR1 is issued on the blockchain 400. The data distribution device 100 according to this embodiment includes a data preparation history information registration unit 160 that issues the transaction TR.
[0153] Specifically, the data preparation history information registration unit 160 issues transaction TR1 on blockchain 400, requesting verification that the data DTA has been prepared by the provider. The issued transaction TR1 is verified by miners on blockchain 400. In other words, it is verified that the data DTA has been properly prepared by its provider. The miner who performs the verification first receives a block reward, specifically Gas in Ethereum®.
[0154] Specifically, transaction TR1 contains plaintext representing the content to be authenticated, and a digital signature obtained by encrypting that plaintext with the provider's private key. Verification by the miner refers to confirming that the plaintext contained in transaction TR1 matches the digital signature contained in transaction TR1 when decrypted with the public key. The same applies to transactions TR2-TR4, which will be described later.
[0155] The verified transaction TR1 is then finalized on blockchain 400 as data preparation history information 430, which is a non-fungible token (NFT), by a smart contract held on blockchain 400. The non-fungible token conforms to the ERC-71 standard.
[0156] As described above, the data preparation history information registration unit 160 indirectly registers data preparation history information 430 on the blockchain 400 through the issuance of transaction TR1 each time a set of data DTA is prepared by the provider and ready for distribution to the user. The data preparation history information 430 proves that the data DTA was prepared by the provider, that is, that the creator of the data DTA is the provider.
[0157] (2) Next, each time the distribution of one set of data DTA from the data distribution device 100 to the user is completed, the data distribution history information registration unit 120 issues transaction TR2 on the blockchain 400.
[0158] Transaction TR2 includes the digital signature of the provider of the data DTA and the digital signature of the user receiving the data DTA, and requests verification that the delivery of the data DTA from the provider to the user has been completed.
[0159] The issued transaction TR2 is verified by miners on Blockchain 400. This verifies that the data DTA was legitimately delivered from its provider to its user. The miner who performs the first verification receives the block reward.
[0160] Then, the contents of the verified transaction TR2 are finalized on blockchain 400 as the aforementioned data distribution history information 410, which is a non-fungible token, by a smart contract held on blockchain 400.
[0161] As described above, the data distribution history information registration unit 120 indirectly registers the aforementioned data distribution history information 410 on the blockchain 400 through the issuance of transaction TR2 each time the distribution of one set of data DTA from the provider to the user is completed. The data distribution history information 410 proves that the data DTA was legitimately distributed from the provider to the user.
[0162] (3) Next, each time a user creates derived data DTB using data DTA, the user registration device 200 issues transaction TR3 on the blockchain 400.
[0163] Transaction TR3 contains the digital signature of the user who created the derived data DTB and requests verification that the derived data DTB was created by that user. The issued transaction TR3 is verified by miners on blockchain 400. In other words, it verifies that the derived data DTB was created by that user. The miner who performs the verification first receives the block reward.
[0164] Then, the contents of the verified transaction TR3 are finalized on blockchain 400 as the aforementioned derived data creation history information 420, which is a non-fungible token, by a smart contract held on blockchain 400.
[0165] As described above, the user registration device 200 indirectly registers the derived data creation history information 420 described above in the blockchain 400 through the issuance of transaction TR3 each time a derived data DTB is created by a user. The derived data creation history information 420 proves that the derived data DTB was created by that user.
[0166] (4) Next, each time that the derived data DTB created by the user is distributed externally, the user registration device 200 issues transaction TR4 on the blockchain 400. Here, "external" specifically refers to devices other than the data distribution device 100 and the user registration device 200, which are not shown in the diagram.
[0167] Transaction TR4 includes the digital signature of the user distributing the derived data DTB and the digital signature of the acquirer obtaining the derived data DTB, and requests verification that the derived data DTB has been distributed externally.
[0168] The issued transaction TR4 is verified by miners on blockchain 400. This verifies that its derived data DTB has been delivered externally. The miner who performs the verification first receives the block reward.
[0169] Then, the contents of the verified transaction TR4 are finalized on blockchain 400 as derived data distribution history information 440, which is a non-fungible token, by a smart contract held on blockchain 400.
[0170] As described above, the user registration device 200 indirectly registers derived data distribution history information 440 in the blockchain 400 through the issuance of transaction TR4 each time derived data DTB is distributed externally. The derived data distribution history information 440 proves that the derived data DTB has been distributed externally.
[0171] The first to fourth embodiments have been described above. The following modifications are also possible.
[0172] In the first embodiment, it is assumed that a derived data DTB is created for each set of data DTAs, and the “predetermined timing” shown in step S21 of Figure 6 is exemplified as the time when the required period for creating the derived data has elapsed from the time when the distribution of one set of data DTAs to the user was most recently completed. On the other hand, a derived data DTB may be created using multiple sets of data DTAs, in which case the “predetermined timing” may be the time when, for example, three days have elapsed as the required period for creating the derived data from the time when the distribution of multiple sets, for example, three sets of data DTAs from the previous set, was most recently completed to the user.
[0173] In the first to third embodiments, the case where there are three users, the first to third users, who utilize the data DTA was described as an example, but there may be one user or four or more users. Also, as previously stated, the users may consist of multiple parties. For example, the distribution company that actually distributes the data DTA using the data distribution device 100 may be a party that has been commissioned to distribute the data by a preparation company that prepares the data DTA, and in that case as well, the distribution company and the preparation company will be collectively referred to as the "provider".
[0174] In the first embodiment, we exemplify a case where the training data DTA shown in Figure 2 is fishing data that associates data representing the sea conditions at the time of fishing with data representing the catch amount under those sea conditions, and the derived data TDB is a trained model for determining whether fishing is permissible or for estimating the catch amount. The combination of the training data DTA and the trained model DDB is not limited to these. For example, the data DTA may be engine state data that associates data representing various physical quantities in an operating engine with data representing the engine's health in that state, and the derived data TDB may be a trained model for determining the engine's health.
[0175] Furthermore, the derived data DTB is not limited to pre-trained models, but may also be application software other than pre-trained models, created using the data DTA as source material.
[0176] The data distribution program 100c shown in Figure 8 can also be installed on existing smartphones, tablets, or other computers to enable the functionality of the data distribution device 100. The data distribution program 100c can be distributed via a communication line or stored on a recording medium. [Explanation of symbols]
[0177] 100...Data distribution device, 100a...communication equipment, 100b...Storage device, 100c...Data distribution program, 100d... Processor, 110...Data Distribution Department, 111...Distribution destination management sheet, 111a...Registered User ID, 111b...Registration password, 111c... Information on whether distribution is possible, 120...Data distribution history information registration section, 130...Derived Data Creation History Information Monitoring Unit, 140...Data Processing Department, 141...First Data Processing Department, 142...Second Data Processing Department, 143...Third Data Processing Department, 150... Billing processing unit, 160...Data preparation history information registration unit, 200... User registration device, 200A... Registration device for the first user, 200B... Second user registration device, 200C...Registration device for third user, 300...Data distribution system, 400…History management database (blockchain), 410...Data distribution history information, 410_j…Data distribution history information, 410_j-1…Data distribution history information, 411...Data distribution history information registration ID (previous data identification information), 420... Derived data creation history information, 420_k... Derived data creation history information, 420_k-1…Derived data creation history information, 421...Data distribution history information registration ID (information identifying data used), 422...Data distribution history information registration ID (parent-derived data identification information), 430...Data preparation history information, 440... Derived data distribution history information, CL...communication line, DTA...Data, DTAa... Input data, DTAb... Output data, DTA1…Data for the first user, DTA2…Data for the second user, DTA3...Data for third-party users, DTB... Derived Data, DTO...Original data, TR1, TR2, TR3, TR4... Transactions.
Claims
1. A data distribution device having a data distribution unit that intermittently distributes to users multiple sets of data with different content, one set of data at a time interval, A user registration device that, each time the data is distributed from the data distribution unit to the user and derivative data obtained using the data is created by the user, registers derivative data creation history information indicating that the derivative data was created by the user in a history management database for managing the history of the use of the data. Equipped with, The aforementioned data distribution device A derivative data creation history information monitoring unit checks whether the derivative data creation history information is registered in the history management database at a predetermined time, and if the derivative data creation history information is not registered in the history management database, it stops the subsequent distribution of the data from the data distribution unit to the user. A data distribution system having the following features.
2. The aforementioned data distribution device Each time the distribution of one set of data from the data distribution unit to the user is completed, the data distribution history information registration unit registers data distribution history information indicating that the distribution of the data to the user has been completed in the history management database. The data distribution system according to claim 1, further comprising the above.
3. The aforementioned data distribution history information includes: Provider identification information that identifies the provider who prepared the aforementioned data, The recipient identification information identifies the recipient, who is the user who received the data, Data identification information that identifies the data, To prove that the data was delivered from the provider to the recipient, the provider's digital signature and the recipient's digital signature, The data distribution system according to claim 2, which includes the following:
4. The aforementioned history management database is implemented using blockchain technology. The data distribution history information registration unit issues a transaction on the blockchain requesting verification that the distribution of the data to the user has been completed. The issued transaction is verified by a miner on the blockchain, and the contents of the verified transaction are finalized on the blockchain as data distribution history information, which is a non-fungible token, by a smart contract held on the blockchain. The data distribution system according to claim 2 or 3.
5. The aforementioned derived data creation history information includes: Creator identification information that identifies the creator, who is the user who created the derived data, Derived data identification information that identifies the said derived data, The creator's digital signature to prove that the creator created the derived data, The data distribution history information, which indicates that the data used to create the derived data was distributed to the creator, is identified in the history management database as data usage identification information, The data distribution system according to claim 2, which includes the following:
6. Using the data distributed to the user from the data distribution unit and the parent derived data which is derived data created in the past, the user creates child derived data which is derived data different from the parent derived data. The derived data creation history information for the aforementioned child derived data includes: Parent derived data identification information that identifies the parent derived data used to create the child derived data, which indicates that the parent derived data has been created, within the history management database. The data distribution system according to claim 1, which includes the following:
7. The aforementioned history management database is implemented using blockchain technology. The user registration device issues a transaction on the blockchain requesting verification that the derived data was created by the user. The issued transaction is verified by a miner on the blockchain, and the contents of the verified transaction are finalized on the blockchain as the derived data creation history information, which is a non-fungible token, by a smart contract held on the blockchain. The data distribution system according to claim 1, 5, or 6.
8. The aforementioned history management database is implemented using blockchain technology. Whenever the user registration device distributes the derived data created by the user to an external source, it issues a transaction on the blockchain requesting verification that the derived data has been distributed. The issued transaction is verified by a miner on the blockchain, and the contents of the verified transaction are finalized on the blockchain as derived data distribution history information, which is a non-fungible token, by a smart contract held on the blockchain. The data distribution system according to claim 1.
9. The aforementioned history management database is implemented using blockchain technology. The aforementioned data distribution device Each time a provider prepares a set of the aforementioned data to be delivered to the user, a data preparation history information registration unit registers data preparation history information indicating that the provider has prepared the data in the history management database. It further possesses, The data preparation history information registration unit issues a transaction on the blockchain requesting verification that the data has been prepared by the provider. The issued transaction is verified by a miner on the blockchain, and the contents of the verified transaction are finalized on the blockchain as data preparation history information, which is a non-fungible token, by a smart contract held on the blockchain. The data distribution system according to claim 1.
10. The aforementioned data distribution device A data processing unit creates different data for each user by duplicating a common set of source data into a number of sets equal to the number of users, and by applying user-specific data processing to each of the source data prepared for each user. It further possesses, The data created for each user by the data processing unit is distributed to the corresponding user by the data distribution unit. The data distribution system according to claim 1.
11. The aforementioned data distribution device When the distribution of the data from the data distribution unit to the user is completed, or when sales report information indicating that the derived data has been sold is obtained from the user who created the derived data using the data, the billing processing unit performs a billing process to charge the user for the data. The data distribution system according to claim 1, further comprising the above.
12. A data distribution unit that intermittently delivers multiple sets of data with different content to users, one set of data at a time interval, A history management database for managing the usage history of the aforementioned data, comprising: a derived data creation history information monitoring unit that accesses the history management database each time the aforementioned data is distributed from the data distribution unit to the user and derived data obtained using said data is created by said user, and a derived data creation history information indicating that said derived data was created by said user is registered in the history management database; Equipped with, The aforementioned derived data creation history information monitoring unit, At predetermined intervals, the system checks whether the derived data creation history information is registered in the history management database, and if the derived data creation history information is not registered in the history management database, it stops the subsequent distribution of the data from the data distribution unit to the user. Data distribution device.
13. On the computer, A data distribution function that intermittently delivers multiple sets of data with different content to users, one set of data at a time interval, A history management database for managing the usage history of the aforementioned data, comprising a derivative data creation history information monitoring function that accesses the history management database each time the aforementioned data is distributed to the user by the data distribution function and derivative data obtained using said data is created by said user, and derivative data creation history information indicating that said derivative data was created by said user is registered in the history management database. To make it happen, The aforementioned derived data creation history information monitoring function, At predetermined intervals, the system checks whether the derived data creation history information is registered in the history management database, and if the derived data creation history information is not registered in the history management database, it stops the subsequent distribution of the data to the user by the data distribution function. Data distribution program.
14. A data distribution step in which a data distribution device intermittently distributes to a user multiple sets of data with different content, one set of data at a time interval, The user registration device registers derived data creation history information in a history management database for managing the history of data usage, each time the data is distributed to the user from the data distribution device and derived data is created by the user using the data. The data distribution device checks at a predetermined time whether the derived data creation history information is registered in the history management database, and if the derived data creation history information is not registered in the history management database, it stops the subsequent distribution of the data to the user. A data distribution method having the following characteristics.