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 instant application having Application No. 18/821,335 has a total of 20 claims pending in the application; there are 3 independent claims and 17 dependent claims, all of which are ready for examination by the examiner.
INFORMATION CONCERNING OATH/DECLARATION
Oath/Declaration
The applicant’s oath/declaration has been reviewed by the examiner and is found to conform to the requirements prescribed in 37 C.F.R. 1.63.
ACKNOWLEDGEMENT OF REFERENCES CITED BY APPLICANT
As required by M.P.E.P. 609(C), the applicant’s submissions of the Information Disclosure Statements 08/30/2024 and 09/20/2024 are acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending. As required by M.P.E.P 609 C(2), a copy of the PTOL-1449 initialed and dated by the examiner is attached to the instant office action.
REJECTIONS NOT BASED ON PRIOR ART
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is now directed to non-statutory subject.
As per the independent claims and their dependent claims respectively, they are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Paragraph 0109 of the filed specification and body of claims do not limit structural features to perform the steps. Rather, the body of the claims are interpreted as purely software because paragraph 0109 stated that the method can be performed by software. For example, paragraph 0109 discloses “in an embodiment, the described methods and/or their equivalents may be implemented with computer executable instructions. Thus, in an embodiment, a non-transitory computer readable/storage medium is configured with stored computer executable instructions of an algorithm/executable application that when executed by a machine(s) cause the machine(s) (and/or associated components) to perform the method. Example machines include but are not limited to a processor, a computer, a server operating in a cloud computing system, a server configured in a Software as a Service (Saas) architecture, a smart phone, and so on. In an embodiment, a computing device is implemented with one or more executable algorithms that are configured to perform any of the disclosed methods”. Software is per se not a statutory class of invention. Therefore, the claims are rejected under 35 U.S.C. 101 because they are directed to software which is not a statutory class of invention.
REJECTIONS BASED ON PRIOR ART
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed, approved immediately upon submission, and reduces waiting time for Terminal Disclaimer to be manually approved. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory double patenting over the claims of 1-19 of U.S. Pat. No. 12,079,495, since the claims, if allowed, would improperly extend the “right to exclude” already granted in patents. Although the conflicting claims are not identical, they are not patentably distinct from each other because the subject matter claimed in the instant application is at least fully disclosed in the reference patents and application.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
1. Claims 1-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Barker, Jr. et al. (US pub. 2023/0016170), hereinafter, “Barker”.
At the outset, Applicant is reminded that claims subject to examination will be given their broadest reasonable interpretation in light of the supporting disclosure. In re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023,1027-28 (Fed. Cir. 1997). With this in mind, the discussion will focus on how the terms and relationships between the terms in the claims are met by the references.
2. As per claims 1, 8 and 15, Barker discloses a method, comprising: tracking memory and processor utilization by a container (a container is being equated to resources; see paragraph 0127, which discloses “resources 314 may be embodied as one or more software containers or in many other ways”) accessing a volume through a file system in user space (see paragraph 0165); obtaining at least one of historic memory, processor, input/output operations per second (IOPS), and throughput utilization by the container over a time period [see paragraph 0278, which discloses “in such an example, projecting a change to the application (404) over time may be carried out by performing a time-series analysis of various performance metrics associated with the application (404) to identify trends associated with the application (404). In addition, projecting a change to the application (404) over time may also be carried out based on telemetry data collected for similar applications as the telemetry data may be useful for identifying trends associated with the application (404). As such, an examination of the various performance metrics associated with the application (404) and the telemetry data can be used to generate trending information for the applications (404) including, for example, information describing the rate at which the number of IOPS being generated by the application (404) has been changing, the rate at which overwrite rates for I/O operations that are being generated by the application (404) are changing, the rate at which the amount of read bandwidth that is being consumed by I/O operations generated by the application (404) is changing, and many others. In such a way, predicted characteristics (416) of the application (404) may be generated by extrapolating identified trends out over a period of time in the future”]; generating a recommendation of memory and processor allocations for the container based upon the at least one of historic memory, processor, IOPS, and throughput utilization (see paragraph 0116, which discloses “such data analytics applications may be configured, for example, to receive telemetry data phoned home by the storage system 306. Such telemetry data may describe various operating characteristics of the storage system 306 and may be analyzed, for example, to determine the health of the storage system 306, to identify workloads that are executing on the storage system 306, to predict when the storage system 306 will run out of various resources, to recommend configuration changes, upgrades, workflow migrations, or other actions that improve the operation of the storage system”); evicting (not selecting a recommendation, resource) the container based upon a current memory and processor allocation for the container violating the recommendation [see fig. 6 and paragraph 0275, which discloses “one example of an action that may be taken by the storage system (406) in response to a different outcome being generated when selecting (410) one or more storage resources within the storage system (406) to support the execution of the application (404) is to generate (602) a recommendation to cease supporting the execution of the application (404) on first storage resources within the storage system (406) and begin supporting the execution of the application (404) on second storage resources within the storage system (406). Such a recommendation may be presented, for example, to a user such as a system administrator or application developer such that the user can choose whether to accept the recommendation. In such an example, if the user decides to accept the recommendation, a process may be initiated to move data, modify data communications connections, and so on, to enable the application (404) to use the updated set of storage resources within the storage system (406)”]; rewriting a specification (to change an application) for the container with requests and limit values derived from the recommendation (see claim 5 of Barker, which discloses “the method of claim 1 further comprising: identifying, in dependence upon a predicted change to the application, one or more updated storage performance characteristics associated with the application, wherein the predicted change comprises a predicted increase in required processing storage resources to support the application; and selecting, in dependence upon the one or more updated storage performance characteristics associated with the application and storage performance characteristics of one or more storage resources within one or more of the cloud-based storage systems, an updated set of storage resources within the one or more cloud-based storage systems to support the execution of the application”); and re-hosting the container based upon the specification [see fig. 5 and paragraph 0290, which discloses “as another example of automatically (904) performing corrective actions, the storage system (406) may limit the amount of resources that may be consumed by particular applications. Consider an example in which multiple applications are being supported by a first storage subsystem (412a) whose storage controllers are becoming constrained. In such an example, the storage system (406) may be configured to automatically throttle one or more application isolation domains such that only a predetermined amount of IOPS, read bandwidth, write bandwidth, or some other quantifiable measure of total system resources for the storage subsystem that supports the application isolation domain is made available to the application isolation domain that is being throttled”].
3. As per claims 2 and 9, Barker discloses “The method of claim 1” [See rejection to claim 1 above], comprising: calculating a lower bound limit for inclusion within the recommendation based upon a lower bound percentile amount applied to the historic memory and processor utilization, a lower bound safety margin, and a confidence factor (see fig. 15 and paragraphs 0337 and 0338); and evicting the container based upon the container requesting resources that violate the lower bound limit (see fig. 6 and paragraph 0275).
4. As per claims 3 and 10, Barker discloses, comprising: calculating an upper bound limit for inclusion within the recommendation based upon an upper bound percentile amount applied to the historic memory and processor utilization, an upper bound safety margin, and a confidence factor (see fig. 15 and paragraphs 0337 and 0338); and evicting the container based upon the container requesting resources that violate the upper bound limit (see fig. 6 and paragraph 0275).
5. As per claims 4 and 11, Barker discloses, comprising: calculating a target estimation for inclusion within the recommendation based upon a target percentile amount applied to the historic memory and processor utilization and a target safety margin (see paragraph 0208 and fig. 15); and rewriting the specification with a request derived from the target estimation (see claim 5 of Barker).
6. As per claims 5, 12 and 16, Barker discloses, comprising: running the container using a pod; and evicting the container by stopping a container orchestration platform from running the pod (see paragraph 0245).
7. As per claims 6 and 13, Barker discloses, comprising: determining that the recommendation specifies a resource amount greater than a resource allocation of a node hosting a pod that runs the container; creating a new node with a new resource allocation derived from the recommendation; and migrating the pod to the new node (see paragraph 0116).
8. As per claims 7 and 14, Barker discloses wherein the container is evicted based upon a target estimation being a threshold percentage greater than a resource request by the container and based upon the target estimation being generated at least a threshold time since a last target estimation (see paragraph 0149).
9. As per claim 17, Barker discloses wherein the vertical pod autoscaler is configured to: specify a request within the specification to bind a scheduler of the container orchestrated platform to reserve a set amount of resources for running the container, wherein the container is allowed to utilize more resources than the set amount of resources reserved by the scheduler (see paragraphs 0109 and 0258).
10. As per claim 18, Barker discloses wherein the vertical pod autoscaler is configured to: specify a limit value within the specification as a resource usage limit that cannot be surpassed by the container (see fig. 15 and paragraphs 0337 and 0338), wherein the container is evicted based upon the container attempting to access resources beyond the resource usage limit (see fig. 6 and paragraph 0275).
11. As per claim 19, Barker discloses wherein the vertical pod autoscaler is configured to: calculate a lower bound limit for inclusion within the recommendation based upon a lower bound percentile amount applied to the historic memory and processor utilization, a lower bound safety margin, and a confidence factor, wherein the container is evicted based upon the container requesting resources that violate the lower bound limit (see fig. 15 and paragraphs 0337 and 0338).
12. As per claim 20, Barker discloses wherein the vertical pod autoscaler is configured to: apply a minimum allowed cap to the lower bound limit based upon a container policy (see fig. 15 and paragraphs 0337 and 0338).
RELEVANT ART CITED BY THE EXAMINER
The following prior art made of record and not relied upon is cited to establish the level of skill in the applicant’s art and those arts considered reasonably pertinent to applicant’s disclosure. See MPEP 707.05(c).
The following reference teach of dynamically allocating resources based on input/output operations per second (IOPS) and throughput monitoring: US Pat. # 11,403,000 (Barker, Jr. et al.)
CLOSING COMMENTS
CONCLUSION
a. STATUS OF CLAIMS IN THE APPLICATION
The following is a summary of the treatment and status of all claims in the
application as recommended by M.P.E.P. 707.07(i):
a (1) CLAIMS REJECTED IN THE APPLICATION
Per the instant office action, claims 1-20 have received a first action on the merits and are subject of a first action non-final.
b. DIRECTION OF FUTURE CORRESPONDENCES
Any inquiry concerning this communication or earlier communications from the
Examiner should be directed to Ernest Unelus whose telephone number is (571) 272-
8596. The examiner can normally be reached on Monday to Friday 9:00 AM to 5:00PM.
IMPORTANT NOTE
If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner's supervisor, Mr. Idriss Alrobaye, can be reached at the following telephone number: Area Code (571) 270-1023.
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 either Private PAIR or Public PAIR. Status information for unpublished applications is available through private PAIR only. For more information about the PMR system, see her//pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217- 91 97 (toll-free).
/Ernest Unelus/
Primary Examiner
Art Unit 2181
Prosecution Insights