DETAILED ACTION
Claims 1-20 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.
Claims 1-2 and 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over Szczepanik et al. (US 2022/0083242) hereinafter “IBM” in further view of Patel et al. (US 9,864,636 B1).
Regarding claim 1, IBM teaches a computational storage unit ([0016] For example, processing elements are beginning to be incorporated into memory subsystems; such memory may be referred to as Processing in Memory (PIM). PIM may incorporate a processing element into, for example, a dual in-line memory module (DIMM), such as a stick of dynamic random access memory (DRAM). In such embodiments, it would be possible to perform at least a subset of computing operations without accessing the CPU at all. At the same time, it may differ from processing done on specialized cards (e.g., graphics processing units (GPU) or field programmable gate array (FPGA) accelerators) as it does not require the transfer of data outside of the DIMM. Therefore, in order to achieve an accurate measurement of computing resources consumed, the resources consumed within a PIM-enabled memory subsystem would need to be measured and reported, in addition to any resources consumed at the CPU or other specialized card, such as a GPU or FPGA accelerator.; [0022]; [0058] In one example, management layer 80 may provide the functions described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment… Service level management 84 provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment 85 provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.).
While IBM teaches the use of SLA to guaranteeing fulfillment of computing resources for consumers, IBM does not teach a first resource of a first type;
a second resource of the first type;
a table mapping a user identifier (UID) for a user to a number of resources of the first type.
However, Patel teaches a first hardware resource of a first type (Col. 17, lines 39-49: The set of computing resources may include a processing resource, and in some embodiments, may further include at least one of a memory resource, a storage resource, and an I/O (input/output) resource, such as those as described above.);
a second hardware resource of the first type (Col. 17, lines 39-49: The set of computing resources may include a processing resource, and in some embodiments, may further include at least one of a memory resource, a storage resource, and an I/O (input/output) resource, such as those as described above.);
a table mapping a user identifier (UID) for a user to a number of resources of the first type (Fig. 13, Service Level Agreement table 1300; Col. 17, lines 39-49: In some embodiments, the information from the SLA can be used by resource allocation policy module 410 to set the policy on how the resources can be allocated to this tenant. The information regarding the computing resources to provide to a tenant can be stored, for example, in a table associated with a task identifier assigned to the tenant. The set of computing resources may include a processing resource, and in some embodiments, may further include at least one of a memory resource, a storage resource, and an I/O (input/output) resource, such as those as described above.).
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 Patel with the teachings of IBM to apply SLA registering techniques for memory resources with the PIM element. The modification would have been motivated by the desire of combining known elements such as tenant SLA registering for managing resource allocation with Processing-in-Memory to yield predictable results.
Regarding claim 2, Patel teaches wherein the computational storage unit is configured to limit a user device of the user to the number of resources of the first type (Col. 17, lines 50-67: At block 1406, process 1400 determines a set of one or more resource usage constraints to be applied to the set of computing resources based on the SLA associated with the tenant. For example, a resource usage constraint can be a cap on the consumption amount of a computing resource per time interval, a fixed quantity or fixed proportion of a computing resource to allocate to the task, a limit on how long or how much access of a computing resource can be given to a task or any combination thereof. Examples of resource usage constraints may include a number of processor cycles per time interval, a number of bytes of memory accessed by a memory controller per time interval, a number of megabytes of DRAM, a number of gigabytes of disk storage, access to a number of coprocessors or specialized execution units, etc. In some embodiments, a mapping of the resource usage constraints to the corresponding computing resources and tenant can be stored in memory (e.g., an array or table in DRAM) or in hardware registers.).
Regarding claim 4, Patel teaches further comprising a session context indicating that the first resource is used by a session of a user device of the user (Col. 18, lines 5-31: At block 1408, the set of computing resources for execution of the task can be allocated to the task or to the virtual machine instance used for execution of the task. If a virtual machine instance for execution of the task has not instantiated yet, a virtual machine instance can be instantiated on the shared hardware resources. Allocating the set of computing resources may involve associating the set of computing resources to a task ID or VM ID associated with the tenant requesting execution of the task, for example, by resource mapping module 408. Examples of allocating the set of computing resources may include allocating one or more blocks of one or more of a Level 1 cache, a Level 2 cache, a Level 3 cache and a Level 4 cache for execution of the task based on the SLA (e.g., by tagging one or more blocks of the corresponding cache with the task ID or VM ID associated with the task to expose or make visible the corresponding blocks of cache to the task); allocating one or more banks of dynamic random access memory (DRAM) for execution of the task based on the SLA (e.g., by a memory controller tagging one or more blocks or one or more ranks of DRAM with the task ID or VM ID associated with the task to expose or make visible the corresponding banks or ranks of DRAM to the task); providing access to one or more coprocessors for the execution of the task based on the SLA; and/or providing access to one or more coprocessors and/or specialized execution units for the execution of the task based on the SLA.).
Regarding claim 5, Patel teaches further comprising a second table mapping the UID to a number of used resources of the first type of the computational storage unit based at least in part on the session context (Col. 18, lines 5-31 teaches associating a task or VM ID with a tenant showing the allocation; Col. 24, lines 17-23: The task identifier can be a value that is incremented for each task, a value derived from a tenant identifier, a random value, or other suitable identifier to uniquely identify the task. According to some embodiments, the task identifier can be used to track the utilization and unused amounts of a computing resource for the task or corresponding tenant.).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over “IBM” and Patel as applied to claim 1, in further view of Mathews et al. (US 2017/0031698 A1).
Regarding claim 3, While Patel teaches an SLA table as shown on Fig 15, IBM nor Patel expressly teach the limitations of claim 3 but Mathews teaches wherein the table includes:
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
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 IBM and Patel. 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.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over IBM and Patel as applied above for claim 1 in further view of Ghostine (US 2009/0248869 A1).
Regarding claim 6, IBM nor Patel explicitly teach further comprising a reclamation unit to reclaim hardware resources based at least in part on an active status associated with a user device of the user.
However, Ghostine teaches further comprising a reclamation unit to reclaim hardware resources based at least in part on an active status associated with a user device of the user ([0012] Each Terminal Server keeps track of its user sessions, active and disconnected, as well as all the running processes associated with these sessions… Idle user sessions can be optionally logged off to reclaim wasted computing resources.; [0043] where each desktop computer is the equivalent of a Terminal Server user session).
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 Ghostine with the teachings of IBM and Patel to determine resource utilization status to determine whether to reclaim resources to optimize resource deployment. The modification would have been motivated by the desire of optimizing the deployment of resources so that only those resources that are required to be used, are deployed.
Claims 7-8, 10-15, 17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Szczepanik et al. (US 2022/0083242) hereinafter “IBM” in further view of Guim Bernat et al. (US 2020/0278804 A1).
Regarding claim 7, IBM teaches a computational storage unit ([0016] For example, processing elements are beginning to be incorporated into memory subsystems; such memory may be referred to as Processing in Memory (PIM). PIM may incorporate a processing element into, for example, a dual in-line memory module (DIMM), such as a stick of dynamic random access memory (DRAM). In such embodiments, it would be possible to perform at least a subset of computing operations without accessing the CPU at all. At the same time, it may differ from processing done on specialized cards (e.g., graphics processing units (GPU) or field programmable gate array (FPGA) accelerators) as it does not require the transfer of data outside of the DIMM. Therefore, in order to achieve an accurate measurement of computing resources consumed, the resources consumed within a PIM-enabled memory subsystem would need to be measured and reported, in addition to any resources consumed at the CPU or other specialized card, such as a GPU or FPGA accelerator.; [0022]; [0058] In one example, management layer 80 may provide the functions described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment… Service level management 84 provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment 85 provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.).
While IBM teaches the use of SLA to guaranteeing fulfillment of computing resources for consumers, IBM does not teach explicitly teach but Guim Bernat 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 (Abstract: receives a memory request from the tenant to access a selected one of the plurality of memory devices; wherein the memory is the hardware resource type);
determining a number of hardware resources of the first type to which the user device should have access ([0018] In an embodiment, tenant registrations 304 is implemented by any suitable data structure, such as a table or an array, for example, indexed by tenant ID or tenant tag.; [0021] When a memory request is received, QoS enforcer 310 determines how and to what extent the memory request is to be implemented. QoS enforcer 310 accesses tenant registrations 304, SLAs 312, and current usages 308 to determine if the requesting tenant is valid and the memory request should be allowed (e.g., implemented or performed) based on the tenant's one or more SLA requirements 312 and the current usages 308 by the tenant (or in one embodiment, by all tenants).); and
limiting the user device to a maximum number of resources of the first type in the computational storage unit ([0018] In an embodiment, tenant registrar 302 causes QoS enforcer 310 to store one or more SLA requirements for a tenant in SLAs 312. In an embodiment, SLAs 312 is implemented by any suitable data structure, such as a table or array, for example, indexed by tenant ID or tenant tag. In another embodiment, SLAs 312 is stored within or accessible by tenant registrar 302.; [0021] When a memory request is received, QoS enforcer 310 determines how and to what extent the memory request is to be implemented. QoS enforcer 310 accesses tenant registrations 304, SLAs 312, and current usages 308 to determine if the requesting tenant is valid and the memory request should be allowed (e.g., implemented or performed) based on the tenant's one or more SLA requirements 312 and the current usages 308 by the tenant (or in one embodiment, by all tenants). For example, if the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is only 1 GB, then QoS enforcer 310 allows memory request and QoS manager 118 to implement the request. However, if for example the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is 5 GB, then QoS enforcer does not allow memory request and QoS manager 118 to implement the request. Instead, an error message may be returned to the requesting tenant. In another example, if the requesting tenant is not currently using a selected bandwidth as a percentage of the overall bandwidth for a memory device 120, then QoS enforcer 310 allows memory request and QoS manager 118 to implement the request. However, if the requesting tenant already is using all bandwidth allocated to the tenant as a percentage of the overall bandwidth of a memory device 120, then QoS enforcer denies the request. In an embodiment, QoS enforcer 310 controls memory bandwidth and prioritization of memory requests for tenants by managing queue slots (not shown in FIG. 3) used to access a memory device 120.).
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 Guim Bernat with the teachings of IBM to apply SLA registering techniques for memory resources with the PIM element. The modification would have been motivated by the desire of combining known elements such as tenant SLA registering with Processing-in-Memory to yield predictable results.
Regarding claim 8, Guim Bernat 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 ([0013] For example, tenant A may comprise 10 processes accessing a memory from one computing device, each process having a different process ID, and tenant B may comprise 20 processes across four computing devices (including one or more accelerators), all of which are accessing the same memory as tenant A. It may be desirable, or even required according to an SLA, to guarantee that 50% of the bandwidth to that memory is always available and/or allocated to tenant B.; [0021] When a memory request is received, QoS enforcer 310 determines how and to what extent the memory request is to be implemented. QoS enforcer 310 accesses tenant registrations 304 (i.e., tables, see [0018]), SLAs 312, and current usages 308 to determine if the requesting tenant is valid and the memory request should be allowed (e.g., implemented or performed) based on the tenant's one or more SLA requirements 312 and the current usages 308 by the tenant (or in one embodiment, by all tenants). For example, if the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is only 1 GB, then QoS enforcer 310 allows memory request and QoS manager 118 to implement the request.).
Regarding claim 10, Guim Bernat teaches further comprising initializing the table with the number of hardware resources of the first type to which the user device should have access ([0018] In an embodiment, SLAs 312 is implemented by any suitable data structure, such as a table or array, for example, indexed by tenant ID or tenant tag. In another embodiment, SLAs 312 is stored within or accessible by tenant registrar 302.; [0021] For example, if the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is only 1 GB, then QoS enforcer 310 allows memory request and QoS manager 118 to implement the request).
Regarding claim 11, Guim Bernat 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 ([0021] When a memory request is received, QoS enforcer 310 determines how and to what extent the memory request is to be implemented. QoS enforcer 310 accesses tenant registrations 304, SLAs 312, and current usages 308 to determine if the requesting tenant is valid and the memory request should be allowed (e.g., implemented or performed) based on the tenant's one or more SLA requirements 312 and the current usages 308 by the tenant (or in one embodiment, by all tenants). For example, if the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is only 1 GB, then QoS enforcer 310 allows memory request and QoS manager 118 to implement the request. However, if for example the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is 5 GB, then QoS enforcer does not allow memory request and QoS manager 118 to implement the request. Instead, an error message may be returned to the requesting tenant. In another example, if the requesting tenant is not currently using a selected bandwidth as a percentage of the overall bandwidth for a memory device 120, then QoS enforcer 310 allows memory request and QoS manager 118 to implement the request. However, if the requesting tenant already is using all bandwidth allocated to the tenant as a percentage of the overall bandwidth of a memory device 120, then QoS enforcer denies the request. In an embodiment, QoS enforcer 310 controls memory bandwidth and prioritization of memory requests for tenants by managing queue slots (not shown in FIG. 3) used to access a memory device 120. In an embodiment, QoS enforcer 310 operates periodically to check usages against SLA requirements per tenant and does not check usages for every received memory request.; [0022] In an embodiment a register SLA and tenant command 123 specifies latency and/or bandwidth values for a tenant 101.).
Regarding claim 12, Guim Bernat teaches further comprising updating a table of hardware resources used by the user device based at least in part on the request ([0020] Tenant resource monitor 306 receives memory requests 112 and, based at least in part on the requests to read memory and/or write memory, modifies current usages 308. Current usages 308 comprises statistical information regarding memory usage of memory devices 120 over time by one or more tenants. In an embodiment, current usages 308 is implemented by any suitable data structure, such as a table or array, for example, indexed by tenant ID or tenant tag. In an embodiment, successful completion of a memory request is included in updated current usages 308.).
Regarding claim 13, Guim Bernat teaches further comprising: receiving a second request at the computational storage unit from the user device to use the computational storage unit and updating the table of hardware resources used by the user device based at least in part on the second request ([0020] Tenant resource monitor 306 receives memory requests 112 and, based at least in part on the requests to read memory and/or write memory, modifies current usages 308. Current usages 308 comprises statistical information regarding memory usage of memory devices 120 over time by one or more tenants. In an embodiment, current usages 308 is implemented by any suitable data structure, such as a table or array, for example, indexed by tenant ID or tenant tag. In an embodiment, successful completion of a memory request is included in updated current usages 308.; [0021] When a memory request is received, QoS enforcer 310 determines how and to what extent the memory request is to be implemented. QoS enforcer 310 accesses tenant registrations 304, SLAs 312, and current usages 308 to determine if the requesting tenant is valid and the memory request should be allowed (e.g., implemented or performed) based on the tenant's one or more SLA requirements 312 and the current usages 308 by the tenant (or in one embodiment, by all tenants). For example, if the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is only 1 GB, then QoS enforcer 310 allows memory request and QoS manager 118 to implement the request. However, if for example the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is 5 GB, then QoS enforcer does not allow memory request and QoS manager 118 to implement the request. Instead, an error message may be returned to the requesting tenant. In another example, if the requesting tenant is not currently using a selected bandwidth as a percentage of the overall bandwidth for a memory device 120, then QoS enforcer 310 allows memory request and QoS manager 118 to implement the request.).
Regarding claim 14, Guim Bernat 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 ([0020] Tenant resource monitor 306 receives memory requests 112 and, based at least in part on the requests to read memory and/or write memory, modifies current usages 308. Current usages 308 comprises statistical information regarding memory usage of memory devices 120 over time by one or more tenants. In an embodiment, current usages 308 is implemented by any suitable data structure, such as a table or array, for example, indexed by tenant ID or tenant tag. In an embodiment, successful completion of a memory request is included in updated current usages 308.; [0021] When a memory request is received, QoS enforcer 310 determines how and to what extent the memory request is to be implemented. QoS enforcer 310 accesses tenant registrations 304, SLAs 312, and current usages 308 to determine if the requesting tenant is valid and the memory request should be allowed (e.g., implemented or performed) based on the tenant's one or more SLA requirements 312 and the current usages 308 by the tenant (or in one embodiment, by all tenants). For example, if the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is only 1 GB, then QoS enforcer 310 allows memory request and QoS manager 118 to implement the request. However, if for example the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is 5 GB, then QoS enforcer does not allow memory request and QoS manager 118 to implement the request. Instead, an error message may be returned to the requesting tenant. In another example, if the requesting tenant is not currently using a selected bandwidth as a percentage of the overall bandwidth for a memory device 120, then QoS enforcer 310 allows memory request and QoS manager 118 to implement the request. However, if the requesting tenant already is using all bandwidth allocated to the tenant as a percentage of the overall bandwidth of a memory device 120, then QoS enforcer denies the request. In an embodiment, QoS enforcer 310 controls memory bandwidth and prioritization of memory requests for tenants by managing queue slots (not shown in FIG. 3) used to access a memory device 120. In an embodiment, QoS enforcer 310 operates periodically to check usages against SLA requirements per tenant and does not check usages for every received memory request.; [0022]).
Regarding claim 15, Guim Bernat teaches further comprising determining an active status associated with the user device (Fig. 3, Current Usages 308).
Regarding claim 17, Guim Bernat teaches wherein determining an active status associated with the user device includes periodically determining the active status associated with the user device ([0021] In an embodiment, QoS enforcer 310 operates periodically to check usages against SLA requirements per tenant; Fig. 3, Current Usages 308).
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, Guim Bernat 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 ([0021] When a memory request is received, QoS enforcer 310 determines how and to what extent the memory request is to be implemented. QoS enforcer 310 accesses tenant registrations 304, SLAs 312, and current usages 308 to determine if the requesting tenant is valid and the memory request should be allowed (e.g., implemented or performed) based on the tenant's one or more SLA requirements 312 and the current usages 308 by the tenant (or in one embodiment, by all tenants). For example, if the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is only 1 GB, then QoS enforcer 310 allows memory request and QoS manager 118 to implement the request. However, if for example the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is 5 GB, then QoS enforcer does not allow memory request and QoS manager 118 to implement the request. Instead, an error message may be returned to the requesting tenant. In another example, if the requesting tenant is not currently using a selected bandwidth as a percentage of the overall bandwidth for a memory device 120, then QoS enforcer 310 allows memory request and QoS manager 118 to implement the request. However, if the requesting tenant already is using all bandwidth allocated to the tenant as a percentage of the overall bandwidth of a memory device 120, then QoS enforcer denies the request. In an embodiment, QoS enforcer 310 controls memory bandwidth and prioritization of memory requests for tenants by managing queue slots (not shown in FIG. 3) used to access a memory device 120.).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Szczepanik et al. (US 2022/0083242) hereinafter “IBM” in view of Guim Bernat et al. (US 2020/0278804 A1), in further view of Mathews et al. (US 2017/0031698 A1).
Regarding claim 9, IBM nor Guim Bernat 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.
However, Mathews teaches 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 IBM and Guim Bernat. 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.
Claims 16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over IBM and Guim Bernat as applied above for claim 1 in further view of Ghostine (US 2009/0248869 A1).
Regarding claim 16, IBM nor Guim Bernat expressly teach further comprising reclaiming the hardware resource based at least in part on the active status associated with the user device.
However, Ghostine teaches further comprising reclaiming the hardware resource based at least in part on the active status associated with the user device ([0012] Each Terminal Server keeps track of its user sessions, active and disconnected, as well as all the running processes associated with these sessions… Idle user sessions can be optionally logged off to reclaim wasted computing resources.; [0043] where each desktop computer is the equivalent of a Terminal Server user session).
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 Ghostine with the teachings of IBM and Guim Bernat to determine resource utilization status to determine whether to reclaim resources to optimize resource deployment. The modification would have been motivated by the desire of optimizing the deployment of resources so that only those resources that are required to be used, are deployed.
Regarding claim 18, IBM teaches a computational storage unit, Guim Bernat 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 ([0021] When a memory request is received, QoS enforcer 310 determines how and to what extent the memory request is to be implemented. QoS enforcer 310 accesses tenant registrations 304, SLAs 312, and current usages 308 to determine if the requesting tenant is valid and the memory request should be allowed (e.g., implemented or performed) based on the tenant's one or more SLA requirements 312 and the current usages 308 by the tenant (or in one embodiment, by all tenants). For example, if the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is only 1 GB, then QoS enforcer 310 allows memory request and QoS manager 118 to implement the request. However, if for example the tenant's one or more SLA requirements specify a maximum read/write limit per unit time of 5 GB and the current usage is 5 GB, then QoS enforcer does not allow memory request and QoS manager 118 to implement the request.) and
the method further comprises: determining an active status associated with the process (Fig. 3 Current Usages 308).
In addition, Ghostine teaches reclaiming the resource based at least in part on the active status associated with the process ([0012]).
Response to Arguments
Applicant’s arguments with respect to claims 1-6, 9, and 16-18 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.
In Remarks, Applicant argues:
(I) According to the Office Action, the "resource" as taught by Guim Bernat is memory bandwidth. But according to Guim Bernat, memory bandwidth, like latency, is a performance metric. A performance metric may be understood to be a property of the memory: but a performance metric would not appear to be a resource of the memory. A resource may be increased or decreased.
Examiner respectfully submits the following:
As to point (I)
Applicant’s arguments, see page 12, filed 01/22/2026, with respect to the rejection of claim 7 under 35 USC 103 have been fully considered and are persuasive in view of the amendments. Upon further review of the claim as drafted and the Guim Bernat reference, examiner interprets the memory as being the hardware resource type rather than bandwidth. Accordingly, the combination of IBM and Guim Bernat reasonably teach the limitation as claimed.
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 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