T 2158/12 (Computer-based testing/PROMETRIC) of 11.4.2018

Summary of Facts and Submissions

I. The appeal is against the decision by the examining division, dispatched with reasons on 4 May 2012, to refuse European patent application 02803206.8, on the basis that neither request satisfied the requirements of Article 56 EPC 1973.

II. No documents were cited during the first instance procedure. The following document cited in the search report was mentioned in the application; during the oral proceedings before the board, the appellant considered it to represent the closest prior art:

D1: US 5 513 994 A

III. A notice of appeal was received on 4 July 2012, the appeal fee being paid on the same day. A statement of grounds of appeal was received on 4 September 2012.

IV. The appellant requested that the decision under appeal be set aside and a patent granted on the basis of the main or auxiliary request that were the object of the refusal. The appellant made a conditional request for oral proceedings. The appellant further requested reimbursement of the appeal fee.

V. The board issued a summons to oral proceedings. In an annex to the summons, the board set out its preliminary opinion on the appeal.

VI. On 12 March 2018, the appellant filed two new auxiliary requests, replacing the previous single auxiliary request.

VII. During the oral proceedings before the board, the appellant orally formulated a new auxiliary request 1, as being based on claims 39-70 of the main request, former auxiliary requests 1 and 2 then becoming auxiliary requests 2 and 3.

VIII. The appellant requests that the decision under appeal be set aside and that a patent be granted on the basis of the main request, dated 19 October 2009, or on the basis of claims 39-70 of that request, or on the basis of the request of 12 March 2018, labelled auxiliary request 1, or on the basis of the request of 12 March 2018, labelled auxiliary request 2.

IX. Independent claim 1 of the main request reads as follows:

"A system for computer-based testing for at least one test, the at least one test having a presentation format and data content, comprising:

a test driver, having an executable code that controls functionality that enables the test driver to deliver the at least one test to an examinee using a display device, manage the at least one test, control progression of the at least one test, control scoring of the at least one test, and control results reporting of the at least one test;

a resource file, in operative data communication with the test driver, that stores information relating to the data content, the presentation format, progression, scoring, and results reporting of the at least one test, the information being accessible to the test driver to enable the functionality of the test driver; and

an expansion module, in operative data communication with the test driver and the resource file, that retrieves the information relating to at least one of the data content, the presentation format, the progression, the scoring, and the results reporting of the at least one test from the resource file and provides the information to the test driver during delivery of the at least one test, the expansion module expanding the functionality of the test driver without necessitating modification to the executable code of the test driver."

X. Independent claim 39 of the main request reads as follows:

"A method for computer-based testing for at least one test, the at least one test having a presentation format and data content, the at least one test being controlled by a test driver, the test driver having an executable code that controls functionality that enables the test driver to deliver the at least one test to an examinee using a display device, manage the at least one test, control progression of the at least one test, control scoring of the at least one test, and control results reporting of the at least one test, the method comprising the steps of:

instantiating an expansion module;

providing to the expansion module a resource storage element within a resource file;

loading information from the resource storage element into the expansion module during delivery of the at least one test, wherein the information from the resource storage element relates to at least one of the data content, the presentation format, progression, scoring, and results reporting of the at least one test; and

providing the information from the expansion module to the test driver during the delivery of the at least one test such that the expansion module expands the functionality of the test driver without necessitating programming changes to the executable code of the test driver."

XI. Compared to claim 1 of the main request, independent claim 1 of the claim set labelled "Auxiliary Request 1" contains the following additional features at the end:

" a source file, in operative data communication with the expansion module, that stores the information relating to the data content, the presentation format, the progression, the scoring, and the results reporting of the at least one test; and

a test packager, in operative data communication with the source file and the expansion module, that passes the information from the source file to the expansion module such that the expansion module is capable of validating the information from the source file,

wherein a test packager, in operative data communication with the source file, retrieving the information from the source file; and a resource file, in operative data communication with the test packager, storing the information retrieved by the test packager [sic]"

XII. Compared to claim 1 of the main request, independent claim 1 of the claim set labelled "Auxiliary Request 2" contains the following additional features at the end:

"a source file, in operative data communication with the expansion module, that stores the information relating to the data content, the presentation format, the progression, the scoring, and the results reporting of the at least one test;

a test packager, in operative data communication with the source file and the expansion module, that passes the information from the source file to the expansion module such that the expansion module is capable of validating the information from the source file, wherein the test packager, in operative data communication with the source file, retrieving the information from the source file; and the resource file, in operative data communication with the test packager, storing the information retrieved by the test packager, wherein the expansion module, in operative data communication with the test packager and the test driver, receiving the information stored in the source file from the test packager, validating the information received from the test package, storing the information to the resource file, retrieving the information from the resource file, and providing the information to the test driver during delivery of the at least one test, the expansion module expanding the functionality of the test driver without necessitating modification to the executable code of the test driver;

a function interface that enables communication between the test packager and the expansion module, wherein the function interface enables the test packager to notify the expansion module that the source file is present, that the information in the source file is to be validated, and to pass the information from the source file to the expansion module such that the expansion module is capable of validating the information from the source file, the information further comprising at least one of non-interactive display material, test navigation, test navigation controls, items, timing, selection, scoring, results, and reporting; and

an instance file, in operative data communication with the test driver and the expansion module, comprising examination state information, which includes responses provided by the examinee to items presented to the examinee during the at least one test; and

wherein the function interface enables communication between the test driver and the expansion module and between the test packager and the expansion module, wherein:

the function interface enables the test driver to load core object references into the expansion module at a start of a test delivery cycle and to unload the core object references from the expansion module at a completion of the test delivery cycle; and

the function interface enables the test packager to notify the expansion module that the source file is present, that the information in the source file is to be validated, and to pass the information from the source file to the expansion module such that the expansion module is capable of validating the information from the source file, the information further comprising at least one of non-interactive display material, test navigation, test navigation controls, items, timing, selection, scoring, results, and reporting"

XIII. At the end of the oral proceedings, the chairman announced the board's decision.

Reasons for the Decision

1. The admissibility of the appeal

The appeal is admissible.

2. The invention

The invention lies in the area of computer-based testing of human examinees. In the prior art, any changes in the test would require a recompilation of the complete program. To avoid this, the invention proposes a system which comprises a test driver, a resource file storing the test parameters for use by the test driver, and an expansion module retrieving the necessary information from the resource file. Changes of the test parameters in the resource file will then not require a recompilation of the complete program.

3. Inventive step (Article 56 EPC 1973) - main request

3.1 The board agrees with the appellant's point of view expressed during the oral proceedings that D1 represents a suitable starting point for the analysis of inventive step. This document illustrates the fact that centralised systems for administering computer based tests were known before the priority date (see D1, abstract).

3.2 According to the appellant, in the system of D1 all information which defines the test, i.e. the data content, presentation format, progression, scoring, and results reporting, is part of the program code. For that reason, any changes in the test require a recompilation of the complete program, in contrast to the system of claim 1 of the main request.

Following this, the problem to be solved should be seen as how to obtain a resource-saving flexible possibility for changing the test conditions.

3.3 The board holds that the skilled person would want to solve this problem and that a common way to achieve this is by introducing modularity in the software design. Modularity as a software design principle was well known before the priority date, including its advantage that changes in one module only require a recompilation of that one module. None of the features of claim 1 go beyond a straightforward implementation of this principle by the person skilled in the field of automation:

3.3.1 Part of the program, which may be called a "test driver", should have executable code for delivering the test to an examinee using, as a rule, a display device. This part should manage the test, controlling its progression, scoring, and results reporting.

3.3.2 Following the principle of modularity, the elements of the program which may change should be kept separate, e.g. in a "resource file", in "operative data communication" with the test driver. The changeable elements would comprise information relating to the data content, the presentation format, progression, scoring, and results reporting of the test. The information should be accessible to the test driver to enable its functionality.

3.3.3 The program should contain a module, which may be called an "expansion module", in "operative data communication" with the test driver and the resource file, that retrieves said information from the resource file and provides it to the test driver during delivery of the test. It can then be said that the expansion module expands the functionality of the test driver without necessitating modification to its executable code.

3.4 The skilled person would thus arrive at the subject-matter of claim 1 of the main request without demonstrating the presence of an inventive step.

3.5 The method features of claim 39 correspond exactly to the system features of claim 1, the temporal order in which they should appear also being already implicit in claim 1. The inventive step reasoning for claim 1 therefore also applies to claim 39.

3.6 The main request therefore does not satisfy the requirement of Article 56 EPC 1973.

4. Auxiliary requests

4.1 The independent claim of the first auxiliary request is claim 39 of the main request. The first auxiliary request therefore does not satisfy the requirement of Article 56 EPC 1973 for the reasons given under 3.5 above.

4.2 Regarding claim 1 of the claim set labelled "Auxiliary Request 1", i.e. the present auxiliary request 2, the only function of the test packager which is apparent from the claim is that it passes the information from the source file to the expansion module. The expression "such that the expansion module is capable of validating" imposes no limitation on the test packager.

The use of a "source file" (e.g. using an XML-based format, as mentioned in the description on page 9, line 18) in which data is entered in a readable format, later to be compiled (description page 10, lines 35 seq.) or simply transferred to a "resource file" is considered common practice.

Although the claim language does not include validation but only states that "the expansion module is capable of validating", the board notes that the act of validating the information in the source file, e.g. for syntax errors, before it finds its way in the resource file would also be considered commonplace.

The second auxiliary request therefore also does not satisfy the requirement of Article 56 EPC 1973.

4.3 Claim 1 of the claim set labelled "Auxiliary Request 2", i.e. the present auxiliary request 3, contains a large number of implementation details of the testing system. The appellant has, during the oral proceedings, not refined his inventive step argument in view of any of the new features and not challenged the board's opinion that the new features are straightforward to the skilled person. As a consequence, he failed to indicate why any of these implementation features go beyond a straightforward application of the modularity principle. The third auxiliary request is therefore also considered not to satisfy the requirement of Article 56 EPC 1973.

5. Request for reimbursement of the appeal fee

Given that none of the requests is allowable, the appeal fee cannot be reimbursed (Rule 103(1)(a) EPC).

Order

For these reasons it is decided that:

1. The appeal is dismissed.

2. The request for reimbursement of the appeal fee is refused.