Should the UDRP be reformed? Don't go there, says WIPO

The Uniform Dispute Resolution Policy (UDRP) of ICANN, which is binding for all registrars and, by virtue of being incorporated into the domain name registration agreement, on anyone registering a domain name in a generic top level domain (notably .com, .net and .org, the others play a small role), provides since 1999 for a dispute resolution process if a trade mark owner feels that a domain name infringes his rights. Assuming IPKat readers will be roughly familiar with the policy, I shall spare you the details (some background here).

ICANN is cautiously posing the question whether the UDRP should be reformed, and has received a resounding "NO, PLEASE DON'T" from WIPO. The main arguments of WIPO, as summarized in a Webinar held on 10 May 2011, are the following:

• The UDRP has been offering an effective solution for trademark owners, domain name registrants, and registration authorities.
• By accommodating evolving norms and practices, the UDRP has proven to be a flexible and fair dispute resolution system.
• With vast DNS growth around the corner and untested new RPMs in development, the time is wrong to revise the UDRP.
• Institutionally stacked, an ICANN revision process would likely end up overburdening and diluting the UDRP.
• Fundamental questions about the business and DNS beneficiaries of cybersquatting must be addressed before targeting the very mechanism intended to address this practice.

Instead of allowing the UDRP to be placed in the dock, ICANN should first fairly address the following issues:

• the relationship between cybersquatting and the activities, revenues and budgets of DNS actors; the incidence of UDRP cybersquatting findings in relation to wider trademark abuse in the DNS overall, with filed UDRP cases merely representing the tip of the iceberg; and
• the degree of proportionality between trademark rights enforcement and domain name registration opportunities in the DNS.

From the user's side, Aimee Gessner, Senior Trademark Counsel at the BMW Group, adds:

• The real problem is not the UDRP: Other practices since the launch of the UDRP in 1999 have contributed largely in encouraging cybersquatting:
• Domain name tasting
• Increasing domain parking sites / pay per click sites
• Drop-catching
• Use of privacy registration services to hide identities of cybersquatters
• Establishment of bogus “registrars” that have no purpose other than to cybersquat

Summary:
• The UDRP is working fairly and efficiently for its intended purpose
• There are many other causes today for the steady increase in cybersquatting which ICANN should rather review
• Brand owners are concerned at this time with what the expansion of the DNS will cause in terms of cybersquatting and other forms of rights infringement system at such a critical time
• Unwise to review and possibly compromise UDRP system at such a critical time

Attorneys acting for complainants point out that the trade mark owners bear the entire cost of the UDRP system and suggest that a "loser pays" system may be fairer. Respondents warn against further streamlining a system that may cease to be considered fair.

The registrars have some technical issues with the UDRP, notably

• The meaning of “Maintaining the Status Quo” in Section 7 is not clear: No explanation of “Legal Lock” mechanisms and when they go into effect or when they should be removed.
• Policy does not provide guidance on what a registrar is to do if a claim is stayed or suspended: Is the legal lock to be removed or remain in place?
• Policy does not address Privacy and Proxy Registrations or require complaining party to amend complaint once infringing party identified.
• No explanation on what a registrar should do when a UDRP decision conflicts with an injunctive order issued by a of local jurisdiction.

It should be possible to implement these rather technical issues without breaking the system, this Kat thinks. As far as the message of WIPO is concerned, it couldn't be clearer: don't go there (they literally state this in an open letter to ICANN).