gTLD	Full Legal Name	E-mail suffix	Detail
.beats	Beats Electronics, LLC	beatsbydre.com	View

29.1 Rights Protection Mechanisms

Beats is firmly committed to the protection of Intellectual Property rights and to implementing the mandatory rights protection mechanisms contained in the Applicant Guidebook and detailed in Specification 7 of the Registry Agreement. .beats recognizes that although the New gTLD program includes significant protections beyond those that were mandatory for a number of the current TLDs, a key motivator for .beatsʹs selection of Neustar as its registry services provider is Neustarʹs experience in successfully launching a number of TLDs with diverse rights protection mechanisms, including many the ones required in the Applicant Guidebook. More specifically, .beats will implement the following rights protection mechanisms in accordance with the Applicant Guidebook as further described below:

-Trademark Clearinghouse: a one-stop shop so that trademark holders can protect their trademarks with a single registration.
-Sunrise and Trademark Claims processes for the TLD.
-Implementation of the Uniform Dispute Resolution Policy to address domain names that have been registered and used in bad faith in the TLD.
-Uniform Rapid Suspension: A quicker, more efficient and cheaper alternative to the Uniform Dispute Resolution Policy to deal with clear cut cases of cybersquatting.
-Implementation of a Thick WHOIS making it easier for rights holders to identify and locate infringing parties

29.1.1 Trademark Clearinghouse Including Sunrise and Trademark Claims

The first mandatory rights protection mechanism (RPM) required to be implemented by each new gTLD Registry is support for, and interaction with, the trademark clearinghouse. The trademark clearinghouse is intended to serve as a central repository for information to be authenticated, stored and disseminated pertaining to the rights of trademark holders. The data maintained in the clearinghouse will support and facilitate other RPMs, including the mandatory Sunrise Period and Trademark Claims service. Although many of the details of how the trademark clearinghouse will interact with each registry operator and registrars, .beats is actively monitoring the developments of the Implementation Assistance Group (IAG) designed to assist ICANN staff in firming up the rules and procedures associated with the policies and technical requirements for the trademark clearinghouse. In addition, .beatsʹs back-end registry services provider is actively participating in the IAG to ensure that the protections afforded by the clearinghouse and associated RPMs are feasible and implementable.

Utilizing the trademark clearinghouse, all operators of new gTLDs must offer: (i) a sunrise registration service for at least 30 days during the pre-launch phase giving eligible trademark owners an early opportunity to register second-level domains in new gTLDs; and (ii) a trademark claims service for at least the first 60 days that second-level registrations are open. The trademark claim service is intended to provide clear noticeʺ to a potential registrant of the rights of a trademark owner whose trademark is registered in the clearinghouse.

.beatsʹs registry service provider, Neustar, has already implemented Sunrise and⁄or Trademark Claims programs for numerous TLDs including .biz, .us, .travel, .tel and .co and will implement the both of these services on behalf of .beats.

29.1.1.1 Neustarʹs Experience in Implementing Sunrise and Trademark Claims Processes

In early 2002, Neustar became the first registry operator to launch a successful authenticated Sunrise process. This process permitted qualified trademark owners to pre-register their trademarks as domain names in the .us TLD space prior to the opening of the space to the general public. Unlike any other Sunrise plans implemented (or proposed before that time), Neustar validated the authenticity of Trademark applications and registrations with the United States Patent and Trademark Office (USPTO).

Subsequently, as the back-end registry operator for the .tel gTLD and the .co ccTLD, Neustar launched validated Sunrise programs employing processes. These programs are very similar to those that are to be employed by the Trademark Clearinghouse for new gTLDs.

Below is a high level overview of the implementation of the .co Sunrise period that demonstrates Neustarʹs experience and ability to provide a Sunrise service and an overview of Neustarʹs experience in implementing a Trademark Claims program to trademark owners for the launch of .BIZ. Neustarʹs experience in each of these rights protection mechanisms will enable it to seamlessly provide these services on behalf of .beats as required by ICANN.

a) Sunrise and .co

The Sunrise process for .co was divided into two sub-phases:

-Local Sunrise giving holders of eligible trademarks that have obtained registered status from the Colombian trademark office the opportunity apply for the .CO domain names corresponding with their marks
-Global Sunrise program giving holders of eligible registered trademarks of national effect, that have obtained a registered status in any country of the world the opportunity apply for the .CO domain names corresponding with their marks for a period of time before registration is open to the public at large.

Like the new gTLD process set forth in the Applicant Guidebook, trademark owners had to have their rights validated by a Clearinghouse provider prior to the registration being accepted by the Registry. The Clearinghouse used a defined process for checking the eligibility of the legal rights claimed as the basis of each Sunrise application using official national trademark databases and submitted documentary evidence.

Applicants and⁄or their designated agents had the option of interacting directly with the Clearinghouse to ensure their applications were accurate and complete prior to submitting them to the Registry pursuant to an optional Pre-validation Process. Whether or not an applicant was pre-validated, the applicant had to submit its corresponding domain name application through an accredited registrar. When the Applicant was pre-validated through the Clearinghouse, each was given an associated approval number that it had to supply the registry. If they were not pre-validated, applicants were required to submit the required trademark information through their registrar to the Registry.
As the registry level, Neustar, subsequently either delivered the:

-Approval number and domain name registration information to the Clearinghouse
-When there was no approval number, trademark information and the domain name registration information was provided to the
Clearinghouse through EPP (as is currently required under the Applicant Guidebook).

Information was then used by the Clearinghouse as either further validation of those pre-validated applications, or initial validation of those that did not go through pre-validation. If the applicant was validated and their trademark matched the domain name applied-for, the Clearinghouse communicated that fact to the Registry via EPP.

When there was only one validated sunrise application, the application proceeded to registration when the .co launched. If there were multiple validated applications (recognizing that there could be multiple trademark owners sharing the same trademark), those were included in the .co Sunrise auction process. Neustar tracked all of the information it received and the status of each application and posted that status on a secure Website to enable trademark owners to view the status of its Sunrise application.

Although the exact process for the Sunrise program and its interaction between the trademark owner, Registry, Registrar, and IP Clearinghouse is not completely defined in the Applicant Guidebook and is dependent on the current RFI issued by ICANN in its selection of a Trademark Clearinghouse provider, Neustarʹs expertise in launching multiple Sunrise processes and its established software will implement a smooth and compliant Sunrise process for the new gTLDs.

b) Trademark Claims Service Experience

With Neustarʹs biz TLD launched in 2001, Neustar became the first TLD with a Trademark Claims service. Neustar developed the Trademark Claim Service by enabling companies to stake claims to domain names prior to the commencement of live .biz domain registrations.

During the Trademark Claim process, Neustar received over 80,000 Trademark Claims from entities around the world. Recognizing that multiple intellectual property owners could have trademark rights in a particular mark, multiple Trademark Claims for the same string were accepted. All applications were logged into a Trademark Claims database managed by Neustar.
The Trademark Claimant was required to provide various information about their trademark rights, including the:

-Particular trademark or service mark relied on for the trademark Claim
-Date a trademark application on the mark was filed, if any, on the string of the domain name
-Country where the mark was filed, if applicable
-Registration date, if applicable
-Class or classes of goods and services for which the trademark or service mark was registered
-Name of a contact person with whom to discuss the claimed trademark rights.

Once all Trademark Claims and domain name applications were collected, Neustar then compared the claims contained within the Trademark Claims database with its database of collected domain name applications (DNAs). In the event of a match between a Trademark Claim and a domain name application, an e-mail message was sent to the domain name applicant notifying the applicant of the existing Trademark Claim. The e-mail also stressed that if the applicant chose to continue the application process and was ultimately selected as the registrant, the applicant would be subject to Neustarʹs dispute proceedings if challenged by the Trademark Claimant for that particular domain name.

The domain name applicant had the option to proceed with the application or cancel the application. Proceeding on an application meant that the applicant wanted to go forward and have the application proceed to registration despite having been notified of an existing Trademark Claim. By choosing to cancel, the applicant made a decision in light of an existing Trademark Claim notification to not proceed.

If the applicant did not respond to the e-mail notification from Neustar, or elected to cancel the application, the application was not processed. This resulted in making the applicant ineligible to register the actual domain name. If the applicant affirmatively elected to continue the application process after being notified of the claimantʹs (or claimantsʹ) alleged trademark rights to the desired domain name, Neustar processed the application.

This process is very similar to the one ultimately adopted by ICANN and incorporated in the latest version of the Applicant Guidebook. Although the collection of Trademark Claims for new gTLDs will be by the Trademark Clearinghouse, many of the aspects of Neustarʹs Trademark Claims process in 2001 are similar to those in the Applicant Guidebook. This makes Neustar uniquely qualified to implement the new gTLD Trademark Claims process.

29.1.2 Uniform Dispute Resolution Policy (UDRP) and Uniform Rapid Suspension (URS)

29.1.2.1 UDRP

Prior to joining Neustar, Mr. Neuman was a key contributor to the development of the Uniform Dispute Resolution Policy (UDRP) in 1998. This became the first Consensus Policy of ICANN and has been required to be implemented by all domain name registries since that time. The UDRP is intended as an alternative dispute resolution process to transfer domain names from those that have registered and used domain names in bad faith. Although there is not much of an active role that the domain name registry plays in the implementation of the UDRP, Neustar has closely monitored UDRP decisions that have involved the TLDs for which it supports and ensures that the decisions are implemented by the registrars supporting its TLDs. When alerted by trademark owners of failures to implement UDRP decisions by its registrars, Neustar either proactively implements the decisions itself or reminds the offending registrar of its obligations to implement the decision.

29.1.2.2 URS

In response to complaints by trademark owners that the UDRP was too cost prohibitive and slow, and the fact that more than 70 percent of UDRP cases were clear cut cases of cybersquatting, ICANN adopted the IRTʹs recommendation that all new gTLD registries be required, pursuant to their contracts with ICANN, to take part in a Uniform Rapid Suspension System (URS). The purpose of the URS is to provide a more cost effective and timely mechanism for brand owners than the UDRP to protect their trademarks and to promote consumer protection on the Internet.

The URS is not meant to address Questionable cases of alleged infringement (e.g., use of terms in a generic sense) or for anti-competitive purposes or denial of free speech, but rather for those cases in which there is no genuine contestable issue as to the infringement and abuse that is taking place.

Unlike the UDRP which requires little involvement of gTLD registries, the URS envisages much more of an active role at the registry-level. For example, rather than requiring the registrar to lock down a domain name subject to a UDRP dispute, it is the registry under the URS that must lock the domain within 24hours of receipt of the complaint from the URS Provider to restrict all changes to the registration data, including transfer and deletion of the domain names.

In addition, in the event of a determination in favor of the complainant, the registry is required to suspend the domain name. This suspension remains for the balance of the registration period and would not resolve the original website. Rather, the nameservers would be redirected to an informational web page provided by the URS Provider about the URS.
Additionally, the WHOIS reflects that the domain name will not be able to be transferred, deleted, or modified for the life of the registration. Finally, there is an option for a successful complainant to extend the registration period for one additional year at commercial rates.

.beats is fully aware of each of these requirements and will have the capability to implement these requirements for new gTLDs. In fact, during the IRTʹs development of f the URS, Neustar began examining the implications of the URS on its registry operations and provided the IRT with feedback on whether the recommendations from the IRT would be feasible for registries to implement.

Although there have been a few changes to the URS since the IRT recommendations, Neustar continued to participate in the development of the URS by providing comments to ICANN, many of which were adopted. As a result, Neustar is committed to supporting the URS for all of the registries that it provides back-end registry services.

29.1.3 Implementation of Thick WHOIS

The .beats registry will include a thick WHOIS database as required in Specification 4 of the Registry agreement. A thick WHOIS provides numerous advantages including a centralized location of registrant information, the ability to more easily manage and control the accuracy of data, and a consistent user experience.

29.1.4 Policies Handling Complaints Regarding Abuse

In addition the Rights Protection mechanisms addressed above, Beats will implement a number of measures to handle complaints regarding the abusive registration of domain names in its TLD as described in .beatsʹs response to Question 28.

29.1.4.1 Registry Acceptable Use Policy

One of the key policies each new gTLD registry is the need to have is an Acceptable Use Policy that clearly delineates the types of activities that constitute abuse and the repercussions associated with an abusive domain name registration. The policy must be incorporated into the applicable Registry-Registrar Agreement and reserve the right for the registry to take the appropriate actions based on the type of abuse. This may include locking down the domain name preventing any changes to the contact and nameserver information associated with the domain name, placing the domain name on hold rendering the domain name non-resolvable, transferring to the domain name to another registrar, and⁄or in cases in which the domain name is associated with an existing law enforcement investigation, substituting name servers to collect information about the DNS queries to assist the investigation. .beatsʹs Acceptable Use Policy, set forth in our response to Question 28, will include prohibitions on phishing, pharming, dissemination of malware, fast flux hosting, hacking, and child pornography. In addition, the policy will include the right of the registry to take action necessary to deny, cancel, suspend, lock, or transfer any registration in violation of the policy.

29.1.4.2 Monitoring for Malicious Activity

.beats is committed to ensuring that those domain names associated with abuse or malicious conduct in violation of the Acceptable Use Policy are dealt with in a timely and decisive manner. These include taking action against those domain names that are being used to threaten the stability and security of the TLD, or is part of a real-time investigation by law enforcement.

Once a complaint is received from a trusted source, third-party, or detected by the Registry, the Registry will use commercially reasonable efforts to verify the information in the complaint. If that information can be verified to the best of the ability of the Registry, the sponsoring registrar will be notified and be given 12 hours to investigate the activity and either take down the domain name by placing the domain name on hold or by deleting the domain name in its entirety or providing a compelling argument to the Registry to keep the name in the zone. If the registrar has not taken the requested action after the 12-hour period (i.e., is unresponsive to the request or refuses to take action), the Registry will place the domain on ServerHold. Although this action removes the domain name from the TLD zone, the domain name record still appears in the TLD WHOIS database so that the name and entities can be investigated by law enforcement should they desire to get involved.

29.2 Safeguards against Unqualified Registrations

IN THE EVENT, .BEATS IS VERIFYING INFORMATION SUPPLIED BY REGISTRANTS TO ENSURE THAT A REGISTRANT IS QUALIFIED TO REGISTER A DOMAIN, INFORMATION FROM THE APPLICANT SHOULD BE INSERTED IN THIS SECTION. IT IS NOT REQUIRED BY ICANN IN ORDER TO SCORE A 1 MEETS REQUIREMENTS, BUT MAY BE REQUIRED TO GET A SCORE OF 2 ON THIS QUESTION. THIS IS NOT PART OF NEUSTARʹS REGISTRY SERVICES OFFERING.

29.3 Resourcing Plans

The rights protection mechanisms described in the response above involve a wide range of tasks, procedures, and systems. The responsibility for each mechanism varies based on the specific requirements. In general the development of applications such as sunrise and IP claims is the responsibility of the Engineering team, with guidance from the Product Management team. Customer Support and Legal play a critical role in enforcing certain policies such as the rapid suspension process. These teams have years of experience implementing these or similar processes.

The necessary resources will be pulled from the pool of available resources described in detail in the response to Question 31. The following resources are available from those teams:

-Development⁄Engineering 19 employees
-Product Management- 4 employees
-Customer Support 12 employees

The resources are more than adequate to support the rights protection mechanisms of the .beats registry.

gTLD	Full Legal Name	E-mail suffix	Detail
.nyc	The City of New York by and through the New York City Department of Information Technology & Telecommunications	neustar.biz	View

29.1. Rights Protection Mechanisms
The City of New York (the City) is firmly committed to the protection of Intellectual Property rights and to implementing the mandatory rights protection mechanisms contained in the Applicant Guidebook and detailed in Specification 7 of the Registry Agreement. The City recognizes that although the New gTLD program includes significant protections beyond those that were mandatory for a number of the current TLDs, a key motivator for .nyc’s selection of Neustar as its registry services provider is Neustar’s experience in successfully launching a number of TLDs with diverse rights protection mechanisms, including many the ones required in the Applicant Guidebook. More specifically, Neustar will implement the following rights protection mechanisms in accordance with the Applicant Guidebook as further described below:
* Trademark Clearinghouse: a one-stop shop so that trademark holders can protect their trademarks with a single registration;
* Sunrise and Trademark Claims processes for the TLD;
* Implementation of the Uniform Dispute Resolution Policy to address domain names that have been registered and used in bad faith in the TLD;
* Uniform Rapid Suspension: A quicker, more efficient and cheaper alternative to the Uniform Dispute Resolution Policy to deal with clear cut cases of cybersquatting;
* Implementation of a Thick WHOIS making it easier for rights holders to identify and locate infringing parties;
* Implementation of a Whois complaint portal by which third parties can submit claims of false or inaccurate Whois data for domain names within the TLD; and
* Implementation of Nexus requirements with both active and passive post registration safeguards to ensure contractual compliance.

A. Trademark Clearinghouse Including Sunrise and Trademark Claims
The first mandatory rights protection mechanism (“RPM”) required to be implemented by each new gTLD Registry is support for, and interaction with, the trademark clearinghouse. The trademark clearinghouse is intended to serve as a central repository for information to be authenticated, stored and disseminated pertaining to the rights of trademark holders. The data maintained in the clearinghouse will support and facilitate other RPMs, including the mandatory Sunrise Period and Trademark Claims service. Although many of the details of how the trademark clearinghouse will interact with each registry operator and registrars has not yet been finalized at the time of this submission, The City actively monitored the developments of the Implementation Assistance Group (“IAG”) designed to assist ICANN staff in firming up the rules and procedures associated with the policies and technical requirements for the trademark clearinghouse. In addition, the City’s Registry Services Provider actively participated in the IAG to ensure that the protections afforded by the clearinghouse and associated RPMs are feasible and implementable.

Utilizing the trademark clearinghouse, all operators of new gTLDs must offer: (i) a sunrise registration service for at least 30 days during the pre-launch phase giving eligible trademark owners an early opportunity to register second-level domains in new gTLDs; and (ii) a trademark claims service for at least the first 60 days that second-level registrations are open. The trademark claim service is intended to provide clear notice to a potential registrant of the rights of a trademark owner whose trademark is registered in the clearinghouse.

As discussed in the City’s response to Question 18, the City will implement the launch of .nyc through a three-phased process. Phase 1 is strictly reserved for governmental entities, City-based non-profits, concessionaries, franchisees and licensees. Each of these entities will be authenticated and validated by the City prior to registration. Phase 2 is reserved for businesses, organizations and legal entities that have a physical address in the City and have paid City taxes within its most recent fiscal year. Finally, Phase 3 will be the final launch phase that commences normal first-come, first-serve operations for all perspective registrants who fulfill the .nyc Nexus Policy.

The .nyc Sunrise Process will coincide with the launch of Phase 2 and will last a minimum of thirty days. During this time period, only those businesses, organizations and other entities qualifying under Phase 2 that hold a trademark registered in the Trademark Clearinghouse in accordance with the final Applicant Guidebook will be allowed to register .nyc domain names. In the event that there are multiple applicants for the same domain name during the Sunrise Period, the City may conduct an auction to determine the registrant of such domain name.

Following the Sunrise Period, the City shall accept all other Phase 2 registrants through a Landrush process described in the City’s response to Question 18. This is also when the City shall begin offering the mandatory Trademark Claims Service. Although ICANN only requires implementation of the Trademark Claims process for sixty-days, the City intends on offering the Trademark Claims service throughout the remainder of Phase 2 as well as the first sixty days of Phase 3 at a minimum. Thus, the City will implement the Trademark Claims service for a minimum of seven or eight months (5-6 months longer than required by ICANN). The City also reserves the right to implement the Trademark Claims process for a longer period of time.

The City’s registry service provider, Neustar, has already implemented Sunrise and⁄or Trademark Claims programs for numerous TLDs including .biz, .us, .travel, .tel and .co and will implement both of these services on behalf of the City for .nyc.

Neustar’s Experience in Implementing Sunrise and Trademark Claims Processes
In early 2002, Neustar became the first registry operator to launch a successful authenticated Sunrise process. This process permitted qualified trademark owners to pre-register their trademarks as domain names in the .us ccTLD prior to the opening of the namespace to the general public. Unlike any other “Sunrise” plans implemented (or proposed before that time), Neustar validated the authenticity of Trademark applications and registrations with the United States Patent and Trademark Office (USPTO).

Subsequently, as the back-end registry operator for the .tel gTLD and the .co ccTLD, Neustar launched validated Sunrise programs employing processes. These programs are very similar to those that are to be employed by the Trademark Clearinghouse for new gTLDs.

Below is a high level overview of the implementation of the .co Sunrise period that demonstrates Neustar’s experience and ability to provide a Sunrise service and an overview of Neustar’s experience in implementing a Trademark Claims program to trademark owners for the launch of .BIZ. Neustar’s experience in each of these rights protection mechanisms will enable it to seamlessly provide these services on behalf of the .nyc gTLD as required by ICANN.

a) Sunrise and .co
The Sunrise process for .co was divided into two sub-phases:
* Local Sunrise giving holders of eligible trademarks that had obtained registered status from the Colombian trademark office the opportunity to apply for the .CO domain names corresponding with their marks
* Global Sunrise program giving holders of eligible registered trademarks of national effect, that had obtained a registered status in any country of the world the opportunity to apply for the .CO domain names corresponding with their marks for a period of time before the registration was open to the public at large.

Like the new gTLD process set forth in the Applicant Guidebook, trademark owners had to have their rights validated by a Clearinghouse provider prior to the registration being accepted by the Registry. The Clearinghouse used a defined process for checking the eligibility of the legal rights claimed as the basis of each Sunrise application using official national trademark databases and submitted documentary evidence.

Applicants and⁄or their designated agents had the option of interacting directly with the Clearinghouse to ensure their applications were accurate and complete prior to submitting them to the Registry pursuant to an optional “Pre-validation Process”. Whether or not an applicant was “pre-validated”, the applicant had to submit its corresponding domain name application through an accredited registrar. When the Applicant was pre-validated through the Clearinghouse, each was given an associated approval number that it had to supply the registry. If they were not pre-validated, applicants were required to submit the required trademark information through their registrar to the Registry.

As the registry level, Neustar, subsequently either delivered the:
* Approval number and domain name registration information to the Clearinghouse
* When there was no approval number, trademark information and the domain name registration information was provided to the Clearinghouse through EPP (as is currently required under the Applicant Guidebook).

Information was then used by the Clearinghouse as either further validation of those pre-validated applications, or initial validation of those that did not go through pre-validation. If the applicant was validated and their trademark matched the domain name applied-for, the Clearinghouse communicated that fact to the Registry via EPP.

When there was only one validated sunrise application, the application proceeded to registration when the .co launched. If there were multiple validated applications (recognizing that there could be multiple trademark owners sharing the same trademark), those were included in the .co Sunrise auction process. Neustar tracked all of the information it received and the status of each application and posted that status on a secure Website to enable trademark owners to view the status of its Sunrise application.

Although the exact process for the Sunrise program and its interaction between the trademark owner, Registry, Registrar, and IP Clearinghouse is not completely defined in the Applicant Guidebook and is dependent on the current RFI issued by ICANN in its selection of a Trademark Clearinghouse provider, Neustar’s expertise in launching multiple Sunrise processes and its established software will implement a smooth and compliant Sunrise process for the .nyc gTLD.

b) Trademark Claims Service Experience
With Neustar’s .biz TLD launched in 2001, Neustar became the first TLD with a Trademark Claims service. Neustar developed the Trademark Claim Service by enabling companies to stake claims to domain names prior to the commencement of live .biz domain registrations.

During the Trademark Claim process, Neustar received over 80,000 Trademark Claims from entities around the world. Recognizing that multiple intellectual property owners could have trademark rights in a particular mark, multiple Trademark Claims for the same string were accepted. All applications were logged into a Trademark Claims database managed by Neustar.

The Trademark Claimant was required to provide various pieces of information about their trademark rights, including the:
* Particular trademark or service mark relied on for the trademark Claim
* Date a trademark application on the mark was filed, if any, on the string of the domain name
* Country where the mark was filed, if applicable
* Registration date, if applicable
* Class or classes of goods and services for which the trademark or service mark was registered
* Name of a contact person with whom to discuss the claimed trademark rights.

Once all Trademark Claims and domain name applications were collected, Neustar then compared the claims contained within the Trademark Claims database with its database of collected domain name applications (DNAs). In the event of a match between a Trademark Claim and a domain name application, an e-mail message was sent to the domain name applicant notifying the applicant of the existing Trademark Claim. The e-mail also stressed that if the applicant chose to continue the application process and was ultimately selected as the registrant, the applicant would be subject to Neustar’s dispute proceedings if challenged by the Trademark Claimant for that particular domain name.

The domain name applicant had the option to proceed with the application or cancel the application. Proceeding on an application meant that the applicant wanted to go forward and have the application proceed to registration despite having been notified of an existing Trademark Claim. By choosing to “cancel,” the applicant made a decision in light of an existing Trademark Claim notification to not proceed.

If the applicant did not respond to the e-mail notification from Neustar, or elected to cancel the application, the application was not processed. This resulted in making the applicant ineligible to register the actual domain name. If the applicant affirmatively elected to continue the application process after being notified of the claimant’s (or claimants’) alleged trademark rights to the desired domain name, Neustar processed the application.

This process is very similar to the one ultimately adopted by ICANN and incorporated in the latest version of the Applicant Guidebook. Although the collection of Trademark Claims for new gTLDs will be by the Trademark Clearinghouse, many of the aspects of Neustar’s Trademark Claims process in 2001 are similar to those in the Applicant Guidebook. This makes Neustar uniquely qualified to implement the new gTLD Trademark Claims process.

B. Uniform Dispute Resolution Policy (UDRP) and Uniform Rapid Suspension (URS)
1. UDRP
Prior to joining Neustar, Mr. Jeff Neuman (VP Business Affairs) was a key contributor to the development of the Uniform Dispute Resolution Policy (“UDRP”) in 1998. This became the first “Consensus Policy” of ICANN and has been required to be implemented by all domain name registries since that time. The UDRP is intended as an alternative dispute resolution process to transfer domain names from those that have registered and used domain names in bad faith. Although there is not much of an active role that the domain name registry plays in the implementation of the UDRP, Neustar has closely monitored UDRP decisions that have involved the TLDs for which it supports and ensures that the decisions are implemented by the registrars supporting its TLDs. When alerted by trademark owners of failures to implement UDRP decisions by its registrars, Neustar either proactively implements the decisions itself or reminds the offending registrar of its obligations to implement the decision.

2. URS
In response to complaints by trademark owners that the UDRP was too cost prohibitive and slow, and the fact that many UDRP cases were “clear cut” cases of cybersquatting, ICANN adopted the IRT’s recommendation that all new gTLD registries be required, pursuant to their contracts with ICANN, to take part in a Uniform Rapid Suspension System (“URS”). The purpose of the URS is to provide a more cost effective and timely mechanism for brand owners than the UDRP to protect their trademarks and to promote consumer protection on the Internet.

The URS is not meant to address Questionable cases of alleged infringement (e.g., use of terms in a generic sense) or for anti-competitive purposes or denial of free speech, but rather for those cases in which there is no genuine contestable issue as to the infringement and abuse that is taking place.

Unlike the UDRP which requires little involvement of gTLD registries, the URS envisages much more of an active role at the registry-level. For example, rather than requiring the registrar to lock down a domain name subject to a UDRP dispute, it is the registry under the URS that must lock the domain within 24hours of receipt of the complaint from the URS Provider to restrict all changes to the registration data, including transfer and deletion of the domain names. In addition, in the event of a determination in favor of the complainant, the registry is required to suspend the domain name. This suspension remains for the balance of the registration period and would not resolve the original website. Rather, the nameservers would be redirected to an informational web page provided by the URS Provider about the URS.

Additionally, the WHOIS reflects that the domain name will not be able to be transferred, deleted, or modified for the life of the registration. Finally, there is an option for a successful complainant to extend the registration period for one additional year at commercial rates. The City is fully aware of each of these requirements and will have the capability to implement these requirements for the .nyc gTLD. In fact, during the IRT’s development of the URS, Neustar began examining the implications of the URS on its registry operations and provided the IRT with feedback on whether the recommendations from the IRT would be feasible for registries to implement.

Although there have been a few changes to the URS since the IRT recommendations, Neustar continued to participate in the development of the URS by providing comments to ICANN, many of which were adopted. As a result, Neustar is committed to supporting the URS for all of the registries that it provides back-end registry services.

C. Implementation of Thick WHOIS
The .nyc registry will include a thick WHOIS database as required in Specification 4 of the Registry agreement. A thick WHOIS provides numerous advantages including a centralized location of registrant information, the ability to more easily manage and control the accuracy of data, and a consistent user experience.

D. Policies for Handling Complaints Regarding Abuse
In addition the Rights Protection mechanisms addressed above, the City will implement a number of measures to handle complaints regarding the abusive registration of domain names within the TLD. Below is a summary of the measures that are more fully described in the City’s response to Question 28.

Registry Acceptable Use Policy
One of the key policies each new gTLD registry requires is the need to have an Acceptable Use Policy that clearly delineates the types of activities that constitute “abuse” and the repercussions associated with an abusive domain name registration. The policy must be incorporated into the applicable Registry-Registrar Agreement and reserve the right for the registry to take appropriate actions based on the type of abuse. This may include locking down the domain name preventing any changes to the contact and nameserver information associated with the domain name, placing the domain name “on hold” rendering the domain name non-resolvable, transferring the domain name to another registrar, and⁄or in cases in which the domain name is associated with an existing law enforcement investigation, substituting name servers to collect information about the DNS queries to assist the investigation. The City’s Acceptable Use Policy, set forth in our response to Question 28, will include prohibitions on phishing, pharming, dissemination of malware, fast flux hosting, hacking, and child pornography. In addition, the policy will include the right of the registry to take action necessary to deny, cancel, suspend, lock, or transfer any registration in violation of the policy.

Monitoring for Malicious Activity
The City is committed to ensuring that those domain names associated with abuse or malicious conduct in violation of the Acceptable Use Policy are dealt with in a timely and decisive manner. These include taking action against those domain names that are being used to threaten the stability and security of the TLD, or is part of a real-time investigation by law enforcement.

Once a complaint is received from a trusted source, third-party, or detected by the Registry, the Registry will use commercially reasonable efforts to verify the information in the complaint. If that information can be verified to the best of the ability of the Registry, the sponsoring registrar will be notified and be given 12 hours to investigate the activity and either take down the domain name by placing the domain name on hold or by deleting the domain name in its entirety or providing a compelling argument to the Registry to keep the name in the zone. If the registrar has not taken the requested action after the 12-hour period (i.e., is unresponsive to the request or refuses to take action), the Registry will place the domain on “ServerHold”. Although this action removes the domain name from the TLD zone, the domain name record still appears in the TLD WHOIS database so that the name and entities can be investigated by law enforcement should they desire to get involved.

29.2 Safeguards against Unqualified Registrations
A. Policies for Handling Complaints Regarding Abuse
1. Whois Accuracy
Neustar will maintain and operate on behalf of the .nyc gTLD a Whois compliance portal through which third parties can submit allegations of accurate or incomplete Whois data. Neustar has first-hand experience implementing a similar reporting mechanism in connection with the .US ccTLD, see http:⁄⁄www.neustar.us⁄whoiscompliance⁄ComplaintMain.jsp. This reporting mechanism WILL incorporate suitable safeguards to ensure that third party complaints are not frivolously submitted, therefore burdening the registry or registrars.

Today most third parties with concerns about inaccurate or incomplete Whois data have only one option, the used of ICANN’s whois report tool which forwards these complaints to the sponsoring registrar, with little or no involvement with the registry. Neustar is proposing to take a much more active role to promote the accuracy and completeness of the Whois data within the .nyc gTLD. Specifically, Neustar itself will forward the information to the sponsoring Registrar, who shall be required to address those complaints with their registrants. Thirty days after forwarding the complaint to the registrar, the Registry will examine the current WHOIS data for names that were alleged to be inaccurate to determine if the information was corrected, the domain name was deleted, or there was some other disposition. If the Registrar has failed to take any action, or it is clear that the Registrant was either unwilling or unable to correct the inaccuracies, Applicant reserves the right to suspend the applicable domain name(s) until such time as the Registrant is able to cure the deficiencies.

2. Nexus Requirements, Monitoring and Enforcement
In addition to the measures to the rights protection mechanisms described above, the City believes that requiring each domain name registrant in .nyc to meet its unique system of Nexus requirements also serves as a rights protection mechanism which will prevent and⁄or mitigate the tendency to have abusive registrations in the .nyc gTLD. In fact, the City’s Nexus policy was developed precisely with this goal in mind. Below is a summary of the Nexus Policy as well as the City’s monitoring and enforcement efforts, which are more fully described in the City’s response to Question 28.

The .nyc Nexus Policy is based on the notion that only those individuals, businesses, organizations or other entities having a substantial and lawful connection to the City be permitted to register for .nyc domain names (“Nexus Policy”). Therefore .nyc Registrants must either be:
(i) a natural person whose primary place of domicile is in the City of New York (“Nexus Category 1”); or

(ii) an entity or organization that has a bona fide presence in the City of New York (“Nexus Category 2”). Factors that should be considered in determining whether an entity or organization has bona fide presence in the City shall include, without limitation whether such prospective registrant:
(A) regularly performs lawful activities within the City related to the purposes for which the entity or organization is constituted (e.g. selling goods or providing services to customers, conducting regular training activities, attending conferences), provided such activities are not conducted solely or primarily to permit it to register for a .nyc domain name; and
(B) maintains an office or other facility in the City for a lawful business, noncommercial, educational or governmental purpose, and not solely or primarily to permit it to register for a .nyc domain name; and;
(C) regularly performs lawful activities outside of the City; provided that such activities relate to, or are primarily directed towards residents, tourists, businesses and organizations within the City (e.g. online content related to the City).

The City will conduct random spot checks of .nyc domain names to determine whether their owners satisfy the applicable Nexus Category. Domains will be manually reviewed for accuracy of the WHOIS information, and any domain found to contain patently inaccurate information or where there is a high likelihood of a nexus violation will be flagged for further investigation. The sponsoring Registrars of these domain names will be notified of the investigation and the registrants will be required to provide additional evidence that they meet the Nexus requirements.

Thirty days after forwarding the complaint to the registrar, the .nyc registry will examine the current WHOIS data for names that were alleged to be inaccurate to determine if the information was corrected, the domain name was deleted, or there was some other disposition. If the Registrar has failed to take any action, or it is clear that the Registrant was either unwilling or unable to correct the inaccuracies, .nyc reserves the right to suspend the applicable domain name(s) until such time as the Registrant is able to cure the deficiencies.

29.3 Resourcing Plans
The rights protection mechanisms described in the response above involve a wide range of tasks, procedures, and systems.  The responsibility for each mechanism varies based on the specific requirements.  In general the development of applications such as sunrise and IP claims is the responsibility of the Engineering team, with guidance from the Product Management team.  Customer Support and Legal play a critical role in enforcing certain policies such as the rapid suspension process.   These teams have years of experience implementing these or similar processes.  

The necessary resources will be pulled from the pool of available resources described in detail in the response to Question 31.  The following resources are available from those teams:
Development⁄Engineering – 19 employees
Product Management- 4 employees
Customer Support – 12 employees

The resources are more than adequate to support the rights protection mechanisms of the .nyc registry.