Case Law Review – T 2296/10

Case:

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, notwithstanding 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.

Amateur Hour: A Patent Workflow Web App

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: 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?

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

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

Patents: Another Language?

I have been playing with natural language processing.

Now I have a body of patent data (see here), I can do some interesting things. For example, most people would say that patents have a pretty specific terminology. I say: show me the data.

Taking all patent publications in 2001 as an example, I programmed a little routine that:

Extracted the text data of each patent publication;
Split the text data into words;
Filtered the words for non-words (e.g. punctuation etc.);
Applied a stemming algorithm (from 1979!); and
Recorded the frequency distribution of the results.

In total I counted 277493492 occurrences of 287455 unique word stems.

In common with most written material, 100 words accounted for 50% of the published material. Amazing when you think about it.

(Next time you get a drafting bill from a patent attorney, complain that half their work is shuffling 100 words around :)).

Here is the graph (click to zoom for full glory).

Cumulative Percentage of Top100 Words — Cumulative Percentage of Top 100 Words (click for full-size)

Patent Stopwords

There is more.

“Stopwords” are common words that are often filtered out when analysing documents. The Natural Language Tool Kit provides a set based on a general analysis of written English. These include words such as:

…’did’, ‘doing’, ‘a’, ‘an’, ‘the’, ‘and’, ‘but’, ‘if’, ‘or’, ‘because’, ‘as’, ‘until’, ‘while’, ‘of’, ‘at’, ‘by’, ‘for’…

In total there are 127 stopwords in this collection representing high-frequency content that has little lexical use.

I thought it would be interesting to compare these stopwords with the 127 most frequent in our frequency count.

Words that occurred frequently in (US) patent publications that do not comprise regular stopwords include:

said use first one form invent thi may second data claim wherein accord control signal present devic provid portion includ embodi compris method layer surfac system process exampl step ha shown connect posit prefer oper gener mean inform circuit imag unit time materi also end wa member line film side least select apparatu output element refer receiv describ direct base light section set show substrat contain display view valu part cell two plural group structur number optic electrod input result abov respect region memori plate case differ user

These words will be familiar to most patent professionals. The result of the stemming operation can be seen in certain words, e.g. “oper” – these should be treated as “oper*” – “operates”, “operating”, “operate” etc.. You can see that stemming is not perfect (“thi” may relate to “this”, which has been taken to be a plural form) but it is generally good enough. Without the stemming there would be many different variations of the same word in our counts.

Now this list of “patent stopwords” is useful. Firstly, these words are probably not useful for searching in isolation (we may move onto n-grams later). Secondly, they can be used as a dictionary of sorts for claim drafting. Thirdly, they could be used to distinguish patent text from non-patent text (e.g. as the basis for a feature vector for this classification).

The words that occur in patent specifications but also occur in “the real world” are also interesting:

the of a to and in is for be an as by with or are that from which at on can it have such each not when between other into through further more about than will so if then

These can be used as universal stopwords.

Further Fun

There are a number of paths for further analysis:

Extend across the whole US patent publication corpus from 2001 to 2014. I may need to optimise my code to do this!
Perform a similar analysis for different classification levels – e.g. do patents classified as G have a different vocabulary from those classified as H?
Look at infrequent or unique words – How many are there? Are they useful for searching clusters?