USPTO bounces its own rendering of DOCX claims

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”

How the non-DOCX penalty will work for non-English filings?

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?”

Seventy-Three Patent Practitioners

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.

Four years later, USPTO still discards characters and hand-keys images

click to enlarge

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:

click to enlarge

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

click to enlarge

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

If there was any doubt that USPTO does not really support non-Microsoft DOCX files

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

click to enlarge

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:

Image result for icon for docx fileImage result for icon for docx fileImage result for icon for docx fileImage result for icon for docx file

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.

Comments on the USPTO’s proposed penalty for non-DOCX filings

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:

USPTO fails to support DOCX from non-Microsoft word processors

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”

The problem with USPTO’s proposed non-DOCX penalty

(Update:  it is time for you, dear reader to consider signing another letter.  See blog posting.)

Until now, it has been optional for a practitioner to file a US patent application in DOCX format rather than in PDF format.  But USPTO now proposes to charge a $400 penalty for filing a patent application in non-DOCX format.  This is a very bad idea, for reasons that I will discuss in detail.  Only if USPTO were to make fundamental changes in its way of receiving DOCX files would it be acceptable for USPTO to impose a penalty for filing in a non-DOCX format.

USPTO needs to follow WIPO’s example, permitting the practitioner to file a “pre-conversion format” version of a patent application along with the DOCX file.  In the event of some later problem with USPTO’s rendering of the DOCX file, the practitioner would be permitted to point to the pre-conversion format, which would control in the event of any discrepancy.

Continue reading “The problem with USPTO’s proposed non-DOCX penalty”