- A claim for making, on a computer, a model of multi-processor system, and simulating the model, was found to lack inventive step.
- " The major part of claim 1 is thus concerned with the expressions of a graphical programming environment which were found in T 1539/09 (reasons 5) not to contribute to inventive step (see also T 2270/10, reasons 7), even if, as the appellant argues, it "enables users to" develop the program in question "in a convenient and efficient way" [] and simplifies the modelling or the model ..." .
- "The board follows its earlier jurisprudence according to which modifications to a programming language or system that enable the programmer to develop a program with greater ease and thus, presumably, speed and accuracy, do not make a technical contribution to the art."
III. Claim 1 reads as follows:
"A method for simulating a multi-processor system in an electronic device that provides a graphical modeling environment using a deployment model and a functional model for the multi-processor system, the method comprising:
providing a functional model of a multi-processor system in the graphical modeling environment, the functional model including one ore more functional units;
creating a deployment model for the functional model in the graphical modeling environment, the deployment model comprising one or more processing units represented by node blocks interconnected via an inter process communication (IPC) channel, wherein:
the IPC channel comprises a shared memory, a bus or a broadcast medium, that exchanges data between one or more processing units represented by the node blocks, and
the node blocks include:
a write block that writes data to the IPC channel, and sends data to the one or more processing units, and
a read block that reads data from the IPC channel, and makes data available to the node blocks;
representing characteristics of the IPC channel with a model for the IPC channel, the model for the IPC channel including an IPC channel input port block, an IPC model and an IPC channel output port block;
mapping the one or more functional units of the functional model to the one or more processing units of the deployment model; and
simulating the deployment model in the graphical modeling environment."
Reasons for the Decision
The invention
1. In general, the application relates to modelling and simulating a multiprocessor system in a graphical programming environment (page 1, lines 10-12).
1.1 For the modelling step, the user has to specify a "functional model" (herein: FM) and a "deployment model" (herein: DM). The FM [] provides a "functional view of the model", whereas the DM [] provides an "architectural [...] view of the model" and represents the processing units and the inter-process communication (IPC) channels []. A process referred to as "system integrator" maps the functional units to the processing units of the DM []. In doing this, it relies on additional mapping information given by the user, such as processing characteristics of the available processing units and the protocols used by the IPC channels [].
1.2 The deployment model can be executed "in simulation mode" or deployed on a real-time system []. To make this possible, the deployment model may have to be compiled [] and linked []1) and then executed, or it may be executed in "interpretive mode" ([].
1.3 The functional and deployment models are programs written in a graphical programming language. Hence, modelling and simulation are tantamount to programming - i.e. developing a graphical computer program - and program execution. The description discloses that modelling and simulating are used synonymously with programming and execution, respectively (see page 5, last paragraph).
Inventive step, Article 56 EPC 1973
6. There is broad agreement in the jurisprudence of the boards of appeal that neither modelling nor programming is, by itself, a technical undertaking (with regard to modelling see in particular the catchwords of T 49/99, T 354/07, T 1171/06 and T 42/09, point 2.4 of the reasons; with regard to programming see for instance the catchword of T 1539/09 and T 2270/10, point 7 of the reasons).
7. As regards simulation, the board notes that in T 1227/05 a particular numeric simulation method was found to make a technical contribution to the art. Specifically, it was found that "Simulation of a circuit subject to 1/f noise constitutes an adequately defined technical purpose for a computer-implemented method functionally limited to that purpose" (see catchword and point 3.1 of the reasons). In T 1227/05, the deciding board argued that the claimed simulation made it possible to reliably predict how a designed circuit would behave in reality and thus to assess whether manufacturing the circuit would be worthwhile (see T 1227/05, point 3.2.2 of the reasons). As a consequence, all mathematical steps in the claimed method were found to contribute to inventive step (see esp. point 3.2.4 of the reasons).
7.1 It may be questioned whether, for a computer-simulated simulation method to make a technical contribution to the art, it is sufficient that the technical purpose be "adequately defined" and the claim limited to that purpose, as T 1227/05 appears to suggest. Similar doubts were expressed in T 1265/09 (point 1.13 of the reasons, penultimate paragraph) and T 531/09 (point 3 of the reasons).
7.2 In the present case, however, this question may be left open because the board considers that the technical purpose of the claimed simulation is not adequately defined. Present claim 1 is concerned with simulation only insofar as it specifies the execution of a multi-processor specification developed as a graphical program. The claim is not concerned with the "simulation" of any specific such processor, nor any specific class of processors. Rather than the device being modelled and simulated, the claim indicates the programming means with which the model can be specified, namely "functional units", "processing units", "IPC channels", "read/write blocks" and "input/output blocks".
8. The major part of claim 1 is thus concerned with the expressions of a graphical programming environment which were found in T 1539/09 (reasons 5) not to contribute to inventive step (see also T 2270/10, reasons 7), even if, as the appellant argues, it "enables users to" develop the program in question "in a convenient and efficient way" (see the grounds of appeal, page 2, paragraph 3) and simplifies the modelling or the model by "enabl[ing] the user to separate the algorithmic model from the final deployment hardware" (see the grounds of appeal, page 2, paragraph 4).
9. The board also considers that the appellant's arguments in favour of technical character fail.
9.1 The appellant argues that "associating a simulation model with [an] IPC channel" is a technical effect (grounds of appeal, page 2, paragraph 5). However, the features of the deployment model are not technical merely due to the fact that they represent technical items, because they are still part of the model. This applies in particular to the IPC channel (see point 5 above).
9.2 The appellant also argues that the invention enables users "to efficiently model and simulate a multi-processor system", in particular a "hierarchical one" (grounds of appeal, page 3, paragraphs 1-2). However, the board follows its earlier jurisprudence according to which modifications to a programming language or system that enable the programmer to develop a program with greater ease and thus, presumably, speed and accuracy, do not make a technical contribution to the art.
9.3 Lastly, the appellant suggests that the invention provides "the further technical effect of a faster simulation" (grounds of appeal, page 3, paragraph 3). If "faster simulation" refers to the "faster development" of the model/program that is being simulated/executed, the previous remark applies. If it refers to the execution of the model being faster, the board considers that there is no basis for this effect in the application to hand.
10. In summary, the board shares the examining division's opinion that the claimed invention does not make a technical contribution to the art, and thus lacks inventive step, Article 56 EPC 1973.
Inventive step vis-à-vis D1
11. The appellant did not challenge the comparison of earlier claim 1 with D1 given in the decision under appeal (see point 1.1 of the reasons), and the board also agrees with this assessment.
11.1 Accordingly, the claimed invention differs from D1 by
(a) the fact that in D1 two tools are used for modelling and simulation whereas the claimed invention uses the same environment for both, and
(b) the particular, and newly defined, blocks used to specify IPC channels in the deployment model.
11.2 As regards difference (a), the board agrees with the examining division that the integration of two tools is, in principle, an obvious means for the skilled person, to get rid for instance of undesirable overhead communication between both.
11.3 As regards difference (b), the specifically claimed blocks are expressions of the graphical programming language in question which, as argued above, do not have any technical effect and thus do not contribute to inventive step (see T 1539/09).
Order
For these reasons it is decided that:
The appeal is dismissed.
No comments:
Post a Comment
Do not use hyperlinks in comment text or user name. Comments are welcome, even though they are strictly moderated (no politics). Moderation can take some time.