Software usage status investigation system, software usage status investigation device, and software usage status investigation method

Abstract

A software usage status investigation system that can grasp the usage status of each piece of software used in a system without requiring a complicated configuration or procedure. A software usage status investigation device and a software usage status investigation method are provided. [Solution] A software usage status investigation system includes a storage system that provides APIs, a client server on which software is installed, and a software usage status investigation device. The client server includes software identification information in the API request and sends the API request to the storage system. A management processing unit of the storage system records an API log, which is a log of API accesses by software to the API, so that the API log includes software identification information, and stores the API log in a log storage unit. The software usage status investigation device obtains the API log from the storage system and creates information indicating software usage from the API log.

Description

[Technical Field]

[0001] The present invention relates to a software usage status investigation system, a software usage status investigation device, and a software usage status investigation method. [Background technology]

[0002] Storage vendors provide software such as management software and plug-ins for use with their storage products (storage systems), either bundled with the storage products or free of charge, but storage vendors do not have a system in place to manage and track the usage status and function utilization rate of each piece of software.

[0003] As a result, it is not possible to distinguish between software features with high and low customer demand, and it is not possible to allocate appropriate investments to software features based on customer demand based on data (usage status). As a result, software features with high customer value are not being expanded or developed. Furthermore, from the user's perspective, additional development of frequently used features is not prioritized, and features that users do not use are developed, which results in a lack of usability for the software and its features, and a decline in user satisfaction. Therefore, storage vendors and users are requesting an understanding of the usage status of each piece of software. Note that these problems and requests also apply to systems other than storage systems (software used in other systems).

[0004] Patent Document 1 (Japanese Patent Laid-Open Publication No. 2001-306314) discloses a software management method for recording the usage history of software. This software management method grasps the frequency of software usage as follows.

[0005] The software supply device has a server and a user database. When a user terminal downloads a software program from the software supply device, the software supply device assigns user terminal identification information to the software program and registers the user terminal identification information and identification information of the access point used by the user terminal to connect to the communication network in the user database.

[0006] The server compares the user terminal identification information notified when the user terminal executes the software and the access point passed through at the time of notification with the contents of the user database, and if the user terminal identification information is in the user database and the access point passed through matches the access point identification information in the user database, it sends software usage permission information to the user terminal and updates the usage history information in the user database.The user database allows software vendors to accurately grasp the frequency of software use, and can use this information as reference information for future software development.

[0007] Patent Document 2 (JP Patent Publication No. 2021-174129) discloses an API billing system that uses an API connection infrastructure to record the history of requests from an application to an API (Application Programming Interface) on a system infrastructure and the history of responses from the system infrastructure to the application, and calculates API usage fees for the application's use of the API based on the history.

[0008] Patent Document 3 (JP 2019-96060 A) discloses an API billing system in which an API management device stores the history of requests and responses to an API for each of multiple applications that use the API, and a billing management device determines the billing value for an application that uses the API based on the billing conditions for using the API and information related to the history obtained from the API management device. [Prior art documents] [Patent documents]

[0009] [Patent Document 1] Japanese Patent Application Laid-Open No. 2001-306314 [Patent Document 2] Japanese Patent Publication No. 2021-174129 [Patent Document 3] Japanese Patent Application Publication No. 2019-96060 Summary of the Invention [Problem to be solved by the invention]

[0010] The inventors of the present application are studying a new software usage status investigation device for grasping the usage status of each piece of software used in a system (for example, a storage system).

[0011] Users of a system that uses a REST API use software on a terminal connected to the system via a network. In this case, the software (REST API client) accesses the system via the network, internally calls the system's API (Application Programming Interface), and uses the API to operate the system, thereby executing the functions implemented in each software.

[0012] REST API performs session-based user authentication. When a Rest API client accesses the Rest API server and starts an operation on the system, it first calls the session generation API on the system side and performs user authentication using the user information (user ID and password) used to access the system.

[0013] However, because Rest API clients (software) are not assigned individual identifiers (identification information), the system cannot identify the Rest API client (software) that is calling the API. As a result, while it is clear that users are performing some operation using the system's API (Rest API Server), it is not possible to tally the number of API calls for each piece of software or the usage of each function, making it impossible to grasp the usage status of each piece of software. Software usage can be aggregated by collecting logs on the user's device running the software, but in this case, the logs are managed by the software and are not centralized, so collecting the logs is time-consuming, resulting in a complex configuration and procedure.

[0014] The software management method of Patent Document 1 requires the management of user terminal identification information and access point identification information and processing using these, resulting in a complicated configuration and procedures. Patent Documents 2 and 3 do not describe, as in the present invention, acquiring from the system an API audit log that records API accesses to the system-side API of software that has been assigned identification information so that the identification information of the software that made the API access remains, and generating information indicating the usage status of the software from the API audit log.

[0015] One object of the present invention is to provide a software usage status investigation system, a software usage status investigation device, and a software usage status investigation method that can grasp the usage status of each piece of software used in a system without requiring complicated configurations and procedures. [Means for solving the problem]

[0016] In order to solve the above-mentioned problems, the software usage investigation system of the present invention is a software usage investigation system comprising: a plurality of systems that provide an API and each have a computing device and a first storage device; a plurality of client servers that have software installed that accesses the API via a network and executes functions, and that send API requests to the systems and receive API responses from the systems through the operation of the software; and a software usage investigation device that includes an information processing device, wherein the client servers include identification information of the software in the API request and send the API request to the system, the computing device of the system records an API log, which is a log of API accesses to the API by the software, so that the API log includes the identification information of the software, and stores the API log in the first storage device, and the information processing device obtains the API log from the system and creates information indicating the usage of the software from the API log.

[0017] The software usage status investigation device of the present invention is a software usage status investigation device that includes an information processing device that investigates the usage status of software that accesses an API provided by a system via a network and executes the software's functions, and the information processing device is configured to obtain from the system an API log related to API access to the API by the software to which identification information has been assigned, the API log being recorded so as to include the software's identification information, and to create information indicating the usage status of the software from the API log.

[0018] The software usage investigation method of the present invention is a software usage investigation method using an information processing device that investigates the usage of software that accesses an API provided by a system via a network and executes the software's functions, and the information processing device obtains from the system an API log related to API access to the API by the software to which identification information has been assigned, the API log being recorded so as to include the software's identification information, and creates information indicating the usage of the software from the API log. [Effects of the Invention]

[0019] According to the present invention, it is possible to grasp the usage status of each piece of software used in a system without requiring complicated configurations and procedures. Note that the effects described herein are not necessarily limited to those described herein, and may be any of the effects described in this disclosure. [Brief explanation of the drawings]

[0020] [Figure 1A] FIG. 1A is a diagram showing an example of the configuration of a software usage status investigation system according to the first embodiment. [Figure 1B] FIG. 1B is a diagram illustrating an example of the configuration of a system including a customer system platform and a second cloud platform. [Figure 2] FIG. 2 is a block diagram showing an example of the hardware block configuration of a storage system. [Figure 3] FIG. 3 is a schematic diagram showing an example of the configuration of an information processing device applied to a client server and a cloud server. [Figure 4A] FIG. 4A is a diagram for explaining the format of the API log. [Figure 4B] FIG. 4B is a diagram showing an example of an API log recorded for multiple API accesses. [Figure 5A] FIG. 5A is a diagram for explaining the tool ID management table. [Figure 5B] FIG. 5B is a diagram for explaining the serial ID model correspondence table. [Figure 5C] FIG. 5C is a diagram for explaining the serial ID customer correspondence table. [Figure 6] FIG. 6 is a diagram for explaining the log conversion table. [Figure 7] FIG. 7 is a diagram for explaining the usage tally table. [Figure 8A] FIG. 8A is a diagram for explaining a usage statistics table. [Figure 8B] FIG. 8B is a diagram for explaining the model usage statistics table. [Figure 8C] FIG. 8C is a diagram for explaining the customer usage statistics table. [Figure 9] FIG. 9 is a diagram for explaining the operation of the system. [Figure 10] FIG. 10 is a diagram for explaining the operation of the system. [Figure 11] FIG. 11 is a diagram for explaining the prior art. [Figure 12] FIG. 12 is a sequence diagram for explaining the operation of each element of the system. [Figure 13] FIG. 13 is a sequence diagram for explaining the operation of each element of the system. [Figure 14] FIG. 14 is a flowchart showing the processing flow executed by the log interpretation unit and the usage information extraction unit. [Figure 15] FIG. 15 is a diagram showing an example of a screen created by the utilization rate display unit. [Figure 16] FIG. 16 is a diagram showing an example of a screen created by the utilization rate display unit. [Figure 17] FIG. 17 is a diagram showing an example of a screen created by the utilization rate display unit. [Figure 18] FIG. 18 is a diagram showing an example of a screen created by the utilization rate display unit. [Figure 19] FIG. 19 is a diagram showing an example of a screen created by the utilization rate display unit. [Figure 20] FIG. 20 is a diagram for explaining the processing flow executed by the utilization rate display unit. [Figure 21] FIG. 21 is a diagram for explaining the processing flow executed by the utilization rate display unit. [Figure 22] FIG. 22 is a diagram for explaining the processing flow executed by the utilization rate display unit. [Figure 23] FIG. 23 is a diagram for explaining the processing flow executed by the utilization rate display unit. [Figure 24] FIG. 24 is a diagram for explaining the processing flow executed by the utilization rate display unit. [Figure 25] FIG. 25 is a diagram for explaining the API management table. [Figure 26] FIG. 26 is a diagram for explaining an example of a log conversion table held (memorized, stored) by the software usage status investigation system. [Figure 27] FIG. 27 is a diagram for explaining the API usage tally table. [Figure 28] FIG. 28 is a diagram for explaining the API usage statistics table. [Figure 29] FIG. 29 is a flowchart showing the processing flow executed by the log interpretation unit and the usage information extraction unit. [Figure 30] FIG. 30 is a diagram showing an example of a screen created by the utilization rate display unit. [Figure 31] FIG. 31 is a diagram showing an example of a screen created by the utilization rate display unit. [Figure 32] FIG. 32 is a diagram for explaining a modified example of the present invention. [Figure 33] FIG. 33 is a flowchart showing the processing flow executed by the API calling unit according to the modified example of the present invention. [Figure 34] FIG. 34 shows the number of uses screen for each model. [Figure 35] FIG. 35 shows the customer usage number screen. DETAILED DESCRIPTION OF THE INVENTION

[0021] Hereinafter, each embodiment of the present invention will be described with reference to the drawings. In all the drawings of the embodiments, the same or corresponding parts may be denoted by the same reference numerals.

[0022] In the following explanation, various types of information may be described using expressions such as "table," "record," "row," "column," and "row," but the various types of information may also be expressed using data structures other than these. When describing identification information, expressions such as "ID" and "name" are used, but these are interchangeable and can also be replaced with other expressions of identification information.

[0023] In the following explanation, processing may be described using functional blocks as the subject, but the subject of processing may also be a CPU or device instead of a functional block. The subject of processing performed by executing a program may be a computing unit, and may include a dedicated circuit that performs specific processing. Here, the dedicated circuit may be, for example, an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or a CPLD (Complex Programmable Logic Device).

[0024] <<First Embodiment>> A software usage status investigation system according to a first embodiment of the present invention will be described. FIG. 1A is a diagram illustrating an example of the configuration of the software usage status investigation system according to the first embodiment. As illustrated in FIG. 1A, the software usage status investigation system includes multiple customer system platforms 1000a1 to 1000aN and a second cloud platform 300. These are connected via a network so that they can send and receive information (data) to and from each other. Hereinafter, the multiple customer system platforms 1000a1 to 1000aN may be referred to as "customer system platforms 1000a" when there is no need to distinguish between them. The multiple customer system platforms 1000a may belong to different customers, or two or more of them may belong to the same customer. In this example, the customer system platform 1000a is a system platform including a storage system. The customer system platform 1000a includes a storage system that provides an API, a host server, and a client server in which software is installed and which sends API requests to the storage system and receives API responses from the storage system through the operation of the software. As an example of the configuration of the customer system infrastructure 1000a, details of a customer system infrastructure 1000a1 are shown in FIG. 1B described later, but the configuration of the customer system infrastructure 1000a is not limited to this.

[0025] FIG. 1B is a diagram showing an example of the configuration of a system including a customer system infrastructure 1000a1 and a second cloud infrastructure 300. As shown in FIG. 1B, the system includes the customer system infrastructure 1000a1 and the second cloud infrastructure 300. The customer system infrastructure 1000a1 includes an on-premise infrastructure 100 and a first cloud infrastructure 200. These are connected via a network so that they can send and receive information (data) with each other. In this example, the customer system infrastructures 1000a2 to 1000aN have the same configuration as the customer system infrastructure 1000a1 (however, the model of the storage system 130 may be the same or different).

[0026] The on-premise platform 100 has a computer system built in an on-premise environment. The computer system includes a first management server 110, a second management server 120, a storage system 130, and a host server 140.

[0027] The first management server 110 manages the storage system 130. Management software 111 is introduced (installed) in the first management server 110. The first management server 110 executes the management software 111. The management software 111 includes an API call unit 112. The API call unit 112 includes a request construction function, an authentication management function, an error handling function, and a response processing function. In this example, the name of the management software 111 is "Management Software A" and the Tool ID is "mms345g7jf56".

[0028] The request construction function constructs a request for performing operations such as retrieving, saving, updating, and deleting data on the storage system 130. The request construction function constructs a request by combining an endpoint, an HTTP method, parameters, etc. The request construction function constructs a request so that the request further includes a Tool ID assigned to the management software 111. For example, the request construction function includes an argument for inputting the Tool ID in the header or body of the API request, includes an argument for inputting the Tool ID in the body of the request (e.g., a JSON file), and passes the specific Tool ID as an argument, thereby including the Tool ID in the request.

[0029] The authentication management function manages authentication information such as API keys and tokens and applies it to requests. The error handling function processes error messages and retries when an API call fails. The response processing function analyzes responses from the API and extracts necessary data.

[0030] For example, when the API call unit 112 acquires data from the storage system 130, the API call unit 112 uses the request construction function and the authentication management function to construct a request for acquiring the data. The request includes an endpoint for acquiring the data, an HTTP method (GET), necessary headers (such as authentication information), parameters (query parameters), and a Tool ID. The API call unit 112 sends the constructed request to the management API reception unit 135 of the storage system 130. When the API call unit 112 receives a response from the management API reception unit 135, it uses the response processing function to analyze the response and extract the necessary data.

[0031] An external plug-in 121 is introduced (installed) in the second management server 120. The second management server 120 executes the external plug-in 121 of the storage system 130. The external plug-in 121 is software for extending the functions of the storage system 130. The external plug-in 121 includes an API call unit 122 that has the same functions as the management software 111. In this example, the name of the external plug-in 121 is "Plug-In A" and the Tool ID is "jjuh786s39ik".

[0032] The storage system 130 includes a storage management unit 131 and a storage data unit 132. The storage management unit 131 includes a management processing unit 133 and a log holding unit 134. The management processing unit 133 includes a management API reception unit 135, a management execution unit 136, and an API log upload unit 137.

[0033] The management processing unit 133 provides an interface for the storage system 130 to communicate with clients (first management server 110, second management server 120, first cloud server 210, and second cloud server 220). The management processing unit 133 enables the clients to perform operations such as data acquisition, storage, update, and deletion through the API.

[0034] The management API reception unit 135 exposes API endpoints for clients to access specific functions and resources provided by the API in order to operate on data. The management API reception unit 135 receives requests from clients, performs appropriate processing according to the requests using the management execution unit 136, and then returns a response to the client. For example, in response to a data acquisition request, the specified data is returned.

[0035] The management execution unit 136 performs appropriate processing in response to the request. The management execution unit 136 also performs access control regarding API usage. The management execution unit 136 authenticates clients and checks access restrictions to resources. The management execution unit 136 converts the format of request data and response data from clients as necessary (for example, converting JSON format data to XML format). The management execution unit 136 records an API log 138, which is a log related to API access, in the log storage unit 134.

[0036] The API log upload unit 137 uploads the API log 138 to the log storage unit 315 of the second cloud infrastructure 300 .

[0037] The log storage unit 134 stores (preserves, memorizes) the API log 138 .

[0038] The storage data section 132 includes volumes, which are provided to a host server 140.

[0039] The host server 140 is a computer (server device) that issues an IO request. The host server 140 may be a physical computer or a virtual computer. The host server 140 is connected to the storage data unit 132 via a SAN (Storage Area Network). The storage data unit 132 provides the host server 140 with a volume. The host server 140 recognizes a volume when the volume is mounted on the host.

[0040] The first cloud infrastructure 200 is a cloud that can provide a resource providing service on the first cloud infrastructure 200. The first cloud infrastructure 200 includes a first cloud server 210 and a second cloud server 220 that are provided by the resource providing service. Note that the first management server 110 and the second management server 120, and the first cloud server 210 and the second cloud server 220, described above, are referred to as "client servers" when there is no need to particularly distinguish between them.

[0041] The first cloud server 210 manages the storage system 130. Management software 211 is introduced (installed) in the first cloud server 210. The first cloud server 210 executes the management software 211. The management software 211 includes an API call unit 212. The API call unit 212 has the same functions as the API call unit 112 described above. In this example, the name of the management software 211 is "Management Software B" and the Tool ID is "s88fwasgggg".

[0042] An external plug-in 221 is introduced (installed) in the second cloud server 220. The second cloud server 220 executes the external plug-in 221 of the storage system 130. The external plug-in 221 is software for extending the functions of the storage system 130. The external plug-in 221 includes an API call unit 222 that has the same functions as the management software 111. In this example, the name of the external plug-in 221 is "Plug-In B" and the Tool ID is "s88fwajdasua".

[0043] The second cloud infrastructure 300 is a cloud that can provide a resource providing service on the second cloud infrastructure 300, and includes a cloud server 310 that is provided by the resource providing service.

[0044] Cloud server 310 may be referred to as a "software usage status survey device." Cloud server 310 includes a log interpretation unit 312, a usage information extraction unit 313, a usage rate display unit 314, a log storage unit 315, and a database 316. Log interpretation unit 312 acquires API log 138 from log storage unit 134 and creates a log conversion table 600. Usage information extraction unit 313 creates a usage aggregation table 700 and a usage statistics table 800 from the log conversion table 600. Furthermore, usage information extraction unit 313 creates a model usage statistics table 810 and a customer usage statistics table 820. Usage rate display unit 314 creates a display screen (image) based on usage statistics table 800 and the like and displays it on a display.

[0045] The log holding unit 315 includes the API log 138. The API log 138 is uploaded from the API log upload unit 137 and held (memorized, stored) in the log holding unit .

[0046] The database 316 includes a tool ID management table 500, a serial ID-model correspondence table 510, a serial ID-customer correspondence table 520, a log conversion table 600, a usage tally table 700, a usage statistics table 800, a model usage statistics table 810, and a customer usage statistics table 820. Details of these tables will be described later.

[0047] <Hardware configuration> 2 is a block diagram showing an example of the hardware configuration of the storage system 130. The storage system 130 has a plurality of (or one) physical storage devices, PDEVs 21, and a storage controller 22 connected to the PDEVs 21.

[0048] The storage controller 22 has an I / F 23, an I / F 24, two memories 25, and two processors 26 connected thereto.

[0049] The I / F 23 is a communication interface device that mediates data exchange between an external device (for example, a host server 140) and the storage controller 22. The host server 140 is connected to the I / F 23 via an FC (Fibre Channel) network 29.

[0050] The host server 140 sends an I / O request (write request or read request) to the storage controller 22 specifying the I / O destination (for example, a logical volume number such as a LUN (Logical Unit Number) or a logical address such as an LBA (Logical Block Address)).

[0051] The I / F 24 is a communication interface device that mediates the exchange of data between a plurality of PDEVs 21 and the storage controller 22. A plurality of PDEVs 21 are connected to the I / F 24.

[0052] The memory 25 stores programs executed by the processor 26 and data used by the processor 26. The processor 26 executes the programs stored in the memory 25. In this example, the set of the memory 25 and the processor 26 is duplicated.

[0053] The GUM (Gateway for Unified Management) 28 is a computer that has basic management functions for the storage system 130. When the storage system 130 is managed externally, communication is performed with the GUM 28. The computer includes a CPU, ROM, RAM, a non-volatile storage device that can read and write data, a network interface, and an input / output interface (i.e., it has the same configuration as the information processing device shown in FIG. 3, which will be described later). The management processing unit 133 is configured by a program stored in the ROM and / or storage device. The log holding unit 134 is configured by a storage device.

[0054] Fig. 3 is a schematic diagram showing an example of the configuration of an information processing device applied to a client server and a cloud server 310. As shown in Fig. 3, the information processing device 30 includes a CPU 31, a ROM 32, a RAM 33, a non-volatile storage device 34 that can read and write data, a network interface 35, and an input / output interface 36. Note that the information processing device 30 applied to a server on a cloud is a virtual information processing device constructed on the cloud.

[0055] The ROM 32 and / or the storage device 34 hold (store, memorize) software and various programs. The software and various programs include programs for realizing various functions of the information processing device 30.

[0056] The CPU 31 loads a program stored in the ROM 32 and / or the storage device 34 into the RAM 33. The CPU 31 executes the program loaded into the RAM 33 to realize various functions of the information processing device 30.

[0057] As described above, the programs executed by the CPU 31 are loaded into the RAM 33, and data used when the CPU 31 executes the programs is temporarily stored therein.

[0058] The network interface 35 is an interface for connecting the information processing device 30 to a network. The input / output interface 36 is an interface for connecting operation devices such as a keyboard and a mouse, a display, and the like.

[0059] At least a part of the processing performed by the CPU 31 executing the program may be executed by another computing device (for example, hardware such as an ASIC or FPGA).

[0060] In the cloud server 310, the log interpretation unit 312, the usage information extraction unit 313, and the usage rate display unit 314 are configured by programs stored in the ROM 32 and / or the storage device 34. The log retention unit 315 is configured by the storage device 34. The database 316 is stored in the storage device 34.

[0061] 4A is a diagram illustrating the format of the API log 138. The API log 138 is a log related to API access of software (for example, an operation log, an audit log, an API access log, etc.), and is recorded for each API request. Note that FIG. 4A shows the API log 138 for one API request. The API log 138 includes at least the date and time 401 when the API was called, the type of the called API (API type 402), and the tool ID 403 of the caller. The API log 138 may also include optional items such as the IP address 404 of the operation source (caller), the operation result 405 (Success or Fail), a serial ID 406, and authentication information 403.

[0062] 4B shows an example of the API log 138 recorded for multiple API accesses. The API log 138 is saved, for example, in a file format. The API log 138 is created and saved so that the serial ID of the storage system 130 is included in the file name.

[0063] 5A is a diagram illustrating a tool ID management table 500. The tool ID management table 500 includes columns for storing information (values): ID 501, Tool Name 502, and Tool ID 503. In the tool ID management table 500, information corresponding to each column for managing software whose usage status is to be investigated is associated with each other and stored as row-by-row information (records).

[0064] Specifically, ID 501 stores identification information (ID) for identifying the corresponding record. Tool Name 502 stores the name of the software. Tool ID 503 stores the Tool ID, which is identification information of the software.

[0065] 5B is a diagram illustrating the serial ID model correspondence table 510. The serial ID model correspondence table 510 includes columns for storing information (values): Serial ID 511 and Model 512. In the serial ID model correspondence table 510, information corresponding to each column for managing serial IDs and storage models is associated with each other and stored as row-based information (records).

[0066] Specifically, the Serial ID 511 stores the identification information (Serial ID) of the storage system 130. The Model 512 stores the name of the model of the storage system 130.

[0067] 5C is a diagram illustrating the serial ID-customer correspondence table 520. The serial ID-customer correspondence table 520 includes columns for storing information (values), such as Customer ID 521 and Serial ID 522. In the serial ID-customer correspondence table 520, information corresponding to each column for managing the storage system 130 used by the customer is associated with each other and stored as row-based information (records).

[0068] Specifically, identification information (Customer ID) for identifying a customer is stored in the Customer ID 521. Identification information (Serial ID) of the storage system 130 is stored in the Serial ID 522.

[0069] 6 is a diagram illustrating a log conversion table 600. The log conversion table 600 includes columns for storing information (values): ID 601, 1st 602, 2nd 603, API 604, 4ht 605, and Tool ID 606. Note that between 4ht 605 and Tool ID 606, there are multiple columns similar to 1st 602, 2nd 603, and 4ht 605, but these are not shown in the figure.

[0070] In the log conversion table 600, information corresponding to each column relating to character strings in units obtained by dividing the text of the API log 138 by delimiters is stored as information (records) in units of rows in association with each other.

[0071] Specifically, ID 601 stores identification information (ID) for identifying the corresponding record. 1st 602, 2nd 603, 4th 605, and multiple columns (not shown) each store character strings separated by delimiters. API 604 stores a character string indicating the API type (API name). Tool ID 606 stores a Tool ID, which is software identification information. As will be described in detail later, the log conversion table 600 is created from the API log 138 by the log interpretation unit 312. Note that one record is information in which multiple character strings obtained by separating, by delimiters, the text of the API log 138 written by one API request are stored in each column.

[0072] 7 is a diagram illustrating a usage tally table 700. The usage tally table 700 includes an ID 701, a Serial ID 702, and a Tool ID 703 as columns for storing information (values).

[0073] In the usage tally table 700, information corresponding to each column relating to information tallying software usage is associated with each other and stored as row-based information (records). Specifically, ID 701 stores identification information (ID) for identifying the corresponding record. Serial ID 702 stores identification information (Serial ID) of the storage system 130. Tool ID 703 stores a Tool ID, which is software identification information. As will be described in detail later, the usage tally table 700 is created by the usage information extraction unit 313 based on the log conversion table 600.

[0074] 8A is a diagram illustrating a usage statistics table 800. The usage statistics table 800 includes columns for storing information (values), such as Serial ID 801, mms345g7jf56802, jjuh786s39ik803, s88fwajdasua804, and s88fwasgggg805. In the usage statistics table 800, information corresponding to each column relating to statistical information on software usage status is associated with each other and stored as row-based information (records).

[0075] Specifically, Serial ID 801 stores identification information (Serial ID) of the storage system 130. mms345g7jf56 802 stores information indicating whether the software with Tool ID "mms345g7jf56" is being used for the corresponding storage system 130. "Active" indicates that the software with the corresponding Tool ID is being used for the storage system indicated by the corresponding Serial ID. "-" indicates that the software with the corresponding Tool ID is not being used for the storage system indicated by the corresponding Serial ID.

[0076] Item jjuh786s39ik 803 stores information indicating whether or not the software with Tool ID "jjuh786s39ik" is being used in the corresponding storage system 130. Item s88fwajdasua 804 stores information indicating whether or not the software with Tool ID "s88fwajdasua" is being used in the corresponding storage system 130. Item s88fwasgggg 805 stores information indicating whether or not the software with Tool ID "s88fwasgggg" is being used in the corresponding storage system 130. These are created by the usage information extraction unit 313 based on the usage tally table 700.

[0077] 8B is a diagram illustrating a model usage statistics table 810. The model usage statistics table 810 includes columns for storing information (values): Serial ID 811, Model 812, mms345g7jf56813, jjuh786s39ik 814, s88fwajdasua 815, and s88fwasgggg 816. In the model usage statistics table 810, information corresponding to each column relating to statistical information on software usage status is associated with each other and stored as information on a row-by-row basis.

[0078] Specifically, Serial ID 811 stores identification information (Serial ID) of the storage system 130. Model 812 stores the name of the storage model. mms345g7jf56 813 stores information indicating whether software with Tool ID "mms345g7jf56" is being used for the corresponding storage system 130. jjuh786s39ik 814 stores information indicating whether software with Tool ID "jjuh786s39ik" is being used for the corresponding storage system 130. s88fwajdasua 815 stores information indicating whether software with Tool ID "s88fwajdasua" is being used for the corresponding storage system 130. s88fwasgggg 816 stores information indicating whether software with Tool ID "s88fwasgggg" is being used for the corresponding storage system 130.

[0079] 8C is a diagram illustrating a customer usage statistics table 820. The customer usage statistics table 820 includes columns for storing information (values), such as Serial ID 821, Customer ID 822, mms345g7jf56823, jjuh786s39ik824, s88fwajdasua825, and s88fwasgggg826.

[0080] Specifically, the Serial ID 821 stores identification information (Serial ID) of the storage system 130. The Customer ID 822 stores identification information (Customer ID) for identifying a customer. The mms345g7jf56 823 stores information indicating whether software with Tool ID "mms345g7jf56" is being used for the corresponding storage system 130. The jjuh786s39ik 824 stores information indicating whether software with Tool ID "jjuh786s39ik" is being used for the corresponding storage system 130. The s88fwajdasua 825 stores information indicating whether software with Tool ID "s88fwajdasua" is being used for the corresponding storage system 130. The s88fwasgggg 826 stores information indicating whether software with Tool ID "s88fwasgggg" is being used for the corresponding storage system 130.

[0081] <Operation> The operation when the software of each client server calls the API in the system will be described below. Each function implemented in each software is realized by internally calling the API on the storage system 130 side.

[0082] In this example, a REST API may be applied to the API provided by the storage system 130. In this case, the storage system 130 provides a Web API that complies with the principles of REST (Representational State Transfer) to acquire information and change the configuration of the storage system 130. In this case, the management processing unit 133 corresponds to the Rest API Server, and each of the API calling unit 112, the API calling unit 122, and the API calling unit 213 corresponds to the API Client.

[0083] 9 and 10, an example of operation when software uses an API will be described. A management processing unit 133 is placed on the GUM 28 of the storage system 130. The management processing unit 133 receives a request from the API calling unit 112 of the management software 111, issues the request to the storage system 130, and responds with the execution result to the API calling unit 112.

[0084] The management processing unit 133 receives a request from the API calling unit 122 of the external plug-in 121, issues the request to the storage system 130, and responds to the API calling unit 122 with the execution result.

[0085] The management processing unit 133 receives a request from the API calling unit 222 of the external plug-in 221, issues the request to the storage system 130, and responds with the execution result to the API calling unit 212.

[0086] In the following explanation, the operation of the API call unit 112 of the management software 111 will be used as an example, and the operation of the API call unit 122 of the external plug-in 121 and the operation of the API call unit 222 of the external plug-in 221 will not be explained as they are similar to the operation of the API call unit 112 of the management software 111.

[0087] When the API call unit 112 executes an operation on the storage system 130, user authentication is required. This system performs session-based user authentication. When the API call unit 112 accesses the management processing unit 133 to start an operation, this system always first generates a session. A session is generated by executing a session generation API in response to a session generation API request from the API call unit 112. The session generation API request includes a user ID, password, TooI ID, etc. As mentioned above, the TooI ID is the ID of the software (in this case, the software that issues the session generation API request).

[0088] In response to the request for session creation, authentication is performed using a user ID and password for accessing the storage system 130 (S1001 in FIG. 10). When a session is created (established), a Session ID and a Session Token are provided to the API call unit 112 as a response (S1002 in FIG. 10).

[0089] To execute an API after a session is generated (established), the API call unit 112 specifies a Session Token in the Authorization header of the request and sends the request to the management processing unit 133 (S1003 in FIG. 10). This request also includes a Tool ID. The management processing unit 133 performs authentication based on the session information (Session Token). The management processing unit 133 determines whether the request has been issued by an authenticated user (API call unit 112) based on the authentication information (Session Token), and returns a response to the API call unit 112 (S1004 in FIG. 10). When the operation from the API call unit 112 is to be terminated, the session is discarded (deleted) from the management processing unit 133 (S1005 in FIG. 10). Note that if a certain period of time has passed without the session being used, the session is automatically discarded.

[0090] The management processing unit 133 writes and stores an API log 138 in the log storage unit 134 for each API call.

[0091] <Comparison with conventional technology> Here, we will compare the operation when conventional software calls an API with the present invention. In the conventional technology, as in the present invention, a user ID common to each piece of software is used in user authentication when creating an initial session (processing corresponding to S1001 in FIG. 10). However, in the conventional technology, as shown in FIG. 11, the API caller does not have an individual identifier (Tool ID), so it is not possible to identify the API caller. Therefore, although it is possible to use the management processing unit 133 on the storage system 130 side to determine that software corresponding to the user ID is performing some operation, it is not possible to determine which software is calling the API, so it is not possible to count the number of API calls for each piece of software or the number of times each function (API) is used for each piece of software on the storage system 130 side. Note that in the conventional technology, it is possible to count the number of API calls for each piece of software and the number of times each function (API) is used for each piece of software by collecting logs on the software side, but the configuration and procedure are quite complicated.

[0092] Therefore, in the present invention, a Tool ID is assigned to each piece of software, and when external software calls an API provided by the storage system 130, the Tool ID is added (embedded) in the API request, and the storage system 130 (management processing unit 133) that receives the API request writes the Tool ID in the API log 138. This makes it possible to extract the Tool ID from the API log 138 based on the Tool ID written in the log, and to aggregate information for analyzing the usage status of each piece of software in the storage system 130 without requiring a complicated configuration or procedure on the storage system 130 side.

[0093] <Overall system operation> FIG. 12 is a sequence diagram for explaining the operation of each element of the system.

[0094] S1201: The operator 400 performs a specific operation on the client server.

[0095] S1202: The API call unit 112 (management software 111) generates an API request corresponding to a specific operation. As described above, the API request includes a Tool ID. The API call unit 112 (management software 111) sends the API request to the management API reception unit 135 of the storage system 130.

[0096] S1203: The management API reception unit 135 issues a request (execution instruction) to the management execution unit 136 of the storage system 130.

[0097] S1204: The management execution unit 136 writes the API log 138 to the log storage unit 134. As described above, at this time, the API log 138 is written to the log storage unit 134 so that the Tool ID is included.

[0098] S1205: The management execution unit 136 transmits the execution result for the request (execution instruction) to the management API reception unit 135.

[0099] S1206: The management API receiving unit 135 transmits the execution result to the API calling unit 112 as a response.

[0100] S1207: The API calling unit 112 uses the response to provide the execution result of the specific operation to the client server (the operator 400).

[0101] Through the above operations, the management execution unit 136 writes the API log 138 to the log holding unit 134 for each API call. The log holding unit 134 holds (memorizes, stores) the API log 138.

[0102] FIG. 13 is a sequence diagram for explaining the operation of each element of the system.

[0103] S1301: The API log upload unit 137 periodically (in this example, once a day (once at a predetermined time)) retrieves the API log 138 retained (memorized, stored) in the log retention unit 134. As a result, the log for each day is retrieved into the API log upload unit 137 in file format.

[0104] S1302: The API log upload unit 137 uploads the API log 138 in a file format to the log storage unit 315 of the second cloud infrastructure 300. The log storage unit 315 stores (preserves, saves) the API log 138 in a file format.

[0105] S1303: The log interpretation unit 312 and the usage information extraction unit 313 obtain the API log 138 from the log storage unit 315, and create a usage tally table 700 and a usage statistics table 800 from the API log 138. Details of this process will be described later. Furthermore, the usage information extraction unit 313 creates a model usage statistics table 810 from the usage statistics table 800 and the serial ID model correspondence table 510. The usage information extraction unit 313 creates a customer usage statistics table 820 from the usage statistics table 800 and the serial ID customer correspondence table 520.

[0106] S1304: The utilization rate display unit 314 calculates (extracts) information (for example, utilization rate) required for screen display from the utilization statistics table 800.

[0107] S1305: The decision maker 410 can see the screen provided by the utilization rate display unit 314 to understand the software utilization status (such as the number of storage systems 130 that use the software).

[0108] FIG. 14 is a flowchart showing the processing flow executed by the log interpretation unit 312 and the usage information extraction unit 313.

[0109] At a predetermined time, the log interpretation unit 312 starts the process from step 1400 and executes the processes of steps 1405 to 1415 described below.

[0110] Step 1405: The log interpretation unit 312 retrieves the log file (API log 138) for each of the plurality of storages to be investigated on a daily basis.

[0111] Step 1410: The log interpreter 312 selects an unselected log file (one of the API logs 138 of the multiple storage systems).

[0112] Step 1415: The log interpretation unit 312 converts the selected log file (API log 138) into a log conversion table 600 by separating it using delimiters, and stores (manages) the log conversion table 600 by assigning the name [LogDB_serial id] (the serial ID of the storage system 130 is substituted for serial id) which includes the serial ID of the storage system 130 corresponding to the selected log file. For example, if the serial ID of the storage system 130 is "87238", the name of the log conversion table 600 will be "LogDB 87238".

[0113] Next, in step 1420 , the usage information extraction unit 313 selects one unselected Tool ID from the tool ID management table 500 (Tool ID correspondence table), and proceeds to step 1425 .

[0114] In step 1425 , the usage information extraction unit 313 determines whether or not the column (Tool ID 604 ) of the log conversion table 600 contains at least one Tool ID selected in step 1420 .

[0115] If the Tool ID selected in step 1420 is not included in any column (Tool ID 604) of the log conversion table 600, the usage information extraction unit 313 determines "NO" in step 1425, returns to step 1420, selects one unselected Tool ID from the tool ID management table 500 (Tool ID correspondence table), and proceeds to step 1425.

[0116] If at least one Tool ID selected in step 1420 is included in the column (Tool ID 604 ) of the log conversion table, the usage information extraction unit 313 determines “YES” in step 1425 and proceeds to step 1430 .

[0117] In step 1430, the usage information extraction unit 313 checks whether the type of API corresponding to the Tool ID is a Session API, thereby determining whether the log (record) corresponding to the Tool ID is a Session API log. Note that if multiple Tool IDs are included in the column (Tool ID 604) of the log conversion table, this determination is made for each of the logs (records) corresponding to the multiple Tool IDs.

[0118] If the logs (records) corresponding to all Tool IDs are not Session API logs, the usage information extraction unit 313 judges "NO" in step 1430, returns to step 1420, selects one unselected Tool ID from the tool ID management table 500 (Tool ID correspondence table), and proceeds to step 1425.

[0119] If the log (record) corresponding to at least one Tool ID is a Session API log, the usage information extraction unit 313 determines “YES” in step 1430 and proceeds to step 1435 .

[0120] When the usage information extraction unit 313 proceeds to step 1435, it updates the usage tally table 700 with the Serial ID and Tool ID. The usage tally table 700 is given the name [SW usage tally_yyyymmdd]. The date on which the tally was performed is substituted for "yyyymmdd" in the name.

[0121] In step 1440, the usage information extraction unit 313 determines whether or not all the tool IDs in the tool ID management table 500 (tool ID correspondence table) have been confirmed (selected) for the log file selected in step 1410.

[0122] If not all tool IDs in the tool ID management table 500 (tool ID correspondence table) have been confirmed (selected), the usage information extraction unit 313 returns to step 1420, selects one unselected tool ID from the tool ID management table 500 (tool ID correspondence table), and proceeds to step 1425.

[0123] If all the tool IDs in the tool ID management table 500 (tool ID correspondence table) have been confirmed (selected), the usage information extraction unit 313 determines “YES” in step 1440 and proceeds to step 1445 .

[0124] When the usage information extraction unit 313 proceeds to step 1445, it determines whether or not all of the log files (API logs 138) imported in step 1405 have been confirmed (selected). If not all of the log files have been confirmed (selected), the usage information extraction unit 313 determines "NO" in step 1445, returns to step 1410, selects an unselected log file, and proceeds to step 1415.

[0125] If all log files have been checked (selected), the usage information extraction unit 313 judges "YES" in step 1445, executes the processing of step 1450 described below, and then proceeds to step 1495 to temporarily end this processing flow.

[0126] Step 1450: The usage information extraction unit 313 reflects the contents of the usage tally table 700 in the usage statistics table 800. The name [SW usage statistics_yyyymmdd] is given to the usage statistics table 800. The date on which the statistics were collected is substituted for "yyyymmdd" in the name.

[0127] 15 shows an example of a screen created by the utilization rate display unit 314. The example of the screen shown in Fig. 15 is a statistics screen 1500. The statistics screen 1500 shows the utilization status of each piece of software in the storage system 130.

[0128] The statistics screen 1500 includes four pie charts and a bar graph. The four pie charts show the software usage rates of Management Software A, Management Software B, Plug-In A, and Plug-In B. The software usage rate is the ratio (percentage) of the "number of storage systems using that software" to the "total number of storage systems surveyed." The bar graph shows the number of storage systems using each piece of software.

[0129] The terminal (not shown) of the decision maker 410 can access a web page held by the cloud server 310 using a browser to display a web page (statistics screen 1500 in FIG. 15) on the display of the terminal (not shown) (the same applies to the screens in FIGS. 16 to 19 described below). By checking the statistics screen 1500 in FIG. 5, the decision maker 410 can determine which software is used frequently, which helps in data-driven decision-making, such as conducting interviews focused on unused software (functions), eliminating functions, or making additional investments (the same applies to the screens in FIGS. 15 to 19 below).

[0130] Fig. 16 shows an example of a screen created by the usage rate display unit 314. The example of the screen shown in Fig. 16 is an individual screen 1600. The individual screen 1600 shows details of the usage status of specific software (selected software). In this example, the details of the usage status of Plug-In A are shown.

[0131] The individual screen 1600 includes a table, a pie chart, a box, and a line graph. The table shows the results of an analysis of the software usage rate of specific software (Plug-In A in this example). The table shows trends and ROI for the specific software. The pie chart shows the software usage rate of the specific software. The box shows the MR (midrange model) and HE (high end model) share rates for the specific software within that box. The MR share rate indicates the share rate (percentage) of the MR storage system 130 relative to the total number of storage devices using the software. The HE share rate indicates the share rate (percentage) of the HE storage system 130 relative to the total number of storage devices using the software. The line graph is a line graph with quarters on the horizontal axis and number of storage devices on the vertical axis. The lines in the line graph indicate the change in the number of storage devices using the specific software per quarter.

[0132] FIG. 17 shows an example of a screen created by the utilization rate display unit 314. The example of the screen shown in FIG. 17 is a transition screen 1700. The transition screen 1700 shows the transition of the usage status of each software by quarter. The transition screen 1700 includes a line graph. The line graph is a line graph with quarter as the horizontal axis and the number of storage units as the vertical axis. Each line in the line graph shows the transition of the number of storage units using each software by quarter.

[0133] Fig. 18 shows an example of a screen created by the utilization rate display unit 314. The example of the screen shown in Fig. 18 is a list screen 1800. The list screen 1800 includes a table showing the usage status of each software in each storage system 130. The table displays a checked check box indicating whether each software is in use in a field corresponding to each software name in the same row as the storage ID. As a result, the table shows whether or not the software in the storage system 130 indicated by the storage ID is being used during the survey period (in this example, one specific date).

[0134] FIG. 19 shows an example of a screen created by the utilization rate display unit 314. The example of the screen shown in FIG. 19 is a list screen (past comparison) 1900. The list screen (past comparison) 1900 includes a table showing the usage status of each software on a specific date in each storage system 130 and the usage status of each software 30 days prior to the specific date. The table displays a checked check box indicating whether each software was used in the field corresponding to each software name in the same row as the storage ID. Furthermore, a checked check box indicating whether each software was used 30 days prior to the specific date is displayed in the field corresponding to each software name in the same row as the storage ID. As a result, the table shows whether the software was used during the investigation period (in this example, the first day of the specific date) and whether the software was used 30 days prior to the specific date. The user can use the table to check whether the software has recently started to be used.

[0135] Fig. 20 is a diagram illustrating the processing flow executed by the utilization rate display unit 314. This processing flow is the processing flow when the statistics screen 1500 of Fig. 15 is drawn on a Web page. The utilization rate display unit 314 starts processing from step 2000 and sequentially executes the processing of steps 2005 to 2015 described below.

[0136] Step 2005: The utilization rate display unit 314 acquires the statistical data (the utilization statistics table 800 in FIG. 8A) required to create the statistics screen 1500 in FIG.

[0137] Step 2010: The utilization rate display unit 314 refers to the tool ID management table 500 and converts the Tool ID into a Tool Name (software name).

[0138] Step 2015: The utilization rate display unit 314 counts the number of uses of each software (number of storage systems used) by adding up the serial IDs, thereby calculating the number of uses of each software for each storage system 130.

[0139] Thereafter, the utilization rate display unit 314 executes steps 2020, 2025, and 2030 in parallel, which will be described below, and then proceeds to step 2035.

[0140] Step 2020: The utilization rate display unit 314 divides the total sum by the total number of serial IDs to calculate the software utilization rate.

[0141] Step 2025: The utilization rate display unit 314 creates a pie chart showing the utilization rate of each piece of software, and then proceeds to step 2035.

[0142] Step 2030: The utilization rate display unit 314 creates a line graph showing the transition of utilization of all software, and then proceeds to step 2035.

[0143] In step 2035, the utilization rate display unit 314 creates the statistics screen 1500. Next, in step 2040, the utilization rate display unit 314 renders the statistics screen 1500 on the Web page, and then proceeds to step 2095 to temporarily end this processing flow.

[0144] 21 is a diagram illustrating the processing flow executed by the utilization rate display unit 314. This processing flow is the processing flow when drawing the individual screen 1600 of FIG. 16 on a Web page. The utilization rate display unit 314 starts processing from step 2100, and sequentially executes the processing of steps 2105 and 21010 described below.

[0145] Step 2105: The utilization rate display unit 314 acquires the statistical data (the utilization statistics table 800 in FIG. 8A) required to create the individual screen 1600 in FIG.

[0146] Step 2110: The utilization rate display unit 314 refers to the tool ID management table 500 and converts the Tool ID into a Tool Name (software name).

[0147] The utilization rate display unit 314 executes in parallel steps 2115 and 2120, steps 2125 and 2130, and steps 2135 through 2145, which will be described below, and then proceeds to step 2150.

[0148] Step 2115: The utilization rate display unit 314 compiles the utilization statistics table 800 for each quota for the target software.

[0149] Step 2120: The utilization rate display unit 314 creates a line graph showing the transition in utilization of the target software (the transition in the number of storage systems used).

[0150] Step 2125: The utilization rate display unit 314 calculates the number of uses of the target software from the model utilization statistics table 810 in FIG. 8B by summing up the serial IDs.

[0151] Step 2130: The utilization rate display unit 314 tally up the share of the sum of serial IDs for each midrange model price range (= sum of serial IDs for midrange model price ranges / sum of serial IDs) and the share of the highend model price range (= sum of serial IDs for highend model price ranges / sum of serial IDs).

[0152] Step 2135: The usage rate display unit 314 counts the number of uses of the target software as the sum of the serial IDs.

[0153] Step 2140: The utilization rate display unit 314 divides the total sum by the total number of serial IDs to calculate the utilization rate (percentage).

[0154] Step 2145: The utilization rate display unit 314 creates a pie chart showing the utilization rate (percentage) of the target software.

[0155] When the utilization rate display unit 314 proceeds to step 2150, it creates the individual screen 1600 shown in Fig. 16. The table showing the trends and return on investment for the target software in the individual screen 1600 is created by an analysis process (not shown). Next, the utilization rate display unit 314 proceeds to step 2155, where it renders the individual screen 1600 on the Web page, and then proceeds to step 2195, where it temporarily ends this processing flow.

[0156] Figure 22 is a diagram illustrating the processing flow executed by the utilization rate display unit 314. This processing flow is the processing flow when rendering the transition screen 1700 of Figure 17 on a Web page. The utilization rate display unit 314 starts processing from step 2200, and after sequentially executing the processing of steps 2205 to 2230 described below, proceeds to step 2295 and temporarily ends this processing flow.

[0157] Step 2205: The utilization rate display unit 314 acquires the statistical data (utilization statistics table 800) required to create the transition screen 1700 of FIG.

[0158] Step 2210: The utilization rate display unit 314 refers to the tool ID management table 500 and converts the Tool ID into a Tool Name (software name).

[0159] Step 2215: The utilization rate display unit 314 compiles the utilization statistics table 800 for each quota for all the target software.

[0160] Step 2220: The utilization rate display unit 314 creates a line graph showing the transition of utilization of each piece of target software.

[0161] Step 2225: The utilization rate display unit 314 creates the transition screen 1700 of FIG.

[0162] Step 2230: The utilization rate display unit 314 renders the transition screen 1700 on the Web page.

[0163] 23 is a diagram illustrating the processing flow executed by the utilization rate display unit 314. This processing flow is the processing flow when the list screen 1800 of FIG. 18 is drawn on a Web page. The utilization rate display unit 314 starts processing from step 2300, and after sequentially executing the processing of steps 2305 to 2330 described below, proceeds to step 2295 and temporarily ends this processing flow.

[0164] Step 2305: The utilization rate display unit 314 acquires the statistical data (utilization statistics table 800) required to create the list screen 1800 of FIG.

[0165] Step 2310: The utilization rate display unit 314 refers to the tool ID management table 500 and converts the Tool ID into a Tool Name (software name).

[0166] Step 2315: The utilization rate display unit 314 converts the value of each piece of software in the utilization statistics table 800 for the target date: "Active" into an icon such as a checked check box.

[0167] Step 2320: The utilization rate display unit 314 creates the utilization statistics table 800 for the target date.

[0168] Step 2325: The utilization rate display unit 314 creates the list screen 1800 of FIG.

[0169] Step 2330: The utilization rate display unit 314 renders the list screen 1800 on the Web page.

[0170] 24 is a diagram illustrating the processing flow executed by the utilization rate display unit 314. This processing flow is the processing flow when the list screen (past comparison) 1900 of FIG. 19 is drawn on a Web page. The utilization rate display unit 314 starts processing from step 2400, and executes the processing of steps 2405 to 2435 described below in order, and then proceeds to step 2495 to temporarily end this processing flow.

[0171] Step 2405: The utilization rate display unit 314 acquires the statistical data (utilization statistical table 800) required to create the list screen (past comparison) 1900 of FIG.

[0172] Step 2410: The utilization rate display unit 314 converts the Tool ID into a Tool Name (the name of the software).

[0173] Step 2415: The utilization rate display unit 314 converts the value of each software item in the utilization statistics table 800 for the target date: "Active" into an icon such as a checked check box.

[0174] Step 2420: The utilization rate display unit 314 converts the value of each software in the utilization statistics table 800 for the past days (e.g., 30 days ago) before the target date: “Active” into an icon such as a checked check box. Step 2425: The utilization rate display unit 314 creates the utilization statistics table 800 (ie, the table in FIG. 19) for the latest day and the past day.

[0175] Step 2430: The utilization rate display unit 314 creates the list screen (past comparison) 1900 of FIG.

[0176] Step 2435: The utilization rate display unit 314 renders the list screen (past comparison) 1900 on the Web page.

[0177] <Effects> As described above, the software usage status investigation system according to the first embodiment can grasp the usage status of each piece of software used in the system without requiring a complicated configuration or procedure.

[0178] <<Second embodiment>> A software usage status investigation system according to a second embodiment of the present invention will be described. The present invention differs from the software usage status investigation system according to the first embodiment in the following points. The software usage status investigation system according to the second embodiment creates information indicating the usage status of APIs used by each piece of software.

[0179] The following description will focus on this difference.

[0180] Fig. 25 is a diagram illustrating an API management table 2500 held (memorized, stored) by the cloud server 310. As shown in Fig. 25, the API management table 2500 includes ID 2501 and API Name 2502 as columns for storing information (values). In the API management table 2500, information corresponding to each column for managing APIs is associated with each other and stored as row-by-row information (records).

[0181] Specifically, ID 2501 stores identification information (ID) for identifying the corresponding record. API Name 2502 stores the name of the API.

[0182] 26 is a diagram illustrating an example of a log conversion table 2600 held (memorized, stored) by the cloud server 310. Each column of the log conversion table 2600 is the same as that in FIG.

[0183] 27 is a diagram illustrating an API usage aggregation table 2700. The API usage aggregation table 2700 includes columns for storing information (values): ID 2701, Serial ID 2702, Tool ID 2703, and API 2704. In the API usage aggregation table 2700, aggregate information on APIs used by software is stored as information (records) on a row-by-row basis corresponding to each column.

[0184] Specifically, ID 2701 stores identification information (ID) for identifying the corresponding record. Serial ID 2702 stores identification information (Serial ID) of the storage system 130. Tool ID 2703 stores identification information (Tool ID) of the software. API 2704 stores the name of the API. The API usage aggregation table 2700 is created by the log interpretation unit 312, as will be described in detail later.

[0185] 28 is a diagram illustrating an API usage statistics table 2800. The API usage statistics table 2800 includes columns for storing information (values): ID 2801, Tool Name 2802, GAD Creation API 2803, and UR Creation API 2804. In the API usage statistics table 2800, information corresponding to each column relating to statistical information on the usage status of the API of each piece of software is associated with each other and stored as row-by-row information (records). Specifically, ID 2801 stores identification information (ID) for identifying the corresponding record. Tool Name 2802 stores the name of the software. GAD Creation API 2803 stores the number of times the GAD (global-active device) creation API has been called by the corresponding software. UR Creation API 2804 stores the number of times the UR (Universal Replicator) creation API has been called by the corresponding software.

[0186] Fig. 29 is a flowchart showing the processing flow executed by the log interpretation unit 312 and the usage information extraction unit 313. The flowchart in Fig. 29 is the same as the flowchart in Fig. 14 except that the processing of step 1430 has been deleted, step 2910 has been added between step 1425 and step 1440, and step 2920 has been added after step 1445 instead of step 1450. Therefore, the following description will mainly focus on the differences from the flowchart in Fig. 14, and other detailed descriptions will be omitted as appropriate.

[0187] In step 1425, the usage information extraction unit 313 determines whether at least one Tool ID is included in the column of the log conversion table 2600. If no Tool ID is included in the column of the log conversion table 2600, the usage information extraction unit 313 determines "NO" in step 1425, returns to step 1420, and executes the above-described processing again.

[0188] If at least one Tool ID is included in the column of the log conversion table 2600, the usage information extraction unit 313 determines "YES" in step 1425 and proceeds to step 2910. When proceeding to step 2910, the usage information extraction unit 313 updates the API usage tally table 2700 with the Tool ID, the API type corresponding to the Tool ID in the log conversion table 2600, and the serial ID corresponding to the API log 138. Thereafter, the usage information extraction unit 313 proceeds to the processing of step 1445.

[0189] If all log files have been checked in step 1445, the usage information extraction unit 313 determines "YES" in step 1445 and proceeds to step 2920. When the usage information extraction unit 313 proceeds to step 2920, it updates the contents of the API usage aggregation table 2700 in the API usage statistics table 2800, and proceeds to step 2995, where it temporarily ends this processing flow. By executing the above processing, the API usage statistics table 2800 is created from the API log 138.

[0190] Fig. 30 shows an example of a screen created by the usage rate display unit 314. The example of the screen shown in Fig. 30 is a list screen 3000. The list screen 3000 includes a table showing the usage status of each API of each software. The list screen 3000 uses the table to show the number of times each API of each software is used. For example, a record (row) with a table ID of "1" indicates that Management Software A's GAD creation API has been used once, its UR creation API has been used zero times, and its TC (True Copy) creation API has been used three times.

[0191] FIG. 31 shows an example of a screen created by the usage rate display unit 314. The example of the screen shown in FIG. 31 is a transition screen / per function 3100. The transition screen / per function 3100 shows the quarterly transition of the number of times a specific API (in this example, the GAD creation API) of each piece of software is used. The transition screen / per function 3100 includes a line graph. The line graph is a line graph with the horizontal axis representing the quarter and the vertical axis representing the number of times the API is used. Each line in the line graph shows the quarterly transition of the number of times each piece of software uses the API. By checking the screens of FIGS. 30 and 31, the decision maker 410 can identify frequently used APIs, which can lead to activities to improve customer convenience, such as additional development of the API.

[0192] <Effects> As described above, the software usage status investigation system according to the second embodiment can grasp the usage status of each piece of software used in the system without requiring a complicated configuration or procedures, similar to the first embodiment. The software usage status investigation system according to the second embodiment can grasp the usage status of the API provided by the storage system 130 that is used by the software without requiring a complicated configuration or procedures, similar to the second embodiment.

[0193] <<Modifications>> The present invention is not limited to the above-described embodiments, and various modifications can be adopted within the scope of the present invention. Furthermore, the above-described embodiments can be combined with each other without departing from the scope of the present invention.

[0194] 32, when the API call unit 112 receives a Tool ID in response to a request from the higher-level management software 3211, the API call unit 112 may embed the Tool ID of the higher-level management software 3211 in the API request sent to the management processing unit 133 of the storage system 130, instead of the Tool ID of its own management software 111. In this case, the API call unit 112 may embed the Tool ID of its own software in the API request, along with the Tool ID of the higher-level management software 3211.

[0195] The processing flow executed by the API call unit 112 of this modified example is shown in Fig. 33. The API call unit 112 starts processing from step 3300 and proceeds to step 3305, where it checks the sending requirements for the API request. At this time, if the requirements are from another management software 3211, the Tool ID of the other management software 3211 is held.

[0196] Thereafter, the API calling unit 112 proceeds to step 3310 and determines whether the API request to be sent is an API request from another piece of management software 3211 or not.

[0197] If the API request to be sent is an API request from another management software 3211, the API call unit 112 determines "YES" in step 3310 and proceeds to step 3315. In step 3315, the API call unit 112 sends the API request to the management processing unit 133 of the storage system 130, substituting the Tool ID of the other management software as the Tool ID instead of its own Tool ID. Thereafter, the API call unit 112 proceeds to step 3395 and temporarily ends this processing flow.

[0198] On the other hand, if the API request to be sent is not an API request that has come from another management software 3211, the API calling unit 112 determines "NO" in step 3310 and proceeds to step 3330.

[0199] When the API calling unit 112 proceeds to step 3320, it sends an API request using its own Tool ID as the Tool ID to the management processing unit 133 of the storage system 130. After that, the API calling unit 112 proceeds to step 3395 and ends this processing flow.

[0200] According to this modification, when other management software 111 is present between the management software 3211 and the storage system 130, and the management software 111 itself has an API, the API call unit 112 receives a call from the other management software 3211 via the API and issues the API again to the storage system (management processing unit 133). In this case, the API call unit 112 of the management software 111 describes the Tool ID of the caller and sends an API request to the management processing unit 133 so that the management software 3211 that called the API can be identified. As a result, in the storage system 130, the Tool ID of the API caller of the management software 3211 is recorded in the API log 138, so that the API caller can be identified even when other management software 111 is present between the management software 3211 and the storage system 130.

[0201] In each of the above embodiments, the usage information extraction unit 313 may calculate the number of software programs used for each model based on the model usage statistics table 810 and store the calculated number of software programs used for each model as statistical information in the database 316. In this case, the usage rate display unit 314 may create and display a per-model usage count screen 3400 shown in FIG. 34 based on the statistical information. The per-model usage count screen 3400 shows the number of software programs used for each model. According to this modification, the decision maker 410 can identify software programs with high usage rates in the mid-range and high-end ranges using the per-model usage count screen 3400. This allows the decision maker 410 to prioritize user-specific feature development in the management software.

[0202] In each of the above embodiments, the usage information extraction unit 313 may calculate the number of customers using each software program based on the customer usage statistics table 820 and store the calculated number of customers for each software program as statistical information in the database 316. In this case, the usage rate display unit 314 may create and display a customer usage count screen 3500 shown in FIG. 35 based on the statistical information. The customer usage count screen 3500 shows the number of customers using each software program. According to this modification, the decision maker 410 can use the statistical information to analyze customer segments for the management software, leading to improved product value.

[0203] In each of the above embodiments, it is assumed that the API log 138 is output for each API request and that the API type is written therein. In contrast, in the first modified example, the API request path included in the API request and the log JSON file included in the request may also be written to the API log 138. In this case, the API type may be extracted by specifying a specific keyword.

[0204] The present invention may be applied to systems other than the storage system 130. Examples of other systems include a payment system that provides an API, and a content management system that provides an API. The present invention may also have the following configuration.

[0205] A software usage status investigation system including: a system that provides an API and includes a computing device and a storage device; a management server that has software installed therein and that transmits API requests to the system and receives API responses from the system by the operation of the software; and a software usage status investigation device that includes an information processing device, the management server includes identification information of the software in the API request and sends the API request to the system; The computing device of the system stores the API log, in which a record of API access by the software to the API provided by the system is written in such a way that identification information of the software remains, in the storage device; the information processing device acquires the API log from the system and generates information indicating the usage status of the software from the API log; Software usage survey system. [Explanation of symbols]

[0206] Reference Signs List 100... On-premise platform, 110... First management server, 111... Management software, 112... API calling unit, 120... Second management server, 121... External plug-in, 122... API calling unit, 130... Storage system, 131... Storage management unit, 132... Storage data unit, 133... Management processing unit 134...log storage unit, 135...management API reception unit, 136...management execution unit, 137...API log upload unit, 138...API log, 140...host server, 200...first cloud platform, 210...first cloud server, 220...second cloud server, 300...second cloud platform, 310...cloud server, 312...log interpretation unit, 313...usage information extraction unit, 314...usage rate display unit, 315...log storage unit, 316...database, 336...API log upload unit

Claims

1. A software usage status investigation system including: a plurality of systems that provide an API and each include a computing device and a first storage device; a plurality of client servers that have installed therein software that accesses the API via a network and executes functions, and that transmits API requests to the systems and receives API responses from the systems by the operation of the software; and a software usage status investigation device that includes an information processing device, The client server includes identification information of the software in the API request and sends the API request to the system; the computing device of the system records an API log, which is a log regarding API access to the API by the software, such that the API log includes identification information of the software, and stores the API log in the first storage device; the information processing device acquires the API log from the system and creates information indicating the usage status of the software from the API log; Software usage survey system.

2. 2. The software usage status investigation system according to claim 1, the information processing device includes a second storage device; storing the plurality of API logs for each of the plurality of systems acquired from the plurality of systems in the second storage device; acquiring the plurality of API logs for each of the systems for a period to be investigated from the second storage device, and creating information indicating the usage status of the software from the plurality of API logs for each of the systems; Software usage survey system.

3. 3. The software usage status investigation system according to claim 2, the information processing device extracts identification information of the software from the plurality of API logs, and creates information indicating the usage status of the software using the extracted identification information of the software. Software usage survey system.

4. 4. The software usage status investigation system according to claim 3, the APIs provided by the system include a session generation API that generates a session; The information processing device includes: using the extracted identification information of the software, identifying the API access log to the session generation API of the software from the plurality of API logs, and creating information indicating the usage status of the software based on the identified API access log; Software usage survey system.

5. 5. The software usage status investigation system according to claim 4, The information processing device includes: creating information indicating whether the software is being used for each system as information indicating the software usage status based on the identified API access log; Software usage survey system.

6. 6. The software usage status investigation system according to claim 5, The information processing device includes: extracting the software identification information and API type from the API log by dividing the API log using delimiters, creating correspondence information in which the extracted software identification information and API type are associated, and using the software identification information and the correspondence information to identify the API access log to the session generation API of the software in the API log; Software usage survey system.

7. 2. The software usage status investigation system according to claim 1, The information processing device includes: extracting identification information and API types of the software from the API log by dividing the API log using delimiters, creating correspondence information in which the extracted identification information of the software and the API types are associated, tallying the number of calls to the API of the software using the software identification information and the correspondence information, and creating information indicating the usage status of the functions of the software as information indicating the usage status of the software based on the aggregated information; Software usage survey system.

8. 5. The software usage status investigation system according to claim 4, The information processing device includes: creating, as information indicating the software usage status, at least one of the following: a usage rate of the software for the plurality of systems, a transition in the software usage status, the number of customers using the software, and the number of uses of the software for each type of system; Software usage survey system.

9. 2. The software usage status investigation system according to claim 1, the information processing device is connected to a display device, The information processing device includes: displaying a screen including information indicating the usage status of the software on the display device; It was configured as follows: Software usage survey system.

10. 2. The software usage status investigation system according to claim 1, When one of the plurality of client servers receives the API request from another client server through operation of the software of the other client server, the software of the one client server transmits the API request from the other client server to the system and transmits the API response received from the system to the other client server, one of the client servers includes, in the API request to be sent to the system, identification information of the software of the other of the client servers instead of identification information of the software of the one of the client servers, and sends the API request; Software usage survey system.

11. 2. The software usage status investigation system according to claim 1, When one of the plurality of client servers receives the API request from another client server through operation of the software of the other client server, the software of the one client server transmits the API request from the other client server to the system and transmits the API response received from the system to the other client server, one of the client servers includes in the API request to be sent to the system identification information of the software of the one of the client servers as well as identification information of the software of the other of the client servers, and sends the API request; Software usage survey system.

12. 2. The software usage status investigation system according to claim 1, the system is a storage system; Software usage survey system.

13. A software usage status investigation device including an information processing device that investigates the usage status of software that accesses an API provided by a system via a network and executes a function of the software, The information processing device acquires from the system an API log relating to API access to the API by the software to which identification information has been assigned, the API log being recorded so as to include the identification information of the software, and creates information indicating the usage status of the software from the API log. The software usage status investigation device is configured as follows.

14. A software usage status investigation method using an information processing device to investigate the usage status of software that accesses an API provided by a system via a network and executes a function of the software, comprising: A software usage status investigation method in which the information processing device acquires from the system an API log related to API access to the API by the software to which identification information has been assigned, the API log being recorded so as to include the identification information of the software, and creates information indicating the usage status of the software from the API log.

Images