Blog & Noticias

En el contexto de los muchos desafíos anteriormente expuestos, ahora proporcionamos seis consideraciones para profesionales de la PI y clientes que emplean metodologías ágiles de desarrollo con el fin de identificar eficazmente y proteger la propiedad intelectual de contratos de confidencialidad con cláusulas. Durante las muchas fases de revisión de usuario de un proyecto ágil, un desarrollador tiene que revelar necesariamente el producto en fase de desarrollo a un cliente potencial (externo) con el fin de obtener información valiosa acerca de las funciones simplemente desarrolladas. Por lo tanto, cómo un cliente puede proteger su propiedad intelectual? Pues bien, un acuerdo de confidencialidad (NDA) -incluso si se llama un "acuerdo asesor de productos", es una necesidad. Pero un acuerdo de confidencialidad con una "cláusula de retroalimentación" es aún mejor. Un ejemplo simple de una cláusula de este tipo es: No obstante cualquier otra disposición de este Acuerdo, si el cliente proporciona cualquier idea, sugerencia o recomendación en relación con el Producto ( "Comentarios"), la empresa es libre de utilizar e incorporar dichos comentarios en sus productos, sin pago de regalías u otra consideración al cliente, siempre y cuando la empresa no infrinja cualquiera de los derechos de propiedad intelectual del cliente en el comentario de lo que existía antes del momento de proporcionar dichos comentarios”. Un ejemplo más avanzado es el siguiente: El cliente entiende que, como asesor del producto, la empresa podrá solicitar que el cliente: (i) proporcione información o inputs en una serie de temas, incluyendo pero no limitado a el diseño, la funcionalidad, la interfaz de usuario, el desarrollo y la integración o liberar la estrategia de productos o servicios de la empresa; y (ii) participar en grupos de discusión y / o la evaluación de utilización de determinados productos de la empresa, prototipos o maquetas. A menos que se acuerde por escrito por la compañía y el cliente en virtud de un acuerdo por separado, el cliente reconoce y acepta que cualquier retroalimentación, de entrada, o la participación por parte del cliente en cualquiera de dichas actividades (colectivamente, "Feedback") se proporciona de forma voluntaria solamente y el cliente no podrá solicitar o tener derecho a recibir ningún tipo de compensación en cualquier forma por tales comentarios. Además, el cliente acepta que ninguna captación proporcionada por la misma deberá incluir información confidencial o privada que es propiedad de Cliente o cualquier tercero, o que el Cliente está obligado a mantener la confidencialidad de la ley o de otro modo. En la medida en que no se crea ninguna PI, concebida, desarrollada, o hecha durante el transcurso de la participación del cliente como un asesor de producto, que será propiedad exclusiva y se ceda a la sociedad, ya que se basa en, hace referencias a , incorpora, o haga uso de, en su totalidad o en parte, de las participaciones. Acuerdos de personal con cláusulas de asignación de PI Dado el entorno actual en el que los trabajadores son tan móviles como las aplicaciones que crean, una de las mayores amenazas a la propiedad intelectual de una empresa, por desgracia, son sus propios empleados y contratistas. Por lo tanto, es prudente que los profesionales de la PI asesoren a sus clientes a: (1) entrar en acuerdos de empleo y contratistas que contienen obligaciones de confidencialidad y cláusulas de asignación de PI con todo el personal sobre su compromiso inicial con la empresa; y (2) poner en práctica física y controles de seguridad de TI (por ejemplo, sistemas de gestión de documentos, software Data Loss Prevention, bloque USB, etc.) para controlar el acceso a los archivos de código fuente y los documentos de diseño. Además, el fomento de una cultura de la formación de PI (ambas formales e informales) y los incentivos al inventor (por ejemplo, la remuneración, placas de reconocimiento, cenas anuales, etc.) se asegurará de que tu personal no sólo sea consciente de la propiedad intelectual, sino también con entusiasmo participe en su construcción, protección y observancia. Información de copyright El código de software y su resultante interfaz gráfica de usuario (GUI) y los diseños de experiencia del usuario (UX) son, por supuesto, también objeto de protección de derechos de autor, que se atribuye de forma automática cuando se crean. Marcar los ficheros de código con los avisos de copyright proporciona cierta protección durante sprints ágiles para al menos advertir a todo el personal con acceso (autorizados y no autorizados) que esos archivos contienen la propiedad intelectual de la empresa. El registro de derechos de autor real de al menos una porción de código de software de un proyecto (por ejemplo, cada x iteraciones o cada tantos meses) también se deberá considerar dar a los clientes la posibilidad de enviar cartas de cese y desista. Por lo tanto, mientras que el diseño de un producto de software debe ser evaluada partir de una perspectiva de patentes (utilidad y diseño), la protección de derechos de autor puede también ser una herramienta rápida y de bajo costo para proteger la propiedad intelectual durante y después del desarrollo ágil. Un ejemplo sencillo de un aviso de copyright de los archivos de proyecto es "©" o "Derechos de autor", seguido del año y el nombre de la compañía. Un aviso de copyright más avanzado para recordar al personal de la importancia de la propiedad intelectual es el siguiente: / * * Copyright © [año] por [la empresa]. Todos los derechos reservados. * El derecho de autor a los programas de ordenador en este documento es propiedad de la empresa. * El software puede ser utilizado y / o copiarse sólo con el permiso por escrito de la empresa de acuerdo con los términos y condiciones estipulados en el el acuerdo / contrato en el que el software ha sido suministrado. * / Tratar como un secreto comercial y luego evaluar la protección de patente Las leyes de secretos comerciales ofrecen protección para una variedad de innovaciones relacionadas con el software, como cualquier "fórmula, patrón, compilación, programa, dispositivo, método, técnica o proceso." Por lo tanto, cualquier código o diseño que tenga valor y que no sea de conocimiento general por el público puede ser clasificado y protegido como secreto comercial, siempre y cuando se tomen las medidas razonables para mantener la confidencialidad. Por lo tanto, asegurarse de que los clientes tengan un protocolo de protección del secreto comercial con pasos definidos para marcar, registrar y realizar un seguimiento de materiales secretos comerciales (por ejemplo, código, comentarios, algoritmos, documentos de diseño, etc.) es esencial. Por ejemplo, el código de software, comentarios, know-how, procesos, algoritmos, etc., pueden ser etiquetados y protegidos como secretos comerciales. El protocolo de secreto comercial de un cliente a menudo se denomina una "política de protección de datos" -debería incluir pasos para determinar: (1) si el asunto ya es conocido, (2) si el objeto es capaz de ser mantenido en secreto de los usuarios finales, y (3) si el acceso a la materia objeto puede ser controlado. Una vez que un protocolo de protección de secreto comercial está en su lugar y se incorpora en el proceso de desarrollo ágil (por ejemplo, antes de la fase de revisión de usuario), implementar el protocolo implica: (1) el marcado y el almacenamiento de materiales secretos comerciales, separados de materiales secretos no comerciales; (2) educar a los empleados (por ejemplo, a través de orientación para nuevos empleados, recordatorios a los empleados actuales, y entrevistas a empleados que van de salida) sobre la importancia de marcar y mantener los materiales de secreto comercial confidenciales y restringidos; (3) la ejecución adecuada de confidencialidad o acuerdos de confidencialidad; y (4) la revisión periódica de los documentos y los procedimientos para su cumplimiento. Si bien no hay "palabras mágicas" que deben estar presentes para indicar un secreto comercial, frases reconocibles incluyen "secreto comercial", "confidencial" o "propiedad de la información." Estas frases se pueden añadir a un encabezado, pie de página, comentarios, fondo , etc., dentro de cualquier archivo de documento de código fuente, los comentarios / notas, manual, o cualquier otra documentación del proyecto. Un ejemplo de una etiqueta de secreto comercial más detallada es el siguiente: Este documento contiene información de secreto comercial confidencial y patente propiedad y control de la empresa. La reproducción o distribución de este documento, o el uso de la información contenida en el presente documento en modo alguno, está estrictamente prohibidos sin la autorización expresa de la compañía. Se debe tener cuidado de mantener la confidencialidad de este documento y su información constituyente y evitar su divulgación fuera de las instalaciones de la compañía. La información de etiquetado como un secreto comercial durante un sprint puede ser revisada y quizás más tarde presentarse como una solicitud de patente en un sprint posterior u opinión de cierre. La presentación de solicitudes de patente Dado el enfoque iterativo del desarrollo ágil, un mejor servicio podrá efectuarse mediante la presentación de una o más solicitudes de patente (o derecho de autor) durante cada sprint. Una reunión inicial en la fase de planificación se puede utilizar para establecer una hoja de ruta aproximada para la presentación de solicitudes. La información de divulgación de la invención puede entonces ser recogida durante la fase de desarrollo para la presentación antes de la fase de revisión de usuario. Con uno o más solicitudes presentadas de acuerdo con un ritmo regular durante todo el proceso de desarrollo multisprint, uno o más pedidos de patente pueden ser presentadas al final del proyecto. Este ritmo debe permitir tiempo suficiente tiempo para preparar PI importante y fuerte sin perder ningún beneficio de las fechas de prioridad. Mientras que una solicitud, por supuesto, debe incluir una investigación exhaustiva, permitiendo descripción de la materia pertinente, pudiendo ignorar algunas "sutilezas" y dedicar más tiempo a la redacción de las reivindicaciones, lo que permite al practicante ajustar el ritmo de presentación necesario por la corta duración de los sprints. Tal proceso de redacción también puede ayudar a reducir los costos generales debido a las sumas que se gastan en la preparación de las solicitudes. Un enfoque en una sola innovación, discreta (o unas pocas innovaciones estrechamente relacionadas) en cada archivo provisional debería permitir al practicante optimizar su eficiencia de redacción, a la vez que minimiza ida y vuelta entre el profesional y los inventores, que no tienen mucho tiempo para gastar en cuestiones de PI en un ciclo de sprint típico. Luego, al final de un proyecto, los inventores, practicantes de PI y los administradores pueden reflexionar sobre el trabajo de desarrollo realizado y las solicitudes presentadas, y revisar la estrategia de presentación con el fin de ultimar los documentos presentados necesarios para el producto resultante. Las lecciones aprendidas de un sprint al siguiente pueden alterar o afectar la estrategia inicial de protección PI. Pueden incluir los documentos presentados de utilidad para proteger la funcionalidad del producto y limaduras de diseño para proteger la interfaz gráfica de usuario del producto y UX. Divulgaciones de invenciones estructuradas y solicitudes de patente La redacción de las solicitudes provisionales y no provisionales de acuerdo con un enfoque modular y / o una plantilla creada para el producto en particular en fase de desarrollo debe disminuir el tiempo (y dinero) que se necesita para preparar la pluralidad de notificaciones. Por ejemplo, un médico puede desarrollar una o más plantillas de aplicaciones que proporcionan cierta información de base, sistemas y métodos de fondo, la terminología, y otros marcos, en la que cada presentación se puede construir. Con el uso de este tipo de plantillas, el practicante puede entonces centrarse en la descripción de los aspectos inventivos de la aplicación sin tener que gastar demasiado tiempo en reinventar la rueda, a la vez que mantener el ritmo de los procesos de desarrollo ágil. Términos más cortos se traducirán en una revisión más corta y proporcionará un mejor ajuste dentro de las limitaciones de tiempo y de recursos impuestos por el desarrollo ágil. Gestión de PI al ritmo del desarrollo ágil como se discutió anteriormente, profesionales de la PI tienen muchas herramientas a su disposición para asesorar y servir a sus clientes en la identificación y protección de la propiedad intelectual a la vez que se adaptan a las exigencias particulares de las diversas metodologías ágiles de desarrollo de software empleados por dichos clientes. Estos enfoques no son mutuamente excluyentes y se pueden aplicar en diversas combinaciones para proporcionar una protección de PI robusta. Por ejemplo, el software desarrollado a través de un proceso ágil puede estar protegido por un acuerdo de confidencialidad, derechos de autor, secreto comercial (en su totalidad o en parte), y múltiples solicitudes modulares basadas en plantillas seguido de al menos una aplicación completa. El desarrollo ágil de software es similar a otras innovaciones producidas por diversas metodologías de I + D por una estrategia multifacética de PI, compromiso con el cliente, y un control frecuente por un abogado de PI. El objetivo del practicante debe ser reflejar la metodología de desarrollo ágil del cliente con las seis consideraciones discutidas anteriormente. Esto resulta en un equipo de desarrollo PI-educado para entrar en la fase de planificación, donde se identifican las prioridades iniciales PI. En la fase de sprint, las invenciones pueden ser extraídas, y en la fase de revisión de usuario, se realizan los documentos presentados provisionales. Durante la fase retrospectiva, las estrategias de protección PI pueden ser revisados, confirmaron, y finalizan. El uso de este ritmo, cada iteración del proyecto ágil proporciona una oportunidad posterior para perfeccionar la estrategia de captura/protección de PI. El producto resultante puede entonces ser revisado antes de ser liberado para identificar nuevas oportunidades para las solicitudes de patentes (nacionales e internacionales) y otros mecanismos de protección (por ejemplo, marcas comerciales y derechos de autor registros, acuerdos de licencia de usuario final, etc.). Conclusión Cada vez son más los clientes de las empresas de todos los tamaños y de diferentes industrias que están produciendo (y comenzarán a producir) software utilizando metodologías ágiles de desarrollo en su intento de producir software de mayor calidad más rápidamente. Si bien la adopción de estos enfoques ágiles no tiene ningún efecto sobre los propios derechos de propiedad intelectual, no afectarán la forma en profesionales de la PI deben aconsejar a sus clientes. Es decir, los derechos de propiedad intelectual son derechos de propiedad intelectual, y los requisitos básicos para su registro y ejecución, obviamente, permanecen sin cambios. Pero, si el primer mandamiento de negocios dice "conoce a tu cliente", es una guía, profesionales de la PI deben informarse acerca de las metodologías ágiles que sus clientes usan para innovar y ser más ágiles en su enfoque de asesoramiento y garantizar los derechos de propiedad intelectual.