DETAILED ACTION
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 § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 8, 9, 15, 16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
At step 1, if no statutory category rejection was given above, then the claims have been determined to have a statutory category.
At step 2a, prong one, referring to claim 8, as emphasized, there is disclosed a method for detecting a hung state and initiating recovery so that it returns to an operational state. Claim 8 recited, “A method comprising: detecting a hung state of an RDU resource on a reconfigurable dataflow unit (RDU) that is executing a workload, wherein the RDU resource is selected from at least one of: an RDU tile, an RDU die, or the RDU; and initiating a recovery mechanism associated with the RDU resource, wherein the RDU resource is returned to an operational state from the hung state. ” Claim 15 is similar.
The limitations of detecting a hung state, as crafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of additional elements that do not integrate the judicial exception into a practical application. That is, nothing in these claim elements as emphasized precludes the step from practically being performed in the mind, possibly with the aid pen and paper. For example, these steps perform steps of observation, evaluation, judgment, or opinion.
At step 2a, prong two, this judicial exception is not integrated into a practical application. In particular the claim additionally recites initiating an action to recover. Additionally, in claim 15, there is explicitly recited a generic computer, but this may also refer to whatever mechanism the recovery is initiated through.
The computer is recited at a high level of generality. The computer is used to perform an abstract idea, as discussed above in Step 2A, Prong One, such that it amounts to no more than mere instructions to apply the exception using a generic computer. See MPEP 2106.05(f).
Initiating a recovery mechanism provides nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception. The mechanism is used to generally apply the abstract idea without placing any limits on how the mechanism functions and does not include details about how the recovery is accomplished.
Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application, and the claim is directed to the judicial exception. The generic computer, to the extent that it is even present, covers the span of the invention and would merely be the generic element that would perform generic recovery
At step 2b, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, there are the additional elements of a generic computer, and a initiating recovery.
The limitations regarding use of a computer amounts to no more than mere instructions to apply the exception using a generic computer component. See MPEP2106.05(d), for example TLI Communications, Flook, Alice Corp, and Versata.
The recitation of initiating recovery is at best mere instructions to “apply” the abstract ideas, which cannot provide an inventive concept. See MPEP 2106.05(f). See MPEP 2106.05(g) In re Brown and Ameranth and MPEP 2106.05(d) Flook.
Even when considered in combination, these additional elements represent mere instructions to implement an abstract idea or other exception on a computer and insignificant extra-solution activity, which do not provide an inventive concept.
Further referring to claim 9 and 16 this merely further describes an association of the subject of detection and the recovery mechanism.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 5, 6, 8, 12, 13, 15, 18, 19 is/are rejected under 35 U.S.C. 102a1/a2 as being anticipated by US 20160306701 to Heil et al.
Referring to claim 1, Heil discloses a system comprising:
a reconfigurable dataflow unit (RDU) coupled to a local interconnect and configured to receive a workload for execution from a host via a system interconnect coupled to the local interconnect (Paragraph 56, “In general, a data center deployment includes a hardware acceleration plane and a software plane. The hardware acceleration plane can include a plurality of networked acceleration components (e.g., FPGAs). The software plane can include a plurality of networked software-implemented host components (e.g., central processing units (CPUs)). A network infrastructure can be shared between the hardware acceleration plane and the software plane. In some environments, software-implemented host components are locally linked to corresponding acceleration components.” Paragraph 79, “The requested service 512 is a composed service spread out over a plurality of acceleration components, each of which performs a specified portion of the service. Although acceleration component 506 was contacted to request use of the service 512, acceleration component 506 may not be the head of the composed service (or even be part of the multi-component service). Instead, acceleration component 508 may be the head component for the composed service.”); and
a reconfigurable dataflow runtime (RDRT) architecture executing on the host and configured to process the execution of the workload using the RDU (See for example figure 2 including servers and management functionality. Further see for example figure 16 including service manager, server, various acceleration components and their monitors, and host component. Paragraph 77, 78, “In general, a service (e.g., search ranking, encryption, compression, computer vision, speech translation, etc.) can be implemented at one or more host components, at one or more acceleration components, or a combination of one or more host components and one or more acceleration components depending on what components are better suited to provide different portions of the service. FIG. 5 illustrates an example service 512 implemented using components of software plane 104 and components of hardware acceleration plane 106. In operation (1), host component 502 communicates with host component 504 in the course of performing a computational task. In operation (2) host component 504 then requests the use of service 512 that is implemented in the hardware acceleration plane 106 (although host component 504 may not be “aware” of where service 512 is implemented) by communicating with acceleration component 506 over a local link.”), the RDRT architecture configured to:
detect a hung state of an RDU resource on the RDU, wherein the RDU resource is selected from at least one of: an RDU tile, an RDU die, or the RDU (From paragraph 129-134, “Method 1400 includes detecting an error in a role at the acceleration component by comparing actual behavior of the role to defined legitimate behavior for the role, the acceleration component included in a group of interoperating acceleration components in a hardware acceleration plane, roles at each acceleration component in the group of interoperating acceleration components linked together to compose a graph that provides service acceleration for a service (1401). For example, during monitoring, monitor 1304 can detect error 1341 in the operation of role 1312. A variety of different conditions may cause an error. If inputs are queued up for a specified period of time with no output (i.e., a timeout), monitor 1304 can detect that role 1302 is hung. Output properties, divide by zero exceptions, and other performance characteristics of role 1312 can also indicate errors in the operation of role 1312. In some aspects, monitor 1304 compares monitored behavior of role 1312 against defined legitimate behavior for 1312 to determine if there is an error in the operation of role 1312. Method 1400 includes pausing input to the role (1402). For example, monitor 1304 can send pause command 1342 to role 1312. Pause command 1342 instructs role 1312 to pause incoming data. Turning to FIG. 13B, communication 1361 and 1363 are paused. However, communication 1362 and 1364 continue to output data to role 1312. Any data output to role 1312 can be buffered until legitimate behavior of role 1312 restored. Method 1400 includes locally sending a reset command to the role within the acceleration component (1403). For example, monitor 1304 can send reset 1343 to role 1312. Reset 1343 resets role 1312 by resetting internal state of acceleration component 1302 corresponding to role 1312. Any partially processed service data can be buffered prior to reset. If partially processed data cannot recovered, a NACK or synthetic response for the data can be propagated back to the originator. A synthetic response can include a NULL result and/or debug information. Method 1400 includes receiving an acknowledgment from the role, the acknowledgement indicating that the role was successfully restarted (1404). For example, monitor 1304 can receive ACK 1344 from role 1312. When role 1312 is reset, ACK 1344 is returned to monitor 1304. ACK 1344 indicates to monitor 1304 that reset 1343 was successful. Method 1400 includes enabling input to the role in response to receiving the acknowledgment (1405). For example, monitor 1304 can send resume command 1346 to role 1312. Resume command 1346 instructs role 1312 to resuming handling of incoming data. Turning to FIG. 13C, communication 1361 and 1363 are resumed. Since role 1312 was reset (restored) locally, service manager 1322 may be unware that error 1341 even occurred. For example, buffers used by acceleration components 1301, 1302, and 1303 may have been sufficient to buffer data until role 1312 was restored. As such, service manager 1322 does not detect any incorrect behavior from service 1300. However, if role 1312 cannot be locally restored after some amount of time, service manager 1322 may detect incorrect behavior at graph 1333 and/or more specifically at acceleration component 1302. For example, graph 1333 can exhibit incorrect behaviors, such as, for example, non-responsiveness, performance degradation, outputting incorrect results, sending phantom packets, latency spikes, etc. In response, service manager 1322 can query the status of acceleration components 1301, 1302, and 1303 and determine an error in operation of role 1312. The error in operation of role 1312 can in turn cause the incorrect behavior exhibited by graph 1333. In response, service manager 1322 can attempt to restore role 1312 by reloading an image file (e.g., for role 1312) to acceleration component 1302.” Paragraph 168, 169, “When a datacenter application hangs for any reason, a higher level service in the service hierarchy (such as a machine that aggregates results) can notice that a set of servers are unresponsive. The higher level service can query each server to find its status. If a server is unresponsive, it is put through a sequence of soft reboot, hard reboot (e.g., image reload), and then flagged for manual service and possible replacement, until the machine starts working correctly. If the server is operating correctly, it responds to the higher level service with information about the health of its local acceleration components (e.g., one or more FPGAs) and associated links. The higher level service can return a vector with error flags for inter-FPGA (or other acceleration component) connections, DRAM status (bit errors and calibration failures), errors in the acceleration component application, PLL lock issues, PCIe errors, and the occurrence of a temperature shutdown. The call can also return the machine IDs of neighbors of an acceleration component, to test whether the neighboring acceleration components in a graph are accessible and that they are the machines that the higher level service expects (in case the cables are miswired or unplugged). Based on this information, the higher level service may update a failed machine list (including the failure type) and based on the failure location and type, determine where to re-locate various application roles on the fabric. It is possible that relocation is unnecessary, such as when the failure occurred on a spare node, or when simply reconfiguring an acceleration component in-place is sufficient to resolve the hang. The higher level service can then go through its reconfiguration process for every acceleration component involved in that service to clear out any corrupted state and map out any hardware failure or recurring failure with an unknown cause.”); and
initiate a recovery mechanism associated with the RDU resource, wherein the RDU resource is returned to an operational state from the hung state (For example, from paragraph 49-52, “In another aspect, a service manager (a higher-level software service) has a global view of a plurality of acceleration components, including the group of interoperating acceleration components as well as one or more other acceleration components. Roles at each acceleration component in the group of interoperating acceleration components are linked to compose a graph that provides service acceleration for a service. The service manager can monitor roles at each acceleration component for errors. As such, the service manager has knowledge of the graph and of roles at other acceleration components that are not available locally at the acceleration components. The service manager can use the knowledge to restore legitimate behavior for a graph and one or more roles. Thus, the service manager can detect an error in a role at an acceleration component. In response, the service manager can contact a locally linked host component or a module within the acceleration component to attempt to reset the role. Although the error is detected by the service manager (an external component), restoration is performed locally. Locally restoring a role is less resource intensive and more efficient than having the service manager restore the role. When local restoration fails, the service manager can attempt to restore the role, such as, for example, by moving the role to another acceleration component, by reloading an image for the role at the acceleration component, etc. In some aspects, an acceleration component is locally linked to a host component (e.g., a CPU), such as, for example, when the acceleration component and host component are included in the same server. In these aspects, the host component may detect an error in a role at the locally linked acceleration component. The host component can instruct the acceleration component to locally restore the role. When local restoration fails, the host component can attempt to restore the role (e.g., reloading an image for the role at the acceleration component) without involving external components (e.g., a higher-level software service). A host component restoring a role at a locally linked acceleration component can be less resource intensive (at least with respect to network bandwidth resources) and more efficient than having external components (e.g., a higher-level software service) restore the role. When restoration by a locally linked host component fails, external components (e.g., a higher-level software service, such as, a service manager) can attempt to restore the role.”).
Referring to claim 5, Heil discloses wherein the RDRT architecture configured to detect the hung state of the RDU resource on the RDU further comprises the RDRT architecture configured to: detect a timeout associated with a control-status register (CSR) on the RDU that is indicative of the RDU resource; and prevent additional portions of the workload from being processed by the RDU (Paragraph 129, 130, “Method 1400 includes detecting an error in a role at the acceleration component by comparing actual behavior of the role to defined legitimate behavior for the role, the acceleration component included in a group of interoperating acceleration components in a hardware acceleration plane, roles at each acceleration component in the group of interoperating acceleration components linked together to compose a graph that provides service acceleration for a service (1401). For example, during monitoring, monitor 1304 can detect error 1341 in the operation of role 1312. A variety of different conditions may cause an error. If inputs are queued up for a specified period of time with no output (i.e., a timeout), monitor 1304 can detect that role 1302 is hung. Output properties, divide by zero exceptions, and other performance characteristics of role 1312 can also indicate errors in the operation of role 1312. In some aspects, monitor 1304 compares monitored behavior of role 1312 against defined legitimate behavior for 1312 to determine if there is an error in the operation of role 1312. Method 1400 includes pausing input to the role (1402). For example, monitor 1304 can send pause command 1342 to role 1312. Pause command 1342 instructs role 1312 to pause incoming data. Turning to FIG. 13B, communication 1361 and 1363 are paused. However, communication 1362 and 1364 continue to output data to role 1312. Any data output to role 1312 can be buffered until legitimate behavior of role 1312 restored.”).
Referring to claim 6, Heil discloses wherein the RDRT architecture is further configured to: designate the workload as failing to execute on the RDU; transition an RDU state for the RDU to FAULTED; and initiate quiescing of the RDU resource (Paragraph 129, 130, “Method 1400 includes detecting an error in a role at the acceleration component by comparing actual behavior of the role to defined legitimate behavior for the role, the acceleration component included in a group of interoperating acceleration components in a hardware acceleration plane, roles at each acceleration component in the group of interoperating acceleration components linked together to compose a graph that provides service acceleration for a service (1401). For example, during monitoring, monitor 1304 can detect error 1341 in the operation of role 1312. A variety of different conditions may cause an error. If inputs are queued up for a specified period of time with no output (i.e., a timeout), monitor 1304 can detect that role 1302 is hung. Output properties, divide by zero exceptions, and other performance characteristics of role 1312 can also indicate errors in the operation of role 1312. In some aspects, monitor 1304 compares monitored behavior of role 1312 against defined legitimate behavior for 1312 to determine if there is an error in the operation of role 1312. Method 1400 includes pausing input to the role (1402). For example, monitor 1304 can send pause command 1342 to role 1312. Pause command 1342 instructs role 1312 to pause incoming data. Turning to FIG. 13B, communication 1361 and 1363 are paused. However, communication 1362 and 1364 continue to output data to role 1312. Any data output to role 1312 can be buffered until legitimate behavior of role 1312 restored.”).
Referring to claim 8, 12, 13, 15, 18, 19 see claims 1, 5, 6 above.
Claim Rejections - 35 USC § 103
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.
Claim(s) 2, 9, 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Heil as applied to claim 1, 8, 15 above, and further in view of “LabVIEW FPGA Compilation Process: From Run Button to Bitfile”.
Referring to claim 2, 9, 16 Heil further discloses the hung state of the RDU resource is associated with a file including instructions executable by the RDU for configuring the RDU to execute the workload (Paragraph 120, “Each of acceleration components 1301-1303 can include an array of programmable logic blocks and hierarchy of reconfigurable interconnects that allow logic blocks to be connected together in different configurations to provide different functionality (i.e., different roles). Image files can be received and loaded at acceleration component acceleration components 1301-1303 to configure programmable logic blocks and configure interconnects to provide desired functionality (i.e., roles).”).
Although Heil does not explicitly disclose this file is a bitfile with compiled instructions (even though it likely is), this is known in the art. In a related field of computing, an example of this is shown by LabVIEW, from page 1, “The process of running a user-defined application directly in silicon requires the application to be synthesized to a bitfile. Thecompilation process for FPGA devices, no matter what development software you are using, can last minutes to hours. One techniqueto reduce the amount of compilations is to simulate on the development computer and resolve any programming errors before going tohardware. However, at some point you will need to compile in order to test your application in hardware, interfacing with real signals.This paper discusses LabVIEW features and techniques you can use to view alerts about overmapping and timing errors earlier in thecompile, queue compiles, implement remote compile servers, and other pertinent information on the significant time spent betweenkicking off a compile and receiving a working bitfile.” It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide such a file for configuration because, from page 1 of LabView, “The LabVIEW FPGA Module helps developers take their designs and translate them directly to hardware, achieving higherperformance and reliability than what is achievable with a processor.” This supplies the needed file to accomplish the goal of configuration shown in Heil.
Claim(s) 3, 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Heil as applied to claim 2, 9 above, and further in view of Official notice.
Referring to claim 3, 10, Heil further discloses the RDRT architecture is further configured to: prior to initiating the recovery mechanism, managing at least a portion of the workload on the RDU (Paragraph 130-134, “Method 1400 includes pausing input to the role (1402). For example, monitor 1304 can send pause command 1342 to role 1312. Pause command 1342 instructs role 1312 to pause incoming data. Turning to FIG. 13B, communication 1361 and 1363 are paused. However, communication 1362 and 1364 continue to output data to role 1312. Any data output to role 1312 can be buffered until legitimate behavior of role 1312 restored. Method 1400 includes locally sending a reset command to the role within the acceleration component (1403). For example, monitor 1304 can send reset 1343 to role 1312. Reset 1343 resets role 1312 by resetting internal state of acceleration component 1302 corresponding to role 1312. Any partially processed service data can be buffered prior to reset. If partially processed data cannot recovered, a NACK or synthetic response for the data can be propagated back to the originator. A synthetic response can include a NULL result and/or debug information. Method 1400 includes receiving an acknowledgment from the role, the acknowledgement indicating that the role was successfully restarted (1404). For example, monitor 1304 can receive ACK 1344 from role 1312. When role 1312 is reset, ACK 1344 is returned to monitor 1304. ACK 1344 indicates to monitor 1304 that reset 1343 was successful. Method 1400 includes enabling input to the role in response to receiving the acknowledgment (1405). For example, monitor 1304 can send resume command 1346 to role 1312. Resume command 1346 instructs role 1312 to resuming handling of incoming data. Turning to FIG. 13C, communication 1361 and 1363 are resumed. Since role 1312 was reset (restored) locally, service manager 1322 may be unware that error 1341 even occurred. For example, buffers used by acceleration components 1301, 1302, and 1303 may have been sufficient to buffer data until role 1312 was restored. As such, service manager 1322 does not detect any incorrect behavior from service 1300. However, if role 1312 cannot be locally restored after some amount of time, service manager 1322 may detect incorrect behavior at graph 1333 and/or more specifically at acceleration component 1302. For example, graph 1333 can exhibit incorrect behaviors, such as, for example, non-responsiveness, performance degradation, outputting incorrect results, sending phantom packets, latency spikes, etc. In response, service manager 1322 can query the status of acceleration components 1301, 1302, and 1303 and determine an error in operation of role 1312. The error in operation of role 1312 can in turn cause the incorrect behavior exhibited by graph 1333. In response, service manager 1322 can attempt to restore role 1312 by reloading an image file (e.g., for role 1312) to acceleration component 1302.”).
Although Heil and LabView does not specifically disclose managing may including retrying, this is very well known in the art. In a related field of computing, examiner takes official notice for retrying. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to retry because it allows a level of recovery isolated to the instruction.
Allowable Subject Matter
Claims 4, 7, 11, 14, 17, 20 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Referring to claim 4, the prior art does not teach or fairly suggest wherein the RDU is one of multiple RDUs being used to execute the workload, and wherein the RDRT architecture configured to retry at least a portion of the workload further comprises the RDRT architecture configured to: rollback execution of the workload to a last successful checkpoint specified in the bitfile, in the scope and context of claims 1-3.
Referring to claim 7, the prior art does not teach or fairly suggest wherein the RDRT architecture is further configured to: cycle through a selection of a first RDU resource in order of: the RDU tile, the RDU die, the RDU, and an RDU system including the RDU; reset the first RDU resource using a control mechanism for the RDU resource included in the RDU system; when the control mechanism for resetting the RDU resource results in the RDU returning to the operational state, stop cycling through the selection, else continue cycling through the selection; and when the cycling through the selection of the first RDU resource does not result in the RDU returning to the operational state, initiate a power reset of the RDU system, in the scope and context of claim 1.
Referring to claims 11, 14, 17, 20 see claims 4, 7 above.
Response to Arguments
Applicant's arguments filed 28 July 2026 have been fully considered but they are not persuasive.
Regarding Applicant’s argument (page 9) that the RDU is physical, further arguing that a human cannot detect a hung state of a die, for example, a human may detect the color of a car as a step of observation, evaluation, judgment, or opinion.
Applicant further argues that a human cannot return failed hardware to an operational state. The claim as written does not describe any specific mechanisms by which this occurs, save a generic “recovery mechanism” which merely describes the intended result. So to is returning to an “operational state” an intended result rather than a specific mechanism. As rejected above and previously, this is a generic “apply it” type step. As claimed, this merely says that you’ve detected a problem and you want to do “something” to fix it.
Regarding the “telling” difference in eligibility rejections applied between the claims, Applicant should note that the claims are also different. Elements in isolation do not form the basis of the entirety of analysis.
Regarding Applicant’s argument (page 9) that the claims integrate, again pointing out a return to “operational state”, see above where this additional step is insignificant and extrasolution.
Regarding the comparison to Enfish, while returning to operational state is an improvement for the RDU, the invention itself is directed to detection and insignificantly a correction step.
Regarding the comparison to McRO, as above, the claims herein describe a non-specific, generic technological process at best.
Regarding Applicant’s argument (page 9) that the ordered combination of detecting and initiating is not well-understood, routine, or conventional and that no evidence was cited in support of this combination, Attorney has apparently misapprehended the Berkheimer ruling and ordered combination analysis. Firstly, regarding “evidence”, see citation from MPEP. Secondly, ordered combination arguments are regarding the combination of additional elements, of which there is essentially only one. The generic computer, to the extent that it is even present, covers the span of the invention and would merely be the generic element that would perform generic recovery. Thirdly, Applicant appears to be treating the first detection step as an additional element that is part of such an ordered combination, which it is not. It was identified as an abstract element. However, even if it were considered an additional element, there is no requirement that the combination of additional elements be presented in a single piece of evidence.
Regarding Applicant’s argument (page 10) that the claimed interconnect topology is absent, as cited from Heil at paragraphs 56 and 79, there is disclosed a software plane that is connected to a hardware acceleration plane, where software host components are locally linked to corresponding acceleration components. Each AC performs a portion of a requested service, which is the claimed “workload”, and this “local link” is the claimed “local interconnect”. The claimed “system interconnect” that the host uses is the means by which one host in Heil can connect to AC’s that are not locally linked. This is what paragraph 79 refers to when discussing the spread of a service over a plurality of AC’s and using one AC as an initial point of contact. From the point of view of an indirectly contacted AC, that indirect connection would form the local interconnect and the direct connection between a host and an initially contacted AC would be the system interconnect coupled to that local interconnect. Applicant may read further at, for example, paragraphs 65-67.
Regarding Applicant’s argument (page 10) that Heil discloses a hung role and not a hung hardware RDU resource, Applicant indicates that the “specification makes clear” what an RDU is. This was not claimed.
Regarding Applicant’s argument (page 10-11) that Heil does not disclose a CSR timeout and instead detects a hung role “behaviorally”, Applicant goes on to argue how the “specification describes” CSR-based detection. This was not claimed.
Regarding Applicant’s argument (page 11) that Heil does not disclose a faulted state transition or quiescing, Applicant goes on to argue how the “specification describes” faulted and quiescing. This was not claimed.
Regarding Applicant’s argument (page 11) regarding official notice, the common knowledge or well-known in the art statement is taken to be admitted prior art because applicant either failed to traverse the Examiner’s assertion of official notice or because the traversal was inadequate. If the traversal was inadequate, it is because the Applicant has not included any (adequate) statement as to why the noticed fact is not considered to be common knowledge or well-known in the art. See MPEP 2144.03C. The “substitution” noted by Applicant merely forms the nexus for combination.
Conclusion
THIS ACTION IS MADE FINAL. 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 GABRIEL L CHU whose telephone number is (571)272-3656. The examiner can normally be reached weekdays 8 am to 5 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, Ashish Thomas can be reached at (571)272-0631. 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.
/GABRIEL CHU/Primary Examiner, Art Unit 2114
Prosecution Insights