E-filing docx files at the USPTO

If you want to be trendy, modern, and up-to-date, you can now e-file “docx” files at the USPTO.  If you do this, not only will you be trendy, modern, and up-to-date, but you will also likely encounter fewer instances in the future in which you need to request a Certificate of Correction or a corrected publication.  Read on to learn how to be trendy, modern, and up-to-date.

When Thomas Jefferson was the Commissioner of Patents, all patent applications in the USPTO were handwritten.  By the mid-twentieth century, USPTO required that patent applications be typewritten.

Things changed in about 2002.  Congress passed a law that established 18-month publication for US patent applications, thus bringing the USPTO a little closer to harmonization with the rest of the world where 18-month publications had been routine for decades.  In response to this law, USPTO got the idea of asking applicants to file patent applications in computer-readable form.  At great expense, USPTO developed an e-filing system called ePave.  In ePave, the practitioner was required to generate the patent application as XML (extensible markup language).  The main point of an XML-formatted document is that it contains computer-readable characters.  The idea was that these computer-readable characters would be used by the government contractor in charge of doing the 18-month publications.  The hope at USPTO was that this would permit USPTO to negotiate a favorable price for the publication service.

In the early days of ePave, we at OPLF struggled mightily to do our patent filings in XML.  The authoring software provided by USPTO for the XML formatting was buggy and very poorly designed from the user interface point of view.  The ePave software for e-filing the XML-formatted patent applications was also buggy and was also very poorly designed from the user interface point of view.  Despite these problems, there was a period of a few months during which OPLF managed to e-file (through XML and ePave) something like ten percent of all of the patent applications that were e-filed at the USPTO during that period.  (This tells you more about the very small number of filers that made use of ePave than it tells you about the volume of patent filings by OPLF during this time.)

USPTO established targets — a date by which 25% of all US patent applications would be filed in character-based format rather than on paper, a date by which 50% of all US patent applications would be filed in character-based format rather than on paper, and so on.

Not even one of those targets was ever met.  At its peak, the success rate with inducing practitioners to e-file a character-based patent application rather than a paper-based patent application never reached even one percent.

One of the saddest things about the ePave initiative at the USPTO is that the computer-readable characters, provided with great struggle by beleaguered practitioners, never actually reached the publication contractor.  Instead, the way that USPTO processed an electronically filed patent application from ePave was to print it out on paper and insert it into the legacy workflow for paper-filed patent applications.

At OPLF we were very stubborn.  We tried very hard to make ePave work.  People at our firm would lose entire weekends struggling with the USPTO-provided authoring tools and the USPTO-provided e-filing system in an effort to e-file a patent application.  It was routine to look back at a successfully e-filed case in ePave and to realize that ten hours or more of practitioner time had been spent trying to get the system to work.

USPTO’s implementation of ePave led to troublesome results in many cases.  In our filings it was routine to encounter places where the Greek characters in a math formula would, within USPTO’s systems, appear later as smiley faces (☺) or simple black rectangles (▮).

After about a year and a half, when it became clear that very few practitioners would ever actually make use of the ePave system, USPTO quietly scrapped it.  During the life of ePave, only a few thousand patent applications were ever e-filed (during a time when over half a million patent applications were paper-filed).  The cost to the USPTO to develop ePave, divided over the small number of patent applications that actually passed through the ePave system, amounted to a loss of something like a thousand dollars per patent application.

USPTO then gave up on collecting computer-readable characters from patent filers, and rolled out EFS-Web.  With EFS-Web, the filer merely uploads PDF files.  The PDF file might simply be a scan — an image containing pixels showing which areas are dark and which are light.  The PDF format is actually a bundle of related formats, some of which are capable of containing computer-readable characters.  But the EFS-Web system never required the filer to use a PDF format that contains computer-readable characters, and indeed the EFS-Web system actually pukes on many PDF files that contain computer-readable characters.  (It pukes with an error message saying that the PDF file contains “embedded fonts”, and the only good way to overcome such an error message is to print the PDF file using CutePDF to generate a second, larger PDF file that will be accepted by EFS-Web.)

So for over a decade, from around 2005 to about 2015, USPTO gave up on trying to collect computer-readable characters from patent filers.  The publication contractor would try, with limited success, to scrape characters from within the small fraction of PDF-filed patent applications that happened to contain such computer-readable characters.  But the vast majority of patent publications and issued patents were typeset using OCR (optical character recognition) applied to image-based PDF files from the IFW system.

In 2016, USPTO regrouped and decided to try again to collect computer-readable characters from patent filers.  This time USPTO was smarter about how it proceeded.  USPTO got more beta-testers involved, and USPTO included beta-testers from a wide range of practitioners.  (With ePave there was not very much beta testing and what little beta testing there was, was offered to a very small number of relatively high-volume filers.)  OPLF was among those invited to participate in this new program, called the eMod Text Pilot Program.

With eMod, the practitioner is invited to upload a patent application in DOCX format.  When USPTO announced that it would require DOCX format, I complained.  DOCX originated as a proprietary Microsoft format, and although standard setting has taken place, the majority of users who would be able to generate DOCX-formatted patent applications probably do it only using Microsoft products such as Microsoft Word or Microsoft Office.  I urged USPTO instead to adopt OpenDocument format (ODT) as the standard for e-filed patent applications in the eMod program.  OpenDocument format was, from its beginnings, an open and non-proprietary format.  This format is supported by nearly all word processors, including nearly all word processors that are free of charge (such as OpenOffice and Libre Office and Google Docs) and including nearly all word processors that cost money.

But USPTO selected DOCX format.  If you wish to use eMod, and if you don’t want to have to purchase Microsoft Word or Microsoft Office, the best way to proceed will be to download and install Libre Office.

How does eMod work?  Basically you take your patent application and break it up into three separate word processor files — one for the specification, one for the claims, and one for the abstract.  Export each file in DOCX format.  When the time comes to prepare your e-filing submission package in EFS-Web, you simply check a box that says you would like to upload DOCX files, and upload the files.

When you do the upload, EFS-Web will render the DOCX files as PDF files.  You are then invited to view and print out the rendered PDF files, so that you can see for yourself whether USPTO’s rendering of the DOCX information is successful.  The idea is that you should use this preview function to work out for yourself whether the formatting worked.  You would not want to find out later that the Greek characters in a math formula had become smiley faces, for example.  The goal is to do the previewing in advance of the actual submission of the patent application, or at least to do the previewing the same day (so that corrective steps could be taken if needed without losing the filing date).

The payoffs for the practitioner from the use of eMod are clear.  First, you can look forward to the 18-month publication having fewer errors if it draws upon your DOCX files, as compared with the outcome if the 18-month pub draws upon an OCRd body of text.  Second, the USPTO system will serve as a convenient offsite backup of the word processor files.  This means that even if your file server were to crash, even if your own word processor files were to be lost or accidentally deleted, you will always be able to get the DOCX files back from the USPTO system.

What will be interesting, of course, is to put the USPTO through its paces.  Practitioners should upload DOCX files containing chemical structures and mathematical formulas.  This will permit the USPTO to gain experience with such data types for purposes of the 18-month publications and for purposes of the issued patents.

The eMod system also permits the user to download DOCX files generated by Office personnel.  As one example, the user could download a DOCX copy of an Office Action and it would make it easy to copy and paste text from the Office Action in a response.

Have you used the DOCX upload function?  How did it go?  Did you find it easy or difficult to do?  Please post a comment below.