Authentication

Abstract

A software license distribution system is arranged for connection between an external software provider and one or more end user clients and provides licenses to access a software service. A storage portion stores a license pool provided by the provider. A request for a software license from a requesting end user client includes a user credential. A verification logic is arranged to verify the user credential by comparing it to a stored database of authorised credentials. A decision logic is arranged such that, when the user is verified, it determines whether there is an available license in the license pool. When there is an available license key, the available license key is selected, but when there is not an available license key, the decision logic requests a new license key from the external software provider. The decision logic is arranged to produce a cryptographic token comprising the selected license key using a cryptographic function and to send the cryptographic token to the requesting end user client and to record the cryptographic token and the user credential as a linked pair in a database.

Claims

1. A software license distribution system arranged for connection between an external software provider and one or more end user clients, said software license distribution system comprising: a storage portion arranged to store a license pool comprising one or more software licenses from the external software provider; an interface arranged to receive a request for a software license from a requesting end user client, said request including a user credential; a verification logic arranged to receive said user credential and to compare said user credential to a set of approved user credentials, wherein the verification logic produces a verification flag only when the user credentials match an entry in the set of approved user credentials; and a decision logic arranged such that, when the verification flag has been produced by the verification logic, the decision logic determines whether there is an available license in the license pool and such that: when there is an available license key in the license pool, the decision logic selects the available license key as a selected license key; and when there is not an available license key in the license pool, the decision logic sends a request for a new license key to the external software provider and, when it receives the new license key from the external software provider, selects the new license key as the selected license key; the decision logic being further arranged to produce a cryptographic token comprising the selected license key using a cryptographic function; wherein the software license distribution system sends the cryptographic token to the requesting end user client and records the cryptographic token and the user credential as a linked pair in a database.

2. The software license distribution system as claimed in claim 1, wherein the cryptographic function comprises an encryption function.

3. The software license distribution system as claimed in claim 2, wherein the cryptographic token comprises the selected license key and a license password associated with the selected license key, wherein the software license distribution system is arranged to set the license password to an encrypted password derived from the user credential.

4. The software license distribution system as claimed in claim 3, wherein the user credential is encrypted to produce the encrypted password, optionally wherein a salt is added to the user credential before the user credential is encrypted to produce the encrypted password.

5. The software license distribution system as claimed in claim 2, wherein the cryptographic function comprises a private key cryptography function.

6. The software license distribution system as claimed in claim 2, wherein the cryptographic function comprises a hashing function.

7. The software license distribution system as claimed in claim 1, wherein the cryptographic function comprises combining the selected license key with a salt before the cryptographic token is generated.

8. The software license distribution system as claimed in claim 1, wherein the requesting end user client uses the cryptographic token to source the software directly from the service provider.

9. The software license distribution system as claimed in claim 1, wherein the requesting end user client provides the cryptographic token to the software provider, which upon receiving the token, grants access to the software.

10. The software license distribution system as claimed in claim 1, wherein the software provider is arranged to provide a software service.

11. The software license distribution system as claimed in claim 10, wherein the software service comprises a communications network.

12. The software license distribution system as claimed in claim 11, wherein the communications network comprises an access network, optionally wherein the access network comprises a Wi-Fi network and/or a mobile wireless network.

13. The software license distribution system as claimed in claim 1, arranged such that the selected license key is returned to the license pool when the end user client releases said key.

14. The software license distribution system as claimed in claim 1, arranged to allocate the selected license key to the end user client with a time limit, wherein upon expiration of said time limit, the selected license key is returned to the license pool.

15. The software license distribution system as claimed in claim 1, arranged such that when the user credentials do not match any entry in the approved set of set of user credentials, the verification logic sends an error message to the end user client.

16. The software license distribution system as claimed in claim 1, wherein the requesting end user client comprises a hardware device.

17. The software license distribution system as claimed in claim 1, wherein the requesting end user client comprises a software application.

18. The software license distribution system as claimed in claim 1, wherein the interface comprises an application programming interface (API).

19. A networked computer system comprising a software license distribution system, a software provider, and one or more end user clients, wherein the software license distribution system is connected between the software provider and the end user clients, wherein the software license distribution system comprises: a storage portion arranged to store a license pool comprising one or more software licenses from the software provider; an interface arranged to receive a request for a software license from a requesting end user client, said request including a user credential; a verification logic arranged to receive said user credential and to compare said user credential to a set of approved user credentials, wherein the verification logic produces a verification flag only when the user credentials match an entry in the set of approved user credentials; and a decision logic arranged such that, when the verification flag has been produced by the verification logic, the decision logic determines whether there is an available license in the license pool and such that: when there is an available license key in the license pool, the decision logic selects the available license key as a selected license key; and when there is not an available license key in the license pool, the decision logic sends a request for a new license key to the software provider and, when it receives the new license key from the software provider, selects the new license key as the selected license key; the decision logic being further arranged to produce a cryptographic token comprising the selected license key using a cryptographic function; wherein the software license distribution system sends the cryptographic token to the requesting end user client and records the cryptographic token and the user credential as a linked pair in a database.

20. A method of operating a software license distribution system connected between an external software provider and one or more end user clients, said method comprising: storing a license pool comprising one or more software licenses from the external software provider; receiving a request for a software license from a requesting end user client, said request including a user credential; comparing said user credential to a set of approved user credentials, and producing a verification flag only when the user credentials match an entry in the set of approved user credentials; when the verification flag has been produced, determining whether there is an available license in the license pool and such that: when there is an available license key in the license pool, the decision logic selects the available license key as a selected license key; and when there is not an available license key in the license pool, sending a request for a new license key to the external software provider and, upon receiving the new license key from the external software provider, selecting the new license key as the selected license key; producing a cryptographic token comprising the selected license key using a cryptographic function; sending the cryptographic token to the requesting end user client and recording the cryptographic token and the user credential as a linked pair in a database.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Certain embodiments of the present invention will now be described with reference to the accompanying drawings, in which:

[0061] FIG. 1 is a block diagram of a prior art networked computer system for software license distribution;

[0062] FIG. 2 is a block diagram of a networked computer system including a software license distribution system in accordance with an embodiment of the present invention;

[0063] FIG. 3 is a schematic diagram showing the system architecture used in the system of FIG. 2;

[0064] FIG. 4 is a block diagram that shows the communication flow between the components of the system architecture of FIG. 3;

[0065] FIG. 5 is a logical data flow diagram illustrating negotiation during the dynamic user license allocation process;

[0066] FIGS. 6A and 6B are schematic diagrams illustrating the benefit of dynamic user license allocation; and

[0067] FIG. 7 is a flow chart the tokenisation process used during the dynamic user license allocation process.

DETAILED DESCRIPTION

[0068] FIG. 1 is a block diagram of a prior art software license distribution system 500. In particular, FIG. 1 provides a high level illustration of the typical way a user 501 accessing a service provided by a vendor 502, i.e. the software provider.

[0069] In the system 500 of FIG. 1, a user 501 sends an access request 503 to the vendor 502 with user credentials which, in this particular example, include a unique identifier e.g. email, phone number, username etc. together with some form of password.

[0070] The vendor 502 validates the authentication details and grants the access request 504. Once the vendor 502 has validated the authentication details and granted the request, the user 501 is provided with access the service 505.

[0071] However, in this case, the vendor 502 is able to track the activities of the user 501 because the vendor is able to trace the service usage of the user 501 based on the details sent in the access request 503 (e.g. the email address or username of the user 501).

[0072] FIG. 2 a block diagram of a networked computer system 510 including a software license distribution system 512 in accordance with an embodiment of the present invention. As can be seen in FIG. 2, in the system 510 of FIG. 2, the user 511 accesses the service provided by the vendor 513 using the software license distribution system 512, referred to hereinafter as a dynamic user licensing allocation system 512, where these terms are interchangeable.

[0073] Initially, the user 511 sends an access request 514 to the dynamic user licensing allocation system 512 with authentication details which includes a unique identifier e.g. email, phone number, username etc. together with some form of password. Thus in the system 510 of the present invention, the authentication details are not sent to the vendor 513 itself.

[0074] The dynamic user licensing allocation system 512 validates the authentication details and maps the user to a license. The dynamic user licensing allocation system 512 then sends an access request 515 that comprises encrypted details to the vendor 513. Importantly, the encrypted details do not allow the vendor 513 to trace back the access to a user or a person, but rather only to this particular session. The vendor then grants the access 516 which then the dynamic user licensing allocation system 512 confirms the access grant 517 to the user 511, who can then access the service 518. Further explanation of the manner in which licenses are allocated is provided with reference to FIGS. 3 to 7 below.

[0075] FIG. 3 is a schematic representation of the architecture of a networked computer system 100 that includes a dynamic user licensing allocation system 108 in accordance with embodiments of the present invention.

[0076] Initially, the user requests authentication access to the software provided by the vendor 105, using user credentials 106. The dynamic rules engine 102, which includes a verification logic 115 and a decision logic 116, is arranged such that the verification logic 115 receives and identifies the user credentials 106 and sends a verification request 107 to an authentication database 103.

[0077] If the user is successfully authenticated by the authentication database 103, the decision logic 116 of the dynamic rules engine 102 will identify an unallocated license key from the available pool of vendor license keys if there is one available in the pool that it has access to.

[0078] The identified license key is encoded in a unique token by the dynamic rules engine 102 and is mapped to user client in authentication database 103, in a manner described in further detail below with reference to FIG. 7. The unique token is sent 109 to the client 101, where the client 101 then sends an authenticate request 110 to the service 104.

[0079] Conversely, if no unallocated license keys exist in the authentication database 103, the decision logic 116 of the dynamic rules engine 102 requests 112 a new license key from the vendor 105 and encodes the license in a unique token which the dynamic rules engine 102 maps to user credentials 114 in the authentication database 103. The unique token including this new license key is sent 109 to the client 101, where the client 101 then sends an authenticate request 110 to the service 104.

[0080] When the user account expires or it becomes inactive, the associated license key is released and returned to the available pool of licenses for reallocation.

[0081] FIG. 4 shows a detailed communication flow between systems to negotiate a dynamic user license allocation in a networked computer system 200 including a dynamic user license allocation system 218 in accordance with an embodiment of the present invention. FIG. 5 is a logical data flow diagram illustrating the negotiation of the dynamic user license allocation process.

[0082] When the user initiates 300 an access request to the client 201, the client sends 302 an access request 209 to the dynamic rules engine 202, which includes a verification logic 219 and a decision logic 220. The verification logic 219 of the dynamic rules engine 202 validates 304 the user access details by comparing the user credential(s) to the database 203 via a database query 210 on the user authentication table 206 (i.e. a stored list of authorised credentials).

[0083] If the user credential(s) are not successfully verified, the dynamic rules engine 304 sends an error message 306 to the client 201 informing them that they have supplied invalid credentials 308.

[0084] Following successful user authentication, the decision logic 220 of the dynamic rules engine 202 looks up vendor licenses available 310, 312 via a database query 211 on the vendor licenses table 207 of the database 203.

[0085] If there are unallocated software licenses available in the vendor licenses table 207, the decision logic 220 of the dynamic rules engine 202 will allocate 314 an available license to the user via a database update query 212 in the user-license mapping table 208.

[0086] Conversely, if there are no vendor licenses available in vendor licenses table 207, the decision logic 220 of the dynamic rules engine 202 requests 316 a new vendor license 213 from the vendor 205. Once supplied 318 by the vendor 205, the new license details 214 are stored in the vendor licenses table 207 via an insert query 211, and then the new license is allocated 314 to the user in the database 203 via a database update query 212 in the user-license mapping table 208 of the database 203.

[0087] Regardless of whether an existing or new license key is used, the allocation 314 of the license involves the creation of a cryptographic token comprising the allocated license key, as described in further detail with reference to FIG. 7.

[0088] The dynamic rules engine responds to the client 201 with the license details 215. The client 201 then uses 320 these license details 215 to send an access request 216 for the service 204, and the service 204 is granted access 217 to the service 204 upon validation of the license, ending 322 the allocation process.

[0089] Once a client session to the service 201 terminates or expires, the dynamic rules engine 202 updates the user-license mapping table 208 and the vendor licenses table 207 to mark the vendor license as being available again.

[0090] FIGS. 6A and 6B illustrate the benefits associated with a software license distribution system provided by embodiments of the present invention. Specifically, FIG. 6A shows a prior art license allocation scheme, while FIG. 6B shows a dynamic user license allocation scheme in accordance with embodiments of the present invention.

[0091] The block 401 represents a prior art one-to-one license allocation process which is known in the art per se. In this block 401, the relationship between a pipeline 426 and a license pool 427 throughout the license allocation process at different stages in time is shown.

[0092] At an initial time 403, user 1 409 already has access to the service, and is allocated license A 410. Subsequently, at time 404, a further user, user 2 411, requires access to the service. At time 405, a new license, license B 412 is allocated to user 2 412. After some time, at time 406, user 1 409 terminates its service session, leaving license A 410 unallocated.

[0093] At time 407 a new user, user 3 413, requires access to the service and subsequently, at time 408, a new license, license C 414 is allocated to user 3 413.

[0094] As outlined above, FIG. 6B shows a dynamic user license allocation scheme in accordance with embodiments of the present invention. The block 402 represents the dynamic user allocation process. In this block 402, the relationship between a pipeline 428 and a license pool 429 throughout the license allocation process at different stages in time is shown.

[0095] Initially at time 415, user 1 421 already has access to the service, and is allocated license A 422. At time 416 a second user, user 2 423, requires access to the service, and as there are no available (i.e. unallocated) licenses, a new license, license B 424 is acquired as outlined above with reference to FIGS. 4 and 5, and this new license B 424 is allocated to user 2 423 at time 417.

[0096] At time 418, user 1 terminates its service session, leaving license A 422 unallocated. When, at time 419, user 3 425 requires access to the service, this available unallocated license, license A 422, is allocated to user 3 425 at time 420.

[0097] Those skilled in the art will appreciate that while in the one-to-one license allocation process of FIG. 6A the system had to acquire three licenses in order to provide the service to three users, the dynamic user allocation process of FIG. 6B requires only two licenses to offer the service to the same three users in the exemplary scenario described. Moreover, the vendor in the dynamic user allocation process of FIG. 6B is unable to determine the identity of any of the users with access to the service, and is also unable to tell whether the license A has been re-allocated to the original user (i.e. user 1) or to a new user (i.e. user 3) due to the tokenisation of the license, as described in further detail below with reference to FIG. 7.

[0098] FIG. 7 illustrates how the tokenization of user credentials ensures that user anonymity is maintained such that the vendor cannot identify the user.

[0099] Initially, the user 601 requests access with their personal username and personal password. The dynamic user licensing allocation system encrypts the user's username using a private key to generate a new license password 602. The dynamic user licensing allocation system then checks for available license keys 603.

[0100] Each license key is typically a string of characters, e.g. a random sequence of alphanumeric characters and/or other symbols. Associated with each license key is a license password, that must be provided to the vendor by a user in order to prove that the user is authorised to use that license. When the dynamic user licensing allocation system allocates a license to a particular user, the system sets the license password to a value generated cryptographically, typically by encrypting the user's credentials (e.g. their personal username or personal email address supplied as the user credentials, or at least part of the user credentials) with a private key. The license password can be set to this generated password, and the license can then be provided to the user together with this newly generated license password so as to allow the user to access the software service provided by the vendor.

[0101] If there are license keys available 613, the dynamic user licensing allocation system will set the license password associated with an available license to the newly generated license password 602 and allocate that license key to the user 606. However, if there are no license keys available 614, the dynamic user licensing allocation system generates a new random license key with the vendor 604 and sets the license password to match the newly generated license password 602. The dynamic user licensing allocation system then allocates the new license key to the user 606. The next time the user tries to access the service, the user enters their personal email and password, and the dynamic user licensing allocation system will map the user to the allocated license key and associated license password and pass those to the vendor (i.e. it passes only the license key and license password, not the user's personal email or personal password). Thus even if the vendor is able to determine the identity of a specific device it is communicating with, the vendor cannot identify the user using the service or track it to any specific person using that device. The license key and license password pair are a cryptographic token that may be passed to the user to provide access to the software service.

[0102] The dynamic user licensing allocation system thus authorises the user to the vendor, but then sits out of further communications, and thus is unable to monitor user data usage patterns and also cannot see the exchanged data itself, providing further privacy benefits for the user.

[0103] When the user no longer has a need for the license and the license is returned to the pool, the dynamic user licensing allocation can reset the password to some other value, e.g. a random value or a default value, until the license is needed again, e.g. by the same user or by a different user, at which time the license password can be changed once more to a user-specific password generated from the user's credentials as outlined above.

[0104] When generating the license password, a salt (e.g. a random or pseudorandom string) may be appended to the user's credential (e.g. the username or email address used to generate the license password) prior to encryption with the private key such that the license password generated for a given user is different each time, further ensuring that the vendor cannot glean information regarding a user's identity by observing the same license password multiple times.

[0105] Thus it will be appreciated by those skilled in the art that embodiments of the present invention provide an improved software license distribution system in which, because the licenses are distributed as a session-specific token, the software provider does not have any knowledge of which specific users have access to the software, improving the anonymity of the users. Similarly, the software license distribution system does not have any knowledge of the usage pattern or the actual data of the user. Thus, advantageously, no single party is able to link the user's identity with the user's usage data or patterns, yielding improvements in the privacy of the license distribution compared with conventional systems known in the art per se.

[0106] While specific embodiments of the present invention have been described in detail, it will be appreciated by those skilled in the art that the embodiments described in detail are not limiting on the scope of the claimed invention.