An update on reverse domain name hijacking
Three recent UDRP cases involving claims of reverse domain name hijacking (RDNH) reveal some of the common motivations behind a panel finding RDNH and how to spot them. An apparent increase in the frequency of RDNH should put Respondents on notice to consider whether a UDRP claim against them constitutes RDNH which Respondents should address in their submissions if they suspect it has occurred. Panellists might otherwise be reluctant to make a finding of RDNH.
Of course, on one reading of the Rules, a panel has the right to look at RDNH even if it is not asked for by the Respondent. So it might be wise for Complainants in complicated or unusual cases to ask themselves “Would a claim for a finding of RDNH be made against me if I start this case and would it be successful?”.
What is reverse domain name hijacking?
The ICANN definition of RDNH can be found here.[1] It is essentially a Complainant abusing the UDRP process to take a domain name opportunistically. RDNH therefore requires bad faith on the part of the Complainant to be evident.
Hijackers will commonly go after valuable domain names in order to sell them on for profit. We also see RDNH occurring when a business relationship has soured, and one partner seeks to go after the company domain name to prevent their partner from retaining the name and its value. Needless to say, RDNH is an ugly business fuelled by bad faith.
Once a panel has declared a finding of RDNH the story ends there. For better or worse, panels do not have jurisdiction to issue sanctions, such as an order for costs or other penalties against Complainants who have abused the UDRP process. However, given the public nature of the decisions, you might say one incurs reputational damage when they become as a known “reverse hijacker”. Still, nothing prevents them from abusing the process again in future.
In Crestron Electronics a fallout between business partners prompted a claim for the company’s domain names. The reason that a claim by one business partner against another often fails, is that the UDRP requires the registration of the domain name to have been made in bad faith – which it naturally wouldn’t have been in the context of two people forming a company together, at least not at the beginning ! The key point is that initial good faith registration cannot be transformed into a bad faith registration merely through the passage of time or even the souring of the relationship. The panel in this case found that there was RDNH because the claim was doomed for lack of evidence, as well as being vexatious.
In Aktsionernoe Obshchestvo, Kontsern Radioelektronnye Tehnologii V. Titan Networks, Domain Hostmaster a Russian electronics company was found to have engaged in RDNH for almost identical reasons, that is to say, bringing a claim which rests entirely on retroactively imputing bad faith without evidence. See the full decision here.
In another case, a large manufacturing company called AVK Group brought a claim for the domain name <avk.com> which it had previously attempted to purchase but never did because the asking price was too high for them. So, AVK then sought to use the UDRP as an alternative, cheaper means of acquiring the domain name. On this point the panel specifically noted the UDRP is “not a cheap alternative to commercial negotiation with legitimate domain name holders”. This case represents one of the most clear-cut examples of an abuse of process you might ever find. Naturally, AVK’s illegitimate commercial intention was sufficient for a finding of RDNH.
Don’t be a victim of RDNH
If , as a Respondent, you suspect that your Complainant opponent in a UDRP claim knows that you have a right or legitimate interest in the domain name; you have recently declined to sell the domain name to them for their asking price; or key factual information is missing from the Complainant’s submission, or put misleading information before the Panel, then it might be worthwhile asking the panel to make a finding of RDNH, i.e.that the claim was brought in bad faith.
[1] See the definition of RDNH in Rule 1 of the Rules and Rule 15(e) for how RDNH works.