<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Wow this is fascinating. In the application as originally filed
(yesterday!) the mark appeared as:<br>
</p>
<p><img src="cid:part1.Ljduij0g.nPSc4G0z@oppedahl.com" alt=""></p>
<p>The character that the applicant filed is Unicode 2027 which is
also called "hyphenation point". (That is 2027 in hexadecimal.
If you express it as a decimal number you get Kevin's 8231.)<br>
</p>
<p>Today the TSDR engine renders the drawing as:</p>
<p><img src="cid:part2.DwAWpTZa.hbLWO6g6@oppedahl.com" alt=""></p>
<p>Oh by the way if you ever have a character and you wonder which
Unicode character it is, one way to find out is <a
href="https://www.babelstone.co.uk/Unicode/whatisit.html">this
web site</a>.<br>
</p>
<p>There are several paths for a trademark application to get into
USPTO's systems:</p>
<ul>
<li>paper filing</li>
<li>Madrid designation to the US (79 series code)<br>
</li>
<li>Trademark Center (child of TEAS)</li>
</ul>
<p>In the old days of paper filing, these problems like mishandling
of Unicode characters simply were unable to arise. Somebody at
the USPTO would be hand-keying the drawing into a USPTO system and
the software used by the USPTO person simply did not permit keying
in anything other than ASCII.<br>
</p>
<p>Knowing what I have seen of cases where USPTO systems have
botched the handling of Madrid cases, I'd guess the USPTO's coders
have in the past not paid anywhere near to enough attention to
stuff like (non-ASCII) Unicode characters that might slip in from
the Madrid system.</p>
<p>Then for some years the path 3 was TEAS and it did whatever it
did about Unicode. But that is in the past now. Now we have TC.
And over the course of many months there have been instances
where it appears that the coders at USPTO who coded Trademark
Center dropped the ball on Unicode. It simply should not happen
that the TC software permits these two things to happen in the
same single trademark application:</p>
<ul>
<li>the filer gets away with claiming "standard characters", and</li>
<li>the filer includes a non-standard character in the mark.</li>
</ul>
<p>There should be no way to enter a character that is not a
standard character into TC and get away with calling the mark a
standard-character mark.</p>
<p>So I tried this same filing today. I went into TC and I did what
I imagine are the exact same things that Nitin Kaushik (the
attorney in yesterday's case) did yesterday.</p>
<p>And I pasted "Z\u2027PILOT" into the box for "what is my trademark".
And TC caught it! Here is what TC said:</p>
<p><img src="cid:part3.2fuozu1T.Gq8Egf8q@oppedahl.com" alt=""
width="499" height="307"> </p>
<p>This is today, April 15. I was not able to use U+2027 in TC
while calling it a standard character. And yet yesterday, April
14, Nitin Kaushik was able to use U+2027 in TC while calling it a
standard character.</p>
<p>Kevin wrote:</p>
<blockquote>
<p>In any case, I'm guessing everyone on this E-trademark
discussion group will be more thoroughly double checking the
USPTO generated standard character drawings before submitting
their standard character marks.</p>
</blockquote>
<p>But my experiment that I carried out today suggests that there is
no need for such double checking. There was, apparently, a need
for such double checking yesterday, but not today. <br>
</p>
<p>I wonder if the coding of TC changed between yesterday and today?</p>
<p>Carl<br>
</p>
<div class="moz-cite-prefix">On 4/15/2025 6:59 AM, Ken Boone via
E-trademarks wrote:<br>
</div>
<blockquote type="cite"
cite="mid:SN6PR14MB2237C40A8CFD9468672D6986D5B22@SN6PR14MB2237.namprd14.prod.outlook.com">
<div class="elementToProof">
I happened to notice a new standard character application,
namely 99134995 - Z<span>\u2027</span>Pilot - filed April 14, 2025 at
4:58:56 AM ET according to the raw application on TSDR (<span>highlighting</span> mine).
Looks pretty common, right? Well, consider the drawing.</div>
<div class="elementToProof">
<br>
</div>
<div class="elementToProof">
<img id="image_0" moz-do-not-send="true"></div>
<div class="elementToProof">
<br>
</div>
<div class="elementToProof">
Yes, the second character <span>\u2027</span> is a little bit
special. By my check, \u2027 is the Unicode character with decimal
value 8231. The USPTO's standard character set only consists of
characters with decimal values ranging from 32 to 382. So, the
current electronic application system accepted \u2027 as a standard
character but generated a box instead of a raised dot for the
official standard character drawing?</div>
<div class="elementToProof">
<br>
</div>
<div class="elementToProof">
It's been a while since I have <i>tested</i> the USPTO's
electronic application system. Does it still present a graphic
of the standard character drawing for the applicant to review?
Did this applicant simply ignore that option to review the
drawing generated by the USPTO for the wordmark provided for
this standard character mark? Will the applicant have the
option of amending the mark, converting the \u2027 character with
decimal value 8231 to the standard character
<b>·</b> (the <b><i>middle dot, centered dot</i></b> character
with decimal value 183) and have the electronic application
system generate a more appropriate official drawing, or would
that constitute a material alteration of the mark?</div>
<div class="elementToProof">
<br>
</div>
<div class="elementToProof">
In any case, I'm guessing everyone on this E-trademark
discussion group will be more thoroughly double checking the
USPTO generated standard character drawings before submitting
their standard character marks.</div>
<div class="elementToProof">
<br>
</div>
<div class="elementToProof">
From the raw application on TSDR.</div>
<div class="elementToProof">
<br>
</div>
<div class="elementToProof">
Trademark/service mark application, Principal Register</div>
<div class="elementToProof">
Serial number: 99134995</div>
<div class="elementToProof">
Mark: Z\u2027Pilot</div>
<div class="elementToProof">
Mark format: Standard character</div>
<div class="elementToProof">
Filing date: April 14, 2025 at 4:58:56 AM ET</div>
<div class="elementToProof">
Docket number:</div>
<div class="elementToProof">
Owner name: Shenzhen Sipaili Technology Co., Ltd</div>
<div class="elementToProof">
Amount paid: $350 (1 class)</div>
<div class="elementToProof">
Trademark details</div>
<div class="elementToProof">
Mark</div>
<div class="elementToProof">
Z\u2027PILOT</div>
<div class="elementToProof">
Mark Format</div>
<div class="elementToProof">
Standard character</div>
<div class="elementToProof">
The mark consists of standard characters, without claim to any
particular font style, size, or color.</div>
<div class="elementToProof">
<br>
</div>
<div class="elementToProof">
<br>
</div>
<div class="elementToProof">
<br>
</div>
<div class="elementToProof" id="Signature">
<div>
Happy Standard Character Marking!?!?!</div>
<div>
Ken Boone</div>
<div>
<br>
</div>
<div>
PS - You probably didn't notice, but there's a new Madrid
application <span>
<b>without a filing date</b></span>. Well, it is not all
that new, as it was received at the USPTO on Nov. 16, 2023
(according to the mail/create date for the application on
TSDR). Additionally, it has neither a wordmark nor any GS
text on Trademark Search/TSDR. And how did it get the 1 -
TYPESET WORD(S) /LETTER(S) /NUMBER(S) mark drawing code unless
Pre-Exam did their initial processing, except how could
Pre-Exam then ignore the missing wordmark, GS entry, etc.?
Well, there is a Note to the file stating
<span><b><i>Per the 4/11/2024 correction notice Correction to
the initial EOP limitation has been entered</i></b></span>,
so apparently both the USPTO and the IB are a little confused
about this application that is still awaiting assignment to an
examining attorney. So it goes.</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div class="elementToProof">
<br>
</div>
<div class="elementToProof">
\u2002\u2002\u2002\u2002\u2002\u2002\u2002\u2002\u2002\u2002\u2002\u2002<img alt="Trademark image" id="image_1"
moz-do-not-send="true"></div>
<div class="elementToProof">
<br>
</div>
<div class="elementToProof">
Generated on:\u2002\u2002\u2002\u2002\u2002This page was generated by TSDR on
2025-04-08 06:56:36 EDT</div>
<div class="elementToProof">
<span>Mark:\u2002\u2002\u2002\u2002\u2002\u2002\u2002</span></div>
<div class="elementToProof">
Trademark image</div>
<div class="elementToProof">
US Serial Number:\u2002<b>79383109\u2002\u2002\u2002\u2002</b><span>Application Filing
Date:\u2002\u2002\u2002\u2002\u2002\u2002</span></div>
<div class="elementToProof">
Register:\u2002\u2002\u2002Principal</div>
<div class="elementToProof">
<br>
</div>
<div class="elementToProof">
Status:\u2002\u2002\u2002\u2002\u2002New application awaiting assignment to an
examining attorney. See current trademark processing wait
times for more information.</div>
<div class="elementToProof">
Status Date:\u2002\u2002\u2002\u2002\u2002\u2002<span>Nov. 16, 2023</span></div>
<div class="elementToProof">
</div>
<div class="elementToProof">
Mark Information</div>
<div class="elementToProof">
Mark Literal Elements:\u2002\u2002None</div>
<div class="elementToProof">
Standard Character Claim:\u2002\u2002\u2002\u2002\u2002<span><b>Yes. The mark consists
of standard characters without claim to any particular
font style, size, or color.</b></span></div>
<div class="elementToProof">
Mark Drawing Type:\u2002\u2002\u2002\u2002\u2002\u2002<span>1 - TYPESET WORD(S) /LETTER(S)
/NUMBER(S)</span></div>
<div class="elementToProof">
<br>
</div>
<div class="elementToProof">
<br>
</div>
<div>
<br>
</div>
<div>
<br>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
</body>
</html>