14-15 November 2018
|European Case Law Identifier:||ECLI:EP:BA:2014:T175510.20141106|
|Date of decision:||06 November 2014|
|Case number:||T 1755/10|
|IPC class:||G06F 15/00
|Language of proceedings:||EN|
|Download and more information:||
|Title of application:||METHOD AND APPARATUS FOR DETERMINING COMMISSION|
|Applicant name:||TRILOGY DEVELOPMENT GROUP|
|Relevant legal provisions:||
|Keywords:||Inventive step - no (no further technical effect implied in modified software)|
Software implementation fallacy (reasons, points 6 and 11)
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
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
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).
Reasons for the Decision
1. The application addresses a need for a system that quickly communicates an incentive plan to sales representatives, accurately and effectively calculates compensation to be paid to sales representatives, and allows flexibility to adjust an incentive plan as needed in a rapidly changing environment (A1, page 4, paragraph 3).
In its most general aspect (original claim 1), the application proposes a computerised method for determining a performance-related commission for a recipient (sales representative). The description discusses a commission engine and a data model (218) (A1, from page 17 onwards), in particular using object-oriented programming (from page 10 onwards).
Article 56 EPC 1973 ? Inventive step
2. In the light of Article 52(1)(2)(3) EPC, Article 56 EPC 1973 requires a non-obvious technical contribution (see e.g. T 641/00-Two identities/COMVIK, Headnote 1, OJ EPO 2003, 352; T 1784/06-Classification method/COMPTEL).
Non-technical aspects cannot meet that requirement. The overall goal of claim 1 is a method for determining performance-related commissions to be paid to sales representatives. This is a commercial goal; sales and marketing considerations ("commissions", "promotions", "reward", "credit", "compensation") cannot enter into the examination for an inventive step.
3. The claimed method seeks to support managers in a rapidly changing business environment (A1, page 3, paragraphs 2 and 3; page 4, paragraph 3). Automation is a general technical answer to that need: the method makes use of data processing systems. However, the general technical idea of computer-implemented automation is notorious, and its use is obvious also in the present context.
4. It is true that claim 1 comprises not only said general idea. The claimed implementation lends itself to rapid changes by combining a "commission engine" (a piece of software for a specific data processing task) with a "data model". Whenever rules have to be adapted to a changing situation, only the data model needs to be updated whereas the commission engine and its way of accessing the data model can be invariable.
5. In view of the broad wording of claim 1, the combination of a "data model" and an "engine" constitutes a general software concept. A priori, programs for computers are not regarded as inventions (Article 52(2)(c) EPC). If the application disclosed a "further" technical effect of the software concept, beyond the elementary interaction of any computer software and hardware (T 1173/97-Computer program product/IBM, OJ EPO 1999, 609), then the software concept would not relate to computer programming as such (Article 52(3) EPC).
6. As the overall goal of the claimed method (determining commissions) is not technical, the software concept cannot derive any (further) technical character from that goal. In fact, the Board judges that no "further" technical effect is present at all.
On the one hand, a "further" technical effect does not have to be external to the computer. For example, a specific way of programming might result in a more stable operation of the computer itself.
On the other hand, the Board does not follow the appellant's central and fundamental argument: Any different way of programming is said to change the internal operation of the computer and should be considered as a technical implementation already for that reason.
Such an approach would result in any software being considered as a technical means of its own. It would effectively remove computer programs from the list of non-inventions according to Article 52(2)(c) EPC -- by which the Board is bound (Article 23(3) EPC) even if the appellant regards this as a discrimination against computer-implemented inventions.
Therefore, the Board judges that in the absence of any other potential "further" technical effect, the mere use of a specific software solution does not amount to a technical implementation (which would have to be considered in the inventive step examination).
In other words, the frequent general argument that modified software causes a modified behaviour of the computer and should for that very reason (eo ipso) be considered as a technical implementation means is insufficient. Hence, a "software implementation fallacy" might be added to a pertinent gallery established recently by the Board (T 1670/07-Shopping with mobile device/NOKIA).
7. As the software concept is not considered to contribute to the technical character of the method, it does not enter into the examination for an inventive step.
Hence, it can be left open what kind of code is intended to form a "data model" according to claim 1, i.e. whether the wording of the claim rules out conventional program modules (subroutines), which are well-known to increase the flexibility of programming and facilitate the maintenance of programs.
8. The data items processed according to the claimed method are defined by their commercial content and intent rather than by any non-obvious functional or structural aspect. Hence, they do not provide any non-obvious contribution, either.
9. Therefore, the Board judges that the method of claim 1 does not involve any inventive step.
Auxiliary Request 1
10. While formally not admitting the auxiliary request into the first-instance procedure under Rule 137(3) EPC, the examining division provided an extensive substantive analysis and assessment of the amended claim 1.
As the Board is in a position to comment on that analysis, it admits the auxiliary request into the appeal procedure.
11. The amendment according to auxiliary request 1 specifies the use of object-oriented programming in the form of two objects in the data model: the data model contains a "quota object" and a "promotion object".
An object-oriented program can be created at a higher (more abstract) level and, thus, may be designed and changed more easily, without considering details of the computer platform. However, even a more specific program structure within the data model does not constitute a technical implementation by itself as the alleged technical effect is limited to the general observation that modified software results in a modified operation of the computer. This is just another way of saying that software interacts with hardware and, thus, is not sufficient to establish a "further" technical effect.
Consequently, even the more specific programming structure does not enter into the examination for an inventive step.
12. It may be added that object-oriented programming was known before the priority date of the present application, as acknowledged by the application (see the pre-published article by Lieberman mentioned in the paragraph bridging pages 11 and 12 of A1).
Auxiliary Request 2
13. The above comments on the first auxiliary request apply mutatis mutandis to the second auxiliary request.
Claim 1 is more specific in that the quota object comprises a collection of objects that maintain the current performance of each individual recipient. However, the concept of an object comprising a collection of objects is still a programming concept without any "further" technical effect. Therefore, even the more specific concept does not enter into the examination for an inventive step.
14. It may be added that the concept of nested objects is disclosed in Lieberman (page 216, left-hand column, chapter 4, end of 2nd paragraph: "composite objects extensions"). Moreover, as the description of the present application does not provide any detail regarding objects within an object, "a collection of objects" according to claim 1 encompasses conventional pointers to those objects (Lieberman, page 216, right-hand column, "Tools for Sharing Knowledge", "Extensions").
Procedural remark on the decision under appeal
15. In response to the examining division's summons and preliminary opinion, the appellant filed extensive counter-arguments (letter of 3 November 2009). Nevertheless, the reasons in the decision under appeal are almost identical to the reasons in the examining division's preliminary opinion, as far as the issue of (non-)technical subject-matter is concerned. The appellant's conclusion is that the examining division had grounds to consider the submissions not to be pertinent without communicating those grounds to the appellant, contrary to the requirements of Article 113(1) EPC (right to be heard).
16. The Board does not consider that the appellant's right to be heard has been infringed. In a case like the present one in which oral proceedings took place, the assumption is that the examining division and the party discussed the additional arguments orally.
However, for the same reason, a helpful summary of that discussion could have been, and preferably should have been, included in the appealable decision to complete its reasoning (Rule 111(2) EPC).
For these reasons it is decided that:
The appeal is dismissed.