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 .
Detailed Action
Response to Arguments
Applicant's arguments filed 1/8/2026 have been fully considered but they are not persuasive.
With respect to the amendment to claims 9 and 16, the Examiner has updated the rejection below to highlight that Chaganti teaches a hashing function being performed within the authentication step which reads on the broad “security limitation” of “hashing”. See rejection below for details.
With respect to the arguments on page 7 of the Remarks regarding the rejection of claims 11 and 18, the Examiner respectfully disagrees with these arguments that state that Tripathi doesn’t teach stop/prevent the crypto device from receiving power.
Paragraph 24 of Tripathi states:
“In an embodiment, the always-on component 16 may be configured to wake one or more peripheral components 18A-18n during a time that the CPU processors 30 are powered down. The peripheral components 18A-18n may perform work that the CPU processors 30 have assigned to the peripheral components 18A-18n prior to the CPU processors 30 being powered down. For example, the work may be described in data structures stored in the memory 12 (and thus the memory controller 22 may also be powered up to permit access to the memory 12). The always-on component 16 may be configured to provide information identifying the data stored in memory (e.g. pointer(s) to the data structures) to the peripheral components 18A-18n so that the peripherals may perform the work. Once the work is complete, the peripheral components 18A-18n may be returned to sleep (as may the memory controller 22).”
The highlighted sections emphasize that the peripheral components are woken from sleep (provide power to the components) to perform a task and then returned to sleep (stop/prevent power to the components) upon the completion of the task.
The Examiner notes that the “wake crypto device from sleep, perform task, and then return crypto device to sleep upon completion of the task” process maps to the process taught by the applicants Specification in paragraphs 264-265:
[0264] In some cases, the selected crypto device may be crypto device 2412 internal to OOB MCU 604. In other cases, however, the selected crypto device may be crypto device 2411. In those cases, at 2504, OOB MCU 604 may power up crypto device 2411 out of a low-power state via one or more power control FETs, VCI pin wake logic, and/or a voltage regulator while host processor(s) 602 is its low-power state. At 2505, OOB MCU 604 may send the command or an indication of the command to crypto device 2411 through internal interconnect 2401.
[0265] At 2506, OOB MCU 604 determines whether a response to the command or instruction has been received from crypto device 2411 via interconnect 2401 indicating that the command or instruction has been processed. If so, at 1207 OOB MCU 604 may power down crypto device 2411 to its low-power state via the one or more power control FETs, VCI pin wake logic, and/or voltage regulator.
The Examiner asserts that it is well-known in the computer power control arts that putting a device/component into a sleep state represents a state of stopping/preventing power to the device/component. Devices that can be put into and returned from a sleep/low-power state must have a level of ambient power (or a battery) provided in order to detect a signal trigger a return to an operation state from the sleep state.
Therefore, based on the above highlighted section of the instant Specification and Tripathi, Tripathi’s returning a component to a “sleep state” reads on the instant application’s powering down crypto device 2411 to its “low-power state”.
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 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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, 2, 4, and 6-18 are rejected under 35 U.S.C. 103 as being unpatentable over Tripathi, U.S. PGPUB No. 2015/0362980 in view of Chaganti et al. U.S. PGPUB No. 2021/0019392 in further view of Sodhi et al. U.S. PGPUB No. 2012/0179927.
Per Claim 1, Tripathi: discloses:
an Information Handling System (IHS) (Paragraph 79, System 150 can be any type of computing device), comprising:
a heterogeneous computing platform and a plurality of devices coupled to an interconnect (Figures 1, 8; communication fabric 27 and connected devices);
and an out-of band (OOB) always-on component (16) integrated into the heterogeneous computing platform (Paragraphs 21-23, Figure 1; Component 16 can be considered OOB since it receives signals from sensors 20 which is considered OOB with respect to communication fabric 27.);
wherein the OOB always-on component is configured to: receive a command; and transmit the command or an indication of the command to a device via an interconnect while a host processor is in a low-power state (Paragraphs 21-24 and 46, Figures 1 and 2; Processor 40 of the always-on component 16 receives a signal from an external device, such as one of the sensors 20 which triggers a wake-event for one of the selected peripherals 18 to perform processing while the CPU processors 30 are powered down.).
Tripathi teaches that the peripherals 18 may be any set of additional hardware functionality and can be “any set of hardware” (Paragraph 39). Tripathi does not specifically mention a microcontroller or that the peripheral devices 18 represent a “crypto” device.
However, Chaganti teaches an out-of-band manager 130 receiving commands/requests and utilizing an authentication engine 132 to perform an authentication function to determine if a request is valid/authorized prior to changing the state of components of the system/device to service the request (Paragraphs 58-63, 69-74, 163, 164; The authentication step represents a “crypto” device, as further defined in claim 9 as it addresses operational security within a distributed environment by validating whether a request is authorized prior to processing it.). Chaganti further teaches utilizing microcontrollers to perform functions of the invention (Paragraphs 60-66 and 72)
- It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the above teachings of Chaganti and Tripathi because a secure “crypto” functionality falls into Tripathi’s “any set of additional hardware functionality” for the peripherals 18 discussed in Paragraph [39] and an authentication functionality provides a level of security to the system. Additionally, would have been obvious to one having ordinary skill in the art before the effective filing date to perform the functions of Tripathi’s always-on component 16 by using a microcontroller because a microcontroller represents a computing component commonly used interchangeably with processing devices to process commands/requests. This would have been obvious since it has been held that the simple substitution of one known element for another to obtain predictable results is obvious to one of ordinary skill. See MPEP 2141, section III(B).
Tripathi teaches an interconnect (Paragraph 40; The communication fabric 27 can be any communication interconnect and protocol for communicating among the components of the SOC 10, Figure 1), but neither Tripathi nor Chaganti specifically mention the inclusion of a RISC processor or that the interconnect is a QPI bus.
However, Sodhi similarly teaches a mobile computing device (Paragraph 54) comprising always-on circuitry (Paragraphs 18-21; Deep power down logic 104 is an always-awake logic that monitors the state of the device 130.), power saving states/modes (Paragraphs 22, 23), and further teaches the utilization of RISC processors (Paragraph 37, Fig. 3B) and a QuickPath interconnect (QPI) bus (Paragraph 57, Fig. 6).
- It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to implement one of the processors of Tripathi as a RISC processor, as taught by Sodhi because both inventions may be implemented in mobile devices (Tripathi, Paragraph 79; Sodhi, Paragraph 54) and RISC are commonly used in mobile devices due to the greater power savings they provide. It further would have been obvious to implement the communication fabric of Tripathi as a QPI bus, as taught by Sodhi, because Tripathi teaches that communication fabric 27 could be any communication interconnect and protocol for communicating among the components of SoC 10 and the QPI bus protocol is a high-speed point-to-point interconnect connecting and managing functional blocks within a system-on-chip (SoC).
Per Claim 2, Tripathi discloses the IHS of claim 1, wherein the heterogeneous computing platform comprises: a System-On-Chip (SoC) (SOC 10), a Field-Programmable Gate Array (FPGA), or an Application-Specific Integrated Circuit (ASIC).
Per Claim 4, Tripathi discloses the IHS of claim 3, wherein the plurality of devices comprises at least one of: a Graphical Processing Unit (GPU), an audio Digital Signal Processor (aDSP), a sensor hub, a Neural Processing Unit (NPU), a Tensor Processing Unit (TSU), a Neural Network Processor (NNP), an Intelligence Processing Unit (IPU), an Image Signal Processor (ISP), or a Video Processing Unit (VPU) (Paragraph 39; GPU).
Per Claims 6 and 13, Tripathi discloses the IHS of claim 1, wherein the low-power state comprises an Advanced Configuration and Power Interface (ACPI) G3 state (Paragraphs 22, 32, and 33; The SoC 10 can be in various stages of power consumption, including completely turned off (corresponds to ACPI G3 state) or low-power.).
Per Claim 7, Tripathi discloses the IHS of claim 1, wherein the peripheral device comprises at least one of: a trusted execution module, a Secure Processing Unit (SPU), or an offload engine (Paragraphs 24 and 39). Chaganti teaches utilizing an authentication engine 132 to perform an authentication function to determine if a request is valid/authorized prior to changing the state of components of the system/device to service the request (Paragraphs 58-63, 69-74, 163, 164; The authentication step represents a “crypto” device, as further defined in claim 9 as it addresses operational security within a distributed environment by validating whether a request is authorized prior to processing it.). Please refer to the above rejection of claim 1 as the motivation to combine the references remains the same.
Per Claim 8, Tripathi does not specifically teach wherein the command enables remote management of the IHS. However, Chaganti teaches remote management of the IHS (Paragraphs 29, 36, 37, 51, and 53).
- It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to allow remote management of the Tripathi system in a similar manner as taught by Chaganti because always-on components are often used in network components to receive signals to way a sleeping device (such as wake-on-LAN) and can allow a remotely located administrator or troubleshooter access to a system.
Per Claims 9 and 16, Chaganti further teaches wherein the command enables a security operation selected from the group consisting of: encryption, decryption, hashing (Paragraphs 68-72 discuss that authentication tokens are used to verify the identity of a requesting entity of request received via the always-on in-band connection 140. Paragraph 73 further details that operations management engine 152 may utilize a hash function to generate authentication tokens. Paragraph 115; “the authentication token may be a hash of an identity of the entity”; Paragraph 139 teaches a hash function and a reverse hash function being used to determine an identity of a requesting entity.), creation and validation of digital signatures, creation and validation of digital certificates, creation and validation of One-Time Passwords (OTPs). Please refer to the above rejection of claim 1 as the motivation to combine the references remains the same.
Per Claims 10 and 17, Tripathi teaches the IHS of claim 1, wherein the OOB MCU is configured to, prior to transmission of the command or the indication of the command, allow the crypto device to receive power while the host processor is in the low-power state (Paragraph 24; Always-on component 16 may wake one or more peripheral components 18 during a time that the CPU processors 30 are powered down.).
Per Claims 11 and 18, Tripathi teaches the IHS of claim 10, wherein the OOB MCU is configured to, in response to a message from the crypto device that the command or the indication of the command has been processed, stop the crypto device from receiving power (Paragraph 24; Always-on component 16 may wake one or more peripheral components 18 during a time that the CPU processors 30 are powered down. Once the work is complete, the peripheral components 18 may be returned to sleep.).
Per Claim 12, Tripathi teaches:
an Out-of-Band (OOB) always-on component (16) integrated into a heterogeneous computing platform of an Information Handling System (IHS) (Paragraph 79, Figures 1 and 8; System 150 can be any type of computing device),
the OOB always-on component (16) comprising: a processing core (processor 40) distinct from any host processor (processor/CPU 14/30) of the heterogeneous computing platform and a plurality of devices coupled to an interconnect (Figures 1, 8; communication fabric 27 and connected devices);
and a memory coupled to the processing core (Fig. 2; memory 42), the memory having program instructions stored thereon that, upon execution by the processing core, cause the OOB always-on component to (Paragraph 47):
receive an Out-of-Band (OOB) command, by an OOB component integrated into a heterogenous computing platform, while every host processor of the heterogenous computing platform is in a low-power state; select one of a plurality of devices external to the OOB always-on component and integrated into the heterogeneous computing platform; and in response to selecting the second crypto device, transmit the command or an indication of the command to the second crypto device via the interconnect while every host processor of the heterogenous computing platform is in the low-power state (Paragraphs 21-24 and 46, Figures 1 and 2; Processor 40 of the always-on component 16 receives a signal from an external device, such as one of the sensors 20 which triggers a wake-event for one of the selected peripherals 18 to perform processing while the CPU processors 30 are powered down.).
select a first crypto device internal to the OOB component or a second crypto device external to the OOB MCU and integrated into the heterogeneous computing platform; and in response to selection the second crypto device, transmit the command or an indication of the command to the second crypto device while every host processor of the heterogenous computing platform is in the low-power state.
Tripathi teaches that the peripherals 18 may be any set of additional hardware functionality and can be “any set of hardware” (Paragraph 39). Tripathi does not specifically mention a microcontroller or that the peripheral devices 18 represent a “crypto” device that can be located within the always-on component.
However, Chaganti teaches an out-of-band manager 130 receiving commands/requests and utilizing an authentication engine 132 to perform an authentication function to determine if a request is valid/authorized prior to changing the state of components of the system/device to service the request (Paragraphs 58-63, 69-74, 163, 164; The authentication step represents a “crypto” device, as further defined in claim 9 as it addresses operational security within a distributed environment by validating whether a request is authorized prior to processing it. Authentication engine 132 can be located within the OOB manager 130 or externally 124.4.). Chaganti further teaches utilizing microcontrollers to perform functions of the invention (Paragraphs 60-66 and 72)
- It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the above teachings of Chaganti and Tripathi because a secure “crypto” functionality falls into Tripathi’s “any set of additional hardware functionality” for the peripherals 18 discussed in Paragraph [39] and an authentication functionality provides a level of security to the system. Additionally, would have been obvious to one having ordinary skill in the art before the effective filing date to perform the functions of Tripathi’s always-on component 16 by using a microcontroller because a microcontroller represents a computing component commonly used interchangeably with processing devices to process commands/requests. This would have been obvious since it has been held that the simple substitution of one known element for another to obtain predictable results is obvious to one of ordinary skill. See MPEP 2141, section III(B).
Tripathi teaches an interconnect (Paragraph 40; The communication fabric 27 can be any communication interconnect and protocol for communicating among the components of the SOC 10, Figure 1), but neither Tripathi nor Chaganti specifically mention the inclusion of a RISC processor or that the interconnect is a QPI bus.
However, Sodhi similarly teaches a mobile computing device (Paragraph 54) comprising always-on circuitry (Paragraphs 18-21; Deep power down logic 104 is an always-awake logic that monitors the state of the device 130.), power saving states/modes (Paragraphs 22, 23), and further teaches the utilization of RISC processors (Paragraph 37, Fig. 3B) and a QuickPath interconnect (QPI) bus (Paragraph 57, Fig. 6).
- It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to implement one of the processors of Tripathi as a RISC processor, as taught by Sodhi because both inventions may be implemented in mobile devices (Tripathi, Paragraph 79; Sodhi, Paragraph 54) and RISC are commonly used in mobile devices due to the greater power savings they provide. It further would have been obvious to implement the communication fabric of Tripathi as a QPI bus, as taught by Sodhi, because Tripathi teaches that communication fabric 27 could be any communication interconnect and protocol for communicating among the components of SoC 10 and the QPI bus protocol is a high-speed point-to-point interconnect connecting and managing functional blocks within a system-on-chip (SoC).
Per Claim 14, Tripathi discloses the OOB MCU of claim 12, wherein the program instructions, upon execution, cause the OOB MCU to select the first or second crypto devices based, at least in part, upon a look up table of that associates: (i) commands or types of commands; with (ii) the first or second crypto device or type of crypto device (Paragraphs 60, 67, 68, 71, 72, 75, and 76; Descriptor pointers 62 are used to select peripheral devices 18. The descriptor pointers may be part of the programmable configuration data 56 associated with the peripheral component 18.).
Per Claim 15, Tripathi discloses the OOB MCU of claim 12, wherein the program instructions, upon execution, cause the OOB MCU to select the first or second crypto device based, at least in part, upon a header of an OOB packet within which the command is received while the host processor is in the low-power state (Paragraphs 60, 67, 68, 71, 72, 75, and 76; Work descriptors 60 may be a data structure that describes work to be performed by the peripheral component 18.).
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 BRIAN T MISIURA whose telephone number is (571)272-0889. The examiner can normally be reached on M-F: 8-4:30PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner' s supervisor, Andrew Jung can be reached on (571) 272-3779. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/Brian T Misiura/
Primary Examiner, Art Unit 2175
Prosecution Insights