Apparently, the company that originally made it threw a hissy fit when people started hacking the device. Using their software, the concept was barcoded URLs, but every time it resolved a barcode, it uploaded it plus the devices serial number to their website, which is a big privacy no-no.
Digging through the Internet Wayback Machine, I found lots of information on how to disable the serial number (being stored on a standard 93C46), but that didn't interest me as much as decoding the faux-encrypted barcodes it spit out over the PS/2 connection:
.C3nZC3nZC3nXCNPXE3zWChnY.cGf2.ENr7C3n0C3rXDNDXChPZC3nZ.(Yeah, that has my unique serial number in it; I trust you enough to give you that)
In digging around for decrypting this encoding that looks kind of like base64, but isn't, I found mention of being able to place the device in a debug mode where it would spit out the raw barcode, which is what I really want anyways, so a-diggin' I go.
Useful links for the hardware:  .
My particular model seems to be one of the early models, since they hadn't yet moved to the epoxy die-on-PCB process used by most of the documented cases, but oddly didn't match any of those early models I found online either. Reading the second link very carefully, I noticed that they point out that it's the 10th pin on the Hyundai 8051 core that you cut to get it into debug mode, and although mine doesn't have a Hyundai 8051 on it, it was pretty obvious which chip is the CPU on this thing, so I tried cutting the 10th pin on that, and it worked!
Front view: The silkscreen says K023A016 REV:C
Back view: The larger chip is a 74 series chip for interrupting the PS/2 clock to the daughter keyboard for injecting keypresses.
Closeup of the controller (presumably a generic 8051 substitution for the Hyundai found in most other :CATs; understandable due to the general components shortage at the time) : SyncMOS 0022 SM2958 C160
Note that I cut the trace from the 10th pin to the ground plane, which is the second from right pin on the bottom row (The white bar indicates it to the right of "C1 U2"). I haven't extensively tested this from a failure point of view, so you might want to additionally pull it up to 5V, but it's hot here in Davis and that would require turning on a soldering iron in my bedroom...
Putting it back together and firing it up gives the following result for the same barcode as before:
Sweet! Now I have a raw UPC and ISBN barcode reader. I started testing it on other barcodes I had laying around, and it triggered on one in my Mark's Handbook and printed the name "matthews" (pg 10-77 fig 10.7.14). Unfortunately, the book made no comment as to what encoding that specific barcode is, and I couldn't get it to trigger on anything else in the section other than the UPC. This does indicate that it can read at least primitive barcodes with some sort of alphanumeric encoding, which is a little more interesting than just numeric codes.
[UPDATE 9/30/2010: I have confirmed that it does in fact read 2 of 5, 3 of 9, and most Code 39 bar codes I've thrown at it. It just takes a finesse to get it to read, and the initial samples I was using didn't want to register...]
The possibilities as to what to do with it now are pretty appealing. In addition to the obvious cataloging of my book collection, PS/2 is relatively easy to decode with microcontrollers, so working this into some kind of embedded project wouldn't be that difficult.
I didn't bother trying to dump the 93C46 chip due to a lack of interest, but if anyone out there is dying to know (unlikely), I'll see what I can do.