Fwd: Reuni�n de Los �ngeles para discutir temas de protecci�n de TM

[[--Translated text (en -> es)--]] Asunto: Fwd: Reunión de Los Ángeles para discutir temas de protección de TM De: devtee@gmail.com ---------- Mensaje reenviado ---------- De: Alan Greenberg <alan.greenberg@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@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-clear... . 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 --]]