In the growing palm-sized computer market, it is becoming increasingly important for developers to protect their software from piracy. The "shareware" concept, while useful for small programs and hobbyist developers, does not provide protection that is required for professional applications sold through online software distribution sources. Now that application beaming technology is becoming commonplace among palm-sized computers, it will be even more important for developers to ensure that only registered users have full access to their applications.

Unfortunately, this goal competes with the convenience of offering real-time fulfillment where the customer purchases a program and is instantly given an unlock key or access to download the full, registered version. Online software distributors generally do not provide a mechanism for customers to submit personal information, and compute a unique unlock key for them. Consequently developers who want security must sacrifice convenience and typically must receive batches of customer information, then compute and email unique unlock keys to each one. This procedure can take days, causing annoyance for the customer and a headache for the developer, and potential loss of sales as customers can become discouraged by the idea of paying now and receiving the software later.

In order to ensure that a software program runs on only one user's device, it should be necessary to require the user to enter a unique key, specific to that device, to unlock the program. If the key is not unique, then it could be shared just as easily as the program itself. The best protection is to require the key to match some piece of information specific to the actual device.

Fortunately, all Palms record the owner’s "Pilot User Name" (PUN), making it easy for developers or software to key off of this unique information to determine if a particular user has registered the software or not. By asking the user for his or her PUN during the software purchase transaction, a developer can derive a unique key that will only unlock the application when it is running on a device with that user's Pilot User Name. Some device models such as the Palm III and newer models actually embed a serial number into each unit which would work just as well or even better than the Pilot User Name, but serial numbers are not universal to all handheld devices.

During the online software purchase transaction, the customer will be asked to provide his RegCode. The online software distributor's website will automatically compute an unlock key based on this RegCode and some proprietary algorithm provided by the developer. Because RegCodes include a checksum, the realtime fulfillment procedure can be fully automated because codes with typos can be trivially rejected. So by the end of the transaction, the user is provided with an unlock key which, when typed into the application's "Registration screen", will permanently unlock the program.

As an example of the security feature of the RegCode system, consider the following scenario. Suppose Abe runs a demo version of some software, and then decides to purchase the full, registered version of the application. During the purchase procedure, Abe will be asked to supply the RegCode (based on his PUN, "Abe") which only appears on his device. The developer will use this RegCode to invent a unique key based on some proprietary algorithm.

For the purposes of this example, the developer’s secret algorithm simply adds up the (ASCII) numeric representation of each character in the RegCode to generate a key. 'A' = 65, 'b' = 98, 'e' = 101, so the key generated will be: 65 + 98 + 101 = 00264.

In order for Abe to unlock the full potential of his unregistered application, he will need to go to the application’s registration screen and type in his unlock code, '264'. The Pilot application will automatically check the RegCode generated by the PUN on his device, and check to see that it generates the same key that was entered. In this case, the unlock procedure succeeds because the application is computing the key using the same RegCode (PUN) and same algorithm as was used by the online distributor to generate the key. The application may wish to store this unlock key in the preferences database for future reference, so the user doesn't have to re-type the key each subsequent time they run the program.

Suppose Abe meets Anne on a flight to Dallas. They are checking their appointments on their Palms, and strike up a conversation that leads to a discussion of Abe's new application. Eventually, they decide to try and beam Abe's unlocked application (including the key used to unlock the application stored in Abe's preferences database) onto Anne’s Palm device.

When Anne runs the application, it will immediately look at her Pilot User Name, and derive a key using the application's proprietary algorithm. But when the application looks up Abe's key of 264 in the preferences database, the application will notice that key fails to unlock the application for Anne's device. The attempt fails because application will expect to see a key specific to the Pilot User Name of "Anne" which is '00386', not '00264'. Typically, the application would continue to run in demo or locked mode if the unlock procedure fails.

1) The RegCode generated by the application must be a series up to 10 colon-separated HEX values followed by a 1 byte HEX checksum. One digit HEX values are permitted: for example "5" does not need to be written as "05". The longest RegCode string can be 32 characters long.

2) The RegCode compliant application must use an algorithm to compute an unlock key based solely on the RegCode as input. No other parameters (such as date, PUN, software title, distributor name, etc) may be used in conjunction with the RegCode to compute the unlock key. Typically, an online software distribution may impose additional restrictions on the algorithm used to produce unlock keys from RegCodes. For example, Handango requires that the algorithm uses a simple reverse-polish-notation arithmetic string using the variables i, the byte position in the RegCode, c, the value at that position, and key, the unlock key computed up to that position.

3) The output key must be a 2-byte unsigned short value (displayed to the user as a decimal number).

Since, in most cases, developers will probably be satisfied to simply convert the customer's PUN into a RegCode, we provide a simple method for reducing a PUN to a RegCode along with free sourcecode. The method we use to convert an arbitrary length PUN (up to 40 characters) down to a maximum of ten values (as required by this RegCode spec) is to first pull up to five characters from the beginning of the PUN, then pull up to five characters from the end of the PUN. After up to five of the first and last characters are pulled into an abbreviated PUN, these characters are simply converted to ASCII hexadecimal values and a hex checksum byte is appended to the end. The following table provides examples of converting actual PUN's to RegCodes.

Actual Pilot User Name	Abbreviated Pilot User Name	RegCode (including checksum)
"Joe"	"Joe"	4A:6F:65:1E
"Joe_Cool"	"Joe_Cool"	4A:6F:65:20:43:6F:6F:6C:CB
"A_very_long_and_unwieldy_user_name"	"A_ver_name"	4A:6F:68:6E:20:77:61:72:74:7A:E7

Any algorithm that parses a RegCode should account for certain predictable typos. Because Hexadecimal digits only contain the 16 digits: 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F, we know that all other characters are invalid, and certain characters should be converted. For example, if a code contains "...:OF:...", it should be replaced with "...:0F:..." If a code contains "...:DI:...", it should be replaced with "...:D1:...", etc. Using the checksum byte at the end will confirm whether these predicted substitutions fixed the code, or if it is still invalid. The source code included with this distribution automatically corrects many kinds of typos. RegCode parsers should also be as lenient as possible since they are designed to parse hand-typed user input. Therefore, they be resilient to allow ";" separators instead of colons, one or two-digit HEX values, and ignore whitespace.

When ordering a product from an online distribution source, the user will be prompted to supply his RegCode. To eliminate user confusion (and the need for customer service intervention) over this point, we recommend three remedies to online software distributors:

1) Only ask for the RegCode on purchase screens for applicaitons that actually require a RegCode

2) Put a "What's This?" Link next to the RegCode input field. This link will popup a window describing what the RegCode is, what it looks like, and where it can typically be found in an application. The window may optionally display some developer-supplied string indicating exactly how to find the RegCode in that application.

3) The purchase screen should immediately validate the code using the checksum and trivially reject invalid codes, prompting the user to double-check and try again.

The user should be able to find his RegCode on a licensing or registration screen in the application. For example:

The distributor's website will take the user's RegCode for the given application, verify it is internally consistent according to the spec, above, and then generate a simple, numeric, 5 digit unlock key.. This key can be generated in real-time and displayed in the order confirmation screen so that the user can immediately use it to unlock his demo program. Once the program has been unlocked, the program should store the key in its preferences database (which gets hotsync'd) so that the user does not have to re-type the key unless he or she deletes and re-installs the application.

Each developer should use his or her own custom, proprietary algorithm to generate a decimal integer unlock key from a RegCode. This algorithm, known only to the developer and the online software distributor must be run on each customer's RegCode by the online transaction website's program, and by the PalmPilot application.

In order to eliminate the need for an online software distributor to do custom programming for each developer's algorithm, a simple framework is provided to facilitate a convenient method for communicating and implementing a variety of algorithms, along with the flexibility for developers to adequately customize their algorithm to offer a good measure of security. The framework we provide uses an "RPNString" (Reverse Polish Notation arithmetic string) to as a convenient way to communicate algorithms between developers and online distributors. It is not necessary for distributors to restrict unlock algorithms to this RPNString framework, however, their framework must certainly be flexible enough to accomodate any type of arithmetic unlock algorithms -- whether they are specified as RPNStrings or not is irrelevant to the RegCode spec.

Using the RPNString framework, each developer is free to invent an algorithm that processes each character of the RegCode once, in order, using a given set of arithmetic, boolean, and logical operations. These operations may operate on any 2-byte unsigned integer value, or any of the following variables: "key", the unlock key's current (2-byte) unsigned integer value, "i", the current position being evaluated in the RegCode, and "c" the value at the current position. The unlock key is initialized to 0, and the algorithm is applied to each value in the RegCode to generate a new key at each step:

The algorithm given at the top of this document (in the "Abe" example) simply adds up the values of the RegCode into the key:

The "license" and "RegCode" programs included with this distribution both use a simple custom algorithm to produce unlock keys from a RegCode. The algorithm is the same as the one given in the "Abe" example at the beginning of this document. That is, unlock keys are produced using an algorithm that sums each of the values in the RegCode together into an unsigned int key.

Communicating developers' custom unlock algorithm to the online distributor.

In order to make it easy for the online distributor to incorporate new applications with new custom algorithms into their automatic unlock key generation procedure, developers would specify their algorithm as an "RPNString" (Reverse Polish Notation string). RPN is simply a way to express mathematical expressions with operators placed after the operands instead of the familiar "infix notation" where operators are placed between operands. RPN allows developers to create sophisticated expressions without the need for parenthesis, and provides an easy way to reject mal-formed expressions.

Infix Notation	RPN Notation
(10 + 2)	(10 2 +)
((4 + 3) / 2)	(4 3 + 2 /)
((5 + i) / (7 + key)	(5 i + 7 key + /)

The complete list of operators supported by the RPNString calculator used to generate unlock keys from RegCodes are:

Algorithms can use any of the operators above to form expressions to operate on "key", "i", "c", or any unsigned short (2 byte) number. Examples of algorithms, expressed as an RPNString are:

A simple RPN calculator is provided in this distribution to help developers experiment to create custom RPNStrings. Online software distributors who would like to facilitate realtime fulfillment by generating unlock keys using RegCodes are free to use the RPNCalc sourcecode to implement their own server-side unlock key generation routine that parses users' RegCodes and developers' RPNStrings to produce unlock keys.

Generating a unique unlock key for each registered user provides the best security for developers. But without real-time key generation, the two-step unlock protocol is too cumbersome. To the developer, it is inconvenient to hand-type each customer's Pilot User Name in order to generate a key, and even more inconvenient when glitches arise as the result of human error. To the end user, it is unfair for them to order and pay for a product, but not be able to unlock it until the developer emails them the key, perhaps one or two business days later.

RegCode provides an error-free mechanism for communicating certain information such as the PUN to an online distribution service so that an unlock key can be generated without human intervention. But more importantly, RegCode creates a standard protocol for both developers and online software distribution services. This is important because RegCode makes it easy for any online software distribution service to generate real-time unlock codes for any application that leverages the RegCode syntax.

RegCode provides a standard protocol for the entire software purchase. The RegCode printed on each application's registration screen follows the same syntax rules between applications so that a single realtime fulfillment program running on the online software distributor's server can parse it. The online software distributor's program that parses the RegCode uses a custom unlock algorithm for each developer in the form of a standardized RPNString. Finally, the unlock key generated is always a 5 decimal digit number so that the developer always knows what kind of input field to provide on the registration screen. Standardizing the procedure eliminates duplication of effort required and customization that would be required by multiple conflicting schemes, and also provides for a single mechanism familiar to all users which can help to streamline the registration process.

Online software distributor PalmCentral currently has a solution based on RegCode available 1/2001, but it currently doesn't meet the RegCode spec, as users are asked to supply PUN's instead of RegCodes on the login screen (providing an opportunity for human error) I hope they will correct their implementation to conform to the RegCode spec at an early date. PilotGear HQ has also made preparations to support RegCode, and they are expecting to have support which conforms to the spec available soon.

license.c -- Does conversions from Pilot User Name to RegCode to Unlock key and back (using the algorithm from the "Abe" example, above.)

RPNcalc.c -- Takes in a customer's RegCode and developer's RPNString as parameters, and computes an unlock key

RegCode.c -- The smallest PalmPilot application to demonstrate the RegCode unlocking procedure.