T 1952/12 (Validating posting requests/SAP) of 11.8.2015

Summary of Facts and Submissions

I. The appeal lies against the decision of the examining division, with reasons dated 12 April 2012, to refuse European Patent application No. 05 111 312.4 because a main and a first auxiliary request lacked an in­ven­tive step as the obvious implementation of an admi­nis­trative procedure on a "common-place general purpose networked computer system". To amendments filed as second and third auxiliary requests the examining division did not give its consent under Rule 137(3) EPC.

II. A notice of appeal was filed on 17 April 2012, the appeal fee being paid on the same day. A statement of grounds of appeal was received on 28 June 2012. The appellant requested that the decision under appeal be set aside and that a patent be granted based on claims 1-14 accor­ding to a main request or a first auxiliary request sub­mitted with the applicant's letter dated 11 November 2011, or based on claims 1-12, 1-10, or 1-8 accor­ding to, respectively, second to fourth auxiliary re­quests as filed with the grounds of appeal. The fur­ther applica­tion documents are drawings sheets 1/5-5/5 and descrip­tion pages 1, 3-13 as originally filed, and 2 and 2a as filed with letter dated 5 December 2006. The appellant argued that the decision was based on an impermissible ex-post-facto analysis and that the approach used by the examining division in de­termining the technical problem was incorrect and not in line with the Guidelines for Examination.

III. With a summons to oral proceedings, the board informed the appellant of its preliminary opinion. It con­sidered that a number of terms used in the claims might have to be considered unclear (Article 84 EPC 1973). It then argued, with respect to an example rela­ting to room booking in the boards of appeal, why it tended to agree with the exami­ning division that the claimed in­vention did not go be­yond the computer-imple­mentation of an administrative workflow. It added that the claimed inven­tion also appeared to lack inven­tive step over a trans­action system such as that of D1 in view of common know­ledge in the art (Article 56 EPC 1973).

IV. In response to the summons, the appellant filed claims 1-7 according to a further, fifth auxiliary request. It argued that all claimed features had to be con­sidered to be technical, when the procedure explaining the exami­na­tion of computer-implemented inventions at the European Patent Office was followed (see OJ EPO 11, 2007, 594) and account was taken of board of appeal decisions T 928/03, T 971/07, and T 2055/08. It con­clu­ded that, therefore, T 641/00 COMVIK was not applicable to the present case and gave reasons why it considered the claimed subject-matter to be inventive over D1.

V. It further requested that the board refer a question to the Enlarged Board of Appeal under Article 112(1)(a) EPC as to whether it was "legitimate to negate inven­tive­ness of a claimed IT-system or method on the basis that it is possible to somehow derive a business method from claimed features (although it was shown that said fea­tures are technically motivated and make a contri­bu­tion to the technical character of the invention) and on the basis that such a "derivative business method" may also be useful in [a] completely unrelated field such as room booking."

VI. Claim 1 of the main request reads as follows:

"A data processing method in a computer system comprising:

- entering at least one code (146) for specifying at least one posting to be performed for a transaction data processing operation,

- starting the transaction data processing operation,

- sending a request (122) to a service component (120) for performing a validity check of the at least one code,

- buffering (144) one or more posting requests resulting from execution of the transactional data processing operation in a buffer memory (144), and,

- in response to receipt of a first signal (124) indicative of code validity from the service component, sending the one or more buffered posting requests with the at least one code from the buffer memory (144) to a posting component (102)."

Claim 1 of auxiliary request i reads as follows:

"A data processing method in a computer system comprising:

- entering codes (146) via a user interface for specifying multiple postings to be performed for a transaction data processing operation,

- starting the transaction data processing operation by an application program,

- sending a request (122) to a service component (120) for performing a validity check of the codes via a network interface,

- buffering (144) multiple posting requests resulting from execution of the transactional data processing operation in a buffer memory (144), and,

- in response to receipt of a first signal (124) indicative of code validity from the service component, sending the buffered posting requests with the codes from the buffer memory (144) to a posting component (102)."

Claim 1 of auxiliary request ii reads as follows:

"A data processing method in a computer system comprising:

- entering (202) codes (146) via a user interface for specifying multiple postings to be performed for a transaction data processing operation,

- starting (214) the transaction data processing operation by an application program,

- sending (204) a request (122) to a service component (120) for performing a validity check of the codes via a network interface,

- buffering (144) multiple posting requests resulting from execution of the transactional data processing operation in a buffer memory (144) while the code checking is performed,

whereby the transactional data processing and the code check are performed asynchronously such that the transactional data processing operation starts already even if the code check has not been completed, and

- in response to receipt of a first signal (124) indicative of code validity from the service component, sending the buffered posting requests with the codes from the buffer memory (144) to a posting component (102),

further comprising in response to receipt of a second signal indicative of code invalidity:

- prompting a user to enter a correction of at least one of the codes,

- sending a request for performing a validity check of the at least one corrected code to the service component,

wherein the posting requests resulting from execution of the transaction data processing operation after receipt of the second signal are continued to be buffered until receipt of the first signal."

Claim 1 of auxiliary request iii differs from claim 1 of auxiliary request ii in that

- the method comprises the following additional first step:

"... providing a user interface (148) having at least a first data entry field (150) for entry of transactional data, a second data entry field (152, 156) for codes, and an enter button (154) ...",

- the entering step now uses definite articles in­stead of indefinite ones when referring to the codes and the user interface, and

- the sending step is extended by the following clause:

"... wherein the transactional data processing operation and the sending of the request is initiated by a user's selection of the enter button".

Claim 1 of auxiliary request iv differs from claim 1 of auxiliary request iii in that the sending step is further extended by the following clause:

"... wherein the service component is a web service and the request is sent to the web service via the network (118), wherein the web service is coupled to storage means (104) holding valid codes and/or valid code ranges".

Claim 1 of auxiliary request v differs from claim 1 of auxiliary request iv in that

- the preamble is now directed towards "[a] data processing method of operating a computer system",

- the entering step now refers to the entering being made "by" rather than "via a user interface",

- the starting step is extended by the additional clause "... for performing the transactional data processing operation",

- the sending step now reads as follows: "sending (204) a request (122) to a service component (120) for performing a validity check of the codes via a network interface, wherein the service component is a web service and the request is sent to the web service via the network (118), wherein the transactional data processing operation and the sending of the request is initiated by a user's selection of the enter button",

- the buffering step is extended by the following clause: "... the posting requests being generated by program instructions (130) of an application program (128) for performing the transactional data processing operation ...", and that

- the "sending of buffered posting requests" is additionally specified to be "via a network".

All the requests contain a system claim corresponding closely in wording to the respective method claim 1.

VII. At the end of the oral proceedings, the chairman announced the decision of the board.

Reasons for the Decision

The invention

1. The application relates to enterprise software and, in this context, to what is called "transaction pro­cessing". It is explained that users initiate trans­actions (see application as filed, p. 2, 1st para.) and that transactions "result in one or more postings" (p. 2, 2nd para.). It is not specifically explained what a "posting" is, except that it is "encoded" by pre­defined "codes" such as area codes or cost center codes (loc. cit.). Codes are entered by the users through a suitable user interface (see Fig. 5).

1.1 It is disclosed that entered codes may be incorrect ("invalid") and "the respective postings may [then] have to be corrected in retrospect". Such a correc­tion could be "extremely costly" and could, inter alia, nega­tively impact the response times of the transaction pro­cessing system. The application is concerned with avoi­ding the need for such corrections.

1.2 The proposed solution is to check the codes before the postings are actually carried out and to buffer the posting requests until the code checking is success­fully completed. Moreover, it is proposed that the code checking is performed by a code checking component, which is coupled to the transaction processing system via a network and which can operate in parallel with the latter (see Fig. 1, Nos. 100, 118, 126; Fig. 2, Nos. 214, 204; para. bridging pp. 2-3). The code checking could, for instance, be pro­vided as a web service (see, e.g., p. 4, last para., and p. 9, penult. para.).

1.3 If a code is determined to be invalid, the user is promp­ted to input corrected codes, which have to be checked again (p. 10, 1st para.). If and when, eventu­ally, all codes identified in a posting request are de­ter­mined to be valid, the corresponding buffered pos­ting request is carried out (p. 8, lines 16-18; p. 10, 2nd para.).

The decision under appeal

2. The appellant argued that the reasoning in the decision was based on an ex-post-facto analysis of the inven­tion and not in compliance with the Guidelines for Examina­tion of "mixed" inventions as set out in the Official Journal EPO 11, 2007 (see letter dated 7 July 2015; p. 4, last para. - p. 9, 1st para.).

2.1 It argued that "[t]he business method proposed by the Examining Division [was] [...] not of any use in a con­text where the individual steps of the claimed method are executed manually by a human being" (see grounds of appeal, p. 12, 2nd para.). The appro­priate starting point for the assessment of in­ven­tive step therefore could not be a "pencil-and-paper based setting" but had to be an automated - and thus technical - transaction processing system, and the claimed features were all provided based on technical conside­rations.

2.2 The appellant also argued in the grounds of appeal that the decision failed to establish that the adminis­tra­tive procedure it consi­dered as given in the objective technical problem (see deci­sion under appeal, p. 8, 3rd para.) had been known in the art, and, during the oral proceedings, it took the position that so had the board when basing its preli­minary opinion in part on a work­flow situation in the boards of appeal (see summons, point 11.1).

2.3 The board appreciates that an inventive step objection may, at times, be more immediately convincing to or more easily acceptable by an applicant or proprietor if it is based on a known business (or otherwise non-tech­nical) method and supports the idea that the examining division might refer to known business method steps for that pur­pose. However, the board considers that the search di­vi­sions cannot systematically be required to search for methods which are, as such, excluded from paten­ta­bility (cf. T 172/03, headnotes).

2.4 Moreover, since an inventive step can only be ack­now­ledged for an invention which makes a technical con­tri­bution to the art (see, e.g., T 1461/12, reasons 15.1, and references therein), even a new business method alone will be insufficient to establish an inventive step. Therefore, as far as the assessment of the in­ven­tive merit of an invention is concerned, it is immate­rial whether the business method features referred to in the objective technical problem as "the aim to be achieved in the non-technical field" (see T 641/00, OJ EPO 2003, 352; headnote 2) are known or not (see also T 154/04, OJ EPO 2008, 46, reasons 16).

2.5 Returning now to the decision under appeal, the board notes that the examining division set out in detail which of the claimed features in combination it consi­dered to define the non-technical business (or admini­strative) method and which it considered as technical, implementation-related features. The board cannot find that, in doing so, it was in any conflict with the pro­cedure for examination as set out in the Official Journal.

2.6 The board also cannot find that the examining division, in its decision, applied an unreasonable approach in ma­king its distinction between which features it con­sidered to make a technical contribution and which not.

2.7 The board observes that enterprise software as mentioned in the application is often meant to provide support for and thus to be modelled on existing work­flow situ­a­tions. Hence, the specification of such soft­ware systems may well, to a large degree, require the workflow to be specified. That, according to T 641/00, the technical problem to be solved may turn out to be how to implement a given workflow (or business or administrative me­thod) is, according to the board, a realistic approach. The board agrees with the appellant that the specific technical problem must be formulated with care and in fairness (see below, point 18.1.1) in order to avoid hindsight reasoning, but cannot find the decision under appeal to be objectionable in this respect.

The prior art

3. The decision under appeal refers to the ab­stracts (in English) of two Ja­panese patent appli­ca­tions JP63075938 and JP01007155. The abstracts contain ve­ry little tech­nical infor­ma­tion. The first of them discloses in par­ti­cular that the validity check of an item should pre­cede the processing of that item, and the second dis­closes the use of different com­ponents for performing a vali­di­ty check and the actu­al data pro­cessing.

4. In the application itself (p. 2, 2nd para.), the follow­­ing statement about the prior art is made: "Ty­pi­cally a transaction results in one or more postings. Each pos­ting is encoded using one or more predefined codes that specify the posting, such as a business area code, asset code, cost center code, order code, profit center code. If the code entered by a user is invalid, the respective postings have to be corrected in retro­spect. This may require to reverse the incorrect pos­tings and generate corrected postings." In the board's view, the fact that the user may enter the codes that "speci­fy" the postings implies some sort of user inter­face.

Inventive step

5. The auxiliary requests differ from the main request in­ter alia by an increasing number of technical details, for instance the reference to an application program, a user interface, a net­work and a web service. In view of this the board has decided to assess inventive step star­ting from a specific piece of prior art. During the oral pro­ceedings, the appellant agreed to the board's suggestion to base the inventive step assessment of the claimed invention on the method and system as described in the appli­cation itself.

5.1 Since the application uses the same terminology in de­scribing this prior art as it does in the claims, the ques­tions raised in the summons (esp. points 6, 7 and 10) regarding the precise meaning (and clarity) of the terms "posting", "code" and code "va­li­dity", and whe­ther these features contribute to the techni­cal charac­ter of the invention, may be left open.

5.2 As a consequence, the board also leaves open the extent to which its pre­liminary analysis (esp. point 11) as set out in the summons applies to the present requests and, specifically, how it would have to be adapted for the different requests at stake.

Main request and auxiliary requests i and ii

6. Claim 1 according to auxiliary request ii differs from the known transaction processing method in that

a) a service component is provided to perform the code validity checks and is coupled to the trans­action pro­cessing system via a network interface;

b) the service component and the transaction pro­cessing system operate "asynchronously", i.e. in parallel;

c) the posting requests are buffered while the code checking is being performed and until the code checking service indicates code validity;

d) if the code checking service indicates code inva­lidity, the user is prompted to enter corrected codes, and the code checking is repeated.

6.1 Differences c) and d) primarily solve the problem ex­pressly mentioned in the de­scrip­tion, namely to avoid the need for retrospective correc­tion of the codes. The buffering of unchecked posting requests according to difference c) in combination with difference b) has the further effect that the code checking does not block the transaction processing after the generation of a posting request and ensures that the claimed system is, in this respect, not slower than the known one. The problem sol­ved by differences b), c) and d) over the known method (and sys­tem) can be con­sidered as avoiding the need for retro­­spect correction without a loss of overall efficiency.

6.2 The effect of diffe­rence a), i.e. of coupling the ser­vice component with the transaction processing system via a network, is, in the board's view, that of making the same service compo­nent available for possibly se­ve­ral trans­action pro­cessing systems and thus of avoiding redun­dan­cy.

6.3 The board considers that the problem solved by diffe­rence a) and that solved by differences b), c) and d) are independent of each other. In particular, the pro­vi­sion of a networked code checking component is also possible and useful in the known system, even if the code checking is performed after the posting and a retrospective correction may still therefore be necessary.

The technical field and the skilled person

7. The appellant argued that the invention did not relate to the field of software development in general but to the more narrow field of enterprise software illustra­ted in the application, that is "transaction processing sys­tems" as used for accounting, order processing, air­line booking or credit control (see p. 1, last para. - p. 2, 1st para.). Moreover, the skilled person had to be assumed to be an expert in such systems, rather than, for instance, an expert in scientific computing and pa­rallel computer architectures.

7.1 The systems in the field of enterprise software had certain established and accepted properties which the skilled person would normally not question or set out to change. Specifically, these systems were generally sequential and it was conventional practice to perform code checks only after "posting".

7.2 The skilled person trying to improve existing systems would have to overcome convention and prejudice in the field and might find that certain changes ­were imprac­ti­­cable in reality. Specifically, it was a radical change of established practice to consider parallel processing and perfor­ming the checks anywhere else than after posting.

7.3 Even if, therefore, it could be argued that the skilled person could do certain things, it had to be acknow­ledged that the skilled person in the field of en­ter­prise software would not consider them without exer­cising an inventive step.

8. The board does not agree.

8.1 First, the board does not agree that the appropriate tech­ni­cal field to be considered in the present case was the narrow field of enterprise systems.

8.2 The board accepts that systems in the field may have established proper­ties and structure. However, such properties may be caused by non-technical circumstan­ces, for instance that a certain order of steps is re­quired or re­commen­ded by law or by business consi­de­ra­tions, or that a certain class of systems has become a de facto standard in the field. The board also accepts that the skilled person trying to improve such a system will be constrained by several non-technical require­­ments such as complying with the law, adhering to con­tracts and fini­shing within a cer­tain time and cost frame.

8.3 In the board's view, the requirement for inventions to be technical implies that what the skilled person would or would not find obvious to do must be assessed accor­ding to technical criteria only. A technically obvious solution does not become non-obvious for the purpose of inventive step (Article 56 EPC 1973) if the solution turns out to be impracticable, too costly or illegal.

8.4 The board accepts that the persons with the skill to design and rea­li­se enterprise software need not be ex­perts in scien­tific computing and parallel computer ar­chitectures. They do need, however, and must be assumed to have, a general under­standing of software enginee­ring and develop­ment.

8.5 The board thus considers that the skilled person in the present case must be assumed to have a solid knowledge of software engineering and development principles - in addi­tion to the necessary understanding of the field of application.

Differences b), c) and d)

8.6 Given the observation in the appli­cation that code checking after the posting causes undesirable costs due to the need for retrospective code checking, the board deems it immediately obvious for the skilled person to perform the code checking before the posting. It is also evident that the goal of "posting" only correct codes entails the need for correction before the pos­ting. As the codes are initially entered by the user, the board considers it obvious to have the user also perform the correction.

8.7 The skilled person would obviously realize that the possi­bility to have the user re-enter incorrect codes might slow down the transaction processing system con­si­derably - in comparison to the known system - if the latter were to block waiting for the code checking ser­vice to signal validity. The skilled person would also realize that the code checking is logically unre­lated to the transaction processing itself and the eventual gene­ra­tion of further posting requests.

8.8 The board considers that it would be obvious for the skilled person to decouple two independent components from each other and allow them to operate in parallel in order to increase the overall system throughput. If the second component might be slower in processing re­quests than the first in generating them, the need for a buffer between the components is, for the skilled per­­son, an obvious requirement. A typical instance of this scheme which is well-known in the art is print spooling, i.e. the pro­vi­sion of a buffer which decouples the com­puter generating print jobs from the printer pro­cessing them. Typically, this buffer is pro­vided in the memory of the computer system genera­ting the jobs, i.e. as pre­sently claimed. The board further considers that the choice whether to place the buffer in the system gene­rating the jobs, the system pro­cessing them, ­or else­where, is one which the skilled person would make with­out exer­cising an inventive step.

Difference a)

8.9 The board considers that there are obvious circumstan­ces which may require the same code checking ser­vice to be available to different transaction processing systems, say located at two different branches of the same com­pa­ny. This could be addressed by providing se­parate but equivalent code checking services, or by making a cen­tral code checking service available to all systems via a network. In the board's view, the skilled person would choose between these equally obvious al­ter­natives by balancing their relative advantages and disadvantages against each other.

9. In summary, the board concludes that differences a) to d) do not establish that the subject-matter of claim 1 according to auxiliary request ii is based on an in­ventive step (Article 56 EPC 1973). As claim 1 of the main request and of auxiliary request i is strictly more general than claim 1 of auxiliary request ii, claim 1 of these requests also lacks an inventive step.

Auxiliary request iii

10. The differences of claim 1 over the higher-ranking requests relate, in the board's judgment, to common-place details of user interfaces and their operation.

Auxiliary request iv

11. The board considers that the implementation of a net­worked code checking service as a "web service" is an obvious option for the skilled person. Claim 1 of auxil­iary request iii further states that the code checking service is coupled to storage means holding valid codes and/or code ranges. The board notes that for different kinds of codes there may be different notions of "vali­di­ty" and different ways of checking it. For instance, a code might be considered "valid" if it exists (say a per­sonnel number or a zip code), if it matches a given check digit (say a bank account number), or if an au­tho­rized person accepts it as valid. In a situation like the one first mentioned it is obvious, in the board's view, to provide the code checking service with a storage means defining valid codes as claimed.

Auxiliary request v

12. The additional features of claim 1 according to auxil­iary request v were meant, as explained by the appellant during oral proceedings, to clarify the claimed subject-matter and to make more evident its technical nature. No addi­tio­nal arguments in favour of inventive step were, how­ever, put forward by the appellant. The board considers that these amendments do not invalidate the board's above assessment of inven­tive step, given that the implicit understanding all along was that the prior art and the claimed invention related to a computer-based transaction processing method or system.

13. In summary, the board concludes that none of the pen­ding requests shows the required inventive step over the known system as disclosed in the application itself (Article 56 EPC 1973).

The request to refer a question to the Enlarged Board of Appeal

14. According to Article 112(1)(a) EPC, the board shall re­fer questions to the Enlarged Board of Appeal only if it considers that a decision is required in order to en­sure the uniform appli­cation of the law or if an im­por­tant point of law ari­ses. The answer to a referred question should not be merely of theoretical or general interest, but has to be essential for reaching a deci­sion on the appeal in question (see, e.g., G 3/98; OJ EPO 2001, 62; reasons 1.2.3).

15. In view of the fact that the board's decision does not rely on the finding that the claimed invention is an obvious implementation of a business method, an answer to the question proposed by the appellant is not required for the board's decision.

16. Nonetheless, the question is pertinent to the present case, since the decision under appeal relied on that argument. In this regard, however, the board considers itself able to give the answer itself without any doubt (see J 5/81, OJ EPO 1982, 155, headnote 2).

17. In particular, the board considers the following.

17.1 The question formulated by the appellant asks, inter alia, whether it is "legitimate to negate inventiveness of a claimed IT-system or method on the basis that it is possible to somehow derive a business method from claimed features", and whether this may be done "on the basis that [it] may also be useful in [a] completely unrelated field".

17.1.1 To the extent that the appellant, in using the terms "somehow" and the reference to a "completely unrelated field", means to ask whether the business method in question may be derived in an arti­fi­cial, academic or contrived way, the board considers that the answer must be "no". In order for the inven­tive step assessment of inventions comprising both technical and non-technical features using the approach based on T 641/00 COMVIK to be fair, the objective technical prob­lem ­­formulated in this context should not be mere­ly academic or contrived, but should be one that can reaso­na­bly be assumed to have arisen at the priori­ty date (see T 1461/12, reasons 17.2, and decisions cited therein).

17.1.2 Whether the concrete business method in question is from a "completely unrelated field" may depend, as in the present case, on a judgment by the deciding body, and whether the choice is legitimate in an individual case will have to be decided based on, inter alia, the breadth of the terminology used in the claims.

17.1.3 Beyond that, however, the board considers that it may well be legitimate to "derive a business method from the claimed feature" and ask whether its technical imple­men­tation is sufficient to establish an inventive step (see, for instance, again T 1461/12, reasons 19). In such situations, the business method consti­tutes the "aim to be achieved in a non-technical field" within the meaning of T 641/00, headnote 2.

17.2 The question also asks whether this approach is le­gi­timate if "it was shown that said features are tech­nically motivated and make a contribution to the tech­ni­cal character of the invention".

17.2.1 The board endorses the statement in headnote 1 of T 641/00 that "[a]n invention consisting of a mixture of technical and non-technical features and having tech­ni­cal 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." To this extent, the answer to the question must also be "no".

17.2.2 The board remarks however, that the question of which features in a given claim contribute to the technical character of an invention is a question of fact which requires judgment on the part of the deciding body which must be exercised with care and in fairness, as argued above.

Order

For these reasons it is decided that:

The appeal is dismissed.