Archive for February, 2014

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

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

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

As you may remember, a while back I posted some ideas for a patent workflow tool. It is taking a while, what with actual work and family commitments. However, I finally have a rough-and-ready prototype covering at least the initial review stage.

The application* is built in Flask. It generates an XML document containing the entered data. Fields are rendered based on the XML document (making use of XSLT). To avoid file system headaches, XML data is stored as string data in an SQLite3 database. The data is indexed using a hash masquerading as a key identifier. The key identifier can then be passed as a URL parameter to retrieve a particular XML document. Although nowhere near a fully working “thing”, the code is here if you want a look: .

Initial Review: Process Overview in Pictures

First we enter our case reference:

Enter Case Reference

Enter Case Reference

Then we enter the communication details and the objections raised:

Communication Overview

Communication Overview

Then we briefly enter salient details of each objection raised in the communication. This can be used for reporting and as a reference for a later, more detailed review:

Enter First Objection

Enter First Objection

There is an option to enter further objections under the same category (see the lower checkbox). This adds an additional XML element and populates it with data from a template. Once submit is pressed, fields for a next objection will load:

Enter Second Objection

Enter Second Objection

The result is then a populated XML document that forms the starting point for a response:

XML Document

XML Document

Where from here?

I have similar review workflows in progress for novelty and inventive step. They follow a similar pattern: an XML template defines data entry and works the user through a number of review steps. I have JavaScript functions that breaks down a claim into features – I can use this as a front-end for my novelty review. Inventive step has a different process for each of the UK, Europe and US, wherein the process incorporates the current practice from case law.

The aim is that objections entered in the initial review will be addressed through a detailed review and/or instructions. As we initially enter the objections, we do not have to worry about missing objections or approaching things in a less efficient order. The workflow also allows a response to be split into a number of modular processes. These are then ripe for outsourcing, e.g. to paralegal staff or trainees, allowing an attorney to concentrate their time on the “meat” of the objections and thus saving money for clients. The workflow also provides mental scaffolding that is perfect for trainees and/or sleep-deprived attorneys with young children/dogs.

I use a combination of Evernote, Remember the Milk and Trello to jot down ideas, plan and set out to-do lists. Currently pending are:

  • Map XML to more user-friendly form fields;
  • Sort the loading of existing data;
  • Sort the CSS for that tiny textarea;
  • Add some JavaScript time-savers to the front-end (e.g. that allow a user to click “same communication” for multiple objections);
  • Build an XSL file that transforms the result of the initial review to text for storage or reporting;
  • Work out how to use cloud storage APIs to automatically save a copy of the above to a document management system;
  • Add detailed review workflow, including bespoke processes for novelty, inventive step and patentability/excluded subject matter;
  • Add easy “report bug/suggest feature” reporting for iterative updates; and
  • Host on a £30 Raspberry Pi in the office.

* Aside: ‘web-site’/’web-app’/’app’/’application’ are all kind of the same thing. “Web-site” was a traditionally static site that hosted HTML documents. No-one really does that any more though; nearly all sites are built dynamically, making them more like a traditionally client-server application (especially with JavaScript on the front end and Python or similar on the back-end).


T 0218/11

Claimed Subject Matter:

A self-service checkout which solved the problem of the self-service checkout being overly sensitive (or conversely not sensitive enough) to people making mistakes (or conversely, trying to “cheat” the checkout).


The Appellant argued that keeping track of customers and tolerating different numbers of errors when using the checkout was itself technical, and that this would form part of the problem for the technically skilled person to solve.

However, the Board concluded that judging whether a customer is trust-worthy and treating them according to that judgement was a non-technical matter. Hence, an underlying idea of recording a level of trust forms part of a requirements specification that is given to the skilled person; the technically skilled person is faced with the task of modifying the self-service checkout terminals so as to keep track of how trusted different customers are, and so as to interrupt transactions earlier for those customers who are less trusted, and later for those that are more trusted.

The features of the claimed solution was thus deemed to either be found in the prior art, be non-technical and thus not contribute to an inventive step, or be technically obvious given the defined technical problem.

[With thanks to Jake Loftus for help finding and reviewing these cases.]