Patentcenter mishandles diacritical marks

(Updated to use a different inventor name.)

(This is trouble ticket number CP26.)

Patentcenter does a very poor job with diacritical marks.  Alpha testers of Patentcenter have been reporting this problem for over a year now and it has not been fixed.

There is not merely some single way that Patentcenter does poorly with diacritical marks.  There are multiple lapses in design and implementation quality.  I will detail them one by one.

We start with a general notion that of course it is a Good Thing if a patent office makes it easy for a filer to provide information in computer-readable form, and then if the patent office auto-loads that information faithfully into USPTO’s systems.  In general, the USPTO fails miserably at this seemingly easy Good Thing:

• The filer uses the web-based Form 85B to pay an Issue Fee, providing the Assignee information in computer-readable form.  USPTO flattens the information into an image, and then hand-keys the Assignee information onto the front page of the issued patent.  
• The filer uses the web-based Corrected ADS to provide updated bibliographic data, providing the updated bibliographic information in computer-readable form.  USPTO flattens the information into an image, and then hand-keys the new bibliographic information into Palm.  
• The filer provides a patent application in Microsoft Word format (misnamed by the USPTO as “DOCX format”).  USPTO renders the word processor file into a PDF using a proprietary rendering engine, the behavior of which is unpredictable, and forces the filer to sign an adhesion contract agreeing that the PDF rendering will control even if the rendering engine makes mistakes.

The Patentcenter design defects are easy to see from this sequence of events.

The starting point of course is USPTO’s Form AIA/14, the ridiculously large (over one megabyte) PDF computer-readable fillable PDF form.  I completed this form with the name of an inventor:

If you click to enlarge, you can see the kreska ukośna (stroke) in the letter ł which appears as the seventh letter in the inventor’s given name.  This is pronounced sort of like the letter “w”.  I suppose if a person gives up and attempts to select a Latin character instead, it might be the letter “L”.  You can also see the kreska (which is graphically similar to the acute accent) in the letter ś, which appears as the third letter in the inventor’s family name.  I suppose if a person gives up and attempts to select a Latin character instead, it might be the letter “S”.

The eventual resting place for this bibliographic data is Palm which is a four-letter acronym (“Patent Application Location and Monitoring”).  Maybe Palm is able to store the stroke-L or maybe Palm is not able to store it.  The actual answer is not very important here.  The important thing is that if the designers of these systems were doing their jobs, they would validate the user inputs from the very start for things like this.

For example if Palm turns out to be incapable of storing a stroke-L, then (design mistake number 1) the Form AIA/14 should puke on the stroke-L the instant that I try to paste it into the inventor given name field.  The fact of Form AIA/14 accepting the character rather than puking on it is, I submit, a promise by the USPTO that all downstream systems will accept the stroke-L.  As will be seen, the USPTO breaks that promise.  

The next step in Patentcenter is for the filer to upload Form AIA/14 into Patentcenter.  I did that.  Patentcenter then opens the ADS and extracts several fields and displays them on the screen for the filer to review.  This is a very nice feature, much nicer than what EFS-Web does.   This avoids the evil in EFS-Web of making you enter such things twice — once on a web-based screen and a second time through the uploaded ADS.  And it permits you to check one last time to see whether for example by accident you uploaded the wrong ADS, for example an ADS from some other patent application.  Here is what I saw on the Patentcenter screen when I did this:

Review the following information to make sure it is correct. In case of any errors fix the application data sheet and upload the file again.

So of course following the instructions, I did review the information to make sure it was correct.  You can click to enlarge and you can see that the stroke-L and the accent-S each came through from the ADS into Patentcenter just fine.  

The fact that the Patentcenter screen saying “review this information to make sure it is correct” shows the system accepting the character rather than puking on it is, I submit, a second promise by the USPTO that all downstream systems will accept the stroke-L.  As will be seen, the USPTO breaks that second promise.  

So then, relying on the Patentcenter preview of this bibliographic data which auto-loaded from my ADS, I e-filed the patent application.  The first hint that the Patentcenter designers screwed up was in the Acknowledgment Receipt.  In the Ack Receipt the system silently discarded two characters — the stroke-L and the accent-S.  This is very poor system design.  If designers are going to discard characters for any reason, the designers need to explicitly tell the user that they choose to do this.  This is defect number three.

We then click around in the PAIR-like functions of Patentcenter with a goal of seeing what is actually in Palm.  And what we see is this:

Well okay.   In a way in could be said that this is less bad than what USPTO did in the Ack Receipt.  At least on this screen the USPTO comes out and openly admits having mishandled two characters, replacing them on the screen with question marks. 

The normal “USPTO way” of dealing with failures like this is “blame the user”.  Instead of doing decent data validations at filing time, the USPTO normally ducks this and instead selects the most hard-to-find place on the USPTO web site and tucks away some obscure list of “acceptable characters” for this system or that system.  Never mind that there is no single list of “acceptable characters”.  There is the AC list for Form AIA/14 in and of itself.  There is the AC list for Palm for inventor names.  There is the AC list for Palm for street addresses.  There is the AC list for characters permitted to be used in patent applications filed in Microsoft Word format (misnamed as “DOCX format”).  There is the AC list for characters permitted in EPAS for street names for assignees, or for characters permitted in assignee names.  No matter what, the usual approach is to hide away some list and then when some USPTO system turns out to be designed poorly (as illustrated here) the USPTO will blame it on the filer who (USPTO says) should have known better than to try to use the accent-S in the first place.

USPTO should get in touch with WIPO to learn how to do this sort of thing correctly.  In ePCT, the system validates user inputs against permitted character sets at data entry time.  If ePCT fails to flag a character is supposedly not permitted, then the character really does auto-load into all downstream systems without a hitch.