Problem-and-solution approach

The so-called problem-and-solution approach has became the standard test for inventive step. In the meantime it is also used as a tool to decide whether an invention is a technical invention for which a patent can be awarded or if the invention does not contribute any technical features besides from those already known from prior art. If the contributions to the prior art are confined to non-technical matters, e.g. rules of business, the invention is excluded from patentability according to Art. 52 (2) EPC.

In order to assess inventive step in an objective and predictable manner, the so-called "problem-and-solution approach" should be applied. Thus deviation from this approach should be exceptional.

In the problem-and-solution approach, there are three main stages:

1. determining the "closest prior art"
2. establishing the "objective technical problem" to be solved, and
3. considering whether or not the claimed invention, starting from the closest prior art and the objective technical problem, would have been obvious to the skilled person.

Source http://www.epo.org/law-practice/legal-texts/html/guidelines/e/g_vii_5.htm as retrieved on 27.06.2012

For the purpose of the problem-and-solution approach, the problem must be a technical problem, it must actually be solved by the solution claimed, all the features in the clai should contribute to the solutionm and the problem must be one that the skilled person in the particular technical field might be asked to solve at hte priority date. In this context "problem" is used merely to indicate that the skilled person is to be considered as faced with some task (German "Aufgabe"), not that its solution need necessarily involve any great difficulty (T 641/00).

Defining a problem should be the starting point where a person skilled in the art is getting involved. This may be the point of time when a product manager asks the R&D department to think about what it would cost to implement a feature for which clients are permanently asking. One can imagine that in some cases formulating a challenging technical problem could be the most important part of a technical solution and therefore in itself involves already an inventive step. In those cases the solution to the challenging problem might be a straightforward application of the inventors technical skills. In such cases a patent would be rejected if the standards for the problem are set to high in the beginning. Therefore "only" an "objective" technical problem is required, irrespective of the ambitious problem the inventor might have had in mind.   

In the following cases are considered where no technical problem can be identified or where the technical features disclosed in an application do not solve the objective technical problem.

Examples for non-technical problems/solutions

• Comparing prices of components and identifying relatively expensive components for which suppliers should be requested to provide bids in the hope that the price can be reduced by bidding and those relatively cheap priced components which should be simply ordered when they are required does not solve the technical problem of reducing the amount of data processing a computer needs to perform for those goods which are ordered immediately as if there is a reduction in processing due to requesting fewer bits there is on the other hand also an increase due to the calculation of sorting order data into two sets.
  
  Further the effect of reducing processing is not tied to technical implementations of the method as the reduction would be also achieved [to the same extend] if the bids were requested by telephone, by e-mail, or in face to face conversations.
  (T 0711/08)


• Introducing a new [buisness] rule for a reverse auction (so-called Dutch auction) that changes the known rule so that delays in data transmission become irrelevant avoids solving the technical problem. Therfore the new business rule does not contribute any technical means to the technical subject matter [computer system with client-server architecture] of the claimed invention.
  (T 258/03)

Examples for technical problems/solutions

• Using digital security attributes to improve the security of a virtual payment system.
  (T 0823/08)


• Compensating delays in data transmissions from various client computer to a server computer causing the problem to decide which client computer sent a bid prior to the bids of the other client computers (in the specific case a technical problem was acknowledged but the features to solve the technical problem were rejected as not providing a technical contribution).
  (T 258/03)