JP2019220146A - Management method, management apparatus, and, program - Google Patents

Abstract

To provide a management method of the software version capable of preventing the generation of alteration of the information under management.SOLUTION: The management method includes: a first management apparatus in multiple management apparatuses receives a piece of transaction data that includes a piece of first information relevant to a first version of a software, a piece of second information relevant to a second version of the software version-upped by a developer on the basis of the first version, a piece of identification information of the developer, and an electronic signature from a unit connected to the first management apparatus via a network (S124); the first management apparatus verifies the validity of the transaction data by using the electronic signature included in the received transaction data (S114); and when the transaction data is valid, each of the multiple management apparatuses stores the transaction data on a distributed ledger (S115).SELECTED DRAWING: Figure 12

Description

  The present invention relates to a management method, a management device, and a program.

  In a management system for managing software, version information indicating the version of software developed by the developer is managed together with the identification information of the developer (for example, see Patent Document 1).

JP 2014-203352 A

  However, the conventional management system has a problem that it is difficult to prevent tampering of information managed by the management server.

  Accordingly, the present invention provides a software version management method, such as a management method for suppressing the occurrence of falsification of managed information.

  A management method according to an aspect of the present invention is a software version management method executed by a version management system, wherein the version management system includes a plurality of management devices holding a distributed ledger, The management method includes: a first management device among the plurality of management devices, a first information regarding a first version of the software, and a second information of the software upgraded by a developer based on the first version. Receiving transaction data including version information, the developer identification information, and an electronic signature from a device connected to the first management device via a network; Corrects the transaction data using the electronic signature included in the received transaction data. Verify the sex, when the transaction data is valid, each of the plurality of management apparatus storing the transaction data in the distributed ledger.

  Note that these comprehensive or specific aspects may be realized by a recording medium such as a system, a method, an integrated circuit, a computer program or a computer-readable CD-ROM, and the system, the method, the integrated circuit, and the computer program. And any combination of recording media.

  According to the present invention, it is possible to provide a software version management method that suppresses the occurrence of falsification of managed information.

FIG. 1 is an explanatory diagram showing a software version series based on agile development. FIG. 2 is an explanatory diagram showing the exchange of tokens in agile development. FIG. 3 is an explanatory diagram illustrating the configuration of the management system according to the first embodiment. FIG. 4 is a block diagram showing a configuration of the storage server according to the first embodiment. FIG. 5 is a block diagram illustrating a configuration of the development device according to the first embodiment. FIG. 6 is a block diagram illustrating a configuration of the management device according to the first embodiment. FIG. 7 is an explanatory diagram illustrating a first example of transaction data according to the first embodiment. FIG. 8 is an explanatory diagram illustrating a second example of the transaction data according to the first embodiment. FIG. 9 is an explanatory diagram illustrating a third example of the transaction data according to the first embodiment. FIG. 10 is an explanatory diagram illustrating an example of transaction data stored in the block chain according to the first embodiment. FIG. 11 is a sequence diagram illustrating a first process in the management system according to the first embodiment. FIG. 12 is a sequence diagram illustrating a second process in the management system according to the first embodiment. FIG. 13 is an explanatory diagram illustrating branching of a version sequence according to the second embodiment. FIG. 14 is an explanatory diagram illustrating the configuration of the management system according to the second embodiment. FIG. 15 is a block diagram illustrating a configuration of a control device according to the second embodiment. FIG. 16 is a block diagram illustrating a configuration of a management device according to the second embodiment. FIG. 17 is a first explanatory diagram illustrating transaction data stored in the block chain according to the second embodiment. FIG. 18 is a second explanatory diagram illustrating the transaction data stored in the block chain according to the second embodiment. FIG. 19 is a sequence diagram illustrating processing in the management system according to the second embodiment. FIG. 20 is an explanatory diagram illustrating an example of transaction data according to the second embodiment. FIG. 21 is a flowchart showing a process related to a version sequence included in the consensus algorithm according to the second embodiment. FIG. 22 is an explanatory diagram illustrating the abolition of the version series according to the third embodiment. FIG. 23 is a block diagram illustrating a configuration of a control device according to Embodiment 3. FIG. 24 is a block diagram illustrating a configuration of a management device according to the third embodiment. FIG. 25 is an explanatory diagram illustrating an example of transaction data according to the third embodiment. FIG. 26 is an explanatory diagram illustrating transaction data stored in the block chain according to the third embodiment. FIG. 27 is an explanatory diagram illustrating information managed by the state management unit according to the third embodiment. FIG. 28 is a sequence diagram illustrating processing in the management system according to the third embodiment. FIG. 29 is an explanatory diagram showing the data structure of the block chain. FIG. 30 is an explanatory diagram showing the data structure of the transaction data.

(Knowledge underlying the present invention)
The present inventor has found that the following problems occur with respect to software development described in the section of “Background Art”.

  When developing software, agile development is used, in which an unspecified number of developers as well as development manufacturers participate. In this form, a variety of version sequences can occur as many developers improve the software.

  In a management system that manages software, version information indicating a version of software developed by the developer is managed together with identification information of the developer (for example, see Patent Document 1).

  Here, the version information has a role of uniquely specifying the version of the software. Also, the developer identification information can be used to provide a reward to the developer for developing a new version of the software.

  However, the conventional management system has a problem that it is difficult to prevent the version information of the program managed by the management server or the falsification of the developer identification information.

  Thus, the present invention provides a management method and the like for suppressing the occurrence of falsification of managed information.

  A management method according to an aspect of the present invention is a software version management method executed by a version management system, wherein the version management system includes a plurality of management devices holding a distributed ledger, The management method includes: a first management device among the plurality of management devices, a first information regarding a first version of the software, and a second information of the software upgraded by a developer based on the first version. Receiving transaction data including version information, the developer identification information, and an electronic signature from a device connected to the first management device via a network; Corrects the transaction data using the electronic signature included in the received transaction data. Verify the sex, when the transaction data is valid, each of the plurality of management apparatus storing the transaction data in the distributed ledger.

  According to the above aspect, information on the developer whose software has been upgraded is managed by the distributed ledger. The distributed ledger has the advantage that it is difficult to falsify the information it holds and that it is less susceptible to system downtime. Therefore, the management method can suppress the occurrence of falsification of the managed information.

  For example, the second information includes a version number of the second version, and further, the management method further includes, before receiving the transaction data, receiving an issuance request for a version number of the second version from the device. In the case, a new version number is transmitted to the device as a version number of the second version, and when the transaction data is received, the new version number transmitted to the device is included as the second information. Transaction data may be received.

  According to the above aspect, the version number of the new version is issued, and the information on the developer of the new version is managed in association with the issued version number. If the version number is assigned by a device different from the version management system, defects such as duplication of the version number may occur. ADVANTAGE OF THE INVENTION According to the management method concerning this invention, it can suppress generation | occurrence | production of the falsification of managed information, avoiding the defect of a version number beforehand.

  For example, the first information may include a version number of the first version of the software, and the second information may include a hash value of the second version of the software and a version number of the second version. Good.

  According to the above aspect, by using the version number of the first version, the hash value of the second version, and the version number of the second version, it is possible to more easily suppress the occurrence of falsification of the managed information. Can be.

  For example, the first information may include a hash value of the first version of the software, and the second information may include a hash value of the second version of the software.

  According to the above aspect, using the hash value of the first version and the hash value of the second version can more easily suppress the occurrence of falsification of the managed information.

  For example, the first information may include a hash value of the first version of the software, and the second information may include a hash value of a difference between the first version and the second version of the software.

  According to the above aspect, by using the hash value of the first version and the hash value of the difference between the first version and the second version, it is possible to more easily suppress the occurrence of falsification of the managed information. it can.

  For example, the apparatus has location information indicating a location where the second version of the software is stored, and the management method includes the location information when receiving the transaction data. Transaction data may be received.

  According to the above aspect, the information indicating the storage location of the second version of the software is stored in the distributed ledger together with the information on the developer. Therefore, it is possible to suppress the occurrence of falsification of the managed information while suppressing the falsification of the location information in which the second version is stored.

  For example, the management method, when branching the second version series from the first version series of the software, at least one version including at least the last version of the first version series, the second version A new distributed ledger having one or more versions of a series may be generated, and the plurality of management apparatuses may hold the new distributed ledger.

  According to the above aspect, the distribution ledger corresponding to each of the plurality of version series is managed, and when the version series branches, the distribution ledger corresponding to the new series is generated. If a large number of version upgrades are performed in one series, when acquiring information such as a history of version upgrades, information corresponding to each of the multiple version upgrades is obtained, and there is a possibility that the processing load increases. In such a case, by branching the version series and managing the new version series with a new distributed ledger, it is possible to reduce information such as the history of version upgrades and prevent the above processing load from increasing. .

  For example, when receiving the transaction data, it specifies whether the transaction data is the transaction data according to the first version series or the second version series, the received transaction data, the first It may be stored in a distributed ledger corresponding to the version series corresponding to the specified transaction data among the version series and the second version series.

  According to the above aspect, when a plurality of version series are managed by a plurality of distributed ledgers, it is possible to specify which version series the transaction data belongs to, and manage the transaction data by an appropriate distributed ledger. .

  For example, the management method further includes, when abolishing one version series, generating transaction data indicating that the one version series is abolished, and generating the generated transaction data corresponding to the one version series. May be stored in the distribution ledger.

  According to the above aspect, the version series can be appropriately abolished by the predetermined transaction data. Therefore, it is possible to more easily suppress the falsification of the managed information while further eliminating the version series.

  For example, the management method may further provide a token to the developer with reference to the transaction data stored in the distributed ledger.

  According to the above aspect, a token is provided to a new version of the developer based on the transaction data so far. Since it is difficult to falsify the transaction data stored in the distributed ledger, it is possible to avoid providing a token to an inappropriate person impersonating a developer. In this way, it is possible to suppress the occurrence of falsification of the managed information and to avoid providing inappropriate tokens.

  For example, the distributed ledger is a block chain, and when the transaction data is valid, each of the plurality of management devices may store the transaction data in the block chain.

  According to the above aspect, the use of the blockchain as the distributed ledger by the plurality of management apparatuses can more easily suppress the falsification of the information being managed.

  The management device according to an aspect of the present invention is a first management device among a plurality of management devices holding a distributed ledger, provided in a version management system for managing software versions, wherein the software Transaction including first information about a first version of the software, second information about a second version of the software upgraded by a developer based on the first version, identification information of the developer, and an electronic signature A data verifying unit that receives data from a device connected to the first management device via a network, and verifies the validity of the transaction data using the electronic signature included in the received transaction data; and , If the transaction data is valid, the transaction And a ledger managing unit for storing in said dispersion ledger the Yondeta.

  Thereby, an effect similar to that of the above-described management method can be obtained.

  A management device according to one embodiment of the present invention operates a computer as a first management device among a plurality of management devices having a distributed ledger, which is included in a version management system for managing software versions. A first information about a first version of the software, a second information about a second version of the software upgraded by a developer based on the first version, and an identification of the developer. Information, transaction data including an electronic signature is received from a device connected to the first management device via a network, and the transaction data is received using the electronic signature included in the received transaction data. Verify the validity and the transaction data is valid The case, storing said transaction data in said dispersion ledger.

  Thereby, an effect similar to that of the above-described management method can be obtained.

  Note that these comprehensive or specific aspects may be realized by a recording medium such as a system, a method, an integrated circuit, a computer program or a computer-readable CD-ROM, and the system, the method, the integrated circuit, and the computer program. Alternatively, it may be realized by an arbitrary combination of recording media.

  Hereinafter, embodiments will be specifically described with reference to the drawings.

  Each of the embodiments described below shows a comprehensive or specific example. Numerical values, shapes, materials, constituent elements, arrangement positions and connection forms of constituent elements, steps, order of steps, and the like shown in the following embodiments are merely examples, and do not limit the present invention. Further, among the components in the following embodiments, components not described in the independent claims indicating the highest concept are described as arbitrary components.

(Embodiment 1)
In the present embodiment, a software version management method, such as a management method for suppressing the occurrence of falsification of managed information, will be described. Here, the software is, for example, software that is mounted on a home appliance (a washing machine, an air conditioner, a refrigerator, a television, or the like), controls the operation of the home appliance, and exerts the function of the home appliance.

  FIG. 1 is an explanatory diagram showing a software version series based on agile development.

  As shown in FIG. 1, in agile development, company Z, a development maker, develops the first version, version 1 (referred to as “Ver1” in the figure, the same applies hereinafter) and provides it to the community of developers. . Next, based on the provided version 1 software, development is performed by developers belonging to the community, and various version series are generated. In each version series, for example, software having different functions is developed. The version series is represented as a series 1A in FIG. The version series includes one or more versions.

  In FIG. 1, based on the software of version 1, version 1. A1 is generated, and version 1. B1 is generated, and version 1. It is shown that C1 has been generated.

  And further developments can be made based on these versions. For example, version 1. Based on A1, version 1. A2 was developed and version 1. Version 1. based on A2 A3 is developed. Version 1. Version 1 based on B1 B2 is developed. Version 1. Based on C1, the developers D and E make version 1. C1. D1 and version 1. C1. E1 is developed.

  Here, version 1. Versions after A1 (that is, version 1.A1, and versions 1.A2 and 1.A3 that are versions developed based on version 1.A1) are referred to as a series 1A. Similarly, version 1. Versions after B1 are called series 1B. Version 1. C1 is referred to as series 1C, and version 1. C1. D1 is called series 1D, and version 1. C1. E1 is called sequence 1E. A series including version 1 and all versions of series 1A to 1E is also referred to as series 1.

  As described above, in the agile development, software is developed by a developer different from the development maker based on software provided by the development maker Z, and a plurality of version series are generated.

  Then, the version desired by the user among the plurality of versions is provided to the user. For example, the latest version of a version series having a function desired by the user is provided to the user.

  FIG. 2 is an explanatory diagram showing the exchange of tokens in agile development. Here, the token is a concept corresponding to profit or value, and is owned or transferred by a person (natural person) or a legal entity such as a maker. In agile development, software development proceeds by appropriately exchanging tokens among developers, general users, and manufacturers.

  For example, a general user receives software provided by a developer, and the user operates the home appliance by operating the software on the home appliance held by the user. The general user provides the developer with a token in exchange for receiving the software.

  The general user also provides the manufacturer with data of the product when the home appliance equipped with the software is operated, and receives a token as a price for the data.

  Here, the general user and the developer directly exchange tokens without going through a maker. When such a token exchange occurs, the identification information of the managed developer may be falsified for the purpose of gaining fraudulently or damaging the profits of others. This is because if the identification information is falsified, it becomes possible for a Service-to-Self to impersonate a developer and receive a token, or to impersonate another and provide malicious software to deteriorate their reputation.

  The management system according to the present embodiment aims to suppress the occurrence of falsification of managed information.

  FIG. 3 is an explanatory diagram illustrating a configuration of the management system 1 according to the first embodiment.

  As shown in FIG. 3, the management system 1 includes a plurality of management devices 10A, 10B and 10C, a plurality of development devices 20A, 20B and 20C, and a storage server 30. The above devices are communicably connected to each other by a network N.

  The plurality of management devices 10A, 10B, and 10C (also referred to as 10A and the like) are management devices that manage information about software versions by a computer. The case where the number of the plurality of management apparatuses 10A and the like is 3 will be described as an example, but any number may be used as long as the number is 2 or more. The plurality of management apparatuses 10A and the like are communicably connected to each other. Each of the plurality of management devices 10A and the like corresponds to a first management device. In the following, the management device 10A may be used as a representative for the plurality of management devices 10A and the like, but the same description will be applied to other management devices 10B and 10C. Note that the plurality of management devices 10A and the like can also communicate via the network N.

  The plurality of management apparatuses 10A and the like each have a distributed ledger for managing information about software versions, and update the held distributed ledgers while synchronizing with each other by communication. When any of the plurality of management apparatuses 10A and the like acquires information on a new version from any of the development apparatuses 20A and the like, each of the plurality of management apparatuses 10A and the like holds a copy of the acquired information. The distributed ledger generally has the advantage that it is difficult to falsify the information it holds and that it is less susceptible to system downtime.

  The plurality of development devices 20A, 20B, and 20C (also referred to as 20A and the like) are computers used by software developers, and operate independently of each other. The case where the number of the plurality of development devices 20A and the like is 3 will be described as an example, but the number may be one or more. In the following, the development device 20A is used as a representative of the development devices 20A and the like, and the description may be made using the development device 20A. However, the same description holds for the other development devices 20B and 20C.

  The developer uses the development device 20A to develop a new version of software, and transmits the developed new version of software to the storage server 30 for storage. The development device 20A transmits information on a new version developed by the developer to any of the management devices 10A and the like via the network N.

  The storage server 30 is a computer that stores software. The storage server 30 stores one or more versions of software in a storage device.

  The network N is a communication line that connects the development device 20A, such as the management device 10A, and the storage server 30 so that they can communicate with each other. The type of the communication line is not particularly limited, and may be any combination of a wired network and a wireless network. Further, a part of the Internet may be included in the network N.

  Hereinafter, the storage server 30, the development device 20A, and the like, and the management device 10A and the like will be described in more detail.

  FIG. 4 is a block diagram illustrating a configuration of the storage server 30 according to the present embodiment.

  As shown in FIG. 4, the storage server 30 includes a communication unit 31, a storage unit 32, an issuing unit 33, and a storage device. Each function of the storage server 30 can be realized by a processor executing a predetermined program using a memory.

  The communication unit 31 is a communication interface device connected to the network N. The storage server 30 can communicate with the development device 20A via the communication unit 31.

  The storage unit 32 is a processing unit that stores software using the storage device 34. When acquiring a new version of software from the development device 20A via the communication unit 31, the storage unit 32 stores the acquired software in the storage device. Further, it reads out the software stored in the storage device 34 in response to a request from the user.

  The issuing unit 33 is a processing unit that issues location information indicating a location where software is stored. When the storage unit 32 stores the software in the storage device 34, the issuing unit 33 acquires the information indicating the location where the software is stored, and generates the location information indicating the location, thereby obtaining the location information. Issue The issuing unit 33 notifies the development device 20A of the generated location information.

  The location information is, for example, a URL (Uniform Resource Locator) indicating the location on the Internet of the electronic file related to the software in the storage device 34. Hereinafter, this case will be described as an example. The URL includes, for example, information on a path (Path) and a file name indicating the location in the storage device 34, and the host name of the storage server 30.

  The storage device 34 is a storage device in which software is stored. The storage device 34 stores one or more versions of software. In the storage device 34, the software is stored by the storage unit 32, and the software is read by the storage unit 32.

  FIG. 5 is a block diagram illustrating a configuration of the development device 20A according to the present embodiment. The development devices 20B and 20C also have the same configuration and operate independently.

  As illustrated in FIG. 5, the development device 20A includes a communication unit 21, a development unit 22, a transaction generation unit 23, and a storage device 24. Each function of the development device 20A can be realized by a processor executing a predetermined program using a memory.

  The communication unit 21 is a communication interface device connected to the network N. The development device 20A can communicate with the storage server 30 and the management device 10A via the communication unit 21.

  The development unit 22 is a processing unit that generates a new version of software developed by a developer based on an operation by a user or a function of a tool for software development. Specifically, the development unit 22 has software (or a program or a program code) of a version (corresponding to the first version) from which the software is developed, and newly develops the software based on the held software. A new version (corresponding to the second version) of software. In this way, the developer develops a new version of software using the development device 20A (specifically, the development unit 22). Developing a new version is also called version upgrade. The development unit 22 transmits the new version of the developed software to the storage server 30 via the communication unit 21 to store the software. At this time, the development unit 22 is notified of the URL indicating the storage location of the software stored in the storage server 30 from the storage server 30 (specifically, the issuing unit 33).

  The transaction generation unit 23 is a processing unit that generates transaction data including information on the software version. The transaction data includes information on the first version of the software (corresponding to the first information), information on the second version upgraded by the developer based on the first version (corresponding to the second information), It includes at least a developer ID that is identification information and a digital signature of the developer. The developer's electronic signature is generated from information included in the transaction data by encryption with the developer's private key. The developer identification information and the secret key can be obtained by reading from the storage device 24 by the transaction generation unit 23. Further, the transaction generation unit 23 transmits the generated transaction data to the management device 10A via the communication unit 21.

  Further, the transaction generation unit 23 generates a request for issuing a new version number, transmits the request to the management apparatus 10A, and receives a notification of the new version number as a response.

  The storage device 24 is a storage device that stores information about developers and information about software. The information on the developer includes a developer ID, which is identification information of the developer, and key information (including a secret key) of the developer. The developer ID is information that can uniquely identify a developer. The information about the software includes the URL of the software itself and the storage location of the software in the storage server 30. Here, the software main body is a software program, and is simply described as “software” in FIG. The software main body stored in the storage device 24 is read by the development unit 22. The developer ID, the key information, and the URL stored in the storage device 24 are read by the transaction generation unit 23.

  FIG. 6 is a block diagram showing a configuration of the management device 10A according to the present embodiment.

  As shown in FIG. 6, the management device 10A includes a communication unit 11, a number management unit 12, a transaction verification unit 13, a ledger management unit 14, and a token management unit 16. Each function of the management device 10A can be realized by a processor executing a predetermined program using a memory.

  The communication unit 11 is a communication interface device connected to the network N. The management device 10A can communicate with the development device 20A and the other management devices 10B and 10C via the communication unit 11.

  The number management unit 12 is a processing unit that manages version numbers of software versions. Upon receiving a request to issue a new version number of software from the development device 20A, the number management unit 12 issues a new version number in response to the issuance request and notifies the development device 20A. The number management unit 12 issues a version number that is higher than the version number of the latest version among the currently held versions. When there are a plurality of series in a version, the number management unit 12 receives a request to issue a new version number for each series, and issues a version number for each series.

  Here, the version number is set according to a predetermined rule. For example, using a numerical value, it is set to have a larger numerical value as the version advances (that is, as the version is upgraded). At this time, characters may be used together with the numerical values. Here, an example is shown in which the version series is indicated by characters. That is, the version included in the series 1A developed based on the first version, version 1, is referred to as version 1. A1, version 1. A2 and version 1. A3 etc. Also, based on version 1, the version included in the series 1B developed separately from the series 1A is called version 1. B1 and version 1. B2 etc.

  The transaction verification unit 13 is a processing unit that verifies the validity of transaction data. The transaction verification unit 13 receives transaction data from the development device 20A via the communication unit 11. The received transaction data includes first information about the first version of the software, second information about the second version of the software upgraded by the developer based on the first version, identification information of the developer, Electronic signature. When receiving the transaction data, the transaction verification unit 13 verifies the validity of the transaction data using the electronic signature included in the received transaction data. Verification of the validity of the transaction data is performed using information included in the transaction data and the developer's public key, and it is determined whether the transaction data is valid. More specifically, it is determined that the transaction data is indeed generated by the development device 20A, and that the transaction data has not been falsified since it was generated. Verification of the validity of transaction data is also simply referred to as verification of transaction data.

  Note that the transaction data received by the transaction verification unit 13 may include the new version number notified by the number management unit 12.

  Further, the transaction data received by the transaction verification unit 13 may further include a URL that is location information of a new version of software.

  The ledger management unit 14 is a processing unit that manages a distributed ledger for managing software versions. Here, the case where the distribution ledger is the blockchain 15 will be described as an example, but it is also possible to adopt another type of distribution ledger (for example, IOTA or hash graph).

  When the transaction verification section 13 verifies the transaction data, the ledger management section 14 synchronizes the transaction data by transmitting the transaction data to the other management apparatuses 10B and 10C. Then, the ledger management unit 14 executes a consensus algorithm between the management device 10A and the other management devices 10B and 10C. When consensus is reached in the consensus algorithm, a block including the transaction data is generated, and the generated block is stored in the block chain 15.

  An example of the consensus algorithm is PBFT (Practical Byzantine Fault Tolerance), but the present invention is not limited to this, and PoW (Proof of Work) or PoS (Proof of Stake) may be used.

  The token management unit 16 is a processing unit that manages tokens held by each of the user and the developer. The token management unit 16 provides the token to the developer with reference to the transaction data stored in the block chain 15. Note that the token management unit 16 may use a block chain for token management.

  Next, three examples of the configuration of transaction data for causing the management device 10A or the like to manage a new version of software will be described.

  FIG. 7 is an explanatory diagram showing transaction data 40 which is a first example of transaction data according to the present embodiment. In the transaction data 40, the first information on the first version of the software includes the version number of the first version, and the second information on the second version of the software includes the hash value of the second version of the software and the hash value of the second version. This is an example in the case of including a version number.

  As shown in FIG. 7, the transaction data 40 includes a developer ID 41, a URL 42, a new version number 43, a base version number 44, a hash value 45 of the new version, and a signature 46.

  The developer ID 41 is identification information of a developer who has developed a new version to be newly managed by the transaction data 40.

  The URL 42 is a URL indicating a location where a new version to be newly managed by the transaction data 40 is stored. The URL 42 indicates a location where a new version of software is stored in the storage device 34 of the storage server 30.

  The new version number 43 is a version number of a new version to be newly managed by the transaction data 40.

  The base version number 44 is a version number of a version (also referred to as a base version) from which a new version to be newly managed by the transaction data 40 is developed.

  The new version hash value 45 is a hash value obtained by performing a hash operation on all or a predetermined part of the new version program to be newly managed by the transaction data 40.

  The signature 46 is an electronic signature generated by encrypting the information included in the transaction data 40 with the developer's private key. Specifically, a hash value obtained by performing a hash operation on information including the developer ID 41, the URL 42, the new version number 43, the base version number 44, and the hash value 45 of the new version is encrypted using the developer's secret key. Value.

  FIG. 8 is an explanatory diagram showing transaction data 50 which is a second example of transaction data according to the present embodiment. The transaction data 50 is obtained when the first information on the first version of the software includes a hash value of the first version of the software, and the second information on the second version of the software includes the hash value of the second version of the software. It is an example.

  As shown in FIG. 8, the transaction data 50 includes a developer ID 51, a URL 52, a new version hash value 53, a base version hash value 54, and a signature 55.

  The developer ID 51 and the URL 52 are the same as the information of the same name in the transaction data 40.

  The new version hash value 53 is a hash value obtained by performing a hash operation on all or a predetermined part of the new version software program to be newly managed by the transaction data 50.

  The base version hash value 54 is a hash value obtained by performing a hash operation on all or a predetermined part of the base version software program from which the new version is developed based on the transaction data 50. It is.

  The signature 55 is an electronic signature generated from the information included in the transaction data 50 by encryption with the developer's private key. Specifically, a value obtained by encrypting a hash value obtained by performing a hash operation on information including the developer ID 51, the URL 52, the hash value 53 of the new version, and the hash value 54 of the base version with the developer's secret key It is.

  FIG. 9 is an explanatory diagram showing transaction data 60 which is a third example of transaction data according to the present embodiment. In the transaction data 60, the first information on the first version of the software includes a hash value of the first version of the software, and the second information on the second version of the software indicates a difference between the first version and the second version of the software. It is an example in the case of including the hash value of.

  As shown in FIG. 9, the transaction data 60 includes a developer ID 61, a URL 62, a hash value 63 of the difference, a hash value 64 of the base version, and a signature 65.

  The developer ID 61 and the URL 62 are the same as the information of the same name in the transaction data 40.

  The difference hash value 63 is a hash value of the difference between the new version of the program to be newly managed by the transaction data 60 and the base version of the program from which the new version was developed.

  The base version hash value 64 is a hash value obtained by performing a hash operation on all or a predetermined part of a new version of a software program to be newly managed by the transaction data 60.

  The signature 65 is an electronic signature generated by encrypting the information included in the transaction data 60 with the developer's private key. Specifically, a hash value obtained by performing a hash operation on information including the developer ID 61, the URL 62, the hash value 63 of the difference, and the hash value 64 of the base version is a value encrypted with the developer's secret key. is there.

  Hereinafter, the transaction data stored in the block chain 15 will be described.

  FIG. 10 is an explanatory diagram showing an example of transaction data stored in the block chain 15 according to the present embodiment. FIG. 10 specifically shows transaction data managed by the management device 10A and the like by the blockchain 15. One entry (one row) shown in FIG. 10 corresponds to one transaction data. In FIG. 10, the lower data on the paper is newer transaction data.

  As shown in FIG. 10, each transaction data includes a URL, a new version number, a base version number, and a developer ID for each version of the software. Note that the transaction data shown in FIG. 10 corresponds to each information included in the transaction data 40 shown in FIG.

  As shown in FIG. 10, the block chain 15 stores information about each version of the software before the current time. Specifically, from version 1 to version 1. A1,1. A2 and 1. A3 was developed and version 1 to version 1. B1 and 1. Information indicating that B2 has been developed is stored.

  The information about each version of the software before the current time is managed by the management device 10A so as not to be falsified due to the characteristic of the blockchain that it is difficult to falsify.

  Hereinafter, processing of the management system 1 will be described.

  FIGS. 11 and 12 are sequence diagrams showing first and second processes in the management system 1 according to the present embodiment. FIGS. 11 and 12 show a series of processes from the development of a new version of software by the development device 20A to the management of the developed software version by the management device 10A or the like.

  As shown in FIG. 11, in step S121, a new version of software is completed by the development device 20A.

  In step S122, the development device 20A transmits the new version of the software developed in step S121 to the storage server 30 so as to be stored in the storage server 30.

  In step S131, the storage server 30 receives the new version of the software transmitted from the development device 20A and stores it in the storage device.

  In step S132, the storage server 30 issues a URL indicating the location of the new version of the software stored in step S131. Then, the storage server 30 transmits the issued URL to the development device 20A. The URL may be sent as a response to the software received in step S122.

  In step S123, the development device 20A generates an issuance request for a new version number (also referred to as a new number) and transmits it to the management device 10A. Here, the issuance request is communication data for requesting the management apparatus 10A to issue a new number assigned to a new version of software, that is, a new version number, and includes at least a base version number.

  In step S111, the management device 10A receives the issuance request transmitted in step S123, and determines whether or not the base version included in the issuance request is stored in the block chain 15 managed by the management device 10A. Is determined. If it is determined that the base version is stored in the block chain 15 (Yes in step S111), the process proceeds to step S112.

  If it is determined that the base version is not stored in the blockchain 15 (not shown), the management device 10A transmits a predetermined error process (for example, a notification indicating that the issuance has failed to the development device 20A). Is performed, and the process ends. However, in this case, the management device 10A may end the processing without performing any processing. In this way, it is determined that the base version is not stored in the blockchain 15 when, for example, the management device 10A or the like attempts to manage a version of software that is not managed by the management device 10A or the like. .

  In step S112, the management device 10A issues a version number of the new version.

  Referring to FIG. 12, in step S113, the management device 10A notifies the development device 20A of the version number of the new version issued in step S112. The notification of the version number of the new version can be transmitted as a response to the issuance request in step S123.

  In step S124, transaction data for writing the new version to the block chain 15 is generated and transmitted to the management device 10A. The transaction data includes the new version number transmitted in step S113, or information calculated using the new version number.

  In step S114, the management device 10A verifies the transaction data transmitted by the development device 20A in step S124. Here, it is assumed that the transaction data is determined to be valid as a result of the verification of the transaction data.

  In step S115, the management device 10A transmits the transaction data to the management devices 10B and 10C. Then, the block including the transaction data is stored in the block chain 15 by executing the consensus algorithm by the management device 10A or the like. As a result, information on the new version of the software developed by the developer, more specifically, the developer ID and the version number are stored in the blockchain 15, and it becomes difficult to falsify the information after the storage.

  If the verification of the transaction data has failed in step S114, that is, if it is verified that the transaction data is not valid, the fact may be notified to the development device 20A. In this way, the developer can recognize this and take action. On the other hand, the notification need not be made.

  The software itself may be stored and managed in the blockchain 15 by the management device 10A. This makes it possible to manage the software while suppressing not only the information on the version but also the falsification of the software itself, which is more useful. To do so, the development device 20A generates transaction data including the software itself (that is, the program code of the software) and transmits it to the management device 10A, and the management device 10A transmits the received transaction data to the blockchain 15A. Should be stored in

  Note that the development device 20A is an example of a device connected to the management device 10A via a network, and this case has been described as an example, but the above device is not limited to the development device 20A. For example, a device used by a person commissioned by a developer may also correspond to a device connected to the management device 10A via a network. In this case, the above description is established by replacing “developer” in the above description with “person entrusted by the developer”.

  As described above, according to the management method of the present embodiment, information on a developer whose software has been upgraded is managed by the distributed ledger. The distributed ledger has the advantage that it is difficult to falsify the information it holds and that it is less susceptible to system downtime. Therefore, the management method can suppress the occurrence of falsification of the managed information.

  Further, a version number of the new version is issued, and information on the developer of the new version is managed in association with the issued version number. If the version number is assigned by a device different from the version management system, defects such as duplication of the version number may occur. ADVANTAGE OF THE INVENTION According to the management method concerning this invention, it can suppress generation | occurrence | production of the falsification of managed information, avoiding the defect of a version number beforehand.

  Further, using the version number of the first version, the hash value of the second version, and the version number of the second version, it is possible to more easily suppress the falsification of the managed information.

  In addition, the use of the first version hash value and the second version hash value makes it possible to more easily suppress the falsification of the managed information.

  Further, using the hash value of the first version and the hash value of the difference between the first version and the second version, it is possible to more easily suppress the occurrence of falsification of the managed information.

  Information indicating the storage location of the second version of the software is stored in the distributed ledger along with information on the developer. Therefore, it is possible to suppress the occurrence of falsification of the managed information while suppressing the falsification of the location information in which the second version is stored.

  Also, tokens will be provided to newer versions of developers based on previous transaction data. Since it is difficult to falsify the transaction data stored in the distributed ledger, it is possible to avoid providing a token to an inappropriate person impersonating a developer. In this way, it is possible to suppress the occurrence of falsification of the managed information and to avoid providing inappropriate tokens.

  Further, by using a blockchain as a distributed ledger by a plurality of management apparatuses, it is possible to more easily suppress the occurrence of falsification of managed information.

(Embodiment 2)
In the present embodiment, a software version management method, such as a management method for suppressing the occurrence of falsification of managed information, will be described. In particular, a description will be given of a technology for managing a version by a different blockchain before and after the major version upgrade of software.

  Here, the major version upgrade is generally a version upgrade in which a relatively large function modification or addition is made to the base version. On the other hand, the version upgrade from the first version to the second version described in the first embodiment is a version upgrade in which a relatively small function correction or addition is made, and is generally called a minor version upgrade. The major version upgrade is performed based on, for example, a decision by Company Z.

  FIG. 13 is an explanatory diagram showing branching of a version sequence according to the present embodiment.

  Version 1 shown in FIG. 13 (described as “Ver1” in FIG. 13) and the like correspond to the software version according to the first embodiment. Here, a community of developers who have been developing the software is referred to as a “version 1 community”.

  In software development, when a major version is upgraded, a copy of part or all of the series 1 developed by the community of version 1 is used as a new version series, series 2. At this time, what is used as the series 2 is a series of a version including at least the latest version of the series 1 of the version developed in the community of version 1, and the series of the version developed in the community of version 1 is used. May be a version series that includes all versions of.

  Generating a new sequence 2 from part or all of the sequence 1 in this manner is referred to as “branching the sequence”. In other words, branching refers to generating a new sequence 2 from a part or all of the sequence 1.

  Then, based on the version that is the first version of the series 2 (“Ver2” in FIG. 13), development is performed by developers belonging to the community of version 2, and various version series are generated. In FIG. 13, based on the software of version 2, version 2. F1 is generated, and version 2. It is shown that G1 has been generated. Version 2. Version 2. based on F1 F2 is developed.

  FIG. 14 is an explanatory diagram illustrating the configuration of the management system 2 according to the present embodiment.

  As illustrated in FIG. 14, the management system 2 includes a plurality of management devices 10D, 10E, and 10F, a plurality of development devices 20A and the like, a storage server 30, and a control device 70. The plurality of development devices 20A and the like and the storage server 30 are the same as the components having the same names in the first embodiment, and therefore, the description is omitted.

  The control device 70 is a control device that controls the management device 10D and the like to branch the version sequence. Specifically, control device 70 transmits, as the above control, communication data including a branch instruction that is an instruction to cause a version sequence to branch. This communication data can be transmitted based on an operation of the control device 70 by a user or the like.

  The plurality of management devices 10D, 10E, and 10F (also referred to as 10D and the like) are management devices that manage version information by computer, similarly to the plurality of management devices 10A and the like in the first embodiment. The management device 10D and the like have functions equivalent to those of the management device 10A and the like, and further have a function of creating a version sequence branch based on a branch instruction transmitted from the control device 70.

  FIG. 15 is a block diagram illustrating a configuration of a control device 70 according to the present embodiment.

  As shown in FIG. 15, the control device 70 includes a communication unit 71 and a branch instruction unit 72.

  The communication unit 71 is a communication interface device connected to the network N. The control device 70 can communicate with the management device 10D via the communication unit 71. Each function of the control device 70 can be realized by the processor executing a predetermined program using the memory.

  The branch instruction unit 72 is a processing unit that transmits an instruction (branch instruction) to cause the management device 10D to branch via the communication unit 71. The branch instruction includes at least information for specifying a version sequence serving as a branch source.

  FIG. 16 is a block diagram illustrating a configuration of a management device 10D according to the present embodiment.

  As shown in FIG. 16, the management device 10D includes a communication unit 11, a number management unit 12, a transaction verification unit 13, and a ledger management unit 14A. Each function of the management device 10D can be realized by a processor executing a predetermined program using a memory.

  The management device 10D is different from the management device 10A of the first embodiment in that it has a ledger management unit 14A. Hereinafter, the ledger management unit 14A will be mainly described.

  The ledger management unit 14A has a branching unit 17. Further, in addition to the block chain 15, a block chain 15A can be held.

  The branching unit 17 is a processing unit that branches a software version series to create a new series. The branching unit 17 receives communication data including a branch instruction transmitted by the control device 70 via the communication unit 11 and, when receiving the communication data, creates a software version sequence branch. At this time, the branching unit 17 generates a block chain 15A corresponding to a new version series having a copy of at least one version including at least the latest version of the block chains 15 corresponding to the version series that has been upgraded. By generating, the version sequence is branched.

  After branching the version series, when receiving the transaction data, the transaction verification unit 13 specifies whether the transaction data is transaction data relating to the first version series or the second version series, and receives the received transaction data. Data is stored in a distributed ledger corresponding to the version series corresponding to the specified transaction data of the first version series and the second version series.

  Next, the block chains 15 and 15A managed by the ledger management unit 14A according to the present embodiment will be described.

  FIGS. 17 and 18 are explanatory diagrams showing transaction data stored in the block chains 15 and 15A according to the present embodiment. Specifically, the transaction data shown in FIG. 17 is the transaction data stored in the block chain 15 corresponding to the series 1 that is the version series including the version 1. The transaction data shown in FIG. 18 is transaction data stored in the block chain 15A corresponding to the series 2 which is a version series including version 2.

  As shown in FIG. 17, each transaction data included in the block chain 15 corresponding to the series 1 includes the URL, the new version number, and the base version of each version of the software, similarly to the block chain 15 shown in FIG. Number and developer ID. Specifically, the blockchain 15 has the version 1. A1,1. A2 and 1. Each of the above information about B1 and the like is included.

  Also, as shown in FIG. 18, each transaction data included in the block chain 15A corresponding to the series 2 includes a URL for each version of the software, a new version number, as in the block chain 15 shown in FIG. It contains the base version number and the developer ID. Specifically, the blockchain 15A has version 2. D1, 2,. D2 and 2. Each of the above information about E1 and the like is included.

  Hereinafter, the processing of the management system 2 will be described.

  FIG. 19 is a sequence diagram illustrating processing in the management system 2 according to the present embodiment.

  As shown in FIG. 19, when it is determined in step S271 that the version sequence is branched by the company Z, the control device 70 generates communication data including a branch instruction and transmits the communication data to the management device 10D.

  In step S211, when receiving the branch instruction transmitted in step S271, the management device 10D generates transaction data for generating a block chain (corresponding to the block chain 15A in FIG. 16) corresponding to the new version sequence. .

  In step S212, the management device 10D transmits the transaction data generated in step S211 to the management devices 10E and 10F. Then, the block including the transaction data is stored in the block chain by executing the consensus algorithm by the management device 10D or the like. As a result, information on the new version of the software corresponding to the new version series, more specifically, the developer ID and the version number are stored in the blockchain, and it becomes difficult to falsify after the storage.

  Next, management of a new version when a block chain corresponding to each of a plurality of version series is managed by the management device 10D or the like will be described.

  FIG. 20 is an explanatory diagram showing transaction data 40A which is an example of the transaction data according to the present embodiment.

  The transaction data 40A is obtained by further adding a sequence number 43A to the transaction data 40 shown in FIG.

  The series number 43A is information indicating a series of a new version to be newly managed by the transaction data 40A.

  The signature 46 is an electronic signature generated by encrypting the information included in the transaction data 40A with the developer's private key. The information on which the signature 46 is generated includes the sequence number 43A in addition to the information on which the signature 46 is generated in FIG.

  When there are a plurality of sequences, the development device 20A includes the sequence number 43A indicating the sequence to which the new version of the software belongs, in the transaction data 40A, and transmits the transaction data 40A to the management device 10D. When receiving the transaction data 40A, the management device 10D acquires the sequence number included in the received transaction data 40A, and stores the transaction data 40A in a block chain corresponding to the sequence number.

  FIG. 21 is a flowchart showing processing related to the version sequence included in the consensus algorithm according to the present embodiment. The process illustrated in FIG. 21 is a process included in the consensus algorithm of step S115 in FIG.

  In step S141, the management device 10D acquires the sequence number included in the received transaction data 40A.

  In step S142, the management device 10D specifies a block chain corresponding to the sequence number acquired in step S141 from among a plurality of block chains managed by the ledger management unit 14A.

  In step S143, the management device 10D executes a consensus algorithm with the management devices 10E and 10F for the block chain specified in step S142. As a result, the received transaction data 40A is stored in the block chain specified in step S142.

  In this way, the transaction data is stored in the block chain corresponding to the sequence number specified by the development device 20A.

  As described above, according to the management method of the present embodiment, a distributed ledger corresponding to each of a plurality of version series is managed, and when a version series is branched, a distributed ledger corresponding to a new series is generated. . If a large number of version upgrades are performed in one series, when acquiring information such as a history of version upgrades, information corresponding to each of the multiple version upgrades is obtained, and there is a possibility that the processing load increases. In such a case, by branching the version series and managing the new version series with a new distributed ledger, it is possible to reduce information such as the history of version upgrades and prevent the above processing load from increasing. .

  Further, when a plurality of version series are managed by a plurality of distribution ledgers, it is possible to specify which version series the transaction data belongs to, and manage the transaction data by an appropriate distribution ledger.

(Embodiment 3)
In the present embodiment, a software version management method, such as a management method for suppressing the occurrence of falsification of managed information, will be described. In particular, a technology for managing versions so as to stop using the version series of software will be described. Stopping the use of a version series is also called abolishing the version series.

  FIG. 22 is an explanatory diagram showing the abolition of the version series according to the present embodiment.

  Ver1 and Ver2 shown in FIG. 22 correspond to software versions according to the second embodiment.

  In software development, use of a relatively old version series is stopped, that is, abolished, because a relatively new version series is generated. The abolished version series is controlled so that version upgrade after the abolition point is prohibited. Further, after the point of discontinuation, further control may be performed so that the provision of the software of each version included in the discontinued series to the user is prohibited.

  Specifically, as shown in FIG. The latest version of the A version series A3 and version 1. The latest version of the B version series It is assumed that the sequence 1 is abolished when B2 exists. Then, for example, version 1. The next version that can be included in the version series of A1. A4 (not shown) or version 1. The next version that can be included in the version series of B1. Registration of B3 (not shown) is prohibited. In addition, since the time of discontinuation, version 1, version 1. A and version 1. Provision of the software of each series B to the user is prohibited.

  The management system 2 according to the present embodiment is similar to the management system 2 according to the second embodiment, and the functions of the control device and the management device are partially different. Specifically, the management system 2 according to the present embodiment includes a control device 70A, and includes management devices 10G, 10H, and 10I (also referred to as 10G or the like). Hereinafter, the control device 70A and the management device 10G according to the present embodiment will be described in detail.

  FIG. 23 is a block diagram showing a configuration of a control device 70A according to the present embodiment.

  As shown in FIG. 23, the control device 70A includes a communication unit 71 and a transaction generation unit 73. Note that the control device 70A may include the branch instruction unit 72, similarly to the control device 70 of the second embodiment.

  Communication unit 71 is the same as communication unit 71 included in control device 70A of the second embodiment.

  The transaction generation unit 73 is a processing unit that generates transaction data indicating that the version series is abolished. The transaction generation unit 73 transmits the generated transaction data to the management device 10G. The transaction data includes at least a sequence number as specific information that can specify a version sequence to be abolished.

  FIG. 24 is a block diagram illustrating a configuration of a management device 10G according to the present embodiment.

  As shown in FIG. 24, the management device 10G includes a communication unit 11, a number management unit 12, a transaction verification unit 13, a ledger management unit 14A, and an abolition unit 18. The management device 10G may include a state management unit 19. Each function of the management device 10G can be realized by a processor executing a predetermined program using a memory.

  The management device 10G is different from the management device 10A according to the first embodiment and the management device 10D according to the second embodiment in that the management device 10G includes an abolition unit 18 and may include a state management unit 19. Hereinafter, the abolition unit 18 and the state management unit 19 will be mainly described.

  The abolition unit 18 is a processing unit that stores a block including information indicating that the version series is abolished in a block chain corresponding to the version series to be abolished. The abolition unit 18 receives the transaction data indicating that the version series is abolished, transmitted by the control device 70A. The abolition unit 18 stores the transaction data in the block chain corresponding to the version sequence specified by the sequence number included in the received transaction data.

  The state management unit 19 is a processing unit that manages information indicating whether each version series is in the operating state or the discontinued state. The state management unit 19 holds information indicating whether each of the version series managed by the management device 10G is in the operating state or the abolished state. Then, when the revoking unit 18 stores the transaction for revoking the version sequence in the blockchain, the state management unit 19 changes the state of the version sequence from the operation status to the revoked status. Note that the state management unit 19 is not an essential component.

  FIG. 25 is an explanatory diagram showing transaction data 80 which is an example of transaction data according to the present embodiment.

  As shown in FIG. 25, transaction data 80 includes sequence number 81, abolition information 82, and signature 83.

  The sequence number 81 is information for specifying a version sequence to be abolished by the transaction data 80.

  The abolition information 82 is information indicating that the transaction data 80 is transaction data indicating abolition.

  The signature 83 is an electronic signature generated by encrypting the information included in the transaction data 80 with the secret key of the control device 70A. Specifically, it is a value obtained by encrypting a hash value obtained by performing a hash operation on information including the sequence number 81 and the revocation information 82 with a secret key of the control device 70A.

  FIG. 26 is an explanatory diagram showing transaction data stored in the block chain according to the present embodiment. Specifically, the transaction data shown in FIG. 26 is the block chain 15 corresponding to the version series of version 1.

  As shown in FIG. 26, each transaction data included in the block chain 15 corresponding to the version series of version 1 includes the URL and the new version number of each version of the software, similarly to the block chain 15 shown in FIG. , Base version number and developer ID. Specifically, the blockchain 15 has the version 1. A1,1. A2 and 1. Each of the above information about B1 and the like is included.

  Then, the transaction data 91 included in the block chain 15 is the transaction data for bringing the version series 1A into the abolished state. Further, the transaction data 92 included in the block chain 15 is the transaction data for putting the version series 1B into the abolished state.

  FIG. 27 is an explanatory diagram of a state table T1 indicating state information managed by the state management unit 19 according to the present embodiment.

  As shown in FIG. 27, the state table T1 has information indicating the states of the version series 1A and 1B. FIG. 27 shows that version series 1A is in an abolished state and version series 1B is in an operating state. This corresponds to a case where the ledger management unit 14A has a block chain corresponding to each of the series of version 1 and version 2, the series of version 1 is abolished, and the series of version 2 is in operation. .

  Hereinafter, the processing of the management system 2 will be described.

  FIG. 28 is a sequence diagram illustrating processing in the management system 2 according to the present embodiment.

  As shown in FIG. 28, in step S371, the control device 70A generates transaction data for abolishing the version sequence, and transmits the transaction data to the management device 10G.

  In step S311, upon receiving the transaction data transmitted in step S371, the management device 10G verifies the received transaction data. The verification of the transaction data is performed based on the information included in the transaction data and the public key of the control device 70A. Here, it is assumed that the transaction data is determined to be valid as a result of the verification of the transaction data.

  In step S312, the management device 10G transmits the transaction data generated in step S312 to the management devices 10H and 10I. Then, the block including the transaction data is stored in the block chain by executing the consensus algorithm by the management device 10G or the like. As a result, information indicating the abolition of the version series is stored in the block chain, and subsequent tampering becomes difficult. Thereafter, connection of the block to the block chain corresponding to the discontinued version series is prohibited, and provision of software included in the discontinued version series is also prohibited.

  If the verification of the transaction data has failed in step S311, that is, if it is verified that the transaction data is not valid, the fact may be notified to the control device 70A. By doing so, the operator of the control device 70A can recognize this and take measures. On the other hand, the notification need not be made.

  When the management device 10G receives a request to issue a new version number from the development device 20A for the already discontinued version series, the management device 10G transmits a notification indicating that the version series has already been discontinued. Is also good. When the management device 10G abolishes the version series, the token management unit 16 may provide a token to a developer of a version included in the abolished version series. This token can be said to have a meaning as a reward or reward.

  The block chain in each of the above embodiments will be supplementarily described.

  FIG. 29 is an explanatory diagram showing the data structure of the block chain.

  A block chain is a block in which blocks as recording units are connected on a chain. Each block has a plurality of transaction data and a hash value of the immediately preceding block. Specifically, the block B2 includes the hash value of the previous block B1. Then, the hash value calculated from the plurality of transaction data included in the block B2 and the hash value of the block B1 is included in the block B3 as the hash value of the block B2. In this way, by connecting the blocks in a chain while including the contents of the previous block as a hash value, falsification of the recorded transaction data is effectively prevented.

  If past transaction data is changed, the hash value of the block will be different from the value before the change, and in order to make the falsified block correct, all subsequent blocks must be recreated, and this work Is very difficult in practice. Using this property, the tampering difficulty of the blockchain is secured.

  FIG. 30 is an explanatory diagram showing the data structure of the transaction data.

  The transaction data shown in FIG. 30 includes a transaction body P1 and an electronic signature P2. The transaction body P1 is a data body included in the transaction data. The electronic signature P2 is generated by signing the hash value of the transaction body P1 with the signature key of the creator of the transaction data, more specifically, by encrypting the hash value with the secret key of the creator. is there.

  Since the transaction data has the digital signature P2, falsification is substantially impossible. This prevents tampering of the transaction body.

  As described above, according to the management method of the present embodiment, it is possible to appropriately abolish the version series using predetermined transaction data. Therefore, it is possible to more easily suppress the falsification of the managed information while further eliminating the version series.

  In each of the above embodiments, each component may be configured by dedicated hardware, or may be realized by executing a software program suitable for each component. Each component may be realized by a program execution unit such as a CPU or a processor reading and executing a software program recorded on a recording medium such as a hard disk or a semiconductor memory. Here, the software for realizing the management device and the like in each of the above embodiments is the following program.

  That is, this program is a software version management method executed on a computer by a version management system, wherein the version management system includes a plurality of management devices holding a distributed ledger, The first management device of the plurality of management devices is related to first information about a first version of the software and a second version of the software upgraded by a developer based on the first version. Transaction information including second information, the developer identification information, and an electronic signature is received from a device connected to the first management device via a network, and the first management device is Using the electronic signature included in the received transaction data, the transaction Verifies the validity of the data, if the transaction data is valid, a program for executing a method of managing each of the plurality of management apparatus storing the transaction data in the distributed ledger.

  As described above, the management method according to one or more aspects has been described based on the embodiment, but the present invention is not limited to this embodiment. Unless departing from the gist of the present invention, various modifications conceivable to those skilled in the art may be applied to this embodiment, and a form constructed by combining components in different embodiments may be in the range of one or more aspects. May be included within.

  INDUSTRIAL APPLICABILITY The present invention is a software version management method, and can be used for a management system or the like that suppresses the occurrence of falsification of managed information.

1, 2 management system 10A, 10B, 10C, 10D, 10E, 10F, 10G, 10H, 10I management device 11, 21, 31, 71 communication unit 12 number management unit 13 transaction verification unit 14, 14A ledger management unit 15, 15A Block chain 16 token management unit 17 branch unit 18 abolition unit 19 state management unit 20A, 20B, 20C development device 22 development unit 23, 73 transaction generation unit 24, 34 storage device 30 storage server 32 storage unit 33 issuing unit 40, 40A 50, 60, 80, 91, 92 Transaction data 41, 51, 61 Developer ID
42, 52, 62 URL
43 New version number 43A, 81 Sequence number 44 Base version number 45, 53 New version hash value 46, 55, 65, 83 Signature 54, 64 Base version hash value 63 Difference hash value 70, 70A Control device 72 Branch instruction Part 82 Revocation information B1, B2, B3 Block N Network T1 Status table P1 Transaction body P2 Electronic signature

Claims (13)

A method for managing software versions performed by a version control system,
The version control system includes a plurality of management devices holding a distributed ledger,
The management method includes:
A first management device of the plurality of management devices has first information on a first version of the software and a second information on a second version of the software upgraded by a developer based on the first version. Information, transaction data including the developer identification information, and an electronic signature are received from a device connected to the first management device via a network,
The first management device verifies the validity of the transaction data using the electronic signature included in the received transaction data,
A management method in which each of the plurality of management devices stores the transaction data in the distribution ledger when the transaction data is valid. The second information includes a version number of the second version,
The management method further includes:
Before receiving the transaction data, if a request to issue a version number of the second version is received from the device, a new version number is transmitted to the device as the version number of the second version,
The management method according to claim 1, wherein when receiving the transaction data, the transaction data including the new version number transmitted to the device as the second information is received. The first information includes a version number of the first version of the software,
The management method according to claim 1, wherein the second information includes a hash value of the second version of the software and a version number of the second version. The first information includes a hash value of the first version of the software,
The management method according to claim 1, wherein the second information includes a hash value of the second version of the software. The first information includes a hash value of the first version of the software,
The management method according to claim 1, wherein the second information includes a hash value of a difference between the first version and the second version of the software. The device has location information indicating where the second version of the software is stored,
The management method includes:
The management method according to any one of claims 1 to 5, wherein when receiving the transaction data, the transaction data including the location information is received. The management method, when branching the second version series from the first version series of the software,
A new distributed ledger having at least one version including at least the last version of the first version series as one or more versions of the second version series is generated, and the plurality of management apparatuses are configured to generate the new distributed ledger. The management method according to any one of claims 1 to 6, wherein a ledger is held. When receiving the transaction data, specify whether the transaction data is transaction data according to the first version series or the second version series,
The management method according to claim 7, wherein the received transaction data is stored in a distributed ledger corresponding to a version series corresponding to the specified transaction data among the first version series and the second version series. The management method further includes:
When abolishing one version series,
9. The transaction data indicating that the one version series is abolished is generated, and the generated transaction data is stored in the distributed ledger corresponding to the one version series. 10. Management method. The management method further includes:
The management method according to any one of claims 1 to 9, wherein a token is provided to the developer with reference to the transaction data stored in the distribution ledger. The distributed ledger is a blockchain,
The management method according to any one of claims 1 to 10, wherein when the transaction data is valid, each of the plurality of management devices stores the transaction data in the block chain. A version management system for managing software versions, the first management device among a plurality of management devices holding a distributed ledger,
First information on the first version of the software, second information on the second version of the software upgraded by a developer based on the first version, identification information of the developer, and an electronic signature A transaction verification that receives transaction data including the transaction data from a device connected to the first management device via a network, and verifies the validity of the transaction data using the electronic signature included in the received transaction data. Department and
A management device comprising: a ledger management unit that stores the transaction data in the distributed ledger when the transaction data is valid. A version management system for managing software versions, a first management device among a plurality of management devices holding a distributed ledger, a program for operating a computer,
First information on the first version of the software, second information on the second version of the software upgraded by a developer based on the first version, identification information of the developer, and an electronic signature Transaction data including, received from a device connected to the first management device via a network, verify the validity of the transaction data using the electronic signature included in the received transaction data,
A program for storing the transaction data in the distributed ledger when the transaction data is valid.

Images