Patent Application
20160292397
The invention relates to software rights management. More particularly, the invention relates to a method and apparatus for automatic license configuration updates.
Licenses in, for example, the FlexNet Manager Suite (Flexera Software, Itasca, Ill.) are created based on a definition. Over time that definition changes, or other definitions related to other purchases are associated with the license. Operators can also manually change the license such that it does not match the original terms of the license definition.
Most licenses, for example in a typical FlexNet Manager Suite, are created using license definitions that are supplied via content libraries. These content libraries contain definitions of license properties, such as name, version, etc.; applications to link to the license; and usage rights to be set on the license. Once a license is created, it is then static and does not pick up any changes as the data is updated and extended over time. Thus, the licenses are configured from the definition at the time of creation and are not updated as the definition evolves over time. Changes to the definition are often due to, for example, changes to the licensing terms and conditions. Uncorrected, this results in reduced accuracy and optimization value to customers.
Further, it is not desirable to let the licenses pass settings through from the definition, in effect inheriting them from the definition, because customers may have negotiated their own terms. It is therefore necessary to at least inform the customers and not just make changes that could cause the customer's license position to change drastically. For example a customer may wish to change the SKU they are purchasing if a publisher turns off a second use feature on the SKU they were purchasing.
Embodiments of the invention provide a license update engine that is run as part of a license entitlement automation system. In embodiments of the invention, the license update engine is minimally executed daily and identifies, for example, content updates to be applied and licenses that have drifted from their original definition. The license update engine then generates proposals for operators to consider. Accepted proposals update the license configuration. Thus, the license update engine identifies licenses and the definitions that are connected to them, including definitions for the licenses from which they were created and definitions that are linked to SKUs of entitlement purchases. Analyses relate three categories of proposal, including license types, applications linked to licenses, and usage rights on licenses. Proposals are stored in a database and operators can accept or ignore them. The database then maintains a history of the license changes.
In an embodiment of the invention, the license update engine regularly analyses licenses which have been created from, and that are associated to, definitions and highlights differences between the current license settings and the latest reference definitions. As noted above, these differences can then either be accepted to bring the license in line with the reference definition, or they can be ignored, leaving the license in its current state. The license update engine thus compares licenses that have been created from definitions to the latest versions of those definitions and generates proposals that permit an operator to update their license definitions.
Embodiments of the invention provide a license update engine that is run as part of a license entitlement automation system. In embodiments of the invention, the license update engine is minimally executed daily and identifies, for example, content updates to be applied and licenses that have drifted from their definition. The license update engine then generates proposals for operators to consider. Accepted proposals update the license configuration. Thus, the license update engine identifies licenses and the definitions that are connected to them, including definitions that the licenses from which the were created and definitions that are linked to SKUs of entitlement purchases. An analysis produced by the license update engine relates to, for example, three categories of proposal, including license types, applications linked to licenses, and usage rights on licenses. Proposals are stored in a database and operators can accept or ignore them. The database maintains a history of the license changes.
In embodiments of the invention, the following terms have their associated meanings:
Content libraries: Archived collections of application, SKU, and license definitions. The content data is downloaded and stored in the product database. Customers receive regular, e.g. monthly, updates to these content libraries in the product database for as long as the customer has a current maintenance agreement. Embodiments of the invention are principally concerned with the license definitions in the content libraries and their use by the product. Definitions of purchasable SKUs from software publishers are linked to license definitions that define the license entitlements that were purchased.
License definition: A template defining attributes and properties of a license entitlement from a software publisher. The license definition includes basic properties, such as license type, name, version and publisher; applications that are covered by the license; and use rights that this license grants. The template is used to instantiate licenses.
License: An instance created from a license definition that represents a quantity of entitlements, from purchases associated with the license, for the installation and use of applications subject to a set of use rights.
Use right: A term in a license which affects how applications are entitled to be installed and/or used. Example of use rights include, for example:
License update engine: Logic that identifies definitions associated to licenses and that then compares those licenses with their definitions to determine the accuracy of the license. The license update engine is automatically run regularly as part of a batch process to generate proposals in a timely fashion for operators. Operators can also manually initiate the license update engine for a selected set of licenses to recalculate the proposals for those licenses. The license update engine can also accept the proposals and modify the state of licenses.
Proposal: A recommendation to change a setting or property of a license to match its reference definition, as defined by the content libraries, better. The proposal is relative to the reference definition for the license. The impact on the license position is not presented as part of the proposal.
Accept: The act of an operator choosing to act upon a proposal. This updates the properties and/or settings of a license to match those of a definition. To see the effects of the update to the license configuration on the license position, a license reconcile process is run to re-optimize the license position.
Ignore: The act of an operator choosing to ignore a proposal. This means that the proposal is no longer shown in the list of active proposals visible to operators. This is typically only done in situations where a specific set of terms have been negotiated with a software publisher that are different from the normal license terms.
For example, the FlexNet Manager Suite product is one context within which an embodiment of this invention can exist. To provide additional context of the product and how the invention sits within that context, a brief summary of the product follows.
FlexNet Manager Suite takes in data from a variety of an enterprise's data sources and processes this data to arrive at a license position for that enterprise. The first source of data is an inventory of an enterprise's computers, covering both hardware and software. This inventory data is stored in a database associated with the product.
The other source of data is the purchasing data that records an enterprise's purchases of products supplied by software publishers. These purchases are typically made via stock keeping units (SKUs) which are the publisher's definition of what has been purchased. The purchase data is stored in a database associated with the product.
FlexNet Manager Suite converts these purchases to licenses via knowledge of publisher SKUs contained in the content libraries. The content libraries contain definitions of SKUs, each of which has an associated license definition. From these, the FlexNet Manager Suite can create licenses from purchases of SKUs and link purchases of SKUs to existing licenses that match the definition.
These content libraries are regularly updated on the Flexera Software website by Flexera Software staff who monitor the accuracy of the content library data against the SKUs and associated license definitions of software publishers. The content libraries are downloaded by the product into the associated database. The licenses created from purchases are also stored in the same database.
The update engine accesses the licenses from the database, determines the set of license definitions associated with the licenses, and then confirms whether each license matches the one or more definitions associated with it. This is the task performed by the update engine discussed in connection with embodiments of the invention. The proposals generated are also stored in tables in the associated product database.
Once FlexNet Manager Suite has inventory data and license data, there is a regularly scheduled job which compares the two to arrive at a license position. The comparison involves finding the most optimal consumption of the purchased license entitlements by installed instances of software products following the use right rules defined by the purchased license entitlements. The inventive update engine herein disclosed is employed during one phase of this regularly scheduled job.
In
This existing functionality provides a set of definitions to compare against the current license. Iterating over each license it can then compare the current state of the license against each of the definitions identified for the licensed product. The license update engine 17 thus polls license definitions and licenses and, based on determined differences, generates license update proposals.
In embodiments of the invention, the license update engine performs comparisons in three categories (although the invention may be used with any number of categories):
From these comparisons, proposals are generated to highlight to operators what they should consider updating on their licenses.
The scenario of a definition updated within the content libraries after license creation has a flow as follows (this example shows a change to a use right, but the flow is the same for a change of license type or change of applications):
The scenario of a license manually altered by an operator is shown by the following flow:
Because a license is typically associated with multiple definitions, there is the possibility of conflicting proposals for the same license. For example, a license may be linked with two definitions, e.g. one for a purchase with software assurance, and one without software assurance. This would generate a proposal that the license should have upgrade rights enabled, assuming they were disabled on the license, but be noted as conflicting with another definition. Once a license has more than one definition associated with it, these conflicts are reported. This highlights to the operator that they need either to accept the clashing license settings or split the license into two and associate each definition with each license. Note that at the time of license creation there is only one definition and, as such, no conflicts exist at that time. Rather, conflicts can come into being as time passes and conditions change.
Proposals are automatically cleaned up when they are no longer relevant. They are also updated if they change. For example, the points consumed on the definition may change from 50 to 100 but the license has a value of 75 so there is now only one proposal to change it to 100.
There exist a plurality of separate properties that are populated into a license definition that trigger a different behavior in the licensed product, as well as custom features based in the product that address calculation issues and licensing issues for operators. The system monitors these behaviors and features as they exist in the license definitions and provides recommendations to the operators in the proposal.
The operator, upon receiving the proposal, has the option to accept the proposal 33 or to ignore the proposal 30.
The license update engine thus looks at the licenses and the definitions that can be connected to them. This can be a definition from which a license was originally created or definitions linked to the SKU of purchases that have subsequently also been linked to that license. Thus, there can be multiple license definitions. In embodiments of the invention, there are three different proposals that are made: license types, applications linked to licenses, and usage rights on licenses.
For example, consider a license that is out of compliance. In this example, a license definition existed for Microsoft® Office® that was purchased at the time that Office 2010 was released. Along with the license, four years maintenance were purchased, thus entitling the purchaser to future versions of the product. Thus, when Office 2013 is released the system updates the license definition to replace Office 2010, such that the latest license definition now includes Office 2013. In this case, the license update engine detects the difference between the purchaser's existing license, based upon the license definition at the time the license was purchased and the current license definition, and recommends to the operator that they add Office 2013 to their license.
Further, definitions can conflict with each other, e.g. a customer has made two purchases of Office 2010 one with maintenance and one without maintenance. As well, second use is turned on for one license and turned off for the other license. If both of these purchases are linked to the same license, the customer is not getting the best value for their usage rights because either they have second use turned on for that license when they should not have it for half of the entitlement, or they have it turned off and they are not getting the benefit of that use right for half of the entitlement. In the proposals the license update engine highlights such conflicts as well, such that a proposal is made to the customer advising of the need to break the license out into two separate licenses.
If the operator accepts the proposal, the properties and/or settings of a license are updated to match those of the current definition. To see the effects of the update to the license configuration on the license position, a license reconcile process is run to re-optimize the license position. If the operator ignores a proposal, the proposal is no longer shown in the list of active proposals visible to operators. This is typically only done in situations where a specific set of terms have been negotiated with a software publisher that are different from the normal license terms. All proposals and operator choices are tracked in the database. The proposals remain visible to the operator until acted upon or they are removed by the license update engine because they are no longer relevant.
The computing system 40 may include one or more central processing units (“processors”) 45, memory 41, input/output devices 44, e.g. keyboard and pointing devices, touch devices, display devices, storage devices 42, e.g. disk drives, and network adapters 43, e.g. network interfaces, that are connected to an interconnect 46.
In
The memory 41 and storage devices 42 are computer-readable storage media that may store instructions that implement at least portions of the various embodiments of the invention. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, e.g. a signal on a communications link. Various communications links may be used, e.g. the Internet, a local area network, a wide area network, or a point-to-point dial-up connection. Thus, computer readable media can include computer-readable storage media, e.g. non-transitory media, and computer-readable transmission media.
The instructions stored in memory 41 can be implemented as software and/or firmware to program one or more processors to carry out the actions described above. In some embodiments of the invention, such software or firmware may be initially provided to the processing system 40 by downloading it from a remote system through the computing system, e.g. via the network adapter 43.
The various embodiments of the invention introduced herein can be implemented by, for example, programmable circuitry, e.g. one or more microprocessors, programmed with software and/or firmware, entirely in special-purpose hardwired, i.e. non-programmable, circuitry, or in a combination of such forms. Special-purpose hardwired circuitry may be in the form of, for example, one or more ASICs, PLDs, FPGAs, etc.
Although the invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the present invention. Accordingly, the invention should only be limited by the Claims included below.
