Data processing: financial – business practice – management – or co – Business processing using cryptography – Usage protection of distributed data files
Reexamination Certificate
2000-11-08
2004-10-26
Trammell, James P. (Department: 3621)
Data processing: financial, business practice, management, or co
Business processing using cryptography
Usage protection of distributed data files
C705S051000, C705S057000, C713S152000
Reexamination Certificate
active
06810389
ABSTRACT:
BACKGROUND OF THE INVENTION
1. 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.
2. Background
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
15
,
20
and a licensing server
25
. Each application
15
,
20
includes a client licensing library
30
,
35
. In operation, an application
15
,
20
within an SLS
10
requests a license
40
,
45
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
15
,
20
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
15
,
20
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 (
50
,
55
) a license request. If the license request is denied, the application
15
,
20
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
40
,
45
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
40
,
45
. A typical license file
65
is illustrated in
FIG. 2. A
license file
100
typically includes at least one (attribute key, attribute value) pair
105
,
110
,
115
.
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 (
315
,
320
) and attribute values (
325
,
330
). 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
(
405
)
2
(
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 (
430
,
435
) 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
Bever Hoffman & Harms LLP
Harms Jeanette S.
Synopsys Inc.
Trammell James P.
Worjloh Jalatee
LandOfFree
System and method for flexible packaging of software... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for flexible packaging of software..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for flexible packaging of software... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3328060