Flexible License Manager
Original Publication Date: 2007-Feb-01
Included in the Prior Art Database: 2007-Feb-01
Disclosed is a way to decouple licensed product specific information from user organization specific information. These last ones will be fully customizable according to the specific business needs (internal billing system, reporting,...) of the user organization having no impact on the license server logic.
Flexible License Manager
The three typical actors in a license management system are the software organization in charge of writing the licensing software, the indipendent software vendor willing to protect his software and the end user organization willing to use the licensed software.
The problem is that generally the license management softwares are not flexible enough to meets the needs of all software vendors and of all end user companies. For example there is no way to tight the use of license to the specific company structure allowing the usage of license per department or per project or per floor: often the company internal billing does not match the business model proposed by the software vendor. Of course the big obstacle here is to define a model that could cover all possible structures and pricing models.
The current solutions already on the field are based on machine/user identification plus some already defined company fields as for example the department identifier: this is not enough flexible for big companies.
The solution described here is based on the separation of the licensing systems in two main engines: one responsible for adhering to the software vendors defined policies, the other responsible for managing the company internal business cases. The first engine could be flexible in such a way that it is able to interpret and manage whatever license policy the software vendor decides to implement (all the licensing policy could be described in the license certificate in the extreme case in which the license server should have no knowledge of the licensing algorithm, but should only be a calculator and data storer); the second engine will behave as a server plug-in adding an additional layer between the license enabled application and the license server, collecting all the company-specific information needed for internal billing purposes, statistics,...This second engine could also work as an additional filter for the license server to deny in advance license requests based on the internal company rules. It can also work in order to simply collect additional information needed for internal business only and not for the license server activity. In this case it will be mainly useful for reporting purposes.
The classical licensing system is made up of one (or more) license server(s) and at least one license client (that is the license enabled application). Licensing systems that do not adopt instrumentation techniques have as client, instead of the enabled application, licensing agents that are in charge of triggering application start/stop events. The described solution could be applied to both licensing techniques. For sake of simplicity from now on the terminology used or instrumented licensing system will be used, but the concepts can be easily extended to any other licensing mechanism.