[Patentpractice] failure to "scale" (was PatentCrapper today...)

Fri Mar 7 16:54:56 UTC 2025

Thank you Suzannah for posting.  There are at least four bad things 
about this aspect of the PC system.

First, the USPTO developers very predictably failed to design the system 
so that it would "scale".  At the outset of system design, the 
developers unfortunately made initial design decisions that were just 
barely good enough to support the small number of alpha testers (of 
which I was one and other listserv members were also).   Later when the 
system got opened to beta testing, these "search limit reached" notices 
started popping up every now and then.  And then of course when PAIR got 
shut down, this forced all USPTO customers to shift their work to PC, 
and the "search limit reached" notices became commonplace.

In the first year of a computer science curriculum, one of the 
first-year courses always addresses the need for a software developer to 
plan ahead about this.  If the eventual bandwidth required to handle a 
production environment is at some (in this case very predictable) level, 
then the design decisions back in alpha test need to be made so that the 
system can eventually "scale" to that level to serve production needs.  
This need for a designer to pay attention to scalability has its own 
Wikipedia article that you can see here 
<https://en.wikipedia.org/wiki/Scalability>.

It would have been prudent for the USPTO developers (back in 2018) to 
carry out simple measurements on PAIR to see how many queries per second 
got made by paying customers, how much data had to be served up per 
query, and how big the peak loads would get. I'd guess the USPTO 
developers failed to do that.  And with PAIR having been shut down a 
year ago now, there is now no opportunity to carry out such measurements 
on PAIR.

The red screen shots below prove that the USPTO developers failed at 
this first-year-of-CS-school task.

A second bad thing about this is the developers having failed to take 
proper account of the different service standards applicable to paying 
customers on the one hand, and to non-paying general members of the 
public.  The former are easy to spot because they have logged in with a 
user ID and password and two-factor authentication, linked to customer 
numbers with dozens or (in Suzannah's case) thousands of fee-paying 
patent applications.  To the extent that (due to poor system design) 
there is some need to treat one user differently from another, the last 
thing that should happen is that someone who (like Suzannah) has paid 
half a million dollars in government fees in recent months should have 
her service quality pushed down in favor of some other user.

A third bad thing about this is the USPTO developers carrying on their 
by now well-established tradition (see trouble ticket CP34 
<https://patentcenter-tickets.oppedahl.com/#CP34> reported in the year 
2020) of picking the wrong words for important parts of the PC user 
interface.  Here, the developers characterize the bad thing that 
happened as a "Search Limit" that was "reached".  But Suzannah was not 
"searching" at all.  She was looking at the documents page for one of 
her own patent applications (in which she had paid thousands of dollars' 
worth of government fees).  And she was clicking to view or download a 
document from that patent application.  She was not "searching" at all.  
There should be no "limit" on the activity of a paying customer clicking 
on a document in the customer's own application file.

Here is what the error message should actually say:

    Database timeout

    The database is unfortunately unable to keep up with user needs.  We
    apologize for the inconvenience.  We have logged this failure and we
    will try to address it soon.  Unfortunately your only choice is to
    try again.

A fourth bad thing is the failure of the USPTO developers to have 
addressed their failure to "scale".  It has been more than a year now 
that USPTO customers have been reporting these "search limit exceeded" 
failures to the EBC (see trouble ticket CP178 
<https://patentcenter-tickets.oppedahl.com/#CP178> reported in the year 
2023).  And even if not even a single user had reported such a failure, 
a responsible developer would have been logging these failures and would 
have been taking action based upon the logs.  But even now, the 
developers have not fixed this element of bad system design.

The USPTO hasn't shared its system design for PC.  One could imagine 
that maybe the relevant portions of PC are in a cloud such as AWS.  If 
so, then it turns out these things are quite fixable. You go to your 
user interface for your cloud, and you find the "bandwidth" knob, and 
you turn it up from 5 to 8 or whatever. Yes, you will then get charged a 
little more money, but then the cloud will keep up with your actual 
bandwidth needs.  That is one of the good things about hosting a system 
in a cloud, you can turn these knobs up and down as needed and you can 
avoid paying unnecessarily for more of any particular computing resource 
than you actually need.

I suspect the USPTO developers chose to host the relevant portions of PC 
on self-hosted physical servers in some USPTO facility in Virginia at 
some distance from the Alexandria campus. This means that the bad system 
design decisions that date from the days of alpha testing (back in the 
year 2018) are "baked in" to the system, and very hard to change.  Maybe 
this particular recurring system failure could be traced to some single 
point of bad design, like an ethernet link running between two boxes 
that should have been gigabit ethernet but was only implemented as 
100base-T ethernet (ten times slower).  If that had been the mistake, 
then it would be readily fixable by swapping out the slow ethernet ports 
for gigabit ethernet ports, and standing back to see the system work 
much faster than before.

But I suspect that the elements of bad system design, dating from the 
alpha test days, are pervasive rather than single-point.  The dozen or 
so file servers and software servers that make up this portion of PC 
were probably badly chosen across the board. Probably now in 2025 it 
would not even be possible to correct the system design by throwing more 
money at the existing servers; swapping out this server or that server 
with an upgraded server that is (say) 20% faster (and costs twice as 
much money) would not meaningfully reduce the number of (misnamed) 
"search limit reached" error messages.  No, what needed to happen back 
in 2018 was picking some completely different topology for the servers 
and making completely different decisions about how to architect the 
underlying databases.  That didn't happen in 2018 and now the failure to 
scale cannot be fixed now in 2025 just by little tweaks here and there.

On 3/7/2025 7:16 AM, Suzannah K. Sundby via Patentpractice wrote:
>
> Trying to access eCorrespondence and individual cases in PatentCrapper
>
> Suzannah K. Sundby <http://www.linkedin.com/in/ssundby/>*|* Partner
>
> _canady + lortz__LLP_ <http://www.canadylortz.com/>
>
> 1050 30th Street, NW
>
> Washington, DC 20007
>
> T: 202.486.8020
>
> F: 202.540.8020
>
> suzannah at canadylortz.com <mailto:suzannah at canadylortz.com>
>
> www.canadylortz.com <http://www.canadylortz.com/>
>
> Confidentiality Notice: This message is being sent by or on behalf of 
> a lawyer. It is intended exclusively for the individual or entity to 
> which it is addressed. This communication may contain information that 
> is proprietary, privileged or confidential, or otherwise legally 
> exempt from disclosure. If you are not the named addressee, you may 
> not read, print, retain, copy, or disseminate this message or any 
> part. If you have received this message in error, please notify the 
> sender immediately by e-mail and delete all copies of the message.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oppedahl-lists.com/pipermail/patentpractice_oppedahl-lists.com/attachments/20250307/f501b84c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 39487 bytes
Desc: not available
URL: <http://oppedahl-lists.com/pipermail/patentpractice_oppedahl-lists.com/attachments/20250307/f501b84c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://oppedahl-lists.com/pipermail/patentpractice_oppedahl-lists.com/attachments/20250307/f501b84c/attachment.p7s>