Informe sobre la Patente de Software en una Empresa China

Un registro de la patente de software puede conectar una versión de software nombrada con un titular de derechos registrado. No certifica que el software funcione, que la compilación actual sea la versión registrada, ni que el proveedor posea cada componente en el producto.

Esa frontera es especialmente importante al revisar una plataforma industrial, una aplicación móvil, un controlador integrado, un proveedor de SaaS o un proveedor de dispositivos inteligentes. Un informe de empresa puede revelar un registro de utilidad, pero la pregunta de adquisición es más estrecha: ¿apoya este registro el papel reclamado por el proveedor en este producto?

¿Qué está registrado?

China's Regulaciones para la Protección del Software Informático definen el software como programas informáticos y su documentación relacionada. El código fuente y el código objeto del mismo programa se tratan como la misma obra bajo esa definición. El concepto es por lo tanto más específico que una idea de producto, un servicio en la nube, una marca o todo un negocio tecnológico.

El Resumen de software de la OMPI traza otra línea útil: la patente protege la expresión, no las ideas, procedimientos, métodos de operación o conceptos matemáticos como tales. Una inscripción para `Plataforma de Enrutamiento de Almacenes V1.0` no es propiedad exclusiva de cada concepto de enrutamiento de almacén o algoritmo descrito en una presentación de ventas.

Cuando un informe de empresa enumera inscripciones de software junto con patentes y marcas, mantenga sus propósitos separados. El mapa de uso de registros de PI explica la cartera más amplia; esta página se mantiene con el registro de software.

El registro es evidencia, no el nacimiento de la patente

Las regulaciones de protección dicen que la patente de software surge cuando se completa el desarrollo. También permiten que un titular registre y describa el documento de registro resultante como evidencia preliminar de los asuntos registrados. China's Medidas de Registro de la Patente de Software fomentan el registro y establecen los requisitos del solicitante y del documento.

Así que evite dos declaraciones comunes:

• `La empresa obtuvo la patente en la fecha de registro.` El derecho subyacente no es creado por esa fecha administrativa.
• `No se encontró ningún registro, por lo que la empresa no tiene patente.` Un resultado de búsqueda ausente no resuelve si existe software protegible o derechos contractuales.

La distinción también explica por qué el volumen de registro no es una clasificación de calidad. La Administración Nacional de Derechos de Autor informó 3,182,829 registros de derechos de autor de software en 2025. Ese es un contexto administrativo amplio, no evidencia de que un proveedor con 100 registros sea mejor que uno con cinco registros relevantes.

Leer seis campos como una tarjeta de versión

La disponibilidad varía según la fuente, pero un extracto de registro útil puede contener los siguientes campos. Preserve el texto chino y la fecha de recuperación en lugar de traducir un sufijo de versión o nombre de entidad.

Nombre completo del software y nombre corto

Compare la redacción exacta con la cotización, la pantalla de inicio de sesión, el manual de usuario y el anexo del contrato. Los nombres similares pueden describir una familia de productos en lugar de la versión adquirida.

Número de versión

`V1.0` no es intercambiable con un `V3.2` demostrado. Pregunte cómo se relacionan las versiones, módulos y ediciones white-label con la versión registrada.

Titular registrado o titular de derechos registrado

Coincidir el nombre legal en chino con la empresa contratante. Si nombra a un fundador, empleado, afiliado o desarrollador externo, documente la cadena de propiedad o licencia en lugar de tratar la diferencia como automáticamente legítima o sospechosa.

Fecha de finalización del desarrollo

Este es el punto de finalización reportado para el software registrado. No es una auditoría independiente del repositorio de código, la completitud de las funciones ni la calidad de la versión.

Fecha de primera publicación, si se muestra

Esto puede ayudar a reconstruir la cronología. `Sin publicar`, vacío o no disponible no debe reescribirse como `nunca usado` o `nunca entregado`.

Fecha y número de registro

Use estos datos para identificar y datar el registro administrativo. No sustituya la fecha de registro por la fecha de finalización, la fecha de primera publicación o la fecha de lanzamiento actual del producto.

El titular de los derechos puede no ser el vendedor

Una discrepancia requiere una explicación de la relación. El software puede haber sido desarrollado por empleados, desarrollado conjuntamente, encargado a un contratista, transferido, licenciado o retenido en otra empresa del grupo. Las regulaciones de protección contienen reglas predeterminadas específicas para el software encargado y cierto software desarrollado por empleados, pero un comprador no debe intentar resolver la propiedad legal a partir de un resultado público breve.

Solicite los documentos que se ajusten a la historia real: acuerdo de desarrollo, cláusulas de propiedad intelectual laboral, instrumento de transferencia, licencia, autorización de empresa del grupo, registro de fusión o cambio de nombre, y una lista de componentes de terceros y de código abierto. Verifique cada empresa por su identidad legal china. Si el vendedor dice que el desarrollador es un afiliado, compare la relación con la parte contractual y el equipo de servicio en lugar de colapsar ambos nombres en una sola empresa.

El ámbito de actividad puede proporcionar contexto sobre el desarrollo de software o servicios tecnológicos, pero no decide la propiedad de los derechos de autor. Use el revisión del ámbito de actividad para ese campo separado.

Tres fechas no constituyen un historial de lanzamientos

Un registro puede proporcionarle una fecha de finalización, una fecha de primera publicación y una fecha de registro. Ninguna necesariamente le indica qué versión está ejecutándose en la demostración hoy, cuándo se añadió una función, quién mantiene la producción o si el proveedor puede restaurar el servicio tras una falla.

Construya una cronología breve a partir de registros creados para la entrega de software:

1. título registrado, versión y fecha de finalización reportada;
2. notas de lanzamiento e identificadores de compilación para la versión cotizada;
3. registros de aceptación con fecha de cliente o internos;
4. evidencia de repositorio, implementación o depósito en garantía apropiada para el acuerdo;
5. propietario actual del soporte, subcontratistas y política de fin de vida.

El objetivo no es exigir el código fuente para cada compra. Se trata de que la evidencia sea proporcional a la dependencia: una utilidad fuera de línea utilizada por un analista necesita menos evidencia de continuidad que un software que controla una línea de producción o almacena datos regulados.

Caso: el informe dice V1.0, la demostración dice V3.2

Un proveedor ficticio demuestra `PlantWatch 3.2`, una plataforma de monitoreo incluida con sensores de fábrica. El informe de la empresa enumera `Plataforma de Monitoreo de Equipos PlantWatch V1.0`, registrada hace tres años a favor de la misma entidad legal china. El título, el propietario y la cronología son plausibles. El registro respalda la continuidad entre la empresa y una versión anterior del producto.

No autentica V3.2. El comprador solicita notas de la versión que vinculen V1.0 con V3.2, el número de compilación mostrado en la demostración, una lista de características por versión, evidencia reciente de aceptación y la divulgación del componente de mapeo suministrado por otro desarrollador. El contrato nombra entonces la versión entregable, el plazo de soporte, el método de exportación de datos, las obligaciones de seguridad, las pruebas de aceptación y la responsabilidad por las licencias de terceros.

La conclusión resultante no es ni `derechos de autor verificados, aprobar` ni `desajuste de versión, rechazar`. Es: `El registro respalda una relación producto-empresa anterior; la propiedad de la versión actual, los componentes y los controles de entrega requieren la evidencia enumerada.`

Lo que el registro no prueba

• Función: si las características prometidas funcionan bajo la carga de trabajo del comprador.
• Seguridad: gestión de vulnerabilidades, control de acceso, cifrado, respuesta a incidentes o desarrollo seguro.
• Procedencia del código: si cada módulo es original, está licenciado, es de código abierto o es suministrado por un contratista.
• Operaciones: propietario del alojamiento, copias de seguridad, recuperación ante desastres, personal de soporte y tiempo de actividad.
• Derechos del producto: si el vendedor tiene autoridad para licenciar la compilación actual en el territorio del comprador y para el caso de uso.

Estos requieren pruebas técnicas, composición de software o revisión de seguridad, evidencia contractual y, a veces, asesoramiento legal especializado. Un registro de la empresa puede ayudar a dirigir esas verificaciones; no puede realizarlas.

Redactar una conclusión acotada del informe de la empresa

Indique el registro exacto, la coincidencia de identidad, la relación de versiones, el límite de fecha y la próxima acción. Por ejemplo:

El informe identifica `Plataforma de Monitoreo de Equipos PlantWatch V1.0` registrada a favor de la entidad contratante verificada. Esto respalda una relación software-empresa para la versión nombrada según las fechas registradas. No establece la propiedad, la seguridad o el rendimiento de la compilación V3.2 citada. Obtenga la cadena de versiones, la divulgación de componentes, la evidencia de aceptación y la licencia contractual antes de aprobar.

Adjunte el extracto de origen y la respuesta del proveedor al archivo de aprobación del proveedor. Un informe de empresa de muestra muestra cómo el módulo de PI se sitúa junto a los datos de identidad y operativos; no debe leerse de forma aislada.

Escale el desarrollo personalizado de alto valor, la propiedad disputada, el acceso al código fuente, las licencias transfronterizas, las preocupaciones por infracción o la continuidad crítica para el negocio a revisores técnicos y legales calificados. Para la adquisición ordinaria, coloque el resultado en la secuencia de evidencia precontractual y registre la redacción acotada en el memo de aprobación interno.