CTNF 17/134,327 CTNF 87495 DETAILED ACTION 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. The Office Action is in response to RCE filed on 7/1/2026 , wherein claims 1, 3, 5,7-9, 11-13, 15-16, 18, 20-22, 24, and 28-30 are pending. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA 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. 07-21-aia AIA Claim 1, 3, 5, 8-9, 11-13, 16, 18, 20-22, 24, and 28-30 are rejected under 35 U.S.C. 103 as being unpatentable over Neiger et al. (US PGPUB 2018/0217857), in view of Tsirkin (US PGPUB 2016/0246633), further in view of Unknown Author (“Intel 64 and IA-32 Architectures Software Developer’s Manual”, May 2019) (hereafter as “Intel SDM”) . As for claim 1, Neiger teaches a method comprising: Performing, by a virtualized device resource manager [VMM]: Translating first content, from a first guest virtual machine (VM) requesting to reserve one or more device resources, to a corresponding physical register based on first remapping data [EPT page-table hierarchy for address translations to be performed] associated with the first guest VM (paragraph 32, “….the private register space for an instance of guest software….the translations define the …translation process from physical addresses specified by the guest software (“guest-physical addresses”) to the physical addresses in system memory where the data/instructions associated with the specified addresses actually reside, as well as the access rights with which guest software may access those physical addresses…”)); Based on the first content requesting to reserve the one or more device resources [cpu thread/system memory space/disk drive] corresponding to a permitted range of contents for the first VM (paragraph 32, “….translation process from physical addresses specified by the guest software to the physical address in system memory…..as well as the access rights with which guest software may access those physical addresses…” and paragraph 33, “…different components of guest software (two different applications or two different software modules….may access different physical location of system memory….provide protection between these components by associating each such component with its own EPT table-table hierarchy…operate from different memory address spaces…driver maybe configured to access one portion of physical memory and other module ….could be configured to access a second portion…” teaching based on different requestor, they are restricted from accessing specific memory addresses. Here, present application states content can include RMID (claim 3), and RMID can refer to ID of an application that runs on a processor. (Specification paragraph 36). Here the system can determine accessibility of a request based on the identity of an application making the request, Thus, whatever the form of representation of the application ID is, whose requesting guest address translates to physical, is being used to determine if it’s in a permitted range (i.e., if the application ID is permitted to access). In addition, the alternative embodiment at paragraph 29, “…the CPU then look to the private control registers that were earlier loaded …to see…whether the specific service that has been requested by the guest software has also been enabled…”. With respect to permitted range, the Specification of present application explains content written to the register can refer to CLOS and RMID (paragraph 38), which can be priority levels or class of requesting entity or the identity of the application/requestor (paragraph 36). Thus, the BRI of the claim limitation “corresponding to a permitted range of content” includes limits based on characteristics of the requestor. Here, while Neiger does not explicitly use the words “permitted range”, paragraph 29 and 30 of Neiger teaches “look to the private control registers that were earlier loaded with VMCS information upon VM entry to see whether VMFUNC is enabled for the guest software and …whether the specific service that has been requested by the guest software has also been enabled…” and “embodiments may limit some or all services to specific privilege levels or operating modes…” which teaches limits on execution of service based on requestor related characteristic Thus, it is obvious to a person of ordinary skill before the effective filing date of the application to recognize limitation of the ability to invoke services without causing an VM exit based on privilege levels or operating modes of the source of requestor is a form of providing range-limited capability to a virtualized execution environment because functionally limiting which service can be invoked based on privilege or operating modes is functionally based on characteristic of requestor or the operating environment itself and because doing so enables improved granular control on situations that allows for executing the functionality (paragraphs 29 and 30) In view of paragraph 4 (“actual resources…cpu threads, system memory space, disk drive…”. See also, e.g., paragraph 39. These exemplary resources are forms of device resources for the virtualized execution environment.), allocating the request one or more device resources to the virtualized execution environment. (paragraph 29,”…instruction execution resources…”, in view of paragraph 4 (“actual resources…cpu threads, system memory space, disk drive…”. See also, e.g., paragraph 39. These exemplary resources are forms of device resources for the virtualized execution environment.) translating second content, from a second guest VM requesting to reserve one or more device resources, to a corresponding physical register based on second remapping data associated with the second guest VM ((paragraph 32, “….the private register space for an instance of guest software….the translations define the …translation process from physical addresses specified by the guest software (“guest-physical addresses”) to the physical addresses in system memory where the data/instructions associated with the specified addresses actually reside, as well as the access rights with which guest software may access those physical addresses…”) Examiner note the prior art teaches performing of this for each “instance of guest software”, thus, it would be obvious to a person of ordinary skill to recognize the functionality can be performed for a second instance of guest software because doing so allows for the access control for all instances of guest software running in prior art execution environment as a whole.). based on the second content requesting to reserve the one or more device resources corresponding to a permitted range of content for the second guest VM allocating the requested one or more device resources as shared or exclusive to the second guest VM ((paragraph 32, “….translation process from physical addresses specified by the guest software to the physical address in system memory…..as well as the access rights with which guest software may access those physical addresses…” and paragraph 33, “…different components of guest software (two different applications or two different software modules….may access different physical location of system memory….provide protection between these components by associating each such component with its own EPT table-table hierarchy…operate from different memory address spaces…driver maybe configured to access one portion of physical memory and other module ….could be configured to access a second portion…” teaching based on different requestor, they are restricted from accessing specific memory addresses. Here, present application states content can include RMID (claim 3), and RMID can refer to ID of an application that runs on a processor. (Specification paragraph 36). Here the system can determine accessibility of a request based on the identity of an application making the request, Thus, whatever the form of representation of the application ID is, whose requesting guest address translates to physical, is being used to determine if it’s in a permitted range (i.e., if the application ID is permitted to access). In addition, the alternative embodiment at paragraph 29, “…the CPU then look to the private control registers that were earlier loaded …to see…whether the specific service that has been requested by the guest software has also been enabled…”. With respect to permitted range, the Specification of present application explains content written to the register can refer to CLOS and RMID (paragraph 38), which can be priority levels or class of requesting entity or the identity of the application/requestor (paragraph 36). Thus, the BRI of the claim limitation “corresponding to a permitted range of content” includes limits based on characteristics of the requestor. Here, while Neiger does not explicitly use the words “permitted range”, paragraph 29 and 30 of Neiger teaches “look to the private control registers that were earlier loaded with VMCS information upon VM entry to see whether VMFUNC is enabled for the guest software and …whether the specific service that has been requested by the guest software has also been enabled…” and “embodiments may limit some or all services to specific privilege levels or operating modes…” which teaches limits on execution of service based on requestor related characteristic Thus, it is obvious to a person of ordinary skill before the effective filing date of the application to recognize limitation of the ability to invoke services without causing an VM exit based on privilege levels or operating modes of the source of requestor is a form of providing range-limited capability to a virtualized execution environment because functionally limiting which service can be invoked based on privilege or operating modes is functionally based on characteristic of requestor or the operating environment itself and because doing so enables improved granular control on situations that allows for executing the functionality (paragraphs 29 and 30) In view of paragraph 4 (“actual resources…cpu threads, system memory space, disk drive…”. See also, e.g., paragraph 39. These exemplary resources are forms of device resources for the virtualized execution environment.), allocating the request one or more device resources to the virtualized execution environment. (paragraph 29,”…instruction execution resources…”, in view of paragraph 4 (“actual resources…cpu threads, system memory space, disk drive…”. See also, e.g., paragraph 39. These exemplary resources are forms of device resources for the virtualized execution environment.), wherein: the one or more device resources comprise one or more of: cache allocation, memory bandwidth, memory allocation, accelerator usage, or processor usage (paragraph 4. See also, e.g., paragraph 39) While Neiger teaches the virtualized execution environment is issuing/requesting the service, that is clearly distinguished from the VMM (paragraph 24, “…guest software invokes the service via a specific instruction…this may be one of some number of …instructions….to invoke the service by the CPU…with a single new instruction, VMFUNC” teaches the guest, hosted by the VMM, clearly separate and distinct from the VMM is issuing the requesting instruction.), and it would be obvious to a person of ordinary skill to recognize the virtualized execution environment can be a virtual machine/container (See, paragraph 25 “…VMFUNC is enabled for the guest software/VM…”), and it’s obvious a guest can be a virtual machine or a container hosted by a VMM. Nevertheless, in the interest of compact prosecution, Examiner note Neiger does not explicitly state the guest issuing the VMFUNC instruction is a VM or a container. However, Tsirkin teaches a known method of utilizing VMFUNC to invoke a hypervisor configured service including the virtualized execution environment comprises one or more of: a virtual machine or container ( (paragraph 17 and 25, “…the virtual machine may execute a command to start the first VM function component (e.g., a VMFUNC command ), which can subsequently send a request to the hypervisor to initiate execution of the VM function without an exit …” teaches the virtual machine invoking VMFUNC). This known technique is applicable to the system of Neiger as they both share characteristics and capabilities, namely, they are directed to utilization of VMFUNC by a guest invoke hypervisor/VMM provided services/functions without causing a VM Exit. One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Tsirkin would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Tsirkin to the teachings of Neiger would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such VM instruction issuing features into similar systems. Further, applying the virtualized execution environment comprises one or more of a virtual machine or container that issues VMFUNC to Neiger with providing VMFUNC for virtualized execution environments to invoke VMM provided functions without causing virtualized environment to exit accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved VM execution speed by reducing the number of VM exits. (Tsirkin, paragraph 2). While Neiger and Tsirkin teaches allocating the requested one or more device resources to the virtualized execution environment. Neiger and Tsirkin do not explicitly teach based on content, allocating the device resources as shared or exclusive. However, Intel SDM teaches a known method of resource allocation associated with logical/virtual entities including based on content corresponding to a permitted range of content [CLOS], allocate the requested one or more device resources [cache allocation] as shared or exclusive [overlapped Bitmask/Isolated Bitmask] (Pg. 3337, Section 17.19.2, “….resource allocation based on classes of service….cache allocation for the respective application or threads is then restricted based on the class with which they are associated….each class of service can be configured using capacity bitmasks ….indicate the degree of overlap and isolation between classes. For each logical processor there is a register exposed (referred to here as the IA32_PQR_ASSOC MSR or PQR) to allow …specify a COS when an application, thread or VM is scheduled. And P3338-2229, Fig. 17-27 and “Figure 17-27 …shows examples…an overlapped case….which would allow some lower-priority threads share cache spaces with the highest priority threads….non-overlapped partitioning scheme…” here, Overlapped use of cache (which is a form of resource contemplated by present application as indicated in explicit limitations of claim 1), is understood as shared use of resources by the virtualized entity, and isolated is understood as exclusive use and this is based on the respective permitted range of CLOS for respective shared or exclusive device resource allocation stored in the hardware register.). This known technique is applicable to the system of Neiger and Tsirkin as they both share characteristics and capabilities, namely, they are directed to utilization of hardware register to manage allocation of device resources to a virtualized entity. One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Intel SDM would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Intel SDM to the teachings of Neiger and Tsirkin would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such hardware register based device resource allocation into similar systems. Further, applying based on the content, allocate the requested one or more device resources as shared or exclusive to Neiger and Tsirkin with based on first content and second content, allocating the requested one or more device resources to the virtualized execution environment accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow reduced software overhead at context swap time. (Intel SDM, Page 3337, Section 17.19.2). As for claim 3, Neiger teaches content comprises identifier that can obviously be construed as functionally equivalent to a Resource Monitoring ID (RMID) and class of service (CLOS) and wherein the permitted range comprises a permitted range of identifiers (paragraph 29. Examiner note Resource Monitoring ID corresponds to either the VEE or application that made the requestion, in another word, identity of a requestor, and class of service corresponds to the class or priority level of services, where services are understood as also a workload executing in the VEE environment (Specification at paragraph 36 in view of paragraph 1. Here, prior art determining whether the guest software running inside a virtual environment is allowed to issue the request, is a check on content of the request of whether the guest software is an entity that’s within the range of entities to make the request.). In addition, Intel SDM teaches a known method of register based access control to resource allocation for VMMs on x86 chips, including content including a Resource Monitoring ID (RMID) and class of service (CLOS) and wherein the permitted range comprises a permitted range of identifiers (Pg. 3345 – Figure 17-34 teaching the register contains both COS and RMID, and Pg 3337-3339, Section 17.19.2. permitted range is understood as the corresponding CLOS stored in the IA32-PQR-ASSOC MSR or PQR register that corresponds to shared/exclusive allocation). As for claim 5, Neiger also teaches the instructions comprises process-executed microcode (paragraph 40). In addition, Intel SDM also teaches the virtualized resource manager comprises processor-executed code determines if the content is within a permitted range (Pg. 3337-3339, the determination of the CLOS and corresponding shared or exclusive allocation of cache resources is understood as determining if it’s within a permitted range for the different types of device resource allocation.). As for claim 8, Neiger also teaches based on the content not being within the permitted range, invoking a virtual machine manager (VMM) to handle a fault (paragraph 26 in view of paragraphs 29-30, “…exception or a VM exit….” Exception and VM exit lead to VMM handling the issue. See, e.g., paragraph 5). As for claim 9, Intel SDM also teaches the reserve one or more device resources comprises writing a Resource Monitoring ID (RMID) and class of service (CLOS) to the register and wherein the CLOS indicates the requested one or more device resources (Pg. 3345 -3346, Fig. 17-34 showing IA_32PQR_ASSOC include both CLOS and RMID. Pg. 3337-3339 teaching the CLOS corresponds to the cache resources to be allocated.). As for claims 11, Neiger teaches at least one non-transitory computer-readable medium comprising instructions stored thereon, that if executed by one or more processors (claim 18 and paragraph 49), cause the one or more processors to: provide access to a virtualized execution environment to allocate resources by accessing a register associated with a resource manager (paragraph 8) by: based on a write to the register of a request from the virtualized execution environment to reserve one or more device resources, translating content to a corresponding physical register based on a remapping data associated with the virtualized execution environment (paragraph 32, “….the private register space for an instance of guest software….the translations define the …translation process from physical addresses specified by the guest software (“guest-physical addresses”) to the physical addresses in system memory where the data/instructions associated with the specified addresses actually reside, as well as the access rights with which guest software may access those physical addresses…”); reserving one or more device resources separate from causing the virtualized execution environment to exit to request to reserve one or more device resources based on a class of service of the virtualized execution environment and based on a policy specifying exclusive allocation of resources or shared use of resources (paragraph 32, “….translation process from physical addresses specified by the guest software to the physical address in system memory…..as well as the access rights with which guest software may access those physical addresses…” and paragraph 33, “…different components of guest software (two different applications or two different software modules….may access different physical location of system memory….provide protection between these components by associating each such component with its own EPT table-table hierarchy…operate from different memory address spaces…driver maybe configured to access one portion of physical memory and other module ….could be configured to access a second portion…” and paragraph 34, “…without a VM exit…” teaching based on different requestor, they are restricted from accessing specific memory addresses without causing a VM exit. Here the system can determine accessibility of a request based on the identity of an application making the request, Thus, whatever the form of representation of the application ID is, whose requesting guest address translate to physical, is being used to determine if it’s in a permitted range, such as driver vs other classes of service in exemplary paragraphs, which are understood as corresponding to class of service. In addition, the alternative embodiment at paragraph 29, “…the CPU then look to the private control registers that were earlier loaded …to see…whether the specific service that has been requested by the guest software has also been enabled…”. paragraph 29 and 30 of Neiger teaches “look to the private control registers that were earlier loaded with VMCS information upon VM entry to see whether VMFUNC is enabled for the guest software and …whether the specific service that has been requested by the guest software has also been enabled…” and “embodiments may limit some or all services to specific privilege levels or operating modes…” which can be understood as class of service. paragraph 29,”…instruction execution resources…”, in view of paragraph 4 (“actual resources…cpu threads, system memory space, disk drive…”. See also, e.g., paragraph 39. These exemplary resources are forms of device resources for the virtualized execution environment). the one or more device resources comprise one or more of: cache allocation, memory allocation, memory bandwidth allocation, accelerator usage, or processor usage (paragraph 4. See also, e.g., paragraph 39). While Neiger teaches the virtualized execution environment is issuing/requesting the service, that is clearly distinguished from the VMM (paragraph 24, “…guest software invokes the service via a specific instruction…this may be one of some number of …instructions….to invoke the service by the CPU…with a single new instruction, VMFUNC” teaches the guest, hosted by the VMM, clearly separate and distinct from the VMM is issuing the requesting instruction.), and it would be obvious to a person of ordinary skill to recognize the virtualized execution environment can be a virtual machine/container (See, paragraph 25 “…VMFUNC is enabled for the guest software/VM…”), and it’s obvious a guest can be a virtual machine or a container hosted by a VMM. Nevertheless, in the interest of compact prosecution, Examiner note Neiger does not explicitly state the guest issuing the VMFUNC instruction is a VM or a container. However, Tsirkin teaches a known method of utilizing VMFUNC to invoke a hypervisor configured service including the virtualized execution environment comprises one or more of: a virtual machine or container ( (paragraph 17 and 25, “…the virtual machine may execute a command to start the first VM function component (e.g., a VMFUNC command ), which can subsequently send a request to the hypervisor to initiate execution of the VM function without an exit …” teaches the virtual machine invoking VMFUNC). This known technique is applicable to the system of Neiger as they both share characteristics and capabilities, namely, they are directed to utilization of VMFUNC by a guest invoke hypervisor/VMM provided services/functions without causing a VM Exit. One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Tsirkin would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Tsirkin to the teachings of Neiger would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such VM instruction issuing features into similar systems. Further, applying the virtualized execution environment comprises one or more of a virtual machine or container that issues VMFUNC to Neiger with providing VMFUNC for virtualized execution environments to invoke VMM provided functions without causing virtualized environment to exit accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved VM execution speed by reducing the number of VM exits. (Tsirkin, paragraph 2). While Neiger and Tsirkin teaches allocating the requested one or more device resources to the virtualized execution environment. Neiger and Tsirkin do not explicitly teach based on content, allocating the device resources as shared or exclusive. However, Intel SDM teaches a known method of resource allocation associated with logical/virtual entities including based on content corresponding to a permitted range of content [CLOS], allocate the requested one or more device resources [cache allocation] as shared or exclusive [overlapped Bitmask/Isolated Bitmask] (Pg. 3337, Section 17.19.2, “….resource allocation based on classes of service….cache allocation for the respective application or threads is then restricted based on the class with which they are associated….each class of service can be configured using capacity bitmasks ….indicate the degree of overlap and isolation between classes. For each logical processor there is a register exposed (referred to here as the IA32_PQR_ASSOC MSR or PQR) to allow …specify a COS when an application, thread or VM is scheduled. And P3338-2229, Fig. 17-27 and “Figure 17-27 …shows examples…an overlapped case….which would allow some lower-priority threads share cache spaces with the highest priority threads….non-overlapped partitioning scheme…” here, Overlapped use of cache (which is a form of resource contemplated by present application as indicated in explicit limitations of claim 1), is understood as shared use of resources by the virtualized entity, and isolated is understood as exclusive use and this is based on the respective permitted range of CLOS for respective shared or exclusive device resource allocation stored in the hardware register.). This known technique is applicable to the system of Neiger and Tsirkin as they both share characteristics and capabilities, namely, they are directed to utilization of hardware register to manage allocation of device resources to a virtualized entity. One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Intel SDM would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Intel SDM to the teachings of Neiger and Tsirkin would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such hardware register based device resource allocation into similar systems. Further, applying based on the content, allocate the requested one or more device resources as shared or exclusive to Neiger and Tsirkin with based on first content and second content, allocating the requested one or more device resources to the virtualized execution environment accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow reduced software overhead at context swap time. (Intel SDM, Page 3337, Section 17.19.2). As for claim 18, they are claim of claim 11 above. Thus, it is rejected under the same rationales. In addition, Neiger teaches based on content in a request being within permitted range for a virtualized execution environment (paragraph 29), transfer the request from the virtualized execution environment to reserve one or more device resources. (paragraph 31, in view of paragraph 29 and paragraph 39) As for claim 12, Neiger also teaches determine whether content in the request is within a permitted range for the virtualized execution environment (paragraphs 32-33). In addition, Intel SDM also teaches determine whether content in the request is within a permitted range for the virtualized execution environment (Pg. 3337-3339, the determination of the CLOS and corresponding shared or exclusive allocation of cache resources is understood as determining if it’s within a permitted range for the different types of device resource allocation.). As for claim 20, it contains similar limitation as claim 12 above. Thus, it is rejected under the same rationales. As for claim 13, Neiger teaches content comprises identifier that can obviously be construed as functionally equivalent to a Resource Monitoring ID (RMID) and class of service (CLOS) and wherein the permitted range comprises a permitted range of identifiers (paragraph 29. Examiner note Resource Monitoring ID corresponds to either the VEE or application that made the requestion, in another word, identity of a requestor, and class of service corresponds to the class or priority level of services, where services are understood as also a workload executing in the VEE environment (Specification at paragraph 36 in view of paragraph 1. Here, prior art determining whether the guest software running inside a virtual environment is allowed to issue the request, is a check on content of the request of whether the guest software is an entity that’s within the range of entities to make the request.). In addition, Intel SDM teaches a known method of register based access control to resource allocation for VMMs on x86 chips, including content including a Resource Monitoring ID (RMID) and class of service (CLOS) and wherein the permitted range comprises a permitted range of identifiers (Pg. 3345 – Figure 17-34 teaching the register contains both COS and RMID, and Pg 3337-3339, Section 17.19.2. permitted range is understood as the corresponding CLOS stored in the IA32-PQR-ASSOC MSR or PQR register that corresponds to shared/exclusive allocation). As for claim 16, Neiger also teaches the instructions comprises process-executed microcode (paragraph 40). As for claim 21, Neiger teaches content comprises identifier that can obviously be construed as functionally equivalent to a Resource Monitoring ID (RMID) and class of service (CLOS) and wherein the permitted range comprises a permitted range of identifiers (paragraph 29. Examiner note Resource Monitoring ID corresponds to either the VEE or application that made the requestion, in another word, identity of a requestor, and class of service corresponds to the class or priority level of services, where services are understood as also a workload executing in the VEE environment (Specification at paragraph 36 in view of paragraph 1. Here, prior art determining whether the guest software running inside a virtual environment is allowed to issue the request, is a check on content of the request of whether the guest software is an entity that’s within the range of entities to make the request.). In addition, Intel SDM teaches a known method of register based access control to resource allocation for VMMs on x86 chips, including content including a Resource Monitoring ID (RMID) and class of service (CLOS) and wherein the permitted range comprises a permitted range of identifiers (Pg. 3345 – Figure 17-34 teaching the register contains both COS and RMID, and Pg 3337-3339, Section 17.19.2. permitted range is understood as the corresponding CLOS stored in the IA32-PQR-ASSOC MSR or PQR register that corresponds to shared/exclusive allocation). As for claim 22, Neiger also teaches the apparatus comprising one or more of a server [a computing system], rack of servers, or data center (Fig. 6 and paragraph 41) As for claim 24, Neiger also teaches the VM is separate from a virtual machine manager (VMM) (paragraph 24-25. Examiner note “guest software” that requests it, i.e., invokes the service, is clearly separate and distinct from the VMM that manages the guest/VM). As for claim 28, Intel SDM teaches a policy of exclusive allocation of resources comprises reservation of resources for the first guest VM based on a priority level of the first VM (pg. 3339, “….priority…software policy for extensibility COS0 ….as the highest priority COS, followed by COS1…”) and a policy of shared use of resources comprises reservation of resources shared by the first VM with the second VM (pg. 3339, “….allow some ….threads share cache space with ….threads…software policy for extensibility COS0 ….as the highest priority COS, followed by COS1…” ). As for claims 29-30, they contain similar limitations as claim 28 above. Thus, they are rejected under the same rationales . 07-21-aia AIA Claim 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Neiger et al. (US PGPUB 2018/0217857), in view of Tsirkin (US PGPUB 2016/0246633), further in view of Unknown Author (“Intel 64 and IA-32 Architectures Software Developer’s Manual”, May 2019) (hereafter as “Intel SDM”), further in view of Herdrich et al. (US PGPUB 2018/0373633) . As for claim 7, Neiger teaches the control structure and the first remapping data comprises a Virtual Machine Control Structure and the VMCS includes indicators for one or more VEEs (paragraph 25). While Intel SDM also teaches mapping the content of the register to a mapping table. Neiger, Tsirkin and Intel SDM do not explicitly teach the remapping data includes a pool of RMID values and CLOS values, wherein the CLOS values are associated with one or more device resources permitted to be allocated to the first VM (paragraph 33-34) However, Herdrich teaches a known method of register based access control to resource allocation for VMMs on x86 chips, including remapping the content based on a remapping data and based on the remapped content being within the permitted range, performing a functionality associated with device resources (paragraph 32-34, and 40 and Fig. 1). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate Herdrich’s teaching of remapping the content based on a remapping table to Neiger, Tsirkin and Intel SDM because they are both directed to handing of resource requests utilizing register based indicators for accessibility of resource in Intel x86 chips from the same assignee, and because doing so allows for expanded mapping capabilities without limited by inherent size of mapping tables (Herdrich, paragraph 34). In addition, Herdrich also teaches remapping the content based on a remapping data and based on the remapped content being within the permitted range, performing a functionality associated with device resources (paragraph 32-34, and 40 and Fig. 1). It would be obvious that since the request is routed to the L3 cache that the cache is considered allocated. It would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application to incorporate Herdrich’s teaching into Herdrich because doing so allows for expanded mapping capabilities without limited by inherent size of mapping tables (Herdrich, paragraph 34). As for claim 15, it contains similar limitations as claim 7 above. Thus, it is rejected under the same rationales. Response to Arguments 07-37 Applicants’ arguments filed on 7/1/2026 have been fully considered but they are not persuasive. Applicant argues in the Remarks dated 7/1/2026: Argument I: “…Neiger teaches…Neiger does not teach translating content from first and second guest virtual machines to corresponding physical registers based on remappings associated with respective first and second virtual machines…” (App. Arg. Pg. 7). Examiner respectfully disagrees for the following reasons: With respect to Argument I, see paragraph 6 above. In addition, Examiner note, applicant’s characterization of the prior art is directly contradicted by the explicit teaching of the prior art stating that it can translate content in a guest address space to a physical register in physical address space based on remappings associated with the specific instance of guest (paragraph 32-33). Thus, applicants’ argument is unpersuasive. Examiner’s Comments Examiner suggests applicant to consider incorporating additional elements to the claims including 1) detailed steps and objects and their relationships to implement the process between the VEEs and the RDT (Resource manager), and 2) positive recitation of additional steps performed that necessarily precludes the current claim limitations from causing a VM exit instead of the intended goal currently recited as recited in paragraphs 40-57 of Specification. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN X LU whose telephone number is (571)270-1233. The examiner can normally be reached on M-F 10am-6pm. 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, Lewis Bullock can be reached on 5712723759. 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 the Patent Portal. 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). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /KEVIN X LU/ Examiner, Art Unit 2199 /LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199 Application/Control Number: 17/134,327 Page 2 Art Unit: 2199 Application/Control Number: 17/134,327 Page 3 Art Unit: 2199 Application/Control Number: 17/134,327 Page 4 Art Unit: 2199 Application/Control Number: 17/134,327 Page 5 Art Unit: 2199 Application/Control Number: 17/134,327 Page 6 Art Unit: 2199 Application/Control Number: 17/134,327 Page 7 Art Unit: 2199 Application/Control Number: 17/134,327 Page 8 Art Unit: 2199 Application/Control Number: 17/134,327 Page 9 Art Unit: 2199 Application/Control Number: 17/134,327 Page 10 Art Unit: 2199 Application/Control Number: 17/134,327 Page 11 Art Unit: 2199 Application/Control Number: 17/134,327 Page 12 Art Unit: 2199 Application/Control Number: 17/134,327 Page 13 Art Unit: 2199 Application/Control Number: 17/134,327 Page 14 Art Unit: 2199 Application/Control Number: 17/134,327 Page 15 Art Unit: 2199 Application/Control Number: 17/134,327 Page 16 Art Unit: 2199 Application/Control Number: 17/134,327 Page 17 Art Unit: 2199 Application/Control Number: 17/134,327 Page 18 Art Unit: 2199 Application/Control Number: 17/134,327 Page 19 Art Unit: 2199 Application/Control Number: 17/134,327 Page 20 Art Unit: 2199 Application/Control Number: 17/134,327 Page 21 Art Unit: 2199 Application/Control Number: 17/134,327 Page 22 Art Unit: 2199 Application/Control Number: 17/134,327 Page 23 Art Unit: 2199 Application/Control Number: 17/134,327 Page 24 Art Unit: 2199
Prosecution Insights