T 2048/07 (Dynamic data type enrichment/SAP) 24-11-2011

Reasons for the decision

1. Reference is made to the transitional provisions in Article 1 of the Decision of the Administrative Council of 28 June 2001 on the transitional provisions under Article 7 of the Act revising the European Patent Convention of 29 November 2000, for the amended and new provisions of the EPC, from which it may be derived which Articles of the EPC 1973 are still applicable to the present application and which Articles of the EPC 2000 shall apply.

2. Admissibility of the appeal

In view of the facts set out at points I and II above, the appeal is admissible, since it complies with the EPC formal admissibility requirements.

3. The claimed invention

Computer programs contain variables, such as "x", "y", "height" or "weight". In most programming languages, each variable is defined to have a certain "type", for example, "integer", "floating point", "character" or "boolean". Further, in some languages, variables may be defined with constraints specific to the program, or variables may be specified to be of a type which is in turn defined in the program to have specific constraints. Thus, to take a somewhat old-fashioned but clear example, in Pascal the programmer could write:

var x: 1..10;

to define a variable x of type integer constrained to belong to the "subrange" 1 to 10. Alternatively, one could write:

type capital = 'A'..'Z';

var letter: capital;

to define a variable "letter" of type character constrained to be an uppercase letter. The latter formulation might be used when several variables with the same constraints are to be defined. The constraints in the above examples are called "metadata", since they are data about the data which the variables "x" and "letter" can represent.

The application is concerned with such metadata, although it goes beyond constraints on variables to any data which may be associated with a class of variables within a program which may be defined as a "type" ("the corresponding metadata (150) includes data type details (151, 152, 153) including a text label, a range of allowed values, constraints or any other data that specifies the specific data type"). It advocates that, at least for some programs, when a type is defined in the program, such metadata should not be embedded as a constant in the program as in the examples above, but rather read into the program when it runs, as input. It further specifies that the mechanism for doing so be an "application programming interface" (API), i.e. a collection of standard "library" procedures.

This has some advantages: the metadata, e.g. range of permissible values, need not be decided when the body of the code is written; the same code may be used for situations where the metadata is different, but the functionality is the same, i.e. the code is more "reusable"; the metadata may even be changed while the program is running - cf. claim 11.

4. Amendments to the appellant's case, Rule 13 RPBA

The board agrees that the amended claims constitute a serious attempt to remedy the deficiencies that it had noted, without prima facie introducing new deficiencies or unjustifiably delaying the procedure. The request is, therefore, admitted into the appeal proceedings, Article 13(1) RPBA.

5. Amendments, Article 123(2) EPC

Claim 1

The present independent claim 1 is a combination of the original claims 1-3 and 5-7, with the following additional features, which are listed together with their basis in the original application documents:

- The method is computer-implemented This is disclosed on page 2, line 25 of the original description.

- The at least one variable is an 'integer', 'character', or 'string' This is disclosed on page 4, lines 13-14 of the original description.

- To specify the specific data type, the corresponding metadata includes data type details including a text label, a range of allowed values, constraints or any other data that specifies the specific data type This is disclosed on page 1, lines 12-16 of the original description.

- The data type details are exposed to the application program and its variable through the API in the form of the at least one metadata service This is disclosed on page 7, lines 13-17 of the original description.

The board concludes that the present claim 1 contains no added subject-matter (Article 123(2) EPC).

Claims 6, 7, 11

The present independent claims 6, 7 and 11 contain no added subject matter, for the same reasons as given for claim 1 above.

6. Exclusion from patentability, Article 52(2) and (3) EPC

It is open to debate whether some of the claims, in particular claim 6, are excluded from patentability by Article 52(2) and (3) EPC. The question is, however, irrelevant in view of 7 below.

7. Further technical effect

7.1 On page 10 of the statement of grounds of appeal (lines 10 to 13), the appellant identifies the effects achieved by the claimed invention thus: "System failures due to an otherwise non-matching data type requirement in the underlying system [are] avoided and thereby robustness, reuse and consistency of (mobile) application programs is improved". However, the board is not convinced, at least insofar as this suggests that the claimed invention makes the computer system more reliable, in the sense of avoiding program or system crashes. A properly written program expecting a ten-digit customer number will not crash if presented with a twenty-digit one, it will simply reject the input. Indeed, if anything, the proposed invention introduces new dangers of system failure. The problems involved in at first accepting an assignment to a variable of a value consisting of twenty digits, and later changing the definition of that variable to specify that it can only have values of ten digits length, are evident.

The Board accepts that reading certain data usually embedded in program source code from a file would make at least that part of the source code more reusable and the program more flexible and portable (as it was formulated in the appellant's submission of 13 April 2007, page 5, lines 5 and 6). However, this is simply an advice on how to write a program, and belongs to the fundamentals of that art. To take an example, if one wanted to write a program to calculate the trajectory of a projectile, one option would be to embed the value of g (acceleration due to gravity, on the earth's surface approximately 9.8 ms**(-2)) in the source, either as a number or as a defined constant. The program would, however, not work for trajectories on the moon; the system would "fail" if one tried to use it for such a calculation. To make the program cover all cases, the value of g could be made an input variable. It would simply be a programming option that would directly follow from the specification drawn up by a systems analyst: if the specification states that some data may change, the programmer will make it a variable.

7.2 The program, therefore, contains only features that are necessary to ensure its proper functioning, independent of any technical context in which it should be used. As a consequence, the program lacks a "further technical effect", i.e. an effect that goes beyond the normal technical effects that would be caused by any program within the computer system on which it runs (T 1173/97, OJ 1999, 609, Reasons 6).

7.3 During the oral proceedings, the representative reformulated the "reliability" argument as an increased availability of the system on which the program is running, since a change of the metadata could be effected without stopping the program. It was argued that this was the required "further technical effect". However, the board considers that this again is simply a matter of how a program is specified. A correct program is precisely as flexible as it is designed to be. The way in which a formal specification is implemented in a computer program is part of the art of computer programming, which by virtue of Art. 52(2)(c) and (3) EPC cannot of itself be adduced as an indication of "technical" activity (see G 3/08, OJ EPO 2011, 10, Reasons 13.5).

7.4 In the course of discussion, the representative was asked if, taking the example trajectory program, he would consider there to be the same "further technical effect" in a program which read in the value of "g" rather than having it embedded in the source code. He said that there would indeed be a technical difference between the programs. The board agrees that if the "increased availability" argument were accepted, this would be the consequence. But the implication of this would be that any program which read in any data at all would show a "further technical effect". The board can not accept this: reading in data is part of the fundamental definition of computing - input, process, output. Thus the board considers that reading in data does not go beyond the normal technical effects that would be caused by any program within the computer system on which it runs, i.e. that reading data is not a further technical effect in itself. Thus the "increased availability" argument, at least in the context of this particular claimed invention, equally fails.

7.5 The board notes that the claims concern themselves with "metadata", i.e. a particular subset of data in general. However, the arguments given above are not affected by what the nature of the data is, nor does "metadata" have any inherently technical nature, as might be argued in the case of data relating to some technical process.

8. Inventive step, Article 52(1) and 56 EPC 1973

Since the program causes no further technical effect, it also solves no technical problem with respect to the prior art of computers in general. As a result, claims 1, 6, 7 and 11 lack an inventive step, according to the established case law of the Boards of Appeal (see e.g. G 3/08 at 10.13).

9. Conclusion

For the reasons given in 8 above, the appellant's request is not allowable.