Full Spectrum IP cover for Software

IP protection for software extends well beyond patenting of inventions and indeed patenting a software invention may be advisable if a third party can only access the inputs and outputs of a service with the processing being carried out remotely and securely, for example in some Software As A Service (SaaS) products.

As can be seen from the figure below the progression of a software development from inception to market has a number of phases and patenting only covers one of those phases, the actual solution to the requirement phase. Even within the solution phase there are limitations placed upon what can be patented which vary between jurisdictions leading to potentially variable outcomes. In general it is possible to obtain patent protection for a technical solution, for example controlling a piece of equipment, but not for a business solution, for example inventory control.

In many instances the other forms of IP protection are overlooked in the rush to patent protection, where a more nuanced and considered tactical approach to IP protection can yield a more effective scope of protection.

Software is protected under copyright as a “literary work” with all preparatory works and the code itself, both source and executable, protected. Copyright does not cover what the software does, just the literal code on the screen. The inclusion of certain types of Open Source code in software brings with it the risk of so called “copyleft” and patent license requirements that can undermine your control of the software that you develop so it is always advisable to have an IP Policy that clearly sets out usage restrictions on Open Source code and to regularly scan your software for risky Open Source components associated with “copyleft” type licenses.

Trade secrets in software cover the development process right up until the Go To Market phase and can cover not only technical solutions but also business solutions and, for example, customer databases etc. However, trade secrets require that “reasonable measures” are taken to maintain secrecy of the software under development. Reasonable measures would include physical and technical solutions to limit and monitor access to trade secret information, for example locked server rooms, multi-factor authentication, mobile device management, and data loss prevention software being implemented.

Developers working on projects considered for trade secret protection should have to execute project specific non-disclosure agreements in addition to any confidentiality obligations in their employment contracts. Non-disclosure agreements should have secrecy obligations, audit rights, and provisions for post-relationship control. Object code provided to customers should include digital rights management and robust licensing terms containing anti-reverse engineering provisions and there should be no release of source code.

The patenting of software, i.e. the code itself, is not allowed nor, generally, is the patenting of a process that solves a purely business or administrative problem. It is necessary to establish a technical problem that is solved by the invention and frame the solution to that problem in a technical manner. The patent protects the idea behind the technical solution that the code achieves, i.e. what your software does, the code is not the idea. The mere processing of data without it having a technical result, is highly unlikely to be patentable.

One thing that is increasingly being considered by patent offices is, is the invention sufficiently well described in the patent application for someone to read it and then be able implement the invention? A “black box” transformation is not enough, the patent application must describe what goes on inside the “black box”. A listing of the code is not necessary but a detailed description of the algorithms employed may well be necessary.

Murgitroyd has published an article on recent developments in the patenting of computer simulations.

When developing an IP strategy for a software product there are number of points that should be considered, including:

• What is the nature of the product? (Technical, marketing…..)
• Is Open Source software (OSS) to be used and if so, what are the implications for the IP protection of the licenses associated with the OSS used?
• Is the software implementing a functionality that is new to the market?;
• Is it a technical improvement over an existing product?
• Is interoperability with other devices required?
• Is it part of a platform for which a trade name is used?

The answers to these questions, and others, will inform the approach to be adopted in protecting your investment in the software and Murgitroyd are here to help you navigate to the solution that suits you and your product in a practical and commercially aware manner.