Módulo 4 Aportes de la comunidad, objeciones y apelaciones

Después del Día de confirmación de las cadenas de caracteres, la comunidad tendrá la oportunidad de brindar aportes de varias maneras durante los plazos y de acuerdo con las pautas descritas en las secciones siguientes.

4.1 Comentarios sobre solicitudes

Los mecanismos para la presentación de comentarios forman parte de los procesos de desarrollo, implementación y funcionamiento de las políticas de la ICANN. La ICANN se compromete a mantener la seguridad y estabilidad operativas de Internet. También pretende fomentar la competencia y garantizar una amplia representación de las comunidades de Internet a nivel mundial. La ICANN elabora políticas adecuadas a su misión mediante procesos ascendentes basados en el consenso. En cumplimiento de estos compromisos, el público tendrá la oportunidad de presentar comentarios sobre las solicitudes publicadas.¹

Los solicitantes y los autores de los comentarios deben saber que los comentarios sobre las solicitudes permiten que el público pueda poner en conocimiento de la ICANN, los solicitantes y los evaluadores información y cuestiones relevantes. Si un comentario es pertinente en relación con criterios de evaluación específicos y no es manifiestamente frívolo, fácticamente engañoso, infundado o vejatorio, podrá tenerse en cuenta en el curso de la evaluación. Si un comentario incluye afirmaciones basadas en hechos concretos, los evaluadores tienen la potestad de verificar estos hechos y pueden solicitar información complementaria al autor del comentario si fuere necesario.

El período de comentarios sobre solicitudes se aplica a todas las solicitudes, incluidas aquellas presentadas por una comunidad. Los comentarios de terceros sobre las solicitudes presentadas por una comunidad deben enviarse antes de que finalice el período de comentarios para que se tengan en cuenta durante la Evaluación con prioridad de la comunidad.²

4.1.1 Cómo presentar comentarios sobre solicitudes

Los comentarios se publicarán en el Foro de comentarios sobre solicitudes (ACF), lo que permitirá a todas las partes interesadas, incluidos los solicitantes, revisar y comentar sobre las solicitudes.

Para presentar un comentario, los participantes deberán tener una cuenta en la ICANN.³ Se pedirá a quienes realicen comentarios que indiquen su afiliación y si tienen relación con algún solicitante o alguna solicitud.⁴ Además, se pedirá a quienes realicen comentarios que especifiquen las solicitudes, cadenas de caracteres, y evaluaciones y procesos específicos a los que se refieren sus comentarios. Se pueden incluir anexos junto con los comentarios.

Si quienes comentan consideran que tienen información relacionada con partes confidenciales de una solicitud que puede no ser pertinente presentar públicamente, pueden optar por presentar un comentario con carácter confidencial. Este comentario confidencial sólo será visible para la ICANN, el solicitante y los evaluadores. Para garantizar la transparencia, esta opción sólo puede utilizarse para comentarios relacionados con partes confidenciales de la solicitud, y la ICANN revisará el comentario antes de hacerlo visible para el solicitante y los evaluadores pertinentes. Si la ICANN determina que el comentario presentado confidencialmente se refiere a partes públicas de la solicitud, el comentario no se aceptará como confidencial y se pedirá al autor del comentario que lo presente públicamente. La ICANN no procesará los comentarios confidenciales recibidos fuera de los períodos de comentarios oficiales.

Toda parte que publique comentarios debe respetar los Términos de servicio de la ICANN.⁵

En el diagrama de flujo que figura a continuación se describe el proceso para los comentarios presentados durante los periodos para comentarios sobre solicitudes, tal como se indica en la Sección 4.1.2 Plazo para comentarios sobre solicitudes.

Figura 4-1: Presentación en el Foro de Comentarios sobre Solicitudes

4.1.2 Plazo para comentarios sobre solicitudes

El ACF permanecerá abierto durante todas las etapas del proceso de evaluación para que el público pueda aportar cualquier información o cuestión pertinente en relación con una solicitud.

4.1.2.1 Plazo para comentarios sobre solicitudes después de la publicación de las solicitudes

La ICANN anunciará la apertura del período de comentarios sobre solicitudes el Día de confirmación de las cadenas de caracteres. Los paneles de evaluación sólo tendrán en cuenta los comentarios sobre solicitudes recibidos durante los 104 días siguientes, salvo circunstancias extraordinarias. La ICANN se reserva el derecho de extender el período de comentarios para una, varias o todas las solicitudes.

Los solicitantes que deseen responder a los comentarios relacionados con su solicitud y asegurarse de que su respuesta esté disponible para los paneles de evaluación pueden hacerlo a través del ACF, dentro de los 30 días siguientes a la finalización del período de comentarios.

4.1.2.2 Plazo para comentarios sobre solicitudes con posterioridad a un pedido de cambios en una solicitud o un pedido de cambios en una cadena de caracteres que representa a una marca

Como se describe detalladamente en la sección 3.8 Pedidos de cambios en una solicitud, los solicitantes pueden pedir que se modifiquen o actualicen sus solicitudes durante las etapas de procesamiento, evaluación y contratación. Los cambios que supongan cambios sustanciales en partes públicas de la solicitud estarán sujetos a un período de comentarios de 30 días, durante el cual la comunidad tendrá la oportunidad de plantear cualquier inquietud que pueda tener sobre los cambios. Un período de 30 días para presentar comentarios sobre solicitudes también se abrirá con posterioridad a un pedido de cambio de una cadena de caracteres que representa a una marca, tal como se indica en la Sección 5.3.3 Solicitudes de cambio de una cadena de caracteres que representa a una marca y aportes de la comunidad. El público general puede optar por recibir una notificación cada vez que se abra un período de comentarios sobre solicitudes con posterioridad a un Pedido de cambios en una solicitud o un Pedido de cambio de una cadena de caracteres que representa a una marca.

4.1.3 Comentarios sobre solicitudes en el proceso de evaluación

La ICANN entregará a los evaluadores los comentarios y respuestas relacionados con las solicitudes que evaluarán. Los paneles de evaluación sólo tendrán en cuenta los comentarios y las respuestas recibidos durante los plazos descritos en la Sección 4.1.2.1 Plazo para comentarios sobre solicitudes después de la publicación de las solicitudes. En caso de que un comentario pueda afectar a una evaluación, se deberá formular una pregunta aclaratoria para dar al solicitante la oportunidad de responder al comentario. Consultar la Sección 5.4 Evaluación con prioridad de la comunidad y el Módulo 7 Procedimientos de evaluación de la cadena de caracteres y solicitudes para más información sobre cómo se integran los comentarios sobre solicitudes en el proceso de evaluación.

4.1.4 Comentarios sobre solicitudes en el proceso de resolución de disputas

Los comentarios sobre solicitudes tienen un papel muy limitado en el proceso de resolución de disputas. Se debería hacer una distinción entre los comentarios sobre solicitudes, que pueden ser relevantes para la tarea de la ICANN de determinar si las solicitudes cumplen los criterios establecidos, y las objeciones, que se tramitan mediante un proceso independiente.⁶

Un Objetor independiente (IO) puede tener en cuenta los comentarios sobre las solicitudes a la hora de realizar una evaluación independiente sobre si una objeción es justificada. El IO sólo podrá presentar una objeción si se ha presentado al menos un comentario en oposición a la solicitud relevante.⁷

4.2 Alertas tempranas de miembros del GAC

Después de que las solicitudes se publiquen en el sitio web del Programa de Nuevos gTLD, ⁸ los miembros y observadores del Comité Asesor Gubernamental (GAC) de la ICANN pueden emitir una Alerta temprana de un miembro del GAC (Alerta temprana) respecto de una solicitud.⁹ Una Alerta temprana indica al solicitante que la solicitud se considera potencialmente sensible o problemática, por ejemplo, por posiblemente infringir la legislación nacional o generar susceptibilidades, que deben especificarse en el aviso de alerta temprana.¹⁰

Las Alertas tempranas de los miembros del GAC deberán presentarse dentro de los 104 días siguientes al Día de confirmación de las cadenas de caracteres, y deberán incluir una explicación por escrito en la que se describa el motivo de la presentación de la Alerta temprana y el modo en que el solicitante puede abordar las inquietudes del miembro del GAC. Los miembros del GAC deben facilitar datos de contacto para comunicarse con el solicitante. La ICANN notificará a los solicitantes las Alertas tempranas tan pronto como sea posible tras su recepción. Se invita a los solicitantes que reciban Alertas tempranas a entablar un diálogo directo con las partes implicadas lo antes posible para abordar las preocupaciones expresadas. No es necesario el consenso del GAC para que se emitan Alertas tempranas.

Una alerta temprana es solo una notificación y no tiene un impacto directo en la solicitud. No obstante, los solicitantes deben tomar con seriedad las Alertas tempranas, ya que indican la posibilidad de que la solicitud sea objeto de un asesoramiento consensuado del GAC.¹¹ o de una objeción.¹² Los paneles de evaluadores pueden considerar las Alertas tempranas. Como parte de una Alerta temprana, un miembro del GAC puede indicar que su preocupación sólo puede resolverse si el solicitante retira su solicitud.

El GAC no ha publicado pautas definitivas sobre lo que constituye una cadena de caracteres sensible. No obstante, durante la Ronda de 2012, el GAC indicó que “las cadenas de caracteres que podrían plantear susceptibilidades incluyen aquellas que 'pretenden representar o que incluyen un grupo particular de personas o intereses sobre la base de componentes de identidad históricos, culturales o sociales, como nacionalidad, raza o etnia, religión, creencia, cultura u origen o grupo social particular, opinión política, pertenencia a una minoría nacional, discapacidad, edad, y/o idioma o grupo lingüístico (no exhaustivo)” y “aquellas cadenas de caracteres que se refieren a sectores particulares, como las que están sujetas a regulaciones nacionales (como .bank, .pharmacy) o las que describen o están dirigidas a una población o industria que es vulnerable al fraude o abuso en línea”.¹³

Durante la Ronda de 2012, el GAC también emitió asesoramiento sobre categorías de cadenas de caracteres que afectaron a varias solicitudes.¹⁴ Si bien esta información se refiere a la Ronda de 2012, los solicitantes pueden tenerla en cuenta a la hora de determinar cómo responder a una Alerta temprana.

Para reducir la posibilidad de recibir una Alerta temprana o un Asesoramiento consensuado del GAC, se invita a todos los solicitantes a identificar las posibles sensibilidades antes de presentar la solicitud y a trabajar anticipadamente con las partes pertinentes para mitigar las inquietudes relacionadas con la solicitud. Si bien una Alerta temprana es un indicador potencial de que una solicitud podría ser objeto de un Asesoramiento consensuado del GAC sobre nuevos gTLD, no es necesaria una Alerta temprana para que el GAC emita un asesoramiento consensuado.

4.2.1 Otros mecanismos para que los miembros del GAC presenten sus inquietudes sobre una solicitud

Si bien el proceso de Alerta temprana está disponible para que los miembros del GAC presenten sus inquietudes sobre una solicitud, no impide que las partes interesadas utilicen otros mecanismos a disposición del público. Estas alternativas incluyen la utilización del Foro de comentarios sobre solicitudes para comunicar inquietudes, o comunicarse directamente con los solicitantes utilizando la información de contacto publicada en la solicitud. Por ejemplo, las partes podrían notificar a los solicitantes que una cadena de caracteres de gTLD solicitada podría contravenir una ley nacional, e intentar resolver cualquier inquietud con el solicitante. No obstante, se debe tener en cuenta que las inquietudes presentadas a través de estos mecanismos no constituyen una Alerta temprana.

4.2.2 Opciones para los solicitantes que reciban alertas tempranas de los miembros del GAC

Tras la recepción de una Alerta temprana, el solicitante que desee seguir adelante con su solicitud podrá reunirse con representantes de la parte o partes afectadas por iniciativa propia o presentar un Pedido de cambios en una solicitud (Sección 3.8) para tratar de resolver las inquietudes.

Los solicitantes también pueden optar por no actuar y continuar con su solicitud tal como está. Aunque, por lo general, se aconseja a los solicitantes a que se pongan en contacto con los miembros pertinentes del GAC para abordar las preocupaciones planteadas; el hecho de no hacerlo puede dar lugar o no a un Asesoramiento consensuado del GAC.

En caso de que un solicitante decida retirar su solicitud tras una Alerta temprana, se aplicará el cronograma de reembolsos indicado en la Sección 3.3 Tarifas y pagos.

4.3 Asesoramiento consensuado del GAC

El proceso de Asesoramiento consensuado del GAC sobre las solicitudes de nuevos gTLD tiene por objeto abordar las solicitudes que se consideren problemáticas, como las que puedan infringir la legislación nacional o plantear susceptibilidades.

4.3.1 Aviso a los solicitantes sobre la recepción del asesoramiento consensuado del GAC

El GAC puede asesorar a la Junta Directiva de la ICANN respecto de cualquier solicitud. Si bien se invita al GAC a que presente su asesoramiento dentro de los 104 días siguientes al Día de confirmación de cadenas de caracteres, para que la Junta Directiva pueda tenerlo en cuenta durante el proceso de evaluación, el GAC se reserva la facultad de presentar el asesoramiento sobre una solicitud o aspecto específico del Programa de Nuevos gTLD en cualquier momento.

El Asesoramiento consensuado del GAC debe indicar claramente que se trata de un Asesoramiento consensuado del GAC, incluir un fundamento bien articulado, limitarse al alcance establecido en las disposiciones aplicables de los Estatutos y detallar cualquier "interacción entre las políticas de la ICANN y las diversas leyes y acuerdos internacionales o los casos en que puedan afectar cuestiones de política pública".

Cuando la Junta Directiva reciba el Asesoramiento consensuado del GAC en relación con una solicitud, la ICANN publicará dicho asesoramiento y notificará a los solicitantes pertinentes.

Tras la notificación a través del TAMS de que una solicitud está sujeta al Asesoramiento consensuado del GAC, el solicitante dispondrá de 21 días para presentar una declaración a la ICANN en respuesta al Asesoramiento consensuado del GAC. Esta declaración se pondrá a disposición de la Junta Directiva y del GAC para su consideración. En su declaración, los solicitantes pueden sugerir modificaciones a la solicitud destinadas a resolver las preocupaciones. Los solicitantes que deseen retirar su solicitud deben consultar la Sección 3.3 Tarifas y pagos para obtener más información sobre el proceso de retiro y el cronograma de reembolsos.

La Junta Directiva considerará el Asesoramiento consensuado del GAC sobre las solicitudes de conformidad con los Estatutos.¹⁵ La Junta Directiva tomará una decisión con respecto al asesoramiento y, en función de ello, la solicitud podrá seguir adelante; seguir adelante con ciertas modificaciones (consultar las secciones 4.3.2 y 4.3.3 a continuación); o no seguir adelante en absoluto.

4.3.2 Asesoramiento consensuado del GAC y pedidos de cambios en una solicitud

Se invita a los solicitantes a analizar soluciones para abordar las cuestiones planteadas en el Asesoramiento consensuado del GAC en relación con una solicitud o cadena de caracteres solicitada (consultar la Sección 7.8.3.2.3.1 Situación 1: Compromisos adquiridos para resolver las objeciones o Asesoramiento consensuado del GAC). Por ejemplo, un solicitante podría considerar la incorporación de los compromisos pertinentes en sus políticas de registro, condiciones de uso o la celebración de un acuerdo independiente con el tercero. No obstante, el solicitante también puede presentar un ACR, que puede incluir la propuesta de agregar, eliminar o modificar Compromisos voluntarios de los operadores de registro (RVC).¹⁶

4.3.3 Asesoramiento consensuado del GAC y Compromisos voluntarios de los operadores de registro

El GAC, en su asesoramiento, podría recomendar a la Junta Directiva que una solicitud no debe proceder a menos que se llegue a un acuerdo sobre un RVC nuevo o modificado que la ICANN apruebe para su inclusión en el Acuerdo de Registro aplicable (consultar la Sección 7.8.3.2.3.1 Situación 1: Compromisos adquiridos para resolver las objeciones o Asesoramiento consensuado del GAC). El solicitante puede optar por resolver la inquietud mediante un RVC en dos casos distintos:

1. RVC existente: Un solicitante considera que un RVC existente en su solicitud aborda las inquietudes planteadas en el Asesoramiento consensuado del GAC. La Junta Directiva determinará si la inquietud del GAC debe ser abordada y si el RVC existente es suficiente.

2. RVC nuevo o modificado: Un solicitante presenta un ACR que incluye la adición de un RVC nuevo o modificado para abordar el asesoramiento consensuado del GAC. Si se acepta el ACR y se aprueba la Evaluación de compromisos de los operadores de registro, la Junta Directiva tendrá en cuenta el RVC nuevo o modificado. La Junta Directiva determinará si debe abordarse la inquietud planteada en el Asesoramiento consensuado del GAC y si el RVC nuevo o modificado aborda dicha inquietud.

4.4 Notificaciones singular/plural

Algunos solicitantes pueden solicitar cadenas de caracteres que, involuntaria o intencionalmente, formen palabras significativas en diferentes idiomas, y estas palabras pueden tener diferentes significados en diferentes idiomas y pueden tener formas singulares y plurales.

Para reducir el riesgo de confusión del usuario final, se prohíbe la delegación de singulares y plurales de la misma palabra en el mismo idioma, siempre que la ICANN reciba una notificación y se determine que la notificación es legítima según los criterios que se indican a continuación.

Esta sección establece las reglas que rigen las cadenas de caracteres que representan formas singulares y plurales de la misma palabra dentro de un mismo idioma, independientemente del idioma pretendido del solicitante.

4.4.1 Requisitos para las notificaciones singular/plural

Cualquier persona, incluso, a modo meramente enunciativo, los solicitantes del Programa de Nuevos gTLD, los operadores de gTLD delegados, los gobiernos y el público en general, puede plantear sus inquietudes sobre cuestiones relativas al singular/plural. Las notificaciones pueden enviarse a través de la página de Notificaciones singular/plural en el sitio web del Programa de Nuevos gTLD.¹⁷ Todas las notificaciones legítimas¹⁸ recibidas se archivarán públicamente.

Cuando se notifique a la ICANN una cuestión de singular/plural, se deberá presentar la siguiente información:

• El fundamento de la notificación, que debe ser uno de los siguientes:

  • La cadena de caracteres de gTLD solicitada que es la forma singular o plural de la misma palabra en el mismo idioma que otra cadena de caracteres solicitada en la misma ronda de solicitudes.

  • La cadena de caracteres de gTLD solicitada que es la forma singular o plural de un gTLD existente, una cadena de caracteres que se está procesando de una ronda anterior de nuevos gTLD o de un nombre bloqueado.

• Referencia a un diccionario, publicado en una fecha que no sea anterior al 1 de enero de 1970. Para todos los idiomas internacionales o nacionales, el diccionario debe ser una obra de referencia publicada y acreditada, elaborada por una editorial o institución de prestigio. Para todos los demás idiomas, el diccionario, si no ha sido elaborado por una editorial o institución de prestigio, debe ser reconocido por la comunidad que utiliza el idioma. Para todos los idiomas, es necesario incluir la siguiente información del diccionario en la notificación a la ICANN:

  • Nombre del diccionario

  • Nombre del idioma

  • Número internacional normalizado del libro (ISBN)

  • Nombre del editor

  • Año y lugar de publicación

  • Número de página en el que se encuentra la palabra

  • Nombre y dirección (física o en línea) donde se puede adquirir el diccionario o una biblioteca pública donde se puede acceder a él para su evaluación.

Para ayudar a la ICANN a verificar la notificación, quien notifica también debe enviar imágenes del ISBN del diccionario, de la portada y de las páginas del pie de imprenta, así como imágenes de las páginas en las que aparece la palabra en cuestión.

Si una notificación a la ICANN carece de alguno de los datos e imágenes requeridos enumerados anteriormente, es posible que la ICANN no pueda verificar la alegación. Esto podría dar lugar a que la cadena de caracteres se procesara sin considerar la cuestión identificada de singular/plural.

La ICANN podrá verificar de forma independiente la autenticidad del material de origen proporcionado.

Si hay dos cadenas de caracteres de gTLD solicitadas que representan palabras que son formas singulares y plurales la una de la otra en el mismo idioma, pero la ICANN no recibe una notificación, ambas cadenas de caracteres seguirán adelante sin ser incluidas en un conjunto de solicitudes controvertidas. Del mismo modo, si una cadena de caracteres solicitada es la forma singular o plural de un TLD delegado, una cadena de caracteres que se está procesando de una ronda anterior de nuevos gTLD o un nombre bloqueado, la solicitud de esa cadena de caracteres de gTLD seguirá adelante a menos que la ICANN reciba una notificación según lo indicado en la Sección 4.4.1 Requisitos para las notificaciones singular/plural.

4.4.2 Período para la presentación de notificaciones singular/plural

El período de notificación singular/plural tendrá lugar durante los 30 días inmediatamente posteriores al Día de confirmación de las cadenas de caracteres. Salvo circunstancias extraordinarias, las notificaciones enviadas a la ICANN fuera del período de notificación singular/plural no serán tenidas en cuenta por la ICANN.

4.4.3 Resultado de las notificaciones singular/plural

Cuando se emite una Notificación singular/plural, hay tres posibles resultados para las solicitudes afectadas, que se describen a continuación:

• Sin impacto en la solicitud: No se confirmó la cuestión de singular/plural.

• Se colocan las cadenas de caracteres en conjunto de solicitudes controvertidas: Si se confirma que una cadena de caracteres de gTLD solicitada representa una palabra que es la versión singular o plural de la misma palabra de otra cadena de caracteres de gTLD solicitada en el mismo idioma, ambas cadenas deberán ponerse en controversia para evitar confusiones al usuario final.

• La solicitud no puede proceder: Si una cadena de caracteres solicitada representa una palabra que es la versión singular o plural de un gTLD delegado, una cadena de caracteres que se está procesando de una ronda anterior de nuevos gTLD o un nombre bloqueado, la solicitud no puede proceder.

Una vez que la ICANN haya revisado los materiales presentados, determinará cómo proceder con las solicitudes pertinentes. El resultado se notificará a los solicitantes y se publicará en las páginas correspondientes al estado de la solicitud.

4.4.4 Impugnación de la evaluación de notificaciones singular/plural

Los solicitantes tienen una única oportunidad de impugnar los resultados de una Notificación singular/plural presentando una solicitud a través del sistema de solicitudes en un plazo de 21 días a partir de la notificación. El solicitante debe presentar todos los hechos necesarios para demostrar el fundamento de su impugnación y no debe utilizarla para modificar sustancialmente su solicitud sustituyendo la información presentada en su solicitud original por información nueva. La ICANN revisará la impugnación.

La revisión determinará si la ICANN cometió un error de hecho o de procedimiento cuando constate que:

1. La cadena de caracteres solicitada por el solicitante es una forma singular o plural de otra cadena de caracteres solicitada.

2. El diccionario presentado para documentar la alegación de singular/plural cumple los criterios establecidos en la Guía.

La impugnación se evaluará en virtud de un estándar de revisión "de error manifiesto". Específicamente, la decisión de la ICANN se mantendrá a menos que:

1. No haya seguido los procedimientos adecuados.

2. No haya considerado ni solicitado las pruebas sustanciales o la información necesarias.

La ICANN comunicará las conclusiones resultantes de la impugnación en un plazo de 30 días a partir de la presentación de dicha impugnación por parte del solicitante.

4.5 Objeciones y apelaciones

El público general, incluidos otros solicitantes, tienen la oportunidad de presentar objeciones a cualquier solicitud y someterlas a la consideración de un panel de expertos cualificados. Para que una objeción sea considerada por un panel, debe ser presentada según fundamentos específicos (consultar la Sección 3.5.1 Fundamentos de una objeción y la parte que presenta la objeción debe tener legitimación (consultar la Sección 4.5.2 Legitimación para objetar). Si una solicitud es objeto de una objeción, el solicitante tendrá la oportunidad de presentar una respuesta. Todos los gTLD solicitados y las cadenas de caracteres variantes asignables solicitadas estarán sujetos a los procesos de objeción. Además, sólo en el caso de las objeciones por confusión de cadenas de caracteres, las cadenas variantes bloqueadas también estarán sujetas a los procesos de objeción.

Por ende, se recomienda a los solicitantes que identifiquen posibles intereses regionales, culturales, de propiedad intelectual u otras cuestiones sensibles en relación con las cadenas de caracteres de gTLD y sus usos antes de presentar la solicitud y, cuando sea posible, que consulten con las partes interesadas para mitigar cualquier inquietud de antemano.

El Programa de Nuevos gTLD incluye mecanismos que permiten a las partes pertinentes apelar una Resolución del Panel de objeción respecto de una objeción (consultar la Sección 4.5.9 Presentación y procesamiento de apelaciones).¹⁹

Al presentar una solicitud o una objeción, el solicitante o el objetor, respectivamente, aceptan la aplicabilidad de la Guía, los procedimientos de la ICANN para presentar y apelar objeciones, y las reglas del DRSP.

Para más información sobre los criterios y procedimientos para presentar y responder a las objeciones y a las apelaciones, así como sobre el proceso de resolución de disputas, consultar esta sección de la Guía y las Reglas de los DRSP relevantes (consultar las Reglas de los Proveedores de Servicio de Resolución de Disputas).

En la siguiente tabla se incluyen las definiciones de los términos que se utilizarán en esta sección.

Tabla 4-1: Definiciones de objeciones y apelaciones

La siguiente tabla presenta una descripción general simplificada para contextualizar las reglas y los procedimientos detallados en esta sección. Para más información y detalles, consultar las secciones de la Guía que figuran a continuación.

Tabla 4-2: Descripción general de los fundamentos de una objeción, partes legitimadas y resultados

4.5.1 Fundamentos de una objeción

Sólo se puede presentar una objeción sobre la base de cuatro fundamentos específicos: confusión de cadenas de caracteres, derechos legales, interés público limitado y la comunidad. Estos fundamentos se describen con más detalle a continuación.

4.5.1.1 Fundamento de la objeción: Confusión de cadenas de caracteres

Una parte legitimada que considere que una cadena de caracteres principal solicitada, sus cadenas variantes asignables o sus cadenas variantes bloqueadas son similares desde el punto de vista visual, auditivo o de significado a un gTLD existente y/o a otra cadena de caracteres principal solicitada y/o a cualquiera de sus cadenas variantes asignables o bloqueadas puede presentar una Objeción por confusión de cadenas de caracteres.

La única excepción es que una cadena de caracteres variante bloqueada no puede alegarse como similar a la cadena variante bloqueada de un gTLD existente o de otra cadena principal solicitada.

Como se mencionó anteriormente, las Objeciones por confusión de cadenas de caracteres pueden presentarse no sólo sobre la base de la similitud visual, sino también de la similitud auditiva y de la similitud de significado, como se describe en la Sección 4.5.10.1 Principios: Confusión de cadenas de caracteres. El objetor debe describir claramente cómo considera que las cadenas de caracteres son similares. Para el caso de similitud visual, el objetor debe remitirse a las pautas para la similitud visual de cadenas de caracteres.

Una Objeción por confusión de cadenas de caracteres puede, si prevalece, cambiar la configuración de los conjuntos de solicitudes controvertidas, dando lugar a que las dos cadenas de caracteres de gTLD solicitadas se consideren en controversia directa entre sí, tal como se describe en el Módulo 5 Resolución de conjuntos de solicitudes controvertidas. El proceso de objeción no dará lugar a la eliminación de una solicitud de un conjunto de solicitudes controvertidas. Si un solicitante considera que su cadena de caracteres solicitada no debería formar parte de un conjunto de solicitudes controvertidas tras la Evaluación de la similitud entre cadenas de caracteres, (consultar la Sección 7.10 Evaluación de la similitud entre cadenas de caracteres), el solicitante tendrá la oportunidad de impugnar dicha resolución, tal como se describe en la Sección 7.10.4 Impugnación de una Evaluación de la similitud entre cadenas de caracteres. Para más información sobre los posibles resultados, consultar la Sección 4.5.8.14 Resolución del Panel.

4.5.1.2 Fundamento de la objeción: Derechos legales

Una parte legitimada que considere que una cadena de caracteres de gTLD solicitada y/o una o más cadenas variantes asignables solicitadas infringen sus derechos legales existentes puede presentar una Objeción por derechos legales. No podrá presentarse una Objeción por derechos legales contra cadenas variantes asignables no solicitadas o cadenas variantes bloqueadas.

4.5.1.3 Fundamento de la objeción: Interés público limitado

Una parte legitimada que considere que la cadena de caracteres de gTLD solicitada y/o una o más cadenas variantes asignables solicitadas son contrarias a las normas jurídicas generalmente aceptadas de moralidad y orden público reconocidas en virtud de los principios del derecho internacional podrá presentar una Objeción de interés público limitado. No podrá presentarse una Objeción de interés público limitado contra cadenas variantes asignables no solicitadas o cadenas variantes bloqueadas.

4.5.1.4 Fundamento de la objeción: La comunidad

Una parte legitimada que considere que existe una oposición bien fundamentada a una cadena de caracteres de gTLD solicitada y/o a una o más cadenas variantes asignables solicitadas por parte de una parte significativa de la comunidad a la que la cadena pueda dirigirse explícita o implícitamente puede presentar una Objeción de la comunidad. No podrá presentarse una Objeción de la comunidad contra cadenas variantes asignables no solicitadas o cadenas variantes bloqueadas.

4.5.2 Legitimación para objetar

Como parte del procedimiento de resolución de disputas, todas las objeciones serán revisadas por un panel de expertos designados por el Proveedor de Servicio de Resolución de Disputas (DRSP) correspondiente para determinar si el objetor está legitimado para objetar. Esta revisión formará parte de la Revisión preliminar (consultar la Sección 4.5.8.7 Revisión preliminar de objeciones). A continuación, se describen los requisitos de legitimación para los cuatro fundamentos de objeción.

4.5.2.1 Legitimación para objetar: Confusión de cadenas de caracteres

El proceso de Objeción por confusión de cadenas de caracteres permite a partes interesadas específicas objetar la posible confusión de cadenas de caracteres, siempre que dicha confusión de cadenas no se haya resuelto ya durante la Evaluación de la similitud entre cadenas de caracteres (consultar la Sección 7.10 Evaluación de la similitud entre cadenas de caracteres). Esto significa que un solicitante no estaría legitimado para objetar otra solicitud con la que ya está en un conjunto de solicitudes controvertidas. Las siguientes entidades pueden presentar una Objeción por confusión de cadenas de caracteres:

Un operador de gTLD existente puede presentar una Objeción por confusión de cadenas de caracteres para afirmar que una cadena de caracteres principal solicitada, una cadena variante asignable de una cadena principal solicitada y/o una cadena variante bloqueada de una cadena de caracteres principal solicitada son similares a su cadena de caracteres de gTLD existente y/o sus cadenas variantes asignables o bloqueadas.

Un operador de ccTLD existente o una Parte con interés significativo ²⁰ en el país o territorio pertinente puede presentar una Objeción por confusión de cadenas de caracteres para afirmar que la cadena principal solicitada, una cadena variante asignable de una cadena principal solicitada y/o una cadena variante bloqueada de una cadena principal solicitada es similar a una cadena de caracteres de ccTLD existente o a sus cadenas variantes asignables o bloqueadas.

Un solicitante²¹ en esta ronda de solicitudes puede presentar una Objeción por confusión de cadenas de caracteres para afirmar que la cadena de caracteres principal solicitada, una cadena variante asignable de una cadena principal solicitada y/o una cadena variante bloqueada de una cadena de caracteres principal solicitada es similar a su cadena de caracteres principal solicitada o a sus cadenas variantes asignables o bloqueadas.

4.5.2.2 Legitimación para objetar: Derechos legales

A continuación, se enumeran las entidades legitimadas para presentar una Objeción por derechos legales:

• Un titular de derechos²² puede tener legitimidad para presentar una Objeción por derechos legales. La fuente y la documentación de los derechos legales existentes que el objetor alega que son infringidos por el gTLD solicitado deben incluirse en la presentación (por ejemplo, documentación relativa a marcas registradas o no registradas). Para más información sobre los derechos legales cubiertos, consultar la Sección 4.5.10.2 Principios: Derechos legales.

• Una organización intergubernamental (OIG) puede presentar una Objeción por derechos legales si cumple los criterios para la registración de un nombre de dominio .INT descritos en las Políticas y procedimientos de la IANA para .INT.²³ También se reconoce que cumplen los criterios los organismos especializados de la ONU y las organizaciones que tienen estado de observador en la Asamblea General de la ONU.

4.5.2.3 Legitimación para objetar: Interés público limitado

Cualquier persona puede presentar una Objeción de interés público limitado. Las Objeciones de interés público limitado sólo pueden presentarse con el fundamento de que la cadena de caracteres correspondiente²⁴ es contraria a las normas jurídicas de moralidad y orden público generalmente aceptadas y reconocidas en virtud de los principios del derecho internacional. Las objeciones presentadas con otros fundamentos serán desestimadas por falta de legitimación.

4.5.2.4 Legitimación para objetar: La comunidad

Las instituciones establecidas asociadas a comunidades claramente definidas pueden presentar una Objeción de la comunidad. La comunidad nombrada por el objetor debe ser una comunidad estrechamente relacionada con la cadena de caracteres de gTLD solicitada en la solicitud objeto de la objeción.

Para contar con la legitimación en una Objeción de la comunidad, el objetor debe demostrar los dos requisitos siguientes:

• Ser una institución establecida. Los factores que pueden considerarse para realizar esta determinación incluyen, entre otros, los siguientes:

  • Nivel de reconocimiento mundial de la institución.

  • Antigüedad de la institución.

  • Pruebas históricas públicas de su existencia, como la presencia de una carta orgánica formal o una inscripción nacional o internacional, o la validación por parte de un gobierno, una organización intergubernamental o un tratado. La institución no debe haberse constituido únicamente en relación con el proceso de solicitud del gTLD.

• Mantener una relación permanente con una comunidad claramente definida. Los factores que pueden considerarse para realizar esta determinación incluyen, entre otros, los siguientes:

  • La presencia de mecanismos de participación en actividades, membresía y liderazgo.

  • Propósito institucional relacionado con el beneficio de la comunidad asociada.

  • Realización de actividades periódicas que beneficien a la comunidad asociada.

  • El nivel de límites formales en torno a la comunidad.

Para tomar su decisión, el panel de resolución de disputas sopesará los factores enumerados anteriormente, así como cualquier otra información pertinente. No se espera que un objetor deba demostrar el cumplimiento de todos y cada uno de los factores considerados para cumplir con los requisitos de legitimación.

4.5.3 Proveedores de Servicio de Resolución de Disputas

Para activar un procedimiento de resolución de disputas, debe presentarse una objeción antes de la fecha límite publicada, directamente ante el DRSP correspondiente para cada fundamento de objeción:

• Confusión de cadenas de caracteres y derechos legales: Organización Mundial de Propiedad Intelectual (OMPI).

• Interés público limitado y la comunidad: Cámara de Comercio Internacional (ICC).

Las reglas de los DRSP, junto con información sobre tarifas y costos, se pueden consultar en el Apéndice 3 Materiales sobre objeciones y apelaciones. Se proporcionará más información al respecto en las páginas específicas de los sitios web del Programa de Nuevos gTLD, ²⁵ la OMPI ²⁶ y la ICC²⁷.

4.5.4 Objetores independientes

Una objeción a una solicitud también puede ser presentada por uno de los tres objetores independientes (IO). Los IO no actúan en nombre de ninguna persona o entidad en particular, sino únicamente en pos del interés del público que utiliza Internet a nivel mundial. El plazo para la presentación de objeciones por parte de los IO comenzará al mismo tiempo que el de las demás partes, pero se prolongará durante siete días adicionales tras la finalización del plazo para la presentación de objeciones por parte del público en general definido en la Sección 4.5.8.1 Plazo para la presentación de objeciones; los IO solo podrán presentar objeciones durante el plazo inicial para la presentación de objeciones. En caso de que sus objeciones no prosperen, los IO podrán apelar las resoluciones pertinentes del Panel.

Para mitigar los posibles conflictos de interés que puedan surgir por el hecho de que un único panelista actúe como IO, la ICANN ha establecido un panel permanente de tres IO. Ni la ICANN ni la Junta Directiva de la ICANN tienen autoridad para ordenar o exigir a los IO que presenten o no una objeción específica.

Si un IO a título individual determina que debe presentarse una objeción, ese IO iniciará y proseguirá la objeción en pos del interés público. El IO puede presentar objeciones contra solicitudes altamente objetables contra las que no se haya presentado ninguna objeción por los mismos motivos, salvo circunstancias extraordinarias.²⁸ El IO puede presentar objeciones contra solicitudes de gTLD que sean ampliamente objetables y respecto de las cuales no se haya presentado ninguna objeción.²⁹

Los IO:

• No objetarán una solicitud a menos que se haya formulado al menos un comentario contrario a la solicitud en la esfera pública, a la luz del objetivo de interés público señalado anteriormente.

• No se considerará su objeción si otra objeción con el mismo fundamento ha superado la Revisión preliminar, salvo circunstancias extraordinarias.³⁰

• Deben tener en cuenta los comentarios de la solicitud al realizar una evaluación independiente sobre si una objeción está justificada. Los IO tendrán acceso a los comentarios sobre las solicitudes recibidos durante el período de comentarios.

4.5.5 Opciones en caso de objeción

Los solicitantes de las solicitudes que son objeto de una objeción tienen las siguientes opciones:

• El solicitante puede ponerse en contacto con el objetor a través del DRSP y trabajar para llegar a un acuerdo con el objetor, tal como se describe en la Sección 4.5.8.11.3 Acuerdo, que puede dar lugar al retiro de la objeción o de la solicitud.³¹

• El solicitante puede presentar una respuesta a la objeción dentro del plazo establecido, tal como se especifica en la Sección 4.5.8.9 Respuesta a una objeción, y entrar en el proceso de resolución de disputas.

• El solicitante puede optar por retirar la solicitud, en cuyo caso el objetor prevalecerá por defecto y la solicitud no seguirá adelante.³²

Si, por cualquier motivo, el solicitante no presenta una respuesta a una objeción dentro del plazo establecido, el objetor prevalecerá por defecto.

Un solicitante que sea objeto de una Objeción por confusión de cadenas de caracteres que alegue que la cadena o cadenas en cuestión son similares a otra cadena de caracteres solicitada puede decidir aceptar que su cadena o cadenas se coloquen en un conjunto de solicitudes controvertidas y no avanzar en el procedimiento de objeción mediante la no presentación de una respuesta. En tal caso, se recomienda expresamente al solicitante que informe al DRSP lo antes posible en el proceso para que pueda resolverse la objeción e informarse a todas las partes.

4.5.6 Costos de las objeciones y apelaciones

Los procedimientos de objeción y apelación requerirán que se presenten diferentes pagos directamente a los DRSP en diferentes momentos. Las instrucciones, así como los importes, se indican en las respectivas Reglas del DRSP.

• Tarifas de presentación

  • El objetor pagará una tarifa de presentación en el momento de presentar su objeción. En caso de que el objetor no abone la tarifa según lo descrito en las respectivas Reglas del DRSP, la objeción será desestimada. La tarifa de presentación de objeciones no se reembolsará en ningún caso.

  • El objetado (que también es el solicitante) pagará una tarifa de presentación en el momento de presentar su respuesta a la objeción. En caso de que el objetado no abone la tarifa según lo descrito en las respectivas Reglas del DRSP, prevalecerá el objetor. La tarifa de presentación de respuesta no se reembolsará en ningún caso.

  • Si se presenta una apelación a una Resolución del Panel de objeción, el apelante pagará una tarifa de presentación en el momento de presentar su apelación ante el DRSP. En caso de que el apelante no abone la tarifa tal como se describe en las respectivas Reglas del DRSP, la apelación se desestimará sin perjuicio alguno. La tarifa de presentación de apelación no se reembolsará en ningún caso.

  • El apelado pagará una tarifa en el momento en que responda a la apelación. En caso de que el apelado no abone la tarifa tal como se describe en las respectivas Reglas del DRSP, se desestimará la respuesta.

• Pago anticipado: Ambas partes de una objeción o apelación realizarán un pago anticipado, según las instrucciones del DRSP, si la objeción o apelación pertinente supera la Revisión preliminar. Puede tratarse de una tarifa por hora basada en el número estimado de horas que el panel dedicará al caso (incluidas la revisión de las presentaciones, la facilitación de una audiencia, si se permite, y la elaboración de una decisión), o de un importe fijo. En los casos en que las disputas se consoliden y haya más de dos partes implicadas, el pago anticipado se realizará de acuerdo con las respectivas Reglas del DRSP. A la parte vencedora en una objeción o apelación se le reembolsará el pago anticipado (no la tarifa de presentación), mientras que la parte no vencedora no recibirá reembolso alguno y, por lo tanto, correrá con los gastos del procedimiento. En los casos en que las objeciones o apelaciones se consoliden y haya más de dos partes implicadas, el reembolso de los costos se producirá de acuerdo con las Reglas del DRSP. En caso de que ninguna de las partes realice el pago anticipado, se desestimará la objeción o apelación.

• Costos adicionales: En circunstancias extraordinarias, el DRSP podrá exigir el pago de costos adicionales como parte del proceso de objeción o apelación. En caso de que una de las partes no efectúe el pago adicional tal como se describe en las respectivas Reglas del DRSP, prevalecerá la otra parte y se le reembolsará el pago anticipado. En caso de que ninguna de las partes realice el pago anticipado, se desestimará la objeción o apelación.

4.5.7 Posibilidades de financiación para objeciones y apelaciones

Para apoyar el modelo de múltiples partes interesadas, la ICANN ofrece ciertas posibilidades de financiación al Comité Asesor At-Large (ALAC) y a los gobiernos nacionales, como se describe a continuación. Dicha financiación se destina a cubrir los costos pagaderos al DRSP y efectuados directamente a éste, es decir, las tarifas de presentación y el pago anticipado de los costos, tal como se describe en la Sección 4.5.6 Costos de las objeciones y apelaciones; no cubre otros costos como los honorarios por asesoramiento legal. Se publicará más información en la página web de objeciones y apelaciones del sitio web del Programa de Nuevos gTLD.³³

• La financiación del ALAC está supeditada a la publicación por parte del ALAC de su proceso aprobado para la consideración y formulación de objeciones. Como mínimo, el proceso de objeción a una solicitud requerirá:

  • desarrollo ascendente de posibles objeciones,

  • debate y aprobación de las objeciones a nivel de la Organización Regional At-Large (RALO), y

  • un proceso de consideración y aprobación de la objeción por parte del Comité Asesor At-Large.

El procedimiento del ALAC para la presentación de comentarios y objeciones durante el Programa de Nuevos gTLD: Ronda de 2026 se puede consultar en https://icann-community.atlassian.net/wiki/x/DwBAD.

• La financiación de la ICANN está a disposición de los gobiernos nacionales individuales para una objeción y una apelación.

4.5.8 Presentación y procesamiento de objeciones

La información que figura a continuación ofrece una descripción general del proceso por el cual los objetores pueden presentar objeciones y los objetados responder a ellas, así como el proceso por el que los DRSP administran los procedimientos de disputas que se han iniciado. Para más información, consultar el Procedimiento de objeción de la ICANN. En caso de discrepancia entre la información presentada en este módulo y el procedimiento, prevalecerá el procedimiento. También deben seguirse las reglas y procedimientos de cada DRSP específico para cada fundamento de objeción, que se publican en las Reglas de los Proveedores de Servicio de Resolución de Disputas.

4.5.8.1 Plazos para la presentación de objeciones

El público general, siempre que tenga legitimación, tal y como se describe en la Sección 4.5.2 Legitimación para objetar, tendrá la oportunidad de presentar objeciones durante los siguientes plazos:

• Durante 104 días, para todos los fundamentos de objeción, a partir del anuncio en el Día de confirmación de las cadenas de caracteres.³⁴

• Durante 30 días, sólo para confusión de cadenas de caracteres, tras la publicación actualizada de los conjuntos de solicitudes controvertidas, tras la conclusión de la Evaluación de la cadena de caracteres.

• Durante 30 días, para todos los fundamentos de Objeción, en caso de cambio de cadena de caracteres que representa a una marca, a partir del día en que se publiquen los Informes de evaluación de la cadena de caracteres, y solo si la evaluación de la cadena es satisfactoria.³⁵

Para más información consultar la Sección 1.2 Etapas de la solicitud y la Sección 5.3 Solicitudes de cambios de cadenas de caracteres que representan a una marca.

4.5.8.2 Presentación de una objeción

Cualquier parte que desee presentar una objeción a una solicitud deberá seguir los procedimientos descritos en esta subsección.

• Todas las objeciones deben presentarse electrónicamente ante el DRSP correspondiente antes de la fecha límite publicada. Los DRSP no aceptarán objeciones después de esta fecha.

• Todas las objeciones deben presentarse en inglés.

• Cada objeción debe presentarse por separado. Un objetor que desee objetar varias solicitudes deberá presentar una objeción separada y abonar las tarifas de presentación correspondientes por cada solicitud objeto de objeción, a menos que el objetor presente varias objeciones contra solicitudes para la misma cadena de caracteres. Si un objetor desea objetar una solicitud por más de un fundamento, deberá presentar objeciones separadas y abonar las tarifas de presentación correspondientes por cada fundamento de objeción.

• Las objeciones se limitan a 5 000 palabras, sin incluir los anexos.

• Un objetor debe proporcionar al solicitante copias de todas las presentaciones al DRSP relacionadas con el procedimiento de objeción.

Cada objeción debe incluir:

• El nombre y los datos de contacto del objetor.

• Una declaración del fundamento de la legitimación del objetor; es decir, por qué el objetor cree que cumple los requisitos de legitimación para objetar.

• Una descripción de los fundamentos de la objeción, que incluya:

  • Una declaración en la que se indique el fundamento específico por el que se presenta la objeción.

  • Una explicación detallada de la validez de la objeción y de por qué debe mantenerse.

• Copias de cualquier documento que el objetor considere que fundamenta su objeción.

En el momento de presentar una objeción, el objetor debe abonar una tarifa de presentación por el importe fijado y publicado por el DRSP correspondiente.³⁶ Si la tarifa de presentación no es abonada dentro de un término de 10 días a partir de la recepción de la Objeción, el DRSP desestimará la Objeción sin perjuicio alguno.

Si una parte legitimada desea presentar una Objeción por confusión de cadenas de caracteres contra una solicitud de una cadena de caracteres que han solicitado varios solicitantes, podrá presentar una objeción contra una, algunas o todas las solicitudes de esa cadena de caracteres. Si la objeción se presenta contra varias solicitudes para una cadena de caracteres idéntica, cada solicitante que reciba una objeción podrá presentar una respuesta a la objeción; si un solicitante no lo hace, la objeción se mantendrá contra esas solicitudes para las cuales no se presentó una respuesta. El mismo panel revisará toda la documentación asociada a la objeción y cada respuesta se revisará en función de sus méritos propios. El panel emitirá una única resolución en la que se identificarán las partes que prevalecen en la objeción, cuando corresponda.

4.5.8.3 Revisión administrativa de la objeción

Cada DRSP llevará a cabo una revisión administrativa de cada objeción para comprobar el cumplimiento de todas las reglas de procedimiento en un plazo de 14 días a partir de la recepción de la objeción y las tarifas de presentación. En función de la cantidad de objeciones recibidas, el DRSP podrá solicitar a la ICANN una breve extensión de este plazo. La revisión administrativa incluye la decisión de si la objeción se presentó ante el DRSP correcto.

Los posibles resultados de la revisión administrativa se describen a continuación:

• Si el DRSP considera que la objeción cumple con el procedimiento y las reglas aplicables del DRSP, la objeción se considerará presentada y el procedimiento continuará.

• Si el DRSP considera que la objeción no cumple con las reglas de procedimiento, lo notificará al objetor, quien dispondrá de cinco días para rectificar las cuestiones identificadas.

  • Si el objetor rectifica las cuestiones dentro del plazo especificado, la objeción se considerará presentada.

  • Si el objetor no rectifica las cuestiones en el plazo especificado, la objeción será desestimada.

4.5.8.4 Publicación y notificación de la objeción

El DRSP publicará y actualizará periódicamente en su sitio web una lista en la que se identifiquen todas las objeciones que hayan superado la revisión administrativa, y lo notificará a la ICANN. A continuación, la ICANN publicará en el sitio web del Programa de Nuevos gTLD³⁷ un aviso con todas las objeciones que superen la revisión administrativa. Una vez que se ha notificado al solicitante que se ha presentado una objeción contra su solicitud, este puede decidir retirar su solicitud de nuevo gTLD, en cuyo caso, se desestimará la objeción.

4.5.8.5 Consolidación de objeciones por parte del DRSP

Cualquiera de las partes podrá proponer la consolidación de las objeciones en un plazo de siete días a partir de la publicación de las mismas; el DRSP dispondrá de siete días adicionales para proponer la consolidación a las partes pertinentes. El DRSP tendrá la facultad de decidir si acepta la propuesta presentada por las partes.

A la hora de evaluar si procede unificar las objeciones, el DRSP sopesará la eficiencia en tiempo, dinero, esfuerzo y coherencia que puede obtenerse con la consolidación frente a los perjuicios o inconvenientes que la consolidación pueda causar. Los DRSP procurarán que todas las objeciones se resuelvan en un plazo similar. Se pretende no establecer ningún orden de prioridad de objeciones.

Si el DRSP propone consolidar determinadas Objeciones, las Partes dispondrán de siete días tras recibir la notificación de consolidación para presentar al DRSP cualquier inquietud que puedan tener sobre la consolidación propuesta. El DRSP considerará la presentación de las partes y decidirá si consolida o no las objeciones. El DRSP informará a las partes de la decisión final sobre la consolidación en un plazo de 28 días a partir de la publicación de las objeciones.

4.5.8.6 Designación del Panel de objeción

El DRSP designará un panel para cada objeción que supere la revisión administrativa. Las partes en un procedimiento tendrán la oportunidad de acordar mutuamente un panel compuesto por una persona o por tres personas, en cuyo caso los costos se repartirán según lo descrito en la Sección 4.5.6 Costos de objeciones y apelaciones. A falta de acuerdo de todas las partes para tener un panel de tres personas, por defecto habrá un panel unipersonal.

Un panel estará compuesto por expertos debidamente cualificados designados para cada procedimiento por el DRSP designado. Los panelistas deben ser independientes de las partes en un procedimiento de resolución de disputas. Cada DRSP seguirá sus procedimientos adoptados para requerir dicha independencia, incluidos los procedimientos para impugnar y sustituir un panelista por falta de independencia, así como las políticas de la ICANN respecto del Conflicto de interés (Apéndice 7) y su Código de conducta y pautas sobre conflictos de interés para proveedores de servicios (Apéndice 8).

El panel estará compuesto por uno o tres panelistas, idealmente con los siguientes conocimientos especializados:

• Objeciones por confusión de cadenas de caracteres: Experiencia en disputas sobre derechos legales, con al menos un panelista que conozca los códigos de escritura pertinentes.

• Objeciones por Derechos Legales: Experiencia en disputas sobre derechos legales.

• Objeciones de interés público limitado: Reconocidos como eminentes juristas de reputación internacional, con experiencia en campos relevantes como ciencias sociales, ciencias políticas, sociología, ciencias de la salud y otros.

• Objeciones de la comunidad: Reconocidos como eminentes juristas de reputación internacional, con experiencia en campos relevantes como ciencias sociales, ciencias políticas, sociología y otros. Idealmente, al menos uno de los panelistas debería comprender o conocer sobre la comunidad pertinente.

Ni los panelistas, ni el DRSP, ni la ICANN, ni sus respectivas afiliadas, miembros del personal, empleados, directores o consultores serán responsables ante ninguna parte en ninguna acción por daños y perjuicios o medidas cautelares por cualquier acto u omisión en relación con cualquier actuación en virtud de los procedimientos, excepto en casos de mala conducta intencionada o negligencia grave.

Las Reglas del DRSP establecerán los procedimientos para plantear y abordar cuestiones de conflictos de interés con el panel asignado.

4.5.8.7 Revisión preliminar para objeciones

La Revisión preliminar para objeciones está diseñada para identificar y rechazar las objeciones que sean manifiestamente infundadas, constituyan un abuso del derecho de oposición o presenten ambas características.

Una objeción se considerará manifiestamente infundada, un abuso del derecho de oposición, o ambas cosas, en los siguientes casos:

1. La objeción no se presenta sobre la base de uno de los principios o fundamentos aceptados para las objeciones.

2. La parte que presenta la objeción no tiene legitimación.

3. No se proporcionan pruebas suficientes o no se proporciona ninguna prueba para respaldar la objeción.

4. La objeción es descabellada, claramente inventada, manifiestamente contraria al sentido común o tan ambigua que es objetivamente imposible que el DRSP le encuentre sentido.

5. La objeción difunde, incita, promueve o justifica el odio basado en la intolerancia hacia un determinado grupo.

6. Las mismas partes o partes afiliadas presentan múltiples objeciones con el mismo fundamento contra el mismo solicitante de una manera que constituye acoso hacia el solicitante.

7. Otros hechos que demuestren claramente que la objeción es manifiestamente infundada y/o constituye un abuso del derecho de oposición.

La Revisión preliminar representa la primera tarea sustantiva del panel, ya que proporciona una apreciación decisiva sobre la objeción. Esta revisión debe completarse en un plazo de 30 días a partir de la designación del panel, y el plazo comienza tras la resolución de cualquier objeción por conflicto de interés presentado por las partes implicadas.

La desestimación de una objeción que sea manifiestamente infundada, constituya un abuso del derecho de oposición, o tenga ambas características, se consideraría una Resolución del Panel, dictada de conformidad con el Artículo 22 del Procedimiento de Objeción de la ICANN.

Si la Revisión preliminar da lugar a tal desestimación, el procedimiento posterior, incluido el pago del anticipo total de los costos, no tendrá lugar.

4.5.8.8 Pago de los costos anticipados

En un plazo de 10 días a partir de la finalización de la Revisión preliminar, el DRSP estimará los costos totales y solicitará el pago anticipado total tanto al objetor como al solicitante. Cada parte deberá realizar el pago anticipado en un plazo de 20 días a partir de la notificación del resultado de la Revisión preliminar y presentar al DRSP el comprobante de dicho pago.

El DRSP puede revisar su estimación de costos totales y solicitar otros pagos anticipados a las partes durante el procedimiento de resolución. Pueden exigirse tarifas adicionales en circunstancias específicas, por ejemplo, si el DRSP recibe presentaciones complementarias u opta por celebrar una audiencia.

Si un objetor no paga estos costos por adelantado, el DRSP desestimará la objeción y no se reembolsará ninguna tarifa pagada por el objetor. Si un objetado no paga estos costos por adelantado, prevalecerá el objetor y no se reembolsarán las tarifas pagadas por el objetado. No se dará curso a la solicitud.³⁸ En caso de que ninguna de las partes realice el pago anticipado, se desestimará la objeción y no se reembolsarán las tarifas.

4.5.8.9 Respuesta a una objeción

Una vez que ambas partes hayan efectuado el pago anticipado, los DRSP notificarán al objetado quien dispone de 30 días para presentar una respuesta a la objeción tras la transmisión de los resultados de la Revisión preliminar. Los DRSP no aceptarán respuestas fuera de plazo. En el momento en que el objetado presente su respuesta, deberá abonar una tarifa de presentación por el importe fijado y publicado por el DRSP correspondiente, que será el mismo que la tarifa de presentación abonada por el objetor. Si el objetado no abona la tarifa de presentación en el plazo de 20 días a partir de la notificación del resultado de la Revisión preliminar, la respuesta se desestimará, lo que dará lugar a que prevalezca el objetor, y no se admitirá el procesamiento de la solicitud.³⁹

Si el objetado no presenta una respuesta en el plazo de 30 días, se considerará que ha incurrido en incumplimiento, y se considerará que la objeción ha prosperado. En este caso, no se reembolsarán las tarifas al objetado. Si se considera que la respuesta incumple el Procedimiento de objeción y las Reglas aplicables del DRSP, el objetado dispondrá de cinco días para corregirla.

Los objetados deben atenerse a las siguientes pautas relativas a las respuestas:

• Todas las respuestas deben presentarse en inglés.

• Cada respuesta debe presentarse por separado. Si un solicitante responde a varias objeciones, deberá presentar una respuesta separada y la tarifa de presentación correspondiente por cada objeción.

• Las respuestas deben presentarse por vía electrónica.

• La extensión máxima de cada respuesta se limita a 5 000 palabras, sin incluir los anexos.

• Cada objetado debe proporcionar al objetor copias de todas las presentaciones al DRSP relacionadas con el procedimiento de objeción.

Cada respuesta presentada por un objetado debe incluir:

• El nombre y los datos de contacto del objetado.

• Respuesta punto por punto a las alegaciones del objetor.

• Toda copia de los documentos que considere que fundamenta la respuesta.

4.5.8.10 Evidencia complementaria y audiencia

El panel podrá decidir si las partes deben presentar declaraciones escritas además de la objeción y la respuesta presentadas, y podrá especificar los plazos⁴⁰ para dichas presentaciones. Para garantizar que las disputas se resuelvan rápidamente y a un costo razonable, la producción de documentos será muy limitada, si es que se permite, y solo a petición del panel. Únicamente cuando el panel lo considere necesario y apropiado, podrá exigir a una de las partes que presente evidencia complementaria, o celebrar una audiencia virtual, aunque, por lo general, las disputas se resolverán sin audiencia. En ningún caso, se celebrará una audiencia presencial.

4.5.8.11 Mediación y acuerdo

Cuando se produzcan objeciones, las partes podrán recurrir a la mediación o negociar acuerdos para resolver las disputas, tal como se describe a continuación.

4.5.8.11.1 Generalidades sobre la mediación y acuerdo

Se invita a las partes de un procedimiento de resolución de disputas a participar en una mediación destinada a resolver la disputa, aunque no están obligadas a hacerlo. Cada DRSP cuenta con expertos que se pueden contratar para desempeñarse como mediadores a fin de facilitar este proceso, si las partes así lo deciden, y los DRSP se comunicarán con las partes en relación con esta opción y las tarifas asociadas, que correrán a cargo de las partes.

Si se nombra a un mediador, esa persona no podrá formar parte del panel constituido para emitir una Resolución del Panel en la disputa relacionada. Las partes son libres de negociar sin mediación en cualquier momento o de contratar a un mediador de mutuo acuerdo por su propia cuenta.

La ICANN no participará en ningún momento en la mediación.

4.5.8.11.2 Período de reflexión

No existen prórrogas automáticas para llevar a cabo negociaciones o mediaciones. Sin embargo, las partes tienen la oportunidad de presentar una solicitud de período de reflexión al DRSP de acuerdo con sus reglas; dicha solicitud debe ser presentada conjuntamente por ambas partes. Un período de reflexión es un período de tiempo durante el cual los plazos de presentación y de otro tipo quedarán en suspenso. El DRSP o el panel, si se lo nombra, decidirá si concede la solicitud.

Salvo circunstancias excepcionales, las partes deben limitar el período de reflexión a 30 días. Sin embargo, debe tenerse en cuenta que si el solicitante presenta un Pedido de cambios en una solicitud (ACR) en respuesta a las preocupaciones planteadas en una objeción, el proceso de resolución de disputas podría quedar en suspenso durante más tiempo, si ambas partes están de acuerdo y tal como se describe en la Sección 4.5.8.12 Pedido de cambios en una solicitud en el proceso de objeción.

Se puede solicitar un período de reflexión en cualquier momento después de que el objetado haya presentado una respuesta a la objeción y antes de que se emita la Resolución del Panel. Las partes deberán hacerse cargo de los gastos en los que haya incurrido el DRSP antes del período de reflexión.

4.5.8.11.3 Acuerdo

En cualquier etapa del proceso, el objetor y el objetado pueden llegar a un acuerdo. Hay dos resultados posibles:

1. El objetor retira la objeción. En este caso, a menos que esté sujeta a algún otro proceso, la solicitud seguirá adelante.

2. El objetado/solicitante retira su solicitud.

Si el acuerdo requiere que el objetado/solicitante presente un ACR, ambas partes deben ser conscientes de que el cambio no será necesariamente aprobado. Para más información sobre los ACR en el proceso de objeción, consultar la sección siguiente.

Si las partes llegan a un acuerdo, informarán al DRSP, quien pondrá fin al procedimiento, siempre que las partes hayan cumplido con sus obligaciones de pago. El DRSP también informará a la ICANN y a las partes de la conclusión en consecuencia.

Todos los acuerdos deben respetar las reglas de la Guía para el Solicitante relativas a la prohibición de resolución privada de controversias por cadenas de caracteres, tal como se describe en la Sección 5.2.3 Prohibición de resolución privada de controversias por cadenas de caracteres por parte de los solicitantes.

4.5.8.12 Pedidos de cambios en una solicitud en el proceso de objeción

Los solicitantes tienen la oportunidad de pedir enmiendas a sus solicitudes; estas enmiendas podrán incluir, entre otras cosas, la adición o modificación de los Compromisos voluntarios de los operadores de registro (RVC, Sección 7.8.3) o Políticas de registración para la comunidad (Sección 7.8.4) en respuesta a las preocupaciones planteadas en una objeción, a través de un Pedido de cambios en una solicitud (ACR, consultar la Sección 3.8). Salvo circunstancias extraordinarias, la ICANN no participará en los procesos de objeción.

Si un solicitante presenta un ACR después de haber respondido a una objeción, puede pedir al DRSP que suspenda el proceso de objeción, siempre que el objetor esté de acuerdo, tal como se describe en la Sección 4.5.8.11 Periodo de reflexión. Si el DRSP considera legítima la solicitud conjunta, el proceso de resolución de disputas quedará congelado hasta que concluya el proceso de ACR y la correspondiente reevaluación (si es necesaria/aplicable). Si el solicitante no presenta el ACR dentro del plazo de 30 días tras solicitar el periodo de reflexión, el DRSP reanudará el proceso de resolución de disputas. Si el DRSP no aprueba la solicitud, el solicitante aún podrá presentar un ACR, pero el proceso de resolución de disputas no quedará en suspenso.

El panel deberá considerar los resultados del ACR como parte de su evaluación. Debe tenerse en cuenta que, en este caso, el panel podría determinar aún que una solicitud puede proceder, aunque no se acepte el ACR. El objetor y el solicitante también pueden llegar a un acuerdo, tal como se describe en la Sección 4.5.8.11.3 Acuerdo.

4.5.8.13 Objeciones y Compromisos voluntarios de los operadores de registro

El panel, en circunstancias extraordinarias, ⁴¹ y como parte de su Resolución del panel, podría ordenar que una solicitud no proceda a menos que se incluya en el Acuerdo de Registro aplicable un RVC nuevo o modificado que sea aprobado por la ICANN. Dichos RVC serán considerados RVC de conformidad con los Compromisos adquiridos para resolver las objeciones o el Asesoramiento consensuado del GAC (consultar la Sección 7.8.3.2.3.1 Situación 1: Compromisos adquiridos para resolver las objeciones o Asesoramiento consensuado del GAC). Existen tres escenarios diferentes:

1. Un solicitante considera que un RVC existente en su solicitud aborda las inquietudes planteadas en la objeción. En caso de que el panel determine que la inquietud tiene fundamento y que el RVC ya existente la abordará, en su Resolución del panel, el panel indicará que el RVC es un RVC de conformidad con los Compromisos adquiridos para resolver las objeciones o Asesoramiento consensuado del GAC.

2. Un solicitante y el objetor en un procedimiento de objeción determinado llegan a un acuerdo que incluye la adición de un nuevo RVC o la modificación de uno ya existente. En tales casos, el solicitante deberá presentar un ACR que, si es aceptado por la ICANN, irá seguido de una Evaluación de compromisos de los operadores de registro (RCE). Si el RVC supera la RCE, el objetor retirará la objeción con la condición de que el RVC se considere un RVC de conformidad con los Compromisos adquiridos para resolver las objeciones o Asesoramiento consensuado del GAC.

3. El panel determina si un RVC nuevo o modificado aborda las inquietudes planteadas en una objeción. En dicho caso, el solicitante actualizará el RVC existente o redactará uno nuevo y presentará un ACR que, si es aceptado, irá seguido de la RCE. Si el RVC supera el ACR y la RCE, en su Resolución del panel, el panel indicará que el RVC es un RVC de conformidad con los Compromisos adquiridos para resolver las objeciones o Asesoramiento consensuado del GAC si el panel considera que el RVC nuevo o modificado permitiría al solicitante resolver la objeción. Si el panel considera que el RVC nuevo o modificado no resuelve la objeción, el objetor prevalecerá.

4.5.8.14 Resolución del panel

Las Resoluciones finales del panel del DRSP serán por escrito e incluirán:

• Un resumen de la disputa y las conclusiones.

• La identificación de la parte vencedora.

• El razonamiento en el que se basa la Resolución del panel.

A menos que el panel decida lo contrario, cada DRSP publicará íntegramente en su sitio web todas las resoluciones emitidas por sus paneles.

La decisión del panel se considerará una Resolución del panel, que la ICANN aceptará dentro del proceso de resolución de disputas.

Los resultados de las Objeciones por confusión de cadenas de caracteres pueden incluir lo siguiente:

• Si el objetor prevalece:

  • Cuando el objetor sea otro solicitante, tanto las cadenas de caracteres solicitadas por el solicitante como por el objetor y sus cadenas variantes (si corresponde) deberán incluirse en el conjunto de solicitudes controvertidas.

  • Cuando el objetor sea un operador de gTLD existente o un operador de ccTLD existente/una Parte con un interés significativo en el país o territorio correspondiente, la solicitud (incluidas las cadenas de caracteres principales y las cadenas variantes asignables) no podrá pasar a la siguiente etapa del proceso de solicitud.

• Si el objetor no prevalece, dicha solicitud podrá pasar a la siguiente etapa del proceso de solicitud, a menos que otros procesos lo impidan.

Los posibles resultados de Objeciones de interés público limitado, por derechos legales y de la comunidad son los siguientes:

• Si prevalece una objeción contra una cadena de caracteres de gTLD principal solicitada, dicha solicitud, junto con todas las cadenas de caracteres variantes solicitadas de esa cadena de caracteres principal, no será elegible para pasar a la siguiente etapa del proceso de solicitud.

• Si una objeción prevalece contra una o más cadenas variantes asignables solicitadas, la solicitud para la cadena principal y cualquier cadena variante asignable no afectada puede pasar a la siguiente etapa, excepto las cadenas variantes que se han tornado no elegibles debido a la objeción.

• Si la objeción no prevalece, entonces dicha solicitud podrá pasar a la siguiente etapa del proceso de solicitud, a menos que otros procesos lo impidan.

• La solicitud no puede seguir adelante a menos que se llegue a un acuerdo sobre un RVC nuevo o modificado que sea aprobado por la ICANN. Consultar la Sección 4.5.8.13 Objeciones y Compromisos voluntarios de los operadores de registro para más información.

Después de que el panel dicte su Resolución del panel, el DRSP reembolsará el pago anticipado de los costos a la parte vencedora. Si la Resolución del panel indica que la solicitud no puede seguir adelante a menos que se llegue a un acuerdo sobre un RVC nuevo o modificado que sea aprobado por la ICANN, el objetor será considerado como la parte vencedora.

4.5.9 Presentación y procesamiento de apelaciones

La Parte no vencedora de una Objeción tendrá la oportunidad de apelar una Resolución del panel y dicha Apelación sería considerada bajo un estándar de revisión de error manifiesto. El procedimiento de apelación a la Resolución del Panel se describe en el Procedimiento para la apelación de objeciones de la ICANN. En caso de discrepancia entre la información presentada en esta sección y el procedimiento, prevalecerá el procedimiento. También deben seguirse las reglas de cada DRSP específico para cada fundamento de objeción, que se publican en las Reglas de los Proveedores de Servicio de Resolución de Disputas.

4.5.9.1 Presentación de una apelación

Una parte en una objeción dispondrá de 15 días a partir de la fecha en que el DRSP emita la Resolución del panel para notificar al DRSP su intención de apelar dicha Resolución (Notificación de apelación). La Notificación de apelación debe especificar los elementos de la Resolución del panel que se apelan y debe contener una breve declaración de los fundamentos de la apelación. El apelante dispondrá de 15 días a partir de la fecha de presentación de la Notificación de apelación para presentar la apelación y abonar las tarifas exigidas. El apelante que desee apelar las Resoluciones del panel en más de un procedimiento de objeción deberá presentar apelaciones separadas ante los DRSP correspondientes.

La Notificación de apelación contendrá, entre otros datos, la siguiente información:

• Los nombres e información de contacto (dirección, número de teléfono, dirección de correo electrónico, etc.) del apelante.

• Identificación de la objeción en cuestión que se apela.

• Una descripción de los fundamentos de la apelación, que incluya:

  • Una declaración de los fundamentos por los que se presenta la apelación, tal como se establece en el Artículo 1 de este Procedimiento de apelación de objeciones.

  • Una explicación de la validez de la apelación y de las razones por las que debe ser admitida.

La parte expositiva de la apelación se limitará a 5 000 palabras, sin incluir los anexos. Los anexos no son un método para aportar argumentos adicionales ni pasar por alto el límite de palabras previamente establecido.

Al mismo tiempo que se presenta la apelación, el apelante deberá pagar una tarifa de presentación por el importe establecido de conformidad con las Reglas de apelación aplicables del DRSP e incluir el comprobante de dicho pago junto con la Notificación de apelación. Si no se abona la tarifa de presentación, la apelación se desestimará sin perjuicio alguno.

4.5.9.2 Revisión administrativa de la apelación

El DRSP llevará a cabo una revisión administrativa de la apelación para verificar el cumplimiento de todas las reglas de procedimiento e informará al apelante, al apelado y a la ICANN del resultado de su revisión dentro de un plazo de 14 días a partir de la recepción de la apelación. El DRSP puede extender este plazo si es necesario. Si el DRSP considera que la apelación se ajusta al Procedimiento de apelación, la apelación se registrará para su procesamiento. No obstante, si el DRSP considera que la apelación no está en consonancia con el procedimiento, podrá solicitar que se corrijan las deficiencias administrativas dentro de un plazo de cinco días. Si no se corrigen las deficiencias en el plazo especificado, se desestimará la apelación.

4.5.9.3 Publicación de la apelación

Tras registrar una apelación para su procesamiento, el DRSP publicará en su sitio web la siguiente información sobre la apelación:

• La cadena de caracteres propuesta a la que se refiere la apelación.

• El nombre del apelante.

• Un enlace web a la Resolución del panel del procedimiento de objeción en cuestión.

• Los fundamentos de la apelación.

• Las fechas de recepción de la apelación por parte del DRSP.

4.5.9.4 Consolidación de apelaciones

Cuando dos o más partes con intereses alineados sean elegibles para apelar una Resolución del panel, podrán presentar una Notificación de apelación conjunta y proceder como un único apelante. Si las partes han presentado por separado notificaciones de apelación dentro del plazo, el DRSP podrá unir o consolidar estas apelaciones, ya sea de forma independiente o a petición de una parte, dentro de un plazo de 5 días a partir de la publicación de la Apelación en el sitio web del DRSP.

A la hora de decidir si se consolidan las apelaciones, el DRSP sopesará los beneficios (en términos de tiempo, costo, coherencia de las decisiones, etc.) que puedan resultar de la consolidación frente a los posibles perjuicios o inconvenientes que la consolidación pueda causar. La decisión del DRSP sobre la consolidación será definitiva e inapelable.

4.5.9.5 Designación del panel de apelación

El DRSP designará un panel para cada apelación que supere la Revisión administrativa. Las partes en un procedimiento tendrán la oportunidad de acordar mutuamente un panel compuesto por una persona o por tres personas, en cuyo caso los costos se repartirán según lo descrito en la Sección 4.5.6 Costos de objeciones y apelaciones. A falta de acuerdo de todas las partes para tener un panel de tres personas, por defecto habrá un panel unipersonal.

Un panel estará compuesto por expertos debidamente cualificados designados por el DRSP designado. Los panelistas deben ser independientes de las partes implicadas en el procedimiento de resolución de disputas. Cada DRSP seguirá sus propios procedimientos para requerir dicha independencia, incluidos los procedimientos para impugnar y sustituir un panelista por falta de imparcialidad.

4.5.9.6 Revisión preliminar para apelaciones

La Revisión preliminar para apelaciones está diseñada para identificar y rechazar las apelaciones que sean manifiestamente infundadas, constituyan un abuso del derecho de oposición, o presenten ambas características.

Una apelación se considerará manifiestamente infundada, un abuso del derecho de oposición, o ambas cosas, en los siguientes casos:

1. La apelación no es presentada por la parte no vencedora de la objeción.

2. No se proporcionan pruebas suficientes o no se proporciona ninguna prueba para respaldar la apelación.

3. La apelación es descabellada, claramente inventada, manifiestamente contraria al sentido común o tan ambigua que es objetivamente imposible que el DRSP le encuentre sentido.

4. La apelación difunde, incita, promueve o justifica el odio basado en la intolerancia hacia un determinado grupo.

5. La apelación constituye acoso a la otra parte o a la propia objeción.

6. La apelación incluye hechos que demuestran claramente que es manifiestamente infundado o constituye un abuso del derecho de apelación.

La Revisión preliminar es la primera tarea del Panel de apelación y es determinante para la apelación. La Revisión preliminar debe realizarse dentro de un plazo de 30 días a partir de la designación del panel.

La desestimación de una Apelación que sea manifiestamente infundada, constituya un abuso del derecho de apelación o tenga ambas características, sería una Resolución del Panel de apelación, dictada de conformidad con el Artículo 19 del Procedimiento para la apelación de objeciones de la ICANN.

4.5.9.7 Pago de los costos de la apelación

En un plazo de 10 días a partir de la publicación del resultado de la Revisión preliminar, el DRSP estimará los costos totales y solicitará el pago anticipado total a ambas partes. Las partes presentarán pago anticipado en un plazo de 10 días a partir de la solicitud de pago del DRSP, aportando el comprobante de pago. El DRSP puede revisar su estimación de los costos totales y solicitar pagos anticipados adicionales a las partes durante el procedimiento.

Si un apelante no paga estos costos por adelantado, el DRSP desestimará la apelación y no se reembolsará ninguna tarifa pagada por el apelante. Si un apelado no paga estos costos por adelantado, prevalecerá el apelante y no se reembolsarán las tarifas pagadas por el apelado. No se dará curso a la solicitud.⁴² En caso de que ninguna de las partes realice el pago anticipado, se desestimará la apelación y no se reembolsarán las tarifas.

4.5.9.8 Respuesta a una apelación

El apelado puede presentar una respuesta a una apelación dentro de un plazo de 30 días a partir del resultado de la Revisión preliminar, aunque no está obligado a hacerlo. Si no se presenta una respuesta, el Panel de Apelación presumirá que el apelado no se pronuncia sobre la apelación.

Si se presenta una respuesta, debe incluir, entre otros datos:

• Los nombres e información de contacto (dirección, número de teléfono, dirección de correo electrónico, etc.) del apelado.

• Una respuesta punto por punto a las declaraciones formuladas en la apelación.

La parte expositiva de una respuesta se limitará a 5 000 palabras, sin incluir los anexos. Los anexos no son un método para aportar argumentos adicionales ni pasar por alto el límite de palabras previamente establecido.

Cuando se presenta la respuesta, el apelado deberá pagar una tarifa de presentación por el importe establecido y publicado por el DRSP correspondiente (que será la misma que la tarifa de presentación abonada por el apelante) e incluir el comprobante de dicho pago junto con la respuesta. Si la tarifa de presentación no se abona en un plazo de 10 días a partir de la notificación del resultado de la Revisión preliminar, cualquier respuesta será desestimada y el Panel de apelación presumirá que el apelado no se pronuncia sobre la apelación.

Si el DRSP considera que la respuesta no cumple con todas las reglas de procedimiento, el DRSP tendrá la facultad discrecional de solicitar que se corrijan las deficiencias administrativas de la respuesta dentro de un plazo de cinco días.

4.5.9.9 Estándares de la apelación

El Panel de apelación aplicará el estándar de revisión "de error manifiesto" para cada categoría de apelación según lo establecido en el Programa de Nuevos gTLD. En virtud de un estándar de revisión de error manifiesto, el Panel de apelación debe aceptar las conclusiones de hecho del Panel de objeción a menos que éste no haya realizado lo siguiente:

1. Seguir los procedimientos adecuados; o

2. Considerar o solicitar las pruebas sustanciales o la información necesarias en el procedimiento de objeción; o

3. Tanto la opción 1 como la opción 2.

El apelante tiene la carga de probar que su apelación debe ser admitida de conformidad con el estándar aplicable.

4.5.9.10 Resolución de Panel de apelación

La Resolución del Panel de apelación deberá realizarse por escrito, identificar a la parte vencedora e indicar los motivos en los que se basa. El Panel de apelación adoptará una de las siguientes medidas:

1. Rechazar la Apelación y mantener la Resolución del Panel de objeción.

2. Sustituir la Resolución del Panel de objeción en cuestión por su propia resolución.

El Panel de apelación no puede ordenar un nuevo procedimiento de objeción ni devolver el asunto al Panel de objeción original para que realice correcciones o una nueva revisión.

La decisión del panel se considerará una Resolución del Panel de apelación, que la ICANN aceptará dentro del proceso de resolución de disputas.

La Resolución del Panel de apelación deberá indicar la fecha en que se dicta y estar firmada por el Panel de apelación. Si algún panelista no firma la Resolución del Panel de apelación, ésta deberá ir acompañada de una declaración en la que se explique la razón de la ausencia de dicha firma.

La Resolución del Panel de apelación se publicará íntegramente en la página web del DRSP. Una vez concluido el proceso de Apelación, la Resolución del Panel de apelación será la resolución definitiva y final, y no podrá someterse a una nueva apelación.

4.5.10 Principios de las objeciones

Un panel evaluará los méritos de cada objeción utilizando los principios generales apropiados, con principios de adjudicación específicos detallados para cada tipo de objeción. Además, un panel puede hacer referencia a reglas pertinentes del derecho internacional en relación con los principios. La Resolución de un Panel de objeciones o apelaciones dictada en cualquier ronda no constituirá un precedente vinculante. La carga de la prueba recae en el objetor en cada caso. Los principios que se exponen a continuación siguen siendo dinámicos y están sujetos a un perfeccionamiento continuo a través de consultas con los DRSP, expertos en asuntos legales y el público.

4.5.10.1 Principios: Confusión de cadenas de caracteres

El proceso de objeción por confusión de cadenas de caracteres complementa la Evaluación de la similitud entre cadenas de caracteres (Sección 7.10). Mientras que la Evaluación de la similitud entre cadenas de caracteres se limita a la similitud visual, las objeciones por confusión de cadenas de caracteres pueden presentarse sobre la base de todo tipo de similitud: visual, auditiva o de significado.

Un panel que examine una Objeción por confusión de cadenas de caracteres considerará si es probable que las cadenas de caracteres en cuestión den lugar a una confusión de cadenas de caracteres. Existe confusión de cadenas de caracteres cuando una cadena de caracteres se parece tanto a otra que puede inducir a error o confusión. Para que exista riesgo de confusión, debe ser probable, y no meramente posible, que la confusión surja en la mente del usuario medio y razonable de Internet. La mera asociación, en el sentido de que la cadena de caracteres evoca a otra cadena de caracteres, no es suficiente para concluir que existe riesgo de confusión.

4.5.10.2 Principios: Derechos legales

4.5.10.2.1 Derechos legales: Uso potencial de la cadena de caracteres

El panel que presida una objeción por derechos legales determinará si el uso potencial de la cadena de caracteres pertinente por parte del solicitante:

1. Se aprovecharía de manera injusta del carácter distintivo o de la reputación de la marca comercial registrada o no registrada o de la marca de servicio (marca) del objetor o del nombre o acrónimo de la OIG (tal como se identifica en el tratado constitutivo de la organización).

2. Perjudicaría injustificadamente el carácter distintivo o la reputación de la marca del objetor o del nombre o acrónimo de la OIG.

3. De algún modo, crearía un riesgo de confusión inadmisible entre la cadena de caracteres en cuestión y la marca del objetor o el nombre o acrónimo de la OIG.

4.5.10.2.2 Derechos legales: Marcas comerciales

Para las objeciones sobre marcas comerciales, el panel considerará los siguientes factores no excluyentes:

1. Si la cadena de caracteres en cuestión es idéntica o similar, incluso en apariencia, fonética o significado, a la marca existente del objetor.

2. Si la adquisición y el uso de los derechos sobre la marca por parte del objetor han sido de buena fe.

3. Si existe, y, de ser así, en qué medida, un reconocimiento en el sector pertinente del público del signo correspondiente a la cadena de caracteres, como marca del objetor, del solicitante o de un tercero.

4. La intención del solicitante al solicitar la cadena de caracteres pertinente, incluso si el solicitante, en el momento de solicitar el gTLD, tenía conocimiento de la marca del objetor, o no podía razonablemente desconocer dicha marca, e incluso si el solicitante ha incurrido en un patrón de conducta por el que solicitó o gestiona gTLD o registraciones en gTLD que son idénticos o similares a las marcas de otros.

5. Si, y de ser así, en qué medida, el solicitante ha utilizado, o ha realizado gestiones demostrables para utilizar, el signo correspondiente al gTLD en relación con una oferta de buena fe de productos o servicios o un suministro de buena fe de información de forma que no interfiera con el ejercicio legítimo de los derechos de marca del objetor.

6. Si el solicitante tiene marcas u otros derechos de propiedad intelectual sobre el signo correspondiente al gTLD y, de ser así, si cualquier adquisición de tal derecho sobre el signo, y el uso del signo, ha sido de buena fe, y si el uso pretendido o probable del gTLD por parte del solicitante está en consonancia con dicha adquisición o uso.

7. Si el solicitante ha sido comúnmente conocido por el signo correspondiente al gTLD y, de ser así, en qué medida, y si cualquier uso supuesto o probable del gTLD por parte del solicitante está en consonancia con ello y es de buena fe.

8. Si el uso previsto del gTLD por parte del solicitante crearía un riesgo de confusión con la marca del objetor en cuanto a la fuente, patrocinio, afiliación o respaldo del gTLD.

9. Si el uso previsto por el solicitante de un término común del diccionario que también es una marca pretende aprovecharse de dicho significado común o se dirige a una marca.

4.5.10.2.3 Derechos legales: OIG

En el caso de que una OIG haya presentado una Objeción por derechos legales, el panel considerará los siguientes factores no excluyentes:

1. Si el gTLD en cuestión es idéntico o similar, incluso en apariencia, fonética o significado, al nombre o acrónimo de la OIG objetora.

2. Coexistencia histórica de la OIG y uso por parte del solicitante de un nombre o acrónimo similar. Los factores considerados pueden incluir:

   1. Nivel de reconocimiento mundial de ambas entidades.

   2. Antigüedad de las entidades.

   3. Pruebas históricas públicas de su existencia, que pueden incluir si la OIG objetora ha comunicado su nombre o abreviatura en virtud del artículo 6ter del Convenio de París para la Protección de la Propiedad Industrial.

3. Si, y de ser así, en qué medida, el solicitante ha utilizado, o ha realizado gestiones demostrables para utilizar, el signo correspondiente al gTLD en relación con una oferta de buena fe de productos o servicios o un suministro de buena fe de información de forma que no interfiera con el ejercicio legítimo del nombre o acrónimo de la OIG objetora.

4. Si el solicitante ha sido comúnmente conocido por el signo correspondiente al gTLD relevante y, de ser así, en qué medida, y si cualquier uso supuesto o probable del gTLD por parte del solicitante está en consonancia con ello y es de buena fe.

5. Si el uso previsto por el solicitante del gTLD en cuestión crearía una probabilidad de confusión con el nombre o acrónimo de la OIG objetora en cuanto a la fuente, patrocinio, afiliación o respaldo del gTLD.

4.5.10.3 Principios: Interés público limitado

Un panel que examine una Objeción de interés público limitado considerará si la cadena de caracteres de gTLD en cuestión es contraria a los principios generales del derecho internacional en materia de moralidad y orden público.

Algunos ejemplos de instrumentos que contienen estos principios generales son:

• La Declaración Universal de los Derechos Humanos (DUDH)

• El Pacto Internacional de Derechos Civiles y Políticos (ICCPR)

• La Convención sobre la Eliminación de Todas las Formas de Discriminación contra la Mujer (CEDAW)

• La Convención Internacional sobre la Eliminación de todas las Formas de Discriminación Racial

• La Declaración sobre la Eliminación de la Violencia contra la Mujer

• El Pacto Internacional de Derechos Económicos, Sociales y Culturales

• La Convención contra la Tortura y Otros Tratos o Penas Crueles, Inhumanos o Degradantes

• La Convención Internacional sobre la Protección de los Derechos de Todos los Trabajadores Migratorios y de sus Familiares

• Convención sobre la Esclavitud

• Convención para la Prevención y la Sanción del Delito de Genocidio

• Convención sobre los Derechos del Niño

Los instrumentos mencionados anteriormente se incluyen a modo de ejemplo, sin pretender ser una lista exhaustiva, y varían en cuanto a su estado de ratificación. Además, los Estados pueden limitar el alcance de ciertas disposiciones mediante reservas y declaraciones que indiquen cómo interpretarán y aplicarán determinadas disposiciones. Las leyes nacionales que no se basen en principios del derecho internacional no son un motivo válido para una Objeción de interés público limitado.

En virtud de estos principios, toda persona tiene derecho a la libertad de expresión, pero el ejercicio de este derecho conlleva deberes y responsabilidades especiales. En consecuencia, pueden aplicarse ciertas restricciones de carácter limitado.⁴³

Los fundamentos por los que una cadena de caracteres de gTLD puede considerarse contraria a las normas jurídicas generalmente aceptadas relativas a la moralidad y el orden público reconocidas en virtud de los principios del derecho internacional son:

• Incitación o promoción de acciones violentas fuera de la ley.

• Incitación o fomento de la discriminación por motivos de raza, color, sexo, etnia, religión o nacionalidad, u otros tipos similares de discriminación que infrinjan las normas jurídicas generalmente aceptadas y reconocidas en virtud de los principios del derecho internacional.

• Incitación o promoción de la pornografía infantil u otros abusos sexuales de menores.

• La determinación de que una cadena de caracteres de gTLD sería contraria a principios específicos del derecho internacional reflejados en los instrumentos jurídicos internacionales pertinentes.

El panel llevará a cabo su análisis basándose en la propia cadena de caracteres de gTLD. En caso necesario, el panel podrá utilizar como contexto adicional la finalidad prevista del gTLD tal como se indica en la solicitud.

4.5.10.4 Principios: La comunidad

Las cuatro pruebas aquí descritas permitirán a un panel determinar si existe una oposición sustancial a la representación de la comunidad propuesta por el solicitante por parte de una parte significativa de la comunidad a la que puede dirigirse la cadena de caracteres. Para que una objeción prospere, el objetor debe demostrar que:

• La comunidad invocada por el objetor es una comunidad claramente delimitada.

• La oposición de la comunidad a la solicitud es sustancial.

• Existe una fuerte correlación entre la comunidad invocada y la cadena de caracteres del gTLD relevante.

• La solicitud da lugar a un posible perjuicio material en relación a los derechos o intereses legítimos de una parte significativa de la comunidad a la que la cadena de caracteres puede ir dirigida explícita o implícitamente.

Cada una de estas pruebas se describe con más detalle a continuación. El objetor debe superar las cuatro pruebas del estándar para que la objeción prevalezca.

4.5.10.4.1 La comunidad

El objetor debe demostrar que la comunidad que expresa su oposición a la representación de la comunidad propuesta por el solicitante puede considerarse una comunidad claramente delimitada. Un panel podría sopesar una serie de factores para determinarlo, incluidos, entre otros:

• El nivel de reconocimiento público del grupo como comunidad a nivel local o mundial.

• El nivel de límites formales en torno a la comunidad y qué personas o entidades se considera que forman la comunidad.

• La antigüedad de la comunidad.

• La distribución global de la comunidad (esto puede no aplicarse si la comunidad es territorial).

• La cantidad de personas o entidades que componen la comunidad.

Si se encuentra oposición a la representación de la comunidad propuesta por el solicitante por parte de varias personas o entidades, pero no se determina que el grupo representado por el objetor sea una comunidad claramente delimitada, la objeción no prosperará.

4.5.10.4.2 Oposición sustancial

El objetor debe demostrar una oposición sustancial a la representación de la comunidad propuesta por el solicitante dentro de la comunidad que se ha identificado como representante. Un panel podría sopesar una serie de factores para determinar si existe una oposición sustancial, por ejemplo:

• Número de manifestaciones de oposición en relación con la composición de la comunidad.

• La naturaleza representativa de las entidades que expresan oposición.

• El nivel de reputación o peso reconocido entre las fuentes de oposición.

• Distribución o diversidad entre las fuentes de manifestaciones de oposición, entre ellas:

  • Regional

  • Subsectores de la comunidad

  • Liderazgo de la comunidad

  • Membresía de la comunidad

• Defensa histórica de la comunidad en otros contextos.

• Costos en los que incurrió el objetor para manifestar su oposición, incluidos otros canales que el objetor haya podido utilizar para transmitir su oposición.

Si se determina cierta oposición dentro de la comunidad, pero no cumple con el estándar de oposición sustancial, la objeción no prosperará.

4.5.10.4.3 Foco

El objetor debe demostrar una fuerte asociación entre la cadena de caracteres de gTLD pertinente y la comunidad representada por el objetor. Entre los factores que un panel podría sopesar para determinar esto figuran los siguientes:

• Declaraciones contenidas en la solicitud.

• Otras declaraciones públicas del solicitante.

• Asociaciones por parte del público.

Si se determina la oposición a la representación de la comunidad propuesta por el solicitante por parte de una comunidad, pero no existe una fuerte asociación entre la comunidad y la cadena de caracteres de gTLD pertinente, la objeción no prosperará.

4.5.10.4.4 Perjuicio

El objetor debe probar que la cadena de caracteres crea una probabilidad de perjuicio material a los derechos o intereses legítimos de una parte significativa de la comunidad a la que la cadena de caracteres puede ir dirigida explícita o implícitamente. Una alegación de perjuicio material que se funde únicamente en la explotación por parte del solicitante de la cadena de caracteres de gTLD pertinente no se considerará fundamento sustancial para una objeción.

Los factores que podría utilizar un panel para tomar esta decisión incluyen, entre otros, los siguientes:

• Naturaleza y alcance del daño a la reputación de la comunidad representada por el objetor que resultaría de la explotación por parte del solicitante de la cadena de caracteres de gTLD pertinente.

• Pruebas de que el solicitante no actúa o no tiene intención de actuar de acuerdo con los intereses de la comunidad o de los usuarios en general, incluidas pruebas de que el solicitante no ha propuesto o no tiene intención de instituir una protección de seguridad eficaz para los intereses de los usuarios.

• Interferencia con las actividades principales de la comunidad que resultaría de la explotación por parte del solicitante de la cadena de caracteres de gTLD pertinente.

• Dependencia de la comunidad representada por el objetor con respecto al DNS para sus actividades principales.

• Naturaleza y alcance del daño concreto o económico a la comunidad representada por el objetor que resultaría de la explotación por parte del solicitante de la cadena de caracteres de gTLD pertinente.

• Nivel de certeza de que se producirán los supuestos resultados perjudiciales.

Si se determina la existencia de oposición por parte de una comunidad, pero no existe probabilidad de perjuicio material para la comunidad a la que se dirige como resultado de la explotación del gTLD correspondiente por parte del solicitante, la objeción no prosperará.