JP7604234B2 - Service Management System - Google Patents

Description

The present invention relates to technology for supporting management and operation tasks such as purchasing, concluding contracts, renewing, and discontinuing various services, such as mobile phones, smartphones, and paid and free software applications, that are provided or loaned to employees and staff of companies, organizations, and other such organizations.

Generally, companies, groups, organizations, etc. provide or lend various services necessary for their employees to carry out their work, such as mobile phones, smartphones, and paid or free software applications, at the company's expense.
For example, in the past, there was the management of fixed-line telephone line subscription rights and monthly usage fee assets and payments, and more recently, there is the management of equipment rental fees and annual or monthly usage fees for various cloud services, installment payments and monthly communication fees for mobile phone companies' smartphones, and the management of each contract, which is renewed on an annual basis.

The various services provided to employees as part of such business operations and employee benefits can be enormous in type, content, quantity, and cost to be paid. It is therefore extremely important for companies and organizations to properly manage and operate the purchase of these services, as well as the conclusion, renewal, and termination of contracts. It is also necessary to eliminate unnecessary and inefficient duplicate contracts for services as much as possible.
However, until now, the management of these various services has been carried out manually by staff in management departments, such as a company's management department or general affairs department, using their many years of experience and intuition, which placed a heavy burden on the staff, and in many cases it was difficult to say that the services were being managed and operated appropriately.

In response to this, support technologies have been proposed that aim to enable efficient management and operation of various services in such companies and organizations while reducing the burden on those in charge.
For example, Patent Document 1 proposes a "license management method" that uses a computer to manage the number of software licenses held within an organization such as a company and the number of software actually being used within the organization, checks whether there is a shortage of licenses for any software, and notifies a person in charge if there is a shortage, thereby preventing unauthorized use of licenses within the organization, achieving efficient and accurate license management, and reducing the workload of license management.

Patent No. 4121344 specification

However, there is still room for further improvement in the service management support technologies up to now, including the technology disclosed in Patent Document 1.
For example, the license management method of Patent Document 1 is intended only to prevent shortages of or unauthorized use of software to be contracted for, and is not capable of, for example, extracting unnecessary or overlapping services and reviewing or optimizing the contracts.

The present invention has been proposed to solve the problems described above, and aims to provide a service management system that can automatically extract unnecessary services, inefficient operations, overlapping contracts, etc. by dynamically monitoring and determining the purchase, conclusion, renewal, suspension, termination, etc. of various paid and free services contracted by companies, organizations, etc., and can optimize the execution, review, suspension, termination, etc. of contracts and purchases.

In order to achieve the above object, the present invention provides a system for managing the optimization of license contracts and purchases for one or more predetermined services contracted on a predetermined contract basis, the system comprising: a storage means for storing predetermined license information including usage status information, purchase information, and purchase condition information for each license for identifying the contracted license, and predetermined similar license information indicating one or more similar licenses; and when a license contract application is received from a user, a predetermined license purchase optimization simulation is executed to determine whether or not the license should be purchased based on the usage status information, purchase information, and purchase condition information for each license stored in the storage means, and a predetermined license purchase process is executed based on the results of the simulation. and a license switching information generation unit that performs a license switching simulation to determine whether or not there is a similar license to be switched with for each license based on any of the usage information, purchase information, purchase condition information, and similar license information of each license stored in the storage means, and generates switching list information indicating the relevant similar licenses based on the result of the simulation, wherein the license switching information generation unit is configured to refer to the storage means, extract data on services similar to the current service related to each license, perform a simulation to compare the fees if the service is switched, and generate a list that displays the names and fees of the current service and one or more similar services in a comparative manner .

Furthermore, the present invention can be configured as a program executed in the service management system according to the present invention as described above.
Furthermore, the present invention can also be embodied as a method that can be implemented by the service management system and program according to the present invention as described above.

According to the present invention, by dynamically monitoring and determining the purchase, contract conclusion, renewal, suspension, termination, etc. of various paid and free services contracted by companies, organizations, etc., it is possible to automatically extract unnecessary services, inefficient operations, overlapping contracts, etc., and to optimize the execution, review, suspension, termination, etc. of contracts and purchases.
This makes it possible to provide a service management system, program, and method that is ideal for managing and operating the purchase and contracts of various services, such as mobile phones, smartphones, and paid and free software applications that are provided or loaned to employees and staff of companies, organizations, and other companies, groups, and organizations.

1 is an explanatory diagram illustrating a schematic diagram of an overall configuration of a service management system according to an embodiment of the present invention; 2 is a functional block diagram showing the configuration of each unit in the service management system. 1A is an explanatory diagram showing the data configuration stored in the database of the service management system, where FIG. 1A shows the data configuration of a license usage status DB, FIG. 1B shows the data configuration of a service cancellation information DB, and FIG. 1C shows the data configuration of a service cancellation list DB. 5A, 5B, and 5C are explanatory diagrams showing data configurations stored in databases of a service management system, in which FIG. 5A shows the data configuration of a purchased license DB, FIG. 5B shows the data configuration of a purchase condition DB, and FIG. 5C shows the data configuration of a similar license DB. 13 is a flowchart showing an outline of a processing operation in a license purchase optimization unit. FIG. 13 is an explanatory diagram showing an input screen image of a paid license application form. 13 is a flowchart showing details of a processing operation in a license purchase optimization simulation. 11A and 11B are explanatory diagrams showing output images of a license purchase optimization simulation, in which (a) is a purchase simulation list, and (b) is an example of a display of purchase conditions. 13 is a flowchart showing an outline of a processing operation in a license inventory optimization unit. 13 is a flowchart showing details of a processing operation in a license inventory optimization simulation. 11A is an explanatory diagram showing an output image of a license inventory optimization simulation, in which (a) is a usage status output instruction screen, (b) is a usage status output, and (c) is an example of a usage status display. 13 is a flowchart showing an outline of a processing operation in a license update optimization unit. 13 is a flowchart showing details of a processing operation in a license renewal optimization simulation. 11A and 11B are explanatory diagrams showing an output image of a license renewal optimization simulation, in which (a) is an instruction screen for outputting the usage status of a renewal target person, (b) is an output of the usage status of a renewal target person, and (c) is an example of a display of the usage status of a renewal target person. 13 is a flowchart showing an outline of a processing operation in a license switching information generating unit. 13 is a flowchart showing details of a processing operation in a license switching simulation. 11A is an explanatory diagram showing an output image of a license switching simulation, where FIG. 11A is a license switching simulation output instruction screen, FIG. 11B is a license switching simulation output, and FIG. 11C is an example of a display of the usage status of similar licenses. 13 is a flowchart showing an outline of a processing operation in a license cancellation information generating unit. 13 is a flowchart showing details of a service cancellation list output process by a license cancellation information generating unit. 13 is an explanatory diagram showing an image of an input screen for instructions to create data for disabling or suspending an account in an external system and cancelling a service. FIG. FIG. 13 is an explanatory diagram showing an output image of a service cancellation list.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, an embodiment of a service management system according to the present invention will be described with reference to the drawings.
The service management system (this system) of the present invention described below is realized by processes, means, and functions executed by a computer according to instructions from a program (software). The program sends commands to each component of the computer, and can cause it to perform the specified processes and functions according to the present invention described below. In other words, each process, means, and function in the present invention is realized by a specific means in which the program and the computer work together.

The whole or part of the program may be provided by a computer-readable recording medium, such as a magnetic disk, an optical disk, a semiconductor memory, or any other recording medium, and the program may be read from the recording medium and installed on a computer for execution. The program may also be directly loaded into a computer via a communication line and executed without using a recording medium.
Furthermore, the present system can be configured with a single information processing device (such as one personal computer) or with a plurality of information processing devices (such as a group of a plurality of server computers).

Although not shown in the figure, the hardware configuration of this system is composed of information processing devices including a CPU, RAM, ROM, HDD, input device, display device, etc. These components are connected by a system bus, and data is exchanged via the system bus. The CPU (Central Processing Unit), also known as the central processing unit, is the part that performs the central processing of the computer, controlling each device and calculating/processing data. RAM (Random Access Memory) is a type of memory device that allows data to be erased and rewritten, and ROM (Read Only Memory) is a type of memory device that uses semiconductors, etc., and data is written only once during manufacturing, and the recorded data can only be read when used. HDD (Hard Disk Drive) is an auxiliary storage device that uses the properties of magnetic materials to record and read information. The input device is used by the user to give operational instructions to the computer or to input characters, etc., and specifically consists of a keyboard, mouse, etc. The display device consists of, for example, a liquid crystal display, etc., and may have a touch panel function. In addition, it may also have a communication function that enables communication with other terminals, information processing devices, etc.

[System configuration]
As shown in FIG. 1, a service management system 1 (hereinafter referred to as "this system 1") according to one embodiment of the present invention is configured to include a service management server 10 and one or more applicant terminals 30 (30a to 30n).
The service management server 10 and the applicant terminal 30 are connected via the Internet 100, which includes networks such as LAN and WAN, and are capable of data communication with each other.
The service management server 10 is also connected via the Internet 100 to be able to communicate with a predetermined external system 50 installed outside (domestic or overseas).

Here, the service management server 10 and the applicant terminal 30 can be configured by information processing devices installed in, for example, the same organization/company, etc. In this case, the present system 1 is configured by the service management server 10 and the applicant terminal 30, and the present system 1 can function as an in-house system operated, for example, by the same organization/company.
Furthermore, the service management server 10 and the applicant terminal 30 can be configured by information processing devices installed in different organizations, companies, etc. In this case, for example, the service management server 10 can be configured by an information processing device operated by a company that provides the present system 1 as a service to customers, and the applicant terminal 30 can be configured by an information processing device provided in one or more companies, organizations, groups, etc. that receive license management services via the present system 1. In this case, the applicant terminal 30 functions as an external device connected to the present system 1 via a network, and the present system 1 is configured only by the service management server 10.

[Service Management Server]
The service management server 10 is an information processing device that serves as the core of the system 1 and is used to manage and support the optimization of license contracts and purchases for one or more specified services that are contracted on a specified contract basis in each company, organization, etc., and constitutes the service management system of the present invention.
Here, the specified contract units for contracting/purchasing licenses for one or more services covered by this system 1 include, for example, a user unit for each user who uses the service, a terminal unit, device unit, or software unit for executing the service, etc.
This service management server 10 can be configured, for example, by an information processing device on which a specified program (software) is implemented, such as one or more server computers or personal computers, or a server system consisting of one or more virtual servers built on a cloud computing service.

The service management server 10 also includes an operating system (OS) and a data base management system (DBMS), neither of which are shown, and is operated as a server computer.
The service management server 10 is implemented with software that runs on middleware, such as a Web server program.
This software publishes and provides applications that can be used by one or more applicant terminals 30 via a network such as the Internet 100 in the form of, for example, an API (Application Programming Interface).
As a result, each applicant terminal 30 can execute and use the functions of the service management system of the present invention by calling up and logging in to a dedicated application program or web browser that is operated to provide services provided or proposed by the service management server 10, such as application processing for the purchase of a desired license and receiving notifications of license suspension or cancellation, etc.

In addition, the service management server 10 is provided with a specified service management DB (database) 20 (described later) which is implemented as a database or the like, and is also provided with a storage means for acquiring and storing specified information required for the operation of the service management system according to the present invention.
The storage means stores, as various information resources, specific information for identifying various contracted service licenses to be managed by this system 1, such as specific license information including usage status information, purchase information, and purchase condition information for each license, as well as specific information input and transmitted from each applicant terminal 30 described below, such as application information for license purchase and license usage information, and the necessary information is read out, stored, and updated as needed in conjunction with the operation of this system 1.

The service management server 10 in this embodiment is configured to function as each of the following units, as shown in Figure 2: a license purchase optimization unit 11, a license inventory optimization unit 12, a license update optimization unit 13, a license switching information generation unit 14, and a license cancellation information generation unit 15.
In addition, the service management server 10 has constructed a service management DB 20 configured by the above-mentioned storage means. Specifically, the service management DB 20 is provided with a license usage status DB 21, a service cancellation information DB 22, a service cancellation list DB 23, a purchased license DB 24, a purchase condition DB 25, and a similar license DB 26, and the specified data necessary for the service management processing in this system 1 is stored and managed as a database.

The service licenses to be managed by this system 1 include usage contracts and lease contracts for various communication devices and electronic devices used for business purposes by companies and the like, and software application usage contracts.
For example, this includes managing fixed-line telephone line subscription rights and assets and payments for monthly usage fees, equipment rental fees and annual or monthly usage fees for various cloud services, installment payments and monthly communication fees for mobile phone companies' smartphones, and management of software application usage contracts and monthly usage fees.
It also covers the management of renewals of those contracts, for example on an annual basis.
The management of contracts and fees for these various services becomes more complex in proportion to the size of the company and the number of contracts, and it is not uncommon for fees to be paid in a non-optimized manner and in an unnecessary manner.

Therefore, in this system 1, the processing operations of five subsystems, namely, the license purchase optimization unit 11, the license inventory optimization unit 12, the license renewal optimization unit 13, the license switching information generation unit 14, and the license cancellation information generation unit 15 of the service management server 10, are executed based on the specified license information stored and managed in the service management DB 20, thereby solving the above-mentioned conventional problems.
In other words, with this system 1, the management of a large number of service licenses, which was previously done by personnel in management departments such as the general affairs department or the information systems department based on their intuition and experience, can now be performed based on data from five subsystems and various databases, making it possible to use the necessary services efficiently and without waste at the optimal usage fee, without human intuition or experience.
Furthermore, in this system 1, in conjunction with the suspension of an SSO (IDaaS) account, a list of services to be canceled (service cancellation list) is output, and unnecessary or useless licenses that should be canceled midway are actively extracted, and suggestions and support can be made for cancellation (or suspension management).

Here, SSO (single sign-on) is a feature that allows resources on multiple independent software systems to be used with a single user authentication process. This feature eliminates the need for users to input a set of user ID and password for each system. IDaaS is an abbreviation for "Identity as a Service" and is a service that provides ID authentication, ID password management, SSO, access control, etc. via the cloud.
Such SSO and IDaaS services are provided from an external system 50 via a network such as the Internet 100 .
By utilizing these functions, the present system 1 is able to extract and determine which services are not being used and which should be suspended, discontinued, or cancelled.

[Service Management DB]
The service management DB 20 is a storage means in which predetermined data and information relating to the service licenses to be managed by the present system 1 is managed as a database.
This service management DB 20 pre-stores, for each company or organization being managed, predetermined license information for identifying licenses that have already been contracted by that company or organization, and further, data is stored and updated as needed in response to new purchases, suspension, abolition, switching, etc. of licenses.
In addition, predetermined information is input and transmitted to the service management DB from each applicant terminal 30 and external system 50 via a network such as the Internet 100, and data is stored and updated as needed in accordance with this information.

The specified information stored and managed in the service management DB 20 is information relating to the license agreements for each of the above-mentioned services that are managed by the present system 1, and includes, for example, various types of information and data such as a license usage status DB 21, a service cancellation information DB 22, a service cancellation list DB 23, a purchased license DB 24, a purchasing condition DB 25, and a similar license DB 26, as shown in FIG. 2.
Note that the information stored in the service management DB 20 shown below is an example of information to be processed in this system 1, and is not limited to only the information below. It goes without saying that any information required by this system 1 can be added, deleted, changed, etc.

Specifically, the information and data constituting the license usage status DB21, service cancellation information DB22, service cancellation list DB23, purchased license DB24, purchase condition DB25, and similar license DB26 of the service management DB20 are, for example, as shown in Figures 3 and 4 (see Figures 3 and 4 for samples, contents, and notes of each data).

[License Usage Status DB]
1. License (name of license, etc.)
2. User ID
3. Applicant ID
4. Applicant organization CD
5. Charged unit 6. License type 7. Status 8. Fiscal year 9. Application date 10. Change date 11. Planned start date of use 12. Planned end date of use 13. Start date of use 14. End date of use 15. Suspension date 16. Cancellation date

[Service Cancellation Information DB]
1. User ID
2. Date of retirement 3. Date of leave of absence

[Service Cancellation List DB]
1. License 2. User ID
3. Applicant ID
4. License type 5. Status 6. Start date of use 7. End date of use 8. Suspension date 9. Cancellation date 10. Resignation date 11. Date of leave of absence

[Purchased License DB]
1. License 2. License type 3. Number of licenses 4. Start date of use 5. End date of use 6. Purchase date

[Purchase Condition DB]
1. License 2. License type 3. Estimate comment 4. Start date of use 5. End date of use 6. Expiration date of use 7. Unit price 8. Number of licenses 9. Conditions, etc. 10. Estimate date 11. Estimate validity date 12. Number of days that can be reassigned after suspension

[Similar License]
1. License 2. License type 3. Similar licenses 4. Similar license types 5. Special notes

Based on the data stored and managed in the service management DB 20 as described above, each processing operation in the license purchase optimization unit 11, license inventory optimization unit 12, license renewal optimization unit 13, license switching information generation unit 14, and license cancellation information generation unit 15 of the service management server 10 is executed, thereby ensuring proper operation and optimization of one or more target services.
In the past, service licenses were purchased each time they were needed, but there was no need to review them (take an inventory) after that. For example, the decision as to whether or not a license was needed was made when a renewal notice was received from the carrier or vendor from which the license was purchased. As a result, it was not possible to optimize license agreements.

For example, in the past, various information related to license agreements was often managed on paper or in the mind of the person in charge, and in some cases it was managed through invoices or contract renewal notifications from service providers.
In addition, recently, by utilizing the above-mentioned SSO (IDaaS) function, it has become easier to obtain usage history (Login-Logout history) for each service, making it easy to check whether or not contracted services are being used.
In addition, while contracts with telecommunications carriers for services such as cloud computing and smartphones are often annual, companies manage service contract information and payments on a monthly basis, resulting in a discrepancy between the contract renewal unit and the payment unit.

In addition, various services contracted or purchased for business purposes may be used by contract employees and part-time staff in addition to full-time employees, and their usage varies from month to month. In addition, expense management must be carried out by organization (department).
For example, if employee A of department X left the company last month, it would be desirable to be able to decide whether to immediately stop the services that employee A was using, or whether it would be more efficient to continue assigning them to employee B of department Y.
Furthermore, some services may have multiple options, and it is desirable to be able to manage such options in a detailed manner, and in some cases, it is preferable to be able to manage and determine options by checking them against invoices, etc.

Therefore, in this system 1, as described above, a database for managing information on already purchased items (purchased license DB 24) and a database for managing purchasing conditions (purchase conditions DB 25) are constructed in the service management DB 20, and these are compared with information on newly applied for services at the time of purchase application, thereby making it possible to optimize license purchases by performing optimal simulations according to purchasing units, including inventory of non-users and test users.
Specifically, the optimization of license agreements according to the present invention can be realized by executing the processing operations of five subsystems, namely, a license purchase optimization unit 11, a license inventory optimization unit 12, a license renewal optimization unit 13, a license switching information generation unit 14, and a license cancellation information generation unit 15, as described below.

[License Purchase Optimization Department]
When a user applies for a license contract, the license purchase optimization unit 11 executes a predetermined license purchase optimization simulation to determine whether or not the license should be purchased based on the usage information, purchase information, and purchase condition information of each license stored in a storage means (service management DB 20), and executes a predetermined license purchase process based on the results of the simulation.
Specifically, the license purchase optimization unit 11 executes the process of "license purchase optimization simulation + purchasing process automation" as described below (see Figures 5 to 8), thereby creating and proposing an optimal purchasing simulation plan based on the data in the purchased license DB 24 (containing usage information) and the purchasing condition DB 25 for services that have previously been purchased based on the intuition and experience of the person in charge, and automatically carrying out the purchasing process in accordance with the selected simulation plan.
A specific processing operation (license purchase optimization simulation) of the license purchase optimization unit 11 will be described later with reference to FIGS.

[License Inventory Optimization Department]
The license inventory optimization unit 12 executes a license inventory optimization simulation to determine whether or not the license should be suspended based on the usage information of each license stored in a storage means (service management DB 20) and specified login/logout information for each license, and executes suspension processing for the relevant license based on the results of the simulation.
A specific processing operation (license inventory optimization simulation) of the license inventory optimization unit 12 will be described later with reference to FIGS.

[License Renewal Optimization Department]
The license update optimization unit 13 performs a license update optimization simulation to determine whether or not the license should be abolished based on the usage information of each license stored in a storage means (service management DB 20) and specified login/logout information for each license, and performs abolition processing of the relevant license based on the results of the simulation.
A specific processing operation (license update optimization simulation) of the license update optimization unit 13 will be described later with reference to FIGS.

[License switching information generation unit]
The license switching information generation unit 14 performs a license switching simulation to determine whether or not there is a similar license to be switched to the license in question, based on the usage information, purchase information, purchase condition information, and similar license information of each license stored in the storage means (service management DB 20), and generates switching list information indicating the relevant similar licenses based on the results of the simulation.
A specific processing operation (license switching simulation) of the license switching information generating unit 14 will be described later with reference to FIGS.

[License cancellation information generation unit]
The license cancellation information generating unit 15 generates cancellation list information indicating the corresponding licenses to be cancelled based on the purchase information of each license stored in the storage means (service management DB 20) and the predetermined account cancellation information for each license.
A specific processing operation (service cancellation list output) of the license cancellation information generating unit 15 will be described later with reference to FIGS.

[Applicant terminal]
The applicant terminal 30 (30a to 30n) can be composed of one or more information processing devices, such as a PC, tablet terminal, smartphone, etc., used by companies, organizations, etc. that are managed by this system 1, and which can be connected to the service management server 10 via an in-house network such as a LAN or WAN, or the Internet 100.
Through such an applicant terminal 30, for example, officers, employees, staff, etc. belonging to the company or organization who use the applicant terminal 30 can access the service management server 10 via the Internet 100 to send/receive various necessary information, and output/display it.

[External System]
The external system 50 is an information processing device connected to the service management server 10 via the Internet 100 and configured with a group of PCs and servers installed in the office or data center of a business providing services to be managed by the present system 1, such as various communication devices, electronic devices, and software applications. By accessing this external system 50 from the service management server 10, it becomes possible to carry out online processing such as new contracts, purchases, suspension, cancellation, and cancellation of various services provided by the business of the external system 50.

The external system 50 also includes a web server that publishes and provides various information and services that can be used online via a network such as the Internet 100, such as the above-mentioned SSO and IDaaS.
By accessing such an external system 50, the system 1 can utilize the SSO/IDaaS functions to extract and determine unused, unnecessary, and inefficient service contracts.

[Action]
Next, specific processing and operations (implementation of a service management method) in the above-described system 1 will be described with reference to FIGS.
In this system 1, a series of processing operations are automatically executed in the license purchase optimization unit 11, license inventory optimization unit 12, license renewal optimization unit 13, license switching information generation unit 14, and license cancellation information generation unit 15 of the service management server 10 described above, thereby dynamically monitoring and determining new purchases, contract conclusion, renewal, suspension, abolition, etc. of various services provided by companies, etc., and automatically extracting unnecessary services, inefficient operations, duplicate contracts, etc., and optimizing the execution, review, suspension, abolition, etc. of contracts and purchases.

[License purchase optimization simulation]
First, the operation of the license purchase optimization unit 11 (license purchase optimization simulation) will be described with reference to FIGS.
FIG. 5 shows an outline of the processing operation in the license purchase optimization unit 11. As shown in FIG.
As shown in the figure, the license purchase optimization unit 11 uses a license usage status DB 21 and a purchase condition DB 25 to generate an optimal purchase simulation plan for various service licenses that have previously been purchased based on the intuition and experience of a person in charge, and automatically executes the purchase process in accordance with the selected simulation plan.
Specifically, the license purchase optimization unit 11 first performs a "license application" as a first function (step 501). To apply for a license, an applicant accesses and logs into the system 1 from the applicant terminal 30, inputs data along a predetermined input screen, and transmits the data to the service management server 10.

FIG. 6 shows an image of an input screen for a paid license application form.
As shown in the figure, an application form input screen for applying for a license is generated and displayed on the applicant terminal 30, and the necessary information is input.
In the example shown in FIG. 6, for example, the following applications and subscriptions can be made.
(1) New
(2) Change in accounting unit
(3) Abolished at the end of the fiscal year
(4) Immediate abolition (by license)
(5) New test account
(6) Test account termination

As shown in the figure, the information entered and managed via the application form includes necessary information for each item, such as "applicant, approver, user organization, number of licenses, billing unit, user," etc.
Regarding "user" information, for example, licenses are managed by managing the number of licenses purchased, the name, and the account as one record, and the applicant information, approver information, and user organization information are managed.
The "account status", for example "1: in use, 2: suspended, 3: test account use", is managed based on information such as the application date, start date of use, end date of use, and account cancellation date.
As the "end status", for example, predetermined information such as "1: unit changed, 2: end of fiscal year abolition not reached, 3: end of fiscal year abolition new allocation made, 4: test account abolished" is managed.

By inputting and managing such specific information via the application form, for example, when purchasing a new license for which an application has been made, an account is assigned and changed from "2: Not yet abolished at the end of the fiscal year" to "3: Abolished at the end of the fiscal year, newly assigned", and date information is registered in "Account abolition date", so that the license is not purchased anew, but a "test account" is used, and this fact is notified to the applicant's applicant terminal 30. This allows for dynamic and flexible responses according to the situation.

As an example of a "license application" made via the applicant terminal 30 as described above, it is assumed that an application is made for three paid licenses for the software application "WebMeeting" for online conferencing (step 501).
As mentioned above, applications for such new licenses can be made in one of six ways, such as "new, accounting unit change, abolition (only at the end of the fiscal year depending on the license), immediate abolition (depending on the license), new test account, abolition of test account." This allows for flexible responses such as "basically abolishing at the end of the fiscal year, but setting it to suspended/dormant in the system, and if there is a new one, changing the unit to that."

When information on a license application (step 501) is input, the license purchase optimization unit 11 executes a predetermined license purchase optimization simulation for the license related to the application (step 502).
In this license purchase optimization simulation, a predetermined simulation is performed on the purchase of the license related to the application based on the data stored in the license usage status DB 21, the purchase condition DB 25, and the purchased license DB 24 (see Figures 3 and 4).

The license usage status DB 21 stores data indicating the usage and management status including suspended and dormant licenses.
The purchase condition DB 25 stores data on predetermined purchase conditions, such as "purchase one license at a time" or "purchase in units of 10 licenses" for the applicable licenses related to the application.
In the purchased license DB24, flags indicating, for example, a "test user" or a "low-use user" are set as user information for licenses that have already been contracted/purchased, and based on this information, if it is determined that the license related to the application should not be purchased, the user can be extracted as a candidate for stopping the service.

In the example shown in Figure 5, the data "Dormant accounts: 0, accounts suspended at the end of this month: 2, test users: 2" is extracted from the license usage status DB 21, the data "Purchased in units of 10 or 100 accounts, with one year's supply renewed in November 2020" is extracted from the purchase condition DB 25, and the "Purchased quantity confirmation" data for the license is extracted from the purchased license DB 24.
A simulation is run based on this data, and two proposed results are generated: "Plan 1: Purchase 0. Use dormant account 2 at the end of this month, and contact Mr. A to see if he can return his license, who has an even lower utilization rate." and "Plan 2: Purchase 10. Purchase as is, and after allocation next month, 10 - 3 = 7 and the 2 dormant accounts will result in 9 unallocated accounts.""Plan2" is adopted as the final simulation result.

When the license purchasing optimization simulation result is generated and output, the license purchasing optimization unit 11 performs "purchase of license" as the second function (step 503).
In the license purchasing process, the selection of the purchasing plan confirmed in the processing of the first function (license purchasing optimization simulation) is input to the present system 1, and the purchasing process is executed and confirmed.
In the example of FIG. 5, the simulation result of "Plan 2: Purchase quantity 10" is output and presented as an optimal license purchase quantity plan via the service management server 10 to, for example, a person in the general affairs department of the company.

The person in charge who receives the simulation results can check the license purchase proposal, make an optimal purchase plan (or revoke the license from non-users or test users without purchasing), etc., and then automatically place an order for the license purchase via the service management server 10 to an external system 50 operated by the vendor that provides and sells the license.
Furthermore, when a license is purchased, the data stored in the purchased license DB 24 is updated and the purchase information is changed.
In addition, when the license purchase is executed, reply data (e.g., e-mail, etc.) informing the applicant of the license purchase is sent to the applicant terminal 30 of the applicant who applied for the license, and if license revocation of the test user, etc. is selected instead of purchasing the license, the user is notified of the fact by e-mail, etc.

FIG. 7 shows the details of the processing operations in the license purchase optimization simulation described above.
As shown in the figure, in the license purchase optimization simulation, when a "license application" is made by a user department via applicant terminal 30 (step 701), this triggers processing in system 1, and first "license purchase application registration (registration of application acceptance & acceptance date, planned start and end dates of use)" (step 702) is performed.
Along with this "license purchase application registration" process, data is registered and updated in the license usage status DB 21.
Next, a "license purchase necessary counting process" (step 703) is executed, and data necessary for the process is referenced and extracted from the license use status DB 21 and the purchased license DB 24.

Next, a determination is made as to whether "number of licenses used + number of applications = < purchased (already purchased) licenses" (step 704). Note that in the case of a service that requires a contract for each device, such as a smartphone, the process will always branch to "No", so this process may be omitted and the process may proceed directly to the next step (step 707).
If the determination in step 704 is "Yes", the data of "Date of use & change, Date of use start &End" is registered in the license usage status DB 21 as "License usage start registration (1)" (step 705). In this case, the simulation result is not output, and a "License usage start notice" is sent to the using department and the applicant terminal 30 (step 706).

On the other hand, if the determination in step 704 is "No", a "License Purchase Simulation List Creation" process is executed (step 707) to generate a predetermined "Simulation List". Based on this list, for example, an analysis is performed to determine whether to "increase the number of suspended licenses or purchase licenses more efficiently".
As a result, if it is determined that "the number of suspended licenses should be increased beyond the number required for purchase" (step 708), the suspended number data in the license utilization status DB 21 is updated and increased.
Furthermore, if it is determined that a license has been purchased (step 709), the number of purchases in the purchased license DB 24 is incremented and updated, and the system is investigated to consider and execute an automatic order to the vendor (external system 50), etc.

Thereafter, data such as "in use & change date, use start & end date" and "suspended ->abolished" are registered and updated in the license use status DB 21 as "license use start registration (2)" (step 710).
In this case, when it is necessary to output the simulation results, a predetermined "license usage start notification" is sent to the using department or the applicant terminal 30 (step 711), and the generated and output simulation results are presented.

FIG. 8 shows an image of the output of the license purchase optimization simulation described above.
FIG. 8A is an example of a purchase simulation list. The following information is generated as the output result of the simulation and is output and displayed on the service management server 10 or the display of the applicant terminal 30.
1. License (name of license, etc.)
2. License type 3. Remaining licenses (purchased licenses - (currently in use + test use))
4. Number of accepted applications 5. Number of suspended licenses 6. Number of accepted applications - (remaining licenses + number of suspended licenses + number of test licenses)

FIG. 8(b) is an example of the display of purchase conditions, and for the following "purchase conditions: 1 to 5," the relevant content for each of the items "usage start date, usage end date, usage expiration date (number of days), unit price, number of licenses, amount, conditions, etc., estimated date, estimated validity date" is output/generated and output/displayed on the display of the service management server 10 or the applicant terminal 30.
1. End of term sale price: 100 licenses 2. End of term sale price: 10 licenses 3. Regular price: 100 licenses 4. Regular price: 10 licenses 5. Regular price: 1 license It goes without saying that the output image of the license purchase optimization simulation described above is merely an example, and other information can be output and displayed as well.

[License inventory optimization simulation]
Next, the operation of the license inventory optimization unit 12 (license inventory optimization simulation) will be described with reference to FIGS.
FIG. 9 shows an outline of the processing operation in the license inventory optimization unit 12. As shown in FIG.
As shown in the figure, the license inventory optimization unit 12 extracts unused user information while utilizing the functions of an external system 50, etc., automatically notifies non-users to cancel their accounts, etc., and automatically performs the process of changing accounts to dormant accounts (and cancels accounts that can be canceled during the fiscal year) depending on the user's request.

Specifically, the license inventory optimization unit 12 first obtains the Login-Logout record data for the target service (e.g., online conference software "WebMeeting") from an external system 50 such as SSO (IDaaS) (step 901), and then executes a specified license inventory optimization simulation based on the data (step 902).

In this license inventory optimization simulation, a predetermined simulation is performed on the inventory to determine whether or not the contract should be reviewed for each relevant account, based on data indicating the usage status of purchased licenses by account, which is extracted and obtained each time from the external system 50, and the data stored in the license usage status DB 21 (see Figure 3).
In the example shown in FIG. 9, the data of "dormant accounts: 10, test accounts that can be suspended: 20" is extracted from the license usage status DB 21, and the accounts of "unused for 3 months: 5, unused for 2 months: 3, unused for 1 month: 1" are extracted from the data obtained from the external system 50.
A simulation is performed based on these data, and the results are notified to, for example, the administrator of the system 1 (step 903).

The administrator who receives the optimization simulation can, for example, pick out users from the listed unused accounts that he or she particularly wishes to suspend, attach data on their usage status (unused status), and notify or contact the applicant terminal 30 of the applicant who manages the relevant service or contract by email, etc.
The applicant who receives the notification from the administrator can check the situation and suspend or otherwise suspend the paid licenses of unused users (step 904).
This allows applicants and companies to benefit from the fact that, for example, while they would normally have to pay a monthly fee until renewal, system 1 can extract users who are able to suspend their subscription, meaning that they will not have to pay unnecessary charges from the following month.

In addition to the configuration described above in which the relevant license (account) is immediately suspended depending on usage, taking into consideration that there are different types of licenses even for the same service/product, it is also possible to configure the system to be able to notify/suggest changing/switching the same license from "Type A" to "Type B" depending on usage, for example.
For example, if the online conferencing software "WebMeeting" is available with both a free license and a paid license, and a user has used it recently, but all usage was within the free usage time (for example, within 30 minutes), the user can be notified and suggested to switch from the paid license to the free license.
Conversely, if the usage status always exceeds the free usage time (one hour or more), a notification or suggestion can be made to switch from a free license to a paid license. In this case, the usage time needs to be calculated and obtained from data such as logs.

FIG. 10 shows details of the processing operations in the license inventory optimization simulation described above.
As shown in the figure, in the license inventory optimization simulation, first, when an "usage status output instruction (1)" is issued by an administrator or the like of this system 1 (step 1001), a "system access record acquisition instruction" is sent to an external system 50 such as SSO (IDaaS) (step 1002), and record data of "Login-Logout" for each day of the past three months for, for example, online conferencing software "WebMeeting" is extracted from the external system 50 (step 1003) and sent to this system 1.

Although the system access records differ for each service, for example, in the case of a software application such as “WebMeeting”, and an external system 50 such as SSO (IDaaS), the usage status can be correctly obtained from the login/logout data.
In the case of a file server service, for example, in an external system 50 that provides a log collection and analysis service such as "Splunk (registered trademark)", it is possible to confirm by checking the existence of a log indicating that some file was accessed on that day.

When usage data is transmitted/acquired from the external system 50, the system 1 refers to the usage data and the data in the license usage DB 21, outputs a "usage output instruction (2) to be automatically executed as soon as the input data is collected" (step 1004), and generates a predetermined "usage output" (step 1005).
This "usage status output" is output, for example, as a "list of users with infrequent usage days," and a notification such as "usage status output has been completed" is sent or notified to the system administrator of this system 1, for example, by email (step 1006).
Then, based on the generated "usage status output", a predetermined "suspension simulation (to consider whether to suspend the service for those with low usage)" is executed (step 1007), and the results of the simulation are notified and transmitted from the system administrator to the applicant terminal 30 of the applicant for the service, together with a "confirmation email regarding whether to suspend the service for those with low usage" (step 1008).

The applicant side that has received the suspension simulation result can perform a "suspension consideration" to determine whether or not the corresponding license should be suspended (step 1009). Note that this "suspension consideration" is performed when an application (submission) for use of the corresponding license has been made and there is a shortage of paid licenses, so there is an advantage in that by suspending the notified license, it is possible to avoid paying unnecessary fees for a license that will not be used until the renewal deadline.
If the applicant determines that "suspension is OK" (step 1010), a notification and transmission of that fact is sent to system 1, and system 1 executes "license usage suspension registration", registers "in use → suspended & suspension date", etc. (step 1011), and changes and updates the data in license usage status DB 21 to "in use → suspended", etc.

FIG. 11 shows an image of the output of the license inventory optimization simulation described above.
FIG. 11A shows an example of a usage status output instruction screen. The following information is generated as a usage status output instruction and is output/displayed on the display of the service management server 10 or the applicant terminal 30.
1. License (name of license, etc.)
2. License type 3. Number of output users

FIG. 11B is an example of the usage status output, and the following information is generated as the usage status output result, and is output and displayed on the display of the service management server 10 or the applicant terminal 30.
1. License (name of license, etc.)
2. License type 3. Number of purchased licenses 4. Number of licenses in use 5. Remaining licenses (purchased licenses - (in use + test use))
6. Number of applications accepted (accepted and unprocessed)
7. Number of suspended licenses 8. Number of test licenses 9. Number of accepted applications - (remaining licenses + number of suspended licenses + number of test licenses)

Figure 11 (c) is an example of a usage status display, and for the "Usage status (few people) employee CD" as shown below, the relevant information for each of the items "Name, test use, number of days of use this month, number of days of use last month, number of days of use the month before last, number of days of use three months ago, applicant ID, and name" is output/generated and output/displayed on the service management server 10 or the display of the applicant terminal 30.
In this example, all test users and a specified number of people with low usage are output.

[License renewal optimization simulation]
Next, the operation of the license renewal optimization unit 13 (license renewal optimization simulation) will be described with reference to FIGS.
FIG. 12 shows an outline of the processing operation in the license update optimization unit 13. As shown in FIG.
As shown in the figure, the license renewal optimization unit 13 extracts unused user information while utilizing the functions of an external system 50, etc., and automatically notifies non-users whether or not they wish to renew and urges them to review their licenses, etc., and automatically executes renewal and cancellation processing according to requests, etc.

Specifically, the license update optimization unit 13 first obtains the Login-Logout record data for the target service (e.g., the online conference software "WebMeeting") from an external system 50 such as SSO (IDaaS) (step 1201), and then executes a predetermined license update optimization simulation based on the data (step 1202).
In this license renewal optimization simulation, a predetermined simulation is performed to determine whether or not renewal is necessary for each relevant account, based on data indicating the usage status of purchased licenses for each account obtained from the external system 50 and data stored in the purchased license DB 24 (including management data for suspended and dormant licenses) (see Figure 4).

In the example shown in FIG. 12, data of "License: 50" is extracted as the online conference software "WebMeeting: License Status" for "Using Department: Digital Workplace Division 3" from the license usage status DB21, and "Dormant accounts (unassigned): 10, Suspendable test accounts: 5, Unused in 3 months: 5" is extracted as "Can be abolished" data, and accounts such as "In use" and "Used once in the last n 3 months, 0 times in February, 0 times in January" are extracted as account information from the data obtained from the external system 50.

A simulation is run based on these data, and as a result, a notification such as "It appears possible to abolish a total of 20 licenses, but those who wish to abolish should apply for a minus license purchase" is generated, and this is notified to, for example, the applicant or user of the license, on the applicant terminal 30, requesting a "minus license application" (step 1203).
This provides the benefit of, for example, avoiding unnecessary contract renewals and the associated payments, by extracting services that would normally be automatically renewed annually as licenses that do not require renewal and can be abolished by this system 1.

FIG. 13 shows details of the processing operations in the license renewal optimization simulation described above.
As shown in the figure, in the license renewal optimization simulation, first, when an "Instruction to output usage status of renewal target (1) (license)" is made by an administrator of this system 1 or the like (step 1301), a "Instruction to obtain system access records" is sent to an external system 50 such as SSO (IDaaS) (step 1302), and record data of "Login-Logout" for each day of the past three months for, for example, the software "WebMeeting" is extracted from the external system 50 (step 1303) and sent to this system 1.

When the usage status data is transmitted and acquired from the external system 50, the system 1 refers to the usage status data and the data in the license usage status DB 21, outputs "an instruction to output the usage status of the person to be updated (2) to be automatically executed as soon as the input data is collected" (step 1304), and generates and outputs a predetermined "usage status of the person to be updated" (step 1005). In addition, data indicating this "usage status of the person to be updated" is stored in the license usage status DB 21, and information such as "record update for the next year is being accepted" is generated and stored.
This "usage status of the person to be updated" is output, for example, by "license > applicant unit", and a notification such as "output of the usage status of the person to be updated has been completed" is sent or notified to the system administrator of this system 1, for example, by email (step 1306).
The generated "update target user usage status" is then notified and transmitted from the system administrator to the applicant terminal 30 of the applicant for the service in the form of an "update confirmation email" or the like (step 1307).

Upon receiving the renewal confirmation mail, the applicant can carry out a "renewal review" to determine whether or not the corresponding license should be renewed (step 1308).
Once the applicant has decided whether or not renewal is necessary/will occur, a "scheduled renewal" indicating the result is entered via the applicant terminal 30 or the like (step 1309), which is then notified and transmitted to system 1. In system 1, "registration of continued license usage" is then executed, and registrations such as "In use -> Continue next year, Cancelled next year, Suspended ->Cancelled" are made (step 1310), and the data in license usage status DB 21 is changed/updated from "accepting record renewal for next year" to "In use next year, Cancelled", etc.

FIG. 14 shows an image of the output of the license renewal optimization simulation described above.
FIG. 14(a) is an example of an instruction screen for outputting usage status of a person to be updated. The following information is generated as an instruction for outputting usage status and is output and displayed on the display of the service management server 10 or the applicant terminal 30.
1. Fiscal year 2. License (Name of license, etc.)
3. License type 4. Applicant (if not entered, all applications will be output)
5. User (can be left blank)

FIG. 14(b) is an example of the usage status output of the person to be updated. The following information is generated as the usage status output result and is output and displayed on the service management server 10 or the display of the applicant terminal 30.
1. Fiscal year 2. License (Name of license, etc.)
3. License type 4. Applicant 5. User (can be left blank)
6. Number of licenses purchased (per applicant)
7. Number of licenses used 8. Number of suspended licenses 9. Number of test licenses used

Figure 14 (c) is an example of a display of the usage status of the person to be updated. For the "Usage status (low number of people) employee CD" as shown below, the relevant information for each of the items "Name, Usage, Number of days of usage this month, Number of days of usage last month, Number of days of usage the month before last, Number of days of usage three months ago, Applicant ID, Name" is output/generated and output/displayed on the display of the service management server 10 or the applicant terminal 30.
In this example, all test users and a specified number of people with low usage are output.

[License switching simulation]
Next, the operation (license switching simulation) of the license switching information generating unit 14 will be described with reference to FIGS.
FIG. 15 shows an outline of the processing operation in the license switching information generating unit 14. As shown in FIG.
As shown in the figure, in the license switching information generation unit 14, when there is a service equivalent to the currently contracted/used service, the conditions and costs of, for example, SSO, storage service, server service, container service, etc. are registered, and a fee simulation is performed in the case where the service is switched.

Specifically, the license switching information generation unit 14 refers to the data stored and registered in the license usage status DB 21, purchased license DB 24, purchase condition DB 25, and similar license DB 26 provided in the present system 1, searches and extracts data on similar services that are equivalent or identical to the currently contracted service, and performs a predetermined simulation to compare the fees that would be incurred if the service were switched (step 1501).
In the example shown in Figure 15, when services from companies A, B, etc. are searched for and extracted as equivalent or similar services to the currently used service, a list is generated and output in which the names of those services and their fees (prices) can be compared.
This will bring about benefits such as lowering the fees and reducing costs by changing or reviewing the services currently being used to other similar services that are roughly the same but less expensive.

FIG. 16 shows details of the processing operations in the above-described license switching simulation.
As shown in the figure, in the license switching simulation, first, when an "instruction to output a license switching simulation list" is given by an administrator or the like of this system 1 (step 1601), each data of the license usage status DB 21, the purchased license DB 24, the purchase condition DB 25, and the similar license DB 26 is referenced, and a predetermined "license switching simulation list" is generated and output (step 1602) in which "enter license > license type to list" is set for the current license that is the subject of switching determination and licenses similar to it.
In addition, in the similar license DB 26, for example, if there are multiple types of licenses, both paid and free, for the same "WebMeeting" software, equivalent similar licenses, such as corresponding paid and free licenses from other companies (for example, Company A, Company B, Company C, etc.), are registered, and the corresponding equivalent license is picked up.

FIG. 17 shows an output image of the above license switching simulation.
FIG. 17A is an example of a license switching simulation output instruction screen. The following information is generated as a usage status output instruction and is output/displayed on the service management server 10 or the display of the applicant terminal 30.
1. License (name of license, etc.)
2. License type 3. Applicant (if blank, all applications will be output)

FIG. 17B is an example of the license switching simulation output, and the following information is generated as the output result of the usage status, and is output and displayed on the service management server 10 or the display of the applicant terminal 30.
1. License (name of license, etc.)
2. License type 3. Number of purchased licenses 4. Number of licenses in use 5. Remaining licenses (purchased licenses - (in use + test use))
6. Number of applications accepted (accepted and unprocessed)
7. Number of suspended licenses 8. Number of test licenses 9. Number of accepted applications - (remaining licenses + number of suspended licenses + number of test licenses)

Figure 17 (c) is an example of a display of the usage status of similar licenses, and for the currently used "WebMeeting" and similar licenses from "Company A" and "Company B" as shown below, the relevant content for each of the items "license type, estimated comment, start date of use, end date of use, usage restrictions, unit price (monthly), number of licenses, amount, conditions, etc., estimated date, estimated validity date, number of days available for reassignment after suspension" is output/generated and output/displayed on the display of the service management server 10 or the applicant terminal 30.
For example, a basic usage scenario for this type of "usage status" would be to continue using the service until the end of the contract fiscal year, and then check the price difference if you were to use another service in the following year.

[Service cancellation list output]
Finally, the operation of the license cancellation information generating unit 15 (output of the service cancellation list) will be described with reference to FIGS.
FIG. 18 shows an outline of the processing operation in the license cancellation information generating unit 15. As shown in FIG.
As shown in the figure, the license cancellation information generation unit 15 utilizes the functions of an external system 50, etc., and, for example, when an account is terminated at the end of each month, outputs a list of licenses purchased by the terminated account, and automatically executes a process of encouraging the termination of each service by email, etc., if a termination request for the license has not been submitted.

Specifically, the license cancellation information generating unit 15 first obtains account cancellation information for the target service (e.g., online conference software "WebMeeting") from an external system 50 such as SSO (IDaaS) (step 1801), and generates and outputs a predetermined service cancellation list based on the cancellation information and the data stored in the purchased license DB 24 (including management data for suspended and dormant licenses) (see FIG. 4) (step 1802).

In the example shown in Figure 18, a list is generated and output that displays the service (system) name, contract period, and monthly fee for one or more currently subscribed services for which account cancellation information has been obtained.
This allows you to see at a glance which services have been discontinued even though the contract is still valid, and you can reliably extract the services and licenses that should be canceled or discontinued, thereby avoiding the continuation of unnecessary contracts and paying the associated costs.

FIG. 19 shows details of the service cancellation list output process performed by the license cancellation information generating unit 15 as described above.
As shown in the figure, in the service cancellation list output process, first, when a "resignation/leave of absence notice" or the like is sent to the external system 50 from the resigning employee or the company/department to which the employee belonged (step 1901), the external system 50 performs the "account disable/suspend process" for the relevant user (step 1902).

In the external system 50, the process of “invalidating accounts of employees who have left or are on leave of absence (employees who have left the company will be deleted after xx months)” is executed (step 1903), and then “instruction to create service cancellation data” (step 1904), “user > create data on service termination/suspension days” (step 1905), etc. are executed.
In this system 1, when the above-mentioned information on account invalidation/service termination is transmitted/obtained from the external system 50, a "service cancellation list creation instruction" is generated/output (step 1906) based on the information and the data (see FIG. 4) stored in the purchased license DB 24 (including management data on suspended/dormant licenses), and a predetermined "service cancellation list" is generated/output.

FIG. 20 shows an image of an input screen for instructions to create data for disabling or pausing an account and cancelling a service in the external system 50. In FIG.
As shown in the figure, the process of disabling or suspending an account in the external system 50 is carried out, for example, on the "SSO System" screen, where the "employee code" and "valid/invalid" of the relevant user are entered, and the process of validating/invalidating the account of that user is executed and confirmed by the "confirm" process.
In addition, the instruction to create service cancellation data in external system 50 is given, for example, on a "Service Cancellation List Creation Instruction" screen, where the target "system name" is selected, its "license type" and the cancellation reason for the user, "resignation/leave of absence", are selectably input, and the creation of the service cancellation list for that user is confirmed and executed by a "confirm" process.

FIG. 21 shows an output image of the service cancellation list.
Figure 21 is an example of a service cancellation list display. For licenses for which account cancellation information has been obtained even though a contract currently exists, the relevant information for each of the following items is output/generated: license, user ID, user name, applicant ID, applicant name, license type, monthly fee, status, start date of use, end date of use, suspension date, cancellation date, retirement date, and leave of absence date. This information is then output/displayed on the display of the service management server 10 or the applicant terminal 30.
This type of "service cancellation list" makes it possible to check and understand at a glance which services have had their accounts abolished even though the contract still exists, making it possible to reliably extract the services and licenses that should be canceled or abolished.

As described above, according to the present system 1, it is possible to dynamically monitor and determine the purchase, contract conclusion, renewal, suspension, discontinuance, etc. of various paid and free services contracted by companies, organizations, etc.
This makes it possible to automatically extract unnecessary services, inefficient operations, overlapping contracts, etc., and to optimize contracts and purchases by executing, reviewing, suspending, or canceling them.

For example, even if a service provider such as a cloud service or telecommunications carrier does not provide information because it is disadvantageous to the company, the simulation results of this system 1 can be output and presented in a timely manner as an appropriate usage and proposal report.
Also, by checking usage status before an annual contract expires, it is possible to immediately cancel or terminate any unnecessary services.
In addition, by monitoring and checking the monthly usage status of each of multiple contracts, it is possible to take measures such as changing plans, suspending or canceling them depending on the usage status.
Furthermore, for services that require multi-year (two-year) contracts, such as for mobile phones and smartphones, once that period (two years) has elapsed, it will be possible to consider changing or reviewing the model, plan, or contract company (carrier) at an appropriate time, taking into account usage patterns and other options.

In this way, according to the present system 1, appropriate reports and proposals can be presented in a timely manner to users (employees, employees, etc.) who use various services and to personnel (accountants, etc.) who manage the entire company/enterprise, including the organization (department, etc.) to which the users belong.
Therefore, it is possible to realize a service management system that is ideal for companies, organizations, and groups that need to properly manage the purchase and contract management and operation of various services, such as mobile phones, smartphones, and paid and free software applications that are provided or loaned to employees and staff of companies, organizations, and groups.

Although the present invention has been described above by showing preferred embodiments thereof, it goes without saying that the present invention is not limited to the above-described embodiments, and various modifications can be made within the scope of the present invention.
For example, in the above-described embodiment, various services contracted for and managed by companies, organizations, etc. have been described as examples of services and licenses that are the subject of the present invention, but the subjects to which the present invention can be applied are not limited to foreign companies, large groups, organizations, etc., and can be any company, organization, etc. of any size or type that is a business operator that purchases or contracts for one or more services and needs to review the contract contents, etc. on a daily basis, and are not particularly limited.
Therefore, even small and medium-sized enterprises, privately-run companies, freelancers, and the like can apply the present invention to monitor unnecessary services, duplicate contracts, and the like, and perform optimal operations.

In the above-described embodiment, as an example, the service management server 10 and the applicant terminal 30 are installed in the internal network of one company and connected to each other. However, the service management server 10 may be installed in the system company, and the applicant terminals 30 of multiple client companies of the system company may access the service management server 10 from outside to receive the service functions of the service management server 10 (SaaS configuration). Note that even in the SaaS configuration, some functions of the service management server 10 may remain on the client company side as server or client functions.

The present invention can be suitably used as a service management system to support the management and operation of various services, such as mobile phones, smartphones, and paid and free software applications, that are provided or loaned to employees and staff of companies, organizations, and other such organizations.

REFERENCE SIGNS LIST 1 Service management system 10 Service management server 11 License purchase optimization unit 12 License inventory optimization unit 13 License renewal optimization unit 14 License switching information generation unit 15 License cancellation information generation unit 20 Service management database 21 License usage status database 22 Service cancellation information database 23 Service cancellation list database 24 Purchased license database 25 Purchase condition database 26 Similar license database 30 Applicant terminal 50 External system

Claims (4)

A system for managing the optimization of license contracts and purchases for one or more specified services contracted on a specified contract basis, comprising:
a storage means for storing predetermined license information including usage status information, purchase information, and purchase condition information of each license for identifying the license under contract , and predetermined similar license information indicating one or more similar licenses ;
a license purchase optimization unit that, when a license contract application is received from a user, executes a predetermined license purchase optimization simulation to determine whether or not the license should be purchased based on the usage status information, purchase information, and purchase condition information of each license stored in the storage means, and executes a predetermined license purchase process based on a result of the simulation;
a license switching information generating unit that executes a license switching simulation to determine whether or not there is a similar license to be switched with the license based on any one of the use status information, purchase information, purchase condition information, and similar license information of each license stored in the storage unit, and generates switching list information indicating the relevant similar license based on a result of the simulation ,
The license switching information generation unit
Refer to the storage means, extract data on services similar to the current service related to each license, execute a simulation to compare the fees when the service is switched, and generate a list that displays the names and fees of the current service and one or more similar services in a comparative manner.
A service management system comprising: 2. The service management system according to claim 1, further comprising a license inventory optimization unit that executes a license inventory optimization simulation to determine whether or not a license should be suspended based on the usage status information of each license stored in the storage means and predetermined login/logout information for each license, and that executes suspension processing for the corresponding license based on the results of the simulation. The service management system according to claim 1 or 2, further comprising a license update optimization unit that performs a license update optimization simulation to determine whether or not a license should be revoked based on the usage status information of each license stored in the storage means and predetermined login/logout information for each license, and that performs a revocation process for the corresponding license based on the results of the simulation. The service management system according to any one of claims 1 to 3, further comprising a license cancellation information generation unit that generates cancellation list information indicating the corresponding licenses to be cancelled based on the purchase information of each license stored in the storage means and predetermined account cancellation information for each license.

Images