1. Field of the Invention
This invention relates to management of software licenses, particularly the management of software licenses in a large enterprise environment.
2. Description of the Related Art
With the advancement of computer technology proceeding at a lightning pace, computers are being replaced with great frequency. Older computers being replaced are typically donated to employees or non-profit organizations, sold, scrapped, or recycled. Many PC manufacturers even offer their customers the opportunity to recycle personal computers and other peripherals.
When a user decides to migrate from an old system to a newer system with more up-to-date technology, in many instances, applications that were being used on the old system will again be used on the new system. For example, a user may use Lotus Notes (International Business Machines Corporation) on the old system and may wish to use the same Lotus Notes program on the new system. Likewise, an office productivity suite, such as Microsoft Office (Microsoft Corporation) may well be used on the new system.
Typically, a license exists for each application used on the old system. In most cases, the license for the application is transferrable from an old PC to a new PC, as long as the licensed copy is removed from the old system prior to use on the new system. For an individual user, this license transfer may not present much of a difficulty. However, in a large corporation with multiple users, it is difficult to track the old licenses and maintain a running inventory of which licensed copies are deployed on which machines within the organization. In view of this administrative difficulty, many large corporations simply buy new applications and licenses for their new personal computers instead of reusing the existing licenses. This is cost-inefficient and can represent a significant cost to a large corporation.
Accordingly, what is needed is a license-maintenance method and system to track application licenses and their deployment automatically so that the licenses for applications that have been removed from unused machines can be reused on new or different existing machines.
This invention is a system and method for storing an electronic record of the existence of licenses available for use in a network of computers and the deployment status of programs covered by the licenses. In a preferred embodiment, license tokens are stored on a license server, and the stored license tokens are used to validate the deployment of applications stored on clients associated with the license server. The license server maintains the license tokens for all licensed applications used by the associated clients and maintains a license file for each client. On a regular basis the license file containing token data is sent to the pre-boot environment of each client in the system, e.g., by a synching process. A license-maintenance application residing in the pre-boot environment of each client validates the applications stored on the client by comparing them with the token data in the license file upon the occurrence of a pre-boot process. If an application is found on the client that does not have an appropriate token data entry in the license file, corrective action may be taken.
When an application is voluntarily removed from a client by the user or IT administrator, on the next boot the application is identified as having been removed by the pre-boot environment (e.g., there will be a token data entry in the license file, but the program will not be found), and the license maintenance application informs the license server, and the license server then frees up the license token (and thus the license) for that instance of the application for use by another client and sends the client a new license file indicating this application is no longer on the client.
For example, for each program P1-Pn, there are five license tokens, A-E, available for use by clients associated with server 100. Shaded license tokens in the example of
It is understood that the architecture illustrated in
Details of license-file storage 102 are illustrated in
As noted above, the license files, including the license token data entries from license file storage 102, are periodically sent to the clients over the network. License server 100 is configured in a well-known manner (e.g., via software code, firmware, a combination of hardware and software, etc.) to enable the transfer of, i.e., to send, the license files to the preboot environment of their corresponding clients. The license file for a particular client is stored in a license-maintenance program residing in the pre-boot environment of each client. Thus, the license token data entries of license file 204 will be stored in the license-maintenance program of client 104, license token data entries of license file 206 will be stored in the license-maintenance program of client 106, the license token data entries of license file 208 will be stored in the license-maintenance program of client 108, and the license token data entries of license file 210 will be stored in the license-maintenance program of client 110.
Each license-maintenance program is configured to validate the applications stored on its corresponding client by reading the files on the client and comparing the results of this reading process with the license token data entries that have been sent to the client during synching with the license server. Whenever each of these clients begin a boot-up process, during the pre-boot operation, the license-maintenance program in the pre-boot environment will validate the programs installed on the client by comparing them with the license file data. The license-maintenance program is also configured to initiate corrective action when it finds unverified applications. If an application is loaded on one of the clients and there is not a corresponding entry in the license token data, the license-maintenance program can initiate protective action, e.g., it can make a request to the license server to arrange for the purchase of another license, remove the application from the client, deactivate it, etc. If desired, for statistical or for purpose of taking disciplinary action, this information can be conveyed back to the license server for reporting to a system administrator.
The corrective action can take many forms. For example, a request can be generated by the license maintenance program for an additional license to be purchased. Alternatively, the license maintenance program can immediately remove the detected program from the client so that it can no longer be accessed. Another option is to have alerts sent to system administrators, or the program can be left on the client, but can be deactivated so that it cannot be used. The specific type of corrective action to be taken is a matter of design choice.
At step 314, a determination is made as to whether or not there are additional programs to be checked on the client device. If there are additional programs to be checked, the process proceeds back to step 306, where the next detected program is checked. If there are no additional programs to be checked, the process ends.
At step 406, the license information, correlated to the client information regarding the program, is stored as part of the license file data currently residing in the license maintenance program of the client device. At step 408, this information is conveyed to the license server, e.g., the license file data in the license-maintenance program is synched with the license server, thereby conveying to the license server the information regarding the newly-installed program. At step 410, the license server, now “aware” of the installation of one of the licensed programs, confirms that a license token exists on the license server corresponding to the newly-installed licensed version of the program. At this point, the installation process is complete. In this manner, the license server has confirmed that a license token exists for the new installation and maintains the license token information pertaining to this installation in the license file for the client.
If it turns out that there are no license tokens available for the installation, an alert is sent to the license server requesting a token. The administrator can then determine to purchase an additional license or find a client not using its license in order to free up a token. During the next pre-boot environment, an available token will be presented to the client which can then enable use of the licensed program.
At step 510, the token associated with the removed program is disassociated with the client and is made available for use by others. The license file for the client is modified so that the license-file data for the now-disassociated program no longer is in the license file. Thus, on the next transmission of the license file data to the client, the license file data will not contain license file data for the disassociated program. If the user of the client has reinstalled the program, when the client goes through the pre-boot process, there will be no license file data for the improperly installed program, and corrective action can be taken. At step 514, the removal process is complete.
In some enterprise environments, when a client is surrendered by a particular user (e.g., the user leaves the company and leaves the client computer in his/her office and/or returns a laptop on their last day of employment) it is sent to an enterprise configuration center where it is completely cleaned of all files and then “common operating environment” (e.g., the enterprise image) is reloaded onto the computer before it is deployed to a new user. The cleaning of the files is typically performed by a disposal tool such as IBM's Secured Data Disposal (SSD). To ensure that the license server is made aware of the programs to be cleaned from the computer (and thus “return” the tokens for the licensed programs on the computer for reuse), the present invention can be implemented as a plug-in (or integrated directly) to the disposal program. Configured in this manner, after the disposal program reads the programs to be removed, but before the computer is actually wiped clean (which could dispose of the pre-boot environment of the client), the disposal program can connect to the license server to make it aware as to which licensed programs are being removed, allowing the tokens for these programs to be made available for new installations of the same program.
The above-described steps can be implemented using standard well-known programming techniques. The novelty of the above-described embodiment lies not in the specific programming techniques but in the use of the steps described to achieve the described results. Software programming code which embodies the present invention is typically stored in permanent storage of some type, such as permanent storage of the license server and/or any clients using the system. In a client/server environment, such software programming code may be stored with storage associated with a server. The software programming code may be embodied on any of a variety of known media for use with a data processing system, such as a diskette, or hard drive, or CD-ROM. The code may be distributed on such media, or may be distributed to users from the memory or storage of one computer system over a network of some type to other computer systems for use by users of such other systems. The techniques and methods for embodying software program code on physical media and/or distributing software code via networks are well known and will not be further discussed herein.
It will be understood that each element of the illustrations, and combinations of elements in the illustrations, can be implemented by general and/or special purpose hardware-based systems that perform the specified functions or steps, or by combinations of general and/or special-purpose hardware and computer instructions.
These program instructions may be provided to a processor to produce a machine, such that the instructions that execute on the processor create means for implementing the functions specified in the illustrations. The computer program instructions may be executed by a processor to cause a series of operational steps to be performed by the processor to produce a computer-implemented process such that the instructions that execute on the processor provide steps for implementing the functions specified in the illustrations. Accordingly, the figures support combinations of means for performing the specified functions, combinations of steps for performing the specified functions, and program instruction means for performing the specified functions.
Although the present invention has been described with respect to a specific preferred embodiment thereof, various changes and modifications may be suggested to one skilled in the art and it is intended that the present invention encompass such changes and modifications as fall within the scope of the appended claims.