Every month or so, in recent years, we receive from the USPTO a Notice to File Corrected Application Papers (NTFCAP) in a recently filed patent application that says our drawings are not good enough. What we find to be frustrating and annoying about this is that invariably the application is a continuation or a divisional of an application in which the drawings were good enough. Today I filed a request to have such a Notice withdrawn. Here is what I wrote: Continue reading “Drawings that are good enough and then not good enough”
2020 is a leap year
2020 is a leap year. What got me thinking about this is a sentence that I just wrote in an email message to instructing counsel in Turkey for a US case that our firm is handling:
We now have an Office Action and it is attached. To avoid abandonment a response must be made by February 29, 2020.
Which prompts a discourse on the inadequacy of integers. All but the most diehard blog readers are invited to skip the following. Continue reading “2020 is a leap year”
Listserv update redux
(Update: See a followup message here about a step that you might take to try to get the listservs working for you again.)
(See also I turned on munging.)
(Updated to describe shipment of digital multimeters.)
Readers may recall my recent blog article about woes with outbound emails from our listserv server.
Alert listserv member Diane L. Gardner of Mastermind IP Law P.C. posted this comment to that blog article:
From my IT provider:
They do not have a spf record.
And her IT provider was absolutely right. I had not attended to setting up an SPF record on our new dedicated server. I ought to have done that sooner. Prompted by her posting, we added the SPF record. Here is the record:
v=spf1 +mx +a +ip4:162.213.248.195 ~allWe have sent two of our digital multimeters to Diane — one for her and one for her IT provider. Thanks to both of you!
We also corrected a PTR (reverse DNS lookup) record. The PTR record is “195.248.213.162.in-addr.arpa.” pointing to “server1.oppedahl-lists.com.”.
There’s a chance these two changes might help a little.
We already had and still have a DKIM record. The DKIM record is “server1.oppedahl-lists.com.” pointing to “v=DKIM1; k=rsa; p=[public key]”.
Thanks again to the nice commenter.
If you have stopped receiving listserv postings
(Update: See a followup message here about a step that you might take to try to get the listservs working for you again.)
(Here is an update.)
(See also “I turned on munging“.)
Oppedahl Patent Law Firm LLC sponsors a dozen listservs (email discussion communities) free of charge for the intellectual property community. If you are a subscriber to one or more of the listservs, and if you have stopped receiving the postings, read on.
You can see many of the listservs here. The email discussion communities sponsored free of charge by OPLF include:
- the Patent Cooperation Treaty listserv, for practitioners who use the PCT
- the e-Trademarks listserv, for trademark practitioners
- the Designs listserv, for industrial design and US design patent practitioners
- the Copyright listserv, for copyright practitioners
- the EFS-Web listserv, for US patent practitioners
- the Madrid Protocol listserv, for practitioners who use the Madrid Protocol
- the PAIR listserv, for users of USPTO’s PAIR system
On about November 17, we migrated the listservs from “shared hosting” at our hosting provider to “dedicated hosting”. In the old system, our outbound listserv traffic was commingled with that of the many other customers of our hosting provider who were also being hosted on the particular server that was our “shared server”. (In case it is of interest to you, our traffic came out from IP address 198.54.114.161.) But starting on about November 17, our outbound listserv traffic came out all by itself, not commingled with anybody else’s traffic, from our dedicated server. (In case it is of interest, our traffic now comes out from IP address 162.213.248.195.)
The volume of our outbound email traffic is no greater than before, and the nature and type of our traffic is unchanged from what it was before. But instead of being commingled with outbound email traffic from other entities unrelated to OPLF, it now comes out from an IP address that is not the source of email from anybody other than OPLF.
And starting on about November 18, several email service providers, among them Google, have been randomly blocking lots of our email traffic.
As best I can see, the service providers use some poorly designed AI algorithm. The algorithm notices that email traffic is arriving from a new IP address, and the algorithm notices that multiple email messages from this new IP address have identical content, and then the algorithm in a very mindless way decides to block random messages that arrives from that IP address.
If the decision whether or not to block randomly selected emails were made by an actual human being, things would be different. The human being would see the multiple identical email messages being a very dry discussion of some obscure aspect of the Patent Cooperation Treaty or the Madrid Protocol or the Hague Agreement and would realize that this is not a sales pitch for a cream for dissolving skin moles or a proposal of a way to spirit ten million dollars out of a bank in Nigeria. The human being would notice that each of the listserv messages has an “unsubscribe” link and is emitted from a “Mailman” software system that ensures that email postings only get sent to people who have actually subscribed to the listserv.
But it is clear that these decisions, at Google and at other email service providers, are being made by poorly designed algorithms that do not exercise any such judgment.
I have attempted to contact several of the poorly behaved email service providers, including Google, but I have not been able to reach an actual human being at any of them. And I have not gotten any of them to pay any attention to this problem.
As far as I can see, the only chance of straightening this out is for you, the paying customer of the email service provider, to instruct your email service provider to be smarter. As I describe here, this might be a matter of whitelisting emails that are “From:” particular email addresses in our listserv system. Or it might be a matter of whitelisting emails where the “envelope sender” is “server1.oppedahl-lists.com”. Or it might be a matter of whitelisting emails where the sender is IP address 162.213.248.195. It might be as simple as instructing them to read this blog article.
Your email service provider probably won’t do this because I ask. Probably if they do the right thing it will only be because you ask it to do so.
If you do contact your email service provider and give them instructions, please post a comment below for the benefit of other readers and listserv members. Indeed the accumulated comments might help a decisionmaker at a company like Google to better appreciate what is the right thing to do about this.
How you learn that your case has been accepted into Collaborative Search & Examination?
Readers will recall my article about Super Patents. If you want to try to get a Super Patent, you have to file a PCT application in one of the participating Receiving Offices and you have to select one of the participating International Searching Authorities (ISAs) and you have to file a form requesting acceptance into the Collaborative Search & Examination (CS&A) pilot program. And you have to get incredibly lucky to get one of the very small number of slots open for applicants in this pilot program.
Which raises the very interesting question — if you do all of these things, how do you find out if you got accepted into the pilot program? How do you find out whether your PCT application will receive an International Search Report and Written Opinion that resulted from the collaborative effort of five International Searching Authorities?
Just now I was delighted to learn that one of our firm’s clients got one of the small number of coveted slots in CS&E. But how did we learn this good news? How, as a general matter, does one learn that one has been accepted into this pilot program? Maybe you already knew the answer, but I did not. I was astonished at the answer. Continue reading “How you learn that your case has been accepted into Collaborative Search & Examination?”
Today’s big yellow banner on EFS-Web
Sometimes when USPTO has something very important that it feels customers need to know, it shouts the message with a big yellow banner very prominently on the front page of EFS-Web.
Just checking my calendar here … yes, today’s date is Monday, November 25, 2019. The announcement about EFS-Web being unavailable during the wee hours of Friday, November 8 is now seventeen days out of date.
I wonder how long it will take after this blog post for someone at the USPTO to get that banner (which is dated Wednesday, November 6) aged off the system.
November 28 is a holiday at the USPTO
Thursday, November 28, 2019 will be a federal holiday in the District of Columbia. This means the USPTO will be closed. This means that any action that would be due at the USPTO on November 28 will be timely if it is done by Friday, November 29, 2019.
Be sure to participate in WIPO’s 2019 PCT User Survey
Every two years, WIPO surveys its users. WIPO’s goal is to help determine which areas of the PCT services provided by the International Bureau could be improved. If you would like to make sure that you receive this year’s questionnaire when WIPO has it ready, follow the instructions in this article from the November 2019 PCT Newsletter.
Better to use an RCE or a continuation?
(Revised to include many excellent thoughts from readers.)
One of the nicest things about working with sophisticated patent firms in other countries is that they will ask questions about US practice that make me try to collect my thoughts about particular points of US practice. I have a pending US case that has received an Advisory Action. Instructing counsel, located in Europe, asked just now whether I thought it would be better to file an RCE or a continuation application in that case. In this blog article I will try to list some of the factors that I think might nudge an applicant one way or the other on such a judgment call.
Followup on “why the check box doesn’t work”
Last week I posted a blog article in which I explained that I had figured out why the check box doesn’t work. What USPTO says is that if you check the box, then for the next 24 hours you won’t have to do the two-step authentication. What really happens is that this almost never works. My explanation, as detailed in that blog article, is that there is a sneeze sensor in the software and if you have the bad luck to sneeze before your next login, this negates the effect of checking the box.
What is very sad about this situation with this poorly designed USPTO software is that judging from the reader comments and from other comments that I received privately, my explanation, which was intended to be humorous, was apparently no less plausible than whatever the (unknown to anyone outside of the USPTO) true explanation is. Many people were taken in.
Yes that previous blog article was meant like a sort of April Fool’s Day article.
I dug around in my cookies and I found what I am confident is the cookie that supposedly protects the user from having to do two-factor authentication for 24 hours. Here is an example of such a cookie:
Name: TwoFactorToken
Content:
LhRlmjFejO7oXhVAsL0ALTLakL0uoSU6EfdQF4vUl+VK+++CkALV+TY8/QuRgPUKmcphLj2KU1xKk+qPK6uvJXGVRLyRmF8UmY0CzjKGR7VJeamcI484moLcci/pqI41RVk4fdCJ5BjomIgoidqUP1n7n3XOd7/zhMXPlS1V0kzagVru9JSHfdSZVwUQDf6jDX4oEbDHDSCiaqACeUyxsGEwnY4Kjvv0egb6Wf7Rdq1uGGE8l4co+5EYlaPLBCt18L3ieisrgwMkRLo5pgJu8HQ3XTB+3+VSKU5F0iaYXsrkn5emalQXzqAVr2Ql+YWwyf3s5jaIac1rXngcFxcMXTm0sfsPHUOPKHPTUmbI0=
Domain: .uspto.gov
Path: /
Send for: Secure connections only
Accessible to script: Yes
Created: Monday, November 4, 2019 at 11:06:24 AM
Expires: Tuesday, November 5, 2019 at 11:06:24 AM
The cookie is called “TwoFactorToken”. It expires 24 hours after being set. Any second-level domain within “.uspto.gov” is able to retrieve the cookie. Clearly USPTO encrypts the “content” field. I consider it very likely that the way it works is this.
At the time the user checks the box, the USPTO script interrogates the user’s web browser asking for every possible piece of information that it can extract from the browser. It turns out that any web site can ask your browser for quite a few things:
- your operating system
- your browser
- what browser plugins you have installed
- your display resolution
- your battery level of charge
- whether it is charging or not right now
- your public IP address
The USPTO script might collect all of these things, combine it with the MyUSPTO user ID, generate a nonce, and assemble this into a data bundle. The USPTO script would then encrypt the bundle, or extract a hash of the bundle, or encrypt a hash of the bundle, something like that. And the result is put it into the cookie such as the one quoted above.
Then of course you get a forced logout after 30 minutes. So now it is time to log in again. The USPTO system asks for your user ID and password, and then the USPTO system has to decide whether or not it will force you to go through the two-factor authentication again. So it looks for the TwoFactorToken cookie. If there is no such cookie, then you have to do the two-factor authentication. If there is such a cookie, but it has expired, then you have to do the two-factor authentication. If there is such a cookie and it has not yet expired, then the USPTO system asks your browser for all of these things:
- your operating system
- your browser and browser version
- what browser plugins you have installed
- your display resolution
- your battery level of charge
- whether it is charging or not right now
- your public IP address
The USPTO system also looks to see what your user ID is that you are using to log in, and looks up the nonce that it stored in its local database relating to your user ID. The USPTO then then compares the answer that your web browser gave an hour ago with the answer that your web browser is giving right now.
Common sense tells you that many of these things are very unlikely to have changed during the past hour. Your operating system has probably not been upgraded during that time. Probably you have not updated your browser during that time. Maybe your list of installed plugins has not changed.
But your public IP address might well have changed. This might be because you logged into or out of a VPN. Or you physically moved from a Starbucks to your office. Maybe just moving from one location in your office to another location in your office could lead to your having a different public IP address. Moving from the secure network in your office to a guest network might well lead to a different public IP address.
And common sense tells you, the state of charge of your notebook computer battery is very likely to have changed during that hour. You may have plugged in your charger, or you may have unplugged your charger.
Also consider that you might have changed your screen resolution during that hour. By this we mean the screen resolution for the active window in your browser where the USPTO login was taking place. You might have resized a browser window for example.
Worse yet, suppose the USPTO local database containing your nonce is flaky. Suppose it often fails to respond promptly to a query from the login authentication software? Suppose it sometimes forgets the nonce?
Depending on how poorly the USPTO selected what to load into the cookie, any change to any of the things just mentioned could conceivably make the poorly designed USPTO software decide that you need to log in the hard way again. Maybe your battery ran down a bit during the past hour. Maybe you resized a browser window. Maybe you moved from your office to a Starbucks.
Or depending on how poorly the USPTO designed the local database that stores the nonces, maybe that by itself would explain why the checkbox often fails to work.