(Updated May 12, 2020. USPTO has fixed this bug, thus clearing trouble ticket CP8.)
Until this week the Patentcenter system was in a controlled beta test, accessible to only a very limited number of beta testers. This week USPTO made the choice to open the beta testing to everybody. This week I also launched the Patentcenter listserv, an email discussion group for users of Patentcenter. (To find out more or to subscribe, click here.) Listserv members have already solved a coding error that USPTO made in Patentcenter in the display of reel and frame numbers.
The way this started was that alert listserv member Shannon Vieau noticed that if you look at a reel and frame number for a patent application in PAIR, and if you look at the same patent application in Patentcenter, the reel and frame numbers don’t match. Prompted by Shannon’s posting, I looked up a few of my own applications, and they all likewise failed to match. I picked one that was a published case. For that case, the frame number is the same in the two places — 366. But in PAIR the reel number is 048299 while in Patentcenter the reel number is 17237. I posted the actual reel and frame numbers in this blog article.
At this point alert listserv member Richard Schafer wrote:
Guess what you get if you add 17237 to 48299: 65536. That just can’t be a coincidence. I haven’t checked any of my cases, but I’ll bet they’re all like that, suggesting some weird piece of bad handling of a 16-bit integer value. How that could pass any level of testing of the code, I can’t imagine.
65536 is one of those really interesting numbers for a person who does a lot of computer programming. It is 216.
Richard then looked up some of his own cases in PAIR and in Patentcenter, and here was his report:
I just confirmed my suspicion with two of my applications. The Patent Center reel number and the PAIR reel number always add up to 65536. That’s just hilariously broken.
At this point alert listserv member and experienced computer programmer Neil Ormos identified how USPTO can fix this coding mistake:
What a great catch! Someone at the PTO owes you a bug bounty!
That kind of error is fairly common. Someone writes the field as an unsigned int and then reads it back as a signed int, or uses sprintf(“%d”) when they should have used sprintf(“%u”). Happens all the time.
“Beta” testing is great, no? You just harness the customer as free labor, and they stand in line to volunteer!
So anyway the coding fix has now been posted here. It will be interesting to see how many days it takes USPTO to correct the coding error in Patentcenter. (This is trouble ticket number CP8, cleared May 12, 2020.)