Why is it hard to patent software?

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.
Software

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.

What can we do?

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.

Computer-Related Board of Appeal Decisions from 2014 Case Law Summary

The European Patent Office has now published a case law summary for 2014 as Official Journal supplementary publication 4/2015. Sections I-C-4.1, I-C-5.1, II-A-1, and II-E-1.4 discuss case law that relates to computer-related inventions. The relevant passages are extracted and commented on below.

Skilled Person

T 407/11 held that the relevant skilled person in the context of providing computer-system users with operating assistance via a user interface (e.g. error messages or warnings) was an expert in software ergonomics concerned with the userfriendliness of human-machine interfaces rather than an expert in software programming or in computer technology in the strict sense.

The objective problem to be solved by that skilled person was to prevent a situation whereby the user’s action caused an electronic data-processing system to execute a called function differently from intended (or even to fail to execute it at all).

In the board’s view, however, the technical effect claimed in the application (simpler operation of an object-oriented user interface, facilitating initial use and subsequent familiarisation, especially for beginners or upgrading users, and so making the resulting method easier and more intuitive to learn) could not be considered a directly derivable consequence of the distinguishing features, because attributes such as “simpler operation” or “easy and intuitive familiarisation” were generally subjective, i.e. depended on the user’s individual preferences and experience or intellectual capabilities, while the classification of users as “beginners”, “upgraders” or “advanced” was generally based on a variety of criteria which were not clearly defined.

This suggests that providing objective definitions of technical effects (e.g. millisecond time savings) may help to support an inventive step under European practice. It also further indicates a need to avoid reference to “user”-based advantages.

Applications of Algorithms

In T 2035/11 the application mainly related to navigation systems that could be tailored to a user’s particular wishes. The focus of the application was on the route-planning functionality of a navigation system.

The board held that the subject-matter of claim 1 lacked an inventive step within the meaning of Art. 52(1) and 56 EPC. It noted that mathematical algorithms may contribute to the technical character of an invention only in so far as they serve a technical purpose (see e.g. decision T 1784/06). The purpose of the algorithm was the mere display of an optimal path to the user for cognitive processing. The user could act on the information, but did not need to.

As stated in decision T 1670/07, a technical effect may arise from either the provision of data about a technical process, regardless of the presence of the user or its subsequent use, or from the provision of data (including data that on its own is excluded, e.g. produced by means of an algorithm) that is applied directly in a technical process.

In the case at issue, the data was produced by means of an algorithm and was not applied directly in a technical process, so neither possibility applied.

Warning on Generalisation

In T 2231/09 the patent in suit concerned a method of representing and analysing images. Claim 1 of the main request set out that “… at least one said descriptor element is derived using only a subset of pixels in said image.”

The board considered the expression “subset of pixels” to be problematic under Art. 84 EPC 1973 and stressed that, while a certain degree of generalisation may be permitted, features as claimed should make it possible to clearly identify features of embodiments that are covered by the terms of a claim. Moreover, the generalised subject-matter as claimed should make it possible to understand the technical problem to be solved.

When amending claim 1, the applicant had put forward a new interpretation according to which a “region” could mean the whole image, and a “subset” could correspond to all pixels of the region. The board considered this interpretation to be inconsistent with essential parts of the described embodiments, according to which a subset corresponded to only some of the pixels of a region. The subject-matter of claim 1 was thus unclear when interpreted in the light of the description.

The board also stated that the requirements of clarity and support by the description in Art. 84 EPC 1973 were designed to reflect the principle that the terms of a claim should be commensurate with the invention’s technical contribution to the art. Taking into account the description, the board regarded the division of the image into regions and subsets as essential for achieving the technical effect underlying the invention. Therefore, the subject-matter of claim 1 was not supported by the description. The board concluded that claim 1 did not comply with Art. 84 EPC 1973.

This indicates the need, when drafting claims for computer-related inventions, to provide clear and unambiguous definitions of terms used within the claims. This is especially important when features of the claims relate to abstract entities, e.g. data within a data processing system.

Added Subject Matter and Features without Technical Contribution

In T 1779/09 the board considered that the appellant had found itself exactly in the situation envisaged in decision G 1/93 (OJ 1994, 451). As emphasised in Headnote II of G 1/93, “a feature which has not been disclosed in the application as filed but which has been added to the application during examination and which, without providing a technical contribution to the subject-matter of the claimed invention, merely limits the protection conferred by the patent as granted by excluding protection for part of the subject-matter of the claimed invention as covered by the application as filed, is not to be considered as subject-matter which extends beyond the content of the application as filed within the meaning of Art. 123(2) EPC.” These principles were confirmed in G 2/98 (OJ 2001, 413) and G 2/10 (OJ 2012, 376). The board in the case at issue concluded that a limiting feature which generally would not be allowable under Art. 123(2) EPC could, under certain conditions, nevertheless be maintained in the claim of an opposed patent in the particular situation addressed in decision G 1/93. It then complied with Art. 123(2) EPC by way of a legal fiction. In the case at issue, the term “only” was introduced during the examination proceedings and successfully objected to under Art. 100(c) EPC in proceedings before the opposition division by the former respondent. Since the board considered the term to be truly limiting, its deletion would extend the protection conferred and thereby infringe Art. 123(3) EPC. However, the board held that the exclusive limitation did not influence the solution of the technical problem as understood from the application as originally filed, and hence provided no technical contribution to the claimed invention (see also decision T 384/91, Headnote II). It merely excluded protection of part of the invention described in the application, thus not giving any unwarranted advantage to the applicant. Claim 1 of the appellant’s sole request was therefore deemed to comply with Art. 123(2) EPC.

Updated US Guidance on Patent Eligibility (or “Stuff =/ Patents”)

The USPTO issued updated guidance on Patent Subject Matter Eligibility (i.e. things you can get a patent for in the US) at the end of July.

The materials are fairly dense and help address some of the criticisms raised by applicants. Further explanations of the approach are provided as well as an expanded list of examples.

Reading between the lines, it appears the USPTO is moving towards a position that is harmonised with European, Chinese and UK approaches on excluded subject matter.

Having a relatively simple mind, I found the following page from the guidance summary useful.

Stuff What You Can't Patent

Software & Patenting: IP Outside Your Comfort Zone

A presentation given as a CIPA Webinar on 25 February 2014.

Provides an introduction to software as it relates to patenting and an overview of current practice in UK and Europe. Details of relevant legislation and case law are provided, together with some tips for drafting.

Provided according to the terms set out here: http://www.eip.com/legal.php – i.e. does not constitute legal advice and should be taken as guidance.

Patenting Software – Can You Protect Programming Inventions in the EPO?

This article is a brief summary of the European Patent Office position on patenting inventions associated with computer programming.

Overview

It may be easier to obtain a granted patent for computer programming inventions when an application is made via the European Patent Office rather than the UK Patent Office.

However, the European Patent Office may be more likely to raise clarity objections and find relevant prior art.

Defining Case: COMVIK

The defining case in Europe is COMVIK.

Following this case, the claims of a patent application are assessed for “technical” and “non-technical” features. Only “technical” features may be used to demonstrate an improvement over previous publications.

The term “technical” is necessarily fuzzy; it has been defined in a piece-meal manner by European case law. However, it is generally taken to mean clearly relating to a field of science or engineering. Features relating to “administration” or “business” are considered “non-technical”.

Useful Case Law

The cases below provide examples of the thinking of the UK Patent Office.

  • T_0505/09: in this case, an invention related to a method for identifying defective program code. At an abstract level, certain testing techniques were agreed to form part of the common general knowledge. However, there was no objection that the invention related to “non-technical” features. Instead, emphasis was put on what written evidence relating to the invention was published before the application was filed.

 

  • T_1893/08: in this case, information on data definitions was provided in the form of a common language file represented in a different language to first and second languages for compilation. The first language had an “import” statement that imported the common language file. The board concluded that compiler features provided a solution to a “technical” problem and did provide an inventive step when compared to the cited art.

 

  • T_1216/08: this case featured authentication of software in a dynamic loading environment. A validator generated a digital signature based on a portion of a program image, wherein pointers in the image that required “fixing up” by a program loader were excluded from the portion. Implicitly, these features were considered “technical” and an inventive step was found.

 

  • T_0702/08: in this case, a patent claim referred generally to “process objects” and “task objects”. These terms were considered to have a broad meaning encompassing the general concept of a “goal” or “objective” at an administrative management level. It was concluded that there was no unambiguous correlation between the described “objects” and object-oriented programming. Hence, a specific technical mapping between abstract concepts and their technical implementation needs to be set out in any patent application.

 

  • T_0077/08: here the main difference between a patent claim and a previous publication was that a business logic rule was expected as an expression rather than a statement in a programming language. It was considered obvious that both formulations would be considered. It was questioned whether making a system more “flexible” was a “technical” problem.

 

  • T_2078/07: in this case the invention, using metadata to describe data types, was found not to provide “a further technical effect” over fundamental programming conventions. It was “simply an advice on how to write a program”.

 

  • T_1928/07: this case referred generally to “event processes”, “tasks”, “inclusion” and “execution” in a programming context. These terms were not defined in terms of concrete, rather than abstract, features. The case was thus rejected for lacking clarity.

Patenting Software – Can You Protect Programming Inventions in the UK?

This article is a brief summary of the UK position on patenting inventions associated with computer programming.

Overview

In the UK, it may be difficult to obtain a granted patent for inventions relating to computer programming.

These inventions may not be allowed by the UK Patent Office on the basis that they relate solely to a “computer-program”, a “mental act”, a “business method” or a “mathematical method”.

However, while patent applications for application-level software are most likely to be refused, certain improvements at a low, technical level may be allowed.

Defining Cases: Symbian and Halliburton

The defining cases in this area are Symbian and Halliburton (see links for full references).

  • Symbian concerned adapted dynamic link libraries (DLLs) with two parts: a fixed part and an extension part. Even though it was directed to a method implemented in practice by a computer program, it was found not to be solely a computer program as it made a computer work better as a matter of practical reality. From this case, an improvement at the level of the operating system or below could form the basis of a granted patent. The UK Patent Office appears to dislike the citing of Symbian; frugal use is recommended.

 

  • Halliburton made it easier to obtain a granted patent for inventions that could be performed mentally. In the past, these would be rejected. Now, inventions that are described as “computer-implemented methods” are not rejected just because the “method” could be performed mentally.

Hearings from the UK Patent Office in this area suggest it will be difficult, but not impossible, to obtain a granted patent for a computer programming invention.

Much will depend on the language of the patent application and the particular examiner considering the case. It must be shown that there is more than would be expected when simply running a better program on a computer.

Useful Case Law

The cases below provide examples of the thinking of the UK Patent Office.

  • O/173/08: the invention involved “taking an existing computer program, analysing the instructions … and applying [parallel processing code] substitutions so that the program will operate more quickly”. This may be performed at runtime using a “rules-based system for converting the original code into more efficient code”. This was found to relate to “the generation of more efficient program code rather than an improvement in the operation of the computer system”, i.e. to be an improvement in “programming” and thus excluded for being a “compute program as such”.

 

  • O/066/06: in this case, data received from trace units associated with a processor was used to adapt compilation in real time. The Hearing Officer stated that compilers per se were not patentable for being a mental act; it is likely this is now overturned by Haliburton. The result of the invention was “a faster, more accurate compiler, able to adapt and improve in an iterative manner each time the compiler is used”. This was seen to be a “technical” rather than “cosmetic” advantage, and the case was allowed.

 

  • O/057/06: this case involved the application of a reduced set of Java® Bytecode instructions, i.e. multiple Bytecode instructions were reduced to a single virtual machine instruction. Even though the Hearing Officer acknowledged that Reduced Instruction Set Computers (RISC) were well known, he found that the application related to a non-obvious “invention” under UK patent law. Following from this a patent should be granted. His logic was that hardware-based RISC processors were unarguably patentable, providing a clear technical effect of being faster and more economical. Hence, a software-based version should not be excluded simply because it is implemented on a programmed computer.

 

  • O/036/10: this case involved a simulation system comprising a new arrangement for debugging software enabling a user to locate bugs more quickly and more effectively. Here, however, the computer running the software was “entirely conventional”. The software made “a computer, work differently in the sense of processing data in a different way, but it [did] not make it work better, faster or more reliably in terms of its performance”. No “deep level” technical improvement was located. Thus the application was refused.

“Software” Patents in the UK – Practice Notices

If you want to understand how the UK Intellectual Property (i.e. Patent) Office exams patent applications relating to “software”*, a good place to start is the most recent Practice Notice:

Patents Act 1977: Patentability of computer programs (Recent= 8 December 2008).

The most recent Practice Notice builds on a previous Notice:

Patents Act 1977: Patentable subject matter (dated 2 November 2006).

This previous Notice was also updated by short Notice:

Patents Act 1977: Patentable subject matter (7 February 2008) .

* By referring to software in inverted commas I am indicating that the term “software” patent is not often used within the profession, which prefers the terms “computer programs” or “computer-implemented inventions”.


With regard to protecting computer games at the UK IPO see the Practice Notice:

Patents Act 1977: Patentability of games (updated 2 November 2006).

Basically, games are not patentable. Paragraph 4 of the Notice is superseded by the Practice Notices above.

“Software” Patents in Europe

Well, to be precise, computer-implemented inventions under the European Patent Convention.

The Enlarged Board of Appeal has just issued a decision in referral G03/08 (for background see here). The Enlarged Board have decided that the referral is inadmissible. The accompanying opinion states that previous decisions of the Boards of Appeal are not sufficiently “different” (i.e. “conflicted”) to warrant clarification from the higher Enlarged Board.

Better men than I have summarised the decision here:

http://www.ipjur.com/blog2/index.php?/archives/150-EPO-EBoA-Opinion-in-re-G-0308-Patentability-Of-Computer-Implemented-Inventions.html

http://ipkitten.blogspot.com/2010/05/g-308-software-patents-decision-is-out.html

[Update] and here: http://www.iam-magazine.com/blog/Detail.aspx?g=cc296bce-5de8-484c-ac43-95d5b6ce68df featuring Gill Jennings & Every‘s Peter Finnie

To be honest, the decision was pretty much expected: the European Patent Office (EPO) has been taking a fairly consistent approach to computer-implemented inventions and has a growing body of learning materials on the subject. In fact, by no small coincidence, the book “Patent Law for Computer Scientists“, written by EPO Patent Examiners was released a few days ago. I have ordered a copy and will let you know if it is of any use. A review can be found here.

However, the opinion is not without merit. Its 60-odd pages set out the current state of the law on the issue and may provide a useful caselaw summary. I will attempt to read through the pages of dense courier font shortly.

Can software be patented?

Can software be patented? If so, in what form?

This post provides some general background on the issue and briefly considers two pending cases in Europe and the US.

The patentability of software has important consequences for the way in which individuals and businesses protect, and make money from, their creations under the law.

Nearly all modern inventions make use of a computer, whether in their design, construction or operation. The Internet is simply a network of computers.

On one side of the debate are those calling for the abolition of patents for software; on the other side are those calling for clearer protection.

Quick Crib Sheet

A patent is a property right granted by a state which allows its holder to prevent third parties from commercially exploiting an invention for a set period of time.

The enforcement of a patent is governed by national law.  The procedure for obtaining a patent is governed by at least one of national law (e.g. the UK Patents Act), regional treaty (e.g. The European Patent Convention) and international treaty (e.g. The Patent Cooperation Treaty).

The era of revolution, both industrial and political, gave birth to substantive patent law.  Modern patent law was codified in the post-war period.  British, European and international codes were drawn up in the 1970s.

Since the 1970s, the growth in computing has been exponential.

From this:

Computer - 1970s c/o Ecksemmess

to this:

iPhone c/o Masaaki Komori from Tokyo, Japan

Under British and European patent law, a patent cannot be granted for “business methods” or “computer programs” “as such”.  However, certain inventions may be patented as “computer-implemented inventions” (CIIs).  The law in the UK and Europe should be harmonised but in practice differs on points of interpretation.  This prompted Lord Justice Jacob, in the Court of Appeal, to ask the European Patent Office for clarification in 2006.  The European Patent Office refused the request.

In the US, case law developed at the turn of the last century was used to demonstrate a “business method” exclusion for patents.  This changed in the late 1990s when, under pressure from the dot-com boom, the US Patent Office began to grant patents for “business methods” implemented using a computer.  The explosion of such patents, which were considered by some to be of “potential vagueness and suspect validity”, has recently seen a legal backlash.

Cases:

Europe:

Points of law are considered by the Enlarged Board of Appeal.  On the 22 October 2008 the (British) President of the European Patent Office referred a series of questions to the Board.  These questions were formulated to seek an answer to the question above and provide guidance for national harmonisation.  The Board may dismiss the referral.

The referral was rigorously debated by the high-tech community.  Amicus curiae briefs were filed by many well-known companies, including Apple, IBM, and Philips, as well as by groups such as the Foundation for a Free Information Infrastructure and the Pirate Party.

US

The US Supreme Court is presently considering a case concerning a 1997 patent application filed by Bernard Bilski on a business method for hedging financial trades (known generally as “Bilski”).  The application was rejected by the U.S. Patent Office and this decision was upheld by the Federal Circuit Court.  As in Europe, the case has ignited fierce debate; amicus curiae briefs have been filed on behalf of, for example, Microsoft, Google, and Bank of America, as well as associations both for and against patents for software.

EPO CII OU

The EPO has released some new material that maybe useful for those that work with computer-implemented inventions:

e-learning slide-show:
Part I: http://academy.epo.org/e_learning/cii_module_i/player.html
Part II: http://academy.epo.org/e_learning/cii_module_ii/player.html

and revised Patents for Software booklet: http://www.epo.org/about-us/publications/general-information/patents-for-software.html?update

Whilst the more cynical among you may see these as hastily-rushed out PR-tools for the public spotlight of G3/08, I was actually quite impressed by the slide-shows (apart from the (mis)pronunciation of “patent”). Together they last about half-an-hour and may be useful as training for those pre-EQE or as a refresher for those with upcoming Appeals/Oral Proceedings in the CII area. As a warning though, they do contain sounds (and moving images).