14-15 November 2018
|European Case Law Identifier:||ECLI:EP:BA:2016:T244811.20160907|
|Date of decision:||07 September 2016|
|Case number:||T 2448/11|
|IPC class:||G06F 9/38|
|Language of proceedings:||EN|
|Download and more information:||
|Title of application:||RISC processor supporting one or more uninterruptible co-processors|
|Applicant name:||QUALCOMM Incorporated|
|Relevant legal provisions:||
|Keywords:||Amendments - added subject-matter (no)
Inventive step - (yes)
Summary of Facts and Submissions
I. The appeal is directed against the decision of the examining division, dated 27 June 2011, to refuse application 03007418.1 for added subject-matter of the main request and for lack of inventive step of the auxiliary request over document D2:
D2 EP 0 793 168 A2.
The following documents were mentioned in the European search report or in the first communication of the examining division, dated 4 November 2004:
D3 US 5 887 160 A.
D1 IBM Technical Disclosure Bulletin: "Loosely coupled synchronisation mechanism supporting precise interrupts"; volume 35, No. 4B, 1 September 1992; XP313862.
II. A notice of appeal was received on 26 August 2011. The appeal fee was paid the same day. A statement of the grounds of appeal was received on 26 October 2011.
III. The appellant requests that the decision be set aside and the case be remitted to the first instance with the order to grant a patent based on a sole request ("new main request appeal") filed with the grounds of appeal and identical to the (first) auxiliary request filed during oral proceedings before the examining division.
The further application documents on file are: description pages 1-17 as originally filed; drawing sheets 1-6 as originally filed.
IV. The sole independent claim reads as follows:
"1. A method of processing instructions in a computer system comprising a processor (102) and a co-processor (106), wherein the processor (102) includes a co-processor interface (138), the processor (102) being coupled to the co-processor (106), the method comprising:
(a) processing instructions in the processor (102), in an instruction pipeline (300) wherein instructions are processed sequentially by an instruction fetch stage (310, 510), an instruction decode stage (320, 520), an instruction execute stage (330, 530), a memory access stage (340, 540) wherein in the memory access stage interrupts or exceptions are raised and a result write-back stage (350,550); and
(b) if a co-processor instruction is received by the processor (102), performing the steps of:
(b)(i) providing the co-processor instruction to the co-processor interface (138) during the instruction execute stage (330, 530) and holding the co-processor instruction within a buffer located within the co-processor interface (138);
(b)(ii) if there is an interrupt or exception raised before the co-processor instruction reaches the memory access stage (340, 540), cancelling the co-processor instruction in the co-processor interface (138) before it is sent to the co-processor; and
(b)(iii) if no interrupt or exception is raised before the co-processor instruction reaches the memory access stage (340, 540), sending the co-processor instruction from the co-processor interface (138) to the co-processor in the memory access stage (340, 540)."
Reasons for the Decision
1. Overview of the invention
The application relates to a method of processing co-processor instructions in a processor chip of a computer. The co-processor instructions go through the core processor's pipeline until the execute stage and are then transmitted, during the memory access stage, to the co-processor for execution, unless an interrupt or exception is raised before the instruction reaches the memory access stage (claim 1). In the case of an interrupt, the instructions are reissued starting at the instruction fetch stage and do not have to be transmitted twice from the processor to the co-processor (claim 2).
2. Original disclosure
2.1 The examining division did not raise any objections under Article 123(2) EPC in its decision and the board concurs that there was no reason to do so with respect to the claims of the auxiliary request as refused.
2.2 The following indications confirm this by giving a basis for the main amendments of claim 1:
- "wherein in the memory access stage interrupts or exceptions are raised" -> see page 11, lines 8-9;
- "(b)(i) providing the co-processor instruction to the co-processor interface ... during the instruction execute stage" -> see original claim 5;
- "... and holding the co-processor instruction within a buffer ..." -> follows from figure 6 (see arrow from Core to COP interface with COP cmd into cmd buffer 150) and page 16, lines 3-12;
- "(b)(ii) if there is an interrupt ..." and
"(b)(iii) if no interrupt ... is raised ..."
-> see page 11, lines 19-25.
3. Inventive step
3.1 The appealed decision (14.1-14.5) argues that a combination of D2 and "common knowledge" would lead to the subject-matter of claim 1.
3.2 The board agrees with the decision that D2 is well-suited to serve as closest prior art, but disagrees with the decision (14.1) that D2 disclosed a buffer in a co-processor interface for holding the co-processor instruction. The appellant convincingly argues in its grounds of appeal (page 6, paragraphs 2-4) that co-processor input controller 30 of D2 neither contains a buffer (see the boxes inside 30 in figure 5: two decoders and four counting circuits), nor is bus 20 connected with co-processor input controller 30. Rather, the co-processor instruction enters over bus 20 directly into one of FIFOs a and b, before being outputted by the concerned FIFO into one of input registers SR0 or SR1 (see D2, figure 5 and column 10, lines 21-31). The FIFOs and the input registers are located in co-processor execution unit 31 (see 202, 203, 213 and 31 in figure 5 and 31 in figure 4). Both co-processor execution unit 31 and co-processor input controller 30 (which is identified with the co-processor interface of the claim) are located in the co-processor (see 30, 31 and 50 in figure 4), in contrast to the co-processor interface of the claim (see co-processor interface named "COP I/F" 138 and co-processor "COP" 106 in figure 2 of the application; see also claim 1, lines 2-3 which defines co-processor interface 138 as being included in the processor).
3.3 It follows that all steps of claim 1 relating to the buffering of the co-processor instruction in a co-processor interface in the processor are not disclosed by D2, i.e. steps (b)(i), (b)(ii) and (b)(iii).
3.4 The decision does not explicitly indicate in which features claim 1 differs from the disclosure of D1 and formulates the technical problem as "dealing with exceptions" (14.3 and 14.4).
3.5 In the grounds of appeal, the objective technical problem is formulated as "cancelling co-processor instructions before negatively affecting the co-processor" (page 9, paragraph 5 and page 3, first paragraph).
3.6 The board considers the problem formulated by the examining division to be too general and not taking into account the above identified differences (i.e. steps (b)(i), (b)(ii) and (b)(iii)), whereas the problem formulated by the appellant is regarded as appropriate.
3.7 By buffering the co-processor instruction in a co-processor interface in the processor until the co-processor instruction reaches the memory access stage (i.e. the exception raising stage) in the processor's pipeline, it is guaranteed that no preceding instruction in the pipeline can raise an interrupt or exception. The description (page 11, lines 25-30) states regarding this topic:
"This ensures that the co-processor instruction is not cancelled after it is dispatched to the co-processor. As such, a co-processor instruction appears to the core processor 102 like a load or store instruction, in that it is executed in the memory access stage 340 and completed in the write back stage 350. Holding the co-processor instruction until the memory access stage also avoids the ambiguity that would occur if a later-issued instruction arrived at the co-processor 106 before an earlier one."
3.8 Since the execution of the co-processor instruction can change the co-processor state (page 11, line 11), it would be laborious to reinstall the previous state if the co-processor instruction were to be cancelled due to an interrupt or exception. Thus cancelling the co-processor instruction before it is executed (and perhaps changes the co-processor's state), is advantageous.
3.9 Neither of the other two documents on file (D2 and D3) discloses this solution.
3.10 The board furthermore does not consider it obvious to add this solution to D2 by using common general knowledge, since the execution mechanism of D2 would have to be substantially changed (see grounds, page 8, last paragraph, to page 9, first paragraph).
3.11 The board concludes that claim 1 involves an inventive step, Article 56 EPC 1973.
For these reasons it is decided that:
1) The decision under appeal is set aside.
2) The case is remitted to the department of first instance with the order to grant a patent on the basis of claims 1-5 of the sole request filed with the grounds of appeal with description and drawings to be adapted as necessary.