The applicant filed an appeal against the decision of the Examining Divison to refuse his application.
Claim 1 of the final request before the Board read:
A computer-implemented method (400) for dynamic data type enrichment comprising the steps:
- accessing (415), through an application programming interface, API, (190) by an application program (210), metadata (150), wherein the application program (210) uses at least one variable (201) being an ‘integer’, ‘character’, or ‘string’ and wherein the application program (210) calls through the application programming interface(190) at least one metadata service (191, 192, 193) that relates to the corresponding variable (201); and
- enriching the corresponding variable (201) with metadata (150) at runtime when the application program (210) is executed, wherein the metadata (150) is associated with a specific data type (120) defined in a metadata store (220) and the application program (210) provides a mapping (302) between the specific data type (120) and the corresponding variable (201), wherein to specify the specific data type (120), 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 and wherein the data type details (151, 152, 153) are exposed to the application program (210) and its variable (201) through the API (190) in the form of the at least one metadata service (191, 192, 193).
The Board came to the conclusion that this claim lacked inventive step :
Further technical effect
[7.1] [… In] the statement of grounds of appeal […], 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 […]. 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 [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 A 52(2)(c) and (3) cannot of itself be adduced as an indication of “technical” activity (see G 3/08 [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.
Inventive step, A 52(1) and A 56 EPC 1973
[8] 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 [10.13]). […]
The appeal is dismissed.
Should you wish to download the whole decision, click here.
The file wrapper can be found here.
3 comments:
A discussion on novelty would have been interesting. Can features that have no technical character convey novelty?
That is an interesting question. I remember having heated discussions on that topic with colleagues when preparing the EQE. I have come to the conclusion that non-technical differences cannot confer novelty. There is also case law that supports this view:
“…The Board therefore concludes that these features do not produce a technical effect of any kind. It follows that they are not “technical features” in the meaning of R 29(1) EPC [1973] and, consequently, that they cannot serve to distinguish the invention from the prior art.” (T 619/98 [4.8]).
I think the problem is that non-technical features often imply (completely obvious) technical features.
If an application claims a sheet of paper on which a new poem is printed, then clearly the new poem is a non-technical feature that cannot contribute to inventive step.
However, the physical sheet of paper including the ink patterns printed on it differs from any physical sheet of paper from the prior art in the particular ink patterns. Those ink patterns are not inventive, but they do represent a physical difference.
Post a Comment