[E-trademarks] Yet another really bad defect in Trademark Center

Tue Sep 23 17:07:11 UTC 2025

If the USPTO had done even half-decent beta testing of TC, then the 
really bad defect that I am about to describe would never have gotten 
into the production version of TC.

To say this differently, the fact that the defect I am about to describe 
is right now present in the production version of TC absolutely proves 
that the so-called "beta testing" of TC was no such thing.  It was, at 
best, sort of going through the motions, pretending to do genuine beta 
testing but utterly failing to do proper beta testing.

Take a look at this TSDR page. 
<https://tsdr.uspto.gov/#caseNumber=99407734&caseType=SERIAL_NO&searchType=statusSearch>  
What does it show as the mark?  You can see it on that page.  That page 
says the mark is "FX BRALN AR".

Now the first reaction that many might have is that this application 
must be one of those Chinese applications that strings together six or 
seven consonants, tosses in one random vowel, and finishes with a mark 
that no human mouth could ever pronounce. But no, this application 
cannot be one of those, because it has spaces in it.  The randomly 
generated Chinese filings never have spaces in them.

Okay so what explains this weird mark?  The next step for the forensic 
analysis of the defective Trademark Center is to click in TSDR on 
"documents" and click on "Application".

At this point, we need to start very carefully distinguishing between 
"actual characters that the practitioner entered into TC" and "stuff 
that got generated by defective software that is not the fault of the 
customer".

First let's focus on "actual characters that the practitioner entered 
into TC".  And the place to find this is by scrolling down to "mark 
description".   This is exactly what the practitioner copied and pasted 
into Trademark Center during the e-filing process.  The practitioner 
pasted this:

    the characters "FX brAIn AR"

Now at this point what the forensic analysis requires is some absolutely 
authoritative way to prove that the practitioner either copied and 
pasted an "I" or an "L" (or maybe a vertical bar!) into that place 
between the "A" and the "n".  Yes, one possibility is that this screwup 
is the practitioner's fault, because the practitioner copied and pasted 
an "L".  The other possibility is that the USPTO developers of Trademark 
Center screwed up in the coding of the software (and failed to do proper 
beta testing), and somehow placed into production some software that 
would methodically change an "I" into an "L" /*in a way that would not 
be apparent to the practitioner at any point in the e-filing 
process*/ but that would reveal itself only /*after the application had 
been e-filed, when it is too late to fix.*/

Which of these two things is true?  Did the practitioner screw up?  Or 
did the developers screw up?

My favorite forensic-analysis tool for uncovering mistakes about 
character coding is this Unicode decoder 
<https://www.babelstone.co.uk/Unicode/whatisit.html>.  There are many 
tools that provide this kind of coding analysis but this one is my 
personal favorite.  So you can follow along with this if you like.  It 
is actually a very helpful learning opportunity for practitioners to 
learn about Unicode.  (And it would be a very helpful learning 
opportunity for the USPTO developers who gave us Trademark Center.)  So 
please, settle down with a source of caffeine and click along with me.

You open up this Unicode decoder 
<https://www.babelstone.co.uk/Unicode/whatisit.html> and you get ready 
to use it.  But next, open a new browser window and click on the TSDR 
page 
<https://tsdr.uspto.gov/#caseNumber=99407734&caseType=SERIAL_NO&searchType=statusSearch>, 
click on "documents", click on "application", scroll down to the "mark 
description".  Copy the mark description which is "FX brAIn AR" and 
paste it into the Unicode decoder. Click on "identify".  What you will 
see on your own computer screen is this:

This proves that the party who screwed up was not the practitioner.  
This proves that what the practitioner copied and pasted into Trademark 
Center was a "LATIN CAPITAL LETTER I".

So we now scratch our heads and we try to work out what exactly are the 
very poor software decisions inside Trademark Center that somehow led to 
this situation that what auto-loaded into TSDR in the most prominent 
field was "FX BRALN AR".  What were the software decisions somehow 
changed the "I" to an "L" /*during the e-filing process*/ and yet 
/*concealed it from the practitioner*/ and then waited until /*after the 
practitioner clicked "submit"*/ to reveal the change?

How could this possibly have happened in the software?

I have a theory as to the mistakes made by the developers in this 
specific case.  I cannot be sure about it because of course the 
developers don't do their work in an open-source way (open to the user 
community).  But this is my theory.

Recall that during the filing process, TC asks whether you want a 
standard character mark or a stylized mark and so on.  If you pick 
anything other than "standard character" then TC requires that you 
upload a drawing.  In this case the practitioner uploaded this drawing:

As we know, the drawing is a raster drawing (not vector-drawn). It is 
just individual pixels that are either black or white.  When you are in 
raster world, nothing about the computer file takes a position one way 
or the other as to whether the thing between the "A" and the "n" is a 
vertical bar or an uppercase sans-serif "I" or is a lower-case 
sans-serif "L" or maybe is none of those things.  It is just a bunch of 
pixels.

Here is where the TC developers thought they were smarter than everybody 
else.  At this stage, the TC developers made use of some OCR engine and 
ran it on the drawing, and then the software popped up a message on the 
screen that asked "we think the literal element of your mark is this, 
did we get it right?"  And the "literal element" characters on the 
screen were:

    FX brAln AR

At this point, the practitioner looked at the screen, and it didn't look 
wrong.  So the practitioner clicked to say "yes that looks like our 
literal element".

Here is the evil, I think.  I think the TC developers' OCR engine 
/wrongly identified that character as a lower-case L./

Our forensic analysis proves this.  Go to the "application" file in TSDR 
and scroll back up a line or two to "literal element" and you will see 
"FX brAln AR".  Now you can copy and paste the "literal element" into 
the Unicode decoder and here is what you get:

Yes, the "literal element" OCR engine employed by the TC developers 
wrongly identified the thing between the A and n as a SMALL LETTER L.

During the e-filing process, this mistake would never have revealed 
itself to the practitioner for at least two reasons. First, the 
developers chose to use a sans-serif font that makes it impossible to 
visually distinguish a lower-case L from an uppercase I. Second, the 
dramatic reveal (converting the entirety of the literal element into ALL 
UPPERCASE LETTERS) happened only /*after*/ the practitioner clicked 
"submit".

As I say, I cannot be absolutely sure that what I just described in the 
previous ten paragraphs is exactly what they did wrong.  It is only my 
educated guess from the forensic analysis and from my decades of 
experience in the world of computer programming.

But if there had been anything close to competent beta testing done, 
this would have revealed itself long before the end of the beta testing 
process.

The biggest design blunder was to postpone the conversion to ALL UPPER 
CASE of the "literal element" characters until it was too late for the 
practitioner to see what the OCR software had gotten wrong.  If you, as 
a developer, are aware that what will get loaded into the most prominent 
place in TSDR is the ALL UPPER CASE version of the "literal element" 
characters, then you need to fess up to this /*at the earliest possible 
point*/ in the Trademark Center click path.

A lesser but still significant blunder was to fail to use a serif font 
at this most crucial stage of the click path.  The serif font might well 
have tipped off the practitioner of the OCR fail.

At the point in the click path where the developers say "we think the 
literal element of your mark is this, did we get it right?", what 
absolutely should have appeared on the screen is the text that later got 
slotted into that most prominent place in TSDR. What should have 
appeared on the TC screen was:

    FX BRALN AR

Again, in case I perhaps failed to mention it, had the purported "beta 
testing" of Trademark Center actually taken place, this user interface 
mistake would have gotten caught and corrected long before the release 
of Trademark Center into production service.

Given that the USPTO's CX team for Trademark Center is now decimated, 
with a staff size of "1", and given that the purported "beta testing" of 
TC allowed mistakes like this to reach production service, I am aghast 
that the Trademark Office would now plow ahead with continued cutoff of 
other TEAS functions. According to the earlier-quoted email, the next 
two TEAS functions to be cut off would apparently be the Voluntary 
Amendment ("VA") form and the and Change Address or Representation 
("CAR") form.

There should be a hard stop on any further cutoff of TEAS functions (by 
which I mean migrating them to TC) until such time as the Trademark 
Office works out a proper way to beta-test its work with the expansion 
(mission creep) of TC.

See the three recent postings about experiences that three people had as 
they participated in the purported "beta testing" of Trademark Center, 
to get a sense of how badly the purported "beta testing" fell when 
compared with what proper beta testing would have been like.  USPTO 
interviewers, for example, who made clear from their questions that they 
had not even a clue about what it means to prepare or file a trademark 
application.

Again to anyone at the USPTO who might listen, the hundreds of members 
of the e-trademarks listserv stand ready to help.

Carl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oppedahl-lists.com/pipermail/e-trademarks_oppedahl-lists.com/attachments/20250923/caff8450/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6dKk0Gx95yWsbPvz.png
Type: image/png
Size: 60259 bytes
Desc: not available
URL: <http://oppedahl-lists.com/pipermail/e-trademarks_oppedahl-lists.com/attachments/20250923/caff8450/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: m9udUvI0dX7G10LX.png
Type: image/png
Size: 1897 bytes
Desc: not available
URL: <http://oppedahl-lists.com/pipermail/e-trademarks_oppedahl-lists.com/attachments/20250923/caff8450/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C6L8vOxKBGZ26a5B.png
Type: image/png
Size: 30124 bytes
Desc: not available
URL: <http://oppedahl-lists.com/pipermail/e-trademarks_oppedahl-lists.com/attachments/20250923/caff8450/attachment-0002.png>