T 1755/10 (Software structure/TRILOGY) 06-11-2014

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division to refuse European patent application No. 99916241.5, entitled "Method and apparatus for determining commission", published as

A1: WO-A1-99/60486.

II. The examining division refused the application on the basis of a main request received on 3 November 2009. The division saw only an obvious automation and implementation of a business model on a notorious general-purpose computer (Article 56 EPC 1973).

Two auxiliary requests filed during oral proceedings before the examining division were not admitted into the procedure (Rule 137(3) EPC) as the amendments (relating to object-oriented programming) were said not to overcome the obviousness objection raised to the main request.

III. A notice of appeal was filed maintaining claims 1 to 47 of the refused main request. The appellant requested that the impugned decision be set aside and a patent be granted on the basis of those claims.

The statement setting out the grounds of appeal included two further sets of claims designated Auxiliary Request 1 and Auxiliary Request 2, respectively, essentially corresponding to the first and second auxiliary requests that had not been admitted by the examining division.

Initially, a further request relating to a refund of the appeal fee was filed; that request was dropped during oral proceedings before the Board.

(a) Claim 1 according to the main request reads:

"1. A method for determining commissions to be paid to a plurality of recipients, wherein the method is implemented using one or more data processing systems that include (A) a data model, wherein said data model includes (i) quotas, (ii) allocation rules, and (iii) promotions and (B) a commission engine to receive transactions, to access the model and to process each transaction in accordance with the model, said method being executed by a computer and comprising:

- obtaining one or more transactions;

- obtaining from the data model one or more quotas that apply to the one or more transactions, and which represent levels of commissions available to one or more recipients;

- determining a quota state for each recipient using the commission engine, wherein each quota state includes recipient identification data and current performance data of the identified recipient;

- obtaining from the data model one or more promotions that specify a reward for one or more of said levels;

- calculating performances of the recipients based on said transactions and using the commission engine, wherein calculating performances comprises:

obtaining one or more of the allocation rules of the model corresponding to the transactions wherein for each of the transactions, said allocation rules apportion credit to one or more recipients; and

applying the allocation rules to the transactions,

using the quotas and quota states to calculate the performances;

- using the commission engine, determining a compensation for those recipients, the performance of which qualifies for a promotion."

(b) According to Auxiliary Request 1, the opening paragraph of claim 1 reads:

"1. A method for determining commissions to be paid to a plurality of recipients, wherein the method is implemented using one or more data processing systems that include (A) a data model, wherein said data model includes (i) a quota object in the sense of object-oriented programming, (ii) allocation rules, and (iii) a promotion object in the sense of object-oriented programming and (B) a commission engine to receive transactions, to access the model and to process each transaction in accordance with the model, said method being executed by a computer and comprising:"

(c) According to Auxiliary Request 2, the opening paragraph of claim 1 reads:

"1. A method for determining commissions to be paid to a plurality of recipients, wherein the method is implemented using one or more data processing systems that include (A) a data model, wherein said data model includes (i) a quota object in the sense of object-oriented programming, wherein the instance of the quota object comprises a collection of objects that maintain the current performance of each individual recipient, (ii) allocation rules, and (iii) a promotion object in the sense of object-oriented programming and (B) a commission engine to receive transactions, to access the model and to process each transaction in accordance with the model, said method being executed by a computer and comprising:"

IV. Argumentation in the statement setting out the grounds of appeal

Main Request

Technical character was not limited to hardware features such as computers and data processing systems. The implementation of a business method might have technical character if it was based on technical considerations (T 258/03?Auction method/HITACHI, Reasons 3.6 and 5.8). Likewise, data structures used independently of any cognitive content had technical character (T 1194/97?Data structure product/IBM; T 424/03?Clipboard Formats/MICROSOFT). Decision T 688/05?Ticket auctioning system/TICKETMASTER cautioned that disregarding seemingly non-technical features might lead to inappropriate results. The examining division erred in its approach considering only individual features rather than the entirety of features as required by opinion G 3/08 of the Enlarged Board of Appeal.

The present application concerned a specific program structure, namely an "engine" and a separate "data model" comprising rules which the engine accessed to process transactions. This program structure represented a technical implementation because it related to the internal operation of a computer and was independent of the specific content processed or the business method implemented. The term "engine" was commonly used as an independent, task-specific part of a computer program. The term "data model" implied a certain data structure used by the engine and comprised "rules", i.e. conditions and logic functions, which were different from mere parameters or values.

Said program structure, separating the rules from the data processing, was more flexible compared to a "rigid program" implementing the conditions of the business scheme by "if" statements, cf. Figure 4 of

D2: US-A-5 483 444.

An update to the incentive scheme did not require the entire computer implementation to be reprogrammed but only the commission model needed to be amended. This also facilitated program maintenance. Furthermore, by separating the rules of the incentive program from the data processing proper, it was possible to implement an incentive program of essentially any level of complexity. The separation also allowed certain steps or stages of the data processing to be performed in parallel on different computers. These were technical effects supporting the presence of an inventive step.

Technical features were features independent of the business model to be implemented and, more generally, of the content of the data processed. If one replaced the business-related terms in claim 1 by neutral technical terms, e.g. replacing quotas, allocation rules and promotions by first, second and third data-processing rules, the method of claim 1 would still be workable and make sense. In fact, one could use the process flow of claim 1 for any other business method, unrelated to commissions, or even for technical applications.

The problem underlying the invention was to find a specific implementation rather than any implementation. The objective technical problem was how to provide a specific computer implementation of an incentive scheme, which implementation was more flexible, allowed for the processing of a large number of transactions and allowed the recipient and the system to check the amount of commission due.

The closest prior art was represented by D2 which related to a computer-implemented commission scheme for hotel reservations corresponding to the prior art mentioned in the present application (A1, page 3, from line 21). D2 did not disclose or suggest using a data model interacting with an engine to process the transactions. Nor could such a suggestion be derived from

D3: US-A-4 825 360, or

D1: Hansen, H.R.: "Wirtschaftsinformatik", 7th edition, revised reprint 1998, pages 7...21, 122...131, 469...477.

D3 related to a low-level processor architecture which allowed parallel processing. A person skilled in the art of application software typically used a high-level programming language and would not look into prior art related to the operation of processors. D1 was only a background document explaining the use of computers in business applications. It did not disclose or suggest a program architecture as proposed by the present application.

First Auxiliary Request

The first auxiliary request clarified that the term "object" was to be understood in the sense of object-oriented programming. Support for the clarifying features could be found in A1, e.g. on page 16 (lines 25/26), page 25 (lines 10 to 12), page 27 (from line 26) and original claim 10.

The specific use of an object-oriented approach was also considered non-obvious. At the priority date, the use of object-oriented programming was not so common that a person skilled in the art would have considered it for solving the problem of the application without receiving any suggestion or hint.

Second Auxiliary Request

The allegation in the decision under appeal (point 5.3) that the additional features of the second auxiliary request merely added cognitive content was considered to be wrong. Auxiliary request 2 specified the implementation of the commission scheme in greater detail without any change to cognitive content.

V. The Board appointed oral proceedings, as requested by the appellant, and communicated its preliminary opinion with the summons.

Claim 1 (main request) seemed to relate to a business goal (determining a commission) while relying on a software concept (separating a data model from an engine) which did not appear to enter into the examination for an inventive step. Even if the software concept were to be considered as technical, modular programming would appear notorious. Thus, the claimed method did not appear to include any non-obvious technical contribution.

The Board tended to admit the auxiliary requests into the procedure but doubted that a specific programming structure (object-oriented programming) would enter into the examination for an inventive step. Moreover, object-oriented programming was known before the priority date of the present application, as acknowledged by the application.

VI. In a written response to the summons and at the ensuing oral proceedings before the Board, the appellant argued that claim 1 did not claim an abstract concept or software as such but a method of processing data according to software embodying said data model and engine. The operation of a computer and especially data processing on a computer was a technical process to be distinguished from software as such. While the non-technical aim of determining a commission might be given to a software architect by a business man, any new way of processing a data input changed the operation of the computer and, thus, produced a "further" technical effect beyond the elementary interaction of computer software and hardware (i.e. beyond the transformation of physical states in a computer under the control of software). A desired commission scheme did not pre-empt a specific technical implementation from among a variety of conceivable implementations. Therefore, all aspects of the specific implementation claimed should be considered for inventive step. Like in other fields of technology, a distinction had to be made between the mental activity of inventing and the patentable result of that activity. No discrimination should be made against inventions in the field of computer technology.

Business-related aspects of a claim must not detract from its technical functions. Business aspects in claim 1 might affect its conciseness but did not negate the technical functions specified. A proven and recommendable test for the technical character of a feature was whether a machine kept working if the feature was taken away; if the machine stopped working, the feature was clearly a technical one.

The data model according to the application was not a subroutine or program module comprising executable code but it defined rules at a more abstract level. By providing an engine and a separate data model which told the computer how to work, the claimed computer-implemented method could be changed or updated easily whereas a conventional rigid program required deep reprogramming to accomplish the change. Like in Gutenberg's technical invention of flexible printing, the flexibility achieved was a technical advantage of the method even though the advantage did not show when running the method but only when changing it.

The examining division had failed to provide proper reasons for considering most of the claimed features as non-technical. By ignoring those features, the division reduced the claimed subject-matter to some hypothetical "core" - an obsolete national approach never endorsed by the Boards of Appeal. As a matter of transparency and fairness, the division should have considered the appellant's central counterarguments in greater detail, both in its substantive decision regarding the main request and its procedural decision regarding the auxiliary requests.

As to the merits of the auxiliary requests, the appellant argued that object-oriented programming was tied to the internal operation of the computer and, thus, technically relevant. It had an impact on how to process data by means of embedded (as opposed to sequential or linear) programming. Therefore, the question to be asked was whether an object-oriented approach was obvious to the programmer. It had been known only at an academic level but not for the specific purpose of the present application. Hence, object-oriented programming with a view to further enhancing flexibility was not rendered obvious by the available prior art (could/would issue).