License management method

Abstract

To efficiently permit the license of an application program.SOLUTION: In a license request management server 10 for managing the acquisition of license permission necessary for the execution of an application program, the acquisition request of the license of the application program is received from a client 30 to which the start of the application program is requested. A license request management server 10 acquires information related to the attribute of a user 50 who requests the start of an application program (110), acquires priority to the user on the basis of priority preliminarily applied to the attribute (120), and determines the propriety of the permission of a license to a client on the basis of the priority to the user (130).SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to software license management, and more particularly to a method for managing software licenses that limit the number of users who can use the software simultaneously. [Background technology]

[0002] Generally, paid programs can be used under the license that has been acquired. One type of program license is a floating license, which allows use by multiple users but limits the number of users who can use the program simultaneously. With a floating license program, when a user starts the program, the license server is accessed from the terminal (client) used by the user. The license server grants a license to a user if the number of users using the program simultaneously falls within the number of users that can be licensed. When a license is granted by the license server, the user can use the program from that client.

[0003] An example of a management device for performing such license management is described in Patent Document 1. Patent Document 1 discloses that when the number of users using the software simultaneously reaches the license upper limit, the priority of the users is checked, and if there is a user with a low priority, the license is reclaimed from that user and the license is granted to a user with a high priority. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 5-346851 Summary of the Invention [Problem to be solved by the invention]

[0005] In organizations such as companies, product development projects and other tasks are typically carried out by multiple people. The urgency of the tasks can change depending on factors such as the product delivery date and the project phase. The management device described in Patent Document 1 determines whether to grant a license based on the priority assigned to each user. Therefore, it is necessary to manage the priority for each user depending on the user's level of involvement in the project or task. Furthermore, if the priority changes between projects or tasks, it is necessary to change the priority for all users involved, which makes priority management cumbersome.

[0006] The object of the present invention is to solve the problems of the prior art described above, and to enable efficient license management in a business system that uses an application program that limits the number of users that can use the program simultaneously and requires a license to be obtained when the program is executed, by flexibly setting the priority used to determine whether or not to grant a license. [Means for solving the problem]

[0007] In order to solve the above-mentioned problems, in one preferred aspect, the license management method of the present invention is implemented by a management device that is connected to a terminal used by a user via a network and manages the acquisition of licenses necessary for the user to execute an application program. The management device receives a request to acquire a license for the application program from a client that has requested the application program to be started, acquires information about the attributes of the requesting user who requested the application program to be started, acquires a priority for the requesting user based on predetermined priorities for the attributes, and determines whether to grant a license to the client based on the priority for the requesting user. [Effects of the Invention]

[0008] According to the present invention, a priority for a user is obtained from information about the user's attributes based on the priority set for the attributes, and a license grant decision is made, thereby enabling flexible and efficient management of user priorities. Other novel features of the present invention and the technical problems solved thereby will become apparent from the description and drawings of this specification. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a schematic block diagram illustrating a system configuration in an embodiment of a development system. [Figure 2] FIG. 2 is a schematic block diagram showing the logical configuration of a license request management server. [Figure 3] FIG. 2 is a schematic diagram showing the configuration of history information stored in a database. [Figure 4] FIG. 2 is a schematic diagram showing the configuration of user information stored in a database. [Figure 5] FIG. 2 is a schematic diagram showing the configuration of project information stored in a database. [Figure 6] FIG. 2 is a schematic diagram showing the configuration of license information stored in a database. [Figure 7] 10 is a flowchart showing the flow of processing executed by an input information extraction unit. [Figure 8] 10 is a flowchart showing the flow of processing executed by a priority acquisition unit. [Figure 9] 10 is a flowchart showing the flow of processing executed by a priority comparison unit. [Figure 10] 10 is a flowchart showing the flow of processing executed by a history information registration unit. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[0011] FIG. 1 is a schematic block diagram showing the system configuration of an embodiment of a development system to which the present invention is applied.

[0012] The development system of this embodiment is configured to include a license request management server 10, a license management server 20, and a client 30. The license request management server 10, the license management server 20, and the client 30 are connected to each other via a network 40 such as a local area network (LAN).

[0013] The license request management server 10 and the license management server 20 can be computers such as general personal computers or servers equipped with a processor, memory, an auxiliary storage device which is a nonvolatile storage device, etc. The various functions of the license request management server 10 and the license management server 20 are realized by the processor executing programs stored in memory or loaded from the auxiliary storage device to memory. The license request management server 10 and the license management server 20 may also be equipped with a display for displaying various information, a keyboard, a mouse, etc. which can be used by the user to input commands. Similarly, the client 30 can be configured using a general personal computer equipped with a processor, memory, an auxiliary storage device which is a nonvolatile storage device, and input / output devices such as a display device, a keyboard, and a mouse.

[0014] The license request management server 10 executes a license request management program that manages the license grant status for application programs used by the clients 30. The license request management server 10 accepts a request for a license required to execute an application program from the client 30, and if the license can be granted according to the license grant status, the license request management server 10 requests the license management server 20 to issue a license and sends the issued license to the requesting client 30. When execution of the application program on the client 30 is completed, the license request management server 10 accepts a license return from the client 30 and returns the license to the license management server.

[0015] The license management server 20 executes a license management program that manages the usage rights of application programs running on the clients 30. In response to license requests for application programs sent via the license request management server 10, the license management server 20 grants licenses based on license rights and collects granted licenses. The license management server 20 also provides functions such as displaying the usage status of application programs using a GUI (Graphical User Interface) or CUI (Character User Interface) and forcibly stopping application programs being used by the clients 30.

[0016] The client 30 is used by a user to execute various application programs, such as tools used by the user in development work. Here, the software is assumed to be application programs, such as tools used in development work, but it is not limited to these, and can also be applied to application programs used outside of development work and other general software. By obtaining a license issued by the license management server 20, the client 30 can execute the application program corresponding to that license.

[0017] The license request management server 10 and the license management server 20 can be configured using a computer such as a general personal computer or server equipped with a processor, memory, and an auxiliary storage device that is a non-volatile storage device. The various functions of the license request management server 10 and the license management server 20 are realized by the processor executing the license request management program or license management program stored in memory or loaded from the auxiliary storage device to memory. The license request management server 10 and the license management server 20 may also be equipped with a display for displaying various information, a keyboard, a mouse, and the like that can be used by the user to input commands. The license request management server 10 and the license management server 20 may be provided as a dedicated device in addition to the general computer described above.

[0018] Similarly, the client 30 can be configured using a general personal computer equipped with a processor, memory, an auxiliary storage device which is a nonvolatile storage device, and input / output devices such as a display device, keyboard, and mouse.

[0019] In this embodiment, the license request management server 10 and the license management server 20 are implemented as separate devices connected via a network 40, but the functions of both may be implemented by a single server. Also, although the application program is assumed to run on a client 30 used by a user, it may also be executed on a server (not shown) in response to a request from the client 30.

[0020] FIG. 2 is a schematic block diagram showing the logical configuration of the license request management server in this embodiment.

[0021] The license request management server 10 includes an input information extraction unit 110, a priority acquisition unit 120, a priority comparison unit 130, and a history information registration unit 140. A database 200 is connected to the license request management server 10, and stores history information 210, user information 220, project information 230, and license information 240. The database 200 is provided in the license request management server 10 and is realized by an auxiliary storage device that stores this information. Note that the database 200 may be configured so that some or all of the stored information is held by another device connected via a network 40 and provided by the other device via the network 40.

[0022] The input information extraction unit 110 receives a license acquisition request sent from the client 30 when the user 50 starts an application program on the client 30. The license acquisition request includes information about the user 50 who is trying to start the application program and information about the application program, and the input information extraction unit 110 acquires this information.

[0023] Based on the information about the user 50 and the information about the application program extracted by the input information extraction unit 110, the priority acquisition unit 120 acquires the priority when the user 50 uses the application program.

[0024] The priority comparison unit 130 determines whether or not to acquire a license based on the license grant status for the application program for which license acquisition is requested, the priority of the user 50 acquired by the priority acquisition unit 120, and the priorities of other users who are using the application program.

[0025] The history information registration unit 140 updates the history information 210 and the user information 220 based on the determination result of the priority comparison unit 130. Furthermore, if it is possible to acquire a license for the license acquisition request accepted by the input information extraction unit 110, the history information registration unit 140 transmits the license acquisition request to the license management server 20.

[0026] FIG. 3 is a schematic diagram showing the configuration of the history information 210 stored in the database 200. As shown in FIG.

[0027] The history information 210 includes a usage history table 211 in which the usage history of application programs is recorded. The usage history table 211 has fields such as "serial number," "user ID," "software ID," "terminal address," "usage start date and time," "usage end date and time," and "priority." In this embodiment, the usage history table 211 is stored in the database 200 as table-format data, but the information stored in the usage history table 211 is not limited to the table format and may be managed in other formats such as a list format. The same applies to information stored in the database 200 other than the usage history table 211.

[0028] The "serial number" is information for managing the information stored in the usage history table 211, and a unique number is issued at the time of registration. The serial number does not have to be a consecutive number like a general serial number, and may be composed of a character string including letters and symbols other than numbers, as long as it is unique for each row of the usage history table 211.

[0029] "User ID" is information for identifying a user who is using or has used an application program, and is registered with a user ID managed in a user management table, which will be described later.

[0030] "Soft ID" is information for identifying an application program that is in use or has been used, and the soft ID of the application program managed in the license management table, which will be described later, is registered here.

[0031] In the "terminal address" field, the address on the network of the client 30 where the user is using or has used the application program is registered.

[0032] The "use start date and time" and "use end date and time" register the date and time when use of the application program began and ended, respectively. Here, each date and time is expressed as a combination of the year, month, day, hour, and minute, represented by digits for each digit, but any format that can be used to identify the required date and time can be used. A row in which the "use end date and time" field is blank indicates that the user has not finished using the application program, i.e., the program is still in use. Note that when an application program is shared between bases in countries or regions with different time zones, it is preferable to use a common time such as Coordinated Universal Time (UTC) for the date and time.

[0033] In "Priority", the priority acquired by the priority acquisition unit 120 when starting to use the application program, as will be described later, is registered. If there is a scheduled task, the priority is recalculated and updated every hour using the user ID and software ID.

[0034] FIG. 4 is a schematic diagram showing the configuration of the user information 220 stored in the database 200. As shown in FIG.

[0035] The user information 220 is composed of three tables: a user management table 221 in which information about individual users is registered; an area management table 222 in which information about the areas to which users belong is registered; and a suspended user management table 223 in which information about users who have not been granted a license or whose licenses have been forcibly suspended is registered.

[0036] The user management table 221 has fields for, for example, "user ID," "user name," "area ID," and "contact information." Information that identifies an individual user is registered in the "user ID." Information unique to an individual, such as an employee number, can be used as the "user ID." The name of the user identified by the user ID, for example, the first and last name, is registered in the "user name." The "area ID" is information for identifying the area to which the user belongs, and is registered with the area ID managed in the area management table 222 described below. Information that can be used for notifying the user, such as the user's email address, is registered in the "contact information."

[0037] The area management table 222 has four fields, for example, "area ID," "area name," "operation start time," and "operation end time." In "area ID," unique information assigned to each area where an application program is used is registered. In "area name," the name of the area identified by the area ID is registered. The area here refers to the location where the user uses the application program, and in this embodiment, the name of a base, such as a factory name or research institute name, is used. In addition to the name of such a base, the name of the location or region where the base is located may also be used as the area name. In "operation start time" and "operation end time," for example, the scheduled start and end times of work in each area are registered.

[0038] The suspended user management table 223 has fields for, for example, "user ID," "software ID," and "date and time of suspension of use." The "user ID" field is registered with the user ID of a user who was not granted a license for an application program due to priority, or whose license was forcibly suspended while using the application program, making it impossible for the user to use the application program. The "software ID" field is registered with the soft ID of an application program whose use has been suspended, which is managed in the license management table described below. The "date and time of suspension of use" field is registered with the date and time of a license acquisition request for which a license was not granted, or the date and time when the license was forcibly suspended.

[0039] FIG. 5 is a schematic diagram showing the configuration of the project information 230 stored in the database 200. As shown in FIG.

[0040] The project information 230 includes a project management table 231 in which information about each individual project is registered, and a responsible user table 232 in which information about users participating in each project is registered.

[0041] The project management table 231 has fields for, for example, "project ID," "project name," "project priority," "project start date," and "project end date." "Project ID" is information that identifies an individual project, and unique information is registered for each project. "Project name" is registered with the name of the project identified by the project ID. "Project priority" is information that indicates the priority of each project. "Project start date" and "project end date" are registered with the start date and end date of the project, respectively.

[0042] The responsible user table 232 has, for example, fields for "project ID" and "user ID." In the "project ID," the project ID of the project managed in the project management table 231 is registered. In the "user ID," the user ID of the user participating in the project identified by the project ID registered in the corresponding "project ID" is registered.

[0043] FIG. 6 is a schematic diagram showing the configuration of the license information 240 stored in the database 200. As shown in FIG.

[0044] The license information 240 includes a license management table 241 that manages the licenses of application programs.

[0045] The license management table 241 has fields for "software ID," "software name," and "number of licenses." The "software ID" is information unique to each application program that identifies the application program used within the system. The name of the application program identified by the software ID is registered in "software name." The number of licenses that are permitted for simultaneous use for each application program is registered in "number of licenses."

[0046] FIG. 7 is a flowchart showing the flow of processing executed by the input information extraction unit 110.

[0047] When the user 50 launches the application program 300 on the client 30, the license acquisition request sent from the application program 300 is received by the input information extraction unit 110. The license acquisition request includes a user ID that identifies the user 50 and a software ID that identifies the application program. Upon receiving the license acquisition request, the input information extraction unit 110 obtains the user ID and the software ID from the license acquisition request (step S700).

[0048] The input information extraction unit 110 acquires the area ID registered for the user 50 from the user management table 221 included in the user information 220 based on the acquired user ID (step S710). Next, the input information extraction unit 110 searches the area management table 222 of the user information 220 using the acquired area ID, and acquires the operation start time and operation end time of the area identified by the acquired area ID (step S720). The input information extraction unit 110 further searches the stopped user management table 223 based on the user ID and software ID, and if there is registered information, stores the status (step S730).

[0049] Next, the input information extraction unit 110 searches the responsible user table 232 of the project information 230 based on the user ID to obtain the project ID of the project in which the user 50 identified by the obtained user ID is participating (step S740). Subsequently, the input information extraction unit 110 searches the project management table 231 of the project information 230 based on the project ID to obtain information on the project priority and the project end date (step S750).

[0050] The input information extraction unit 110 further searches the license management table 241 of the license information 240 based on the acquired software ID, and acquires the number of licenses that can be granted (step S760).

[0051] The input information extraction unit 110 then searches the usage history table 211 of the history information 210 based on the acquired user ID and software ID to acquire the usage history of the application program for which the user 50 has requested license acquisition. From the acquired usage history, the input information extraction unit 110 acquires, for example, the number of times and duration of usage of the application program by the user 50 over the past three months (step S770). The input information extraction unit 110 also searches the usage history table 211 of the history information 210 based on the acquired software ID to acquire information about the application program in use, i.e., information for which the "usage end date and time" field is blank. The input information extraction unit 110 then acquires the number of licenses in use from the number of pieces of information acquired, and the priority of the user currently using the application program from the "priority" field of each piece of information (step S780).

[0052] FIG. 8 is a flowchart showing the flow of processing executed by the priority acquisition unit 120.

[0053] The priority acquisition unit 120 acquires the priority of the license acquisition request received after processing by the input information extraction unit 110.

[0054] In the process by the priority acquisition unit 120, a priority based on the usage history is first acquired from the number of times and usage time of the application program by the user 50 acquired by the input information extraction unit 110. For example, threshold values ​​are determined for each of the number of times of use and usage time, and the priority is set to "0" when both the number of times of use and usage time are below the threshold, "1" when one is equal to or greater than the threshold and the other is below the threshold, and "2" when both are equal to or greater than the threshold. In this embodiment, the priority is set higher as the numerical value increases. Note that here, the number of times of use and usage time are both divided into two levels to set the priority, but they may be divided into more detailed levels. Furthermore, the number of times of use and usage time do not need to be divided into the same number of levels, and priorities may be set by dividing them into any number of levels (step S800).

[0055] Next, the priority acquisition unit 120 acquires the priority of the project in which the user 50 participates, based on the project priority acquired by the input information extraction unit 110. For example, if the project priority has three levels, "A," "B," and "C," the respective priorities are acquired as "2," "1," and "0." The project priority and the acquired priority do not necessarily have to correspond one-to-one. For example, the priority can be acquired in any relationship, such as setting the priority to "2" when the project priority is "A" and setting the priority to "1" when the project priority is "B" or "C." Furthermore, instead of acquiring the priority indirectly from the project priority, the priority used here may be directly registered in the "project priority" field of the project management table 231, so that the project priority acquired by the input information extraction unit 110 can be used as the priority here (step S810).

[0056] The priority acquisition unit 120 then acquires a priority based on the duration of the project from the acquired information on the project's end date. The priority based on the project's duration is determined by acquiring the period until the end of the project from the acquired information on the project's end date and determining the priority based on the length of the remaining period. For example, the priority can be acquired as "2" when the remaining period of the project is less than 10 days, "1" when it is 10 days or more but less than 20 days, and "0" when it is 20 days or more (step S820).

[0057] Next, the priority acquisition unit 120 acquires a priority based on the core time, based on the operation start time and operation end time acquired from the area management table. Core time here refers to the regular working hours in each area. In this embodiment, core time is defined as the period from the operation start time to the operation end time registered in the area management table 222, and the priority is acquired depending on whether the current time is within the core time. For example, if the current time is within the core time, the priority is acquired as "4," and if it is outside the core time, the priority is acquired as "0." For example, when an application program is shared between countries or regions in different time zones, including a priority based on time in this way enables operation that takes into account the time difference between areas (step S830).

[0058] The priority acquisition unit 120 further acquires a priority according to whether or not there is a suspension history for the user 50 in the suspended user management table 223. If the user ID of the user 50 is registered in the suspended user management table 223 and there is a suspension history, the priority based on the suspension history is set high to give preferential permission for use. For example, if there is a suspension history, the priority is set to "12," and if there is no suspension history, the priority is set to "0" (step S840).

[0059] Finally, the priority acquisition unit 120 adds up the priorities acquired in steps S800 to S840 to acquire an overall priority (step S850). FIG. 9 is a flowchart showing the flow of processing executed by the priority comparing unit 130.

[0060] When the priority acquisition unit 120 acquires the priority of the user 50 who issued the license acquisition request, the priority comparison unit 130 compares the information on the number of licenses acquired from the license management table 241 by the input information extraction unit 110 with the number of licenses in use also acquired by the input information extraction unit 110 (steps S900, S905). If the number of licenses acquired from the license management table 241 is greater, there is a license that can be granted, so the priority comparison unit 130 ends the process without performing any further processing.

[0061] If the determination result in step S905 is negative, it means that there is no license that can be granted. Therefore, the priority comparison unit 130 compares the lowest priority among the priorities of the users currently using the software acquired in step S780 with the priority of the user 50 acquired by the priority acquisition unit 120 (steps S910 and S915).

[0062] If the priority of user 50 acquired by the priority acquisition unit 120 is lower, there is no license to be assigned to user 50. Therefore, the priority comparison unit 130 notifies the client 30 that sent the license acquisition request of a "not available" message. At this time, the priority acquisition unit 120 may notify the client 30 of the acquired priority, as well as the priority of each active user and the start time of use of the application program acquired in step S780, and cause the client 30 to display these. Alternatively, the priority acquisition unit 120 may predict the end time of use of the application program by the active user based on the start time of use, obtain an estimated waiting time, and notify this to the client 30 to display it. In this way, the user 50 whose license acquisition was denied can know the time when the application program will be available for use (step S920).

[0063] At this time, the priority comparison unit 130 also secures a new entry in the suspended user management table 223 of the user information 220, and registers the user ID and software ID acquired from the license acquisition request. The current date and time is registered in the "usage suspension date and time" field of this entry (step S925).

[0064] On the other hand, if the priority of user 50 who requested license acquisition is determined to be higher in step S915, the execution state of the application program by the currently using user whose priorities were compared is saved and a determination is made as to whether execution of the application program can be interrupted. If saving is not possible and the license of that user is forcibly stopped, the work performed up to that point will be wasted, resulting in a decrease in efficiency. Therefore, in such a case, priority comparison unit 130 selects the user with the next lowest priority among the currently using users obtained in step S780, and repeats the process from step S910 (step S930).

[0065] If the execution status of the currently using user can be saved, the priority comparison unit 130 notifies the client 30 used by the selected currently using user that the use of the application program has been stopped, and instructs it to save the execution status. At this time, the client 30 notifies the user by displaying a message that the use of the application program has been stopped (step S935). Next, the priority comparison unit 130 newly registers the user ID and software ID of the currently using user and the current date and time in the stopped user management table (step S940). Furthermore, the priority comparison unit 130 searches the usage history table 211 based on the user ID of this user and the software ID of the application program, and registers the current date and time as the usage end date and time in the "usage end date and time" field of the corresponding entry (step S945).

[0066] Finally, the priority comparison unit 130 notifies the license management software 500 on the license management server 20 of the license suspension of the application program being executed on the client 30 used by the user, and then ends the process (step S950).

[0067] FIG. 10 is a flowchart showing the flow of processing executed by the history information registration unit 140.

[0068] If the license acquisition request can be granted, the history information registration unit 140 searches the suspended user management table 223 based on the user ID and software ID to check whether there is a suspended use history that matches the user ID and software ID. If there is a suspended use history, the history information registration unit 140 deletes the suspended use history from the suspended user management table 223 (step S1000).

[0069] The history information registration unit 140 then creates a new entry in the usage history table 211 and records the user ID, software ID, and priority in the corresponding fields. It also records the current date and time in the "usage start date and time" field and the network address of the client that sent the license acquisition request in the "terminal address" field (step S1010).

[0070] Next, the history information registration unit 140 requests the license management software 500 on the license management server 20 to grant a license to the client 30 that launched the application program. Once the license management software grants a license, it is sent to the requesting client 30, and the process ends (step S1020).

[0071] According to the embodiment described above, licenses are assigned and replaced based on the priority obtained according to the attributes of each user, so that license management can be performed flexibly and application programs can be used efficiently.

[0072] For example, as described above, by using the type of work, such as the project to which a user belongs, as an attribute, even if the priority of the work changes, the priority of the work can be changed between related users by resetting the priority of the work. This eliminates the need to reset the priority for each user, enabling efficient operation. Furthermore, by obtaining priorities according to the duration of work, such as projects, it is possible to flexibly set priorities that suit the actual situation in the organization.

[0073] When terminating the license of a user who is already using the application program, the license is forcibly terminated after checking whether the use of the application program in use can be interrupted, such as whether the intermediate state can be saved, so that it is possible to prevent users with low priority from repeating tasks.In addition, information about users who could not obtain a license or whose license was terminated midway is recorded, and the priority of such users is increased the next time they request license acquisition, so that it is possible to prevent excessive suppression of use of application programs by users with low priority.

[0074] While the present invention has been specifically described above based on its embodiments, the present invention is not limited to these embodiments and can be modified in various ways without departing from the spirit of the present invention. For example, in the above-described embodiment, the license management server transfers the license to the client via the license request management server. However, the license management server may directly transfer the license to the client. Furthermore, the functions realized by the license request management program may be incorporated into the license management program as one of its functions. Furthermore, when a user stops using an application program, the client may notify the user by a message or the like that the program has been stopped and that the status of the program has been saved. If the user does not stop the program, the client may forcibly stop the program. [Explanation of symbols]

[0075] 10: License request management server, 20: License management server, 30: Client, 40: Network, 50: User, 110: Input information extraction unit, 120: Priority acquisition unit, 130: Priority comparison unit, 140: History information registration unit, 200: Database, 210: History information, 220: User information, 230: Project information, 240: License information

Claims

1. 1. A license management method implemented by a management device that is connected to a terminal used by a user via a network and manages acquisition of a license necessary for the user to execute an application program, comprising: receiving a request to acquire a license for the application program from a client that has requested the launch of the application program; obtaining information about the attributes of a requesting user who has requested the launch of the application program; obtaining a priority for the requesting user based on a predetermined priority for the attribute; A license management method for determining whether or not to grant the license to the client based on the priority of the requesting user.

2. 2. The license management method according to claim 1, wherein the attribute relates to the type of business in which the user is involved, and the priority of the user is obtained based on a priority given according to the type of business.

3. 3. The license management method according to claim 2, wherein the priority given according to the type of business includes a priority according to the period of the business.

4. 2. The license management method according to claim 1, wherein the attribute is an area to which the user belongs, and the priority of the user is acquired based on a priority according to a time period for each area.

5. 5. The license management method according to claim 1, wherein the priority of the user is acquired taking into consideration a usage history of the application program by the user.

6. The process of determining whether or not the permission is granted is as follows: determining whether the number of application programs already being executed has reached the number of licenses that can be granted and whether a new license cannot be granted; A license management method according to any one of claims 1 to 4, characterized in that if it is determined that a new license cannot be granted, the user having the lowest priority among the users currently using the application program that is currently running is selected, the priority of the selected user is compared with the priority obtained for the user who requested the launch, and the license is granted to the user with the highest priority.

7. The license management method according to claim 6, characterized in that the process of implementing the granting of the license rejects the request for granting of the license of the application program by the requesting user if the selected using user has a higher priority.

8. The license management method according to claim 7, characterized in that the process of implementing the granting includes, if the requesting user has a high priority, suspending the granting of the license for the application program being executed on a client used by the selected active user, and granting the license to the client used by the requesting user.

9. The license management method according to claim 8, characterized in that the process of suspending the permission includes a process of confirming whether the execution of the application program by the currently using user can be suspended, and if the execution of the application program cannot be suspended, a currently using user having the next lowest priority after the selected currently using user is selected, and the process of implementing the permission is repeated.

10. The license management method according to claim 9, characterized in that the process of suspending the license includes a process of instructing the client used by the selected user to save the execution status of the application program being executed, and the process of confirming whether the execution can be stopped confirms whether the execution can be stopped based on whether the execution status can be saved.

11. The license management method according to claim 10, characterized in that the process of terminating the permission includes a process of terminating the application program being executed on the client being used by the selected user when it is determined in the process of checking whether the execution state can be saved that the execution state can be saved.

12. the process of suspending the license includes a process of acquiring a suspension history for a user whose license has been denied or suspended; 9. The license management method according to claim 8, wherein the process of acquiring the priority includes a process of increasing the priority when a history of the suspension of use has been acquired for the requesting user.

13. The license management method according to claim 8, characterized in that the process of terminating the license includes a process of notifying the client used by the selected user of a message prompting the client to stop the application program being executed and save its execution state.

14. The license management method according to claim 8, characterized in that the process of suspending the permission includes a process of obtaining the priority of the currently using user and notifying the client used by the requesting user of the priority for each currently using user.

15. The license management method according to claim 14, wherein the notification process includes a process of predicting the end time of the use of the application program by the currently using user based on the start time of the use of the application program by the currently using user, and obtaining an estimated waiting time, and notifying the waiting time together with the priority for each user.

Images