(Update: it is time for you, dear reader to consider signing another letter. See blog posting.)
Earlier today I posted the dismaying realization that Patentcenter lies about the DOCX file that you uploaded (blog article).
This has a very disappointing interplay with the adhesion contract that the USPTO people have had in mind for the people who file DOCX patent applications at the USPTO. We are now on our third variant of the adhesion contract, and arguably this most recent variant is far worse than either of the previous two variants.
Working through this step by step…
First variant of DOCX adhesion contract. The original adhesion contract for DOCX patent applications worked like this.
You upload a DOCX file, the USPTO runs it through a proprietary rendering engine to generate a PDF, the USPTO gives you a quick glimpse at the PDF, and then you click your assent to an adhesion contract that it is the rendered PDF that controls.
In that system, the chief evils for me were:
- the glimpse is too quick because usually it is almost midnight in Virginia, and
- they don’t give you a “pre-conversion format” protection the way WIPO does so that you can fix it later if their rendering engine surprises you, and
- the rendering engine is not open-source but is proprietary. (They never came clean on this but I assume it is Microsoft Word for Windows.)
Second variant of DOCX adhesion contract. More recently the USPTO decided to change the adhesion contract. The way the USPTO publicized the new adhesion contract was like this.
You upload a DOCX file, the USPTO hands you a SHA512 hash of the DOCX file, the DOCX file that you actually uploaded gets preserved for at least a year in USPTO’s systems. (The SHA512 hash permits everyone involved to be in complete agreement as to exactly what was in the DOCX file.) You click your assent to an adhesion contract that says that you have one year during which to gripe about how the USPTO rendered your actual DOCX into PDF, and after that the PDF controls. During that year, if their rendering engine and your rendering engine disagree, you can put in the rendering that you like better and they will grudgingly agree that it controls. I guess you get extra credit if after the filing date, the way you got your rendering into the application file was by coding your own fork of OpenOffice that renders the number 3 into the number 4 in a way that permits you to add new matter after the filing date.
In that system, the chief evil for me was that there was a danger that I might snooze through the year and not notice some subtle bad thing in the USPTO’s rendering engine. Maybe only TYFNIL does the subtle bad thing in USPTO’s rendering engine truly reveal itself. A related evil was the USPTO refusing to open-source its rendering engine.
Third variant of DOCX adhesion contract. But now what we have is far worse than either of the two previous adhesion contracts. Now what we have is this.
You upload a DOCX file, they hand you a SHA512 hash. The DOCX file that you actually uploaded is never preserved in their system and does not get memorialized in the ack receipt. You could preserve in your own files the DOCX file that you actually uploaded, but it does not matter because later the USPTO can simply play dumb and pretend it never received that DOCX file. Instead, what gets memorialized in the ack receipt is a SHA512 hash of a tampered version of the DOCX file. By your silence you are agreeing that the ack receipt has memorialized which DOCX file controls. It is not the DOCX file that you uploaded. It is a DOCX file that contains whatever the USPTO decided it should contain. It does not even matter whether you did or did not click your assent to an adhesion contract!
The one-year period during which you could set up your rendering engine to do battle with their rendering engine becomes a farce because what gets rendered in this battle is their tampered-with DOCX file, not your original DOCX file.
You can’t even make this stuff up! If you actively tried to design a system to destroy any possible trust with the user, I don’t know if you would be able to devise something like this third variant.
There are three more entirety stupid things about this.
1. In the last Federal Register notice, June 2, 2021, https://www.federalregister.gov/documents/2021/06/02/2021-11256/submitting-patent-applications-in-structured-text-format-and-reliance-on-the-text-version-as-the the PTO PROMISED “the USPTO now considers the DOCX document filed by the applicant to be the authoritative document.” Just like Valdimir Putin PROMISED “Oh it’s just a training exercise.” The PTO just crossed the same truthfulness threshold.
2. The hash is stupid — it solves the wrong problem. Even if they archived the exact bits we upload (instead of the redigested bits that Carl describes), it doesn’t address the problem. The dispute isn’t (in first instance) about what bits the PTO received. The question we’ve raised over and over is what those bits mean, how they render. The DOCX standards define the meaning of the bits to be “implementation dependent”–that is, by the words of the standard, the meaning and rendering of the bits is ambiguous.
3. One year is absurd. The first time the PTO lets you know how they interpreted the bits is the 18-month publication.
4. The PTO justifies this choice because “DOCX is a standard.” But then the PTO’s intake engine refuses to accept documents that use features that are within the standard. You can’t have it both ways, boys and girls.
This is not dumb. This is affirmative hostility to the applicant base and to truthfulness, much like the 2006-08 continuations and claims rules.