Skip to main content

Un Seguimiento sobre nuestras Reuniones acerca del Centro de Información y Protección de Marcas

Para concluir con la serie de reuniones que la ICANN mantuvo con las partes interesadas con el fin de ponerse de acuerdo con respecto a la implementación del Centro de Información y Protección de Marcas, hoy realizamos una reunión de seguimiento con el grupo que trabajó sobre dichas cuestiones mientras se llevaban a cabo nuestras reuniones en Bruselas y Los Ángeles.

Discutimos dos temas:

  1. Una actualización del contrato del Centro de Información y Protección de Marcas y
  2. Una manera de avanzar con respecto a la solución preliminar (strawman) que se desarrolló durante la reunión que se llevó a cabo en Los Ángeles.

Contratos

La ICANN ha continuado realizando negociaciones sobre el acuerdo de servicio de base de datos que tiene con IBM y el acuerdo de servicio de validación que tiene con Deloitte para incluir términos adicionales que brindarán a la ICANN una mayor flexibilidad operativa y la administración garantizada de la base de datos de marcas.

A continuación se encuentra un resumen:

  • La ICANN conserva todos los derechos de propiedad intelectual de los datos del Centro de Información y Protección de Marcas.
  • Los servicios de validación de Deloitte no serán exclusivos. La ICANN podrá agregar validadores adicionales luego de que se cumpla con un umbral mínimo de estabilidad.
  • Las tarifas para la presentación de marcas tienen un tope de USD 150 por cada registro. Hay descuentos disponibles para aquellos que realicen presentaciones de marcas masivas y plurianuales.
  • IBM le cobrará a Deloitte el acceso a la base de datos a través de una interfaz de procesamiento de aplicaciones (API) y le cobrará a los registros y registradores el acceso en tiempo real a la base de datos durante los períodos de pre-registro (sunrise) y de reclamo.
  • La ICANN podrá auditar el desempeño de Deloitte (incluyendo sus ingresos y costos) para confirmar que los costos y tarifas por sus servicios de validación son razonables.

Ahora estamos realizando avances para firmar los acuerdos tan pronto como sea posible, y publicaremos los mismos una vez que estén firmados.

La “Solución Preliminar” (Strawman)

De acuerdo a lo prometido, revisamos cada uno de los elementos de la solución preliminar (strawman) para identificar una manera de avanzar, y se prestó especial atención en determinar si cada uno pertenecía a una política o un proceso de implementación. No encontramos inconsistencias en los elementos de la solución preliminar (strawman) con respecto a la recomendación 3 de la GNSO: Las cadenas de caracteres no deben infringir los actuales derechos legales de terceros reconocidos o exigidos de acuerdo a los principios de derecho generalmente aceptados y reconocidos internacionalmente. Sin embargo, con el análisis de varios elementos se obtuvieron diferentes recomendaciones sobre los pasos a seguir. Los mismos se encuentran descritos a continuación.

  • Requisito de Notificación de Pre-registro (Sunrise) Nuestro análisis demostró que la adición del requisito del período de notificación de 30 días al Pre-registro (Sunrise) claramente entraría dentro de la categoría de la implementación. En el asesoramiento sobre políticas no se recomendaron períodos específicos de tiempo, y este es un medio razonable para ayudar a abordar las inquietudes relacionadas a la comunicación de los titulares de derechos, especialmente teniendo en cuenta la gran cantidad de solicitudes de gTLD.
  • Reclamos de Marcas. La extensión para los Reclamos de Marcas de 60 a 90 días también puede ser considerada como una implementación, ya que trata acerca de continuar un servicio que ya es requerido. La inclusión de un proceso de “Reclamos 2″ también podría considerarse como parte de la categoría de implementación dado que es un servicio opcional para titulares de derechos que esta basado en tarifas, y es más ligero que lo que los registros y registradores habrán implementado en el período de Reclamos de Marcas 1. Este servicio está previsto para beneficiar a ambos, los consumidores y los titulares de derechos, y es consistente con los objetivos del servicio de Reclamos de Marcas que desarrolló la comunidad. Con respecto a los costos adicionales incurridos por los registros y registradores, preveo que estas tarifas se pueden compensar cuando se implemente el proceso, ya que una parte de las tarifas por este servicio voluntario que serán recolectadas por IBM se compartirán con los registros y registradores.
  • Alcance de los Reclamos de Marcas. Se puede considerar como parte de la implementación la inclusión de cadenas de caracteres que anteriormente fueron registradas de forma abusiva en el Centro de Información y Protección de Marcas a los efectos de los Reclamos de Marcas, ya que permite asociar una cantidad limitada de nombres de dominios adicionales a un registro de marcas. Esto corresponde con el asesoramiento sobre políticas que establece que los derechos de marcas deberían ser protegidos, y, dado que la inclusión de tales marcas se basarían únicamente en una decisión tomada por la UDRP o un proceso judicial, el proceso simplemente tendría en cuenta los nombres para los que los problemas ya hayan sido evaluados y considerados. Sin embargo, dadas las discusiones intensivas anteriores que se realizaron sobre el alcance de las protecciones asociadas a un registro del CCI, en el cual se involucra el IRT y el STI, creemos que necesitamos la orientación del Consejo de la GNSO para abordar este tema.

Le estaré enviando un mensaje al Consejo de la GNSO para pedir su orientación en lo que respecta al Alcance de los Reclamos de Marcas. Además, el modelo preliminar (strawman) se publicará esta semana para el comentario público. También estoy incluyendo, junto con el modelo preliminar (strawman), una propuesta revisada de la IPC y la BC sobre registros preventivos limitados que están diseñados para abordar la necesidad de registros defensivos de segundo nivel. Si bien actualmente esta propuesta no forma parte del modelo preliminar (strawman), también estaré solicitando orientación de parte del Consejo de la GNSO con respecto a esta misma.

El modelo preliminar (strawman) fue desarrollado por participantes que fueron seleccionados por los grupos de partes interesadas de la GNSO. Les agradezco por colaborar conmigo en explorar un conjunto balanceado de mejoras para el TMCH y para los mecanismos de protección de derechos que se encuentran disponibles para los nuevos gTLD.

Planeo reunir este grupo una vez más para discutir acerca de los resultados de las discusiones sobre contratos que planearemos realizar con IBM. Espero que esto se lleve a cabo a finales de esta semana, o la semana siguiente.

Cordialmente,
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."