T 0505/09 (Testing program code/SIEMENS) of 9.11.2012

Summary of Facts and Submissions

I. The appeal lies against the decision of the examining division, with written reasons dispatched on 7 August 2008, to refuse European patent application 04810843.5. The decision mentions, inter alia, the following two do cu ments based on which objections had been raised du ring examination:

D1: Greer D., "How to debug a program", excerpt from the "SMUG" book, pp. 1-2, March 2001, retrieved from the Internet, and

D2: Moock C., "Actionscript for Flash MX: The Defini tive Guide", 2nd ed., Chapter 19, O'Reilly, 2001,

but it does not rely on either of them for its reasons. The then main and 1st auxiliary requests were refused for lack of an inventive step over common knowledge alone, whereas the then 2nd auxiliary request was found to violate Articles 84 EPC 1973 and 123 (2) EPC. In an obiter dictum however, the 2nd auxiliary request, sui ta bly interpreted, was also argued to lack an inventive step over common knowledge alone.

II. An appeal was filed on 6 October 2008, the appeal fee being paid on the same day. A statement of grounds of appeal was filed on 17 December 2008. It was reques ted that the decision be set aside and a patent be granted based on one of three sets of claims filed with the grounds of appeal.

III. With a summons to oral proceedings, the board informed the appellant about its preliminary opinion according to which the claims lacked clarity, Article 84 EPC 1973, and the main and 1st auxiliary requests lacked an in ven tive step, Article 56 EPC 1973, but indicated that it was minded to remit the case to the first instance for further prosecution if a clarified 2nd auxil ia ry request were submitted.

IV. During oral proceedings, the appellant submitted an amended claim 1 and replaced all his earlier request with the sole request that a patent be granted based on this claim with fur ther claims to be defined. The further application documents on file are as follows:

description pages

1, 4, 5, 8-13 as originally filed

2, 6, 7 as filed with telefax on 4 July 2007

3, 14 as filed with telefax on 4 February 2008

drawing sheets

2/4-4/4 as originally filed

1/4 as filed with telefax on 4 July 2007

V. Claim 1 reads as follows:

"A method for identifying defective program code, comprising:

providing a first program code (GoodDLL) consisting of verified program components (S1, S2, S3, S4, S5) and a second program code (NewDLL) having a plurality of modified program components (S2',S3',S5'), wherein a test of the second program code (NewDLL) failed;

(i) grouping the plurality of modified program components (S2', S3', S5') into sets,

(ii) running the test process for each of the sets of modified program components (S2', S3', S5') by creating a third program code (TestDLL) which corresponds to the second program code (NewDLL), wherein the set of modified program components (S2', S3', S5') is replaced with a set of corresponding ones of the verified program components (S2, S3, S5) and testing the third program code (TestDLL), and

(iii) determining on a test of a set failed that the set contains a defective modified program component;

automatically testing a further third program code (TestDLL), wherein in said third program code (TestDLL), one of the modified program components (S2', S3', S5') of the failed set is replaced with a corresponding one of the verified program components (S2, S3, S5) and designating the replaced modified program component as defective according to the results of the test."

VI. At the end of the oral proceedings, the chairman pronounced the decision of the board.

Reasons for the Decision

The invention

1. The application relates to the tes ting of software du ring software development. More specifically it relates to the rather common situation that a program used to work properly (i.e. pass the per tinent tests) at some point in time but stopped wor king properly (i.e. failed at least some of the per ti nent tests) after having been modified ("Yesterday my program worked. Today it does not. Why?"; see de scription, pars. 1-3). In the art, such testing of modified code is referred to as re gression testing.

1.1 The application pro poses a procedure based on se lec tive ly replacing modified program components by ear lier, ve ri fied compo nents - there by "undoing" some of the mo di fications - and running the pertinent tests again (see fig. 2). When this second run succeeds, it is concluded that the re placed components must contain an error (see e.g. fig. 4). The application further proposes to per form this procedure in two stages: In the first one, an entire set of pro gram components is re placed by corres pon ding set of verified ones and the program so-obtained is tested to find defective sets of components (see de scription, pars. 28-32, and fig. 3, nos. 315-335), and in the second one, in di vidual components from defec tive sets are replaced and tested (see description, par. 33, and fig. 4).

1.2 Claim 1 refers to the tested program as the "first pro gram code ... consisting of verified components", to the modified and erroneous program as the "second pro gram code ... having ... modified program compo nents" for which "a test ... failed", and as respective "third pro gram code" to the programs generated during the test procedure according to the invention. Claim 1 also spe cifies that the modi fied pro gram components of the se cond program code in divi du ally corres pond to the "veri fied components" of the first one.

Article 123 (2) EPC

2. Present claim 1 is based on claim 1 of the second auxili ary request as subject to the decision under appeal.

2.1 The decision (reasons 2.15) found this earlier claim to violate Article 123 (2) EPC because, as the board un derstands the argument, it mentioned the re place ment of individual components before the replace ment of sets of components and thus in the wrong and in an un dis closed order. Claim 1 now specifies steps (ii) and (iii) in the correct order, so that this deficiency is overcome.

2.2 The application as originally filed discloses that the "changed files are ... sorted into groups" or "sorted in to sets" (see par. 27) and does not literally talk about "grouping ... into sets" as does claim 1 in step (i). The application also discloses that the "sorting" could be "by any chosen criteria" such as "by the user or developer". In the board's view, the skilled person person would thus understand that the term "sorting" as used in the application is not meant to imply any order on program components, but that it is used instead to mean, more generally, "grouping". Accordingly, the board finds that the feature "grouping" is originally disclosed.

2.3 Beyond that, the board is satisfied that the wording of claim 1 finds disclosure in the application as origi nally filed, witness the passages of the application as cited above, and therefore conforms with Article 123 (2) EPC.

Article 84 EPC 1973

3. In the board's view, amended claim 1 is clear. In parti cu lar, the objection raised in the decision under appeal (reasons 2.16) that claim 1 of the then 2nd auxiliary re quest lacked clarity due to an expression lacking pro per antecedent in the claim is overcome by the amended wording.

Article 56 EPC 1973

4. The decision under appeal argues that the claimed inven tion is obvious over common knowledge in the art of tes ting, especially regression testing of pro grams (see reasons 2.2, 2nd par. for the then main and the 1st auxiliary request, and, obiter, reason 3.11 for the then 2nd auxiliary request). It is argued that the "process of elimination", understood as excluding possible causes of failure, is commonly used in the field of regression tes ting and implies that some indispensable components have to be replaced by "trusted" components. It is also argued that the process of replacing a tested com po nent by a "trus ted" one is common practice beyond the narrow context of software testing, as is illustra ted by way of an example outside of the software context. With regard to the then 2nd auxiliary request on which present claim 1 is based, the decision under appeal further argues that the "principle of divide and conquer" is common knowledge to a person skilled in the art of testing. The decision under appeal thus arrives at its conclusion that the claimed invention lacks an inventive step pure ly based on common knowledge in the art and without reference to any of the cited documents.

5. The board agrees with the suggestion in the de ci sion un der appeal that replacement of individual components is a commonly used strategy for locating the error in a mal functioning sys tem which used to work properly until a number of chan ges were ma de. For example, assume one were to modernise the wiring in a household and to re place several old (but working) components such as wire connec tions, safety fu ses, or switches, only to find the changed wiring not to work. It is, in the board's judg ment, a typical strategy to locate the cause for this error to selec tive ly "undo" the chan ges, in order to see whether the wiring would work if, for in stance, this old safety fuse were used instead of the new one.

5.1 The board is not convinced, however, that the claimed stra tegy, which the decision under appeal refers to as "divide and conquer", namely to determine defective sets of components before determining individual de fec tive components from defective sets of components, is a commonly known testing strategy. The board con si ders that it depends on the nature of the system being tested whether its components can be "grouped" in a mea ningful manner and in such a way that replacement of en tire groups of components is possible. The board also notes that the need to speed up the testing of a large number of modifications, and thus the need for grouping, may not arise in sys tems in which modifications are normally made one by one and tested imme diately, or in systems with a small complexity in which large numbers of modi fi cations do not arise at all. Therefore, the board considers that the assertion that "divide and conquer" is a well-known testing strategy cannot be made independent of the system being tested.

6. As for the context of software testing, the board agrees with the decision under appeal that the person skilled in the art of testing would not hesitate to apply the "replacement" strategy to the testing of software and that, therefore, re placing an in di vidual modi fied program component by an earlier, ve ri fied version to determine whether or not they are defec tive is obvi ous by direct analogy.

6.1 The board also agrees that "divide and conquer" is a well-established principle in computing, based on the idea of solving a hard problem by recursively breaking it into simpler subproblems and combining their solu tions into a solution of the entire problem.

6.2 However, while the board deems the "replacement" stra tegy to be obvious for the testing of software almost without any appre ciation of the nature and complexity of the soft ware being tested or of nature of the tests em ployed and the computational costs involved, it takes the position that the relevance of "divide and conquer" in this con text cannot be judged without an assessment of such as pects. The board also considers that such an assessment goes beyond general common knowledge the art of testing. The board therefore concludes that the mere exis tence of the well-established, but abstract, compu ta tio nal principle of "divide and conquer" is suffi cient to establish that the claimed method of error lo ca li sation in software is obvious over the common know ledge in the art of testing.

7. The decision under appeal further asserts that eli mi na tion is also commonly used in the field of regression testing. The appellant however does not accept this alle ga tion without any specific evidence (grounds of appeal, p. 1, 3rd par.). The board agrees with the appellant that the allegation can reasonably be challenged and must, therefore, if relied upon be substantiated by evi dence.

7.1.1 Neither D1 nor D2 provide such evidence. Although both D1 and D2 use the term "elimi na tion" (see D1, par. 4, and D2, 3rd par. from below), they do so merely to refer to the ge ne ral strategy of eli minating possible cau ses of an error in the process of locating the actual cause.

7.1.2 D1 talks about debugging in general terms. Inter alia, it discusses a game called Clue with the objec tive to de duce the sol u tion to a crime by a "process of elimi na tion" and it suggests that one "can do the same" in de bugging by "doing numerous, care fully-selected test runs, each of which changes only one fac tor" and by "dedu c[ing]", "[f]rom the differences in the results", "which module the error is in" and "which data structure is in volved" (par. [4]). What these factors are, how they are to be changed across test runs, and how test results are to be interpreted is left open.

7.1.3 D2 discusses a methodology of debugging (p. 408 ff.) in three stages, namely "recognizing and re pro du cing a problem", "identifying the source of the prob lem" and "fixing the problem". For recognizing prob lems, D2 dis closes the im por tance of testing (see p. 409, 2nd par.). For identi fy ing the source of an error, D2 tea ches to com pare what "the code should be doing against what it actually is do ing" and to use the "pro cess of eli mi na tion" to narrow down the possible sources (p. 410, lines 1-2 and 3rd par. from the bottom, line 1). The only specific illus tra tion for such elimination in D2 is based on program tracing (see e.g. the trace() state ments in the code on the top of p. 410), rather than on the modi fi cation of any "factors", let alone the replace ment of program com ponents.

7.1.4 Neither D1 nor D2 therefore provide evidence for the assertion that "elimination" is a commonly known tech nique in regression testing. Nor do they disclose or suggest the claimed im provement based on "divide and conquer". Hence D1 and D2 are also insufficient to establish that present claim 1 lacks an inventive step.

Summary

8. Present claim 1 was considerably amended over claim 1 of the 2nd auxiliary request as subject to the decision un der appeal and over comes the primary reasons for which the then second auxiliary re quest had been refused, namely those under Article 123 (2) EPC and Article 84 EPC 1973.

8.1 The board also considers that the objection under Article 56 EPC which the decision made obiter cannot be maintained because it relies on assertions about common knowledge which, in the board's judgment, either do not suffice to estab lish lack of inventive step of claim 1 insofar as they relate to the art of testing in general, or which must be substantiated with specific, typically written, evidence insofar as they relate to the specific field of software testing and debugging.

8.2 The board therefore decides to set aside the decision and exercises its discretion under Article 111 (1) EPC to remit the application to the department of first instance for further prosecution.

ORDER

For these reasons it is decided that:

1. The decision under appeal is set aside.

2. The case is remitted to the first instance for further prosecution based on the main request (claim 1 as filed during oral proceedings, further claims to be defined).