SWORD Fights and String Theory: Part 1

This is the first post in a two-part series of blog posts explaining String Contention Sets, a complex aspect of ICANN’s new gTLD evaluation process.

When the news about the New gTLD Program first broke, before details about the application process and trademark protection mechanisms were widely discussed, many assumed that ICANN would be doling out new top-level domains to the highest bidders through a series of auctions.

Of course, we all know that’s not really the case – in reality, there is only one scenario where two or more gTLD applicants would end up in an auction over an extension, or “string,” as ICANN refers to it. That scenario is if applicants end up in a String Contention Set.

So how do you end up in a String Contention Set, anyway? In the New gTLD Applicant Guidebook, ICANN states that “String contention applies when there is more than one qualified application for the same or similar gTLD strings.” The “same” part is self-explanatory: if I apply for .XYZ and you also apply for .XYZ and we are both deemed to be qualified applicants during the Initial Evaluation, then we will end up in a String Contention Set.

The “similar” part presents a wrinkle, though, both for applicants and for the evaluators ICANN will contract to assess the applications. Because ICANN will accept applications for gTLDs across languages and writing systems, the task of determining whether strings are similar to the point that they will confuse Internet users will be quite challenging. To help expedite the process, ICANN has adopted the SWORD algorithm, which a number of national trademark offices, including the World Intellectual Property Organization, use in connection with trademark prosecution. (Those familiar with UDRP proceedings should be recalling the phrase “identical or confusingly similar” right now.)

Unlike the trademark offices, though, ICANN is focused purely on visual confusion between applied-for strings. In other words, if an Internet user saw the strings written, would he or she think they were the same thing? Focusing on visual similarity also means that ICANN will likely not lump together applications for the same word in different languages: .HOUSE and .CASA mean the same thing but don’t look remotely alike, meaning both strings could coexist (and, most likely, would end up serving different groups of Internet users).

Of course, ICANN quickly learned that, as computers are not infallible, it would need to rely on real, live humans to validate the algorithm. Therefore, any two strings that receive a SWORD score higher than 30 percent will be referred to an expert. What are some pairs of strings that score higher than 30 percent? “Dog” vs. “bog” scores 85 percent, “dog” vs. “bag” scores 50 percent, and “dog” vs. “bad” scores 47 percent. “Dog” vs. “bam,” on the other hand, scores only 16 percent. What we found really interesting was that SWORD rates “sport” and “party” as 54 percent similar.

Ultimately, it will be up to the evaluators and experts contracted by ICANN to determine whether or not two or more strings are similar enough to be placed into a Contention Set. A group called the “String Similarity Panel” will be in charge of reviewing the entire pool of applications to determine if two or more strings are similar enough that they will cause user confusion. The Panel will put strings in “direct contention” – those that are identical or confusingly similar – in a Contention Set. Two or more strings are considered to be in “indirect contention” with each other if they are both/all in direct contention with a third string.

To put it more simply, if String A is in direct contention with String B and String C is also in direct contention with String B, then String A is in indirect contention with String C. “A” and “C” will not end up in a Contention Set, and potentially both could be allowed to proceed. (This is explained further in section 4.1.1 in the Applicant Guidebook.)

The Panel is not the only entity that can put you into a Contention Set, though. Any existing TLD operator (including gTLDs and ccTLDs) or any other gTLD applicant has sufficient standing to file a String Confusion Objection alleging that your applied-for string is confusingly similar to its string. If an existing TLD operator is successful in asserting that your string is confusingly similar to its TLD, your application will be rejected. If another applicant is successful in its assertion, both you and that applicant will be placed into a String Contention Set. (If the applicant is unsuccessful, both applications move forward in the evaluation process.) The International Centre for Dispute Resolution will be tasked with administering String Confusion Objections.

So what happens if you do find yourself in a String Contention Set? Check back with gTLD Strategy tomorrow to find out.