`
`Ex. 1012
`EX. 1012
`
`US Patent No. 5,905,860 (“Olsen”)
`US Patent No. 5,905,860 (“Olsen”)
`
`
`
`
`
`

`

`United States Patent [19]
`Olsen et al.
`
`US005905860A
`[11] Patent Number:
`[45] Date of Patent:
`
`5,905,860
`May 18, 1999
`
`[54] FAULT TOLERANTELECTRONIC
`LICENSING SYSTEM
`
`e
`
`22–~ * >
`
`a??lSOIl .....................................
`
`-
`-
`[73] Assignee: Novell, Inc., Provo, Utah
`
`-
`
`-
`
`-
`
`-
`
`ustralia .
`
`[56]
`
`5,222,134 6/1993 Waite et al. ................................ 380/4
`5,260,999 11/1993 Wyman ....
`... 380/4
`5,265,065 11/1993 Turtle ..............
`... 707/4
`[75] Inventors: James E. Olsen, Park City; Adam L. ; º: º et al. … sº
`Bringhurst, Provo, both of Utah
`5,319,705 6/1994 Halter et al. .
`... 380/4
`5,343,526 8/1994 Lassers .....
`... 380/4
`5,343,527 8/1994 Moore ......
`... 380/4
`5,349,642 9/1994 Kingdon ...
`... 380/25
`5,371,792 12/1994 Asai et al. .................................. 380/3
`[21] Appl. No.: 08/804,936
`5,375,206 12/1994 Hunter et al.
`. 395/712
`-
`5,386,369
`1/1995 Christiano ...
`... 705/400
`[22] Filed:
`Feb. 24, 1997
`5,438,508 8/1995 Wyman ....................................... 705/8
`- -
`-
`5,553,143 9/1996 Ross ................
`... 380/25
`Related U.S. Application Data
`5,675,782 10/1997 Montague et al. ...................... 395/609
`5,689,638 11/1997 Sadovsky ........................... 395/188.01
`[63) Continuation-in-part of application No. 08/620,319, Mar.
`15, 1996, Pat. No. 5,758,069.
`FOREIGN PATENT DOCUMENTS
`
`[51] Int. Cl." … H04L 9/00 A-38209/93 4/1993 Australi
`[52] U.S. Cl. ............... 395/187.01; 395/186; wº A-48113/93 3/1994 Australia .
`e
`/
`WO 89/04520 5/1989 WIPO .
`[58] Field of Search ............................... 395/187,01, 186,
`WO 92/20021 11/1992 WIPO .
`395/200.57; 380/3. 4
`/
`; 380/3,
`Primary Examiner—Ly Hua
`Attorney, Agent, or Firm—Dinsmore & Shohl LLP
`References Cited
`U.S. PATENT DOCUMENTS
`[57]
`ABSTRACT
`4,870,568 9/1989 Kahle et al. ................................ 707's
`Alicensing system provides enhanced flexibility for licens
`4924.37s 5/1990 Hershey ....
`... 395/187.01
`ing applications in a network. The licensing system includes
`4,937,863 6/1990 Robert et al. ............................... 380/4
`a directory services database which stores all license infor
`4,941,175
`7/1990 Enescu et al. ....
`.... 380/4
`mation. The directory services database is accessed by
`5,023.907
`6/1991 Johnson et al. ...
`.... 380/4
`providing a request to a license service provider associated
`5,047,928 9/1991 Wiedemer ................................... 380/4
`with a server. The license service provider generates an
`º; 3/1992 Burger et º --------------------------- 395/500
`executable entity based on the request parameters, which
`,103,476 41992 Waite et al. ................…. 380/4
`searches the database and, if the appropriate units are
`5,138,712 8/1992 Corbin ..........
`... 395/186
`-
`-
`-
`-
`5,157,663 10/1992 Major et al. .............................. 380/25
`available, assembles a license. The license and the applica
`5,182,770
`1/1993 Medveczky et al. ....................... 380.4
`tion are then transmitted to the requesting client. All aspects
`5,187,770 2/1993 Mishima et al. ........................ 385/145
`of the transaction are also stored in a database organized
`5,201,046 4/1993 Goldberg et al. .
`... 707/100
`according to a transaction’s relation to a particular license.
`5,201,048 4/1993 Coulter et al. ....
`... 707/3
`5,204.897 4/1993 Wyman ....................................... 380/4
`
`22 Claims, 5 Drawing Sheets
`
`
`
`NOWELL DIRECTORY SERVICES
`112
`
`
`
`NDS
`DATABASE
`
`
`
`
`
`LICENSE SERVICE PROVIDER
`NETWARE ARE NLM)
`
`LCENSE
`TRANSACTION
`DATABASE
`
`L/
`
`NCP EXTENSIONS
`COMMUNICATIONS
`(EXISTING CONNECTION]
`
`
`
`|CENSING SERVICE CLIENT
`(DOS, WN 3X. WN95, NETWARENLM)
`
`

`

`U.S. Patent
`
`May 18, 1999
`
`Sheet 1 of 5
`
`5,905,860
`
`1OO
``s
`
`102-2”
`
`1O4.
`
`SERVER
`
`
`
`CLENT
`
`1O(3
`
`1O(3
`
`FIG. 1A
`
`11O
`LSP
`SERVER
`
`1O4
`
`
`
`
`
`CLENT
`ACQ MNG
`AP1 | A/
`
`1O3
`
`NOWELL DIRECTORY SERVICES
`112
`
`NDS
`DATABASE
`
`1OO
`
``s
`
`1O4.
`
`LICENSE SERVICE PROVIDER
`(NETWARE ARENLM)
`
`
`
`
`
`
`
`
`
`
`
`
`
`|CENSE
`TRANSACTION
`DATABASE
`
`10& NINCPEXTENSIONS
`COMMUNICATIONS
`(EXISTING CONNECTION)
`
`
`
`LICENSING SERVICE CLIENT
`(DOS, WN 3X. WN95, NETWARENLM)
`
`FIG. 1B
`
`

`

`U.S. Patent
`
`May 18, 1999
`
`Sheet 2 of 5
`
`5,905,860
`
`11C)
`
`
`
`2O2
`
`NCP HANDLER CODE (NCPEXTENSION ENTRYPOINT)
`
`REQUEST DIRECTION
`OF CODE
`
`SERVERSTUBS (LSAP AND NLSAP)
`
`2O4.
`
`ENGINE CODE|MAPSFUNCTIONAL TO OBJECT REQUESTS)
`
`2O6
`
`CERTIFICATE
`OBJECT
`
`CERTIFICATE
`DATABASE
`OBJECT
`
`HANDLE
`OBJECT
`
`2O3,
`
`LIST
`OBJECT
`
`91O
`
`TRANSACTION
`DATABASE
`OBJECT
`
`REPLY DIRECTION
`OF CODE
`
`908,
`FIG. 2
`
`3O2
`
`// 3O8,
`
`3O4.
`
`
`
`|DENTIFIER
`
`
`
`3O6
`
`DATA
`LENGTH
`
`DATA
`
`DTLENGTHDAADTENGTHDAIATDTENGTH
`O
`306A zoea
`306P 232B
`306C
`
`

`

`U.S. Patent
`
`May 18, 1999
`
`Sheet 3 of 5
`
`5,905,860
`
`400
``, NDS TREE EXAMPLE
`
`
`
`UTAH
`
`ENGINEERING
`
`MARKETING
`
`ENGINEER?NG
`
`MARKETING
`
`4O4.
`
`
`
`
`
`|NITIATE
`504-i?ºs
`
`F|G. 4.
`
`5OO
`
`
`
`DIRECTORY
`SERVICE
`
`
`
`Y
`aO2, | SCAN CURRENT
`CONTAINER
`
`
`
`
`
`
`
`AT
`ROOT:
`
`513
`
`Y
`
`514.
`
`SELECT
`PARENT
`CONTAINER
`
`RETURN | B10
`ERROR
`
`FIG. 5
`
`

`

`U.S. Patent
`
`May 18, 1999
`
`Sheet 4 of 5
`
`5,905,860
`
`LSAP
`CODE
`
`902 CONSTRUCTOR
`CONSTRUCTOR
`DESTRUCTOR
`DESTRUCTOR
`PT LICENSE HANDLE [E] CERTIFICATE
`PUBLIC OBJECT
`PUBLIC OBJECT* |
`OBJECT
`METHODS
`METHODS
`
`904.
`
`L
`
`NLSAP
`PROCEDURAL
`CODE
`
`91O CONSIROIR,
`DESTRUCTOR
`C
`PUBLCOBECT
`METHODS
`
`CONSTRUCTOR
`DESTRUCTOR
`&— us
`|- OBJECT
`PUBLIC OBJECT
`METHODS
`
`906
`
`CERTIFICATE
`OBJECT
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CONSTRUCTOR
`DESTRUCTOR
`
`PUBLIC OBJECT
`METHODS
`
`
`
`908,
`
`TRANSACTION
`DATABASE
`OBJECT
`
`
`
`DATABASE
`OBJECT
`
`912
`
`FIG. (3
`
`CREATE LICENSE
`CERTIFICATE OBJECT
`
`7OO
`
`WRITE LICENSE CERTIFICATE
`|NTO BUFFER FORMAT | 7O2
`
`STORE BUFFER NLICENSE
`CERTIFICATE DATABASE
`
`END
`FIG. 7
`
`

`

`U.S. Patent
`
`May 18, 1999
`
`Sheet 5 of 5
`
`5,905,860
`
`/*
`
`START
`
`SFIECTAFEICATIONTL-802
`
`CLIENT
`
`U
`
`3O4.
`
`ERRL "
`&O(3
`
`Y
`ASSEMBEANDTRANSWTREQUESTL-808
`
`RECEIVE ANDDECODEREQUESTL-810
`
`CREATE TRANSACTION OBJANDUCENSE HANDLE OBJL-8512
`
`CREATECFRTFICATEDATABASFORFCTL-814
`
`&16-NTSEARCHICURRENTCONIANER
`
`826-NTCREATETCENSECHRTFICATEGEECTS
`
`319
`
`32O
`
`Y
`
`SELECT NEXT OU AND SEARCH
`
`LøP {
`
`N
`
`N
`
`932
`
`Y
`CONSUME LICENSE UNITS
`
`Y 922
`
`ERROR
`
`933
`
`Y
`TRANSMT HANDLE TO CLIENT
`
`939,
`
`\-
`
`END
`
`F|G. 9A-5
`
`

`

`1
`FAULT TOLERANTELECTRONIC
`LICENSING SYSTEM
`
`CROSS-REFERENCES TO RELATED
`APPLICATIONS
`This is a continuation-in-part of U.S. patent application
`No. 08/620,319, filed Mar. 15, 1996, now U.S. Pat. No.
`5,758,069.
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`The invention relates to licensing software, and more
`particularly, to licensing software electronically in a network
`environment.
`2. Description of the Related Art
`Most software vendors currently favor licensing as the
`preferred method of distributing software. Licensing soft
`ware provides the vendor with a certain amount of control
`which may be used to the vendor’s advantage. For example,
`licensing software allows the vendor to prohibit unautho
`rized usage of the software that might facilitate unauthorized
`copying. In addition, licensing provides an advantageous
`method of providing and billing for software. Through
`licensing, the vendor may sell several identical copies of the
`same software and charge the buyer for each copy.
`Licensing schemes have been adapted for the network
`environment as well as the individual personal computer. In
`a network environment, such as a client-server network,
`multiple users may access the same copy of a particular
`application. Consequently, the vendor can charge the net
`work owner not for the number of copies installed on the
`network, but for the number of users having access to the
`software.
`Software is conventionally licensed using an agreement
`between the vendor and the user or administrator. The
`agreement is typically either a conventionally signed con
`tract or a “shrink wrap” agreement attached to the packaging
`for the software, to which the licensee acknowledges agree
`ment by opening the package.
`Although traditional and shrink wrap licensing are more
`or less applicable to individual systems, they are not well
`suited to the network environment. Both traditional and
`shrink wrap licensing schemes are difficult to enforce on a
`network where several users have access to the software.
`Consequently, various electronic systems have been devised
`for controlling access to software on a network.
`Electronic licensing typically comprises providing a set of
`criteria under which a request for an application from the
`server should be granted. One common licensing system
`uses a fixed set of licenses controlled by a license server. The
`license information is maintained in a license database,
`along with information regarding which applications are in
`use and how many units are still available. The information
`in the database may be encrypted to prevent forgeries. When
`an application is desired, the application commences run
`ning. Code embedded in the application initially requests a
`license from the server to facilitate the execution of the
`application. The server checks the database of licenses, and
`if the appropriate licenses are available, grants the request.
`As requests are received and licenses granted, the relevant
`information is logged into a file to track usage of the various
`applications.
`If a license is not available, the client contacts another
`server to find the appropriate license. The client in the
`conventional system has the responsibility to obtain licenses
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`5,905,860
`
`2
`from the various servers, and the individual servers provide
`resources at the client’s request. To facilitate such licensing,
`the application typically includes a library of programs
`designed to contact the server, request a license, and track
`the resulting license.
`Although such a licensing system provides some security
`against unauthorized usage of applications, it suffers several
`drawbacks. For example, the number of programs required
`for the client to request and maintain licenses occupies a
`significant portion of the client’s limited memory resources.
`Further, a conventional licensing system stores most of the
`licensing information in the client’s memory. Consequently,
`in the event of a client crash, the licensing information is lost
`and difficult to reconstruct.
`Conventional licensing systems also suffer limited scal
`ability. When a call is made to a server, all of the execution
`occurs on each individual server for any particular call.
`Similarly, if a license is located on a particular machine, all
`execution necessary to operate on that license occurs on that
`machine. Consequently, a central server containing most of
`the licenses available on a particular network may be
`overworked while other, more local server resources remain
`idle. Similarly, if any particular server crashes or otherwise
`becomes unavailable, none of the licensing information
`associated with that server can be accessed by clients, even
`if other servers are operating.
`In addition, conventional licensing systems rely on code
`embedded in the application to establish the licensing
`attributes. Code is placed in the application which interprets
`information received from the server to establish licensing
`parameters. Because the behavior of the license is not
`established until after the request has been made and the
`license obtained, the user cannot read the license terms prior
`to the request. Moreover, this system lacks flexibility. To
`change the licensing terms, the code in the application must
`be revised.
`An electronic software licensing system is thus needed
`which overcomes the shortcomings of the prior art.
`SUMMARY OF THE INVENTION
`An electronic licensing system according to various
`aspects of the present invention provides alternative meth
`ods and apparatus for licensing software in a network
`environment. License information is suitably stored in a
`distributed database among several servers. In the preferred
`embodiment, the license information is stored and accessed
`in conjunction with a directory service, such as Novell
`Directory Services (NDS). The license information may be
`coupled with any suitable attributes to create a desired
`licensing policy. Clients are equipped with a suitable library
`of application programming interfaces (APIs) for acquiring
`and managing licenses. To request an application, the client
`assembles a request having the desired license criteria, such
`as the publisher, product, version, and number of license
`units. This information is provided with other relevant
`information, such as the user’s name.
`When the request for a license to an application is
`received by a local server, the server uses the directory
`service to locate license information which satisfies the
`request criteria. If the requested license information is
`available to the requesting client, a license service provider
`(LSP) constructs a license certificate object and collects that
`information into the license certificate object. If the license
`units are available to grant the request, the information in the
`directory services database is then adjusted to reflect the
`granting of the license. The directory services system then
`
`

`

`3
`suitably replicates the data according to a corresponding
`partitioning and replicating scheme to maintain the integrity
`of the licensing information.
`In a system according to a preferred embodiment of the
`present invention, most of the license transactions occur at
`the servers; the client merely bundles the arguments for a
`license request and transmits them to the server.
`Consequently, the client resources required for the license
`system are relatively small.
`In accordance with a further aspect of the present
`invention, recoverability of the system is enhanced. To
`anticipate a client crash, the client only needs to store a
`license handle associated with the license request. The
`remaining information is stored in the server database, and
`may be reestablished by finding the particular transaction
`associated with the license handle in the NDS database.
`Further, a licensing system according to various aspects of
`the present invention is highly fault tolerant in the event of
`a server crash. Because the directory services system auto
`matically replicates licensing information among various
`servers, license information associated with a particular
`server is not lost or unavailable if the server fails. Instead,
`the information may be retrieved from another server which
`has received a replica of the licensing information.
`In accordance with yet a further aspect of the present
`invention, licensing flexibility is also enhanced. The licens
`ing criteria may be adjusted by revising the contents of the
`NDS database and the client APIs. Because the application
`requires no particular code to facilitate licensing, recompi
`lation or re-linking of the application binaries is unnecessary
`to change the licensing attributes. In addition, the structure
`of the database and the APIs facilitates the use of uncon
`ventional licensing modes by applying various different
`criteria to the license information in the database and the
`license request. Further, the distributed nature of the data
`base provides enhanced scalability and allows several serv
`ers to be searched with a single request from the client.
`BRIEF DESCRIPTION OF THE DRAWING
`FIGURES
`The subject matter of the invention is particularly pointed
`out and distinctly claimed in the concluding portion of the
`specification. The invention, however, both as to organiza
`tion and method of operation, may best be understood by
`reference to the following description taken in conjunction
`with the claims and the accompanying drawing, in which:
`FIGS. 1A–B are a block diagrams of a network according
`to various aspects of the present invention;
`FIG. 2 is a block diagram of the LSP of FIG. 1;
`FIG. 3 is a diagram of the organization of a license record
`object;
`FIG. 4 is a block diagram illustrating an example con
`figuration of a network serviced by a directory service;
`FIG. 5 is a flow diagram of a process for a client to locate
`an LSP;
`FIG. 6 is a block diagram of a series of implementation
`objects generated in response to requests;
`FIG. 7 is a flow diagram of a process for installing a
`license in the license certificate database; and
`FIGS. 8A-B comprise a flow diagram of a process for
`requesting and generating a license for an application.
`DETAILED DESCRIPTION OF PREFERRED
`EXEMPLARY EMBODIMENTS
`A licensing system according to various aspects of the
`present invention provides a flexible, robust, and fault
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`5,905,860
`
`4
`tolerant licensing apparatus and method for licensing soft
`ware in a network. Referring now to FIGS. 1A and 1B, a
`licensing system 100 according to various aspects of the
`present invention suitably includes a network 102 compris
`ing a plurality of servers 104, at least one client 106, and a
`communications system (e.g., a network bus) 108. Each
`server 104 suitably comprises a high-speed computer oper
`ating on a network operating system, such as a Novell
`NetWare server operating system. Any suitable operating
`system, however, may be utilized in accordance with the
`present invention.
`The network 102 is suitably configured for distributed
`processing and to accommodate a directory services system.
`In a preferred embodiment, the directory services system
`comprises a multiple-platform, distributed network direc
`tory service, for example NOVELL DIRECTORY SER
`VICESTM (NDSTM) 103, which provides global access to
`network resources regardless of where the resources reside.
`NDS 103 includes a global, distributed information system
`that maintains information about every resource associated
`with a network, including users, groups, printers, volumes,
`and other devices. The information is preferably organized
`as a collection of objects, each object representing a par
`ticular device, module, application, file, or the like. Infor
`mation relating to the various resources may be organized
`and presented to the administrator in a hierarchical tree
`structure. For example, referring now to FIG. 4, a tree
`structure 400 may be organized into a series of branches 402,
`sub-branches 404, and so on, which may correspond to
`particular user groups, device types, geographical location,
`or other suitable classifications. Similarly, the sub-groups
`may, in turn, be organized by dividing and sub-dividing
`resources into individual branches as may be convenient.
`Each group, sub-group, or the like is typically referred to as
`a particular context, container, organizational unit, or the
`like according to the particular configuration of the network
`102.
`NDS 103 provides a host of functions in conjunction with
`a licensing system according to various aspects of the
`present invention, including, for example, organization,
`location, and replication of various components. NDS 103
`allows the network 102 to be organized in a logical manner
`for administration, applications sharing, document sharing,
`and the like. The directory service organization may further
`be used to control and facilitate searching for license infor
`mation by the various LSPs 110, as described in greater
`detail below.
`In the present embodiment, the directory services system
`suitably includes a distributed database 112. The NDS
`database 112 is configured to automatically replicate infor
`mation in the NDS database 112 and store the replicated
`versions at alternative locations in the NDS database 112.
`Replication of the information in the NDS database 112,
`including the license information, provides fault tolerant
`login, administration, and licensing services. More
`particularly, the NDS database 112 is typically separated into
`multiple distributed sections, known as partitions, which are
`distributed across the network 102. NDS partitions are
`replicated and updated among various memory locations
`within the network 102 according to pre-selected procedures
`as many times as may be necessary or desirable to provide
`effective fault tolerance. The NDS system 103 automatically
`updates information across the network 102 as data associ
`ated with a particular partition is modified. Thus, if a
`primary partition is lost due to a server crash or other cause,
`the NDS system 103 automatically reconfigures itself to use
`an alternate copy. It should be noted, however, that the
`
`

`

`5
`replication process of the NDS system 103 may be limited
`or controlled to optimize the efficiency of the licensing
`system. For example, servers that do not include an LSP or
`otherwise provide licensing services may not need to repli
`cate license-related data.
`In the present embodiment, at least one of the servers 104
`has access to the NDS database 112, which is suitably
`managed by NDS 103. In particular, NDS database 112
`stores all of the information relating to the various licenses
`available via the LSPs 110. The license information in the
`NDS database 112 is suitably organized into license record
`objects, each of which suitably contains a license certificate
`supplied by a vendor or other installer along with additional
`information relating to, for example, the location of assign
`ment information and user information.
`In the preferred embodiment, two extensions are used to
`provide infrastructure for creating and maintaining stored
`license record objects, a product schema extension and a
`certificate schema extension. The product schema extension
`provides a reference mechanism for locating license record
`objects, and suitably corresponds a series of attributes, for
`example corresponding to the publisher, product, and ver
`sion of a licensed application. The productschema extension
`may be located within a particular organization or organi
`zational unit in the NDS system 103 to organize similar or
`related license record objects in the organization or organi
`zational unit.
`The certificate schema extension corresponds to indi
`vidual stored license record objects. An instance of a license
`record object subject to a certificate schema extension only
`exists within product container subject to a product schema
`extension. All of the license record objects associated with
`a particular application version and located in an organiza
`tional unit, for example, are suitably associated with a single
`product container. Associating various license record objects
`with product containers facilitates searching for license units
`without examining every object in the organizational unit.
`The license certificate is stored in the license record object
`in a block copy fashion, so that all of the data and structure
`of the certificate are preserved. The license information
`stored in directory services database 112 is suitably stored in
`a format common to each license record object. Additional
`memory space is also suitably provided for information
`required by licensing system 100. For example, memory
`space may be provided for entry of information relating to
`the user, license handle, number of license units consumed,
`the last time of update, assignment, and owner. Each license
`record object is suitably extendable by adding additional
`identifiers that may be recognized by executable license
`certificate objects.
`Referring now to FIG. 3, a suitable format for a license
`record object 302 comprises an identifier field 304, a data
`length field 306, and a data field 308. A suitable identifier is
`stored in identifier field 304, for example to identify the
`nature of the license record object 302. Data length field 306
`describes the length of data field 308, suitably in bytes. Data
`length field 306 suitably comprises a four byte number, for
`example in little endian format. Data length field 306 may be
`read to determine where the current license record object
`302 ends and where the next license record object 302
`begins.
`Data field 308 suitably contains information specific to
`the license. Data field 308 is formatted in any suitable
`manner to be compatible with licensing system 100. In
`particular, data field 308 suitably contains nested sets of
`identifiers, data length fields, and data fields for various
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`5,905,860
`
`6
`characteristics and variables associated with the license
`record object. For example, each entry in the data field
`suitably includes an identifier 304A–C which indicates the
`type of information in the entry, e.g. an error attribute,
`ownership data, etc. A data length field 306 A–B indicates
`the length of the entry, and a data field 308A-B includes the
`actual information. The format may suitably be determined
`according to a portion of the identifier, so that if licensing
`system 100 does not recognize the relevant portion of
`identifier field 304, data field 308 is ignored. The informa
`tion stored in data field 308 is provided by license installa
`tion or creation, as described further below.
`The data fields 308 suitably include both static and
`dynamic portions. The static portions are set once when the
`license record object is installed on the directory services
`database 112 and remain unchanged for the duration of the
`license. The dynamic portion may be changed as the license
`certificate is utilized and thus manipulated.
`In the preferred embodiment, the dynamic and static
`portions are suitably stored in a single multi-valued
`attribute. The static portion includes the actual license
`certificate binary in its original form. Storage of the original
`binary facilitates authentication mechanisms employed by
`the licensing system and/or the associated application.
`Because information is typically only added to the record to
`describe units in use, i.e. in the dynamic portion, unautho
`rized manipulation of the license certificate is inhibited. The
`dynamic portion of the license record object stores infor
`mation relating to its current state, which allows the object
`to be modified and transmit the modifications to the next
`process using the license record object. This allows certain
`values in the object to be manipulated without affecting the
`other values.
`At least one server 104, and preferably multiple servers
`104, further includes an LSP 110 for performing license
`transactions. LSP 110 performs several licensing functions,
`for example receiving requests from clients 106 and main
`taining and searching the NDS database 112. LSP 110 is
`implemented in any suitable manner, for example in
`software, suitably comprising a NetWare Loadable Module
`in the operating system.
`Referring now to FIG. 2, LSP 110 suitably comprises a
`NetWare Core Protocol (NCP) Extension Entry Point code,
`which is referred to as the NCP handler 202; a server stubs
`module 204; an engine code 206; and a plurality of imple
`mentation objects 208, which may be generated, stored, and
`destroyed as necessary by the LSP 110 to fulfill its functions.
`The NCP handler 202 receives messages from clients relat
`ing to various licensing functions. To handle multiple
`messages, the NCP handler 202 suitably processes several
`requests concurrently. NCP handler 202 notes the message
`contents, as well as the source of the message to establish a
`return location. To initiate fulfillment of the request, the NCP
`handler 202 transfers control of the request to the server
`stubs module 204 or to a queue to await processing.
`The request is sent to the server stubs module 204 with the
`request information and the client information received from
`the client 106. The server stubs module 204 dissects the
`information received from the NCP handler 202, initially
`determines which particular function is requested, and con
`verts the message into an appropriate format for the other
`components of the server 104. Based on the type of
`transaction, the server stubs module 204 then parses out the
`appropriate arguments from the message and transfers the
`results to the engine code 206.
`The server stubs module 204 may perform different tasks
`according to the type of request received. For example, the
`
`

`

`25
`
`7
`server stubs module 204 suitably includes at least two
`sections for parsing client requests in the present embodi
`ment. A first section parses functions in the LSAPI, which is
`submitted by the client 106 for requesting licenses. A second
`section parses functions located in the NLSAPI, which is
`suitably submitted for managing licenses.
`When the engine code 206 receives the results from the
`server stubs module 204, the engine code 206 first checks all
`arguments for validity, and if any arguments fail, returns a
`rejection message to the client 106. If the arguments are
`valid, the engine code 206 translates the arguments from the
`particular functional request for licenses or information into
`an appropriate implementation object 208. In addition, the
`engine code 206 translates results from an implementation
`object 208 and returns the appropriate error codes or other
`information to the client 106.
`The implementation objects 208 are suitably initiated by
`the engine code 206 and create, locate, obtain, and manipu
`late license record objects in the NDS database 112. The
`implementation objects 208 may further include objects for
`tracking license transactions and keeping records. For
`example, referring now to FIG. 6, the implementation
`objects 208 suitably include a license handle object 902, a
`certificate database object 904, a license certificate object
`906, and a transaction database object 908.
`Upon receipt of a license request, for example an LSAPI,
`the engine code 206 suitably generates a license handle
`object 902. The license handle object 902 functions as an
`object representation of the functionality of the request.
`Further, the license handle object 902 assigns a unique
`identifier to the request for identification and record keeping
`purposes.
`The certificate database object 904 uses the information
`from the engine code 206 to find license record objects
`conforming to the request criteria. For example, the certifi
`cate database object 904 suitably receives a combination of
`publisher name, product name, version, and license handle.
`After the certificate database object 904 has been created, it
`may be used to search through license record objects in the
`NDS database 112 or to retrieve specific license record
`objects. The certificate database object 904 retrieves the
`necessary information from the NDS database 112 and
`passes the binary state information to the constructor of the
`license certificate object 906. The certificate database object
`904 provides access to the license record objects without
`regard to the underlying certificates’ policy attributes.
`To access the NDS database 112 and perform various
`functions, LSP 110 suitably assembles a license certificate
`object 906 for any particular license record object installed
`in the NDS database 112. The license certificate object 906
`provides for all of the basic manipulation of a single license
`record object. A license certificate object 906 suitably com
`prises code for performing various functions within the NDS
`database 112, such as adding, removing, requesting, and
`55
`releasing a license certificate. In addition, the license cer
`tificate object 906 suitably provides information regarding
`the corresponding license record object and its state. For
`example, based on the user information or a license handle,
`the certificate database object 904 suitably locates the cor
`responding license record object and constructs a license
`certificate object, which transmits information relating to the
`current users, number of units in use, identifier information,
`default update period, ownership information, and the like to
`the requesting client 106.
`The license certificate object 906 also suitably performs
`various license management functions in response to an
`
`35
`
`40
`
`45
`
`50
`
`60
`
`65
`
`5,905,860
`
`10
`
`15
`
`20
`
`30
`
`8
`NLSAPI. For example, the license certificate object 906
`facilitates adding assignment information to license record
`objects to assign or remove access rights for