|European Case Law Identifier:||ECLI:EP:BA:2015:T195212.20150811|
|Date of decision:||11 August 2015|
|Case number:||T 1952/12|
|IPC class:||G06F 9/46|
|Language of proceedings:||EN|
|Download and more information:||
|Title of application:||Data processing method and system|
|Applicant name:||SAP SE|
|Relevant legal provisions:||
|Keywords:||Inventive step - based on the prior art acknowledged in the application itself
Skilled person for transactional data processing system - not a separate field
Inventive step - (no)
Referral to the Enlarged Board of Appeal - (no)
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 inventive step as the obvious implementation of an administrative 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 according to a main request or a first auxiliary request submitted with the applicant's letter dated 11 November 2011, or based on claims 1-12, 1-10, or 1-8 according to, respectively, second to fourth auxiliary requests as filed with the grounds of appeal. The further application documents are drawings sheets 1/5-5/5 and description 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 determining 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 considered 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 relating to room booking in the boards of appeal, why it tended to agree with the examining division that the claimed invention did not go beyond the computer-implementation of an administrative workflow. It added that the claimed invention also appeared to lack inventive step over a transaction system such as that of D1 in view of common knowledge 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 considered to be technical, when the procedure explaining the examination 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 concluded 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 inventiveness 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 features are technically motivated and make a contribution 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 instead 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
1. The application relates to enterprise software and, in this context, to what is called "transaction processing". It is explained that users initiate transactions (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 predefined "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 correction could be "extremely costly" and could, inter alia, negatively impact the response times of the transaction processing system. The application is concerned with avoiding 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 successfully 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 provided 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 prompted to input corrected codes, which have to be checked again (p. 10, 1st para.). If and when, eventually, all codes identified in a posting request are determined to be valid, the corresponding buffered posting 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 invention and not in compliance with the Guidelines for Examination 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 context where the individual steps of the claimed method are executed manually by a human being" (see grounds of appeal, p. 12, 2nd para.). The appropriate starting point for the assessment of inventive 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 considerations.
2.2 The appellant also argued in the grounds of appeal that the decision failed to establish that the administrative procedure it considered as given in the objective technical problem (see decision 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 preliminary opinion in part on a workflow 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-technical) method and supports the idea that the examining division might refer to known business method steps for that purpose. However, the board considers that the search divisions cannot systematically be required to search for methods which are, as such, excluded from patentability (cf. T 172/03, headnotes).
2.4 Moreover, since an inventive step can only be acknowledged for an invention which makes a technical contribution 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 inventive merit of an invention is concerned, it is immaterial 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 considered to define the non-technical business (or administrative) 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 procedure 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 making its distinction between which features it considered 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 workflow situations. Hence, the specification of such software 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 method) 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 abstracts (in English) of two Japanese patent applications JP63075938 and JP01007155. The abstracts contain very little technical information. The first of them discloses in particular that the validity check of an item should precede the processing of that item, and the second discloses the use of different components for performing a validity check and the actual data processing.
4. In the application itself (p. 2, 2nd para.), the following statement about the prior art is made: "Typically a transaction results in one or more postings. Each posting 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 retrospect. This may require to reverse the incorrect postings and generate corrected postings." In the board's view, the fact that the user may enter the codes that "specify" the postings implies some sort of user interface.
5. The auxiliary requests differ from the main request inter alia by an increasing number of technical details, for instance the reference to an application program, a user interface, a network and a web service. In view of this the board has decided to assess inventive step starting from a specific piece of prior art. During the oral proceedings, 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 application itself.
5.1 Since the application uses the same terminology in describing this prior art as it does in the claims, the questions raised in the summons (esp. points 6, 7 and 10) regarding the precise meaning (and clarity) of the terms "posting", "code" and code "validity", and whether these features contribute to the technical character of the invention, may be left open.
5.2 As a consequence, the board also leaves open the extent to which its preliminary 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 transaction processing system via a network interface;
b) the service component and the transaction processing 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 invalidity, the user is prompted to enter corrected codes, and the code checking is repeated.
6.1 Differences c) and d) primarily solve the problem expressly mentioned in the description, namely to avoid the need for retrospective correction 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 solved by differences b), c) and d) over the known method (and system) can be considered as avoiding the need for retrospect correction without a loss of overall efficiency.
6.2 The effect of difference a), i.e. of coupling the service component with the transaction processing system via a network, is, in the board's view, that of making the same service component available for possibly several transaction processing systems and thus of avoiding redundancy.
6.3 The board considers that the problem solved by difference a) and that solved by differences b), c) and d) are independent of each other. In particular, the provision 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 illustrated in the application, that is "transaction processing systems" as used for accounting, order processing, airline 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 parallel 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 impracticable in reality. Specifically, it was a radical change of established practice to consider parallel processing and performing 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 acknowledged that the skilled person in the field of enterprise software would not consider them without exercising an inventive step.
8. The board does not agree.
8.1 First, the board does not agree that the appropriate technical 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 properties and structure. However, such properties may be caused by non-technical circumstances, for instance that a certain order of steps is required or recommended by law or by business considerations, 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 requirements such as complying with the law, adhering to contracts and finishing within a certain 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 according 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 realise enterprise software need not be experts in scientific computing and parallel computer architectures. They do need, however, and must be assumed to have, a general understanding of software engineering and development.
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 addition to the necessary understanding of the field of application.
Differences b), c) and d)
8.6 Given the observation in the application 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 posting. 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 possibility to have the user re-enter incorrect codes might slow down the transaction processing system considerably - in comparison to the known system - if the latter were to block waiting for the code checking service to signal validity. The skilled person would also realize that the code checking is logically unrelated to the transaction processing itself and the eventual generation 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 requests than the first in generating them, the need for a buffer between the components is, for the skilled person, an obvious requirement. A typical instance of this scheme which is well-known in the art is print spooling, i.e. the provision of a buffer which decouples the computer generating print jobs from the printer processing them. Typically, this buffer is provided in the memory of the computer system generating the jobs, i.e. as presently claimed. The board further considers that the choice whether to place the buffer in the system generating the jobs, the system processing them, or elsewhere, is one which the skilled person would make without exercising an inventive step.
8.9 The board considers that there are obvious circumstances which may require the same code checking service to be available to different transaction processing systems, say located at two different branches of the same company. This could be addressed by providing separate but equivalent code checking services, or by making a central code checking service available to all systems via a network. In the board's view, the skilled person would choose between these equally obvious alternatives 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 inventive 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 networked code checking service as a "web service" is an obvious option for the skilled person. Claim 1 of auxiliary 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 "validity" and different ways of checking it. For instance, a code might be considered "valid" if it exists (say a personnel number or a zip code), if it matches a given check digit (say a bank account number), or if an authorized 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 auxiliary 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 additional arguments in favour of inventive step were, however, put forward by the appellant. The board considers that these amendments do not invalidate the board's above assessment of inventive 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 pending 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 refer questions to the Enlarged Board of Appeal only if it considers that a decision is required in order to ensure the uniform application of the law or if an important point of law arises. The answer to a referred question should not be merely of theoretical or general interest, but has to be essential for reaching a decision 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 artificial, academic or contrived way, the board considers that the answer must be "no". In order for the inventive 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 problem formulated in this context should not be merely academic or contrived, but should be one that can reasonably be assumed to have arisen at the priority 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 implementation is sufficient to establish an inventive step (see, for instance, again T 1461/12, reasons 19). In such situations, the business method constitutes 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 legitimate if "it was shown that said features are technically motivated and make a contribution to the technical 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 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." 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.
For these reasons it is decided that:
The appeal is dismissed.