[E-trademarks] Solicitation from Chinese Firm

Stacy Grossman sgrossman at sgip.law
Thu Sep 25 18:26:25 UTC 2025


Sharing selections from an email received from a firm in China.

Anyone interested???  ;-)


Hi, I am a trademark attorney for XXX Firm in China and we express our
desire to seek a key partner to build win-win cooperation in the area of
patents, designs and trademarks, licensing and infringement, especially in
trademark registration.

***

Our client's budget is *$50 per new trademark application* agent fees.

Response OA (including the fee for changing the agency) - $35

SOU (including the fee for changing the agency) - $35

Setion 8 (including the fee for changing the agency) - $50





STACY J. GROSSMAN

*PRINCIPAL*


o: (212) 873-6120

m: (917) 693-9143

e: sgrossman at sgip.law

www.sgip.law


On Wed, Sep 24, 2025 at 4:46 PM Ken Boone via E-trademarks <
e-trademarks at oppedahl-lists.com> wrote:

> Another irregularity: the new *Beta* view of the *TSDR*-like record for
> *99407734* does NOT show the* Attorney info,* the *Correspondence info*,
> or the *Prosecution history* (including the *raw application*).  Since
> that Beta view is more copy/paste *friendly*, here's the relevant portion
> of that *Beta *view.
>
> Attorney information
> N/A
> Correspondence information
> Name
> undefined
> Address
> Email
> Prosecution history and documents
> Documents only
> Date
> Description
> Document
> Proceeding
> Items per page:
> 5
> 0 of 0
> Proceedings
> N/A
>
> Of course, this Beta view of the *TSDR*-like record was not possible on
> Trademark Search yesterday, as this new application was not available on
> Trademark Search until today's update occurred.  (Yes, I was confused
> yesterday when trying to find this application on Trademark Search until I
> noticed the filing date of this application.)
>
> Hope this helps,
> Ken Boone
> ------------------------------
> *From:* E-trademarks <e-trademarks-bounces at oppedahl-lists.com> on behalf
> of Carl Oppedahl via E-trademarks <e-trademarks at oppedahl-lists.com>
> *Sent:* Tuesday, September 23, 2025 12:07 PM
> *To:* for trademark practitioners <e-trademarks at oppedahl-lists.com>
> *Cc:* Carl Oppedahl <carl at oppedahl.com>; TEAS <teas at uspto.gov>
> *Subject:* [E-trademarks] Yet another really bad defect in Trademark
> Center
>
>
> 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
> --
> E-trademarks mailing list
> E-trademarks at oppedahl-lists.com
> http://oppedahl-lists.com/mailman/listinfo/e-trademarks_oppedahl-lists.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oppedahl-lists.com/pipermail/e-trademarks_oppedahl-lists.com/attachments/20250925/d7ece9ea/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/20250925/d7ece9ea/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/20250925/d7ece9ea/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/20250925/d7ece9ea/attachment-0002.png>


More information about the E-trademarks mailing list