(Update: it is time for you, dear reader to consider signing another letter. See blog posting.)
What should the the USPTO do so that patent applicants and practitioners will be less reluctant to try filing with DOCX files?
The problem of course is that the e-filing regime which USPTO presently imposes is that when the filer uploads a DOCX file, the USPTO e-filing system (EFS-Web or Patentcenter) then renders the DOCX file into a PDF using USPTO’s own proprietary rendering engine. The e-filing system then displays the PDF and presents an adhesion contract for a click-wrap signature by the filer. The filer is required to irrevocably agree that whatever appears in the PDF as rendered by the USPTO will control for all later purposes.
This e-filing regime is often played out at a time of day that is only a few hours or even just a few minutes prior to midnight on the day that the filer absolutely must get the patent application filed. Under such circumstances it is wholly unacceptable for USPTO to require that the filer proofread the entire PDF from the top to the bottom to see whether the USPTO’s proprietary rendering engine might have rendered something incorrectly.
This e-filing regime presents an unacceptable malpractice risk for the patent practitioner.
This e-filing regime puts the patent practitioner in an untenable position regarding inventor workflow. The inventor is asked to review a draft patent application and to sign an inventor’s oath or declaration based upon that draft patent application. The document reviewed by the inventor might be a word processor file in a format that is commonly understood by the inventor and the practitioner. Alternatively the document reviewed by the inventor might be a PDF file that was rendered by the practitioner. But later, at e-filing time, the practitioner uploads a DOCX file and the USPTO uses its proprietary rendering engine to render the DOCX file into a PDF file. And it is this PDF file which is the subject of the click-wrap adhesion contract. It is this PDF file, which almost certainly is non-identical to the PDF or word processor rendering that was reviewed by the inventor, that USPTO intends will control.
What is untenable is that the practitioner is in the position of filing at the USPTO an inventor declaration that refers to a document or rendering that is known to be non-identical to the patent application actually being filed with that inventor declaration.
Everybody agrees that of course there are goals common to the applicant and to the patent office that are advanced whenever characters are provided rather than mere images.
For many years now, the patent community has suggested several ways to the USPTO by which the USPTO could greatly reduce or even eliminate these profound problems and risks from the existing DOCX e-filing regime. What is regrettable is that USPTO has ignored them all. For example many years ago the patent community pointed out to the USPTO the solution that had been arrived at in the PCT community, namely the filing of a “document in pre-conversion format”. You can read about this in Section 706 of the Administrative Instructions. This approach of course has the profound drawback of being “not invented here” from USPTO’s point of view.
The patent community has also pointed out that most patent applicants have for years been e-filing patent applications as PDF files that do contain characters. USPTO regrettably flattens such PDFs into pure-image TIF files when loading those PDFs into its IFW system. USPTO actively discards those characters. USPTO could get 80% of the way toward its character-capture goal simply by not discarding those characters.
As I say, these two approaches, the “pre-conversion format” approach and the “don’t discard the characters in the PDF” approach, have fallen on deaf ears at the USPTO. So today’s blog article offers yet another suggestion how USPTO could largely eliminate the risks and problems with USPTO’s DOCX e-filing regime.
The chief concern is the mistaken impression that there is some single unambiguous way that everyone in the world renders DOCX into human-viewable images, for example as PDF files. This mistaken impression is communicated by the oxymoron phrase “DOCX standard”. There is no “DOCX standard”. (The USPTO disingenuously and falsely refers to a “DOCX standard” but there is no such thing.)
This lack of any single unambiguous way that everyone in the world renders DOCX into human-viewable images only becomes a problem if a government agency selects some particular proprietary rendering engine and sets up a filing regime in which the rendering takes place at e-filing time and in which the user is required to agree at e-filing time to an adhesion contract that the images rendered by that proprietary engine control for later purposes. The combination of a rendering shortly before midnight on filing day, with an adhesion contract that the rendered images control, is absolutely unacceptable to applicants or to practitioners.
The single best way to eliminate this problem is for USPTO to publish the source code for its rendering engine. It’s as simple as that. Locate that body of source code, and with one or two mouse clicks, publish it on USPTO’s web site. That’s it. Then the problems all go away.
If for some reason the USPTO feels it cannot or will not publish that particular source code, then USPTO should scrap that rendering engine and adopt an open-source rendering engine. Such an open-source rendering engine is available for example in the Libre Office software development platform.
If the rendering engine code is public, then applicants can see for themselves exactly how particular tags and markup will be rendered and in particular can see this well in advance of filing day.
Ten years later in litigation, there would not be any opportunity for dueling experts to pretend to hold different views as to how a particular tag or markup would or would not have been rendered on filing day, because the open-source rendering engine would have been documented and date-stamped in the relevant software development platform.
So there’s the answer, presented in this open letter to the Commissioner for Patents. Publish the source code for your DOCX-to-PDF rendering engine. Do that, and I can promise you that the patent filing community will join you in moving this DOCX e-filing initiative forward.
Thank you for taking another run at resolving what I agree is an untenable way to treat applicants and their representatives. There are so many examples of USPTO initiatives that were implemented only to be withdrawn due to having been ill-conceived. Rather than serving taxpayers and the user community, such initiatives undermine their interest in a well-functioning system, even though that community supported the USPTO’s effort to make the USPTO self-financed via fees that have increased substantially since I entered practice before the USPTO.
While a large number of practitioners are able to read the code, i must admit that despite having a computer science degree, i cannot see myself reading the code, and comparing each file I read to the different tags, etc. For those that do not have extensive computer background, this is even less of an option.
i am fully for using text pdf’s and having the office simply stop this insane docx demand.
yet another option is depositing a visual file, with a docx – for the office’s convenience. The controlling document must be what I saw when I filed.
I also believe strongly that it is unfair and immoral of the Office to demand that after I read the application, the inventor read the application (all which may take significant time) that I must again read the document, and compare every iota prior to committing to the accuracy of the conversion that I have no way to control. It is extremely difficult to do, and moreover, extremely expensive for the client.
And all for the Office to cover it’s incompetence.
i believe that we should simply fight this whole messed up concept with each and every legal way open to us. We did something similar with the insane RCE/continuation regulations, and hopefully will succeed with this new insanity.
Shalom, I’m with you. I’m not a programmer. Publishing source code or any other kind of code won’t help.
And Carl, this is not a case of “if at first you don’t succeed, try suggesting something else”. Several reasonable proposals have been made to the USPTO. The USPTO’s deafness is no reason to put forth another *unreasonable* proposal.
WIPO already solved how to deal with pdfs: allow applicants to submit “pre-conversion” documents. But, yet again, the USPTO refuses to learn from anyone else.
I agree with Shalom. I would have to undergo some serious training to be able to read the code and compare each document to the different tags, etc. If the current system (which I find works well) must be changed, the solution that had been arrived at in the PCT community, namely the filing of a “document in pre-conversion format” seems like a much better alternative.
The idea is not that each and every applicant and practitioner has to sit and read the source code.
The idea is that a few people sit and read it. And that it can be archived and USPTO commits to using that source code and not some other source code. That’s all you need for the transparency to work.