Obtaining a strong, enforceable patent that protects your software invention is often difficult. Here I will touch on some approaches to stack the odds in your favour.
Why is it difficult to patent software?
There are a number of hurdles that must be overcome to obtain a patent for a software invention. These include:
- Being new: at least one aspect of your invention must differ from other solutions available to the public. This includes solutions described in other patent applications, blog posts, manuals, online documentation and white papers.
- Being inventive: not only must your invention have a differing feature, that differing feature needs to be non-obvious. If the differing feature is common knowledge, e.g. is a common feature described in text books or on Wikipedia, and it is straightforward to use it in the context of the other known features, then your invention will be deemed obvious. Likewise if the differing feature is described in another document, and it would be obvious to combine this other document with the pre-existing solution providing the other features, then your inventive will be said to lack an inventive step.
- Being patentable: your software invention must meet requirements set by law for patentable subject matter. Each jurisdiction has slightly different rules. Normally, statute sets some very broad categories of excluded subject matter. Individual cases and hearings then provide a body of case law that says which areas are allowable and which areas are not. For example, in Europe you need to show that the differing feature provides a ‘technical’ effect, which is often an engineering improvement.
Patenting software also taxes patent attorneys and patent examiners. With mechanical products, you can often see and feel the invention. Similarly, pharmaceutical inventions may be defined through sets of well-defined chemical formulae. Software is harder to visualise – there may be multiple technology layers in an implementation stack and many non-essential interoperating parts. This can often lead to poor patent specifications and misunderstandings.
Also if a patent claim is too specific then it will be easy for a software developer to work around. Most inventions will need to transcend a particular programming language or technology to cover ports to different platforms and to future-proof a patent’s value. However, if a patent claim is too broad, it is often deemed too abstract to be patentable and may also run afoul of clarity provisions.
What do these difficulties mean in practice?
In practice these difficulties often lead to:
- Low grant rates;
- Validity challenges;
- High prosecution spend; or
- Patent avoidance.
These factors often interact to form a vicious cycle of mutual distrust: too many poor quality patent specifications are filed, leading to cynicism from patent examiners and the public, which leads to knee-jerk rejections and lobbying, which in turn undermines confidence in the system from businesses.
The first thing software companies can do is to find the right patent attorney or attorney firm. There are a few attorneys who deal with software day-in-day-out. These need to be sought out. Look for an attorney with experience of working for a large software company, e.g. Microsoft, IBM, Hewlett-Packard, Oracle, SAS, Amazon, Google. The European Patent Office allows you to search by representative to see example applicants.
The second thing software companies can do is to set high standards for their patent specifications. The recent change in practice in the US will hopefully catalyse this. Technical or engineering features should be defined in detail; any high-level marketing terms or IT jargon should be jettisoned. A strong technical problem should be eluded to, and there should be a good set of tiered fall-back positions, each with their own defined engineering advantages.
The third thing software companies can do is to keep on top of the case law in different jurisdictions. Your patent attorney may offer to help you with this. At a simple level, a one page table can show what kind of inventions have been allowed and what kind of inventions have been refused. For example, UK hearing officers often find that database management improvements are not allowed, whereas European examiners find these are technical.