Patent Publication Number: US-2021182364-A1

Title: Software license manager security

Description:
FIELD 
     This disclosure relates to software licensing, in particular, ensuring compliance with software licensing requirements in a secure manner. 
     BACKGROUND 
     Some known techniques for software license management are encryption-based, operating by encapsulating the executable binaries within an encrypted runtime environment. When the encapsulated binary is executed, the encapsulated shell sends a message to a license server requesting an application software license. If a license is available, the license server sends a reply to the encapsulated runtime environment with the encryption key to unlock the application executable and execute the application binary. If a license is not available, then the license server sends a reply to the encapsulated runtime environment to display a license denied message to the end user. Once the executable terminates, the runtime environment will send a license checkin message to the license server. 
     Some known techniques for software license checkout and checkin embed, within a software application executable, a set of tools to perform checkout and checkin license entitlements from a license server. These embedded utilities, which may decrypt the encrypted application executable, are usually provided by a license management system vendor that does not develop the application executable itself. Consequently, such known techniques may not be available for managing licensing for arbitrary software applications. Even if such techniques are available for a particular software application, because the license management vendor provides the embedded tools, the associated costs are passed on to the user, even if the user does not utilize that particular software application. 
     License servers may be used when an entity requires an automated method for enforcing the terms and conditions of vendor application license agreements. However, the vast majority of software subject to software license agreements is intended to be sold and distributed on a one-license-per-machine basis. Such software is therefore typically not provisioned to work with license servers. 
     In order to make a typical application work with an encryption-based license server, an administration team for the license must acquire the tools to encrypt applications from the license manager vendor, encrypt the suite of applications they want the company to use, and then distribute only those encrypted applications. Such encryption-based techniques thus require a non-trivial amount of administrative effort. Because such techniques involve modifying the executable with encryption, they may in some circumstances result in program faults. As a result, customer support for the application software by the application vendor may be withheld because the vendor may consider such encryption methods unsupportable and deny providing technical assistance. 
     It is a common practice for application vendors to specify a list of multiple terms and conditions for purchased software license agreements. These may include limits on the number of simultaneous uses of a license (concurrent jobs, concurrent nodes, and concurrent users), limits on which nodes may have access to the licenses, limits on which users can have access to the licenses, and/or limits on whether a license can be deployed domestically or internationally. In addition, vendors can specify that a set of licenses can only be used by persons that are a member of a particular group, and/or used by persons that are a member of a particular skill set. Generally, these terms and conditions are conjunctive (“and”) conditions and not disjunctive (“or”) conditions. 
     However, existing software license management solutions at most provide the ability to evaluate a license usage request based on a single criterion. The type of license entitlement criterion used by existing solutions include concurrent jobs, or concurrent nodes, or concurrent users, or a list of nodes, or a list of users. Existing solutions require that for a given application, only one license entitlement criterion be used to determine whether a license entitlement is granted or rejected. In particular, the vast majority of application license managers use some form of a concurrent software license—a single criterion—to determine software entitlement outcomes. 
     Further, it is common for corporations to deploy software licenses to clients so as to provoke violations of the terms and conditions, which can result in huge penalties for non-compliance. For example, the vast majority of software applications do not have automated checkout/checkin license management software to enforce the relevant terms and conditions. Moreover, software vendors frequently add combinations of license restrictions, such as restrictions on a list of clients and a list of user account names. 
     To optimize the deployment and use of software licenses, it is desirable to know where the available license entitlements are stored, where the licenses are deployed, who is using the license, how often the licenses are being used, and how much license maintenance is required. Further, one should be able to identify unused or little used licenses for all types of software. Solutions exist to capture some of this information, for concurrent software licenses only. However, software entitlements based on only concurrent software licenses account for about 2% of software titles. The remaining software titles may be subject to software license agreement terms and conditions that are node based, user based, token based, enterprise based, group based, skill based, pool based, site based, or domain based. 
     Large companies need to allocate costs of software licensing among their various projects for accounting purposes. This is particularly important when the software licensing terms charge on a per-use, per-job, or per-hour basis. Employees may work on a variety of projects and should be equipped with tools to account for costs appropriately. For companies with a large selection of chargecodes (alternatively charge codes), the glut of choices increases the burden of finding the desired chargecode and the risk of electing a wrong line in error. Where software license managers allow chargecode management at all, the typical solutions involve multiple transactions between the user and the license server. The user may send a request for available chargecodes, the server may respond to the request, and the user may send an update, which the server may or may not acknowledge. On the face of it, these transactions may appear nominal, but when a server may need to process tens of thousands of requests an hour, any transaction other than a license checkin/checkout will have a negative effect on the maximum throughput of license requests that can be processed in an hour. 
     Software license entitlement management services may be performed on multiple license entitlement servers, which require synchronized license management configurations. Maintaining such license management configurations can be time consuming and error prone. In addition, managing and supporting hundreds of thousands to millions of clients is extremely labor intensive and time consuming. Further, troubleshooting, debugging, and resolution of client software can be very complicated. 
     Typically, application service maintenance support is performed by remotely logging into the target and searching for potential misconfigurations. This is frequently very labor intensive to diagnose and/or update. In addition, obtaining detailed diagnostic information for analysis is virtually non-existent, making it nearly impossible to replicate the issues/failures. 
     Some existing software license management solutions lack protection from actions by a malicious user. Such a user may seek to delete, alter, or disable elements of the software license management solution. Such a malicious user may seek to thwart software license management, e.g., so that the user&#39;s employer, or the software licensor themselves, is unaware of the user&#39;s software usage. 
     SUMMARY 
     According to some examples, a method of securing computer executable software for tracking usage of at least one software application is presented. The computer executable software for tracking usage of at least one software application includes tracking software installed on a client and monitoring software installed on the client. The monitoring software is hidden from users of the tracking software. The method includes tracking, by the tracking software, a usage of the at least one software application by the client; obtaining, by the tracking software, a status of the monitoring software; and restarting the monitoring software, by the tracking software, in response to obtaining a status of the monitoring software indicating that the monitoring software is not executing. 
     Various optional features of the above examples include the following. The method can include storing software identification data for the at least one software application in a configuration file; checking, by the monitoring software, whether the configuration file is present; detecting, by the monitoring software, that the configuration file is not present; and sending an alert to an administrator of the computer executable software for tracking usage of at least one software application in response to the detecting. The tracking software can include at least one tracking software file, and the method can further include: checking, by the monitoring software, whether the at least one tracking software file is unchanged; detecting, by the monitoring software, that the at least one tracking software file is not unchanged; and sending an alert to an administrator of the computer executable software for tracking usage of at least one software application in response to the detecting. The method can include checking, by the monitoring software, whether at least one directory for the tracking software is unchanged; detecting, by the monitoring software, that the at least one directory for the tracking software is not unchanged; and sending an alert to an administrator of the computer executable software for tracking usage of at least one software application in response to the detecting. The tracking can include: detecting by the tracking software, an initiation of the at least one software application on the client; suspending by the tracking software, an execution process of the at least one software application; determining, by the tracking software, that the software application is subject to at least one software license agreement; obtaining a license for a usage of the at least one software application; and resuming, by the tracking software, the initiation of the software application on the client, such that the client executes the software application. The obtaining the license for the usage of the at least one software application can include: requesting, by the tracking software and from a server, the license for the usage of the at least one software application on the client; determining, by the server, that the usage of the at least one software application on the client satisfies a plurality of license entitlement criteria from the at least one software license agreement; and providing, by the server and to the client, a license for the usage of the at least one software application on the client. The obtaining, by the tracking software, a status of the monitoring software can include periodically obtaining by the tracking software, a status of the monitoring software at least once per second. The method can include obtaining, by the monitoring software, a status of the tracking software; and restarting the tracking software, by the monitoring software, in response to receiving a status of the tracking software indicating that the tracking software is not executing. The method can include sending an alert to an administrator of the computer executable software for tracking usage of at least one software application in response to receiving a status of the monitoring software indicating that the monitoring software is not executing. The method can include storing installation data for the at least one software application in an encrypted configuration file; where at least one configuration file for at least one of the tracking software or the monitoring software is encrypted. 
     According to some examples, a system for securing computer executable software for tracking usage of at least one software application is presented. The computer executable software for tracking usage of at least one software application includes tracking software and monitoring software, where the monitoring software is hidden from users of the tracking software. The system includes a client with the tracking software and the monitoring software installed thereon and configured by the tracking software and the monitoring software to perform actions including: tracking, by the tracking software, a usage of the at least one software application by the client; obtaining, by the tracking software, a status of the monitoring software; and restarting the monitoring software, by the tracking software, in response to obtaining a status of the monitoring software indicating that the monitoring software is not executing. 
     Various optional features of the above examples include the following. The actions can further include: storing software identification data for the at least one software application in a configuration file; checking, by the monitoring software, whether the configuration file is present; detecting, by the monitoring software, that the configuration file is not present; and sending an alert to an administrator of the computer executable software for tracking usage of at least one software application in response to the detecting. The tracking software can include at least one tracking software file, and the actions can further include: checking, by the monitoring software, whether the at least one tracking software file is unchanged; detecting, by the monitoring software, that the at least one tracking software file is not unchanged; and sending an alert to an administrator of the computer executable software for tracking usage of at least one software application in response to the detecting. The actions can further include: checking, by the monitoring software, whether at least one directory for the tracking software is unchanged; detecting, by the monitoring software, that the at least one directory for the tracking software is not unchanged; and sending an alert to an administrator of the computer executable software for tracking usage of at least one software application in response to the detecting. The tracking can include: detecting by the tracking software, an initiation of the at least one software application on the client; suspending by the tracking software, an execution process of the at least one software application; determining, by the tracking software, that the software application is subject to at least one software license agreement; obtaining a license for a usage of the at least one software application; and resuming, by the tracking software, the initiation of the software application on the client, such that the client executes the software application. The obtaining the license for the usage of the at least one software application can include: requesting, by the tracking software and from a server, the license for the usage of the at least one software application on the client; determining, by the server, that the usage of the at least one software application on the client satisfies a plurality of license entitlement criteria from the at least one software license agreement; and providing, by the server and to the client, a license for the usage of the at least one software application on the client. The obtaining, by the tracking software, a status of the monitoring software can include periodically obtaining by the tracking software, a status of the monitoring software at least once per second. The actions can further include: obtaining, by the monitoring software, a status of the tracking software; and restarting the tracking software, by the monitoring software, in response to receiving a status of the tracking software indicating that the tracking software is not executing. The actions can further include sending an alert to an administrator of the computer executable software for tracking usage of at least one software application in response to receiving a status of the monitoring software indicating that the monitoring software is not executing. The actions can further include: storing installation data for the at least one software application in an encrypted configuration file; where at least one configuration file for at least one of the tracking software or the monitoring software is encrypted. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate the present teachings and together with the description, serve to explain the principles of the disclosure. 
         FIG. 1  is a schematic diagram of a system for managing software licenses according to some examples; 
         FIG. 2  is a schematic diagram of a client in a system for managing software licenses according to some examples; 
         FIG. 3  is a schematic diagram of a license server according to some examples; 
         FIG. 4  is a schematic diagram of a director in a system for managing software licenses according to some examples; 
         FIG. 5  is a schematic diagram of an accountant in a system for managing software licenses according to some examples; 
         FIG. 6  is a schematic diagram of a data warehouse in a system for managing software licenses according to some examples; 
         FIG. 7  is a flow diagram of a portion of a method for processing a message in a system for managing software licenses according to some examples; 
         FIG. 8  continues the flow diagram of  FIG. 7 ; 
         FIG. 9  concludes the flow diagram of  FIGS. 7 and 8 ; 
         FIG. 10  is a flow diagram of a process for managing software licenses according to some examples; 
         FIG. 11  is a schematic diagram of an architecture and a technique for securing client software according to some examples; 
         FIG. 12  is a flow diagram of a method for securing client software by restarting monitoring software according to some examples; 
         FIG. 13  is a flow diagram of a method for securing client tracking software according to some examples; and 
         FIG. 14  is a flow diagram of a method for detecting configuration file tampering according to some examples. 
     
    
    
     It should be noted that some details of the figures have been simplified and are drawn to facilitate understanding of the present teachings, rather than to maintain strict structural accuracy, detail, and scale. 
     DETAILED DESCRIPTION 
     Reference will now be made in detail to the disclosed examples, which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. In the following description, reference is made to the accompanying drawings that form a part thereof, and in which is shown by way of illustration specific examples. These examples are described in sufficient detail to enable those skilled in the art to practice them and it is to be understood that other examples may be utilized and that changes may be made without departing from the scope of the disclosure. The following description is, therefore, merely exemplary. 
     I. Software License Management 
     Some examples provide a solution for managing software licensing. Further, some examples, provide a software application license terms-and-conditions compliance enforcement application. Yet further, some examples provide a software application hybrid license entitlement manager. Some examples provide all of the above features and advantages. Companies that need to manage pools of software licenses, for example, may utilize the disclosed systems and methods, which use a client/server process-based method of enforcing vendor application license usage terms and conditions. 
     According to some examples, each client has tamper-resistant software loaded on it that monitors the processes being run by the client machine. When it detects the startup of a managed application process, it suspends the process momentarily and contacts a license server to attempt to check out a license for the usage of the managed application. If the license request is granted, it will allow the process to resume. If the license request is denied, the client software will terminate the process and notify the user. When the process terminates, the client software checks the license back in. According to some such examples, the managed software application is not encrypted. 
     Some examples provide the ability to determine whether a license for usage of a software application can be provided based on an evaluation of multiple license entitlement criteria that are defined by an associated software license agreement. That is, some examples provide the ability to enforce multiple simultaneous license entitlement criteria in an automated fashion. The criteria may include all, any, or any combination, of: concurrent jobs, concurrent nodes, concurrent users, a list of sites, a list of nodes, a list of users, a list of domains, a list of groups, a list of skills, and a list of pools. Some examples grant a license for usage only if the request indicates that such usage passes all ten simultaneous license entitlement criteria. This mechanism may be performed in response to a dynamic real time request for a license for usage of a software application from a client to a license server. 
     Some examples manage chargecodes in an efficient manner. Such examples may permit querying for, and selecting, valid chargecodes, without meaningful impact network traffic to the license server. Such examples may, in addition or in the alternative, allow for specifying filters to limit chargecode choices. 
     Some examples provide the ability to easily manage the synchronized license management configurations of multiple license entitlement servers. Further, some examples provide service support tools, which allow for remote diagnostic debug, configuration management, application license notifications and warnings, option selection, token license entitlement creation and deletion, inventory, and configuration updates. 
     These and other features and advantages are described in detail below. 
       FIG. 1  is a schematic diagram of a system  100  for managing software licenses (e.g. for controlling access to one or more software applications) according to some examples. Each block in  FIG. 1  represents a computing device, and each arrow represents a communication channel, such as the internet. Thus, system  100  may be implemented in a distributed manner, e.g., over the internet. As shown,  FIG. 1  depicts license servers  102 , which are communicatively coupled to client  104 . Servers  102  are further communicatively coupled to directors  106  and to data warehouse  110 , which may be an information technologies service management data warehouse  110 . Client  104  is also communicatively coupled to directors  106 , and to accountant  108 . Client  104  has client computer software installed thereon that directs client  104  (e.g., one or more electronic processors of client  104 ) to perform the actions described herein. Likewise, license server  102 , directors  106 , accountant  108 , and data warehouse  110  have respective software installed thereon that directs the respective machines (e.g., their respective one or more electronic processors) to perform the actions described herein. The operation of license servers  102 , client  104 , directors  106 , accountant  108 , and data warehouse  110  is described in detail herein further below. 
     System  100  may include service support tools as described presently. The service support tools provide for repairing application license entitlement configuration issues, and for configuring service support options. In general, the service support tools may be executed on a network machine, such as a node, in the same network as system  100 . From this networked machine, the service support tools may be used to perform the following tasks for client  104 : debug, manage security, turn on or off email alerts for debug errors, generate a software application inventory, generate license manager reports, look up accountant files, and pull token records. Further, from the networked machine, the service support tools may be used to perform the following tasks for server  102 : debug, check in or out a license for a usage of a software application, start or stop a chargecode timer, create or delete tokens, and retrieve data regarding any managed, software application, any user, any site, and any node. In addition, service notification and warning messages can inform the user of upcoming updates and outages. 
     The service support tools provide an ability to turn on and off debug and trace diagnostics and record these in a debug log file. This log file can then be delivered to application experts for analysis. The debug ability of the service support tools is superior to prior art techniques that require compiling code with a debugger turned on. Instead, each of client  104 , license server  102 , director  106 , and accountant  108  each have built-in debug systems. Such systems write to a log file each event, routine, variable value, and timestamps. Turning on the log file recordation of the debug service support tool during operation of any of client  104 , license server  102 , director  106 , or accountant  108  causes the creation of a thread that generates a verbose log file. 
     According to some examples, license server  102 , director  106 , and accountant  108  may be configured to require a key in order to execute. Such examples thus provide for tamper-resistance and thwart malicious installations. According to such examples, a system component, e.g., one of license server  102 , director  106 , and accountant  108 , checks for the presence of a license key in a local configuration file, and does not execute if the key is not present. Each system component has an associated media access control (MAC) address. Further, each system component has an associated system identifier. The key for a given system component may be formed as a cryptographic hash of a concatenation of: the MAC address for the system component, the system identifier for the system component, and a random number. 
       FIG. 2  is a schematic diagram of a client  104  in a system for managing software licenses according to some examples.  FIG. 2  also depicts director  106 , accountant  108 , and license server  102  and their communicative couplings. Client  104  electronically stores ordered lists of servers  102 , directors  106 , and accountants  108  with which it may communicate. If a respective server  102  (or director  106 , or accountant  108 ) is down, client  104  may attempt communication with the next server  102  (or director  106 , or accountant  108 ) on its lists. 
     In order to manage a software application, some examples establish software asset management records  259 . Such records may be formed and sent by client  104  to director  106 , e.g., when the software application is installed, upgraded, or removed on client  104 . In particular, some examples include a software application installer that installs and uninstalls software applications on clients such as client  104 . When it installs or updates a new software application, the software application installer forms and sends a message to director  106  that indicates the software application, the user, the node at which the software application is installed, and the location of the node at which the software application is installed. This information is formed in software asset management records  258  and sent to director  106 . Further, when installing a new software application, the software application installer configures the software application such that its initiation can be intercepted while licensing requirements are checked as disclosed in detail herein. Note that the use of the software application installer as described is superior to prior art techniques that rely on network scans to identify managed software, at least because such network scans are resource intensive and slow, e.g., on the order of months. 
     According to some examples, there are three distinct categories of software license entitlements that may be defined by a software license agreement, particularly its relevant terms and conditions. A first category is token-based software license entitlements, a second category is enterprise-based software license entitlements, and a third category is server-based software license entitlements. These categories are described in detail presently. 
     Token-based software license entitlements involve data located on individual clients  104 , and do not require involvement by license server  102  at the time the respective software is used. Token-based software license entitlements may be used, for example, to permit a client to execute software when client  104  is not communicatively coupled to any license server  102 . Thus, token-based software license entitlements may be used when client  104  is expected to be offline for a length of time. When client  104  attempts to execute a managed software application, it first checks whether a local token is available. If so, then the token is used instead of requesting a license from server  102 . Token-based software license entitlements may therefore bypass requesting, by client  104  and from license server  102 , a license for a usage of the software application, if client  104  has an appropriate token. For token-based software license entitlements, license for usage request transaction information is captured by client  104 , and later transferred to director  106  when communication between such computing devices is available. Such token-based software license entitlement interactions between client  104  and license server  102  are represented in  FIG. 2  by block  202 . 
     Enterprise-based software license entitlements involve enterprise licenses, where an entire enterprise may simultaneously utilize as many copies of a give software application as they wish. For enterprise-based software license entitlements, client  104  may request an enterprise license for usage of a software application from license server  102 . If successful, then the enterprise license for the usage is checked out from server  102 , and application license transactions (e.g. enterprise transactions), represented by block  204 , are captured on license server  102 . If the request for the enterprise license for the usage of the software application is unsuccessful for any reason (e.g., license server  102  license denial, license server  102  not online or otherwise available, etc.), then the software application is permitted to execute anyway, and the relevant application license transactions  204  are captured on client  104 , and later transferred to director  106 . Because enterprise-based software license entitlements generally permit unlimited instances of the managed software application executing simultaneously, the presence of enterprise-based software license entitlements is generally checked after checking for token-based license entitlements and before checking for server-based software license entitlements. 
     Token-based software license entitlements and enterprise-based software license entitlements, described above, do not utilize communications between client  104  and license server  102  at the time of the usage of the respective software application. By contrast, server-based software license entitlements, described below, generally utilize communications between client  104  and license server  102  at the time of the usage of the respective software application. 
     Server-based software license entitlements involve interactions between client  104  and server  102 . In reference to  FIG. 2 , a description of a process  254  for client  104  to acquire a license for a usage of a software application from license server  102 , from the perspective of client  104 , follows. 
     At  220 , a user at client  104  initiates (e.g. starts) an instance of a software application that is managed by an example. The user may do so using standard application initiation techniques, such as clicking on an icon. The process is transparent from the perspective of the user. 
     At  222 , an executing instance of client software for an example monitors the execution processes of client  104 . In doing so, it determines that a new instance of a monitored software application has been invoked. Accordingly, at  224 , the client software suspends the execution process of the monitored software application. 
     At  226 , the executing client software locates an account for the software application, and at  228 , it checks the account to determine whether a license for the requested usage of the software application is required. As part of  226 , client  104  may first check whether a token-based software license entitlement is present, then check whether an enterprise-based software entitlement license present, and then check whether a server-based software license entitlement is present. If no license is required, then control passes to block  230 , where the software application process is permitted to resume execution, until, at  232 , the user exits the software application and the process  254  of client  104  acquiring a license for a usage of a software application from license server  102  concludes. Otherwise, if a server-based software license entitlement for the requested usage of the software application is required, then control passes to block  234 . 
     At block  234 , the executing client software contacts accountant  108  to determine whether the software usage is to be associated with a chargecode. To do so, client  104  contacts accountant  108  with a request for accountant  108  to indicate (e.g. to lookup) a chargecode that is currently in use for the particular software application. 
     In general, accountant  108  maintains an electronically stored record of the current chargecode that has been previously selected by the user. Further, accountant  108  maintains, for each user, a list of allowed chargecodes. Accountant  108  may obtain and update such a list by using an active directory feature of the client operating system, for example. Accountant  108  also maintains a record of a current chargecode for each managed user. 
     To maintain a record of the current chargecode for the user of client  104 , accountant  108  may interact with client  104  in a chargecode update process  252  as follows. Per block  256 , client  104  may request from accountant  108  its list of permitted (e.g. allowed) chargecodes for the managed software user at issue. Client  104  receives the list, and generates a dialogue (e.g., a pop-up box) to display to the user of client  104 . Per block  258 , the dialogue allows the user to select, or change, a current chargecode for the requested user. Per block  260 , once the user enters (e.g. updates) the current chargecode information, chargecode update process  252  of client  104  provides the information to accountant  108 . Note that chargecode update process  252  may be performed at any time, not limited to during process  254  by which client  104  acquires a license for the usage of the software application from license server  102 . According to some examples, a user of client  104  may initiate chargecode update process  252 , e.g., by clicking on a button, at any time. 
     Thus, per block  234 , if a chargecode is currently in use for the managed software application and user of client  104 , then accountant  108  replies with the current chargecode. 
     At block  236 , client  104  determines that the software application is subject to a plurality of software license entitlement criteria defined by at least one software license agreement and requests (e.g. requests to checkout) a license for a usage of the software application from license server  102 . The request may include an identification of the software application, an identification of the user, an identification of the node, an identification of the chargecode, an identification of the domain, an identification of the pool, an identification of the site, for example. The request may be sent using any of a variety of protocols, such as TCP, HTTP, or XML. License server  102  performs a process for determining whether to provide client  104  with the requested license for usage of the software application as set forth in reference to  FIG. 3 , below. 
     At block  238 , client  104  determines whether the license checkout request was successful and license server  102  has provided a license for the usage. If not, then control passes to block  240 , where client  104  kills the execution process of the software application, and then to block  242 , where client  104  display an error message to the user, indicating that the license checkout request was denied. After block  242 , control passes to block  232 , where and the process  254  of client  104  acquiring a license for a usage of a software application from license server  102  concludes. 
     If, at block  238 , client  104  determines that the request was successful and has provided a license for usage of the software application, then control passes to block  244 , where client  104  permits the execution process of the software application to resume normally. During the execution of the managed software application, client  104  continuously monitors the execution of the managed software application at block  246 , checking whether the execution is still active (e.g. the application process exists) at block  248 . If the software application is still active, then control passes back to block  246 , and the monitoring repeats. If the software application is no longer executing, then control passes to license checkin  250 . 
     At license checkin  250  (alternatively check-in), client  104  sends a message to license server  102 , requesting that the license for the usage of the managed software application be checked back in. Once the license is checked back in, license server  102  sends a confirmation message back to client  104 . Subsequently, at block  232 , the process  254  by which client  104  acquires a license for the usage of the software application from license server  102  ends. 
     Client  104  also includes client heartbeats block  262 . In general, every fixed interval (e.g., daily, every four hours, every hour, every 30 minutes, etc.), client heartbeats block  262  sends a simple “ping” message to director  106 . The ping message includes an identification of the client. Director  106  updates the time of the latest ping message for each client such as client  104 . 
       FIG. 3  is a schematic diagram of a license server  102  in a system for managing software licenses according to some examples.  FIG. 3  also depicts client  104  and director  106 , as well as their communicative couplings. A description of a process  302  for license server  102  providing client  104  with a license for a usage of a software application, from the perspective of license server  102 , follows. 
     At block  304 , process  302  commences when license server  102  receives a checkout license request for a usage of a software application from client  104 . The request may include a request number, an identification of the software application, an identification of the user, an identification of the node, an identification of the site, an identification of the domain, an identification of the pool, and an identification of the chargecode at which the software application is to be used, and a current time, for example. The request may be received according to any of a variety of protocols, such as TCP, HTTP, or XML. 
     At block  306 , license server  102  initiates a plurality of license entitlement criteria tests (e.g. available application licenses), including concurrent jobs test  308 , concurrent nodes test  310 , concurrent users test  312 , list of nodes test  314 , list of users test  316 , list of groups test  318 , list of skills test  320 , list of domains test  322 , list of sites test  324 , and list of pools test  326 . Each test  308 ,  310 ,  312 ,  314 ,  316 ,  318 ,  320 ,  322 ,  324 ,  326  corresponds to one or more license entitlement criteria, which may be defined by the terms and conditions of a software license agreement for the software application. In general, the concurrent tests, such as concurrent jobs test  308 , concurrent nodes test  310 , and concurrent users test  312 , check whether the requested usage of the software application would result in exceeding a number of concurrent (e.g., simultaneous) uses of the software application according to some predefined limit indicated by the corresponding software license agreement. In general, the list tests, such as list of nodes test  314 , list of user test  316 , list of groups test  318 , list of skills test  320 , list of domains test  322 , list of sites test  324 , and list of pools test  326 , check whether the requested usage of the software application would result in a violation of a specified restriction concerning the named usage parameters. Thus, for example, the list of nodes test determines whether the requested usage would be inconsistent with restrictions on the software application&#39;s execution on nodes as specified in the list of nodes test. This test, and others, are described in detail presently. A description of how to use the results from the individual tests  308 ,  310 ,  312 ,  314 ,  316 ,  318 ,  320 ,  322 ,  324 ,  326  to draw a final conclusion as to whether the request of a usage of the software application should be affirmed or denied follows the descriptions of the individual tests  308 ,  310 ,  312 ,  314 ,  316 ,  318 ,  320 ,  322 ,  324 ,  326 . 
     Concurrent jobs test  308  determines whether a set limit on the number of executing instances of the particular software application would be exceeded if the requested usage were permitted. License server  102  stores a copy of this set limit on concurrent application jobs and compares it to a running tally of executing instances of the software application as obtained by current usage block  328 . If the tally is greater than or equal to the limit, then this test fails. 
     Concurrent nodes test  310  determines whether a set limit on the number of nodes executing the particular software application would be exceeded if the requested usage were permitted. Here, “nodes” refers to network nodes, e.g., clients such as client  104 , as specified by a node name such as A1234567.nw.nos.boeing.com. License server  102  stores a copy of the set limit on the number of nodes that may concurrently execute a copy of the software application and compares it to a running tally of executing instances of the software application on different nodes as obtained by current usage block  328 . If the tally is greater than or equal to the limit, then this test fails. 
     Concurrent users test  312  determines whether a set limit on the number of users using the particular software application would be exceeded if the requested usage were permitted. License server  102  stores a copy of this set limit on concurrent application users. Note that generally, nodes may correspond to users, but not necessarily. For example, a single user may be logged in to, and use multiple instances of the software application, on multiple nodes. Likewise, a single node, such as a supercomputer, may have multiple users logged in and using software applications. License server  102  stores a copy of the set limit on concurrent users and compares it to a running tally of executing instances of the software application by different users as obtained by current usage block  328 . If the tally is greater than or equal to the limit, then this test fails. 
     List of nodes test  314  determines whether the requested usage of the software application would violate conditions specified by one or more lists of nodes, e.g., clients such as client  104 . Such lists of nodes are stored by license server  102 . 
     According to some examples, each list of nodes test  314  involves two lists of nodes, referred to herein as the “accept node list” and the “reject node list”. These node lists are formatted to provide information as to, respectively, which nodes are permitted to execute an instance of the software application, and which nodes are forbidden from executing an instance of the software application. For example, each node list may be a computer-readable text (e.g., dot txt) document that includes a list of nodes, specified by name such as A1234567.nw.nos.boeing.com. The node lists may include subscription end dates in association with one or more node names, e.g., next to the node names. Further, either list of nodes may include a wildcard character, such as an asterisk. The presence of wildcard character in the node accept list, regardless as to whether any nodes are listed explicitly, indicates that all nodes are permitted to execute an instance of the software application. The presence of a wildcard character in the node reject list, regardless as to whether any nodes are listed explicitly, indicates that no nodes are permitted to execute an instance of the software application. 
     To evaluate list of nodes test  314  using an accept node list and a reject node list as described above, the following algorithm may be performed according to some examples. License server  102  identifies the requesting node, from which the request for a license for a usage of the software application originated. License server may consult data in the request itself for this information. License server  102  then checks the requesting node against the reject node list. If the requesting node is explicitly listed in the reject node list, then it fails list of nodes test  314 . List of nodes test  314  outputs a negative response, e.g., a binary “0”, and concludes. Otherwise, proceed to check whether the requesting node is explicitly listed in the accept node list. If the requesting node is explicitly listed in the accept node list, then it passes list of nodes test  314 . List of nodes test  314  outputs an affirmative response, e.g., a binary “1”, and concludes. Otherwise, proceed to check whether the reject node list includes a wildcard character. If the reject node list includes a wildcard character, then the requesting node fails list of nodes test  314 . List of nodes test  314  outputs a negative response and concludes. Otherwise, proceed to check whether the accept node list includes a wildcard character. If the accept node list includes a wildcard character, then the requesting node passes list of nodes test  314 . List of nodes test  314  outputs a positive response and concludes. Otherwise, the requesting node fails list of nodes test  314 . List of nodes test  314  outputs a negative response and concludes. 
     The above algorithm for evaluating the list of nodes test using an accept node list and a reject node list may be generalized to evaluate any of the list tests  314 ,  316 ,  318 ,  320 ,  322 ,  324 ,  326  based on a parameter concerning the request and using an accept list and a reject list. A general parameter test algorithm appears below. 
     
       
         
           
               
             
               
                   
               
               
                 Parameter Test Algorithm 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
            
               
                 (1) 
                 Identify parameter to be tested. Proceed to (2). 
               
               
                 (2) 
                 Check the parameter against the reject list. 
               
               
                   
                 If the parameter is explicitly listed in the reject list, then output “0” 
               
               
                   
                 and halt. 
               
            
           
           
               
            
               
                 Otherwise, proceed to (3). 
               
            
           
           
               
               
            
               
                 (3) 
                 Check the parameter against the accept list. 
               
               
                   
                 If the parameter is explicitly listed in the accept list, then output “1” 
               
               
                   
                 and halt. 
               
            
           
           
               
            
               
                 Otherwise proceed to (4). 
               
            
           
           
               
               
            
               
                 (4) 
                 Check whether the reject list includes a wildcard character. 
               
               
                   
                 If the reject list includes a wildcard character, then output “0” 
               
               
                   
                 and halt. 
               
            
           
           
               
            
               
                 Otherwise, proceed to (5). 
               
            
           
           
               
               
            
               
                 (5) 
                 Check whether the accept list includes a wildcard character. 
               
               
                   
                 If the accept list includes a wildcard character, then output a “1” 
               
               
                   
                 and halt. 
               
            
           
           
               
            
               
                 Otherwise, output a “0” and halt. 
               
               
                   
               
            
           
         
       
     
     As described in detail below, the above disclosed parameter test algorithm may be used to evaluate users test  316  based on a user parameter, evaluate groups test  318  based on a group parameter, evaluate skills test  320  based on a skills parameter, evaluate domains test  322  based on a domain parameter, evaluate sites test  324  based in a site parameter, and evaluate pools test  326  based on a pool parameter. 
     Note that the use of two lists for list of nodes test  314 , and for the general parameter test algorithm, is for purposes of illustration rather than limitation. Examples may utilize a single list, or more than two lists. 
     List of users test  316  determines whether the requested usage of the software application would violate conditions specified by one or more lists of users. Such lists of users are stored by license server  102 . To evaluate list of users test  316  for a particular request for usage of a software application, the user is identified per (1) of the parameter test algorithm. The user&#39;s identification may be retrieved from the request, for example. The remaining steps (2)-(5) are then applied, as needed, using an accept user list and a reject user list. 
     List of groups test  318  determines whether the requested usage of the software application would violate conditions specified by one or more lists of groups. Here, a group may be a group within a commercial organization such as a corporation. A group may be defined as a portion of a commercial organization&#39;s org chart. Example groups include executive, engineering, legal, administrative, maintenance, etc. An accept group list and a reject group list may be stored by license server  102 . To evaluate list of groups test  318  for a particular request for usage of a software application, the parameter test algorithm may be applied with the parameter “group”. To do so, the group is identified per line (1) of the parameter test algorithm. The group&#39;s identification may be retrieved from the request, for example. Alternately, license server  102  may look up the group&#39;s identification from a stored look-up table that associates the user identified in the request with the user&#39;s group, for example. The remaining steps (2)-(5) of the parameter test algorithm are then applied, halting where indicated, using the accept group list and the reject group list. The output of list of groups test  318  is one of affirmative or negative, e.g., “1” or “0”. 
     List of skills test  320  determines whether the requested usage of the software application would violate conditions specified by one or more lists of skills. Here, a skill may be an official certification, a degree of education, a delegation, or an appointment, for example. A particular type of skill is a named role in a business entity, e.g., network engineer, human resource specialist, data analyst, etc. Further example skills include engineering certifications, such as vendor-supplied engineering certifications, etc. An accept skills list and a reject skills list may be stored by license server  102 . To evaluate list of skills test  320  for a particular request for usage of a software application, the parameter test algorithm may be applied with the parameter “skill”. To do so, the skill is identified per line (1) of the parameter test algorithm. The skill may be retrieved from the request, for example. Alternately, license server  102  may look up the skill from a stored look-up table that associates the user identified in the request with the user&#39;s skill(s), for example. The remaining steps (2)-(5) of the parameter test algorithm are then applied, halting where indicated, using the accept skills list and the reject skills list. The output of list of skills test  320  is one of affirmative or negative, e.g., “1” or “0”. 
     List of domains test  322  determines whether the requested usage of the software application would violate conditions specified by one or more lists of domains. Here, a domain may be a geographic region or a network domain. Example domains include Eastern USA, Western USA, European Union, Australia, Asia, etc. An accept domains list and a reject domains list may be stored by license server  102 . To evaluate list of domains test  322  for a particular request for usage of a software application, the parameter test algorithm may be applied with the parameter “domain”. To do so, the domain is identified per line (1) of the parameter test algorithm. The domain may be retrieved from the request, for example. Alternately, license server  102  may look up the domain from a stored look-up table that associates the node identified in the request with the respective domain in which it is located, for example. The remaining steps (2)-(5) of the parameter test algorithm are then applied, halting where indicated, using the accept domains list and the reject domains list. The output of list of domains test  322  is one of affirmative or negative, e.g., “1” or “0”. 
     List of sites test  324  determines whether the requested usage of the software application would violate conditions specified by one or more lists of sites. Here, a site may be a physical commercial site. Example sites include corporate campuses, university campuses, engineering facilities, office buildings, cities, etc. An accept sites list and a reject sites list may be stored by license server  102 . To evaluate list of sites test  324  for a particular request for usage of a software application, the parameter test algorithm may be applied with the parameter “site”. To do so, the site is identified per line (1) of the parameter test algorithm. The site may be retrieved from the request, for example. Alternately, license server  102  may look up the site from a stored look-up table that associates the node identified in the request with the respective site at which it is located, for example. The remaining steps (2)-(5) of the parameter test algorithm are then applied, halting where indicated, using the accept sites list and the reject sites list. The output of list of sites test  324  is one of affirmative or negative, e.g., “1” or “0”. 
     List of pools test  326  determines whether the requested usage of the software application would violate conditions specified by one or more lists of pools. Here, a pool may be a division of a corporate work force. Example pools include domestic employees, international employees, contractors, etc. An accept pools list and a reject pools list may be stored by license server  102 . To evaluate list of pools test  326  for a particular request for usage of a software application, the parameter test algorithm may be applied with the parameter “pool”. To do so, the pool is identified per line (1) of the parameter test algorithm. The pool may be retrieved from the request, for example. Alternately, license server  102  may look up the pool from a stored look-up table that associates the user identified in the request with the respective pool in which the user is classified, for example. The remaining steps (2)-(5) of the parameter test algorithm are then applied, halting where indicated, using the accept pools list and the reject pools list. The output of list of pools test  326  is one of affirmative or negative, e.g., “1” or “0”. 
     Note that each of the license entitlement tests (blocks  308 ,  310 ,  312 ,  314 ,  316 ,  318 ,  320 ,  322 ,  324 ,  326 ) output either affirmative (e.g., “1”) or negative (e.g., “0”). If the software license agreement for a given software application lacks restrictions with respect to any software entitlement test(s), then such test(s) may output a “1” in such a situation. Thus, the outputs of the license entitlement tests may be concatenated in a succinct, ordered, ten-binary-digit string. For example, if a given request passes concurrent jobs test  308  and list of nodes test  314 , the succinct string may be formed as, for example, 1001000000. 
     Once all of the license entitlement criteria tests (blocks  308 ,  310 ,  312 ,  314 ,  316 ,  318 ,  320 ,  322 ,  324 ,  326 ) initiated per block  306  are performed, license server  102  determines whether a license for the requested usage is available. To do so, license server may utilize the succinct string described above, may consider the test outputs directly, or may consider the test outputs in a different format. Block  306  thus receives the outputs from the tests, and license server  102  compares the test results to a stored set of license entitlement criteria for the software application. 
     Based on the comparison, license server  102  determines whether all 10 license tests have been meet to provide a license for the requested usage of the software application. License checkout block  304  receives the results of this determination. If the determination reveals that all tests were passed, e.g., the determination is equal to 1111111111, then license server  102  checks out and provides a license for the requested usage to client  104 . Otherwise, license server sends a report to client  104 , detailing exactly which tests  308 ,  310 ,  312 ,  314 ,  316 ,  318 ,  320 ,  322 ,  324 ,  326  passed and exactly which tests  308 ,  310 ,  312 ,  314 ,  316 ,  318 ,  320 ,  322 ,  324 ,  326  failed. Client  104  may display these results to the user, e.g., in a pop-up box. 
     License checkout block  304  reports the license checkout to transaction information block  330  for the checkout process. The report to transaction information block  330  for the checkout process may include a variety of transaction information. Any, or any combination, of the following transaction information may be included: record number, application transaction number, transaction type (here, “checkout”), number of available licenses, usage (e.g., number of checked out licensees at the time of the transaction), timestamp, software application identification, user identification, user actual name, node identification, group identification, pool identification, skill identification, domain identification, site identification, chargecode information, license server identification, client identification, identification of the request for usage of the software application, and/or identification of the license for the usage. For requests that failed, the report to transaction information block  330  for the checkout process may include details of all tests that passed and failed. In some examples, this information is included for each transaction, e.g., in the form of the succinct, ordered, ten-binary-digit string discussed above. In either case, transaction information block  330  for the checkout process reports the transaction information to director  106  for persistent storage, e.g., in director  106  or data warehouse  110 . 
     Director  106  may effectuate very fast throughput using disclosed techniques. For example, director  106  may hold incoming transaction information in a first portion of volatile memory until a certain threshold amount of information is received, at which point new incoming information is held in a second portion of volatile memory, the information held in the first portion is transferred to persistent memory, and the process repeated for the second portion of volatile memory. The threshold amount and number of volatile memory portions used may be adjusted based on actual rates of transaction information received. Some examples are expected to record transaction information in director  106  within a 100,000 th  of a second from when the user requests the respective application&#39;s initiation. 
     License checkout block  304  also reports the license checkout to current license checkout information block  336 . Current license checkout information block  336  packages license checkout information and sends it to current usage block  328 . Such license checkout information may include any, or any combination, of: record number, application transaction number, transaction type (here, “checkout”), number of available licenses, usage (e.g., number of checked out licensees at the time of the transaction), timestamp, software application identification, user identification, user actual name, node identification, group identification, pool identification, skill identification, domain identification, site identification, chargecode, license server identification, client identification, identification of the request for usage of the software application, and/or identification of the license for the usage. Current usage block  328  reports this information to director  106 , which maintains a running record of which applications are currently checked out with a license, as well as related information such as the number of currently executing instances of the application, as well as their respective nodes, users, groups, skills, domains, sites, pools, and satisfied license entitlement criteria. 
     Once the user is finished with the software application, or the software application is otherwise closed, per license checkin  332 , client  104  sends a checkin message to license server  102 . Per license checkin  332 , license server  102  checks back in the license obtained per the actions of block  304 . In addition, license server  102  provides an update to current license checkout information block  336 , which updates director  106  via current usage block  328  to account for the checked-in license. Yet further, license server  102  provides updated transaction information to transaction information block  334  for the checkin process, which updates the transaction information stored at director  106  for the particular license checkin event. Such updated information may include a stop time and a duration of usage time, for example. 
     Some examples include active license checkout monitoring. According to such examples, once client  104  successfully checks out a license for a usage of a software application, it thereafter periodically sends an active license message to license server  102 , e.g., every twenty minutes. License server  102  checks for such messages periodically, e.g., hourly. Licenses that have been checked out, but not associated with any active license message for a sufficient period of time, e.g., two hours, may be checked back in automatically. License server  102  may ignore stale active license messages and stale license checkin requests. This functionality can prevent license pool depletion. 
       FIG. 4  is a schematic diagram of a director  106  in a system for managing software licenses according to some examples.  FIG. 4  also depicts client  104  and license server  102 , as well as their communicative couplings. 
     Current consolidated usage block  402  interfaces with license server  102  to receive current usage information per block  328  of  FIG. 3 , such as license checkout information and license checkin information. Current consolidated usage block  402  consolidates the current usage information received from a plurality of license servers, including license server  102 . Current consolidated usage block  402  can provide current usage information for any of the managed software applications upon request. 
     Server transaction information block  404  interfaces with license server  102  to receive transaction information per block  334  of  FIG. 3 . Server transaction information block  404  consolidates the transaction information received from a plurality of license servers, including license server  102 . Server transaction information block  404  can provide transaction information for any of the managed software applications, any user, any node, etc., upon request. 
     Client heartbeats block  406  receives client heartbeat ping messages from clients such as client  104 . Director  106  updates the time of the latest ping message for each such client. Director  106  may use this information to determine which clients are active and in need of software license management services. 
     Software asset management records  408  receives software asset management records  259  from clients such as client  104 . Such records may indicate the software application, the user, the node at which the software application is installed, and the location of the node at which the software application is installed. This information is stored in software asset management records  258 . 
     Token-based software transaction interaction block  410  (e.g. Token Transactions) of director  106  interfaces with token-based transaction interaction block  202  of client  104  to receive license for usage request transaction information when communication with client  104  is available. 
     Enterprise-based software transaction interaction block  412  (e.g. Enterprise Transactions) of director  106  interfaces with enterprise-based software transaction interaction block  204  of client  104  to receive license for usage request transaction information when communication with client  104  is available. 
       FIG. 5  is a schematic diagram of an accountant  108  in a system for managing software licenses according to some examples.  FIG. 5  also depicts process  254  for client  104  to acquire a license for a usage of a software application from license server  102 , and chargecode update process  252 , both components of client  104 .  FIG. 5  also depicts the communicative couplings between accountant  108  and processes  252  and  254 . 
     Chargecode update process  252  of client  104  interacts with lookup current allowed account chargecodes process  502 , which is part of license manager accountant service  508  of accountant  108 . Such interaction may occur upon client  104  requesting a list of permitted chargecodes for a provided user account from accountant  108  per block  256 . In response, lookup current allowed account chargecodes process  502  retrieves the requested information and provides it to chargecode update process  252  of client  104 . 
     Chargecode update process  252  of client  104  also interacts with update current chargecode process  504 , which is part of license manager accountant service  508  of accountant  108 . Such interaction may occur upon client  104  providing current chargecode information per block  258  and providing an update per block  260 . 
     Process  254  for client  104  to acquire a license for a usage of a software application from license server  102  interacts with lookup current chargecode block  506 , which is part of license manager accountant service  508  of accountant  108 . Such interaction may occur per block  234 , at which client  104  contacts accountant  108  to determine whether the software usage is to be associated with a chargecode. 
       FIG. 6  is a schematic diagram of a data warehouse  110  in a system for managing software licenses according to some examples.  FIG. 6  also depicts license servers  102 ,  614 ,  616 , and director  106 , as well as their communicative couplings. Data warehouse  110  may be implemented as cloud storage, local persistent storage, or as a different type of storage 
     Data warehouse  110  may store data provided by director  106 . For example, data warehouse  110  may store software asset management records  602 , e.g., as provided to director  106  per  258  of  FIG. 2 . Also, data warehouse  110  may store token license transaction information  604 , e.g., as provided to director  106  per block  202  of  FIG. 2 . Further, data warehouse  110  may store enterprise license transaction information  606 , e.g., as provided to director  106  per block  204  of  FIG. 2 . 
     Data warehouse  110  may also store data provided by license server  102  (as well as data from other license servers  614 ,  616 ). For example, data warehouse  110  may store transaction information  610  provided by license server  614  per block  330  for the checkout process and updated per block  334  for the checkin process. Data warehouse  110  may further store respective transaction information  610 ,  612  for a plurality of license servers, such as for license servers  614  and  616 . 
     Data warehouse  110  provides the ability to generate analytic reports (also referred to as “analytics”) with specifically filtered data. Specifically, data warehouse  110  stores transaction information, including chargecode information, as described above in reference to  FIG. 3 . Data warehouse  110  may store such information in a database, for example. 
     Analytic report generation may be initiated in a variety of ways. Some examples include a report generation application configured to query the chargecode information (and other transaction information) stored in the database of data warehouse  110 . A user may use the report generation application to specify filtering criteria, and the application may retrieve the corresponding data. Some examples may be configured to periodically (e.g., daily, monthly, quarterly, yearly) generate one or more analytic reports and publish them, e.g., to a password-protected website. Authorized users may be provided with the password in order to obtain the reports. Other chargecode initiation techniques may be used in addition or in the alternative. 
     Analytic reports may include chargecode information and other transaction information filtered according to a variety of criteria. A non-exhaustive list of such criteria is presented below.
         Named application license usage by hour, day, week, month, quarter, year, and all years (this could be in percent of available license or total count of licenses);   Named application license usage by network domain (for example, this could be displayed for a specific network domain or all network domains, e.g., Northwest, Southwest, Midwest, Northeast, Southeast, . . . );   Named application license usage by physical site (for example, the Bellevue site, the Everett site, the Chicago site, etc.);   Named application license usage by employee type (for example, US employees, international employees, US contractors, international Contractors, country specific employees, country specific contractors, . . . );   Named application license usage by employee name (for example, Jane Smith, John Doe, etc.);   Named application license usage by organization group (for example, flight test, engineering, customer service, accounting, human resources, etc.);   Named application license usage by skill classification (for example, software engineers, business management, finance, configuration management, flight test, etc.);   Named application license usage by business unit (for example, product development, product test, product verification and validation, product test, product maintenance, product support, . . . );   Named application license usage by chargecode (for example, FLT_TST_01, ENG_EVAL_02, etc.);   Named application license usage by computer (for example, Computer_00001, Computer, 00002, etc.);   Named application license usage by user account name (for example, astrx_01, detjk_45, etc. A single user could have multiple computer accounts, so this does not necessarily correspond to employee name);   Named application peak license usage for a given time period;   Named application license denials by hour, day, week, month, quarter, year, and all years (this could be in percent of available license or total count of licenses);   Named application license denials by network domain (for example, this could be displayed for a specific network domain or all network domains, e.g. Northwest, Southwest, Midwest, Northeast, Southeast, . . . );   Named application license denials by physical site (for example, the Bellevue site, the Everett site, the Chicago site, etc.);   Named application license denials by employee type (for example, US employees, international employees, US contractors, international Contractors, country specific employees, country specific contractors, . . . );   Named application license denials by employee name (for example, John Smith, Bob Turner, etc.);   Named application license denials by organization group (for example, flight test, engineering, customer service, accounting, human resources, etc.);   Named application license denials by skill classification (for example, software engineers, business management, finance, configuration management, flight test, etc.);   Named application license denials by business unit (for example, product development, product test, product verification and validation, product test, product maintenance, product support, . . . );   Named application license denials by chargecode (for example, FLT_TST_01, ENG_EVAL_02, etc.);   Named application license denials by compute (for example, Computer_00001, Computer, 00002, etc.);   Named application license denials by user account name (for example, astrx_01, detjk_45, etc.: A single user could have multiple computer accounts, so this one is different than employee name);   Named application license denials for a given time period;   List of top named application users (for example, Jane Smith, John Doe, etc.);   List of top named application computers (for example, Computer 9876, Computer 3485, etc.);   List of top named application groups (for example, structures, computing, etc.);   List of top named application sites (for example, Philadelphia site, London site, etc.);   Named chargecode units summary by business unit, organization, employee classification;   List of computers which have the application installed, but are not using it;   List of users which have the application installed, but are not using it; and   List of users average license usage.       

     The usage reports may include charts that track trends, such as graphs of a named application&#39;s usage each day for a month. Any data filtered by one or more of the above criteria may be tracked, and graphed, over any span of time, e.g., daily for a week, month, or year; monthly for a year, hourly for a day, etc. 
       FIGS. 7, 8, and 9  depict a flow diagram for a method  700  for processing a message in a system for managing software licenses according to some examples. Method  700  may be practiced by any of license server  102 , client  104 , director  106 , and/or accountant  108 . In particular, method  700  may be implemented to receive and process any message, as described herein, sent between any of license server  102 , client  104 , director  106 , and/or accountant  108 . Thus, method  700  is described as being performed by a “system component”, which may be any of license server  102 , client  104 , director  106 , or accountant  108 . 
     In general, messages sent between any of license server  102 , client  104 , director  106 , and accountant  108  may have a specified message format. Each message may include a plurality of fields with designated meanings. For example, such messages may have fields for any, or any combination, of: message header, message password, message authentication, message system identifier, message type, message payload, message status, and message checksum. These fields, and their contents, are described in reference to method  700  below. 
     Method  700  may commence at  702 . At  704 , the system component waits to receive a next message. 
     At  706 , the system component receives a message from another system component. The receiving system component extracts data from the header field of the received message. In particular, the receiving system component extracts a message receive address corresponding to the sending message component and a message system name corresponding to the system of the sending system component. 
     At  708 , the system component initializes message tests, and at  710 , the system component decrypts the message. 
     At  712 , the system component parses and extracts the message fields, and at  714 , the system component tests the message format, e.g., by determining whether the expected message fields are present. If not, then per  716 , the message is dropped at  718  and control reverts to  704  where the system component waits for the next message. If the message has a valid format, then per  716 , control passes to  720 . 
     At  720 , the system component extracts the message checksum from the message checksum field. The message checksum may be a hash, e.g., a cryptographic hash, of the remainder of the message, or of any particular field or fields, such as the message payload. At  722 , the system component tests the message checksum, e.g., by re-computing the hash and comparing it to the message checksum provided in the message checksum field. If the message checksum is valid, then per  724 , control passes to  802  of  FIG. 8 . Otherwise, the message is dropped at  718 , and control reverts to  704 , where the system component waits for the next message. 
     At  802 , the system component extracts the message password from the message password field, the message authentication from the message authentication field, the message system identifier (SID) from the message system identifier field, and the message type from the message type field. 
     At  804 , the system component tests the message password. The message password may be one or more random numbers periodically (e.g., every five minutes) generated by a system component such as license server  102 . According to some examples, each such random number is associated with a time period within which it was generated. Each message may include three such random numbers, namely, a random number corresponding to the time period in which the message was sent, a random number corresponding to the time period immediately before the time period in which the message was sent, and a random number corresponding to the time period immediately after the time period in which the message was sent. If any of the passwords are identical to the password for the time period in which the message was received, or for the time periods just prior to and just after the time period in which the message was received, then, per  806 , control passes to  808 . Otherwise, the message is dropped at  812 , and control reverts to  704 , where the system component waits for the next message. 
     At  808 , the system component tests the message system identifier (SID). The message system identifier may be a unique datum associated with the system  100  for managing software licenses. Also per  808 , the system component may test the message authentication. The message authentication may be a digitally signed datum, such as a digitally signed cryptographic hash of the message. A trusted party, such as license server  102 , may provide the digital signature using a private key of an asymmetric cryptographic scheme. The signature may be validated by applying a corresponding public key of the asymmetric cryptographic scheme and determining if the result is as expected, e.g., a cryptographic hash of the message. The message authentication may be omitted, except, for example, if the message requests privileged actions. If the message system identifier matches the unique datum associated with the system, and if the message authentication is properly validated, then, per  810 , control passes to  902 . Otherwise, if either test fails, the message is dropped at  812 , and control reverts to  704 , where the system component waits for the next message. 
     At  902 , the system component tests the message type. The message type may be any of a variety of indications as to the message&#39;s purpose. For example, message types may be checkin, checkout, etc. If the message type is properly formed and an allowed message type (e.g. the message type is valid), then, per  904 , control passes to  906 . Otherwise, the message is dropped at  914 , and control reverts to  704 , where the system component waits for the next message. 
     At  906 , the system component processes the message according to the specified message type. Details of such processing are shown and described herein in reference to  FIGS. 1-6 . Such processing computes the message reply at  908 , which is encrypted at  910 , and sent to the appropriate system component (which may differ from the system component that sent the message) at  912 . Subsequently, control reverts to  704 , where the system component waits for the next message. Note that the message status field may be used in return messages to indicate whether the initial message was successfully or unsuccessfully received. 
       FIG. 10  is a flow diagram of a process  1000  for managing software licenses according to some examples. Method  1000  may be implemented using a system such as system  100  of  FIG. 1 , e.g., including license server  102 , client  104 , director  106 , accountant  108 , and data warehouse  110 . 
     At  1002 , client  104  detects the initiation of a managed software application, e.g., as described above in reference to  FIG. 2 . Previously, the software application may have been installed using a software installer as described above in reference to  FIG. 1 . 
     At  1004 , client  104  suspends execution of the software application, e.g., as described above in reference to  FIGS. 2 and 3 . 
     At  1006 , client  104  determines that the software application is subject to a plurality of software license entitlement criteria defined by at least one software license agreement, e.g., as described above in reference to  FIGS. 2 and 3 . 
     At  1008 , client  104  requests from license server  102  a license for a usage of the software application, e.g., as described above in reference to  FIGS. 2 and 3 . 
     At  1010 , license server  102  determines that the usage of the software application satisfies the plurality of license entitlement criteria, e.g., as described above in reference to  FIGS. 2 and 3 . 
     At  1012 , license server  102  provides a license for the usage of the software application to client  104 , e.g., as described above in reference to  FIGS. 2 and 3 . 
     At  1014 , client  104  resumes the initiation of the software application, e.g., as described above in reference to  FIGS. 2 and 3 . 
     II. Software License Management Security 
     Section II presents in detail techniques for securing the software license management processes described above in Section I. Such techniques may thwart a malicious user from tampering with or disabling the software license management processes. 
       FIG. 11  is a schematic diagram  1100  of an architecture and a technique for securing client software according to some examples. According to some examples, the client software installed on a client, such as client  104 , includes two components. A first component, referred to as tracking software  1102 , performs actions related to managing software licenses, such as the actions shown and disclosed herein in reference to  FIGS. 2 and 10 . A second component, referred to herein as monitoring software  1104 , helps to ensure that tracking software  1102  is not tampered with, among other actions as shown and described presently. Tracking software  1102  may run as an administrator, and monitoring software  1104  may run as the respective user of tracking software  1102 . In general, a user of the client computer is able to see certain actions performed by tracking software  1102 , but the actions of monitoring software  1104  may be hidden from such a user. 
     In general, tracking software  1102  and monitoring software  1104  periodically check the execution status of each-other. If one detects that the other is not executing, then it restarts the other and sends an alert, such as an email message, to an administrator, for example. The period may be as short as every millisecond or as long as every minute, according to some examples. 
     Thus,  FIG. 11  depicts tracking software  1102  and monitoring software  1104 , both of which execute on a client computer such as client  104  of  FIG. 1 . Tracking software  1102  sends a request  1106  for the status of monitoring software  1104 . The request may be sent to monitoring software  1104  as shown in  FIG. 11 , or may be sent to an operating system, e.g., using an active directory feature. At  1108 , tracking software  1102  obtains a status of monitoring software  1104 . In the event that the status indicates that monitoring software  1104  is not executing, tracking software  1102  restarts  1110  monitoring software  1104 . The restarting may be accomplished using any known technique by which one software application initiates the execution of another software application. 
     Further, tracking software  1102  may send an alert to an appropriate individual or individuals indicating that the monitoring software was restarted. The alert may be sent via email, for example. The alert may include relevant information such as the client computer identification, the user identification, the time of the restart, which tracked software applications were executing at the time, etc. 
     Note that, in general, if tracking software  1102  runs as an administrator, additional actions may be used in order for it to send messages out. According to some examples, tracking software  1102  may drop messages into a file that is visible to monitoring software  1104 . Monitoring software  1104 , or a separate software application that can access the file, may periodically scan the file, and convey any messages deposited therein to the user and/or other individuals using any of the disclosed communication channels. 
     Further shown in  FIG. 11 , monitoring software  1104  sends a request  1112  for the status of tracking software  1102 . The request may be sent to monitoring software  1102  as shown, or may be sent to an operating system, e.g., using an active directory feature. At  1114 , tracking software  1102  obtains a status of monitoring software  1104 . In the event that the status indicates that tracking software  1102  is not executing, monitoring software  1104  restarts  1116  tracking software  1102 . Further, monitoring software  1104  may send an alert as described above with respect to tracking software  1102 . 
       FIG. 12  is a flow diagram of a method  1200  for securing client software by restarting monitoring software according to some examples. In particular, the present description of method  1200  elaborates on part of the description presented with respect to  FIG. 11 , above. Thus, method  1200  may be performed by the tracking software  1102  component of the client software on client  104 , for example. 
     At  1202 , tracking software  1102  tracks a usage of a software application. The actions of  1202  may be as shown and described herein in reference to  FIG. 10 , for example. 
     At  1204 , tracking software  1102  obtains a status of monitoring software  1104 . The status may be obtained by sending a query to monitoring software  1104 , through the use of an operating system active directory, or using a different technique. In response to the query, tracking software  1102  obtains a status of monitoring software  1104 . The status may be in the form of a return message that includes an indicator of the execution status, e.g., “0” for not currently executing and “1” for currently executing. Alternately, the status may be in the form of a lack of response after a specified timeout period, e.g., one second. Such a lack of response within the timeout period may indicate that monitoring software  1104  is not currently executing. 
     At  1206 , tracking software determines whether the obtained status indicates that monitoring software  1104  is not executing. If it is executing, then control reverts to  1204 , where tracking software  1102  obtains a status of monitoring software  1104 . This reversion may include a specified delay according to some examples, so that the status is obtained periodically with a known temporal period, e.g., in a range from every millisecond to every minute. Otherwise, if monitoring software  1104  is not executing, then control passes to  1208 . 
     At  1208 , tracking software  1102  restarts monitoring software  1104 . This may be accomplished using any technique by which an executing software application may initiate the execution of another software application. 
     At  1210 , tracking software  1102  sends an alert indicating that monitoring software  1104  was restarted. The alert may be sent via a variety of communication channels, including by way of non-limiting example: email, text message, pop-up message, or automated phone call. The alert may be sent to any of a variety of individuals or groups, including any, or a combination, of an administrator of the computer executable software for tracking usage of at least one software application, the user that was logged in to the client when the restart occurred, a supervisor of the user that was logged in to the client when the restart occurred, a systems administrator, and/or any other interested individual. The alert may include relevant information, such as the client computer identification, the user identification, the time of the alert, and which tracked software applications were executing at the time. 
       FIG. 13  is a flow diagram of a method  1300  for securing client tracking software  1102  according to some examples. In particular, method  1300  may be used to detect tampering with tracking software  1102 . Method  1300  may be performed by monitoring software  1104 , for example. 
     At  1302 , method  1300  stores file and directory data for tracking software  1102 . This action may occur as part of the installation of tracking software  1102 . The data may be stored locally on client  104  e.g., in a file accessible by monitoring software  1104 . The data may include the names and locations of the files and directories that constitute tracking software  1102 . Further, the data may include checksums for each file that constitutes tracking software  1102 . Such checksums may be obtained by applying a hash function to each such file. The outputs of the hash function may be stored as the respective checksums for the files. The data stored per  1302  may be encrypted and stored in encrypted form according to some examples. The encryption may be symmetric key encryption, and the key may be stored on client  104 , e.g., embedded in tracking software  1102  or monitoring software  1104 , according to some examples. When the client software is upgraded, the key may be changed out. 
     At  1304 , monitoring software  1104  checks whether tracking software  1102  files and directories are present. To do so, monitoring software  1104  accesses the data stored at  1302  and compares it to the files and directories for tracking software  1102  currently present on client  104 . 
     At  1306 , if monitoring software detects that each file and directory is present, then control passes to  1308 . Otherwise, if monitoring software  1104  detects that at least one file or directory is not present, then control passes to  1312 , where an alert is sent, as elaborated below. 
     At  1308 , monitoring software  1104  checks whether the tracking software  1102  files and directories are unchanged. To do so for the directories, monitoring software  1104  may compare the directories currently present to the expected directories per the data stored at  1302 . A tree traversal algorithm may be used to do so. To check whether the files of tracking software  1102  are unchanged, monitoring software  1104  may compute checksums for each currently existing file (e.g., using a hash function) and then compare such checksums to the data stored at  1302 . If the checksums match (e.g., are identical) then a conclusion may be reached that the files are unchanged. 
     At  1310 , monitoring software  1104  detects whether the tracking software files and directories are unchanged. If both the directories and files are unchanged per  1308 , then control reverts to  1304 . A delay may be inserted before the reversion in order to ensure that the checking of  1310  is performed periodically with a known period, e.g., in a range from every millisecond to every minute. Otherwise, if at least one file or at least one directory is not unchanged, then control passes to  1312 . 
     At  1312 , an alert is sent to indicate that at least one file or directory of tracking software  1102  has changed. The alert may be sent via a variety of communication channels, including by way of non-limiting example: email, text message, pop-up message, or automated phone call. The alert may be sent to any of a variety of individuals or groups, including any, or a combination, of an administrator of the computer executable software for tracking usage of at least one software application, the user that was logged in to the client when the alert was generated, a supervisor of the user that was logged in to the client when the alert was generated, a systems administrator, and/or any other interested individual. The alert may include relevant information, such as the client computer identification, the user identification, the time of the alert, which tracked software applications were executing at the time, an identification of the file(s) or director(ies) that were absent or changed, and an indication as to whether such file(s) or director(ies) were missing or changed. 
       FIG. 14  is a flow diagram of a method  1400  for detecting configuration file tampering according to some examples. Such configuration files represent software identification data for the software applications being tracked and managed. A malicious user may attempt to thwart such tracking and management by tampering with the configuration files. Method  1400  may be used to detect and report such tampering. Method  1400  may be performed by monitoring software  1104  and/or tracking software  1102 , for example. 
     At  1402 , method  1400  stores software identification data for the software applications being managed in one or more configuration files. This action may occur as part of the installation of the software applications to be managed. In particular, the software applications may be installed using a software application installer, as described above in reference to  FIG. 2 . Such an installer may generate and store the configuration files, e.g., one per installed software application or one per installed software application trait. The software identification data may include the names and locations for each file for each managed software application, the directories for each software application, the respective license vendor, etc. The configuration files may be stored locally, e.g., in a file accessible by monitoring software  1104 . The data stored per  1402  may be encrypted and stored in encrypted form according to some examples. The encryption may be symmetric key encryption, and the key may be stored on client  104  according to some examples. Further, method  1400  may compute and store checksums for the configuration files at  1402 . The checksums may be the result of applying a hash function to the contents of the configuration files. The checksums may be encrypted and stored in a location separated from the storage location of the key used for encryption. 
     At  1404 , method  1400  checks whether software configuration files are present for each installed software application. To do so, method  1400  accesses the data stored at  1402  and compares it to the files and directories for the software applications currently present on client  104 . 
     At  1406 , if a software application installed on client  104  is not represented by the configuration files stored at  1402 , then control passes to  1412 , where an alert is sent as elaborated below. Otherwise, if all configuration files are present, then control passes to  1408 . 
     At  1408 , method  1400  checks whether the software identification data in the configuration files is unchanged. To check whether the software identification data is unchanged, method  1400  may compute checksums for each currently existing file (e.g., using a hash function) and then compare such checksums to the checksums stored at  1302 . If the checksums match (e.g., are identical) then a conclusion may be reached that the files are unchanged. 
     At  1410 , if the software identification data is unchanged, then control reverts to  1404 . This reversion may include a specified delay according to some examples, so that the tampering detection may be performed periodically with a known temporal period, e.g., in a range from every millisecond to every minute. Otherwise, if the software identification data is not unchanged, then control passes to  1412 . 
     At  1412 , an alert is sent to indicate that the software identification data has changed. The alert may be sent via any of the communication channels, and to any of the individuals or groups, as described above in reference to  1312  of method  1300 . The alert may include relevant information, such as the client computer identification, the user identification, the time of the alert, which tracked software applications were executing at the time, an identification of the configuration files that were absent or changed, and an indication as to whether such configuration files were missing or changed. 
     Examples may include a variety of features beyond those disclosed above. Some examples may include a startup operation that checks for any upgrades to the software for tracking usage of at least one software application, including the client software, for example. If an upgrade is detected, then the startup operation shuts down the service, updates the software, computes and stores new checksums and configuration files, and restarts the software. Some examples may hide the home directory of the client software. This may be accomplished by changing the attributes of the directory, for example. In some examples, to properly shut down the client software, a message is simultaneously sent to tracking software  1102  and monitoring software  1104 . Such a simultaneous message may ensure that the restarting functionality described herein, e.g., in reference to  FIG. 11 , is prevented. 
     The present disclosure is not to be limited in terms of the particular examples described in this application, which are intended as illustrations of various aspects. Many modifications and variations can be made without departing from its spirit and scope, as will be apparent to those skilled in the art. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is also to be understood that the terminology used herein is for the purpose of describing particular examples only, and is not intended to be limiting. 
     With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations may be expressly set forth herein for sake of clarity. 
     It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to examples containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and/or “an” should be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of “two recitations,” without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to “at least one of A, B, or C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.” In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group. 
     While various aspects and examples have been disclosed herein, other aspects and examples will be apparent to those skilled in the art. The various aspects and examples disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.