A quick post that checks on the state of play for computer-implemented inventions (“software patents”) at the European Patent Office. It has a quick look at some minor updates to the Guidelines for Examination and then reviews a few recent Board of Appeal cases.
Guidelines for Examination
After the overhaul of 2018, there are relatively few updates to the Guidelines for Examination for the 1 November 2019 edition. I go through those that relate to computer-implemented inventions below. I recommend viewing the links to the sections with the “Show modifications” check box ticked.
Section G-II, 3.3.1 on “Artificial intelligence and machine learning” has been tweaked to indicate that terms such as “support vector machine”, “reasoning engine” or “neural network” do not by themselves imply a technical means. They must be considered in context (i.e. make sure you describe a “hard” engineering problem and context).
Section G-II, 3.3 on “Mathematical methods” has a few minor changes.
It is stressed that special attention needs to be paid to the clarity of terms in claims that relate to mathematical methods. If terms are deemed to have “no well-recognised meaning” this may make it difficult to demonstrate a technical character (and so care should be taken to provide detailed functional definitions within the detailed description).
It is also added that mathematical methods may produce a technical effect when applied to a field of technology and/or adapted to a specific technical implementation. In this case, the “computational efficiency” of the steps of the methods may be taken into account when assessing inventive step. This is echoed in a minor update to section G-II, 3.6 on “Programs for computers”.
As also discussed below, the EPO is hinting that it might be a good idea to provide some actual experimental evidence to back up claims of increased efficiency when dealing with more abstract software-style inventions.
In this case, the Board distinguished the field of data privacy from the field of data security. It was implied that the field of data security could give rise to technical solutions that provide an inventive step under Article 56 EPC. However, the field of data privacy was felt to relate to administrative, rather than technical, endeavours. In particular, the Board held that de-identifying data, by removing individually identifiable information, and by aggregating data from a plurality of sources, was not technical. It was felt that the claims related to data processing with a legal or administrative aim, rather than a technical one.
It is noted that the specification of the patent application was relatively light on concrete technical details – this may have led the Board to a negative opinion. The generalizations to the field of data privacy are perhaps too heavy-handed; there appears to be room to argue that some data privacy systems do contain technical features. In the light of this case, those drafting applications directed towards a data privacy aim may wish to determine if the technical effects may be recast in neighbouring data security fields.
T 0817/09 – Scoring a Document
T 0817/09 related to a computer implemented method for scoring a document.
The scoring was related to history data and was generated by monitoring signatures of the document, where the signatures were provided in the form of “term vectors”. As per similar linguistic processing cases discussed before, the “term vector” was found not to be “an inherently technical object” and “semantic similarity” was deemed to be a non-technical linguistic concept. The Board considered that solutions developed by the “notional mathematician” or the “notional computer programmer” would generally not be technical, whereas solutions developed by a digital signal processing engineer could be technical.
On the facts, the claimed methods were not found to provide any resource savings that could be presented as a technical, rather than linguistic effect. This does, however, suggest that providing evidence of technical improvements, e.g. reduced server processing times and/or reduced memory usage, may help applications with algorithmic subject matter.
T 0697/17 – Database Management Systems
T 0697/17 considered the patentability of SQL extensions within a relational database.
At first instance, the Examining Division held that the claim in question “entirely described a purely abstract method”. The Board disagreed: they held that the claim related to a method performed in a relational database system, which was a known form of software system within the field of computer science and as such would involve a computer system. The claim was thus not an abstract method. The Board noted that describing a technical feature at a high level of abstraction does not necessarily take away the feature’s technical character.
In consideration of inventive step, the Board cited T 1924/17, and stated that features make a technical contribution if they result from technical considerations on how to (for instance) improve processing speed, reduce the amount of memory required, improve availability or scalability, or reduce network traffic, when compared with the prior art or once added to the other features of the invention, and contribute in combination with technical features to achieve such an effect. However, effects and the respective features are non-technical if the effects are achieved by non-technical modifications to the underlying non-technical method or scheme (for example, a change of the business model, or a “pure algorithmic scheme”, i.e. an algorithmic scheme not based on technical considerations). The Board made an interesting distinction between a “programmer as such” and a “technical programmer”, and stated it was difficult to distinguish abstract algorithmic aspects that were non-technical and arose from the “programmer as such” from “technical programming” aspects that arose from the “technical programmer”.
Returning to T 1924/17, the Board concluded that a database management system is not a computer program as such but rather a technical system. The data structures used for providing access to data and for optimising and processing queries were deemed functional data structures and were held to purposively control the operation of the database management system and of the computer system to perform those technical tasks. While a database system is used to store non-technical information and database design usually involves information-modelling aspects, which do not contribute to solving a technical problem, the implementation of a database management system involves technical considerations. In the end, the case, which had been pending for 13 years, was remitted back to the Examining Division with an informally rap over the knuckles. It provides a useful citation for those drafting and prosecuting applications relating to database management systems.
Examination practice at the European Patent Office follows a set of Guidelines. These are published online and provide guidance for European Examiners and applicants. They are updated annually.
An updated set of Guidelines came into force on 1st November 2018. The recent updates introduce major amendments to sections that cover subject matter that is excluded from patentability in European. These sections include those directed to “mathematical methods”, “schemes, rules and methods for performing mental acts, playing games or doing business” (often shortened to “business methods”), and “programs for computers”. The updates are relevant to those filing applications related to “computer-implemented inventions” (often colloquially referred to as “software patents”).
Although the amendments do not significantly change current practice at the European Patent Office, they do expand the guidance on what may and may not be protected with a European patent. They represent a significant upgrade and demonstrate the maturity of the case law with regard to computer-implemented inventions.
This post will review and highlight the updates. The post may be useful for those seeking to patent machine learning and artificial intelligence inventions. The updates cover the following areas:
claims to distributed computing systems;
inventions that use mathematical methods;
AI and machine learning inventions;
inventions that cover simulations and models; and
inventions that relate to business methods, gaming, mental acts or computer programs.
Section F-IV, 3.9.3 has been added to the section relating to claims for computer-implemented inventions. It provides expanded guidance and an example relevant to processes operating in a distributed computing environment. These processes form a basis for many real-world implementations of computer-implemented inventions. For example, a smartphone accessing a cloud computing service would implement a process operating in a distributed computing environment.
The section sets out the current practice of the European Patent Office. Claims in a claim set may be directed to each entity of the distributed system and/or the system as a whole. Such a claim set may be argued to meet the requirement for multiple independent claims set by Rule 43(2)(a) EPC, i.e. the claims may be allowed despite having multiple independent claims in the same category because the subject-matter of the claims relates to a plurality of interrelated products. However, each individual claim will need to meet the requirements of novelty, inventive step and clarity.
For example, if a cloud computing service provides a new image classification function via an application programming interface that is accessed by a smartphone, a claim set may feature apparatus claims to both a server computing device (the cloud server) and a mobile computing device (the “accessing device” or smartphone). If the smartphone is simply a generic smartphone making a network request (e.g. an “HTTPS request to a REST API endpoint”), it will likely not be new when compared to known smartphones. An objection will be raised against the smartphone claim. However, if the smartphone implements some new low-level processing, e.g. some new feature extraction process that is specific to the new image classification function (like pre-extracting cat-like facial features), it may also be new and inventive in itself and be allowed.
The updated section draws our attention to the need for clarity in claims to distributed entities. It recommends that distributed method claims specify the entity that is performing each method step.
Claiming distributed processes in a challenge. In practice, one entity often implements most of the new and inventive process (e.g. the cloud server), while other devices are relatively “thin” and generic (e.g. the smartphone). However, claims to the accessing device are often of greater commercial value (e.g. they might allow a royalty for each smartphone that is sold). This often leads to the inclusion of claims to the mobile computing device in a claim set, but a high likelihood of an objection being raised by the European Examiner.
To attempt to overcome novelty and inventive step objections to “accessing device” claims, it is common to include an indirect or implicit reference to the functions of the server computing device. This can then lead to one or more clarity, novelty or inventive step objections. For example, the indirect features may trigger a clarity objection for not clearly specifying features of the “accessing device”. Alternatively, the indirect features may be ignored for novelty and/or inventive step, as they are deemed to present no inherent structural limitations for the “accessing device”.
When drafting claims to distributed systems, it is worth questioning the inventors to determine what functions may be implemented with low-level adaptations to the accessing device. If the invention can be embodied in an “app”, it is worth looking at the architecture of the app, and the sequence of low-level system calls it may be implementing. This may not be obvious to the inventors, as commercial and engineering demands often require as much functionality as possible to be embodied on the back-end in the cloud.
The section on the examination of mathematical methods has been re-written and two sub-sections have been added. A first sub-section – 3.3.1 – now provides specific guidance for artificial intelligence and machine learning. A second sub-section – 3.3.2 – expands upon claims to simulation, design or modelling.
The updated guidance is now clearer on the importance of “technical means”, i.e. a concrete implementation in a field of technology, when an invention makes use of mathematical methods. This complements the recent changes to practice for “abstract inventions” in the United States.
I really like the updates to this section and the inclusion of helpful concrete examples. The section emphasises that a mathematical method or algorithm per se will not be enough to make a claim feature patentable, although many patentable inventions do have a mathematical or algorithmic basis.
Examples of the Fast Fourier Transform, geometric objects and graphs are provided: these features may contribute to the technical character of an invention if they contribute to producing a technical effect that serves a technical purpose. Put another way, these features need to be provided in a context that relates to an engineering problem encountered in the real-world, and the use of these features needs to result in a change in the real-world that helps solve that problem. This is further emphasised later in the guidance – the technical purpose of the mathematical features needs to be specific rather than generic, and the claim needs to be functionally limited to the technical purpose, either explicitly or implicitly.
What kind of applications are seen by the European Patent Office to be “technical”? My personal definition is: does the application relate to something in the real-world that requires knowledge that is taught in an undergraduate engineering degree? If the answer is “yes”, then the application is “technical”. If the answer is “no”, then the application may not be “technical”.
Section 3.3 now provides a useful list of purposes that are deemed “technical”. These include:
controlling a specific machine or technical process, e.g. an X-ray apparatus or steel cooling;
using measurements to control a machine or technical process, e.g. using a compaction machine to achieve a desired material density;
digital audio/visual processing, this can be relatively high-level – detecting people is a provided example (but a clear relation to captured data is recommended);
processing speech data, e.g. to generate text (but processing text per se may not be technical);
encoding data, e.g. for transmission or storage;
generating higher-level measurements by processing data from physiological sensors or other medical diagnosis;
analysing DNA samples to provide a genotype estimate; and
simulating “technical” things (this is described in more detail in new sub-section 3.3.2).
The section stresses that there must be a sufficient link between the technical purpose of the invention and the mathematical method steps, for example, by specifying how the input and the output of the sequence of mathematical steps relate to the technical purpose so that the mathematical method is causally linked to a technical effect. When drafting an application for Europe for an invention that features mathematical operations (e.g. equations and/or algorithmic designs), it is recommended to place such an explanation in the description – this can then be pointed to in examination if any objection is raised.
Similar to practice in the United Kingdom, the section ends by indicating that a feature may contribute to the technical character of an invention independently of any technical application, when the claim is directed to a specific technical implementation of a mathematical method, and the mathematical method is particularly adapted for that implementation in that its design is motivated by technical considerations of the internal functioning of the computer. Using the Fast Fourier Transform example, it may be possible to obtain protection for a new digital implementation of the Fast Fourier Transform, if you were performing specific mathematical operations that were adapted to the available computing resources of the implementation, e.g. available memory registers, processing cores, etc.
When considering inventions involving mathematical methods, one useful approach is to make an initial determination:
Does the invention relate to a specific engineering application (e.g. what branch of “applied” maths is being considered)?
Or does the invention relate to a new technical implementation of a mathematical operation (e.g. in effect a new and beneficial way of performing mathematical operations or “computing” using a device – sometimes called “core” inventions)?
A positive answer in the first case, suggests a quick check against the provided examples and the case law to determine if the specific engineering application has in the past been deemed to be “technical” under European practice.
A positive answer in the second case suggests looking carefully at the constraints imposed by the electronic hardware of the implementation. You will need to describe how the mathematical method is adapted, e.g. as compared to a “text-book” application, to provide concrete implementational improvements.
Artificial Intelligence and Machine Learning
Sub-section 3.3.1 is relatively short and seeks to summarise existing case law that applies in this area. This anticipates a large rise in patent applications over the coming years.
Machine learning inventions have been patented at the European Patent Office almost since its inception in the late 1970s. The present sub-section reminds us that despite the recent resurgence in neural networks, algorithms for approaches such as “classification, clustering, regression and dimensionality reduction” including “genetic algorithms, support vector machines, k-means, kernel regression and discriminant analysis” have been around for a number of years.
The sub-section stresses that the algorithms and approaches themselves per se of an abstract mathematical nature. The guidance from section 3.3 therefore applies: the invention either needs to relate to a specific engineering application that uses the approaches (e.g. using k-means clustering to classify packets in a network for selective filtering) or a new technical implementation of the approach that is constrained by technical factors at least the underlying computation hardware.
The sub-section hints that “technical character” often requires a clear causal link to measured data that represents physical phenomena. For example, classification of digital data such as physiological measurements, images, videos, or audio data is seen to be a common “technical application”. However, classifying text data is regarded as a “linguistic” and “non-technical” application. Likewise, general classification of “data” or “records” without a link to a specific technical problem would likely be seen as “non-technical”. Reference is made to case T 1358/09.
The sub-section ends by indicating that if a classification method is seen to serve a technical purpose then the steps of generating the training set and training the classifier may also contribute to the technical character of the invention if they support the technical purpose. This provides useful advice for drafting claims for inventions in this area: it is recommended to consider independent claims to the generation of training data and architecture training, as well as claims to an inference step. These claims may also provide a distributed processing system as discussed in section 3.3, for example inference may be performed on a smartphone, whereas data cleaning and training may be performed on a remote server. Care should be taken to cover different infringing acts.
Simulation, design or modelling
Sub-section 3.3.2 draws out material that was present in section 3.3. Discussing this material in a separate sub-section clarifies the high-level overview now present in section 3.3.
A computer-implemented simulation of a specific technical system or process may be seen to provide a technical effect and lead to a granted European patent. However, objections will be raised to computer-implemented simulations of non-technical systems or processes, such as those with an aim in the fields of finance, marketing, administration, scheduling or logistics. Care should be taken; cases such as T 531/09 indicate that the presence of technical devices (X-ray scanners in that case) is not enough to provide technical character, the technical devices need to be specific devices and the simulation needs to perform a technical purpose.
In the field of computer-aided design, the determination of a technical parameter which is intrinsically linked to the functioning of a technical object, where the determination is based on technical considerations, is a technical purpose. For example, a method of determining a particular value for a parameter of a specific technical device, in a manner that improves production or use of the device may be seen as suitably “technical”. Care should be taken if the design involves decisions to be made by a human being – e.g. the selection of an approved value – this intervention may be seen to break a causal chain that connects the design method to a technical purpose. Such decisions also risk importing factors that are outside of a narrow determination based on “technical considerations”.
Finally, this new sub-section suggests that claims that produce “models” will often lead to objections on the grounds that the models are not technical features per se; instead, they are seen as “abstract” mathematical or mental features. This again complements current practice in the United States. It is emphasised that generation of a model may be considered to lack a technical effect, even if the modelled product, system or process is technical. It this case it is important that the claim clearly indicates how the model is used, or to be used, in a technical system or process to solve a technical problem.
The previous high-level summary in section 3.5 has now been deleted, with this material being moved into separate sub-sections related to each of “performing mental acts”, “playing games” and “doing business”. Each sub-section then contains new material relating to each sub-category.
Each sub-section begins with a useful definition of each exclusion. Although this is described in the context of the exclusion being applied to the whole claim (e.g. the exclusion applying “as such” or “per se”), this often will not occur in practice, e.g. in most cases the exclusions set out in Article 52(2)(c) EPC will be avoided by having the method performed by a computing device. However, the definitions are useful as they indicate which claim features may be ignored for inventive step on the grounds that they provide no technical effect.
These are described as instructions to the human mind on how to conduct cognitive, conceptual or intellectual processes. The learning of a language is given as an example, which hints at how the European Patent Office legally support an objection to “linguistic” features (e.g. text processing) as being non-technical.
When drafting claims to computer-implemented inventions, especially method claims, care should be taken to avoid accidentally falling within the exclusion. For example, claims should be checked to ensure that the method steps therein cannot be performed entirely in the human mind; at least one step needs to be performed outside of the human mind. In practice, considering whether a method step can be performed in the human mind is useful when predicting whether inventive step objections may be issued during European examination; if the determination is positive, the method step can often be drafted or amended in a manner that avoids this interpretation, e.g. by referring to a specific technical apparatus. The sub-section indicates that a method would not be seen as performing mental acts if it requires the use of technical means or if it provides a physical entity as a resulting product.
The sub-section does not indicate that mental steps are necessarily ignored for an analysis of inventive step; however, it does emphasise that are mental steps must contribute to producing a technical effect that serves a technical process. A good example provided in the sub-section is that of affixing a driver to a Coriolis mass flowmeter: steps specifying the position of the driver may be performed mentally but by defining the position so as to maximise the performance of the flowmeter, a technical contribution is provided.
Games are defined in sub-section 3.5.2 as a conceptual framework of conventions and conditions that govern player conduct and how a game evolves in response to decisions and actions by the players. Games are governed by game rules, that are by their nature abstract, mental entities that are only meaningful within a game context. Games may be simple – matching random numbers – or complex – video games with extensive virtual game worlds.
If a claim sets out technical means for implementing the rules of a game, it is not excluded as such and analysis moves onto inventive step. To provide an inventive step, a claim feature must make a technical contribution, i.e. provide some engineering benefit beyond a mere computer-implementation of the game rules. The benefit of a claim feature is to be assessed from the point of view of an engineer or game programmer, who may be given the games rules by a game designer as a “requirements specification”.
The sub-section indicates that in many situations the burden is on the applicant to show that a gaming invention provides a real engineering benefit. It notes that abstracting non-technical game elements, relying on a complexity of a solution or indicating cognitive content will not help the applicant.
It is interesting to compare the general negativity of this sub-section with cases such as T 928/03 and T 12/08 that presented a more liberal view of the technical nature of gaming inventions. It will be seen whether they represent a narrower approach than seen in the past.
Doing business is defined in sub-section 3.5.3 as including activities which are of financial, commercial, administrative or organisational nature. The latter two areas should be noted; they are often overlooked as they do not directly relate to making a profit but are still seen to be “non-technical”.
Some useful examples of “business method” features are provided. They include:
management of rights and contractual agreements,
scheduling of tasks,
business optimisation, and
data science for the purpose of managerial decision making.
If an invention relates to any of these features, it should be assumed to relate to excluded subject matter unless there is strong evidence that a technical problem is being solved by a technical solution that involves technical considerations.
For practitioners, a disclosure document or inventor from industry will often present an invention in terms of a commercial benefit. For example, inventors often become familiar with internally promoting an invention on commercial grounds. Care should be taken to dig behind these grounds and return to the underlying engineering aspects of the idea. If no engineering aspects can be presented, the idea may not be suitable for a European patent application. Examiners and Boards of Appeal will also use an indication of a commercial benefit, or the presence of the above business features, as evidence of a lack of a technical contribution. For this reason, it is recommended to avoid discussing these when drafting the patent specification.
Programs for Computers
Section 3.6 has now been redrafted and sub-sections 3.6.1, 3.6.2, and 3.6.3 have been added to respectively cover “further technical effects”, “information modelling” and programming, and “data retrieval, formats and structures”.
Section 3.6 now begins by indicating that computer programs must produce a “further technical effect” to avoid exclusion on the grounds of being a computer program “as such”. A “further technical effect” is an effect that goes beyond the normal operation of a computer, e.g. the physical effects of executing a computer program. Controlling a technical process or the internal functioning of a computer or its interfaces are deemed to be valid “further technical effects”.
Although not explicitly indicated in section 3.6, it is relatively straightforward to demonstrate a “further technical effect” and avoid an objection to the whole claim under Articles 52(2)(c) and (3) EPC. For example, claims to a computer program may be said to provide a “further technical effect” if they include instructions to implement a technical method, e.g. if they indicate a dependency to an independent method claim that is deemed technical. In this manner, European patent applications often feature claims to a “computer program for implementing the method of claim X”.
Further technical effects that may be demonstrated by a computer program are set out in sub-section 3.6.1. These include:
controlling a technical system or process (e.g. a braking system of a car or an X-ray device);
data processing in any of the areas highlighted in section 3.3, e.g. audio/visual processing, encryption or compression;
improving the internal functioning of a computer running the program, e.g. programs that are adapted for a specific architecture or that provide benefits at the kernel or operating system level; and
providing low-level tools such as compilers, memory allocators, and builders.
This updated section and its sub-sections are more useful in indicating what kind of features may be deemed to provide a technical effect. For example, if a feature of a computer program is deemed to provide a “further technical effect” as set out in this section, the feature would be seen as “technical” and be counted in any evaluation of inventive step (e.g. for other independent system or method claims).
Information Modelling and Programming
Sub-section 3.6.2 now provides useful guidance when the invention relates to aspects of computer engineering or software in itself, e.g. as opposed to a computerised solution in another field of engineering. While software developers may assume that their solution is technical according to the normal use of that term, features may not actually be “technical” for the requirements of patentability.
Information modelling is defined here as relating to providing a formal description of a real-world system or process. It may be seen to relate to models built in graphical or textual modelling languages, such as the Unified Modelling Language (UML) or the Business Process Modelling Notation (BPMN). Information Modelling may result in data models or templates that represent an underlying process.
Programming is defined as relating to the way in which computer code is written. It can involve choosing certain options or conventions for performing a common functional operation, or defining and providing a programming language, including text-based or graphical systems.
This sub-section stresses that information modelling or programming features that improve the intellectual effort of a programmer or software developer will often be seen to lack technical character and so cannot contribute to an inventive step. Benefits such as re-usability, platform-independence, conciseness, easier code-management or convenience for documentation, are not regarded as technical effects. For a feature to provide a technical effect, it must provide an improvement from the viewpoint of the computer, as opposed to the programmer. For example, manipulating machine code to provide for greater memory efficiency is seen as providing a technical contribution.
Data retrieval, formats and structures
Computer-implemented data structures or data formats embodied on a medium or as an electromagnetic carrier wave may be claimed, as they do not fall within the exclusions of Article 52(2) EPC. This sub-section has been relocated from previous section 3.7.
This section emphasises that cognitive data, i.e. data that is only relevant to a human user, cannot normally contribute to an inventive step. However, functional data, i.e. data that controls a device processing the data and that reflects technical features of the device, can.
Some examples of functional data are provided. These include a picture encoding, an index structure for a relational database, or a header structure of an electronic message. It is emphasised that the actually data content of the picture, database record or electronic message is often seen to be cognitive content and so cannot contribute to an inventive step.
When working with neural network architectures we need good datasets for training. The problem is good datasets are rare. In this post I sketch out some ideas for building a dataset of smaller, linked portions of a patent specification. This dataset can be useful for training natural language processing models.
What are we doing?
We want to build some neural network models that draft patent specification text automatically.
In the field of natural language processing, neural network architectures have shown limited success in creating captions for images (kicked off by this paper) and text generation for dialogue (see here). The question is: can we get similar architectures to work on real-world data sources, such as the huge database of patent publications?
How do you draft a patent specification?
As a patent attorney, I often draft patent specifications as follows:
Review invention disclosure.
Draft independent patent claims.
Draft dependent patent claims.
Draft patent figures.
Draft patent technical field and background.
Draft patent detailed description.
The invention disclosure may be supplied as a short text document, an academic paper, or a proposed standards specification. The main job of a patent attorney is to convert this into a set of patent claims that have broad coverage and are difficult to work around. The coverage may be limited by pre-existing published documents. These may be previous patent applications (e.g. filed by a company or its competitors), cited academic papers or published technical specifications.
Where is the data?
As many have commented, when working with neural networks we often need to frame our problem as map X to Y, where the neural network learns the mapping when presented with many examples. In the patent world, what can we use as our Xs and Ys?
If you work in a large company you may have access to internal reports and invention disclosures. However, these are rarely made public.
To obtain a patent, you need to publish the patent specification. This means we have multiple databases of millions of documents. This is a good source of training data.
Standards submissions and academic papers are also published. The problem is there is no structured dataset that explicitly links documents to patent specifications. The best we can do is a fuzzy match using inventor details and subject matter. However, this would likely be noisy and require cleaning by hand.
US provisional applications are occasionally made up of a “rough and ready” pre-filing document. These may be available as priority documents on later-filed patent applications. The problem here is that a human being would need to inspect each candidate case individually.
Claim > Figure > Description
At present, the research models and datasets have small amounts of text data. The COCO image database has one-sentence annotations for a range of pictures. Dialogue systems often use tweet or text-message length text segments (i.e. 140-280 characters). A patent specification in comparison is monstrous (around 20-100 pages). Similarly there may be 3 to 30 patent figures. Claims are better – these tend to be around 150 words (but can be pages).
To experiment with a self-drafting system, it would be nice to have a dataset with examples as follows:
Independent claim: one independent claim of one predefined category (e.g. system or method) with a word limit.
Figure: one figure that shows mainly the features of the independent claim.
Description: a handful of paragraphs (e.g. 1-5) that describe the Figure.
We could then play around with architectures to perform the following mappings:
One problem is this dataset does not naturally exist.
Another problem is that ideally we would like at least 10,000 examples. If you spent an hour collating each example, and did this for three hours a day, it would take you nearly a decade. (You may or may not also be world class in example collation.)
The long way
Because of the problems above it looks like we will need to automate the building of this dataset ourselves. How can we do this?
If I was to do this manually, I would:
Get a list of patent applications in a field I know (e.g. G06).
Choose a category – maybe start with apparatus/system.
Get the PDF of the patent application.
Look at the claims – extract an independent claim of the chosen category. Paste this into a spreadsheet.
Look at the Figures. Find the Figure that illustrated most of the claim features. Save this in a directory with a sensible name (e.g. linked to the claim).
Look at the detailed description. Copy and paste the passages that mention the Figure (e.g. all those paragraphs that describe the features in Figure X). This is often a continuous range.
The shorter way
There may be a way we can cheat a little. However, this might only work for granted European patents.
One bug-bear enjoyable part of being a European patent attorney is adding reference numerals to the claims to comply with Rule 43(7) EPC. Now where else can you find reference numerals? Why, in the Figures and in the claims. Huzzah! A correlation.
So a rough plan for an algorithm would be as follows:
Get a list of granted EP patents (this could comprise a search output).
Define a claim category (e.g. based a string pattern – [“apparatus”, “system”]).
Extract paragraphs from the description that contain the extracted reference numerals (likely with some threshold – e.g. consecutive paragraphs with greater than 2 or 3 inclusions).
Save the paragraphs and the claim, together with an identifier (e.g. the published patent number).
Determine a candidate Figure number from the extracted paragraphs (e.g. by looking for “FIG* [/d]”).
Fetch that Figure using the EPO OPS “Drawings” or images retrieval API.
Now we can’t retrieve specific Figures, only specific sheets of drawings, and only in ~50% of cases will these match.
We can either:
Retrieve all the Figures and then OCR these looking for a match with the Figure number and/or the reference numbers.
Start with a sheet equal to the Figure number, OCR, then if there is no match, iterate up and down the Figures until a match is found.
See if we can retrieve a mosaic featuring all the Figures, OCR that and look for the sheet number preceding a Figure or reference numeral match.
Save the Figure as something loadable (TIFF format is standard) with a name equal to the previous identifier.
The output from running this would be triple similar to this: (claim_text, paragraph_list, figure_file_path).
We might want some way to clean any results – or at least view them easily so that a “gold standard” dataset can be built. This would lend itself to a Mechanical Turk exercise.
We could break down the text data further – the claim text into clauses or “features” (e.g. based on semi-colon placement) and the paragraphs into clauses or sentences.
The image data is black and white, so we could resize and resave each TIFF file as a binary matrix of a common size. We could also use any OCR data from the file.
What do we need to do?
Initially we could start with a smaller dataset of say 10 or 100 examples. Get that working. Then scale out to many more.
If the EPO OPS is too slow or our downloads are too large, we could use (i.e. buy access to) a bulk data collection. We might want to design our algorithm so that the processing may be performed independently of how the data is obtained.
Another option is that front page images of patent publications are often available. The Figure published with the abstract is often that which the patent examiner or patent drafter thinks best illustrates the invention. We could try to match this with an independent claim. The figure image supplied though is smaller. This maybe a backup option if our main plan fails.
So. We now have a plan for building a dataset of claim text, description text and patent drawings. If the text data is broken down into clauses or sentences, this would not be a million miles away from the COCO dataset, but for patents. This would be a great resource for experimenting with self-drafting systems.
This article will look into how the process of obtaining a patent could be automated using deep learning approaches. A possible pipeline for processing a patent application will be discussed. It will be shown how current state of the art natural language processing techniques could be applied.
Brief Overview of Patent Prosecution
First, let’s briefly look at how a patent is obtained. A patent application is filed. The patent application includes a detailed description of the invention, a set of figures, and a set of patent claims. The patent claims define the proposed legal scope of protection. A patent application is searched and examined by a patent office. Relevant documents are located and cited against the patent application. If an applicant can show that their claimed invention is different from each citation, and that any differences are also not obvious over the group of citations, then they can obtain a granted patent. Often, patent claims will be amended by adding extra features to clearly show a difference over the citations.
For a deep learning practitioner the first question is always: what data do I have? If you are lucky enough to have labelled datasets then you can look at applying supervised learning approaches.
It turns out that the large public database of patent publications is such a dataset. All patent applications needs to be published to continue to grant. This will be seen as a serendipitous gift for future generations.
In particular, a patent search report can be thought of as the following processes:
A patent searched locates a set of citations based on the language of a particular claim.
Each located citation is labelled as being in one of three categories:
– X: relevant to the novelty of the patent claim.
– Y: relevant to the inventive step of the patent claim. (This typically means the citation is relevant in combination with another Y citation.)
– A: relevant to the background of the patent claim. (These documents are typically not cited in an examination report.)
In reality, these two processes often occur together. For our ends, we may wish to add a further category: N – not cited.
Thinking as a data scientist, we have the following data records:
This data may be retrieved (for free) from public patent databases. This may need some intelligent data wrangling. The first process may be subsumed into the second process by adding the “not cited” category. If we move to a slightly more mathematical notation, we have as data:
(c, d, s)
Where c and d are based on a (long) string of text and s is a label with 4 possible values. We then want to construct a model for:
P(s | c, d)
I.e. a probability model for the search classifications given the claim text and citation detailed description. If we have this we can do many cool things. For example, for a set c, we can iterate over a set of d and select the documents with the highest X and Y probabilities.
Representations for c and d
Machine learning algorithms operate on real-valued tensors (n*m -dimensional arrays). more than that, the framework for many discriminative models maps data in the form of a large tensor X to a set of labels in the form of a tensor Y. For example, each row in X and Y may relate to a different data sample. The question then becomes how do we map (c, d, s) to (X, Y)?
Mapping s to Y is relatively easy. Each row of Y may be an integer value corresponding to one of the four labels (e.g. 0 to 3). In some cases, each row may need to represent the integer label as a “one hot” encoding, e.g. a value of  > [0, 0, 1, 0].
Mapping c and d to X is harder. There are two sub-problems: 1) how do we combine c and d? and 2) how do we represent each of c and d as sets of real numbers?
There is an emerging consensus on sub-problem 2). A great explanation may be found in Matthew Honnibal’s post Embed, Encode, Attend, Predict. Briefly summarised, we embed words from the text using a word embedding (e.g. based on Word2Vec or GloVe). This outputs a sequence of real-valued float vectors for each word (e.g. vectors of length ~300). We then encode this sequence of vector into a document matrix, e.g. where each row of the matrix represents a sentence encoding. One common way to do this is to apply a bidirectional recurrent neural network (RNN – such as an LSTM or GRU), where outputs of a forward and backward network are concatenated. An attention mechanism is then applied to reduce the matrix to a vector. The vector then represents the document.
A simple way to address sub-problem 1) is to simply concatenate c and d (in a similar manner to the forward and backward passes of the RNN). A more advanced approach might use c as an input to the attention mechanism for the generation of the document vector for d.
Obtain the Data
To get our initial data records – (Claim text, citation detailed description text, search classification) – we have several options. For a list of patent publications, we can obtain details of citation numbers and search classifications using the European Patent Office’s Open Patent Services RESTful API. We can also obtain a claim 1 for each publication. We can then use the citation numbers to look up the detailed descriptions, either using another call to the OPS API or using the USPTO bulk downloads.
I haven’t looked in detail at the USPTO examination datasets but the information may be available there as well. I know that the citations are listed in the XML for a US grant (but without the search classifications). Most International (PCT / WO) publications include the search report, so as a push you could OCR and regex the search report text to extract a (claim number, citation number, search category) tuple.
Once you have a dataset consisting of X and Y from c, d, s, the process then just becomes designing, training and evaluating different deep learning architectures. You can start with a simple feed forward network and work up in complexity.
I cannot guarantee your results will be great or useful, but hey if you don’t try you will never know!
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.
“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.
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.
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…
Often you are faced with the question: should I patent my invention? A quick, back-of-the-envelope calculation can help with this decision.
CAVEAT: these are all roughly sketched out figures. This post is written in my spare time between cooking, cleaning, childcare and work. It does not constitute legal or financial advice. The figures are rough generalisations that allow you to work out whether it’s worth investigating further but may vary considerable for each individual case. Always get professional help with the details.
Obtaining a patent is not a cheap process. As of 2017, my very rough rule-of-thumb is to budget £50k per country over the 20 year lifetime (excluding taxes – ~$75k).
This is based on, for a typical case:
~£10k for initial work (e.g. searching), drafting an application and the costs of first (i.e. priority) filing.
~£10k for developing strategy after an initial patent office search (e.g. UKIPO or in the International phase) and for filing an International patent application within a year of the first filing.
~£5k per country to enter the national or regional phase after the end of the International phase for the International application. This is about right for a simple US and European entry; countries requiring translations may be up to £10k per country.
~£15k per country for prosecution and grant. This is likely the most variable figure, with variance typically being on the upside (i.e. more expensive) if you are unlucky with prior art or a particular obstinate examiner.
~£10k per country for renewal fees over 20 years. Again, this varies per country.
In terms of the distribution with time, this breaks down to:
~£10k / year for first 3-4 years.
~£0.5-1k / year for next 16-17 years.
Hence, most of the costs are front-loaded to the first 3-4 years: you need ~£30k over this period to properly take part in the patenting process.
Return on Investment
For a decent return, you want the patent’s value over its 20 year life to be at least 3x its cost (excluding inflation). Say this is £150k.
This works out as a real return of at least 5-6% per year over the lifetime of the patent.
The value of a patent is unlikely to be gained evenly over its lifetime. Statistics show that much of a patent’s value is realised towards the end of its life, e.g. 10-15 or 15-20 years post filing.
Anything less than this and your business would be better off just investing in the stock market.
How to Determine Value
This is normally the hard part. However, there are a few short-cuts.
Most of the claims, understandably, were made by large companies. As such, the £500k / year average claim may include a number of different patented products. However, small businesses often only have one or two patents or products. Hence, the small business claim may be closer to a lower bound on yearly value per patent.
Of course, you can perform your own calculations. For a very rough upper bound on the benefit, simply add up the profits derived from each of your main products or services and multiply by 0.1. (This does assume you are making a profit.) For a lower bound, multiply this 10% saving by 0.5.
Now remember this is a yearly saving. The total saving will thus depend on the lifetime of your product.
Assuming a rough product lifetime of 10 years, and a lower bound on the tax claim of £15k / year, this means that an average UK patent provides a saving of £150k over its lifetime. This just happens to be the number we came up with above for a decent return.
From these rough calculations we see a couple of things:
To justify a UK patent’s value based on a Patent Box claim, you need to be making around £150k / year in profit for at least one product or service.
If this applies, a UK patent covering the product or service will pay for its costs and make a decent return.
Patenting can thus be economically justified in this case.
Another way a patent can provide a return is through licensing. (Someone pays you for your permission to use the technology of the patent.)
Looking at our rough figures, you would need licence fees of ~£150k over 20 years, or approximately £7.5k / year.
Hence, if you feel that you can get one or more companies to pay £10k / year for the technology, patenting is worthwhile.
In this case, an average worldwide FRAND licence rate for major markets for mobile equipment and infrastructure for a portfolio of 2G, 3G and 4G patents was deemed to be 0.05%. Now Unwired Planet have around 2,500 patents. Some googling indicates total infrastructure and handset sales to be around $150 billion (split 1:2). If everyone licensed at this rate, the annual licensing revenue would be $7.5 billion, divided by 2,500 patents gives you an average licensing income of $3 million (~£2 million) per patent per year.
Of course this is an upper-upper-bound estimate, you won’t get a licensing fee from each sale and this may be time-limited (e.g. the value of 2G technology not used in current handsets is falling). However, it does show that a licensing revenue of £20 million per patent over its lifetime is not completely pie-in-the-sky and may be relevant if you are lucky and patent a subsequent core technology.
In this case, IBM covers its patenting costs, but there is only a small real return from licensing alone. Hence, for IBM licensing is a useful aspect to cover costs, but must form only a portion of the value of a given patent.
Valuing individual patents is tricky. This article here is interesting – http://www.hayes-soloway.com/patent-valuation . It suggests a lower bound on patent transactions of around $90,000 (£70k), a median of around $200k (£150k) and an average of around $400k (£300k). Each of Kodak’s patents was valued at around $500k when recently sold in 2012.
These valuations are consistent with the numbers discussed so far. The lower bound on the value of patents when sold is a little above cost (but not below cost). The median amount provides the magical £150k figure discussed above, i.e. a real return of around 5-6%. If you are lucky and/or skilled (delete depending on your political persuasion), a value of around £300k provides a decent market-beating return of around 10%. The higher figures also compensate for the fact that average patent grant rates are around 50% – hence, there is a certain amount of survivor bias and each of these sells would need to factor in the sunk costs of their unsuccessful brethren.
Another caveat here – patents tend to be very illiquid and most patent transactions involve large companies with large patent portfolios. Hence, while these figures may be applicable to similar sized entities, they may not apply as much to small and medium sized businesses. The distribution of values is also likely to be a power law distribution, with a few patents having astronomical valuations, and a long tail of patents with low valuations.
Here, we see that if you are a large company, it is worth patenting for the value you realise if you sell your patents.
Access to Market
We now move into the more hand-wavy aspects of patent valuation.
Underlying all this discussion is the fact that patents allow you to sue those who are providing products without your permission that fall within your patent claims . Licensing is one way to realise this value by providing permission for cash.
Another way patents can provide value is by allowing you access to a market at a low cost through cross-licensing. This is where another entity has at least one patent that covers your product or service. They could thus prevent you from accessing the market by either refusing permission or demanding high licensing fees. However, you have a patent that covers their product or service. Hence, each side has a potential weapon they can deploy and the sensible outcome is to come to an agreement to provide permission to use each other’s technology.
The problem with cross-licensing is that these deals are typically performed in confidence. There is thus little data to quantify the transaction. Standard public licensing rates provide some indication of the value. Hence, the licensing figures from above may be used here.
Average licensing rates can vary from 0.01% to 30% depending on the technology, product and market. Most are probably below 5-10%, with higher rates for low volume, high profit products (e.g. software services) and lower rates for commodity items (e.g. phone handsets).
One (very rough) way you can value access to a market is thus to:
determine the size of the potential market for your product;
determine an average revenue for you for this market over a 20-year period; and
times this by 10%.
Working backwards from our figures above, this gives us an average revenue of £150k / 0.1 = £1.5 million over 20 years (which may be £300k / year for a 5 year lifespan, £150k / year for a 10 year lifespan, and £75k / year for a 20 year lifespan etc.).
If you are not selling your product yet, you can look at figures for the size of the potential market by dividing these figures by an estimated, percentage market share. For example, if you believe you can gain 10% of a market, the market needs to be worth £15 million over the 20 years (e.g. £3 million / year for a 5 year lifespan, £1.5 million / year for a 10 year lifespan, and £750k / year for a 20 year lifespan etc.).
The other flip-side to this is to look at the cost of litigation. If cross-licensing can avoid the costs of litigation then this also provides value. If we say an average court case costs between £1-3 million, then the value of your patent depends on the likelihood of litigation. In this case, if a chance of litigation is above 15%, patenting is cost effective. Here, you can also ask for a quote for litigation insurance in your market and use that to determine the value of any patent on a competitor’s product or service.
These simple calculations mean that, for a product with a 5 year lifespan and a potential market of only £100k per year, patenting may not be cost effective if looking at access to market.
One reason why small businesses obtain patents is to gain investment.
Likewise, one reason venture capitalists invest in small businesses with patents is because they perform similar calculations to those above (although with prettier and more accurate spreadsheets) and realise they can obtain an above market return (or a market return for a given risk – 90% of small businesses fail folks).
Now venture capitalists have requests for funding from many small startups (understatement). Most of these will be refused. One way you can cut through the noise as a company is to show you have at least a strong chance of obtaining a patent. Hence, a patent application may provide an immediate effect by enabling leverage – i.e. the patenting costs may facilitate a much large amount of funding.
Of course, there are many different factors that influence funding, and most of these may be more important than a patent portfolio (such as founders / founder experience, market proposition, existing capital raised, and existing profit). Let’s say, conservatively, that having a patent increases your chance of funding from 0% to 10%. In this case, funding of £200k plus would justify an initial £20k patent spend (e.g. initial filing and International application).
Another way of looking at this may be to compare patenting costs and engineer costs. Say an engineer costs £50k / year, where on-costs are £75k (i.e. actual cost to company is 1.5x salary). The question to then ask is: what would increase your chances of funding more: 4 months of that engineer’s time or having a patent application?
If the answer is that, at your current stage of development, 4 months engineer time would greatly enhance your offering and increase your chance of funding by 50%, then limited funds may be better spent on that rather than patenting.
If you are at a stage where development has been kept confidential, and 4 months of engineer time would make only small incremental improvements to attract funding, then patenting becomes a better choice.
You can also run similar arguments with consultant costs and other areas such as marketing.
Patented products make for good marketing.
This may only be a small proportion of a patent’s value but should not be overlooked.
For example, an average marketing budget may be 10% of sales. If a patent replaces 1% of that (i.e. has the same effect as 1% of the sales budget), then a patent could start to make a decent return if revenues are £15 million or more over 10 year (i.e. £1.5 million / year).
What Have We Learnt
Often it is difficult to provide an answer to the question: should I get a patent?
Patent attorneys typically err on the side of saying “yes”, as that is what they do day-in-day-out. It can be like asking a decorator: should I paint my house? (I decided not to say it may be like asking a car salesman: should I buy a car? :))
In certain businesses the answer is often “yes”, but the reason is “because that’s what we do”. Similar, in other businesses (I’m looking at you software), the answer is often “no”, with the reason being “because we don’t do that here”.
Hopefully, in the discussion above, I have tried to explain some of the areas and conditions where there may be an economic justification for obtaining a patent.
In particular, assuming a product with a 10 year lifespan, patenting may be cost effective:
if you are paying UK corporation tax and your product will earn £150k / year in profit;
if your market is worth more than £1.5 million per year and you can capture at least 10% of this;
if the patented technology is of interest to one or more acquirers;
if the chance of litigation is above 15% in your market;
if it increases your chance of funding from 0 to 10%; or
if it increases sales by 1% of products with revenues of more than £1.5 million / year.
Some of these value factors may be gained independently. For example, a patent may allow you to reduce UK corporation tax, increase sales, provide access to a market and reduce litigation risk. The more the factors apply cumulatively, the lower the figures above need to be.
By sketching these numbers out on the back of an envelope, say over 30 minutes, you can get a feel for how relevant patenting is for your company.
If you look at these figures and gasp, then patenting may not be right for you. Although patenting is open to anyone, practically you need to be a business with actual or projected revenues of hundreds of thousands of pounds for the system to work properly.
If you are close to break-even thresholds, there need to be other good reasons to patent, or prospects for future growth need to be good, otherwise patenting may not be worthwhile economically.
If you are way over the thresholds, and you do not have a patenting strategy, then this provides strong basis for an argument to your Board of Directors to get one. It may justify spending a few thousand pounds on professional advice to fill in the details of feasibility.
If you have an existing patenting strategy, running these calculations once a year or so may enable you to make decisions on maintaining patents and patent applications, and provide justification to support existing budgets (or even to ask for more funds).
Obtaining a patent is an uncertain process. It is difficult, if not impossible, to predict the prior art that may be located or the examiner you are assigned. Grant rates often vary from 5 to 50%, and it is rare for patent claims to be allowed without limitations during prosecution. However, there are techniques to manage this uncertainty. Some of these are discussed below.
The International Patent Application
For many businesses, the US and Europe are core markets. To obtain patent protection in these markets, many patent attorneys advise filing an International patent application (also called a Patent Cooperation Treaty – PCT – application). An International patent application only needs to be converted into specific national or regional applications 30 months from an initial filing or priority date. This provides time for a product or service to develop in parallel with a pending application and leaves open the possibility of obtaining protection in states such as Japan, China, Korea and Australia.
An International patent application is searched and a written opinion is drawn up by an examiner. The written opinion resembles an examination report. For applicants from Europe, the European Patent Office prepare these documents. The European Patent Office is seen internationally as one of the tougher patent offices; I often see cases with favourable opinions from examiners in the US, Korea and China hit objections when the case is examined by the European Patent Office.
There are also costs to consider. Patenting is not cheap. Depending on length and scope, a patent application will likely cost between £5-10k (all figures are excluding taxes and at 2017 rates) to be drafted. Filing costs for an International patent application are £4-5k (most of this being official fees). Filing costs for national or regional applications at the end of the International phase will cost between £5-10k (a chunk of this being official fees and/or translation costs). Then it may cost between £5-15k to prosecute an application and pay grant fees. A good rule of thumb is £30k per country over a 3-7 year period.
Faced with this, a strategy I often suggest is set out below:
Initial UK Patent Filing
First, it is worth noting that I would not attempt the patenting process unless I could budget around £10k per year over the first 3 years.
Second, it is good to take advantage of the ease and low cost of the UK Intellectual Property Office for a first filing. Official fees are only £230 for filing, search and examination (a bargain really – European Patent Office fees are 10x this). Unlike the US there is no need for assignments and declarations to be filed. You can register this first filing with the priority document access service as well, which makes supply of a certified copy of the priority document a doddle.
UK Combined Search and Examination Report
The UK Intellectual Property Office provide a combined search and examination report with 4-6 months. You can ask to accelerate this and if you have a good reason the request is often granted, shortening the time to 4-8 weeks. While a UK search is often not quite as thorough as an European search, it is quick and cheap (e.g. as compared with Europe or US). It is thus a useful way of identifying any “low-hanging” prior art that may be problematic.
For example, if “knock-out” prior art is located you can choose to withdraw the application within the first 12 months before publication. This helps to cap your loss at the £10k or so of initial costs; it prevents you spending another £20k only to get a refusal on subsequent national or regional applications (or even to have a patent that would easily get knocked out in court). Withdrawing before publication means the content of the patent application will not become public and count against future applications you may make. This is useful if the patent application relates to a product in development; you may come up with an improvement after a year that could support a further patent application that can reuse much of the initial material.
Even if “knock out” prior art is not found, the UK combined search and examination report can help you strengthen your patent claims. For example, prior art may be cited that anticipates your main claims but an amendment is possible that renders the claims novel and inventive over the cited documents. It is definitely better to work this out over a leisurely 4 month period (e.g. iterating with the inventors who may still remember the case), rather than rush this just before priority-claiming applications need to be filed at the 12-month point. While you can never be sure that subsequent searches by other patent offices will not find other, more relevant prior art, an amendment at this stage is often going to be taking your application in the right direction and will be making favourable opinions more likely. Engineers may like to see this as a first “stress test” for the patent application.
The UK combined search and examination report may also flag other issues such as clarity or support that are best dealt with early on. For example, a term you and your inventors thought was well-known may be considered by the UK examiner to be unclear; the specification may then be amended to provide a more in-depth definition from text-books or Wikipedia.
If you do need to amend the claims at this 6-12 month stage, another advantage is that you can make sure that you maximise the scope of positions covered by your patent claims. For example, you first filing may have 20 patent claims. If a number of these claims are deemed obvious over the general knowledge or certain claims need to be added to the main independent claims, then claims may be deleted and other improved fall-back positions added.
Typically, it is good to set aside some inventor time, and a budget of £1-2k to review the UK combined search and examination report and cited art. I often see those who choose not to make this investment at this stage be subject to avoidable higher costs later on in prosecution.
If you have a set of patent claims that are novel and inventive over the prior art cited by the UK Intellectual Property Office, the next stage is to file an International patent application within 12 months of the initial filing date.
If you are a UK company, the European Patent Office will perform another search and issue a written opinion setting out any objections. They are pretty good at issuing this within 4-6 months of filing the International patent application. The European search and written opinion provides the second “stress test” of the claims.
Often the European examiner will locate new prior art. One way to reduce this risk is to amend the background of the patent specification before filing the International patent application to make reference to the prior art located in the UK search. In 25-50% of cases, if the UK-cited prior art is relevant and reasonable, the European examiner will (understandably) take the easier option of citing it again. At the very least, referencing the UK-cited art can help you “seed” the European search towards areas you have had time to analyse.
If the European examiner does locate new prior art, then again it is recommended to repeat the same analysis that was performed for the UK combined search and examination report. Often you still have over a year before choices regarding national or regional applications need to be made. A relatively leisurely 4-8 weeks review cycle, incorporating comments from inventors or other engineers, at an attorney cost of £1-2k, can again reap cost savings later on in prosecution.
For example, if the European cited art is “knock out”, costs can be capped at around £15k (e.g. drafting, UK filing, PCT filing and review costs). It may not be possible to have the search results in time to be able to stop publication (which is why the UK search is good). This may seem a lot but it prevents additional spends of £15-20k per country (e.g. £30k < spend < £80k) only for you to receive multiple refusals 2-3 years later.
If amendment is possible, then this can be determined following a review of the prior art and a claim set prepared for national and regional applications. At this stage you may have more confidence in the claims as you know they have been through both UK and European examination. This may make it easier to justify patent applications in multiple countries to a company board or budget comittee.
This process represents an additional spend of up to £4k in attorney time. However, this easily pays for itself:
It can avoid spending up to £40k+ on patent applications worldwide that are unlikely to be granted.
It can avoid long and protracted European Patent prosecution.
It often simply represents front-loading of costs that would be occurred in normal prosecution.
It allows leisurely review while the case may still be fresh in inventors minds (with touch points at 6 and 18 months following the filing process). This can also promote inventor engagement with the patent process.
The possibility of Patent Prosecution Highways could avoid long and protracted prosecution In multiple countries.
If you do obtain a patent it is likely to be stronger and hence of more value.
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;
High prosecution spend; or
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.
As you work as a patent attorney you meet many small to medium enterprises (SMEs – businesses with under 250 employees – also known as “small entities” in the US). Everyone has a different level of knowledge, and some companies are unaware of how they can get a better deal. To remedy this, here is my guide to commissioning patent work.
The advice is roughly split into the following areas:
Use competition to your advantage;
Prepare to better use your time;
Meet the people doing the work;
Look for a commercial and technical fit;
Agree on costs and timings in advance; and
Agree on workflow in advance.
Use competition to your advantage
Patent firms (at least in the UK) will offer a free 30-minute consultation to potential new clients. Patent firms do this to get new business. It is often recommended to meet at least three firms to compare costs, people and approach. This means you can get up to 1.5 hours of free legal advice.
You can create a shortlist by looking for local patent firms. For SMEs, local firms (i.e. outside of London) are often a better fit on price and people, and organising company visits is easier. Many university cities have patent law firms, so a good play to start is to pick your nearest and search the Internet for “patent firm [nearest city]”. Have a look at the firms’ websites. You can normally get a feel for the size of a firm and their area(s) of expertise from their website.
If you are in a main patent hub (e.g. London or Munich), look for firms involved in activities that over lap with yours, e.g. firms that have talked at a nearby incubator or known industry group.
Firms are often split into four or so subject areas: pharma & biotech; chemistry; mechanical / heavy engineering; and IT & electronics. Many firms are better in one of these areas and weaker in others. Look for numbers of attorneys, their backgrounds and mentions of key clients to work out strengths and weaknesses. Try to shortlist firms with a strong practice group in your area of business.
Arrange meetings with your shortlist of firms by email or phone.
Prepare to better use your time
Ahead of your initial meetings, there is some preliminary work you can do to maximise your free legal advice and test your prospective firms. This often needs to be an hour or so of preparation: one page of A4 is about right.
First, attempt to write down why you need patent services. Do this in plain English. For example:
I need to stop my competitors doing X.
I have a new product that in launching in two months. We have spent Y on R&D.
We need investment. We have seed/series A/series B funding. We are looking at acquisition in as an exit in two to three years.
We have a few patents. We wish to monetise our portfolio.
Information that is useful to a patent attorney includes:
Your key markets (current and future);
Where you manufacture;
Your competitors (and their key markets / places of manufacture);
Your launch schedule; and
Your general business direction over the next 5-10 years (at a brief, high level).
If you have this information in pre-existing material (e.g. an investor or shareholder pack), you can provide this ahead of your meeting. It is worth keeping this high level and keeping as much as possible to publicly known details.
If you have a new product or idea, it may also be worth doing an hour or so of Internet searching and selecting the three most relevant finds. These may be supplied ahead of your meeting (e.g. send three URLs with brief notes – “This blog post describes something similar to the first step”).
If you can send this information, in confidence, ahead of your meeting then it is likely your prospective patent firms will do at least an additional 30 minutes of preparation before your meeting, and you will get better advice to compare. It also frees up time in the meeting to discuss strategy rather than go over these points. If you prefer not to send confidential details ahead of time, take your page of A4 as a meeting prompt.
Meet the people doing the work
A traditional way of law firms acquiring new clients is as follows:
Prospective client meets charismatic partner at an event / on the golf course;
A meeting is arranged with law firm via charismatic partner, who attends;
The work starts and charismatic partner vaporises – a series of unknown associates impersonally deal with the work.
There is nothing necessarily malicious in this, some partners are better at sales, associates often do a bulk of the work due to the “leverage” model of law firms. It can, however, leave a bad taste if unexpected.
One way to avoid this is to ask to meet all those who will be potentially working with the company. Most patent firms should be happy to oblige. Be a little wary of those that refuse.
Look for a commercial and technical fit
A perfect technical match may be difficult to find. If there is a perfect match, there is often a conflict, e.g. the firm may work for one of your competitors. If you need to discuss sensitive commercial details in your initial meeting, you may wish to ask the patent firms you are meeting to perform a conflict check and confirm there is no conflict *before* you meet (or before you send them non-public information).
Sometimes you may get lucky and a technical fit may exist due to a recent client change (e.g. a past client was acquired and the work was moved to the patent firm of the parent company). This is probably the exception rather than the rule.
For a general technical fit look for:
Patent attorneys with a technical degree in your area of technology;
Current or recent experience in a neighbouring non-competing field;
Familiarity with at least general core concepts of your technology (if not your particular niche); and
For a commercial fit look for:
Experience of similar size companies (e.g. revenue-wise) ;
Experience with your business model (e.g. software licensing vs. chemical manufacturing); and
General knowledge of your industry and market (e.g. at a Bloomberg, Economist or FT level).
Look for those that listen.
Agree on costs and timings in advance
When you are obtaining cost estimates ask for prospective costs over the next year. Also ask to identify one or two key billing points over the year for costs to be charged.
An often heard criticism from companies is the stream of small bills from patent firms after a particular piece of work has been done. This is often due to the nature of the hourly billing module – small bits of work are often needed after an event of when miscellaneous communications arrive. Firms also wish to avoid having unpaid work sitting on their systems. One way to avoid this is to either include small future predictable costs in initial charges (firms often avoid doing this as it raises their estimates in comparison with other firms) or to have agreed billing points. For example, filing an application and filing a response are two normal billing points – you can ask that all others charges are also billed at these points with the substantive work.
Companies should also ask for caps or fixed prices for the work. Most patent firms should oblige if these are reasonable. This makes costs more predictable for the company, avoids surprise charges and often gets them a better deal.
Agree on workflow in advance
Patent attorneys charge for their time. Companies thus have a trade-off when commissioning patent work: they can save their time (e.g. engineer or C-level time) at the expense of higher patent attorney charges; or they can agree to do more on their end to save patent attorney costs.
For example, one substantial part of responding to examination reports is reviewing the cited prior art (typically 2-4 20-50 page patent publications). If a company wish to save on patenting costs, they can perform this work in-house (e.g. make it part of an engineer role). If a company provides guidance on differences and advantages (even if these are not put in legal terms), they can negotiate lower charges for responding to an examination report. If, on the other hand, engineer time is at a premium, they may ask that the patent attorney provides options or a proposal for their review (this should be provided at an executive summary level).
Similarly, to avoid drift, loss of momentum or extra charges, a timescale for work on both ends should be agreed at a high level. For example, it may be agreed that a draft will take 4 weeks to prepare and that engineers will review within 1 or 2 weeks of receipt. Similarly, it may be agreed that all official communications and filings are to be reported with 5 working days, or that engineers need 4 weeks to review cited prior art.
It is also a good idea to agree who is going to be the main point of communication on both sides, and whether any additional stakeholders need to be cc-ed by default (e.g. engineering managers, directors, secretaries, etc.).
This should not take too long to work out (e.g. a 30 min phonecall or a quick email exchange) but it pays dividends later on in the relationship (and avoids “surprise” charges cropping up).
In a previous post, we looked at some measures of patent attorney (or firm) success:
Timely actions; and
High legal success rate.
In this post, we will look at how we can measure these.
Let’s start with legal success. For legal success rate we identified the following:
Case grants (with the caveat that the claims need to be of a good breadth);
Cases upheld on opposition (if defending);
Cases revoked on opposition (if opposing);
Oral hearings won; and
Court cases won.
When looking to measure these we come across the following problems:
It may be easy to obtain the grant of a severely limited patent claim (e.g. a long claim with many limiting features) but difficult to obtain the grant of a more valuable broader claim (e.g. a short claim with few limiting features).
Different technical fields may have different grant rates, e.g. a well-defined niche mechanical field may have higher grant rates than digital data processing fields (some “business method” areas have grant rates < 5 %).
Cases are often transferred between firms or in-house counsel. More difficult cases are normally assigned to outside counsel. A drafting attorney may not necessarily be a prosecuting attorney.
During opposition or an oral hearing, a claim set may be amended before the patent is maintained (e.g. based on newly cited art). Is this a “win”? Or a “loss”? If an opponent avoids infringement by forcing a limitation to a dependent claim, that may be a win. What if there are multiple opponents?
In court, certain claims may be held invalid, certain claims held infringed. How do you reconcile this with “wins” and “losses”?
One way to address some of the above problems is to use a heuristic that assigns a score based on a set of outcomes or outcome ranges. For example, we can categorise an outcome and assign each category of outcome a “success” score. To start this we can brainstorm possible outcomes of each legal event.
To deal with the problem of determining claim scope, we can start with crude proxies such as claim length. If claim length is measured as string length, (1 / claim_length) may be used as a scoring factor. As automated claim analysis develops this may be replaced or supplemented by claim feature or limiting phrase count.
Both these approaches could also be used together, e.g. outcomes may be categorised, assigned a score, then weighted by a measure of claim scope.
For example, in prosecution, we could have the following outcomes:
Application abandoned; and
Application refused is assigned the lowest or a negative score (e.g. -5). Abandoning an application is often a way to limit costs on cases that would be refused. However, applications may also be abandoned for strategic reasons. This category may be assigned the next lowest or a neutral score (e.g. 0). Getting an application granted is a “success” and so needs a positive score. It maybe weighted by claim breadth (e.g. constant / claim_length for shortest independent claim).
In opposition or contentious proceeding we need to know whether the attorney is working for, or against, the patent owner. One option maybe to set the sign of the score based on this information (e.g. a positive score for the patentee is a negative score for the opponent / challenger). Possible outcomes for opposition are:
Patent maintained (generally positive for patentee, and negative for opponent);
Patent refused (negative for patentee, positive for opponent).
A patent can be maintained with the claims as granted (a “good” result) or with amended claims (possibly good, possibly bad). As with prosecution we can capture this by weighting a score by the scope of the broadest maintained independent claim (e.g. claim_length_as_granted / claim_length_as_maintained).
Oral hearings (e.g. at the UK Intellectual Property Office or the European Patent Office) may be considered a “bonus” to a score or a separate metric, as any outcome would be taken into account by the above legal result.
For UK court cases, we again need to consider whether the attorney is working for or against the patentee. We could have the following outcomes:
Patent is valid (all claims or some claims);
Patent is invalid (all claims or some claims);
Patent is infringed (all claims or some claims);
Patent is not infringed (all claims or some claims);
Case is settled out of court.
Having a case that is settled out of court provides little information, it typically reflects a position that both sides have some ground. It is likely better for the patentee than having the patent found invalid but not as good as having a patent found to be valid and infringed. Similarly, it may be better for a claimant than a patent being found valid but not infringed, but worse than the patent being found invalid and not infringed.
One option to score to partial validity or infringement (e.g. some claims valid/invalid, some claims infringed/not infringed) is to determine a score for each claim individually. For example, dependent claims may be treated using the shallowest dependency – effectively considering a new independent claim comprising the features of the independent claim and the dependents. A final score may be computed by summing the individual scores.
So this could work as a framework to score legal success based on legal outcomes. Theses legal outcomes may be parsed based on patent register data, claim data and/or court reports. There is thus scope for automation.
We still haven’t dealt with the issues of case transfers or different technical fields. One way to do this is to normalise or further weigh scores developed based on the above framework.
For technical fields, scores could be normalised based on average legal outcomes or scores for given classification groupings. There is a question of whether this data exists (I think it does for US art units, it may be buried in an EP report somewhere, I don’t think it exists for the UK). A proxy normalisation could be used where data is not available (e.g. based on internal average firm or company grant rates) or based on other public data, such as public hearing results.
Transferred cases could be taken into account by weighting by: time case held / time since case filing.
These may be measured by looking at the dates of event actions. These are often stored in patent firm record systems, or are available in patent register data.
It is worth noting that there are many factors outside the control of an individual attorney. For example, instructions may always be received near a deadline for a particular client, or a company may prefer to keep a patent pending by using all available extensions. The hope is that, as a first crude measure, these should average out over a range of applicants or cases.
For official responses, a score could be assigned based on the difference between the official due date and the date the action was completed. This could be summed over all cases and normalised. This can be calculated from at least EP patent register data (and could possibly be scraped from UKIPO website data).
For internal timeliness, benchmarks could be set, and a negative score assigned based on deviations from these. Example benchmarks could be:
Acknowledgements / initial short responses sent with 1 working day of receipt;
Office actions reported with 5 working days of receipt;
Small tasks or non-substantive work (e.g. updating a document based on comments, replying to questions etc.) performed within 5 working days of receipt / instruction; and
Substantive office-action and drafting work (e.g. reviews / draft responses) performed within 4 weeks of instruction.
This could be measured, across a set of cases, as a function of:
a number of official communications issued to correct deviations;
a number of requests to correct deficiencies (for cases where no official communication was issued); and/or
a number of newly-raised objections (e.g. following the filing of amended claims or other documents).
This information could be obtained by parsing document management system names (to determine communication type / requests), from patent record systems, online registers and/or by parsing examination communications.
One issue with cost is that it is often relative: a complex technology may take more time to analyse or a case with 50 claims will cost more to process than a case with 5. Also different companies may have different charging structures. Also costs of individual acts need to be taken in context – an patent office response may seem expensive in isolation, but if it allows grant of a broad claim, may be better than a series of responses charged at a lower amount.
One proxy for cost is time, especially in a billable hours system. An attorney that obtains the same result in a shorter time would be deemed a better attorney. They would either cost less (if charged by the hour) or be able to do more (if working on a fixed fee basis).
In my post on pricing patent work, we discussed methods for estimating the time needed to perform a task. This involved considering a function of claim number and length, as well as citation number and length. One option for evaluating cost is to calculate the ratio: actual_time_spent / predicted_time_spent and then sum this over all cases.
Another approach is to look at the average number of office actions issued in prosecution – a higher number would indicate a higher lifetime cost. This number could be normalised per classification grouping (e.g. to counter the fact that certain technologies tend to get more objections).
The time taken would need to be normalised by the legal success measures discussed above. Spending no time on any cases would typically lead to very high refusal rates, and so even though a time metric would be low, this would not be indicative of a good attorney. Similarly, doing twice the amount of work may lead to a (small?) increase in legal success but may not be practically affordable. It may be that metrics for legal success are divided by a time spent factor.
Patent billing or record systems often keep track of attorney time. This would be the first place to look for data extraction.
An interesting result of this delve into detail is we see that legal success and cost need to be evaluated together, but that these can be measured independently of timeliness and error, which in turn . may be measured independently of each other. Indeed, timeliness and error avoidance may be seen as baseline competences, where deviations are to be minimised.
It would also seem possible, in theory at least, to determine these measures of success automatically, some from public data sources and others from existing internal data. Those that can be determined from public data sources raise the tantalising (and scary for some?) possibility of comparing patent firm performance, measures may be grouped by firm or attorney. It is hard to think how a legal ranking based on actual legal performance (as opposed to an ability to wine and dine legal publishers) would be bad for those paying for legal services.
It is also worth raising the old caveat that measurements are not the underlying thing (in a Kantian mode). There are many reasonable arguments about the dangers of metrics, e.g. from the UK health, railways or school systems. These include:
the burden of measurement (e.g. added bureaucracy);
modifying behaviour to enhance the metrics (e.g. at the cost of that which is not measured or difficult to measure);
complex behaviour is difficult to measure, any measurement is a necessarily simplified snapshot of one aspect; and
misuse by those in power (e.g. to discriminate or as an excuse or to provide backing for a particular point of view).
These, and more, need to be borne in mind when designing the measures. However, I believe the value of relatively objective measurement in an industry that is far too subjective is worth the risk.