Amending a US application that Is the basis of an IR?

A member of the E-Trademarks listserv asked this:

I have never filed via the Madrid Protocol, but I am considering filing one based on a recently filed US application. If the listing of goods in the US application are amended, are the IR and the subsequent designations automatically amended so that the goods are always the same? It would seem weird to have an IR and national designations with a different listing of goods.

Continue reading “Amending a US application that Is the basis of an IR?”

USPTO still an SSL laggard

In August of 2014 I blogged that USPTO needed to implement SSL (“https://”) on all of its public-facing web sites.  I also said that USPTO needed to implement PFS on all of its SSL-enabled web sites.  (SSL and PFS are security features that protect visitors from eavesdropping by third parties around the Internet.)  In that blog article I explained in detail why this is important.  As just one of many examples of why this is important, the way things are now at the USPTO, third parties could eavesdrop and learn what search terms you are using when you search for a patent or a trademark registration.

Ten months have passed.  It is now June of 2015 and USPTO has made no progress on this.  None.  Zip. Every USPTO web site that was vulnerable to this sort of eavesdropping in August of 2014 continues to be vulnerable today in June of 2015.

Now comes a directive from the White House saying the same thing now in June 2015 that I said in August of 2014.  The directive tells all federal agencies that “all publicly accessible Federal websites and web services” must “only provide service through a secure connection” meaning https://.  All agencies, including the USPTO, are required to get this done by December 31, 2016.

Let’s see how promptly the USPTO complies with this directive from the White House.

What’s the Best Practice for 92bis changes?

One of many nice things about the PCT (Patent Cooperation Treaty) system is that you can do one-stop shopping for changes in the bibliographic data.  (In a somewhat similar way, the Madrid Protocol and Hague Agreement systems provide one-stop shopping for assignments and owner address changes.)  By filing a so-called Rule 92bis request, you can update the inventor list, the name of the applicant, and/or addresses and citizenships thereof.

When I say “one-stop shopping” I mean that you do the change once and it covers multiple countries or Offices around the world.  

But there are better and worse ways to carry out your 92bis request, and that’s the point of this blog posting.

Continue reading “What’s the Best Practice for 92bis changes?”

A reminder of an AIA trap for the unwary – “checking the box”

The America Invents Act took effect on September 16, 2012 and on March 16, 2013.  Well over two years ago.  So we don’t have to keep worrying about it nowadays, right?

Wrong, very wrong.  We have to worry about it now even more than ever.

Here’s one example for the practitioner who is asked by foreign counsel to enter the US national phase from a PCT application. Continue reading “A reminder of an AIA trap for the unwary – “checking the box””

Register now for AIPLA PCT Seminar in July

You will recall that last February I told you to save the date for the Nineteenth Annual AIPLA Patent Cooperation Treaty Seminars.  Registration is now open for the Seminars:

  • July 20 and 21 (Monday and Tuesday) in San Francisco
  • July 23 and 24 (Thursday and Friday) in Alexandria, Virginia

The AIPLA PCT Seminars are the best way to learn about the PCT and to bring yourself up to date about recent changes and developments in the PCT.

Registration for the Seminar also entitles you to attend a webinar, at no additional charge, on July 14.  The webinar is a PCT primer, providing an overview of the PCT system and the basics of filing a PCT application.

Continue reading “Register now for AIPLA PCT Seminar in July”

DNSSEC incompetence at GoDaddy

Clipboard01DNSSEC is an important protocol by which DNS zone records are cryptographically signed.  The protocol permits an internet user to be confident that a particular web site is what it purports to be rather than a fake or substitute web site created by an intermeddler or wrongdoer.  The protocol also offers many other benefits too numerous to discuss here in detail.

I use GoDaddy for hosting of this blog and I use GoDaddy to provide DNSSEC protection for the blog.  Unfortunately GoDaddy has implemented DNSSEC in a way that does not work well with the way that it provides blog hosting.  This has led to three intervals in the past year during which the DNSSEC protection did not work for the domain blog.oppedahl.com.  The result has been that some visitors (those whose connection to the Internet is sophisticated enough to make use of the protection offered by DNSSEC) have been unable to visit the blog web site during those intervals.

In technical terms, what GoDaddy has screwed up during those three intervals is that it has stopped providing DS records for blog.oppedahl.com in the oppedahl.com zone file.

It is a big disappointment that GoDaddy did not fix the bug in its implementation of DNSSEC after the first failure, which was about a year ago.  When that first failure happened a year ago, it looks as though GoDaddy fixed the problem manually, by manually re-inserting the all-important DS records into the zone file.  But did not correct the underlying problem, which is that GoDaddy’s DNS setup for blog.oppedahl.com is fragile and breaks at the slightest provocation, like changing some other record in the zone file.

Then around eight months ago some change that should have been harmless led once again to GoDaddy failing to provide DS records for blog.oppedahl.com in the oppedabl.com zone file.  GoDaddy eventually got the DS records back into place, but again apparently only due to some manual update.  GoDaddy’s mistakes in implementing DNSSEC generally remained uncorrected.

Three days ago the fragility of GoDaddy’s implementation of DNSSEC revealed itself again, because once again GoDaddy stopped providing DS records for blog.oppedahl.com.  What’s frustrating with GoDaddy is that when I try to explain the problem (the blog.oppedahl.com subdomain lacks any DS records), the response from the GoDaddy tech support person is the telephone equivalent of a deer in the headlights.

The image above, from VeriSign’s DNS Analyzer, shows that GoDaddy is to blame.

Anyway after something like the fourth call to GoDaddy tech support in three days, I finally reached someone who understood the problem.  And supposedly GoDaddy’s “advanced tech support” will now manually re-insert the missing DS records into the zone file.

Of course what needs to happen is that GoDaddy needs to correct its implementation of DNSSEC so that it handles subdomains (such as blog.oppedahl.com) reliably rather than in a fragile way.

So anyway if you have been unable to reach this blog during the past three days, that’s why.