Technical Implementation One of the great benefits of CodeMeter is the fact that it has been offering pay-per-use capabilities for many years already and also accommodates offline use . All licenses , be they dongle-based , computer-based , server or cloud licenses , come with a license option for a pay-per-use counter . This unit counter is set to a starting value by you and then begins to count down . You can read the counter automatically and reset or increase it at will , by an absolute figure or by a relative count . This represents the technical underpinnings for any pay-per-use implementation .
With these foundations in place , you can establish both prepaid and consumption-driven models . Prepaid models would start with the unit counter set to a specific value , which is counted down in response to a specific action . That action is prohibited as soon as the counter reaches 0 . Consumption models set the unit counter to its maximum value of 4 billion ( 0xFF FF FF FF ). The countdown begins , and the difference to the maximum value shows you the number of the actual consumed units .
How the unit counter counts down depends on your chosen business model . If you license your products by usage time , the unit counter would , for example , count down by the minute . The total time is recorded as a value in minutes in the license . Of course , you can also set the interval to 5 or 10 minutes . In these cases , you can leave the count down up to AxProtector ; a manual implementation is not necessary .
If you want the counter to work by numbers of processed dental implants , by printed objects , or by device calibrations , for example , you include this in the API at the right place in your application . This can be done securely by setting the counter to count down first before the actual action is allowed . Naturally , the counter can also be set to count down after the fact . You can also set the counter to deduct
different values for different operations , e . g . two units for a canine implant , but three for a molar .
Only Proprietary Material One common requirement for pay-per-use models is that the machine user is given discounted access to the machine , but only allowed to process material on it that was supplied by the manufacturer .
The most pragmatic way of doing so is a combination of a pay-per-use counter with a defined amount of material . Your user is
allotted x pieces of material and y units . Every time one piece is processed , the counter goes down by one unit . This means that the user can only work with the amount of material he or she has actually purchased . It would , of course , be feasible to use the same units to process “ cheap ” material from the “ grey ” market , but the limit on the actual units makes this choice commercially pointless .
A technically better way is to mark the materials and include means to authenticate the marker in the machine . If the material in question is , for instance , delivered in a cartridge with its own intelligent computing capabilities , a challenge-response technique with asymmetric encryption would be a safe tactic . This is , however , not possible for simpler materials like paper or granulates .
The most sophisticated option would be to define one license per delivery / packaging unit . The license could be tied to specific properties , like a watermark in the material , which would be scanned and checked against the license . It could also be a special property like the typical shrinkage of the implanting block when heat-treating a dental implant .
Creating a Pay-per-Use License The process of creating and delivering a pay-per-use license does not differ from the creation of any other regular license or a subscription or maintenance agreement license . In most cases , the procedure is initiated by an ERP , e-commerce , or CRM solution , which sends the order with the right material number to CodeMeter License Central , where a ticket is created ( with an activation code , product number etc .) and returned . You can decide how the user receives the ticket , e . g . as a PIN letter , a license card , or – the fastest and easiest option – by email .
The user can then transfer the license or the units he has purchased onto a local CmDongle , a CmActLicense bound to a given computer , a license server , or a Cloud server . From that point , he or she has access to the license and free units . Typically , that transfer process is integrated in the licensed software ( leaving the user to only enter the ticket ) or handled via a simple license portal .
There are two options for integrating the interface for creating licenses . Either , you create separate packages with e . g . 10 , 100 , and 1000 units . Or you create an article and leave the unit counter as a dynamic value . Your choice will depend on the capabilities of your ERP , e-commerce , or CRM solution .
9