T 0991/09 (Design flow guidance/LSI LOGIC) of 28.11.2014

Summary of Facts and Submissions

I. The applicant (appellant) lodged an appeal against the decision of the Examining Division refusing European patent application No. 03025848.7.

II. The contested decision cited the following documents:

D1: EP-A-1 063 599, published 27 December 2000; and

D6: Fossati F.: "Un approccio innovativo per la realizzazione di chip custom", Elettronica Oggi, October 2002.

The Examining Division decided that the subject-matter of claim 1 of the then main request and of the then first auxiliary request lacked an inventive step over a combination of documents D1 and D6. Two further auxiliary requests were not admitted under Rule 137(3) EPC.

III. With the statement of grounds of appeal, the appellant filed a main request and a first auxiliary request.

IV. In a communication accompanying a summons to oral proceedings, the Board raised objections under Articles 84 and 123(2) EPC and expressed the view that the subject-matter of claim 1 of each request lacked an inventive step in view of a combination of documents D1 and D6.

V. With a letter dated 28 October 2014, the appellant replaced its claim requests with a main request and first to third auxiliary requests.

VI. Oral proceedings were held on 28 November 2014. At the end of the oral proceedings, the chairman pronounced the Board's decision.

VII. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the claims of the main request filed with the letter dated 28 October 2014 or, in the alternative, on the basis of the claims of one of the first to third auxiliary requests filed with the letter dated 28 October 2014.

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

"A computer-implemented method for automatically guiding a user through a design flow for an integrated circuit, the method comprising a web-based expert system storing a number of reference chip designs that serve as a starting point for the design of a custom chip, the method comprising the steps of:

(a) displaying a design flow user interface on a user's computer, where the user interface includes symbols corresponding to design flow process steps, the design flow process steps being defined with a set of rules;

(b) analyzing whether user input for each step complies with the rules; and

(c) allowing the user to proceed to a next step if it is determined that previous steps have been completed successfully;

wherein after the user has input parameter values for the custom chip, a screen is displayed to the user showing the input design parameters values compared to the values for the parameters of closest matching reference designs, such that the user can select one of the reference designs on which his or her custom design will be based."

IX. Claim 1 of the first auxiliary request differs from claim 1 of the main request in that the first occurrence of the expression "the method comprising" has been replaced by "method comprises" and in that the text following step (c) has been replaced by:

"wherein the design flow process steps include 'Initial Analysis and Fit to Slice', 'Import Cores and IP', 'RapidWorks Tools', 'Simulation and Timing Models', 'Chip Place and Route', and 'Data Check and Preparation for Manufacturing'; and wherein

the 'Initial Analysis and Fit to Slice' is a step where the user is prompted to enter initial design parameters in order to populate a design-specific database and wherein after the user has input the parameter values for the custom chip, a screen is displayed to the user showing the input design parameters values compared to the values for the parameters of closest matching reference designs, such that the user can select one of the reference designs on which his or her custom design will be based;

the 'Import Cores and IP' is a step where the user imports customer-specific or third party cores and intellectual property (IP) to establish circuit logic;

the 'RapidWorks Tools' is a step where the logic is wired together with third party tools;

the 'Simulation and Timing Models' is a step where EDA tools are invoked to simulate the finished design and where the user decides if the design meets requisite timing goals;

the 'Chip Place and Route' is a step where EDA tools are invoked to perform cell placement and interconnect routing; and

the 'Data Check and Preparation for Manufacturing' is a step where final validation and releases [sic] of the design to manufacturing is performed."

X. Claim 1 of the second auxiliary request reads as follows:

"A web-based expert system for automatically guiding a user through a design flow for an integrated circuit, comprising:

a master database for storing a plurality of reference chip designs that serve as starting point for a design of a custom chip;

a design-specific database for storing design parameters values defining the custom chip; and

a set of rules, the set of rules for:

defining how the user inputs the design parameter values for the custom design, and for verifying that the values comply with design specifications for a selected reference chip design,

invoking third-party EDA tools at points in the flow for analysis, verification, and simulation, and

controlling a display of a user interface to a user that graphically depicts steps in the design flow and in a sequence that the steps are to be completed, such that only after it has been determined that the user has correctly performed a step in the flow, will the user be allowed to proceed to a next step in the flow;

wherein after the user has input the parameter values for the custom chip, a screen is displayed to the user showing the input design parameters values compared to the values for the parameters of closest matching reference designs, such that the user can select one of the reference designs on which his or her custom design will be based."

XI. Claim 1 of the third auxiliary request differs from claim 1 of the second auxiliary request in that the feature "wherein after the user ... will be based" has been replaced by:

"the system further including a project coordinator application that executes on a server and is accessed by the user over a network using a web browser, wherein the project coordinator facilitates the process flow and performs file management and checking; and

wherein the project coordinator checks compliance of the custom design after invoking one of the EDA tools by either reading the EDA tool's compiler constraints and comparing the constraints to the parameter values of the design, or by reading return codes returned by the EDA tools, which indicate successful completion or an error."

Reasons for the Decision

1. The appeal complies with the provisions referred to in Rule 101 EPC and is therefore admissible.

2. The invention

2.1 The background section of the description explains that integrated circuit design has become very complex. A large number of Electronic Design Automation (EDA) software tools designed for different stages of the design process have become available from multiple vendors. This has led to compatibility and management issues.

2.2 The application aims to address this problem by providing a user interface for guiding a user through a design flow for an integrated circuit. The user interface displays a design flow in the form of a number of symbols corresponding to design flow process steps. For each step, user input is checked for compliance with rules associated with the step. The user is allowed to proceed to a next step of the design flow once it is determined that the previous steps have been completed successfully.

2.3 The user interface is implemented as a "web-based expert system" that is said to provide "a deterministic, unified user-interface that integrates the functions required to design and build ICs". The system invokes third-party EDA tools at appropriate steps in the design flow. It models the design flow for designing a "rapid chip" in a preferred embodiment, but can be programmed to model any type of integrated circuit, such as an ASIC.

3. Main request - inventive step

3.1 Document D1 relates to a software suite supporting a methodologies-based approach for the development of large-scale integrated circuits (see abstract). It therefore represents a suitable starting point for the assessment of inventive step of the subject-matter of claim 1.

3.2 Document D1, Figure 2 and paragraphs [0026], [0027] and [0031], discloses a design system comprising an "in-house system". This in-house system includes a web server, an archive server, a compute server and an engineering workstation. The engineering workstation includes a web browser, which provides a graphical interface for communicating with other system elements. The web server provides the web browser with input forms for display.

3.3 The web server includes an "interface and flow control tool" (see paragraphs [0032] and [0047]). This tool is used for defining methodologies for designing integrated circuits, for attaching a set of methodologies to a specific chip or block, and for providing for the execution of the attached methodologies to achieve implementation of the chip or block. Paragraph [0032] explains that a methodology is a series of steps that together form a design flow for designing and implementing a chip or block design.

3.4 The methodology definition (or "capture") process is described in paragraphs [0091] to [0133]. Paragraph [0092] makes clear that design methodologies are defined independently of a particular block or chip; they are "eventually" associated with various specific blocks or chips. How methodologies are associated with blocks or chips is discussed in paragraphs [0134] to [0143].

3.5 Paragraphs [0144] to [0173] focus on methodology execution. According to paragraphs [0146] to [0149] and Figure 23, a methodology page is displayed which shows the steps of a design flow and their dependencies. Each step is displayed as a step name surrounded by a rectangular box. A user may access a step by selecting its box. Design tools are invoked where appropriate (see paragraphs [0032], [0035] and [0042]).

3.6 Claim 1 of the main request refers to a "web-based expert system". The detailed description does not give any detail as to what exactly makes the system an "expert system", and at the oral proceedings the appellant conceded that this term did not imply any limitation in the context of the present invention. The Board therefore considers the web-based system of document D1 to be a "web-based expert system" within the meaning of claim 1.

3.7 The computer-implemented method of claim 1 hence differs from what is disclosed in document D1 in that:

(a) for each design step it is analysed whether user input complies with rules associated with that design step;

(b) the user is allowed to proceed to a next step if it is determined that previous steps have been completed successfully;

(c) the web-based expert system stores a number of reference chip designs that serve as a starting point for the design of a custom chip; and

(d) after the user has input parameter values for the custom chip, a screen is displayed to the user showing the input design parameter values compared to the values for the parameters of closest matching reference designs, such that the user can select one of the reference designs on which his or her custom design will be based.

3.8 Feature (a) is an obvious user interface feature. Indeed, it is well known in the field of user interfaces to perform consistency checks on entered data by applying predetermined rules, for example to verify that the user has entered a number in a field intended for inputting a numerical value, and such checks are encompassed by feature (a).

3.9 The Board understands feature (b) as meaning that the user is allowed to proceed to a next step only after it has been determined that previous steps have been completed successfully (see paragraph [025] of the original description). Document D1, paragraph [0147], refers to a design flow as representing a directed acyclic graph that contains information on the names of the design steps to be executed as well as the order of execution. The Board would conclude from this passage that document D1 in fact discloses feature (b), were it not for the sentence in paragraph [0146] reading "The designer may select any step displayed on the methodology page". Document D1 hence does not disclose feature (b), but does render it obvious.

3.10 Features (c) and (d) relate to the first step of the "rapid chip" design flow discussed in paragraphs [032] to [034] of the description of the present application in connection with Figure 2. This step is discussed in more detail in paragraphs [040] to [046] in connection with Figures 3A, 3B, 4A and 4B. The idea behind the "rapid chip" design flow is that the designer starts by selecting one of a number of "reference chip designs" to serve as the starting point for the design of a custom chip.

3.11 In claim 1 of both the main request and the auxiliary request filed with the statement of grounds, the term "master slice" was used instead of "reference chip design". These claims included the feature "the different master slices representing product family wafers including on-wafer resources on which a custom chip may be based". In the statement of grounds, the appellant explained that a slice was a "pre-manufactured semiconductor wafer (ie. a pre-manufactured physical item) that may be used as a foundation for making a customized integrated circuit" and that a slice has "(pre-implemented) on-chip resources, useful for a certain family or type of custom design".

In its communication accompanying the summons, the Board noted that paragraph [027] of the description disclosed a "master slice reference database" which stored parameters defining "reference chip designs, referred to as master slices, that represent one or more product families". The term "master slice" hence referred to a reference chip design. There appeared to be no disclosure of a correspondence between reference chip designs and "product family wafers including on-wafer resources".

3.12 Present claim 1 no longer refers to wafers including on-wafer resources. At the oral proceedings, the appellant did not contest that the term "reference chip design" may be interpreted essentially as a partial chip design serving as a possible template for a complete chip design. In this interpretation, the claimed selection of a reference chip design arguably reflects a well-known approach to organising intellectual work, comparable to the selection of a suitable template letter to serve as a customisable starting point when writing a complete letter.

3.13 Nevertheless, claim 1 as now worded does not exclude the interpretation put forward by the appellant in the statement of grounds of appeal, i.e. the designer starts by selecting a "reference chip design" which corresponds to a physical pre-manufactured wafer including on-wafer resources which can be customised further. Such a design flow is in fact known from document D6.

3.14 Document D6 describes the appellant's "RapidChip" semiconductor platform. The underlying concept of the RapidChip platform is the design and creation of an integrated circuit starting from a pre-manufactured slice comprising pre-diffused memory, high-performance building blocks from a "CoreWare library" and customisable logic (page 1, left-hand column, lines 11 to 20, and Figure 1, step 1). These slices can be customised by mapping further IP elements from the "Coreware library" together with custom logic by means of metal layers already present on the slice (page 1, middle column, line 1, to right-hand column, line 3, and Figure 1, steps 2 and 3).

Document D6 further refers to the availability of design tools that allow the designer to manage the architectural design, verification and physical design thanks to predefined rules (page 2, left-hand column, line 3, to middle column, line 3).

3.15 According to the appellant, document D1 taught away from the "rapid chip" design flow of the invention, since the basis for the process described by document D1 was not the selection of a reference chip design, but the definition of a methodology to be assigned to a chip.

The Board does not agree that document D1 teaches away from, or is in any way incompatible with, the selection of a reference chip design as a first step of the design flow. It is true that the design system of document D1 allows the definition of new design flows (or "methodologies"), but such definition activities are independent of and precede the assignment of a design flow to a particular chip and the execution of that design flow (see points 3.33.3 and 3.43.4 above). Document D1 therefore in fact invites the skilled person to add further known design flows. The Board hence considers it obvious to adapt the system of document D1 to include the design flow of document D6. Such adaptation involves in particular the provision of a user interface for facilitating the selection of a slice (or "reference chip design" in the wording of claim 1) from a number of available slices (see document D6, Figure 1, step 1).

3.16 The appellant has argued that neither document D1 nor document D6 provided any hint that would have prompted the skilled person to let the user, in accordance with feature (d), select a reference design from a displayed list of comparisons between input design parameter values and the parameter values of closest matching reference designs.

In the Board's view, this feature can nevertheless not support an inventive step. Without the help of a user interface, a designer would have to perform step 1 of Figure 1 of document D6 manually by going through the available reference chip designs, comparing them with the design requirements, and selecting the design that most closely matched the requirements. With the help of a user interface this process could be fully automated: the user enters his requirements and the system determines the closest match. Or the manual selection process could remain the same, except that it is performed on a computer: the system would display the available designs together with relevant information enabling the user to assess the suitability of each design and let the user pick a design. The Board considers that both these possibilities are obvious and that the skilled person would also think of an intermediate approach in which the system would automatically generate a shortlist of closest matching designs and then allow the user to make the final selection, similar to how in a manual selection process a designer could let an assistant make a preselection. This is essentially the claimed approach. Feature (d) adds the sub-feature that "input design parameters values compared to the values for the parameters" are displayed for each closest matching reference design. Since the designer, in order to be able to make the final selection, must be provided with information regarding the suitability of each of the closest matching designs, this is obvious as well.

3.17 The appellant has submitted that features (c) and (d) combine to improve the efficiency of the design flow for an integrated circuit.

While it is arguably true that both features help to improve the efficiency of integrated circuit design, the contribution of feature (c) is to the design flow itself, whereas the contribution of feature (d) is to facilitating the automation of a previously manually performed step with the help of a graphical user interface. These features do not combine to provide a further technical effect going beyond the sum of their individual effects and can hence be treated separately.

3.18 Referring to paragraph [0022] of document D1, the appellant further argued that document D1 proposed providing a common set of tools and libraries, thereby averting the possibility of generating an unusable design due to use of different design tools. The invention on the other hand allowed the use of design tools obtained from different vendors.

However, document D1, paragraphs [0054] and [0055], in fact recognises that an EDA tool may expect an input file in a different format than that of an output file produced by another EDA tool and suggests addressing this problem by means of a format converter. In addition, none of the (distinguishing) features of claim 1 solves problems caused by the use of incompatible tools.

3.19 For these reasons, the subject-matter of claim 1 of the main request lacks an inventive step (Articles 52(1) and 56 EPC).

4. First auxiliary request - inventive step

4.1 Claim 1 of the first auxiliary request differs from claim 1 of the main request essentially in that it defines further steps of the design flow:

(a) importing, by the user, customer-specific or third-party cores and intellectual property (IP) to establish circuit logic;

(b) wiring the logic together with third-party tools;

(c) invoking EDA tools to simulate the finished design, wherein the user decides if the design meets requisite timing goals;

(d) invoking EDA tools to perform cell placement and interconnect routing;

(e) final design validation and release to manufacture.

In addition, the claim specifies that initial design parameters entered by the user populate a "design-specific database".

4.2 Regarding steps (a) and (b), document D6, Figure 1, steps 2 and 3 in combination with page 1, middle column, line 1, to right-hand column, line 3, discloses a step of importing IP from a logic library and a step of providing custom logic in order to wire the imported logic together. In the context of document D1, it is obvious to perform these steps using a tool, for example a third-party tool.

4.3 Steps (c), (d) and (e) are conventional steps of known chip design processes (see document D1, Figure 9, steps 409, 411, 415 and 417, and the corresponding paragraphs [0084] to [0089], and see also document D6, page 2, left-hand column, line 3, to middle column, line 3). According to paragraph [025] of the present application, the corresponding "EDA tools" are to be obtained from third parties, which further confirms that these steps were known at the priority date. Document D1, paragraphs [0032] and [0035], discloses that the user interface invokes tools associated with steps of the design flow.

4.4 Finally, it is obvious to store values input by a user in a suitable database, which may, for example, be a file.

4.5 The subject-matter of claim 1 of the first auxiliary request hence lacks an inventive step (Articles 52(1) and 56 EPC).

5. Second auxiliary request - inventive step

5.1 Claim 1 of the second auxiliary request relates to a web-based expert system and is identical to independent apparatus claim 9 of the main request. Compared to independent method claim 1 of the first auxiliary request, this claim more explicitly expresses that how data is entered and verified, how third-party EDA tools are invoked at appropriate points in the design flow and how the user interface is displayed are controlled by the rules defining the design flow process steps. However, the term "rule" is very broad, and the methodologies defined in document D1 (see paragraphs [0091] to [0096]), which control the same functionality, implicitly consist of rules as well.

5.2 A further difference from claim 1 of the first auxiliary request is that the user interface depicts steps in the design flow "in a sequence that the steps are to be completed". Since document D1, paragraphs [0146] and [0147] in combination with Figure 23, discloses that a "methodology page" displays the steps of a design flow including their order of execution, this difference likewise does not further distinguish the claimed invention from what is disclosed in document D1.

5.3 The appellant has not argued that any of these differences, or their combination, supports an inventive step, and for the reasons given above the Board considers that they indeed do not. The subject-matter of claim 1 hence lacks an inventive step (Articles 52(1) and 56 EPC).

6. Third auxiliary request - inventive step

6.1 Claim 1 of the third auxiliary request is based on claim 1 of the second auxiliary request. The feature relating to the selection of a reference design has been removed. Instead, the claim specifies that the system includes a "project coordinator application". This project coordinator application:

- executes on a server;

- is accessed by the user over a network using a web browser;

- facilitates the process flow;

- performs file management and checking; and

- checks compliance of the custom design after invoking one of the EDA tools either by

- reading the EDA tool's compiler constraints and comparing the constraints to the parameter values of the design, or by

- reading return codes returned by the EDA tools, which indicate successful completion or an error.

6.2 The "interface and flow control tool" disclosed in document D1, paragraphs [0032], [0047] and [0048], executes on the design server and comprises HTML pages and CGI scripts. It is hence accessed by the user over a network using a web browser. The tool guides the user through the steps of a design process flow, thereby facilitating the latter (paragraphs [0145] to [0149]). It further performs file management in that the CGI scripts produce files and store them in one location or in various directories (paragraph [0049]).

6.3 The features relating to checking compliance of the custom design correspond to paragraph [051] of the description of the present application. This passage explains that "compliance of the custom design with the output of the design tools" is checked in one of the two ways specified by the claim.

6.4 At the oral proceedings, the appellant agreed that the two ways of checking compliance of the custom design as specified by claim 1 represented two alternatives. Since the first alternative might raise a clarity issue, the Board will concentrate on the second alternative.

6.5 This second way of checking compliance of the custom design with the output of the design tools involves reading return codes returned by the EDA tools indicating successful completion or an error. The Board considers this to mean that the claimed compliance checking essentially amounts to verifying whether the output produced by tools invoked in previous steps is successfully processed by tools invoked in subsequent steps.

6.6 According to document D1, paragraphs [0158] and [0159], during execution of a step the interface and flow control tool records tool execution status reports and provides for problem reporting. The Board considers that tool execution status reports are "return codes returned by the EDA tools" and that such status reports at least indicate successful completion or an error. If a previous tool has produced output that cannot successfully be processed by a later tool, this will typically result in a status report indicating an error.

6.7 For these reasons the Board concludes that the subject-matter of claim 1 of the third auxiliary request likewise lacks an inventive step (Articles 52(1) and 56 EPC).

7. Conclusion

Since none of the requests is allowable, the appeal is to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.