Skip to main content

Actualización sobre el Centro de Información y Protección de Marcas

Esta semana me reuní con un grupo de representantes de los grupos de partes interesadas para trabajar con el personal de la ICANN con el objetivo de finalizar con las discusiones sobre la implementación del Centro de Información y Protección de Marcas y sus mecanismos de protección de derechos. Como lo indiqué en el anuncio anterior que realicé desde Bruselas, durante estas reuniones sobre la implementación se abordaron los siguientes temas:

  • La reciente propuesta de la Unidad Constitutiva de Propiedad Intelectual (IPC) y de la Unidad Constitutiva de Negocios (BC) para realizar Mejoras y Avances a los Mecanismos de Protección de Derechos (RPM) para nuevos gTLDs [PDF, 68 KB], el cual está enfocado principalmente en la implementación, en lugar de cuestiones de políticas.
  • El marco comercial y contractual del Centro de Información y Protección de Marcas.
  • La arquitectura para la implementación del período de Pre-registro (Sunrise) y de los Reclamos de Marcas.

Los representantes de las unidades constitutivas de Negocios, de la Propiedad Intelectual y de Proveedores de Servicios de Internet, los grupos de partes interesadas no comerciales, de Registradores y de Registros, y el Comité Asesor At-Large (ALAC), también participaron de estas discusiones en pos de hallar soluciones para la implementación. Estas reuniones no se basaron en el desarrollo de políticas, sino que se enfocaron principalmente en ponernos de acuerdo y avanzar con la discusión sobre las soluciones para la implementación.

Para dar comienzo al debate, introduje un resumen sobre el departamento de Servicios de gTLD que está desarrollando la ICANN para incluir recursos del personal que estén trabajando en el compromiso con la industria del DNS, en las operaciones de servicio de gTLD y en el apoyo de gTLD.

Akram Atallah y yo supervisaremos en forma personal todo el Programa de Nuevos gTLD hasta que se asigne el primer nuevo gTLD.

Propuestas de la IPC y la BC

El grupo escuchó y consideró las razones que se encuentran detrás de las siguientes ocho propuestas que realizaron hace poco la IPC y la BC:

  1. Extender el Período de Lanzamiento del Pre-registro (Sunrise) de 30 a 60 días con un proceso estandarizado.
  2. Extender el período de las notificaciones del Centro de Información y Protección de Marcas (TMCH) por un tiempo indefinido; garantizar que el proceso sea seguro, estable y fácil de utilizar.
  3. Completar el Sistema Uniforme de Suspensión Rápida (URS) como alternativa de bajo costo y mejorar su utilidad (en caso que sea necesario, la ICANN podría suscribirse por un período inicial).
  4. Implementar en todos los registros un mecanismo para que los dueños de marcas puedan prevenir el registro de segundo nivel de sus marcas (coincidencias exactas, y además, cadenas de caracteres que anteriormente fueron registrados o utilizados de forma abusiva), y que, mediante el pago de una tarifa razonable, tenga medidas de seguridad para los registrantes que posean el derecho o interés legítimo.
  5. Validar la función de información de contacto para los registrantes en WHOIS.
  6. Todos los registradores activos en los registros de nuevos gTLD deben cumplir con el RAA enmendado para todos los registros de gTLD que patrocinen.
  7. Exigir el cumplimiento de todos los compromisos de los registros de las solicitudes estándar.
  8. Expandir el servicio de Reclamos de Marcas en función de incluir al menos las cadenas de caracteres que anteriormente fueron registradas o utilizadas de forma abusiva.

El grupo determinó que los ítems 5, 6 y 7, detallados anteriormente, ya estaban siendo considerados, por lo que estos puntos quedaron diferidos de este debate.

El grupo discutió sobre el posible uso de un árbol de decisión como herramienta para considerar si los cambios propuestos eran apropiados para los procesos de políticas o implementación. El equipo de políticas de la ICANN continuará trabajando formalmente sobre este árbol de decisión junto con la comunidad en función de crear y documentar estos mecanismos para la toma de decisiones.

Para esta reunión, el grupo decidió enfocarse principalmente en encontrar las soluciones adecuadas, y luego abordar cómo estas soluciones deberían ser consideradas, adoptadas o implementadas. Además, reconocimos la necesidad de abordar de forma individual la manera en que los elementos de estas soluciones podrían aplicarse a los gTLD heredados, pero no consideramos este tema necesario para desarrollar la solución preliminar (strawman).

Modelo Preliminar (Strawman)

Se identificaron los siguientes puntos clave sobre los cinco últimos ítems que fueron propuestos:

  • Duración de los servicios del Período de Pre-registro (Sunrise) y de Reclamos de Marcas
  • Alcance de las marcas que serán incluidas en los Reclamos de Marcas
  • Establecimiento de un mecanismo de bloqueo de segundo nivel que tenga medidas de seguridad para los registrantes.

El grupo discutió y colaboró sobre una posible solución preliminar (strawman) que aborde varios de estos elementos.

Característica Actual Guía para el Solicitante Solución Preliminar (Strawman)
Período de Pre-registro (Sunrise) 30 días

30 días para el Pre-registro + 30 días para el preaviso

Período de Reclamos de Marcas 60 días 90 días + opción de un período de “Reclamos 2″ adicional con duración de 6 a 12 meses
Alcance de los Reclamos de Marcas Coincidencia Idéntica Coincidencia Idéntica + hasta 50 variaciones de marcas que fueron abusadas

En el modelo preliminar (strawman):

  • Todos los operadores de nuevos gTLD publicarán las fechas y requisitos de sus períodos de pre-registro (sunrise) con una anticipación mínima de 30 días. Al combinar esto con el período existente de pre-registro (sunrise) (30 días) cumplimos con el objetivo de permitir a los titulares de derechos a anticiparse y prepararse para los próximos lanzamientos.
  • El período de Reclamos de Marcas, de acuerdo a lo descrito en la Guía para el Solicitante, durará 90 días. Durante este período de “Reclamos 1″, a aquellas personas que intenten registrar un nombre de dominio que coincida con un informe del Centro de Información, se le mostrará una notificación de Reclamo (tal como se encuentra incluido en la Guía para el Solicitante) que muestre la información pertinente de la marca, y deberán acusar recibo de la notificación para poder proceder. Si el nombre de dominio está registrado, los titulares de derechos correspondientes recibirán una notificación del registro.
  • Los titulares de derechos tendrán la opción de abonar una tarifa adicional para incluir un informe del Centro de Información a un servicio de “Reclamos 2″ en donde, durante 6 a 12 meses adicionales, a cualquier persona que intente registrar un dominio que coincida con el informe se le mostrará una notificación de Reclamo que indique que el nombre coincide con un informe en el Centro de Información (pero no necesariamente mostrara los datos del Reclamo). Dicha notificación también brindará una descripción de los derechos y las responsabilidades del registrante e incluirá un complemento educativo para ayudar a difundir información sobre el rol de las marcas y generar consumidores más informados en el proceso de registro.
  • Se podrá incluir una cantidad limitada de etiquetas de dominios que hayan sido sujetos de anteriores registros abusivos (como por ejemplo, como resultado de un procedimiento de la UDRP o de un proceso judicial) a un informe del Centro de Información (es decir, dichos nombres serán incluidos a un informe existente para el cual la marca ya fue verificada por el Centro de Información). Cuando se intente registrar estos dominios se generarán notificaciones de Reclamos, como también notificaciones para el titular de derechos.
  • Se discutieron posibles mecanismos de bloqueo, pero no se incluyeron dentro del modelo preliminar (strawman).

Estas fases se encuentran detalladas a continuación:

Marco Contractual

Brindé una actualización sobre el marco contractual esperado para la operación del Centro de Información. Como se anunció a principios de este año, el personal de la ICANN está trabajando con Deloitte, IBM y CHIP para desplegar el Centro de Información. La estructura fue rediseñada para brindar a la ICANN una mayor flexibilidad y la habilidad de proporcionar la mejor administración posible de la base de datos.

Sesión Técnica

El grupo revisó y discutió sobre un conjunto de preguntas relacionadas a las especificaciones funcionales de la interfaz entre el Centro de Información, los registros y los registradores. Hemos realizado un avance importante y publicaremos los resultados de la discusión en la lista de distribución de correo electrónico tmch-tech. Nuestra intención es continuar realizando consultas a la comunidad sobre las preguntas restantes.

Próximos pasos

Realizaremos llamadas informativas de seguimiento en noviembre para llevar a cabo tres cosas. (1) Revisar cualquier aporte adicional realizado por los grupos de partes interesadas, (2) Transmitir la visión del personal sobre el camino a seguir con respecto a algunos o a todos los elementos de la solución preliminar (strawman), y (3) Transmitir detalles adicionales sobre los contratos del Centro de Información y Protección de Marcas.

Ahora estamos enfocados firmemente en avanzar con la implementación del Centro de Información y Protección de Marcas para garantizar que el Programa de Nuevos gTLD se lance en consonancia con nuestros objetivos.

Luego, me enfocaré en el URS y en el RAA.

¡Gracias a todos los grupos de partes interesadas por tantas horas de arduo trabajo!

Atentamente,

Fadi

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."