JP2016173715A - License management system, program, and license management method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To perform install control for each contract of an application.SOLUTION: A server 10 manages information on an object in which at least one of a parent and a child is determined. A terminal device 30 acquires the installer of an application object including a first authority object generated as the descendant of the application object, acquires a second authority object, which is the descendant object of the application object, generated for the licensee of the application object, and controls execution of installation by an installer based on the first authority object and the second authority object included in the installer.SELECTED DRAWING: Figure 2

Description

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

  Application licenses are granted to devices and users. For example, as a technology for managing a license granted to a user without depending on a device, there is an invention described in Patent Document 1 below.

JP 2004-135325 A

  There are various forms of license agreements for applications, such as those tied to individual users, and those tied to organizations, giving organizations the authority to grant licenses to individual users within the organization. Must be managed and controlled.

  An object of the present invention is to provide a license management system, a program, and a license management method capable of controlling installation and execution of each contract of an application.

  The invention according to claim 1 is a license management system that controls at least one of installation and execution of an application according to a license, and verifies the authenticity of the access token for authenticating the license relating to the user's application. Generating means for generating a verification token, means for receiving a license authentication request for the application, including the access token, means for receiving the verification token, and based on the access token, the user's An authentication unit that performs license authentication; a verification unit that verifies the authenticity of the access token based on the verification token; and an installation of the application based on the processing results of the authentication unit and the verification unit. And control means for controlling whether to allow at least one of Le and execution, a license management system comprising a.

  The invention according to claim 2 further comprises means for embedding the verification token so that it cannot be replaced with at least one of the application and an installer of the application. It is.

  The invention according to claim 3 is the license management system according to claim 1, further comprising distribution means for distributing the access token to a license destination user when the license of the application is issued. .

  According to a fourth aspect of the present invention, the authentication unit and the verification unit are configured so that the authentication and the verification unit are performed at least at any one of the appropriate timing during installation of the application, activation of the application, and operation of the application. The license management system according to claim 1, wherein verification processing is performed.

  The invention according to claim 5 further includes management means for managing information of an object for which at least one of a parent and a child is defined, and the generation means generates an application object representing the application and represents the verification token The license management system according to claim 1, wherein a verification token object is generated as a descendant of the application object.

  The invention according to claim 6 further includes management means for managing information of an object for which a parent or at least one is determined, wherein the generation means generates an application object representing the application and a user object representing the user The license management system according to claim 1, further comprising: generating an access token object as a descendant of the application object and generating an access token object representing the access token as a descendant of the user object.

  The invention according to claim 7 further includes management means for managing information on an object for which at least one of a parent and a child is defined, and the generation means generates an application object representing the application, and Generating an organization object representing an organization to which the application is licensed as a descendant, generating an authority object in which an authority capable of generating a descendant object of the organization object is defined as a descendant of the organization object; The license management system according to claim 1, wherein a user object representing the user and an access token object representing the access token are generated as descendants of the organization object based on the license management system. It is a non.

  The invention according to claim 8 is characterized in that the generation means generates an object for storing log information of processing by the authentication means and the verification means as a descendant of the organization object based on the authority object. The license management system according to claim 7.

  The invention according to claim 9 is a computer for controlling at least one of installation and execution of an application in accordance with a license, an access token for authenticating a license relating to the application of a user, and verification of the authenticity of the access token. Generating a verification token, a means for receiving a request for activation of the application including the access token, a means for receiving the verification token, and activating the user based on the access token Authentication means for performing, verification means for verifying the authenticity of the access token based on the verification token, and installation and execution of the application based on the results of processing of the authentication means and the verification means Even without a program to function as a control means for controlling whether to allow the other.

  According to a tenth aspect of the present invention, in a license management method by a license management system that controls at least one of installation and execution of an application according to a license, an access token for authenticating a license related to the application of a user, and the access token Generating a verification token for verifying authenticity; receiving a request for activation of the application including the access token; receiving the verification token; and based on the access token An authentication step for performing license authentication of the user; a verification step for verifying authenticity of the access token based on the verification token; and a process of the authentication step and the verification step Based on the results, a control step for controlling whether to allow at least one of installing and running the application, a license management method comprising.

  According to the invention of claim 1, 9 and 10, at least one of installation and execution of an application is performed by using an access token for the license of the application and a verification token for verifying the authenticity of the access token. And can be controlled based on

  According to the second aspect of the present invention, the verification token can be used in an embedded form so that it cannot be replaced with at least one of the application and the installer of the application.

  According to the third aspect of the present invention, when the license of the application is issued, it can be distributed to a user who is a license destination.

  According to the fourth aspect of the present invention, the authentication and the verification processing are performed at least at any one of an appropriate timing during installation of the application, activation of the application, and operation of the application. Can be.

  According to the fifth aspect of the present invention, it is possible to manage the application and the object representing the verification token of the application in a mechanism for managing the information of the object in which at least one of the parent and the child is determined. .

  According to the sixth aspect of the present invention, the authority given to each of the license destinations of the application can be managed independently.

  According to the seventh aspect of the present invention, a license for a user belonging to an organization can be granted to the organization to which the application is licensed.

  According to the eighth aspect of the present invention, log information of users belonging to an organization can be managed for each organization.

It is a system configuration figure of the information processing system concerning this embodiment. It is a functional block diagram of an information processing system. It is a figure which shows the specific example of a prototype-based object. It is a figure which shows an example of an object management table. It is a figure which shows an example of a value management table. FIG. 10 is a sequence diagram of application object generation processing. It is a sequence diagram of a generation process of a license-destination user object. It is a sequence diagram of an installation control process. FIG. 10 is a sequence diagram of tenant object generation processing. It is a sequence diagram of a generation process of a tenant user object. It is a figure which shows an example of the object which memorize | stores the verification log produced | generated as a descendant of a tenant object.

  Hereinafter, an embodiment for carrying out the present invention (hereinafter referred to as an embodiment) will be described with reference to the drawings.

[1. Explanation of system configuration]
FIG. 1 shows a system configuration diagram of an information processing system 1 according to the present embodiment. As shown in FIG. 1, the information processing system 1 includes a server 10, a first terminal device 30-1, a second terminal device 30-2, a third terminal device 30-3, and a cloud service server 50. The server 10 is connected to the first terminal device 30-1, the second terminal device 30-2, the third terminal device 30-3, and the cloud service server 50 via the network 2 so that data communication is possible.

  Here, the first terminal device 30-1 is a device used by an application vendor (licensor), the second terminal device 30-2 is a device used by an application licensee, and the third terminal device 30-3. Is a device used by a tenant administrator who makes a tenant contract for an application. In addition, when the licensee is an individual user, the licensee may be a tenant (an organization such as a company). Here, if the licensee is a tenant, the tenant may give a license to users belonging to the tenant within the scope of the contract. The information processing system 1 according to the present embodiment can flexibly cope with the various license forms described above.

  In the following description, contents common to the first terminal device 30-1, the second terminal device 30-2, and the third terminal device 30-3 may be described as the terminal device 30.

  Further, as illustrated in FIG. 1, the server 10 includes a control unit 11, a storage unit 12, and a communication unit 13 as an example of a hardware configuration.

  The control unit 11 includes a CPU (Central Processing Unit), executes various arithmetic processes based on a program stored in the storage unit 12, and controls each unit of the server 10.

  The storage unit 12 stores a control program such as an operating system of the server 10 and data, and is also used as a work memory of the control unit 11. The program may be supplied to the server 10 in a state stored in an information storage medium such as an optical disk, a magnetic disk, a magnetic tape, a magneto-optical disk, or a flash memory, or may be supplied to the server 10 via a data communication network such as the Internet. It may be supplied.

  The communication unit 13 includes, for example, a network interface card (NIC), is connected to the network 2 via the NIC, and communicates with a terminal device or the like connected to the network 2.

  As illustrated in FIG. 1, the terminal device 30 includes a control unit 31, a storage unit 32, a communication unit 33, an input unit 34, and a display unit 35 as an example of a hardware configuration.

  The control unit 31 includes a CPU (Central Processing Unit), executes various arithmetic processes based on a program stored in the storage unit 32, and controls each unit of the terminal device 30.

  The storage unit 32 stores a control program such as an operating system of the terminal device 30 and data, and is also used as a work memory of the control unit 31. The program may be supplied to the terminal device 30 in a state stored in an information storage medium such as an optical disk, a magnetic disk, a magnetic tape, a magneto-optical disk, a flash memory, or the terminal device via a data communication network such as the Internet. 30 may be supplied.

  The communication unit 33 includes, for example, a network interface card (NIC), is connected to the network 2 via the NIC, and communicates with a terminal device or the like connected to the network 2.

  The input unit 34 receives a user operation input from an input device such as a keyboard, a mouse, or a touch panel.

  The display unit 35 includes a liquid crystal display, for example, and displays a graphic image generated by the control unit 31.

  Note that the input unit 34 and the display unit 35 may be provided as external devices of the terminal device 30.

  In the present embodiment, the server 10 manages prototype-based objects. Here, the prototype-based object is an object having only one parent object (prototype) except for a root object that exists only in the set of prototype-based objects. Note that the root object does not have its own prototype.

  Further, when the object A is a prototype of the object B, the object B is also referred to as an artifact of the object A. Due to the prototype relationship between objects, the entire set of prototype-based objects is represented in a tree structure. If the tree structure constituted by objects is not destroyed, the tree structure can be deformed by reconnecting the prototype.

  Further, an object managed by the server 10 can have an attribute and an attribute value. In the REST (REpresentational State Transfer) architectural style, an object is sometimes called a resource and a value is called an expression. An object can be simply a pure identity consisting only of an object identifier and prototype, representing data with a value of any content type, an access token that is a credential that certifies access, or the owner of the object It may be included that represents an entity such as a resource owner or an application (client) that accesses an object under the authorization of the resource owner. These objects are included in one tree structure. Note that the above access token can also be said to be an object associated with authority information.

  In the information processing system 1 according to the present embodiment, the server 10 receives a request that presents an access token, and when the access token is verified to be valid, the server 10 receives the request within the authority range specified based on the access token. Process the request. For example, the range of authority specified by the access token is obtained by authorizing (or disapproving) one of object creation (addition), content reference, update, and deletion. Further, for example, the server 10 executes addition, update, information reading, deletion, and the like of the managed object in accordance with the request received from the terminal device 30.

  Below, an example of the function implement | achieved in the information processing system 1 is demonstrated.

[2. Description of functions realized in information processing system 1]
Next, an example of functions provided in the server 10 and the terminal device 30 will be described based on a functional block diagram of the information processing system 1 shown in FIG.

[2.1. Function of server 10]
As illustrated in FIG. 2, the server 10 includes a data storage unit 110, a request reception unit 120, an authority object verification unit 130, an object management unit 140, a request processing unit 150, and a processing result providing unit 160.

  The functions of the above-described units included in the server 10 may be realized by the control unit 11 included in the server 10 reading and executing a program stored in the storage unit 12 or a computer-readable information storage medium. . The program may be supplied to the server 10 by an information storage medium such as an optical disk, a magnetic disk, a magnetic tape, a magneto-optical disk, or a flash memory, or may be supplied to the server 10 via a data communication network such as the Internet. It is also good to do. Hereinafter, the details of the function of each unit provided in the server 10 will be described.

  The data storage unit 110 manages information on prototype-based objects. Here, the prototype-based object includes an authority object called an access token associated with authority information. Prototype-based objects are mutable objects and are typically identified by randomly generated IDs.

  FIG. 3 shows a specific example of a prototype-based object managed by the server 10. In the example shown in FIG. 3, tree structure data in which a parent-child relationship of prototype-based objects is connected is shown.

  As shown in FIG. 3, an “api” object D11 and a “vendor” object D12 are provided as child objects of the “root” object D1. Furthermore, an “authLicenseScope” object D111 and a “verifyTokenScope” object D112 are provided as child objects of the “api” object D11.

  Further, an “application” object D121 and a “vendorToken” object D122 are provided as child objects of the “vendor” object D12.

  Further, a “user” object D1211, a “tenant” object D1212, a “verifyToken” object D1213, and an “applicationToken” object D1214 are provided as child objects of the “application” object D121.

  Further, a “licenseToken” object D12111 is provided as a child object of the “user” object D1211.

  Further, a “userInTenant” object D12121 and a “tenantToken” object D12122 are provided as child objects of the “tenant” object D1212.

  Further, a “licenseToken” object D12111 is provided as a child object of the “userInTenant” object D12121.

  In the example shown in FIG. 3, an “authLicenseScope” object D111 corresponds to a scope that permits license authentication, and a “verifyTokenScope” object D112 corresponds to a scope that permits verification of an access token.

  Of the objects shown in FIG. 3, an “application” object D121 corresponds to an application to be installed. The “user” object D1211 corresponds to the licensee user of the application to be installed. The “licenseToken” object D12111 corresponds to a license granted to the user.

  Also, among the objects shown in FIG. 3, a “verifyToken” object D1213 is generated when the “application” object D121 is created, and becomes an access token embedded in the installer of the application to be installed.

  Also, among the objects shown in FIG. 3, a “tenant” object D1212 corresponds to a tenant contractor of the application. The “userInTenant” object D12121 corresponds to the licensee of the application belonging to the tenant. The “licenseToken” object D121211 corresponds to the license granted to the “userInTenant” object D12121.

  The relationship between the above prototype-based objects can be managed by data stored in the object management table 111 and the value management table 112 shown below, for example.

  That is, in the present embodiment, the data storage unit 110 includes an object management table 111 and a value management table 112, and information on prototype-based objects is stored in the object management table 111 and the value management table 112. I manage.

  FIG. 4 shows an example of the object management table 111, and FIG. 5 shows an example of the value management table 112.

  As shown in FIG. 4, in the object management table 111, an object ID that is identification information of a prototype-based object, a prototype ID that is identification information of a parent (prototype) object of the object, and whether or not the object is validated. (T is valid, F is invalid), and the attribute information of the object is stored in association with each other. The object attribute information includes a type indicating the type of the object, an tag indicating the identification information of the data object storing the data content of the object, a name storing the name of the object, and a time indicating the generation date and time of the object. Note that the data structure of the prototype-based object is not limited to the example shown in FIG. 4 and may include elements other than the elements described above.

  Also, as shown in FIG. 5, the value management table 112 is associated with a value storing the contents of the tag in association with the value of the tag.

  For example, in the case of an access token, as the value of an tag, the format of {“owner”: object ID of owner (owner), “client”: object ID of client (client), “scope”: scope of authorized processing} Contains information. In the information processing system 1 according to the present embodiment, an access token is attached to a processing request received from a terminal device. Here, the owner, client, and scope information are specified by verifying the access token. The owner is treated as a process requester, and the client is treated as a process requester.

  The request receiving unit 120 receives a request from the terminal device 30. For example, the request receiving unit 120 may receive a request regarding processing of an object managed by the data storage unit 110 from the terminal device 30. Note that the request receiving unit 120 may receive the access token information related to the request from the terminal device 30 together with the request. At this time, the request reception unit 120 may receive a request from the terminal device 30 in the form of an HTTP request, for example.

  The authority object verification unit 130 acquires information on the authority object (access token) related to the request received by the request reception unit 120 and verifies the acquired authority object. For example, the authority information acquisition unit 13 may obtain the access token information from the Authorization field of the HTTP request, or from a cookie if there is a cookie containing the access token information.

  The authority object verification unit 130 verifies whether or not the acquired information of the access token (authorization object) is valid. Hereinafter, a specific example of verification processing by the authority object verification unit 130 will be described.

  First, the authority object verification unit 130 determines whether the ID of the access token acquired by the authority information acquisition unit 13 is included in the object management table 111 managed by the data storage unit 110 (appropriateness of the first condition). If it is not included, it is determined that the verification has failed.

  Next, the authority object verification unit 130 determines whether the data format (type) of the access token is a predetermined type (that is, application / json) when the first condition is satisfied (second application / json). If the condition is not a predetermined type, it is determined that the verification has failed. That is, if the value stored in the value management table 112 for the access token etag is not a predetermined type (a data format designating owner, client, scope), it is determined that the verification has failed.

  Next, when the second condition is satisfied, the authority object verification unit 130 acquires the value of the access token (the value of owner, client, and scope), and the value of each of the owner, client, and scope Is data managed by the data storage unit 110 (appropriateness of the third condition), and if any value is not data managed by the data storage unit 110, it is determined that the verification has failed. .

  Next, when the third condition is satisfied, the authority object verification unit 130 acquires the access token prototype information from the data storage unit 110, and the access token prototype matches the access token owner. And whether it is included in the owner's prototype chain (the owner's parent and then the route connecting the owner's ancestors in turn) (matching the fourth condition), and matches any of the above If not, it is determined that the verification has failed. When the first to fourth conditions are satisfied, the authority object verification unit 130 may determine that the access token verification is successful.

  The authority object verification unit 130 notifies the request processing unit 150 of the verification result, information on the scope (processing range) authorized by the access token, and the received request.

  The request processing unit 150 confirms the verification result notified from the authority object verification unit 130 regarding the access token (authorization object) acquired for the request received by the request reception unit 120, and the scope (process) processed for the received access token. The request receiving unit 120 controls the processing of the request received based on For example, if the verification result for the access token related to the request received by the request receiving unit 120 is a verification failure, the request processing unit 150 outputs an error to the processing result providing unit 160 by rejecting the processing related to the request. It is good to do. Further, when the verification result for the access token related to the request received by the request receiving unit 120 is successful, the request processing unit 150 determines that the request received by the request receiving unit 120 is the access token received for the request. And the execution result is output to the processing result providing unit 160.

  For example, the request processing unit 150 requests the object management unit 140 to create, read, update, and delete an object based on the received request, and receives a processing result from the object management unit 140.

  Specifically, based on the request received from the terminal device 30, the request processing unit 150 generates verification of the application object, and verification with a right to verify the license token at the time of application installation that is a child object of the application object. The object management unit 140 is caused to generate a token for the user, generate a licensee object corresponding to the user or tenant corresponding to the licensee, generate a license token indicating a license that is a child of the licensee object and is granted to the licensee, and the like.

  For example, the “application” object D121 in FIG. 3 corresponds to the “application object”, and the “verifyToken” object D1213 corresponds to the “verification token”. Further, the “user” object D1211 and the “tenant” object D1212 in FIG. 3 correspond to the above “licensey object”, and the “license” objects D12111 and D121211 correspond to the above “license token”.

  For example, in the present embodiment, the request processing unit 150 responds to a request received from the first terminal device 30-1 operated by an administrator in the application vendor, and the above application object, verification token, licensee object, Control for generating a license token may be executed.

  The object management unit 140 manages information on objects managed by the data storage unit 110. For example, based on a request received from the request processing unit 150, the object management unit 140 executes processing such as information addition, reading, update, and deletion with respect to the object management table 111 and the value management table 112.

  The object management unit 140 includes a distribution object generation unit, and generates a distribution object that is a child (or descendant) of the master data based on a distribution object generation request received from the request processing unit 150.

  Further, the object management unit 140 reads out information on the distribution object based on the distribution object read request received from the request processing unit 150. Here, the object management unit 140 refers to the data item information of the parent (or ancestor) object of the distribution object and returns the data item that the distribution object does not have as the distribution object information.

  Further, the object management unit 140 updates the content of the distribution object based on the distribution object update request received from the request processing unit 150. Further, the object management unit 140 deletes the distribution object based on the distribution object deletion request received from the request processing unit 150.

  The processing result providing unit 160 provides the processing result by the request processing unit 150 to the terminal device 30 that is a request source of the request.

  For example, in the present embodiment, the processing result providing unit 160 sends the application object, the verification token, and the licensee generated based on the request received from the first terminal device 30-1 to the first terminal device 30-1. Information on the object and license token (object ID, etc.) may be provided.

  The first terminal device 30-1 then embeds the verification token in the installer of the application by writing the verification token provided in the installer for installing the application in a non-rewritable state. That's good. Then, the application vendor may provide the installer in which the verification token is embedded to the licensee side device (second terminal device 30-2, third terminal device 30-3, etc.). The installer may be provided by distributing an information storage medium storing the installer, or distributing the information storage medium from the first terminal device 30-1 or another device to the licensee side device via a network.

  Further, the first terminal device 30-1 requests the server to generate a licensee object and a license token upon the conclusion of a license contract with the licensee (for example, completion of the charging process), and the licensee object generated thereby Get license token information. Then, the first terminal device 30-1 provides license token information to the device on the licensee side (second terminal device 30-2, third terminal device 30-3, etc.).

  Then, the licensee side apparatus executes application installation based on the installer in which the verification token is embedded and the license token. Below, based on FIG. 2, the function with which the terminal device 30 is provided regarding said installation process is demonstrated.

[2.2. Function of terminal device 30]
As illustrated in FIG. 2, the terminal device 30 includes an installation control unit 310, a license authentication request unit 320, a token verification request unit 330, and a processing result acquisition unit 340. In the example described below, the storage unit 32 of the terminal device 30 stores the installer in which the verification token is embedded and the license token information.

  The function of each unit provided in the terminal device 30 is realized by the control unit 31 provided in the terminal device 30 reading and executing a program stored in the storage unit 32 or a computer-readable information storage medium. As good as The program may be supplied to the terminal device 30 by an information storage medium such as an optical disk, a magnetic disk, a magnetic tape, a magneto-optical disk, or a flash memory, or may be supplied to the terminal device 30 via a data communication network such as the Internet. It may be supplied. Hereinafter, the details of the functions of the units included in the terminal device 30 will be described.

  The installation control unit 310 is realized mainly by the control unit 31 and the storage unit 32 of the terminal device 30, and controls the installation process based on the installer in which the verification token is embedded and the license token.

  The installation control unit 310 instructs the license authentication request unit 320 to execute license authentication based on the license token. Further, the installation control unit 310 instructs the token verification request unit 330 to execute token verification based on the verification token embedded in the installer.

  The license authentication request unit 320 is realized mainly by the control unit 31, the storage unit 32, and the communication unit 33 of the terminal device 30, and requests the server for license authentication based on the license token received from the installation control unit 310. For example, the license authentication requesting unit 320 may execute the above request by transmitting the license token ID (object ID) to the request receiving unit 120 of the server 10.

  For example, in the server 10, the license token is verified as valid by the authority object verification unit 130, and the client (transferee information) specified by the license token is a descendant of the owner (owner information) specified by the access token. In such a case, the authentication may be successful, and if not, the authentication may fail. Then, the processing result providing unit 160 transmits authentication result information indicating the authentication result of the license token to the terminal device 30 that has received the authentication request.

  The token verification request unit 330 is mainly implemented by the control unit 31, the storage unit 32, and the communication unit 33 of the terminal device 30, and requests the server for token verification based on the verification token received from the installation control unit 310. . For example, the license authentication request unit 320 may execute the above request by transmitting the ID (object ID) of the verification token to the request reception unit 120 of the server 10.

  In the server 10, the verification of the verification token is executed by the authority object verification unit 130, the verification successful when verification of the verification token is successful, and the verification result that verification is failed when verification of the verification token fails The information is transmitted to the terminal device 30 that has received the token verification request.

  The processing result acquisition unit 340 is mainly realized by the control unit 31, the storage unit 32, and the communication unit 33 of the terminal device 30, and acquires information provided from the processing result providing unit 160 of the server 10.

  For example, the processing result acquisition unit 340 may receive and acquire authentication result information indicating the authentication result of the license token and verification result information indicating the verification result of the verification token from the processing result providing unit. Further, the processing result acquisition unit 340 may provide the acquired authentication result information and verification result information to the installation control unit 310.

  Based on the authentication result information and the verification result information provided from the processing result acquisition unit 340, the installation control unit 310 performs an installation process based on the installer when the license token is successfully authenticated and the verification token is successfully verified. If either of the license token authentication or the verification token verification fails, the installation process based on the installer may be stopped.

[3. Explanation of an example of processing]
Next, an example of processing executed in the information processing system 1 will be described in detail based on the sequence diagrams shown in FIGS.

[3.1. Application registration process]
First, an example of application registration processing executed by the application vendor's first terminal device 30-1 and the server 10 will be described based on the sequence diagram shown in FIG. In the flow of FIG. 6, the first terminal device 30-1 has a “vendorToken” object that is an access token (T 1) with a scope that allows generation, acquisition, update, and deletion of child objects for the “vendor” object D 12. D122.

  As illustrated in FIG. 6, the first terminal device 30-1 uses the access token T <b> 1 to create an application object (corresponding to the “application” object D <b> 121) as a child object of the “vendor” object D <b> 12. (S300).

  Upon receiving an application object creation instruction from the first terminal device 30-1 (S100), the server 10 verifies the access token T1, and creates an application object when the verification is successful (S101). Then, the server 10 transmits the ID (object ID) of the created application object to the first terminal device 30-1 (S102).

  The first terminal device 30-1 receives the ID of the application object transmitted from the server 10 (S301).

  Next, using the access token T1, the first terminal device 30-1 instructs the server 10 to create an access token T2 (corresponding to the “applicationToken” object D1214) for creating a child object of the application object. (S302).

  Upon receiving an access token T2 creation instruction from the first terminal device 30-1 (S103), the server 10 verifies the access token T1, and creates an access token T2 (application token) if the verification is successful ( S104). Then, the server 10 transmits the ID (object ID) of the created access token T2 to the first terminal device 30-1 (S105).

  The first terminal device 30-1 receives the ID of the access token T2 transmitted from the server 10 (S303). Then, using the access token T2, the first terminal device 30-1 instructs the server 10 to create a verification token that is an access token for verifying the license token as a child object of the application object ( S304).

  Upon receiving a verification token creation instruction from the first terminal device 30-1 (S106), the server 10 verifies the access token T2, and creates a verification token as a child object of the application object when the verification is successful. (S107). Then, the server 10 transmits the ID (object ID) of the created verification token to the first terminal device 30-1 (S108).

  The first terminal device 30-1 receives the ID of the verification token from the server 10 (S305).

  The first terminal device 30-1 may provide the installer to the second terminal device 30-2 after embedding the ID of the received verification token in the installer of the application.

[3.2. License registration process for users]
Next, based on the sequence diagram shown in FIG. 7, an example of a process for registering a license for a licensee user executed by the first terminal device 30-1 and the server 10 will be described.

  The first terminal apparatus 30-1 instructs the server 10 to create a user object using the access token T2 (application token) (S310). The above instruction may include an instruction to set user attribute information (user name, mail address, etc.) in the user object.

  Upon receiving a user object creation instruction from the first terminal device 30-1 (S110), the server 10 verifies the access token T2, and creates a user object if the verification is successful (S111). Then, the server 10 transmits the generated user object information (object ID) to the first terminal device 30-1 (S112).

  The first terminal device 30-1 receives the user object information from the server 10 (S311).

  Next, using the access token T2 (application token), the first terminal device 30-1 instructs the server 10 to create a license token that is an access token indicating a license to be granted to the user (S312). . In the above instruction, the owner of the license token is set to “application” object D121 (application object), the client is set to “user” object D1211 (user object), and the scope is set to “authLicenseScope” D111 (scope object for license authentication). Instructions may be included.

  Upon receiving a license token creation instruction from the first terminal device 30-1 (S113), the server 10 verifies the access token T2, and creates a license token if the verification is successful (S114). Then, the server 10 transmits the information (object ID) of the generated license token to the first terminal device 30-1 (S115).

  The first terminal device 30-1 receives the license token information (object ID) from the server 10 (S313).

  The first terminal 30-1 executes the above-described processing based on the user information received from the user with the license contract with the licensee user, and receives the license token information (object ID) received as a result, It is good also as providing to the 2nd terminal device 30-2 which a user (licensee) operates.

[3.3. Installation control process]
Next, an example of application installation control processing executed by the second terminal device 30-1 and the server 10 will be described based on the sequence diagram shown in FIG. In the following sequence example, it is assumed that the second terminal device 30-2 has an installer in which a verification token is embedded and a license token uniquely issued to the user.

  As shown in FIG. 8, the second terminal device 30-2 instructs the server 10 to perform a license authentication process based on the license token (S320).

  When the server 10 receives a license authentication processing instruction based on the license token (S120), the server 10 executes license authentication based on the license token (S121). For example, if the license token is a valid access token and the client (transferee information) specified by the license token is a descendant of the owner (owner information) specified by the access token, If the authentication is successful, the authentication result indicating authentication failure is transmitted to the second terminal device 30-2 (S122).

  The second terminal device 30-2 receives the authentication result from the server 10 (S321), and when the received authentication result is successful authentication (S322: Y), the verification of the verification token embedded in the installer is performed. The server 10 is instructed (S323).

  Upon receiving the verification instruction for the verification token (S123), the server 10 verifies the verification token (S124), and transmits the verification result to the second terminal device 30-2 (S125).

  The second terminal device 30-2 receives the verification result from the server 10 (S324), and when the received verification result is a verification success (S325: Y), the installation process of the application based on the installer is executed (S325: Y). S323).

  On the other hand, if the authentication result received in S321 is not successful authentication (S323: N), and if the verification result received in S324 is not successful (S325: N), an error is detected (S327), and application installation based on the installer is performed. Cancel processing.

  Note that the application installation process based on the installer means that the application can be executed in the second terminal device 30-2 based on the installer.

[3.4. Tenant registration process]
Next, an example of processing for registering a tenant as a licensee executed by the first terminal device 30-1 and the server 10 will be described based on the sequence diagram shown in FIG.

  The first terminal device 30-1 instructs the server 10 to create a tenant object using the access token T2 (application token) (S330). The above instruction may include an instruction to set tenant administrator information (administrator name, email address, etc.) in the tenant object.

  Upon receiving a tenant object creation instruction from the first terminal device 30-1 (S130), the server 10 verifies the access token T2, and creates a tenant object if the verification is successful (S131). Then, the server 10 transmits the generated tenant object information (object ID) to the first terminal device 30-1 (S132).

  The first terminal device 30-1 receives information on the tenant object from the server 10 (S331).

  Next, using the access token T2 (application token), the first terminal device 30-1 instructs the server 10 to create a tenant token that is an access token indicating the authority to be granted to the tenant (S332). . The tenant token may be defined with authority that allows an object to be added to a descendant of the tenant object and the added object to be deleted or updated. For example, the tenant token owner may be set to “tenant” object D1212 (tenant object), “tenant” object D1212 (tenant object), and the scope may be set to “crudScope”.

  Upon receiving the tenant token creation instruction from the first terminal device 30-1 (S133), the server 10 verifies the access token T2, and creates a tenant token if the verification is successful (S134). Then, the server 10 transmits the generated tenant token information (object ID) to the first terminal device 30-1 (S135).

  The first terminal device 30-1 receives the tenant token information (object ID) from the server 10 (S333).

  The first terminal 30-1 may provide the tenant token information to the tenant administrator who is the licensee.

[3.5. License registration process for tenant users]
Next, based on the sequence diagram shown in FIG. 10, an example of processing for registering a license for a user in a tenant, which is executed by the third terminal device 30-3 operated by the tenant administrator and the server 10. explain.

  Using the tenant token, the third terminal apparatus 30-3 instructs the server 10 to create a tenant user object (corresponding to the “userInTenant” object D12121 in FIG. 3) (S340). The above instruction may include an instruction to set user attribute information (user name, email address, etc.) in the tenant user object.

  Upon receiving an instruction to create an in-tenant user object from the third terminal device 30-3 (S140), the server 10 verifies the tenant token and creates an in-tenant user object if the verification is successful (S141). And the server 10 transmits the information (object ID) of the generated user object in the tenant to the third terminal device 30-3 (S142).

  The third terminal device 30-3 receives the information on the user object in the tenant from the server 10 (S341).

  Next, using the tenant token, the third terminal device 30-3 instructs the server 10 to create a license token that is an access token indicating a license to be granted to the in-tenant user (S342). In the above instruction, the owner of the license token is “tenant” object D1212 (tenant object), the client is “userInTenant” object D12121 (in-tenant user object), and the scope is “authLicenseScope” D111 (scope object for license authentication). Instructions to set may be included.

  Upon receiving a license token creation instruction from the third terminal device 30-3 (S143), the server 10 verifies the tenant token and creates a license token if the verification is successful (S144). Then, the server 10 transmits the information (object ID) of the generated license token to the third terminal device 30-3 (S145).

  The third terminal device 30-3 receives the license token information (object ID) from the server 10 (S343).

  The third terminal 30-3 may provide the license token information (object ID) to the in-tenant user. The application installation process based on the license token for the in-tenant user may be the same as the process described in FIG.

[4. Other forms of the present invention]
Hereinafter, other embodiments of the present invention will be described. FIG. 11 shows a structure obtained by changing the structure of the descendant object of the “tenant” object D1212 among the object structures shown in FIG.

  As shown in FIG. 11, the “tenant” object D1212 is provided with a “LicenseUsage” object D12123 and a “LogScope” object D12124 in addition to the “userInTenant” object D12121 and the “tenantToken” object D12122.

  Here, in the “License Usage” object D12123, log information related to user installation processing, application activation, application operation, and the like corresponding to the “userInTenant” object D12121 is recorded.

  The “LogScope” object D12124 is a scope in which processing for recording log information in addition to authentication processing is defined.

  The “licenseToken” object D12111 that is a child object of the “userInTenant” object D12121 is different from the example of the object shown in FIG. 3 in that the “LogScope” object D12124 is set as the scope. The point is common.

  In the case of adopting the object configuration example shown in FIG. 11, when registering a license for a user in the tenant, the scope of the license token is set to the “LogScope” object D12124 in the sequence diagram shown in FIG. Except for this point, the same processing as that in the sequence diagram of FIG. 10 can be adopted.

  Also, the installation process of the tenant user is omitted because it can be realized by the same sequence as in FIG. 8 although the process depending on the scope of the license token is different.

  The embodiment described above is shown as a specific example, and the invention disclosed in this specification is not limited to the configuration of the specific example or the data storage example itself. Those skilled in the art may make various modifications to the disclosed embodiments, for example, change the data structure and the execution order of the processes. It should be understood that the technical scope of the invention disclosed herein includes such modifications.

  For example, in the information processing system 1 described above, a license token may be used to perform OAuth authentication in a cloud service (cloud service server 50 in FIG. 1) corresponding to an application.

  For example, when the user of the terminal device 30 wants to use the service of the cloud service server 50, when instructing the cooperation with the cloud service, the user is asked for permission to receive the authentication information from the server 10. If permitted by the user, the server 10 returns user information in response to a request from the cloud service server 50 to the server 10.

  For example, the cloud service server 50 may provide the terminal device 30 with information on the target folder specified based on the user information. For example, the terminal device 30 may display the user's folder managed by the user-specific cloud service server 50 in the cooperation folder with the cloud service. According to said structure, since it is not necessary to preserve | save the cloud service account information in the terminal device 30, the leakage risk of account information reduces. Further, after the first authentication, confirmation from the cloud service server 50 to the server 10 is performed, and the user does not have to input the ID and password every time.

  10 server, 30-1 first terminal device, 30-2 second terminal device, 30-3 third terminal device, 50 cloud service server, 110 data storage unit, 120 request reception unit, 130 authority object verification unit, 140 object Management unit, 150 request processing unit, 160 processing result providing unit, 310 installation control unit, 320 license authentication request unit, 330 token verification request unit, 340 processing result acquisition unit.

Claims (10)

In a license management system that controls at least one of installation and execution of an application according to a license,
Generating means for generating an access token for authenticating a license relating to the application of the user and a verification token for verifying the authenticity of the access token;
Means for receiving a request for activation of the application including the access token;
Means for receiving the verification token;
Authentication means for performing license authentication of the user based on the access token;
Verification means for verifying authenticity of the access token based on the verification token;
Control means for controlling whether to permit at least one of installation and execution of the application based on a result of processing of the authentication means and the verification means;
A license management system comprising: Means for embedding the verification token so that it cannot be replaced with at least one of the application and an installer of the application;
The license management system according to claim 1, further comprising: Distribution means for distributing the access token to a licensed user when issuing a license for the application;
The license management system according to claim 1, further comprising: The authentication unit and the verification unit perform the authentication and the verification process at at least one of an appropriate timing during installation of the application, startup of the application, and operation of the application.
The license management system according to claim 1. A management means for managing information on an object in which at least one of a parent and a child is defined;
The generation unit generates an application object representing the application, and generates a verification token object representing the verification token as a descendant of the application object.
The license management system according to claim 1. A management means for managing the information of the object for which each parent or at least one is determined;
The generation means generates an application object representing the application, generates a user object representing the user as a descendant of the application object, and generates an access token object representing the access token as a descendant of the user object.
The license management system according to claim 1. A management means for managing information on an object in which at least one of a parent and a child is defined;
The generation means generates an application object representing the application,
Generating an organization object representing the licensed organization of the application as a descendant of the application object;
As a descendant of the organizational object, generate an authority object that is defined as an authority capable of generating the descendant object of the organizational object,
Based on the authority object, a user object representing the user and an access token object representing the access token are generated as descendants of the organization object.
The license management system according to claim 1, wherein: The generation unit generates an object for storing log information of processing by the authentication unit and the verification unit as a descendant of the organization object based on the authority object.
The license management system according to claim 7. A computer that controls at least one of application installation and execution according to a license,
Means for generating an access token for authenticating a license relating to the application of the user and a verification token for verifying the authenticity of the access token;
Means for receiving a request for activation of the application including the access token;
Means for receiving the verification token;
Authentication means for performing license authentication of the user based on the access token;
Verification means for verifying authenticity of the access token based on the verification token;
A program for functioning as control means for controlling whether to permit at least one of installation and execution of the application based on the processing results of the authentication means and the verification means. In a license management method by a license management system that controls at least one of installation and execution of an application according to a license,
Generating an access token for authenticating a user's license for the application and a verification token for verifying the authenticity of the access token;
Receiving a request for activation of the application including the access token;
Receiving the verification token;
An authentication step of performing license authentication of the user based on the access token;
A verification step of verifying authenticity of the access token based on the verification token;
A control step for controlling whether to permit at least one of installation and execution of the application based on a result of the processing of the authentication step and the verification step;
A license management method comprising:

Images