A boundary-value programming mistake in Patentcenter

One of the easiest things to get wrong, for some programmers in some programming languages, are “boundary values”.  Here we see a classic example of a boundary-value mistake by the developers of Patentcenter. 

On March 10, 2023 the USPTO announced (archived here) that seven days later (today, as it turns out) the USPTO would roll out “an updated interface [for Patentcenter] with an improved look and feel to enhance and modernize the customer experience.”  I will mention that I am not aware of any customer that felt that there was a need for “an improved look and feel” in Patentcenter, nor any need for “modernization” in a system that was released for general use only a year ago.  I will also mention that by now the hundreds of Patentcenter users who make up the Patentcenter listserv have accumulated a list of over one hundred trouble tickets detailing bugs and programming mistakes in Patentcenter.  And they have identified over forty missing  features in Patentcenter.  But not once in over two years has any need for “an improved look and feel” or any need for “modernization” come up in the discussions in the listserv.

Today is the day of the rollout of this “updated interface”.  For me the most noticeable differences in this updated interface are (a) the introduction of unhelpful and content-free “icons” taking up pixel space in already-too-spread-out menus and tab arrays, and (b) an embarrassing coding mistake with a boundary value.  (I address the unhelpful and content-free “icons” in a separate blog article.)

Which brings us back to “boundary values”.  When I logged in just now at Patentcenter, I found myself on its home page, and I looked for “workbench” which is, by the way, the true “home” for any day-to-day user of Patentcenter.  In the previous version of Patentcenter, the link for “workbench” was “above the fold” meaning that you could see it right away without the need to scroll down.  Not in the “updated interface” that got rolled out today!  No, in today’s “modernized” user interface with its “improved look and feel”, you can no longer immediately see the place to click on “workbench” but must instead scroll down by an entire screen-height to find the place to click for “workbench”.    (It is a disappointment that with today’s revamp of the user interface, the true “home” for any day-to-day user of Patentcenter is no longer to be seen on the nominal “home” page of Patentcenter.)

Having reached the “workbench” screen, I clicked on “correspondence”.  This brought me to the “correspondence” page which by default lists my “outgoing correspondence” that was “imaged” by USPTO personnel in the last three days.  (This choice of “3” is a design mistake by the USPTO which was reported by the Patentcenter listserv to the USPTO on June 23, 2020 and has not yet been corrected.)

When you get to a “list page” like this, you see that the designer tries to provide for the possibility that the list may have so many list items that the items cannot all be listed on a single “page”.  If so, then the list items are spread out over two or more “pages”.  The user might be given the ability to pick the number of items per “page” (here, the default is 100 items per “page”).  The user is given an indication of which “page” is presently being shown, and is given click buttons to move up and down among the “pages”.

Given the default of 100 items per “page”, then we consider what it would take for you to encounter the need to click down to “page 2”.  The answer is, this clicking to “page 2” would only arise if the number of correspondence items were to happen to be more than 100.  (And, given the programming mistake mentioned above, the programming mistake that has gone uncorrected for more than two years now, it is actually pretty rare for most users that they would ever reach an item count of more than 100.)

Today, Patentcenter thinks I have … wait for it … eleven items of outgoing correspondence.  (The true number is 19, as may be seen in Private PAIR, the system that will eventually get shut down when all of its features are supposedly implemented in Patentcenter.  The fact that 11 is smaller than 19 is a consequence of the programming mistake just mentioned.)

Now regardless of whether Patentcenter reaches a goal of listing the true number of items of outgoing correspondence (19) or the mere 11 items that Patentcenter is displaying today for me due to the programming mistake, either way, the number of “pages” of items should be “one”.  This page count of “one” is a consequence of 100 being a bigger number than either 11 or 19.  But what we actually see in today’s “enhanced” and “modernized” updated interface is (I am not making this up) page “2 of 1”.  You can see it here:

Which brings us back to the category of computer programming mistake called the “boundary value” category of mistake.  For this outgoing correspondence listing table, if there were, say, 1145 items of correspondence, we might have, say, a dozen “pages”, each with 100 or so of the items of outgoing correspondence.  The programmer will not make mistakes showing pages like page 3 or page 5 or page 7 because they fall comfortably in the middle of the page count.  But in some programming languages it is very easy for the sloppy programmer to get it wrong for boundary values such as “the last page” or “the first page”.  The “last page” can come to ruin because the programmer failed to consider “what happens when the item count on a particular page is smaller than the boundary number 100?”  The “first page” can come to ruin because “first” is itself a boundary value.  In the programming language that the programmer selected, perhaps it is “built into” the basic structure of the programming language that an “array” always starts with a position number of “zero”, rather than the starting number of “one” that a schoolchild would expect from one’s first experience with counting things (which starts with the number “one” and works its way up).

Here, we see marked in green the place on the screen where the boundary value mistake is most visible.  Because the item count is less than 100, the page count is (or should be) “one”.  But instead, what appears on the screen is that we are seeing is “page 2 of 1”.

I can’t see the actual programming code for this page, of course — all that I can see is the human-rendered result.  But I can guess that any of two particular boundary-value mistakes may have been made here:

• • The programmer may have failed to handle correctly the condition of “what if the page count is the smallest possible page count”?  In the programming language involved, the smallest number for an array position might be zero, and yet the programmer may have followed the schoolchild habit of assuming the smallest number that you can have when you are counting things is “one”.  And this mistake of being “off by one” in the count somehow led to the rendered text that I am seeing namely “page 2 of 1”.
  • The programmer may have coded this section of software to handle properly only the case where there are multiple pages of correspondence items.  The programmer may have failed to consider that sometimes the number of pages of correspondence items is only “one”.  To say this another way, the programmer may have failed to consider that sometimes “the last page” and “the first page” might happen to turn out to be the same page.

The close observer will note that there is a small “downarrow” next to “page 2 of 1” which suggests that there may be a drop-down list Easter Egg available if you click on “page 2 of 1”.  And indeed there is an Easter Egg here in the form of a pop-up window:

The hapless user of today’s “modernized look and feel” interface who has clicked on “page 2 of 1” is, in the pop-up window, given an opportunity to “please enter a number between 1-1”.  I will mention that each of the three hyperlinks in this pop-up window is actually broken.  The invitation to click to “jump to page 2” does not work, and if you click to “go” it does not actually “go” anywhere.

In any well-run programming shop, there is some arrangement where a second team member, usually more senior or more experienced with the programming language involved, will have the responsibility of reviewing the code that just gotten finished by the first team member.  This review includes “checking the boundary values” for the just-finished code.  This second team member reviews the code to consider things like “what happens when the number of items is bigger than some threshold like the number 100 that we see here?” or “what happens when the number of items is zero?” or “what do I get if I click on this link over and over again until there are no more items to display?”  It stares us in the face that for today’s “modernized look and feel” body of code, no boundary-value checking ever took place.

In many well-run programming shops, an effort will be made to beta-test the body of code that is on the verge of being placed into service.  The beta testing must, by definition, be carried out by human beings who are (a) actual users and (b) not the same as the programmers who did the coding.  I’d guess that no such beta testing happened here.  There are two reasons why I’d guess no beta testing actually took place for this “modernized look and feel” body of new code:

• • First, even the most limited amount of beta testing would have flagged this particular mistake, which is in the main page that most users would actually consider to be their “home” page, and which they would visit more often than any other page.
  • Second, the natural go-to place for the USPTO developers of Patentcenter to find beta testers would be … wait for it … the Patentcenter listserv.  But the USPTO developers did not get in touch with the Patentcenter listserv to see whether maybe some of its hundreds of members might be willing to beta-test this “modernized look and feel” body of code.

What I find most regrettable about this resource allocation by the decisionmakers at the USPTO was the decision to spend this money and programmer time on a solution for a non-existent problem.  There was no need for a “modernized look and feel” of a system that was released to open production service only a year ago.  There was, however, a need to fix the more than 100 bugs that are on the Patentcenter trouble ticket list.  And there was a need to implement the more than forty unimplemented Patentcenter features that are on the Patentcenter missing features list.