USPTO can now publish a new Federal Register notice about ePCT

For many years the Best Practice for filing in RO/US has been to use a ZIP file as the way to provide the PCT Request to EFS-Web.  Originally the only way create the ZIP file was PCT-SAFE.  Three years ago WIPO announced that ePCT would be available starting on June 1, 2016 as a second way to create the ZIP file.  Shortly after this announcement, USPTO published a Federal Register notice that put a cloud over the use of ePCT in this way.  WIPO has made a change to ePCT that obviates concerns raised in that notice.  Hopefully now the USPTO will publish a “cloud removal” Federal Register notice that expressly cites the previous notice and that expressly removes the cloud.

In this blog article I explain that at this point ePCT is now without question the Best Practice for creating the ZIP file.  And I offer proposed language for a “cloud removal” Federal Register notice.

First a bit of background.  PCT is complicated, and there are many ways in which the unwary practitioner can screw up a PCT application.  Some of the ways that the practitioner can screw up a PCT application are so serious that substantive rights can be irrevocably lost.  For a filer in the RO/US, one of the smartest ways that a practitioner has been able to reduce the risk of screwing up has been the use of PCT-SAFE software.  PCT-SAFE carries out dozens of “validations” on the bibliographic data entered by the practitioner.  With PCT-SAFE, after the validations had been carried out, the user receives a ZIP file which can then be uploaded to EFS-Web.

Over the years, through various roles (presenter in PCT seminars, cleaner-up of referred-in cases, service as expert witness, colleague at professional meetings, informal discussions with Office personnel) I have become familiar with many hundreds of cases where a practitioner screwed up a PCT application, many dozens of which screwups led to irrevocable losses of substantive rights.

Here are the sad facts:

• In well over half of the screwups, the screwup would have been simply prevented had the practitioner made use of the validations offered by PCT-SAFE or ePCT.
• In many of the remaining screwups, even if the use of the software would not have prevented the practitioner from screwing up, diligent use of ePCT to manage the pending case would have brought the screwup to light soon enough to permit corrective steps.

Put plainly, if a filer files using a ZIP file, then by definition the filer must have made use of software (PCT-SAFE or ePCT) to create the ZIP file.  And by definition the filer must thus have benefited from the validations carried out by the software.  Which means that whole categories of malpractice will have been avoided by the filer.

Given these facts, you might think that of course every PCT application filed in the RO/US in recent years would have been filed using a ZIP file.  What practitioner would ever knowingly pass up the chance to use software that drastically reduces the risk of malpractice lawsuits?  Astonishingly, the actual situation is that in 2018 fully 55% of all PCT applications filed in RO/US were filed without a ZIP file.  Put plainly, fully 55% of PCT applications filed in RO/US did not receive the benefit of any data input validations.  This 55% “non-compliance rate” surely has led and, so long as it persists,will continue to lead to many applicants being harmed or losing substantive rights at the hands of sloppy practitioners.

What I have heard informally from people who sit at the PCT Help Desk at the USPTO is when a caller is a practitioner who turns out to have screwed up very badly in the filing of a PCT application, nearly always it turns out the practitioner did not upload a ZIP file. Meaning that the practitioner did not use PCT-SAFE or ePCT to prepare the Request.

When I learn of a case where a practitioner screwed up a PCT application so badly that substantive rights were lost, what I very often find is that it would have been impossible for the screwup to happen at all if the practitioner had been using PCT-SAFE or ePCT.  And in the remaining cases where the use of PCT-SAFE or ePCT would not have been able to prevent the screwup, the use of ePCT thereafter to manage the pending case would have brought the screwup to light in good time to correct things.

With this background in mind, we come to the events of 2016.  The important events of 2016 for this discussion are:

• WIPO announced that starting on June 1, 2016 it would be possible to create the ZIP file in ePCT as an alternative to using PCT-SAFE to create the ZIP file, and
• USPTO thereafter published the Federal Register notice warning filers of the dangers of using ePCT.

From the moment that ePCT became available as a way to create the ZIP file, it was by far the smarter way to do so, for many reasons, including:

• ePCT cross-checks priority claim data against the DAS system which PCT-SAFE does not.
• ePCT permits collaborative workflow, with shared access to in-progress submission packages by multiple users;  PCT-SAFE does not.
• ePCT works on any platform having a web browser, including Chromebook, Linux, and Mac.  PCT-SAFE works only on Windows.
• ePCT is always up to date;  PCT-SAFE can get out of date if a user fails to keep it up to date.
• ePCT has shared address books;  PCT-SAFE does not.

For me the first reason (the DAS crosscheck) is by far the most important because it is a malpractice risk avoidance feature.  For a priority application that is in the DAS system, it reduces to zero the risk of a mistyped priority application number.  Maybe for some other users the second, third, fourth or fifth reasons might be important.

Unfortunately, as soon as WIPO made this announcement about ePCT being available as a way to create the ZIP file, the USPTO published the Federal Register notice. It warned applicants that before using ePCT to create a ZIP file, the applicant might need to obtain:

appropriate clearances from the Bureau of Industry and Security (BIS) at the Department of Commerce …, the Directorate of Defense Trade Controls (DDTC) at the Department of State, or the National Nuclear Security Administration (NNSA) at the Department of Energy.

This Federal Register notice is presumably a major factor contributing to the 55% non-compliance rate.  That is, when you see that 55% of PCT applications are filed without a ZIP file, much of this behavior is presumably due in part to the Federal Register notice that gives this extremely scary warning.

It is worth recalling that ePCT serves many other functions in addition to generating ZIP files.  For example ePCT provides a function that is much like that of Private PAIR, so that users can see the content and status of their (otherwise secret) pending PCT applications.  The situation in 2019 is that almost no US PCT filers use ePCT for any function.  I have to imagine that many who read that Federal Register notice got the mistaken impression that if you use ePCT in any way, you were risking running afoul of these various national security laws.

With this background, we can turn to today’s development.  And we can discuss the “cloud removal” Federal Notice that USPTO should now publish.

The concern raised in the 2016 Federal Register notice, simply put, was that a filer who does either of two things might conceivably run afoul of national security laws by doing either of two things:

• pasting the Abstract into the ePCT web screen, or
• pasting the Title into the ePCT web site.

To give an example, an Abstract might explain how to create some kind of nuclear weapon.  The ePCT system does not, however, actually require that the user paste the Abstract into the screen, it merely suggests it.  The filer who wishes to avoid the risk of inadvertently exporting nuclear weapon secrets through the “abstract” field of the web page may achieve this goal by the simple step of not pasting anything into that field.

It will be appreciated that even if the EFS-Web user does not paste the Abstract into the field (so that it ends up inside the ZIP file), this does not mean that the to-be-filed PCT application will not include an Abstract.  The Abstract normally gets uploaded into EFS-Web as a PDF file regardless of whether there is or is not an Abstract inside the ZIP file.

The other concern raised in the notice is that even the Title, all by itself, could conceivably explain (for example) how to create some kind of nuclear weapon.  Until now, the ePCT software did check to see whether the filer had pasted a title into the screen.  What I recommended for all these years was to put a period into the “title” field.  This would fake the software into thinking that a title had been pasted into the screen.  What would happen next is that RO/US would see the fact of the title being missing in the Request, and would copy the title from the Description (provided to EFS-Web as a PDF) onto the Request as an ex officio correction.

Today’s change is that if the RO/US is being used, ePCT no longer requires that the filer has pasted a title into the screen.  What happens instead (quoting from “What’s new in ePCT” on the WIPO web site) is this:

When preparing a draft application for filing to RO/US, it is now possible to indicate that the title is as provided on page 1 of the description and will not be typed into ePCT. Accordingly, there will be no error message preventing filing due to the missing title. This procedure has been introduced in collaboration with the USPTO, who will not issue any invitation to correct in such cases, provided of course that the title of the invention appears on page 1 of the description that is submitted to RO/US using EFS-Web.

This is what it looks like on the screen:

The idea is that the filer who reaches this screen can make a choice.  If filer is worried about the warning in the Federal Register notice, the filer can simply check the box as shown.  This relieves the filer of any need to paste anything into the “title” field on the web page.

To summarize, as of right now, there is absolutely no reason for any filer in RO/US to worry about the warnings in the Federal Register notice.  The filer can simply (a) not paste anything into the “abstract” field of ePCT and (b) check the box so that there is no need to paste anything into the “title” field of ePCT.  The filer must then, of course, ensure that the Abstract and Title are provided (as they usually are) in the various PDF files that the filer uploads into EFS-Web.

Laid on top of all of this is that if the filer has a Foreign Filing License that covers the content of the to-be-filed PCT application, the Even Better Practice is simply to file in RO/IB.  Filing in RO/IB offers many advantages including:

• the just-filed PCT application is visible instantly in your workbench instead of taking a week or two to become visible;
• the Transmittal Fee is cheaper;
• the PDF uploading interface permits you to preview your documents to see if they will get blurred in the e-filing process (a feature conspicuously absent in EFS-Web).

Given these and other advantages to the use of RO/IB, why does any filer use RO/US?  So far as I can see, the only reasons that the filer should even consider filing in RO/US rather than in RO/IB are:

• the time of day is past midnight in Switzerland and the user needs a same-day filing date, or
• the invention was made in the US and the user does not have a Foreign Filing License that covers the content of the to-be-filed PCT application, or
• the RO/IB e-filing server is broken.

(In over five years, I have actually never seen the RO/IB e-filing server to be broken.  I only mention this third possible reason out of a desire to be exhaustive in the list of possible reasons.)

Which now brings us to the action step for the USPTO.  What needs to happen now is that the USPTO needs to publish a new Federal Register notice.  The new notice, if translated into plain language, would need to say “you can now disregard that scary notice that we published in 2016.”  Of course no Federal Register notice is ever in plain language.   With that in mind, here is what I suggest for the “cloud removal” Federal Register notice:

It is recalled that the USPTO published a Federal Register notice on May 6, 2016 (81 FR 27417, “the Notice”) warning would-be users of ePCT of the risk of violating US national security laws.  In particular, the notice warned users that either of two actions posed this risk:

• • inserting text into the “abstract” field of the ePCT web user interface, and
  • inserting text into the “title” field of the ePCT web user interface.

It has all along been possible for the would-be user of ePCT to avoid the first of the two risks by simply refraining from inserting any text into the “abstract” field of the ePCT web user interface.  But, until now, the ePCT web user interface displayed an error message in the event that the user failed to insert text into the “title” field of the ePCT web user interface.

A recent change in ePCT offers a radio button captioned “The title is as provided on page 1 of the description”.  If the user of ePCT selects this radio button, then the ePCT system does not require the user to insert any text into the “title” field of the ePCT web user interface.

With this recent change, a would-be user of ePCT may completely avoid any of the risks identified in the Notice.  The would-be user of ePCT may select this radio button and refrain from inserting any text into the “title” and “abstract” fields of the ePCT web user interface, and if so, the user may disregard the warnings given in the Notice.

Users of the PCT system are reminded that there are benefits from the use of ePCT (rather than PCT-SAFE) to prepare a Request and ZIP file for uploading into EFS-Web.  One benefit is that if the filer selects DAS as the way to provide a certified copy of a priority document to the IB, then ePCT will cross-check the priority claim information against information in the WIPO DAS system.  This reduces the risk of an incorrectly typed priority claim.

Another potential benefit is that ePCT, being web-based, is always up to date, while PCT-SAFE can become out of date.  Still another potential benefit is that ePCT offers collaborative workflow functions that are not found in PCT-SAFE, such as shared access to saved submission packages and shared address books.

I hope the USPTO will publish such a “cloud removal” Federal Register notice as soon as possible.