Category: non-DOCX penalty

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

A member of the EFS-Web listserv asks if he can hear from people who used USPTO’s XML patent application authoring and e-filing system back in 2002.  Yes our firm was among the beta-testers of that system.  This prompts the following blog article. Continue reading “Who was a beta-tester of ePave?”

I just received a Notice to File Corrected Application Papers telling me that the PDF claims in IFW for my newly filed patent application don’t have the right line spacing.   The Notice says that I have to reprint the claims and send them in again.  But get this — I filed those claims as a DOCX file — a character-based file.  Would you like to make a guess who it is that converted that DOCX file into a PDF file?  Yes.  It was the USPTO that did the conversion to PDF.  Not me.  So it’s the USPTO that got the line spacing wrong. Continue reading “USPTO bounces its own rendering of DOCX claims”

USPTO published a Notice of Proposed Rulemaking some months ago, proposing to hit the filer with a $400 if the filer files a patent application in a format other than Microsoft Word word processor format.  (USPTO says “DOCX” but realistically the only way a filer can get USPTO’s system to work accurately is to generate the word processor file with Microsoft Word, and even then, only with Microsoft Word for Windows, in a very recent version of the software.) 

I published two comments (here and here) explaining some of the reasons why I feel the USPTO got it wrong on this.  And I joined seventy-two other patent practitioners in signing a comment that explored in quite some detail some of the things that USPTO got wrong on this. 

I imagine most of us nowadays have started at least trying to e-file in DOCX, just to try to find out how bad it is so that we can get ready for how bad it will be when USPTO starts charging the $400 penalty.  And recently I realized that there is a very interesting fact pattern that I am quite confident that no one at the USPTO thought about at all when it promulgated this Rule — the fact pattern where the initial filing is in a non-English language. Continue reading “How the non-DOCX penalty will work for non-English filings?”

About forty-six comments have been filed in response to USPTO’s recent notice of proposed rulemaking regarding patent fees.  One of the comments is filed by “Seventy-three patent practitioners”.  Here is the opening paragraph of their letter:

We write as patent practitioners to comment on a Notice of Proposed Rulemaking (NPRM), Setting and Adjusting Patent Fees During Fiscal Year 2020.  The signatories are members of several email listserv groups, a community of patent practitioners. The signatories taken together filed about 20,000 patent applications at the PTO during the past ten years, and paid about $50 million in fees to the PTO in the past ten years.

I am honored to be among the signers of that letter.

On a quick skim, it appears that every comment to this NPRM (including the comment cited above) that touches in any way on the non-DOCX surcharge is critical of USPTO’s effort to try to force applicants to file patent applications in DOCX format through imposition of a $400 penalty for failure to do so.  

In future blog articles I will try to excerpt and summarize some of the views expressed in the comments.

Suppose that there were a computerized system operated by a government agency where the paying customer pastes text characters into the system.  Suppose the text were really important text that needs to appear at a later time in a prominent place on an official government document that bears a gold seal and the signature of the Undersecretary of Commerce.  

The normal sensible thing would be for the text characters to get auto-loaded into the system that prints the official government document, right?

If you were going to make up a hypothetical example of what would be really stupid, your hypothetical example might be that after the customer pastes the text characters into the government system, the government agency flattens the text characters into a TIF image.  And then the government agency carries out OCR (optical character recognition) to recover the text characters for the system that prints the official government document.  And then the document gets printed, and the gold seal is applied, and then the Undersecretary of Commerce signs the document.  In your hypothetical example it would be stupid to do it that way because the Office already was in possession of the actual characters, and anyway the OCR workflow costs money, and every now and then the OCR system might make a mistake.  Of course it would be better to auto-load the text from the first computer system into the second computer system.

Well, you can’t make this stuff up.  What the USPTO actually does is actually stupider than what you would make up.  Yes, several hundred times per day, every time somebody pays an Issue Fee using the web-based issue fee payment system, the customer pastes text characters for the assignee name, the city of the assignee, and the “attorney, agent or firm” into a special page in EFS-Web.  These text characters are all to be printed on the front page of the issued patent.  And yes, after the customer clicks “submit” in EFS-Web, the USPTO flattens the information into a TIF image in IFW.  But what you wouldn’t be able to make up is that USPTO does not even use OCR on those images.  Just a few days after USPTO flattened the text into image format, a human being views the TIF image on a screen and hand-keys the information into the system for printing the US patent.

No, you can’t make this stuff up.

The way that the TIF image got generated by EFS-Web is that it was vector-rendered by a computer from text character information.  This means the OCR would in fact be very close to 100% accurate if the USPTO were to use that path for recovering the characters.  But USPTO does not even use OCR to recover the text from the images.  The USPTO uses hand-keying by a human being to recover the text from the images.

Oh and the amount of time that passes during which this character information is temporarily stored in image format?  Only a few days.  The customer pays the issue fee on some particular day, and the Final Data Capture happens maybe a week later.  

Let’s look at some real-life examples.  The map above shows Radom, Poland, which I understand to be the fourteenth-largest city in Poland, having a population of over two hundred thousand people.  Radom is also the home of a company (my client) that has over the years paid to the USPTO well over a quarter of a million dollars in Filing Fees, Search Fees, Examination Fees, Issue Fees, and Maintenance Fees relating to its inventions.

A few months ago I paid yet another Issue Fee to the USPTO on behalf of this client.  I used the web-based Issue Fee system in EFS-Web.  Here are the characters that I pasted into USPTO’s web-based form 85B:

And here is what USPTO printed on the front page of the patent that the USPTO issued a couple of weeks ago:

Yes, some human being saw the five letters “Radom” on a computer screen and typed the six letters “Random” into a keyboard.

Long-time readers of this blog will recall that I blogged with some enthusiasm about it when the USPTO first launched this web-based issue fee payment system in September of 2015.  In November of 2015, I blogged with disappointment that it had become clear that USPTO was hand-keying the 85B information from the web-based Issue Fee form rather than auto-loading it.  

During the four years that have passed, I would have hoped that maybe my November 2015 blog article would have prompted (or shamed) the USPTO into doing the non-stupid thing with the web-based Issue Fee payment form.  The non-stupid thing would be to start auto-loading the text characters from the first computer system into the second computer system.

But even now in 2019, four years later, USPTO continues to take the text characters provided by the customer in the web-based form, and flatten them to TIF images, and then just a few days later the USPTO has a human being hand-key those same characters into a second computer system.

It pains me to have to say that this is not the first time that the USPTO caused this exact harm to this exact customer.  In 2017 I paid an Issue Fee for this same client, and I used the web-based Issue Fee form.  I pasted the five characters “Radom” into the web-based form.  And the USPTO human being hand-keyed the six characters “Random” into the system for printing the US patent. 

We will, of course, ask the USPTO to provide a corrected patent with the front-page information spelled correctly (not a mere certificate of correction) pursuant to 37 CFR § 1.322(b).

(Corrected September 1, 2019 to reflect that the telltale Microsoft Word file-type icons appear in the Patentcenter e-filing system, not in EFS-Web.)

USPTO presents patent practitioners with a choice of two filing paths — Microsoft Word and PDF.  If you e-file a Microsoft Word file, then that’s what USPTO wants.  If you want to use a word processor other than Microsoft Word, then you face two possible paths.  One path is that you save your patent application as a PDF.  USPTO has proposed that you would have to pay a $400 penalty for e-filing the PDF.  The other possibility is to export your patent application in a DOCX format from your non-Microsoft-Word word processor.  You would then upload the DOCX file to EFS-Web or to Patentcenter (in alpha-test), and EFS-Web or Patentcenter would render the file into a PDF.  You would then be expected to proofread the PDF carefully to detect the corruptions (and there would often be corruptions, documented here) introduced by USPTO’s failure to correctly handle DOCX files generated by word processors other than Microsoft Word.  Here is the adhesion contract that EFS-Web or Patentcenter asks you to agree to:

The PDF(s) have been generated from the docx file(s). Please review the PDF(s) for accuracy. By clicking the continue button, you agree to accept any changes made by the conversion and that it will become the final submission.

Again, if you wished to avoid this malpractice risk, you need merely take either of two precautions:

• purchase and use Microsoft Word, or
• pay the $400 penalty and submit a PDF format patent application.

The situation is that the rendering engine that USPTO uses to render a DOCX file into a PDF is the Microsoft Word rendering engine.  So by definition, the PDF that is generated from the DOCX file will be error-free if you used Microsoft Word to generate your DOCX file.  But if you used a word processor file other than Microsoft Word to generate your DOCX file, the rendering engine offers no assurance of rendering the document accurately.

USPTO disingenuously suggests that there is some uniform “DOCX standard” and that somehow all word processor files that have file names ending in “DOCX” will look the same when e-filed in EFS-Web or in Patentcenter, regardless of the particular word processor that was used to create the word processor file.  This is factually false.

USPTO’s disingenuousness is highlighted by the icon that USPTO uses in Patentcenter to identify the type of file that the practitioner has uploaded.  You can see it three times in this screen shot.  

Yes, USPTO uses the Microsoft Word branded icon to identify the file type for the word processor file that the user has uploaded (that happens to have a “docx” file name extension).  For this particular screenshot, the DOCX files that you see are files that I created using Libre Office.  But did USPTO use a Libre Office branded icon for those files?  No!  USPTO used the Microsoft Word branded icon for those files.  You can see it right there in the screen shot, three times.

If USPTO were really dedicated to trying to accommodate users of word processors other than Microsoft Word, we would not be seeing the Microsoft Word icon three times in this screen shot.

There do exist plenty of truly generic icons for DOCX file types, but USPTO did not choose to use any of those truly generic icons.  Here are some of them:

Let’s see whether someone at USPTO who is responsible for Patentcenter reads this blog and decides to take corrective action.  Let’s see how long it takes for USPTO to change Patentcenter so that it uses an icon that is not Microsoft branded to identify the DOCX files that users upload to Patentcenter.

What would really be excellent is if USPTO were to stop using the Microsoft Word rendering engine in EFS-Web and Patentcenter to render DOCX files into PDF files.  I think the responsible thing would be for USPTO to use (for example) the Libre Office rendering engine to render DOCX files into PDF files.  I say this because I believe the Libre Office rendering engine actually comes much closer to complying with the relevant industry standards (ECMA-376 and ISO/IEC 29500) than does the Microsoft Word rendering engine.

You can see comments which people have submitted to USPTO’s proposed penalty for non-DOCX filings.

Unfortunately the way the Notice of Proposed Rulemaking is written, it mixes together many different issues. So it’s not easy to pick out the comments that particularly address the proposed penalty for non-DOCX filings.

Here are some comments that address this issue:

• Carl Oppedahl
• Dekel Patent Ltd
• Jeffrey Mote

One of the fundamental requirements in the design of an important system like USPTO’s system for e-filing patent applications is that the system should not force the customer to purchase any particular proprietary software as a precondition of use of the system.

USPTO’s initiative to try to force customers to file patent applications in DOCX format is an example of a failure to satisfy that requirement. Continue reading “USPTO fails to support DOCX from non-Microsoft word processors”