Friday, 26 September 2014

T 0835/10 - Double dead - Art.123(2) and Art.56

The examining division refused an application for lack of inventive step. The applicant appealed. The representative indicated not to attend the oral proceedings. The Board refused the application for added subject-matter on a formulation already introduced during examination; this ground had not been raised by the Examining Division. The Board considered the question of inventive step, “since inventiveness was the only reason of the appealed decision to refuse the application, and the objection concerning Article 123(2) EPC could have been easily overcome”.
For inventive step, the Board disagreed with the appellants statement that the problem definition was based on hindsight. Moreover, the Board did not see any inventiveness as such in letting a human operator intervene in an automated process.

Summary of Facts and Submissions

I. The appeal is directed against the decision of the examining division, posted on 27 November 2009, to refuse the application 03721348 for lack of inventive step over […]

II. A notice of appeal was received on 22 January 2010. The fee was received the same day. A statement of the grounds of appeal was received on 6 April 2010. Claim sets of a main and four auxiliary requests were filed.

III. In its summons to oral proceedings, the board gave reasons for its preliminary opinion with respect to Articles 123(2), 84 and 56 EPC.

IV. In a letter dated 20 August 2014, the appellant announced that it would not be represented at the oral proceedings.


VII. Claim 1 of the main request reads as follows:

"1. A method of reorganizing an array layout in a behavioral synthesis tool used to design an integrated circuit, comprising:


Reasons for the Decision

1. Overview of the invention

1.1 The application relates to a method of using a behavioural synthesis tool to design integrated circuits. The tool reads a (behavioural) source code description (in a programming language like C or Pascal, or in a behavioural hardware description language like VHDL or Verilog; see original description page 5, lines 12-17) of a circuit designed by a user (figure 2 (30)).

This description contains arrays, i.e. memories modeled in the source code language (page 1, lines 26-33), and a default set of memory allocation constraints (page 6, lines 2-3; step of "storing" in claim 1 of all requests). A constraint can designate the array length and width (page 17, lines 15-20), the memory type (on-/off-chip, single-/multi-port, synchronous/asynchronous; see original claim 21), the packing mode or the format (page 7, lines 31-33). Note that in original claims 31-33, "format" designates little/big endian or interlacing, whereas on page 9, lines 16-18 and page 10, lines 3-4, "format" designates the size, i.e. array length and word width.

The tool generates from the read source code description an "intermediate data structure" in a kind of internal format, called "synthesis intermediate format" ("SIF", page 5, 17-20; page 6, lines 5-13; page 3, lines 9-12; figure 2 (32)), and stores this data structure.

Now, the tool calculates and displays a report of area and speed of the current array allocation in the memories of the circuit (figure 2 (36)).

The user can then modify the constraints, whereupon the tool re-allocates the arrays (figure 2 (34)). There are two way of modifying: either directly by editing the constraints in the source code description (figure 16(c); claim 4 of the main request; original claim 6; page 3, lines 2-4; sentence bridging pages 7 and 8) or indirectly by using a graphical user interface (GUI) like in figure 13 (see also page 10, lines 1-5).

After the constraints have been modified, the tool displays an updated report of area and speed and waits for some unspecified kind of user satisfaction input (page 8, lines 23-24; page 10, lines 4-5). After the user has expressed his satisfaction, the tool transforms/updates the intermediate data structure (in the SIF format) to represent the modified constraints (the step of "transforming/updating" in claim 1 of all requests; see also page 8, line 24 to page 9, line 9).

All this is done before the register-transfer level description (RTL code; figure 2 (40)) of the circuit is generated.

1.2 According to original description page 2, lines 10-19, it is the advantage of the invention to avoid the prior art method of re-editing the source code and re-reading it into the tool in case the user is not satisfied with the array allocation. Another passage (page 9, lines 16-30) further specifies that when re-editing the source code description, it is the re-calculation of the array addresses for every code segment which accesses an array element (figure 16(b): A[2], A[9]) which "requires substantial editing time" and is "error-prone".

2. Overview of the decision


3. Original disclosure

The examining division did not raise any objections under Article 123(2) EPC in its decision. However, the board finds that the following amendment is not originally disclosed:

3.1 Claim 1 of all requests recites "responsive to the user modifications" at the beginning of the "transforming" step. This amendment was introduced with the first letter of reply to the examining division, dated 7 February 2006. The letter (page 1) indicates passages in the original description supporting this amendment. However, none of these passages show that the transformation of the intermediate data structure is done in response to the user modifications:


To summarise, the transformation is started only in response to a user satisfaction input, and not already in response to the user modification.

3.2 Thus claim 1 of all requests does not comply with Article 123(2) EPC.

3.3 For this reason alone, the appeal must be dismissed. However, the board will also consider the question of inventive step (and of clarity as a prerequisite of inventive step), since inventiveness was the only reason of the appealed decision to refuse the application, and the above objection concerning Article 123(2) EPC could have been easily overcome.


5. Inventiveness

In the following, the claims are interpreted in the way indicated in 3.1 and 4.

5.1 Main request

5.1.1 The board considers D1 to be the closest prior art, as it was in the appealed decision (Reasons, 1.1). This was accepted in the grounds of appeal "for the sake of argument" (A.2, first paragraph).

5.1.2 According to the appealed decision (page 4), claim 1 of the refused main request (corresponding to the current main request) differs from D1 in that a graphical user interface (GUI) is used for modifying the constraints, and a report of the estimated circuit area/speed is displayed. The objective technical problem is how to modify D1 in order to allow a user to manually influence the design space exploration process. To solve this problem, a skilled person would provide input means for manually overriding the parameters manipulated by the succeeding optimisation process, e.g. array width, length and grouping (page 5, paragraph 3). He would also provide displaying the results of the manipulation, because interactive design and manual correction is a standard procedure in computer-aided design. GUIs are an obvious implementation choice.

5.1.3 According to the grounds of appeal (page 3, first paragraph), the technical problem formulated in the decision points to the solution, since the problem of allowing a user to manually influence the design space exploration is achieved in the claim by "allowing a user to modify ...". The technical problem without an "ex post facto analysis" as used by the examining division is "the need to provide a method for re-organising an array layout to achieve more efficient memory designs more quickly using customisable design options" (paragraph 4). The automated approach of D1 leads the skilled person in a completely different direction than the application: It teaches that optimisation must involve a thorough evaluation of each design possibility relative to the system cost (last paragraph). Based on D1, a fully automated design optimisation is preferable and desirable (grounds, page 4, paragraph 4).

5.1.4 The board agrees with the view of the examining division. It cannot see that the problem formulated in the decision would point to the solution: The feature of the claim which allows the user to manually influence the design is the provision of a GUI and not the "allowing a user to modify ... constraints". The latter cannot be considered as a technical feature in the proper sense. It is more an aim that is achieved by the GUI and by storing the entered values.

5.1.5 The technical problem formulated in the grounds is less appropriate than that of the decision: "Achieving more efficient memory designs" (page 3, paragraph 4; emphasis added) is stated to be a technical effect of the claimed method and contained in the problem formulation.

5.1.6 However, a more efficient design is not a result of the computer-implemented method itself, but (if achieved) of the design decisions taken by a human designer which are merely entered via a GUI and then cognitively evaluated by the designer with the help of a report. Moreover compared to D1, it is unlikely that the claimed method finally achieves a more efficient memory design, since D1 apparently evaluates exhaustively all the possibilities in an automatic way. So, one can only say that the method aids the designer to manually find a good memory design (therefore the expression "computer-aided design"), but such a good memory design cannot be seen as a technical effect of the method itself.


5.1.8 The board is of the opinion that the method of D1 is characterised by maximally automating the memory allocation design process, whereas the application aims to provide the designer with a half-automated tool for the same purpose, leaving to the designer the determination of important parameters for allocating arrays in memories.

However, as little as merely automating human behaviour is usually considered to be inventive (see for example section 6. from decision T634/01 of a different board, or section 5.4 from T1937/09 of this board in a different composition), the inverse - i.e. "de-automating" or undoing (in a computer-implemented method) the automation performed by a prior art software - cannot in general be considered to be inventive.
5.1.9 In particular in the present application, the board cannot see an inventive activity in leaving the optimisation task mainly to the designer and providing him with the necessary aid to perform that task (reporting the evaluation parameters for the current design and providing him with a GUI for modifying the design).

5.1.10 Therefore, claim 1 of this request is not inventive in the sense of Article 56 EPC.


For these reasons it is decided that:
1) The appeal is dismissed.
2) The request for reimbursement of the appeal fee is rejected.

This decision has European Case Law Identifier: ECLI:EP:BA:2014:T083510.20140903. The whole decision can be found hereThe file wrapper can be found here. Photo by Richard Giles, obtained via Flickr.

No comments :

Post a Comment