As described in this report, a face-to-face meeting took place on October 18, 2023 between representatives of the Patent Center listserv and Commissioner for Patents Vaishali Udupa and her Patent Center staff. At the start of the meeting, Commissioner Udupa started to present an 18-slide deck which we had never seen before. You can see the slide deck here. Slides 3 through 18 have one CP trouble ticket on each slide, meaning that sixteen CP trouble tickets are shown, one per slide. This blog article discusses each of the sixteen trouble tickets in detail.
Commissioner Udupa presented the first five slides (reaching and discussing trouble ticket CP49) and then what happened is that we moved on to other topics. The slides for CP tickets numbered higher than CP49, then, did not get discussed during that face-to-face meeting at the USPTO. During the meeting, we committed to the USPTO that we would be very glad to discuss the remaining thirteen slides in a video conference at any later time that would be convenient for the USPTO people. We invited them to let us know when they would like to discuss the remaining slides. Thirteen days have passed and we have not heard back from the USPTO about resuming the discussion of the 18-slide deck.
This 18-page slide deck is a detailed discussion of sixteen of the Patent Center CP tickets that had been listed in our Offer of Compromise that we had sent to her on September 30 (blog article).
When Commissioner Udupa introduced this slide deck, at first it seemed that maybe she was getting ready to either accept the Offer of Compromise, or to make some sort of counteroffer. It will be recalled that what we had proposed in the Offer of compromise was that the USPTO would agree to several things:
-
- Commit to publish when USPTO believes it has fixed any of the bugs on the Patentcenter bug list, cited by ticket number, including the bugs that we have denoted as “high priority”.
- Agree to eventually commence work on the more than forty feature requests that are outstanding.
- Agree to postpone the USPTO’s shutdown of PAIR and EFS-Web until after the USPTO had fixed the bugs in the Patent Center bug list that we had designated “high priority”.
The point of this Offer of Compromise was that if the USPTO would commit to these three things, then we would give the USPTO a pass on having to fix the rest of the CP tickets (the ones not designated by us as high priority) prior to the shutdown of PAIR and EFS-Web.
What became clear is that the significance of the Offer of Compromise to Commissioner Udupa was not that the USPTO might accept the offer, or make a counteroffer. Instead, it seemed that Commissioner Udupa was only interested in that document to the limited extent that it would somehow count as a sort of party admission by the listserv community that the sixteen designed “high priority” trouble tickets were the only ones that would need to get fixed prior to the shutdown of PAIR and EFS-Web. And the point of Commissioner Udupa’s 18-slide presentation was to try to convince us to agree with her that none of the sixteen trouble tickets really did count as “high priority”. I guess the idea was that she would click through each of the 18 slides one by one, and for each trouble ticket, she would tell us why we were mistaken to think that it was actually a high priority. I guess she figured she would be so persuasive at this that when we reached the last of her slides, we would have been forced to agree with her that there is no reason to postpone the scheduled shutdown of PAIR and EFS-Web on November 8.
What follows is a detailed discussion of all eighteen slides, that is, a detailed discussion of each of the sixteen Patent Center trouble tickets, along with my brief summary of what I guess the USPTO had in mind that they would explain to us about each of the CP tickets, along with my sense of where the CP ticket stands. If and when the USPTO takes us up on our offer of a videoconference to discuss the remaining thirteen slides that were not reached during the October 18 meeting, the points discussed below will be relevant.
The reader may find it helpful to print out the eighteen USPTO slides to keep at hand when following the discussion below.
-
- CP28 – this is a ticket that did get discussed during the October 18 meeting. USPTO’s position is that this is not really a problem, and that even if it were a problem, it would not need fixing by November 8. To the extent that it might need fixing, the fixing would be put off until some time after the shutdown of EFS-Web. They might fix it, but what they have said is that they think this is a feature, not a bug. (This ticket had been discussed back in 2020 in one of the meetings between the listserv and the USPTO developers.)
- CP31 – this is a ticket that did get discussed during the October 18 meeting. (I discuss this Patent Center bug in detail here.) USPTO’s position is that this is not a problem at all, and that even if it were a problem, it would not need fixing by November 8. Any Patent Center user who actually wants the OCN (outgoing correspondence) function to work can get it to work by manually, USPTO explains, changing the default lookback period in Patent Center from 3 days to 7 days. USPTO’s position, I guess, is that eventually all users of Patent Center would learn that the default value of 3 doesn’t actually work and that the user must simply always change the number from 3 to 7 whenever they are using Patent Center. But once you have gotten into the habit of always changing the 3 to the 7 in Patent Center, then this will match the (correct) function of PAIR, and then you will consistently be informed of your outgoing correspondence. So no corrective action is needed, they say.
- CP49 – this is a ticket that did get discussed during the October 18 meeting. The USPTO position is, they have a Patent Center user guide that says this function is missing for this kind of patent application. And so that means it is okay for it to be missing from Patent Center. And anyway, you can still pay the Issue Fee the hard way for this kind of patent application in Patent Center, so this is not a problem that the easy way does not work for this kind of patent application. The USPTO position is, there is no urgency to addressing this prior to November 8. Some time after EFS-Web has been shut down, they will see about making this function work for this kind of patent application.
- CP51 – this and the higher-numbered tickets did not get discussed during the October 18 meeting, because we moved on to other topics after the slide for CP49. The USPTO comment for this bug is that “the user” did not “disclose the Hague stage”. I am not aware of anywhere in any USPTO documentation where “Hague stages” are publicly defined. I guess that “Hague stage” is some internal thing within the USPTO workflow for design patent applications relating to the Hague Agreement. Actually I think it will turn out that the mere fact that the application has had a 35-series application number connected to it is enough for them to figure out what the “Hague stage” is. Anyway, it looks like the USPTO position is that no corrective action is needed on this.
- CP69 – The USPTO comment is “please provide example application number(s) so that we can investigate”. My best guess is that this comment on this slide got written by somebody at the USPTO some weeks ago, before Scott Nielson provided five example application numbers that appear in the CP69 trouble ticket text. If we had reached this slide during the meeting, I suppose we would have invited them to re-read the trouble ticket so that they can see the detailed application number examples provided by Scott.
- CP94 – The USPTO comment is that yes, Patent Center has exactly the bug that is reported at CP94. And the Patent Center information page does list this bug. For now, I guess they have in mind that if you were to find the need to pay the search fee and exam fee, for example by credit card, you would upload Form 2038, exposing all of your credit card information to public view once the design patent issues. It seems the USPTO does have a goal of fixing this bug.
- CP98 – The USPTO position is, they have a Patent Center user guide that says this function is missing for this kind of patent application. And so that means it is okay for it to be missing from Patent Center. And anyway, you can still accomplish the desired function the hard way for this kind of patent application in Patent Center, so this is not a problem that the easy way does not work for this kind of patent application. The USPTO position is, there is no urgency to addressing this prior to November 8. Some time after EFS-Web has been shut down, they will see about making this function work for this kind of patent application.
- CP99 – this trouble ticket is listed as “resolved” in the listserv’s trouble ticket list. So there would not have been any actual need to talk about getting this bug fixed before November 8. Another way to say this is that this “CP99” slide did not need to be in this slide deck. The USPTO comment is that yes they acknowledge that the correct behavior that may be seen in EFS-Web (blocking the second attempt to enter the US national phase) did not get implemented in Patent Center. So yes this was a correct example of the “100%” claim by the USPTO being in error. The USPTO comment is that yes they could “improve the system” (Patent Center) by making it match EFS-Web’s function. My best guess is that this comment on this slide got written by somebody at the USPTO some time before October 11, which is when the USPTO did correct this bug in Patent Center.
- CP101 – The USPTO position is, they have a Patent Center user guide that says this function is missing for this kind of patent application. And so that means it is okay for it to be missing from Patent Center. And anyway, you can still accomplish the desired function the hard way for this kind of patent application in Patent Center, so this is not a problem that the easy way does not work for this kind of patent application. The USPTO position is, there is no urgency to addressing this prior to November 8. Some time after EFS-Web has been shut down, they will see about making this function work for this kind of patent application.
- CP102 – The USPTO position is, they have a Patent Center user guide that says this function is missing for this kind of patent application. And so that means it is okay for it to be missing from Patent Center. And anyway, you can still accomplish the desired function the hard way for this kind of patent application in Patent Center, so this is not a problem that the easy way does not work for this kind of patent application. The USPTO position is, there is no urgency to addressing this prior to November 8. Some time after EFS-Web has been shut down, they will see about making this function work for this kind of patent application.
- CP117 – EFS-Web provides a unique, distinct file name for each ack receipt that you receive when you have e-filed something. This feature of EFS-Web did not get carried forward into Patent Center, so this counts as a correct example of the “100%” claim by the USPTO being in error. The USPTO comment acknowledges that Patent Center has this implementation failure (each ack receipt always gets a file name of N417, just like the previous ack receipt and the one before that). The USPTO response is, if this bothers you, you can always just rename the files later so that they have non-identical file names. What this all misses is that we raised this during one of the meetings in 2020 between the listserv and the USPTO developers, and at that time, one of the developers agreed that they needed to fix this so that each ack receipt would receive its own distinct file name. But it never got fixed.
- CP127 – For certain foreign countries, for certain data entry situations, Patent Center will require the filer to pick a “state” within the “country” that the filer has selected. Depending on the country involved, sometimes Patent Center does not actually provide any “states” in the drop-down menu for that part of the click path, or provides only a sort of unhelpful state like “Tibet”. The ticket mentions China, Oman, and the UK. The USPTO comment acknowledges this problem in the particular case of China. It is not quite clear from the USPTO comment what the USPTO view is about Oman or the UK. Maybe the comment is saying that there never was such a problem for Oman or the UK, or maybe the comment is saying that the problem or Oman and the UK got fixed at some time in the past. Anyway, the USPTO comment acknowledges that this part of Patent Center is broken so far as China is concerned, and says “this will be fixed by the end of October”. Note that this is a CP ticket for which the user did open an EBC trouble ticket. And note that the EBC did not ever get back to the user about this.
- CP151 – This was the problem of the ellipsis that disappeared from the “correspondence” tab on about September 18 and then the USPTO corrected the problem on about October 11, so on the listserv trouble ticket page this CP number has been listed as “resolved” since about October 11. So there would have been no need to discuss this ticket CP151 on October 18, since the ticket has been listed by the listserv as “resolved” since a week earlier. Another way to say this is that this “CP151” slide did not need to be in this slide deck. As of October 11, the USPTO’s Patent Center information page still listed this bug as a bug that had not yet gotten fixed. The slide says this bug got fixed on October 6. What goes unmentioned is that this was a bug that the USPTO created while fixing some other earlier bug.
- CP153 – If a filer were to have a need to file an ST25 sequence listing, and if the filer were to choose Patent Center as the way to try to file it, what would happen next is that Patent Center would display a red error message with the unhelpful text “Required resource was null”.
click to enlarge Normally most users would understand, from the red color of the error message, that it would be futile to proceed, and futile to try to click “submit” in Patent Center. So the user would revert to EFS-Web where the e-filing process continues without any such error message and the user can click “submit” and it works. But the USPTO position is, if only you keep clicking toward “submit”, ignoring the red error message, you will find that you are able to click “submit”. So this isn’t really a bug, USPTO explains, because eventually all Patent Center users will learn that you can ignore the red error message when you encounter it in Patent Center. The USPTO response is a terse “Fixed 10/6/2023”. It is not clear from this USPTO response whether they are saying “we made the incorrect red error message stop happening”. It seems that as recently as October 17, it was still necessary for the Patent Center user to actively disregard the red error message if they wished to click “submit”.
- CP155 – USPTO apparently acknowledges that this trouble ticket does correctly identify an actual bug. Note that this used to work correctly before September 20. In other words, this is a bug that arose for the first time on September 20, presumably as a result of the USPTO fixing some other earlier bug. USPTO response is that they will fix this bug “by the end of October”.
- CP160 – The bug report says that when you do a certain combination of inputs to Patent Center while trying to pay an Issue Fee, what happens next is that Patent Center displays an unhelpful error message “DocCode must be one of the valid codes from reference data”. The USPTO response says that the USPTO thinks they tried the exact same combination of inputs while trying to pay an Issue Fee, and no such error message appeared. “A recording of the user’s experience would be helpful”, says the USPTO. One thing that is very sad about this USPTO response is that the CP ticket recites an actual specific EBC ticket number. Presumably all details of what the user described to the EBC are in that ticket. It is not clear from the USPTO response whether the USPTO personnel went to the trouble of taking a look at the actual EBC ticket. And note that this is an example of an EBC failure to get back to the user who opened the EBC ticket. If it really is true that somehow not enough information had gotten entered into the EBC ticket for the developers to replicate the problem, then what ought to have happened next is an EBC person getting back in touch with the user to ask for more information. But nobody from the EBC (or from any other part of the USPTO) ever did get back in touch with the user to ask for more information.
