When the USPTO made Patentcenter available for alpha testing about two years ago, I was one of the alpha testers. As an alpha tester, I reported bug after bug to the USPTO. But I did not criticize the USPTO publicly. I was a good alpha tester, reporting the bugs only privately to the USPTO.
This went on for a year, and then USPTO quietly shifted from alpha testing to beta testing, and it meant that more users got added to the pool of testers. The beta testing was also a closed environment, just like the alpha testing. I was a good beta tester, continuing to report bugs only privately to the USPTO.
I think it is possible that my firm was the most diligent and prolific alpha- and beta-tester of Patentcenter during the closed alpha and closed beta testing phases. What makes me think this is:
- It appears that by the end of 2019, my firm had filed fully half of all of the entries into the US national phase from a PCT application that anybody had filed in Patentcenter (blog article).
- It appears that by April of 2020, my firm had filed at least eight percent of all of the utility patent applications that anybody had filed in Patentcenter (blog article).
- It appears that by April of 2020, my firm had filed at least half of all of the design patent applications that anybody had filed in Patentcenter (blog article).
To the USPTO’s credit, it did fix perhaps one-third of the bugs that alpha- and beta-testers reported. But even now, two years later, many bugs that alpha- and beta-testers have reported to the USPTO have not gotten fixed.
This would not be so bad except that a few months ago the USPTO decided to release Patentcenter for beta testing by the general public. Anybody who wishes may now make use of Patentcenter.
And so as of that time I felt there is no need to keep bug reports private. I set up the Patentcenter listserv, which is an email discussion group for beta testers of Patentcenter. I set up the Patentcenter trouble ticket web site.
What is disappointing is that many Patentcenter bugs that have been reported to the USPTO since it released Patentcenter for beta testing by the public have not been fixed. What is even more disappointing is that many Patentcenter bugs reported a year ago or even two years ago by beta- and alpha-testers have not been fixed.
Here is one example among dozens.
When you upload a PDF as part of your e-filing activity, your natural expectation about it might be:
If you upload it, and if you preview it in the e-filing system, and if it looks the way it is supposed to look, then you can safely click “submit” and it will look that way in IFW.
In ePCT, this is indeed how it works. If it is going to get degraded when you click “submit”, then the preview will show you what the degraded file would look like. This gives you fair warning. You can then set to work trying to figure out what to do differently so that the file will not get degraded so badly.
In Patentcenter, this is not how it works. A file containing gray scale might look perfectly normal to the human eye when previewed in Patentcenter. But it will get degraded badly after you click “submit”, and it might get degraded to the point of being unreadable.
Not only that, Patentcenter might convert it into blank pages.
I am not making this up. Blank pages. The preview will show normal pages that are not blank. And when you click “submit”, what will later turn up in IFW might be blank pages.
One thing that this means is that to protect yourself from malpractice liability when using Patentcenter, you have no choice but to go into IFW after you have e-filed a document, to view it and to see whether it has gotten converted into blank pages. And to see whether it has gotten blurred or degraded, perhaps to the point of unreadability.
This is not easy to do if, as has very often happened in recent weeks, you cannot see it at all in IFW until a day or two after the day that you e-filed it.
Which brings me to my disappointment at USPTO’s failure to attend to bugs that are being reported these days by the listserv community. Take a look at bug number CP27 . This bug is the problem of Patentcenter converting a perfectly readable PDF file into blank pages. This bug got reported to the USPTO on June 8, 2020. I blogged about it on June 8, 2020. Three weeks passed with no corrective action by the USPTO, so one of the listserv volunteers (Richard Schafer) cross-posted the bug report into Ideascale (direct link) on July 4, 2020. Nobody from USPTO has responded in any way to this posting in Ideascale.
What prompted this blog posting today is a disappointing thing that happened yesterday when I e-filed a new patent application in Patentcenter. This time I got lucky and I was able to see the newly filed application in IFW right away instead of having to wait several days for it to be visible in IFW. And I was astonished to see that the USPTO had still not corrected the defect in Patentcenter that Patentcenter sometimes converts a PDF into blank pages.
Months have passed since this extremely serious bug got reported to the USPTO, and it has not been attended to even now.
As I say, in this case I got lucky. Instead of having to wait several days for the newly filed application to be visible in IFW, I was able to see this application right away in IFW. I clicked through the 120 or so pages of what I just e-filed, to see what damage Patentcenter had done to the various files that I had uploaded. Yes, many files were degraded but most of the degradations were modest enough to permit the pages to continue to be human readable. But three pages had gotten converted to blank pages. I then located the source PDF document and printed it to CutePDF and uploaded it and e-filed it again. This time Patentcenter did not convert it to blank pages. Because I was able to deal with this malfunction in Patentcenter on the same day that Patentcenter malfunctioned, I did not need to worry about losing a filing date due to the malfunction in Patentcenter.
But what is so very disappointing is that USPTO has seemingly paid no attention to this extremely serious bug report, even after some three months.
Several aspects of the fundamental baked-in design of PatentCenter guarantee that it cannot possibly ever work reliably.
The first, most inviolable, no-questions-asked principle of a legal document filing system must be “what you file is what we get.” Bit-for-bit. Get your mitts off my bits. The federal court ECF system works that way — when you file a brief, you get a warning — “Did you do your redactions the right way? Have you flattened PDFs to single layer? We’re not going to fix it for you.” Then they take your bits exactly as you file them, and store exactly those bits. WIPO’s ePCT does that at least with the specification. They at least store the exact bits for the drawings, though they don’t (and can’t) guarantee that drawings will be rendered in the final publication exactly as filed (different resolutions, aliasing, etc.) But they come as close as humans can coerce machines to be.
The PTO takes the opposite view — what you file gets treated like input into a sausage factory.
Let’s look at the past. For the last 15 years, the PTO has recommended specific tools and specific settings that you “Print to PDF” — the result you get with the PTO’s settings is a text-form document that gets rendered to pixels by your rendering software. What does the PTO do with that? They convert your text-form document to a flat (fairly low resolution) bitmap! Within milliseconds, what you originally filed gets mangled to a degraded form! The difference between the letter “X” the Greek letter “Χ” or between the letter “x” and multiplication “” is gone. Not because of any necessary or inherent property of computers, but because the PTO threw it away as a matter of design choice.
Drawings submitted in vector form (and thus infinitely perfect at all resolutions, all rendering technologies, for all time) get downsampled to pretty low resolution.
Now let’s look at the future. The PTO, shedding the crocodile tears that “oh it’s so difficult to accurately OCR the flat bitmap back to text,” proposes that a year from now we’ll have to file .DOCX documents, which the PTO will convert to flat bitmaps, and then OCR back to text. Anybody with any experience in computers knows that this cannot possibly work reliably. https://brattahlid.wordpress.com/2012/05/08/is-docx-really-an-open-standard https://www.uspto.gov/sites/default/files/documents/Comment_Seventy_Three_Patent_Practitioners_092719.pdf Any number of people have written to the PTO that the right solution to the OCR problem is “Stop degrading the text-based PDFs that people file. Use them. Just like WIPO. Just like the federal courts. Just like the EPO. Stop being an outlier.” How does the PTO react? By lying its ass off in the notice of Final Rule, by quite overtly rewriting the comments to “leave out the hard parts.”
Then comes Carl’s question today. The problem is that PatentCenter mangles the bits. The moron engineers working on PatentCenter think they know more about the bits than the bits do. That cannot be right. The design philosophy of PatentCenter must be “keep your mitts off my bits.”
Director Iancu, somehow the PatentCenter has become the mouse sticky trap for the dumbest software engineering in the western hemisphere. This is not just dumb. This is abject rejection of the basic science (information theory or Shannon Theory, depending on which grad school you went to) that governs computers.
Director Iancu, your goal has been predictability in proceedings? Then throw out this stupid PatentCenter. Maybe the right answer is to start over with WIPO ePCT, maybe not, but the right answer is unquestionably to throw this out, and start over with competent design foundations.
And then let’s look at the difference between the public comments and the Final Rule notice, and identify the people that rewrote the comments. That’s just plain illegal. Director Iancu, there are lawyers in your organization that need firing, and if you ask, I’ll help you identify them.
Carl, I can understand why the PTO might not have fixed the problem in 3 months, We don’t really know what is causing the problem, so we don’t know how complicated the fix is. But if the PTO is going to try to maintain the fiction that Ideascale is useful, someone needs to be tasked with at least review the Ideascale postings and acknowledging that the PTO will address the issue. Even better would be a response that not only says “We will fix this” but one that includes some identifier, ticket number, etc. that could be used for follow-up by the PTO’s customers. Every problem tracking system I’ve heard of in the past 40 years has had a way of communicating that kind of information not only to the development/maintenance staff responsible for fixing the problem but also to the person reporting the problem, and surely the PTO is tracking their problems internally with some sort of tracking system that could do this. Even if that doesn’t speed up the fix, confirming to the problem submitter that the problem report has been accepted at least lets us know someone is aware of it.
About 30 years ago, when I was a hotshot software engineer (MIT invited me in for a couple afternoons to guest lecture), I wrote an article that might be instructive — David Boundy, A taxonomy of programmers, ACM SIGSOFT Software Engineering Notes 16(4):23-30 (Sept 1991). https://dl.acm.org/doi/10.1145/122552.122553 (also available at a number of other web sites — I’ll let you find them). It wasn’t exactly groundbreaking, just a collection of wise maxims I had learned from mentors, and personal observations of what happens over time to software that starts with bad design foundations.
One observation was that you can never bugfix your way out of badly designed software. When you fix it here, that will destabilize something else over there. You’re always straining against the limits, the concrete walls that were designed in from day one. You have to throw it out and start with sound design foundations.
Director Iancu, it’ll be a lot less expensive for the PTO over time, and literally billions less expensive for the economy, to take the existing PatentCenter as a “lessons learned” dry run, throw it out, and start over.
About 30 years ago, when I was a hotshot software engineer (MIT invited me in for a couple afternoons to guest lecture), I wrote an article that might be instructive — David Boundy, A taxonomy of programmers, ACM SIGSOFT Software Engineering Notes 16(4):23-30 (Sept 1991). https://dl.acm.org/doi/10.1145/122552.122553 (also available at a number of other web sites — I’ll let you find them). It wasn’t exactly groundbreaking, just a collection of wise maxims I had learned from mentors, and personal observations of what happens over time to software that starts with bad design foundations. But it’s apparently good enough that it has ended up in several universities’ reading packets for their software engineering curricula.
One observation was that you can never bugfix your way out of badly designed software. When you fix it here, that will destabilize something else over there. You’re always straining against the limits, the concrete walls that were designed in from day one. You have to throw it out and start with sound design foundations.
Director Iancu, it’ll be a lot less expensive for the PTO over time, and literally billions less expensive for the economy, to take the existing PatentCenter as a “lessons learned” dry run, throw it out, and start over. Have your folks read the paper before beginning.
Do you think that sending this blog post to Director Iancu would have any positive effect towards getting this mess resolved?
Yes that is a very good question. Until now I have not chosen to aim my communications that high. A couple of weeks ago I wrote privately to a person at a fairly high level. It went unanswered. Over the weekend I wrote privately to a person at a somewhat higher level, not as high as Iancu.
If it drags on too long, I suppose what would have to happen is another open letter signed by ninety patent practitioners. Or one hundred ten patent practitioners. Something like that.