Historical Resolution Tracking Feature » Consideration of Reconsideration Request 16-12: Merck KGaA (.MERCK)
Important note: The explanatory text provided through this database (including the summary, implementation actions, identification of related resolutions, and additional information) is an interpretation or an explanation that has no official authority and does not represent the purpose behind the Board actions, nor does any explanations or interpretations modify or override the Resolutions themselves. Resolutions can only be modified through further act of the ICANN Board.
Consideration of Reconsideration Request 16-12: Merck KGaA (.MERCK)
Whereas, Merck KGaA (Requestor) submitted a community-based application for .MERCK (the Application), which was placed in a contention set with other .MERCK applications.
Whereas, the Requestor participated in Community Priority Evaluation (CPE) and but did not prevail.
Whereas, the Requestor submitted Reconsideration Request 16-12, seeking reconsideration of the CPE report of its Application, and ICANN organization's acceptance of that CPE report.
Whereas, while Request 16-12 was pending, the Board directed ICANN organization to undertake a review of the CPE process (the CPE Process Review). The Board Governance Committee determined that the pending Reconsideration Requests regarding the CPE process, including Request 16-12, would be placed on hold until the CPE Process Review was completed.56
Whereas, on 13 December 2017, ICANN org published three reports on the CPE Process Review (CPE Process Review Reports).
Whereas, on 15 March 2018, the Board passed Resolutions 2018.03.15.08 through 2018.03.15.11, which acknowledged and accepted the findings set forth in the CPE Process Review Reports, declared that the CPE Process Review was complete, concluded that, as a result of the findings in the CPE Process Review Reports, there would be no overhaul or change to the CPE process for this current round of the New gTLD Program, and directed the Board Accountability Mechanism Committee (BAMC) to move forward with consideration of the remaining Reconsideration Requests relating to the CPE process that were placed on hold pending completion of the CPE Process Review.
Whereas, in accordance with Resolutions 2018.03.15.08 through 2018.03.15.11, the BAMC invited the Requestor to submit additional materials and to make a presentation to the BAMC in support of Request 16-12.
Whereas, the Requestor submitted additional materials in support and made a telephonic presentation to the BAMC in support of Request 16-12; the Requestor also submitted a written summary of its telephonic presentation to the BAMC.
Whereas, the BAMC has carefully considered the merits of Request 16-12 and all relevant materials and has recommended that Request 16-12 be denied because the CPE Provider did not violate any established policies or procedure in its evaluation of Criterion 2 and ICANN org's acceptance of the CPE Provider's Report complied with established policies.
Whereas, the Board has carefully considered the BAMC's Recommendation on Request 16-12 and all relevant materials related to Request 16-12 and the Board agrees with the BAMC's Recommendation.
Resolved (2019.01.27.25), the Board adopts the BAMC Recommendation on Request 16-12.
Brief Summary and Recommendation
The full factual background is set forth in the BAMC Recommendation on Request 16-12 (BAMC Recommendation), which the Board has reviewed and considered, and which is incorporated here.
On 14 December 2018, the BAMC evaluated Request 16-12 and all relevant materials and recommended that the Board deny Request 16-12 because the CPE Provider did not violate any established policies or procedure in its evaluation of Criterion 2 and that ICANN organization's acceptance of the CPE Provider's Report complied with established policies.
The Board has carefully considered the BAMC's Recommendation and all relevant materials related to Request 16-12, and the Board agrees with the BAMC's Recommendation.
Issue
The issues are as follows:
Whether the CPE Provider adhered to the Guidebook in its application of Criterion 2, Nexus between Proposed String and Community, in the CPE Report;
Whether ICANN org complied with applicable policies and procedures when it accepted the CPE Report;
Whether ICANN org must disclose documentary information and communications between ICANN org and the CPE Provider relating to the Application; and
Whether the Board complied with applicable Commitments, Core Values, and policies when it acknowledged and accepted the findings set forth in the CPE Process Review Reports.
These issues are considered under the relevant standards for reconsideration requests in effect at the time that Request 16-12 was submitted. These standards are discussed in detail in the BAMC Recommendation.
Analysis and Rationale
The CPE Criteria and Procedures
CPE is a contention resolution mechanism available to applicants that self-designated their applications as community applications.57 The CPE standards and CPE process are defined in Module 4, Section 4.2 of the Applicant Guidebook (Guidebook). Community-based applications that undergo CPE are evaluated by the following criteria: Criterion 1: Community Establishment; Criterion 2: Nexus Between the Proposed String and Community; Criterion 3: Registration Policies; and Criterion 3: Community Endorsement.58 Pursuant to the Guidebook, the sequence of the criteria reflects the order in which those criteria will be assessed by the CPE Provider. To prevail in CPE, an application must receive at least 14 out of 16 points on the scoring of the four criteria, each of which is worth a maximum of four points. An application that prevails in CPE "eliminates all directly contending standard applications, regardless of how well qualified the latter may be."59 CPE is performed by an independent panel composed of two evaluators who are appointed by the CPE Provider.60 A CPE Provider's role is to determine whether the community-based application fulfills the four community priority criteria set forth in Module 4.2.3 of the Guidebook.61
The CPE Provider Adhered to Applicable Policies and Procedures in its Application of Criterion 2.
The Requestor claims that the CPE Provider erred in awarding the Requestor's Application zero out of four points for Criterion 2. Criterion 2 evaluates "the relevance of the string to the specific community that it claims to represent."62 It is measured by two sub-criterion: sub-criterion 2-A-Nexus (worth a maximum of three points); and sub-criterion 2-B-Uniqueness (worth a maximum of one point).63
The CPE Provider Adhered to Applicable Policies and Procedures in its Application of Sub-Criterion 2-A-Nexus.
The Requestor's Application received zero points for sub-criterion 2-A. To obtain three points for sub-criterion 2-A, the applied-for string must "match the name of the community or be a well-known short-form or abbreviation of the community."64 The CPE Provider determined that the Requestor's Application did not satisfy the three point test because the applied-for string does not "match the name of the community as defined in the application, nor is it a well-known short-form or abbreviation of the community."65
For a score of two, the applied-for string should "closely describe the community or the community members, without over-reaching substantially beyond the community."66 It is not possible to obtain a score of one for this sub-criterion. The CPE Provider also found that the Requestor's Application did not satisfy the two-point test because the applied-for string does not "identify…the community as defined in the application."67
The CPE Provider found that
although the string "Merck" matches the name of the community defined in the Application, it also matches the name of another corporate entity known as "Merck" within the US and Canada. This US-based company, Merck & Co., Inc., operates in the pharmaceutical, vaccines, and animal health industry, has 68,000 employees, and had revenue of US$39.5 billion in 2015. It is therefore a substantial entity also known by the name "Merck".68
The CPE Provider therefore determined that the string is "'over-reaching substantially beyond the community'…it defines because the applied-for string also identifies a substantial entity—Merck in the US and Canada—that is not part of the community defined by the applicant."69
The BAMC found that, although the Requestor disagrees with the CPE Provider's conclusion, the Requestor has not identified any policy or procedure that the CPE Provider violated in its determination.70 Nor has the Requestor provided any evidence that the CPE Provider violated any established policy or procedure. The BAMC noted that the Requestor does not deny that the U.S.-based entity is connected to the Requestor's community as defined in the Application; to the contrary, the majority of Request 16-12 is devoted to summarizing the decades-old, contentious legal dispute between the Requestor and the U.S.-based Merck & Co., Inc. (a former subsidiary of the Requestor) over which company may use the name "MERCK" outside the United States.71 As such, the BAMC concluded, and the Board agrees, that the Requestor's substantive disagreement with the CPE Provider's conclusion is not grounds for reconsideration.
Additionally, as reported in the CPE Process Review Scope 2 Report, the CPE Provider acted consistent with the Guidebook in its analysis under sub-criterion 2-A for all the CPEs that were conducted.72
Consideration of the CPE Provider's treatment of the Merck & Co. Application confirms the consistency of the CPE Provider's analysis of sub-criteria 2-A across the board for all CPEs. In the CPE Report on the community-based application filed by Merck & Co., Inc. for the .MERCK gTLD (Merck & Co. CPE Report), the CPE Provider applied the same reasoning to the Merck & Co. Application as the reasoning included in the Requestor's CPE Report: it found that the Merck & Co., Inc.'s applied-for string (.MERCK) substantially over-reaches beyond the community because the Requestor here is "a substantial entity also known by the name 'Merck'" and is not included in the Merck & Co. Application's community definition in its application for .MERCK.73 There, the CPE Provider considered whether the existence of the Requestor should prevent the Merck & Co. Application from receiving any points on the nexus element.74 For that reason, the CPE Provider awarded the Merck & Co. Application zero points on sub-criterion 2-A, just as the CPE Provider did with respect to the Requestor's Application.75
With respect to the Requestor's claim that the size of its community is larger than the community associated with Merck & Co., Inc. and therefore "the string clearly identifies the Requestor"76, the BAMC concluded, and the Board agrees, that this assertion does not show that the CPE Provider failed to adhere to any established policy or procedure in concluding that the string .MERCK over-reaches substantially beyond the community definition in the Requestor's Application. Nor has the Requestor shown that the CPE Provider failed to adhere to any policy or procedure in awarding zero points on the nexus element. Rather, as the BAMC noted, the Guidebook specifically instructs that zero points must be awarded if the string substantially over-reaches beyond the community in the application.
The BAMC determined, and the Board agrees, that the Requestor's suggestion that it should have been awarded more points for sub-criterion 2-A because it "will take all necessary measures, including geo-targeting, to avoid internet access by users in the few territories in which Merck & Co. has trademark rights" does not warrant reconsideration because the Requestor does not point to any policy or procedure indicating that the CPE Provider must (or even should) take geo-targeting considerations into consideration when scoring sub-criterion 2-A. The BAMC notes that no such policy exists under the Guidebook.
With respect to the Requestor's suggestion that the CPE Provider failed to consider evidence of "unlawful intrusion" into its territories and its "illegal use" of the word Merck by Merck & Co., Inc.,77 the BAMC concluded, and the Board agrees, that the CPE Provider was not required to evaluate the decades-long trademark dispute between the Requestor and Merck & Co., Inc.78,79 Accordingly, the CPE Provider did not violate any established policy or procedure in not taking the ongoing legal disputes into consideration, and this argument does not warrant reconsideration. For the same reason, the Board also agrees with the BAMC's conclusion that ICANN org was not required to provide the CPE Provider with information relating to the legal disputes between the Requestor and Merck & Co., Inc. The Requestor does not and cannot identify any policy or procedure obligating ICANN org to provide such information to the CPE Provider.
The Application of Sub-Criterion 2-A is Consistent with Other CPE Reports.
The Requestor asserts that the CPE Provider's analysis of sub-criterion 2-A in the CPE Report is inconsistent with its analysis of the same sub-criterion for the applications for .ECO, .RADIO, .SPA, and .ART, claiming that in each of those cases, the "applicant was awarded three points under the nexus requirement although there were other entities using the same name."80 The BAMC concluded, and the Board agrees, that the Requestor provides no support or additional argument concerning this assertion, and further, the argument is misplaced. As discussed in detail in the BAMC Recommendation and incorporated herein by reference, in each of these cases, the CPE Provider determined that the applied-for string did not match the name of the community, but it identified the community without over-reaching substantially beyond the community.81 By contrast, the CPE Provider concluded that .MERCK did match the name of the community, but it also matched the name of another community, that of US-based Merck & Co., Inc.82 Accordingly, the Board agrees with the BAMC's conclusion that reconsideration is not warranted on this basis because the Requestor has not provided any evidence that the CPE Provider contradicted any established policy or procedure.
The CPE Provider Adhered to Applicable Policies and Procedures in its Application of Sub-Criterion 2-B-Uniqueness.
The BAMC determined, and the Board agrees, that the Requestor has not demonstrated that the CPE Provider violated any policy or procedure in awarding the Requestor's Application zero points for sub-criterion 2-B-Uniqueness. To obtain one point for sub-criterion 2-B, the applied-for string must have no other significant meaning beyond identifying the community described in the application.83 An application that does not qualify for two or three points for sub-criterion 2-A will not qualify for a score of one for sub-criterion 2-B.84 Here, the CPE Provider awarded zero points under sub-criterion 2-B because the applied-for string did not receive a score of two or three on sub-criterion 2-A for the reasons discussed above.85
The Requestor suggests that the CPE Provider should have awarded the Application one point on the uniqueness element because of the Requestor's longstanding and sole use of its community name MERCK.86 Similar to its arguments in sub-criterion 2-A, the Board agrees with BAMC that Requestor's challenge of the CPE Provider's scoring on sub-criterion is based solely on a substantive disagreement with the CPE Provider's conclusions, which is not grounds for reconsideration. The Requestor has failed to show any policy or procedure violation in connection with the CPE Provider's finding that the Application should receive a score of zero points for sub-criterion 2-B.
The CPE Report did not Implicate Due Process Rights.
The Requestor argues that the CPE Provider "failed to take reasonable care" in drafting the CPE Report, "and misapplied standards and policies developed by ICANN in the [Guidebook], resulting in a denial of due process to the Request[o]r."87 The Board agrees with the BAMC that this argument does not warrant reconsideration. For the reasons discussed above and in further detail in the BAMC Recommendation, the Requestor has not demonstrated any failure by the CPE Provider to follow the established policy and procedures for CPE as set forth in the Guidebook. Rather, the Requestor suggests that there should have been a formal appeal process for decisions by ICANN org's third-party service providers, including the CPE Provider, Legal Rights Objection Panels, and String Confusion Panels. The methods for challenging determinations in the course of the gTLD contention resolution process are set forth in the Guidebook, which was developed after extensive community consultation, and adopted by the Board in June 2011.88 The time for challenging the Guidebook has long passed.89
As the BAMC noted, the Guidebook provides a path for challenging the results of the CPE process through ICANN's accountability mechanisms.90 Indeed, the Requestor has exercised this right by invoking the Reconsideration process with Request 16-12.91 Accordingly, the Board finds that because the CPE Provider's application of Criterion 2 to the Application was consistent with the Guidebook, ICANN org's acceptance of the CPE Report was also consistent with applicable policies and procedures, and did not implicate any "due process" violation. The Board further finds that the absence of an appeal mechanism under the Guidebook for the substance of evaluation results does not constitute a due process violation.
The CPE Process Review Supports the Results of the Merck KGaA Application.
The CPE Process Review Scope 2 Report shows that CPE Provider applied the CPE criteria consistently across all CPEs and that there is no evidence that CPE Provider's evaluation process or reports deviated in any way from the applicable guidelines.92 For this additional reason, the BAMC found, and the Board agrees, that the Requestor's argument that the CPE Provider incorrectly applied Criterion 2 does not support reconsideration.
The Requestor argues that the CPE Process Review Scope 2 and 3 Reports are excessively narrow and did not reevaluate the CPE Provider's application of the Nexus criteria or assess the propriety or reasonableness of the research undertaken by the CPE Provider.93 For the reasons set forth in the BAMC Recommendation and incorporated herein by reference, the BAMC concluded, and the Board agrees, that the Requestor's claims do not support reconsideration because the Requestor did not demonstrate that any violation of process or procedure has been violated. (BAMC Recommendation, Pgs. 25-28.)
The Requestor's Request for the Disclosure of Documentary Information is Not Grounds for Reconsideration.
The BAMC determined, and the Board agrees, that the Requestor's request for the disclosure of documentary information between the ICANN org and the CPE provider relating to the Application and CPE Report is not properly made in the context of a reconsideration request, as the Requestor is not asking ICANN org to reconsider Board or staff action or inaction.94 As such, the Board agrees with the BAMC that this is not grounds for reconsideration. To the extent the Requestor wishes to make a request under ICANN's Documentary Information Disclosure Policy (DIDP), the Requestor may do so separately, consistent with the DIDP.95 However, it should be noted that the documentary information that the Requestor seeks was the subject of multiple DIDP Requests and subsequent Requests for Reconsideration, which the Requestor may consider consulting before submitting an additional substantially identical request.96
For the foregoing reasons, the Board concludes that reconsideration is not warranted.
This action is within ICANN's Mission and is in the public interest as it is important to ensure that, in carrying out its Mission, ICANN is accountable to the community for operating within the Articles of Incorporation, Bylaws, and other established procedures, by having a process in place by which a person or entity materially affected by an action of the ICANN Board or Staff may request reconsideration of that action or inaction by the Board. Adopting the BAMC's Recommendation has no financial impact on ICANN and will not negatively impact the security, stability and resiliency of the domain name system.
This decision is an Organizational Administrative Function that does not require public comment.