What you are looking for is called "License Management".

Some solutions that I have seen used:
* Aladdin HASP
* SafeNet Sentinel

Problems with these solutions:
* It is really easy to mess up and lock out your loyal customers,
* Dramatic increase in complexity leads to increased costs, bugs, and decreased 
customer satisfaction,
* Every solution we tried was cracked within months of our software releases,
* The ones that won't pay still won't pay,
* Doing this in a sophisticated manner is _really_ expensive,
* Doing this in a non-sophisticated manner is worse than useless,
* I think eliminating unlicensed copies actually decreased our sales, but I 
couldn't collect the evidence to prove it.

You are probably better off changing your business model.

Richard

On Thursday 25 June 2009 11:48:47 Dustin McQuay <[email protected]> wrote:
> I am working on a program that runs on a user's PC. We do not charge the
> user for the software directly, but we charge them to use it. One of the
> things the software does is generate a report. I need a way of allowing the
> user to pay for a number of credits, and then use one of those credits each
> time they generate a report.
> 
> I am hoping to find some information on how others have solved similar
> problems, but have had a hard time finding anything. I think it might be
> that I just don't know exactly what to search for. Does anyone have any
> experience to offer?
> 
> Here's what I'm thinking so far:
> 
> Have a file store on the PC that contains the number of credits and is
> reversibly encrypted.
> The key to decrypt that file is hard coded into the software.
> To generate a report, the file would be read, decrypted and a decremented
> number would be encrypted and written back to file.
> To buy more credits, it gets iffy. Here are some ideas:
> For a simple first iteration, let's not worry about payment. I just want to
> start by figuring out how to increment the credits.
> Our company could give the customer an encrypted file containing a number of
> credits. The key used for encryption would be the same for all installations
> of the application. That key is used by the application to check if the file
> is authoritative.
> 
> There are glaring problems with this. Just to name a couple:
> 
>     * It may be easy to reverse engineer the keys used for encryption from
> the software.
>     * If a user found that file, they could charge it up, then save it
> elsewhere. Then, after using up the credits, just replace the depleted file
> with the saved one.
> 
> Please let me know if you can offer any ideas or just some key words to
> research.
> 
> Thanks!
> 
> Dustin McQuay

--------------------
BYU Unix Users Group 
http://uug.byu.edu/ 

The opinions expressed in this message are the responsibility of their
author.  They are not endorsed by BYU, the BYU CS Department or BYU-UUG. 
___________________________________________________________________
List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list

Reply via email to