Prosecution Insights
Last updated: October 02, 2026
Application No. 17/965,504

ISOLATED EXECUTION MECHANISM FOR CROSS-PLATFORM HARDWARE MANAGEMENT AGENT

Final Rejection §103§112
Filed
Oct 13, 2022
Priority
Sep 26, 2022 — CN 202211180449.1
Examiner
WU, BENJAMIN C
Art Unit
2100
Tech Center
2100 — Computer Architecture & Software
Assignee
Dell Products L.P.
OA Round
2 (Final)
87%
Grant Probability
Favorable
3-4
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 87% — above average
87%
Career Allowance Rate
472 granted / 540 resolved
+32.4% vs TC avg
Strong +16% interview lift
Without
With
+16.4%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
21 currently pending
Career history
559
Total Applications
across all art units

Statute-Specific Performance

§101
19.2%
-20.8% vs TC avg
§103
51.4%
+11.4% vs TC avg
§102
0.8%
-39.2% vs TC avg
§112
14.5%
-25.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 540 resolved cases

Office Action

§103 §112
Notice of Pre-AIA or AIA Status 1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 2. This office Action is in response to the reply filed on 12/17/2025. 3. Claims 1-16 are pending. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. 4. Claims 1–16 are rejected under 35 U.S.C. 112(a), as failing to comply with the written description requirement. The claims contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention. 5. As to independent claims 1 and 8, they recite the limitation of “without traversing the primary, in-band I/O data path.” However, this limitation is not supported by the specification as the specification fails to disclose entirely (the feature of) “managing the OS domain resource from the OS-isolated environment via the SBM bridge … without traversing the primary, in-band I/O data path.” In page 10 of Applicant’s specification, the specification merely describes that “Some devices and industry standards (such as NVMe-25 MI) can leverage the MCTP-over-PCIe VDM to provide the management interface to avoid the in-band software dependency. PCIe VDMs are separate from in-band PCIe traffic, though they share the same physical connection” without describing that “managing the OS domain resource” is performed WITHOUT TRAVERSING the in-band data path or connection. Therefore, claims 1–16 contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed inventions. The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. 6. Claims 1–16 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention and as being incomplete for omitting essential elements, such omission amounting to a gap between the elements. See MPEP § 2172.01. a. Specifically, the following term(s) and/or phrase(s) in the claim language is/are indefinite owing to one or more omitted elements of the claimed steps. i. As to claims 1, the expression: “without exposing host OS privilege and without traversing the primary, in-band I/O data path.” fails to interrelate essential elements of the invention, with respect to other elements of the claim, and thus is indefinite. Specifically, the claim does not set forth nor delineate the “host OS privilege” and “in-band I/O data path” in the context of the claimed “sideband management (SBM) bridge” “OS domain resource” and “OS-isolated environment.” For example, it is unclear whether the “host OS privilege” is a specific feature or characteristic of the claimed SBM bridge, OS domain resources, or OS-isolated environment. b. Appropriate corrections are therefore required. Claim Rejections - 35 USC § 103 7. 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. A. 8. Claims 1–5 and 9–13 are rejected under 35 U.S.C. 103 as being unpatentable over US 20100125653 A1 – hereinafter “Cherian”, in view of US 20220052904 A1– hereinafter “Howard”. 9. With respect to claim 1, Cherian teaches, A method, comprising: (¶ 51: FIG. 3 illustrates a method of sharing storage resources on a server-based system in a flow chart form, in accordance with an embodiment of the present disclosure) initializing a sideband management (SBM) bridge coupled to a system bus of an information handling system to identify an operating system (OS) domain resource as a sideband-manageable resource; (¶ 40: Management controller 240 functions similarly to information handling system 100. In the embodiment illustrated in FIG. 2, management controller 240 includes a CPU 241, a PCIe RC 242, a PCIe switch 244, a PCIe EP 245, a primary transport management module (PTMM) 246, and a storage management module (SMM) 247… RC 242 forms a definitional boundary of a PCIe domain 243 that includes switches 244, and 250, EPs 218, 228, and 245, physical function 232, and virtual functions 233 and 234. As such, RC 242 is coupled to switch 244, switch 244 is coupled to EP 245 and to switch 250. In this way, PCIe domain 243 couples together the various elements of server-based system 200 (e.g., servers 210 and 220, storage resource 230, and management controller 240). EP 245 can function as a host bus adapter, providing a network interface similar to network interface 190, or a storage interface similar to disk controller 150; ¶ 45: PHBA 219 operates to permit data transfers between PCIe domains 213 and 243, and PHBA 229 operates to permit data transfers between PCIe domain 223 and 243… In a non-limiting example, PHBAs 219 and 229 can be in the form of one or more integrated devices included in server 210, in the form of an add-in card in server 210, or any combination thereof; ¶ 47: Similarly, when RC 242 detects EP 228, PTMM 246 determines that EP 228 is part of PHBA 229, creates virtual function 234 on storage resource 230, and sends the bus, device, and function (e.g., the bus:dev:func address) of virtual function 234 to PHBA 229, creating a communication channels 270 between server 220 and storage resource 230 and server 220 thereafter store and retrieve data from storage resource 230 through communication channels 270 by initiating a peer-to-peer transaction between EP 228 and virtual function 234; ¶ 48: In one embodiment, detection of PHBAs 219 and 229 occurs during the initialization and boot process of management controller 240. In this case, PHBAs 219 and 229 include an option ROM that includes code that is executed by management controller 240 when RC 242 initializes PCIe domain 243; ¶¶ 51–52: When a storage resource is coupled to the server-based system, such as when storage resource 230 is installed in server-based system 200 (the "YES" branch of decision tree 304), a decision is made as to whether or not the storage resource is an SR-IOV enabled storage resource at decision tree 306. If not (the "NO" branch of decision tree 306), processing ends at block 308. If the storage resource is an SR-IOV enabled storage resource (the "YES" branch of decision tree 306), a virtual function is created on the storage resource in block 310). Examiners note: The PCIe Host Bridge adapters (PHBAs - PHBA 219 and PHBA 229) serve the function of the claimed “sideband management (SBM) bridge”. The PHBAs bridge communication between distinct PCIE domains (213 and 243, 223 and 243, respectively). Storage resources are identified as manageable resources if a virtual function is created on the resource. If the storage resource goes through the process of figure 3 it is effectively identified as a manageable resource. associating an OS-isolated environment with the SBM bridge; (¶ 4: The Peripheral Component Interconnect-Express (PCIe) standard for connecting resources to an information handling system includes a Single Root I/O Virtualization (SR-IOV) mechanism, whereby a particular PCIe device can be accessed by several virtual machines on the same information handling system. An SR-IOV enabled PCIe device includes a physical function that is directly accessible to the information handling system. The SR-IOV enabled PCIe device also includes the ability to create one or more virtual functions that can be associated with different virtual machines. In this way, a single I/O resource can be accessed by the different virtual machines without creating contention within the I/O resource; ¶ 47: PTMM 246 then creates virtual function 233 on storage resource 230, and sends the bus, device, and function (e.g., the bus:dev:func address) of virtual function 233 to PHBA 219, thus creating a communication channel 260 between server 210 and storage resource 230 ¶ 39: virtual functions 233 and 234 are created in storage resource 230 in accordance with the PCI Special Interest Group (PCI-SIG) Single Root I/O Virtualization and Sharing 1.0 specification (SR-IOV)). Cherian does not explicitly teach managing the OS domain resource from the OS-isolated environment via the SBM bridge. However, analogous art Howard teaches, a sideband management (SBM) bridge coupled to a system bus of an information handling system to identify an operating system (OS) domain resource as a sideband-manageable resource; (¶ 22: As described herein, a computing system can implement port bundling and IO virtualization concurrently by isolating and segregating port bundling operations from device functions that are accessible by a virtualization environment. Specifically, the port bundling operations can be segregated from device functions that are accessible using an interconnect (such as PCIe with the SR-IOV extension). As one example, LAG management logic can be implemented in firmware, hardware, and/or software of a network interface device and segregated from guest or host OS control. The LAG management logic can create a LACP bond to a network switch that is connected to the physical network ports of the network interface device. Individual SR-IOV VFs can be assigned to each virtual machine and/or tenant and each VF can be assigned to carry only specific VLANs for security purposes; ¶ 31: “Additionally, the virtual bonding interface 144 can include the LAG management logic 145 for managing the LAG 180. For example, the LAG management logic 145 can communicate with the LAG logic 174 of the network device 170 to implement a link bundling protocol, such as LACP. The LAG management logic 145 can initialize and maintain the LAG 180 independent of the host OS 132 ¶ 37: The physical ports 146A-B can be managed using the LAG management logic 145. For example, the LAG management logic 145 can communicate with a network device that is connected to the physical ports 146A-B over a pair of network links. The LAG management logic 145 can initiate and manage a control protocol, such as LACP, for bundling the links. The control protocol can be used to detect that different network links are connected to the same pair of devices, negotiate a speed and mode of the LAG, and monitor a status (e.g., up or down) of the links of the LAG (such as by monitoring whether a keep-live packet is received within a threshold period of time) … The bonding interface manager can communicate with the LAG management logic 145 over the physical ports 146A-B or another communication interface (not shown). For example, the bonding interface manager can include routing information, including LAG programming details for the physical ports 146A-B, for the communication network that is programmed by an administrator of the network) Examiners note: The “LAG management logic” that is implemented within the network interface device 140 (¶¶ 22, 31, 37), acts as the claimed SBM bridge. "LAG management logic 145 can initialize and maintain the LAG 180 independent of the host OS 132". associating an OS-isolated environment with the SBM bridge; (Abstract: A device function can be assigned to a virtual machine. The device function can be used for communicating between the network interface and the virtual machine via an interconnect ¶ 20: “The host OS, the hypervisor, and/or the virtual machines can communicate with input/output (IO) devices using an interconnect such as PCIe); and managing the OS domain resource from the OS-isolated environment via the SBM bridge. (¶ 3: The method also includes assigning a device function to a virtual machine, the device function used for communicating between the network interface and the virtual machine via an interconnect. The virtual machine executes on the one or more network traffic management apparatuses. The method also includes using the device function to forward network traffic between the virtual machine and the network interface, and across the link aggregation group; Abstract: A device function can be assigned to a virtual machine. The device function can be used for communicating between the network interface and the virtual machine via an interconnect. The device function can be used to forward network traffic between the virtual machine and the network interface, and across the link aggregation group; ¶ 63: FIG. 5 is a flowchart of an example method 500 for managing network ports in a virtualization environment. As one example, the method 500 can be used to manage the operation of and access to the network ports (e.g., the physical network ports 146 of a network interface device 140 of FIGS. 1-3) when an interconnect (such as PCIe) is used to transfer data between a host-network interface and a hypervisor executing one or more virtual machines; ¶¶ 65–67: At 520, a device function can be assigned to a virtual machine. The device function can be used for communicating between the network interface and the virtual machine via an interconnect (such as PCIe)… For example, the network interface device can include a physical function and multiple virtual functions. The host operating system and/or a hypervisor can assign a virtual function to the virtual machine, where the virtual machine executes within the hypervisor. Each virtual machine executing within the hypervisor can be assigned to use a different virtual function… At 530, the device function can be used to forward network traffic between the virtual machine and the network interface, and across the link aggregation group. For example, the virtual machine can send network packets across the link aggregation group, via the network interface, by writing the network packet data to an address or range of addresses of the device function. Logic within the network domain can forward the network packet from the network interface and across the LAG. The virtual machine can receive network packets from the link aggregation group, via the network interface, by reading the network packet data from an address or range of addresses of the device function… The network traffic of the different virtual machines can be transferred using the different device functions to potentially enhance a confidentiality and security of the network traffic of the virtual machines. At optional 540, a VLAN identifier can be used to forward the network traffic of the virtual machine across the link aggregation group. For example, a VLAN identifier can be selected from a group of VLAN identifiers for use by network traffic associated with the device function. The group of VLAN identifiers can be the VLAN identifiers that have not been assigned to a device function yet. The selected VLAN identifier can be assigned to the device function so that each device function has different VLAN identifiers assigned to it. In other words, each device function can have one or more VLAN identifiers assigned to the device function for its exclusive use among the device functions. By assigning unique VLAN identifier(s) to each of the device functions, the VLAN traffic associated with an identifier can be isolated to a given device function. The VLAN identifier can be used to encapsulate a network packet in a frame that is sent over the LAG. The VLAN identifier can be used to identify a device function and virtual machine associated with an ingress frame. Additionally, the VLAN identifier can be used to demultiplex ingress network traffic from the link aggregation group. Specifically, the VLAN identifier can be matched to a device function and the network traffic can be sent only to the matching device function). without exposing host OS privilege and without traversing the primary, in-band I/O data path (see Fig. 5, ¶ 63, ¶¶ 66–67, as applied above, teaching using the device function to forward network traffic between the virtual machine and the network interface, and across the link aggregation group, and using a VLAN identifier to forward the network traffic of the virtual machine across the link aggregation group, without using any OS privileging or a specific in-band I/O path or connection; See also Cherian, Fig. 2, ¶ 44 and ¶ 45, teaching that PHBA 219 operates to permit data transfers between PCIe domains 213 and 243, and PHBA 229 operates to permit data transfers between PCIe domain 223 and 243, i.e. across different domains, without using peer-to-peer operations within a particular domain). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Cherian to include associating an OS-isolated environment with the SBM bridge; and managing the OS domain resource from the OS-isolated environment via the SBM bridge using the teachings of Howard. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of addressing problems in security, availability and performance caused by scaling, all while maintaining a sideband connection from virtual machines to OS resources (Howard, 0002). 10. With respect to claim 2, Cherian and Howard teach, The method of claim 1, Cherian teaches, wherein the system bus comprises a peripheral component interconnect express (PCIe) bus and the SBM bridge comprises a PCIe bridge. (¶ 29: A method includes discovering a PCIe host bridge adapter (PHBA) and a storage resource coupled to multiple storage extents in a PCIe domain” [Abstract]; “The information handling system 100 can also include an I/O channel 112 connected to the chipset 110. The I/O channel 112 can include a Peripheral Component Interconnect (PCI) bus, a PCI-Extended (PCI-X) bus, a high-speed link of PCI-Express (PCIe) lanes, another industry standard or proprietary bus or link, or any combination thereof. In one embodiment, a PCI bus can be operated at approximately 66 MHz, a PCI-X bus can be operated at approximately 133 MHz, and a PCIe link can be operated at approximately 250 million bytes per second (MB/s) per lane in each direction). 11. With respect to claim 3, Cherian and Howard teach, The method of claim 2, Cherian teaches, wherein the SBM bridge includes a single root I/O virtualization (SR-IOV) interface (¶ 20: The host OS, the hypervisor, and/or the virtual machines can communicate with input/output (IO) devices using an interconnect such as PCIe. PCIe includes virtualization extensions, such as the single root input/output virtualization (SR-IOV) and multi-root input/output virtualization (MR-IOV) extensions for use with a virtualization environment) Cherian does not explicitly teach and wherein initializing the SBM bridge comprises initializing, by the OS domain resource, a physical function (PF) of the SBM bridge. Howard teaches, and wherein initializing the SBM bridge comprises initializing, by the OS domain resource, a physical function (PF) of the SBM bridge. (¶ 32: The host-network interface 160 can provide an interface between the interconnect 150 and the virtual bonding interface 144. For example, the host-network interface 160 can implement the device function(s) 162. As one example, the interconnect 150 can be a PCIe interconnect, and the device function(s) 162 can include one or more of physical function(s), virtual function(s), or combinations thereof). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Cherian to include wherein initializing the SBM bridge comprises initializing, by the OS domain resource, a physical function (PF) of the SBM bridge using the teachings of Howard. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of addressing problems in security, availability and performance caused by scaling, all while maintaining a sideband connection from virtual machines to OS resources (Howard, ¶ 2). 12. With respect to claim 4, Cherian and Howard teach, The method of claim 3, Howard teaches, wherein associating the OS- isolated environment with the SBM bridge comprises assigning a virtual function (VF) of the SBM bridge to the OS-isolated environment. (Abstract: A device function can be assigned to a virtual machine. The device function can be used for communicating between the network interface and the virtual machine via an interconnect; ¶ 20: The host OS, the hypervisor, and/or the virtual machines can communicate with input/output (IO) devices using an interconnect such as PCIe; ¶ 34: For example, the hypervisor can assign each virtual machine to a different virtual function 216 for accessing the network interface device 140). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Cherian to include wherein associating the OS- isolated environment with the SBM bridge comprises assigning a virtual function (VF) of the SBM bridge to the OS-isolated environment using the teachings of Howard. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of addressing problems in security, availability and performance caused by scaling, all while maintaining a sideband connection from virtual machines to OS resources (Howard, 0002). 13. With respect to claim 5, Cherian and Howard teach, The method of claim 1, Howard teaches, wherein the OS-isolated environment comprises a virtual machine (VM) (Abstract: Technology related managing network ports in a virtualization environment is disclosed. In one example, a method includes, without using operating system control, bonding a plurality of physical ports into a link aggregation group accessible from a network interface. A device function can be assigned to a virtual machine). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Cherian to include wherein the OS-isolated environment comprises a virtual machine (VM) using the teachings of Howard. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of addressing problems in security, availability and performance caused by scaling, all while maintaining a sideband connection from virtual machines to OS resources (Howard, 0002). 14. With respect to claim 9, it is the corresponding system claim of claim 1, therefore it is rejected for the same reason as claim 1 above. Furthermore Cherian teaches the claimed elements, An information handling system, comprising: a central processing unit (CPU); and a memory, accessible to the CPU, including processor executable program instructions that, when executed by the CPU, cause the system to perform operations including: (¶ 26: The information handling system can include memory (volatile (e.g. random access memory (RAM), etc.), nonvolatile (read only memory (ROM), flash memory, etc.), or any combination thereof), one or more processing resources, such as a central processing unit (CPU), hardware, firmware, or software control logic, or any combination thereof” [0013]; “FIG. 1 illustrates a functional block diagram of an exemplary embodiment of an information handling system, generally designated as 100. The information handling system 100 can include a processor 102 coupled to a host bus 106, and can further include one or more additional processors, generally designated as an n.sup.th processor 104, coupled to a host bus 108). 15. With respect to claim 10, it is the corresponding system claim of claim 2, therefore it is rejected for the same reason as claim 2 above. 16. With respect to claim 11, it is the corresponding system claim of claim 3, therefore it is rejected for the same reason as claim 3 above. 17. With respect to claim 12, it is the corresponding system claim of claim 4, therefore it is rejected for the same reason as claim 4 above. 18. With respect to claim 13, it is the corresponding system claim of claim 5, therefore it is rejected for the same reason as claim 5 above. B. 19. Claim 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over US 20100125653 A1 – hereinafter “Cherian”, in view of US 20220052904 A1– hereinafter “Howard”, further in view of US 20220398081 A1 – hereinafter “Ragupathy”. 20. With respect to claim 6, Cherian and Howard teach, The method of claim 1, Cherian and Howard do not explicitly teach wherein the OS-isolated environment comprises a rootless container. Ragupathy teaches, wherein the OS-isolated environment comprises a rootless container. (¶ 9: According to the solution described herein, applications may be run with distroless base images designed for a variety of different processor architectures (e.g., x86, x86-64, ARM, AArch64, and/or the like), all of which comply with a specification of the Open Container Initiative. Accordingly, applications can be run as rootless containers and/or daemonless containers without any extra resource utilization on the target). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Cherian and Howard to include wherein the OS-isolated environment comprises a rootless container using the teachings of Ragupathy. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of mitigating or minimizing security vulnerabilities that might be caused by deploying containers in a privileged or root environment (Ragupathy, ¶ 8). 21. With respect to claim 14, it is the corresponding system claim of claim 6, therefore it is rejected for the same reason as claim 6 above. C. 22. Claim 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US 20100125653 A1 – hereinafter “Cherian”, in view of US 20220052904 A1– hereinafter “Howard”, further in view of US 20220019560 A1 – hereinafter “Durairaj”. 23. With respect to claim 7, Cherian and Howard teach, The method of claim 1, Cherian and Howard do not explicitly teach wherein the SBM bridge is configured to pass management component transport protocol (MCTP) messages among the OS-isolated environment, the host OS, and the system bus. Durairaj teaches, wherein the SBM bridge is configured to pass management component transport protocol (MCTP) messages among the OS-isolated environment, the host OS, and the system bus. (¶ 66: In some embodiments, remote access controller 255 may support monitoring and administration of various devices 220, 225, 230 of an IHS via a sideband interface. In such embodiments, the messages in support of the monitoring and management function may be implemented using MCTP (Management Component Transport Protocol) that may be transmitted using I2C sideband bus connection 275a-c established with each of the respective managed devices 220, 225, 230. As illustrated, the managed hardware components of the IHS 200, such as FPGA cards 220, network controller 225 and storage controller 230, are coupled to the IHS processor(s) 205 via an in-line bus 215, such as a PCIe root complex, that is separate from the I2C sideband bus connection 275a-c; ¶ 73: In type-2 or hosted hypervisor implementations, server IHS 100 executes operating system (OS) 302 (e.g., Windows Server, Mac OS X Server, variants of Linux, etc.), which in turn enables execution of hypervisor 303 (e.g., Parallels, VMware workstation, etc.) configured to create and run VMs 304A-M at the request of clients 200A-N. In type-1 or bare-metal implementations, however, OS 301 may be absent and hypervisor 303 (e.g., HyperV, VMware ESXi, etc.) may run directly on hardware 100. In some cases, two or more of VMs 304A-N may be executed on behalf of the same client IHS 200A). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Cherian and Howard to include wherein the SBM bridge is configured to pass management component transport protocol (MCTP) messages among the OS-isolated environment, the host OS, and the system bus using the teachings of Durairaj. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of providing an OS isolated environment a way to communicate and take advantage of the processing, compilation, and communication power of an IHS (Durairaj, ¶ 2). 24. With respect to claim 15, it is the corresponding system claim of claim 7, therefore it is rejected for the same reason as claim 7 above. D. 25. Claim 8 and 16 is rejected under 35 U.S.C. 103 as being unpatentable over US 20100125653 A1 – hereinafter “Cherian”, in view of US 20220052904 A1– hereinafter “Howard”, further in view of US 20220019474 A1 – hereinafter “Kumar”. 26. With respect to claim 8, Cherian and Howard teach, The method of claim 1, Cherian and Howard do not explicitly teach wherein managing the OS domain resource comprise invoking an agent of the OS- isolated environment to execute the hardware management software. Kumar teaches, wherein managing the OS domain resource comprise invoking an agent of the OS- isolated environment to execute the hardware management software (¶ 46: The HMSs 208, 214 of the corresponding physical racks 202, 204 interface with virtual rack managers (VRMs) 225, 227 of the corresponding physical racks 202, 204 to instantiate and manage the virtual server rack 206 using physical hardware resources 224, 226 (e.g., processors, network interface cards, servers, switches, storage devices, peripherals, power supplies, etc.) of the physical racks 202, 204; ¶ 173: An example boot process of the virtual server rack 206 (FIGS. 2 and 4) includes an HMS bootup sequence, a PRM bootup sequence, and an HMS-PRM initial handshake. In an example HMS bootup sequence, when the management switch 207, 213 on which the HMS 208, 214 runs is powered-on and the OS of the management switch 207, 213 is up and running, a bootstrap script to initialize the HMS 208, 214 is executed to fetch and install an HMS agent software installer on the management switch 207, 213 to instantiate the HMS 208, 214. The HMS agent software installer completes install and initialization of the HMS agent software bundle and starts the HMS agent daemon to instantiate the HMS 208, 214. When the HMS agent daemon is started, the HMS 208, 214 determines the inventory of the physical resources 224, 226 of the physical rack 202, 204). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Cherian and Howard to include wherein managing the OS domain resource comprise invoking an agent of the OS- isolated environment to execute the hardware management software using the teachings of Kumar. It would have been obvious to a person having ordinary skill in the art to make this combination, with a reasonable expectation of success, for the purpose of providing ready access to the hardware resources required to run the OS isolated environments, enabling the IHS to provide faster, scalable deployment and lifecycle management to the OS isolated environments (Kumar, 0003). 27. With respect to claim 16, it is the corresponding system claim of claim 8, therefore it is rejected for the same reason as claim 8 above. Response to Arguments 28. Applicant’s arguments with respect to the claims have been considered but are moot because the arguments do not apply to any of the newly applied teachings or references being used in the current rejection. In the Remarks, the Applicant also contends the following: a. Cherian's PHBAs are in-band I/O resources that facilitate shared storage and support peer-to-peer data transactions between inter-domain PCIe endpoints. b. Virtual functions discussed in Cherian do not convert an OS domain resource into a “sideband-manageable resource” and do not expose a sideband management channel to any VM or container. c. Cherian does not teach or suggests “initializing an SBM to identify an OS domain resource as a sideband-manageable resource.” The Examiner disagrees. As to (a), as noted in the rejections, Cherian teaches in Fig. 2, ¶ 44 and ¶ 45, that PHBA 219 operates to permit data transfers between PCIe domains 213 and 243, and PHBA 229 operates to permit data transfers between PCIe domain 223 and 243, i.e. across different domains, without using peer-to-peer operations within a particular domain. Resources within a specific domain may be reasonably understood as “in-band” I/O resources. As to (b), in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e. convert an OS domain resource into a “sideband-manageable resource” and exposing a sideband management channel to any VM or container) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). As to (c), Cherian teaches or suggests this limitation in the rejected claims, wherein Cherian teaches in ¶ 47, that as part of initializing the PCIe domains and PHBAs “when RC 242 detects EP 228, PTMM 246 determines that EP 228 is part of PHBA 229, creates virtual function 234 on storage resource 230, and sends the bus, device, and function (e.g., the bus:dev:func address) of virtual function 234 to PHBA 229, creating a communication channels 270 between server 220 and storage resource 230 and server 220 thereafter store and retrieve data from storage resource 230 through communication channels 270 by initiating a peer-to-peer transaction between EP 228 and virtual function 234.” That is, the PHBAs are sent the bus, device, and function addresses (identifying information) of virtual functions so as to identify the specific storage resources on another domain for “servers 210 and 220 to request access to storage resource 230 after the initialization and boot process” (see Cherian, ¶ 48). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. (a) Abraham et al., US 2014/0229769 A1, teaching PCIe Input/Output device operable to perform Single Root I/O Virtualization (SR-IOV). Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, 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 extension fee 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 BENJAMIN C WU whose telephone number is (571)270-5906. The examiner can normally be reached Monday through Friday, 8:30 A.M. to 5:00 P.M.. 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, Aimee J. Li can be reached on (571)272-4169. 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. /BENJAMIN C WU/Primary Examiner, Art Unit 2195 August 7, 2026
Read full office action

Prosecution Timeline

Oct 13, 2022
Application Filed
Jun 16, 2025
Non-Final Rejection mailed — §103, §112
Dec 17, 2025
Response Filed
Aug 10, 2026
Final Rejection mailed — §103, §112
Aug 28, 2026
Interview Requested
Sep 17, 2026
Applicant Interview (Telephonic)
Sep 17, 2026
Examiner Interview Summary

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12717638
LOAD MANAGEMENT SYSTEM FOR DEVICE TO OPTIMIZE USER EXPERIENCE
3y 4m to grant Granted Aug 25, 2026
Patent 12717879
TARGETED CLUSTERING SYSTEM AND METHOD
2y 8m to grant Granted Aug 25, 2026
Patent 12699611
Statistics and Feedback-Based Scan Framework for Cluster Nodes
2y 3m to grant Granted Aug 04, 2026
Patent 12688073
ADAPTABLE RESPONSE TIME PREDICTION FOR STORAGE SYSTEMS UNDER VARIABLE WORKLOADS
3y 10m to grant Granted Jul 21, 2026
Patent 12688067
GRAPHICS PROCESSING UNIT RESOURCE MANAGEMENT METHOD, APPARATUS, AND DEVICE, STORAGE MEDIUM, AND PROGRAM PRODUCT
3y 0m to grant Granted Jul 21, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
87%
Grant Probability
99%
With Interview (+16.4%)
2y 11m (~0m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 540 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month