Can you protect Artificial Intelligence inventions at the European Patent Office?

In recent years there has been a resurgence of interest in machine learning and so-called “artificial intelligence” systems. Much of this resurgence is based on advances in so-called “deep learning”, neural networks with multiple layers of connections. For example, convolutional neural networks now provide state-of-the-art performance in many image recognition tasks and recurrent neural networks have been used to increase the accuracy of many commercial machine translation systems. Machine learning may be considered a subdiscipline of “artificial intelligence” that deals with algorithms that are trained to perform tasks such as classification based on collections of data. This recent resurgence has meant that more companies wish to protect innovations in this field. This quickly brings them into the realm of computer-implemented inventions, and the nuances of protection at the European Patent Office.

A881388C-9C65-470D-AED6-9C584435DA4A
Obligatory “Terminator” Patent Attorney Stock Image

Computer-Implemented Inventions

“Computer-implemented invention” is the European Patent Office term for a software invention. Claims that specify machine learning and artificial intelligence systems are almost certainly to be considered “computer-implemented inventions”. The innovation in such systems occurs in the design of the algorithms and/or software architectures. Claims for new hardware to implement machine learning and artificial intelligence systems, such as new graphical processing unit configurations, would not be classed as computer-implemented inventions and would be considered in the same manner as conventional computer devices.


What Do We Have To Go On?

As key advances in the field have only been seen since 2010, there are few Board of Appeal cases that explicitly consider these inventions. It is likely we will see many Board of Appeal decisions in this field, but it is unlikely these will filter through the system much before 2020. However, applications in the field are being filed and examined. The following review is based on knowledge of these applications, evaluated in the context of existing Board of Appeal cases.


Prior Art

A first issue regarding machine learning and artificial intelligence systems is that many of the underlying techniques are public knowledge, given the rapid turn-over of publications and repositories of electronic pre-prints such as arXiv. Hence, many applicants may face novelty and inventive step objections if the invention involves the application of known techniques to new domains or problems. For patent attorneys who are drafting new applications, it is recommended to perform a pre-filing search of such publication sources and ensure that the inventors provide a full appraisal of what is public knowledge.


Domain of Invention

A second issue is the domain of the invention. This may be seen as the context of the invention as presented in the claims and patent description.

Inventions that apply machine learning approaches to fields in engineering are generally considered more positively by the European Patent Office. These fields will typically either operate on low-level data that represents physical properties or have some form of actuation or change in the physical world. For example, the following domains are less likely to have features excluded from an inventive step evaluation for being “non-technical”: navigating a robot within a three-dimensional space; dynamic adaptive change of a Field Programmable Gate Array; audio signal analysis in speech processing; and controlling a power supply to a data centre.

On the other hand, inventions that apply machine learning approaches within a business or “enterprise” domain are likely to be analysed more closely. These inventions have a greater chance of claim features being excluded for being “non-technical”. These domains typically have an aim of increasing profit. The more this aim is explicit in the patent application, the more likely a “non-technical” objection will be raised. For example, the following inventions are more likely to have features excluded from an inventive step evaluation for being “non-technical”: intelligent organisation of playlists in a music streaming service; adaptive electronic trading of securities; automated provision of electronic information in a company hierarchy; and automated negotiation of online advertising auctions.


Exclusions from Patentability

A third issue that arises is that individual features of the claims fall within the exclusions of Article 52(2) EPC.  In the field of machine learning and artificial intelligence systems, there is an increased risk of claim features being considered to fall into one of the following categories: mathematical methods; schemes, rules and methods for performing mental acts or doing business; and presentations of information. These will briefly be considered in turn below.

Mathematical Methods

The field of machine learning is closely linked to the field of statistics. Indeed many machine learning algorithms are an application of statistical methods. Academic researchers in the field are trained to describe their contributions mathematically, and this is required for publication in an academic journal. However, the practice of the European Patent Office, as directed by the Boards of Appeal, typically regards statistical methods as mathematical methods. In their pure, unapplied form they are considered “non-technical”.

Schemes, Rules and Methods for Performing Mental Acts

A claim feature is likely to be considered part of schemes, rules and methods for performing mental acts when the scope of the feature is too broad or abstract. For example, if a claimed method step also covers a human being performing the step manually, it is likely that the scope is too broad.

Schemes, Rules and Methods for Doing Business

Claim features are likely to be considered schemes, rules and methods for doing business when the information processing relates to a business aim or goal. This is especially the case where the information processing is dependent on the content of the data being processed, and that content does not relate to a low-level recording or capture of a physical phenomenon.

For example, processing of a digital sound recording to clean the recording of noise would be considered “technical”; processing row entries in a database of information technology assets to remove duplicates for licensing purposes would likely be considered “non-technical”.

Presentation of Information

Objections that features relate to the presentation of information may occur when the innovation relates to user experience (UX) or user interface (UI) features.

For example, a machine learning algorithm that adaptively arranges icons on a smartphone according to use may receive objections on the grounds that features relate to mathematical methods (the algorithm) and presentation of information (the arrangement of icons on the graphical user interface). As per Guideline G-II, 3.7.1, grant is unlikely if information is simply displayed to a user and any improvement occurs in the mind of the user. However, it is possible to argue for a technical effect if the output provides information on an internal state of operation of a device (at the operating system level or below, e.g. battery level, processing unit utility etc.) or if the output improves a sequence of interactions with a user (e.g. provides a new way of operating a device). Again, a technical problem needs to be demonstrated and the machine learning algorithm needs to be a tool to solve this problem.


Subfields of ML and AI

In certain subfields of machine learning and artificial intelligence, there is a tendency for Boards of Appeal and Examining Divisions to consider inventions more or less “technical”. This is often for a combination of factors, including field of operation of appellants, the history of research and traditional applications, and the background and public policy preferences of staff of the European Patent Office.

For example, machine learning and artificial intelligence systems in the field of image, video and audio processing are more likely to be found to have “technical” features that can contribute to an inventive step under Article 56 EPC. A convolutional neural network architecture applied to image processing is more likely to be considered a “technical” contribution that the same architecture applied to text processing. Similarly, it may be argued that machine learning and artificial intelligence systems in the field of medicine and biochemistry have “technical” characteristics, e.g. if they operate on data originating from mass spectrometry or medical imaging.

However, advances in search, classification and natural language processing are more likely to be found to have “non-technical” features that cannot contribute to an inventive step under Article 56 EPC. These areas of machine learning and artificial intelligence systems are often felt to be “technical” by the engineers and developers building such systems. However, it is a nuance of European case law that these areas are often deemed to have claim features that fall into an excluded “business”, “mathematical” or “administrative” category.

A recent example may be found in case T 1358/09. The claim in this case comprised “text documents, which are digitally represented in a computer, by a vector of n dimensions, said n dimensions forming a vector space, whereas the value of each dimension of said vector corresponds to the frequency of occurrence of a certain term in the document”. The Board agreed with the appellant that the steps in the claim were different to those applied by a human being performing classification. However, the Board concluded that the algorithm underlying the method the claim did not “go beyond a particular mathematical formulation of the task of classifying documents”. They were of the opinion that the skilled person would have been given the (“non-technical”) text classification algorithm and simply be tasked with implementing it on a computer.


What Should We Not Do?

Managers and executives of commercial enterprises are often habituated into selling innovations to a non-technical audience. This means that invention disclosures often describe the invention at an abstract “marketing” level. When an invention is described in a patent application at this level, inventive step objections are likely.

The fact that mathematical formulae may comprise excluded “non-technical” features is difficult for inventors and practitioners to grasp. Often equations at an academic-publication level are included in patent specifications in an attempt to add technical character. This often backfires. While such equations may be deemed “technical” according to a standard definition of the term, they are often not deemed “technical” according to the definition applied by European case law.

In general, objections are more likely in this area when the scope of the claim is broad and attempts to cover applications of a particular algorithm in all industries. Applicants should be advised that trying to cover everything will likely lead to refusal.


What Should We Do?

Chances of grant may be increased by ensuring an examiner or Board of Appeal member can clearly see the practical application of the algorithm to a specific field or low-level technical area.

Patent attorneys drafting patent applications for machine learning and artificial intelligence systems should carefully consider the framing and description of the invention in the patent specification. In-depth discussions with the engineers and developers that are implementing the systems often enable innovations to be described more precisely. Given this precision, innovations may be framed as a “technical” or engineering innovation, i.e. a technical solution to a technical problem. This increases the chance of a positive opinion from the European Patent Office.

Often features of an invention will have both a business advantage and a “technical” advantage. For example, a machine learning system that learns how to dynamically route data over a network may help an online merchant more successfully route traffic to their website; however, this improved method may involve manipulation of data packets within a router that also improves network security. A patent specification describing the latter advantage will have a greater chance of grant than the former, regardless of the actual provenance of the invention. A practitioner may work with an inventor to ensure that initial business advantages are distilled to their proximate “technical” advantages and effects. For cases where data does not relate to a low-level recording or capture of a physical phenomenon, it is recommended to ensure that any described technical effect applies regardless of the content of the data.

When considering exclusion for “mental acts”, a risk of a “non-technical” objection may be reduced by ensuring that your method steps exclude a manual implementation. Note that this exclusion does not necessarily prevent other objections being raised (see T 1358/09 above).

When drafting patent applications,  it is also important to describe the implementation of any mathematical method. In this manner, pseudo-code is often more useful than equations. It is also important to clearly define how attributes of the physical world are represented within the computer. Good questions to ask include: “What data structures and function routines are used to implement the elements of any equation?”, “How is data initially recorded, e.g. are documents a scanned image such as a bitmap or a markup file using a Unicode encoding?”,  “What programming languages and libraries are being used?”, or “What application programming interfaces are important?”.

Practitioners do need to be concerned with including overly limiting definitions within the claims; however, a positive opinion is more likely when specific implementation examples are described in the patent specification, followed by possible generalisations, than when specific implementation examples are omitted and the description only presents a generalised form of the invention along with more detailed mathematical equations.

To be successful in search, classification and natural language processing,  one approach is to determine whether features relating to a non-obvious technical implementation may be claimed. This approach often goes hand in hand with a knowledge of academic publications in the field. While such publications may disclose a version of an algorithm being used, they often gloss over the technical implementation (unless the underlying source code is released on GitHub). For example, is there any feature of the data, ignoring its content, which makes implementation of a given equation problematic? If inventors have managed to reduce the dimensionality of a neural network using clever string pre-processing or quantisation then there may be an argument that the resultant solution is implementable on mobile and embedded devices. Reducing a size of a model from 3 GB to 300 KB by intelligent selection of pipeline stages may enable you to argue for a technical effect.


Do Not Believe The Hype?

Despite the hype, machine learning and artificial intelligence systems are just another form of software solution. As such, all the general guidance and case law on computer-implemented inventions continues to apply. A benefit of the longer timescales of patent prosecution is that you ride out the waves of Gartner’s hype cycle. In fact, I still sometimes prosecute cases from the end of the dotcom boom…

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.