T 1171/06 – More On Models

This decision deals with an appeal against the decision of the Examining Division (ED) to refuse an application belonging to the modelling realm. 

Claims 1 and 3 of the main request before the Board read: 

1. Method for modelling a mechatronic system in a motor vehicle, wherein the mechatronic system is structured in a plurality of components between which there are pregiven communication relationships, such as inquiry, invitation and order; wherein a mapping requirement is provided by means of which said components and communication relationships of the system are converted into elements of an object-oriented modelling language, preferentially the UML language; characterised in that said components are divided into an envelope and at least one subcomponent, wherein said subcomponent comprises the existing functions of the component and said envelope comprises at least one interface for said communication relationships, wherein said envelope is devised as a UML stereotype. 

3. Device for modelling a mechatronic system in a motor vehicle, wherein the mechatronic system is structured in a plurality of components between which there are pregiven communication relationships, such as inquiry, invitation and order; wherein a mapping requirement is provided by means of which said components and communication relationships of the system are converted into elements of an object-oriented modelling language, preferentially the UML language; characterised in that said components are divided into an envelope and at least one subcomponent, wherein said subcomponent comprises the existing functions of the component and said envelope comprises at least one interface for said communication relationships, wherein said envelope is devised as a UML stereotype. 

 Here is what the Board had to say: 

** Translated from the German **

[2] The invention concerns the modelling of a mechatronic system in a motor vehicle wherein the structuring of the system in components and communication relationships is converted into an object-oriented modelling language by means of a mapping requirement. 

[2.1] The independent claims of [the requests on file] state that the object-oriented modelling language is preferentially the UML language, but they also state that it has to comprise a “UML stereotype”. The Board is of the opinion that thereby the claim determines that UML is the object-oriented modelling language as claimed. The Board notes that, as far as the following discussion is concerned, this interpretation is in favour of the appellant. 

[2.2] According to the preamble, the independent claims are directed to a method or a device “for modelling a mechatronic system”. The analysis of the object to be modelled, in order to choose the relevant elements, attributes and relationships, is an essential part of a modelling method. This step – in the present case, e.g. the specification of vehicle electronics by means of Cartronic – is not comprised by the subject-matter of claim 1 but precedes it and is presupposed by it […]. Thus the subject-matter of claim 1 is not a complete modelling method but at best part of it. Therefore, the Board interprets claim 1 to refer to a “method (suitable) for (use during the) modelling a mechatronic system”. The same holds true for claim 3. 

[2.3] Neither the mechatronic system as such nor its components are specified in more detail in the claims. When dealing with the communication relationships, claim 1 distinguishes, for example, between “inquiry” (Abfrage), “invitation” (Aufforderung) and “order” (Auftrag). The term “invitation” (Aufforderung) appears to be a clerical error “request” and has been corrected to read “request” (Anforderung) in the auxiliary request. 

[2.4] The Board is of the opinion that the wording of claim 1 does not make it clear whether the claimed structuring is a factual limitation of the system to be modelled (that is to say, to a system having the required components and communication relationships) of whether it designates a model that describes the mechatronic system via the required components and communication relationships. However, as the constructs of a modelling language, to which said components and relationships are to be converted by means of the “mapping requirement”, constitute a description of the mechatronic system, it appears to be more straightforward to assume that a description is at the basis of this mapping.

This interpretation is confirmed by the application, wherein Cartronic is referred to as “ordering concept” allowing for, inter alia, the claimed types of communication […] and by which models – i.e. descriptions – of mechatronic systems are established […]. 

[2.5] It is the intention of the invention to relate to methods and a device for mapping a Cartronic model into the object-oriented modelling language UML […]. 

The appellant has not contested this interpretation expressed in the notification by the Board. Consequently, what follows is based on this interpretation. Questions related to the clarity of terminology that is proper to Cartronic or UML (such as “inquiry”, “request”, “order”, “UML-language”, “UML stereotype”) or the concrete identifiers («interface» and «interfaceorder») and their precise signification can be left open in this decision. 

[3] In decision T 354/07 the competent Board has explained (cf. its headnote) that 

“as a rule, […] conceptual methods and meta-methods of software creation do not possess technical features relevant for patentability and, therefore, cannot establish inventive step, unless in a particular case it can be shown that there is a direct causal connection with a technical effect that is relevant for the solution of a technical problem.” 

Moreover, it has been said (cf. point [4] of the reasons) that 

“the design […] of complex systems [required the person carrying out this work] to act like an engineer and to apply technical expertise but [that] the achievement aimed at and obtained […] does not consist in providing a technical solution to a technical problem, but [for example] a model for data, processes and/or functions […].”

[3.1] Claim 1 discussed in T 354/07 is directed to a method for generating of software programs (31) using an electronic data processing system” wherein the software program has to carry out, inter alia, “controlling and/or regulation tasks” and wherein a “second function chart is established by means of a platform-independent first function chart (7)”, “the second function chart being adapted to specific requirements of [a] target platform.” Function charts within the meaning of the applications are “graphical representations of a model of the control system to be established, on different levels of abstraction, without there being an interaction with the system or the control procedures” (see point [7] of the reasons). 

[3.2] This subject-matter is very close to the subject-matter of the method claimed in the present case. Both methods concern the modelling of comparable technical systems. Both methods refer to two models or their representations, respectively, in a notation that is typically graphical, as well as to the mapping of one of those models into another. 

[4] In what follows, the Board endorses the explanations of decision T 354/07 cited above (point [3]). 

[4.1] Therefore, it is to be examined whether it is possible, for the method of claim 1 of both requests, to establish a causal link with a technical effect that is relevant for the solution of a technical problem. 

[4.2] The present application does not refer to the object to be modelled as an unspecific controlling or regulation system only but also – more narrowly - as a “mechatronic system in a motor vehicle”. However, even this indication is very generic and does not allow to deduce a concrete modelling task of a technical problem that has been considered in this context. 

[4.3] In contrast to the situation in T 354/07, there is no disclosure in the present application of an automatic (“using an electronic data processing system”) conversion of the models. Claims 1 and 2 of both requests do not refer to any computer assistance. Claim 1 is directed to a “device” but it remains open which method steps are assisted by the device, and how. 

[4.4] Again in contrast to the object of T 354/07, the present application does not deal with the automatic generation of program code from a model, as the representative appears to have confirmed during the oral proceedings (OPs) […]. Indeed, neither Cartronic (referred to as “preformal” in the description […]) nor UML are suitable for easily generating program code in an automatic way. 

[4.5] The application refers to the life cycle of software, which comprises very different phases such as problem analysis, systems specification, but also implementation, operation and maintenance. In this context, so goes the disclosure, the object-oriented procedure makes it possible to re-use “components and concepts” in a phase overlapping manner […]. When doing so, the graphic-based models, serving as documentation elements, support, inter alia, the communication between the groups of persons who participate in the development, among which vehicle manufacturers or software developers. However, the Board is of the opinion that a model is not imparted a technical effect because it serves the documentation of the system or because it simplifies communication, even if the system as such is technical. 

[4.6] There are a number of commercial software development tools available for UML, and it is one of the declared objectives of the application to make those tools available for models specified in Cartronic […]. However, those tools are neither claimed nor disclosed in detail. It may, therefore, be left open whether a technical effect is generated by the intended application of such a known tool to a Cartronic model converted to UML. 

[4.7] Therefore, the Board is unable to find a technical effect which is relevant for the solution of a technical problem and which has a causal connection with one of the claimed methods. The appellant has not named any such technical effect in order to overcome this objection raised in the summons to the OPs, either. 

[4.8] As a consequence, the Board comes to the conclusion that the subject-matter of claims 1 and 2 of both requests is not technical but corresponds to a method for a conceptual or mental activity and, as such, is excluded from patentability under A 52(2)(c) and (3). 

[4.9] In conformity with the established case law (see e.g. T 258/03), claim 3 of both requests, which is directed to a device, is considered to be an invention within the meaning of A 52(1). However, the mere unspecific indication of a “device for” assisting a non-technical method does not make any perceptible technical contribution beyond any commercially available PC known at the priority date. Therefore, the subject-matter of claim 3 lacks an inventive step under A 56. 

[5] As none of the requests complies with the requirements of the EPC, the appeal is to be dismissed. 

Should you wish to download the whole document (in German), just click here. 

To have a look at the file wrapper, click here. 

For a translation of the relevant parts of T 354/07, see my previous post dedicated to this decision.