How USPTO could handle bib data changes better

(On December 21, USPTO released a new functionality called Corrected Web-based Application Data Sheet.  I have posted a followup blog article about this new functionality.)

Sometimes a filer needs to update bibliographic (bib) data in a pending patent application.  In a recent blog post I talked about how USPTO’s preferred way of receiving requests for bib data changes is ill-conceived and wastes the valuable time of USPTO personnel and valuable time of the filer.  In that blog post I described how USPTO’s rules actually permit the use of a “smart procedure” in which the filer only lists the items being changed.  Items that are not being changed could be omitted in this “smart procedure”.  But the USPTO actually recommends that the “smart procedure” not be followed.

Having said all of this, the constructive thing to do is to describe how the USPTO could handle bib data changes better.  Which I will now do.  

The way that USPTO could handle bib data changes better is like this.

The user would go to a web-based page, perhaps by means of EFS-Web or Private PAIR.  The web page would permit the user to click a button indicating that the user wishes to make a bib data change.  The user would indicate the particular pending patent application for which the change is to be made.

The page would then ask which particular item of bib data is desired to be changed,  Is it perhaps an inventor’s mailing address?  An item of domestic benefit information?  A detail of the foreign priority?  The user would pick from a list.  Let’s suppose that the item to be corrected is a detail of the foreign priority.  So the user will pick this from the list.

The system will then display the present bib data for the foreign priority.  The system will then ask what change is desired.  Deleting the priority claim?  Adding an additional priority claim?  Correcting some error in the existing priority claim?  The user would pick from a list.  Let’s suppose that the item to be corrected is the Office of filing for the foreign priority.  The filer previously incorrectly listed “EM” (OHIM) for the design filing priority when in fact the priority application was a Hague filing at the IB (for which the correct two-letter code would have been “WO”.)  The user would pick from a list that this is the item to be changed.

The system would then display the present value of “EM” and would invite the user to indicate the new value (in this case “WO”).  Depending on the type of data item, this might be a selection from a drop-down list or a free-form text entry.

The user would then be given a chance to review the proposed change, and could then click “submit”.

Later some USPTO person would review the submitted request and would enter it into the application.

Wouldn’t it be nice if USPTO were to permit bib data updates like this?

Oh, and it turns out that there is a patent office that permits bib data updates in just this way.  WIPO permits bib data updates to be done this way for any PCT application that is in the international phase.  The filer can carry out exactly these steps, using an “action” in the ePCT system.  When I wrote the above “wouldn’t it be nice” description of what USPTO ought to make possible, I was merely describing how it presently works in the ePCT system.

WIPO is to be commended for offering such a user-friendly way for requesting updates of bib data.

(If you are a PCT practitioner and have not yet learned how to use ePCT, now is the time!)

3 Replies to “How USPTO could handle bib data changes better”

  1. Great idea. Would have saved me a lot of time in a case where I accidentally forgot the second slash in the s-signature of an ADS. That was fun. USPTO advised that the ADS would not be recognized as such but treated as a transmittal letter because it wasn’t signed. Resubmitted with the second slash – but that they didn’t like since it didn’t show difference to first ADS which they said wasn’t an ADS. Finally submitted the ADS with everything underlined.

Leave a Reply

Your email address will not be published. Required fields are marked *