USPTO chips away at auto-loading of bib data into Palm

When EFS-Web was new, the USPTO tried to be smart about bibliographic (bib) data.  USPTO designed Form PTO/SB/14 which was an enormous (one megabyte) PDF form.  The user could paste the bib data into the form.  This included things such as “who are the inventors” and “what are their residences” and “what is the priority claim” and “what domestic benefit claim is being made to a provisional application”.  The form was entitled “Application Data Sheet” (ADS).

This was a lot of work for the user, but USPTO dangled a reward.  If the user were to include this ADS in the initial EFS-Web submission, the USPTO would promise to auto-load all of the bib data into Palm.  From there it would propagate into PAIR and it would be used in preparing the official Filing Receipt.  I will now describe how this reward gradually changed into a hoax.  

The reward was that from the filer’s point of view, the auto-loading greatly reduced the risk of USPTO personnel fat-fingering the bib data.

As an old-timer let me tell new readers how this used to work, before EFS-Web and the one-megabyte ADS.  In the old days, no matter which approach the filer selected for communicating bib data to the USPTO (might have been an ADS, might have been the oath or declaration), the document got imaged and any and all character content got discarded.  USPTO personnel then hand-keyed all of the bib data from the image into Palm.

In those old days, our firm tried to track this stuff pretty closely.  When the official Filing Receipt showed up, it contained errors well over fifty percent of the time.  Sometimes an item on the Filing Receipt would be misspelled.  Or an entire item of information (an entire inventor, say, or an entire priority claim) would get overlooked and would be missing from the Filing Receipt.  The USPTO person who was hand-keying the bib data might accidentally jump from inventor number 3 to inventor number 5, missing inventor number 4.

Of course this meant that we were forced to request a corrected Filing Receipt.  Which USPTO would duly mail out.  And in about one-third of cases, the supposedly corrected Filing Receipt would still contain errors or new errors would somehow have crept in.  In such cases we would have to send in a second request for a corrected Filing Receipt.

Every now and then it would actually take three requests for corrected Filing Receipts before we would receive an accurate Filing Receipt.  I don’t recall any case where four requests were needed, but there were several cases where three requests were needed.

So anyway when the USPTO came up with this system in which the user-provided ADS would auto-load all of the bib data into Palm, this was a breath of fresh air.  It meant that so long as we avoided error in our pasting of information into the ADS, the Filing Receipt would be error-free.  For once the USPTO was being smart about this kind of thing.

It was, in those days, our standard procedure after filing a new case to go into PAIR and print out the Pub Review page.  If the information on the Pub Review page was accurate, this meant that the Filing Receipt would be accurate.

And so it went for several halcyon years.

But about three years ago, USPTO began to backtrack.  USPTO changed its BPR (business process rule) so that the foreign priority information no longer auto-loaded into Palm.

This meant that for the foreign priority information to get into USPTO’s systems, some USPTO person would have to (argh!) hand-key it into the USPTO system.

Which meant that even if we were to paste the foreign priority information into the ADS without error, there was still a non-negligible risk that the foreign priority information would turn out to be wrong on the Filing Receipt.  And indeed that is how it worked out.  In one notable case our ADS had listed a priority of Chinese patent application with some twelve digits, and the Filing Receipt showed up from the USPTO with a French patent application of about eight digits listed for the priority.  Oh and a completely different priority filing date with no digits in common with the correct priority filing date.

Then about two years ago, USPTO backtracked further.  USPTO changed its BPR so that the domestic benefit information (for example a benefit claim to a US provisional application) would no longer auto-load into Palm from the ADS.

This, too, means that the mere fact of our correctly supplying dom-ben information in the ADS is no assurance that the dom-ben information will be accurate when USPTO sends us the Filing Receipt.

It means that the proffered reward — filers who go to the trouble of providing bib data in this one-megabyte PDF form will be saved from having to request corrections of that bib data when the Filing Receipt shows up — is by now a hoax.

I don’t know why the USPTO changed those BPRs.  It seems ill-conceived to discard character-based data provided by the customer and to rely instead on hand-keying by USPTO personnel.  I can only guess at the reason for this odd shift.  Maybe USPTO was finding that its employees who were supposed to double-check this stuff were snoozing through it when filers sometimes got things wrong.  In other words maybe its employees who were supposed to double-check this stuff were just clicking the “approve” button on the screen so as to keep up the production quotas or something.  And the management decision as to what to do about it was to switch off the auto-loading.  That would force the employees to actually look at the information when they were hand-keying it.  And this would somehow be the better way to proceed.  Yeah right.

In an earlier life I did plenty of coding.  I can certainly think of different and better ways that USPTO management could have dealt with this “click-the-approve-button” problem if indeed that was the problem that needed fixing.  For example, if you must force the USPTO person to hand-key the information, then when the USPTO person clicks “submit”, the system would compare the customer-provided character-based information from the ADS with the hand-keyed information from the USPTO person.  If they matched, then proceed.  If they did not match, then this gets reviewed by a supervisor, something like that.  Such an approach would at least make use of the character-based information provided by the customer, rather than discarding it.

Again if you want to see how this sort of thing could be done better, instead of being done poorly, look at how WIPO receives bib data for PCT applications.  WIPO provides customer-friendly tools such as PCT-SAFE and ePCT.  The tools can draw upon the user’s own address book to fill in bib data fields.  The tools can (and do) carry out hundreds of validations that save practitioners from a wide range of mistakes that could be embarrassing or worse.  And (gasp) the PCT e-filing systems then do auto-load the bib data into the relevant computer systems.  No hand-keying takes place at the patent offices involved.

To summarize, I am very disappointed that USPTO has in recent years chipped away at the items of bib data that auto-load into USPTO’s systems.  This is backwards progress, not forward progress.