Fwd: Reunión de Los Ángeles para discutir temas de protección de TM
devtee en gmail.com
devtee en gmail.com
Mar Nov 13 22:58:06 UTC 2012
[[--Translated text (en -> es)--]]
Asunto: Fwd: Reunión de Los Ángeles para discutir temas de protección de TM
De: devtee en gmail.com
---------- Mensaje reenviado ----------
De: Alan Greenberg <alan.greenberg en mcgill.ca>
Fecha: Mon, Nov 12, 2012 a las 14:42
Asunto: [ALAC] reuniones en Los Ángeles para discutir los temas de protección de MT
A: Lista de Trabajo ALAC <alac en atlarge-lists.icann.org>
NOTA: ESTE MENSAJE ES LARGO, PERO SOLO TIENE UNOS DÍAS en los que actuar.
En Toronto, el IPC y BC presenta una lista de los derechos sugeridos
mecanismos de protección a la ICANN. El documento se puede encontrar en
http://www.icann.org/en/news/correspondence/metalitz-to-pritz-17oct12-en.pdf
.
La sustancia era los siguientes 8 puntos.
1. Extender Sunrise Period Launch de 30 a 60 días con un estándar
proceso.
2. Extender la TMCH y Avisos Reclamaciones por tiempo indefinido;
asegurar que el proceso es fácil de usar, seguro y estable.
3.Complete la URS como una alternativa de bajo costo y mejorar su
utilidad - si es necesario, la ICANN podría suscribir por un período inicial.
4. Implementar un mecanismo para que los propietarios de marcas para evitar el segundo nivel
registro de sus marcas (coincidencias exactas, además de cadenas de caracteres
previamente se sepa ha sido registrado o utilizado de forma abusiva)
en todos los registros, mediante el pago de una tarifa razonable, con
garantías apropiadas para los solicitantes de registro con un derecho o interés legítimo.
5. Validar la información de contacto para los registrantes en WHOIS.
6. Todos los registradores que actúan en los registros de nuevos gTLD deben adherirse a un
modificado RAA para todos los registros de gTLD que patrocinan.
7. Exigir el cumplimiento de todos los compromisos del registro para aplicaciones estándar.
8. Expandir TM Servicio de Reclamaciones para cubrir al menos los hilos previamente
encontrado que han sido abusivamente registrado o utilizado.
Tenga en cuenta que estas declaraciones son más bien vagos en algunos casos, pero no
más detalles se han proporcionado.
Una reunión para limar asperezas y aclarar cuestiones sobre el TMCH era
celebrada en Bruselas cerca de 2 semanas. Los resultados se pueden encontrar en
http://blog.icann.org/2012/11/building-a-secure-and-reliable-trademark-clearinghouse/
.
Habrá una reunión de seguimiento en Los Angeles para discutir, (tal vez
entre otras cosas), las propuestas de la BBC / IPC. Mi entendimiento es que
Yo una probable Evan serán invitados a participar (de forma remota, ya que no
financiación de los viajes está incluido).
Tras las conversaciones mantenidas con Evan y Olivier, asà como Kathy Kleiman
y Robin bruto de NCUC, esto es lo que yo creo que la actual
posiciones para recibir el apoyo de ALAC ser.
SI USTED SIENTE QUE CUALQUIERA DE ESTE DEBE SER CAMBIADO POR FAVOR HABLE CON RAPIDEZ.
==========================
Nuestra posición general es que preferirÃa no hacer ningún
cambios sustantivos en esta fecha tardÃa, y en particular los que no
razonablemente puede considerarse polÃtica. Esto se dice con la plena
entendiendo que en todo el proceso de nuevos gTLD, las partes de la
comunidad han considerado a menudo cosas que ellos quieren cambiar para ser
"Aplicación", y las cosas que ellos no quieren cambiar para ser
"PolÃtica".De hecho, la discusión STI entero
(Http://gnso.icann.org/issues/sti/sti-wt-recommendations-11dec09-en.pdf)
se consideró que uno de ejecución y la investigación de la polÃtica "
implicaciones "de la TMCH y URS. Tenga en cuenta que algunas de las propuestas
son claramente no "polÃtica" desde el punto de vista de la GNSO.
Dicho esto, es posible que el cambio se producen basándose en la
cuestiones planteadas por el BC / IPC, y el ALAC debe tener en cuenta la
cuestiones especÃficas.
1. Extender Sunrise Period Launch de 30 a 60 dÃas con un estándar
proceso.
ALAC no tiene sentimientos fuertes sobre la comprensión this.My es que puede
ya se han resuelto durante la reunión de Bruselas.
2. Extender la TMCH y Avisos Reclamaciones por tiempo indefinido;
asegurar que el proceso es fácil de usar, seguro y estable.
Un Reclamo TM envÃa un aviso a un posible solicitante de registro de que el nombre
que está registrando los posibles solapamientos con un plazo de TM.No hace
detener el registro, pero le pide que confirme que el solicitante de registro
su uso es legÃtimo y no viola los derechos de TM (TM desde
los derechos son especÃficos para el tipo de servicio / producto ofrecido y un
geográfico local, esto es bastante posible). El informe dice que las ITS
Post-Lanzamiento de reclamos no son obligatorios. El AG dice que, como mÃnimo,
Las reclamaciones se deben utilizar durante 60 dÃas tras el registro general de
disponibilidad. Puesto que ninguno de estos términos se definen completamente, es
No está claro si estos dos requisitos conflicto o son
simultáneamente posible. Uno de los resultados de la reunión de Bruselas
es concretar algunas definiciones, asà que quizás esto se aclarará.
A pesar de ello, el ALAC emitió un informe de la minorÃa a la ITS
diciendo que con algunas reservas especÃficas, apoyamos curso TM
Reclamaciones. Asà que son básicamente de apoyo de la solicitud.
3. Complete la URS como una alternativa de bajo costo y mejorar su
utilidad - si es necesario, la ICANN podrÃa suscribir por un perÃodo inicial.
Esto parece como una declaración de la maternidad y, como tal, no tiene ALAC
problema con él.La única reserva es el significado exacto de
"Aumentar su utilidad". Si esto es lo que implica un cambio sustantivo, que
es necesario considerarlo en sus méritos. Dicho esto, el ALAC en
su declaración minorÃa habÃa apoyado la idea de permitir a URS
reclamante que fue exitosa para tener el dominio transferida a ellas
similar a lo que se permite después de una UDRP éxito.
El concepto de ICANN el aseguramiento de la URS para un cierto perÃodo de tiempo, fue
originalmente sugerida por mÃ, asà que lo apoyan en el concepto. El ALAC tiene
Nunca lo discutimos. En este punto, parece que habrá uno o
más URS proveedores que pueden hacerlo por el pago sin subsidios.
4. Implementar un mecanismo para que los propietarios de marcas para evitar el segundo nivel
registro de sus marcas (coincidencias exactas, además de cadenas de caracteres
previamente se sepa ha sido registrado o utilizado de forma abusiva)
en todos los registros, mediante el pago de una tarifa razonable, con
garantÃas apropiadas para los solicitantes de registro con un derecho o interés legÃtimo.
El ALAC en su declaración minorÃa apoyó permitiendo cuerdas para ser
inscrita en el TMCH que incluyó su término TM junto con
términos relacionados con su servicio / producto (es decir, Ford-Trucks). Asà que * puede *
ser de apoyo de la parte de la solicitud. Sin embargo, el término
"Prevenir" es oneroso, incluso con "garantÃas apropiadas".
Le sugerimos una posición que se trata de una modificación de fondo y
no se debe hacer en este momento, sino más bien considerado como en un futuro
polÃtica del proceso. Además, es un valor que no será
significativamente menor si se retrasa un poco.
5. Validar la información de contacto para los registrantes en WHOIS.
El ALAC ciertamente apoya este concepto y nuestra presunción ha sido
que este se incluirá en la RAA siguiente. En la medida en que este
AC / IPC aumenta la demanda pressue en ICANN para asegurar que este
sucede, lo apoyamos.
6. Todos los registradores que actúan en los registros de nuevos gTLD deben adherirse a un
modificado RAA para todos los registros de gTLD que patrocinan.
Esto ya está siendo discutido en el contexto de la RAA nuevo. En
secretarios particulares, creen que no deben estar a una
desventaja competitiva debido a que algunos registradores permanecer en el viejo RAA
y por lo tanto tiene menores costes (tales como los asociados con
verificación). Desde el punto de vista de la ICANN, sin duda habrá
suficientes asuntos relacionados con el cumplimiento de los nuevos gTLD que tienen
todos los registradores que ellos comercializan en el RAA actual sólo puede ser visto
como bueno. ALAC apoya esto.
7. Exigir el cumplimiento de todos los compromisos del registro para aplicaciones estándar.
No está claro exactamente lo que éste significa. Ciertamente ALAC apoya
cualquier posición que fortalece el cumplimiento de su cumplimiento. La referencia
a "Aplicaciones estándar" no está claro. * Puede * significa que al igual que
Comunidad TLD, estándar (es decir, no comunitarios) TLD debe exigir
en honor a la utilización del TLD descrito en la solicitud (en la actualidad
no se requiere tal - pueden solicitar una cadena de TLD para
un propósito y ese propósito el cambio completo sobre la aplicación).
ALAC en general ha defendido este requisito, aunque parece
como que es un poco tarde para imponer a los solicitantes que hayan solicitado
en virtud de la normativa vigente.
8. Expandir TM Servicio de Reclamaciones para cubrir al menos los hilos previamente
encontrado que han sido abusivamente registrado o utilizado.
Esta es una interesante posiblemente nuevo mecanismo de protección TM, y es un
probablemente un subconjunto de la "TM junto con términos relacionados" declaración de que
que hicimos en nuestro informe de minorÃa. Sin embargo, es un sustantivo
cambiar, y como el tema 4, debe ser objeto de un proceso de polÃticas
antes de su implementación.
Alan (y Evan)
_______________________________________________
[[--Original text (en)
http://mm.icann.org/transbot_archive/6a41a7c0a9.html
--]]
Más información sobre la lista de distribución lac-discuss-es