DETAILED ACTION
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 amendment filed on , wherein claims 1, 3, 5-9, 11-16, 18, 20-22, 24, and 28-30 are pending.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claim 1, 3, 5, 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]:
Based on content written to a hardware resource manager register by a virtualized execution environment that requests to reserve one or more device resources [cpu thread/system memory space/disk drive] corresponding to a permitted range of contents for the virtualized execution environment (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 refers 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.),
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 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 does not explicitly teach based on content in a hardware resource manager register , 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 written to a hardware resource manager register [IA32_PQR_ASSOC MSR or PQR] 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 content written to a hardware resource manager register, allocate the requested one or more device resources as shared or exclusive to Neiger and Tsirkin with based on content written to a hardware resource manager register, 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 claims 11 and 18, they are the product and apparatus claims of method claim 1. 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 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 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 claim 12, 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 contain 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 virtualized execution environment 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 the policy of exclusive allocation of resources comprises reservation of resources for the virtualized/logical entity based on a priority level of the virtual/logical entity (pg. 3339, “….priority…software policy for extensibility COS0 ….as the highest priority COS, followed by COS1…”) and
the policy of shared use of resources comprises reservation of resources shared by the logical/virtual entity with a second logical/virtual entity (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.
Claim 6-8, 14-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 6, Neiger teaches based on the content being within the permitted range, permitting allocation of the requested one or more device resources (paragraph 29).
While Intel SDM also teaches mapping the content of the register to a mapping table. Neiger, Tsirkin and Intel SDM do not explicitly teach remapping the content based on a remapping table.
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 table 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 table 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 14, it contain similar limitations as claim 6 above. Thus, it is rejected under the same rationales.
As for claim 7, Neiger teaches the control structure and tables comprises a Virtual Machine Control Structure and the VMCS includes indicators for one or more VEEs (paragraph 25).
Herdrich teaches control structure is the remapping table comprises 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 one or more virtualized execution environments (paragraph 33-34).
As for claim 15, it contains similar limitations as claim 7 above. Thus, it is rejected under the same rationales.
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).
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 3, 5-9, 11-16, 18, 20-22, 24, 28-30 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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