DETAILED ACTION
Claims 1-20 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 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.
Claims 1-6 are rejected under 35 U.S.C. 103 as being unpatentable over Roberts et al. (US 2014/0281149 A1) in view of Matthews et al. (US 2017/0031698 A1) in further view of Chin et al. (US 2014/0007097 A1).
Regarding claims 1, Roberts teaches a computational storage unit ([0036] processor-in-memory PIM hardware 350), comprising:
a first hardware resource of a first type ([0037] shared resources such as input/output (I/O) devices and memory space, such as the memory 120 of Fig. 1 and/or the memory 220 of Fig. 1);
a second hardware resource of the first type ([0037] shared resources such as input/output (I/O) devices and memory space, such as the memory 120 of Fig. 1 and/or the memory 220 of Fig. 1).
Roberts teaches a processor-in-memory that hosts a hypervisor managing resources for client operating systems (Host OS, see [0036] and Fig. 3; which corresponds to processes associated with a user), Roberts does not explicitly teach a table mapping a user identifier (UID) for a user to a number of hardware resources of the first type; and
a reclamation unit to reclaim hardware resources based at least in part on a terminated status associated with a process associated with the user.
However, Matthews teaches VMs hosted on a hypervisor (see at least [0049]). Further, Matthews teaches a table mapping a user identifier (UID) for a user to a number of hardware resources of the first type ([0006] dynamically allocating resources of virtual machines (VMs). In certain embodiments, the system includes a plurality of VM servers configured to execute a plurality of VMs, and to execute a plurality of software applications on each of the executed VMs, where the VMs are each assigned with one of a plurality of privilege levels… the resource allocation information for the software application to be executed on the one of the executed VMs based on the privilege level of the one of the executed VMs; [0008] In certain embodiments, the first table is a VM, user and privilege (VUP) table, storing information of a plurality of VM identifications (VMIDs) corresponding to the VMs, a plurality of user identifications corresponding to users of the VMs, and the privilege levels corresponding to each of the VM identifications and each of the user identifications.; [0010] the second table is a resource allocation table (RAT) storing information of the software applications, the privilege levels, and the resource allocation information for each of the software applications corresponding to each of the privilege levels. In certain embodiments, the resource of the VM server comprises network bandwidth of the VM server, central processing unit (CPU) load of the VM server, and free system memory space of the VM server. In certain embodiments, for each of the software applications, the resource allocation information comprises information of a network bandwidth bit rate of the VM server, a CPU load percentage of the VM server, and a free memory size of the VM server.; [0073]; [0085]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Matthews with the teachings of Roberts to store resource allocation in one or more tables with a mapping relationship between a user’s VM and its resource allocation. The modification would have been motivated by the desire of being able to track resource utilization on a user basis.
Roberts nor Matthews expressly teach a reclamation unit to reclaim hardware resources based at least in part on a terminated status associated with a process associated with the user.
However, in a similar field, Chin teaches in-memory processing of user VMs (see at least Fig. 1) and storing resource configuration information in a file identifying VMs and the resources allocated at launch including processing resources, memory resources, networking resources, etc. in at least [0045]. Further, Chin teaches a reclamation unit to reclaim hardware resources based at least in part on a terminated status associated with a process associated with the user ([0131] In certain embodiments, a "reclaimable" level priority may be assigned to one or more VMs, representing the lowest priority level. The mVM can shut down a VM that is marked as "reclaimable" and reclaim all of the VM's resources and make the resources available for allocation to other higher priority VMs.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chin with the teachings of Roberts and Matthews to reclaim resources of shut down VMs to allocate to one or more VMs of other users to meet their SLAs. The modification would have been motivated by the desire of modifying resources allocation to adapt to change in demands. (See Chin’s Background)
Regarding claim 2, Matthews teaches wherein the computational storage unit is configured to limit a user device of the user to the number of hardware resources of the first type ([0045]; [0069]; [0078] FIG. 3B schematically depicts a resources allocation table (RAT) according to certain embodiments of the present disclosure. In certain embodiments, the RAT table 320 serves as the second table 144 of the management device 130. As shown in FIG. 3B, the RAT table 320 has five columns, including an application column 322, a privilege level column 324, and three resource requirement columns 326. The resource requirement columns 326 include a network requirement column 327 storing the network bandwidth bit rate information, a CPU requirement column 328 storing the CPU load percentage information, and a memory requirement column 329 storing the free memory size requirement information. Specifically, the RAT table 320 includes the 9 different resource requirements for three software applications at three different privilege levels. For example, for application 1, the resource requirements for the privilege level 1 will include the network requirement of 8 Mbps, the CPU requirement of 25%, and the memory requirement of 4 GB; the resource requirements for the privilege level 2 will include the network requirement of 5 Mbps, the CPU requirement of 10%, and the memory requirement of 2 GB; and the resource requirements for the privilege level 3 will include the network requirement of 2 Mbps, the CPU requirement of 4%, and the memory requirement of 500 MB.; [0081] The third table 146 is a table containing information of the privilege levels and corresponding permissible limit rate for each of the privilege levels.).
Regarding claim 3, Matthews teaches a first table mapping the UID for the user to a Service Level Agreement (SLA) identifier (SLA ID) and a second table mapping the SLA ID to the number of resources of the first type (Abstract: dynamically allocating resources of virtual machines (VMs) using service level agreements (SLAs) and privilege levels of users. The system includes VM servers for executing the VMs. When a software application is to be executed on one executed VM on a VM server, a management device determines, from a first table, the privilege level of each executed VM based on the SLA, and then retrieves, from a second table, the resource allocation information for the software application to be executed using the privilege level of the executed VM.).
PNG
media_image1.png
479
507
media_image1.png
Greyscale
Regarding claim 4, Chin teaches further comprising a session context indicating that the first hardware resource is used by a session of a user device of the user ([0050] Once the VMs have been launched by hypervisor 118, resource manager 122 is configured to monitor the resource allocation and resource usage of the multiple operational VMs and initiate dynamic changes to resources allocated to the VMs as and when needed. Various different conditions may be monitored to determine when a change is to be made. In one embodiment, to facilitate monitoring of the VMs, a special program (or multiple programs) referred to as a "monitor agent" (also referred to as an SLA agent) may be executed by each operational VM. For example, as shown in FIG. 1, monitor agent 124 is executed by the VMs. In certain embodiments, monitor agent 124 for a VM is configured to monitor the resource usage of the VM and convey the information to resource manager 122. Monitor agent 124 executed by a VM may convey the resource usage information for the VM to resource manager 122 at periodic programmable intervals and/or upon the occurrence of certain events. A push or a pull model may be used to communicate the resource usage information from monitor agents 124 to resource manager 122.).
Regarding claim 5, Matthews teaches further comprising a second table mapping the UID to a number of used hardware resources of the first type of the computational storage unit based at least in part on the session context ([0096] Specifically, the management device 130 may find the user associated with the VM 124 to be launched, and check the resources to be consumed by the VM 124.).
Regarding claim 6, Chin teaches wherein the reclamation unit is configured to reclaim hardware resources based at least in part on an active status associated with a user device of the user ([0060] The mVM can shut down a VM that is marked as "reclaimable" and reclaim all of the VM's resources.).
Claims 7, 8, 10-20 are rejected under 35 U.S.C. 103 as being unpatentable over Roberts et al. (US 2014/0281149 A1) in further view of Chin et al. (US 2014/0007097 A1).
Regarding claim 7, Roberts teaches a computational storage unit ([0036] processor-in-memory PIM hardware 350).
Roberts teaches a processor-in-memory that hosts a hypervisor managing resources for client operating systems (Host OS, see [0036] and Fig. 3; which corresponds to processes associated with a user), Roberts does not explicitly teach receiving a request at a computational storage unit from a user device of a user to use the computational storage unit, the request identifying a hardware resource of a first type of the computational storage unit;
determining a number of hardware resources of the first type to which the user device should have access;
limiting the user device to a maximum number of hardware resources of the first type in the computational storage unit; and
reclaiming the hardware resource based at least in part on a terminated status associated with a process associated with the user
However, in a similar field Chin teaches in-memory processing of user VMs (see at least Fig. 1 where VMs and the hypervisor are executing within the memory 104). Further, Chin teaches a method, comprising:
receiving a request at a computational storage unit from a user device of a user to use the computational storage unit, the request identifying a hardware resource of a first type of the computational storage unit (Fig. 1 shows processing of VMs in Memory 104; [0053] As described above, in certain embodiments, the VMs to be started by device 100 and the resources to be assigned to each VM when the VM is launched may be predefined and specified by a resource configuration file (RCF) and a device configuration file (DCF). The RCF may be created by a user of device 100 or by a system administrator. In one embodiment, the RCF may comprise information (e.g., rules) identifying thresholds and conditions indicating when a change is to be made and the type of change to be made.; Table A shows different types of hardware resources such as CPU cores, Memory Network Bandwidth, Network Ports, and Non-volatile memory);
determining a number of hardware resources of the first type to which the user device should have access ([0053] In some embodiments, programs executed by mVM 114, such as resource manager 122, are configured to monitor device 100, determine, based upon the information in RCF, when a change is to be made and the type of change to be made.; See Table A);
limiting the user device to a maximum number of hardware resources of the first type in the computational storage unit (Table A shows Max limit per resource); and
reclaiming the hardware resource based at least in part on a terminated status associated with a process associated with the user ([0131] In certain embodiments, a "reclaimable" level priority may be assigned to one or more VMs, representing the lowest priority level. The mVM can shut down a VM that is marked as "reclaimable" and reclaim all of the VM's resources and make the resources available for allocation to other higher priority VMs.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chin with the teachings of Roberts to reclaim resources of shut down VMs to allocate to one or more VMs of other users to meet their limits. The modification would have been motivated by the desire of modifying resources allocation to adapt to change in demands. (See Chin’s Background)
Regarding claim 8, Chin teaches wherein determining the number of hardware resources of the first type to which the user device should have access includes accessing the number of hardware resources of the first type to which the user device should have access from a table (please refer to Table A; [0056] The "Base" column identifies the base amount of a resource that is to be assigned to a VM when the VM is launched. For each resource, this column identifies the minimum or base amount of the resource that is required by a VM. Resources for a VM are not allowed to drop below their corresponding minimum or base levels. If the base set of resources for a particular VM is unavailable, then that VM may not be created. The particular VM may be started only when enough system resources, as specified by the base set of resources for that VM, are available. For example, per Table A, the base memory resource to be allocated to VM.sub.1 when VM.sub.1 is launched is 2 GB.).
Regarding claim 10, Chin teaches further comprising initializing the table with the number of hardware resources of the first type to which the user device should have access (please refer to Table A; [0056] The "Base" column identifies the base amount of a resource that is to be assigned to a VM when the VM is launched. For each resource, this column identifies the minimum or base amount of the resource that is required by a VM. Resources for a VM are not allowed to drop below their corresponding minimum or base levels. If the base set of resources for a particular VM is unavailable, then that VM may not be created. The particular VM may be started only when enough system resources, as specified by the base set of resources for that VM, are available. For example, per Table A, the base memory resource to be allocated to VM.sub.1 when VM.sub.1 is launched is 2 GB.).
Regarding claim 11, Chin teaches wherein limiting the user device to a maximum number of hardware resources of the first type in the computational storage unit includes:
determining a second number of hardware resources of the first type requested in the request, determining a third number of used hardware resources of the first type, and comparing the second number of hardware resources of the first type and the third number of used hardware resources of the first type with the number of hardware resources of the first type ([0058] The "Alloc" column in Table A identifies a condition (e.g., a threshold) when additional quantities of a resource may be dynamically allocated to the VM. In certain embodiments, when the resource utilization for a resource for a VM is at or exceeds the allocation threshold for the specified amount of time in the RCF, attempts are made to allocate additional amounts of the resource for the VM. The additional resource may be allocated from available resource pool 120 or a portion thereof may be dynamically deallocated from other one or more VMs and then allocated to the VM. In certain embodiments, resource manager 122 monitors this threshold for a VM and, based upon usage information received from a monitor agent for the VM, determines when the amount of a resource allocated to the VM is to be dynamically increased. For example, Table A indicates that the "Alloc" value for CPU cores for VM.sub.1 is "90%/60 sec". This implies that if the CPU resources allocated to VM.sub.1 are at or over 90% utilization over a period of 60 seconds, then additional CPU resources may be assigned or allocated to VM.sub.1.; [0060] The "Priority" column in Table A specifies a priority value for a VM. The priority value for a VM may be used to allocate and deallocate one or more resources for a VM. As described above, resources may be dynamically allocated to a VM from available resources pool 120. In certain embodiments, if a resource is to be allocated to a VM of a particular priority and the requisite amount of the resource is not available in available resource pool 120, resource manager 122 may check VMs with a lower priority than the particular priority to see if the requisite amount of the resource can be deallocated from one or more these VMs and then allocated to the VM with the particular priority. In one embodiment, a check is made to see if the lower priority VMs have been allocated additional resources beyond their base configuration. If so, resource manager 122 may reclaim the additional resources and make them available to the available resource pool 120 for allocation to a higher priority VM.).
Regarding claim 12, Chin teaches further comprising updating a table of hardware resources used by the user device based at least in part on the request ([0066] In certain embodiments, the mVM could synchronize with the pVM to get up to date resource allocations and update the RCF accordingly.).
Regarding claim 13, Chin teaches further comprising: receiving a second request at the computational storage unit from the user device to use the computational storage unit ([0058], [0060]), and updating the table of hardware resources used by the user device based at least in part on the second request ([0066]).
Regarding claim 14, Chin teaches wherein updating the table of hardware resources used by the user device based at least in part on the second request includes:
determining a second number of hardware resources of the first type requested in the second request, determining a third number of used hardware resources of the first type, and comparing the second number of hardware resources of the first type and the third number of used hardware resources of the first type with the number of hardware resources of the first type ([0058] The "Alloc" column in Table A identifies a condition (e.g., a threshold) when additional quantities of a resource may be dynamically allocated to the VM. In certain embodiments, when the resource utilization for a resource for a VM is at or exceeds the allocation threshold for the specified amount of time in the RCF, attempts are made to allocate additional amounts of the resource for the VM. The additional resource may be allocated from available resource pool 120 or a portion thereof may be dynamically deallocated from other one or more VMs and then allocated to the VM. In certain embodiments, resource manager 122 monitors this threshold for a VM and, based upon usage information received from a monitor agent for the VM, determines when the amount of a resource allocated to the VM is to be dynamically increased. For example, Table A indicates that the "Alloc" value for CPU cores for VM.sub.1 is "90%/60 sec". This implies that if the CPU resources allocated to VM.sub.1 are at or over 90% utilization over a period of 60 seconds, then additional CPU resources may be assigned or allocated to VM.sub.1.; [0060] The "Priority" column in Table A specifies a priority value for a VM. The priority value for a VM may be used to allocate and deallocate one or more resources for a VM. As described above, resources may be dynamically allocated to a VM from available resources pool 120. In certain embodiments, if a resource is to be allocated to a VM of a particular priority and the requisite amount of the resource is not available in available resource pool 120, resource manager 122 may check VMs with a lower priority than the particular priority to see if the requisite amount of the resource can be deallocated from one or more these VMs and then allocated to the VM with the particular priority. In one embodiment, a check is made to see if the lower priority VMs have been allocated additional resources beyond their base configuration. If so, resource manager 122 may reclaim the additional resources and make them available to the available resource pool 120 for allocation to a higher priority VM.; [0066]).
Regarding claim 15, Chin teaches further comprising determining an active status associated with the user device ([0050] Once the VMs have been launched by hypervisor 118, resource manager 122 is configured to monitor the resource allocation and resource usage of the multiple operational VMs and initiate dynamic changes to resources allocated to the VMs as and when needed.).
Regarding claim 16, Chin teaches further comprising reclaiming the hardware resource based at least in part on the active status associated with the user device ([0131] In certain embodiments, a "reclaimable" level priority may be assigned to one or more VMs, representing the lowest priority level. The mVM can shut down a VM that is marked as "reclaimable" and reclaim all of the VM's resources and make the resources available for allocation to other higher priority VMs.; [0167] In such a scenario, one or more programs executed by the mVM such as resource manager 122 may be configured to automatically deallocate resources from the first VM (which is now the passive VM) and allocate additional resources to the second VM (which is now the active VM) such that at the end of the failover the second, now active, VM has 75% of the resources allocated to it and the first, now passive, VM has 25% of the resources allocated to it.).
Regarding claim 17, Chin teaches wherein determining an active status associated with the user device includes periodically determining the active status associated with the user device ([0050] Various different conditions may be monitored to determine when a change is to be made. In one embodiment, to facilitate monitoring of the VMs, a special program (or multiple programs) referred to as a "monitor agent" (also referred to as an SLA agent) may be executed by each operational VM. For example, as shown in FIG. 1, monitor agent 124 is executed by the VMs. In certain embodiments, monitor agent 124 for a VM is configured to monitor the resource usage of the VM and convey the information to resource manager 122. Monitor agent 124 executed by a VM may convey the resource usage information for the VM to resource manager 122 at periodic programmable intervals and/or upon the occurrence of certain events. A push or a pull model may be used to communicate the resource usage information from monitor agents 124 to resource manager 122.; [0167-168]).
Regarding claim 18, Chin teaches wherein: receiving the request at the computational storage unit from the user device of the user to use the computational storage unit includes receiving the request at the computational storage unit from a process of the user device to use the computational storage unit, and the method further comprises: determining an active status associated with the process, and reclaiming the hardware resource based at least in part on the active status associated with the process ([0167] In one such embodiment, a user may simply specify the amounts of resources for an active VM and the amounts of resources for the passive VM. For example, the user may specify that 75% of the resources in a system (e.g., 75% of processing and system memory resources, etc.) are to be allocated to the active VM and 25% of the resources are to be allocated to the passive VM. In one embodiment, these amounts may be specified in the RCF. These specified amounts of the resources are then allocated to the VMs when the VMs are launched. For example, a first VM operating as an active VM may be allocated 75% of the resources when the first VM is launched. A second VM operating as a passive VM may be allocated 25% of the resources. Later, when a failover event occurs the second VM may become the active VM and the first VM may become the passive VM. In such a scenario, one or more programs executed by the mVM such as resource manager 122 may be configured to automatically deallocate resources from the first VM (which is now the passive VM) and allocate additional resources to the second VM (which is now the active VM) such that at the end of the failover the second, now active, VM has 75% of the resources allocated to it and the first, now passive, VM has 25% of the resources allocated to it. In this manner, the resources allocated to an active VM follow the VM that is active and likewise the resources allocated to a passive VM follow the VM that is passive. The mVM resides on the VM that is active, i.e., on the active VM. During a failover, the mVM switches to the new active automatically.).
Regarding claim 19, it is a media/product type claim having similar limitations as claim 7. Therefore, it is rejected under the same rationale above.
Regarding claim 20, Chin teaches wherein determining the number of hardware resources of the first type to which the user device should have access includes accessing the number of hardware resources of the first type to which the user device should have access from a table (See Table A; [0056-58]).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Roberts et al. (US 2014/0281149 A1) in view of Chin et al. (US 2014/0007097 A1), in further view of Matthews et al. (US 2017/0031698 A1).
Regarding claim 9, Chin teaches SLAs but neither Roberts nor Chin expressly teach wherein accessing the number of hardware resources of the first type to which the user device should have access from the table includes:
accessing a Service Level Agreement (SLA) identifier (SLA ID) associated with a user identifier (UID) for the user from the table; and accessing the number of hardware resources of the first type associated with the SLA ID from a second table (Abstract: dynamically allocating resources of virtual machines (VMs) using service level agreements (SLAs) and privilege levels of users. The system includes VM servers for executing the VMs. When a software application is to be executed on one executed VM on a VM server, a management device determines, from a first table, the privilege level of each executed VM based on the SLA, and then retrieves, from a second table, the resource allocation information for the software application to be executed using the privilege level of the executed VM.).
PNG
media_image1.png
479
507
media_image1.png
Greyscale
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Mathews of having multiple tables to associate a tenant with an SLA/privilege level and another for defining the resource entitlement based on the SLA/privilege level with the teachings of Roberts and Chin. The modification would have been motivated by the desire of combining known methods of having multiple tables storing data that can be used to associate with data from other tables to yield predictable results of being able to determine resource allocation data based on user ID and SLA/privilege levels.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
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 at (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.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195
Prosecution Insights