T 1952/12 - Enterprise software

EPO T 1952/12

For the decision, click here. 

Key points

• This case relates to inventive step of a claim for an invention relating to enterprise software. 
• The Board notes that  " 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." 

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 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 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.