Thanks everyone for your help!
I did some more testing and I now have some code that can decode it reliably. Once I get it finished up i'll post it here as well. The plan is to get it running on a raspberry pi and upload the measurements to a web server. The interface is indeed USB, but the driver for the PL2303 USB device just creates a local COM port to use.
As for the format, I still have not figured out what bytes 3 & 4 are for. They look like some kind of satus codes "2C 0D", but no matter what units I change on the scale or tare , hold, etc, those bytes stay the same. Also, as far as the individual digits I don't think it is just pulling the 7 segment bits. My main reason that in 7 bytes that are transmitted for digits, 08 is used to indicate a decimal. So, even though the decimal is a part of a single 7 segment display it takes up a whole character in the serial output. Grams is the only unit that won't ever have a decimal, so i can check and if there are no 0x08 i know it's in grams. Kind of a dumb way to do it. You would think if they are going to all the trouble to build this they would have thought to include the UNIT in that data stream... crazy. Even the dumb little application (not sure you can even call it an application), forces you to manually pick the unit.
Also, the other thing I never found out was what bytes 12 & 13 are used for. They look like a checksum of some sort, but every checksum/CRC I tried never matched what they had. It's not really that import unless they contain the unit data... which I don't think they do.
so, 0x06 0x06 0x06 0x11 0x08 0x12 0x13 = 7.45 on the display
lookup = {6,7,4,5,2,3,0,1,11,11,11,11,11,11,8,9};
decimal = lookup[ byteVal & 0x0f];
0x06 = blank
0x08 = decimal
0x10 = 6
0x11 = 7
0x12 = 4
0x13 = 5
0x14 = 2
0x15 = 3
0x16 = 0
0x17 = 1
0x1E = 8
0x1F = 9