System and method to count license seat by application context path

Abstract

Provided is a system and method to count license seats of an application via an Application Context Tree (120), which is used to distinguish between different behaviors for remote sharing software running the application and normal locally running applications. A Licensing API (121) generates an application context path (210) from a process tree for connections to the machine and uses it to submit a login request. A Licensing Manager compares the application context id (320) to existing entries in an application session table (300) to determine if the requested session is different from the existing entries. It decides between allowing a login for the application without consuming a new seat, or consuming a new seat to allow the login in and adding a new entry for the application context id (320) in the application session table (300). Other embodiments disclosed.

Description

SYSTEM AND METHOD TO COUNT LICENSE SEAT BY APPLICATION CONTEXT PATHTECHNICAL FIELD

[0001] The present disclosure generally relates to software licensing models and control over license use. More particularly, but not exclusively, the present disclosure relates to a system and method to count actively used license seats when licensed applications are used with remote sharing services.BACKGROUND

[0002] Software licensing is a process through which an Independent Software Vendor (ISV) offers their software application product or embedded device firmware to an individual or business for a fee. It is a means by which end-users gain access to software and products, while the ownership rights remain with the software publisher. End-users must generally accept some form of a software licensing agreement in order to use the software. Numerous types of software licensing models are available to unlock software for users, varying from simple perpetual licenses and subscription licenses to more advanced models such as floating licensing.

[0003] The majority of software vendors have moved towards a cloud based subscription model for licensing purposes. In this realm, various types of software licensing models are available: perpetual, concurrent, subscription-based, proprietary, feature-based, network-based, cloud-based and so on. Concurrent licensing models are typically based on certain terms and conditions where the ISV expects to authorize a license with limited seats that can only be used by a limited number of end users running the licensed application at the same time. The ISV allows multiple instances of the application to run on the same machine.

[0004] FIG. 1A illustrates such an example where a licensed application can have multiple instances on a same machine; an authorized activity which occupies a single license seat. The license manager monitors application use, and since it allows only for one license seat, the first user to instantiate the application will receive the seat. Here, once User A runs the licensed application, Machine A will log into the License Manager and receive the one seat. If User B then tries to run the application, Machine B will not be able to log into theLicense Manager, and will not receive a seat as expected. With this, the license can only be used as expected by a limited number of end users concurrently.

[0005] Nowadays, remote access software is widespread and available to enable a local user to connect to and access a remote computer, server, or network. Virtual Network Connection (VNC) is one such example of a platform-independent application that allows remote access to another computer. Secure Shell (SSH) can also be used to connect to servers, make changes, perform uploads and exit, either using tools or directly through the terminal. And, Remote Desktop Services (RDS) is yet another type of remote access software that allow users to remotely access graphical desktops and Windows applications. These types of remote services allow multiple users to share the same license seat on a single machine concurrently. Although this is a scenario the ISV may be aware of and may even support, the ISV generally wants to monitor this activity closely. This is because remote accessing allows for multiple users to run multiple instances of the application on the same machine under one license, but if not monitored, also serves as a means to circumvent the requirement of additional license seats without subscribing for additional license seats.

[0006] FIG. 1 B illustrates such an example where multiple users try to share the same license seat. Here, User A and User B are accessing the licensed Application A on Machine X via some remote access service. If there is only one license seat, when User A uses the application, User B cannot use it, until User A release the seat. If there are two license seats, both A and B can login successfully, thus concurrently. With remote access software, User A and B could both use the same license seat, but this is the situation the ISV wants to avoid. Because remote access software gives multiple users access to the same application on Machine X from different Machines Client A and Client B, the problem becomes one of how to distinguish between the remote access sessions of client machine A and client machine B.

[0007] Typical approaches that try to obtain a unique ID from the client machine depend on specific attributes of different remote accessing software. In the case of SSH, the attribute may be the computer port number. But, this attribute can be modified manually, and a savvy client could pretend to be the same machine by changing the port number to match it. In the case of VNC, the attributes may be one, or combination of, a display identifier (id) and a host name. But here too, the attributes can be modified manually, or may not even exist, or even work on various operating systems. For example obtaining host name for remote log in by UMTP may not work on certain versions of Ubuntu and Debian for Linux.The attributes combination are complicated, and offer only low security, and because most of these IDs are just an environment variable, they are easy to modify to deceive the license manager.

[0008] LIS Patent No. 9246916 issued on Jan 26, 2016 is directed to an architecture for enforcing rights in digital content that allows access to encrypted digital content only in accordance with parameters specified by license rights acquired by a user of the digital content. A point of novelty in this license approach is use of a license server that issues a license to a DRM system that is ‘trusted’, and is equipped with a ‘black box’ that performs decryption and encryption functions for such DRM system. The license is stored in the DRM system thereby allowing the user to render the digital content according to the rights conferred by the license and specified in the license terms.

[0009] LIS Patent No. 4937863 issued on June 26, 1990 to assignee Digital Equipment Corporation entitled “Software Licensing Management System” discloses a license management system which includes a license management facility that determines whether usage of a licensed program is within the scope of the license. The license management system maintains a license unit value for each licensed program and a pointer to a table identifying an allocation unit value associated with each use of the licensed program. In response to a request to use a licensed program, the license management system responds with an indication as to whether the license unit value exceeds the allocation unit value associated with the use. Upon receiving the response, the operation of the licensed program depends upon policies established by the licensor. Such system is static in many ways and not sufficiently adaptive for today’s cloud computing environments.

[0010] US Patent No. 9,569,598 issued on February 14, 2017 to assignee Kyndryl Inc. entitled “Software license management in a networked computing environment” discloses an approach for managing licenses for software installations on virtual machine (VM) instances in a networked computing environment (e.g., a cloud computing environment) is provided. Specifically, in one example, data (e.g., real-time and / or historical) pertaining to usage of a set of software installations on a set of (VM) instances in the networked computing environment is collected. When a request is received (e.g., from a requester) for a license for a particular software installation of the set of software installations, it is determined whether the license is available. If not, it is then determined whether the license is obtainable based on the collected data and a current configuration of the networked computing environment. Then, responsive to the license being obtainable,the requested license may be allocated. Again, such a system is static in many respect and not sufficiently adaptive for today’s cloud computing environments.

[0011] The problem here with concurrent licensing via remote access services becomes one of how to find a generic way to detect and avoid the situation where multiple users share the same software license seat, while providing secure access with so many different types of remote access software used across varying operating systems.

[0012] All of the subject matter discussed in the Background section is not necessarily prior art and should not be assumed to be prior art merely as a result of its discussion in the Background section. Along these lines, any recognition of problems in the prior art discussed in the Background section or associated with such subject matter should not be treated as prior art unless expressly stated to be prior art. Instead, the discussion of any subject matter in the Background section should be treated as part of the inventor's approach to the particular problem, which, in and of itself, may also be inventive.SUMMARY

[0013] In some embodiments, a system for a License Model to count license seats of an Application via an Application Context Tree the system comprising: a Licensing API executing on a machine that supports both a local service and a remote access service for an application. Th Licensing API by way of the machine: monitors instantiations of the application on the machine; collects a process tree for connections to the machine responsive to instantiation; generates an application context path from the process tree for each connection to the machine for the local service and the remote access service; adds a machine id to a beginning of the application context path; and logs into a Licensing Manager with the application context path for each connection. The Licensing Manager communicatively coupled to the Licensing API: receives the application context path for each connection of a remote access client; generates a hash for each application context path; prepends the machine id to the hash to produce an application context id; and compares the application context id to existing entries in an application session table to determine if the instantiation of the application is new and different from the existing entries, thereby counting license seats available in the application session table; and then, decides between one of: allowing a login for the application without consuming a new seat; andconsuming a new seat to allow the login in and adding a new entry for the application context id in the application session table.

[0014] In some embodiments, the Licensing Manager upon deciding to consume a new seat: stores the application context id in the application session table; assigns a session id for the instantiation of the application to the application context id; and associates a license id with the session id. In some embodiments, when entries differ, the Licensing Manager determines whether a license seat should be granted in view of a license ID seat table, and grant the application a license to instantiate if there are seats available in the license ID seat table.

[0015] In some embodiments, the Licensing API is integrated with the application and generates the application context path for each connection when the application logs into the Licensing Manager by searching the process tree from a parent node of the application to a root node of the process tree thereby producing a child nodal path. In some embodiments, the search is extended such that the application context path sequentially includes the parent node, the child nodal path and the root node.

[0016] In some embodiments, the Licensing Manager: filters nodes within the application context path based on an exception policy to produce a truncated context path for each connection, wherein said hash is generated from said truncated context path instead of the application context path. In some embodiments, the Licensing Manager, in view of the application session table via string comparison of entries therein, distinguishes between remote sharing software that is running the application and a locally running application; wherein the local service is one among a shell program, such as bash, a terminal program, such as gnome, and wherein the remote service is one among Remote Desktop Services (RDS), Virtual Network Connectivity (VNC), and a secure shell (SSH).

[0017] In some embodiments, the Licensing Manager, in view of the application session table via string comparison of entries therein, determines if a process is fully local on the machine, or “display exported” to another machine and thereby counts remote sessions each as extra license seats but counts multiple local sessions on the machine just as one concurrency license seat.

[0018] In some embodiments, the Licensing API executes on the machine; the Licensing Manager executes on a different machine; and both said machine and said different machine comprise: one or more processors and memory coupled to the one ormore processors, wherein the memory includes computer instructions which when executed by the one or more processors causes the one or more processors at the one or more servers to perform said operations.

[0019] In some embodiments, a method for a License Model to count license seats of an Application via an Application Context Tree is provided. The method comprising steps that by way of a Licensing API executing on a machine that supports both a local service and a remote access service for an application, the Licensing API by way of the machine performs steps for: monitoring instantiations of the application on the machine; collecting a process tree for connections to the machine responsive to instantiation; generating an application context path from the process tree for each connection to the machine for the local service and the remote access service; adding a machine id to a beginning of the application context path; logging into a Licensing Manager with the application context path for each connection; and by way of the Licensing Manager communicatively coupled to the Licensing API: receiving the application context path for each connection of a remote access client; generating a hash for each application context path; prepends the machine id to the hash to produce an application context id; and comparing the application context id to existing entries in an application session table to determine if the instantiation of the application is new and different from the existing entries, thereby counting license seats available in the application session table; and then, deciding between one of: allowing a login for the application without consuming a new seat; and consuming a new seat to allow the login in and adding a new entry for the application context id in the application session table.

[0020] In some embodiments, the Licensing Manager upon deciding to consume a new seat: stores the application context id in the application session table; assigns a session id for the instantiation of the application to the application context id; and associates a license id with the session id, wherein when entries differ, the Licensing Manager determines whether a license seat should be granted in view of a license ID seat table, and grant the application a license to instantiate if there are seats available in the license ID seat table.

[0021] In some embodiments, the Licensing API is integrated with the application and generates the application context path for each connection when the application logs into the Licensing Manager by searching the process tree from a parentnode of the application to a root node of the process tree thereby producing a child nodal path.

[0022] In some embodiments, the Licensing Manager, in view of the application session table via string comparison of entries therein, distinguishes between remote sharing software that is running the application and a locally running application; wherein the local service is one among a shell program, such as bash, a terminal program, such as gnome, and wherein the remote service is one among Remote Desktop Services (RDS), Virtual Network Connectivity (VNC), and a secure shell (SSH).BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Non-limiting and non-exhaustive embodiments are described with reference to the following drawings, wherein like labels refer to like parts throughout the various views unless otherwise specified. The sizes and relative positions of elements in the drawings are not necessarily drawn to scale. For example, the shapes of various elements are selected, enlarged, and positioned to improve drawing legibility. The particular shapes of the elements as drawn have been selected for ease of recognition in the drawings. One or more embodiments are described hereinafter with reference to the accompanying drawings in which:FIG. 1A illustrates an example where a licensed application can have multiple instances on the same machine and occupy only a single license seat;FIG. 1 B illustrates an example where multiple users try to share the same license seat via remote access services;FIG. 2A is a new license model system to count license seats by way of an application context tree in accordance with some embodiments;FIG 2B illustrates an exemplary process tree for a remote access service and resulting application context path in accordance with some embodiments;FIG. 2C illustrates an exemplary process tree for a local service on a different machine in accordance with some embodiments;FIG 2D shows representative application context strings generated by the the Licensing Manager for various user sessions in accordance with some embodiments;FIG. 3A illustrates an exemplary session table for counting license seats in accordance with some embodiments;FIG. 3A illustrates an exemplary seat table for evaluating occupancy and total use of license seats in accordance with some embodiments;FIG 4 provides a method scheme for license control in accordance with one embodiment;FIG. 5 illustrates an example of a computing system suitable for use with the system and method to count license seat by application context path;FIG. 6 illustrates an example of a storage medium suitable for use with the system and method to count license seat by application context path; andFIG. 7 illustrates an example of a computing platform suitable for use with the system and method to count license seat by application context path.DETAILED DESCRIPTION

[0024] In the following description, certain specific details are set forth in order to provide a thorough understanding of various disclosed embodiments. However, one skilled in the relevant art will recognize that embodiments may be practiced without one or more of these specific details, or with other methods, components, materials, etc. Also in these instances, well-known structures may be omitted or shown and described in reduced detail to avoid unnecessarily obscuring descriptions of the embodiments.

[0025] Referring now to FIG. 2A is a new license model system 100 to count license seats by way of an application context tree that resolves the aforementioned technical problems associated with monitoring license usage over remote access software. It provides a more flexible and responsive licensing approach than traditional licensing models.

[0026] The system 100 comprises a Licensing API 121 executing on a Machine A 101 that supports both a local service and a remote access service for an application, and a Licensing Manager 130 communicatively coupled to the Licensing API 121. The application is the program that is licensed, and the vendor of this application integrates the Licensing AP1 121 into their application. This integration allows the vendor to monitor use of the application on any machines once deployed. The local service is one among a shellprogram, such as bash, a terminal program, such as gnome, or any other utility used locally, for example, as shown my User Z. The remote access service is one among Remote Desktop Services (RDS), Virtual Network Connectivity (VNC), a secure shell (SSH), or other type or remote access software; there are many. Here, User X and User Y remotely connect into machine A 101 via remote access client machine X 102 and remote access client machine Y 103, respectively.

[0027] The Licensing API 121 includes a licensed application context path generation function that is running on the machine A 101 with the vendor application. It monitors instantiations 125, also called instances, of the application on the machine A 101 , collects a process tree from the machine A 101 responsive to instantiation, and generates an application context path from the process tree for each connection on the machine A 101 for the local service and the remote service. A process tree depicts the parent-child relationship between various processes running in an operating system. Each process in the tree has a unique process ID (PID), and the 'parent' process can spawn 'child' processes, creating a tree-like structure. In Linux various commands and arguments can be used to find ongoing processes in Linux (e.g., / ps -ef -tree, / pstree, / proc, / htop, etc.). The Licensing API 121 includes functions and other methods to invoke these commands or other system calls for such purpose.

[0028] When the vendor’s application logs into the license manager service of the Licensing Manager 130, the licensed application context path generation function of the API 121 collects the process tree information and generates the licensed application context path based on several rules as follows. Once it gets the process tree from the machine A 101 that is executing the application, it searches the process tree for a child nodal chain path from a parent node of the licensed application to the root node of the tree, at which point the search terminates. This is achieved by way of string comparison functions and parsing operation on string representations of the process tree and branches. In some cases, the search is extended such that the application context path sequentially includes the parent node, the child nodal path and the root node. It then obtains the machine id of the respective remote access connection machines and adds the machine id node at the beginning of the searching path. The Licensing API 121 then logs into the Licensing Manager 130 with the application context path and other login parameters for each connection.

[0029] FIG 2B illustrates an exemplary application context tree 200 for a remote access service and resulting two application context paths 210 generated between an Application parent node (221 or 231) and a root node 211 just below the node 201 for machine A 101. Each of these two paths is an independent application context path. The Licensing API 121 function starts from the parent node (220 or 230) of this application, and stops at the root node 211 on the same machine. This child nodal chain path is enough to distinguish amongst different clients. But, because the License Manager 130 will also need to distinguish the remote access connection from different machines, a machine ID from the process tree is included for the application context path. In this example, there may be two machines A and B as seen in FIG 1A, each running a separate instance of the application. So, it adds a machine id to the beginning of the application context path for the machine the application is running on. Here, the machine id for machine A is “MA”. Although remote access clients MX and MY are shown in FIG. 2A, these are simply for illustrative purposes, and not related to machine ids MA and MB; so as not to confuse these remote machines with a machine id of the process tree.

[0030] FIG. 2C illustrates an exemplary application context tree 250 for a local service on a completely different machine B. This is a determination that the License Manager 130 will make once it processes all the information received in a stream of application context paths from the License AP1 121 . Accordingly, the Licensing API 121 will generate application context paths for all machines for various connections; remote and local. The licensed application context path is then encoded as a context string.

[0031] When the application attempts to log into the Licensing Manager 130, the Licensing AP1 121 sends (or streams) the application context path for each connection with other login parameters together as a part of a request. The Licensing Manager 130 receives all the application context strings, some of which may be truncated, and then calculates and generates a hash for each application context path. In some cases, the Licensing Manager 130 filters nodes within the application context path based on an exception policy, if defined, to produce a truncated context path for each connection, and the hash is generated from the truncated context path and not the application context path. This filtering may involve removing nodes that may be shared between processes running on the same machine, or removing nodes that may be different which do not contribute to identifiable and distinguishing connections to the respective machines using the remote access services. Hashing is the process of generating a value from a text or a list of numbers using amathematical function known as a hash function. A hash function is any function that can be used to map data of arbitrary size to fixed-size values. Commonly used hash functions include SHA (Secure Hash Algorithm), CRC (Cyclic Redundancy Check), MurmurHash, BLAKE2, MD5 (Message Digest 5) though others are applicable.

[0032] FIG 2D shows representative application context strings generated by the the Licensing Manager 130 for various user sessions S1 , S2 and S3 as follows:S1 : Machine A id: Hash(RootS2: Machine A id: Hash(Root(pid1 ) -> c1 (pid2) - c2-2(pid4) c3-2(pid6))S3: Machine B id: Hash(Root...)

[0033] Recall, the License API 121 adds the machine id to the beginning of the application context path which is submitted in the request. The License Manager 130 upon receiving the request takes this machine id and then prepends (appends to front of) it to the hash to produce an application context id. The machine id is added last and prepends to the hash to facilitate faster table indexing and search from left to right string analysis. The Licensing Manager 130 then stores the application context id for each of the context strings (e.g. S1 , S2 and S3) as entries in a session table described ahead.

[0034] FIG. 3A illustrates an exemplary session table 300 for counting seats with columns for session id 310, application context id 320 and license id 330. Briefly, the application context tree 200 provides more information on whether a process is fully local on the machine, or, for example, “display exported” to another machine to treat concurrency counting differently. Here, the License Manager 130, by way of the session table (300 described ahead with FIG 3) with entries for each application context path of a remote access connection, counts each remote session as an extra seat, but counts multiple local sessions on the machine just as one concurrency, or a single seat. Notably, the application context tree is not necessarily used to distinguish the different instances of the application running on the same machine, but rather, the application context tree is used to the create session table 300 with entries for each application context path in order to distinguish different behaviors between one of i) remote sharing software (remote access programs) which is running the application, and ii) normal locally running applications, and therebymake a decision for assigning, or counting, license seats to applications instantiated by remote access connections based on that difference in view of the session table 300.

[0035] Here, each entry for the application context id 320 corresponds to one of the context strings A B of the captured sessions S1-S3. FIG 3B shows a seat table 340 with entries for the license ID 350, total seats available 360 and occupied seats taken 370 for a respective application license. The entries for the occupied seats will vary depending on the number of active licenses granted. The total seats available is generally fixed according to terms and condition of the license, but may be updated by the License Manager 130 as needed. If the number entry for occupied seats taken is less than the number entry for total seats available this means the License Manager 130 has available seats and can grant more seats for licensed application use. When a new license seat is granted the License Manager 130 will also update the session table 300 with the corresponding entry as a new row in order to track this license use.

[0036] Referring briefly back to FIG. 2B in view of FIG. 2D, with respect to User X for session S1 , the application context path 210 is a string representation of machine A id plus the hash value of all the child nodes 231 -232-212 and the root node 211 between app parent node 230 and machine A node 201. For User B for session S2, the application context path 210 is a string representation of machine A id plus the hash value of all the child nodes 221 -222-212 and the root node 211 between app parent node 220 and machine A node 201. In some configurations, the application name (App A) may be included as a node before the hash operation is performed. When comparing the application context paths for User X and User Y, it can be seen that some nodes are common, or shared (e.g., 201 , 21 1 and 212) and some are different (e.g., 220,230, 231 , 232, 221 and 222). The application context path for the nodal child chain (e.g., 231 -232-212-211 versus 221-22-212-211 ) can be evaluated to determine if the remote access instantiating the application is from a different machine or the same machine. In this manner, the License Manager 130 upon receiving the application context paths will be able to determine whether an application was launched from the same machine or different machine.

[0037] FIG 4 provides a flowchart of a method scheme 400 for license control in accordance with one embodiment. The method 400 may use more or less than those number of steps shown. When describing the method, reference will be made to those components of the previous diagrams. Here, the method describes use of the session table300 and seat table 340 in conjunction with license control related to issuance and redaction of license grants. In this illustration, the assumption is a user is loggin in (also “login”) to the same license on the same machine as shown in step 402. That is, the user has already actively received a license for their machine.

[0038] Once a user successfully logs in (i.e., login) to the application, the License Manager 130 can recall the session id 310, the application context id 320, and which license 330 is associated with the session from the session table 300.

[0039] At step 402, a determination is made as to whether the user logins into the same license. When the user tries to log into (aka, “login”) the same license, it evaluates the session table 300 to focus on the user from the same machine from the machine ID of the application context id 320. The License Manager 130 evaluates the session table 300 to determine if the application context id 320 for this current session is “new”; meaning it is different from existing entries. If at step 404, the application context id is not new compared to all entries in the session table, it will allow the login without consuming more seats at step 406.

[0040] Otherwise, if the License Manager 130 determines the app context id is different from those existing in the session table, it will proceed to a strict checking at step 408. Here, a different application context id means the user is accessing from a different machine or a different remote client of the same machine, which consume different seats, and so requires an additional license seat. Strict checking means that it decides it is a new machine (or client machine), and will simply deny it, as shown in step 410, where the log in fails. Briefly, the notion of strict is done to accommodate for debugger behaviors that introduce a new debugger node in the child nodal chain. With strict checking the entire child nodal path is evaluated, for example, MA-> Root - childl -> child2-1 - debugger - child3- 1. The Strict checking feature allows the ISV to require the License Manager 130 to deny login requests associated with debuggers on remote access connections.

[0041] If strict checking is not enabled, it will check whether a new seat is available in the seat table 340 at step 412. If the occupied seat is less than the total seat it means the License Manager 130 has a seat available under this license for the machine (or client machine). It will then allow this log in at step 416, consume one more seat, and add a new entry in the session table 300 for this session. Otherwise, if it doesn’t have enough seats,this login behavior will also be filled as an entry into the session table 300, but will fail the login at step 414.

[0042] The License Manager 130 compares the application context id 320 to existing entries in the application session table 300 to determine if the instantiation 125 of the application is new and different from the existing entries, thereby counting license seats available in the application session table 300. From this analysis, it then decides whether to allow a login for the application without consuming a new seat, or consuming a new seat to allow the login in and adding a new entry for the application context id 320 in the application session table 300; this decision is between the former or latter option. Upon deciding to consume a new seat, it stores the application context id 320 in the application session table 300, assigns a session id 310 for the instantiation 125 of the application to the application context id 320, and associates a license id 330 with the session id 310. Here, when entries differ, the Licensing Manager 130 determines whether a license seat should be granted in view of a license ID seat table 300, and grants the application a license to instantiate if there are seats available in the license ID seat table 300.

[0043] In one example, for the seat table 340 shown in FIG. 3B, and in view of the four session entries S1-S4 in FIG 3A, there are a total of 3 seats for session 1 , session 2, session 3. It appears in FIG. 3A, that User X, user Y and user Z already occupy three seats from the first 3 rows, which means there are no more available seats here. But when session 4 tries to login, the application context ID is the same as session 1 ; it is not new, it is thus different. That means they user is using the same client, so this login will also be successful because it's not a new client. Here, the License Manager 130 can perform a textual string comparison to determine that the application context id 320 for session 1 and session 4 are identical, and thus, the session is from the same client machine. Since the session is from the same client, it will update the table to delete the earlier entry and add the new entry. So, when the user logs out, the earlier session S1 is deleted from the table, and the later session S4 is added. The seat can be resumed later because it was entered as the last session for the application context id in the session table 300.

[0044] This method scheme 400 for license control provides for accurate counting of concurrent sessions of application use by way of the process tree. The solves the problem for the situation wherein an ISV typically licenses an application that allows multiple instances on the same machine, but cannot determine how many remote accessconnections launch instances from different user machines. It preserves the general license use shown in FIG 1 A; namely, that one user can use one license for multiple instances on the same machine from a local service, but adds a license seat limitation to remote access services where each instantiation of an application over a remote access connection will each require a license seat. With remote access (e.g., export desktop, RDP, VNC, etc.) one can use and view the application from a “thin client” where all instances of the application run on the same box, but a license seat is required for each instantiation over a remote access connection.

[0045] FIG. 5 shows a machine 501 that includes circuitry 520, primary memory 530, operating system (OS) 550, Network (NW) I / O device driver 540, virtual machine manager (VMM) (also known as a hypervisor) 551 , at least one application 560 running in a virtual machine (VM) 561 , and one or more storage devices 565. In one embodiment, OS 550 is Linux™. In another embodiment, OS 550 is Windows® Server. Other OSs may also be used. In an embodiment, application 560 comprises one or more of a cloud license manager service having one or more smart license automatic detach policies. Network I / O device driver 540 operates to initialize and manage I / O requests performed by network I / O device 510. In an embodiment, packets and / or packet metadata transmitted to network I / O device 510 and / or received from network I / O device 510 are stored in one or more of primary memory 530 and / or storage devices 565.

[0046] In some embodiments, the machine 501 performs as a computer suitable for use in the system 100 and method 400 to count license seat by application context path, including, but not limited to License Manager 130, Machine A 101 , Machine X 102 and Machine Y 103 in FIG. 2A. In some embodiments, the circuitry 520 comprises one or more processors, with processing cores 522-N, and memory 530 coupled to the one or more processors, wherein the memory includes one or more partitions and computer instructions which when executed by the one or more processors causes the one or more processors to perform said steps and operations described herein. The computer instructions may be stored in the storage device 565 as software code or assembly instructions in some embodiments.

[0047] In at least one embodiment, storage devices 565 may be one or more of hard disk drives (HDDs) and / or solid-state drives (SSDs). In an embodiment, storage devices 565 may be non-volatile memories (NVMs).

[0048] In some examples, as shown in FIG. 5, circuitry 520 may communicatively couple to network I / O device 510 via communications link 555. In one embodiment, communications link 555 is a peripheral component interface express (PCIe) bus conforming to version 3.0 or other versions of the PCIe standard published by the PCI Special Interest Group (PCI-SIG).

[0049] In some embodiments, the storage devices 565 is a disk storage for storing non-sensitive data such as the format preserving tokens representing date date, and associated encrypted data related to primary account numbers (PANs) or personally identifiable information (PI I).

[0050] In some examples, operating system 550, network I / O device driver 540, VM 561 , and application 560 are implemented, at least in part, via cooperation between one or more memory devices included in primary memory 530 (e.g., volatile or non-volatile memory devices), storage devices 565, and elements of circuitry 520 such as processors with processing cores 522-1 to 522-m, where “m” is any positive whole integer greater than 2. In an embodiment, OS 550, VMM 551 , network I / O device driver 540, VM 561 and application 560 are executed by one or more processing cores 522-1 to 522-m.

[0051] In some examples, service provider 501 , includes but is not limited to a server, a server array or server farm, a web server, a network server, an Internet server, a work station, a mini-computer, a main frame computer, a supercomputer, a network appliance, a web appliance, a distributed computing system, multiprocessor systems, processor-based systems, a laptop computer, a tablet computer, a smartphone, a system- on-a-chip (SoC), or a combination thereof. In one example, service provider 501 is a disaggregated server. A disaggregated server is a server that breaks up components and resources into subsystems (e.g., network sleds). Disaggregated servers can be adapted to changing storage or compute loads as needed without replacing or disrupting an entire server for an extended period of time. A server could, for example, be broken into modular compute, I / O, power and storage modules that can be shared among other nearby servers.

[0052] Circuitry 520 having processing cores 522-1 to 522-m may include various commercially available processors, including without limitation Intel® Atom®, Celeron®, Core (2) Duo®, Core i: 3, 5, 7 and 9, Itanium®, Pentium®, Xeon® or Xeon Phi® processors,ARM processors, and similar processors. Circuitry 520 may include at least one cache 535 to store data.

[0053] In some embodiments, data table 51 and shuffled data table 52 and associated index ordering lists are stored in cache for faster processing and secrecy. The generated tables are pinned in memory, not stored on disk and encrypted with a key unique to each installation - derived from a proprietary secret and installation specific details

[0054] According to some examples, primary memory 530 may be composed of one or more memory devices or dies which may include various types of volatile and / or nonvolatile memory. Volatile types of memory may include, but are not limited to, dynamic random-access memory (DRAM), static random-access memory (SRAM), thyristor RAM (TRAM) or zero-capacitor RAM (ZRAIVI). Non-volatile types of memory may include byte or block addressable types of non-volatile memory having a 3-dimensional (3-D) cross-point memory structure that includes chalcogenide phase change material (e.g., chalcogenide glass) hereinafter referred to as “3-D cross-point memory”. Non-volatile types of memory may also include other types of byte or block addressable non-volatile memory such as, but not limited to, multi-threshold level NAND flash memory, NOR flash memory, single or multilevel phase change memory (PCM), resistive memory, nanowire memory, ferroelectric transistor random access memory (FeTRAM), magneto-resistive random-access memory (MRAM) that incorporates memristor technology, spin transfer torque MRAM (STT-MRAM), or a combination of any of the above. In another embodiment, primary memory 530 may include one or more hard disk drives within and / or accessible by service provider 501 .

[0055] FIG. 6 illustrates an example of a storage medium 600. Storage medium 600 may comprise an article of manufacture. In some examples, storage medium 600 may include any non-transitory computer readable medium or machine readable medium, such as an optical, magnetic or semiconductor storage. Storage medium 600 may store various types of computer executable instructions, such as instructions 602 to implement method steps and logic flows described in the above figures. Examples of a computer readable or machine-readable storage medium may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or nonremovable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of computer executable instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, staticcode, dynamic code, object-oriented code, visual code, and the like. The examples are not limited in this context.

[0056] In accordance with various embodiments of the present disclosure, the methods described herein are intended for operation as software programs running on a computer processor or integrated on-chip code within static memory. Furthermore, software implementations can include, but not limited to, distributed processing or component / object distributed processing, parallel processing, or virtual machine processing can also be constructed to implement the methods described herein.

[0057] FIG. 7 illustrates an example computing platform 700. In some examples, computing platform 700 may include a processing component 702, other platform components 704 and / or a communications interface 706. According to some examples, processing component 702 may execute processing operations or logic for instructions stored on storage medium 600. Processing component 702 may include various hardware elements, software elements, or a combination of both. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processor circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), memory units, logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. Examples of software elements may include software components, programs, applications, computer programs, application programs, device drivers, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an example is implemented using hardware elements and / or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints, as desired for a given example.

[0058] In some examples, other platform components 704 may include common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components (e.g., digital displays), power supplies, and so forth. Examples of memory units may include without limitation various types of computer readable and machine readable storage media in the form of one or more higher speed memory units, such as read-only memory (ROM), randomaccess memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), types of non-volatile memory such as 3-D cross-point memory that may be byte or block addressable. Non-volatile types of memory may also include other types of byte or block addressable non-volatile memory such as, but not limited to, multi-threshold level NAND flash memory, NOR flash memory, single or multi-level PCM, resistive memory, nanowire memory, FeTRAM, MRAM that incorporates memristor technology, STT-MRAM, or a combination of any of the above. Other types of computer readable and machine-readable storage media may also include magnetic or optical cards, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory), solid state drives (SSD) and any other type of storage media suitable for storing information.

[0059] In some examples, communications interface 706 may include logic and / or features to support a communication interface. For these examples, communications interface 706 may include one or more communication interfaces that operate according to various communication protocols or standards to communicate over direct or network communication links or channels. Direct communications may occur via use of communication protocols or standards described in one or more industry standards (including progenies and variants) such as those associated with the peripheral component interconnect express (PCIe) specification. Network communications may occur via use of communication protocols or standards such those described in one or more Ethernet standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE). For example, one such Ethernet standard may include IEEE 802.3. Network communication may also occur according to one or more OpenFlow specifications such as the OpenFlow Switch Specification.

[0060] The components and features of computing platform 700, including logic represented by the instructions stored on storage medium 600 may be implemented usingany combination of discrete circuitry, ASICs, logic gates and / or single chip architectures. Further, the features of computing platform 700 may be implemented using microcontrollers, programmable logic arrays and / or microprocessors or any combination of the foregoing where suitably appropriate. It is noted that hardware, firmware and / or software elements may be collectively or individually referred to herein as “logic” or “circuit.”

[0061] In some embodiments, the system 100 of FIG. 2A is technically enabled by way of one or more computing platforms 700 for safeguarding and securing data that includes format preserving tokenization of calendar dates in data, including, but not limited to License Manager 130, Machine A 101 , Machine X 102 and Machine Y 103 in FIG. 2A.

[0062] It should be appreciated that the exemplary computing platform 700 shown in the block diagram of FIG. 7 may represent one functionally descriptive example of many potential implementations. Accordingly, division, omission or inclusion of block functions depicted in the accompanying figures does not infer that the hardware components, circuits, software and / or elements for implementing these functions would necessarily be divided, omitted, or included in embodiments.

[0063] Various examples may be implemented using hardware elements, software elements, or a combination of both. In some examples, hardware elements may include devices, components, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, ASIC, programmable logic devices (PLD), digital signal processors (DSP), FPGA, memory units, logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. In some examples, software elements may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an example is implemented using hardware elements and / or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints, as desired for a given implementation.

[0064] Some examples may include an article of manufacture or at least one computer-readable medium. A computer-readable medium may include a non-transitory storage medium to store logic. In some examples, the non-transitory storage medium may include one or more types of computer-readable storage media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. In some examples, the logic may include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, API, instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof.

[0065] Some examples may be described using the expression “in one example” or “an example” along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the example is included in at least one example. The appearances of the phrase “in one example” in various places in the specification are not necessarily all referring to the same example.

[0066] Included herein are logic flows or schemes representative of example methodologies for performing novel aspects of the disclosed architecture. While, for purposes of simplicity of explanation, the one or more methodologies shown herein are shown and described as a series of acts, those skilled in the art will understand and appreciate that the methodologies are not limited by the order of acts. Some acts may, in accordance therewith, occur in a different order and / or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation.

[0067] A logic flow or scheme may be implemented in software, firmware, and / or hardware. In software and firmware embodiments, a logic flow or scheme may be implemented by computer executable instructions stored on at least one non-transitory computer readable medium or machine readable medium, such as an optical, magnetic or semiconductor storage. The embodiments are not limited in this context.

[0068] Some examples are described using the expression “coupled” and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, descriptions using the terms “connected” and / or “coupled” may indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

[0069] The illustrations of embodiments described herein are intended to provide a general understanding of the structure of various embodiments, and they are not intended to serve as a complete description of all the elements and features of apparatus and systems that might make use of the structures described herein. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. Figures are also merely representational and may not be drawn to scale. Certain proportions thereof may be exaggerated, while others may be minimized. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

CLAIMSWhat is claims, is:1 . A system for a License Model to count license seats of an Application via an Application Context Tree (120), the system comprising: a Licensing API (121 ) executing on a machine (101 ) that supports both a local service and a remote access service for an application, wherein the Licensing API (121 ) by way of the machine: monitors instantiations (125) of the application on the machine; collects a process tree for connections to the machine responsive to instantiation; generates an application context path (210) from the process tree for each connection to the machine for the local service and the remote access service; adds a machine id to a beginning of the application context path (210); logs into a Licensing Manager (130) with the application context path for each connection; and the Licensing Manager (130) communicatively coupled to the Licensing API (121): receives the application context path (210) for each connection of a remote access client (101 / 102); generates a hash for each application context path (230); prepends the machine id to the hash to produce an application context id (3200); and compares the application context id (320) to existing entries in an application session table (300) to determine if the instantiation (125) of the application is new and different from the existing entries, thereby counting license seats available in the application session table (300); and then, decides between one of: allowing a login for the application without consuming a new seat; and consuming a new seat to allow the login in and adding a new entry for the application context id (320) in the application session table (300).

2. The system of claim 1 , wherein the Licensing Manager (130) upon deciding to consume a new seat: stores the application context id (320) in the application session table (300); assigns a session id (310) for the instantiation (125) of the application to the application context id(320); and associates a license id (330) with the session id (310).

3. The system of claim 2, wherein when entries differ, the Licensing Manager (130) determines whether a license seat should be granted in view of a license ID seat table (300), and grant the application a license to instantiate if there are seats available in the license ID seat table (300).

4. The system of claim 1 , wherein the Licensing API is integrated with the application and generates the application context path (210) for each connection when the application logs into the Licensing Manager (130) by searching the process tree from a parent node of the application to a root node of the process tree thereby producing a child nodal path.

5. The system of claim 4, wherein the search is extended such that the application context path sequentially includes the parent node, the child nodal path and the root node.

6. The system of claim 4, wherein the Licensing Manager (130): filters nodes within the application context path based on an exception policy to produce a truncated context path for each connection, wherein said hash is generated from said truncated context path instead of the application context path.

7. The system of claim 4, wherein the Licensing Manager (130), in view of the application session table (300) via string comparison of entries therein, distinguishes between remote sharing software that is running the application and a locally running application; wherein the local service is one among a shell program, such as bash, a terminal program, such as gnome, and wherein the remote service is one among Remote Desktop Services (RDS), Virtual Network Connectivity (VNC), and a secure shell (SSH).

8. The system of claim 4, wherein the Licensing Manager (130), in view of the application session table (300) via string comparison of entries therein, determines if a process is fully local on the machine, or “display exported” to another machine and thereby counts remote sessions each as extra license seats but counts multiple local sessions on the machine just as one concurrency license seat.

9. The system of claim 1 , wherein the Licensing API (121 ) executes on the machine (101); the Licensing Manager (130) executes on a different machine; and both said machine and said different machine comprise: one or more processors and memory coupled to the one or more processors, wherein the memory includes computer instructions which when executed by the one or more processors causes the one or more processors at the one or more servers to perform said operations.

10. A method for a License Model to count license seats of an Application via an Application Context Tree (120), the method comprising steps for by way of a Licensing API (121 ) executing on a machine (101 ) that supports both a local service and a remote access service for an application, wherein the Licensing API (121 ) by way of the machine: monitoring instantiations (125) of the application on the machine; collecting a process tree for connections to the machine responsive to instantiation; generating an application context path (210) from the process tree for each connection to the machine for the local service and the remote access service; adding a machine id to a beginning of the application context path (210); logging into a Licensing Manager (130) with the application context path for each connection; and by way of the Licensing Manager (130) communicatively coupled to the Licensing API (121): receiving the application context path (210) for each connection of a remote access client (101 / 102); generating a hash for each application context path (230);prepends the machine id to the hash to produce an application context id (320); and comparing the application context id (320) to existing entries in an application session table (300) to determine if the instantiation (125) of the application is new and different from the existing entries, thereby counting license seats available in the application session table (300); and then, deciding between one of: allowing a login for the application without consuming a new seat; and consuming a new seat to allow the login in and adding a new entry for the application context id (320) in the application session table (300).11 . The method of claim 11 , wherein the Licensing Manager (130) upon deciding to consume a new seat: stores the application context id (320) in the application session table (300); assigns a session id (310) for the instantiation (125) of the application to the application context id(320); and associates a license id (330) with the session id (310), wherein when entries differ, the Licensing Manager (130) determines whether a license seat should be granted in view of a license ID seat table (300), and grant the application a license to instantiate if there are seats available in the license ID seat table (300).

12. The method of claim 11 , wherein the Licensing API is integrated with the application and generates the application context path (210) for each connection when the application logs into the Licensing Manager (130) by searching the process tree from a parent node of the application to a root node of the process tree thereby producing a child nodal path.

13. The method of claim 13, wherein the Licensing Manager (130), in view of the application session table (300) via string comparison of entries therein, distinguishes between remote sharing software that is running the application and a locally running application; wherein the local service is one among a shell program, such as bash, a terminal program, such as gnome, and wherein the remote service is one among Remote Desktop Services (RDS), Virtual Network Connectivity (VNC), and a secure shell (SSH).

Images