This manual describes the architecture of the Licenturion web application. We first sketch the methods available for licensing your software applications, namely (Personal) Product Keys and Product Activation. So we basically start with a short summary of the introductory sections of our two implementation manuals, which are available as PDF files:
So, if you are already familiar with the licensing methods, simply skip the following three sections and look at the remaining parts of this document that illustrate the use of the Licenturion server.
If you are already familiar with our web application and if you are interested in how to integrate the Licenturion server with your own web server, have a look at our integration guide.
Product Keys are case-insensitive sequences of 32 letters, e.g.
The idea is to make your application or certain features of your application available to an end-user only after he or she has supplied a valid Product Key to your application. Let us assume that you were selling a shareware word processor. You would then, for example, choose to restrict the shareware version by disabling - or "locking" - the "save" and "save as" functions. In this way an end-user would be able to install and evaluate your word processor but he or she would not be able to use it for any real work. In order to obtain a fully functional version, the end-user would have to buy a Product Key from you, supply it to the word processor installed on his or her computer, and thus enable - or "unlock" - the "save" and "save as" functions.
For classic (non-shareware) software sales a Product Key would be required to use your software application at all. The end-user would then typically be asked for his or her Product Key during installation of your software application or when running it for the first time.
To independently unlock individual parts or features of a piece of software, each Product Key contains a 32-bit payload, which can be extracted by the software application. The interpretation of the payload is up to the software application. It could extract the payload from a Product Key and, for example, use it as a bit-mask, each of the 32 bits enabling or disabling a certain feature of the application.
The most significant 13 bits of the 32-bit payload can alternatively be used for storing an expiration date, still leaving the least significant 19 bits for user-defined content. When the expiration date of a Product Key is reached, the Product Key becomes invalid and the software application returns into the state that it had originally been in before the Product Key was entered by the end-user. These temporary Product Keys are typically used in shareware scenarios to implement trial periods, during which a fully unlocked version of a piece of software can be evaluated at no cost.
To eliminate the risk of pirates writing "key generators" for your software application Product Keys are based on public key cryptography. This reliably foils any attacks along these lines.
For further information please consult the implementation manual.
Personal Product Keys
In addition to "key generators" for illicitly generating valid Product Keys, any schemes working similarly to Product Keys face the threat of end-users sharing their Product Key with other end-users or using a single Product Key to unlock more than one installation of your application. The former threat can be mitigated by psychologically discouraging end-users from disclosing their Product Key to others. This is the idea behind Personal Product Keys. Both threats can also be addressed by technical means - as implemented by Licenturion Product Activation - instead of psychological means.
Personal Product Keys bind a Product Key to the identity of the end-user that the Product Key has been issued to. They consist of a case-insensitive Product Key, e.g.
and an identification string - the user ID - of maximally 200 characters that uniquely identifies the end-user, e.g.
A Personal Product Key will only be considered valid, if both of its parts, i.e. the Product Key and the user ID, are presented. When unlocking your application or selected features of your application, end-users therefore always have to supply their identification string in addition to their Product Key. So, sharing a Personal Product Key with other end-users requires sharing the user ID. This prevents anonymous sharing of Personal Product Keys and establishes a psychological barrier that discourages end-users from disclosing their Personal Product Key to others.
Personal Product Keys also employ digital signatures based on public key cryptography to put a definite end to the threat of "key generators."
Personal Product Keys also contain a 32-bit payload. And again, the most significant 13 bits of the payload can be used to store an expiration date for the Personal Product Key.
For further information please consult the implementation manual.
The idea underlying Product Activation is to enable the use of a each copy of a software application or the use of certain features of each copy exclusively on a single computer. Establishing such an exclusive binding between a given copy and a given computer is called activating this copy for this computer. Activation for a computer requires interaction of your end-users with you or with Licenturion.
Let us assume that you were selling a shareware word processor. You would then, for example, choose to restrict the shareware version by disabling the "save" and "save as" functions. In this way an end-user would be able to install and evaluate your word processor on his or her computer but he or she would not be able to use it for any real work. In order to obtain a fully functional version, the end-user would have to pay you and ask you or Licenturion for assistance in activating the copy of your word processor for his or her computer to enable the "save" and "save as" functions - exclusively on this computer.
For classic (non-shareware) software sales activation would typically be required to use your software application at all. Activation for a single computer would then be included in the sales price and be carried out by the end-user in the course of installing your software.
So, how does this prevent piracy? After your software application has been installed on the end-user's computer he or she activates it for this computer in order to be able to use it at all or to use all of its features. Let's assume that the end-user illicitly installed your software application on a second computer. He or she would then have to activate, with your or Licenturion's assistance, the application a second time for the second computer. Noticing, however, the end-user's attempt to activate your application for a different computer, you or Licenturion would deny activation and thus prevent any illicit use of your software application on more than one computer.
In order to be able to establish a binding between a copy of a software application and a given computer, we need means to uniquely identify each distributed copy of a software application and to identify the computer that this copy is to be bound to without disclosing any sensitive information about this computer.
Identifying a copy of a software application is easy. We just have to supply a unique Serial Number with each copy, e.g. by means of a sticker on the CD-ROM jewel case. For Product Activation we use Serial Numbers that are sequences of 16 characters, e.g.
Product Activation identifies a computer by considering nine characteristics, e.g. the make and model, of a variety of hardware components contained in the computer and constructs a Hardware Hash - the identifier for a computer - from the gathered information. A Hardware Hash thus represents the hardware configuration of a computer. Note that the term hardware configuration comprises, in the context of this manual, only some selected hardware components and not the full hardware configuration of the computer.
Hardware Hashes are sequences of 12 characters, e.g.
Like Product Keys and Personal Product Keys, Product Activation supports a 32-bit payload that can be used to carry user-defined content. Again, 13 of the 32 bits may carry an expiration date for the activation, providing support for temporary activations that last for a given number of days.
For further information please consult the implementation manual.
The Licenturion server enables you to
In addition, your end-users interact with the Licenturion server to perform activation of their individual copy of your software application.
Product portfolio, products, product versions
Your account on the Licenturion server is able to handle as many different software applications and as many different releases of each software application as you need. The server maintains a product portfolio that contains products representing the software applications that you have decided to license based on one of the Licenturion licensing methods. Each of the products supports an arbitrary number of product versions, each product version representing a release of the software application represented by the product.
The licensing method - Product Keys, Personal Product Keys, or Product Activation - to be used is selected on a per-product basis. In contrast, generated (Personal) Product Keys and Serial Numbers as well as the libraries and COM components are always specific to a single product version.
Assume that you were selling the initial release - release 1.00 - of a word processor and that you had chosen to license it to your end-users based on Product Activation. You would add a product to your product portfolio to represent your word processor and select Product Activation as its licensing method. You would then add a product version to the product to represent release 1.00 of your word processor, generate Serial Numbers for this product version, and download the library and COM component supplied for this product version to integrate Product Activation into release 1.00 of your word processor.
Assume that you were later planning a new release - release 2.00 - of your word processor and that this release contained substantial improvements over release 1.00. You would want people to pay for this new release, even if they had paid for release 1.00 already and, hence, to issue new Serial Numbers for this release. Otherwise end-users in possession of a Serial Number for release 1.00 could reuse this Serial Number to activate a copy of release 2.00. So, you would add another product version to your product, generate fresh Serial Numbers for this product version, and download the library and COM component supplied for this product version to integrate Product Activation into release 2.00 of your word processor.
The library and COM component downloaded for a given product version would only work in conjunction with Serial Numbers generated for the same product version. The library and COM component obtained for release 1.00 would thus only work with Serial Numbers for release 1.00 and the library and COM component obtained for release 2.00 would only work with Serial Numbers for release 2.00.
So, how does the Licenturion server handle minor updates like, say, a bugfix release 1.01 that is free of charge for people that have bought release 1.00? In this case you would want end-users to be able to keep using the Serial Numbers that you supplied to them for release 1.00. However, creating a new product version for release 1.01 would make the Serial Numbers generated for this release incompatible with the Serial Numbers generated for release 1.00. Actually, to keep things simple, the Licenturion server does not handle this case at all. You would simply not tell the server about release 1.01 and, behind the server's back, continue using the Serial Numbers, the library and the COM component previously obtained for release 1.00 also for release 1.01.
Adding products and product versions
Registering or logging into the Licenturion server takes us to the main page. The main page gives an overview of our product portfolio, i.e. a list of our products and the product versions corresponding to each product. Initially our product portfolio is empty and the main page looks as follows.
To add a product to our product portfolio, we simply click on the "Add product" link, which takes us to a page that asks us to enter information identifying the software application represented by the product and to select one of the three Licenturion licensing schemes to be applied to our software application. For now, let's just enter something identifying an imaginary word processor and let's select Product Activation as the licensing scheme.
Clicking the "Add" button inserts the newly defined product into our product portfolio. As a product without any product versions does not make any sense the server assumes that we would also like to add a first product version to the newly created product. So it automatically takes us to the appropriate page, which asks us to supply a version identifier, e.g. a version number such as "1.00" or something more complex like "1.00 beta", and a comment describing the product version to be created. Let's again enter something matching the initial release of our imaginary word processor.
Clicking the "Add" button associates the newly defined product version with the previously defined product and takes us back to the main page, which now lists the created product, the created product version. If we had already generated any Serial Numbers for the product version, they would also have been displayed. Any specified time is currently local time in Berlin, Germany.
Working with products and product versions
The links to the right of each listed product and product version trigger operations that affect the respective product or product version. Let's first have a look at the operations available for each product.
Add product version. This enables us to add further product versions to the product. Clicking on this link would take us again to the page that requests a version identifier and a comment.
Edit scoring. This operation is only available for products licensed with Product Activation. We'll discuss it in the next section.
Delete product. This irrevocably removes the product from our product portfolio, together with all product versions belonging to the product. Before anything is deleted we are taken to a confirmation page that asks us whether we are sure about deleting the product. BE VERY CAREFUL!
For each product version the following operations are available.
Generate Serial Numbers. This generates Serial Numbers for the product version. For Product Keys and Personal Product Keys this operation is named Generate Product Keys and Generate Personal Product Keys, respectively.
Buy credits. Generating a Serial Number, a Product Key, or a Personal Product Key each cost one credit. Initially, as can be seen in the above screenshot, the Licenturion server grants us 10 credits for testing purposes, which are good for generating 10 Serial Numbers, 10 Product Keys, or 10 Personal Product Keys. If we desire more than the initial number of credits, this operation enables us to buy them.
Download development library. This lets us download the library and the COM component for the product version as a ZIP archive. In addition, the ZIP archive contains an implementation manual and some examples. Remember that each library and COM component as well as each Serial Number or (Personal) Product Key is individually tailored to a single product version. A library or COM component associated with a given product version only works in conjunction with Serial Numbers or (Personal) Product Keys generated for the same product version.
Edit activation state. This operation is only available for products licensed with Product Activation. We'll discuss it in the next section.
Delete product version. This irrevocably removes the product version. Before anything is deleted we are taken to a confirmation page that asks us whether we are sure about deleting the product version. BE VERY CAREFUL!
Let's continue our tour of the Licenturion server and click on the "Generate Serial Numbers" link to add some Serial Numbers to our product version. We are taken to a page that asks us how many Serial Numbers we would like to create and what we want the payload to be by entering it as a decimal number or a hex number in "0x" notation.
If we check the "Use Date" box, 13 bits of the payload will be reserved for an expiration date, leaving 19 bits for us to use. The required format of the expiration date is either YYYY-MM-DD, e.g. "2004-02-24", or simply a single number giving the number of days from today, e.g. "7" for one week from now.
As said above, up to 10 Serial Numbers are supplied free of charge, so that we have something to play around with when evaluating the Licenturion licensing schemes. Let us generate five Serial Numbers. Clicking on the "Generate" button adds the selected number of Serial Numbers to our product version and returns us to the main page, which now also lists Serial Numbers.
Clicking on the "5 Serial Numbers" link displays the five generated Serial Numbers in a separate browser window, resembling the following list.
The leading number in each line is the sequence number. It is incremented for every generated Serial Number.
To display all Serial Numbers that have been generated for a given product, click on the "Display all Serial Numbers" link.
Had we chosen Product Keys instead of Product Activation, the generation process would still have looked very similar: click on the "Generate Product Keys" link, specify that we need five Product Keys, specify the payload by entering it as a decimal number or a hex number in "0x" notation, specify whether we would like to use an expiration date, and, if yes, specify the expiration date, then return to the main page, and finally click on the "5 Product Keys" link to obtain a list that resembles the following.
For Personal Product Keys, the generation process is slightly more complex as we have to specify the user IDs to be used with the Personal Product Keys. Clicking on the "Generate Personal Product Keys" link takes us to a page that lets us specify a list of names (user IDs) to generate Personal Product Keys for. We have the choice between two input methods for this list. We may either upload the list as a plain ASCII file or enter the list into a text input field on the page. Requesting Personal Product Keys for five users and choosing the latter input method could look as follows. Note that we can again specify a payload and an expiration date for the Personal Product Keys to be generated.
Clicking on the "Generate" button would take us back to the main page and selecting the new "5 Personal Product Keys" link would result in a list resembling the following.
Again we find the sequence number at the beginning of each line, which is followed by the Product Key component of the Personal Product Key. The rest of each line contains the user ID component of the Personal Product Key.
The example programs
The ZIP archive containing the development library and the COM component also includes example programs and their source code. To get a first impression of Product Keys or Personal Product Keys we recommend that you run the "DialogBox.exe" executable contained in the top-level directory of the ZIP archive. For Product Activation we recommend that you use the "ActWiz.exe" executable, which can also be found in the top-level directory of the ZIP archive.
Remember that the ZIP archives are individually tailored to products. So, if you download the ZIP archive for a product that, for example, employs Product Keys or Personal Product Keys, this ZIP archive will contain the "DialogBox.exe" executable, but it will not contain "ActWiz.exe".
Tasks specific to Product Activation
The "Edit scoring" link enables us to modify the parameters of the scoring scheme - i.e. the two individual score values for each characteristic, the thresholds for desktop computers and notebook computers, the length of the reset period, and the allowed number of first-time activations per reset period - by modifying the values in the following form. Please consult the implementation manual to learn more about scoring.
In addition, the coincidence matrix reflecting the currently configured scoring model is displayed at the end of the page. the following form. Please consult the implementation manual to learn more about the coincidence matrix.
The "Edit activation state" link allows us to modify the number of first-time activations of a given Serial Number in the current reset period. Please consult the implementation manual to learn more about why you might want to do this.
End-users access the Licenturion server via
to manually activate their copy of our software application. They do not need an account on the Licenturion server to do so. The page asks them for their Serial Number and their Hardware Hash and, if activation is granted, returns the matching Activation Code along with the number of allowed first-time activations remaining for the current reset period and the number of days until the end of the current reset period.
Alternatively, activation can be performed automatically and with a minimal level of interaction for substantially improving end-user convenience. Please consult the implementation manual for a detailed discussion of the activation process.