Preventing falsification in version management

The present disclosure provides a management method for software versions which prevents falsification of information under management. In the management method, a first management apparatus among management apparatuses receives transaction data from an apparatus connected through a network to the first management apparatus, the transaction data including first information on a first version of software, second information on a second version of the software subjected to version upgrade from the first version by a software developer, identification information of the software developer, and an electronic signature. The first management apparatus validates legitimacy of the transaction data using the electronic signature included in the transaction data received. When the transaction data is legitimate, the management apparatuses store the transaction data in distributed ledgers.

BACKGROUND

1. Technical Field

The present disclosure relates to management methods, management apparatuses, and programs.

2. Description of the Related Art

In management systems which manage software, the version information indicating versions of software developed by software developers is managed along with the identification information of the software developer (for example, see Japanese Unexamined Patent Application Publication No. 2014-203352).

SUMMARY

Unfortunately, traditional management systems have difficulties in preventing the falsification of the information under management by management servers.

An object of the present disclosure is to provide a management method for software versions which prevents the falsification of the information under management.

A management method according to one aspect of the present disclosure is a management method for software versions, the management method to be executed by a version management system, the management method including: receiving, by a first management apparatus among management apparatuses which are included in the version management system and have distributed ledgers, transaction data from an apparatus connected through a network to the first management apparatus, the transaction data including first information on a first version of software, second information on a second version of the software subjected to version upgrade from the first version by a software developer, identification information of the software developer, and an electronic signature; validating, by the first management apparatus, legitimacy of the transaction data using the electronic signature included in the transaction data received; and storing, by each of the management apparatuses, the transaction data in a corresponding distributed ledger among the distributed ledgers when the transaction data is legitimate.

These comprehensive or specific aspects may be implemented with systems, methods, integrated circuits, computer programs, or recording media such as computer-readable CD-ROMs, or may be implemented with any combination of systems, methods, integrated circuits, computer programs, and recording media.

The present disclosure provides a management method for software versions to prevent falsification of information under management.

DETAILED DESCRIPTION OF THE EMBODIMENTS

The present inventor has found that the following problem occurs in the development of software described in “BACKGROUND”.

The software is developed by agile development in which not only software developing companies but also many unspecified software developers participate. Such a form of development may generate a variety of version series by improving the software by a large number of software developers.

In a management system which manages software, the version information indicating versions of software developed by the software developers are managed along with the identification information of the software developers (for example, see Japanese Unexamined Patent Application Publication No. 2014-203352).

Here, the version information has a role to uniquely specify the version of the software. The identification information of the software developer may be used to provide a reward the software developer about the development of a new version of the software.

Unfortunately, traditional management systems have difficulties in preventing the falsification of the version information of a program managed by a management server or the identification information of the software developer.

Accordingly, the present disclosure provides a management method of preventing the falsification of the information under management.

The management method according to one aspect the present disclosure is a management method for software versions, the management method to be executed by a version management system, the management method including: receiving, by a first management apparatus among management apparatuses which are included in the version management system and have distributed ledgers, transaction data from an apparatus connected through a network to the first management apparatus, the transaction data including first information on a first version of software, second information on a second version of the software subjected to version upgrade from the first version by a software developer, identification information of the software developer, and an electronic signature; validating, by the first management apparatus, legitimacy of the transaction data using the electronic signature included in the transaction data received; and storing, by each of the management apparatuses, the transaction data in a corresponding distributed ledger among the distributed ledgers when the transaction data is legitimate.

According to the aspect above, the information on the software developer who has updated the version of the software is managed by the distributed ledger. The distributed ledger is advantageous in obstructing the falsification of the possessed information and in reducing influences by system failures. Accordingly, the management method above can prevent the falsification of the information under management.

For example, the second information may include a version number of the second version. The management method may further include: transmitting a new version number to the apparatus as the version number of the second version when a request to issue the version number of the second version has been received from the apparatus before the receiving; and receiving transaction data including, as the second information, the new version number transmitted to the apparatus in the receiving.

According to the aspect above, the version number of the new version is issued, and the information on the software developer of the new version is managed in correspondence with the issued version number. Failures such as duplication of the version number may occur when the version number is assigned by an apparatus different from the version management system. The management method according to the present disclosure can prevent such failures of the version number and prevent the falsification of the information under management.

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

According to the aspect above, the prevention in falsification of the information under management can be further facilitated using the version number of the first version, the hash value of the second version, and the version number of the second version.

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

According to the aspect above, the prevention in falsification of the information under management can be further facilitated using the hash value of the first version and the hash value of the second version.

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

According to the aspect above, the prevention in falsification of the information under management can be further facilitated using the hash value of the first version and the hash value of the difference between the first version and the second version.

For example, the apparatus may possess location information indicating a location where the second version is stored. In the management method, transaction data including the location information may be received in the receiving.

According to the aspect above, the information indicating the location where the software of the second version is stored is stored in the distributed ledger together with the information on the software developer. Accordingly, further, the falsification of the information under management can be prevented while the falsification of the information on the location where the second version is stored is also prevented.

For example, in the management method, when a second version series of the software is branched from a first version series of the software, a new distributed ledger having one or more versions including at least the latest version of the first version series as one or more versions of the second version series may be generated, and the management apparatuses may have the new distributed ledger.

According to the aspect above, the distributed ledgers corresponding to several version series are managed, and a distributed ledger corresponding to a new series is generated during branching of the version series. When a large number of version upgrades are performed in one series, the information corresponding to those version upgrades may be obtained when the information such as the history of version upgrade is obtained, increasing the processing load. In such a case, the version series is branched, and the new version series is managed by the new distributed ledger, thereby reducing the information such as the history of version upgrade and preventing the increase in processing load.

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

According to the aspect above, when several version series are managed according to several distributed ledgers, the version series to which the transaction data belongs can be specified, and the transaction data can be managed according to its appropriate distributed ledger.

For example, the management method may further include: generating transaction data indicating removal of one version series when removing the one version, and storing the transaction data generated in a distributed ledger corresponding to the one version series.

According to the aspect above, the version series can be appropriately removed using the predetermined transaction data. Accordingly, the prevention in falsification of the information under management can be further facilitated, and further, the removal of the version series is implemented.

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

According to the aspect above, a token is provided to the software developer of the new version based on the transaction data so far. Because the falsification of the transaction data stored in the distributed ledger is difficult, provision of the token to an inappropriate person who spoofs the software developer can be prevented. Thus, the falsification of the information under management can be prevented, preventing inappropriate provision of the token.

For example, the distributed ledgers may be blockchains, and when the transaction data is legitimate, the management apparatuses may store the transaction data in the blockchains.

According to the aspect above, the prevention in falsification of the information under management can be further facilitated by using blockchains as distributed ledgers by management apparatuses.

A management apparatus according to one aspect of the present disclosure is a first management apparatus among management apparatuses which are included in a version management system for managing software versions and have distributed ledgers. The management apparatus includes: a transaction validator which receives transaction data from an apparatus connected through a network to the first management apparatus, the transaction data including first information on a first version of software, second information on a second version of the software subjected to version upgrade from the first version by a software developer, identification information of the software developer, and an electronic signature, and validates legitimacy of the transaction data using the electronic signature included in the transaction data received; and a ledger manager which stores the transaction data in the distributed ledgers when the transaction data is legitimate.

Such a configuration achieves the same effect as that in the management method.

A management apparatus according to one aspect of the present disclosure is a program for operating a computer as a first management apparatus among management apparatuses which are included in a version management system for managing software versions and have distributed ledgers. The program includes: receiving transaction data from an apparatus connected through a network to the first management apparatus, the transaction data including first information on a first version of software, second information on a second version of the software subjected to version upgrade from the first version by a software developer, identification information of the software developer, and an electronic signature; validating legitimacy of the transaction data using the electronic signature included in the transaction data received; and storing the transaction data in the distributed ledgers when the transaction data is legitimate.

Such a configuration achieves the same effect as that in the management method above.

These comprehensive or specific aspects may be implemented with systems, methods, integrated circuits, computer programs, or recording media such as computer-readable CD-ROMs, or may be implemented with any combination of systems, methods, integrated circuits, computer programs, or recording media.

Embodiments will now be specifically described with reference to the drawings.

The embodiments described below all are comprehensively or specifically illustrative. Numeric values, shapes, materials, components, arrangements, positions, and connection forms thereof, steps, order of steps, and the like described in the following embodiments are exemplary, and should not be construed as limitative to the present disclosure. Among the components of the embodiments below, the components not described in an independent claim representing the most superordinate concept of the present disclosure are described as arbitrary components.

In the present embodiment, a management method for software versions will be described, which prevents the falsification of the information under management. Here, the software is, for example, software which is installed in a home appliance (such as a laundry machine, an air conditioner, a refrigerator, or a television set) to control the operation of the home appliance and demonstrate the function of the home appliance.

FIG. 1is a diagram illustrating a version series of software in agile development.

As illustrated inFIG. 1, in the agile development, a software development company (Z Company) develops a first version, i.e., version 1 (represented as “Ver1” in the drawing, the same applies below), and provides Ver1 to the community of software developers. Based on the software of version 1 provided, the software developers belonging to the community then perform development to generate a variety of version series. Different software programs having different functions are developed in the version series, for example. The version series is represented as series 1A inFIG. 1. The version series includes one or more versions.

As illustrated inFIG. 1, based on the software of version 1, version 1.A1 is generated through the development by software developer A, version 1.B1 is generated through the development by software developer B, and version 1.C1 is generated through the development by software developer C.

Further development may be performed based on these versions. For example, version 1.A2 is developed based on version 1.A1, and version 1.A3 is developed based on version 1.A2. Version 1.B2 is developed based on version 1.B1. Based on version 1.C1, software developers D and E develop versions 1.C1.D1 and 1.C1.E1 as version series.

Here, the versions of and after version 1.A1 (i.e., version 1.A1 and versions 1.A2 and 1.A3 which are versions developed based on version 1.A1) are referred to as series 1A. Similarly, the versions of and after version 1.B1 are referred to as series 1B. Version 1.C1 is referred to as series 1C, version 1.C1.D1 is referred to as series 1D, and version 1.C1.E1 is referred to as series 1E. The series including version 1 and all the versions of series 1A to 1E is referred to as series 1 in some cases.

As described above, in the agile development, software developers different from the software development company develop software based on the software provided by the software development company (Z Company), generating several version series.

Among these versions, a version which a user desires is provided to the user. For example, the latest version of the version series having the functions which the user desires is provided to the user.

FIG. 2is a diagram illustrating transmission and reception of a token in the agile development. Here, the token represents a concept corresponding to a profit or value, and may be possessed and transferred by a person (natural person) or a manufacturer (legal person). In the agile development, the development of the software is advanced by appropriately transferring tokens between a software developer, a general user, and a manufacturer.

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

The general user provides the data of the product, which is obtained when the home appliance having the software installed therein is operated, to the manufacturer, and receives a token in exchange for the data.

Here, the token is directly transferred between the general user and the software developer without the manufacturer interposed therebetween. When such transfer of the token occurs, the identification information of the software developer under management may be falsified for the purpose of dishonestly obtaining a profit or impairing profits of others in some cases. The falsified identification information enables the following behaviors: A malicious person may spoof the software developer to receive the token, or may spoof another person to provide malicious software and damage the reputation of the software developer.

The management system according to the present embodiment aims at preventing the falsification of information under management.

FIG. 3is a diagram illustrating a configuration of management system1according to Embodiment 1.

As illustrated inFIG. 3, management system1includes management apparatuses10A,10B, and10C, development apparatuses20A,20B, and20C, and storage server30. These apparatuses are communicably connected to each other through network N.

Management apparatuses10A,10B, and10C (also referred to as management apparatuses10A and others) are management apparatuses which manage the information on the versions of software by computers. Although an example of three management apparatuses10A and others will be described, the number of management apparatuses may be two or more. Management apparatuses10A and others are communicably connected to each other. Management apparatuses10A and others each correspond to a first management apparatus. Although management apparatus10A is used as a representative of management apparatuses10A and others in the following description in some cases, the same also applies to other management apparatuses10B and10C. Management apparatuses10A and others can also communicate through network N.

Management apparatuses10A and others each have a distributed ledger for managing the information on the version of software. Management apparatuses10A and others update the distributed ledgers of their own while synchronizing with each other through communication. When one of management apparatuses10A and others obtains the information on a new version from one of development apparatuses20A and others, management apparatuses10A and others each have a copy of the obtained information. In general, the distributed ledger is advantageous in obstructing the falsification of the possessed information and in reducing influences by the system failures.

Development apparatuses20A,20B, and20C (also referred to as development apparatuses20A and others) are computers used by a software developer of the software, and each independently operate. Although an example of three development apparatuses20A and others will be described, the number of development apparatuses may be one or more. Although development apparatus20A is used as a representative of development apparatuses20A and others in the following description, the same also applies to other development apparatus20B and20C.

The software developer develops a new version of the software using development apparatus20A, and transmits the developed software of the new version to storage server30to store the software in storage server30. Development apparatus20A also transmits the information on the new version developed by the software developer through network N to one of management apparatuses10A and others.

Storage server30is a computer which stores the software. Storage server30stores one or more versions of the software in a memory device.

Network N is a communication line which communicably connects management apparatuses10A and others, development apparatus20A, and storage server30to each other. Any communication line can be used. Any combination of wired networks with wireless networks may be used. Network N may partially include the Internet.

Storage server30, development apparatuses20A and others, and management apparatuses10A and others will now be described in more detail.

FIG. 4is a block diagram of a configuration of storage server30according to the present embodiment.

As illustrated inFIG. 4, storage server30includes communicator31, storage32, publisher33, and memory device34. The functions of storage server30can be implemented by a processor which executes a predetermined program using a memory.

Communicator31is a communication interface device connected to network N. Storage server30can communicate with development apparatus20A through communicator31.

Storage32is a processor which stores the software using memory device34. Storage32obtains the software of the new version from development apparatus20A through communicator31, and stores the obtained software in memory device34. Storage32also reads the software stored in memory device34in response to a request from a user.

Publisher33is a processor which publishes location information indicating the location where the software is stored. In the case where storage32stores the software in memory device34, publisher33obtains the information indicating the location where the software is stored, and generates and publishes the location information indicating the location. Publisher33notifies development apparatus20A of the generated location information.

The location information is, for example, a uniform resource locator (URL) indicating a position on the Internet of an electric file related with the software in memory device34. This case will now be described below as an example. The URL includes the information of the path indicating the location in memory device34and the file name, and the host name of storage server30, for example.

Memory device34is a memory device in which the software is stored. Memory device34stores one or more versions of the software. The software is stored in memory device34by storage32, and is read therefrom by storage32.

FIG. 5is a block diagram illustrating a configuration of development apparatus20A according to the present embodiment. Development apparatuses20B and20C also have the same configuration, and each independently operate.

As illustrated inFIG. 5, development apparatus20A includes communicator21, developer22, transaction generator23, and memory device24. The functions of development apparatus20A can be implemented by a processor which executes a predetermined program using a memory.

Communicator21is a communication interface device connected to network N. Development apparatus20A can communicate with storage server30and management apparatus10A through communicator21.

Developer22is a processor which generates a new version of the software developed by the software developer based on the operation by a user or the function of a tool for developing software. Developer22specifically has software (or program or program codes) of a version (corresponding to a first version) underlying the development of the software, and generates a new version (corresponding to second version) of the software based on the possessed software. Thus, the software developer develops the new version of the software using development apparatus20A (specifically, developer22). The development of the new version is also referred to as version upgrade. Developer22transmits the developed software of the new version through communicator21to storage server30to store the software in storage server. At this time, storage server30(specifically, publisher33) notifies developer22of the URL indicating the location of the software stored in storage server30.

Transaction generator23is a processor which generates transaction data including the information on the version of the software. The transaction data includes at least information on a first version of the software (corresponding to first information), information on a second version obtained through version upgrade of the first version by the software developer (corresponding to second information), a software developer ID as an identification information of the software developer, and the electronic signature of the software developer. The electronic signature of the software developer is generated from the information included in the transaction data through encryption with the private key of the software developer. The identification information of the software developer and the private key thereof can be obtained by reading these from memory device24by transaction generator23. Transaction generator23transmits the generated transaction data through communicator21to management apparatus10A.

Transaction generator23also generates a request to issue a new version number, and transmits the request to management apparatus10A. Transaction generator23receives the notification of the new version number in reply.

Memory device24is a memory device which stores the information on the software developer and the information on the software. The information on the software developer includes a software developer ID as the identification information of the software developer, and key information of the software developer (including the private key). The software developer ID is information which enables unique identification of the software developer. The information on the software includes a body of software, and the URL indicating the location in storage server30where the software is stored. Here, the body of software indicates a software program, and is simply represented as “software” inFIG. 5. The body of software stored in memory device24is read by developer22. The software developer ID, the key information, and the URL stored in memory device24are read by transaction generator23.

FIG. 6is a block diagram illustrating a configuration of management apparatus10A according to the present embodiment.

As illustrated inFIG. 6, management apparatus10A includes communicator11, number manager12, transaction validator13, ledger manager14, and token manager16. The functions included in management apparatus10A can be implemented by a processor which executes a predetermined program using a memory.

Communicator11is a communication interface device connected to network N. Management apparatus10A can communicate with development apparatus20A and other management apparatuses10B and10C through communicator11.

Number manager12is a processor which manages the version number of the version of the software. When receiving a request to issue a new version number of the software from development apparatus20A, number manager12issues the new version number according to the request, and notifies development apparatus20A of the request. Among the versions currently possessed, number manager12issues a version number advanced from the version number of the latest version. In the case where the version has several series, number manager12receives 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 predetermined rules. For example, the version number is set using numeric values such that a more advanced version (that is, a version more repeatedly subjected to version upgrade) has a greater numeric value. At this time, letters may also be used in combination with numeric values. Here, an example where the version series is represented with letters will be illustrated. In other words, the versions included in series 1A developed based on the first version, i.e., version 1 are referred to as version 1.A1, version 1.A2, version 1.A3, and the like. The versions included in series 1B developed based on version 1 separately from series 1A are referred to as version 1.B1, version 1.B2, and the like.

Transaction validator13is a processor which validates the legitimacy of the transaction data. Transaction validator13receives the transaction data through communicator11from development apparatus20A. The transaction data to be received includes first information on the first version of the software, second information on the second version of the software obtained through version upgrade of the first version by the software developer, the identification information of the software developer, and the electronic signature of the software developer. When receiving the transaction data, transaction validator13validates the legitimacy of the transaction data using the electronic signature included in the received transaction data. The legitimacy of the transaction data is validated using the information included in the transaction data and the public key of the software developer to determine the legitimacy of the transaction data. More specifically, it is determined that the transaction data is surely generated by development apparatus20A and the transaction data has not been falsified from the generation. The validation of the legitimacy of the transaction data is also simply referred to as validation of the transaction data.

The transaction data received by transaction validator13may include a new version number notified by number manager12.

The transaction data received by transaction validator13may further include the URL or location information of the software of the new version.

Ledger manager14is a processor which manages the distributed ledger for managing the versions of software. Although an example where the distributed ledger is blockchain15will be described here, another type of distributed ledger (such as IOTA or a hashgraph) may also be used.

In the case where transaction validator13validates the transaction data, ledger manager14synchronizes the transaction data through the transmission of the transaction data to other management apparatuses10B and10C. Ledger manager14then executes a consensus algorithm between management apparatus10A and other management apparatuses10B and10C. In the case where an agreement is generated by the consensus algorithm, a block including the transaction data is generated, and the generated block is stored in blockchain15.

Although one example of consensus algorithms is Practical Byzantine Fault Tolerance (PBFT), any other consensus algorithms such as Proof of Work (PoW) or Proof of Stake (PoS) may also be used.

Token manager16is a processor which manages tokens possessed by the user and the software developer. Token manager16provides a token to the software developer with reference to the transaction data stored in blockchain15. Token manager16may use blockchains for management of tokens.

Three examples of a configuration of transaction data which allows management apparatuses10A and others to manage the new version of the software will now be illustrated.

FIG. 7is a diagram illustrating transaction data40as a first example of the transaction data according to the present embodiment. Transaction data40is an example where the first information on the first version of software includes the version number of the first version and the second information on the second version of software includes a hash value of the second version and the version number of the second version.

As illustrated inFIG. 7, transaction data40includes software developer ID41, URL42, new version number43, base version number44, hash value45of the new version, and signature46.

Software developer ID41is the identification information of the software developer who has developed the new version to be newly managed according to transaction data40.

URL42is an URL indicating the location where the new version to be newly managed according to transaction data40is stored. URL42indicates the location in memory device34of storage server30where the software of the new version is stored.

New version number43is a version number of the new version to be newly managed according to transaction data40.

Base version number44is a version number of the version (also referred to as base version) underlying the new version to be newly managed according to transaction data40.

Hash value45of the new version is a hash value obtained through a hash operation performed on all the programs of the new version to be newly managed according to transaction data40or predetermined part of the programs.

Signature46is an electronic signature generated from the information included in transaction data40through encryption with the private key of the software developer. Specifically, signature46is a value obtained as follows: A hash value is obtained by performing a hash operation on the information including software developer ID41, URL42, new version number43, base version number44, and hash value45of the new version, and is encrypted with the private key of the software developer.

FIG. 8is a diagram illustrating transaction data50as a second example of the transaction data according to the present embodiment. Transaction data50is an example where the first information on the first version of software includes the 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.

As illustrated inFIG. 8, transaction data50includes software developer ID51, URL52, hash value53of the new version, hash value54of the base version, and signature55.

Software developer ID51and URL52are the same as those in transaction data40.

Hash value53of the new version is a hash value obtained by the hash operation performed on all the programs of the new version of the software to be newly managed according to transaction data50or predetermined part of the programs.

Hash value54of the base version is a hash value obtained by the hash operation performed on all the programs of the base version of the software underlying the new version of the software to be newly managed according to transaction data50or predetermined part of the programs.

Signature55is an electronic signature generated from the information included in transaction data50through encryption with the private key of the software developer. Specifically, signature55is a value obtained as follows: A hash value is obtained by performing a hash operation on the information including software developer ID51, URL52, hash value53of the new version, and hash value54of the base version, and is encrypted with the private key of the software developer.

FIG. 9is a diagram illustrating transaction data60as a third example of the transaction data according to the present embodiment. Transaction data60is an example where the first information on the first version of software includes the 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 difference between the first version of the software and the second version thereof.

Software developer ID61and URL62are the same as those in transaction data40.

Hash value63of the difference is a hash value of the difference between a new version of the program to be newly managed according to transaction data60and a base version of the program underlying the development of the new version.

Hash value64of the base version is a hash value obtained through a hash operation performed on all the programs in the new version of the software to be newly managed according to transaction data60or predetermined part of the programs.

Signature65is an electronic signature generated from the information included in transaction data60through encryption with the private key of the software developer. Specifically, signature65is a value obtained as follows: A hash value is obtained by performing a hash operation on the information including software developer ID61, URL62, hash value63of the difference, and hash value64of the base version, and is encrypted with the private key of the software developer.

The transaction data stored in blockchain15will now be described.

FIG. 10is a diagram illustrating an example of the transaction data stored in blockchain15according to the present embodiment.FIG. 10is specifically transaction data managed with blockchain15by management apparatuses10A and others. One entry (one row) shown inFIG. 10corresponds to one piece of transaction data. The data located in a lower portion ofFIG. 10is newer transaction data.

As illustrated inFIG. 10, each piece of transaction data includes the URL, the new version number, the base version number, and the software developer ID of each version of the software. The information in the transaction data illustrated inFIG. 10corresponds to the information included in transaction data40illustrated inFIG. 7.

As illustrated inFIG. 10, blockchain15stores the information on the early versions of the software from the current point of time. Specifically, blockchain15stores the information indicating that versions 1.A1, 1.A2, and 1.A3 are developed from version 1 and that versions 1.B1 and 1.B2 are developed from version 1.

The information on the early versions of the software from the current point of time is managed by management apparatus10A so as to prevent falsification, because the blockchain is difficult to falsify.

Processing of management system1will now be described.

FIGS. 11 and 12are sequence diagrams illustrating first and second processings in management system1according to the present embodiment, respectively.FIGS. 11 and 12illustrate a series of processing from the development of the new version of the software by development apparatus20A to the management of the developed version of the software by management apparatuses10A and others.

As illustrated inFIG. 11, in step S121, a new version of the software is completed by development apparatus20A.

In step S122, development apparatus20A transmits the new version of the software developed in step S121to storage server30to store the new version of the software in storage server30.

In step S131, storage server30receives the new version of the software transmitted from development apparatus20A, and stores it in memory device34.

In step S132, storage server30publishes an URL indicating the location of the new version of the software stored in step S131. Storage server30then transmits the published URL to development apparatus20A. The URL can be transmitted as a reply to the software received in step S122.

In step S123, development apparatus20A generates a request to issue a new version number (also referred to as new number), and transmits it to management apparatus10A. Here, the request to issue a new version number is communication data for requesting the issuing of a new number to be assigned to the new version of the software (i.e., the new version number) to management apparatus10A. The request includes at least the base version number.

In step S111, management apparatus10A receives the request transmitted in step S123, and determines whether the base version included in the request is stored in blockchain15managed by management apparatus10A. In the case where management apparatus10A determines that the base version is stored in blockchain15(Yes in step S111), the processing goes to step S112.

In the case where management apparatus10A determines that the base version is not stored in blockchain15(not illustrated), management apparatus10A executes predetermined error processing (such as processing to transmit a notification indicating the failure of the issuing of the new number to development apparatus20A), and terminates the processing. In this case, management apparatus10A may terminate the processing without performing any processing. Management apparatus10A determines that the base version is not stored in blockchain15, for example, when management apparatuses10A and others are caused to manage a version of software not managed by management apparatuses10A and others.

In step S112, management apparatus10A issues the version number of the new version.

Referring toFIG. 12, in step S113, management apparatus10A notifies development apparatus20A 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 reply to the request to issue the new version number in step S123.

In step S124, transaction data for writing the new version in blockchain15is generated, and is transmitted to management apparatus10A. This transaction data includes the new version number transmitted in step S113or the information calculated using this new version number.

In step S114, management apparatus10A validates the transaction data transmitted by development apparatus20A in step S124. Here, assume that it is determined as a result of validation of the transaction data that the transaction data is legitimate.

In step S115, management apparatus10A transmits the transaction data to management apparatuses10B and10C. The block including the transaction data is stored in blockchain15through execution of the consensus algorithm by management apparatuses10A and others. Thus, the information on the new version of the software developed by the software developer, more specifically, the software developer ID and the version number are stored in blockchain15, obstructing the falsification of the information after the storage thereof.

In the case where the validation of the transaction data is failed in step S114, that is, it is validated that the transaction data is not legitimate, development apparatus20A may be notified of this failure. By this notification, the software developer can recognize and treat the failure. This notification does not need to be performed.

Management apparatus10A may store the software itself in blockchain15, and manage the software. Such an operation is more useful because not only the information on the version but also the software can be managed while the falsification of the software itself is also prevented. To do so, development apparatus20A may generate the transaction data including the software itself (i.e., the program codes of the software), and transmit the transaction data to management apparatus10A. Management apparatus10A may store the received transaction data in blockchain15.

Although development apparatus20A has been described as one example of an apparatus connected to management apparatus10A through a network, any apparatus other than development apparatus20A may be used. For example, an apparatus used by an outside contractor of the software developer may also be the apparatus connected to management apparatus10A through a network. The description above also applies to this case by replacing the “software developer” in the description above with the “outside contractor of the software developer”.

As above, in the management method according to the present embodiment, the information on the software developer who has updated the version of the software is managed by the distributed ledger. The distributed ledger is advantageous in obstructing the falsification of the possessed information and in reducing influences by the system failures. Accordingly, the management method can prevent the falsification of the information under management.

Moreover, the version number of the new version is issued, and the information on the software developer of the new version is managed in correspondence with the issued version number. Failures such as duplication of the version number may occur when the version number is assigned by an apparatus different from the version management system. The management method according to the present disclosure can prevent such failures of the version number and prevent the falsification of the information under management.

The prevention in falsification of the information under management can be further facilitated using the version number of the first version, the hash value of the second version, and the version number of the second version.

The prevention in falsification of the information under management can be further facilitated using the hash value of the first version and the hash value of the second version.

The prevention in falsification of the information under management can be further facilitated using the hash value of the first version and the hash value of the difference between the first version and the second version.

Moreover, the information indicating the location where the software of the second version is stored is stored in the distributed ledger together with the information on the software developer. Accordingly, further, the falsification of the information under management can be prevented while the falsification of the information on the location where the second version is stored is also prevented.

Moreover, a token is provided to the software developer of the new version based on the transaction data so far. Because the falsification of the transaction data stored in the distributed ledger is difficult, provision of the tokens to an inappropriate person who spoofs the software developer can be prevented. Thus, the falsification of the information under management can be prevented, preventing inappropriate provision of the tokens.

Moreover, the prevention in falsification of the information under management can be further facilitated by using blockchains as distributed ledgers by management apparatuses.

In the present embodiment, a management method for software versions will be described, which prevents the falsification of the information under management. In particular, a technique of managing versions using different blockchains before and after major version upgrade of software during the major version upgrade will be described.

Here, the major version upgrade usually indicates version upgrade where a base version is subjected to relatively large modification or addition of functions. In contrast, the version upgrade from the first version to the second version described in Embodiment 1 is version upgrade where relatively small modification or addition of functions is performed, and is usually also referred to as minor version upgrade. The major version upgrade is performed based on a decision by Z Company, for example.

FIG. 13is a diagram illustrating branching of the version series according to the present embodiment.

Version 1 illustrated inFIG. 13(represented as “Ver1” inFIG. 13) corresponds to the version of the software according to Embodiment 1. Here, the community of the software developer who has developed the software is referred to as “community of version 1”.

When the major version upgrade is performed in the development of software, copies of series 1 developed in the community of version 1 are partially or entirely used as series 2 which is a new version series. At this time, a series of versions including at least the latest version of series 1 of the versions developed by the community of version 1 is used as series 2. A version series including all the versions of the version series developed by the community of version 1 may be used.

Such generation of a new series 2 from part of or entire series 1 is referred to as “branching of the series”. In other words, the branching means generation of a new series 2 from part of or entire series 1.

Software developers belonging to the community of version 2 perform development based on the first version of series 2 (“Ver2” inFIG. 13) to generate a variety of version series.FIG. 13illustrates that based on version 2 of the software, software developer F develops and generates version 2.F1, and software developer G develops and generates version 2.G1. Furthermore, version 2.F2 is developed from version 2.F1.

FIG. 14is a diagram illustrating a configuration of management system2according to the present embodiment.

As illustrated inFIG. 14, management system2includes management apparatuses10D,10E, and10F, development apparatuses20A and others, storage server30, and control apparatus70. Development apparatuses20A and others and storage server30are the same as those in Embodiment 1, and their description will be omitted.

Control apparatus70controls and causes management apparatuses10D and others to branch the version series. Control apparatus70specifically transmits, as the control, communication data including an instruction to branch the version series. This communication data can be transmitted based on an operation performed on control apparatus70by a user.

Similarly to management apparatuses10A and others in Embodiment 1, management apparatuses10D,10E, and10F (also referred to as10D and others) manage the version information using computers. Management apparatuses10D and others have the functions equivalent to those of management apparatuses10A and others, and further have a function to create the branch of the version series based on the branching instruction transmitted from control apparatus70.

FIG. 15is a block diagram illustrating a configuration of control apparatus70according to the present embodiment.

Communicator71is a communication interface device connected to network N. Control apparatus70can communicate with management apparatus10D through communicator71. The functions included in control apparatus70can be implemented by a processor which executes a predetermined program using a memory.

Branching instructor72is a processor which transmits an instruction (branching instruction) to cause management apparatus10D to branch the series through communicator71. The branching instruction includes at least information for specifying the underlying version series for the branching.

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

As illustrated inFIG. 16, management apparatus10D includes communicator11, number manager12, transaction validator13, and ledger manager14A. The functions included in management apparatus10D may be implemented by a processor which executes a predetermined program using a memory.

Unlike management apparatus10A in Embodiment 1, management apparatus10D includes ledger manager14A. Ledger manager14A will now be mainly described.

Ledger manager14A includes brancher17. In addition to blockchain15, ledger manager14A may include blockchain15A.

Brancher17is a processor which branches the version series of the software to create a new series. Brancher17receives the communication data including the branching instruction transmitted by control apparatus70through communicator11, and creates the branch of the version series of the software in response to the reception of the communication data. At this time, brancher17branches the version series by generating blockchain15A. Blockchain15A corresponds to the new version series which possesses copies of one or more versions including at least the latest version in blockchain15corresponding to the version series subjected to version upgrade.

After branching of the version series, transaction validator13, when receiving the transaction data, specifies whether the transaction data is derived from the first version series or the second version series, and stores the received transaction data in the distributed ledger corresponding to the version series corresponding to the specified transaction data among the first version series and the second version series.

Blockchains15and15A managed by ledger manager14A according to the present embodiment will now be described.

FIGS. 17 and 18are diagrams illustrating transaction data stored in blockchains15and15A according to the present embodiment. Specifically, the transaction data illustrated inFIG. 17is stored in blockchain15corresponding to series 1 which is the version series including version 1. The transaction data illustrated inFIG. 18is stored in blockchain15A corresponding to series 2 which is the version series including version 2.

As illustrated inFIG. 17, similarly to blockchain15illustrated inFIG. 10, the transaction data included in blockchain15corresponding to series 1 includes the URLs, new version numbers, base version numbers, and software developer IDs of all the versions of the software. Specifically, blockchain15includes the information above on versions 1.A1, 1.A2, and 1.B1.

As illustrated inFIG. 18, similarly to blockchain15included inFIG. 10, the transaction data included in blockchain15A corresponding to series 2 includes the URLs, new version numbers, base version numbers, and software developer IDs of all the versions of the software. Specifically, blockchain15A includes the information above on versions 2.D1, 2.D2, and 2.E1.

Processing of management system2will now be described.

FIG. 19is a sequence diagram illustrating processing in management system2according to the present embodiment.

As illustrated inFIG. 19, when Z Company decides to branch the version series in step S271, control apparatus70generates communication data including a branching instruction, and transmits it to management apparatus10D.

In step S211, when receiving the branching instruction transmitted in step S271, management apparatus10D generates transaction data for generating a blockchain corresponding to a new version series (corresponding to blockchain15A inFIG. 16).

In step S212, management apparatus10D transmits the transaction data generated in step S211to management apparatuses10E and10F. A block including the transaction data is then stored in a blockchain through execution of a consensus algorithm by management apparatuses10D and others. Thereby, the information on the new version of the software corresponding to the new version series, more specifically, the software developer ID and the version number are stored in the blockchains, obstructing the falsification of the information after the storage thereof.

Management of the new version when blockchains corresponding to several version series are managed by management apparatuses10D and others will now be described.

FIG. 20is a diagram illustrating transaction data40A, which is an example of the transaction data according to the present embodiment.

Transaction data40A includes transaction data40illustrated inFIG. 7, and further includes series number43A.

Series number43A is the information indicating the series of the new version to be newly managed according to transaction data40A.

Signature46is an electronic signature generated from the information included in transaction data40A through encryption with the private key of the software developer. The information underlying the generation of signature46also includes series number43A in addition to the information underlying the generation of signature46inFIG. 7.

In the case where several series are present, development apparatus20A transmits transaction data40A to management apparatus10D, where transaction data40A includes series number43A indicating the series to which the new version of the software belongs. When receiving transaction data40A, management apparatus10D obtains the series number included in transaction data40A received, and stores transaction data40A in the blockchain corresponding to the series number.

FIG. 21is a flowchart illustrating processing performed on the version series included in the consensus algorithm according to the present embodiment. The processing illustrated inFIG. 21is included in the consensus algorithm in step S115ofFIG. 12.

In step S141, management apparatus10D obtains the series number included in transaction data40A received.

In step S142, management apparatus10D specifies the blockchain corresponding to the series number obtained in step S141among the blockchains managed by ledger manager14A.

In step S143, the consensus algorithm is executed on the blockchain specified in step S142between management apparatus10D and management apparatuses10E and10F. Thereby, transaction data40A received is stored in the blockchain specified in step S142.

Thus, the transaction data is stored in the blockchain corresponding to the series number specified by development apparatus20A.

As above, the management method according to the present embodiment manages the distributed ledgers corresponding to several version series, and generates a distributed ledger corresponding to a new series during branching of the version series. When a large number of version upgrades are performed in one series, the information corresponding to those version upgrades may be obtained when the information such as the history of version upgrade is obtained, increasing the processing load. In such a case, the version series is branched, and the new version series is managed by the new distributed ledger, thereby reducing the information such as the history of version upgrade and preventing the increase in processing load.

When several version series are managed by several distributed ledgers, the version series to which the transaction data belongs can be specified, and the transaction data can be managed by its appropriate distributed ledger.

In the present embodiment, a management method for software versions will be described, which prevents the falsification of the information under management. In particular, a technique of managing versions so as to stop use of the version series of the software will be described. Stop of use of the version series is also referred to as removal of the version series.

FIG. 22is a diagram illustrating removal of a version series according to the present embodiment.

Ver1 and Ver2 illustrated inFIG. 22correspond to the versions of software according to Embodiment 2, respectively.

In the development of software, use of relatively old version series of the program is stopped, that is, those are removed because relatively new version series thereof are generated. The removed version series are controlled such that the version upgrade of the program after the removal is prohibited. The removed version series may be further controlled such that the software of the versions included in the removed series is prohibited from being provided to users after the removal of the version series.

Specifically, as illustrated inFIG. 22, assume that series 1 is removed when the latest version 1.A3 of the version series of version 1.A and the latest version 1.B2 of the version series of version 1.B are present. Then, the registration of the next version 1.A4 (not illustrated) which may be included in the version series of version 1.A or the next version 1.B3 (not illustrated) which may be included in the version series of version 1.B is prohibited, for example. In addition, the software of the series of version 1, version 1.A, and version 1.B is prohibited from being provided to users after the removal of series 1.

Management system2according to the present embodiment is similar to management system2in Embodiment 2, and has functions of the control apparatus and the management apparatus, some of which are different from those in management system2in Embodiment 2. Specifically, management system2according to the present embodiment includes control apparatus70A, and management apparatuses10G,10H, and10I (also referred to as10G and others). Control apparatus70A and management apparatus10G according to the present embodiment will now be described in detail.

FIG. 23is a block diagram illustrating a configuration of control apparatus70A according to the present embodiment.

As illustrated inFIG. 23, control apparatus70A includes communicator71and transaction generator73. Control apparatus70A may include branch instructor72as in control apparatus70according to Embodiment 2.

Communicator71is the same as communicator71included in control apparatus70A according to Embodiment 2.

Transaction generator73is a processor which generates transaction data indicating the removal of the version series. Transaction generator73transmits the generated transaction data to management apparatus10G. The transaction data includes at least a series number as specification information which can specify the version series to be removed.

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

As illustrated inFIG. 24, management apparatus10G includes communicator11, number manager12, transaction validator13, ledger manager14A, and remover18. Management apparatus10G may include state manager19. The functions included in management apparatus10G may be implemented by a processor which executes a predetermined program using a memory.

Unlike management apparatus10A in Embodiment 1 and management apparatus10D in Embodiment 2, management apparatus10G may include remover18and state manager19. Remover18and state manager19will now be mainly described.

Remover18is a processor which stores a block in a blockchain corresponding to the version series to be removed, the block including information indicating the removal of the version series. Remover18receives the transaction data transmitted from control apparatus70A, the transaction data indicating the removal of the version series. Remover18stores the transaction data in the blockchain corresponding to the version series specified by the series number included in the received transaction data.

State manager19is a processor which manages the information indicating whether the version series are operated or removed. State manager19possesses the information indicating that the version series managed by management apparatus10G are operated or removed. When remover18stores the transaction data to remove the version series in the blockchain, state manager19changes the state of the version series from operated to removed. State manager19is not an essential configuration.

FIG. 25is a diagram illustrating transaction data80as an example of the transaction data according to the present embodiment.

Series number81is the information for specifying the version series to be removed according to transaction data80.

Removal information82is the information indicating that transaction data80means the removal of the version series.

Signature83is an electronic signature generated from the information included in transaction data80through encryption with the private key of control apparatus70A. Specifically, signature83is a value obtained as follows: A hash value is obtained by performing a hash operation on the information including series number81and removal information82, and is encrypted with the private key of control apparatus70A.

FIG. 26is a diagram illustrating the transaction data stored in a blockchain according to the present embodiment. Specifically, the transaction data illustrated inFIG. 26is blockchain15corresponding to the version series of version 1.

As illustrated inFIG. 26, similarly to blockchain15included inFIG. 10, the transaction data included in blockchain15corresponding to the version series of version 1 includes the URLs, new version numbers, base version numbers, and software developer IDs of the versions of the software. Specifically, blockchain15includes the information above on versions 1.A1, 1.A2, and 1.B1.

Transaction data91included in blockchain15is the transaction data for removing version series 1A. Transaction data92included in blockchain15is the transaction data for removing version series 1B.

FIG. 27is a diagram illustrating state table T1indicating the state information managed by state manager19according to the present embodiment.

As illustrated inFIG. 27, state table T1has the information indicating the states of version series 1A and 1B.FIG. 27illustrates that version series 1A is removed and version series 1B is operated. This corresponds to the case where ledger manager14A possesses the blockchains corresponding to the series of version 1 and that of version 2, the series of version 1 is removed, and the series of version 2 is operated.

Processing of management system2will now be described.

FIG. 28is a sequence diagram illustrating processing in management system2according to the present embodiment.

As illustrated inFIG. 28, in step S371, control apparatus70A generates the transaction data to remove the version series, and transmits it to management apparatus10G.

In step S311, management apparatus10G receives the transaction data transmitted in step S371, and validates the received transaction data. The transaction data is validated with the information included in the transaction data and the public key of control apparatus70A. Here, assume that as a result of the validation of the transaction data, it is determined that the transaction data is legitimate.

In step S312, management apparatus10G transmits the transaction data generated in step S312to management apparatuses10H and10I. A block including the transaction data is stored in a blockchain through execution of the consensus algorithm by management apparatus10G and others. Thereby, the information indicating the removal of the version series is stored in the blockchain, obstructing the falsification thereafter. Thereafter, connection of the block to the blockchain corresponding to the removed version series is then prohibited, and the software included in the removed version series is also prohibited from being provided.

In the case where the validation of the transaction data is failed in step S311, that is, it is validated that the transaction data is not legitimate, control apparatus70A may be notified of this failure. By this notification, the operator of control apparatus70A can recognize and treat the failure. This notification does not need to be performed.

When receiving a request to issue a new version number from development apparatus20A on the version series already removed, management apparatus10G may transmit a notification indicating that the version series is already removed. Alternatively, when management apparatus10G removes the version series, token manager16may provide a token to the software developer of the version included in the removed version series. This token means a reward or an advance payment.

The blockchain in the embodiments above will be complementally described.

FIG. 29is a diagram illustrating a data structure of the blockchain.

The blockchain is composed of blocks (recording unit) connected on a chain. One block has pieces of transaction data and the hash value of a block immediately before the one block. Specifically, block B2includes the hash value of block B1immediately before block B2. The hash value obtained from an arithmetic operation performed on the pieces of transaction data included in block B2and the hash value of block B1is included in block B3as the hash value of block B2. Thus, the blocks are connected into a chain while the contents of the previous blocks are included as hash values, thereby effectively preventing the falsification of the recorded transaction data.

Any change in the transaction data in the past will result in a hash value of the block different from that before the change. To look the falsified block legitimate, all the blocks thereafter should be regenerated. This regeneration is very difficult in reality. Such properties ensure the difficulties in falsification of the blockchain.

FIG. 30is a diagram illustrating a data structure of the transaction data.

The transaction data illustrated inFIG. 30includes transaction body P1and electronic signature P2. Transaction body P1is a body of data included in the transaction data. Electronic signature P2is generated by signing on the hash value of transaction body P1with the signature key of the creator of the transaction data, more specifically, encrypting the hash value with the private key of the creator.

Because the transaction data has electronic signature P2, the falsification is substantially impossible. Thus, electronic signature P2prevents the falsification of the transaction body.

As described above, in the management method according to the present embodiment, the version series can be appropriately removed using the predetermined transaction data. Accordingly, the prevention in falsification of the information under management can be further facilitated while the removal of the version series is further implemented.

In the embodiments above, the components may be implemented as dedicated hardware, or may be implemented by executing software programs suitable for the components. The components each may be implemented by a program executer, such as a CPU or a processor, which reads and executes the software program recorded on a recording medium, such as a hard disk or a semiconductor memory. Here, the management apparatus and the like in the embodiments are implemented with the following software program.

That is, this program is a program causing a computer to execute a management method for software versions to be executed by a version management system. The version management system includes management apparatuses having distributed ledgers. The management method includes receiving, by a first management apparatus among the management apparatuses, transaction data from an apparatus connected through a network to the first management apparatus, the transaction data including first information on a first version of software, second information on a second version of the software subjected to version upgrade from the first version by a software developer, identification information of the software developer, and an electronic signature; validating, by the first management apparatus, legitimacy of the transaction data using the electronic signature included in the transaction data received; and storing, by each of the management apparatuses, the transaction data in a corresponding distributed ledger among the distributed ledgers when the transaction data is legitimate.

Although the management methods according to one or more aspects have been described based on the embodiments, these embodiments should not be construed as limitation to the present disclosure. A variety of modifications of the present embodiments conceived by persons skilled in the art and embodiments in combination with components in different embodiments may also be included in the scope of one or more aspects without departing from the gist of the present disclosure.

INDUSTRIAL APPLICABILITY

The present disclosure is a management method for software versions, and can be used in a management system which prevents falsification of information under management.