PROGRAM, INFORMATION PROCESSING METHOD AND INFORMATION PROCESSING APPARATUS

Abstract

To quickly check the presence of any correction applied.SOLUTION: A storage unit 11 stores management information 11a. The management information 11a indicates the size of a load module in each of a plurality of versions and the differential data of the load module of each of the plurality of versions with respect to an immediately preceding version. A first load module 20 is created by branching from any version of the load module based on that version, and does not correspond to any of the plurality of versions. Based on the size of the first load module 20 and the size of the load module in each of the plurality of versions, a processing unit 12 determines, from among the plurality of versions, a first version serving as a starting point for selecting a version to be compared with the first load module 20. The processing unit 12 traces the version to be compared from the first version in the forward or reverse direction and identifies, from among the plurality of versions, a branching source version for the first load module 20 depending on whether the differential data corresponding to the version to be compared is included in the first load module 20.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a program, an information processing method, and an information processing device. [Background technology]

[0002] Devices are used to manage load modules executed in computer systems. A load module is an executable program that is loaded into memory. Load modules are also called executable programs or execution programs. Load modules are modified by the load module vendor when adding functions or fixing defects. The modifications to the load module may be provided by the vendor to the user as correction data called a patch, for example. The version of the load module changes depending on the modifications. The version may also be called the version or generation.

[0003] For example, there has been a proposal for an execution program management device that, when a job is executed, compares the name, storage location, generation, size, and update date of various programs that are the subject of the job with the corresponding information in a program management information table that stores the latest status of each program.If any differences are detected as a result of the comparison, the proposed execution program management device notifies the operator.

[0004] There has also been a proposal for an update system that, when it detects an instruction received for an execution program, determines whether the execution program needs to be updated before the execution program executes the detected instruction, and updates the execution program if it determines that an update is necessary.

[0005] Furthermore, there has been proposed an electronic control device that determines whether or not difference data indicating the difference between old data and new data is consistent with a data storage area or with the stored data stored in the data storage area. If the proposed electronic control device determines that the consistency is correct, it uses the difference data and the stored data to restore update data, which is new data, and writes the restored update data to the data storage area, thereby appropriately rewriting the program using the difference data. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2000-172492 A [Patent Document 2] International Publication No. 2008 / 114454 [Patent Document 3] JP 2020-27634 A Summary of the Invention [Problem to be solved by the invention]

[0007] Patches provided by vendors often have conditions for the version of the load module to which the patch can be applied, so the version of the load module used in the user's system may be managed by the user's system.

[0008] However, the versions of load modules used in a user's system are not always managed appropriately. For example, a user's system may be operated by applying patches for individual customization or test versions provided to the load modules of the user's system. Such individually provided patches may not be managed as versions publicly provided by the vendor. In this case, the load modules of the user's system may contain unknown modifications that do not correspond to any of the versions managed by the vendor. For this reason, it may be difficult to determine after the fact to what extent the modifications of each version provided by the vendor have been applied to the load modules of the user's system.

[0009] For example, it is conceivable to compare all versions of a load module managed by a vendor with the load module of a user's system to identify modifications applied to the load module of the user's system. However, with this method, the time required for comparison increases as the number of versions increases.

[0010] In one aspect, the present invention has an object to provide a program, an information processing method, and an information processing device that quickly check whether or not a correction has been applied. [Means for solving the problem]

[0011] In one aspect, a program is provided that causes a computer to execute the following process: acquire management information indicating a size of a load module in each of the multiple versions and difference data for each of the multiple versions relative to a version immediately preceding the load module, determine a first version from among the multiple versions as a starting point for selecting a version to be compared with the first load module based on a first load module created based on a load module of one of the multiple versions by branching off from the load module and based on a size of the first load module that does not correspond to any of the multiple versions and the size of the load module in each of the multiple versions, trace the version to be compared from the first version in a forward or backward direction, and identify a version from among the multiple versions to be branched off from the first load module based on whether or not difference data corresponding to the version to be compared is included in the first load module.

[0012] Also, in one aspect, a method for processing information is provided. In one aspect, an information processing device is provided. Effect of the Invention

[0013] On the one hand, it allows you to quickly check whether a fix has been applied or not. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 is a diagram illustrating an information processing apparatus according to a first embodiment. [Diagram 2] FIG. 11 illustrates an example of an information processing system according to a second embodiment. [Diagram 3] FIG. 2 illustrates an example of hardware of a management server. [Figure 4]FIG. 2 is a diagram illustrating an example of functions of the information processing system. [Diagram 5] FIG. 13 is a diagram showing an example of a user LM. [Figure 6] FIG. 11 is a diagram showing an example of modification management information. [Figure 7] FIG. 13 is a diagram showing an example of difference data for LM correction. [Figure 8] FIG. 13 illustrates an example of a version management table. [Figure 9] FIG. 13 illustrates an example of a differential data management table. [Figure 10] FIG. 11 illustrates an example of processing by a management server. [Figure 11] FIG. 13 is a diagram illustrating an example of a PRE correction search process. [Figure 12] FIG. 13 is a diagram showing an example of a version (N) extraction process to be searched. [Figure 13] FIG. 13 is a diagram showing an example of version (N) extraction of a search target and PRE correction search. [Figure 14] FIG. 13 is a diagram showing examples of two patterns of extraction for N=Nsize. [Figure 15] FIG. 13 is a diagram showing an example of a PRE correction search for pattern P1. [Figure 16] FIG. 13 is a diagram showing an example of a PRE correction search for pattern P2. [Figure 17] FIG. 13 is a diagram showing an example of adding a branch number. [Figure 18] FIG. 13 illustrates an example of updating a version management table. [Figure 19] FIG. 13 illustrates an example of updating a differential data management table; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] The present embodiment will be described below with reference to the drawings. [First embodiment] A first embodiment will be described.

[0016] FIG. 1 is a diagram illustrating an information processing apparatus according to a first embodiment. The information processing device 10 supports management of versions of load modules used in a user's system. The information processing device 10 has a storage unit 11 and a processing unit 12. The storage unit 11 may be a volatile storage device such as a random access memory (RAM) or a non-volatile storage device such as a hard disk drive (HDD) or a flash memory. The processing unit 12 may include a central processing unit (CPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc. The processing unit 12 may be a processor that executes a program. The "processor" may include a collection of multiple processors (multiprocessor).

[0017] The storage unit 11 stores management information 11a. The management information 11a is information indicating the version of a load module provided by a vendor, the size of the load module in that version, and differential data of that version from the immediately preceding version. The differential data corresponds to the corrections made in the relevant version from the immediately preceding version. The size of the load module in the management information 11a is expressed as LM (Load Module) size.

[0018] For example, the management information 11a includes records of version "m", LM size "s(m)", and differential data "dat(m)". m is, for example, a numerical value. The (mi) version indicates a version that is i generations before the m version. i is a positive integer. The (m+i) version indicates a version that is i generations after the m version. The larger the version, the larger the LM size.

[0019] The processing unit 12 acquires management information 11a corresponding to a first load module 20 used in the user's system, and stores it in the storage unit 11. The first load module 20 is a load module currently used in the user's system. The first load module 20 was created by branching off a certain version of a load module, and includes unknown modifications that do not correspond to any version managed by the vendor. In other words, the first load module 20 does not correspond to any version managed by the management information 11a. It is unknown up to which version of modifications provided by the vendor have been applied to the first load module 20.

[0020] For example, the processing unit 12 may acquire the management information 11a by downloading the management information 11a from a server computer operated by a vendor. Note that the user's system that executes the first load module 20 or a device in the system is omitted in FIG.

[0021] The processing unit 12 determines a first version from among the multiple versions as a starting point for selecting a version to be compared with the first load module 20, based on the LM size of each of the multiple versions registered in the management information 11a and the size of the first load module 20. For example, the processing unit 12 may identify an LM size that is most similar to the size s(u) of the first load module 20 from among the LM sizes of each of the multiple versions, and determine the version corresponding to the LM size as the first version. Alternatively, the processing unit 12 may identify an LM size that is most similar to the size s(u) of the first load module 20 from among the LM sizes of each of the multiple versions, and determine a version that is a predetermined generation before or after the version corresponding to the LM size as the first version. The predetermined generation may be one generation, two generations, etc.

[0022] The processing unit 12 traces the version to be compared from the first version in a forward or backward direction, and identifies, among the multiple versions, the version from which the first load module 20 branches, depending on whether or not the first load module 20 contains differential data corresponding to the version to be compared.

[0023] For example, the processing unit 12 determines the mth version as the first version. In this case, the processing unit 12 obtains the mth version difference data dat(m) from the management information 11a. Then, the processing unit 12 determines whether the difference data dat(m) is included in the first load module 20.

[0024] When the differential data dat(m) is included in the first load module 20, the processing unit 12 selects the versions to be compared in a forward order starting from the mth version. The forward order is a direction in which newer versions are traced one by one starting from the mth version, such as the (m+1)th version, the (m+2)th version, .... In this case, the processing unit 12 traces the versions in the forward order, such as the (m+1)th version, the (m+2)th version, ..., and determines whether the differential data of the relevant version is included in the first load module 20. Then, when the processing unit 12 first determines that the differential data of a certain version (the kth version) is not included in the first load module 20, it identifies the version immediately before that version (the (k-1)th version) as the version from which the first load module 20 is to be branched.

[0025] If the differential data dat(m) is not included in the first load module 20, the processing unit 12 selects the versions to be compared in the reverse order, starting from version m. The reverse order is the direction of tracing older versions one by one, starting from version m, such as version (m-1), version (m-2), .... In this case, the processing unit 12 traces the versions in the reverse order, such as version (m-1), version (m-2), ..., and determines whether the differential data of the relevant version is included in the first load module 20. Then, when the processing unit 12 first determines that differential data of a certain version (version k) is included in the first load module 20, it identifies that version (version k) as the version from which the first load module 20 will branch.

[0026] In this manner, the processing unit 12 identifies the version of the branch source for the first load module 20. For example, the processing unit 12 may store the version of the branch source identified for the first load module 20 in the storage unit 11. In addition, the processing unit 12 may notify the version of the branch source identified for the first load module 20 to a user or vendor's server computer.

[0027] According to the information processing device 10, management information 11a is acquired that indicates the size of the load module in each of the multiple versions and the difference data of each of the multiple versions with respect to the version immediately preceding the load module. Based on the size of the first load module 20 and the size of the load module in each of the multiple versions, a first version is determined as a starting point for selecting a version to be compared with the first load module 20 from among the multiple versions. The first load module is created by branching from a load module of one of the multiple versions based on the load module of that version, and does not correspond to any of the multiple versions. The version to be compared is traced forward or backward from the first version, and a version from which the first load module is to be branched from among the multiple versions is identified depending on whether the difference data corresponding to the version to be compared is included in the first load module.

[0028] This allows you to quickly check whether or not the correction has been applied. Here, patches provided by vendors often have conditions for the version of the load module to which the patch can be applied. This is because patches are created on the assumption that they will be applied to an existing version of LM. Therefore, the version of the load module used in the user's system may be managed by the user's system.

[0029] However, the versions of load modules used in a user's system are not always managed appropriately. For example, a user's system may be operated by applying patches for individual customization or test versions provided to the user to the load modules of the user's system. Such individually provided patches may not be managed as versions publicly provided by the vendor.

[0030] In this case, the load module of the user's system, i.e., first load module 20, will include an unknown correction that does not correspond to any version in management information 11a, which may make it difficult to determine after the fact to what extent the correction contents of each version provided by the vendor have been applied to first load module 20.

[0031] For example, it is conceivable that the information processing device 10 compares all versions of load modules managed by a vendor with the first load module 20 to identify modifications applied to the first load module 20. However, with this method, the more versions there are, the more time it takes to make the comparison.

[0032] Therefore, the processing unit 12 traces the comparison target version from the first version in a forward or backward direction, and determines whether or not difference data corresponding to the comparison target version is included in the first load module 20. The processing unit 12 identifies the branch source version for the first load module 20 in accordance with the determination, thereby enabling the processing unit 12 to appropriately obtain the branch source version. Then, the processing unit 12 can determine that modifications prior to the branch source version have been applied to the first load module 20. In this way, the processing unit 12 can efficiently check whether or not modifications have been applied to the first load module 20.

[0033] In particular, the size of a load module tends to be larger as the version is newer. Therefore, the processing unit 12 can identify a load module of a version that is estimated to be relatively similar to the first load module 20 based on the LM size of each of the multiple versions and the size of the first load module 20. Therefore, the processing unit 12 can limit the search range of the branch source version for the first load module 20 to a relatively small range starting from the first version by determining the first version based on the LM size of each of the multiple versions and the size of the first load module 20. As a result, the processing unit 12 can check whether each version of the first load module 20 has been applied in a short time. For example, the processing unit 12 can shorten the time required to check whether a correction has been applied compared to comparing all versions of load modules with the first load module 20.

[0034] In the following, the functions of the information processing device 10 will be described in further detail using a more specific example. [Second embodiment] Next, a second embodiment will be described.

[0035] FIG. 2 illustrates an example of an information processing system according to the second embodiment. The information processing system of the second embodiment includes a management server 100, a user system 200, and a vendor server 300. The management server 100 and the user system 200 are connected to a network 50. The network 50 is, for example, a local area network (LAN) operated by a user. The network 50 and the vendor server 300 are connected to a network 60. The network 60 is a wide area network (WAN) or the Internet.

[0036] The management server 100 is a server computer that assists in managing versions of load modules executed in the user system 200. The management server 100 is an example of the information processing device 10 of the first embodiment. A load module is written as LM. Also, an LM executed in the user system 200 is written as user LM.

[0037] The user system 200 is a computer system that executes the user LM. The user system 200 may be a mainframe or a server computer. The user system 200 has a modification management function that manages patch application to the user LM, and holds modification management information related to the user LM. However, the modification management information may not correctly reflect the modifications that have actually been applied to the user LM.

[0038] The vendor server 300 is a server computer operated by the vendor that provides the LM. The vendor server 300 holds version management information. The version management information is information related to the version of the LM that corresponds to a patch publicly provided by the vendor. The vendor server 300 makes the version management information available to multiple users of the LM via the network 60. For example, although only the user system 200 of a certain user is illustrated in FIG. 2, the user systems of other users can also access the version management information of the vendor server 300 via the network 60.

[0039] Here, a patch that can be applied to the user LM in the user system 200 may be a patch publicly distributed from the vendor server 300, or a patch individually provided by the vendor to the user system 200. Patches individually provided by the vendor to the user system 200 include, for example, test version patches and patches for individually customizing the user system 200. When an individually provided patch is applied to the user LM, the correction made by the patch may be an unknown correction that is not managed in the version management information of the vendor server 300, i.e., an unknown correction. On the other hand, a correction that is managed in the version management information of the vendor server 300 is a known correction, i.e., a known correction.

[0040] FIG. 3 illustrates an example of hardware of the management server. The management server 100 includes a CPU 101, a RAM 102, a HDD 103, a GPU (Graphics Processing Unit) 104, an input interface 105, a media reader 106, and a NIC (Network Interface Card) 107. The CPU 101 is an example of the processing unit 12 of the first embodiment. The RAM 102 or the HDD 103 is an example of the storage unit 11 of the first embodiment.

[0041] CPU 101 is a processor that executes program instructions. CPU 101 loads at least a part of the programs and data stored in HDD 103 into RAM 102 and executes the programs. CPU 101 may include multiple processor cores. Also, management server 100 may have multiple processors. The processes described below may be executed in parallel using multiple processors or processor cores. Also, a set of multiple processors may be called a "multiprocessor" or simply a "processor."

[0042] The RAM 102 is a volatile semiconductor memory that temporarily stores programs executed by the CPU 101 and data used in calculations by the CPU 101. The management server 100 may include a type of memory other than a RAM, and may include multiple memories.

[0043] The HDD 103 is a non-volatile storage device that stores software programs such as an OS (Operating System), middleware, and application software, as well as data. The management server 100 may also include other types of storage devices, such as a flash memory or an SSD (Solid State Drive), or may include multiple non-volatile storage devices.

[0044] The GPU 104 outputs an image to a display 51 connected to the management server 100 in accordance with an instruction from the CPU 101. As the display 51, any type of display can be used, such as a CRT (Cathode Ray Tube) display, a liquid crystal display (LCD: Liquid Crystal Display), a plasma display, or an organic EL (OEL: Organic Electro-Luminescence) display.

[0045] The input interface 105 acquires an input signal from an input device 52 connected to the management server 100, and outputs the signal to the CPU 101. The input device 52 may be a pointing device such as a mouse, a touch panel, a touch pad, or a trackball, a keyboard, a remote controller, or a button switch. In addition, a plurality of types of input devices may be connected to the management server 100.

[0046] The medium reader 106 is a reading device that reads programs and data recorded on the recording medium 53. For example, a magnetic disk, an optical disk, a magneto-optical disk (MO: Magneto-Optical disk), a semiconductor memory, etc. can be used as the recording medium 53. The magnetic disk includes a flexible disk (FD: Flexible Disk) and a HDD. The optical disk includes a compact disc (CD) and a digital versatile disc (DVD).

[0047] The medium reader 106 copies, for example, the program or data read from the recording medium 53 to another recording medium such as the RAM 102 or the HDD 103. The read program is executed, for example, by the CPU 101. Note that the recording medium 53 may be a portable recording medium, and may be used for distributing the program or data. The recording medium 53 and the HDD 103 may also be referred to as computer-readable recording media.

[0048] The NIC 107 is an interface that is connected to the network 50 and communicates with other computers via the network 50. The NIC 107 is connected to a communication device such as a switch or a router via a cable. The NIC 107 may be an interface that performs wireless communication.

[0049] The user system 200 and the vendor server 300 are realized by the same hardware as the management server 100 . FIG. 4 is a diagram illustrating an example of functions of the information processing system.

[0050] The management server 100 includes a storage unit 110, a correction verification unit 120, and an original correction search unit 130. The storage unit 110 uses the storage areas of a RAM 102 and a HDD 103. The CPU 101 executes a program stored in the RAM 102 to thereby realize the functions of the correction verification unit 120 and the original correction search unit 130.

[0051] The user system 200 includes a storage unit 210. A storage area of ​​a storage device such as a HDD included in the user system 200 is used for the storage unit 210. The storage unit 210 stores a user LM 211. For example, the user LM 211 is loaded into a RAM included in the user system 200 and executed by a CPU included in the user system 200.

[0052] The vendor server 300 has an LM management DB 310 and a modification management DB 320. DB is an abbreviation for database. The LM management DB 310 and the modification management DB 320 are stored in a storage device such as a HDD provided in the vendor server 300. Although not shown in the figure, the vendor server 300 has a function of transmitting information held in the LM management DB 310 and information held in the modification management DB 320 to the management server 100.

[0053] The LM management DB 310 includes LM hash value information 311 and LM program code information 312 . The LM hash value information 311 is data that holds a hash value corresponding to each version of the LM provided by the vendor. The hash value is obtained by inputting the body of the LM, i.e., the program code of the LM, into a predetermined hash function.

[0054] The LM program code information 312 is data that holds the program code of each version of the LM managed by the vendor. The revision management DB 320 includes a version management table 321 and a differential data management table 322 .

[0055] The version management table 321 is a table that holds information about the version of the LM provided by the vendor. The differential data management table 322 is a table that holds, for each version of LM, information on differential data with respect to the version immediately preceding that version.

[0056] The storage unit 110 holds the user LM 211 acquired from the user system 200. The storage unit 110 also holds information acquired from the vendor server 300. The modification verification unit 120 acquires the LM hash value information 311 from the LM management DB 310, and compares the hash value of each version with the hash value of the user LM 211. By comparing the hash values, the modification verification unit 120 checks whether the modification management information managed by the user LM 211 is correct, and determines whether the user LM 211 includes unknown modifications.

[0057] If the user LM211 does not include an unknown modification, the modification verification unit 120 corrects the modification management information held in the user system 200 according to the comparison result of the hash value. If the user LM211 includes an unknown modification, the modification verification unit 120 causes the original modification search unit 130 to search for the original version of the modification by the user LM211.

[0058] The modification source search unit 130 acquires the version management table 321 and the differential data management table 322 from the modification management DB 320, and identifies the modification source version of the user LM 211 that includes the unknown modification by determining whether or not the differential data of each version is included in the user LM 211. The modification source search unit 130 notifies the vendor server 300 of the modification source version identified for the user LM 211. The user LM 211 is an LM created by branching from the modification source version managed by the vendor. Therefore, the modification source version can be said to be the branch source version for the user LM 211. The modification of the version before the modification source version among the versions managed by the vendor is applied to the user LM 211. Hereinafter, the modification corresponding to the modification source version is expressed as "PRE modification".

[0059] FIG. 5 is a diagram showing an example of a user LM. The user LM211 is generated by combining the submodules SM1, SM2, SM3, SM4, and SM5. Therefore, the user LM211 has the submodules SM1, SM2, SM3, SM4, and SM5. For example, a new submodule after modification of an old submodule corresponds to a patch. A patch is applied to the user LM211 by changing some of the submodules included in the user LM211 to new submodules.

[0060] In addition, the user LM 211 has LM combination information 211a. The LM combination information 211a includes the date on which the sub-modules SM1 to SM5 were combined to generate the user LM 211, that is, the LM combination date. The LM combination date is the date on which the user LM 211 was last modified by applying a patch.

[0061] FIG. 6 is a diagram showing an example of the modification management information. The revision management information 212 is stored in the storage unit 210. The revision management information 212 indicates the latest revision number among the revision numbers that have been applied to the product name of the software currently being used in the user system 200. The revision management information 212 may have a history of revision numbers that have been applied to the corresponding software product. The revision number of the software is represented by a combination of a character string such as "AD" that specifies the type of revision, etc., and a number that identifies the patch that has been applied to the software. For example, the revision number "AD11122" is registered in the revision management information 212 for the product name "ZZZZZZZ".

[0062] Next, for a software product identified by the product name "ZZZZZZZ", differential data that occurs between versions in response to LM modifications will be described. FIG. 7 is a diagram showing an example of difference data for LM correction.

[0063] LM401 is the first version, that is, version 1. The version increases when a patch is applied to LM401. As the version increases, the size of the LM tends to become larger. LM446 is version 46-0. LM447 is version 47-0. Note that the "-0" part of "version 46-0" indicates the branch number. In what follows, versions with branch number "0", such as "version 46-0", will be abbreviated as "version 46".

[0064] In LM446, correction A has been applied to LM version 45, which is the previous version. The start of the part corresponding to correction A in LM446 is the position indicated by the address "+0170" relative to the start address of LM446. Correction A corresponds to the differential data with respect to LM version 45.

[0065] In LM447, correction B has been applied to LM version 46, which is the previous version. The start of the part corresponding to correction B in LM447 is the position indicated by the address "+0112" relative to the start address of LM447. Correction B corresponds to the differential data with respect to LM version 46.

[0066] Next, a data structure that the vendor server 300 uses to manage the versions LM401, . . . , 446, 447, . . . and the differential data in each version will be illustrated. FIG. 8 is a diagram illustrating an example of a version management table.

[0067] The version management table 321 is stored in the revision management DB 320. The version management table 321 includes the following items: version, branch number, LM combination date, LM size, and differential data storage location. The version field registers the version. The branch number field registers the branch number. The LM merging date field registers the LM merging date. The LM size field registers the LM size of the version. The LM size is, for example, in Mbytes. The differential data storage location field registers storage location information of the differential data for the immediately preceding version. The storage location information is a pointer that indicates the location on the differential data management table 322 where the differential data is stored.

[0068] For example, a record of version "46," branch number "0," LM merge date "2011.09.xx," LM size "1.42," and differential data storage location "Revision A differential data storage location information" is registered in version management table 321. This record indicates that the LM merge date for version 46 is September xx, 2011, the LM size is 1.42 Mbytes, and the storage location of the differential data is the location indicated in the "Revision A differential data storage location information."

[0069] In the version management table 321, records for each version of the software product from version 1 onwards are registered. FIG. 9 illustrates an example of a differential data management table.

[0070] The differential data management table 322 is stored in the revision management DB 320. The differential data management table 322 includes items such as version, branch number, revision number, address of revision location, length, revision type, pre-revision data, and post-revision data.

[0071] In the version field, the version is registered. In the branch number field, the branch number is registered. In the revision number field, the revision number is registered. In the revision address field, the address indicating the beginning of the revision in the LM of the relevant version is registered. Multiple revision addresses may be registered for one revision number. In the length field, the size of the revision is registered. The unit of length is, for example, bytes. In the revision type field, the revision type is registered. The revision types include "change" and "addition". "Change" indicates that the pre-revision data in the revision in the immediately preceding version is rewritten with the post-revision data. "Addition" indicates that the post-revision data is added to the end of the immediately preceding version. In the pre-revision data field, when the revision type is "change", the pre-revision data that was originally present in the revision is registered. In the pre-revision data field, when the revision type is "addition", no setting is made. In the figure, no setting is represented by a hyphen symbol (-). The post-correction data item is the post-correction data added to the corrected portion. The post-correction data corresponds to the main body of the difference data for the previous version.

[0072] For example, the differential data management table 322 has a record registered with the following: version "46", branch number "0", revision number "ADxxxxx", revision location address "0170", length "4", revision type "change", pre-revised data "95B1700A", and post-revised data "47F0A0E4". This record indicates that the revision number corresponding to version 46 is "ADxxxxx", the revision location address is "0170", the revision location size is 4 bytes, and the revision type is "change". This record also indicates that in version 46, the pre-revised data "95B1700A" at the revision location has been changed to post-revised data "47F0A0E4". Records of revision details at revision location addresses "0174" and "0178" are also registered for revision number "ADxxxxx".

[0073] In the differential data management table 322, differential data for each version subsequent to the first version of the software product in question is registered. Furthermore, the version management table 321 and the differential data management table 322 are stored in the revision management DB 320 for each software product to be managed by the vendor. For example, the version management table 321 and the differential data management table 322 are information on a software product with a product name "ZZZZZZZ". Furthermore, for example, the user LM211 corresponds to the product name "ZZZZZZZ".

[0074] Here, the user LM 211 may not correctly correspond to the revision number managed in the differential data management table 322 and the LM of the version indicated by the revision number. For example, even if the revision number of the user LM 211 in the revision management information 212 matches the revision number in the differential data management table 322, the user LM 211 and the LM held by the vendor for the revision number may differ. Alternatively, a revision number present in the revision management information 212 may not exist in the differential data management table 322. This is because, in the user system 200, as described above, the user LM may be updated by an individual patch provided individually to each user, and the revision number for the individual patch may not be properly reflected in the vendor's revision management DB 320.

[0075] Therefore, the management server 100 identifies up to which revision version the user LM 211 has been applied, and notifies the vendor server 300 of the same, by the following procedure. FIG. 10 illustrates an example of processing by the management server.

[0076] (S10) The modification verification unit 120 accepts designation of the user LM 211 to be verified by the user. The modification verification unit 120 acquires the main body of the user LM 211, i.e., the program code of the user LM 211 and the latest modification number among the modification numbers already applied to the user LM 211, from the user system 200. The modification number of the user LM 211 is registered in the modification management information 212. The program code of the user LM 211 is converted into a hash value H1 using a predetermined hash function. This hash function is the same as the hash function used by the vendor server 300 when calculating a hash value for the LM.

[0077] (S11) The modification verification unit 120 obtains a hash value H2 corresponding to the modification number of the user LM 211 from the vendor server 300. The hash value H2 is registered in the LM hash value information 311 in the LM management DB 310 of the vendor server 300. Note that a hash value corresponding to the modification number of the user LM 211 may not be registered in the LM hash value information 311. In this case, the modification verification unit 120 cannot obtain the hash value H2 corresponding to the modification number of the user LM 211 from the vendor server 300, so it skips step S12 and proceeds to step S14.

[0078] (S12) The correction verification unit 120 determines whether the hash value H1 is equal to the hash value H2, i.e., whether H1=H2. If H1=H2, the correction verification unit 120 proceeds to step S13. If H1≠H2, the correction verification unit 120 proceeds to step S14.

[0079] (S13) The correction verification section 120 determines that the correction management information 212 of the user system 200 is correct. Then, the processing of the management server 100 ends. (S14) The correction verification unit 120 determines whether or not there is another correction number corresponding to the hash value H1 in the LM hash value information 311 of the LM management DB 310. If there is no other correction number corresponding to the hash value H1, the correction verification unit 120 proceeds to step S15. If there is another correction number corresponding to the hash value H1, the correction verification unit 120 proceeds to step S17.

[0080] (S15) The modification verification unit 120 detects that the user LM 211 includes an unknown modification. The modification verification unit 120 causes the modification source search unit 130 to start a PRE modification search for the user LM 211.

[0081] (S16) The modification source search unit 130 acquires the version management table 321 and the differential data management table 322 in the modification management DB 320 from the vendor server 300, and stores them in the memory unit 110. Then, the modification source search unit 130 executes a pre-modification search process based on the version management table 321 and the differential data management table 322. The details of the pre-modification search process will be described later. Then, the processing of the management server 100 ends.

[0082] (S17) The modification verification unit 120 detects that the user LM 211 does not include an unknown modification, but only a known modification. (S18) The modification verification unit 120 obtains the modification number corresponding to the hash value H1 from the vendor server 300, and corrects the modification number of the user LM 211 in the modification management information 212 to the modification number obtained from the vendor server 300. Then, the processing of the management server 100 ends.

[0083] FIG. 11 is a diagram illustrating an example of the PRE correction search process. The PRE correction search process corresponds to step S16. (S20) The original revision search unit 130 extracts a version (N) to be searched. For example, the original revision search unit 130 may select, among the versions included in the version management table 321, a version whose LM size corresponding to the version is equal to or smaller than the size of the user LM 211 and is closest to the size of the user LM 211 as the version (N) to be searched. Details of the process of extracting the version (N) to be searched will be described later.

[0084] (S21) The original modification search unit 130 obtains the Nth version of the LM from the vendor server 300. The main body of the Nth version of the LM is stored in the LM program code information 312 of the LM management DB 310. The original modification search unit 130 compares the entire Nth version of the LM with the entire user LM 211. The original modification search unit 130 can use, for example, a diff command for the comparison.

[0085] (S22) Based on the comparison in step S21, the original modification search unit 130 extracts difference data of the user LM 211 with respect to the Nth version of the LM. The difference data extracted in step S22 is referred to as diff data. The diff data includes address positions in the user LM 211 where data differs from the Nth version of the LM, and the data of the user LM 211 at the address positions.

[0086] (S23) The modification source search unit 130 determines whether or not the user LM211 has any modifications imported in the (N+1) version, based on the version management table 321 and the differential data management table 322. The modifications imported in the (N+1) version correspond to the modified data of the (N+1) version in the differential data management table 322. If the user LM211 has any modifications imported in the (N+1) version, the modification source search unit 130 proceeds to step S24. If the user LM211 has no modifications imported in the (N+1) version, the modification source search unit 130 proceeds to step S26.

[0087] For example, the original modification search unit 130 acquires differential data (modified data) corresponding to the (N+1) version based on the version management table 321 and the differential data management table 322. The original modification search unit 130 then performs the judgment in step S23 by judging whether or not the address corresponding to the modified data of the (N+1) version is present in the diff data acquired in step S22. If the modified data of the (N+1) version is not present in the diff data for that address, it means that the user LM211 has not imported the modification in the (N+1) version. On the other hand, if the modified data of the (N+1) version is present in the diff data for that address, it means that the user LM211 has imported the modification in the (N+1) version. Here, the (N+1) version in step S23 is an example of the first version in the first embodiment.

[0088] (S24) The pre-editing search unit 130 sets N=N+1. That is, the pre-editing search unit 130 substitutes N+1 for N. (S25) The original modification search unit 130 judges whether or not the user LM211 has any modifications imported in the (N+1) version, based on the version management table 321 and the differential data management table 322. If the user LM211 has any modifications imported in the (N+1) version, the original modification search unit 130 proceeds to step S24. If the user LM211 has no modifications imported in the (N+1) version, the original modification search unit 130 proceeds to step S28. The judgment method in step S25 is the same as in step S23.

[0089] (S26) The original modification search unit 130 determines whether or not the user LM 211 has any modifications imported in the Nth version. The modifications imported in the Nth version correspond to the modified data of the Nth version in the differential data management table 322. If the user LM 211 has any modifications imported in the Nth version, the original modification search unit 130 proceeds to step S28. If the user LM 211 has no modifications imported in the Nth version, the original modification search unit 130 proceeds to step S27.

[0090] For example, the original modification search unit 130 acquires an address of the differential data (modified data) corresponding to the Nth version based on the version management table 321 and the differential data management table 322. The original modification search unit 130 then performs the judgment in step S26 by judging whether or not there is any data at the address corresponding to the Nth version of the modified data in the diff data acquired in step S22. If there is no data at that address in the diff data, it means that there is a modification imported in the Nth version by the user LM 211. On the other hand, if there is any data at that address in the diff data, it means that there is no modification imported in the Nth version by the user LM 211. Note that if there is any data at that address in the diff data, the data is different from the Nth version of the modified data.

[0091] (S27) The pre-editing search unit 130 sets N=N-1. That is, the pre-editing search unit 130 substitutes N-1 for N. Then, the process proceeds to step S26. (S28) The original modification search unit 130 confirms the PRE modification to be version N. The original modification search unit 130 notifies the vendor server 300 that the PRE modification for the user LM 211 is version N. Then, the original modification search unit 130 ends the PRE modification search process.

[0092] The N version of the PRE modification confirmed in step S28 is the version of the branch source for the user LM 211. For example, the modification source search unit 130 may extract differential data for the N version of LM, which is the PRE modification version, from the user LM 211 and notify the vendor server 300 of the differential data. The vendor server 300 assigns a branch number to the N version acquired from the modification source search unit 130, associates the differential data with the branch number, issues a new modification number, registers the new modification number in the modification management DB 320, and notifies the management server 100. The management server 100 registers the new modification number notified from the vendor server 300 in the modification management information 212 of the user system 200. As a result, the vendor server 300 can assign a new modification number corresponding to the unknown modification in the user LM 211, and reflect the modification number in the user system 200. As a result, the version of the user LM 211 is appropriately managed in the user system 200 and the vendor server 300.

[0093] FIG. 12 is a diagram showing an example of a version (N) extraction process to be searched. The process of extracting the version (N) to be searched corresponds to step S20. (S30) The original modification search unit 130 acquires the LM combination date Du of the user LM 211.

[0094] (S31) The original modification search unit 130 sets the final version number Nmax to the variable N_limit. That is, the original modification search unit 130 sets N_limit=Nmax. The final version number Nmax corresponds to the latest version in the version management table 321.

[0095] (S32) The original modification search unit 130 obtains the LM combination date Dn of the N_limit version from the version management table 321. (S33) The original correction search unit 130 judges whether the LM combination date Dn is newer than the LM combination date Du. If the LM combination date Dn is newer than the LM combination date Du, the original correction search unit 130 advances the process to step S34. If the LM combination date Dn is earlier than the LM combination date Du, the original correction search unit 130 advances the process to step S35.

[0096] (S34) The correction source search unit 130 sets N_limit = N_limit - 1. That is, the correction source search unit 130 substitutes N_limit - 1 into N_limit. Then, the correction source search unit 130 proceeds to step S32 for processing.

[0097] (S35) The correction source search unit 130 determines N_limit to the current value. (S36) The correction source search unit 130 obtains the size Su of the user LM211. (S37) The correction source search unit 130 sets N = N_limit. That is, the correction source search unit 130 substitutes N_limit into N.

[0098] (S38) The correction source search unit 130 obtains the LM size Sn of the Nth version from the version management table 321. (S39) The correction source search unit 130 determines whether Su is greater than or equal to Sn, that is, whether Su ≥ Sn. If Su < Sn, the correction source search unit 130 proceeds to step S40 for processing. If Su ≥ Sn, the correction source search unit 130 proceeds to step S41 for processing.

[0099] (S40) The correction source search unit 130 sets N = N - 1. That is, the correction source search unit 130 substitutes N - 1 into N. Then, the correction source search unit 130 proceeds to step S38 for processing.

[0100] (S41) The correction source search unit 130 determines N as the version to be searched. Then, the correction source search unit 130 ends the extraction process of the version to be searched (N). In this way, the correction source search unit 130 may narrow down the version to be compared in the version management table 321 based on the LM combination date Dn of each version, and then compare the LM size of the version with the size of the user LM211. That is, based on the LM combination date, the correction source search unit 130 can quickly determine the version to be searched (N) and the (N + 1)th version based on N by excluding in advance, from all versions, the versions that are clearly not applicable to the user LM211.

[0101] The N_limit version is a version having a LM combination date that does not exceed the LM combination date of the user LM 211 and is closest to the LM combination date of the user LM 211. Since the revisions provided to the user are created based on the LM provided previously, revisions (unknown revisions) based on the LM of a version N_limit+1 or later are not provided to the user. For this reason, revisions incorporated in versions N_limit+1 or later do not exist in the user LM 211. Therefore, for example, when N=N_limit+1 is reached in step S25, the revision source search unit 130 determines "No" in step S25, and determines the version of the PRE revision as N_limit in step S28.

[0102] FIG. 13 is a diagram showing an example of version (N) extraction of a search target and PRE correction search. 13 shows an example in which management server 100 identifies branch destination versions for user LM211 for software products LM401, ..., 445, 446, 447, ..., 453, 454, ..., 480, whose latest version is version 80. LM445 is version 45. LM453 is version 53. LM454 is version 54. LM480 is version 80. Other versions of LM are omitted in FIG. 13.

[0103] First, the original modification search unit 130 obtains the LM combination date Du="2019.12.xx" of the user LM211. For example, the original modification search unit 130 compares the LM combination date Dn of each version with Du going back from the 80th version, and identifies LM454 that has the LM combination date Dn that is earlier than Du and closest to Du. For example, the original modification search unit 130 sets N_limit=54.

[0104] Here, graph 500 shows the LM sizes of LM401 to LM480. The horizontal axis of graph 500 is the LM version number. The vertical axis of graph 500 is the LM size. The LM sizes of LM401 to LM480 tend to be larger for newer versions.

[0105] Next, the original search unit 130 obtains the size Su of the user LM 211. For example, the original search unit 130 compares the LM size Sn of each version with Su, going back from version 54, and identifies the LM 446 having an LM size Sn equal to or smaller than Su and closest to Su. That is, the original search unit 130 sets N=Nsize=46. Here, Nsize is the version corresponding to the LM size Sn equal to or smaller than Su and closest to Su.

[0106] The modification source search unit 130 traces the versions in the forward or backward direction starting from the version N=Nsize+1, and identifies the version from which the user LM 211 branches depending on whether the user LM 211 has differential data for each version.

[0107] Specifically, if differential data of the version N=Nsize+1 exists in the user LM 211, the original modification search unit 130 traces the versions forward. In this case, if the user LM 211 has differential data for each version, the original modification search unit 130 updates N to N=N+1, and searches the user LM 211 for differential data of the (N+1) version, which is one generation newer than the updated N version. Then, when it is first determined that the (N+1) version differential data does not exist in the user LM 211, the original modification search unit 130 sets the branch source version, i.e., the version of the PRE modification, as N.

[0108] On the other hand, if the difference data of the version N=Nsize+1 does not exist in the user LM 211, the original modification search unit 130 traces the versions backwards. In this case, if the difference data for each version does not exist in the user LM 211, the original modification search unit 130 updates N to N=N-1, and searches the user LM 211 for the difference data of the Nth version after the update. Then, when it is first determined that the difference data of the Nth version exists in the user LM 211, the original modification search unit 130 sets the branch source version, i.e., the version of the PRE modification, as N.

[0109] Next, a specific example of a search for a PRE modified version by the original modification search unit 130 will be described. First, two patterns of extraction of N=Nsize will be illustrated. FIG. 14 is a diagram showing examples of two patterns of extraction for N=Nsize.

[0110] In FIG. 14, LM401, ..., 446, 447, 448, 449 and user LM211 are illustrated. LM448 is the 48th edition. LM449 is the 49th edition. LM446 includes revision A as a difference from the immediately preceding LM version 45. LM447 includes revision B as a difference from the immediately preceding LM version 46, LM446. LM448 includes revision C as a difference from the immediately preceding LM version 47, LM447. LM449 includes revision D as a difference from the immediately preceding LM version 48, LM448. Also, user LM211 includes differential data corresponding to revision A of version 46 and an unknown revision, but does not include differential data corresponding to revisions after version 47. For example, the unknown revision exists in an address range after the address range in which the differential data of revision A of user LM211 exists. However, the management server 100 does not detect that user LM211 includes data corresponding to revision A at the initial stage.

[0111] In this case, as a first example, a case where the original modification search unit 130 determines Nsize=46 is defined as pattern P1. As a second example, a case where the original modification search unit 130 determines Nsize=47 is defined as pattern P2. First, pattern P1 will be described.

[0112] FIG. 15 shows an example of a PRE correction search for pattern P1. In pattern P1, the initial N is N=Nsize=46. First, the modification source search unit 130 compares LM446 with user LM211, and detects diff data that is the difference of user LM211 with respect to LM446. Here, user LM211 includes modification A. That is, data related to modification A is common data that exists in both users LM211 and LM446. Therefore, the difference related to modification A is not detected, and the diff data does not include the difference related to modification A.

[0113] Next, the original search unit 130 sets N=N+1=46+1=47. Then, the original search unit 130 judges whether or not the difference data corresponding to the 47th version of LM447, i.e., the post-correction data related to correction B, is included in the user LM211. As described above, the post-correction data related to correction B has not been imported into the user LM211. Therefore, the original search unit 130 does not detect the post-correction data of correction B in the diff data. Therefore, the original search unit 130 judges that the post-correction data related to correction B is not included in the user LM211.

[0114] Then, the original modification search unit 130 decides to trace the versions in the reverse direction. Then, the original modification search unit 130 determines that N=N-1=47-1=46. The original modification search unit 130 judges whether or not the difference data corresponding to the 46th version of LM446, that is, the post-modification data related to modification A, is included in the user LM211. As described above, the post-modification data related to modification A has already been imported into the user LM211. Therefore, the original modification search unit 130 does not detect data at the address position related to modification A in the diff data. Therefore, the original modification search unit 130 judges that the post-modification data related to modification A is included in the user LM211.

[0115] At this point, since the import status has switched between revision B and revision A in the user LM 211, version 46 becomes a branching point for determining whether to perform a pre-revision. Therefore, the original revision search unit 130 determines version 46 as the pre-revision, that is, the original revision, for the user LM 211.

[0116] Next, pattern P2 will be described. FIG. 16 is a diagram showing an example of a PRE correction search for pattern P2. In pattern P2, the initial N is N=Nsize=47. First, the modification source search unit 130 compares LM447 with user LM211, and detects diff data that is the difference of user LM211 with respect to LM447. Here, user LM211 includes modification A. That is, data related to modification A is common data that exists in both users LM211 and LM446. Therefore, the difference related to modification A is not detected, and the diff data does not include the difference related to modification A. On the other hand, user LM211 does not include modifications B and C. Therefore, the diff data includes the differences corresponding to modifications B and C.

[0117] Next, the original search unit 130 sets N=N+1=47+1=48. Then, the original search unit 130 judges whether or not the difference data corresponding to the 48th version of LM448, that is, the post-correction data related to correction C, is included in the user LM211. As described above, the post-correction data related to correction C has not been imported into the user LM211. Therefore, the original search unit 130 does not detect the post-correction data of correction C in the diff data. Therefore, the original search unit 130 judges that the post-correction data related to correction C is not included in the user LM211.

[0118] Then, the original search unit 130 decides to trace the versions in the reverse direction. Then, the original search unit 130 determines that N=N-1=48-1=47. The original search unit 130 judges whether the difference data corresponding to the 47th version of LM447, that is, the post-correction data related to correction B, is included in the user LM211. As described above, the post-correction data related to correction B has not been imported into the user LM211. Therefore, the original search unit 130 detects data different from the post-correction data of correction B at the address position related to correction B in the diff data. That is, the original search unit 130 does not detect the post-correction data of correction B in the diff data. Therefore, the original search unit 130 judges that the post-correction data related to correction B is not included in the user LM211.

[0119] Next, the original search unit 130 sets N=N-1=46. Then, the original search unit 130 judges whether or not the difference data corresponding to the 46th version of LM446, that is, the post-correction data related to correction A, is included in the user LM211. As described above, the post-correction data related to correction A has already been imported into the user LM211. Therefore, the original search unit 130 does not detect data at the address position related to correction A in the diff data. Therefore, the original search unit 130 judges that the post-correction data related to correction A is included in the user LM211.

[0120] At this point, since the import status has switched between revision B and revision A in the user LM 211, version 46 becomes a branching point for determining whether to perform a pre-revision. Therefore, the original revision search unit 130 determines version 46 as the pre-revision, that is, the original revision, for the user LM 211.

[0121] In this way, when the modification source search unit 130 identifies the version of the PRE modification, it is possible to obtain the difference data corresponding to the unknown modification included in the user LM211 by acquiring the difference of the user LM211 with respect to the version of the PRE modification LM446. The modification source search unit 130 transmits the version of the PRE modification and the difference data corresponding to the unknown modification to the vendor server 300, thereby registering the difference data corresponding to the unknown modification in the vendor server 300. The vendor server 300 registers the difference data corresponding to the unknown modification in the difference data management table 322, and also assigns a new version to the difference data and registers the new version in the version management table 321. The new version is a version branched off from the existing version (in the above example, version 46). Therefore, the vendor server 300 manages the new version as a branch number of the existing version (for example, version 46-1).

[0122] FIG. 17 is a diagram showing an example of adding a branch number. LM446a is LM of version 46-1 added to LM446 of version 46 (version 46-0) of PRE revision. LM446a includes difference data of revision Z corresponding to unknown revision in user LM211 with respect to LM446. The start address of revision Z with respect to the start address of user LM211 is "+0280". In this way, the vendor server 300 registers the unknown revision that existed in user LM211 in revision management DB320 as revision Z of version 46-1, and becomes manageable. At this time, the vendor server 300 assigns a new revision number to version 46-1, and also registers the hash value and LM program code corresponding to the revision number in LM hash value information 311 and LM program code information 312 of LM management DB310.

[0123] Next, an example of updating the revision management DB 320 in association with the addition of a branch number will be described. FIG. 18 illustrates an example of updating the version management table. In response to the addition of version 46-1, the vendor server 300 updates the version management table 321 to a version management table 321a. The version management table 321a includes a record of the branch number "1" of the 46th version.

[0124] FIG. 19 illustrates an example of updating the differential data management table. Furthermore, in response to the addition of the 46-1 version, the vendor server 300 updates the differential data management table 322 to a differential data management table 322a. The differential data management table 322a includes a record with the branch number "1" of the 46th version.

[0125] The post-correction data "478034F8" of the record with branch number "1" of the 46th edition in the differential data management table 322a corresponds to correction Z. The vendor server 300 notifies the management server 100 of the new revision number "TDzzzzz" assigned to revision Z. The management server 100 then updates the revision number "AD11122" corresponding to user LM211 in the revision management information 212 held by the user system 200 to the revision number "TDzzzzz." This allows the revision number for user LM211 to be properly managed in both the user system 200 and the vendor server 300.

[0126] Here, for a patch provided by a vendor, there are often conditions for the version of the LM to which the patch can be applied. This is because a patch is created on the assumption that it will be applied to an existing version of LM. Therefore, the user system 200 manages the version of the user LM 211 used in the user system 200 by using revision management information 212. The user system 200 may manage the version of the user LM 211 by holding a revision number associated with the version, as in the example of the second embodiment.

[0127] However, the version of the user LM 211 is not always managed appropriately. For example, the user system 200 may be operated by applying patches for individual customization or test versions provided to the user LM 211. Such individually provided patches may not be managed as versions publicly provided by the vendor. In addition, when applying an individually provided patch in the user system 200, if the user system 200 applies the individually provided patch by itself without communicating with the vendor server 300, this may also be a factor in the version of the individually provided patch not being managed by the vendor.

[0128] In this case, the user LM211 includes an unknown revision that does not correspond to any version in the version management table 321. For this reason, it may be difficult to grasp after the fact to what extent the revision contents of each version provided by the vendor have been applied to the user LM211.

[0129] For example, it is possible to compare all versions of LM managed by a vendor with the user LM 211 to identify modifications applied to the user LM 211. However, with this method, the time required for comparison increases as the number of versions increases.

[0130] Therefore, the modification source search unit 130 traces the version to be compared from the Nsize+1 version, i.e., the first version, in the forward or backward direction, and judges whether or not the difference data corresponding to the version to be compared is included in the user LM211. The modification source search unit 130 identifies the branch source version for the user LM211 according to the judgment, and can appropriately obtain the branch source version, i.e., the PRE modification version. Then, the modification source search unit 130 can judge that the user LM211 has been applied with modifications before the branch source version. In this way, the management server 100 can efficiently check whether or not each version has been applied to the user LM211.

[0131] In particular, the size of the LM tends to be larger as the version becomes newer. Therefore, the original modification search unit 130 can identify the LM of a version that is estimated to be relatively similar to the user LM 211 based on the LM size of each of the multiple versions and the size of the user LM 211. Therefore, the original modification search unit 130 can limit the search range of the branch source version for the user LM 211 to a relatively small range starting from the first version by determining the first version based on the LM size of each of the multiple versions and the size of the user LM 211.

[0132] As a result, the management server 100 can quickly check whether each version of the update has been applied to the user LM 211. For example, the management server 100 can reduce the time required to check whether an update has been applied compared to comparing all versions of the load modules with the user LM 211.

[0133] However, if the vendor is not aware of unknown modifications contained in the user LM211, there is a possibility that a patch will be created and distributed without considering the unknown modifications. In this case, the patch may not be applicable to the user LM211 because the user LM211 does not include a version that is a prerequisite for patch application. Alternatively, even if the patch can be applied to the user LM211, the unknown modifications in the user LM211 may be rewritten by the patch application, which may cause degradation such as making unique functions that existed in the user system 200 unusable.

[0134] In response to this, the management server 100 can have the vendor server 300 properly manage the unknown fix as fix Z. The vendor server 300 can properly grasp the version already applied to the user LM211 and the contents of fix Z using the fix management DB320 based on the fix number of fix Z. Therefore, for example, a patch developer of the vendor can properly create a patch for the user LM211 based on the fix management DB320, taking into account the applied version. That is, the management server 100 can support the proper creation of a patch for the user LM211. In this way, by properly creating a patch for the user LM211, it is possible to suppress the occurrence of problems such as patch inapplicability and degradation that accompany patch application to the user LM211.

[0135] For example, the management server 100 may execute the following process. The original modification search unit 130 acquires management information indicating the size of the LM in each of the multiple versions of the LM and the difference data of each of the multiple versions with respect to the version immediately preceding the LM. The original modification search unit 130 also acquires a first LM. The first LM is a first LM created by branching from the LM of one of the multiple versions based on the LM of that version, and does not correspond to any of the multiple versions. The original modification search unit 130 determines a first version from among the multiple versions as a starting point for selecting a version to be compared with the first LM, based on the size of the first LM and the size of the LM in each of the multiple versions. The original modification search unit 130 traces the version to be compared from the first version in the forward or backward direction, and identifies a version from among the multiple versions that is a branch source for the first LM, depending on whether the difference data corresponding to the version to be compared is included in the first LM or not.

[0136] This allows the management server 100 to quickly check whether or not modifications have been applied. The user LM 211 is an example of a first LM (first load module). The version management table 321 and the differential data management table 322 are examples of management information.

[0137] For example, when the first difference data corresponding to the first version is included in the first LM, the modification source search unit 130 traces the versions to be compared in the forward direction and identifies the version immediately preceding the version to be compared that is first determined to have no difference data included in the first LM as the version to be branched from. On the other hand, when the first difference data is not included in the first LM, the modification source search unit 130 traces the versions to be compared in the reverse direction and identifies the version to be compared that is first determined to have difference data included in the first LM as the version to be branched from.

[0138] This allows the management server 100 to appropriately check whether or not a correction has been applied. For example, in determining the first version, the original modification search section 130 determines, based on the management information, the version of LM that is larger than the size of the first LM and is closest to the size of the first LM as the first version.

[0139] This allows the management server 100 to appropriately narrow down the range of versions to be checked for the application of modifications. The above-mentioned version N=Nsize+1 is an example of the first version. For example, in determining the first version, the original modification search unit 130 may obtain a second version of the LM that is equal to or smaller than the size of the first LM and has a size closest to the size of the first LM, based on the management information. In identifying the branch source version, the original modification search unit 130 may obtain difference information that is the difference between the first LM and the LM of the second version. The original modification search unit 130 may determine whether or not difference data corresponding to the version to be compared is included in the first LM, based on the difference information.

[0140] This allows the management server 100 to narrow down the portion of the first LM to be checked for checking whether or not modifications have been applied, and allows the management server 100 to check whether or not modifications have been applied in a shorter time than if the entire first LM were used as the comparison target. The above-mentioned N=Nsize version is an example of the second version. The above-mentioned diff data is an example of difference information. If the original modification search unit 130 determines the second version before the first version, it may take the version one generation later than the second version as the first version. If the original modification search unit 130 determines the first version before the second version, it may take the version one generation earlier than the first version as the second version.

[0141] The management information may also include a combination date, which is the date on which the LM of each of the multiple versions was created. In determining the first version, the original revision search unit 130 may identify a third version that is earlier than the first combination date of the first LM and corresponds to a combination date that is closest to the first combination date, based on the management information. The original revision search unit 130 may determine the first version (or the second version) from among the versions earlier than the third version.

[0142] In this way, the management server 100 can quickly determine the first version by excluding in advance from among the multiple versions those versions that are clearly not applied to the first LM. As a result, the management server 100 can check whether or not a revision has been applied in an even shorter time.

[0143] Furthermore, the modification source search section 130 may obtain difference data of the first LM with respect to the LM of the branch source version by comparing the identified LM of the branch source version with the first LM. This allows the management server 100 to appropriately acquire difference data related to the unknown correction included in the first LM. Also, for example, the management server 100 can support the vendor server 300 by transmitting the branch source version and difference data related to the unknown correction to the vendor server 300 so that the vendor server 300 can manage a new version for the unknown correction. As a result, for example, a patch developer of the vendor can easily grasp the correction content for the first LM through the vendor server 300, and can efficiently create a patch that matches the first LM. In this way, the management server 100 may support the vendor in creating an appropriate patch.

[0144] The information processing in the first embodiment can be realized by causing the processing unit 12 to execute a program. The information processing in the second embodiment can be realized by causing the CPU 101 to execute a program. The program can be recorded in a computer-readable recording medium 53.

[0145] For example, the program can be distributed by distributing recording medium 53 on which the program is recorded. The program may also be stored in another computer and distributed via a network. The computer may store (install) the program recorded in recording medium 53 or a program received from another computer in a storage device such as RAM 102 or HDD 103, and read and execute the program from the storage device. [Explanation of symbols]

[0146] 10. Information processing device 11 Storage section 11a Management information 12 Processing section 20 First Load Module

Claims

1. acquiring management information indicating a size of a load module in each of a plurality of versions and differential data of each of the plurality of versions with respect to an immediately preceding version of the load module; determining a first version from among the multiple versions as a starting point for selecting a version to be compared with the first load module, based on a size of the first load module that does not correspond to any of the multiple versions and a size of the load module in each of the multiple versions, the first version being a starting point for selecting a version to be compared with the first load module, tracing the version to be compared from the first version in a forward or backward direction, and identifying a version from which the first load module is branched, among the plurality of versions, according to a determination as to whether or not the difference data corresponding to the version to be compared is included in the first load module; A program that causes a computer to carry out processing.

2. In identifying the version from which the branch originates, tracing the versions to be compared in a forward direction when first difference data corresponding to the first version is included in the first load module, and identifying, as the branch source version, a version immediately preceding a version that is determined for the first time not to include the difference data in the first load module among the versions to be compared; if the first difference data is not included in the first load module, tracing the versions to be compared in a backward direction, and identifying, among the versions to be compared, a version which is first determined to include the difference data in the first load module, as the version from which the branch originates; The program according to claim 1.

3. in determining the first version, a version of the load module that is larger than a size of the first load module and closest to a size of the first load module is determined as the first version based on the management information; The program according to claim 1.

4. The determination of the first version includes obtaining a second version of the load module, the second version being equal to or smaller than the size of the first load module and closest to the size of the first load module, based on the management information; In identifying the version of the branch source, difference information that is a difference between the first load module and the load module of the second version is obtained, and it is determined whether or not the difference data corresponding to the version to be compared is included in the first load module based on the difference information. The program according to claim 3.

5. the management information includes a combination date which is a date on which the load module of each of the multiple versions was created; In determining the first version, a third version is identified based on the management information, the third version being earlier than a first binding date of the first load module and corresponding to a binding date closest to the first binding date, and the first version is determined from among the versions earlier than the third version. The program according to claim 3.

6. acquiring the difference data of the first load module with respect to the load module of the branch source version by comparing the load module of the branch source version with the first load module; The program according to claim 1 , further causing the computer to execute a process.

7. The computer acquiring management information indicating a size of a load module in each of a plurality of versions and differential data of each of the plurality of versions with respect to an immediately preceding version of the load module; determining a first version from among the multiple versions as a starting point for selecting a version to be compared with the first load module, based on a size of the first load module that does not correspond to any of the multiple versions and a size of the load module in each of the multiple versions, the first version being a starting point for selecting a version to be compared with the first load module, tracing the version to be compared from the first version in a forward or backward direction, and identifying a version from which the first load module is branched, among the plurality of versions, according to a determination as to whether or not the difference data corresponding to the version to be compared is included in the first load module; Information processing methods.

8. a storage unit that stores management information indicating a size of a load module in each of a plurality of versions and differential data of each of the plurality of versions from an immediately preceding version of the load module; a processing unit which determines a first version from among the multiple versions as a starting point for selecting a version to be compared with the first load module based on a size of the first load module which does not correspond to any of the multiple versions and a size of the load module in each of the multiple versions, traces the version to be compared from the first version in a forward or backward direction, and identifies a version from which the first load module is to be branched out from among the multiple versions in accordance with a determination of whether the difference data corresponding to the version to be compared is included in the first load module; An information processing device having the above configuration.

Images