A presentation given as a CIPA Webinar on 25 February 2014.
Provides an introduction to software as it relates to patenting and an overview of current practice in UK and Europe. Details of relevant legislation and case law are provided, together with some tips for drafting.
Provided according to the terms set out here: http://www.eip.com/legal.php – i.e. does not constitute legal advice and should be taken as guidance.
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: https://github.com/benhoyle/attass .
Initial Review: Process Overview in Pictures
First we enter our case reference:
Then we enter the communication details and the objections raised:
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:
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:
The result is then a populated XML document that forms the starting point for a response:
Where from here?
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.
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.
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.]