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

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

Skilled Person

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

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

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

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

Applications of Algorithms

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

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

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

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

Warning on Generalisation

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

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

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

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

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

Added Subject Matter and Features without Technical Contribution

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

Case Law Review – T 2296/10

Case:

T 2296/10

Claimed Subject Matter:

OFDM-transmitting apparatus and method, and OFDM-receiving apparatus and method.

Comments:

This case provides an interesting consideration of technical prejudices.

The Appellant attempted to argue that technical prejudices of the company behind the closest prior art document (the BBC) meant that the claimed solution was not obvious.

The Board disagreed with the Appellant’s arguments stating (see 2.1.10):

In this regard, the board notes that, in general, cost considerations and technological preferences of a particular company (like the BBC in this case) cannot impose technical prejudices or uncertainties upon a technically skilled person such that he would be deterred from envisaging a technically sound and feasible solution for that reason alone. Otherwise, when analysing and interpreting the actual teaching of the closest prior art determined for the purpose of assessing inventive step according to the well-established “problem-solution approach”, internal experiences, beliefs, and preferences concerning technologies to be applied by the company from which that closest prior art originates would generally have to be taken into account. This would in turn mean that – to answer the question whether the skilled person starting out from the closest prior art would in fact arrive at the claimed solution – additional internal background information on the respective closest prior art (e.g. derived from witness statements from some employees as provided by the present appellant) would be necessary. In other words, the extent to which the notional skilled person in fact applies his skills in providing a solution to an objective technical problem would be unduly bound by such internal information (e.g. the expected infrastructure costs incurred by the BBC when proposing a change in its applied technology) at the filing date of an application instead of finding an appropriate solution to the objective problem posed. That would, however, definitely be incompatible with the problem-solution approach as generally applied.

Rather, the person skilled in a technical field (i.e. mobile communication networks in the present case) would try to seek a technical solution to an objective technical problem (i.e. choosing a certain pilot symbol pattern) under certain constraints (i.e. digital video distribution), starting with the closest prior art (i.e. document D1). However, based on the reasoning set out in points 2.1.12.1.1 to 2.1.92.1.9 , the board considers that said skilled person would arrive at the solution (i.e. using a DVB-T-based pilot symbol pattern) according to feature A) of claim 1 without exercising inventive skills.

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

Case Law Review – T 1602/09

Case:

T 1602/09

Claimed Subject Matter:

A  computer system for managing relationships between brokers and traders in a trading network.

Comments:

The Appellant claimed that the invention solved a technical problem which arose in such systems, namely that a trader could not simply and easily control, i.e. prevent or permit, a computer terminal operated by a broker to send trading commands on behalf of the trader from the computer terminal via the network to the trading system.

The Appeal was dismissed by the Board.

The Board found that the problem formulation only made sense in the context of operations by a (non-technical) “active trader”, these being traders who wish to be able to supervise trade orders given to brokers. It was found that since the trading was computer-based the active trader would need to have access to the broker’s trading system. The skilled person was certainly aware that this made a log-on necessary. Equivalently, if the active trader for some reason was not logged on, the broker should not be allowed to trade. Ideally, the check should be automatic. These straight-forward considerations were deemed to lead directly to the subject-matter of claim 1.

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

Case Law Review – T 1192/10

Case:

T 1192/10

Claimed Subject Matter:

User interface with gesture recognition.

The subject-matter of claim 1 differed from the disclosure in the closest prior art document in that according to claim 1:

a) warning messages are output to the user instead of having only internal messages between different components,

b) a range of sampling periods, i.e. a period when the button is activated, is supervised,

c) a range of poses indicating ranges of pitch and roll angles of the input device with respect to the bottom plane on which the input device is positioned is supervised and

d) temporary button release when the button is deactivated and re-activated within a predetermined time causes another warning to the user.

Comments:

Feature (a) of outputting warning messages to a user instead of internal messages between different components was deemed to be technical, solving the technical problem of how to provide feedback to the user about internal states or identified conditions of the device, but notoriously known.

However, features (b) of supervising a range of sampling periods and (d) providing temporary de-activation of a button were deemed to be technical features that provided an inventive step over the cited art. This set aside an earlier decision of the examining division.

The examining division had argued that although the actual implementation of the specific validation criteria involved a technically skilled person, the definition of the expected operation (e.g. what motions and durations of the input are expected) was rather business-based, according to the intended purpose of the device and to design choices. This argument was not accepted by the Board who concluded that, whatever the reason for the definition of a gesture might be, the underlying ranges, rolls and angles are of a technical nature.

Case Law Review – T 0913/10

Case:

T 0913/10

Claimed Subject Matter:

Encrypting data within a database system based on a defined system role (security administrator, database administrator, and user administrator).

Comments:

The case provides an interesting discussion about the term “role”, e.g. as used in a computing sense e.g sysadmin, user, database admin.

The Board concluded that “that nothing in the claims or in the description can dispel the reasonable possibility that the definition of tasks to be distributed over three administrators is merely an organisational and hence non-technical issue, not­withstanding that it relates to a technical entity such as a database system”. The claims were then found to lack an inventive step based on this assumption.

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

Case Law Review – T 1929/09

Case:

T 1929/09

Claimed Subject Matter:

Server-side web summary generation and presentation.

Claim 1 specified: an Internet Portal, comprising an Internet-connected server and a portal software executing on the server, including a summary software agent, wherein the Portal maintains a list of Internet destinations specific for a subscriber, and the summary software agent accesses the Internet destinations, retrieves information according to pre-programmed criteria, and summarizes the retrieved information for delivery to the subscriber.

Comments:

The underlying idea was to facilitate the life of a user who normally had to provide some personal information for accessing certain web pages. This was deemed at first instance to be a non-technical problem.

The Board agreed with the Appellant that improving the allocation of resources on the Internet and reducing connection time between servers or between a server and a workstation are, in principle, technical problems. However, the Board held that an information service tailored to the needs of a particular user and limited to user-defined Internet destinations is essentially a business scheme. Thus, the mere idea of providing such a service cannot be regarded as a contribution to the solution of a technical problem.

Claim 1 was broad and lacked technical detail on a specific implementation; as such any technical features therein were deemed to be obviously required. The background of the invention was cited to support this point.

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

Software & Patenting: IP Outside Your Comfort Zone

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

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

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

Case Law Review – T 0218/11

Case:

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

Comments:

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

Case Law Review – T 2216/09

Case:

T 2216/09

Claimed Subject Matter:

A a system that enabled subscribers of a wireless telecom operator to execute financial transactions with a mobile phone.

Comments:

The system was deemed to mainly relate to an excluded business scheme.

All steps of the underlying business scheme were deemed part of the information provided to the technician in charge of the technical implementation and did not as such contribute to inventive step.

The Appellant argued that the specific transaction platform and client software did not exist in a conventional wireless phone system, and so were out of reach of the normal activity of the person skilled in the art of telephone networks. However, the Board concluded that the person skilled in the art would be able to implement the new system, given the specifications of the underlying business scheme. For example, any extension of the type of financial transactions which can be performed with the account (receive monetary deposits, debit and credit operations) was deemed to be dictated by the underlying business scheme.

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

A Dip in the Patent Information Seas (An EPO Online Patent Services Tutorial)

Over Christmas I had a chance to experiment with the European Patent Office’s Online Patent Services. This is a web service / application programming interface (API) for accessing the large patent databases administered by the European Patent Office. It has enormous potential.

To get to grips with the system I set myself a simple task: taking a text file of patent publication numbers (my cases), generate a pie chart of the resulting classifications. In true Blue Peter-style, here is one I made earlier (it’s actually better in full SVG glory, but WordPress.com do not support the format):

Classifications for Cases (in %)
Classifications for Cases (in %)

Here is how to do it: –

Step 1 – Get Input

Obtain a text file of publication numbers. Most patent management systems (e.g. Inprotech) will allow you to export to Excel. I copied and pasted from an Excel column into a text file, which resulted in a list of publication numbers separated by new line (“\n”) elements.

Step 2 – Register

Register for a free EPO OPS account here: http://www.epo.org/searching/free/ops.html . About a day later the account was approved.

Step 3 – Add an App

Setup an “app” at the EPO Developer Portal. After registering you will receive an email with a link to do this. Generally the link is something like: https://developers.epo.org/user/[your no.]/apps. You will be asked to login.

Setup the “app” as something like “myapp” or “testing” etc.. You will then have access to a key and a secret for this “app”. Make a note of these. I copied and pasted them into an “config.ini” file of the form:

[Login Parameters]
C_KEY="[Copied key value]"
C_SECRET="[Copied secret value]"

Step 4 – Read the Docs

Read the documentation. Especially ‘OPS version 3.1 documentation – version 1.2.10 ‘. Also see this document for a description of the XML Schema (it may be easier than looking at the schema itself).

Step 5 – Authenticate

Now onto some code. First we need to use that key and secret to authenticate ourselves using OAuth.

I first of all tried urllib2 in Python but this was not rendering the POST payload correctly so I reverted back to urllib, which worked. When using urllib I found it easier to store the host and authentication URL as variables in my “config.ini” file. Hence, this file now looked like:

[Login Parameters]
C_KEY="[Copied key value]"
C_SECRET="[Copied secret value]"

[URLs]
HOST=ops.epo.org
AUTH_URL=/3.1/auth/accesstoken

Although object-oriented-purists will burn me at the stake, I created a little class wrapper to store the various parameters. This was initialised with the following code:

import ConfigParser
import urllib, urllib2
import httplib
import json
import base64
from xml.dom.minidom import Document, parseString
import logging
import time

class EPOops():

	def __init__(self, filename):
		#filename is the filename of the list of publication numbers

		#Load Settings
		parser = ConfigParser.SafeConfigParser()
		parser.read('config.ini')
		self.consumer_key = parser.get('Login Parameters', 'C_KEY')
		self.consumer_secret = parser.get('Login Parameters', 'C_SECRET')
		self.host = parser.get('URLs', 'HOST')
		self.auth_url = parser.get('URLs', 'AUTH_URL')

		#Set filename
		self.filename = filename

		#Initialise list for classification strings
		self.c_list = []

		#Initialise new dom document for classification XML
		self.save_doc = Document()

		root = self.save_doc.createElement('classifications')
		self.save_doc.appendChild(root)

The authentication method was then as follows:

def authorise(self):
		b64string = base64.b64encode(":".join([self.consumer_key, self.consumer_secret]))
		logging.error(self.consumer_key + self.consumer_secret + "\n" + b64string)
		#urllib2 method was not working - returning an error that grant_type was missing
		#request = urllib2.Request(AUTH_URL)
		#request.add_header("Authorization", "Basic %s" % b64string)
		#request.add_header("Content-Type", "application/x-www-form-urlencoded")
		#result = urllib2.urlopen(request, data="grant_type=client_credentials")
		logging.error(self.host + ":" + self.auth_url)

		#Use urllib method instead - this works
		params = urllib.urlencode({'grant_type' : 'client_credentials'})
		req = httplib.HTTPSConnection(self.host)
		req.putrequest("POST", self.auth_url)
		req.putheader("Host", self.host)
		req.putheader("User-Agent", "Python urllib")
		req.putheader("Authorization", "Basic %s" % b64string)
		req.putheader("Content-Type" ,"application/x-www-form-urlencoded;charset=UTF-8")
		req.putheader("Content-Length", "29")
		req.putheader("Accept-Encoding", "utf-8")

		req.endheaders()
		req.send(params)

		resp = req.getresponse()
		params = resp.read()
		logging.error(params)
		params_dict = json.loads(params)
		self.access_token = params_dict['access_token']

This results in an access token you can use to access the API for 20 minutes.

Step 6 – Get the Data

Once authentication is sorted, getting the data is pretty easy.

This time I used the later urllib2 library. The URL was built as a concatenation of a static look-up string and the publication number as a variable.

The request uses an “Authentication” header with a “Bearer” variable containing the access token. You also need to add some error handling for when your allotted 20 minutes runs out – I looked for an error message mentioning an invalid access token and then re-performed the authentication if this was detected.

I was looking at “Biblio” data. This returned the classifications without the added overhead of the full-text and claims. The response is XML constructed according to the schema described in the Docs above.

The code for this is as follows:

def get_data(self, number):
		data_url = "/3.1/rest-services/published-data/publication/epodoc/"
		request_type = "/biblio"
		request = urllib2.Request("https://ops.epo.org" + data_url + number + request_type)
		request.add_header("Authorization", "Bearer %s" % self.access_token)
		try:
			resp = urllib2.urlopen(request)
		except urllib2.HTTPError, error:
			error_msg = error.read()
			if "invalid_access_token" in error_msg:
				self.authorise()
				resp = urllib2.urlopen(request)

		#parse returned XML in resp
		XML_data = resp.read()
		return XML_data

Step 7 – Parse the XML

We now need to play around with the returned XML. Python offers a couple of libraries to do this, including Minidom and ElementTree. ElementTree is preferred for memory-management reasons but I found that the iter() / getiterator() methods to be a bit dodgy in the version I was using, so I fell back on using Minidom.

As the “Biblio” data includes all publications (e.g. A1, A2, A3, B1 etc), I selected the first publication in the data for my purposes (otherwise there would be a duplication of classifications). To do this I selected the first “<exchange-document>” tag and its child tags.

As I was experimenting, I actually extracted the classification data as two separate types: text and XML. Text data for each classification, simply a string such as “G11B  27/    00            A I”, can be found in the  “<classification-ipcr>” tag. However, when looking at different levels of classification this single string was a bit cumbersome. I thus also dumped an XML tag – “<patent-classification>” – containing a structured form of the classification, with child tags for “<section>”, “<class>”, “<subclass>”, “<main-group>” and “<subgroup>”.

My function saved the text data in a list and the extracted XML in a new XML string. This allowed me to save these structures to disk, more so I could pick up at a later date without continually hitting the EPO data servers.

The code is here:

def extract_classification(self, xml_str):
		#extract the  elements
		dom = parseString(xml_str)
		#Select first publication for classification extraction
		first_pub = dom.getElementsByTagName('exchange-document')[0]
		self.c_list = self.c_list + [node.childNodes[1].childNodes[0].nodeValue for node in first_pub.getElementsByTagName('classification-ipcr')]

		for node in first_pub.getElementsByTagName('patent-classification'):
			self.save_doc.firstChild.appendChild(node)

Step 8 – Wrap It All Up

The above code needed a bit of wrapping to load the publication numbers from the text file and to save the text list and XML containing the classifications. This is straightforward and shown below:

def total_classifications(self):
		number_list = []

		#Get list of publication numbers
		with open("cases.txt", "r") as f:
			for line in f:
				number_list.append(line.replace("/","")) #This gets rid of the slash in PCT publication numbers

		for number in number_list:
			XML_data = self.get_data(number.strip())
			#time.sleep(1) - might want this to be nice to EPO 🙂
			self.extract_classification(XML_data)

		#Save list to file
		with open("classification_list.txt", "wb") as f:
			f.write("\n".join(str(x) for x in self.c_list))

		#Save xmldoc to file
		with open("save_doc.xml", "wb") as f:
			self.save_doc.writexml(f)

Step 9 – Counting

Once I have the XML data containing the classifications I wrote a little script to count the various classifications at each level for charting. This involved parsing the XML and counting unique occurrences of strings representing different levels of classification. For example, level “section” has values such as “G”, “H”. The next level, “class”, was counted by looking at a string made up of “section” + “class”, e.g. “G11B”. The code is here:

from xml.dom.minidom import parse
import logging, pickle, pygal
from pygal.style import CleanStyle

#create list of acceptable tags - tag_group - then do if child.tagName in tag_group

#initialise upper counting dict
upper_dict = {}

#initialise list of tags we are interested in
tags = ['section', 'class', 'subclass', 'main-group', 'subgroup']

with open("save_doc.xml", "r") as f:
	dom = parse(f)

#Get each patent-classification element
for node in dom.getElementsByTagName('patent-classification'):
	#Initialise classification string to nothing
	class_level_val = ""
	logging.error(node)
	#for each component of the classification
	for child in node.childNodes:
		logging.error(child)
		#Filter out "text nodes" with newlines
		if child.nodeType is not 3 and len(child.childNodes) > 0:

			#Check for required tagNames - only works if element has a tagName
			if child.tagName in tags:

				#if no dict for selected component
				if child.tagName not in upper_dict:
					#make one
					upper_dict[child.tagName] = {}
				logging.error(child.childNodes)

				#Get current component value as catenation of previous values
				class_level_val = class_level_val + child.childNodes[0].nodeValue

				#If value is in cuurent component dict
				if class_level_val in upper_dict[child.tagName]:
					#Increment
					upper_dict[child.tagName][class_level_val] += 1
				else:
					#Create a new entry
					upper_dict[child.tagName][class_level_val] = 1

print upper_dict
#Need to save results
with open("results.pkl", "wb") as f:
	pickle.dump(upper_dict, f)

The last lines print the resulting dictionary and then save it in a file for later use. After looking at the results it was clear that past the “class” level the data was not that useful for a high-level pie-chart, there were many counts of ‘1’ and a few larger clusters.

Step 10 – Charting

I stumbled across Pygal a while ago. It is a simple little charting library that produces some nice-looking SVG charts. Another alternative is ‘matlibplot‘.

The methods are straightforward. The code below puts a rim on the pie-chart with a breakdown of the class data.

#Draw pie chart
pie_chart = pygal.Pie(style=CleanStyle)
pie_chart.title = 'Classifications for Cases (in %)'

#Get names of different sections for pie-chart labels
sections = upper_dict['section']

#Get values from second level - class
classes = upper_dict['class']
class_values = classes.keys() #list of different class values

#Iterate over keys in our section results dictionary
for k in sections.keys():
 #check if key is in class key, if so add value to set for section

 #Initialise list to store values for each section
 count_values = []
 for class_value in class_values:
 if k in class_value: #class key - need to iterate from class keys
 #Add to list for k
 #append_tuple = (class_value, classes[class_value]) - doesn't work
 count_values.append(classes[class_value])
 #count_values.append(append_tuple)
 pie_chart.add(k, count_values)

pie_chart.render_to_file('class_graph.svg')

That’s it. We now have a file called “class_graph” that we can open in our browser. The result is shown in the pie-chart above, which shows the subject-areas where I work. Mainly split between G and H. The complete code can be found on GitHub: https://github.com/benhoyle/EPOops.

Going Forward

The code is a bit hacky, but it is fairly easy to refine into a production-ready method. Options and possibilities are:

  • Getting the data from a patent management system directly (e.g. via an SQL connection in Python).
  • Adding the routine as a dynamic look-up on a patent attorney website – e.g. on a Django or Flask-based site.
  • Look up classification names using the classification API.
  • The make-up of a representative’s cases would change fairly slowly (e.g. once a week for an update). Hence, you could easily cache most of the data, requiring few look-ups of EPO data (the limit is 2.5GB/week for a free account).
  • Doing other charting – for example you could plot countries on Pygal’s world map.
  • Adapt for applicants / representatives using EPO OPS queries to retrieve the publication numbers or XML to process.
  • Looking at more complex requests, full-text data could be retrieved and imported into natural language processing libraries.