T 2049/12 (Data structure for defining transformations / MICROSOFT) 09-05-2019
Download und weitere Informationen:
DECLARATIONS FOR TRANSFORMATIONS WITHIN SERVICE SEQUENCES
Inventive step - computer program defining data transformations declaratively (no
Inventive step - not technical)
Summary of Facts and Submissions
I. This is an appeal against the decision of the examining division to refuse the European patent application No. 07750851.3 for lack of sufficiency of disclosure (Article 83 EPC).
II. In the notice of appeal, the appellant requested that the decision to refuse the application be set aside and that a patent be granted on the basis of the refused claims filed on 1 March 2012, of which claim 1 reads:
One or more computer-readable media having thereon a data structure (300), for defining transformations declaratively, the data structure including the following:
a plurality of service identification fields (311), each identifying a service (211, 212, 213, 214) in a sequence (210) of two or more services; and
a transformation class field (312A, 313A) specifying a class of transformation, including parameter mapping transformations or format conversion transformations, to be performed on either input data (221) prior to being provided to the sequence (210) of services, inter-service data provided between two services (211, 212, 213, 214) of the plurality of services in the sequence (210) of services, or output data (224) output from the sequence of services; and
one or more transformation parameter fields (312B, 313B) identifying one or more parameters of the class of transformation to thereby more specifically define the transformation, wherein the transformation is specified declaratively by using the transformation class field (312A, 313A) specifying the class of transformation to be performed, as well as the one or more transformation parameter fields (312B, 313B) that more specifically define the transformation.
III. The Board set out its preliminary view on the case in the communication accompanying the summons to oral proceedings. The Board tended to share the examining division's view on sufficiency of disclosure (Article 83 EPC). Additionally, the Board saw problems of lack of clarity and lack of support by the description (Article 84 EPC). The Board was moreover unable to identify a technical effect produced by the claimed invention that could support the presence of an inventive step (Article 56 EPC).
IV. In a reply, the appellant provided further arguments in support of its case.
V. Oral proceedings took place on 9 May 2019. The appellant maintained the requests made in the notice of appeal: that the decision under appeal be set aside and that a patent be granted on the basis of the refused claims dated 1 March 2012.
Reasons for the Decision
1. The invention
1.1 The invention relates to performing complex tasks that involve using a sequence of different services (see paragraphs [002] and [003] of the published application). The task might be to get a stock quote from all corporations in a given geographical area, which involves using a map service and a finance service [023].
The different services accept and output data in different formats and so the data must be transformed between services, as well as possibly at the end before presentation to a user [003].
The invention concerns the problem of avoiding the need for dedicated code for each transformation, which is time consuming and requires programming skills [004].
This is achieved by specifying the transformations "declaratively", i.e. in a high-level representation, by using a data structure (e.g. in XML form) that specifies the services, the class of transformation involved, and the parameters required for the transformations [027] to [032].
1.2 Claim 1 is directed to a computer readable medium containing such a data structure. The data structure comprises a plurality of service identification fields, a transformation class field, and one or more transformation parameter fields. The service identification fields specify the plurality of services to be performed in the sequence, and the transformation class field and the transformation parameter field(s) together specify the transformations to be performed on data to/from/between the services.
2. Sufficiency of disclosure (Article 83 EPC)
2.1 Claim 1 is manifestly broad. It defines neither the services, nor the transformations, in any real detail. The examining division saw this as a problem of insufficiency of disclosure (Article 83 EPC). The division's arguments were essentially that the small number of concrete examples disclosed in the application did not allow the skilled person to make use of the claimed data structure for defining transformations for any type of service and any type of data. In other words, the examining division was of the opinion that the application did not disclose the invention in a sufficiently clear and complete manner for it to be carried out over the whole scope of the claim.
2.2 In the Board's view, the question of whether or not the claimed invention is sufficiently disclosed certainly has merit. The question was discussed at length with the appellant during the oral proceedings. However, it was also possible to discuss the question of inventive step on the basis of the example disclosed in paragraph [029] of the published application. In the Board's view, this is an example that falls under the scope of claim 1 and that can be carried out.
3. Paragraph [029]
3.1 In the example in paragraph [029], the class of transformation is parameter mapping performed on data between services (inter-service data). A first service, such as the above mentioned map service, takes a first parameter name (e.g. "latitude" and longitude"), and a second service requires a second parameter name (e.g. "lat" and "long"). Thus, a mapping from the first parameter name to the second parameter name, i.e. from "latitude" to "lat" and from "longitude" to "long", takes place when data is provided from the first service to the second service. The parameter names in the example correspond to the parameters defined in the parameter fields in the data structure in claim 1.
4. Article 52(1), (2), and (3) EPC
4.1 The subject-matter of claim 1 is an invention within the meaning of Article 52(1) EPC, because it is directed to one or more computer readable media. A computer readable medium is a technical feature, which lends technical character to the claimed subject-matter as a whole (see T 258/03 - Auction method/HITACHI, and T 424/03 - Clipboard formats I/MICROSOFT).
5. Inventive step (Article 56 EPC)
5.1 In the oral proceedings, inventive step was discussed starting from the prior art described in the application, from paragraphs [001] to [004]. As mentioned above, it was known to provide multiple services in a sequence, and to transform data provided from one service to another. In the prior art, those transformations (i.e. from "latitude" to "lat" and from "longitude" to "long") were implemented using "specific dedicated code" for each of the transformation. The dedicated code was, of course, stored on some computer-readable medium.
5.2 The prior art and the invention achieve the same transformations. The difference lies in how those transformations are defined. In the prior art, they are defined in "dedicated code", whereas in the invention, they are defined in a data structure having service identification fields, a transformation class field and transformation parameter fields.
5.3 The appellant argued that the claimed data structure provided more flexibility in defining the transformations. Owing to defining the transformations "declaratively", it sufficed to change the declaration in the data structure in order to change them; it was not necessary to change the code that carried out the transformation. The increased flexibility was a technical effect that supported the presence of an inventive step.
5.4 The Board, however, is not persuaded that the claimed data structure has technical character.
The invention in claim 1 provides a different, and arguably more flexible, way of structuring a computer program. Computer programs as such are excluded matter under Article 52(2)(c) and (3) EPC. Therefore, pure software concepts are considered to lack technical character (see for example T 1755/10 - Software structure/TRILOGY). Indeed, the software concept in TRILOGY was the separation of rules from an "engine" (the code that implements those rules), which is similar to the data structure and the transformations in claim 1.
5.5 Furthermore, the activity of programming is also excluded under Article 52(2)(c) and (3) EPC, because it is a mental act (see: G3/08, Reasons, point 13; and T 1539/09, Reasons, point 4.2). The choice of program structure, including the choice of data structures, belongs to the activity of programming. Well structured code helps the programmer in performing this activity, because the code is easier to understand, maintain, and adjust, but, since programming is not technical, this is not a technical effect.
5.6 The appellant furthermore argued that, when assessing a data structure according to established case law (see for example T 1194/97 - Data structure product/PHILIPS), a distinction had to be made between cognitive data and functional data. While cognitive data was non-technical, functional data had technical character. The claimed data structure was clearly functional data, and, therefore, it was technical.
5.7 The Board is not persuaded. The PHILIPS decision indeed makes a distinction between cognitive information content and functional data inherently comprising features of the technical system in which it is operative. However, in order to understand the distinction, one needs to look at the whole case.
The invention in PHILIPS concerned a picture data structure recorded on a record carrier. The data structure comprised information specifying where a relevant coded picture line had been recorded on the track, thereby facilitating access by a reader to the relevant picture content. The Board distinguished between the content of the picture, and the data structure, which had a technical function (facilitating access) in a technical system (reader plus record carrier). In other words, the data structure in PHILIPS mapped to technical features in a technical system.
In the present case, however, the data structure does not map to a technical system; it maps to a computer program, which is excluded matter under Article 52(2)(c) and (3) EPC.
5.8 A common misconception regarding the PHILPS decision is that there are only two kinds of data - cognitive and functional - and that functional (i.e. non-cognitive) data is always technical. The relevant question for assessing whether a data structure has technical character is rather whether it produces a technical effect. In the present case, the Board considers that there is no technical effect. Therefore, the claimed data structure does not provide an inventive step (Article 56 EPC).
5.9 In conclusion, the Board judges that the subject-matter of claim 1 lacks an inventive step (Article 56 EPC).
Order
For these reasons it is decided that:
The appeal is dismissed.