Who was a beta-tester of ePave?

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.

Yes of course we at Oppedahl Patent Law Firm LLC were among the beta-testers of USPTO’s ill-fated XML e-filing system.

The impetus of course was Congress passing the law that said that USPTO had to start doing 18-month pubs.  And this was going to cost the USPTO money.  So USPTO figured, the way to fix that problem was to do some cost shifting.  Force the applicant to hand in characters instead of images, so that USPTO could beat up Reed Publishing (the printing contractor) on the price for doing the 18-month pubs.

So USPTO developed ePave as the e-filing engine. 

And developed a plug-in for WordPerfect for authoring XML.

And developed a plug-in for Microsoft Word for authoring XML.

All three were extremely poorly designed, staggering in the paucity of their quality.  None of the three packages was ready even for beta test.  None of the three should ever have been permitted out of alpha test (if USPTO even did alpha testing which I imagine they did not) in the condition that they were in.

Meanwhile EPO and WIPO developed their own XML authoring tools that were less bad.  But unfortunately the USPTO developers went to great lengths to make it difficult to e-file using the not-invented-here authoring tools.  The user had to go to a lot of trouble to fake out ePave so that it would not puke on an XML patent application that had been authored in the EPO or WIPO authoring tool.  If I recall correctly it was necessary to create a ZIP file in one of the bad (USPTO-developed) authoring tools, and then open up the ZIP file, and then use Notepad to perform microsurgery on the contents of some of the files inside the ZIP file, and then zip it up again.  And then IIRC you had to password-protect the ZIP file with some password that only the USPTO knew.

Yeah, the USPTO-developed authoring tools would generate a ZIP file that was password protected with a secret password that only USPTO knew. 

So as I recall what I had to do was use some software from a Russian company that did a brute-force attack on one of the USPTO’s ZIP files.  It took four days as I recall.  And then eventually I came to know USPTO’s password.  Which I then published to the relevant listserv.  And then it became possible to author using the less-bad authoring tools from EPO and WIPO.  And you could then construct a ZIP file that you could then password protect using the not-secret-any-longer USPTO password, and it would fake out ePave so that you could e-file the patent application.

Anyway each of the bodies of software from USPTO was breathtakingly poorly designed.  We at our firm would lose entire weekends trying to somehow get a patent application e-filed in ePave.  The internal cost to our firm in terms of lost professional billings to do an ePave filing averaged I’d guess ten thousand dollars per application filed.

It was easy to see how much beta-test filing activity was going on, because the application numbers assigned in ePave came from a particular block of one thousand serial numbers.  Normal postal service Express Mail filing of physical paper patent applications was maybe half a million patent applications per year back in those days, or maybe two thousand or so cases filed per day.  Meanwhile our firm would e-file a case in ePave and then we would file another case in ePave a week later, and the serial number count might have increased only by one between our two filings.  There was one three-month stretch where you could tell from the serial numbers generated in ePave that our firm had all by itself filed more than ten percent of all of the ePave cases during those three months.

You could also do the math easily enough.  By the time that USPTO scrapped ePave, some number of patent applications had been filed — you could tell from the serial numbers how many that was.  And you could make fairly educated guesses as to how much cash the USPTO had spent making ePave happen.  And you could divide the one number into the other to find out how much money per patent application had been flushed down the toilet with this failed effort.  It was something like two thousand dollars per serial number.

By the way, recall what the reason was for doing ePave.  It was to capture characters instead of images, so that the 18-month pub would not cost so much money to make happen.  The character capture that USPTO hoped to achieve was in two categories — the patent application itself, and the bib data.  By bib data I mean bibliographic data.  Who are the inventors, who is the applicant, what is our priority claim, what is our domestic benefit claim, what is the title. Two categories of information, both to be communicated in character form.

But that never actually came to pass.  It never actually ever happened that any characters that were e-filed in ePave ever reached Reed Publishing for its 18-month-pub activities.  During the limited time that ePave was being beta-tested, the flow path within the USPTO is that every case that some poor hapless law firm lost a weekend to e-file in ePave got printed out on paper at the USPTO and was injected into the legacy workflow along with the cases that were being filed by Express Mail.  I am not making this up.

We could tell this by looking in IFW at our ePave cases.  They would have skewed pages, scuff marks on the pages, and a variety of other scanning artifacts in the IFW pages.  And the 18-month pubs had misspelled words in them that would never have happened if USPTO had actually passed our XML characters to Reed.

When we were doing our ePave beta testing, as you may imagine it became clear with each passing day that the USPTO developers had only ever thought about how to handle 26 letters and nine numerical digits.  It was more and more clear that the developers were absolutely clueless about Greek letters or simple math symbols.  There were many times when we would prepare a case to be e-filed in ePave and some Greek letter would become a black rectangle or, must amusingly, a smiley face.  There was one case I recall where some of our math symbols became the suits in playing cards – spades and clubs and hearts and diamonds. 

At that time the chemistry community was working on a Chemistry Markup Language — a way to use XML to represent chemistry diagrams.  And the mathematics community was working on a Math Markup Language.  This was going to be a way to use XML to represent math formulas.  The USPTO people were very vague about whether they would some day fashion some orifice in ePave that could receive patent applications that had ChemML and MathML stuff inside.  In the near term we were using embedded images in our patent specifications in ePave as our way of providing math formulas and such.

USPTO had made no secret of its goals for adoption of ePave filing.  So many percent of new US patent applications were to be filed through ePave within six months.  Some much higher percentage of new US patent applications were to be filed through ePave after a year had passed.  But even after a year of release and outreach, the penetration rate for ePave had not even reached one percent.  (By the time ePave was shut down, our firm had single-handedly carried out fully six percent of all ePave filings that ever happened.)  Eventually with a whimper, not a bang, ePave was quietly shut down.  And about a year later, USPTO started beta-testing EFS-Web, which completely abandoned any hope of capturing characters from applicants. 

Astonishingly not only did USPTO backtrack on capturing characters for the patent application itself in EFS-Web, but USPTO also punted on capturing characters for the bib data.  To this day in 2020 there are plenty of EFS-Web filings where the bib data does not reach the USPTO as characters but instead reaches the USPTO only as images.  So for example you the filer can go to the trouble of creating a Form AIA/14 (application data sheet), the kind that is over a megabyte in size, the kind with XML bib data inside.  And if you e-file it in your second EFS-Web submission in a particular case instead of in your first EFS-Web submission in a particular case, it will not auto-load.  It will get flattened to an image and USPTO people will hand-key it into Palm.  I am not making this up, in 2020 USPTO flattens the character-rich ADS into images and passes the images into the paper-based workflow.

And in 2020 you can pay an issue fee in the super-clever EFS-Web character-based web-based issue fee payment screen, and guess what, it will all get flattened into images and later the USPTO people will hand-key the stuff like the city where the assignee is located.  One client of our firm, in Radom, Poland has an issued US patent that says the client is in a “Random” place.  This even though we provided characters, darn it. And USPTO flattened the characters from our Form 85B into images and hand-keyed it.

What I find fascinating is that XML patent application filing is not dead even now in 2020.  Right now in 2020 you can, if you wish, make use of a pretty darn good XML authoring tool provided by WIPO to author a patent application in XML, and you can upload it into ePCT for e-filing in the RO/IB, and if you do, they will give you a filing fee reduction of CHF 100 in addition to the other filing fee reductions that you might get for other aspects of e-filing.  And then guess what?  WIPO actually uses the characters to do the 18-month pub.  Yes!  I am not making this up.