T 1630/11 (Modelling a multiprocessor system/THE MATHWORKS) 13-01-2017
Download und weitere Informationen:
MODELING OF A MULTIPROCESSOR SYSTEM
Technical purpose of simulation adequately defined - (no)
Inventive step - (no)
Summary of Facts and Submissions
I. The appeal lies against the decision of the examining division, with reasons dispatched on 11 February 2011, to refuse European patent application No. 06 771 710.8 for lack of inventive step over
D1: Redell O. et al., "The AIDA toolset for design and implementation analysis of distributed real-time control systems", Microprocessors and Microsystems, IPC Business Press Ltd., vol. 28, no. 4, 20 May 2004, pages 163-182.
II. Notice of appeal was filed on 11 April 2011, the appeal fee being paid on the same day. A statement of grounds of appeal was received on 9 June 2011. The board understands the appellant's requests to be that the decision be set aside and that a patent be granted on the basis of claims 1-31 as filed with the grounds of appeal, the other documents on file being drawing sheets 1/14-14/14 and description pages 3-10 and 12-26 as originally filed, and description pages 1, 2, 2a, 11 as filed upon entry into the regional phase.
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."
The set of claims also comprises an independent system claim 9 which largely corresponds to method claim 1.
IV. In an annex to a summons to oral proceedings, the board informed the appellant of its preliminary opinion that the subject-matter of claim 1 lacked inventive step, Article 56 EPC 1973. Objections under Article 123(2) EPC and 84 EPC 1973 were also raised. Even though the appellant had not requested oral proceedings, the board deemed it expedient to give the appellant the opportunity to comment orally on the board's position.
V. In response to the summons, the appellant did not submit arguments or amendments. Instead, with a letter dated 7 December 2016, it informed the board that it did not intend to attend the scheduled oral proceedings, and requested a decision on the file as it stood.
VI. With letter dated 12 January 2017, the oral proceedings were then cancelled. The following reasons are based on the board's preliminary opinion as communicated to the appellant.
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 (see figure 2A, no. 220; figure 2B, no. 280; figure 3A) provides a "functional view of the model", whereas the DM (figure 2A, no. 230; figure 2B, no. 282; figure 4A) provides an "architectural [...] view of the model" and represents the processing units and the inter-process communication (IPC) channels (see page 7, paragraph 3, and e.g. page 14, paragraph 2, to page 15, paragraph 2; see also e.g. figures 4A and 6A). A process referred to as "system integrator" maps the functional units to the processing units of the DM (see page 12, paragraph 3, figures 3B and 3D). 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 (see page 12, paragraph 3, to page 13, paragraph 1).
1.2 The deployment model can be executed "in simulation mode" or deployed on a real-time system (see page 19, paragraph 2). To make this possible, the deployment model may have to be compiled (page 19, paragraph 3) and linked (page 20, paragraph 1) and then executed, or it may be executed in "interpretive mode" (see paragraph bridging pages 21 and 22).
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).
The prior art
2. D1 discloses a toolset for the "design" and "implementation analysis" of distributed control systems. Modelling comprises inter alia the generation of two diagrams - a data-flow diagram and a hardware structure diagram (see sections 2.2.1 and 2.2.3, and figure 3) - where the data-flow diagram defines the data flow between functional blocks and the hardware diagram refers to processing units and to IPCs (see figure 6 and section 2.2.6). In D1, modelling and simulation are supported by two separate systems, DoMe and Simulink (see sections 3-3.2 and figure 11; 3.2). In particular, the model is developed in DoMe and run, i.e. simulated, in Simulink (loc. cit.; esp. page 171, right column, first full sentence).
The decision under appeal
3. The examining division found that the only difference between D1 and the subject-matter of then claim 1 of the main request was that the invention executed the deployment model in the graphical modelling environment, whereas according to D1 the simulation was carried out by a separate tool.
3.1 The examining division took the position that this was an obvious means for simplification of D1 and thus not inventive over D1 (see decision, reasons 1.1, esp. page 4, last 3 paragraphs, to page 5, paragraph 2).
3.2 Moreover, the examining division stated that it considered "modelling as such as belonging to a non-technical branch of knowledge" and hence doubted that the claimed matter had a technical effect (see the decision, reasons 2.5).
Claim construction
4. Claim 1 specifies that the multi-processor system being modelled comprises an "IPC channel" connecting the processing units (see lines 9-11). It is also claimed that the processing units and the IPC channel are represented in the deployment model, by "node blocks" and an interconnection between them (lines 6-13). It is worth stressing that the hardware components of the modelled system are not, as such, part of the model. In the board's view, the skilled person would be able to make the distinction between the system being modelled and its representation in the model, even if in the claim the term "IPC channel" is used for both.
Technical character, Article 52(2) and (3) EPC
5. Claims 1 and 9 concern a "method" and "system for simulating a multi-processor system in an electronic device that provides a graphical modeling environment", i.e. a method of creating a graphical program on a computer and executing it. According to established jurisprudence of the boards of appeal, both constitute inventions within the meaning of Article 52(2) and (3) EPC (as regards the method claim, see esp. T 424/03, reasons 5.1).
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.