JP7279558B2 - License management system and program - Google Patents

Description

The present invention relates to a license management system and program.

Application program license agreements include a form of granting to an individual user and a form of granting to an organization. It should be noted that there is also a form in which a license is given to an organization in which an administrator in the organization is authorized to give a license to a user in the organization. For this reason, prior art documents have proposed a mechanism for uniformly managing various forms of license agreements.

JP 2016-173715 A

Application programs installed in each terminal may be individually upgraded by the user of each terminal. In that case, the user who performed the version upgrade knows the current version of the application program.
However, the administrator in the organization and the administrator who provides the application program cannot know the version of the application program installed in each individual terminal operated by the user.
For this reason, even if a version of an application program that may cause serious problems in the user's usage environment remains unupdated, or if a version of an application program whose support has expired remains on the terminal, the administrator is unaware of its condition.

SUMMARY OF THE INVENTION It is an object of the present invention to enable administrators to check versions of application programs installed in terminals used by individual users.

According to a first aspect of the present invention, there is provided a generating means for generating first information identifying a version of an application program in use, a transmitting means for transmitting said first information to an administrator, and an object to be managed. and linking means for linking second information representing a license generated according to a result of verifying that the version of the application is in a recommended state, with the version identified by the first information. and the second information is a license management system, which is information that prohibits access to the application program in use.
The invention according to claim 2 is the license management system according to claim 1 , wherein the second information is managed in association with a user associated with the version.
According to the third aspect of the invention, the computer has a function of generating first information identifying the version of the application program in use, a function of transmitting the first information to the administrator , and and a function of linking second information representing a license generated according to a result of verifying that the version of an application is in a recommended state to the version identified by the first information. and wherein the second information is information that prohibits access to the application program in use .

According to the first aspect of the invention , it is possible to stop using a version that may cause a serious problem in the user's usage environment.
According to the second aspect of the invention, use of the current version can be suspended for each user until the version changes.
According to the third aspect of the invention , it is possible to stop using a version that may cause serious problems in the user's usage environment .

1 is a diagram illustrating an example of a system configuration of an information processing system according to an embodiment; FIG. 2 is a diagram illustrating an example of functions provided in a server and a terminal device that constitute an information processing system; FIG. FIG. 10 is a diagram illustrating an example of a data structure at the time of a license contract; FIG. 10 is a diagram illustrating an example of a data structure when a problem is confirmed in the authenticity of the version in use; FIG. 10 is a diagram illustrating another data structure example when there is a problem with the authenticity of the version in use; FIG. 4 is a diagram illustrating an example of a data structure when a licensee is a tenant; FIG. 10 is a diagram illustrating application object generation processing executed between a first terminal device and a server used by a vendor that provides an application; FIG. 10 is a diagram illustrating version object generation processing executed between a first terminal device and a server used by a vendor that provides an application; FIG. 4 is a diagram for explaining license object generation processing executed between a first terminal device and a server used by a vendor that provides an application; FIG. 10 is a diagram illustrating display processing of a management screen such as a license executed between a first terminal device used by an application vendor and a server; FIG. 10 is a diagram showing an example of a license management screen;

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, embodiments of the present invention will be described with reference to the drawings.
<Embodiment>
<System configuration>
FIG. 1 is a diagram showing an example of a system configuration of an information processing system 1 according to an embodiment.
The information processing system 1 shown in FIG. 1 has a server 10, a first terminal device 30-1, a second terminal device 30-2, and a third terminal device 30-3.
The server 10, the first terminal device 30-1, the second terminal device 30-2, and the third terminal device 30-3 can communicate with each other via the network 2. FIG.

In the case of this embodiment, the first terminal device 30-1 is a device used by a vendor who is a licensor of an application program (hereinafter referred to as "application"), and the second terminal device 30-2 is a licensee of the application. , and the third terminal device 30-3 is a device used by the administrator of the tenant who contracts the application.
A tenant is a concept that is used when managing application licenses on a per-organization basis. One tenant is established for one contract.

A licensee in this embodiment may be an individual or a tenant. If the Licensee is a Tenant, within the scope of the Agreement, the Tenant Administrator grants licenses to users participating in the Tenant. Therefore, the second terminal device 30-2 includes both a terminal operated by an individual who is a licensee and a terminal operated by an individual who participates in the tenant.
Thus, the information processing system 1 can flexibly deal with various license forms.
In this embodiment, the terminal device 30 is used when generically referring to the first terminal device 30-1, the second terminal device 30-2, and the third terminal device 30-3.

The server 10 in the present embodiment is a computer that provides a service of providing the version of the application installed in the second terminal device 30-2 to the manager of the vendor or the manager of the tenant. The server 10 here is an example of a license management system.
A server 10 shown in FIG. 1 includes a control unit 11 , a storage unit 12 and a communication unit 13 .
The control unit 11 includes a CPU (=Central Processing Unit), a ROM (=Read Only Memory) storing BIOS (=Basic Input Output System), etc., and a RAM (=Random Access Memory) used as a work area. contains.
The control unit 11 here controls various calculations and the operation of each unit that constitutes the device through the execution of programs stored in the storage unit 12 .

The storage unit 12 stores information such as versions of applications installed in the second terminal device 30-2, as well as programs such as basic software and applications. The storage unit 12 is composed of, for example, a hard disk drive. However, the storage unit 12 may be a rewritable non-volatile semiconductor memory.
The communication unit 13 includes, for example, a NIC (=Network Interface Card) and connects to the network 2 via the NIC.

The terminal device 30 includes, for example, a control unit 31, a storage unit 32, a communication unit 33, an input unit 34, and a display unit 35.
The control unit 31 includes a CPU, a ROM, a RAM, etc., and controls various calculations and operations of each unit constituting the device through execution of programs stored in the storage unit 32 .
The storage unit 32 stores programs such as basic software and applications, as well as data handled by the basic software and applications. The storage unit 32 is composed of, for example, a hard disk drive. The storage unit 32 may be a rewritable non-volatile semiconductor memory.
The communication unit 33 includes, for example, a NIC, and connects to the network 2 via the NIC.

The input unit 34 is composed of an input device such as a keyboard, mouse, touch panel, or the like, and is used to receive operations from the user.
The display unit 35 is composed of, for example, a liquid crystal display or an organic EL (=Electro Luminescence) display, and displays images generated by the control unit 31 .
Note that the input unit 34 and the display unit 35 may be externally attached to the device body as peripheral devices of the terminal device 30 .

<Data Management by Server 10>
The server 10 in this embodiment manages objects based on prototypes. A prototype is an object from which new child objects can be created. Therefore, when viewed from the child object's side, the parent object from which it is based is the prototype.
Prototype-based refers to a method of handling objects based on prototypes. A prototype-based object has only one prototype, except for the root object, which is unique in the collection of objects. Note that the root object does not have its own prototype.

Also, when object A is the prototype of object B, object B is said to be an artifact or child object of object A.
A set of prototype-based objects is represented in a tree structure by the prototype relationships between objects. Also, if the tree structure composed of objects is not destroyed, the tree structure can be transformed by reconnecting the prototypes.

Objects managed by the server 10 can have attributes and attribute values.
In the REST (=REpresentational State Transfer) architecture style, objects are sometimes called resources and values are called representations.
An object contains information representing a pure identity consisting simply of an object identifier and a prototype, information representing data with a value of content type, an access token containing credential information proving the access entitlement, and one of the applications accessing the object. or more than one. An access token can also be said to be an object to which information about access privileges is associated.
These objects are contained in one tree structure.

Also, the version token can be said to be an object associated with information identifying the version of the application to be managed. A version token is an example of the first information.
Also, the license token can be said to be an object associated with information generated according to the result of verifying the authenticity of the version. A license token is an example of the second information.
In the case of this embodiment, the authenticity means that the version of the application to be managed is in a recommended state, more specifically, the combination of the version of the application to be managed and the basic software is Appropriateness, appropriateness of the combination of the version of the application in use and the version supported by the vendor, and appropriateness of the license for the version of the application to be managed.

There is no problem in using the correct version of the application, but some restrictions are required to use the wrong version of the application.
In this embodiment, the use of inappropriate applications is controlled in two steps, taking user convenience into consideration.
One is control for limiting the period during which the application can be used to the period required for updating, uninstallation, etc., and the other is control for immediately prohibiting the use of the application.
In this embodiment, an access token with a time limit is used for the former control. An access token with a time limit is hereinafter referred to as an interimToken.
It also uses dormant tokens for the latter control. A hibernation token is hereinafter referred to as a hibernationToken.

When the server 10 according to the present embodiment successfully verifies the token included in the request, the server 10 processes the received request within the scope of authority corresponding to the token (hereinafter also referred to as "scope"). For example, it authorizes or denies any of object creation, object reference, object update, and object deletion based on the scope specified by the access token.
Further, for example, the server 10 executes addition, update, reading of information, deletion, etc. of objects to be managed according to requests received from the terminal device 30 .

<Functions Implemented in Information Processing System 1>
FIG. 2 is a diagram illustrating an example of functions provided in the server 10 and the terminal device 30 that configure the information processing system 1. As shown in FIG.
The server 10 shown in FIG. 2 includes a data storage unit 101 that manages prototype-based object information, a request reception unit 102 that receives requests from the terminal device 30, and a token verification unit that verifies the token included in the received request. 103, a scope execution unit 104 that executes the scope extracted from the valid token that has been successfully verified, and a response transmission unit that returns to the terminal device 30 the result of executing the scope extracted from the request or the token verification failure. 105 are provided. The response transmission unit 105 here is an example of transmission means.

The data storage unit 101 includes an object store 111 that stores objects, a data store 112 that stores data, a version management table 113 that manages versions of applications installed in the terminal device 30, and a version consistency checker. Version consistency information 114 to be managed is stored.
Scope execution unit 104 in this embodiment includes a plurality of sub-functions for processing received requests. However, some of the sub-functions may be provided separately from the scope execution unit 104 .

One of the sub-functions is the object generation function 141 .
The object generation function 141 is, for example, a function for generating a version object whose parent object is the owner (that is, owner information) specified by the token. The object generation function 141 is an example of generation means.
Another sub-function is the object modification function 142 .
The object change function 142 is, for example, a function for changing a version object that is a child object of the owner specified by the token.

Another sub-function is the Get Object function 143 .
The object acquisition function 143 is a function for acquiring value data from the etag attribute when the revokedAt attribute of the designated object is undefined. Incidentally, the etag attribute represents the identification information of the data object that stores the data content of the object.
Another sub-function is the version binding function 144 .
The version tying function 144 is a function for tying versions to licenses. The version linking function 144 is an example of linking means.
Another sub-function is the version object visualization function 145 .
The version object visualization function 145 is a function for displaying information such as the application version and license on the screen of the terminal device 30 operated by the administrator. The version object visualization function 145 is an example of management means.
The terminal device 30 shown in FIG. 2 includes a request transmission unit 301 for transmitting a request to the server 10, a response reception unit 302 for receiving a response from the server 10, and a display of the received response and generation of a new request. A control unit 303 for controlling is provided.

<Concrete examples of prototype-based objects>
<Data structure when the licensee is a user>
FIG. 3 is a diagram explaining an example of a data structure at the time of a license contract. The time of the license contract is, for example, the time when the billing process due to conclusion of the license contract is completed. The point in time here is an example at the time of the license contract.
As mentioned above, the parent-child relationship of prototype-based objects is represented by a tree structure.
In the case of FIG. 3, an 'apl' object D2 and a 'vendor' object D3 are provided as child objects of the 'root' object D1. The 'vendor' object D3 corresponds to the vendor of the application that is the subject of the license agreement.

The "apl" object D2 is provided with an "authLicenseScope" object D4 and a "verifyTokenScope" object D5 as its child objects.
Here, the "authLicenseScope" object D4 corresponds to the license authentication scope, and the "verifyTokenScope" object D5 corresponds to the token verification scope.

The "vendor" object D3 is provided with an "application" object D6 as its child object.
The "application" object D6 is an object corresponding to the application that is the target of the license.
Further, the "application" object D6 has a "user" object D7, a "version" object D8, and a "VerifyToken" object D9 as its child objects.
A "user" object D7 corresponds to a licensee. This "user" object D7 is provided with a "licenseToken" object D10 as its child object. A “licenseToken” object D10 corresponds to a license granted to a user.
The "version" object D8 here is an object representing the version of the application generated at the time of the license contract. The "verifyToken" object D9 is a token for verifying the authenticity of the token included in the request, and is generated when the "application" object D6 is generated.

The "version" object D8 has, as its child objects, a "versionToken" object D11, a "LicenseUsage" object D12, an "auth License And Log Scope" object D13, and a "userOnVersion" object D14.
The "LicenseUsage" object D12 here is an object representing information used to determine the validity of the license. A "userOnVersion" object D14 is an object corresponding to a licensed user. The "userOnVersion" object D14 is provided with a "licenseToken" object D15 as its child object. A "licenseToken" object D15 is an object corresponding to a token representing a license granted to a user.

FIG. 4 is a diagram illustrating an example of the data structure when a problem is confirmed in the authenticity of the version in use.
In FIG. 4, parts corresponding to those in FIG. 3 are shown with reference numerals.
The data structure shown in FIG. 4 is used when the user's use is with a provisional license with a time limit.
In FIG. 4, the contents of the "licenseToken" object D15 in FIG. 3 are changed to an "interimToken" object D16. The "interimToken" object D16 is an object representing an interim license that permits the user to use the current version only for the period necessary for updating, uninstalling, or the like.

FIG. 5 is a diagram illustrating another data structure example when there is a problem with the authenticity of the version in use.
FIG. 5 also shows the parts corresponding to those in FIG.
The data structure shown in FIG. 5 is used when a dormant license applies to a user.
In FIG. 5, the contents of the "licenseToken" object D15 in FIG. 3 are changed to a "hibernationToken" object D17. The "hibernationToken" object D17 is an object representing a hibernation license used when the current version of the application is not permitted to use.

<Data structure when the licensee is a tenant>
FIGS. 3 to 5 assume that the licensee is an individual, but here the case where the licensee is a tenant will be explained.
FIG. 6 is a diagram illustrating an example of the data structure when the licensee is a tenant.
In FIG. 6 as well, parts corresponding to those in FIG. The data structure shown in FIG. 6 is an example of the data structure at the time of the license contract.
6 differs from the data structure of FIG. 3 in that a "tenant" object D21 is provided instead of the "version" object D8 as a child object of the "application" object D6.
The "tenant" object D21 here is an object corresponding to a tenant generated at the time of the license contract.

The "tenant" object D21 is provided with, as its child objects, a "tenantToken" object D22, a "LicenseUsage" object D12, a "tenant" object D23, and a "userInTenant" object D24.
A “tenantToken” object D22 corresponds to a license granted to a tenant.
A "tenant" object D23 is an object representing a contractor of a tenant. This "tenant" object D23 is provided with a "tenantToken" object D25 as its child object. A “tenantToken” object D25 corresponds to a license granted to a tenant.
A “userInTenant” object D24 is an object corresponding to a licensed user belonging to a tenant. This "userInTenant" object D24 is provided with a "versionToken" object D26 as its child object. A "versionToken" object D26 corresponds to a token representing a version granted to a user within the tenant.

<Processing operation performed by information processing system 1>
Specific examples of processing operations performed in the information processing system 1 will be described below.
<Create application object>
FIG. 7 is a diagram illustrating application object generation processing executed between the server 10 and the first terminal device 30-1 used by a vendor that provides an application. The symbol S shown in the figure means a step.

First, the first terminal device 30-1 requests the server 10 to generate an application object (that is, "application" object D6) (step 301).
Specifically, the first terminal device 30-1 requests the server 10 to generate an application object as a child object of the "vendor" object D3.
When the server 10 receives a request to generate an application object from the first terminal device 30-1 (S101), the token verification unit 103 (see FIG. 2) verifies the access token included in the request, and the verification succeeds. In this case, an application object is generated in the scope execution unit 104 (see FIG. 2) (S102). Application objects are created in the object store 111 (see FIG. 2).
Next, the server 10 transmits the ID of the generated application object (that is, the object ID) to the first terminal device 30-1 (S103).

On the other hand, the first terminal device 30-1 receives the object ID as a response from the server 10 (S302).
Next, the first terminal device 30-1 requests the server 10 to generate a token (that is, an application token) for generating a child object of the application object (that is, the "application" object D6) ( S303).
When the server 10 receives a request to generate an application token from the first terminal device 30-1 (S104), it verifies the access token included in the request, and generates an application token if the verification is successful (S105). ).
Next, the server 10 transmits the ID of the application token described above (that is, the token ID) to the first terminal device 30-1 (S106).

On the other hand, the first terminal device 30-1 receives the token ID as a response from the server 10 (S304).
After that, the first terminal device 30-1 requests the server 10 to generate a verification token (that is, the "VerifyToken" object D9) (S305). A verification token is a token used to verify a token embedded in an installer or application (for example, a version token), and is defined for each application object.
When the server 10 receives a request to generate a verification token from the first terminal device 30-1 (S107), the server 10 verifies the access token included in the request, and generates a verification token if the verification succeeds (S108). ). A verification token is generated in the object store 111 (see FIG. 2).
Next, the server 10 transmits the ID of the verification token described above (that is, the token ID) to the first terminal device 30-1 (S109).
On the other hand, the first terminal device 30-1 receives the token ID as a response from the server 10 (S306).

<Generation of version object>
FIG. 8 is a diagram for explaining version object generation processing executed between the server 10 and the first terminal device 30-1 used by a vendor that provides an application.
A version object is created when a vendor signs a license agreement with a user. The symbol S shown in the figure means a step.

First, the first terminal device 30-1 requests the server 10 to generate a version object (that is, the "version" object D8) (step 311).
Specifically, the first terminal device 30-1 requests the server 10 to generate a version object as a child object of the "application" object D6. This request contains an access token.
When the server 10 receives a request to generate a version object from the first terminal device 30-1 (S111), the token verification unit 103 (see FIG. 2) verifies the access token included in the request, and the verification succeeds. If so, the scope execution unit 104 (see FIG. 2) generates a version object (S112). Application objects are created in the object store 111 (see FIG. 2).

A major version, a minor version, and combination information are set in the version object. The combination information includes information such as basic software capable of operating the application that is the target of the license agreement. The combination information stores the information confirmed at the time of the license contract, and is updated when the information is changed by confirmation with a server (not shown).
Next, the server 10 transmits the ID of the generated version object (that is, the object ID) to the first terminal device 30-1 (S113).

On the other hand, the first terminal device 30-1 receives the ID of the version object as a response from the server 10 (S312).
Next, the first terminal device 30-1 requests the server 10 to generate a version token (that is, the "versionToken" object D11) (S313). Specifically, the first terminal device 30-1 requests the server 10 to generate a version token as a child object of the "version" object D8. A version token is the identification of the version of the application covered by the license agreement.

When the server 10 receives a request to generate a version token from the first terminal device 30-1 (S114), it verifies the access token included in the request, and generates a version token if the verification is successful (S115). ). A version token is generated in the object store 111 (see FIG. 2).
Next, the server 10 transmits the version token ID (token ID) described above to the first terminal device 30-1 (S116).
The first terminal device 30-1 receives the token ID as a response from the server 10 (S314).

<Registration of license object>
FIG. 9 is a diagram for explaining license object generation processing executed between the server 10 and the first terminal device 30-1 used by a vendor that provides an application.
License objects are also created when a vendor signs a license agreement with a user. The symbol S shown in the figure means a step.

First, the first terminal device 30-1 requests the server 10 to generate a user object (that is, the "userOnVersion" object D14) (S321).
Specifically, the first terminal device 30-1 requests the server 10 to generate a user object as a child object of the "version" object D8. This request contains an access token.
When the server 10 receives a request to generate a user object from the first terminal device 30-1 (S121), the token verification unit 103 (see FIG. 2) verifies the access token included in the request, and the verification succeeds. In this case, a user object is generated in the scope execution unit 104 (see FIG. 2) (S122). User objects are created in the object store 111 (see FIG. 2). User attribute information is set in the user object.

Next, the server 10 transmits the ID of the generated version object (that is, the object ID) to the first terminal device 30-1 (S123).
On the other hand, the first terminal device 30-1 receives the object ID as a response from the server 10 (S322).
Next, the first terminal device 30-1 requests the server 10 to generate a license token (that is, the "licenseToken" object D15) (S323). Specifically, the first terminal device 30-1 requests the server 10 to generate a license token as a child object of the "userOnVersion" object D14. A license token represents the current license granted to the version.

As a result of verifying the authenticity of the version of the application in use, if it is confirmed that the version of the application in use is not proper, an interim object (that is, "interimToken" object D16) is a child object of the user object. Or a hibernation object (that is, a "hibernationToken" object D17) is created.
Next, the server 10 transmits the license token ID (token ID) to the first terminal device 30-1 (S126).
The first terminal device 30-1 receives the token ID as a response from the server 10 (S324).

7 to 9 assume the data structure when the licensee is an individual, but when the licensee is a tenant, it is possible to manage versions and licenses using similar procedures.
However, the token representing the version of the application installed in the second terminal device 30-2 used by each user participating in the tenant is a "versionToken" object D26 that is a child object of the "userInTenant" object D24. generated in

<Display of management screen for licenses, etc.>
FIG. 10 is a diagram for explaining display processing of a license management screen executed between the first terminal device 30-1 used by the application vendor and the server 10. As shown in FIG.
The processing shown in FIG. 10 is executed at an arbitrary time after the license contract.
First, the first terminal device 30-1 requests the server 10 to display a license management screen (S331). This request includes a version token (that is, a "versionToken" object D11).

When the server 10 receives a request to display the license management screen from the first terminal device 30-1 (step 131), it verifies the version token included in the request. is generated (S132).
After that, the server 10 transmits the generated license etc. management screen to the first terminal device 30-1 (S133).
The first terminal device 30-1 receives the license management screen as a response from the server 10 (S332).
Next, the first terminal device 30-1 displays the received license management screen (S333).

FIG. 11 is a diagram showing an example of the license management screen 400. As shown in FIG.
A license management screen 400 shown in FIG. 11 includes an input field used for designating a search target, an area 401 in which a search execution button is displayed, and a search result display field 402 .
In the case of FIG. 11, in the area 401, "all products in the tenant" is specified as the search target.
A display field 402 shown in FIG. 11 includes a purchaser 411, a serial number 412, a product 413, the number of licenses 414, a version 415, the number of uses 416, and a notice 417.
The purchaser 411 here is a user who uses the product 413 within the tenant. In the case of FIG. 11, there are two persons, "Jiro Fuji" and "Taro Fuji".

The serial number 412 is a number that identifies the individual application that is the product 413 .
A product 413 is the name of the application. In the case of FIG. 11, there are three such as "authentication federation application", "paperless fax application", and "document application".
The number of licenses 414 is the number of licenses for each application owned by the tenant. For example, one license is given to each of the “authentication federation application” and the “paperless fax application”. In addition, 10 licenses are given to the "document application".
A version 415 is the version of the product 413 used by the purchaser 411 . For example, the version 415 of the “authentication federation application” used by Mr. Jiro Fuji is “1.0.2”.
The number of uses 416 is the number of times each product 413 is used within the tenant. In the case of FIG. 11, only one product is used.

The notice 417 displays information about the product 413 used by each user. The notification 417 displays, for example, information indicating the difference between the usage status of the product 413 and the recommended usage status, the management status corresponding to the difference, and the like. In the case of FIG. 11, it can be seen that a provisional license is granted to the "paperless fax application" being used by Mr. Taro Fuji. In addition, it can be seen that the "document application" that Mr. Fujijiro is using is an unusable version.

This license management screen 400 enables the tenant administrator to check the version 415 of the application used by the user in the tenant (that is, the purchaser 411).
In addition, the license etc. management screen 400 makes it possible to prompt the tenant administrator to take measures such as updates and version upgrades through notification 417 of whether or not the version in use is in a recommended state.
The license etc. management screen 400 can be displayed on either the first terminal device 30-1 used by the vendor who is the licensor or the second terminal device 30-2 used by the individual user who is the licensee. .

<Other embodiments>
Although the embodiments of the present invention have been described above, the technical scope of the present invention is not limited to the scope described in the above-described embodiments. It is clear from the scope of claims that the technical scope of the present invention includes various modifications and improvements to the above-described embodiment.

Reference Signs List 1 information processing system 2 network 10 server 30 terminal device 30-1 first terminal device 30-2 second terminal device 30-3 third terminal device 102 request reception Unit 103 Token verification unit 104 Scope execution unit 105 Response transmission unit 301 Request transmission unit 302 Response reception unit 303 Control unit 111 Object store 112 Data store 113 Version Management table 114 Version consistency information 141 Object generation function 142 Object change function 143 Object acquisition function 144 Version linking function 145 Version object visualization function 400 License management screen

Claims (3)

generating means for generating first information identifying the version of the application program in use;
transmitting means for transmitting the first information to an administrator;
Linking second information representing a license generated according to a result of verifying that the version of the application to be managed is in a recommended state, with the version identified by the first information means and
has
The license management system, wherein the second information is information that prohibits access to the application program in use. 2. The license management system according to claim 1 , wherein said second information is managed in association with a user associated with said version. to the computer,
the ability to generate first information identifying the version of the application program in use;
a function of transmitting the first information to an administrator ;
A function of associating second information representing a license generated according to a result of verifying that the version of the application to be managed is in a recommended state, with the version identified by the first information. and,
It is a program to realize
The program, wherein the second information is information that prohibits access to the application program in use .

Images