How many Patent Center bugs and missing features can one encounter in a single e-filing task?

Today I had to pay an Issue Fee.  Let’s see how many Patent Center bugs and missing features I encountered in a single e-filing session in Patent Center, trying to pay an Issue Fee. Try to guess how many bugs and missing features were encountered.

I start by finding my allowed patent application in my application workbench in Patent Center.

But no.  When I try to find my own allowed patent application in Patent Center, I get the error message shown at right.  This is bug CP174.  (For those keeping score at home, we are up to a count of “1”.)  Eventually I somehow get past this “access error”.

So now I am looking at my patent application in Patent Center.  Wouldn’t it be helpful if there were a link for “e-filing a document in this patent application?”  And indeed the alpha testers of Patent Center asked for such a link in 2018.  Five years later, this feature has not been implemented.  This is Feature Request FR1.  (Now we have a count of “2”.)

Okay, so I get it, the USPTO developers have not implemented Feature Request FR1 which has been outstanding for more than three years.  Not only that, but the USPTO developers have not implemented even a single Feature Request.  Not one.  But I digress.

So the filer has to do the Subsequently Filed Document, also known as a Follow-On Submission, the hard way.  The filer has to look around in the user interface of Patent Center to try to find some sensible phrase to click on.  The normal phases to describe this are, as I just said, “Subsequently Filed Document” and “Follow-On Submission”.  But no.  Back in alpha-test in 2018, the USPTO developers wrongly picked the misleading and inapt phrase “Existing Submissions”.  This is bug  CP34.  (We are up to a count of “3”.)

So the user somehow already figured out that “Existing Submissions” is the place to click for a follow-on submission.   Of course what we are going to want to do is right-click on “Existing Submissions” and open it in a new window, because we will need both the previous window and the new window, so that we can copy and paste the application number from the previous window into the new window.  And then we will want to copy and paste the confirmation number from the previous window into the new window.

Except guess what?   If we right-click on “Existing Submissions” and try to open it in a new window, Patent Center fails.  How can this be?  During the very first alpha-tester meeting with the USPTO developers in 2018, the USPTO developers promised that Patent Center would be RESTful (Wikipedia article).  RESTfulness is the result of following best practices in web interface design.  Among other things, if the designer follows best practices, the user can right-click on any link and can open it in a new window.  But guess what, and I know this will astonish you, it turns out that the USPTO developers have spent the past five years failing to follow best practices for web interface design.  See “restfulness” bugs CP74, CP105, and CP121.  (I’ll count this as one bug, so now we are up to “4”.)

Okay, so we open a new window in our browser, and we hand-key the Patent Center URL again, hoping that the system will count us as a logged-in user and hoping that the system will not force us to log in again.  This time we got lucky — we are logged in already in the new Patent Center window.

Once again we work our way toward … oh yes, the misnamed “Existing Submissions”.  And today’s project is to try to pay an Issue Fee.  So the natural place to go click is Web-Based Issue Fee Transmittal.  So that is where we click.  So now we need to copy and paste the application number from that previous screen into the Web-Based Issue Fee Transmittal screen.  And now we need to copy and paste the confirmation number from that previous screen into the Web-Based Issue Fee Transmittal screen. And we click “submit”.  And what happens is that Patent Center refuses to let us pay the Issue Fee.

What we see is a red error message saying “The application type entered does not allow for use of the Web-Based Issue Fee Transmittal”.  This is bug CP49.  (Now we are up to “5”.)

What we see is that the USPTO developers want to make us do this an even harder way.  In this case, the harder way is:

• • Go back and find the application again in the user’s application workbench.
  • Click around in IFW and find the PDF Notice of Allowance.
  • Download the PDF Notice of Allowance to the user’s hard drive.  (Note that the USPTO provides this file with “PDF” as the last three characters of the file name.  This will be important later.)
  • Open up the Notice of Allowance using a PDF editor, and delete the first two PDF pages.  Now the first page of the PDF is the Form 85B.  Delete all of the PDF pages after the first page.  Now you have a one-page PDF.  Save it.
  • Using a PDF typewriter tool, type in the virgule signature.
  • Using the PDF typewriter tool, type in the “attorney-agent-or-firm” information.
  • Using the PDF typewriter tool, type in the assignee name and city and country.
  • Optionally, using the PDF typewriter tool, check a box to indicate the entity type (for example “corporation”).  It turns out the USPTO never pays any attention to whether you do this.
  • Save the PDF file.

Now you return to the new Patent Center screen where you tried (unsuccessfully) to use the web-based Form 95B Issue Fee transmittal.  Click once again on the (incorrectly titled) “Existing Submissions” link, and then click on Upload Documents / Pay Fees.   Once again we need to copy and paste the application number from that previous screen into the Upload Documents / Pay Fees screen.  And now we need to copy and paste the confirmation number from that previous screen into the Upload Documents / Pay Fees screen. And we click “submit”.

And now we are scolded.  The Patent Center developers apparently had the idea that some kind of warning is called for in the special case where a would-be Hague Agreement filer chooses to file a new Hague application at the USPTO as an office of indirect filing.  (The best practice of course is to file one’s new Hague application at the IB as an office of direct filing, assuming that one has a suitable Foreign Filing License.)  You can see the warning, which is very big in screen size, and has a very big word count, at right.

But the developers failed to consider the case of a 35-series patent application.  The developers failed to consider that what sometimes happens is that an applicant files a Hague Agreement application somewhere outside of the US and designates the US.

When this happens, the IB transmits the Hague Agreement application to the USPTO and the USPTO gives the application a 35-series application number.  And the important thing here is that if one were to try to file a follow-on submission in that 35-series application, the very big warning would competely wrong and is wholly inappropriate.  But the USPTO developers nonetheless pop this big warning onto the screen, and the only way to proceed is by working up the resolve to ignore the warning, and to click on the “Continue submission” button.  This is bug CP51.  (Now we are up to “6”.)

Recall that we mentioned that the USPTO developers provide the Notice of Allowance as a file ending in the capital letters “PDF”.  You can see that in the screen shot at right.  (Please ignore the parenthesis in the screen shot.)  So now we upload the PDF Form 85B to Patent Center.

And Patent Center pukes on the USPTO’s own PDF Form 85B.  See screen shot at right.  (Again please ignore the parenthesis in the screen shot.)  Yes, it turns out the USPTO developers don’t play by their own rules (blog article).  The USPTO developers fail to comply with their own file naming conventions.  This is bug CP189. (Now we are up to a count of “7”.)

Okay, so now what the user is forced to do is go find the PDF Form 85B on the user’s hard drive, and rename the file so that instead of the uppercase “PDF” that the USPTO provided, it is lowercase “pdf”.  But no, it is not possible to do this because the PDF file is still open in the PDF editor software.  So now we close the PDF file in the PDF editor software.

Now the file does upload without puking.

Okay.  Now we have an uploaded PDF file (or “pdf” file if you want to call it that).  And it does not have a document description, but maybe the user does not notice this, and maybe the user continues through the fee payment screen.  And then through the additional fee payment screen.  And now the user clicks “submit”.

And Patent Center pukes on the attempted “submit”.  The user’s mistake was to fail to provide a document description on the “upload” page.  But the correct time and place for Patent Center to have warned the user about this problem (which makes it impossible to pay the Issue Fee), would of course have been on the “upload” page.  It is very poor user interface design to keep mum about the error, and not mention it when the user clicks through to the first fee payment screen, and not mention it when the user clicks through to the second fee payment screen, and not mention it when the user clicks through to the “submit” screen.  This is bug CP28.  (Now we are up to “8”.)

Okay so now the user does a “go back” and a “go back” and a “go back”.  And now the user is once again located at the “uploads” page.  And there is the PDF Form 85B, and it does not have a document description.

What the Patent Center developers touted as a big improvement over EFS-Web is that the user can type in a few characters that are evocative of the document description, and Patent Center will offer up one or more proposed document descriptions as a sort of “auto-complete”.  But that feature of Patent Center is broken on this page for uploading a PDF file for a 35-series application.  See the screen shot at right, where the user typed in “issue” and what should have happened next is that Patent Center ought to have offered up a document description along the lines of “Issue Fee Payment (PTO-85B)”.  But what we actually see is a search fail.  This is bug CP50.  (Now we are up to “9”.)

The user can then go on a treasure hunt, asking for a drop-down menu of an alphabetical list of every possible document description.  And eventually, as shown at right, down at the letter “i” the user wins the treasure hunt, selecting “Issue Fee Payment (PTO-85B)”.  The user then clicks forward again, past the first fee payment screen and the second fee payment screen, reaching the “submit” page.

At this point the prudent user will do a “preview” of the uploaded PDF document.  What pops up is a vexing “responsiveness fail” (Wikipedia article).  Yes, starting about ten years ago, the web interface design community realized that the right thing to do is to design web pages so that they view properly even across the normal range of screen sizes and aspect ratios.   Indeed nowadays in 2023, most authoring tools and platforms are automatically “responsive”.  The programmer who uses one of the well-designed authoring tools and platforms will not even need to think about “responsiveness” because the programmer did the right thing by selecting an authoring tool and platform that is automatically “responsive”.

But of course, predictably, the USPTO developers did not choose authoring tools and platforms that are automatically “responsive”.  Under such circumstances, it is encumbent upon the programmer to actively test each user interface design to make sure that it renders well on a normal range of screen sizes and aspect ratios.   Predictably, this did not happen with Patent Center.  There are half a dozen examples of “responsiveness fails” in Patent Center, for example CP109 and CP134.  The way that this usually happens is that the developers each have two (or even three) display monitors on their desks, and each display monitor is only slightly smaller than a highway billboard.  The developer never gives a moment’s thought to the possibility that a paying customer of the USPTO might have a more normal-sized computer display.

The USPTO developers failed this time too.  See the screen shot at right, which shows the PDF document preview.  Once the user is done reviewing the “preview” of the PDF file, the user cannot proceed with the e-filing project until the user somehow closes this pop-up window.  To close this pop-up window, the user looks for the big red “close” button.  But, and I am not making this up, the big red “close” button is off the bottom of the screen.    This is CP190.  (Now we are up to “10”.)

Eventually the user somehow manages to close the pop-up window, and clicks “submit”.  The ack receipt appears, and of course the trap for the unwary is that the user has not yet actually paid the Issue Fee.  On this page, we see a link along the lines of “file another patent application”.  This is CP34.  There are two things wrong with this button text.  First, we did not just “file a patent application”.  We filed a Form 85B.  This is not the same thing has having “filed a patent application”  A second thing wrong with this button text is that there are a wide variety of things that are not the same thing as “filing a patent application” that we might want to do next, and they are all hidden behind this button that says (incorrectly) that the place that it goes is (only) “filing a patent application”.  (Now we are up to “11”.)

But assuming the user does click to pay the Issue Fee, then what one expects to see next is … another ack receipt.  But no, that is not what happens.  What one sees next is a mostly blank screen that remains unchanged for ten minutes.  Conspicuously absent is any “throbber” (blog article) or what would have been called an “hourglass” in times past.  This is bug CP179.  (Now we are up to “12”.)

But fear not!  In EFS-Web, any time that something froze or crashed, the user could go to “last 40 ack receipts” and there would be the most recent ack receipt, showing (for example) that the user had indeed successfully paid the Issue Fee.

This EFS-Web feature is, unfortunately, missing and defective in Patent Center.  It was missing in 2018 when the alpha testers pointed this out to the USPTO developers, and it is stil mostly missing even now.   The user clicks around and eventually stumbles upon “receipt history” which is hidden away behind “Workbench”.  One looks at the most recent ack receipt, and it is indeed in the patent application for which the user was trying to pay the Issue Fee.  Except it is not the most recent ack receipt.  It is the second most recent ack receipt.   This ack receipt tells us only what we already knew, which is that we had successfully e-filed a document (the PDF Form 85B).  But the “receipt history” fails to provide the most recent ack receipt, namely the receipt that shows that we actully did pay the Issue Fee.  This is CP38.  (Now we are up to “13”.)

In EFS-Web, one’s colleagues could see the ack receipts.  This permitted, say, a docket desk to learn of some filing that a practitioner carried out in the middle of the night, and, perhaps, neglected to tell the docket desk about.  But in Patent Center, an ack receipt is visible only to the particular person who did the e-filing.  So this aspect of the “last 40 ack receipts” function did not get accurately carried forward into Patent Center.  This is also CP38.  The USPTO says that this is not a bug at all, but is instead “working as intended”.  It seems the three-word phrase “working as intended” means “we developers know better than you do what you want” and “we wrote stupid code but the code does what it should do given the stupid way we wrote it”.

Let’s assume that eventually we manage to lay our hands on the elusive “second ack receipt”.  What should happen is that we ought to be able to save that ack receipt, all by itself, and thereby prove that we did two things (1) upload documents and (2) pay fees.  But no, the USPTO fails to provide any indication in that last ack receipt of any document uploads.  It only talks about fees.  (In EFS-Web, the user could save that last ack receipt and it would serve as proof of both accomplishments.)  This is CP118.  The developers have told us they will improve the “second ack receipt” so that it includes the document uploads that were in the previous ack receipt.  But this has not yet been done.  (Now we are up to “14”.)

Let’s return briefly to a discussion of the screen that appears after a person has successfully e-filed something.  As a general rule, when the user is on this screen, absolutely always the next thing the user will want is to see exactly what the USPTO received.  In other words, the user wants to go to the application in one’s workbench and view the “documents”.    Why is there no link, on this web page that says the user has successfully e-filed something, to the application in one’s workbench so that the user can view the “documents”?

The alpha testers of Patent Center, in 2018, asked for this link.  Five years later, the developers have not provided this link.  This is FR2, outstanding for more than three years now.  And no, the developers have not implemented even one of the fifty-four outstanding Patent Center feature requests.  (Now we are up to “15”.)

In our continued search for the elusive “second ack receipt”, we eventually find our way back to the patent application in our workbench, and we click on “documents”.   We see, with some sense of relief, that there are two ack receipts.  Hopefully one of them does evidence the successful payment of the Issue Fee.  So we check the check box for each of the three documents that we just e-filed.

In EFS-Web, it was clear what to do next after checking the three boxes.  The user would click on a “download” button.  But in Patent Center, the “download” button is an Easter Egg!  Yes, you have to guess where to click.  It is not even that you could find the Easter Egg by hovering the cursor in the right place.  You have to click somewhere.  And, as shown in the screen shot, the hiding place is the “3 selected” box.  This is CP180.  (Now we are up to “16”.)

By the way, the issue fee payment process just narrated actually took over half an hour to complete.  Yes, sixteen bugs and missing feature requests, all encountered during a seemingly simple task (paying an Issue Fee) that ought to have taken no more than five or ten minutes at worst.