To my knowledge, there's no unique immutable data. If you don't think that they'd do things like hack appvars or bother to discover an encryption method, then a simple checksum (adding all the bytes together) of the calc ID is probably enough.
I don't know how to get the ID, so you'll just have to wait for someone who does and you should be set.
You program would, then, at start-up checksum the ID and compare it to the one in the appvar. If they're different, then it would quit.
You'd also need to write a small program to generate the appvar, but that's trivial once you have the ID

There's the problem that you can change your calc's ID, because it's stored in flash. However, most people won't bother to mess with that, so it's probably a good start.
However, if you don't mind waiting, SirCmpwn's store idea (in the funding topic, IIRC) will probably include a DRM-type mechanism.
To get the ID to begin with, you'll need some ASM, which I don't exactly know. There's almost certainly a bcall for it, but otherwise you'll have to unlock flash.
Whatever en-/decryption method you use, be aware that you have to be able to prevent the user from simply changing the appvar to match their calc ID. A method like app signing (but with a secret key only you know) could work, but getting enough strength to prevent quick cracking is difficult if not impossible to do with good speed.

Yep, every week with a bunch of Cemetech guys. Same chat too. I don't join, though, because I barely understand spoken english

If you listen enough, maybe you could get better Reading/Writing and listening/speaking are two totally different sets of skills, I must agree.
More on topic, I need to start attending again... I keep forgetting

I'm going to agree with Sir's general opinion here. TI-Basic, for small programs, is not, IMO, a good idea because you can only edit one program at a time, so when you switch sub-programs you have to scroll. It also fills the programs menu and the arch/del one too. Of course, that's not practical for larger programs, and in that case you might be working on a sub-program for long enough to make switching not a concern. The same general idea goes for most calculator things, I think.
As for computer languages, you can edit multiple files at once and using multiple files is generally painless. It provides for more organization and is simple enough to do, so why not? As for the many files problem, source (for non-interpreted languages) can be packed in an archive (like .zip) or put in a separate folder, and, in the case of Java, .jar files put everything into one file.
There's my two cents (This isn't meant to attack any others' posts, just to be certain )

I'll take it
So, a base-10 number can be represented as a_n*10ⁿ+a_n-1*10^n-1+...+a₁*10+a₀
You can find divisibility by nine by finding the remainder when the number is divided by nine, in other words, by taking the number mod 9.
So, 10 = 1 (mod 9), and also 10ⁿ = 1 (mod 9)
This means that a_n*10ⁿ+a_n-1*10^n-1+...+a₁*10+a₀ = a_n+a_n-1+...+a₁+a₀ (mod 9)
So, the remainder of a number divided by 9 is equal to the remainder of the sum of its digits written in base 10 by 9.
More generally, this is the divisibility test for n-1 in base n.

I'd totally buy that shirt if I could. Nice, cooliojazz
[bigego]Hey, my name's on there [/bigego]
Edit: Ah, the order is by most posts. That'd explain it.

Java has no built-in syntax for properties, so things work slightly differently. You have to declare two methods, one for getting (typically called "get{variable}()" or "is{variable}()" for booleans), and one for setting (Typically "set{variable}()").
An example:
class Properties {
    private int property_;
    public int getProperty() {
        return property_;
    }
    private void setProperty(int property) {
        property_ = property;
    }
}Of course, you would probably check values or other things, like compynerd said. But that's the basic outline. (Note that setProperty(int) is private. You can do anything with these that you can with other methods, because they are methods. )