<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thank you Suzannah for posting. There are at least four bad
things about this aspect of the PC system. </p>
<p>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.</p>
<p>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 <a
href="https://en.wikipedia.org/wiki/Scalability">here</a>.<br>
</p>
<p>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.<br>
</p>
<p>The red screen shots below prove that the USPTO developers failed
at this first-year-of-CS-school task.</p>
<p>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.</p>
<p>A third bad thing about this is the USPTO developers carrying on
their by now well-established tradition (see <a
href="https://patentcenter-tickets.oppedahl.com/#CP34">trouble
ticket CP34</a> 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.</p>
<p>Here is what the error message should actually say:</p>
<blockquote>
<p>Database timeout</p>
<p>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.<br>
</p>
</blockquote>
<p>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 <a
href="https://patentcenter-tickets.oppedahl.com/#CP178">trouble
ticket CP178</a> 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.</p>
<p>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. <br>
</p>
<p>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.</p>
<p>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.</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/7/2025 7:16 AM, Suzannah K. Sundby
via Patentpractice wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM6PR20MB2298BE90CE4C4033F1499EC7CED52@DM6PR20MB2298.namprd20.prod.outlook.com">
<meta name="ProgId" content="Word.Document">
<meta name="Generator" content="Microsoft Word 15">
<meta name="Originator" content="Microsoft Word 15">
<div class="WordSection1">
<p class="MsoNormal"><span>Trying to access <span
class="SpellE">
eCorrespondence</span> and individual cases in <span
class="SpellE">PatentCrapper</span></span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span><img width="285" height="579"
id="Picture_x0020_1"
src="cid:part1.KHykIIae.oauXuHmH@oppedahl.com" class=""></span><span></span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span><a
href="http://www.linkedin.com/in/ssundby/"
moz-do-not-send="true"><span>Suzannah K. Sundby</span></a></span><span>
<b><span>|</span></b> Partner</span></p>
<p class="MsoNormal"><span><a href="http://www.canadylortz.com/"
moz-do-not-send="true"><u><span>canady + lortz</span></u><u><span>
<span>LLP</span></span></u></a></span><span></span></p>
<p class="MsoNormal"><span>1050 30th Street, NW</span></p>
<p class="MsoNormal"><span>Washington, DC 20007</span></p>
<p class="MsoNormal"><span>T: 202.486.8020</span></p>
<p class="MsoNormal"><span>F: 202.540.8020</span></p>
<p class="MsoNormal"><span><a
href="mailto:suzannah@canadylortz.com"
moz-do-not-send="true"><span>suzannah@canadylortz.com</span></a></span><span></span></p>
<div>
<p class="MsoNormal">
<span><a href="http://www.canadylortz.com/"
moz-do-not-send="true"><span>www.canadylortz.com</span></a></span><span></span></p>
</div>
<p class="MsoNormal"><span>Confidentiality Notice:
<span> </span>This message is being sent by or on behalf of
a lawyer.
<span> </span>It is intended exclusively for the individual
or entity to which it is addressed.
<span> </span>This communication may contain information
that is proprietary, privileged or confidential, or
otherwise legally exempt from disclosure.
<span> </span>If you are not the named addressee, you may
not read, print, retain, copy, or disseminate this message
or any part.
<span> </span>If you have received this message in error,
please notify the sender immediately by e-mail and delete
all copies of the message.</span></p>
<p class="MsoNormal"> </p>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
</body>
</html>