Reluctant to migrate from PCT-SAFE to ePCT?

A colleague at a very well known patent firm asks this:

Some of our clients (a few very large, sophisticated patent clients) refuse to let us move from PCT-Safe to ePCT for their matters since they claim the ePCT servers are located outside the US and that, at a minimum, a foreign-filing license would first be required prior to filing.  Do you have any related experiences with clients?  If so, how did you address their concerns?

First let me offer a compliment to those companies.  It is really good that they think about the FFL issue.  A company (or a practitioner) that fails to pay attention to FFL issues can really run into trouble later.

As a reminder, WIPO provides a very helpful resource on national security requirements for patent filings.

First we need to expand on what “move to ePCT” means.

A first part of “move to ePCT” is “use ePCT with every PCT application that you handle, without exception, starting at least as early as the date that the Record Copy reaches the IB from Receiving Office”.  Let’s call this “ePCT file access”.  It is unfortunate if any PCT practitioner fails to use ePCT file access, since there are so many benefits to getting every one of your PCT applications into the PCT system.

So for example the filer that has an invention that was made in the US, the filer that wishes to take the most conservative possible approach to potential FFL, will be conservative in two ways:

  • using PCT-Safe and not ePCT to generate the ZIP file, and
  • e-filing in RO/US and not e-filing in RO/IB.

But even if the filer is conservative in both of these ways, the fact is that the RO/US will transmit the Record Copy to the IB shortly after carrying out the national security review and finding that there is no national security problem.  When the Record Copy gets to the IB, this means that if you wonder how the invention got exported outside of the US, the answer is that the US government did it (not the filer).  If the US government did it, then the export must be okay so far as US national security is concerned.

And, importantly, once the USPTO has transmitted the Record Copy to the IB, then at that point there is no harm or risk (from the US national security point of view) to making full use of ePCT file access.  And I suggest that it is a Best Practice to make full use of ePCT file access on every PCT case for which the Record Copy has reached the IB.  Said differently, the practitioner that fails to make use of ePCT file access is not serving the client as well as he or she could serve the client.

ePCT file access offers many, many benefits:

  • easily generated report fingering any cases with priority documents outstanding
  • easily generated report fingering any cases that are missing the all-important Form PCT/ISA/202
  • automatic calculation of the 30-month date and automatic reminder when that date is imminent
  • automatic calculation of the Demand date (a complicated calculation, as you know) and automatic reminder when that date is imminent
  • automatic calculation of the Article 19 amendment date (also a complicated calculation, as you know) and automatic reminder when that date is imminent
  • super-easy e-filing of changes of bibliographic data under Rule 92bis
  • automatic notification when any new document gets into the file at the IB, for example a third-party submission of prior art to try to kill your PCT application
  • easy e-filing of a Demand even if the IPEA that you have picked is an Office where you don’t know how to e-file things, or cannot e-file things.

There’s just no excuse for passing up the opportunity to draw upon these and many other benefits of ePCT file access.  And in particular, nothing about US foreign filing licenses should hold the practitioner back from making full use of ePCT file access in every case regardless of where the invention was made or any other national security consideration.

There are two more parts of “move to ePCT” which I will now discuss.  Those two more parts are:

  • for a filer that is planning to e-file in EFS-Web, using ePCT rather than PCT-Safe to generate the ZIP file, and
  • using ePCT to e-file directly at RO/IB.

Each of these parts of “move to ePCT” could conceivably raise FFL issues.  So I will discuss them one by one.

For a filer that is planning to e-file in EFS-Web it can be proposed to use ePCT rather than PCT-Safe to generate the ZIP file.  Let’s call this “ePCT ZIP file creation”.

There are several things that we can say about ePCT ZIP file creation.

One important thing about ePCT ZIP file creation is that eventually PCT-Safe will stop being supported.  From that day onward, it will no longer be possible to use PCT-Safe because it will no longer exist.  Given that this is the case, practitioners might as well suck it up and start learning how to use ePCT to create ZIP files.  The practitioner who foot-drags on this will only be postponing the inevitable.

A second important thing about ePCT ZIP file creation is the validations.  PCT-Safe carries out dozens of validations as you construct your PCT Request, and these validations reduce the risk of looking stupid in front of the client and reduce the risk of committing malpractice.  Put plainly, it is tantamount to malpractice for a practitioner to fail to make use of one or another of the WIPO tools (PCT-Safe or ePCT) when constructing a PCT Request.

But while PCT-Safe carries out dozens of validations, ePCT carries out all of those validations but also carries out additional validations.  Yes, there are ways that a practitioner could screw up, when generating a PCT Request, that PCT-Safe will not catch, but ePCT will catch.  Put plainly, the practitioner who uses ePCT rather than PCT-Safe is protected from more kinds of malpractice.

So why exactly is it that any practitioner passes up the opportunity to use ePCT (rather than PCT-Safe) any time the practitioner generates a ZIP file?  Why would any practitioner pass up the chance to be protected against more kinds of malpractice rather than being protected against a smaller number of kinds of malpractice?

There are, I suppose, several possible explanations for an instance of a practitioner passing up the chance to use ePCT to protect against malpractice when generating a ZIP file:

  • Ignorance regarding ePCT generally.  I’d guess that even now in 2018, more than two-thirds of US patent practitioners are ignorant of ePCT generally.
  • Ignorance regarding benefits of using ePCT to generate ZIP files.  I’d guess that as of the present time, more than nine-tenths of US patent practitioners are unaware that ePCT protects against more malpractice risks when generating a ZIP file than does PCT-Safe.
  • Concern about FFL issues.

So let’s talk through the concern about FFL issues.  I will acknowledge that there is an FFL issue with the use of ePCT to generate ZIP files, an issue that USPTO ought to have fixed a long time ago but has failed to fix as of today.  I blogged about this half a year ago.  I invite the reader to go back and re-read that blog article from six months ago.  Briefly and simply put, the concern is that the practitioner who is using ePCT to generate a ZIP file might inadvertently export instructions as to how to construct a nuclear weapon, by pasting an Abstract into the ePCT system.  Yes, maybe the Abstract, in 150 words or less, might reveal some clever new way to make nuclear weapons.

Having said this, let’s remember that many fact patterns avoid any such risk.

Invention not made in the US.  If your invention was not made in the US, then there is no US national-security concern about exporting the invention from the US.  You can freely paste your Abstract into ePCT for the purposes of generating a ZIP file, and it is not a problem.

Invention for which you already have an FFL.  In the vast majority of cases, your PCT application is claiming priority from some earlier patent application.  If the USPTO already granted an FFL in that earlier application, and if the disclosure in the to-be-filed PCT application does not extend substantively beyond the disclosure for which the FFL has already been granted, then you could freely paste your Abstract into ePCT without having to worry about FFL issues.

But let’s suppose you don’t have the “invention not made in the US” way of avoiding trouble.  And let’s suppose that you don’t already have an FFL.  Or let’s suppose that you have an FFL but you fear that there might be a smidgen of additional disclosure in the to-be-filed PCT application that presents an FFL risk.  This might make you nervous about pasting your Abstract into ePCT.

But it turns out that you can avoid even this potential export risk.  The part of ePCT that use use to generate a ZIP file will permit you to proceed and finish the task without uploading the Abstract at all.  Yes, if you don’t have the “not made in the US” escape route, and if you don’t have the “we already have an FFL” escape route, you can just leave the Abstract blank in the ePCT system.  (Make sure to include an Abstract in the PDF that you upload into EFS-Web.)  This avoids the risk of getting in trouble regarding FFLs.

The super super conservative filer will point out that even if you hold back from pasting your Abstract into ePCT, there is still another way to risk committing an illegal export of national security information.  Yes, the super super conservative filer will point out that the mere pasting of the Title into ePCT could conceivably explain to a foreigner how to construct a nuclear weapon.

So if you don’t have the “not made in the US” escape route, and if you don’t have the “we already have an FFL” escape route, then to be super super safe you would not only refrain from pasting the Abstract into ePCT, you would also refrain from pasting the Title into ePCT.

These protective steps (refraining from pasting the Abstract into ePCT, and refraining from pasting the Title into ePCT) should allay any fears regarding using ePCT to generate the ZIP file that is to be uploaded into EFS-Web.

The remaining area of possible concern might be the use of ePCT to e-file directly at RO/IB.

In our office we try to use ePCT to e-file directly in RO/IB whenever we can.  But isn’t this an illegal export from the US?  Well let’s please recall that if the invention was not made in the US, then there is no problem about making an illegal export from the US.  And let’s please recall that we almost certainly already have an FFL from the priority application that we filed earlier in the USPTO.  So unless there is substantive new matter in the to-be-filed PCT application, the FFL from the priority application will make it okay to file in RO/IB.

Many years ago John Hornickel pointed out a reason that I had never thought of, why a smart practitioner might want to make a special point of filing in RO/IB.  Here is what he explained to me …

Suppose your to-be-filed PCT application is in some technology area that has, in the past, sometimes led to foot-dragging at the USPTO regarding the grant of an FFL.  If you are in such a technology area, you might regret filing your PCT application in RO/US.  Let me explain.

Any time you file a patent application in the USPTO (it might be a PCT, or it might be a provisional, or it might be a non-provisional) it undergoes a security review.   Reviewers who work for any of a dozen government agencies review the application.  Any one of those reviewers might flag the application for further review.  If the application gets flagged, then the FFL does not get granted.  Only weeks or months later, maybe the flag will get lifted and the FFL will be granted.

The problem is that the application that gets flagged might be a PCT application.  If it is a PCT application, and if it gets flagged, then the RO/US will hold back from sending the Record Copy to the IB.  (And will hold back from sending the Search Copy to the ISA.)  This delays the all-important ISR/WO.  And if it drags on too long, this can be fatal to the PCT application itself which will eventually be deemed withdrawn for failure to have its Record Copy transmitted to the IB.

The practitioner who wishes to avoid these risks can simply refrain from filing in RO/US.  Instead, the practitioner files in RO/IB.  Before filing in RO/IB the practitioner checks to be sure that either (a) the invention was not made in the US, or (b) the invention already has an FFL from the priority application.  And the e-filing in RO/IB is preferably carried out by means of ePCT.

So this is an example of a situation where the sophisticated PCT applicant may wish to actively make use of ePCT, for purposes of e-filing in RO/IB, to avoid risk of foot-dragging within RO/US due to the technology area involved.

4 Replies to “Reluctant to migrate from PCT-SAFE to ePCT?”

  1. Hi, Carl – I shared this post to my colleagues. We have neither PCT-Safe nor ePCT and I am trying to inform them that since we are starting from scratch, we should definitely go ePCT. Thank you for the very informative post.

    Thank you and regards,

  2. What about the filing fees lost by the U.S. if every PCT filing migrates to ePCT? The US filed 57,840 PCTs since 2018. There is nothing wrong with filing a PCT using PCT Safe and web filing via EFS.

    1. Your question mixes together three different issues.

      One issue is which software to use to generate your ZIP file. And it is better to use ePCT rather than PCT-SAFE to generate your ZIP file. In either case, the only thing that you can do with a ZIP file is upload it to EFS-Web. There is nowhere else that you can send a ZIP file. This means that I strongly disagree with your view that “There is nothing wrong with filing a PCT using PCT Safe and web filing via EFS.” There is much wrong with that filing path because it fails to make use of the many more validations that get carried out if the EFS-Web filing is done with a ZIP file that was created using ePCT.

      The second issue is who gets the filing fees. If you file a PCT application in EFS-Web, only a very small fraction of the fees paid actually go to the USPTO. By far most of the money goes elsewhere, for example to the International Searching Authority and to the International Bureau. Only the Transmittal Fee goes to the USPTO. If the filer happens to be a small entity, the Transmittal Fee is cut in half, down to only $120. if the filer happens to be a micro entity, the Transmittal Fee is cut in half again, down to a mere $60. I can assure you that RO/US loses money every time they touch a PCT application where the filer is a micro entity.

      The remaining issue is which Receiving Office the filer selects. You seem to assume that a decision to use ePCT is the same thing as a decision to use RO/IB. Such is not at all the case. As I described earlier one use of ePCT can be to generate a ZIP file that is used for filing in EFS-Web. But even if the RO that you choose in ePCT happens to be RO/IB, the revenue loss to the USPTO is miniscule, only $240 and perhaps only $120 or even a loss of only $60. This choice of RO might even be a net benefit, money-wise, to the USPTO for a small or micro entity filing given that USPTO probably would have lost money had it carried out the RO/US work for such a filing. Not only that, the filer from the US who files in RO/IB might nonetheless select ISA/US as its ISA, and in that case the USPTO still receives the same searching authority money that it would have received if RO/US had been selected (that is, if EFS-Web had been used).

      Finally you seem to assume that the use of PCT-SAFE entails use of EFS-Web. That is not at all the case. One of the buttons you can click in PCT-SAFE is to tell it to file your PCT application in RO/IB. This is not at all a Best Practice, given that ePCT carries out more validations than PCT-SAFE. But it is nonetheless the case that one of the things you can do with PCT-SAFE is file in RO/IB.

  3. The term “illegal” here needs to be replaced with “very legal”:
    “Well let’s please recall that if the invention was not made in the US, then there is no problem about making an illegal export from the US”
    The use of “export” should also be examined. Is it an export if invented abroad? It is certainly not illegal.

Leave a Reply

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