System for managing the licensing of software executed on computer systems

ινιπ» niaayaa nysnann main bm>ab nam>» A system for managing the licensing of software executed oncomputer systems

DIGITAL EQUIPMENTCORPORATION C. 100021 15 20

BACKGROUND OF THE INVENTION

This invention relates to methods of operation of computer systems, andmore particularly to a ' . system for managing the Licensing of software executed on computer systems.

In U.S. Patent 4,937,863, issued to Robert, Chase apd Schafer and assignedto Digital Equipment Corporation, the assignee of tfris invention, a SoftwareLicensing Management System is disclosed in which usage of licensed softwaremay be monitored in a computer system to determine if a use is within the scopeof a license. The system maintains a database of licenses for software products, - 2 - delivering the license document may be in the form of a network, or may be aphone line using modems, or may include physical delivery by disks or CD ROMs,for example. Likewise, the method of delivery of the software products beinglicensed, i.e., the applications programs 17 to be executed on the CPUs 16, is notmaterial to the license management facility of the invention; the products aredelivered by some appropriate means, e.g., the communications link 30 and thenetworks 21 and 22, by CD ROMs or disks physically distributed, etc.

Although shown in Figure 1 as operating on a distributed system, in thesimplest case the license management facility of the invention may be operatedon a single CPU. The license management program 11 and the applicationsprogram 17 may be executing on the same CPU, in which case the licensedocument would be stored in a database 23 as before, on this CPU, and the callsfrom the unit 18 to the license server would be local instead of RPCs. As in thedistributed system, however, the licensed product would still not have access to thelicense document, but instead could only make inquires to the server program,even if all are executing on the same CPU.

In operation of the distributed system of Figure 1, the producer 28 gives theissuer 25 authority to grant licenses on its behalf (the producer and issuer can bea single entity or multiple entities). The license document generator program 26,under control of a user (a person), generates a license (usually the result ofnegotiation between the user of program 26 and a user of the server 10). Thislicense is called a product use authorization, and it is transmitted by the link 30to the server 10. The license management program in the server 10 stores theproduct use authorization in the database 23, and, if delegation is an authorizedoption, may distribute parts of the authorized use to the delegatee servers 13, .<· - 3 - i where it is likewise stored in a database. Thereafter, administration of the licenseis only in response to inquiries from user nodes 16. When execution of a program17 begins, the unit 18 is invoked to check on the availability of a license for thisparticular node. The unit 18 sends (as by an RPC) a request to the licensemanagement program 14 (or 11 if there is no delegatee), where the product useauthorization stored in database 23 is checked to see if use is authorized. If so,a return is sent to the user node 16, granting permission to continue. When theprogram 17 has finished executing, the unit 18 again is invoked to signal to thelicense management program, again by an RPC, that the authorization is released,so the license management program can take appropriate action, e.g., log the usein log 24, etc.

To implement these operations, the license management program 11 or 14contains several functions, including a client interface 31, a database interface 32,a management interface 33, and an interserver interface 34 for communicatingwith the delegatees 13 (if any). The client interface 31, as described below,handles the requests received from the user nodes 16, and returns resulting fromthese requests. The database interface 32 handles the storing and retrieval oflicense information in the database 23, and logging license usage activity to log 24,and retrieval of this data. The management interface 33 handles the tasks ofreceiving the product use authorizations from the issuer 25 and maintaining thedatabase 23 via the database interface 32. The interserver interface 34 handlesthe task of communicating with the delegatee servers 13, including transmitting theassigned parts of the product use authorizations, or communicating with otherlicense servers that may be separately executing the license management function;for example, calls for validating calling cards may be made to another such server. - 4 -

If there are no delegatees or no other license servers, then of course theinterserver interface 34 has no function, and is idle.

The license document or "product use authorization" forming the basis forthe license management activity of the program 11 on the server 10 may beillustrated as a data structure containing the information set forth in Figure 2; inactual practice the product use authorization is preferably a more abstract dataarrangement,, not in such a rigidly structured format as illustrated. For example,the product use authorization as well as similar documents stored in the database23, or passed between components of the system of Figure 1, may be of the so-called tag-length-value data format, where the data structure begins with anidentifying tag (e.g., PUA or product use authorization) followed by a field givingthe length, followed by the value itself (the content). One type of data treatmentusing this tag-length-value format is an international standard referred to as ASN.lor Abstract Syntax Notation. In any event, the document 35 illustrated in Figure2 is merely for discussing the various items of data, rather than representing theway the information is stored. Some of the fields shown here exist at some timesand not others, and some are optional; the product use authorization may alsoinclude additional fields not shown or discussed here. Also it should be noted thatcopies of parts of this type of document are made for the delegatees, so thisrepresentation of Figure 2 is a composite of several documents used in the systemof Figure 1. The document 35 includes fields 36 identifying the software productby product name, producer, version numbers, release date, etc. The issuer 25 isidentified in field 37, and the licensee (usually the owner of the license server 10)identified in field 38. The essential terms of the license grant are then defined infields 40-46. The start date and end date are specified in fields 40; these store theexact time (date, hour, minute, second, etc.) when the license becomes valid and when it ends, so licenses may be granted to start at some future time and to endat a particular time. Note that the previous practice has been to specify only theending date, rather than also a start date as employed here. Each of the nodes,including issuer 25. servers 10 and 13, and user nodes 16, maintain a time valueby a local clock referenced to a standard, so inherent in the license managementfacility is the maintaining of a time standard to compare with the start and enddate information in the fields 40. The units granted are specified in field 41; theunits are an arbitrary quantitative measure of program usage. In a delegateeserver 13, the units field 41 will have some subset of the units field in the originalproduct use authorization. As units are granted to users 16 or delegated, theremaining units available for grant are indicated in a subfield 42 in the copy of thedocument used by the server. The management policy occupies fields 43-46, andincludes style, context, duration and LURDM (license use requirementsdetermination method), as will be explained. The style field 43 specifies whetherthe licensed units are controlled by an "allocative" style or "consumptive" style, orsome other "private" algorithm, where styles are ways used to account for theconsumption or allocation of the units. The context field 44 specifies the locationand environment in which product use or license management occurs, i.e., a CPUor an individual user or a network, etc. Duration field 45 indicates whether thelicense granted to a user is by assignment, by transaction, or immediate. TheLURDM field 46 indicates the license use requirements determination method,in some cases using a license use requirements table (LURT) seen as field 47, aswill be described.

Additional fields 48-54 in the product use authorization 35 of Figure 2define features such as delegation authorization, calling authorization, overdraft - 6 - authorization, combination authorization, token, signature, checksum, etc. Thesewill be described in the following paragraphs.

If the delegation field 48 is true, a license server 10 may distribute licenseunits to multiple servers 13. A time limit may be imposed, i.e., units can bedelegated to other hardware systems until they time out. Delegation allows anadministrator to distribute units to improve response time and increase theresilience of the system. For example, the communication network 21 may includea satellite link to a remote facility where the local server 13 has a number ofclients or users 16, in which case the calls to the server 13 would be completedmuch quicker than would be the case if calls had to be made to the server 10.Also, delegation may be used as a method of allocating licensed units within abudget for administrative purposes. Usually the delegation authorization is afeature that is priced by the issuer, i.e., a license granting 1000 units withdelegation authorization is priced higher than without this authorization.

The field 49 contains a calling authorization and/or a caller authorization.If the caller authorization in field 49 is true, the product is permitted to receivecalls from other named products requesting use of the product, and if conditionsare met (identified caller is authorized) the server can grant a calling card, asdescribed below. If the calling authorization is true, the product can make callsto other products. If neither is true, then the product can neither make or receivecalls using the calling card feature. Referring to Figure 1, if product 17a wishesto make a remote procedure call to a feature of product 17b running on adifferent user node 16, it makes a call to its server 13 including a request for acalling card, and, if permitted, the return to product 17a includes a calling card49a. The product 17a then makes a call to product 17b in the usual manner of w RPCs, sending along the calling card 49a, which the product 17b then verifies bya call to its server 13 before executing the called procedure and issuing its returnto product 17a. The feature of calling cards is important for distributedapplications. For example, if a product is able to execute faster in a distributed 5 system by assigning tasks to other CPUs, then the issue is presented of which license policy is needed, i.e., does every node executing a part of the task have tobe licensed and consume or receive allocation of a unit, or just the one managingthe task? This is resolved for most applications by use of this calling card concept.The product use authorization for such a product has the calling authorization LO field 49 enabled, so calling cards can be issued. This feature is typically separately priced.

The combination authorization field 50 of Figure 2 determines whether ornot license requests from a user node 16 can be satisfied by combining units frommultiple product use authorizations. It may be advantageous to purchase licensesl5 with different policy values, and use units from certain product use authorizations only for overflow or the like. Or, for other reasons, it may be advantageous to"borrow" and "lend" units among delegated servers or user nodes. This function is permitted or denied by the content of field 50.

The overdraft field 51 determines whether or not a requested allocation’0 from a user node 16 will be nevertheless granted, even though the units available field 42 is zero or too small to permit the requested use. Overdrafts can beunlimited, or a specific overdraft pool can be set up by a server 10, for acustomer’s internal administrative purposes. That is, the overdraft value may beunlimited in the original license, but limited or zero for internally distributed 15 copies of the license. Thus, the product use authorization sent by the issuer 25 to - 8 - 1 the customer may have overdrafts permitted by the field 51, but the customer maydeny overdraft permission for its own budgeting purposes. In any event, ifoverdraft is permitted, additional fees have to be paid to the issuer at someaccounting period, when the logged usage from log 24 indicates the available unitshave been exceeded. If overdraft is denied, then the units 18 of the user nodesmaking request allocations are structured to inform the products 17 that a licensegrant is not available. The intent is not to prevent the application program fromrunning; the license server merely informs the application whether or not thelicense manager determines that it is authorized to run. The application can itselfbe structured to shut itself down if not authorized to run, or it can be structuredto shut down certain functions (e.g., ability to save files, ability to print, etc.), orit can be structured to continue in a fully functional manner. The purpose of thelicense management facility is not that of enforcement, nor that of "copyprotection", but instead is merely that of license management.

An optional token field 52 is available in the product use authorization 35of Figure 2. This field can contain comments or other information desired by theissuer or user. For example, a telephone support number may be included in thetoken field, then when the product 17 shows its "help screen" the number isinserted. This number would be part of the argument, i.e., data transmitted to theuser node 16, when the server 10 makes a return following a request allocationmessage from the user. This field may also be used to store information used ina "private" style, where the information from this field returned to the user nodeis employed by the application program 17 or the stub 19 to determine if theapplication can be activated. - 9 -

The signature field 53 in the product use authorization 35 is a part of avalidation mechanism which provides important features. This field contains adigital signature encoded to reflect the data in the license itself, as well as otherencoding methods not known to customers, so it cannot be duplicated unless the 5 encoding algorithm is known. In a preferred embodiment, a so-called "public/private key" system of encoding is used for the signature field 53. Theencoding algorithm used to generate the signature 53 is known to the issuer 25,using a private key, and anyone knowing the public key can decode the signatureto determine if it is valid but cannot determine the encoding algorithm so it 10 cannot produce a forged signature. So, if the server 10 knows the public key which is unique to the issuer 25, it can determine if a license document 35 isgenuine, but it cannot itself generate license documents. However, if the serverpossesses a valid license document that gives it the right to delegate, then it willbe assigned its own private key (different from all other issuers or servers) and its 15 delegatees 13 will be able to determine if a valid delegated license is delivered to them as they will be given the public key for the servers 13. The field 53 willthus contain both the original signature from the issuer 25 and the license server’ssignature when delivered to a delegatee 13. The decoding algorithm using apublic key for arty signatures is thus used by the license server 10 or delegatee 13 20 to make sure a product use authorization 35 is authentic before it is stored in the database 23. Related to the digital signature 53 is a checksum field 54, whichmerely encodes a value related by some known algorithm to the data in theproduct use authorization 35 itself. This field may.be used merely to check forcorruption of the data as it is stored, recalled, and transmitted within the system. 25 That is, the checksum is used for data validation rather than security. 10

Two concepts central to the license management system implemented usingthe license document or product use authorization 35 of Figure 2 are the "licenseunits", specified in field 41 or 42 and the "context”, specified in field 44. Licenseunits are an abstract numerical measure of product use allowed by the license.When a product 17 (or a function or feature of a product) makes a license-checking request, the license management program 11 on server 10 computes howmany license units are required to authorize this particular use of the product, andthis is the license units requirement, in some cases using the LURDM field 46.A "context" is a set of tagged values which define the location and environmentin which product use or license management occurs. Context values may bespecified in field 44 of the product use authorization 35 of Figure 2 to restrict theenvironments in which the license may be managed and in which product use mayoccur. A context template may also be specified in the field 44 to indicate whichparts of the complete context of product use (sub-contexts) are significant indifferentiating product uses for the purposes of unit allocation; when this isspecified, it allows separate product uses to share license units in a controlled way.

The two general types of policies specified in field 43 are allocative andconsumptive. An allocative policy grants to the holder a specific number oflicense units (field 41) and specifies the policy which must be used to account forthe allocation of these units. A software product 17 which is being managed byan allocative license will require verification that the appropriate number oflicense units have been allocated to it prior to performing services to the user.Typically, this allocation of units occurs either at the time of activation of theproduct 17 or at the time that product use is enabled on a particular platform(user CPU 16). The units typically remain allocated to the product 17 throughoutthe period that the product is running or is enabled to run. Upon termination of - 11 - processing or disabling, the allocated units are deallocated and made available forallocation to other instances of the software product 17 (other users 16 activatingthe product). In general, as long as any license units remain unallocated in field42, the holder of the license is contractually authorized to increase his utilizationof the licensed product. The usage does not deplete the license, however, as theunits are returned to the units-available field 42 after a user is finished, and canbe granted again to another user. A consumptive unit based license, indicated in policy field 43, grants to theholder a specific number of initial license units (from field 42) and specifies thepolicy used to account for the consumption of those units. A software product 17which is being managed by a consumptive license will cause an appropriatenumber of license units to be consumed to reflect the services provided by theproduct. Once consumed, units cannot be reused. Thus, the number of unitsavailable for future use declines upon every use of the licensed software product17. This may also be referred to as a "metered" policy, being conceptually similarto measured consumption of electricity, water,.etc. When the number of availableunits in field 42 reaches zero, the license may require that further use of theproduct is prohibited, or, the agreement may permit continued decrementing ofthe number of available units; the result is the accumulation of a negative numberof available units in the field 42. It is anticipated that most consumptive unitbased licenses will consider negative units to represent an obligation of the licenseholder to pay the license issuer 25. The transaction log 24 maintains an audit trailfor providing a record of the units used in a consumptive license.

Referring to Figure 3, the major elements of the management policy areset forth in a table, where the possible entries for the fields 43, 44, 45 and 46 are - 12 - listed. For the style entry 43, the possibilities are allocative and consumptive asjust described, plus a category called "private" which represents a style ofmanagement undefined at present but instead to be created especially for a givenproduct, using its own unique algorithm. .It is expected that most licenses may beadministered using the named alternatives of Figure 3, but to allow for futureexpansion to include alternatives not presently envisioned, or to permit specialcircumstances for unique software, the "private" choices are included, which merelymean that the product 17 will generate its own conditions of use. It is importantto note that, except for the "private" alternative, the license management is totallyin control of the license management program 11 on the license server 10 (ordelegatee 13), rather than at the product 17. All the product 17 does, via the unit18, is to make the request inquiry to the server 10 via the client interface 31, andreport when finished.

The context field 44 specifies those components (sub-contexts) of theexecution-context name which should be used in determining if unit allocations arerequired. License data is always used or allocated within, or for the benefit of,some named licensing context, and context can include "platform contexts" and"application contexts". Platform contexts are such things as a specific network, anexecution domain, a login domain, a node, a process ID or a process family, a username, a product name, an operating system, a specific hardware platform, as listedin Figure 3. Applications contexts are information supplied from the application(the product 17), such as may be used in a "private" method of determining licenseavailability. The context name can use several of these, in which case the contextname is constructed by concatenating the values of all subcontexts into a singlecontext name, e.g., a VAX 3100 platform using VMS operating system. - 13 -

The duration field 45 defines the duration of an allocation of license unitsto a specific context or the duration of the period which defines a validconsumptive use. For durations of type "Assignment," the specification of areassignment constraint is also provided for, as discussed below. There are threetypes of duration, these being "transaction," "assignment" and "immediate" as seenin Figure 3.

The transaction duration type, when specified for an allocative policy,indicates that license units should be allocated to the specified context uponreceipt of a license request and that those units should be deallocated andreturned to the pool of available units upon receipt of a corresponding licenserelease from a user node 16. Abnormal termination of the process or contexthaving made the original license request will be semantically equivalent to alicense release. On the other hand, when specified for a consumptive policy, thisduration type indicates that license units should be allocated to the specifiedcontext upon receipt of a license request and permanently removed from theavailable units pool (field 42) upon receipt of a license release which reflectssuccessful completion of the transaction. Upon receipt of a license release whichcarries an error status or upon abnormal termination of the processor contexthaving made the original license request, the allocated units will be deallocatedand returned to the pool of available units (field 42).

The assignment duration type in Figure 3 (field 45 of Figure 2) imposes theconstraint that the required units must have been previously assigned to a specificcontext. The sub-contexts which must be specified in the assignment are thosegiven in the context-template. A "reassignment constraint" may be imposed, andthis is a limitation on how soon a reassignment can be made. For example, a - 14 reassignment constraint of 30-days would require that units assigned to a specificcontext could not be reassigned more often than every 30-days; this would preventskirting the intent of the license by merely reassigning units whenever a user ofanother context made a request allocation call for the product. Related to thisassignment constraint, a "reallocation limit" may also be imposed, to state theminimum duration of an allocation; where there is a context template of process,the intent is to count the number of uses of the software product at a given time,but where software runs in batch rather than interactive mode it may run veryquickly on a powerful machine, so a very few concurrent uses may permit almostunlimited usage - by imposing a reallocation constraint of some time period, thismanner of skirting the intent of the license may be constrained.

The immediate duration type (field 45 of Figure 2) is used to indicate thatthe allocation or consumption of an appropriate number of license units from thepool of available units (field 42) should be performed immediately upon receiptof a license request. Receipt of license release or abnormal terminations will thenhave no impact on the license management system. When specified as theduration for an allocative policy, the effect will be simply to check if anappropriate number of license units are available at the time of a license request.When specified as the duration for a consumptive policy, the effect will be todeduct the appropriate number of license units from the available pool at the timeof a license request, and, thereafter, abnormal termination, such as a fault at theuser CPU 16 or failure of the network link, will not reinstate the units.

The LURDM or license unit requirement determination method, field 46,has the alternatives seen in Figure 3 and stores information used in calculating thenumber of units that should be allocated or consumed in response to a license - 15 - request. If this field specifies a table lookup kind, this means license unitrequirements are to be determined by lookup in the LURT (field 47) which isassociated with the current license. If a constant kind is specified, this indicatesthat the license units requirements are constant for all contexts on which the 5 licensed product or product feature may run. A private LURDM specifies that the license unit requirements are to be determined by the licensed product 17, notby the license management facility 11. The license unit requirements tables(LURTs) provide a means by which issuers of licenses can store informationdescribing the relation between context (or row selector) and unit requirements. 10 The license units requirements determination method (LURDM) must specify "table lookup" for the LURT to be used, and if so a row selector must bespecified, where a valid row selector is any subcontext, e.g., platform ID, username, time of day, etc. An example of an LURT fragment is shown in Figure 4,illustrating the license unit requirements table mechanism. In this example, the 15 row selector is "platform-ID" so the platform-ID value determines which row is used. The issuer of this LURT of Figure 4 has established three unit requirementtiers for use in determining the unit requirements for that issuer’s products. Thereason for the tiers is not mandated by the license management system, but theissuer 25 (actually the user of the program 26) would probably be establishing 20 three pricing tiers, each reflecting a different perspective on the relative utility of different platforms in supporting the use of various classes of product 17. Thefirst column in Figure 4, Column A, specifies the use requirements for a class ofproducts whose utility is highly sensitive to the characteristics of the specificplatform on which they are run. This can be seen by observing that the unit 25 requirements are different for every row in Column A. Products which use the

second column (Column B) appear to have a utility which is more related to theclass of platform on which they run. This is indicated by the fact that all the PC 16 platforms share a single value which is different from that assigned to the VAXplatform. The final column (Column C) is for use with a class of products whichis only supported on the VAX platform. Figure 4 is of course merely an example,and the actual LURT created by the license document generator 26 and storedin the license database 23 (as field 47 of the product use authorization 35) can beof any content of this general format, as desired by the license issuer.

Instead of always selecting the rows in LURT tables according to theplatform ID of the execution platform, in order to handle the breadth of businesspractices that need to be supported by the license management facility, the LURTmechanism is extended by providing a "row selector" attribute in the LURT classstructure. No default is provided although it is expected that the normal value forthe row selector attribute will be "platform ID."

In the system of patent 4,937,863, a concept similar to that of the LURTof Figure 4 was provided, with rows selected by the platform ID and columnsselected by some arbitrary means, typically according to product type. The systemof this invention allows flexibility in the selection of both LURT row and columnwhile continuing to provide backwards compatibility for licenses defined within theconstraints of patent 4,937,863.

Some examples will illustrate potential uses for the row selector attribute.A customer may only want to pay for the use of a product during one or twomonths of the year; the product may be FORTRAN and the reason for thisrequest may be that the company has a fairly stable set of FORTRAN subroutinesthat are given regular "annual maintenance" only during the months of May andJune. To handle this customer’s needs, the FORTRAN product would generate - 17 an application subcontext which would contain a value representing the month ofthe year. Then, a LURT table would be defined with twelve rows, one for eachmonth of the year. In some column, probably column A, a negative one (-1)would be placed in each month except for May and June. These two monthswould contain some positive number. The product use authorization would thenhave a LUROM field specifying a LURT for use to determine the unitsrequirement, and would name this custom LURT table. The effect would be thatthe PUA could only be used during the months of May and June since negativeone is interpreted by license managers to mean "use not authorized." Thismechanism could also be used to do "time of day" charging. Perhaps chargingfewer units per use at night than during the day. Also, if a subcontext was usedthat contained a year value, a type of license would be provided that varied in itsunit requirements as time passed. For instance, it might start by costing 10-unitsper use in 1991 but then cost one unit less every year as time passed, eventuallygetting to the point where the unit requirement was zero.

Another example is font names. A specific customer may purchase alicense giving it the right to concurrent use of 100-units of a large font collection;some of the fonts may cost more to use than others. For instance, Times Romanmight cost 10-units per use while New Century Schoolbook costs 20-units per use.The problem is, of course, making sure that charges are properly made. Thesolution is to build a LURT table with a specified application subcontext as itsrow selector. A row is then created for each font in the collection and in ColumnA of the LURT, the number of units required to pay for use of the font would bespecified. The print server would then specify the name of a font as the value ofthe application subcontext whenever it does an Im^request_allocation() call. Thiswill allow charges to be varied according to font name. - 18 A further example is memory size. Some products are more or lessvaluable depending on the size of memory available to support them. A softwarevendor wishing to determine unit requirements based on memory size will be ableto do so by building LURT tables with rows for each reasonable increment ofmemory (probably l-megabyte increments). Their applications would then sensememory size (using some mechanism not part of the license management facility)and pass a rounded memory size value to the license manager in a private context.

Other examples are environment and operating system. Some productsmay be valued differently depending on whether they are being run in aninteractive mode or in batch. This can be accomplished by building LURT rowsfor each of the standard platform subcontexts that specify environmentRegarding operating system, it has been considered desirable by many to have asingle product use authorization permit the use of a product on any number ofoperating systems, this conflicts with some vendors policies who do not want tohave to create a single price for a product that applies to ail operating systems.Thus, if an operating system independent license were offered for a C compiler,the price would be the same on MS-DOS, VMS, and/or UNIX. Clearly, it can beargued that the value of many products is, in part, dependent on the operatingsystem that supports them. By using a row selector of operating system (one ofthe standard platform subcontexts), license designers could, in fact, requiredifferent numbers of units for each operating system. However, it might be moredesirable to base the row selection on a private application subcontext thatnormally had the same value as the operating system subcontext. The reason forthis is that the license designer might want to provide a default value for operatingsystem names that were unknown at the time the LURT rows were defined. Ifthis is the case, the product would contain a list of known operating systems and - 19 - pass the subcontext value of "Unknown" when appropriate. The LURT row for"Unknown" would either contain a negative one (-1) to indicate that this operatingsystem was unsupported or it would contain some default unit requirement.

Another example is variable pricing within a group. One of the problemswith a "group" license is that there is only one unit requirements field on the PUAfor a group. Thus, all members of the group share a single unit requirement.However, in those cases were all members of the group can be appropriatelylicensed with a constant unit requirement yet it is desired to charge differentamounts for the use of each group member, a LURT can be built that has rowsdefined for each group member. The row selector for such a group would be thestandard platform subcontext "product name."

Many different types of license can be created using different combinationsof contexts, duration and policy from the table of Figure 3. As examples, thefollowing paragraphs show some traditional licensing styles which can beimplemented using the appropriate values of the product use authorization fields43-46. A "system license" as it is traditionally designated is a license which allowsunlimited use of a product on a single hardware system. The correct number ofunits must be allocated to the processor in advance and then an unlimited productuse is available to users of the system. The product use authorization would havein the context field 44 a context template for a node name, the duration fieldwould be "assignment" and the policy style field 43 would be "allocative". - 20 A "concurrent use" license is one that limits the number of simultaneoususes of a licensed product. Concurrent use license units are only allocated whenthe product is being used and each simultaneous user of the licensed productrequires their own units. In this case the context template, field 44, is a processID, the duration field is "transaction" and the policy style 43 is "allocative". A "personal use" license is one that limits the number of named users ofa licensed product. This style of licensing guarantees the members of a list ofusers access to a product. Associated with a personal use type of product useauthorization there is a list of registered users. The administrator is able to assignthese users as required up to the limit imposed by the product use authorization;the number of units assigned to each user is indicated by the LURDM. It may bea constant or it may vary as specified in a LURT. The context template is "username", the duration is "assignment", and the policy is "allocative". A "site license" is one that limits the use of a licensed product to a physicalsite. Here the product use authorization contains for the context template either"network name" or "domain name", the duration is "assignment" and the policystyle field 43 is "allocative".

Generally, a license to use a software product is priced according to howmuch benefit can be gained from using the product, which is related to thecapacity of the machine it will run on. A license for unlimited use on a largeplatform such as a mainframe, where there could be thousands of potential usersat terminals, would be priced at a high level. Here the style would be "allocative",the context template = "node", the duration = "assignment" and the LURDM maybe "Column A' - the units, however, would be large, e.g., 1000. At the other end - 21 - of the scale would be a license for use on a single personal computer, where thefield values would be the same as for the mainframe except the units would be "I".If a customer wanted to make the product available on the mainframe but yetlimit the cost, he could perhaps get a license that would allow only five users atany given time to use the product; here the fields in the product use authorizationwould be: units = 5; style * allocative; context template = process; duration =transaction; LURDM = constant, 1-unit. This would still be priced fairly highsince a large number of users may actually use the product if a session of use wasshort. A lower price would probably be available for a personal use license whereonly five named persons could use the product, these being identified only in thelicense server 10, not named by the license issuer 25. Here the fields in theproduct use authorization are: units = 5; style = allocative; context template =user name; duration = transaction; LURDM = constant, 1-unit.

An additional feature that may be provided for in the product useauthorization 35 is license combination. Where there are multiple authorizationsfor a product, license checking requests sent by user nodes 16 may be satisfied bycombining units from multiple authorizations. Individual product useauthorizations may prohibit combined use. Thus, a licensee may have a licenseto use a product 17 on an allocative basis for a certain number of units and on aconsumptive basis for another number of units (this may be attractive from pricingstandpoint); there might not be enough units available for a particular contextfrom one of these licenses, so some units may be ''borrowed" from the otherlicense (product use authorization), in which case a combination is made.

The interface between the program executing on the client or user 16 andthe license server 10 or its delegatees 13 includes basically three procedure calls: - 22 a request allocation, a release allocation and a query allocation. Figure 5illustrates in flow chart form some of the events occurring in this client interface.The request allocation is the basic license checking function, a procedure callinvoked when a software product 17 is being instantiated, functioning to requestan allocation of license units, with the return being a grant or refusal to grant.Note that a product may use request allocation calls at a number of points inexecuting a program, rather than only upon start-up; for example, a requestallocation may be sent when making use of some particular feature such a specialgraphics package or the like. The release allocation call is invoked when the userno longer needs the allocation, e.g., the task is finished, and this return is oftenmerely an acknowledge; if the style is consumptive, the caller has the opportunityvia the release allocation call to influence the number of units consumed, e.g.,decrease the number due to some event. The query allocation call is invoked bythe user to obtain information about an existing allocation, or to obtain a callingcard, as will be described.

The request allocation, referred to as lmjequest_allocation(), is a requestthat license units be allocated to the current context. This function returns a grantor denial status that can be used by the application programmer to decide whetherto permit use of the product or product feature. The status is based on theexistence of an appropriate product use authorization and any license managementpolicies which may be associated with that product use authorization. Licenseunits will be allocated or consumed, if available, according to the policy statementfound on the appropriate product use authorization. The product would normallycall this function before use of a licensed product or product feature. Thefunction will not cause the products execution to be terminated should the requestfail. The decision of what to do in case of failure to obtain allocation of license - 23 units is up to the programmer. The arguments in a request allocation call are theproduct name, producer name, version, release date, and request extension. Theproduct name, producer name, version and release date are the name of thesoftware product, name of producer, version number and release date forspecifically identifying the product which the user is requesting an allocation bemade. The request extension argument is an object describing extended attributesof the request, such as units required, LURT column, private context, andcomment. The results sent back to the calling node are a return code, indicatingwhether the function succeeded and, if not, why not, and a grant handle, returnedif the function completes successfully, giving an identifying handle for this grantso it can be referred to in a subsequent release allocation call or query allocationcall, for example.

The release allocation, referred to as ltnjelease_allocation(), is anindication from a user to the license manager to release or consume unitspreviously allocated. This function releases an allocation grant made in responseto a prior call to request allocation. Upon release, the license management style38 determines whether the units should be returned to the pool of available unitsor consumed. If the caller had specified a request extension on the earlier call torequest allocation which contained a units-required-attribute, and the number ofunits requested at that time are not the number of units that should be consumedfor the completed operation, the caller should state with the units-consumedargument how many units should be consumed. The arguments of the releaseallocation are: grant handle, units consumed, and comment. The grant handleidentifies the allocation grant created by a previous call to request allocation. Theunits-consumed argument identifies the number of units which should beconsumed if the license policy is consumptive; this argument should only be used - 24 in combination with an earlier call to request allocation which specified a unitsrequirement in a request extension. Omission of this argument indicates that thenumber of units to be consumed is the same as the number allocated previously.The comment argument is a comment which will be written to the log file 24 ifrelease units are from a consumptive style license or if logging is enabled. Theresult is a return code indicating if the function succeeded, and, if not, why not.

The query allocation, or lm_query_allocation(), is used by licensed productswhich have received allocations by a previous request allocation call. The queryis to obtain information from the server 10 or delegatee server 13 about thenature of the grant that has been made to the user and the license data used inmaking the grant, or to obtain a calling card (i.e., a request that a calling card beissued). Typically, the item read by this query function is the token field 52 whichcontains arbitrary information encoded by the license issuer and which may beinterpreted as required by the stub 19 for the licensed product software 17, usuallywhen a "private" allocation style or context is being employed. The arguments inthis procedure call are the grant handle, and the subject. The grant handleidentifies the allocation grant created by a previous call to request allocation. Thesubject argument is either "product use authorization" or "calling card request"; ifthe former then the result will contain a public copy of the product useauthorization. If this argument is a calling card request and a calling card whichmatches the previous constraints specified in that request can be made available,the result will contain a calling card. If the subject argument is omitted, the resultwill contain an instance of the allocation. The results of the query allocation callare (1) a return code, indicating whether the function succeeded, and, if not, whynot, and (2) a result, which is either an allocation, a product use authorization ora calling card, depending on type and presence of the subject argument. - 25 -

Referring to Figure 5, the flow chart shows the actions at the client in\itsinterface with the server. When the software product 17 is to be invoked, the unit18 is First executed as indicated by the block 60, and the first action is to make arequest allocation call via the stub 19, indicated by the block 61. The client waitsfor a return, indicated by the loop 62, and when a return is received it is checkedto see if it is a grant, at decision block 63. If not, the error code in the return ischecked at block 64, and if a return code indicates a retry is possible, block 65,control passes back to the beginning, but if no retry is to be made then executionis terminated. If the policy is to allow use of the product 17 without a licensegrant, this function is separately accounted for. If the decision point 63 indicatesa grant was made, the grant handle is stored, block 66, for later reference. Theprogram 17 is then entered for the main activities intended by the user. Duringthis execution of product 17, or before or after, a query allocation call can bemade, block 67, though this is optional and in most cases not needed. Whenexecution of the program 17 is completed, the grant handle is retrieved, block 68,and a release allocation call is made, block 69. A loop 70 indicates waiting for thereturn from the server, and when the return received it is checked for an errorcode as before, and a retry may be appropriate. If the release is successfullyacknowledged, the program exits.

Referring to Figure 6, the actions of the server 10 or delegatee server 13in executing the license management program 11 or 14, for the client interface,are illustrated in flow diagram form. A loop is shown where the server programis checking for receipt of a request, release or query call from its clients. The callwould be a remote procedure call as discussed above, and would be a messagecommunicated by a network, for example. This loop shows the decision blocks 71,72 and 73. If a release allocation call is received, a list of products for which - 26 - authorizations are stored is scanned, block 74, and compared to the productidentity given in the argument of the received call, block 75. If there is no match,an error code is returned to the client, block 76, and control goes back to theinitial loop. If the product is found, the authorization is retrieved from thedatabase 23, block 77 (there may be more than one authorization for a givenproduct, in which case all would be retrieved, but only one will be referred tohere) and all of the information is matched and the calculations made dependingupon the management policy of Figures 3 and 4, indicated by the decision block78. If a grant can be made, it is returned as indicated at block 79, or if not anerror code is returned, block 80. If a release allocation call is received, indicatedby a positive at the decision block 72, the grant handle in the argument is checkedfor validity at block 81. If no match is found, an error code is returned, block 82,and control passes back to the initial loop. If the handle is valid, the authorizationfor this product is retrieved from the database 23 at block 83, and updated asindicated by the block 84. For example, if the license management style isallocative, the units are returned to the available pool. Or, in some cases, noupdate is needed. The authorization is stored again in the database, block 85, anda return made to the client, block 86, before control passes back to the initialloop. If the decision block 73 indicates that a query allocation call is received,again the grant handle is checked at block 87, and an error code returned at block88 if not valid. If the grant handle matches, the authorization is retrieved fromthe database 23, at block 89, and a return is made to the client giving therequested information in the argument, block 90.

The basic allocation algorithm used in the embodiment of the licensemanagement system herein described, and implemented in the method of Figures5 and 6, is very simple and can handle a very large proportion of known license - 27 .- unit allocation problems. However, it should be recognized that a more elaborateand expanded algorithm could be incorporated. Additions could be made inefforts to extend the allocation algorithm so that it would have specific support foroptimizing unit allocation in a wider variety of situations. Particularly, sources ofnon-optimal allocations occurring when using the basic allocation algorithm arethose that arise from combination and reservation handling.

The first step is formation of full context. The client stub 19 is responsiblefor collecting all specified platform and application subcontexts from the executionenvironment of the product 17 and forwarding these collected subcontexts to thelicense management server 13 or 10. The collection of subcontexts is referred toas the "full context" for a particular license unit allocation request.

The next step is retrieval of the context template. When the licensemanager receives an lmjequest_attocation(), it will look in its list of availableproduct use authorizations (PUA) to determine if any of them conform to theproduct identifier provided in the lmjequestjrilocation() call. The productidentifier is composed of: product name, producer, version, release date. If anymatch is found, the license manager will extract from the matching PUA thecontext template. This template is composed of a list of subcontexts that arerelevant to the process of determining unit requirements. Thus, a contexttemplate may indicate that the node-ID subcontext of a specific full context is ofinterest for the purposes of unit allocation. The context template would notspecify any specific value for the node-ID; rather, it simply says that node-IDshould be used in making the allocation computation. - 28 -

The next step is masking the full context. Having retrieved the contexttemplate, the license manager will then construct an "allocation context" byfiltering the full context to remove all subcontexts which are not listed in thecontext template. This allocation context is the context to be used in determiningallocation requirements.

Then follows the step of determining if the request is new. The licensemanager maintains for each product use authorization a dynamic table whichincludes the allocation contexts of all outstanding allocations for that PUA (i.e.,allocations that have been granted but have not yet been released). Associatedwith each entry in this table is some bookkeeping information which records thenumber of units allocated, the full context, etc. To determine if a recentlm_request_allocation() requires an allocation of units to be made, the licensemanager compares the new allocation context with all those allocation contexts inthe table of outstanding allocations and determines if an allocation has alreadybeen made to the allocation context. If the new allocation context does notalready exist in the table, an attempt will be made to allocate the appropriatenumber of units depending on the values contained in the LURDM structure ofthe PUA and any LURTs that might be required. If an allocation context similarto that specified in the new allocation request does exist in the table, the licensemanager will verify that the number of units previously allocated are equal to orgreater than the number of units which would need to be allocated to satisfy thenew allocation request. If so, the license manager will return a grant handle tothe application which indicates that the allocation has been made (i.e., it is a"shared allocation" - the allocated units are shared between two requests.) If not,the license manager will attempt to allocate a number of units equal to the - 29 difference between the number previously allocated and the number of unitsrequired.

The step of releasing allocations (Fig. 6, blocks 84-85) occurs when thelicense manager receives an lm_release_allocation() call; it will remove the recordin its dynamic allocation table that corresponds to the allocation to be released.Having done this, the license manager will then determine if the allocation to beremoved is being shared by any other allocation context. If so, the unitsassociated with the allocation being released will not be released. They willremain allocated to the remaining allocation contexts. Some of the units mightbe released if the license manager determines that the number of allocated unitsexceeds the number needed to satisfy the outstanding allocation contexts. If thisis the case, the license manager will "trim" the number of allocated units to anappropriate level.

In summary, the two things that make this algorithm work are (1) the basicrule that no more than one allocation will be made to any single allocationcontext, and (2) the use of the context template to make otherwise dissimilar fullcontexts appear to be similar for the purposes of allocation.

The license designer’s task, when defining basic policy, is then to determinewhich contexts should appear to be the same to the license manager. If thelicense designer decides that all contexts on a single node should look the same(context template = node-ID), then any requests that come from that node willall share allocations. On the other hand, a decision that ail contexts should beunique (i.e., context template = process-ID) will mean that allocations are nevershared. ) - 30 - and stores a unit value indicating the number of licensing units for each product.When a user wishes to use a licensed product, a message is sent to the centrallicense management facility requesting a license grant. In response to thismessage, the facility accesses the database to see if a license exists for thisproduct, and, if so, whether units may be allocated to the user, depending uponthe user’s characteristics, such as the configuration of the platform (CPU) whichwill execute the software product. If the license management facility determinesthat a license can be granted, it sends a message to the user giving permission toproceed with activation of the product. If not, the message denies permission.

While the concepts disclosed in the patent 4,937,863 are widely applicable,and indeed are employed in the present invention, there are additional functionsand alternatives that are needed in some applications. For example, the licensemanagement system should allow for simultaneous use of a wide variety ofdifferent licensing alternatives, instead of being rigidly structured to permit onlyone or only a few. When negotiating licenses with users, vendors should haveavailable a wide variety of terms and conditions, even though a given vendor maydecide to narrow the selection down to a small number. For example, a softwareproduct may be licensed to a single individual for use on a single CPU, or to anorganization for use by anyone on a network, or for use by any users at terminalsin a cluster, or only for calls from another specific licensed product, or any of alarge number of other alternatives. A vendor may have a large number ofproducts, some sold under one type of license and some under others, or aproduct may be a composite of a number of features from one or more vendorshaving different license policies and prices; it would be preferable to use the samelicense management system for all such products. - 31 -

Distributed computing systems present additional licensing issues. Adistributed system includes a number of processor nodes tied together in anetwork of servers and clients. Each node is a processor which may executeprograms locally, and may also execute programs or features (subparts ofprograms) via the network. A program executing on one node may make remoteprocedure calls to procedures or programs on other nodes. In this case, someprovision need be made for defining a license permitting a program to beexecuted in a distributed manner rather than separately on a single CPU, short ofgranting a license for execution on all nodes of a network.

In a large organization such as a company or government agency havingvarious departments and divisions, geographically dispersed, a software licensepolicy is difficult to administer and enforce, and also likely to be more costly, ifindividual licenses are negotiated, granted and administered by the units of theorganization. A preferred arrangement would be to obtain a single license fromthe software producer, and then split this license into locally-administered partsby delegation. The delays caused by network communication can thus beminimized, as well as budgetary constraints imposed on the divisions ordepartments. Aside from this issue of delegation, the license management facilitymay best be operated on a network, where the licensing of products run on allnodes of the network may be centrally administered. A network is not necessaryfor use of the features of the invention however, since the license management canbe implemented on a single platform.

Software products are increasingly fragmented into specific functions, andseparate distribution of the functions can be unduly expensive. For example, aspreadsheet program may have separate modules for advanced color graphics, for - 32 - accessing a database, for printing or displaying an expanded list of fonts, etc.Customers of the basic spreadsheet product may want some, none or all of theseadded features. Yet, it would be advantageous to distribute the entirecombination as one package, then allow the customer to license the featuresseparately, in various combinations, or under differing terms. The customer mayhave an entire department of the company needing to use the spreadsheet everyday, but only a few people who need to use the graphics a few days a month. Itis advantageous, therefore, to provide alternatives for varied licensing of parts orfeatures of software packages, rather than a fixed policy for the whole package.

Another example of distribution of products in their entirety, but licensingin parts, would be that of delivering CD ROMs to a customer containing all of thesoftware that is available for a system, then licensing only those parts the customerneeds or wishes to pay fees for rights to use.. Of course, the product need not bemerely applications programs, operating systems, or traditional executable code,but instead could also include static objects such as printer fonts, for example, orgraphics images, or even music or other sound effects.

As will be explained below, calling and caller authorizations are providedin the system according to one feature of the invention, in order to providetechnological support for a number of business practices and solve technicalproblems which require the use of what is called "transitive licensing." By"transitive licensing" is meant that the right to use one product or feature impliesa right to use one or more other products or features. Transitive licenses aresimilar to group licenses in that both types of license consist of a single instrumentproviding rights of use for a plurality of products. However, transitive licensesdiffer from group licenses in that they restrict the granted rights by specifying that - 33 - the licensed products can only be used together and by further specifying one ormore permitted inter-product calling/caller relationships. Some examples mayhelp to clarify the use and nature of a transitive license: the examples to beexplained are (1) two products sold together, (2) a give-away that results fromnarrow choices of licensing alternatives, (3) a client licensing method in aclient/server environment, (4) impact of modular design, and (5) the impact ofdistributed design. A software vendor might have two products for sale: the first a mailsystem, and the second a LEXIS™-like content-based text retrieval system. Eachof these products might be valued at $500 if purchased separately. Somecustomers would be satisfied by purchasing the rights to use only one of theseproducts, others might find that they can justify use of both. In order to increasethe likelihood that customers will, in fact, purchase both products, it would not besurprising if the software vendor offered his potential customers a volumediscount, offering the two products for a combined price of $800. The customerswho took advantage of this combined offer would find that they had received twoproducts, each of which could be exploited to its fullest capabilities independentlyfrom the other. Thus, these customers would be able to use the content basedretrieval system to store and retrieve non-mail documents. However, from timeto time, the vendor may discover that particularly heavy users of mail wish to beable to use the content based retrieval system only to augment the filingcapabilities provided by the standard mail offering. It is likely that many of thesepotential customers would feel that $800 is simply too much to pay for anextended mail capability. The vendor might then consider offering thesecustomers a license that grants mail users the right to use the content-basedretrieval system only when they are using mail and prohibits the use of content - 34 based retrieval with any other application that might be available on thecustomers system. This type of license is referred to below a "transitive license,"and it might sell for S600.

Another example is a relational database product (such as that referred toas Rdb™) designed for use on a particular operating system, e.g., VMS. Thisrelational database product has two components: (1) A user interface used indeveloping new databases, and (2) a "run-time" system which supports the use ofpreviously developed databases. The developers of the database product mightspend quite a bit of effort trying to get other products made by the vendor of thedatabase product to use it as a database instead of having those other productsbuild their own product-specific databases. Unfortunately, the other productdesigners may complain that the cost of a run-time license for the databaseproduct, when added to the cost of licenses for their products, would inevitablymake their products uncompetitive. Thus, some mechanism would be needed thatwould allow one or another of the vendor’s products to use the run-time systemfor the relational database product in a "private" manner while not givingunlicensed access to products of other vendors. No such mechanism existed, priorto this invention: thus, the vendor might be forced to sell the right to use its run-time system for the database product with its proprietary operating system license.Clearly, this combined license would make it possible for the vendors products touse its database product without increasing their prices; however, it also wouldmake it possible for any customers and third-parties to use the database productwithout paying additional license fees. However, had the system of the inventionbeen available, the vendor could have granted transitive licenses for the run-timecomponent of its database product to all the vendor’s products. Essentially, theselicenses would have said that the database run-time could be used without an - 35 - additional license fee if and only if it was used in conjunction with some other ofthe vendor’s products. Any customer wishing to build a new relational databaseapplication or use a third-party application that relied on the vendor’s databaseproduct would have had to pay the vendor for its database run-time license. A proposed client/server licensing method provides yet another exampleof a problem which could be solved by transitive licensing. Typically, a client isonly used by one user at a time, while a server can support an arbitrary numberof clients depending on the level of client activity and the capacity of the machinewhich is supporting the server. While traditionally, server/client applications havebeen licensed according to the number of clients that a server could potentiallysupport, this may not be the most appropriate method for licensing when thealternatives afforded by the invention are considered. The business model for theproposed client/server method requires that each client be individually licensedand no explicit licensing of servers is required to support properly licensed clients.Such a licensing scheme makes it possible to charge customers only for the specificnumber of clients they purchase. Additionally, it means that a single client canmake use of more than one server without increasing the total cost of the system.The solution to this transitive licensing problem would be to provide a mechanismthat would allow the clients to obtain license unit allocations and then pass a"proof* of that allocation to any servers they may wish to use. Servers would thensupport any clients whose proofs could be verified to be valid. On the other hand,if a client that had not received a proof of allocation attempted to use a server,the server would obtain a license allocation for that client session prior toperforming any services. Such a solution has not been heretofore available. - 36 -

As the complexity and size of the software systems provided to customersincreases, it is found that the actual solution provided to customers is no longera single product. Rather, customers are more often now offered solutions whichare built up by integrating an increasing number of components or products, eachof which can often stand alone or can be part of a large number of othersolutions. In fact, a product strategy may rely almost exclusively on the vendor’sengineering and selling a broad range of specialized components that can only befully exploited when combined together with other components into a largersystem. Such components include the relational database runtime systemmentioned above, mail transport mechanisms, hyperinformation databases,document. format conversion services, time services, etc. Because thesecomponents are not sold on their own merits, but rather on their ability tocontribute to some larger system, it is unlikely that any one customer will bereceiving the full abstract economic value of any one of the components onceintegrated into a system. Similarly, it can be observed that the value of anycomponent once integrated into a larger system varies greatly from system tosystem. Thus, it may be found that a mail transport mechanism contributes alarge part of a system whose primary focus is mail, however, it will contributeproportionally less of the value of a system that provides a broader officeautomation capability. As a result of these observations, the job of the businessanalyst who is attempting to find the "correct" market price for each componentstanding on its own, is more complex. In reality, the price or value of thecomponent can only be determined when considering the contribution of thatcomponent to the full system or solution in which it is integrated. Attempting tosell the components at prices based on their abstract, independent values willsimply result in overpriced systems. - 37 -

Transitive license styles are particularly suited to dealing with pricing ofmodular components, since component prices can be clearly defined in relationto the other components or systems which they support. Thus, a vendor cancharge a price of S100 for the right to use a mail transport system in conjunctionwith one product, yet charge S200 for the use of the same mail transport systemwhen used by another product.

In addition to the "business" reasons for wanting to support transitivelicensing, there is also a very good technical reason that arises from the growingtendency of developers to build "distributed products" as well as the drive towardapplication designs that exploit either tightly or loosely coupled multiprocessorsystems; the availability and growing use of remote procedure calls has contributedto this tendency. This technical problem can be seen to arise when consideringa product which has a number of components, each of which may run in adifferent process space and potentially on a different computer system. Thus,there might be a mail system whose user interface runs on one machine, its "filecabinet" is supported by a second machine and its mail transport system runs onyet a third machine. The simple question which arises is: "Which of the threecomponents should check for licenses?" Clearly it must be ensured that no singlecomponent can be used if a valid license is not present. Thus, the answer to thequestion will probably be that all three components should check for licenses.However, the question is then presented: "Where are the licenses to be located?".This can become more complex.

Increasingly, the distributed systems being built are being designed so thatit is difficult to predict on which precise machine any particular component willrun. Ideally, networks are supposed to optimize the placement of functions 38 automatically so that the machine with the most available resource is alwavs thej i one that services any particular request. This dynamic method of configuring thedistribution of function servers on the network makes it very difficult for a systemor network manager to predict which machines will run any particular functionand thus very difficult for him to decide on which machines software licensesshould be loaded.

Even if a system manager could predict which machines would be runningthe various application components and thus where the license units should beloaded, the situation would still be less than ideal. The problem arises from thefact that each of the components of the application would be independentlymaking requests for license unit allocations. This behavior will result in a difficultproblem for anyone trying to decide how many license units are required tosupport any one product. Given the mail example, the problem wouldn’t exist ifit were assumed that all three components (i.e., user interface, file cabinet, andtransport system) were required by the design of the mail system to be in usesimultaneously. If this were the case, it could be simply assumed that supportinga single activation of the mail system would require three units. However, in areal mail system, it will be inevitably discovered that many users will only be usingjust the user-interface and file-cabinet components of the system at one time.Thus, there will be some unused units available which could be used to authorizeadditional users. This situation might not be what is desired- by the softwarevendor.

The problem of providing license support to multi-component productswhich are dynamically configured could be solved by viewing each of the productcomponents as a distinct licensable product and by treating the problem as one -39- 10 of transitive licensing, but a mechanism for accomplishing this has not beenavailable. Essentially, a single license document would be created that stated thatif any one of the components had successfully obtained a license to run, it coulduse this grant to give it the right to exploit the other components. Thus, in theexample above, the user might start the mail system by invoking its user interface.This user interface code would then query the license management facility for alicense allocation and once it has received that allocation, it would pass a proofof allocation to the other mail components that it uses. Each of the othercomponents would request that the license management system validate that the"proof is valid prior to performing any service; however, none of the othercomponents would actually require specific allocations to be made to them. Inthis way, the complexity of licensing and managing networks of distributedapplications can be significantly reduced.

SUMMARY OF THE INVENTION 15 In accordance with one embodiment of the invention, a license management system is used to account for software product usage in a computersystem. The system employs a license management method which establishes amanagement policy having a variety of simultaneously-available alternative stylesand contexts. A license server administers the license, and each licensed product 20 upon start-up makes a call to the license server to check on whether usage is permitted, in a manner similar to that of patent 4,937,863. The license servermaintains a store of the licenses, called product use authorizations, that itadministers. Upon receiving a call from a user, the license server checks theproduct use authorization to determine if the particular use requested is -40- permitted, and, if so, returns a grant to the requesting user node. The licenseserver maintains a database of product use authorizations for the licensedproducts, and accesses this database for updating and when a request is receivedfrom a user. While this license management system is perhaps of most utility ona distributed computer system using a local area network, it is also operable in astand-alone or cluster type of system. In a distributed system, a license serverexecutes on a server node and the products for which licenses are administeredare on client nodes. However, the license management functions and the licensedproducts may be executing on the same processor in some embodiments.

The product use authorization is structured to define a license managementpolicy allowing a variety of license alternatives by components called "style","context", "duration" and "usage requirements determination method". The stylemay be allocative or consumptive. An allocative style means the units of thelicense may be allocated temporarily to a user when a request is received, thenreturned to the pool when the user is finished, so the units may be reused whenanother user makes a request. A consumptive style means the units are deductedfrom an available pool when a user node makes a valid request, and "consumed",not to be returned for reuse. The context value defines the context in which theuse is to be allowed, such as on a particular network, by a particular type of CPU,by a particular user name, by a particular process, etc. The duration value (usedin conjunction with the style component) concerns the time when the license unitsare to be deducted from the available pool of units, whether at the time ofrequest, after a use is completed, etc. A usage requirements determinationmethod may be specified to define or provide information concerning the numberof license units charged in response to a license request from a user node; forexample, some CPU platforms may be charged a larger number of license units -41- 10 15 20 than others. A table may be maintained of usage requirements, and thedetermination method may specify how to access the table, for example. Theimportant point is that the user node (thus the software product) can only makea request, identifying itself by user, platform, process, etc., and the licensemanagement facility calculates whether or not the license can be granted (that is,units are available for allocation), without the user node having access to any ofthe license data or calculation. There is a central facility, the license server,storing the license documents, and, upon request, telling the licensed productswhether they can operate under the license terms.

An important feature of one embodiment is that the license administrationmay be delegated to a subsection of the organization, by creating another licensemanagement facility duplicating the main facility. For example, some of the unitsgranted in the product use authorization may be delegated to another server,where the user nodes serviced by this server make requests and receive grants.

The license management facility cannot create a license itself, but insteadmust receive a license document (a product use authorization) from an issuer oflicenses. As part of the overall license management system of the invention, alicense document generator is provided which creates the product useauthorizations under authority of the owner of the software, as negotiated withcustomers. Thus, there are three distinct rights in the overall license managementfacility of the invention: (1) the right to issue licenses, (2) the right to managelicenses, and (3) the right to use the licensed products. Each one of these uses thelicense document only in prescribed ways. The license issuer can generate alicense document. The license manager (or license server as referred to herein)can grant products the right to use under the license, and can delegate parts of the 25 -42-

<img img-format="tif" img-content="drawing" file="IL116271AD00021.tif" id="idf0001" />

10 15 20 licensed units for management by another server, as defined'by the licensedocument; the way of granting rights to products is by responding to certaindefined calls from the products. And, the licensed products can make certain callsto the license server to obtain grants of rights based upon the license document,inquire, or report, but ordinarily cannot access the document itself.

As explained above, transitive licensing is an important feature of oneembodiment. This is the provision of a mechanism for one user node to getpermission to use another software product located on another user node; this isreferred to as a calling authorization and a caller authorization, using a "callingcard," and these are examples of the optional features which must be specificallypermitted by the product use authorization. A user node must obtain permissionto make a procedure call to use a program on another node; this permission isobtained by a request to the license server as before, and the permission takes theform of a calling card. When a calling card is received by a second node (i.e.,when the procedure call is made), a request is made by the second node to thelicense server to verify (via the product use authorization) that the calling card isvalid, and a grant sent to the user node if allowed. In this manner, all nodes mayhave use of a program by remote calls, but only one consumes license units.

Another important feature of one embodiment is a management interfacewhich allows a license manager to modify the license policy components of alicense document maintained by at a license server in its database. Usually thelicense manager can only make modifications that restrict the license policycomponents to be more restrictive than originally granted. Of course, themanagement interface is used to make delegations and assignments, if these areauthorized. 25 -43-

The license document interchange format is an important feature, in thatit allows the license management system to be used with a wide variety of softwareproducts from different vendors, so long as all follow the defined format. Theformat uses data structures that are defined by international standards. 5 An important function is the filter function, used in the management interface and also in the client interface to select among elements in the datastructures.

Passages of the description which are not within the scope of theclaims do not constitute part of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are set forth in10 the appended claims. The invention itself, however, as well as other features and advantages thereof, will be best understood by reference to the detaileddescription of specific embodiments which follows, when read in conjunction with the accompanying drawings, wherein:

Figure 1 is a diagram in block form of a distributed computer system which15 may be used to implement the license management operations according to one embodiment of the invention;

Figure 2 is a diagram of the content of a license document or "product useauthorization" generated by the license document generator and stored by thelicense server in the system of Figure 1; -44- φ Figure 3 is a diagram of the alternatives for license style, context and duration making up the license management policy implemented in the system ofFigure 1., according to one embodiment of the invention;

Figure 4 is a diagram of an example of a fragment of a license use 5 requirements table (LURT) used in the system of Figure 1, according to one embodiment of the invention;

Figure 5 is a logic flow chart of a program executed by a user node (client),in the system of Figure 1, according to one embodiment of the invention;

Figure 6 is a logic flow chart of a program executed by a license server, in10 the system of Figure 1, according to one embodiment of the invention; and

Figure 7 is a diagram of the calls and returns made in an example of useof calling cards in the system of Figure 1.

Figure 8 is a diagram of an LDIF document identifier, according to anstandard format; 15 Figure 9 is a syntax diagram of an LDIF document;

Figure 10 is a diagram of an LDIF document structure;

Figures 11, 13, 15, 17, 18, 19, 21-28 and 31-43 are syntax diagrams forelements of various ones of the LDIF data structures; -45-

Figure 16 is a diagram of a license data structure;

Figures 12, 14 and 20 are examples of descriptions of data elements usinga standard notation;

Figures 29 and 30 are examples of context templates used in the licensemanagement system;

Figures 44 and 45 are tables of attributes specific to filter and filter itemtype; and

Figure 46 is notation in a standard format for an example of a filter.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

Referring to Figure 1, a license management facility according to oneexample embodiment of the invention is centered around a license server 10,which typically includes a CPU located in the customer’s main office and executinga license management program 11 as will be described, under an operating system 12. The license server 10 communicates with a number of delegatees 13 whichlikewise include CPUs in departments or divisions of the company or organization,each also executing a license management program 14 under an operating system 15. The license management program 14 is the same as the program 11 executingon the main server 10; the only difference in the functions of server 10 and servers13 is that the latter have a delegated subset of the license units granted to theserver 10, as will be described. The CPUs 13 are in turn servers for a number of -46- users 16, which are CPU nodes where the licensed programs 17 are actuallyexecuted. The programs 17 executing on the user CPUs 16 are applicationsprograms (or operating systems, etc.) which have added to them units 18 and 19,according to the invention, allowing them to make inquiry to the their server 13(or 10) before executing and to report back after executing, using a client stub 19in the manner of remote procedure calls, in one embodiment. A user node 16may have many different programs 17 that may be executed, and the various usernodes 16 would usually each have a set of programs 17 different from the otheruser nodes, ail of which would be administered by the license managementprogram 14 or 11. The terms "program" and "licensed product" are used inreference to the element 17, but it is understood that the products beingadministered may be segments of programs, or functions or features called byanother program, or even merely data (such as printer fonts), as well as completestand-alone applications programs. The license server 10 communicates with thedelegatee servers 13 by a network 21, as is usual in large organizations, and thedelegatee servers 13 each communicate with their user nodes 16 by networks 22;these networks may be of the Ethernet, token ring, FDDI types or the like, oralternatively, the user nodes 16 may be merely a cluster of terminals on amultiuser system with the delegatee being a host CPU. The particular hardwareconstruction of the user nodes, server nodes, communication networks, etc., andthe operating systems 12 or 15, are of no concern regarding the utility of thefeatures of the invention, the only important point being that the user CPUs 16of the software products 17 in question can communicate readily and quickly withtheir respective server nodes 13 or 10. In one embodiment, remote procedurecalls (RPCs) are used as the communication medium for the interfaces betweencomponents of the system, handling the inquiries and grants as will be described. -47 A remote procedure call is similar to a local procedure call but is made to aprocedure located on a remote node, by way of a communications network.

The function of the unit 19 is that of a client stub, in a remote procedurecall sense. The calls to the license server 10 are made through this stub 19, andreturns are received by the stub 19 and passed on to the program 17. The stub19 is responsible for obtaining the network addresses of other nodes on thenetwork, such as the server 10. Also, the stub 19 is responsible for determiningthe context (as defined below) for passing on to the server 10. The unit 18functions to execute a "private" type of license availability determination if this isused, rather than this task being done by the application program 17, but if theordinary method of determination is employed (using the license server) as isusually the case, the unit 18 is merely code that starts the execution and passescalls and returns back and forth between the program 17 and the unit 19.

The license server 10, using the license management program 11, maintainsa license data file 23 comprising a number of license documents or licenses(product use authorizations), and also maintains a log 24 which is a record of theusage activity of all of the user CPUs 16 of each of the licensed programs. Thedelegatee servers 13 would maintain similar license databases and logs. Thelicense server 10 has no authority to originate a license, but instead must receivea license from a license issuer 25. The issuer 25 is again a CPU executing alicense document generator program 26 under an operating system 27. Thelicense issuer 25 may be under control of the producer 28 of the programs orsoftware products being licensed, or may be controlled by a distributor who hasreceived the authority to grant licenses from the producer or owner 28. Thecommunications link 30 between the license issuer 25 and the license server 10 for -48-

This mechanism permits the system of the invention to dispose of thecumbersome, explicit support of license types having different scope such as thecluster licenses, node licenses, and process licenses found in prior licensemanagement systems including that of patent 4,937,863. Instead of defining alimited set of scopes (cluster, node, etc.), the system of this invention provides ageneral mechanism which allows an effectively unlimited range of allocationscopes to be defined.

Transitive licensing, as referred to above, is supported by the system of theinvention by (1) calling authorizations, which are statements made in field 49 ofthe product use authorization 35 for one product (the "caller") to permit thatproduct to call another product (the "callee"), and, (2) caller authorizations, whichare statements made in field 49 of the product use authorization for one product(the "callee") to permit it to be called by another product (the "caller").

If calling or caller authorizations are to be exploited by products, thenwhenever one product calls another product, it must pass the callee a calling card49a. This calling card 49a is an encoding of an identification of the caller as wellas a statement by the license management system that a license unit allocation hasbeen made to the caller which is passing the calling card. This calling card is thenpassed by the callee to the license management system for validation and, if theeither the product use authorization of the caller carries an appropriate callingauthorization or the product use authorization of the callee carries an appropriatecaller authorization, the use of the callee by the caller will be authorized withoutrequiring any additional license unit allocations. -49

Referring to Figure 7, the intercomponent interactions that occur wheneither calling or caller authorizations are being used are illustrated. This figureshows a license management server 10, a caller product 17a named "Product-1"and a callee product 17b named "Product-2". When Product-1 starts to run. it willmake an 1m _request -allocation () call to the license management server 10 toobtain a grant handle for an allocation of some number of units of the Product-1license. Either immediately, or at some later time, but always prior to making acall to Product-2, Product-1 will call lm_queryjillocation(), passing the granthandle received earlier and specifying that it wants a calling card for the productnamed "Product-2." If the field 49 of the product use authorization 35 used tosatisfy the grant represented by the grant handle carries a calling authorization infield 49 naming "Product-2," the license manager will create a calling card 49awhich includes the statement that a calling authorization exists and pass thiscalling card back to Product-1. If the calling authorization does not exist, thecalling card passed to Product-1 will contain a statement to that effect.

Once Product-1 has successfully obtained a calling card 49a from thelicense manager, it will then make a call to Product-2, passing the calling cardalong with any other initialization parameters that would normally be used whenstarting Product-2. Product-2 will then pass that calling card to the licensemanager as part of its lm request-allocation () call and the license manager willdetermine if the calling card is valid. Note that calling cards become invalid oncethe process which received the calling card makes an lm_release-allocation() callor terminates abnormally. If the calling card is valid, and it indicates that a callingauthorization is present, the license manager will verify this statement and if foundto be true, will return a grant handle to Product-2. If, on the other hand, thecalling card carries an indication that no calling authorization is present, the -50 license manager will attempt to find a product use authorization for Product-2 thatcontains a caller authorization naming Product-1 as an authorized caller. If thecaller authorization is found, a grant handle will be passed back to Product-2. Ifnot, the license manager will ignore the calling card and proceed with the normallm_request_allocation() logic.

The requirement to be passing calling cards between products requires thatboth the caller and the callee be "aware" of the fact that calling and callerauthorizations may be used. This is one of the few examples of a requirement fora product 17 to become actively involved in the licensing problem when using thelicensing management system of the invention. However, since the use ofcalling/caller authorizations if a fairly "sophisticated" and powerful feature, it isconsidered acceptable to impose this burden on application coders.

MANAGEMENT INTERFACE

Referring to Figure 1, the license management program 11 executing on aserver 10 includes a license management interface 33 which functions to allow auser at a console for the server 10 CPU or at a remote terminal to implementcertain necessary operations. The management interface 33 is essentially the toolsor mechanisms available to the license manager at the licensee’s site to (a) loadthe various licenses received from issuers 25 into the database 23 and make themavailable for request allocation calls from the users, (b) remove the licenses fromthe machine when expired, (c) to make delegations if permitted, (d) to makeassignments, (e) to make reservations, etc. Whatever the license manager isallowed to do to modify the license for his special circumstances (within the original grant, of course), he does it by the mechanism of the managementinterface 33. Some licenses are not modified at all, but merely loaded. In amultiple machine environment, as on a network, there is considerable modifica-tion, as it is necessary to make sure the correct number of units are distributedonto the correct machines, the right people have access, other people don’t haveaccess, etc. Thus, in a network environment, there is extensive use of themanagement interface 33.

In reference to the terminology used in describing the managementinterface, as well as the license management system in general, it is helpful to notethat the documentation conventions, data declarations, macro declarations, etc.,for the object management used in one embodiment of the invention areaccording to the standards set forth in OSI Object Management API Specification,Version 2.0, X.400 API Association and X/Open Company Limited, 24 August1990, a published document.

The specific operations available to the management interface 33 are toallow a manager to open and close a management session, register (load) objectsin the license database 23, obtain a list of objects in the license database 23, andcontrol a cursor (a cursor is a movable pointer to a member of a list of items).Once an object in the license database 23 is identified with the cursor, certainchanges may be made in the object by a write function. For example, certainfields of a license document of Figure 2 or an LURT of Figure 4 may be changedin only specified ways as will be explained.

The operation of opening a session goes by the name of lm_open_session()and is used to establish a license management service session between a -52- management client and the service. Opening a session also creates a workspaceto contain objects returned as a result of functions invoked within the session.Object management Objects can be created and manipulated within thisworkspace. Objects created within this workspace, and only such objects, may beused as Object arguments to the other license management service managementfunctions used during the session established by a call to this function. More thanone session may exist simultaneously.

The arguments that go with a lm_open_session() call are (a) the bindinghandle, which is binding information that defines one possible binding (a client-server relationship), and (b) a comment which will be inserted in the log file 24if logging is enabled. The results from a lm_open_s&amp;amp;ssion() call are (a) a returncode indicating whether the function succeeded, and, if not, why not, (b) a session,which is an established license management session between the managementclient and the license management service, and (c) a workspace that will containall objects returned as a result of functions invoked in the session.

The close session call is referred to by lm_close_session() and functions toterminate the Im session. This function terminates the license service manage-ment session and makes the argument unavailable for use with other interfacefunctions. The arguments that go with a lm_close_session() call are (a) the sessionwhich identifies the established lm session between the management client and.thelicense management service, and (b) a comment which will be inserted in the logfile if logging is enabled. The result of the call is a return code indicating whetherthe function succeeded, and, if not, why not. -53-

The list function returns a set of selected objects in the license database 23,and uses the name Im JistJicenses(). This function is used to search the licensedatabase 23 and return a cursor which represents the first of one or more objectswhich match the specified filter. The specified filter will be applied to each objectin the license database 23; all objects for which the filter evaluates true will beincluded in the object list accessible by the set_cursor function. The argumentsthat go with lmjistjicenses() are (a) session which identifies an establishedsession between the management client and the license management service, and (b) a filter which is an object used to select license database 23 objects; licensedatabase objects will only be included in the object list headed by the cursor ifthey satisfy the filter - the constant no-filter may be used as the value of thisargument if all license data objects are to be included in the object list. Theresults of the lmjistjicenses() call are (a) a return code indicating whether thefunction succeeded, and, if not, why not, and (b) a license list upon successfulcompletion of this call containing a cursor which represents the first of one ormore objects in the current license database 23 for which the specified filterevaluates true.

The register function is to register objects in the license database 23, anduses the name lm_register(). This function is used to register (i.e., load or create)new objects, or modify existing objects, in the license database 23; the objectswhich may be registered include only those which are subclasses of the licensedata class or history objects. The arguments are (a) session, which identifies anestablished session between the management client and the license managementservice, (b) license data object which is to be registered; if this argument isomitted, the comment argument is a required argument and a history objectcontaining the comment will be registered in the license database 23, and (c) -54 comment, which will be inserted in the log file if logging is enabled. The resultis a return code indicating whether the function succeeded, and, if not, why not.The errors possible when it does not succeed include data-expired, duplicate-object, no-such-session, memory-insufficient, network-error, etc., indicated by thisreturn code.

The set cursor function establishes a new cursor, and is called bylm_set_cursor(). The arguments are (a) session, which identifies an establishedsession between the management client and the license management service, (b)forward, which is a boolean value indicating if the direction in which the cursoris to be moved is forward or reverse, (c) filter which is used to eliminate cursorsfrom the search for the next cursor that are not wanted; a new cursor will only beset if it satisfies the filter - the constant no-filter may be used as the value of thisargument if any cursor is to be considered as the target cursor, and (d) the cursorwhich is to be used as the starting point in searching for the new cursor. Theresults are (a) a return code indicating whether the function succeeded, and, ifnot, why not, and (b) next-cursor, which is the requested cursor. The error codesin the return code may be end-of-list, not-a-cursor, etc.

After a session is opened, and an object such as a product use authorizationor a LURT has been identified by the cursor, using the functions explained above,the management interface 33 is able to execute certain object managementinterface functions such as write or copy. By this mechanism, the managementinterface can modify certain limited attributes. None of these attributes can bemodified in such a way that they reduce constraints established by correspondingattributes in the license data objects. The more important attributes which canbe modified by the management interface 33 using this mechanism are: -55- (a) assignment: an assignment of some or all of the units granted onthe associated product use authorization; (b) reservation: a reservation of some or all of the units granted onthe associated product use authorization; (c) delegation: a delegation of the right to manage some or all ofthe units granted on the associated product use authorization, or if theassociated license data is not a product use authorization, the delegationis of the right to use that license data; (d) backup delegation: a statement of the right to manage some orall or the units granted on the associated product use authorization; thisright is only active at times when the delegating server is not available; (e) allocation: an allocation of units to a specific context; (f) allocation period: the minimum duration of a single allocation -all allocated units cannot be allocated to a new context until a time periodequal to the allocation period has passed since the units were lastallocated; (g) termination date: a date which is to override the value specifiedas the end date of the product use authorization 40 - this date must beearlier than specified; (h) delegation permitted: an override of the delegation permittedflag of the associated license data; (i) overdraft; the current overdraft level; (j) overdraft logging: an override of the overdraft logging attributeof the associated product use authorization; (k) comment: a comment created by the licensee: (l) extended info: information not defined by the architecture whichmay be of use in managing the license data. -56-

It will be noted that an assignment and a reservation are identical, the onlydifference being that a reservation is something optional, while an assignment issomething that is required. If the duration is Assignment in the policy declarationof Figure 3, the license manager must assign some or all of the units before unitscan be allocated. Reservations, on the other hand, are made by the licensemanager using the management interface, regardless of the policy.

Thus, there are certain attributes that can be changed by a licenseadministrator using the management interface at the server 10, but none of thesecan result in obtaining more extensive rights to use than granted by the productuse authorization. In each case, the license administrator can limit the rightswhich will be allocated to users in some way that may be appropriate for theadministrator for control purposes.

LICENSE DOCUMENT INTERCHANGE FORMAT

The major structural components of an ASN.l encoded document whichconforms to the specifications for the license management system discussed abovewill be described. The object identifier that is assigned to this data syntax,according to one embodiment, is that specified in ASN.l as seen in Figure 8. TheInternational Standards Organization or ISO, as it is referred to, defines how bitpatterns are chosen to uniquely identify an object type, so the bit pattern set forthin Figure 8 would preceed each document used in the license management systemso the document could be identified as being a document conforming to theprescribed License Document Interchange Format. -57 A document encoded according to this format is represented by a value ofa complex data type called "license document interchange format document" ofLDIFDocument, in this embodiment. A value of this data type represents a singledocument. This self-describing data structure is of the syntax defined in theinternational standard ASN.l referred to above. The X/Open standard referredto above defines the conventions that must be used in employing this syntax, whilethe syntax itself is described in an OSI (Open Systems Interconnect, a standardadministered by ISO) document identified as X.409 (referenced in the X/Opendocument identified herein).

The LDIFDocument data type consists of an ordered sequence of threeelements: the document descriptor, the document header, and the document itself.Each of these elements are in turn composed of other elements. The overallstructure of the LDIFDocument data type will be described, and the nature of thedocument descriptor and document header types. Then, the document contentelements will be described in detail, as well as the various component data typesused in the definition of the descriptor, the header and the content.

The LDIFDocument represents a single license document, with the syntaxbeing shown in Figure 9 and the high-level structure of an LDIF document ingraphical form being seen in Figure 10. The DocumentDescriptor of Figure 9 isa description of the document encoding, the DocumentHeader containsparameters and processing instructions that apply to the document as a whole, andthe DocumentContent is the content of the document, all as explained below.

Referring to Figure 9, what this says is that an LDIFDocument is composedof (::= means "is composed of') a number of elements, the first thing in an -58 LDIFDocument is a bit pattern (tag) according to an international standard,indicating a certain type of document follows, which is indicated here to be"private" or vendor selected, the number 16373 in this case. Following the bitpattern which functions as a "starting delimiter" it is "implicit" that a "sequence"of elements must follow, where a sequence is distinguished from a set. Asequence is one or more of the elements to follow, whereas a set is exactly oneof the elements to be listed. Implicit means that any file identified asLDIFDocument must have a sequence data type, rather than some other type. Inthe case of Figure 9, the sequence is document-descriptor, document header anddocument content; the document-content is mandatory, whereas the first two areoptional. If an element in the sequence begins with a "0" it is a document-descriptor, "1" means a document-header, and ”2" means it is a document-content.Again, it is implicit that the data following is of the format DocumentDescriptor,etc., in each case, and these are defined in Figure 11, Figure 13 and Figure 15.

Each file is in the tag-length-value format mentioned above, and also eachelement of a file containing multiple elements is of the tag-length-value format.The data stream could be examined beginning at any point, and its contentdetermined by first looking for a tag, which will tell what data structure this is,then a length field will say how long it is, then the content will appear. Thesestructures are nested within one another; a document containing several product-use-authorizations would be an LDIFDocument of the format of Figure 9, with anumber of DocumentContent elements of Figure 15 following, with the lengthgiven for the LDIFDocument spanning the several PUAs, and the length given foreach PUA being for the one PUA -59

In Figure 11. the elements major-version and minor-version are seen to be"implicit integer". This means that because the element is of the type major-version, etc., it must be an integer. Various other implicit types are given in othersyntax diagrams, such as character-string, boolean, etc.

In Figure 15. the license body is identified as being of the type "choice"meaning it can be one of PUA, LURT, GroupDefinition, KeyRegistration, etc.Thus, knowing this is a license-body does not mean the data type of the object isknown; it is a bit further where the kind of a license-body becomes known. Thedefintion of a license body is not implicit, but instead is a chioce type.

The contents of the various data elements will now be described in detailwith reference to Figures 11-43. Using these detailed descriptions, the exactformat of each of the elements used in the LDIF can be interpreted.

The license document descriptor or DocumentDescriptor consists of anordered sequence of four elements which specify the version level of the LDIFencoding and identify the software that encoded the document, with the syntaxbeing shown in Figure 11. An example of the way a product called PAKGENVl.O is expressed in the DocumentDescriptor encoding is shown in Figure 12.The fields in the DocumentDescriptor syntax are major-version, minor-version,encoder-identifier and encoder-name. The major-version field is the primaryindicator of compatibility between LDIF processors and the encoding of thepresent document; this major-version field is updated if changes are made to thesystem encoding that are not backward compatible. The minor-version field is therevision number of the system encoding. The encoder-identifier field is aregistered facility mnemonic representing the software that encoded the document; -60- the encoder-identifier can be an acronym or abbreviation for the encoder name -this identifier is constant across versions of the encoder. The encoder-identifiershould be used as a prefix to Named Value Tags in Named Value Lists to identifythe encoder of the named value. The encoder-name field is the name of theproduct that encoded the document; the encoder-name string must contain theversion number of the product.

The document header or DocumentHeader contains data that pertains tothe document as a whole, describing the document to processors that receive it;the syntax is shown in Figure 13. An example of a document header is shown inFigure 14, using the hypothetical product PAKGEN V1.0 of Figure 12. Theprivate-header-data contains the global information about the document that is notcurrently standardized; all interpretations of this information are subject only toprivate agreements between parties concerned, so a processor which does notunderstand private header data may ignore that data. The Title field is the user-visible name of the document. The Author field is the name of the person orpersons responsible for the information content of the document. The Versionfield is the character string used to distinguish this version of the document fromall other versions. The Date filed is the date associated with this document. Notethat the nature and significance of the Title, Author, Version, and Date fields canvary between processing systems.

The content of an LDIF document is represented by a value of a complexdata type called DocumentContent. An element of this type contains one or moreLicenseData content element using a syntax as shown in Figure 15. There are norestrictions on the number, ordering or context of LicenseData elements. Thestructure of a LicenseData element is represented in Figure 16. No restrictions -Gl- are made on the number, ordering, or context of LicenseData elements. Thelicense-data-header field of Figure 16 specifies that data, common to all types oflicense data, which describes the parties to the licensing agreement, the term ofthe agreement, and any constraints that may have been placed on the managementof the license data encoded in the license body. The license-body is an elementthat contains one content element, including: product use authorizations, licenseunit requirements tables, group definitions, key registrations, and various forms ofdelegations. The Management-Info is an element that contains informationconcerning the current state of the license data; this element is not encoded byIssuers.

The license data header, called LicenseDataHeader, is represented as asyntax diagram in Figure 17. The license-id field provides a potentially uniqueidentification of the encoded license data, so issuers of license data can generateunique license-ids to distinguish each issuance of license data; however, thearchitecture does not require this to be the case, since the only architecturalrestriction is that no two objects in any single license management domain mayhave the same value for license-id. The licensee field identifies the party who hasreceived the rights reflected in the license data; there are at least two partiesinvolved in all transfers of license data, first, the issuer of the license data, andsecond, the licensee or recipient of that data - it is anticipated that individuallicensees will specify to those issuing them licenses what the licensee fields ontheir license data should contain, the term field identifies the term during whichthe license data may be used; the validity of license data can be limited by issuersto specific time ranges with given starting and ending dates, which are carried inthe term element - attempts to use license data or products described by that dataeither before the start date or after the end date will result in conforming license -62- managers denying access to the license. Management-constraints identifiesconstraints placed on the right to manage the associated license data: theseconstraints can include (a) limiting the set of contexts permitted to manage thedata, (b) limiting the set of platforms which may benefit from that management,and (c) limiting the right to backup and delegate the managed data. Thesignature provides the digital signature used by the issuer to sign the license dataand identifies the algorithm used in encoding the signature. Issuer-comment is acomment provided by the issuer and associated with the license data.

The IssuerComment is of an informational nature and does not impact theprocess of authorizing product or feature use. This field is not included in thefields used to generate the signature for a license, thus, even if specified by anissuer, the IssuerComment can be omitted from a license without invalidating thelicense. If specified, the IssuerComment should be stored in the appropriatelicense data base with the associated license data. The IssuerComment can beretrieved by products which use the system and may be of particular utility toproducts in the "Software Asset Management" domain which are intended toextend or augment the administrative or accounting facilities or basic systemcomponents. Some examples of potential uses for this field are order information,additional terms and conditions, and support information. For order information,some issuers may wish to include with their loadable license data some indicationof the purchase order or orders which caused the license data to be issued;licensees may find it useful to include this data in their license databases to assistin the license management process. For additional terms and conditions, thesystem will never provide automatic means for the management of all possiblelicense terms and conditions, and so some issuers may wish to include summariesof non-system managed terms and conditions in the comment as a reminder. For -63- support information, the IssuerComment could be used to record the phonenumbers or addresses of the responsible individuals within the issuing organizationwho should be contacted if there are problems with the data as issued. A product use authorization as previously discussed in reference to Figure2 is used to express the issuance of a right to use some product, product feature,or members of some product group. As such, it records the identity of the productfor which use is authorized and specifies the means that will be used by thelicense manager to ensure that the licensee’s actual use conforms to the terms andconditions of the license. Figure 18 illustrates a syntax diagram for aProductUseAuthorization. Product-id identifies the name of the producer of theproduct or product feature of which usage rights are being granted as well as thename of that product; in addition, issuers of product use authorizations mayspecify a range of versions and/or releases whose use is controlled by the specificproduct use authorization. Units-granted - Contains the number of units ofproduct use which are granted by the license. Management-policy defines thepolicy which is to be used in managing the granted software usage rights; thisdefinition specifies the Style, Context-Template, Duration, and License UnitRequirements Determination Method which must be used. The calling-authorizations and caller-authorizations are as explained above in reference tocalling cards. The execution-constraints field identifies constraints placed on thecharacteristics of execution contexts which may be authorized to benefit from theunits granted by this Product Use Authorization. The product-token filed containsproduct specific data not interpreted in any way by any processors conformantwith the architecture; software product producers 28 use this array to augment thecapabilities of conformant license managers. -64-

Some anticipated uses of the token field include language support, detailedfeature authorizations, and product support number. For language support, atoken could be constructed which contains a list of local language interfaceversions whose use is authorized; thus, if a product were available in English, 5 German, French and Spanish, a token could be constructed listing only English and German as the authorized languages. For detailed feature authorizations,some license issuers will wish to have very fine control over the use of features ina complex product; however, they may not wish to issue a large number ofindividual Product Use Authorizations to "turn on" each feature, so these vendors .10 could construct tokens which contain lists of the features authorized or whose use is denied. For product support number, some issuers may wish to include on theproduct use authorization, and thus make available to the running product, someinformation concerning the support procedures for the product; for example, anissuer might include the telephone number of the support center or a support 15 contract number, and the product could be designed to retrieve this data from the license manager and display it as part of Help dialogues.

The LURTs or license use requirements tables of Figure 4 provide ameans by which issuers of licenses, whose LURDM is dependent on the type ofplatform on which the product is run, can store information describing the 20 relationship between the platform type and unit requirements. A syntax diagram for a LURT is shown in Figure 19. In Figure 20, an example of how the LURTof Figure 4 might be encoded is illustrated. Lurt-name specifies the name bywhich the LURT is to be known to conforming license managers. The rows fieldmodels a list of muiticoiumn iurt rows. Platform-id identifies the platform for 25 which this LurtRow provides license unit requirements. The lurt-columns field provides a list of one or more lurt column values; the first value provided is -65- assigned to column* 1 of the lurt-row, the second value provided is assigned tocolumn-, etc. A lurt column value of -1 indicates that use of the product orfeature Is not authorized, while a lurt column value of 0 or greater indicates thenumber of units that must be allocated in order to authorize product use on the 5 platform described by this lurt-row. All unspecified columns (e.g., columns whose number is greater than the number of column values provided in the lurt columnselement) will be considered to contain the value -1.

In reference to Figure 19, to use the row-selector feature mentioned above,the platform-ID element would be replaced with row-selector which would be 10 implicit of Context. Also, in Figure 34 described below, in the lurdm-kind element, row-selector would be included if the row-select feature is to be used.

As discussed above, Figure 4 provides an example of a hypothetical LURT,illustrating the LURT mechanism, where the issuer of this LURT table hasestablished three unit requirement tiers for use in determining the unit 15 requirements for that issuer’s products. Figure 20 provides an example of how the LURT presented in Figure 4 might be encoded. A group definition is used to define and name a license group. Once sodefined, the name of this group can be used on product use authorizations in thesame manner as a product name. Since a single product use authorization 20 specifies the management policy for all members of the group, the members of that group must be compatible in their licensing styles, i.e., a personal use typeproduct can not be mixed with a concurrent use product in the same group.Figure 21 shows a group definition syntax diagram. Group-name is the namewhich must appear on Product Use Authorizations for this group. Group-version -66- specifies the current version of this group; the requirements for matching betweenthe version information on a product use authorization and that on a specifiedgroup definition are the same as those rules which require matching betweenproduce use authorizations and the Release Date data provided by products.Group-members lists those products or features which are components of thenamed group. A key registration is used by a producer 28 or issuer 25 who have beenregistered as authorized license issuers and provided with an appropriate publicand private key pair. The key registration identifies the public key which is to beused by conforming license managers 10 in evaluating signatures 53 created by thenamed issuer 25 or producer 28. A key registration syntax diagram is shown inFigure 22. Key-owner-name provides the name which must be used in either of,or both, of the Producer and Issuer fields of license data generated by the issuer;the key-owner-name must be identical to that specified in the Issuer field of theheader record. Key-algorithm identifies the registered algorithm that is to be usedwhen producing digital signatures with this key. Key-value identifies the publickev. 9

An issuer delegation is typically issued by a producer 28 and authorizes thenamed issuer 25 to issue licenses for products produced by the producer. Anissuer delegation syntax diagram is shown in Figure 23. Delegated-issuer-nameidentifies the name which must appear in the Issuer field of any Product UseAuthorization generated using the License Issuer Delegation. Delegated-product-id identifies the products whose licenses the named issuer is authorized to issue.Delegated-units-granted, if specified, indicates that the use of this IssuerDelegationis to be managed in the style of a consumptive license; the value of this attribute -67- gives the number of units for which license documents may be generated (i.e., ifgranted 1000 units by a Producer, an Issuer can only issue 1000 units.) Template-authorization provides a "template” Product Use Authorization whose attributevalues must be included on any Product Use Authorization generated using thisIssuerDelegation; in the case of attributes which have a scalar value (i.e., Version,Release Date, etc.), the Issuer may issue licenses with more restrictive values thanthose specified on the Template Authorization. Sub-license-permitted indicateswhether the Issuer identified on this IssuerDelegation may issue anIssuerDelegation for the delegated-product-id. A license delegation, as shown in a syntax diagram of Figure 24, is used todelegate the right to manage license data. Such delegations are created by thelicensee (by the license manager), if authorized b.y the issuer 28. A backupdelegation, also shown in Figure 24, is used by one license management facility toauthorize another to manage the delegated rights in the case that the delegatinglicense manager is not running. The delegated-units field specifies the number ofunits whose management is being delegated; this may only be specified when aproduct use authorization is being delegated. Delegation-distribution-controldefines the mechanisms by which the distribution and refreshing of the delegationwill be accomplished. Delegatee-execution-constraints identifies any constraintswhich are placed on the execution-context of the Delegatee; these constraints areapplied in addition to those which are a part of the delegated License Data.Assignment-list identifies any assignments of the delegated units that must berespected by the delegatee. Delegated-data stores a copy of the LicenseDatareceived from the issuer that is the subject of the delegation; the delegated datais not provided when the LicenseDelegation element is included in aDelegationList. -68- 10 15 20

The management information or Managementlnfo element recordsinformation concerning the current state of the License Data with which it isassociated. A syntax diagram of the Managementlnfo element is shown in Figure 25. The assignments field identifies a list of one or more assignments which maybe outstanding for the units on the associated product use authorization.Reservations identifies a list of one or more reservations which may beoutstanding for the units on the associated product use authorization. Delegationsidentifies a list of all outstanding delegations. Backup-delegations identifies alloutstanding backup delegations. the allocations field provides detailedinformation about outstanding allocations which involve units from the associatedproduct use authorization. Registration-date is the date on which the LicenseDatawas registered in the license database. Registrar is the context which caused theLicenseData to be registered. Local-comment is a comment field. Termination-date means a license defined date after which the license data may not be used;this date must be earlier than the end-date specified in the license data’s termrecord. The extended-info field allows additional information concerning the stateof the LicenseData and its handling by the license manager that is notstandardized.

The defined types of elements will now be described. These defined type are:

Allocation

Assignment

Context

DistributionControl

ExecutionConstraints

IntervalTime

ManagementPolicy

Member

NamedValue

NamedValueList

ProductID

Signature 25 -69-

LicenselD

LUDRM

ManagementConstraints

Term

Version

The allocation element records the information concerning a single unitallocation, and is shown in a syntax diagram in Figure 26. Allocation-contextspecifies the context to which the allocation was made. The allocation-lur fieldspecifies the license unit requirement which applies to the allocation-context; thislicense unit requirement is calculated without consideration of any'allocationsharing which may be possible. The allocation-group-id field identifies the"allocation-group" for the current allocation, in which an unshared allocation willalways have an allocation group id of 0; allocations which utilize shared units willhave an allocation group id which is shared by ail other allocations sharing thesame units.

The assignment element is shown in syntax diagram- in Figure 27.Assigned-units identifies the number of units which are assigned. Assignment-term identifies the start and end of the assignment period. Assignee identifies thecontext to which the assignment is made.

The context element is shown in syntax diagram in Figure 28. TheSubContext-type field identifies the type of subcontext, and this type can be eitherstandard or private; if standard, the type value will be taken from the standard-subcontext-type enumeration: (a) network-subcontext means the subcontext valueidentifies a network; (b) execution-domain-subcontext means the subcontext valueis the name of the management domain within which the caller is executing; (d)login-domain-subcontext means the subcontext value is the name of the -70- management domain within which the user of the caller was originallyauthenticated or "logged in"; (d) node-subcontext means the subcontext value isthe name of a node; (e) process-family-subcontext means the subcontext valueis an implementation specific identifier for a group of related processes; (f)process-ID-subcontext means the subcontext value is an implementation specificprocess identifier; (g) user-name-subcontext means the subcontext value is a username; (h) product-name-subcontext means the subcontext value is the same asthe product name found on the Product Use Authorization; (i) operating-system-subcontext means the subcontext value is a character string representation of thename of the operating system; (j) platform-ID-subcontext means the subcontextvalue is an identifier that describes the hardware platform supporting the context.The subcontext-value field is the value of the subcontext.

As discussed above, license data is always used or allocated within, or forthe benefit of, some named licensing context. This context name is constructedby concatenating the values of all subcontexts into a single context name. AContext Template specifies those components of the context name which shouldbe used in calculating license unit requirements. The management systemdetermines the need to perform a unit allocation each time license units arerequested. The full context on whose behalf the allocation should be made isobtained for each requested authorization. The system will mask the full contextto exclude all sub-contexts not specified in the context template and thendetermine if the resulting context already has units allocated to it. If not, unitswill be allocated according to the specification of the LURDM, otherwise, theunits previously allocated will be shared by the new context. Thus, if a givenproduct authorization contains a context specification of NODE + USER_NAME,each context which requests license unit allocations and which has a unique pair -71- of NODE + USER_NAME subcontext values will require an explicit grant oflicense units to be made. On the other hand, any contexts which share the samepair of NODE and USER_NAME subcontext values will be able to "share" asingle allocation of license units. The requirement for specific allocations of unitsand the ability to share units is exhibited in Figure 29 which attempts to providea "snapshot" of the units allocated for the product FOOBAR V4.1 at a particularinstance. It is seen from the figure that although presented with five unique fullcontexts, only four of them are unique when looking only at those portions of eachcontext which are described by the Context Template (ie: NODE +USER_NAME). A unit allocation must be made for each of the four instancesof unique contexts, when masked by the Context Template. The fifth context canshare allocated units with another context. Thus, the total requirement to supportproduct use as described in this example would be 40-units (ie: four allocations often units each). Significant changes in the unit requirements can be achieved bymaking small modifications to the Context Template. Figure 30 shows the samecontexts as in Figure 29 but a Context_Template of NODE. The total unitrequirement for this example would be three units (three allocations of ten unitseach) rather than the forty units required in the previous example.

The distribution control element defines the mechanism that will be usedfor distributing the subject delegation and records some status informationconcerning the distribution of that delegation. A syntax diagram of thedistribution control element is shown in Figure 31. Distribution-method identifiesthe means by which the delegation will be distributed, and the alternatives arerefresh-distribution, initial=distribution-only, and manual-distribution. Refresh-distribution means the license manager shall be responsible for the initialdistribution of the delegation and for ensuring that refresh delegations are -72- properly distributed. Initial-distribution-only means the license manager shall beresponsible for the initial distribution of the delegation, however, distribution ofrefresh delegations will be made by some other means. Manual-distributionmeans the distribution of the delegation will be under the control of some othermechanism (perhaps a license asset manager). Current-start-date is the time thatthe last successful initial or refresh delegation distribution was performed.Current-end-date identifies the last date on which the most recent delegationdistribution was performed. Refresh-interval identifies the period of time betweenattempts to refresh the delegation; the refresh-interval may not be longer than themaximum-delegation-period and should normally be less than that in order toensure that refresh delegations are distributed prior to the expiration of theprevious delegations that they are replacing. Retry-interval identifies the amountof time to wait for an unsuccessful distribution attempt to try again. Maximum-retry-count identifies the maximum number of times that an unsuccessfuldistribution attempt may be retried. Retries-attempted records the number ofunsuccessful retry attempts which have been made since the last successful initialor refresh delegation distribution was performed.

The execution constraints elements place limits on the environments andcontexts which may receive allocations. A syntax diagram of the executionconstraints element is shown in Figure 32. Operating-system contains a list of zeroor more operating systems on which the use of the subject license is authorized;if no operating systems are specified, it is assumed that license use is authorizedon all operating systems. Execution-context specifies a list of zero or more full orpartial context names which identify the contexts within which products describedby the license data may be executed; if no context names are specified, thelicensed products may be executed in any context controlled by the licensee. -73-

Environment-list identifies those environments within which the licensed productmay be used.

The interval time element is defined by the syntax IntervalTime :: =UTCTime.

The license ID element uniquely identifies the license data it is associatedwith, and is described by the syntax diagram of Figure 33. Here issuer uniquelyidentifies the issuer of the license data as well as the name space within which theLicenselD Number is maintained. While the issuer name will typically be thesame as the name of the issuer’s company or personal name, this is not arequirement. For instance: The issuer name for Digital Equipment Corporationis "DEC," an abbreviation of the corporate name. Valid contents of the Issuerfield are maintained in the an Issuer Registry. The serial-number provides aunique identification or serial number for the license data. The amendment fieldis an integer which is incremented each time license data is amended by its issuer,with the first version of any license data carries the amendment number 0; anamendment can only be applied to license data if that license data has identicalIssuer and Number values and an amendment number less than the number of theamendment to be applied.

The license units requirements determination method or LURDM elementis shown in syntax diagram in Figure 34. The combination-permitted fieldindicates whether conforming license managers are permitted to combine togetherinto a common pool the units from different product use authorizations if thoseproduce use authorizations have the same product record value; for example, ifcombination is permitted and a single license manager discovers in its database -74- 1 two 500-unit authorizations for the use of DEC Coboi, the license manager wouldbe permitted to combine these two authorizations into a logical grant of 1000units. The overdraft-limit modifies the behavior of a conforming licensemanagement facility in those cases where it is found that there are zero or fewerlicense units available for use at the time of a request for the allocation orconsumption of additional license units. Operation of overdraft is differentdepending upon whether allocative, or consumptive style is being used. In usingwith allocative style, an allocation is granted even though the remaining units arezero or less, up to the overdraft-limit. In using with consumptive style, the licenseis authorized to accumulate a negative balance of license units, up to theoverdraft-limit. Overdraft-logging-required indicates whether all license grantswhich are the result of overdraft use must cause a log record to be generated.When the allocation-size field is non-zero, then all unit allocations and delegationsmust be made in sizes which are whole number multiples of the allocation-sizevalue. Lurdm-kind identifies the method by which license unit requirements willbe calculated once the requirement for an allocation has been discovered, thepermitted alternatives being (a) LURT which specifies that license unitrequirements are to be determined by lookup in the LURT which is associatedwith the current license, (b) Constant which specifies that license unitrequirements are constant for ail platforms on which the licensed product orproduct feature may run, and (c) Private-LURDM which specifies that license unitrequirements are to be determined by the licensed product, not by the licensemanagement facility. The named-lurt-id specifies the name of the LURT table tobe used in determining license unit requirements if the LURDM-kind is specifiedas LURT; if the LURDM-kind is specified as LURT and no table is explicitlynamed, the name of the. table to be used is constructed from the issuer name onthe product use authorization. Lurdm-value specifies the LURT column to be -75- used' when LURDM-kind = LURT; however, when LURDM-kind = Constant,the Lurdm-value field contains the precise number of units to be allocated orconsumed. Default-unit-requirement specifies the unit requirement value to beused when the appropriate LURT does not have a row corresponding to theappropriate platform ID; when specified on a product use authorization withStyle = Allocative, the context template will change to Process +Product_Specific and the Duration will change to Transaction in cases ofunrecognized Platform ID’s.

The management constraints element is shown in a syntax diagram inFigure 35. The management-context field specifies a list of zero or more partialcontext names which identify the specific contexts within which the license datamay be managed. If no management contexts are specified, the license data maybe managed within any context controlled by the licensee. The contexts used inspecifying Management Context Constraints may only contain the Network,Domain, and Node subcontexts. Specifying a list of management contexts doesnot effect whether or not the license data can be used within other contexts. Forexample, unless otherwise restricted, license data with a specified managementcontext can be remotely accessed from or delegated to other nodes in a network.The management-scope field defines the maximum permitted size of the licensemanagement domain within which the license data may be managed or distributed,these being single-platform, management-domain, or entire-network. Single-platform constrains the license management domain for the subject license datato be no larger than a single platform. Management-domain constrains the licensemanagement domain for the subject license data to be no larger than a singlemanagement domain. Entire-network constrains the license management domainfor the subject license data to be no larger than a single wide area network; that -76- network which contains the platform on which the license units were initiallyloaded. Although technology may not exist to detect the interorganizationalboundaries of a wide area network (i.e., what is on the Internet as opposed tobeing on a company’s own network), the assumption is that interorganization andinternetwork sharing of licenses will normally be considered a violation of licenseterms and conditions. The backup-permitted field indicates if the Issuer hasauthorized the use of backup delegations for this data. Delegation-permittedindicates if the Issuer has authorized the licensee to delegate this data.Maximum-delegation-period identifies the longest interval during which adelegation may be valid; by default, delegations have a life of 72-hours.

The major elements of the management policy specification are shown inFigure 3, as previously discussed. A syntax diagram for the management policyelement is shown in Figure 36. For the Style field, three fundamental styles oflicense management policy are supported, allocative, consumptive, and private-style, as explained above. Only one of these styles may be assigned to any singleproduct use authorization. The Context-template specifies those components (sub-contexts) of the execution-context name which should be used in determining ifunit allocations are required. The Duration defines the duration of an allocationof license units to a specific context or the duration of the period which definesa valid consumptive use. For durations of type "Assignment," the specification ofa Reassignment Constraint is also provided for. Three types of Duration_Kind aresupported, these being Transaction, Assignment and Immediate, as explainedabove. The lur-determination-method stores information used in calculating thenumber of units that should be allocated or consumed in response to a licenserequest. The allocation-sharing-limit identifies the largest number of executioncontexts that may share an allocation made under this management policy; an -77- allocation-sharing-limit of 0 indicates that the number of execution contexts thatmay share an allocation is unlimited. The reassignment-constraint specifies aminimum duration of assignment; although there is normally no constraint placedon how frequently granted units may be reassigned, an issuer may constrainreassignment by specifying this minimum duration of an assignment, in which casereassignment of assigned units will not be supported until the amount of timespecified in the Reassignment Constraint has passed. If an assignment of someparticular set of units has been delegated and the delegation period for thatdelegation has not terminated, cancellation of the delegation must be performedprior to reassignment.

The member element identifies a specific licensed product which may bepart of a calling authorization or group definition, and is shown in syntax diagramin Figure 37. Member-product identifies the product which is a member.Member-signature is constructed from the product and token fields of the calledmember structure as well as the product and issuer fields of the calling product.Member-token provides the data which should be used as the product token forthis member.

Named values are data elements with a character string tag that identifiesthe data element, and have a syntax as shown in Figure 38, which also shows thesyntax for ValueData and named value list. A named value list models a list ofnamed values, with an example being shown in Figure 39. In Figure 38, Value-Name uniquely identifies the value; no standard value names are defined, and theperiod character can be used as a part of the value name to form a hierarchicaltag registry at the discretion of the issuer. Value-data is the data that has beennamed; data types are selected from the possible Value Data types, seen in the -78- i

Figure. Value-boolean means the named data is a boolean value. Value-integermeans the named data is an integer value. Value-text means the named data isa StringList value. Value-general means the named data is a stream of bytes inany format. Value-list means the named data is a list of named data values.

The product ID explicitly identifies the product which is the subject of thelicense data with which it is associated, with the syntax for ProductID being shownin Figure 40. The version and release date fields provide a mechanism fordefining which specific instances of the licensed product are described in theassociated license data. The Producer field is a registered name which identifiesthe producer of the licensed feature; in the case of Group Names, the Produceris always also the Issuer of the group. The Product-name identifies a licensedsoftware feature. The First-version identifies the earliest version of the productwhose use is authorized. The Last-version identifies the latest version of theproduct whose use is authorized. The First-release-date identifies the earliestrelease of the product whose use is authorized. The Last-release-date identifiesthe latest release of the product whose use is authorized. Conforming licensemanagers are required to interpret the contents of these fields in the mostrestrictive way possible. Thus, if a license is issued with Last-version = 3.0 anda Last-release-Date of l-Jan-1991, then the use of version 2.0 of the licensedproduct would be unauthorized if it had a release date of 2-Jan-1991. If either aFirst-version or First-release-date is specified without a matching Last-version orLast-release-date, use of the produce is authorized for all versions or release datesfollowing that specified. Similarly, if either a last-version or Last-release-date isspecified without a matching First-version or First-release-date, use of the produceis assumed to be authorized for all versions or release dates prior to that specified.Issuers should typically only specify one of either First-version or First-release- -79- date. This is the case since it is anticipated that these fields will typically refer toevents which occurred prior to the moment of license data issuance. Thus, itshould normally be possible for the issuer to state unambiguously with only oneof these two fields which is the oldest implementation of the product that is to beauthorized. The architecture does permit, however, both fields to be used in asingle product authorization.

The signature element is used to establish the integrity and authorship ofthe license data with which it is associated. A syntax diagram for the signatureelement is shown in Figure 41. The Signature-algorithm field identifies theregistered algorithm that was used to produce the digital signature. Signature-parameters are the values of the algorithm’s parameters that are to be used; theneed for and syntax of parameters is determined by each individual algorithm.Signature-value is an enciphered summary of the information to which thesignature is appended; the summary is produced by means of a one-way hashfunction, while the enciphering is carried out using the secret key of the signer(Issuer).

The term element defines an interval during which the license data is valid,and is shown in syntax diagram form in Figure 42. The fields are start-date andend-date. Start-date identifies the first date of the term; if not specified, thelicense data is considered valid on any date prior to the end-date. End-dateidentifies the last date of the term; if not specified, the license data is consideredvalid on any date after the Start-date. While the Start-date is always eitheromitted or specified as an absolute date, the End-date can be either absolute orrelative. If the End-date is specified as a relative or "interval" date and the Start-date has been omitted, the date of license registration will be used as the effective -30- start date in computing the valid term of the license data. It should be noted thatthe system does not specify the mechanism by which system dates are maintainedby platforms supporting system components. Instead, the system always acceptsthat system time returned to it as correct. Thus, the reliability of the managementof license data which specifies terms is dependent on the time managementfunction of the underlying platform.

The version element identifies a four-part version of the licensed softwareproduct or feature. A syntax diagram of the version element is shown in Figure 43. The schematics of each of the four parts is not detailed, but it is required thatproducers who wish to permit version ranges to be specified on product useauthorizations ensure that the collating significance of the four parts is maintained.When comparing versions, Part-1 is considered first, then Part-2, then Part-3, andfinally, Part-4. Part-1 identifies a major modification to the versioned object.Part-2 identifies a modification to the versioned object which is less significantthan a modification which would cause a change in the Part-1 value. Part-3identifies a modification to the versioned object which is less significant than amodification which would cause a change in the Part-2 value. Part-4 identifies amodification to the versioned object which is less significant than a modificationwhich would cause a change in the Part-3 value.

FILTERS

An important feature is the use of filters in the license managementprogram 11, including the client interface 31 and the management interface 33.A filter is used is select items in the license database 23, for example. Various -81- selection mechanisms are used in picking out or doing lookups in databasetechnology; filters are one of them. The filter engine used in the licensemanagement system 11 of Figure 1 is generally of a known construction, with theexception of the select filter item type as will be described, which allows acomplex rather than a flat data format to be selected from. The feature that isof importance to this embodiment is the way of specifying items as an input to thefilter function , rather than the filter function itself. Thus, there is describedbelow a template for specifying input to the filter engine. This is as if a formwere used as the input, with blanks on the form; by filing in certain blanks thesewould be the items selected on, the blanks not filled in would be "don’t care".

An instance of the class filter is a basis for selecting or rejecting an objecton the basis of information in that object. At any point in time, a filter has avalue relative to every object - this value is false, true or undefined. The objectis selected if and only if the filter^ value is true. This concrete class has theattributes of its superclass - Object - and the specific attributes listed in the tableof Figure 44. A filter is a collection of simpler filters and elementary filter-items togetherwith a Boolean operation. The filter value is undefined if and only if all thecomponent filters and filter-items are undefined. Otherwise, the filter has a 10 Boolean value with respect to any object, which can be determined by evaluating each of the nested components and combining their values using Booleanoperation (components whose value is undefined or ignored). The attributesspecific to filter as shown in Figure 44 are (a) filter items which are a collection ofassertions, each relating to just one attribute of an object, (b) filters which are a -32- collection of simple filters, and (c) filter type which is the filter’s type, of one of thefollowing values: And, Or, Not.

An instance of the class filter item is a component of a filter. It is anassertion about the existence or values of a single attribute of a license data objector one or its subobjects. This concrete class has the attributes of its superclass -object - and the specific attributes listed in the table of Figure 45.

The value of a filter item is undefined if: (a) the Attribute Types areunknown, or (b) the syntax of the Match Value does not conform to the attributesyntax defined for the attribute type, or (c) a required Attribute is not provided.The attributes specific to filter item as shown in Figure 45 are (a) filter item typewhich identifies the type of filter item and thereby the nature of the filter, and itsvalue must be one of equalityinequalitygreater or equalless or equalgreater less present select request candidatessimulate request (b) attribute type which identifies the type of that attribute whose value orpresence is to be tested; the value of All Attributes may be specified, (c) matchvalue which is the value which is to be matched against the value of the attribute,(d) filter which identifies the filter to be used in evaluating a selected subobjectof the current object; the filter is ignored if the filter item type is not select or if thespecified attribute type is not present in the object, and upon evaluation of thefilter the value of filter item will be set to that of the filter, (e) initial substring, ifpresent, this is the substring to compare against the initial portion of the value of -83- the specified attribute type, (f) substring, if present, this is the substring(s) tocompare against all substrings of the value of the specified attribute type, (g) finalsubstring, if present, this is the substring to compare against the final portion of thevalue of the specified attribute type, and (h) license request, if present, this islicense request against which the appropriate license data objects should beevaluated; this attribute may only be specified if the value of the filter item typeis either Request Candidates or Simulate Request.

An instance of enumeration syntax Filter Type identifies the type of a filter.Its value is chosen from one of the following; (a) And means the filter is thelogical conjunction of its components; the filter is true unless any of the nestedfilters or filter items is false, or if there are no nested components, the filter istrue; (b) Or means the filter is the logical disjunction of its components; the filteris false unless arty of the nested filters or filter items is true, or, if there are nonested components, the filter is false; (c) Not means the result of the filter isreversed; there must be exactly one nested filter or filter item, and the filter istrue if the enclosed filter or filter item is false, and is false if the enclosed filteror filter item is true.

An instance of enumeration syntax Filter Item Type identifies the type of afilter item. Its value is chosen from one of the following; (a) Equality whichmeans the filter item is true if the object contains at least one attribute of thespecified type whose value is equal to that specified by Match Value (accordingto the equality matching rule in force), and false otherwise; (b) Inequality whichmeans the filter item is true if the object contains at least one attribute of thespecified type whose value is not equal to that specified by Match Value(according to the equality matching rule in force), and false otherwise; (c) Greater -84- or Equal which means the filter item is true if the object contains at least oneattribute of the specified type whose value is equal to or greater than the valuespecified by Match Value (according to the matching rule in force), and falseotherwise; (d) Less or Equal which means the filter item is true if the objectcontains at least one attribute of the specified type whose value is equal or lessthan the value specified by Match Value (according to the matching rule in force),and false otherwise; (e) Greater which means the filter item is true if the objectcontains at least one attribute of the specified type whose value is greater than thevalue specified by Match Value (according to the matching rule in force), andfalse otherwise; (f) Less which means the filter is true if the object contains atleast one attribute of the specified type, whose value is less than the valuespecified by Match Value (according to the matching rule in force),and falseotherwise; (g) Present which means the filter item is true if the object contains atleast one attribute of the specified type, and false otherwise; (h) Select whichmeans the filter item is true if the object contains at least one attribute of thespecified type which has an object syntax and when the Filter is evaluated againstthe attributes of that object the Filter is true, and false otherwise; (i) RequestCandidates which means the filter item is true if the object against which it isevaluated is one which could be used to provide some or all of the units requestedby the specified License Request; the evaluation is made independently of anyoutstanding allocations or preallocations; and (j) Simulate Request which meansthe filter item is true if the object against which it is evaluated is one which wouldbe used to provide some or all of the units requested by the specified LicenseRequest.

The Request Candidates and Simulate Request filter item types are ofspecial use in testing and prototyping of systems by a license manager at a -35- licensee’s site. For example, the license manager can simulate the effect ofpotential assignments, the effect of a population of certain types on a network, etc.

As an example, Figure 46 shows how a filter may be constructed to identify"All Product Use Authorizations issued by Digital for the Product ’AmazingGraphics System’ which contains a calling authorization for Digital’s ’AmazingDatabase' Product". This example is in the international standard format referredto as X.409 as mentioned above.

Filters can also used in a request allocation, being specified in a requestextension as explained above. That is, a filter is one of the optional items in arequest extension. For example, if a user wanted to use a version of WordPerfectwith French language extension, and there were version with and without on thenetwork, his request allocation would have a request extension that specified afilter for "French" in the token field. In this manner, a product can describe itselfmore richly. The filter in the request extension can be a Required filter or aPreferred filter, meaning the feature such as "French" is either absolutelynecessary, or merely the preferred.

While this invention has been described with reference to specific embodi-ments, this description is not meant to be construed in a limiting sense. Variousmodifications of the disclosed embodiments, as well as other embodiments of theinvention, will be apparent to persons skilled in the art upon reference to thisdescription. It is therefore contemplated that the appended claims will cover anysuch modifications or embodiments as fall within the true scope of the invention.