US6 6810389 System and method for flexible packaging of software application licenses

ABSTRACT – A method for providing licenses to client computer systems to allow the client computer systems to use licensed software products includes receiving a request for a feature license for a feature included in a package, filtering the request based on whether the license requires the checkout of a parent license, granting a package license to the client computer system when the client computer system is allowed to receive the package license according to a license policy and denying the package license to the client computer system when the client computer system is not allowed to receive the package license according to the license policy. The request may include checkout data that includes at least one desired feature attribute. A software license server for providing licenses to client computer systems to allow the client computer systems to use licensed software products, the software license server includes at least one memory having program instructions and at least one processor configured to use the program instructions to receive a request for a feature license for a feature included in a package, filter the request based on whether the license requires the checkout of a parent license, grant a package license to the client computer system when the client computer system is allowed to receive the package license according to a license policy and deny the package license to the client computer system when the client computer system is not allowed to receive the package license according to the license policy.

FIELD OF THE INVENTION

The present invention relates to computer science. More particularly, the present invention relates to a system and method for flexible packaging of software application licenses.

BACKGROUND OF THE INVENTION

A Software Licensing System (SLS) is typically used to restrict the operation of a software program or system of programs, sometimes called an application, to holders of a verifiable software and/or hardware license. The restrictive information contained within a license may specify what entity may execute the application, when the application may be executed, how many copies of the application may be executed, and how the application may be run. The FLEXlm™ product by Globetrotter Software, Inc. of Campbell, Calif. is an example of a commercially available SLS. Such systems are also discussed in U.S. Pat. No. 5,671,412 entitled “License Management System for Software Applications” to Matt Christiano.

An SLS typically counts the number of authorized licenses in use, and imposes a restriction on the number, or count, of licenses that may be in use contemporaneously. An SLS may also cause the application to wait for a license, or notify the application of the availability of the license when it becomes available in the future.

An SLS may reside completely in the licensed application, or operate in the form of a client-server architecture. Client-server architecture is typically used to keep a count of license uses across multiple invocations of a program, and possibly across multiple computers. An SLS operates on licenses that can only be generated by an authorized entity, which is typically the creator of the application being licensed.

Turning now to FIG. 1, a block diagram that illustrates a typical SLS is presented. A typical SLS 10 includes at least one application 1520 and a licensing server 25. Each application 1520 includes a client licensing library 3035. In operation, an application 1520 within an SLS 10 requests a license 4045 from the licensing server 25. This request is referred to as a performing a “checkout” and is typically performed over a secure channel. The licensing server 25 and the application 1520 cooperate to authenticate the license and to verify that the license is intended to allow the operation of the application in the current configuration, environment, and at the current time. The licensing server 25 and the application 1520 may also verify the integrity of the licensing system components and verify version and platform compatibility. Based on the result of these checks, the licensing server either grants or denies (5055) a license request. If the license request is denied, the application 1520 may not use the feature associated with the license request.

A typical SLS maintains licenses for multiple features, or functional subsets, of an application. These features are also referred to as attributes. Attributes are key/value data pairs that are included in the licensing request 4045 and contain information that may originate in the environment of the applications, or be explicitly set by the application. These licensing request attributes are used in conjunction with similar attributes found in the license 60 or in the license server 25 to determine whether a license 60 satisfies a licensing request 4045. A typical license file 65 is illustrated in FIG. 2. A license file 100 typically includes at least one (attribute key, attribute value) pair 105110115.

FIG. 3 is a block diagram that illustrates examples of (attribute key, attribute value) pairs found in a typical license file. License 200 includes four attributes. The first attribute key 205 is the license count and its associated attribute value 210 is the number five, indicating that five licenses may be checked out. The second attribute key 215 is the feature name, and the associated attribute value 220 is “Spell Checker”. A license request can be met by this license only when the feature name in the license request exactly matches the feature name in the license. In the present example, the license request must include a feature name of “Spell Checker”. The third attribute indicates an end date (225) of Sep. 1, 1999 (230). A license request can be met by this license only when the license request date is less than the end date, Sep. 1, 1999. The fourth attribute indicates a version number (235) of 1.2 (240). A license request can be met by this license only if the requested version number is less than or equal to 1.2.

An SLS may use a “share modes” attribute to determine when multiple license requests may be satisfied using the same underlying license. A share modes attributre specifies a list of attributes that, if matched in any separate license requests, will be satisfied using the same license. The rules for matching are typically based on identity (equality) of both the keys and values of all the attributes in the share modes attribute set. In other words, two requests are satisfied from the same license when their share modes attribute sets are identical. This matching is typically attempted only among licensing requests for the same feature. An illustration of share modes is presented in FIG. 4.

Turning now to FIG. 4, a block diagram that illustrates share modes is presented. Request 1 (300), Request 2 (305) and Request 3 (310) represent three separate license requests. License requests 1 (300) and 2 (305) have identical attribute keys (315320) and attribute values (325330). License request 3 (310) includes the same feature attribute value 335, but a different version attribute value 340. License 345 includes a share mode attribute value 350 consisting of two attribute keys: feature name 355 and license version 355. Since both Request 1 (300) and Request 2 (305) include all attribute keys listed in the share mode attribute value 355, and since the attribute values for both Request 1 (325) and Request 2 (330) are identical, Request 1 (300) and Request 2 (305) are satisfied by the same license (345). Since Request 3 (310) includes an attribute value 340 that is different from attribute value 360 and 365, Request 3 (310) requires an additional license 345. Thus, two separate licenses are required for the three license requests.

One type of attribute is “Checkout data”. The checkout data attribute value is typically set in a licensed application and accompanies a licensing request. The checkout data may be part of the share modes. If the checkout data is part of the share modes, multiple checkouts for the same feature, with the same checkout data attribute value, are satisfied with the same license. The checkout data attribute is described in more detail with reference to FIG. 5.

Turning now to FIG. 5, a block diagram that illustrates the checkout data attribute is presented. FIG. 5 is identical to FIG. 4, except that license 400 and license requests 1 (4052 (410) and 3 (415) include a checkout data attribute 420, and the checkout data attribute 420 is included in the share modes attribute value 425. In the example, since the Request 1 (405) and Request 2 (410) checkout data attribute values (430435) are identical, both license requests are satisfied by the same license. License Request 3 (415) includes a different checkout data value. Consequently, license request 3 (415) is satisfied by a separate license 400.

A license may also include a “license data” attribute that is typically initialized when the license is generated. The license data attribute value is typically used to influence operation of the SLS. FIG. 6 is a block diagram that illustrates the license data attribute. FIG. 6 is identical to FIG. 5, except that license 500 includes a license data attribute key 505 and value 510.

A typical SLS includes support for the bundling of products into “packages”. For the purposes of this disclosure, the term “package” refers to a generic grouping of different component products included within that package. The component products are typically programs, although in an alternate embodiment, packages can be components of higher-level packages. The term “software product” is considered to be a program, package, or other similar type of licensed software product. The term “program” refers to any software process, such as an application program (word processor, spreadsheet, drawing program, etc.), utility program, resident or background program, etc. For example, a package can include different component programs that are conveniently specified within the package heading. A package allows a license sharing policy to be specified regarding how a combination of products consumes a single package license. This allows a single license, for example, to enable the use of one OR another of a set of products at different times. However, this packaging concept is rarely used because it does not allow for groups of components in the same package to have different sharing policies. For example, there is no way of specifying that the same package license apply to any number of components in a first group of package components but only one component in a second group of package components.

Typical software licensing systems support only homogenous groups of features that share the same behavior. They are too inflexible to support different sharing policies for groups of components within the same package. Due to the inflexibility of typical licensing systems, software vendors typically price a licensed system using a pricing model that is based upon an assumed usage. Contract provisions between a software vendor and a software user are relied upon to ensure licensed products are used according to a pricing model. Due to the difficulty of monitoring licensed component usage to ensure compliance with contract provisions, it would be desirable to enable enforcement of a relatively flexible licensing policy within a software licensing system itself. Accordingly, a need exists in the prior art for a system and method for grouping licenses that supports different sharing policies for groups of components within the same package. Additionally, a further need exists for such a system and method that enables enforcement of such sharing policies without requiring independent monitoring of licensed component usage.

SUMMARY OF THE INVENTION

A method for providing licenses to client computer systems to allow the client computer systems to use licensed software products includes receiving a request for a feature license for a feature included in a package, filtering the request based on whether the license requires the checkout of a parent license, granting a package license to the client computer system when the client computer system is allowed to receive the package license according to a license policy and denying the package license to the client computer system when the client computer system is not allowed to receive the package license according to the license policy. The request may include checkout data that includes at least one desired feature attribute. A software license server for providing licenses to client computer systems to allow the client computer systems to use licensed software products, the software license server includes at least one memory having program instructions and at least one processor configured to use the program instructions to receive a request for a feature license for a feature included in a package, filter the request based on whether the license requires the checkout of a parent license, grant a package license to the client computer system when the client computer system is allowed to receive the package license according to a license policy and deny the package license to the client computer system when the client computer system is not allowed to receive the package license according to the license policy.

 

Related Posts