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.