<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>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.</p>
<p>Take a look at <a moz-do-not-send="true"
href="https://tsdr.uspto.gov/#caseNumber=99407734&caseType=SERIAL_NO&searchType=statusSearch">this
TSDR page.</a> What does it show as the mark? You can see it
on that page. That page says the mark is "FX BRALN AR".</p>
<p>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.</p>
<p>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". </p>
<p>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".</p>
<p>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:</p>
<blockquote>
<p>the characters "FX brAIn AR" </p>
</blockquote>
<p>Now at this point what the forensic analysis requires is some
absolutely authoritative way to prove that the practitioner either
copied and pasted an "<font face="monospace">I</font>" 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 "<font
face="monospace">I</font>" into an "L" <i><b>in a way that would
not be apparent to the practitioner at any point in the
e-filing process</b></i> but that would reveal itself only <i><b>after
the application had been e-filed, when it is too late to fix.</b></i></p>
<p>Which of these two things is true? Did the practitioner screw
up? Or did the developers screw up?</p>
<p>My favorite forensic-analysis tool for uncovering mistakes about
character coding is <a moz-do-not-send="true"
href="https://www.babelstone.co.uk/Unicode/whatisit.html">this
Unicode decoder</a>. 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.</p>
<p>You open up <a
href="https://www.babelstone.co.uk/Unicode/whatisit.html">this
Unicode decoder</a> and you get ready to use it. But next, open
a new browser window and click on <a
href="https://tsdr.uspto.gov/#caseNumber=99407734&caseType=SERIAL_NO&searchType=statusSearch">the
TSDR page</a>, 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:</p>
<p><img src="cid:part1.gKtR3XYZ.QpEhcWC6@oppedahl.com" alt=""
width="720" height="335"></p>
<p>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 "<font
face="Times New Roman, Times, serif">LATIN CAPITAL LETTER I</font>".</p>
<p>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 "<font face="monospace">I</font>"
to an "L" <i><b>during the e-filing process</b></i> and yet <i><b>concealed
it from the practitioner</b></i> and then waited until <i><b>after
the practitioner clicked "submit"</b></i> to reveal the
change?</p>
<p>How could this possibly have happened in the software?</p>
<p>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.</p>
<p>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:</p>
<p><img src="cid:part2.RnKFmQhY.x2w34en1@oppedahl.com" alt=""></p>
<p>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 "<font
face="monospace">I</font>" or is a lower-case sans-serif "L" or
maybe is none of those things. It is just a bunch of pixels.</p>
<p>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:</p>
<blockquote>
<p><span
style="color: rgb(27, 27, 27); font-family: sans-serif; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">FX
brAln AR</span></p>
</blockquote>
<p><span
style="color: rgb(27, 27, 27); font-family: sans-serif; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">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".</span></p>
<p><span
style="color: rgb(27, 27, 27); font-family: sans-serif; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">Here
is the evil, I think. I think the TC developers' OCR engine <i>wrongly
identified that character as a lower-case L.</i></span></p>
<p>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 "<span
style="color: rgb(27, 27, 27); font-family: sans-serif; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">FX
brAln AR</span>". Now you can copy and paste the "literal
element" into the Unicode decoder and here is what you get:</p>
<p><img src="cid:part3.fk105Pf8.rfXEzD1f@oppedahl.com" alt=""></p>
<p><span
style="color: rgb(27, 27, 27); font-family: sans-serif; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">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.</span></p>
<p>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 <font face="Times New Roman, Times, serif">I</font>.
Second, the dramatic reveal (converting the entirety of the
literal element into ALL UPPERCASE LETTERS) happened only <i><b>after</b></i>
the practitioner clicked "submit".</p>
<p>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.</p>
<p>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.</p>
<p>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 <i><b>at the earliest possible point</b></i> in the
Trademark Center click path.</p>
<p>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.</p>
<p>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:</p>
<blockquote>
<p>FX BRALN AR</p>
</blockquote>
<p>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.</p>
<p>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. </p>
<p>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.</p>
<p>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.</p>
<p>Again to anyone at the USPTO who might listen, the hundreds of
members of the e-trademarks listserv stand ready to help.</p>
<p>Carl</p>
</body>
</html>