Update: Thanks to Simon Booth for pointing out the uspto docx support documents
I just read Mike Borella’s informative post on patentdocs.org, which builds on an informative post by Carl Oppedahl. Both talk about how the proposed $400 fee for non-DOCX filing should be postponed because EFS DOCX filing is not ready for prime time. I fully agree. I also have a suggestion for helping solve the problem.
In principle, I love the requirement of DOCX filing because it makes those files naively text searchable/parseable rather than relying on OCR after the fact (of course, that assumes we can actually access to the files to search/analyze them, support that cause here). This of course has massive efficiency benefits for the USPTO and it also greatly benefits stakeholders by enabling all sorts of next-generation search, analytics, and automation tools (all of those benefits are discussed in our letter to Director Iancu, which you can sign here).
BUT, ensuring that a DOCX filing is in a format that will support such later text search/analysis is very difficult because there is no standard format for a patent application. All of us practitioners have our own quirky preferences for font, font size, indentation, line breaks, headings, etc. etc. etc. Then throw in equations or sequence listings and it gets even worse.
So how can we help speed the process of getting DOCX filing sufficiently user-friendly to the filer as well as making sure the document can be accurately searched/analyzed etc. later?
One thing that would be helpful is if the PTO where to release the rules/source code used for validating the DOCX files. Then the error messages could point to specific rules/lines of code. This would rapidly speed debugging and also refining of the rules to help the PTO account for as wide a range of practitioner quirkiness as possible.
Even better would be releasing the rules/code in combination with making the docx validation available as a stand-alone web service that practitioners could quickly and easily check their docx files against. Then they could quickly check in-progress files rather than waiting until they are trying to file the application up against a bar date.
Using such a validation tool we practitioners could generate docx templates with predefined styles and text blurbs that we can rely on passing validation as long as we stick with the predefined styles (i.e., reduce the corner cases the validator has to handle). It will also help us more rapidly identify potential bugs in the validation code that we could relay to the USPTO (i.e., crowdsource the debugging).