The USPTO’s non-DOCX surcharge is now rearing its ugly head again. Let’s see if, between now and tomorrow, May 15, 2026, the USPTO people in charge of the non-DOCX penalty provide decent software support for the filing of a new patent application that was prepared using a word processor that is not Microsoft Word. Watch this blog to see how the USPTO handles this defect in Patent Center.
Of course it makes sense for any patent office to ask its applicants to hand in a patent application in a computer-readable way (in a way that contains computer-readable characters rather than mere images of characters). But when the patent office tries construct a filing system with the goal (and with some penalty for failing to use that system), the patent office needs to select a character-based filing format that anybody can generate.
One example of how to get this wrong would be if a patent office were to say “the patent application needs to be e-filed using whatever kind of word processor file gets created if you use Microsoft Word for Windows version X.”
Back when the USPTO first got the idea of asking applicants to hand in computer-readable patent applications, the format that the USPTO selected was XML, the authoring system was software provided by the USPTO called PASSAT, and the e-filing sytem was called ePave. Our firm was among the beta testers of PASSAT and ePave, and there was a point during the beta test where our firm, all by itself, had e-filed around ten percent of all of the XML-formatted patent applications that had been e-filed. I bring this up because I think it is important for everyone in the patent community to be aware that our firm has supported the USPTO in this area for more than twenty years.
The USPTO eventually chose to scrap ePave, I think because users did not like to use it.
Then 9/11 happened and with it, the “anthrax scare”. Government agencies worried that someone mailing a document might put anthrax spores into the envelope, and elaborate programs were developed to pass all mail through devices that would try to kill any such spores. I am not making this up.
Eventually the USPTO decided to try again with e-filing (since an e-filed document does not present the anthrax spore worry). This time the file format the USPTO selected was not XML but PDF. And ePave came into existence. The applicant would upload a PDF file into the ePave system and was given an application number and filing date.
Unfortunately when the USPTO selected a PDF format for ePave, the USPTO selected unwisely. There are PDF formats that ensure the presence of computer-readable characters inside the PDF file. There are, for example, PDF formats that can be read out loud by a “screen reader” to a blind person, and which work because the “screen reader” is able to find and use the computer-readable characters contained within the file. (One such format is called “PDF-A” where “A” means “accessible”.) But the USPTO failed to specify that the uploaded PDF file be a kind of PDF having computer-readable characters inside. The USPTO accepted PDF files that are pure image-based files (the kind where you might have scanned a physical paper document in a scanner to yield a PDF file composed of pages where each page is an image).
And so it went for some years, until about ten years ago the USPTO tried once again to try to force its customers to hand in patent applications containing computer-readable characters. The main challenge for this is that whever file format you pick, you really need to pick a format that is well defined, ideally defined by some standard-setting body that is not controlled by (for example) Microsoft.
There are at least two formats that USPTO could have selected for this purpose that would have worked, and USPTO did not pick either of them. One is the above-mentioned PDF-A, and the other is OpenDocument format (having file extension of ODT). Every word processor in everyday use in 2016 was able to generate PDF-A, and very word processor in everyday use in 2016 was able to generate ODT. Either path would have allowed applicants to proceed without having to purchase any particular word processor software made by any particular company (here, the main “particular company” being Microsoft).
But the USPTO did not pick either the PDF-A format or the ODT format as the one for applicants to use. It picked Microsoft Word as the required format.
Of course the USPTO carefully avoided coming out and saying “you must use Microsoft Word” to author your patent applications, in part because this would have been illegal. USPTO said instead “you must hand in your patent application in ‘DOCX format’ or pay a $400 penalty for failing to do so.”
(The penalty is now $480.)
There are several related prolems with the path that USPTO chose, among them that there is no actual single well-defined “DOCX format” other than “the specific dialect of DOCX that you get if you use Microsoft Word to create the file”.
Yes there are at least two supposed standards for what supposedly counts as a DOCX file, but neither of the supposed standards is well defined by any standards-setting body. The various word processor makers that are not Microsoft do their best to try to export into variants of DOCX that look similar to the variant of DOCX that Microsoft Word generates, but given the lack of any clear standard for “what counts as DOCX”, this is not a realistic goal.
And USPTO’s present patent e-filing system for filing in “DOCX standard format” (a standard that does not exist) pretends to accept DOCX files created by many word processors, but actually only works if the applicant chooses to purchase and use Microsoft Word software to create the DOCX file.
I should mention that our firm, in complete support of the USPTO, has participated since the first day of alpha testing of USPTO’s system for e-filing in DOCX format. We pointed out the many flaws in the system starting from the days of alpha test. When USPTO moved forward to beta test, our firm continued to be one of the most active beta testers, and we pointed out the many flaws in the beta-test system. We tried as hard as we could to guide the USPTO toward a standards-based approach for filing patent applications containing computer-readable characters.
We did not succeed. The USPTO maintained the fiction (and it is a fiction) that supposedly there is some meaningful public standard, administered by someone who is not Microsoft, that somehow defines “what counts as a good DOCX file”. And the USPTO maintained the fiction that this (non-existent) standard was what you get when you author a patent application using a Microsoft word processor or a non-Microsoft word processor.
it’s all a fiction. What USPTO really did was develop software (now a core part of Patent Center) that only works correctly if the applicant uses a Microsoft word processor to generate the DOCX file.
This all came to a head yesterday, May 13, 2026, when I did a first test filing of a patent application that needs to be filed by tomorrow, May 15, 2026. It claims priority from a non-US patent application that was filed on May 15, 2025. So this new US patent application will need to be filed by tomorrow, May 15.
So I did the right thing. I did not wait until the last possible day to try to do this filing. I did not wait until the next-to-last day. I tried it two days in advance.
And Patent Center puked on my DOCX file. Patent Center said (falsely) that my DOCX file “contains fonts that are not recognized by the system”.
So I phoned up the USPTO’s Electronic Business Center, reaching a particular agent whom I will avoid naming to protect the person’s identity. I will call this person “Agent AL”. I was given a trouble ticket number of 2-01001251. At the request of Agent AL, I emailed a copy of the DOCX file to Agent AL. Agent AL, who I believe was genuinely trying to be helpful, immediately started telling me where to click in my word processor to make the DOCX file into a kind of DOCX file that would work in Patent Center. By this I mean a DOCX file that would permit me to avoid paying the $480 penalty.
And Agent AL’s first instructions were to do a “Save A”. I said I was looking at my word processor and could not see any “Save A”. I asked what word processor Agent AL was using, and the agent named some particular Microsoft product. I explained that in my firm we don’t use Microsoft word processors, we use Libre Office. Agent AL was unable to tell me how to get my word processor to generate a DOCX file that Patent Center would not puke on.
I then followed the next few would-be workarounds that Agent AL asked me to try. Do a “select all” and pick a single known-to-be-USPTO-acceptable font and save the file using only that font. Which I did, using Times New Roman. Nope, Patent Center puked on the resulting DOCX file. At the request of Agent AL, I repeated the “select all” and forced the entire document to be Ariel font. Again, Patent Center puked on the resulting DOCX file.
Agent AL then asked me to copy the entire file and past it into Notepad. (This eliminates nearly all formatting in almost any computer file.) It was a good idea to try, I will admit it. And then Agent AL asked me to copy from Notepad into a new empty document in my word processor, which I did. And then I did what was required to restore some of the most basic formatting, such as the section headings for “claims” and “abstract”. And I exported the file into DOCX. Again, Patent Center puked on it.
Agent AL promised to escalate this defect in the Patent Center system to “the developers” and promised to get back to me well in advance of May 15.
There are several possible ways that USPTO’s DOCX developers could handle this defect in Patent Center, between now and tomorrow, May 15.
Fix the defect in Patent Center. A first path would be for the developers to fix the defect, so that Patent Center would not puke on the DOCX file exported by my word processor (Libre Office). This would of course be the best path.
Promise to waive the non-DOCX penalty for this patent application. A second path would be for the developers to waive the $480 penalty for this filing. I would file in PDF, which I already know that Patent Center would not puke on, because I tested it. Normally this would lead to a requirement to pay $480. (If I were to refuse to pay the $480 the case would go abandoned.) But the USPTO would, on this path, promise not to impose the $480 penalty.
Provide software free of charge that will generate a variant of DOCX that Patent Center does not puke on. A third path would, I guess, be for the USPTO to provide free-of-charge some software that would generate a kind of DOCX file that would not make Patent Center puke. The clearest path to success would, I guess, be for the USPTO to provide a site license to our firm for whatever flavor of Microsoft Word was being used by Agent AL yesterday.
Arrange for the EBC to edit the patent application using EBC’s version of Microsoft Word to generate a DOCX file that Patent Center won’t puke on. It seemed, from the discussion yesterday with Agent AL, that the EBC people have some version of Microsoft Word that can generate DOCX files that Patent Center won’t puke on. So a fourth path would be for somebody at the EBC to take my word processor file (generated using Libre Office) and edit it so that Patent Center won’t puke on it, And then, I guess, email the resulting DOCX file to me. I could then e-file the patent application in Patent Center and not have Patent Center puke on the file, thus avoiding the $480 penalty.
It is easy to see reasons why one or another of these four paths might not work well for USPTO management.
Path 2, waiving the $480 penalty, would be uncomfortably close to admitting that USPTO got it wrong when it picked Microsoft Word format and presented (falsely) that this is the same thing as “DOCX standard format”, a thing that does not actually exist. Admitting mistakes is hard for any large organization to do, and I get that.
Path 3, admitting that the only way to make a DOCX file that Patent Center does not puke on, and providing free-of-charge software that does make DOCX files that Patent Center does not puke on, would also be uncomfortably close to admitting error. So I can see why this would not work well for USPTO management.
Path 4, having the EBC person use the EBC’s Microsoft word processor to generate a DOCX file that does not get puked by Ptent Center, seems risky to me as a practitioner. What if, a year or two from now, when the patent issues, a square root sign gets changed into a smiley face? Or a Greek letter mu (representing the fraction 1/1000000) gets changed to a Roman “u” (representing the fraction 1/1000)? There will then be finger-pointing as to who is liable for the defect in the issued patent.
The remaining path is Path 1. Put a crack team of smart coders on the task, and between now and then, correct whatever the bug is in USPTO’s DOCX system that pukes on this DOCX file that was created by non-Microsoft software. And correct it by tomorrow morning, so that I can file by tomorrow, meeting the one-year priority date from the non-US priority application.
Watch this space. I will keep you, the loyal reader, updated on how the USPTO handles this problem.
Today is a travel day for me. I am presently in San Francisco, having taught a class yesterday at the spring meeting of AIPLA (see blog article) about PCT e-filing. Today is my day to return home, flying from California to Denver. Most of the day I will be in transit, traveling to SFO airport, and then flying to Denver airport, and then taking an airport van for a couple of hours up into the Rocky Mountains where my home is. But hopefully during my long travel day today, the USPTO DOCX developers will be diligently figuring out why Patent Center wrongly says my DOCX file “contains fonts that are not recognized by the system”. And will fix the defect in Patent Center. And tomorrow morning, May 15, when I am back in my office, I will find that I can file my patent application (using the word processor of my choice) without having to incur the $480 penalty.