Software license manager

Abstract

The present invention relates to software license management, and more particularly to techniques for controlling access to a software application in accordance with at least one software license agreement using a client computer and a server computer. The client computer is configured to detect initiation of the software application, suspend an execution process of the software application, determine that the software application is subject to a plurality of software license authorization criteria defined by the at least one software license agreement, and request a license from the server computer to use the software application on the client computer. The server computer is configured to determine that use of the software application on the client computer satisfies the plurality of software license authorization criteria, and provide the license to the client computer to use the software application on the client computer. The client computer is configured to resume initiation of the software application.

Description

Technical Field

[0001] This disclosure relates to software licensing, specifically ensuring compliance with software license requirements. Background Technology

[0002] Some known techniques for software license management are cryptographic, operating by encapsulating an executable binary 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 the license is available, the license server uses the cryptographic key to send a response to the encapsulated runtime environment to unlock the application executable and execute the application binary. If the license is unavailable, the license server sends a response to the encapsulated runtime environment to display a license denial message to the end user. Once the executable terminates, the runtime environment sends a license check-in message to the license server.

[0003] Some known technologies used for software license checkout and check-in embed a set of tools within the software application executable to perform the checkout and check-in of licenses from a license server. These embedded utilities can decrypt encrypted application executables and are typically provided by license management system vendors who do not develop their own application executables. Therefore, these known technologies may not be usable for managing licenses for arbitrary software applications. Even if these technologies are applicable to a specific software application, the associated costs are passed on to the user, even if the user does not use that specific software application, because the license management vendor provides the embedded tools.

[0004] A license server can be used when an entity needs an automated method to enforce the terms and conditions of a vendor's application license agreement. However, the vast majority of software subject to software license agreements is designed to be sold and distributed on a one-machine-per-license basis. Therefore, such software is typically not provided to work with a license server.

[0005] For a typical application to work with an encryption-based license server, the license management team must obtain tools from the license manager vendor to encrypt the application suites they want the company to use, and then distribute only those encrypted applications. Therefore, these encryption-based technologies require significant administrative effort. Because these technologies involve modifying executable files using encryption, they can cause program malfunctions in some cases. Consequently, vendors may refuse customer support for application software because they may deem these encryption methods unsupportable and refuse to provide technical assistance.

[0006] A common practice for application vendors is to specify a list of multiple terms and conditions for purchased software license agreements. These may include limits on the number of concurrent uses of a license (parallel jobs, parallel nodes, and parallel users), restrictions on which nodes can access the license, restrictions on which users can access the license, and / or restrictions on whether the license can be deployed domestically or internationally. Additionally, vendors may specify that a set of licenses can only be used by individuals who are members of a specific group, and / or by individuals who are members of a specific skill set. Typically, these terms and conditions are connect (“AND”) conditions, rather than separate (“OR”) conditions.

[0007] However, existing software license management solutions at best offer the ability to evaluate license usage requests based on a single criterion. The types of license authorization criteria used in existing solutions include parallel jobs, parallel nodes, parallel users, lists of nodes, or lists of users. Existing solutions require that, for a given application, only one license authorization criterion be used to determine whether license authorization is granted or denied. Specifically, the vast majority of application license managers use some form of parallel software license (a single criterion) to determine the software licensing outcome.

[0008] Furthermore, it is common for companies to deploy software licenses to clients, leading to breaches of terms and conditions, which can result in substantial penalties. For example, most software applications lack automatic license check-out / check-in management software to enforce relevant terms and conditions. Additionally, software vendors frequently add combinations of license restrictions (e.g., restrictions on the list of clients and the list of user account names).

[0009] To optimize software license deployment and usage, it is desirable to know where available licenses are stored, where they are deployed, who is using them, how frequently they are used, and how much maintenance is required. Furthermore, it should be possible to identify unused or rarely used licenses for all types of software. Solutions exist that capture some of this information only for parallel software licenses. However, software licenses based solely on parallel software licenses account for approximately 2% of software titles. The remaining software titles may be subject to the terms and conditions of software license agreements based on nodes, users, tokens, enterprises, groups, skills, pools, sites, or domains.

[0010] Large companies need to allocate software license costs across their various projects for accounting purposes. This is especially important when software license terms are charged on a usage, job, or hourly basis. Employees may work on various projects and should be appropriately tooled, considering costs. For companies with a large number of charge codes to choose from, too many options increase the burden of finding the desired charge code and the risk of choosing the wrong path. In a software license manager that fully allows charge code management, a typical solution involves multiple transactions between the user and the license server. Users can send requests for available charge codes, the server can respond to the requests, and users can send updates that the server can acknowledge or not acknowledge. Superficially, these transactions may seem normal, but when the server may need to process tens of thousands of requests per hour, any transaction other than license check-in / check-out will negatively impact the maximum throughput of license requests that can be processed per hour.

[0011] Software license management services can be run on multiple license management servers that require synchronized license management configurations. Maintaining these license management configurations can be time-consuming and error-prone. Furthermore, managing and supporting hundreds of thousands to millions of clients is extremely laborious and time-consuming. In addition, troubleshooting, debugging, and resolving client software issues can be very complex.

[0012] Application service maintenance support is typically performed by remotely logging into the target and searching for potential misconfigurations. This diagnostic and / or update process is often extremely laborious. Furthermore, obtaining detailed diagnostic information for analysis is practically nonexistent, making it nearly impossible to replicate the problem / failure. Summary of the Invention

[0013] Based on some examples, a method is proposed to control access to a software application using non-transitory client computer software installed on a client computer and non-transitory server computer software installed on at least one server computer, according to at least one software license agreement. The method includes: detecting the startup of the software application on the client computer by the client computer software executing on the client computer; suspending the execution process of the software application by the client computer software executing on the client computer; determining that the software application is subject to multiple software license authorization criteria defined by the at least one software license agreement by the client computer software executing on the client computer; requesting a license to use the software application on the client computer from the server computer software executing on the server computer; determining that the use of the software application on the client computer satisfies the multiple software license authorization criteria by the server computer software executing on the server computer; providing the license to use the software application on the client computer software executing on the client computer by the server computer software executing on the client computer; and resuming the startup of the software application on the client computer by the client computer software executing on the client computer, causing the client computer to execute the software application.

[0014] Various optional features of the above examples include the following. Multiple software license authorization criteria may include at least criteria regarding parallel jobs, parallel nodes, parallel users, site lists, node lists, user lists, domain lists, group lists, skill lists, and pool lists. The method may include: detecting the launch of a second software application on a client computer by client computer software executing on the client computer; suspending the execution process of the second software application by the client computer software executing on the client computer; determining that the second software application is subject to an enterprise-wide license for the second software application by the client computer software executing on the client computer; requesting a license from the server computer software to use the second software application on the client computer by the client computer software executing on the client computer; storing transaction information about the use of the second software application on the client computer by the client computer software executing on the client computer; and resuming the launch of the second software application on the client computer by the client computer software executing on the client computer, causing the client computer to execute the second software application. The client software may configure the client computer to display an error message for failed software application execution attempts, wherein the error message indicates that the associated software license authorization criteria failed. Client computer software can be configured to bypass a request for a license to use a software application on the client computer from server computer software if a license token is detected on the client computer. The method may include: server computer software executing on the client computer recording transaction information related to the use of the software application on the client computer, wherein the transaction information includes at least: a software application identifier, a client computer identifier, a duration of use, and software license authorization criterion satisfaction data. Any part of the software application may not be encrypted. The method may include: client computer software executing on the client computer receiving an account charging code associated with a user of the software application; the client software executing on the client computer providing the account charging code to an accounting component; and the accounting component storing software usage data, which includes at least a charging code associated with at least the identifier of a user of the software application; wherein the software usage data may be searched for a specific usage criterion. At least the client computer software and server computer software may include an internal debug log generator configured to store debug files, which include at least routine identifiers, variable values, and timestamps. The method may include: using a configuration application to install the software application on the client computer, the configuration application configuring the client computer to perform steps related to detecting the use of the client software.

[0015] Based on various examples, a system for controlling access to a software application according to at least one software license agreement is proposed. The system includes a client computer and a server computer. According to the system, the client computer is configured to detect the launch of the software application on the client computer; the client computer is configured to suspend the execution process of the software application; the client computer is configured to determine that the software application is subject to multiple software license authorization criteria defined by the at least one software license agreement; the client computer is configured to request a license from the server computer for using the software application on the client computer; the server computer is configured to determine that the use of the software application on the client computer satisfies the multiple software license authorization criteria; the server computer is configured to provide the client computer with a license for using the software application on the client computer; and the client computer is configured to resume the launch of the software application on the client computer, causing the client computer to execute the software application.

[0016] Various optional features of the above examples include the following. Multiple software license authorization criteria may include criteria at least regarding parallel jobs, parallel nodes, parallel users, site lists, node lists, user lists, domain lists, group lists, skill lists, and pool lists. The client computer may also be configured to: detect the launch of a second software application on the client computer; suspend the execution process of the second software application; determine that the second software application is subject to an enterprise-wide license for the second software application; request a license from the server computer software to use the second software application on the client computer; store transaction information regarding the use of the second software application on the client computer; and resume the launch of the second software application on the client computer, causing the client computer to execute the second software application. The client computer may also be configured to display an error message for failed software application execution attempts, wherein the error message indicates that the associated software license authorization criterion has failed. The client computer may also be configured to bypass requesting a license from the server computer software to use the software application on the client computer if the client computer detects a license token on the client computer. The server computer may also be configured to log transaction information regarding the use of the software application on the client computer, wherein the transaction information includes at least: a software application identifier, a client computer identifier, a duration of use, and software license authorization criterion satisfaction data. No part of the software application may be encrypted. The client computer may also be configured to receive an account charging code associated with a user of the software application; the client computer may also be configured to provide the account charging code to an accounting component; and the accounting component may be configured to store software usage data, which includes at least a charging code associated with an identifier of the user of the software application; wherein the software usage data can be searched for specific usage criteria. At least the client computer and the server computer may include an internal debug log generator configured to store debug files, which at least include routine identifiers, variable values, and timestamps. The system may include a configuration application for installing the software application on the client computer, wherein the configuration application configures the client computer to detect the launch of the software application on the client computer. Attached Figure Description

[0017] The accompanying drawings are incorporated in and form a part of this specification. The drawings illustrate the teachings and, together with the specification, serve to explain the principles of this disclosure.

[0018] Figure 1 These are schematic diagrams of systems for managing software licenses, based on some examples;

[0019] Figure 2 These are schematic diagrams of clients in a system used to manage software licenses, based on some examples;

[0020] Figure 3This is a schematic diagram of a license server based on some examples;

[0021] Figure 4 This is a diagram illustrating an administrator in a system used to manage software licenses, based on some examples.

[0022] Figure 5 This is a diagram illustrating accounting in a system used to manage software licenses, based on some examples;

[0023] Figure 6 This is a schematic diagram of a data warehouse in a system for managing software licenses, based on some examples;

[0024] Figure 7 This is a flowchart of a method for processing messages in a system for managing software licenses, based on some examples;

[0025] Figure 8 continue Figure 7 Flowchart;

[0026] Figure 9 Finish Figure 7 and Figure 8 Flowchart;

[0027] Figure 10 This is a flowchart of a process for managing software licenses, based on some examples.

[0028] It should be noted that some details in the accompanying drawings have been simplified and drawn to facilitate understanding of this teaching, rather than to maintain strict structural accuracy, detail, and proportion. Detailed Implementation

[0029] Reference will now be made in detail to the disclosed examples, which are illustrated in the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings to denote the same or similar parts. In the following description, reference is made to the drawings that form part of it and illustrate particular examples by way of example. These examples are described in sufficient detail to enable those skilled in the art to practice them, and it will be understood that other examples may be utilized and changes may be made without departing from the scope of this disclosure. Therefore, the following description is merely exemplary.

[0030] Some examples provide solutions for managing software licenses. Additionally, some examples provide software application license terms and conditions enforcement applications. Furthermore, some examples provide software application hybrid license management managers. Some examples offer all of the aforementioned features and advantages. For example, companies needing to manage software license pools can utilize the disclosed systems and methods, which employ a client / server process-based approach to enforce vendor application license terms and conditions.

[0031] In some examples, each client has tamper-proof software loaded to monitor running processes on the client machine. When it detects the startup of a managed application process, it briefly pauses the process and contacts a license server to attempt to check out the license for the managed application. If the license request is granted, it allows the process to resume. If the license request is denied, the client software terminates the process and notifies the user. When the process terminates, the client software re-checks in the license. In some such examples, the managed software application is not encrypted.

[0032] Some examples provide the capability to determine whether a license to use the software application can be granted based on an evaluation of multiple licensing criteria defined by the associated software license agreement. That is, some examples provide an automatic enforcement of multiple simultaneous licensing criteria. These criteria can include all, any, or any combination of the following: parallel jobs, parallel nodes, parallel 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 only if the request indicates that such use has passed all ten simultaneous licensing criteria. This mechanism can be executed in response to dynamic, real-time requests for a license to use the software application from the client to the license server.

[0033] Some examples demonstrate efficient management of charge codes. These examples allow querying and selecting valid charge codes without meaningfully impacting the network operations of the license server. Alternatively, these examples may allow specifying filters to restrict charge code selection.

[0034] Some examples provide the ability to easily manage synchronized license management configurations across multiple license authorization servers. Additionally, some examples offer service support tools that allow for remote diagnostic debugging, configuration management, application license notifications and warnings, option selection, token license authorization creation and deletion, and inventory and configuration updates.

[0035] These and other features and advantages are described in detail below.

[0036] Figure 1 This is a schematic diagram of a system 100 for managing software licenses (e.g., for controlling access to one or more software applications) based on some examples. Figure 1 The boxes in the diagram represent computing devices, and the arrows represent communication channels such as the Internet. Therefore, system 100 can be implemented in a distributed manner (e.g., via the Internet). As shown, Figure 1A license server 102 is described as communicatively connected to client 104. Server 102 is also communicatively connected to supervisor 106 and data warehouse 110 (which may be an information technology service management data warehouse 110). Client 104 is also communicatively connected to supervisor 106 and accountant 108. Client computer software is installed on client 104 to instruct client 104 (e.g., one or more electronic processors of client 104) to perform the actions described herein. Similarly, license server 102, supervisor 106, accountant 108, and data warehouse 110 are equipped with corresponding software to instruct their respective machines (e.g., their respective one or more electronic processors) to perform the actions described herein. The operation of license server 102, client 104, supervisor 106, accountant 108, and data warehouse 110 is described in further detail below.

[0037] System 100 may include service support tools as described herein. These tools provide solutions for troubleshooting application license authorization configuration issues and for configuring service support options. Typically, the service support tools can be executed on a network machine (e.g., a node) within the same network as System 100. From this networked machine, the service support tools can be used to perform the following tasks on client 104: debugging, managing security, enabling or disabling email alerts for debugging errors, generating a software application inventory, generating license manager reports, locating accounting documents, and retrieving token records. Furthermore, from the networked machine, the service support tools can be used to perform the following tasks on server 102: debugging, checking in or checking out licenses for software applications, starting or stopping charge code timers, creating or deleting tokens, and retrieving data about any managed software applications, any users, any sites, and any nodes. Additionally, service notifications and warning messages can inform users of upcoming updates and outages.

[0038] The service support tool provides the ability to enable and disable debugging and trace diagnostics and log these in a debug log file. This log file can then be sent to application experts for analysis. The service support tool's debugging capabilities are superior to existing technologies that require compiling code with a debugger open. Instead, each of client 104, license server 102, supervisor 106, and accountant 108 has its own built-in debugging system. These systems write various events, routines, variable values, and timestamps to the log file. Enabling debugging of the service support tool's log file during operation of any of client 104, license server 102, supervisor 106, or accountant 108 results in the creation of a thread that generates verbose log files.

[0039] According to some examples, license server 102, supervisor 106, and accountant 108 can be configured to require a key for execution. Therefore, these examples provide protection against tampering and prevent malicious installation. According to these examples, system components (e.g., one of license server 102, supervisor 106, and accountant 108) check for the presence of a license key in a local configuration file, and if the key is not present, execution is not performed. Each system component has an associated Media Access Control (MAC) address. Furthermore, each system component has an associated system identifier. The key used for a given system component can be formed as a concatenated cryptographic hash of the following: the MAC address of the system component, the system identifier of the system component, and a random number.

[0040] Figure 2 This is a schematic diagram of client 104 in a system for managing software licenses, based on some examples. Figure 2 The diagram also depicts supervisor 106, accountant 108, and license server 102, along with their communication connections. Client 104 electronically stores an ordered list of servers 102, supervisor 106, and accountant 108 with which it can communicate. If a corresponding server 102 (or supervisor 106 or accountant 108) is closed, client 104 may attempt to communicate with the next server 102 (or supervisor 106 or accountant 108) on its list.

[0041] To manage software applications, some examples establish software asset management records 259. For example, when a software application is installed, upgraded, or removed on client 104, these records may be generated by client 104 and sent to supervisor 106. Specifically, some examples include a software application installer that installs and uninstalls software applications on clients (e.g., client 104). When a new software application is installed or updated, the software application installer generates and sends a message to supervisor 106 indicating the software application, the user, the node where the software application is installed, and the location of the node where the software application is installed. This information is generated in software asset management record 258 and sent to supervisor 106. Furthermore, when a new software application is installed, the software application installer configures the software application such that its launch can be intercepted while license requirements are checked, as detailed herein. It should be noted that using the described software application installer is superior to existing techniques that rely on network scanning to identify managed software, at least because such network scans are resource-intensive and slow (e.g., taking approximately several months).

[0042] Based on some examples, there are three different categories of software license authorization that can be defined by software license agreements (especially their related terms and conditions). The first category is token-based software license authorization, the second is enterprise-based software license authorization, and the third is server-based software license authorization. These categories will now be described in detail.

[0043] Token-based software license authorization involves data residing on each client 104 and does not require the involvement of the license server 102 when using the corresponding software. Token-based software license authorization can be used to allow a client to execute software, for example, when client 104 is not connected to any license server 102 in communication. Therefore, token-based software license authorization can be used when client 104 is expected to be offline for an extended period. When client 104 attempts to execute the managed software application, it first checks if a local token is available. If available, the token is used instead of requesting a license from server 102. If client 104 has the appropriate token, token-based software license authorization thus bypasses the client 104's request for a license to use the software application from license server 102. For token-based software license authorization, the license using the request transaction information is captured by client 104 and later transmitted to supervisor 106 when communication between these computing devices becomes available. These token-based software license authorization interactions between client 104 and license server 102... Figure 2 The middle part is represented by box 202.

[0044] Enterprise-based software license authorization involves an enterprise license, where the entire enterprise can simultaneously utilize numerous copies of a given software application as it wishes. For enterprise-based software license authorization, client 104 may request an enterprise license to use the software application from license server 102. If successful, the enterprise license for use is checked out from server 102, and the application license transaction (e.g., enterprise transaction) represented by box 204 is captured on license server 102. If the request for an enterprise license to use the software application is unsuccessful for any reason (e.g., license server 102 license denial, license server 102 is offline or unavailable, etc.), the software application is allowed to execute in any manner, and the relevant application license transaction 204 is captured on client 104 and later transmitted to supervisor 106. Because enterprise-based software license authorization typically allows an unlimited number of managed software applications to execute simultaneously, the existence of enterprise-based software license authorization is typically checked after token-based license authorization and before server-based software license authorization.

[0045] The token-based and enterprise-based software license authorizations described above do not utilize communication between client 104 and license server 102 when using the corresponding software application. In contrast, the server-based software license authorizations described below typically utilize communication between client 104 and license server 102 when using the corresponding software application.

[0046] Server-based software licensing involves interaction between client 104 and server 102. (See reference...) Figure 2 The following is a description of the process 254 from the perspective of client 104, in which client 104 obtains a license to use the software application from license server 102.

[0047] At 220, the user at client 104 initiates (e.g., starts) an instance of the software application managed by the example. The user can do this using standard application launch techniques (e.g., clicking an icon). From the user's perspective, the process is transparent.

[0048] At 222, the instance of the sample client software monitors the execution process of client 104. In doing so, it determines that a new instance of the monitored software application has been invoked. Therefore, at 224, the client software suspends the execution process of the monitored software application.

[0049] At 226, the executing client software locates the software application's account, and at 228, checks the account to determine if a license is required for the requested software application. As part of 226, client 104 may first check for the existence of a token-based software license, then for an enterprise-based software license, and then for a server-based software license. If no license is required, control proceeds to box 230, whereby the software application process is allowed to resume execution until, at 232, the user exits the software application and process 254, in which client 104 obtains a license to use the software application from license server 102, terminates. Otherwise, if a server-based software license is required for the requested software application, control proceeds to box 234.

[0050] In box 234, the executing client software contacts accountant 108 to determine whether software usage is associated with a charging code. To do this, client 104 contacts accountant 108, requesting accountant 108 to instruct (e.g., query) on the charging code currently used for a particular software application.

[0051] Typically, Accounting 108 maintains an electronically stored record of the user's previously selected current billing code. In addition, Accounting 108 maintains a list of allowed billing codes for each user. For example, Accounting 108 can use Active Directory features of the client operating system to obtain and update this list. Accounting 108 also maintains a record of the current billing codes for each user it manages.

[0052] To maintain a record of the current charge codes for users of client 104, accountant 108 may interact with client 104 in charge code update process 252 as follows. At box 256, client 104 may request a list of charge codes that the managed software user in question is allowed (e.g., permitted) from accountant 108. Client 104 receives the list and generates a dialog (e.g., a pop-up) to display to the user of client 104. At box 258, the dialog allows the user to select or change the current charge code for the requested user. At box 260, once the user enters (e.g., updates) the current charge code information, charge code update process 252 of client 104 provides the information to accountant 108. It should be noted that charge code update process 252 can be executed at any time, not limited to during process 254 during which client 104 obtains a license to use the software application from license server 102. According to some examples, the user of client 104 may initiate charge code update process 252 at any time (e.g., by clicking an icon).

[0053] Therefore, in box 234, if the charging code is currently used for the managed software application and the user of client 104, then accountant 108 replies with the current charging code.

[0054] In box 236, client 104 determines that the software application is subject to multiple software license authorization standards defined by at least one software license agreement, and requests (e.g., requests check-out) a license to use the software application from license server 102. For example, the request may include an identifier for the software application, a user, a node, a charge code, a domain, a pool, or a site. The request can be sent using any of various protocols such as TCP, HTTP, or XML. License server 102 performs a process to determine whether to provide client 104 with the requested license for the software application, as described below. Figure 3 Explained.

[0055] In box 238, client 104 determines whether the license checkout request was successful and whether license server 102 has provided a license for use. If not, control transfers to box 240, where client 104 terminates the execution process of the software application, and then to box 242, where client 104 displays an error message to the user indicating that the license checkout request was rejected. After box 242, control transfers to box 232, where process 254 of client 104 obtaining a license for use of the software application from license server 102 terminates.

[0056] If, at box 238, client 104 determines that the request was successful and a license to use the software application has been provided, control transfers to box 244, where client 104 allows the software application's execution process to resume normally. During the execution of the managed software application, client 104 continuously monitors the execution of the managed software application at box 246 and checks at box 248 whether the execution is still active (e.g., an application process exists). If the software application is still active, control transfers back to box 246, and monitoring repeats. If the software application ceases execution, control transfers to license check-in at 250.

[0057] At license check-in 250 (or alternatively, check-in), client 104 sends a message to license server 102 requesting re-check-in of the license for the managed software application. Once the license is re-checked in, license server 102 sends a confirmation message back to client 104. Subsequently, at box 232, the process 254 in which client 104 obtains the license for the software application from license server 102 ends.

[0058] Client 104 also includes a client heartbeat box 262. Typically, at fixed intervals (e.g., daily, every four hours, every hour, every 30 minutes, etc.), client heartbeat box 262 sends a simple "ping" message to supervisor 106. The ping message includes the client's identifier. Supervisor 106 updates the time of the latest ping message for each client (e.g., client 104).

[0059] Figure 3 This is a schematic diagram of a license server 102 in a system for managing software licenses, based on some examples. Figure 3 The client 104 and supervisor 106, and their communication connection, are also depicted. The following is a description of process 302, from the perspective of license server 102, in which license server 102 provides a license for the software application to client 104.

[0060] In block 304, process 302 begins when license server 102 receives a checkout license request for the use of a software application from client 104. For example, the request may include a request number, an identifier for the software application, an identifier for the user, an identifier for the node, an identifier for the site, an identifier for the domain, an identifier for the pool, an identifier for the charging code to be used for the software application, and the current time. The request may be received according to any of a variety of protocols such as TCP, HTTP, or XML.

[0061] In box 306, license server 102 initiates multiple license authorization standard tests (e.g., available application licenses), including parallel job test 308, parallel node test 310, parallel user test 312, node list test 314, user list test 316, group list test 318, skill list test 320, domain list test 322, site list test 324, and pool list test 326. Each of the tests 308, 310, 312, 314, 316, 318, 320, 322, 324, and 326 corresponds to one or more license authorization standards that can be defined by the terms and conditions of the software license agreement for the software application. Typically, parallel tests such as parallel job test 308, parallel node test 310, and parallel user test 312 check whether the requested use of the software application will result in an amount exceeding the parallel (e.g., simultaneous) usage limit indicated by the corresponding software license agreement. Typically, list tests such as node list test 314, user list test 316, group list test 318, skill list test 320, domain list test 322, site list test 324, and pool list test 326 check whether the requested use of the software application would result in a violation of specified restrictions regarding the naming usage parameters. Therefore, for example, the node list test determines whether the requested use would be inconsistent with the restrictions on executing the software application on the nodes specified in the node list test. This test, along with other tests, will now be described in detail. Following the description of each of the tests 308, 310, 312, 314, 316, 318, 320, 322, 324, and 326 is a description of how the results of each of the tests 308, 310, 312, 314, 316, 318, 320, 322, 324, and 326 are used to draw a final conclusion about whether the request to use the software application should be affirmed or rejected.

[0062] Parallel job test 308 determines whether allowing the requested use would exceed a predefined limit on the number of execution instances of a particular software application. License server 102 stores a copy of this predefined limit for parallel application jobs and compares it to the run count of execution instances of the software application obtained through current use block 328. If the count is greater than or equal to the limit, the test fails.

[0063] Parallel node test 310 determines whether allowing the requested use would exceed a predefined limit on the number of nodes executing a particular software application. Here, a "node" refers to a network node (e.g., a client such as client 104), specified by its node name (e.g., A1234567.nw.nos.boeing.com). License server 102 stores a copy of the predefined limit on the number of nodes that can simultaneously execute copies of the software application and compares it to the run count of instances of the software application executing on different nodes, obtained through current use block 328. If the count is greater than or equal to the limit, the test fails.

[0064] Parallel User Test 312 determines whether allowing the requested use exceeds a predefined limit on the number of users using a particular software application. License Server 102 stores a copy of this predefined limit for parallel application users. It is important to note that, typically, nodes may correspond to users, but are not required to be. For example, a single user may log in and use multiple instances of the software application on multiple nodes. Similarly, a single node (e.g., a supercomputer) may have multiple users logged in and using the software application. License Server 102 stores a copy of the predefined limit for parallel users and compares it to the run count of instances of the software application executed by different users, obtained through Current Use Box 328. If the count is greater than or equal to the limit, the test fails.

[0065] Node list test 314 determines whether the requested use of the software application would violate conditions specified by one or more node lists (e.g., clients such as client 104). These node lists are stored by license server 102.

[0066] According to some examples, each node list test 314 involves two node lists, referred to herein as the "accepted node list" and the "rejected node list." These node lists are formatted to provide information, respectively, about which nodes are allowed to execute instances of the software application and which nodes are prohibited from executing instances of the software application. For example, each node list may be a computer-readable text (e.g., dot txt) document comprising a list of nodes specified by a name such as A1234567.nw.nos.boeing.com. Node lists may include subscription end dates associated with one or more node names (e.g., next to the node names). Furthermore, either node list may include wildcards such as asterisks. The presence of wildcards in the node accept list (regardless of whether any nodes are explicitly listed) indicates that all nodes are allowed to execute instances of the software application. The presence of wildcards in the node reject list (regardless of whether any nodes are explicitly listed) indicates that no nodes are allowed to execute instances of the software application.

[0067] To evaluate node list test 314 using the accept node list and reject node list as described above, the following algorithm can be performed according to some examples. License server 102 identifies the request node from which the request for a license to use the software application originates. The license server can query this information in the data within the request itself. License server 102 then checks the request node against the reject node list. If the request node is explicitly listed in the reject node list, node list test 314 fails. Node list test 314 outputs a negative response (e.g., binary "0") and terminates. Otherwise, it continues to check if the request node is explicitly listed in the accept node list. If the request node is explicitly listed in the accept node list, node list test 314 passes. Node list test 314 outputs a positive response (e.g., binary "1") and terminates. Otherwise, it continues to check if the reject node list includes wildcards. If the reject node list includes wildcards, node list test 314 for the request node fails. Node list test 314 outputs a negative response and terminates. Otherwise, it continues to check if the accept node list includes wildcards. If the accepting node list includes wildcards, then node list test 314 for the requested nodes passes. Node list test 314 outputs a positive response and terminates. Otherwise, node list test 314 for the requested nodes fails. Node list test 314 outputs a negative response and terminates.

[0068] The above algorithm for evaluating a node list test using an accept list and a reject list can be generalized to evaluate any of the following list tests (314, 316, 318, 320, 322, 324, 326) based on parameters about the request and using accept and reject lists. Below is the general parameter test algorithm.

[0069]

[0070] Parameter testing algorithm

[0071] As described in detail below, the parameter testing algorithms disclosed above can be used to evaluate user tests 316 based on user parameters, group tests 318 based on group parameters, skill tests 320 based on skill parameters, domain tests 322 based on domain parameters, site tests 324 based on site parameters, and pool tests 326 based on pool parameters.

[0072] It's important to note that the node list test 314 and the general parameter test algorithm use two lists for illustrative purposes, not as a constraint. Examples can utilize a single list or more than two lists.

[0073] User list test 316 determines whether the requested use of the software application would violate conditions specified by one or more user lists. These user lists are stored by license server 102. To evaluate user list test 316 for a specific request to use the software application, each (1) of the parameter test algorithm identifies the user. For example, the user's identifier can be retrieved from the request. The remaining steps (2)-(5) are then applied as needed using the accept user list and reject user list.

[0074] Group list test 318 determines whether the requested use of the software application would violate conditions specified by one or more group lists. Here, a group can be a group within a business organization such as a company. A group can be defined as part of an organization's organizational chart. Example groups include executive, engineering, legal, administrative, maintenance, etc. The accepting group list and the rejecting group list can be stored by the license server 102. To evaluate group list test 318 for a specific request to use the software application, a parameter test algorithm can be applied using the parameter "group". For this purpose, each line (1) of the parameter test algorithm identifies a group. For example, the identifier of the group can be retrieved from the request. Or, for example, the license server 102 can look up the identifier of the group from a stored lookup table that associates the user identified in the request with the user's group. The remaining steps (2)-(5) of the parameter test algorithm are then applied, stopping where the accepting group list and the rejecting group list are indicated. The output of group list test 318 is one of affirmative or negative (e.g., "1" or "0").

[0075] Skills list test 320 determines whether the requested use of the software application would violate conditions specified by one or more skill lists. Here, for example, skills can be official certifications, educational qualifications, assignments, or appointments. Specific types of skills are named roles within a business entity, such as network engineer, human resources specialist, data analyst, etc. Other example skills include engineering certifications, such as engineering certifications provided by a vendor, etc. Acceptable and rejected skill lists may be stored by license server 102. To evaluate skills list test 320 for a specific request to use the software application, a parameter testing algorithm may be applied using the parameter “skills”. For this purpose, each line (1) of the parameter testing algorithm identifies a skill. For example, a skill may be retrieved from the request. Alternatively, for example, license server 102 may look up a skill from a stored lookup table that associates the user identified in the request with the user’s skills. The remaining steps (2)-(5) of the parameter testing algorithm are then applied, stopping where the accepted and rejected skill lists are indicated. The output of skills list test 320 is one of affirmation or negation (e.g., “1” or “0”).

[0076] Domain list test 322 determines whether the requested use of the software application would violate conditions specified by one or more domain lists. Here, a domain can be a geographic region or a network domain. Example domains include US East, US West, EU, Australia, Asia, etc. The accepting domain list and the rejecting domain list may be stored by the license server 102. To evaluate domain list test 322 for a specific request to use the software application, a parameter test algorithm may be applied using the parameter “domain”. For this purpose, each line (1) of the parameter test algorithm identifies a domain. For example, a domain may be retrieved from the request. Or, for example, the license server 102 may look up a domain from a stored lookup table that associates the node identified in the request with its corresponding domain. The remaining steps (2)-(5) of the parameter test algorithm are then applied, stopping where indicated by the accepting domain list and the rejecting domain list. The output of domain list test 322 is one of affirmation or negation (e.g., “1” or “0”).

[0077] Site list test 324 determines whether the requested use of the software application would violate conditions specified by one or more site lists. Here, a site can be a physical business site. Example sites include company campuses, university campuses, engineering facilities, office buildings, cities, etc. The accepting site list and the rejecting site list can be stored by the license server 102. To evaluate site list test 324 for a specific request to use the software application, a parameter test algorithm can be applied using the parameter “site”. For this purpose, each line (1) of the parameter test algorithm identifies a site. For example, a site can be retrieved from the request. Or, for example, the license server 102 can look up a site from a stored lookup table that associates the nodes identified in the request with their respective sites. The remaining steps (2)-(5) of the parameter test algorithm are then applied, stopping where the accepting site list and the rejecting site list are indicated. The output of site list test 324 is one of affirmation or negation (e.g., “1” or “0”).

[0078] Pool list test 326 determines whether the requested use of the software application would violate conditions specified by one or more pool lists. Here, a pool can be a classification of company employees. Example pools include domestic employees, international employees, contractors, etc. The accept pool list and reject pool list can be stored by the license server 102. To evaluate pool list test 326 for a specific request to use the software application, a parameter test algorithm can be applied using the parameter “pool”. For this purpose, each line (1) of the parameter test algorithm identifies a pool. For example, a pool can be retrieved from the request. Or, for example, the license server 102 can look up a pool from a stored lookup table that associates the user identified in the request with the corresponding pool to which the user is classified. The remaining steps (2)-(5) of the parameter test algorithm are then applied, stopping where indicated by the accept pool list and reject pool list. The output of pool list test 326 is one of affirmation or negation (e.g., “1” or “0”).

[0079] It is important to note that each license authorization test (boxes 308, 310, 312, 314, 316, 318, 320, 322, 324, 326) outputs a positive (e.g., "1") or a negative (e.g., "0"). If the software license agreement for a given software application lacks any restrictions on any software authorization test, then such a test might output "1" in this case. Therefore, the outputs of the license authorization tests can be concatenated into a concise, ordered string of ten-binary-digit numbers. For example, if a given request passes the parallel job test 308 and the node list test 314, the concise string could be formed as, for example, 1001000000.

[0080] Once all license authorization standard tests initiated in block 306 (blocks 308, 310, 312, 314, 316, 318, 320, 322, 324, 326) are executed, license server 102 determines whether a license is available for the requested use. To do this, the license server may utilize the concise string described above, directly consider the test output, or consider test output in different formats. Block 306 therefore receives the output from the tests, and license server 102 compares the test results with the stored set of license authorization standards used for the software application.

[0081] Based on the comparison, license server 102 determines whether all 10 license tests have been met to provide a license for use in the requested software application. License checkout box 304 receives this determination result. If the determination reveals that all tests passed (e.g., the determination equals 1111111111), license server 102 checks out and provides the requested license for use to client 104. Otherwise, the license server sends a report to client 104 detailing exactly which tests 308, 310, 312, 314, 316, 318, 320, 322, 324, and 326 passed and which tests 308, 310, 312, 314, 316, 318, 320, 322, 324, and 326 failed. Client 104 may display these results to the user (e.g., in a pop-up box).

[0082] License checkout box 304 reports the license checkout to transaction information box 330 for checkout processing. The report to transaction information box 330 for checkout processing may include various transaction information. This may include any one or any combination of the following transaction information: record number, application transaction number, transaction type (here, "checkout"), number of available licenses, usage (e.g., the number of licenses checked out at the time of the transaction), timestamp, software application identifier, user identifier, user's actual name, node identifier, group identifier, pool identifier, skill identifier, domain identifier, site identifier, charge code information, license server identifier, client identifier, identifier of the request to use the software application, and / or identifier of the license used. For failed requests, the report to transaction information box 330 for checkout processing may include details of all passed and failed tests. In some examples, this information is included for each individual transaction (e.g., in the form of a concise, ordered ten-bit binary string as described above). In any case, transaction information box 330 for checkout processing reports the transaction information to supervisor 106 for persistent storage, for example, in supervisor 106 or data warehouse 110.

[0083] Supervisor 106 can achieve very high throughput using the disclosed techniques. For example, supervisor 106 can store incoming transaction information in a first portion of volatile memory until a certain threshold amount of information is received. At this point, new incoming information is stored in a second portion of volatile memory, the information stored in the first portion is transferred to persistent memory, and the process is repeated for the second portion of volatile memory. The number of volatile memory portions used and the threshold amount can be adjusted based on the actual rate of received transaction information. Some examples anticipate recording transaction information in supervisor 106 within 1 / 100,000th of a second of the time since the user requested the application to start.

[0084] License checkout box 304 also reports the license checkout to Current License Checkout Information box 336. Current License Checkout Information box 336 encapsulates the license checkout information and sends it to Current Use box 328. This license checkout information may include any one or any combination of the following: record number, application transaction number, transaction type (here, "checkout"), number of available licenses, usage (e.g., the number of licenses checked out during the transaction), timestamp, software application identifier, user identifier, user's actual name, node identifier, group identifier, pool identifier, skill identifier, domain identifier, site identifier, charge code information, license server identifier, client identifier, identifier of the request to use the software application, and / or identifier of the license used. Current Use box 328 reports this information to supervisor 106, who maintains a running record of which applications have currently had their licenses checked out, along with relevant information (e.g., the number of currently running instances of the application), and their corresponding nodes, users, groups, skills, domains, sites, pools, and the license authorization criteria met.

[0085] Once the user completes the software application or the software application is otherwise closed, for each license check-in 332, client 104 sends a check-in message to license server 102. For each license check-in 332, license server 102 re-checks in the licenses obtained from each action in block 304. Additionally, license server 102 updates the current license check-out information block 336, which updates supervisor 106 via current usage block 328 to consider the checked-in license. Furthermore, license server 102 provides updated transaction information to transaction information block 334 used for check-in processing, which updates the transaction information stored at supervisor 106 for a specific license check-in event. This updated information may include, for example, stop time and usage duration.

[0086] Some examples include proactive license checkout monitoring. According to these examples, once client 104 successfully checks out a license to use the software application, it periodically sends proactive license messages to license server 102 (e.g., every twenty minutes). License server 102 periodically (e.g., hourly) checks these messages. Licenses that have been checked out but are not associated with any proactive license messages for a sufficiently long period (e.g., two hours) can be automatically re-checked out. License server 102 can ignore stale proactive license messages and stale license checkout requests. This feature prevents the license pool from running out of space.

[0087] Figure 4 This is a schematic diagram of a supervisor 106 in a system for managing software licenses, based on some examples. Figure 4 The client 104 and the license server 102, as well as their communication connection, are also depicted.

[0088] The current merge uses box 402 to interact with license server 102 in order to... Figure 3 Box 328 receives current usage information (e.g., license check-out information and license check-in information). Current merge usage box 402 merges current usage information received from multiple license servers (including license server 102). Current merge usage box 402 can provide current usage information for any managed software application upon request.

[0089] The server transaction information box 404 interacts with the license server 102 to... Figure 3 Box 334 receives transaction information. Box 404 merges transaction information received from multiple license servers (including license server 102). Box 404 can provide transaction information upon request for any managed software application, any user, any node, etc.

[0090] Client heartbeat box 406 receives client heartbeat ping messages from clients (e.g., client 104). Supervisor 106 updates the time of the latest ping message for each such client. Supervisor 106 can use this information to determine which clients are active and require the software license management service.

[0091] Software asset management record 408 receives software asset management record 259 from a client (e.g., client 104). These records may indicate the software application, the user, the node where the software application is installed, and the location of the node where the software application is installed. This information is stored in software asset management record 258.

[0092] The token-based software transaction interaction block 410 of the supervisor 106 (e.g., token transaction) interacts with the token-based transaction interaction block 202 of the client 104 to receive a license to use the request transaction information when communication with the client 104 is available.

[0093] The supervisor 106's enterprise-based software transaction interaction block 412 (e.g., enterprise transaction) interacts with the client 104's enterprise-based software transaction interaction block 204 to receive a license to use the request transaction information when communication with the client 104 is available.

[0094] Figure 5 This is a schematic diagram of Accounting 108 in a system for managing software licenses, based on some examples. Figure 5 The process 254, in which client 104 obtains a license to use the software application from license server 102, and the charging code update process 252 are also described; these are two components of client 104. Figure 5 The communication connection between Accounting 108 and Processes 252 and 254 is also described.

[0095] The charging code update process 252 of client 104 interacts with the process 502 for finding currently allowed account charging codes (which is part of the license manager accounting service 508 of accountant 108). This interaction can occur when client 104 requests a list of allowed charging codes for user accounts from accountant 108 in box 256. In response, the process 502 for finding currently allowed account charging codes retrieves the requested information and provides it to the charging code update process 252 of client 104.

[0096] The billing code update process 252 of client 104 also interacts with the current billing code update process 504 (which is part of the license manager accounting service 508 of accountant 108). This interaction can occur when client 104 provides current billing code information in box 258 and provides an update in box 260.

[0097] The process 254, in which client 104 obtains a license to use the software application from license server 102, interacts with the lookup current charge code box 506 (which is part of the license manager accounting service 508 of accountant 108). This interaction can occur in box 234, where client 104 contacts accountant 108 to determine whether the software use is associated with a charge code.

[0098] Figure 6 This is a schematic diagram of a data warehouse 110 in a system for managing software licenses, based on some examples. Figure 6 The document also depicts license servers 102, 614, 616, and supervisor 106, as well as their communication connections. The data warehouse 110 can be implemented as cloud storage, local persistent storage, or other types of storage.

[0099] Data warehouse 110 can store data provided by supervisor 106. For example, data warehouse 110 can store software asset management records 602, which, for example, in Figure 2 258 is provided to supervisor 106. Additionally, data warehouse 110 can store token license transaction information 604, which, for example, in... Figure 2 Box 202 is provided to the supervisor 106. Furthermore, the data warehouse 110 can store enterprise license transaction information 606, which, for example, in... Figure 2 Box 204 is provided to supervisor 106.

[0100] 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 in block 330 for checkout processing and updated in block 334 for check-in processing. Data warehouse 110 may also store corresponding transaction information 610, 612 for multiple license servers (e.g., license servers 614 and 616).

[0101] Data warehouse 110 provides the ability to generate analytical reports (also known as "analysis") using specially filtered data. Specifically, data warehouse 110 stores transaction information, including fee code information, as referenced above. Figure 3 The data warehouse 110 can store this information, for example, in a database.

[0102] Analysis report generation can be initiated in various ways. Some examples include a report generation application configured to query billing code information (and other transaction information) stored in the database of data warehouse 110. Users can use the report generation application to specify filtering criteria, and the application can retrieve corresponding data. Some examples can be configured to generate one or more analysis reports periodically (e.g., daily, monthly, quarterly, yearly) and publish them to, for example, a password-protected website. Passwords can be provided to authorized users to access the reports. Alternatively, other billing code initiation technologies can be used.

[0103] The analysis report may include toll code information as well as other transaction information filtered according to various criteria. A non-exhaustive list of these criteria is presented below.

[0104] • Application licenses can be named by hour, day, week, month, quarter, year, and all years (this can be a percentage of available licenses or the total number of licenses);

[0105] • Application licenses named by network domain (e.g., this can be displayed for a specific network domain or all network domains, such as Northwest, Southwest, Midwest, Northeast, Southeast, etc.);

[0106] • Use of application licenses named after physical sites (e.g., Bellevue site, Everett site, Chicago site, etc.);

[0107] • Use application licenses named after employee type (e.g., U.S. employee, international employee, U.S. contractor, international contractor, national proprietary employee, national proprietary contractor, etc.);

[0108] • Use application licenses named after employees (e.g., Jane Smith, John Doe, etc.);

[0109] • Use application licenses named after organizational groups (e.g., flight testing, engineering, customer service, accounting, human resources, etc.);

[0110] • Application licenses named according to skill categories (e.g., software engineer, business management, finance, configuration management, flight testing, etc.);

[0111] • Use application licenses named after business units (e.g., product development, product testing, product verification and validation, product testing, product maintenance, product support, etc.);

[0112] • Use application licenses named according to their pricing codes (e.g., FLT_TST_01, ENG_EVAL_02, etc.);

[0113] • Used under application licenses named after computers (e.g., Computer_00001, Computer00002, etc.);

[0114] • Application licenses named after user account names (e.g., astrx_01, detjk_45, etc.). A single user can have multiple computer accounts, so this may not necessarily correspond to employee names;

[0115] • Peak license usage for applications named within a given time period;

[0116] • App licenses named by hour, day, week, month, quarter, year, and all years are rejected (this can be a percentage of available licenses or the total number of licenses);

[0117] • Application licenses named by network domain are rejected (e.g., this may be displayed for a specific network domain or all network domains, such as Northwest, Southwest, Midwest, Northeast, Southeast, etc.).

[0118] Application licenses named after physical sites (e.g., Bellevue site, Everett site, Chicago site, etc.) are rejected.

[0119] Application licenses named after employee type (e.g., U.S. employee, international employee, U.S. contractor, international contractor, national proprietary employee, national proprietary contractor, etc.) were rejected.

[0120] • Application licenses named after employees (e.g., John Smith, Bob Turner, etc.) are rejected;

[0121] • Application licenses named after organizational groups (e.g., flight testing, engineering, customer service, accounting, human resources, etc.) are rejected;

[0122] Application licenses named according to skill categories (e.g., software engineer, business administration, finance, configuration management, flight testing, etc.) are rejected;

[0123] • Application licenses named after business units (e.g., product development, product testing, product verification and validation, product testing, product maintenance, product support, etc.) are rejected;

[0124] Application licenses named with pricing codes (e.g., FLT_TST_01, ENG_EVAL_02, etc.) are rejected;

[0125] Application licenses named by computation (e.g., Computer_00001, Computer00002, etc.) are rejected;

[0126] Application licenses named after user account names (e.g., astrx_01, detjk_45, etc.) are rejected. A single user can have multiple computer accounts, so this one is different from the employee name.

[0127] • Application licenses named within a given time period are rejected;

[0128] • A list of top-level named application users (e.g., Jane Smith, John Doe, etc.);

[0129] • A list of top-level named application computers (e.g., Computer 9876, Computer 3485, etc.);

[0130] • A list of top-level named application groups (e.g., structures, computations, etc.);

[0131] • A list of application sites with top-level names (e.g., Philadelphia site, London site, etc.);

[0132] • Summary of toll code units categorized by business department, organization, and employee;

[0133] • A list of computers that have the application installed but are not using it;

[0134] • A list of users who have the app installed but do not use it; and

[0135] • List of users' average license usage.

[0136] Reports can include charts that track trends, such as line graphs used by named apps for each day of a month. Any data filtered by one or more of the above criteria can be tracked and represented as a line over any time span (e.g., daily over a week, month, or year; monthly over a year; hourly over a day, etc.).

[0137] Figure 7 , Figure 8 and Figure 9 A flowchart illustrating a method 700 for processing messages in a system for managing software licenses, according to several examples, is provided. Method 700 may be implemented by any of the license server 102, client 104, supervisor 106, and / or accountant 108. Specifically, method 700 may be implemented to receive and process any messages sent between any of the license server 102, client 104, supervisor 106, and / or accountant 108, as described herein. Therefore, method 700 is described as being performed by a “system component,” which may be any of the license server 102, client 104, supervisor 106, or accountant 108.

[0138] Typically, messages sent between any of the license server 102, client 104, supervisor 106, and accountant 108 may have a specified message format. Each message may include multiple fields with specified meanings. For example, these messages may have any one or any combination of the following fields: 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 below with reference to method 700.

[0139] Method 700 can begin at 702. At 704, the system components wait to receive the next message.

[0140] In 706, a system component receives a message from another system component. The receiving system component extracts data from the header fields of the received message. Specifically, the receiving system component extracts the message receiving address corresponding to the sending message component and the message system name corresponding to the sending system component's system.

[0141] At 708, the system component initializes the message test, and at 710, the system component decrypts the message.

[0142] At 712, the system component parses and extracts the message fields, and at 714, the system component tests the message format, for example, by determining whether the expected message fields exist. If not at 716, the message is discarded at 718, and control is transferred to 704, where the system component waits for the next message. If at 716 the message has a valid format, control is transferred to 720.

[0143] At 720, the system component extracts the message checksum from the message checksum field. The message checksum can be the rest of the message or a hash (e.g., a cryptographic hash) of any specific field (e.g., the message payload). At 722, the system component tests the message checksum, for example, by recalculating the hash and comparing it to the message checksum provided in the message checksum field. If the message checksum is valid at 724, control is transferred to the system component. Figure 8 802. Otherwise, the message is discarded at 718, and control is transferred to 704, where system components wait for the next message.

[0144] In 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.

[0145] At 804, the system component tests the message password. The message password can be one or more random numbers generated periodically (e.g., every five minutes) by the system component (e.g., license server 102). According to some examples, each of these random numbers is associated with the time period in which it was generated. Each message may include three such random numbers: a random number corresponding to the time period in which the message was sent, a random number corresponding to the time period immediately preceding the time period in which the message was sent, and a random number corresponding to the time period immediately following the time period in which the message was sent. If at 806, any password is the same as the password for the time period in which the message was received, or for the time periods exactly before and after the time period in which the message was received, control proceeds to 808. Otherwise, at 812, the message is discarded, and control proceeds to 704, where the system component waits for the next message.

[0146] At 808, the system component tests the Message System Identifier (SID). The Message System Identifier can be unique data associated with the system 100 used to manage software licenses. Additionally, at 808, the system component can test message authentication. Message authentication can be digitally signed data, such as a cryptographic hash of the message's digital signature. A trusted party, such as the license server 102, can provide a digital signature using a private key of an asymmetric cryptographic scheme. The signature can be verified by applying the corresponding public key of the asymmetric cryptographic scheme and determining whether the result is as expected (e.g., the message's cryptographic hash). Message authentication can be omitted unless, for example, the message requests a permission action. If at 810, the Message System Identifier matches the unique data associated with the system, and if the message authentication is correctly verified, control proceeds to 902. Otherwise, if either test fails, the message is discarded at 812, and control proceeds to 704, where the system component waits for the next message.

[0147] At 902, the system component tests the message type. The message type can be any of various indications regarding the message's purpose. For example, the message type can be checked in, checked out, etc. If at 904, the message type is correctly formed and is an allowed message type (e.g., the message type is valid), control proceeds to 906. Otherwise, at 914, the message is discarded, and control proceeds to 704, where the system component waits for the next message.

[0148] In 906, system components process messages based on the specified message type. (See references in this document.) Figures 1 to 6 The details of this process are shown and described. This process calculates a message acknowledgment at 908, which is encrypted at 910 and sent to the appropriate system component (which may be different from the system component that sent the message) at 912. Control then moves to 704, where the system component waits for the next message. Note that a message status field can be used in the returned message to indicate whether the initial message reception was successful or unsuccessful.

[0149] Figure 10 This is a flowchart of a process 1000 for managing software licenses, based on some examples. Method 1000 may use methods such as... Figure 1 The system 100 is implemented using a system (e.g., including a license server 102, a client 104, a supervisor 106, an accountant 108, and a data warehouse 110).

[0150] At step 1002, client 104 detects the startup of the managed software application, for example, as shown above. Figure 2 The description. Previously, references as above may have been used. Figure 1 The software installer described installs the software application.

[0151] At error 1004, client 104 pauses the execution of the software application, for example, as shown above. Figure 2 and Figure 3 Described.

[0152] In step 1006, client 104 determines that the software application is subject to multiple software license authorization standards defined by at least one software license agreement, for example, as referenced above. Figure 2 and Figure 3 Described.

[0153] At 1008, client 104 requests a license to use the software application from license server 102, for example, as described above. Figure 2 and Figure 3 Described.

[0154] At 1010, license server 102 determines that the use of the software application meets multiple license authorization criteria, such as those mentioned above. Figure 2 and Figure 3Described.

[0155] At 1012, license server 102 provides the license for the software application to client 104, for example, as referenced above. Figure 2 and Figure 3 Described.

[0156] In step 1014, client 104 resumes the startup of the software application, for example, as shown above. Figure 2 and Figure 3 The description is not limited to the specific examples described herein, which are intended as illustrative of various aspects. Many modifications and variations will be apparent to those skilled in the art without departing from its spirit and scope. In addition to those listed herein, functionally equivalent methods and apparatuses within the scope of this disclosure will be apparent to those skilled in the art from the foregoing description. These modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terminology of the appended claims and the full scope of equivalents granted to those claims. It will also be understood that the terminology used herein is for the purpose of describing particular examples only and is not intended to be limiting.

[0157] Furthermore, this disclosure includes the following examples, and the scope of protection is provided by the claims.

[0158] Example 1. A method for controlling access to a software application using non-transitory client computer software installed on a client computer and non-transitory server computer software installed on at least one server computer, according to at least one software license agreement, the method comprising: detecting the launch of the software application on the client computer by the client computer software executing on the client computer; suspending the execution process of the software application by the client computer software executing on the client computer; determining that the software application is subject to a plurality of software license authorization criteria defined by the at least one software license agreement by the client computer software executing on the client computer; requesting a license to use the software application on the client computer from the server computer software executing on the server computer; determining that the use of the software application on the client computer satisfies the plurality of software license authorization criteria by the server computer software executing on the server computer; providing the license to use the software application on the client computer software executing on the client computer by the server computer software executing on the client computer; and resuming the launch of the software application on the client computer by the client computer software executing on the client computer, whereby the client computer executes the software application.

[0159] Example 2. The method according to Example 1, wherein the plurality of software license authorization criteria include at least criteria regarding parallel jobs, parallel nodes, parallel users, site lists, node lists, user lists, domain lists, group lists, skill lists, and pool lists.

[0160] Example 3. The method according to any one of Examples 1 to 2, further comprising: detecting the launch of a second software application on a client computer by client computer software executing on a client computer; suspending the execution process of the second software application by the client computer software executing on the client computer; determining that the second software application is subject to an enterprise-wide license for the second software application by the client computer software executing on the client computer; requesting a license from server computer software to use the second software application on the client computer by the client computer software executing on the client computer; storing transaction information on the use of the second software application on the client computer by the client computer software executing on the client computer; and resuming the launch of the second software application on the client computer by the client computer software executing on the client computer, thereby allowing the client computer to execute the second software application.

[0161] Example 4. The method according to any one of Examples 1 to 3, wherein the client computer software configures the client computer to display an error message for a failed software application, wherein the error message indicates that the associated software license authorization standard has failed.

[0162] Example 5. The method according to any one of Examples 1 to 4, wherein the client computer software configures the client computer to bypass the request from the server computer software for a license to use the software application on the client computer if the client computer detects a license token on the client computer.

[0163] Example 6. The method according to any one of Examples 1 to 5, further comprising: recording transaction information of the use of the software application on the client computer by server computer software executing on the client computer, wherein the transaction information includes at least: a software application identifier, a client computer identifier, a duration of use, and software license authorization standard satisfaction data.

[0164] Example 7. The method described according to any one of Examples 1 to 6, wherein no part of the software application is encrypted.

[0165] Example 8. The method according to any one of Examples 1 to 7, further comprising: receiving, by client computer software executing on a client computer, an account charge code associated with a user of a software application; providing the account charge code to an accounting component by the client software executing on the client computer; and storing, by the accounting component, software usage data, which includes at least a charge code associated with at least an identifier of a user of the software application; wherein the software usage data can be searched for a specific usage criterion.

[0166] Example 9. The method according to any one of Examples 1 to 8, wherein at least the client computer software and the server computer software include an internal debug log generator configured to store debug files, the debug files including at least routine identifiers, variable values, and timestamps.

[0167] Example 10. The method according to any one of Examples 1 to 9, further comprising using a configuration application to install a software application on a client computer, the configuration application configuring the client computer to perform the step of detecting software using the client computer.

[0168] Example 11. A system for controlling access to a software application according to at least one software license agreement, the system comprising a client computer and a server computer, wherein: the client computer is configured to detect the launch of the software application on the client computer; the client computer is configured to suspend the execution process of the software application; the client computer is configured to determine that the software application is subject to a plurality of software license authorization criteria defined by the at least one software license agreement; the client computer is configured to request a license from the server computer for use of the software application on the client computer; the server computer is configured to determine that the use of the software application on the client computer satisfies the plurality of software license authorization criteria; the server computer is configured to provide the client computer with a license for use of the software application on the client computer; and the client computer is configured to resume the launch of the software application on the client computer, thereby allowing the client computer to execute the software application.

[0169] Example 12. The system according to Example 11, wherein the plurality of software license authorization criteria include at least criteria regarding parallel jobs, parallel nodes, parallel users, site lists, node lists, user lists, domain lists, group lists, skill lists, and pool lists.

[0170] Example 13. A system according to any one of Examples 11 to 12, wherein the client computer is further configured to: detect the startup of a second software application on the client computer; suspend the execution process of the second software application; determine that the second software application is subject to an enterprise-wide license for the second software application; request a license from the server computer to use the second software application on the client computer; store transaction information on the use of the second software application on the client computer; and resume the startup of the second software application on the client computer, thereby allowing the client computer to execute the second software application.

[0171] Example 14. A system according to any one of Examples 11 to 13, wherein the client computer is further configured to perform an attempt to display an error message for a failed software application, wherein the error message identifies a failure of the associated software license authorization standard.

[0172] Example 15. A system according to any one of Examples 11 to 14, wherein the client computer is further configured to bypass requesting a license from the server computer to use the software application on the client computer if the client computer detects a license token on the client computer.

[0173] Example 16. The system according to any one of Examples 11 to 15, wherein the server computer is further configured to record transaction information of the use of the software application on the client computer, wherein the transaction information includes at least: software application identifier, client computer identifier, duration of use, and software license authorization standard satisfaction data.

[0174] Example 17. A system according to any one of Examples 11 to 16, wherein no part of the software application is encrypted.

[0175] Example 18. A system according to any one of Examples 11 to 17, wherein: the client computer is further configured to receive an account charge code associated with a user of the software application; the client computer is further configured to provide the account charge code to an accounting component; and the accounting component is configured to store software usage data, which includes at least a charge code associated with at least an identifier of a user of the software application; wherein the software usage data can be searched for a specific usage criterion.

[0176] Example 19. A system according to any one of Examples 11 to 18, wherein at least the client computer and the server computer include an internal debug log generator configured to store debug files, the debug files including at least routine identifiers, variable values, and timestamps.

[0177] Example 20. The system according to any one of Examples 11 to 19, further comprising a configuration application for installing a software application on a client computer, wherein the configuration application configures the client computer to detect the launch of the software application on the client computer.

[0178] Regarding the use of virtually any plural and / or singular terms in this document, those skilled in the art can appropriately convert plural to singular and / or singular to plural depending on the context and / or application. For clarity, various singular / plural permutations may be explicitly described herein.

[0179] Those skilled in the art will understand that, generally, the terms used herein, and particularly in the appended claims (e.g., the body of the appended claims), are intended to be “open” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will further understand that if a specific number of claim statements are intended to be introduced, such intention will be explicitly stated in the claims, and without such a statement, such intention does not exist. For example, to aid understanding, the appended claims below may contain the use of the introductory phrases “at least one” and “one or more” to introduce claim statements. However, the use of these phrases should not be construed as implying that a claim statement introduced by an indefinite article limits any particular claim containing such an introduced claim statement to an example containing only one such statement, even when the same claim includes the introductory phrases “one or more” or “at least one” along with an indefinite article (e.g., an indefinite article should be interpreted as meaning “at least one” or “one or more”); the same applies to the use of definite articles used to introduce claim statements. Furthermore, even when the specific number of claims is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the number stated (e.g., a bare statement of "two statements" without other modifiers means at least two statements or two or more statements). Additionally, when using idioms such as "at least one of A, B, and C," this construction is generally intended to ensure that those skilled in the art will understand the meaning of the idiom (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having only A, only B, only C, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.). When using idioms such as "at least one of A, B, or C," this construction is generally intended to ensure that those skilled in the art will understand the meaning of the idiom (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having only A, only B, only C, having A and B, having A and C, having B and C, and / or having A, B, and C, etc.). Those skilled in the art will further understand that any transitional words and / or phrases that actually present two or more alternative terms, whether in the specification, claims, or drawings, should be understood to include the possibility of including one, any, or both of the terms. For example, the phrase "A or B" will be understood to include the possibility of including "A" or "B" or "A and B". Furthermore, where features or aspects of this disclosure are described according to the Markush Group, those skilled in the art will recognize that this disclosure is also described according to any individual member or subgroup of the Markush Group.

[0180] 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 illustrative purposes only and are not intended to be limiting; the true scope and spirit are indicated by the appended claims.

Claims

1. A method (1000) for controlling access to a software application using non-transitory client computer software installed on client computers (104) among multiple client computers and non-transitory server computer software installed on at least one server computer (102) according to at least one software license agreement, the method comprising the steps of: The startup of the software application on the client computer is detected by the client computer software executing on the client computer (1002); The execution process of the software application is suspended (1004) by the client computer software running on the client computer; The client computer software executing on the client computer determines (1006) that the software application is subject to multiple software license authorization standards defined by the at least one software license agreement; The client computer software executing on the client computer requests (1008) a license to use the software application on the client computer from the server computer software executing on the server computer, the server computer being connected to the plurality of client computers in a distributed system via a computer network; The server computer software executing on the server computer determines (1010) that the use of the software application on the client computer satisfies the plurality of software license authorization criteria; The server computer software executing on the server computer provides (1012) a license to the client computer software executing on the client computer to use the software application on the client computer; The client computer software executing on the client computer restores (1014) the startup of the software application on the client computer, thereby allowing the client computer to execute the software application; The client computer software, running on the client computer, receives an account charging code associated with the user of the software application; The client computer software, executed on the client computer, provides the account charge code to the accounting component on the computer network; as well as The accounting component stores software usage data, which includes at least the billing code associated with the identifier of the user of the software application, wherein the software usage data can be searched for specific usage criteria.

2. The method according to claim 1, wherein, The multiple software license authorization standards include standards regarding at least parallel jobs, parallel nodes, parallel users, site lists, node lists, user lists, domain lists, group lists, skill lists, and pool lists.

3. The method according to any one of claims 1 to 2, further comprising the step of: The client computer software executing on the client computer detects (1002) the startup of the second software application on the client computer; The execution process of the second software application is suspended (1004) by the client computer software running on the client computer; The client computer software executing on the client computer determines (1006) that the second software application is subject to an enterprise-wide license for the second software application; The client computer software, which is executed on the client computer, requests (1008) a license from the server computer software to use the second software application on the client computer. The client computer, which is executed on the client computer, stores transaction information (606) on the client computer using the second software application; as well as The client computer software executing on the client computer restores (1014) the startup of the second software application on the client computer, thereby the client computer executes the second software application.

4. The method according to any one of claims 1 to 2, wherein, The client computer software configures the client computer to display an error message for failed software applications, wherein the error message indicates that the associated software license authorization standard has failed.

5. The method according to any one of claims 1 to 2, wherein, The client computer software configures the client computer to bypass the request from the server computer software for a license to use the software application on the client computer if the client computer detects a license token on the client computer.

6. The method according to any one of claims 1 to 2, further comprising the step of: The server computer software executing on the client computer records transaction information (604, 606, 608, 610, 612) regarding the use of the software application on the client computer, wherein the transaction information includes at least: software application identifier, client computer identifier, usage duration, and software license authorization standard satisfaction data.

7. The method according to any one of claims 1 to 2, wherein, No part of the software application is encrypted.

8. The method according to any one of claims 1 to 2, wherein, At least the client computer software and the server computer software include an internal debug log generator configured to store debug files, which at least include routine identifiers, variable values, and timestamps.

9. The method according to any one of claims 1 to 2, further comprising using a configuration application to install the software application on the client computer, the configuration application configuring the client computer to perform the step of detecting using the client computer software.

10. A system (100) for controlling access to a software application according to at least one software license agreement, the system comprising a client computer (104) among a plurality of client computers and a server computer (102), wherein: The multiple client computers are connected to the server computer through a computer network in a distributed system. The client computer is configured to detect (1002) the startup of the software application on the client computer; The client computer is configured to suspend (1004) the execution process of the software application; The client computer is configured to determine (1006) that the software application is subject to multiple software license authorization standards defined by the at least one software license agreement; The client computer is configured to request (1008) a license from the server computer to use the software application on the client computer; The server computer is configured to determine (1010) that the use of the software application on the client computer satisfies the plurality of software license authorization criteria; The server computer is configured to provide the client computer with (1012) a license to use the software application on the client computer; The client computer is configured to restore (1014) the startup of the software application on the client computer, thereby allowing the client computer to execute the software application; The client computer is also configured to receive account charging codes associated with the user of the software application; The client computer is also configured to provide the account charge code to the accounting component on the computer network; and The accounting component is configured to store software usage data, which includes at least the billing code associated with the identifier of the user of the software application, wherein the software usage data can be searched for specific usage criteria.

11. The system according to claim 10, wherein, The multiple software license authorization standards include standards regarding at least parallel jobs, parallel nodes, parallel users, site lists, node lists, user lists, domain lists, group lists, skill lists, and pool lists.

12. The system according to any one of claims 10 to 11, wherein, The client computer is also configured to: Detect (1002) the startup of the second software application on the client computer; Pause (1004) the execution process of the second software application; It is determined (1006) that the second software application is subject to an enterprise-wide license for the second software application; Request (1008) from the server computer a license to use the second software application on the client computer; Transaction information (606) stored on the client computer using the second software application; as well as Restore (1014) the startup of the second software application on the client computer, thereby allowing the client computer to execute the second software application.

13. The system according to any one of claims 10 to 11, wherein, The client computer is also configured to attempt to display an error message for a failed software application, wherein the error message indicates that the associated software license authorization standard has failed.

14. The system according to any one of claims 10 to 11, wherein, At least one of the following is true: The client computer is also configured to bypass requesting a license from the server computer to use the software application on the client computer if the client computer detects a license token on the client computer. The server computer is also configured to record transaction information (604, 606, 608, 610, 612) regarding the use of the software application on the client computer, wherein the transaction information includes at least: software application identifier, client computer identifier, usage duration, and software license authorization standard satisfaction data; and No part of the software application is encrypted.

Images