Software usage survey system, software usage survey device, and software usage survey method

Abstract

A software usage survey system that allows for understanding the usage status of each software used in a system without requiring complex configurations or procedures. This invention provides a software usage survey device and a software usage survey method. [Solution] The software usage status survey system comprises a storage system that provides an API, a client server on which the software is installed, and a software usage status survey device. The client server includes the software's identification information in the API request and sends the API request to the storage system. The management processing unit of the storage system records an API log, which is a log of the software's access to the API, so that the software's identification information is included in the API log, and stores the API log in the log holding unit. The software usage status survey device retrieves the API log from the storage system and creates information indicating the software's usage status from the API log.

Description

Technical Field

[0001] The present invention relates to a software usage survey system, a software usage survey device, and a software usage survey method.

Background Art

[0002] Storage vendors provide software such as management software and plugins used for storage products (storage systems) bundled with or free of charge with the storage products. However, storage vendors do not have a mechanism for managing and tracking the usage status and function utilization rates of these software.

[0003] Therefore, it is not possible to distinguish between functions with high customer demand and low functions of software, and it is not possible to perform an appropriate investment allocation according to customer demand for the functions of software based on data (usage status). As a result, functions with high customer value for software have not been expanded and developed. Also, from the user's perspective, additional development of functions with high usage frequency is not prioritized, and functions that users do not use are developed, resulting in no improvement in the usability of the software and its functions and a possible decrease in user satisfaction. Therefore, there is a desire on the part of storage vendors and users to grasp the usage status of each software. Note that such problems and desires also exist in other systems (software used in other systems) other than the storage system.

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

[0005] The software supply device includes 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 the 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 and the access point traversed during the notification, which are notified when the user terminal runs the software, with the contents of the user database. If the user terminal identification information is in the user database and the access point traversed matches the access point identification information in the user database, the server sends software usage permission information to the user terminal and updates the usage history information in the user database. Software vendors can accurately understand the frequency of software usage from the user database, and this information can be used as reference information for future software development.

[0007] Patent Document 2 (Japanese Patent Publication No. 2021-174129) discloses an API billing system that uses an API connection platform to record the history of requests from an application to an API (Application Programming Interface) from an application to 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 (Japanese Patent Publication No. 2019-96060) discloses an API billing system in which an API management device stores a history of requests and responses to a single API for each of multiple applications that use a single API, and a billing management device determines the billing value for an application that uses a single API based on the billing conditions when using the single API and the history information obtained from the API management device. [Prior art documents] [Patent Documents]

[0009] [Patent Document 1] Japanese Patent Publication No. 2001-306314 [Patent Document 2] Japanese Patent Publication No. 2021-174129 [Patent Document 3] Japanese Patent Publication No. 2019-96060 [Overview of the project] [Problems that the invention aims to solve]

[0010] The present inventor is considering a novel software usage survey device for understanding the usage status of each software used in a system (e.g., a storage system).

[0011] Users of a system that utilizes a REST API use various software on terminals 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 performs operations on the system using the API, thereby executing the functions implemented in each software.

[0012] REST APIs use session-based user authentication. When a REST API client accesses a REST API server and begins operations on the system, it first calls the system's session creation API and authenticates the user using the user information (user ID and password) required to access the system.

[0013] However, since REST API clients (software) are not assigned individual identifiers (identification information), the system cannot determine which REST API client (software) is calling the API. Therefore, although it is possible to know that a user is performing some operation using the system's API (REST API Server), it is not possible to aggregate the number of API calls for each software or the usage of each function, and thus the usage status of each software cannot be grasped. While it is possible to aggregate software usage status by collecting logs on the user's device running the software, in this case, the logs are managed by the software and are not centralized, so collecting logs is time-consuming, making the configuration and procedures complicated.

[0014] The software management method described in Patent Document 1 requires the management of user terminal identification information and access point identification information, as well as processing using these, resulting in a complex configuration and procedure. Patent Documents 2 and 3 do not describe the present invention, which involves obtaining API audit logs from the system that record API access to the system-side API of software to which identification information has been assigned, so as to retain the identification information of the software that accessed the API, and generating information indicating the software usage status from the API audit logs.

[0015] One of the objectives of the present invention is to provide a software usage status survey system, a software usage status survey device, and a software usage status survey method that can grasp the usage status of each software used in a system without requiring a complicated configuration and procedure. [Means for solving the problem]

[0016] To solve the above problems, the software usage status investigation system of the present invention comprises: a plurality of systems that provide an API and each system has a computing device and a first storage device; a plurality of client servers on which software is installed to access the API via a network and perform functions, and which send API requests to the systems and receive API responses from the systems through the operation of the software; and a software usage status investigation device including an information processing device. The client servers send the API requests to the systems, including the identification information of the software in the API requests; the computing device of the systems records API logs, which are logs of API access to the API by the software, such that the identification information of the software is included in the API logs; stores the API logs in the first storage device; and the information processing device retrieves the API logs from the systems and creates information indicating the usage status of the software from the API logs.

[0017] The software usage status investigation device of the present invention 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 functions of the software, wherein the information processing device is configured to acquire from the system an API log relating to API access to the API by the software to which identification information has been assigned, and which is recorded so as to include the identification information of the software, and to create information indicating the usage status of the software from the API log.

[0018] The software usage survey method of the present invention is a software usage survey method using an information processing apparatus that surveys the usage status of software by accessing an API provided by a system via a network and executing the functions of the software. The information processing apparatus obtains, from the system, an API log regarding API access to the API by the software to which identification information is assigned and in which the identification information of the software is included, and creates information indicating the usage status of the software from the API log.

Advantages of the Invention

[0019] According to the present invention, it is possible to grasp the usage status of each software used for the system without requiring a complicated configuration and procedure. Note that the effects described here are not necessarily limited, and any of the effects described in the present disclosure may be applicable.

Brief Description of the Drawings

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

[0021] Hereinafter, embodiments 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 terms such as "table," "record," "row," "column," and "section," but these types of information may also be represented using other data structures. When describing identification information, terms such as "ID" and "name" will be used, but these are interchangeable and can also be replaced with other expressions of identification information.

[0023] In the following explanation, the processing may be described using a functional block as the subject, but the subject of the processing may also be the CPU or device instead of the functional block. The main entity performing the processing by executing the program can be the arithmetic unit, and may include dedicated circuits that perform specific processing. Here, dedicated circuits include, for example, FPGAs (Field Programmable Gate Arrays), ASICs (Application Specific Integrated Circuits), CPLDs (Complex Programmable Logic Devices), etc.

[0024] <<First Embodiment>> A software usage status survey system according to the first embodiment of the present invention will now be described. Figure 1A is a diagram showing an example configuration of the software usage status survey system according to the first embodiment. As shown in Figure 1A, the software usage status survey system includes a plurality of customer system infrastructures 1000a1 to 1000aN and a second cloud infrastructure 300. These are connected to each other via a network so that they can send and receive information (data). Hereinafter, the plurality of customer system infrastructures 1000a1 to 1000aN may be referred to as "customer system infrastructure 1000a" when there is no need to particularly distinguish between them. The plurality of customer system infrastructures 1000a may be customer system infrastructures 1000a of different customers, or two or more of them may be customer system infrastructures 1000a of the same customer. In this example, customer system infrastructure 1000a is a system infrastructure including a storage system. Customer system infrastructure 1000a includes a storage system that provides an API, a host server, and a client server on 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 customer system infrastructure 1000a, details of customer system infrastructure 1000a1 are shown in Figure 1B below, but the configuration of customer system infrastructure 1000a is not limited to this.

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

[0026] The on-premises infrastructure 100 has a computer system built in an on-premises environment. The computer system includes a first management server 110 and 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 installed on the first management server 110. The first management server 110 executes the management software 111. The management software 111 includes an API calling unit 112. The API calling 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 requests to perform operations such as retrieving, saving, updating, and deleting data from the storage system 130. The request construction function constructs requests by combining endpoints, HTTP methods, parameters, etc. The request construction function constructs requests so as to further include the Tool ID assigned to the management software 111. For example, the request construction function includes the Tool ID in the request by including an argument to input the Tool ID in the API request header or body, including an argument to input the Tool ID in the request body (e.g., a JSON file), and passing a specific Tool ID as an argument.

[0029] The authentication management function manages authentication information such as API keys and tokens and applies it to requests. The error handling function handles error messages and retries in the event of a failed API call. The response processing function parses the response from the API and extracts the necessary data.

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

[0031] The second management server 120 has an external plugin 121 installed. The second management server 120 executes the external plugin 121 of the storage system 130. The external plugin 121 is software for extending the functionality of the storage system 130. The external plugin 121 includes an API calling unit 122 that has the same functionality as the management software 111. In this example, the name of the external plugin 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). Through the management processing unit 133, clients can perform operations such as data retrieval, storage, updating, and deletion via APIs.

[0034] The management API reception unit 135 exposes API endpoints that allow clients to access specific functions and resources provided by the API in order to manipulate data. The management API reception unit 135 receives requests from clients, and after the management execution unit 136 performs appropriate processing according to the request, it returns a response to the client. For example, in response to a data retrieval request, it returns the specified data.

[0035] The management execution unit 136 performs appropriate processing in response to requests. The management execution unit 136 also performs access control related to API usage. The management execution unit 136 verifies client authentication and restrictions on access to resources. The management execution unit 136 converts the format of request data and response data from clients as needed (for example, converting JSON data to XML format). The management execution unit 136 records API logs 138, which are logs 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 holding unit 134 holds (remembers, stores) the API log 138.

[0038] The storage data section 132 includes a volume. The volume is provided to the host server 140.

[0039] The host server 140 is a computer (server device) that issues I / O requests. 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). Volumes are provided to the host server 140 from the storage data unit 132. The host server 140 recognizes the volumes when they are mounted on the host.

[0040] The first cloud infrastructure 200 is a cloud capable of providing resource provision services on the first cloud infrastructure 200. The first cloud infrastructure 200 includes the first cloud server 210 and the second cloud server 220 provided by the resource provision service. The first management server 110 and the second management server 120, as well as the first cloud server 210 and the second cloud server 220, described above, will be referred to as "client servers" unless there is a need to distinguish between them.

[0041] The first cloud server 210 manages the storage system 130. Management software 211 is installed on the first cloud server 210. The first cloud server 210 runs the management software 211. The management software 211 includes an API calling unit 212. The API calling unit 212 has the same functions as the API calling 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] The second cloud server 220 has an external plugin 221 installed. The second cloud server 220 runs the external plugin 221 of the storage system 130. The external plugin 221 is software for extending the functionality of the storage system 130. The external plugin 221 includes an API calling unit 222 that has similar functionality to the management software 111. In this example, the name of the external plugin 221 is "Plug-In B" and the Tool ID is "s88fwajdasua".

[0043] The second cloud infrastructure 300 is a cloud capable of providing resource provision services on the second cloud infrastructure 300, and includes cloud servers 310 provided by the resource provision services.

[0044] The cloud server 310 is sometimes referred to as a "software usage status survey device." The 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. The log interpretation unit 312 obtains API logs 138 from the log storage unit 134 and creates a log conversion table 600. The usage information extraction unit 313 creates a usage summary table 700 and a usage statistics table 800 from the log conversion table 600. Furthermore, the usage information extraction unit 313 creates a model usage statistics table 810 and a customer usage statistics table 820. The usage rate display unit 314 creates a display screen (image) based on the usage statistics table 800, etc., and displays it on the display.

[0045] The log storage unit 315 includes the API log 138. The API log 138 is uploaded from the API log upload unit 137 and stored (remembered, stored) in the log storage unit 134.

[0046] Database 316 includes the Tool ID Management Table 500, the Serial ID Model Correspondence Table 510, the Serial ID Customer Correspondence Table 520, the Log Conversion Table 600, the Usage Aggregation Table 700, the Usage Statistics Table 800, the Model Usage Statistics Table 810, and the Customer Usage Statistics Table 820. Details of these tables will be described later.

[0047] <Hardware Configuration> Figure 2 is a block diagram showing an example of the hardware configuration of the storage system 130. The storage system 130 has multiple (or one) physical storage devices, which are 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 memory modules 25, and two processors 26 connected to them.

[0049] I / F23 is a communication interface device that mediates data exchange between an external device (e.g., a host server 140) and the storage controller 22. The host server 140 is connected to I / F23 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] I / F24 is a communication interface device that mediates data exchange between multiple PDEV21 and the storage controller 22. Multiple PDEV21 are connected to I / F24.

[0052] Memory 25 stores the program that the processor 26 will execute and the data that the processor 26 will use. The processor 26 executes the program stored in memory 25. In this example, the memory 25 and processor 26 pair is duplicated.

[0053] GUM (Gateway for Unified Management) 28 is a computer that has the basic management functions of the storage system 130. When managing the storage system 130 from the outside, communication is made with 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 Figure 3 below). The management processing unit 133 is composed of programs stored in the ROM and / or storage device. The log holding unit 134 is composed of a storage device.

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

[0055] The ROM 32 and / or storage device 34 hold (store, keep) 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 the program stored in the ROM 32 and / or storage device 34 into the RAM 33. The CPU 31 then executes the program loaded into the RAM 33 to realize the various functions of the information processing device 30.

[0057] As mentioned above, RAM33 is loaded with the program that CPU31 will execute, and it temporarily stores the data that CPU31 uses when executing the program.

[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 operating devices such as a keyboard and mouse, as well as a display.

[0059] Furthermore, at least a portion of the processing performed by the CPU31 when executing a program may be performed by other arithmetic units (e.g., hardware such as ASICs or FPGAs).

[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 composed of programs stored in the ROM 32 and / or the storage device 34. The log retention unit 315 is composed of the storage device 34. The database 316 is stored in the storage device 34.

[0061] Figure 4A is a diagram illustrating the format of the API log 138. The API log 138 is a log related to the software's API access (e.g., operation log, audit log, API access log, etc.) and is recorded for each API request. Figure 4A shows the API log 138 for a single API request. The API log 138 includes at least the date and time 401 when the API was called, the type of API called (API type 402), and the calling Tool ID 403. The API log 138 may also include optional items such as the IP address 404 of the operator (caller), the operation result 405 (Success or Fail), Serial ID 406, and authentication information 403.

[0062] Figure 4B shows an example of 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 file name includes the Serial ID of the storage system 130.

[0063] Figure 5A is a diagram illustrating the Tool ID Management Table 500. The Tool ID Management Table 500 includes ID 501, Tool Name 502, and Tool ID 503 as columns for storing information (values). The Tool ID Management Table 500 stores information corresponding to each column for managing the software whose usage is being investigated, with each column associated with the others, as row-level information (records).

[0064] Specifically, ID501 stores identification information (ID) to identify the corresponding record. Tool Name502 stores the name of the software. Tool ID503 stores the Tool ID, which is the software's identification information.

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

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

[0067] Figure 5C is a diagram illustrating the Serial ID Customer Correspondence Table 520. The Serial ID Customer Correspondence Table 520 includes Customer ID 521 and Serial ID 522 as columns for storing information (values). The Serial ID Customer Correspondence Table 520 stores information corresponding to each column for managing the storage system 130 used by the customer, with each column associated with the others, as row-level information (records).

[0068] Specifically, Customer ID 521 stores identification information (Customer ID) for identifying the customer. Serial ID 522 stores identification information (Serial ID) for the storage system 130.

[0069] Figure 6 is a diagram illustrating the log conversion table 600. The log conversion table 600 includes the following columns for storing information (values): ID601, 1st602, 2nd603, API604, 4ht605, and Tool ID606. Note that between 4ht605 and Tool ID606, there are 1st602, 2nd603, and several other columns similar to those in 4ht605, but these are omitted from the diagram.

[0070] Log conversion table 600 stores the API log 138 as row-level information (records), with each column corresponding to a string unit, which is created by separating the text of the API log 138 using delimiters, and the information is associated with each other.

[0071] Specifically, ID601 stores identification information (ID) to identify the corresponding record. 1st602, 2nd603, 4ht605, and several other columns (not shown) each store a string separated by a delimiter. API604 stores a string indicating the type of API (API name). Tool ID606 stores the Tool ID, which is the software identification information. As will be described in more detail later, the log conversion table 600 is created from the API log 138 by the log interpretation unit 312. Note that a single record is information obtained by separating the text of the API log 138 written by a single API request using a delimiter, and storing these multiple strings in each column.

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

[0073] The usage summary table 700 stores information corresponding to each column of the aggregated software usage data as row-level information (records). Specifically, ID 701 stores identification information (ID) to identify the corresponding record. Serial ID 702 stores the identification information (Serial ID) of the storage system 130. Tool ID 703 stores the Tool ID, which is the software identification information. As will be described in more detail later, the usage summary table 700 is created by the usage information extraction unit 313 based on the log conversion table 600.

[0074] Figure 8A is a diagram illustrating the usage statistics table 800. The usage statistics table 800 includes the following columns for storing information (values): Serial ID 801, mms345g7jf56802, jjuh786s39ik803, s88fwajdasua804, and s88fwasgggg805. The usage statistics table 800 stores information corresponding to each column regarding software usage statistics as row-level information (records), with each column being associated with the others.

[0075] Specifically, Serial ID 801 stores the identification information (Serial ID) of storage system 130. mms345g7jf56802 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] jjuh786s39ik803 stores information indicating whether the software with Tool ID "jjuh786s39ik" is being used for the corresponding storage system 130. s88fwajdasua804 stores information indicating whether the software with Tool ID "s88fwajdasua" is being used for the corresponding storage system 130. s88fwasgggg805 stores information indicating whether the software with Tool ID "s88fwasgggg" is being used for the corresponding storage system 130. These are created by the usage information extraction unit 313 based on the usage summary table 700.

[0077] Figure 8B is a diagram illustrating the Model Utilization Statistics Table 810. The Model Utilization Statistics Table 810 includes the following columns for storing information (values): Serial ID 811, Model 812, mms345g7jf56813, jjuh786s39ik814, s88fwajdasua815, and s88fwasgggg816. The Model Utilization Statistics Table 810 stores information corresponding to each column regarding software usage statistics as row-level information, with each column being associated with the others.

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

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

[0080] Specifically, Serial ID 821 stores the identification information (Serial ID) of the storage system 130. Customer ID 822 stores the identification information (Customer ID) for identifying the customer. mms345g7jf56823 stores information indicating whether the software with Tool ID "mms345g7jf56" is being used for the corresponding storage system 130. jjuh786s39ik824 stores information indicating whether the software with Tool ID "jjuh786s39ik" is being used for the corresponding storage system 130. s88fwajdasua825 stores information indicating whether the software with Tool ID "s88fwajdasua" is being used for the corresponding storage system 130. s88fwasgggg826 stores information indicating whether the software with Tool ID "s88fwasgggg" is being used for the corresponding storage system 130.

[0081] <Operation> This section describes how each client-server software in the system operates when calling APIs. Each function implemented in each software is internally realized by calling APIs on the storage system 130 side.

[0082] In this example, the API provided by the storage system 130 may be a REST API. In this case, the storage system 130 provides a Web API that follows the principles of REST (Representational State Transfer) for obtaining information and changing the configuration of the storage system 130. In this case, the management processing unit 133 corresponds to a REST API Server, and the API calling unit 112, API calling unit 122, and API calling unit 213 each correspond to an API Client.

[0083] Using Figures 9 and 10, an example of how the software operates when using an API will be explained. The management processing unit 133 is located on the GUM28 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 a 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 plugin 121, issues a request to the storage system 130, and sends the execution result back to the API calling unit 122 as a response.

[0085] The management processing unit 133 receives a request from the API calling unit 222 of the external plugin 221, issues a request to the storage system 130, and sends the execution result as a response to the API calling unit 212.

[0086] In the following explanation, the operation of the API calling unit 112 of the management software 111 will be used as an example. The operation of the API calling unit 122 of the external plugin 121 and the API calling unit 222 of the external plugin 221 are the same as the operation of the API calling unit 112 of the management software 111, so their explanation will be omitted.

[0087] When the API calling unit 112 performs an operation on the storage system 130, user authentication is required. This system uses session-based user authentication. When the API calling unit 112 accesses the management processing unit 133 and starts an operation, this system always first creates a session. The session is created by executing the session creation API in response to a session creation API request from the API calling unit 112. The session creation API request includes the user ID, password, and TooI ID. As previously described, the TooI ID is the ID of the software (in this case, the software that issues the session creation API request).

[0088] The session creation request performs authentication using a user ID and password to access the storage system 130 (S1001 in Figure 10). Once the session is created (established), the API call unit 112 is provided with a Session ID and Session Token as a response (S1002 in Figure 10).

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

[0090] The management processing unit 133 writes and saves the API log 138 to the log holding unit 134 for each API call.

[0091] <Comparison with conventional technology> Here, we will explain the operation of conventional software when calling an API and compare it with the present invention. In the conventional technology, as with the present invention, a common user ID is used for user authentication when the initial session is created (the process corresponding to S1001 in Figure 10). However, in the conventional technology, as shown in Figure 11, the API caller does not have an individual identifier (Tool ID), so it was not possible to identify the API caller. Therefore, although it is possible to know that the software corresponding to the user ID is performing some operation by using the management processing unit 133 on the storage system 130, it is not possible to know which software is calling the API, and thus the storage system 130 could not aggregate the number of API calls per software or the number of times each function is used per software. In the conventional technology, it is possible to aggregate the number of API calls per software and the number of times each function (API) is used per software by collecting logs on the software side, but the configuration and procedure would be considerably complicated.

[0092] Therefore, in this invention, a Tool ID is assigned to each software, and when external software calls the API provided by the storage system 130, it adds (embeds) the Tool ID to the API request, and the storage system 130 (management processing unit 133) that receives the API request writes the Tool ID to the API log 138. As a result, based on the Tool ID written in the log, the Tool ID can be extracted from the API log 138, and information for analyzing the usage status of each software in the storage system 130 can be compiled on the storage system 130 side without requiring complicated configurations and procedures.

[0093] <System-wide operation> Figure 12 is a sequence diagram illustrating the operation of each element of the system.

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

[0095] S1202: The API calling unit 112 (management software 111) generates an API request corresponding to a specific operation. As previously described, the API request includes a Tool ID. The API calling unit 112 (management software 111) sends the API request to the management API receiving 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 previously described, the API log 138 is written to the log storage unit 134 in such a way that it includes the Tool ID.

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

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

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

[0101] As a result of the above operations, the management execution unit 136 writes an API log 138 to the log holding unit 134 for each API call. The log holding unit 134 retains (remembers, stores) the API log 138.

[0102] Figure 13 is a sequence diagram illustrating the operation of each element of the system.

[0103] S1301: The API log upload unit 137 periodically (once a day in this example (once at a predetermined time)) retrieves the API logs 138 that are stored (remembered, stored) in the log retention unit 134. As a result, daily logs are imported into the API log upload unit 137 in file format.

[0104] S1302: The API log upload unit 137 uploads the API log 138 in file format to the log storage unit 315 of the second cloud infrastructure 300. The log storage unit 315 stores (remembers, stores) the API log 138 in 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 the usage summary table 700 and the 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 the 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 the 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 (retrieves) the information necessary for screen display (e.g., utilization rate) from the utilization statistics table 800.

[0107] S1305: The decision-maker 410 can understand the software usage status (such as the number of storage systems 130 using the software) by looking at the screen provided by the utilization rate display unit 314.

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

[0109] When a predetermined time arrives, the log interpretation unit 312 starts processing from step 1400 and executes the processes described in steps 1405 to 1415 below.

[0110] Step 1405: The log interpretation unit 312 retrieves daily log files (API logs 138) for each of the multiple storage devices under investigation.

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

[0112] Step 1415: The log interpretation unit 312 splits the selected log file (API log 138) using a delimiter and converts it into a log conversion table 600. It then assigns the name of the log conversion table 600, which includes the Serial ID of the storage system 130 corresponding to the selected log file, as [LogDB_serial id] (the Serial ID of the storage system 130 is substituted for serial id), and saves (manages) the log conversion table. 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] When the user information extraction unit 313 proceeds to step 1425, it determines whether or not the Tool ID selected in step 1420 is included in at least one column (Tool ID 604) of the log conversion table 600.

[0115] If none of the Tool IDs selected in step 1420 are included in the column (Tool ID 604) of the log conversion table 600, the usage information extraction unit 313 determines "NO" in step 1425 and 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 the Tool ID selected in step 1420 is included in at least one 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] When the user information extraction unit 313 proceeds to step 1430, it 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. If the Tool ID is included multiple times in the log conversion table column (Tool ID 604), this determination is made for each log (record) corresponding to each of the multiple Tool IDs.

[0118] If none of the logs (records) corresponding to any of the Tool IDs are Session API logs, the usage information extraction unit 313 determines "NO" in step 1430 and 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 at least one log (record) corresponding to a 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 reflects the Serial ID and Tool ID in the usage summary table 700. The usage summary table 700 is assigned the name [SW Usage Summary_yyyymmdd]. The "yyyymmdd" part of the name is replaced with the date the summary was performed.

[0121] When the usage information extraction unit 313 proceeds to step 1440, it determines whether all Tool IDs in the Tool ID management table 500 (Tool ID correspondence table) have been checked (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 checked (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 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 all log files (API logs 138) acquired in step 1405 have been reviewed (selected). If not all log files have been reviewed (selected), the usage information extraction unit 313 determines "NO" in step 1445 and 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 determines "YES" in step 1445, executes the process in step 1450 described below, and then proceeds to step 1495 to terminate this processing flow.

[0126] Step 1450: The usage information extraction unit 313 reflects the contents of the usage summary table 700 into the usage statistics table 800. The usage statistics table 800 is assigned the name [SW Usage Statistics_yyyymmdd]. The "yyyymmdd" part of the name is replaced with the date the statistics were compiled.

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

[0128] Statistical screen 1500 includes four pie charts and a bar graph. The four pie charts show the software utilization rates for Management Software A, Management Software B, Plug-In A, and Plug-In B. Software utilization 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 software.

[0129] Furthermore, the decision-maker 410's terminal (not shown) can access the web page hosted on the cloud server 310 via a browser, thereby displaying the web page (statistical screen 1500 in Figure 15) on the terminal's (not shown) display (the same applies to the screens in Figures 16 to 19 described later). By checking the statistical screen 1500 in Figure 5, the decision-maker 410 can determine which software has a high usage rate, which helps in data-driven decision-making regarding unused software (functions), such as conducting interviews focused on unused software (functions), eliminating functions, or making additional investments (the same applies to the screens in Figures 15 to 19 below).

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

[0131] Individual screen 1600 includes a table, a pie chart, a frame, and a line graph. The table shows the results of an analysis of the software utilization rate of a specific software (Plug-In A in this example). The table shows the trends and return on investment for the specific software. The pie chart shows the software utilization rate of the specific software. The frame shows the MR (Midrange Model) occupancy rate and the HE (High End Model) occupancy rate for the specific software within that frame. The MR occupancy rate shows the occupancy rate (percentage) of MR storage systems 130 relative to the total number of storage systems using the software. The HE occupancy rate shows the occupancy rate (percentage) of HE storage systems 130 relative to the total number of storage systems using the software. The line graph is a line graph with quarters on the horizontal axis and the number of storage units on the vertical axis. The line in the line graph shows the trend of the number of storage units using the specific software on a quarterly basis.

[0132] Figure 17 shows an example of a screen created by the utilization rate display unit 314. The example screen shown in Figure 17 is the trend screen 1700. The trend screen 1700 shows the trend in the usage status of each software on a quarterly basis. The trend screen 1700 includes a line graph. The line graph has quarters on the horizontal axis and the number of storage units on the vertical axis. Each line in the line graph shows the trend in the number of storage units used for each software on a quarterly basis.

[0133] Figure 18 shows an example of a screen created by the utilization rate display unit 314. The example screen shown in Figure 18 is the list screen 1800. The list screen 1800 includes a table showing the usage status of each software for each storage system 130. The table displays a checked checkbox indicating whether each software is in use in the field corresponding to the software name on the same row as the storage ID. Thus, the table shows whether the software for the storage system 130 indicated by the storage ID is in use during the survey period (in this example, one day on a specific date).

[0134] Figure 19 shows an example of a screen created by the utilization rate display unit 314. The example screen shown in Figure 19 is the 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 for each storage system 130 and the usage status of each software 30 days prior to that specific date. The table displays a checked box indicating that each software is in use in the field corresponding to each software name on the same row as the storage ID. Furthermore, it displays a checked box indicating that each software was in use 30 days prior to that date in the field corresponding to each software name on the same row as the storage ID. Thus, the table shows whether the software was used during the survey period (in this example, the 1st of a specific date) and whether the software was used 30 days prior to that date. The user can check from the table whether the software has recently started to be used.

[0135] Figure 20 is a diagram illustrating the processing flow performed by the utilization rate display unit 314. This processing flow is for rendering the statistics screen 1500 of Figure 15 onto a web page. The utilization rate display unit 314 starts processing from step 2000 and sequentially executes the processes described below in steps 2005 to 2015.

[0136] Step 2005: The utilization rate display unit 314 acquires the statistical data (utilization statistics table 800 in Figure 8A) necessary for creating the statistics screen 1500 in Figure 15.

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

[0138] Step 2015: The utilization rate display unit 314 aggregates the number of uses (number of storage systems used) for each software by summing the Serial IDs. Based on this, the utilization rate display unit 314 calculates the number of uses for each storage system 130 for each software.

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

[0140] Step 2020: The utilization rate display unit 314 calculates the software utilization rate by dividing the aggregated sum by the total number of Serial IDs.

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

[0142] Step 2030: The utilization rate display unit 314 creates a line graph representing the overall software usage trend, and then proceeds to step 2035.

[0143] When the utilization rate display unit 314 proceeds to step 2035, it creates the statistics screen 1500. Next, the utilization rate display unit 314 proceeds to step 2040, renders the statistics screen 1500 on the web page, and then proceeds to step 2095 to terminate this processing flow.

[0144] Figure 21 is a diagram illustrating the processing flow executed by the utilization rate display unit 314. This processing flow is for rendering the individual screen 1600 in Figure 16 onto a web page. The utilization rate display unit 314 starts processing from step 2100 and then sequentially executes the processes in steps 2105 and 2010 described below.

[0145] Step 2105: The utilization rate display unit 314 acquires the statistical data (utilization statistics table 800 in Figure 8A) necessary for creating the individual screen 1600 in Figure 16.

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

[0147] The utilization rate display unit 314 executes steps 2115 and 2120, steps 2125 and 2130, and steps 2135 to 2145 in parallel, 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 representing the trend in the use of the target software (the trend in the number of storage systems used).

[0150] Step 2125: The utilization rate display unit 314 aggregates the number of uses of the target software from the model utilization statistics table 810 in Figure 8B as the sum of the serial IDs.

[0151] Step 2130: The utilization rate display unit 314 aggregates the share of the total number of Serial IDs for each Midrange model price range (= sum of Serial IDs for the Midrange model price range / sum of Serial IDs) and the share of the HighEnd model price range (= sum of Serial IDs for the HighEnd model price range / sum of Serial IDs).

[0152] Step 2135: The utilization rate display unit 314 aggregates the number of uses of the target software by summing the serial IDs.

[0153] Step 2140: The utilization rate display unit 314 calculates the utilization rate (percentage) by dividing the aggregated sum by the total number of Serial IDs.

[0154] Step 2145: The utilization rate display unit 314 creates a pie chart representing the percentage of software usage in the target software.

[0155] When the utilization rate display unit 314 proceeds to step 2150, it creates the individual screen 1600 shown in Figure 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 that is not shown. Next, the utilization rate display unit 314 proceeds to step 2155, renders the individual screen 1600 on a web page, and then proceeds to step 2195 to terminate 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 for rendering the progress screen 1700 of Figure 17 onto a web page. The utilization rate display unit 314 starts processing from step 2200, and after sequentially executing the processes from steps 2205 to 2230 described below, proceeds to step 2295 and terminates this processing flow.

[0157] Step 2205: The utilization rate display unit 314 acquires the statistical data (utilization statistics table 800) necessary for creating the trend screen 1700 shown in Figure 17.

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

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

[0160] Step 2220: The utilization rate display unit 314 creates a line graph representing the usage trends of each target software.

[0161] Step 2225: The utilization rate display unit 314 creates the trend screen 1700 shown in Figure 17.

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

[0163] Figure 23 is a diagram illustrating the processing flow executed by the utilization rate display unit 314. This processing flow is for rendering the list screen 1800 from Figure 18 onto a web page. The utilization rate display unit 314 starts processing from step 2300, and after sequentially executing the processes from steps 2305 to 2330 described below, proceeds to step 2295 to terminate this processing flow.

[0164] Step 2305: The utilization rate display unit 314 obtains the statistical data (utilization statistics table 800) necessary for creating the list screen 1800 shown in Figure 18.

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

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

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

[0168] Step 2325: The utilization rate display unit 314 creates the list screen 1800 shown in Figure 18.

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

[0170] Figure 24 is a diagram illustrating the processing flow executed by the utilization rate display unit 314. This processing flow is for rendering the list screen (past comparison) 1900 of Figure 19 onto a web page. The utilization rate display unit 314 starts processing from step 2400, and after sequentially executing the processes described below in steps 2405 to 2435, proceeds to step 2495 and terminates this processing flow.

[0171] Step 2405: The utilization rate display unit 314 acquires the statistical data (utilization statistics table 800) necessary for creating the list screen (past comparison) 1900 shown in Figure 19.

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

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

[0174] Step 2420: The utilization rate display unit 314 converts the value "Active" for each software in the utilization statistics table 800 for past days prior to the target date (e.g., 30 days prior) into an icon such as a checked checkbox. Step 2425: The utilization rate display unit 314 creates the utilization statistics table 800 (i.e., the table in Figure 19) for the most recent day and past days.

[0175] Step 2430: The utilization rate display unit 314 creates the list screen (past comparison) 1900 shown in Figure 19.

[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 survey system according to the first embodiment can grasp the usage status of each software used in the system without requiring a complicated configuration or procedure.

[0178] <<Second Embodiment>> The software usage survey system according to the second embodiment of the present invention will now be described. The present invention differs from the software usage survey system according to the first embodiment in the following respects. The software usage survey system according to the second embodiment generates information showing the usage status of the APIs used by each software.

[0179] The following explanation will focus on these differences.

[0180] Figure 25 is a diagram illustrating the API management table 2500 maintained (stored, stored) by the cloud server 310. As shown in Figure 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-level information (records).

[0181] Specifically, ID2501 stores identification information (ID) to identify the corresponding record. API Name2502 stores the name of the API.

[0182] Figure 26 is a diagram illustrating an example of a log conversion table 2600 maintained (stored) by the cloud server 310. Each column of the log conversion table 2600 is the same as in Figure 6.

[0183] Figure 27 is a diagram illustrating the API usage summary table 2700. The API usage summary table 2700 includes ID 2701, Serial ID 2702, Tool ID 2703, and API 2704 as columns for storing information (values). The API usage summary table 2700 stores information (records) in rows corresponding to each column regarding the summary information of APIs used by the software.

[0184] Specifically, ID2701 stores identification information (ID) to identify the corresponding record. Serial ID2702 stores the identification information (Serial ID) of the storage system 130. Tool ID2703 stores the identification information (Tool ID) of the software. API2704 stores the name of the API. As will be explained in more detail later, the API usage summary table 2700 is created by the log interpretation unit 312.

[0185] Figure 28 is a diagram illustrating the API usage statistics table 2800. The API usage statistics table 2800 includes the following columns for storing information (values): ID 2801, Tool Name 2802, GAD creation API 2803, and UR creation API 2804. The API usage statistics table 2800 stores information corresponding to each column regarding the statistical information of API usage for each software, with each column associated with the others, as row-level information (records). Specifically, ID2801 stores identification information (ID) to identify the corresponding record. Tool Name2802 stores the name of the software. GAD Creation API2803 stores the number of times the GAD (global-active device) creation API has been called by the corresponding software. UR Creation API2804 stores the number of times the UR (Universal Replicator) creation API has been called by the corresponding software.

[0186] Figure 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 Figure 29 is the same as the flowchart in Figure 14, except that the processing in step 1430 is deleted, step 2910 is added between steps 1425 and 1440, and step 2920 is added after step 1445 in place of step 1450. Therefore, the following explanation will focus on the differences from the flowchart in Figure 14, and other details will be omitted as appropriate.

[0187] In step 1425, the usage information extraction unit 313 determines whether or not the Tool ID is included in at least one column of the log conversion table 2600. If the Tool ID is not included in any column of the log conversion table 2600, the usage information extraction unit 313 determines "NO" in step 1425 and returns to step 1420, where it executes the previously described process again.

[0188] If the Tool ID is included in at least one column of the log conversion table 2600, the usage information extraction unit 313 determines "YES" in step 1425 and proceeds to step 2910. In step 2910, the usage information extraction unit 313 reflects 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 in the API usage summary table 2700. After that, the usage information extraction unit 313 proceeds to the processing in 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 reflects the contents of the API usage summary table 2700 into the API usage statistics table 2800 and proceeds to step 2995 to terminate this processing flow. As a result of the execution of the above processes, the API usage statistics table 2800 is created from the API log 138.

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

[0191] Figure 31 shows an example of a screen created by the utilization rate display unit 314. The example screen shown in Figure 31 is the Trend Screen / Function-Specific 3100. The Trend Screen / Function-Specific 3100 shows the quarterly trend in the number of times a specific API (in this example, the GAD creation API) is used for each software. The Trend Screen / Function-Specific 3100 includes a line graph. The line graph has quarters on the horizontal axis and the number of API uses on the vertical axis. Each line in the line graph shows the quarterly trend in the number of times each software uses the API. By checking the screens in Figures 30 and 31, the decision-maker 410 can identify frequently used APIs and use this information to improve customer convenience, such as by developing additional APIs for those APIs.

[0192] <Effects> As described above, the software usage status survey system according to the second embodiment, like the first embodiment, can grasp the usage status of each software used on the system without requiring a complicated configuration and procedure. The software usage status survey system according to the second embodiment, like the second embodiment, can grasp the usage status of APIs provided by the storage system 130 used by the software without requiring a complicated configuration and procedure.

[0193] <<Variation>> The present invention is not limited to the embodiments described above, and various modifications can be adopted within the scope of the invention. Furthermore, the embodiments described above can be combined with each other as long as they do not depart from the scope of the invention.

[0194] In each embodiment of the present invention, as shown in Figure 32, when the API calling unit 112 receives a request from the higher-level management software 3211 and receives a Tool ID, it may embed the Tool ID of the higher-level management software 3211 in the API request 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 calling unit 112 may embed the Tool ID of its own software together with the Tool ID of the higher-level management software 3211 in the API request.

[0195] Figure 33 shows the processing flow executed by the API calling unit 112 in this modified example. The API calling unit 112 starts processing from step 3300 and proceeds to step 3305 to confirm the requirements for sending the API request. At this time, if the requirement is from another management software 3211, it retains the Tool ID of the other management software 3211.

[0196] Subsequently, the API calling unit 112 proceeds to step 3310, where it determines whether the API request to be sent is an API request that came from another management software 3211.

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

[0198] In contrast, if the API request to be sent is not an API request 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 to the management processing unit 133 of the storage system 130 using its own Tool ID as the Tool ID. After that, the API calling unit 112 proceeds to step 3395 and terminates this processing flow.

[0200] According to this modified example, when other management software 111 is interposed between the management software 3211 and the storage system 130, and the management software 111 itself has an API, the API calling unit 112 receives an API call from the other management software 3211 and issues another API to the storage system (management processing unit 133). In this case, the API calling unit 112 of the management software 111 records the Tool ID of the caller and sends the API request to the management processing unit 133 so that the management software 3211 that called the API can be identified. As a result, the storage system 130 records the Tool ID of the management software 3211's API caller in the API log 138, so that the API caller can be identified even when other management software 111 is interposed 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 the model usage count screen 3400 shown in Figure 34 based on the statistical information. The model usage count screen 3400 shows the number of software programs used for each model. According to this modified example, the decision-maker 410 can identify software programs with high usage rates in the midrange and high-end segments using the model usage count screen 3400. As a result, the decision-maker 410 can prioritize the development of user-specific functions in the development of management software functions.

[0202] In each of the above embodiments, the usage information extraction unit 313 may calculate the number of customers using each software based on the customer usage statistics table 820 and store the calculated number of customers using each software as statistical information in the database 316. In this case, the usage rate display unit 314 may create and display the customer usage screen 3500 shown in Figure 35 based on the statistical information. The customer usage screen 3500 represents the number of customers using each software. According to this modified example, the decision-maker 410 can use the statistical information from the customer usage screen 3500 to analyze customer segments of the management software, thereby improving product value.

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

[0204] The present invention may also be applied to systems other than the storage system 130. Examples of other systems include payment systems that provide APIs and content management systems that provide APIs. The present invention can also adopt the following configuration.

[0205] A software usage status survey system comprising: a system that provides an API and includes a computing device and a storage device; a management server on which software is installed and which sends API requests to the system and receives API responses from the system through the operation of the software; and a software usage status survey device including an information processing device, The management server includes the software identification information in the API request and sends the API request to the system. The computing device of the system stores in the storage device a record of API access by the software to the API provided by the system, in which the API log is written so as to retain the software's identification information. 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] 100…On-premise infrastructure, 110…First management server, 111…Management software, 112…API calling unit, 120…Second management server, 121…External plugin, 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 infrastructure, 210...First cloud server, 220...Second cloud server, 300...Second cloud infrastructure, 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 comprising: a plurality of systems that provide an API and each system having a computing device and a first storage device; a plurality of client servers on which software is installed to access the API via a network and perform functions, and which send API requests to the systems and receive API responses from the systems through the operation of the software; and a software usage status investigation device including an information processing device, The client server includes the software identification information 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 of API access to the API by the software, such that the API log includes the 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. In the software usage status survey system described in claim 1, The aforementioned information processing device includes a second storage device, Multiple API logs for each of the multiple systems obtained from the multiple systems are stored in the second storage device. Multiple API logs for each system during the investigation period are obtained from the second storage device, and information indicating the usage status of the software is created from the multiple API logs for each system. Software usage survey system.

3. In the software usage status survey system according to claim 2, The information processing device extracts software identification information from multiple API logs and uses the extracted software identification information to create information indicating the usage status of the software. Software usage survey system.

4. In the software usage status survey system described in claim 3, The API provided by the aforementioned system includes a session generation API for generating sessions, The aforementioned information processing device is Using the extracted software identification information, logs of API access to the session generation API of the software are identified from multiple API logs, and information indicating the usage status of the software is created based on the identified API access logs. Software usage survey system.

5. In the software usage status survey system described in claim 4, The aforementioned information processing device is Based on the identified API access logs, information indicating the usage status of the software is created, showing whether or not the software is being used for each system. Software usage survey system.

6. In the software usage status survey system described in claim 5, The aforementioned information processing device is By separating the API log using a delimiter, the software identification information and API type are extracted from the API log, correspondence information is created by associating the extracted software identification information and API type, and the logs of API access to the session generation API of the software within the API log are identified using the software identification information and the correspondence information. Software usage survey system.

7. In the software usage status survey system described in claim 1, The aforementioned information processing device is By separating the API log using a delimiter, the software identification information and API type are extracted from the API log; correspondence information is created by associating the extracted software identification information and API type; the number of API calls by the software is aggregated using the software identification information and correspondence information; and information indicating the usage status of the software's functions is created based on the aggregated information as information indicating the usage status of the software. Software usage survey system.

8. In the software usage status survey system described in claim 4, The aforementioned information processing device is As information indicating the usage status of the software, at least one of the following is created: the usage rate of the software for multiple systems, the trend in the usage status of the software, the number of customers using the software, and the number of users of the software for each type of system. Software usage survey system.

9. In the software usage status survey system described in claim 1, The aforementioned information processing device is connected to a display device, The aforementioned information processing device is A screen containing information indicating the usage status of the software is displayed on the display device. It is configured in such a way. Software usage survey system.

10. In the software usage status survey system described in claim 1, When one of the multiple client servers receives the API request from another client server through the operation of the software of the other client servers, the software of the one client server sends the API request from the other client servers to the system and sends the API response received from the system to the other client servers. One client server sends the API request to the system, including the identification information of the software of another client server in place of the identification information of the software of the one client server. Software usage survey system.

11. In the software usage status survey system described in claim 1, When one of the multiple client servers receives the API request from another client server through the operation of the software of the other client servers, the software of the one client server sends the API request from the other client servers to the system and sends the API response received from the system to the other client servers. One client server sends the API request to the system, including the identification information of the software of the other client server along with the identification information of the software of the one client server. Software usage survey system.

12. In the software usage status survey system described in claim 1, The aforementioned 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 APIs provided by a system via a network and executes software functions, The information processing device obtains from the system an API log relating to API access to the API by the software to which identification information has been assigned, and which is 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. A software usage survey device configured as follows.

14. A method for investigating software usage status using an information processing device that investigates the usage status of software by accessing an API provided by a system via a network and executing software functions, A software usage status investigation method comprising: using the information processing device to obtain 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 creating information indicating the usage status of the software from the API log.

Images