(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.
