This is a continuation of copending application Ser. No. 08/031,063 filed on Mar. 12, 1993, now abandoned.

FIELD OF THE INVENTION

This invention relates to Computer Systems and more particularly to licensing of software within a computer system. Even more particularly, the invention relates to licensing software through a common network licensing server.

BACKGROUND OF THE INVENTION

Licensing of computer software has traditionally been done by providing a copy of the software for each computer that was licensed to use the software. The licensed software was "locked" to the computer and could not be legally used on another computer. When computers are networked together, the practice of locking the software to a network node becomes particularly bothersome. One solution to this problem is to use a network license manager, also called a network license server. When a network license server is used, the software may be installed on any or all nodes of the network, however, only a certain number of licenses are purchased from the vendor. The license server limits the number of concurrent users of the software to the number of licenses purchased. This is done by providing some form of license "token" to the software when a user starts to use the software. That is, each time a user wants to use the software, the software sends a network message to the license server requesting a license token. If a token is available, it is returned to the software, and the software then performs its function for the user. When the user finishes using the software, the token is returned to the license server. When all the licenses are in use, the next user will not receive a token and must wait for one to become available. For example, if a network has ten nodes, the software may be installed on all the nodes. If only five licenses are purchased, five users may use the software at the same time. If a sixth user on the network attempts to use the software, no license is available, so this sixth user must wait. The software on this sixth node will not function until it receives a license token. In this manner, the software vendor gets paid for the maximum number of concurrent users, and the customer can start small and add licenses as the usage increases.

This method has proven popular and several different license servers are available from different software vendors. This causes a problem, however, since a customer may use any of the license servers available, and the application software vendor, who may be different from the license server software vendor, must provide different software to interface with each of the different license servers. To interface with the various license servers, an application software vendor must develop several different versions of the application software, one for each of the license servers. This is very costly, and causes considerable delay when the wrong version is sent to a user.

Another problem is that each of the license servers has different interface requirements. This increases development cost and increases the potential for errors. Still another problem is that a software application must be modified each time a new license server is developed or a new version of an existing server is released.

Providing a consistent user interface when a license is not available is yet another problem. When a license is not available, the user must be notified and given the choice of discontinuing the application or being placed in a queue to wait for a license. This user interface must be written for each license server used by each application, thus the user is presented with many different interfaces, all of which are used for solving the same problem.

There is need in the art for a common interface to allow application software to interface to various license servers. There is a further need in the art for such a common interface that allows application software to be easily adaptable to newly developed license servers. A still further need is for a common user interface to notify a user that a problem exists in obtaining a license. The present invention meets these and other needs.

SUMMARY OF THE INVENTION

It is an aspect of the present invention to provide a method of licensing a software application program via common network licensing server software.

It is another aspect of the invention to provide a common interface between such an application program and a plurality of network licensing servers.

Still another aspect is to allow such licensing with a single set of program calls from a single point in the application program.

A further aspect is to provide a single user interface for selecting available user options when a license to the software application is unavailable.

The above and other objects of the invention are accomplished in a system that provides a common application program interface to a variety of license servers. The system provides a single set of program calls and translates this single set of calls into a different set of calls for each license server. This translation is performed using a translation table, which is easily updated to interface to newly developed license servers or new versions of existing servers.

One of the requirement of most license servers is that the application program send a license renewal message to the license server periodically to notify the server that the license is still in use. If the application program fails to send the message, the license server times it out and releases the license to another user. The system of the present invention runs as a separate process within the operating system environment to monitor the application program, and as long as the application program continues to provide services to the user, the system of the present invention sends the periodic license renewal messages to the license server. This relieves the application program of the task of providing the periodic messages, thus the application program need only provide initialization calls, which considerably simplifies the application program.

The system also notifies the user when the application program cannot obtain a license. Since the system of the present invention is performing this notification, the user interface is consistent across all software applications that use the system of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other aspects, features, and advantages of the invention will be better understood by reading the following more particular description of the invention, presented in conjunction with the following drawings, wherein:

FIG. 1 shows a block diagram of a computer system incorporating the present invention;

FIG. 2 shows a diagram of the processes of the present invention, and their way of communicating;

FIG. 3 shows a flowchart of the initialization process of the present invention;

FIG. 4 shows a flowchart of the function called by the application software to interact with the license monitor after initialization;

FIGS. 5, 6 and 7 show a flowchart of the license monitor of the present invention;

FIG. 8 shows a diagram of the translation table used by the license monitor; and

FIG. 9 shows the user interface screen that displays user options when a license is unavailable.

DESCRIPTION OF THE PREFERRED EMBODIMENT

The following description is of the best presently contemplated mode of carrying out the present invention. This description is not to be taken in a limiting sense but is made merely for the purpose of describing the general principles of the invention. The scope of the invention should be determined by referencing the appended claims.

FIG. 1 shows a block diagram of a computer system incorporating the present invention. Referring now to FIG. 1, a computer system 100 contains a processing element 102. The processing element 102 communicates to other elements of the computer system 100 over a system bus 104. A keyboard 106 allows a user of the system to input textual information, and a mouse 110 allows the user to input graphical information. A graphics display 108 allows the system to output text and graphics for viewing by the user. A disk 112 is used to store the software and data of the present invention, as well as software and data for the software application programs within the computer system 100. A communications interface 114 is used by the present invention to communicate with a license monitor remote server in another node of the network to which the computer system 100 is attached. Memory 116 contains the Unix multitasking operating system 118. Unix is a registered trademark of AT&T. In the preferred embodiment of the present invention, the invention uses the Unix operating system, however, other multitasking operating systems, or even a single tasking operating system such as MS DOS could be used with the present invention. A licensed application 120 uses the services of the present invention through library routines compiled and linked into the licensed application 120. These routines communicate to a license monitor local server task 122 which in turn communicates over the communications interface 114 to a vendor specific license server (not shown in FIG. 1).

FIG. 2 shows a diagram of the processes of the present invention, and their interaction. Referring now to FIG. 2, the licensed application 120 from FIG. 1 is shown surrounded by dashed lines. Within the licensed application 120 is a licensed application program 202 which utilizes the services of the present invention. Linked into the licensed application 120 to communicate with the licensed application program 202 are a set of Licensed Mechanism Standard Interface (LMSI) library routines 204. These routines will be more fully described below. The LMSI library routines 204 communicate to the license monitor local server 122 over a secured interprocess communications link 206. The link 206 is made secure by encoding the data. Various means for encoding data are well known in the art. This encoding is necessary to prevent unauthorized usage of the licensed application program by supplying a bogus license monitor local server.

The license monitor local server 122 contains an LMSI license monitor 212 which receives communications from the LMSI library routines 204. The LMSI license monitor 212 uses a license monitor translation table (LMTT) 210 to translate the request from the licensed application program 202 into a set of requests for a particular set of vendor specific library routines 208. The vendor specific library routines 208 then communicate to a vendor specific license server 214, typically located in another node of the network. The vendor specific library routines 208 may be one of several different sets of routines for several different vendors, for example the NetLS license server, available from Hewlett Packard Company, the Flexlm license server available from Highland Software, and the SunNET license server available from Sun Microsystems, Inc.

FIG. 3 shows a flow chart of one of the LMSI library routines 204 (FIG. 2) called by the licensed application program 202 to initialize the license monitor. Referring now to FIG. 3, after entry, block 302 determines whether the license monitor local server 122 is currently running as a daemon. In the Unix operating system, a daemon is an independent process within the operating system, typically started during initialization of the operating system. This type of process performs various services for application programs. For example, printing is done by a daemon process in Unix. In the system of the present invention, the license monitor local server can be implemented as a daemon, or it can be implemented as a child process started by the process containing the licensed application. Block 302 determines whether a server daemon is active, and if one is not active, block 302 transfers to block 304 which starts the license monitor local server as a child process. After starting the child process, or if a daemon is already active, control transfers to block 306 which establishes secure communications to the license monitor local server. This secured communications is created by encoding all transfers between the license monitor local server and the LMSI library routines 204 within the licensed application 120. Block 308 then determines whether communications was established and, if not, block 308 transfers to block 316 which returns an error indication to the licensed application program 202. If secure communications has been established, block 308 transfers to block 310 which calls the LMSI license monitor 212 to get a vendor specific information handle from the LMTT 210. This "handle" is a pointer to information which is necessary for use by the application program 202 in all other calls to the LMSI library routines. Block 312 determines whether the handle was successfully obtained and, if not, transfers to block 316 to return an error. If the handle was successfully obtained, block 312 transfers to block 314 which returns the handle to the licensed application program 202.

FIG. 4 shows a flow chart of the routine called by the licensed application program 202 to interact with the license monitor local server after initialization. This routine is called to request a license, return a license, get a list of current users that are using licenses for the application, or, optionally, to check the current state of the license. Referring now to FIG. 4, after entry, block 402 determines whether the license monitor local server is active and, if not, block 402 transfers to block 408 to return an error condition. If the server is active, that is, the initialization routine of FIG. 3 was called prior to calling this routine, block 402 transfers to block 404 which sends the parameters necessary to perform the request for the application program 202 to the license monitor local server 122. Block 404 then waits until a message is returned from the license monitor local server and block 406 checks the status returned in this message. If the status indicates that the request was not performed successfully, block 406 transfers to block 408 which returns an error indication, otherwise, block 406 returns to the licensed application program 202 with a success indication, and it returns any data obtained by the request.

FIGS. 5, 6 and 7 show a flow chart of the LMSI license monitor 212 (FIG. 2). This monitor is sent messages by the routines of FIGS. 3 and 4 to cause it to perform the license monitor local server functions. Referring now to FIG. 5, after entry, block 502 determines whether the message sent from the LMSI library routines is for initialization. If the message is for initialization, block 502 transfers to block 504 which determines whether the license monitor local server has been previously initialized. If not, block 504 transfers to block 506 which sets up an interval timer signal to cause the operating system to periodically call FIG. 7. This call is used to send periodic license renewal requests to the license monitor remote server, located in another node of the network, to keep the license available to the licensed application program. If these periodic calls are not made, the vendor specific license server may assume that the node containing the licensed application program is no longer functional and may free the license for use by others. After setting up the interval timer signal, block 506 transfers to block 508 which calls the vendor specific library routines 208 (FIG. 2) to perform the initialization. Each of the various sets of vendor specific library routines that interface with the present invention has some form of initialization. Block 508 calls the vendor specific library routines using the specific form acceptable to the specific vendor. After the initialization, block 510 determines whether the initialization was successful and, if not, transfers to block 524 which returns an error indication. If the initialization was successful, or if the license monitor local server had been previously initialized, control transfers to block 512 which sets up a pointer to an area within the license monitor translation table 210 (FIG. 2) for this particular vendor. Block 514 then returns this pointer as the handle to the LMSI library routine 204. If the message is not for initialization, block 502 transfers to block 516 which determines whether the call is to request a license. If the call is not for a license request, that is, the call is for returning a license, or for getting the number of current users that are using licenses for an application, or it is a call for checking the state of the current license, control transfers to block 518 which calls the vendor specific library routines 208 (FIG. 2) and passes the parameters to obtain the information requested by the LMSI library routines 204. Block 520 then determines whether the call was successful and, if not, block 520 transfers to block 524 which returns an error message to the LMSI library routines 204. If the call was successful, block 520 transfers to block 522 which returns the information requested by the application.

If the message sent by the LMSI library routines 204 is to request a license, block 516 transfers to FIG. 6 block 602. Block 602 calls the vendor specific library routines 208 to request a license and waits for the vendor specific library routines to contact the vendor specific license server to obtain the license token. After the call returns, block 604 determines whether the license was obtained. If the license was obtained, block 604 transfers to block 624 which places an entry for this license in a license table, which will be used by FIG. 7 for the periodic license renewal calls. Block 624 then returns a success indication to the LMSI library routines 204.

If the license was not obtained, block 604 transfers to block 606 which displays a user request asking the user for input. An example display of this user request is shown in FIG. 9. The display shown in FIG. 9, is a typical display from a windowing system, and provides several "buttons" that the user can use to indicate their choice. The application program may disable any of these buttons when it calls the LMSI library routines 204. This allows the application to have complete control over the system. Button 902 allows the user to request a retry, button 904 allows a user to request placing the request in a queue, button 906 allows the user to request a demonstration copy of the software, and button 908 is used when the user wishes to discontinue trying to obtain a license. Status box 910 will be used by block 606 to display a message indicating the current conditions. The example message given in box 910 would occur when the licensed application program was unknown to the vendor specific license server.

If the system is not being used with a windowing system, a character based user interface is used. This interface (not shown) is similar to the display of FIG. 9, but uses the arrow keys and the enter key instead of a mouse.

After displaying the user request block 606 transfers to block 608 to get the user input. Block 610 then determines whether the user has clicked the mouse on the retry button 902 and, if so, block 610 transfers back to block 602 for another attempt at obtaining a license. If the user input is not for a retry, block 610 transfers to block 612 which determines whether the user clicked the mouse on the demo button. If the user clicked the mouse on the demo button, block 612 transfers to block 614 which informs the application that a demonstration has been requested and then returns. If the user did not click the demo button, block 612 transfers to block 615 which determines whether the user clicked the exit button 908, If the user did click on the exit button 908, block 615 transfers to block 619 which informs the application that exit has been requested and returns. If the user did not click on the exit button 908, block 615 transfers to block 616 which determines whether the user clicked on the queue button 904. If the user did not click on the queue button 904, block 616 transfers back to block 606 to re-display the user request. If the user did click on the queue button, block 616 transfers to block 618 which builds a queue request and then block 620 calls the vendor specific library routines 208 to send the queue request to the vendor specific license server to place this licensed application program into a queue to obtain the next license available. Block 622 then returns the queue position to the LMSI library routines 204.

FIG. 7 shows a flow chart for a timer signal handler routine. A call to this signal handler was set up by block 506 (FIG. 5). As discussed above, this routine is used to send periodic license renewal requests to the vendor specific license server to keep the license active. Referring now to FIG. 7, after entry, block 702 gets the first or next license table entry. This table was set up by block 624 (FIG. 6). Block 704 determines whether the end of the table has been reached and if it has, block 704 returns from the timer interrupt. If one or more entries is still available in the license table, block 704 transfers to block 706 which calls the vendor specific library routines 208 to have it send a message over the network to the vendor specific license server to keep the license active. If the license is still active, the vendor specific license server will return a message to the vendor specific library routines 208 which will return the status to block 706. After receiving the status, block 708 determines whether the license is valid and if it is, transfers control back to block 702 to check the next entry in the license table. If the license is not valid, block 708 transfers to block 710 which determines whether the application had set up a signal to be called when an invalid license is detected. A license may expire because the expiration date for the license has passed or the license server can no longer be contacted (possibly caused by a network failure). If the license server cannot be contacted, the server may eventually re-issue the license to another application running on a different node. Also, some applications cannot deal with signals, therefore, the application can disable the signal feature when it calls the LMSI library routines 204. Instead, the application may request the current state of the license from the system, as described above with respect to FIG. 4 and the call to check the current state of the license.

If no signal had been set up, block 710 returns to block 702 to check the next table entry. If a signal had been set up, block 710 transfers to block 712 which signals the licensed application program 202 that the license has expired. Block 712 then returns to block 702 to check the next entry.

FIG. 8 shows an example of the license monitor translation table 210 (FIG. 2). Referring now to FIG. 8, block 802 shows an example of the translation table entries for the NetLS vendor specific library routines. Block 804 shows the translation table entries for the Flexlm vendor specific library routines, and block 806 shows the translation table entries for the SunNET vendor specific library routines. As shown in each of the blocks, the entries are position dependent, which allows the information supplied by the licensed application program to be easily translated into the information needed by, the vendor specific library routines. Those skilled in the art will recognize that many other methods could be used to set up the translation table.

Having thus described a presently preferred embodiment of the present invention, it will now be appreciated that the aspects of the invention have been fully achieved, and it will be understood by those skilled in the art that many changes in construction and circuitry and widely differing embodiments and applications of the invention will suggest themselves without departing from the spirit and scope of the present invention. The disclosures and the description herein are intended to be illustrative and are not in any sense limiting of the invention, more preferably defined in scope by the following claims.