T 0843/09 11-10-2012

Reasons for the Decision

1. The appeal is admissible.

2. Main request

2.1 Inventive step

2.1.1 Background of the invention is the handling of transactions in the insurance business. According to the application, "Typically, computer-based systems for transactions processing that are configured to automatically invoice the premiums cause a lot of data transactions between the system and the customers. Furthermore, a corresponding number of financial transactions between customers and financial institutions and between financial institutions and the system are required for paying the invoiced premiums. Similarly, the payment of claims relies on numerous financial transactions between system and financial institutions. Carrying out the data and financial transactions in electronic fashion via a telecommunication network requires a considerable amount of bandwidth of the telecommunication network as well as processor and memory resources for executing and logging the financial transactions. Typically, invoicing the premiums also requires the system to generate a great volume of paper mail that must be delivered physically to the customers" (page 3, lines 10 to 22).

According to the application, "On one hand, the efficiencies and flexibilities within the system's handling of transactions with customers are improved in that it is made possible for customers to access remotely their accounts and to select open items from the list of account bookings, i.e. to selectively group their account bookings, and to select a function to be processed automatically by the system, i.e. to select financial operations to be applied to the specified group of account bookings. Organisation of their accounts and allocation of their account bookings are at the control of the customers. The customers have full transparency of postings and are enabled to reconcile their accounts without involving personnel from the business organisation. On the other hand, the requirements on the technical infrastructure for executing data and financial transactions and for invoicing are reduced in that the customers have the ability to interact and trigger financial transactions, depending on the credit/debit balance positions. For example, payment transactions can be avoided when selected payment advice functions or payment request functions involve small amounts. Particularly, a payment to a customer and all the data communication associated with the payment do not have to be executed when credits and debits related to a payment request are selected to result in a small balance. Likewise, a payment order from a customer and all the data communication associated with the payment order do not have to be executed when credits and debits related with a payment advice are selected to result in a small balance" (cf page 4, line 26 to page 5, line 19).

The customer may select different functions to be performed by the system, including an "advise payment", a "request payment" and a "pairing advice" function. In the "advise payment" function the customer advises the business organisation of an upcoming payment which can be paired with one or more previous events. The system presents a list of open items, credits and debits, from which the customer can select open items it wishes to settle. The system calculates the balance, and if the balance is in favour of the business organisation, proceeds to payment (cf page 18, line 24 to page 21, line 8). In the "request payment" function, again the system presents a list of open items, credits and debits, from which the customer can select open items it wishes to settle. The system calculates the balance, and this time if the balance is in favour of the customer, proceeds to requesting payment (cf page 21, line 9 to page 23, line 7). Finally, in the "pairing advice" function, the system presents one or more lists of items, credits and debits, from which the customer can select items it wishes to pair so that they set off against each other. After verifying that the balance amount is zero or so small that the beneficiary is willing to waive payment, the system proceeds to set off the selected items (cf page 23, line 8 to page 25, line 9).

2.1.2 The application, thus, provides a computer based automated system for carrying out an accounting procedure for transacting business between an insurer (customer) and a reinsurer (business organisation). The underlying accounting procedure involves setting off unsettled payments in favour of the reinsurer (credits) and unsettled payments in favour of the insurer (debits) associated with insurance policies between the insurer and the reinsurer. Credits and debits to be settled are selected by the insurer, and depending on the resulting balance a payment is made by the insurer in favour of the reinsurer, a payment is requested by the insurer in his favour or, in case the balance is zero or small and can be waived, the credits and debits are set off against each other.

The above underlying accounting procedure, however, lies in the field of schemes, rules and methods for doing business, which shall not be regarded as inventions pursuant to Article 52(2)(c) EPC, and is therefore deemed to be non-technical.

As claim 1 does not solely contain non-technical features pertaining to the accounting procedure but also technical features relating to technical means as part of the system, such as a server, a communication network etc., the patentability of its subject-matter is not considered to be excluded under Article 52(2) and (3) EPC.

However, according to established jurisprudence, an invention consisting of a mixture of technical and non-technical features and having technical character as a whole is to be assessed with respect to the requirement of inventive step by taking account of all those features, which contribute to said technical character whereas features making no such contribution cannot support the presence of inventive step. Where the claim refers to an aim to be achieved in a non-technical field, eg in the field of schemes, rules and methods for doing business as in the present case, this aim may legitimately appear in the formulation of the problem as part of the framework of the technical problem that is to be solved, in particular as a constraint that has to be met (cf T 641/00 (OJ 2003, 352)).

Thus, in the present case all steps of the underlying accounting procedure are part of the information provided to the technician in charge of the technical implementation and do as such not contribute to inventive step. The technical problem to be solved, thus, is to implement technically the underlying accounting procedure.

2.1.3 The technical implementation as defined in claim 1 of the underlying accounting procedure consists in providing a system comprising a server used by the reinsurer and being accessible by the insurer via a telecommunication network and a customer account housed on the server, the customer account containing account bookings associated with the insurer.

It would readily occur to a person skilled in the art, a computer systems engineer, to provide the above setup as this type of arrangement is widely used for managing accounts in electronic financial transaction systems.

The system moreover includes, as specified in claim 1, automated instructions that, when executed by the server, allow the customer to use a computer graphical user interface to offset a payment due to the reinsurer from the insurer with one or more payments due from the reinsurer to the insurer, wherein the automated instructions are adapted to present, on the computer graphical user interface for view and use by the customer, a list of debits indicating payments from the reinsurer to the insurer and credits indicating payments from the insurer to the reinsurer.

The underlying accounting procedure requires that credits and debits to be set off are selected by the insurer. The provision, as part of the technical implementation of this procedure, of automated instructions executed by the server adapted to present, on a computer graphical user interface for view and use by the customer, a list of the credits and debits and to allow the insurer to offset them, is obvious to the skilled person. In particular, the use of a computer graphical user interface for viewing and selecting items is widely used and clearly suitable for this type of task, so that it would readily occur to the skilled person to adopt this solution.

Claim 1 further specifies that the customer account is parallelly linked to an advise payment function, a request payment function and a pairing advice function, each being constituted by a data entry portion and a submission screen portion accessible to the customer by means of the graphical user interface, and the advice and request functions having a confirmation portion accessible to the customer by means of the graphical user interface.

It remains unclear from the claim what exactly the "advise payment function", the "request payment function" and the "pairing advice function" are, so that the claim would appear to lack clarity, contrary to Article 84 EPC 1973. Moreover, doubts exist whether the claimed feature that the customer account is parallelly linked to these functions has been disclosed in the application as originally filed in conformity with the requirement of Article 123(2) EPC. These issues, however, may be left open here, as they have no bearing on the assessment of inventive step in the present case. For the purposes of this decision the claimed functions are understood to be as summarised above (see point 2.2.1) based on the information provided in the description.

The underlying accounting procedure requires that credits and debits selected by the insurer be set off against each other. Clearly, depending on the credit and debit items selected, this results in either a balance in favour of the reinsurer, with consequently a payment from the insurer in favour of the reinsurer, a balance in favour of the insurer, with consequently a request for payment from the reinsurer in favour of the insurer, or in case of a zero balance or small balance which can be waived, a set off without any payment. This corresponds to the "advise payment function", the "request payment function" and the "pairing advice function", respectively, referred to in the claim.

These three ways of setting off credits and debits are part of the underlying accounting procedure.

The technical implementation hereof as claimed consists in these three functions being constituted by a data entry portion and submission screen portion, the first two functions also having a confirmation portion, all accessible to the customer by means of the graphical user interface.

However, implementing a computer functionality by means of a graphical user interface providing a data entry screen for entering data required for performing the function, followed by a submission screen and a subsequent confirmation screen where required, is entirely common in computer systems and, thus, an obvious solution for a person skilled in the art.

Finally, as specified in claim 1, a processor at the server uses the list of the debits and credits to offset the payment due from the insurer to the reinsurer with the payment due from the reinsurer to the insurer.

The underlying accounting procedure prescribes that the list of the debits and the credits is used to offset the payment due from the insurer to the reinsurer with the payment due from the reinsurer to the insurer. The provision of a processor at the server to this end is an obvious choice for the skilled person entrusted with the technical implementation.

It is noted for the sake of completeness, regarding the claimed features that the business organization is a reinsurer and the customer is an insurer and that the debits and the credits are associated with more than one insurance policy between the insurer and the reinsurer, that these feature are part of the underlying accounting procedure and have no bearing on its technical implementation, so that they cannot support the presence of an inventive step.

2.1.4 The appellant argued that the claimed system was not obvious as it differed from the conventional accounting procedure used by reinsurers. As indicated in the description, the conventional accounting procedure involved payments between the insurer and the reinsurer for each and every unsettled item (description page 1, line 13 to page 3, line 22). The claimed system reduced the number of these payments, with a consequential reduction in the transaction load, paper mail and costs, by setting off unsettled payments in favour of the reinsurer and the insurer.

It is, however, noted that the above difference resides in the underlying accounting procedure, which, as argued above, cannot support the presence of an inventive step.

In fact, the merits of the underlying accounting procedure are irrelevant to the issue of inventive step. Notwithstanding this, it is noted that balancing debits with credits and only paying the balance, as well as waiving small amounts, in fact is so common in daily life that an accounting procedure based on these principles would be obvious to the person skilled in the art.

The appellant, furthermore, argued that the technical implementation of the accounting procedure as claimed and shown in figure 4 of the application involved a number of specific choices as to the technical solutions adopted which were not obvious as numerous alternatives were available.

However, as discussed above the solutions would all readily occur to the person skilled in the art, so that no inventive selection is considered to be involved.

2.1.5 Accordingly, the subject-matter of claim 1 is obvious to a person skilled in the art and, therefore, lacks an inventive step in the sense of Article 56 EPC 1973.

The appellant's sole request is, therefore, not allowable.