Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3, 8, 9, 11, 14, 16 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Tune, US Patent Application Publication Number 20240004796 (herein “TUNE”) in view of Sistla US Patent Application Publication Number 20080126750 (herein “Sistla”).
Regarding claim 1, TUNE discloses a computer-implemented method (FIGs. 1 and 5, [0054]-[0057], [0065]-[0068]) comprising:
receiving a fetch request from a first processor of a plurality of processors in a first cluster of a plurality of cluster of a data processing system ([0054], The first requestor 4 is configured to issue a coherent access request to the coherent interconnect 12 to request the most up-to-date copy of data corresponding to an address in the memory 10. [0065], As in FIG. 1, the system comprises a coherent interconnect 12, SLC 14, and data stores 10. The system also includes two processing clusters 21 and an I/O coherent domain 30. Each processing cluster 21 comprises two or more central processing units (CPUs) 22 (in the example shown, each processor includes two CPUs 22), private caches associated with each CPU (L1 cache 24, L2 cache 26), and a shared cache 28. The first cluster may be interpreted as a cluster of CPUs of both clusters 21, additional clusters may be interpreted as each of the clusters 21);
performing a local snoop operation for the first cluster, in response to the fetch request ([0054], When a coherent access request is received at the coherent interconnect 12, the coherency control circuitry 16 may issue snoop requests to caches 8 which may hold a copy of the requested cache line (such as the one or more caches 8 associated with the second requestor 6)),
wherein the local snoop operation is initiated within the first cluster and performed without involving an upper level cache associated with the first cluster ([0054], Alternatively, the snoops may be issued directly from the first requestor 4 to the caches 8 which may hold a copy of the requested cache line, bypassing the coherent interconnect 12, bypassing the upper level NI Cache 14 in the coherent interconnect 12, thus inherently performing the snoop operation without involving the upper level cache. The local snoop operation is initiated within the first cluster which may include first requestor 4 and second requestor 6), and
performing the local snoop operation comprises: triggering a snoop controller to (i) send a snoop request to each of the plurality of processors in the first cluster ([0054], “When a coherent access request is received at the coherent interconnect 12, the coherency control circuitry 16 may issue snoop requests to caches 8 which may hold a copy of the requested cache line (such as the one or more caches 8 associated with the second requestor 6)”. FIG. 1 of TUNE discloses each cache 8 may be associated with or included as a part of one of plurality of processors (4 or 6) in the cluster. Thus, coherency control circuitry 16 may be interpreted as a “snoop controller”); and
(ii) receive a snoop response from each of the plurality of processors in the first cluster; ([0068] “However, in an alternative example the snoop-filter information associated with the SLC 14 may indicate whether the first requestor can use the data stored in the matching entry without waiting for a response to a snoop of a particular cache 8. In this case, separate snoop-filter information may be provided for each cache 8. Hence, either: snoop responses need to be received from all caches, a snoop response needs to be received from a selection of caches according to the snoop-filter information, or no snoop responses are needed before the first requestor can use the data stored in the matching entry”. FIG. 1 of TUNE discloses each cache 8 may be associated with or included as a part of one of plurality of processors (4 or 6) in the cluster); and
sending a fetch response to the first processor, based on the local snoop operation ([0054], The first requestor 4 may issue non-coherent access requests, in response to which data may be returned without following the usual cache coherency protocol).
Tune figure 8 step 806 teaches that the first requestor should wait for snoop responses before using returned data, but does not expressly teach receiving, from the snoop controller, a single consolidated response that is generated based on the snoop responses from the plurality of processors in the first cluster, the single consolidated response indicating whether one of the processors in the first cluster has a cache line associated with the fetch request.
With respect to claim 1, Sistla teaches:
and receiving, from the snoop controller, a single consolidated response that is generated based on the snoop responses from the plurality of processors in the first cluster, the single consolidated response indicating whether one of the processors in the first cluster has a cache line associated with the fetch request. (Paragraph 0040 shows that a scalability agent issues snoops to core-cache clusters while concurrently issuing the transaction to the system interconnect and collects responses from all core-cache clusters and issues an aggregate response to the requesting core-cache cluster. Paragraphs 0058-0060 show that the response indicates if one of the core-cache clusters has a cache line associated with the request.)
As of the effective filing date of the application, it would have been obvious to combine the snoop response consolidation of Sistla with caching system of Tune.
The motivation for doing so would have been to mitigate interconnect saturation issues, avoid repeated reconfiguration of CSI home agent and ensure that the core-cache cluster is not aware of the nature or the number of the other core-cache clusters, Sistla paragraphs 0035, 0040.
Regarding claim 3, TUNE discloses wherein the fetch response comprises data associated with the cache line when the single consolidated response indicates that one of processors in the first cluster has the cache line ([0068] However, in an alternative example the snoop-filter information associated with the SLC 14 may indicate whether the first requestor can use the data stored in the matching entry without waiting for a response to a snoop of a particular cache 8. In this case, separate snoop-filter information may be provided for each cache 8. Hence, either: snoop responses need to be received from all caches, a snoop response needs to be received from a selection of caches according to the snoop-filter information, or no snoop responses are needed before the first requestor can use the data stored in the matching entry).
Regarding claim 8, TUNE discloses further comprising: while performing the local snoop operation, detecting that a second processor within the first cluster has released a cache line associated with the fetch request; in response to detecting that the second processor within the first cluster has released the cache line associated with the fetch request, capturing the cache line; and returning the cache line to the first processor within the first cluster ([0068] However, in an alternative example the snoop-filter information associated with the SLC 14 may indicate whether the first requestor can use the data stored in the matching entry without waiting for a response to a snoop of a particular cache 8. In this case, separate snoop-filter information may be provided for each cache 8. Hence, either: snoop responses need to be received from all caches, a snoop response needs to be received from a selection of caches according to the snoop-filter information, or no snoop responses are needed before the first requestor can use the data stored in the matching entry).
Regarding claim 9, TUNE discloses further comprising writing the cache line to the upper level cache ([0062], transactions which write a clean cache line into a lower level cache and deallocate the line from the higher level cache (such as WriteEvict). [0072], if the SLCs 14 use a read-no-allocate write-allocate allocation policy for allocation of data in response to requests originating from the cluster 21, then the SLC data originating from the CPUs of the cluster 21 will be data evicted from higher level coherent caches 8, and therefore data that does not need snoops to be issued to the higher level caches 8).
Regarding claim 11, TUNE discloses further comprising: receiving, from a second processor of the plurality of processors in the first cluster, a request to store a cache line; and in response to receiving the request, sending a write response comprising the cache line to the second processor of the plurality of processors in the first cluster.
Regarding independent claim 14, the applicant is directed to the rejections to claim 1 set forth above, as it is rejected based on the same rationale.
Regarding claim 16, the applicant is directed to the rejections to claim 3 set forth above, as it is rejected based on the same rationale.
Regarding claim 18, the applicant is directed to the rejections to claim 8 set forth above, as it is rejected based on the same rationale.
Regarding claim 19, the applicant is directed to the rejections to claim 9 set forth above, as it is rejected based on the same rationale.
Claims 4-6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over TUNE in view of Sistla and further in view of McGee et al., US Patent Application Publication Number 20200349075 (herein “MCGEE”).
Regarding claim 4, TUNE and Sistla discloses upon determining that the local snoop operation has failed: forwarding the fetch request to upper level cache associated with the first cluster ([0055], When a coherent access request cannot be serviced in response to the snoop requests (there is not another copy of the cache line in the snooped caches 8), a memory request may be issued, in response to which a lookup may be performed in the system level cache 14 and, if that lookup misses, in the memory 10).
TUNE and Sistla does not disclose tagging the fetch request with an identifier corresponding to the first cluster.
MCGEE discloses tagging the fetch request with an identifier corresponding to the first cluster ([0033], In some embodiments an identifier of the requestor or source of the request (e.g., ID of the requestor processor) can be included in the request).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify TUNE and Sistla to further include tagging the fetch request with an identifier corresponding to the first cluster as taught by MCGEE, to allow multiprocessor shared memory systems enforce cache coherency using hardware- or software-based protocols and mechanisms to arbitrate access to the shared memory and enable the processors to see the same data (see MCGEE [0001]).
Regarding claim 5, TUNE discloses receiving a snoop request from an upper level cache associated with a second cluster of the plurality of clusters ([0065], The processing clusters are examples of either a first requestor or a second requestor 6, and the caches 24, 26, and 28 are examples of one or more coherent caches 8),
in response to the snoop request, performing another local snoop operation for the first cluster ([0054], When a coherent access request is received at the coherent interconnect 12, the coherency control circuitry 16 may issue snoop requests to caches 8 which may hold a copy of the requested cache line (such as the one or more caches 8 associated with the second requestor 6)); and
sending a snoop response to the upper level cache associated with the second cluster, the snoop response comprising (i) an indication of a processor within the first cluster has a cache line associated with the snoop request and (ii) the cache line ([0068] However, in an alternative example the snoop-filter information associated with the SLC 14 may indicate whether the first requestor can use the data stored in the matching entry without waiting for a response to a snoop of a particular cache 8. In this case, separate snoop-filter information may be provided for each cache 8. Hence, either: snoop responses need to be received from all caches, a snoop response needs to be received from a selection of caches according to the snoop-filter information, or no snoop responses are needed before the first requestor can use the data stored in the matching entry).
TUNE and Sistla does not disclose wherein the snoop request comprises an identifier corresponding to the first cluster.
MCGEE discloses wherein the snoop request comprises an identifier corresponding to the first cluster ([0033], In some embodiments an identifier of the requestor or source of the request (e.g., ID of the requestor processor) can be included in the request).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify TUNE and Sistla to further include the snoop request comprising an identifier corresponding to the first cluster as taught by MCGEE, to allow multiprocessor shared memory systems enforce cache coherency using hardware- or software-based protocols and mechanisms to arbitrate access to the shared memory and enable the processors to see the same data (see MCGEE [0001]).
Regarding claim 6, TUNE discloses a directory within the upper level cache associated with the second cluster ([0066]-[0068], snoop-filter information /a directory is associated/in SLC 14 (non-inclusive cache) shared by first cluster and second cluster).
TUNE and Sistla does not disclose the identifier corresponding to the first cluster is obtained from a directory.
MCGEE discloses the identifier corresponding to the first cluster is obtained from a directory ([0033], In some embodiments an identifier of the requestor or source of the request (e.g., ID of the requestor processor) can be included in the request).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify TUNE and Sistla to further include the identifier corresponding to the first cluster is obtained from a directory as taught by MCGEE, to allow multiprocessor shared memory systems enforce cache coherency using hardware- or software-based protocols and mechanisms to arbitrate access to the shared memory and enable the processors to see the same data (see MCGEE [0001]).
Regarding claim 17, the applicant is directed to the rejections to claim 4 set forth above, as it is rejected based on the same rationale.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over TUNE in view of Sistla and further in view of Chachad et al., US Patent Application Publication Number 20200371927 (herein “CHACHAD”)
Regarding claim 7, TUNE and Sistla does not disclose wherein the upper level cache is a Level 3 (L3) cache.
CHACHAD discloses wherein the upper level cache is a Level 3 (L3) cache ([0180] At operation 920B, the snoop operation generated by the level-3 cache and/or next higher-level cache) is received by an L2 controller (e.g., UMC 430), additionally, whether the upper level cache is a Level 3 cache is an arbitrary designation and therefore it is inherent that the upper level cache may be any level cache).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify TUNE and Sistla to further include the upper level cache is a Level 3 (L3) cache as taught by CHACHAD, to reduce cache latencies and increase data security (see CHADCHAD [0004]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over TUNE in view of Sistla and further in view of Hughes et al., US Patent Application Publication Number 20230101512 (herein “HUGHES”).
Regarding claim 10, TUNE and Sistla does not disclose wherein the cache line is written to the upper level cache at a same time that the cache line is returned to the first processor
HUGHES discloses wherein the cache line is written to the upper level cache at a same time that the cache line is returned to the first processor ([0050], For software using the shared prefetch instruction, the first reader (core 0 601) will use a shared prefetch instruction to touch the data. This will trigger a different kind of request to the uncore, which will tell the uncore that the data being touched should be treated as shared data. As shown, the shared prefetch from Core 0 601 triggers a code read shared. This instructs the caching agent/last level cache (LLC) to install the data into the LLC 603 in shared state (S) and return a copy to Core 0 601 to be stored in a shared state (S)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify TUNE and Sistla to further include the cache line is written to the upper level cache at a same time that the cache line is returned to the first processor as taught by HUGHES, to efficiently handle shared and private data differently (see HUGHES [0031]).
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over TUNE in view of Sistla and further in view of Brueggen et al., US Patent Application Publication Number 20130263148 (herein “BRUEGGEN”).
Regarding claim 12, TUNE and Sistla does not disclose maintaining, by a coherent interconnect within the first cluster, ownership of the cache line after sending the write response.
BRUEGGEN discloses maintaining, by a coherent interconnect within the first cluster, ownership of the cache line after sending the write response ([0052] The directory cache 408 may be internal to or external to the controller 400. Since the directory cache 408 typically is not large enough to track ownership of all possible cache lines, from time-to-time the controller 400 deletes (or "evicts") certain older ownership entries ("victims") from the directory cache in order to make room in the directory cache 408 for tracking ownership of more recently requested cache lines. When evicting a cache line, the controller 400 issues a "snoop" request to the remote processor 460 that owns that cache line to determine whether the cache line data is different from that stored in the local memory 480. If so, the controller 400 will obtain the modified data from the remote processor 460 and issue a memory write request to the local processor 470 to write the modified data to the local memory 480. Cache controller 400 maintains the ownership of all cache lines, especially during the eviction process).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify TUNE and Sistla to further include maintaining ownership of the cache line after sending the write response for a period of time as taught by BRUEGGEN, to prevent slow down or stalling of the system (see BRUEGGEN [0001]).
Regarding claim 13, TUNE and Sistla does not disclose wherein the ownership of the cache line is maintained by the coherent interconnect for a period of time after the write response is sent; and the period of time is based on an amount of time it takes to write the cache line to the upper level cache.
BRUEGGEN discloses wherein the ownership of the cache line is maintained by the coherent interconnect for a period of time after the write response is sent; and the period of time is based on an amount of time it takes to write the cache line to the upper level cache ([0052] The directory cache 408 may be internal to or external to the controller 400. Since the directory cache 408 typically is not large enough to track ownership of all possible cache lines, from time-to-time the controller 400 deletes (or "evicts") certain older ownership entries ("victims") from the directory cache in order to make room in the directory cache 408 for tracking ownership of more recently requested cache lines. When evicting a cache line, the controller 400 issues a "snoop" request to the remote processor 460 that owns that cache line to determine whether the cache line data is different from that stored in the local memory 480. If so, the controller 400 will obtain the modified data from the remote processor 460 and issue a memory write request to the local processor 470 to write the modified data to the local memory 480. Cache controller 400 maintains the ownership of all cache lines, especially during the eviction process. Therefore, the time of maintaining the ownership is based on the eviction process).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify TUNE to further include the period of time is based on an amount of time it takes to write the cache line to the upper level cache as taught by BRUEGGEN, to prevent slow down or stalling of the system (see BRUEGGEN [0001]).
Claims 20-22 are rejected under 35 U.S.C. 103 as being unpatentable over TUNE in view of Gilbertson et al., US Patent Number 7343515 (herein “GILBERTSON”).
Regarding claim 20, TUNE discloses a computer-implemented method (FIGs. 1 and 5, [0054]-[0057], [0065]-[0068]) comprising:
receiving, at a coherent interconnect within a cluster, a fetch request from a processor of a plurality of processors in the cluster ([0054], The first requestor 4 is configured to issue a coherent access request to the coherent interconnect 12 to request the most up-to-date copy of data corresponding to an address in the memory 10. [0065], As in FIG. 1, the system comprises a coherent interconnect 12, SLC 14, and data stores 10. The system also includes two processing clusters 21 and an I/O coherent domain 30. Each processing cluster 21 comprises two or more central processing units (CPUs) 22 (in the example shown, each processor includes two CPUs 22), private caches associated with each CPU (L1 cache 24, L2 cache 26), and a shared cache 28. The cluster may be interpreted as a cluster of CPUs of both clusters 21);
sending, by the coherent interconnect, a snoop request to trigger a local snoop operation for the cluster, in response to the fetch request ([0054], When a coherent access request is received at the coherent interconnect 12, the coherency control circuitry 16 may issue snoop requests to caches 8 which may hold a copy of the requested cache line (such as the one or more caches 8 associated with the second requestor 6)); and
receiving, by the coherent interconnect, a snoop response in response to the snoop request ([0054], The first requestor 4 may issue non-coherent access requests, in response to which data may be returned without following the usual cache coherency protocol)
TUNE does not disclose wherein the snoop response comprises an indication that at least one processor in the cluster is in an offline state.
GILBERTSON discloses wherein the snoop response comprises an indication that at least one processor in the cluster is in an offline state (Col. Lines 33-55, “The above discussion describes the processing of snoop requests to a failed requester that are queued within snoop request out queue 214 or within a queue of a port of an MSU when an error flit is received by the MSU. In another scenario, some snoop requests may have been issued to a failing requester and are awaiting snoop responses when the error flit is received. In this case, the issuing MSU cannot be sure that a response to the snoop request will ever be received. Therefore, special processing is initiated for these requests. Specifically, when any of the state machines 207 of TTQ 204 is in a state that indicates that a pending snoop request has been issued to a failed requester, the state machine generates another snoop request to the same failed requester. This snoop request has the special error fence indicator set in the transaction header. According to the current example, this snoop request will be provided by MSU 100A to PND 102A. Upon receipt of the snoop request, error logic 130A will generate a snoop response with the error fence indicator set. In the manner discussed above, the response will include the same transaction ID as the request, will have a transaction type of "snoop response", will contain an activated error fence indicator, and will include a status of "master abort"”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify TUNE to further include the snoop response comprises an indication that at least one processor in the cluster is in an offline state as taught by GILBERTSON, to allow for error isolation and error recovery (see GILBERTSON, col. 1 line 48 - col. 2 line 19).
Regarding claim 21, TUNE discloses the computer-implemented method of claim 20, but TUNE does not explicitly disclose further comprising maintaining a status for the at least one processor in the cluster that indicates the at least one processor is unavailable to participate in the local snoop operation.
GILBERTSON discloses further comprising maintaining a status for the at least one processor in the cluster that indicates the at least one processor is unavailable to participate in the local snoop operation (Col. 23 Lines 33-55, “The above discussion describes the processing of snoop requests to a failed requester that are queued within snoop request out queue 214 or within a queue of a port of an MSU when an error flit is received by the MSU. In another scenario, some snoop requests may have been issued to a failing requester and are awaiting snoop responses when the error flit is received. In this case, the issuing MSU cannot be sure that a response to the snoop request will ever be received. Therefore, special processing is initiated for these requests. Specifically, when any of the state machines 207 of TTQ 204 is in a state that indicates that a pending snoop request has been issued to a failed requester, the state machine generates another snoop request to the same failed requester. This snoop request has the special error fence indicator set in the transaction header. According to the current example, this snoop request will be provided by MSU 100A to PND 102A. Upon receipt of the snoop request, error logic 130A will generate a snoop response with the error fence indicator set. In the manner discussed above, the response will include the same transaction ID as the request, will have a transaction type of "snoop response", will contain an activated error fence indicator, and will include a status of "master abort"”. E.g. locally generated “snoop response” as a bypass response by error logic 130A will maintain a status that a processor /requester has failed is unavailable for snoop operations).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify TUNE to further include the snoop response comprises an indication that at least one processor in the cluster is in an offline state as taught by GILBERTSON, to allow for error isolation and error recovery (see GILBERTSON, col. 1 line 48 - col. 2 line 19).
Regarding claim 22, TUNE discloses the computer-implemented method of claim 20, further comprising upon determining that the at least one processor is in an online state, sending the snoop request to the at least one processor ([0062], “Depending on the implementation, this state may indicate that snoops should not be issued, snoops may be issued but there is no need to wait for snoop responses, or that a response to a coherent access request should indicate that the data included in the response may be used without waiting for a snoop response.” E.g. there is a state indication of whether to send snoop request, thus, a setting indicating/determining the processor is in an online state).
Response to Arguments
Applicant’s arguments, see the final paragraph beginning on page 8 of the remarks submitted 2/17/2026, with respect to the rejection(s) of claim(s) 1 and 14 under 35 USC 102 as being anticipated by Tune have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Sistla.
In the last paragraph beginning on page 10 through the first paragraph beginning on page 12 of the remarks submitted 2/17/2026, applicant argues:
“In the Office Action, the Office relies on Tune for allegedly disclosing "receiving, by the coherent interconnect, a snoop response in response to the snoop request ([0054], [t]he first requestor 4 may issue non-coherent access requests, in response to which data may be returned without following the usual cache coherency protocol)." Office Action, p. 20. The Office further concedes that Tune "does not disclose wherein the snoop response comprises an indication that at least one processor in the cluster is in an offline state," but nevertheless asserts that Gilbertson "discloses wherein the snoop response comprises an indication that at least one processor in the cluster is in an offline state (col. [23], Lines 33-35 ...)." Office Action, p. 20.
Gilbertson relates to fault isolation and error recovery in a partition. The cited
portions of Gilbertson disclose generating a snoop response that includes an error fence indicator and a master abort status when a failed requestor is detected. See Gilbertson, col. 23, II. 33-49. However, Gilbertson fails to teach or suggest that the error fence indicator and the master abort status include "an indication that at least one processor in the cluster is in an offline state," as recited in claim 20.
Furthermore, even assuming, arguendo, that the Office's mapping of Gilbertson's error-fence snoop response to the "snoop response" in claim 20 were correct (which Applicant does not concede), the Office has failed to show that Gilbertson's error-fence snoop response (even if combined with Tune) is received "in response to the snoop request" sent to "trigger a local snoop operation for the cluster," as recited in claim 20. To the contrary, Gilbertson instead discloses that the error-fence snoop response is received in response to another snoop request generated by a TTQ state machine. See Gilbertson, col. 23, II. 42-51 (explaining "when any of the state machines is in a state that indicates that a pending snoop request has been issued to a failed requester, the state machine generates another snoop request to the same failed requester [that] has the special error fence indicator set in the transaction header Upon receipt of the [error-fence] snoop request, error logic will generate a snoop response with the error fence indicator set."). This other snoop request that is generated, however, is not sent "to trigger a local snoop operation for the cluster" as recited in claim 20. Rather, Gilbertson explicitly teaches that the other snoop request is sent only to the failed requester. See Gilbertson, col. 23, II. 42-51.”
The examiner notes that the rejection is based on modifying Tune based on the teachings of Gilbertson. Tune teaches triggering a local snoop operation for the cluster. The examiner notes that claim 20 does not recite or prohibit an “other snoop request.” Claim 20 recites “the snoop response comprises an indication that at least one processor in the cluster is in an offline state.” Gilbertson column 23 lines 50-51 shows that in response to the receipt of the snoop request, error logic 130A will generate a snoop response with the error fence indicator set, which indicates the failure (a form of being offline). That there is a second snoop request that includes that error fence indicator is not prohibited by the claim. The claim does not prohibit multiple requests being sent in order to receive the snoop response, merely that is it “in response to the snoop request.” Gilbertson’s snoop request that includes that error fence indicator is sent in response to the initial snoop response as it is the initial snoop response that sets in motion the process that results in the generation of the snoop response including the error fence indicator.
Further, the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). The modification is not based on the wholesale incorporation of Gilbertson’s error-fence snoop request, rather on Gilbertson’s teaching on how to handle the situation where a processor has failed. Gilbertson teaches a reason to indicate in a snoop response that a requestor has failed for the reasons presented supra with respect to claim 20.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jared Ian Rutz whose telephone number is (571)272-5535. The examiner can normally be reached Monday-Friday, 8:00 AM to 4:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John Cottingham can be reached at (571)272-1400. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JARED I RUTZ/Supervisory Patent Examiner, Art Unit 2135
Prosecution Insights