[E-trademarks] ZWSP (was Standard Character Watch: 79409085 - A³-SHIELD - Now Scheduled For Publication!?!?)

Carl Oppedahl carl at oppedahl.com
Thu Jul 10 19:24:57 UTC 2025


Aha!  There's a chance I learned something from Ken today.  See below.

On 7/10/2025 12:41 PM, Ken Boone via E-trademarks wrote:
> [...]
>
> Following are some recent additions to my */challenging standard 
> character mark/* watch list (where the reader gets to determine why I 
> decided these standard character marks were /challenging/).
>
> SN
> 	
> Wordmark
> 	
> Drawing
> 99181596
> 	
> OMMISIMQIST​
> 	
> _Image for 99181596, select for more details_
>
>
Okay here is my guess as to why Ken deems this application number 
99181596 to be "challenging".  Prompted by Ken, I looked up that case in 
TSDR.  I then went to the application-as-filed to copy the mark as filed.

On a quick glance one might assume that this mark contains eleven 
characters, starting with "O" and ending with "T".  But the alert reader 
eventually catches on that there are not eleven but twelve characters in 
this mark.  Yes, after the "T" there is a twelfth character.  Maybe you 
can't see it, depending on what software you are using to view the 
drawing, but it is there.

I then pasted the mark into a string-to-hex converter 
<https://www.rapidtables.com/convert/number/ascii-to-hex.html> and it 
revealed the hexadecimal values of the characters:

    4F 4D 4D 49 53 49 4D 51 49 53 54 200B

This tells us that there are indeed twelve characters.  We recognize 
"4F" as the hex value for "O" and we recognize "54" as the hex value for 
"T".  And we then turn our gaze over to the character after "T" (the 
character after "54").  The hexadecimal value is "200B".  Clicking 
around on the Internet reveals this:

    Unicode character U+200B represents a Zero Width Space (ZWSP). It is
    a non-printing character that does not take up any visible space on
    the rendered text. It's used in computer typesetting to indicate
    where word boundaries are, primarily for line breaking purposes in
    scripts that don't use explicit spacing.

So yes, for this application number 99181596 we have a twelve-character 
mark of which on a quick glance there might only have been eleven 
characters.

Clearly what absolutely must not happen is the Trademark Office sort of 
looking the other way and pretending that the mark has only eleven 
characters.  What must not happen is the case getting published for 
opposition, and then going to registration, with only eleven characters 
appearing in the registration certificate.

There are many sad things here.  A first sad thing is that clearly the 
Trademark Office people who coded the software in the Trademark Office 
systems failed to code it to flag this (presumably) nonstandard 
character for the Examining Attorney to pay attention to.  It would have 
been trivially easy to do (for example a regular expression could have 
detected it).  But no, this trivially easy thing did not get done.  
There is no hint or suggestion anywhere in TSDR that anything at all has 
been done to flag this situation for the Examining Attorney.

A second sad thing is that clearly the Trademark Office people who coded 
the software in the Trademark Office systems failed to code it to flag 
this (presumably) nonstandard character /*during the application process*/.

As we sit here as third-party observers, of course we do not know 
whether the applicant actively wants twelve characters in this 
application (including the ZWSP) or whether, perhaps, it was an 
inadvertent mistake on the part of the applicant.

But the ideal time to smoke this out would have been /*during the 
application process. */Trademark Center ought to have flagged this to 
the filer.  TC ought to have said something like "we have detected a 
character in your drawing that is not a standard character".  And TC 
ought to have asked the filer to pick one path or another depending on 
what the filer actually intended for the drawing.

Again it would have been trivially easy to detect this (again, for 
example a regular expression could have detected it).  But no, this 
trivially easy thing did not get done in the coding of TC.

I have of course loaded this application into IP Badger.  The case was 
filed in May, so maybe it will get examined in around December.  I will 
watch to see how the Examining Attorney handles this twelfth character 
in the drawing.

Having said all of this, I realize I may not have figured out why Ken 
calls this a "challenging" case.  His reason for calling this a 
"challenging" case may be something else.

Carl


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oppedahl-lists.com/pipermail/e-trademarks_oppedahl-lists.com/attachments/20250710/2cb4f761/attachment.html>


More information about the E-trademarks mailing list