DETAILED ACTION
Claims 1-20 are pending in the application. Autonomously sovereign independent
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 .
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 (i.e., changing from AIA to pre-AIA ) 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.
Examiner’s Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Specification
The use of the term BLUETOOTH, which is a trade name or a mark used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 6, 13, and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 6 is rejected on the basis that it contains an improper Markush grouping of alternatives. See In re Harnisch, 631 F.2d 716, 721-22 (CCPA 1980) and Ex parte Hozumi, 3 USPQ2d 1059, 1060 (Bd. Pat. App. & Int. 1984). A Markush grouping is proper if the alternatives defined by the Markush group (i.e., alternatives from which a selection is to be made in the context of a combination or process, or alternative chemical compounds as a whole) share a “single structural similarity” and a common use. A Markush grouping meets these requirements in two situations. First, a Markush grouping is proper if the alternatives are all members of the same recognized physical or chemical class or the same art-recognized class, and are disclosed in the specification or known in the art to be functionally equivalent and have a common use. Second, where a Markush grouping describes alternative chemical compounds, whether by words or chemical formulas, and the alternatives do not belong to a recognized class as set forth above, the members of the Markush grouping may be considered to share a “single structural similarity” and common use where the alternatives share both a substantial structural feature and a common use that flows from the substantial structural feature. See MPEP § 2117.
The Markush grouping of “the set of metrics is selected from at least one of process IDs, incoming traffic on a port, processor usage, memory usage, input/output operations, or TCP/IP connections” is improper because the alternatives defined by the Markush grouping do not share both a single structural similarity and a common use for the following reasons: A Markush grouping is a closed group of alternatives, i.e., the selection is made from a group "consisting of" (rather than "comprising" or "including") the alternative members. In this case, the phrase “selected from at least one of” presents an open group of alternatives which is an improper Markush grouping and renders the claim indefinite. See MPEP §2173.05 (h).
To overcome this rejection, Applicant may set forth each alternative (or grouping of patentably indistinct alternatives) within an improper Markush grouping in a series of independent or dependent claims and/or present convincing arguments that the group members recited in the alternative within a single claim in fact share a single structural similarity as well as a common use.
For the following analysis, the Examiner will consider the limitation “the set of metrics is selected from at least one of process IDs, incoming traffic on a port, processor usage, memory usage, input/output operations, or TCP/IP connections” as referring to –the set of metrics is at least one of process IDs, incoming traffic on a port, processor usage, memory usage, input/output operations, or TCP/IP connections— (referring to an open group of alternatives).
Claim 13 is rejected on the basis that it contains an improper Markush grouping of alternatives. See In re Harnisch, 631 F.2d 716, 721-22 (CCPA 1980) and Ex parte Hozumi, 3 USPQ2d 1059, 1060 (Bd. Pat. App. & Int. 1984). A Markush grouping is proper if the alternatives defined by the Markush group (i.e., alternatives from which a selection is to be made in the context of a combination or process, or alternative chemical compounds as a whole) share a “single structural similarity” and a common use. A Markush grouping meets these requirements in two situations. First, a Markush grouping is proper if the alternatives are all members of the same recognized physical or chemical class or the same art-recognized class, and are disclosed in the specification or known in the art to be functionally equivalent and have a common use. Second, where a Markush grouping describes alternative chemical compounds, whether by words or chemical formulas, and the alternatives do not belong to a recognized class as set forth above, the members of the Markush grouping may be considered to share a “single structural similarity” and common use where the alternatives share both a substantial structural feature and a common use that flows from the substantial structural feature. See MPEP § 2117.
The Markush grouping of “the set of metrics is selected from at least one of process IDs, incoming traffic on a port, processor usage, memory usage, input/output operations, or TCP/IP connections” is improper because the alternatives defined by the Markush grouping do not share both a single structural similarity and a common use for the following reasons: A Markush grouping is a closed group of alternatives, i.e., the selection is made from a group "consisting of" (rather than "comprising" or "including") the alternative members. In this case, the phrase “selected from at least one of” presents an open group of alternatives which is an improper Markush grouping and renders the claim indefinite. See MPEP §2173.05 (h).
To overcome this rejection, Applicant may set forth each alternative (or grouping of patentably indistinct alternatives) within an improper Markush grouping in a series of independent or dependent claims and/or present convincing arguments that the group members recited in the alternative within a single claim in fact share a single structural similarity as well as a common use.
For the following analysis, the Examiner will consider the limitation “the set of metrics is selected from at least one of process IDs, incoming traffic on a port, processor usage, memory usage, input/output operations, or TCP/IP connections” as referring to –the set of metrics is at least one of process IDs, incoming traffic on a port, processor usage, memory usage, input/output operations, or TCP/IP connections— (referring to an open group of alternatives).
Claim 20 is rejected on the basis that it contains an improper Markush grouping of alternatives. See In re Harnisch, 631 F.2d 716, 721-22 (CCPA 1980) and Ex parte Hozumi, 3 USPQ2d 1059, 1060 (Bd. Pat. App. & Int. 1984). A Markush grouping is proper if the alternatives defined by the Markush group (i.e., alternatives from which a selection is to be made in the context of a combination or process, or alternative chemical compounds as a whole) share a “single structural similarity” and a common use. A Markush grouping meets these requirements in two situations. First, a Markush grouping is proper if the alternatives are all members of the same recognized physical or chemical class or the same art-recognized class, and are disclosed in the specification or known in the art to be functionally equivalent and have a common use. Second, where a Markush grouping describes alternative chemical compounds, whether by words or chemical formulas, and the alternatives do not belong to a recognized class as set forth above, the members of the Markush grouping may be considered to share a “single structural similarity” and common use where the alternatives share both a substantial structural feature and a common use that flows from the substantial structural feature. See MPEP § 2117.
The Markush grouping of “the set of metrics is selected from at least one of process IDs, incoming traffic on a port, processor usage, memory usage, input/output operations, or TCP/IP connections” is improper because the alternatives defined by the Markush grouping do not share both a single structural similarity and a common use for the following reasons: A Markush grouping is a closed group of alternatives, i.e., the selection is made from a group "consisting of" (rather than "comprising" or "including") the alternative members. In this case, the phrase “selected from at least one of” presents an open group of alternatives which is an improper Markush grouping and renders the claim indefinite. See MPEP §2173.05 (h).
To overcome this rejection, Applicant may set forth each alternative (or grouping of patentably indistinct alternatives) within an improper Markush grouping in a series of independent or dependent claims and/or present convincing arguments that the group members recited in the alternative within a single claim in fact share a single structural similarity as well as a common use.
For the following analysis, the Examiner will consider the limitation “the set of metrics is selected from at least one of process IDs, incoming traffic on a port, processor usage, memory usage, input/output operations, or TCP/IP connections” as referring to –the set of metrics is at least one of process IDs, incoming traffic on a port, processor usage, memory usage, input/output operations, or TCP/IP connections— (referring to an open group of alternatives).
Claim Rejections - 35 USC § 102
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-6, 8-13, and 15-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Barak et al. (US 2013/0227710 A1; hereinafter “Barak”).
With respect to claim 1, Barak teaches: A computer implemented method for deprovisioning a virtual machine, the computer implemented method comprising:
initializing, by a number of processor units (see e.g. paragraph 14: “one or more processors may cause the processors to perform the features and functions related to securing leased images, as described herein”), a deprovisioning agent (see e.g. Fig. 2: “Control Agent 202”; paragraph 25: “control agent 202 includes image activate/deactivate module 202a”; and paragraph 62: “de-provision the leased guest virtual machine 102 using image activation/deactivation module 202a”) within the virtual machine (see e.g. Fig. 2: “Guest Virtual Machine 102”; and paragraph 24: “guest virtual machine 102 includes a native operating system (OS) that can be controlled by a specific control modules installed thereon such as, for example a control agent 202”);
monitoring, by the number of processor units (see e.g. paragraph 14), a set of metrics in the virtual machine (see e.g. paragraph 47: “determines a remaining portion of usage time of the leased guest virtual machine 102”; and paragraph 57: “determines whether or not the reuse time is close to exceeding the total allowed time for reuse of the leased guest virtual machine”) using the deprovisioning agent (see e.g. paragraph 27: “control agent 202 includes an image local store 202c that is configured to store one or more electronic certificates associated with guest virtual machine 102 and local status for guest virtual machine 102, to be communicated with agent monitor control 204d on the use control monitor 204”; paragraph 33: “image use control monitor store 204e is a store for certificates and status of guest virtual machines in cloud environment C1, and specifically for use control agent 202 associated with each of guest virtual machines in cloud environment C1. Image use control monitor 204e also includes the time a leased guest virtual machine will expire”; paragraph 47: “control module 204 determines a remaining portion of usage time”; and paragraph 57: “control module 204 determines whether or not the reuse time is close to exceeding the total allowed time for reuse”); and
deprovisioning, by the number of processor units (see e.g. paragraph 14), the virtual machine using the deprovisioning agent (see e.g. paragraph 25: “control agent 202 includes image activate/deactivate module 202a”; and paragraph 62: “de-provision the leased guest virtual machine 102 using image activation/deactivation module 202a”) in response to the set of metrics meeting a set of criteria (see e.g. paragraph 48: “control module 204 determines whether the previous active usage time for the leased guest virtual machine 102 (determined in operation 320) is close to or equals the total allowed time for which guest virtual machine 102 was leased. If yes, the flow proceeds”; paragraph 57: “determines whether or not the reuse time is close to exceeding the total allowed time for reuse of the leased guest virtual machine 102… If yes, the flow proceeds”) for deprovisioning the virtual machine (see e.g. paragraph 61: “any operation that leads to de-provisioning or de-commissioning of the leased image (as shown in operation 350)”; and Fig. 3, step 350).
Barak discloses a control agent 202 installed on a virtual machine 102 wherein the control agent 202 is used by a control module 204 to deprovision the virtual machine in response to expiration of monitored virtual machine timers (e.g. a virtual machine usage timer, a virtual machine reuse timer).
With respect to claim 2, Barak teaches: The computer implemented method of claim 1, wherein initializing, by the number of processor units, the deprovisioning agent comprises:
installing, by the number of processor units, the deprovisioning agent in the virtual machine (see e.g. paragraph 24: “guest virtual machine 102 includes a native operating system (OS) that can be controlled by a specific control modules installed thereon such as, for example a control agent 202”);
retrieving, by the number of processor units, a set of rules implementing the set of criteria from a configuration repository (see e.g. Fig. 2: “Image Use Control Monitor Store 204e”; and paragraph 33: “image use control monitor store 204e is a store for certificates and status of guest virtual machines in cloud environment C1, and specifically for use control agent 202 associated with each of guest virtual machines in cloud environment C1. Image use control monitor 204e also includes the time a leased guest virtual machine will expire and the policy governing functionalities of image leasing in cloud environment C1 in case of an alert (e.g., get the guest virtual machine down, warn, and/or send an alert and where to send it). Information in image use control monitor store 204e is used by the other components on use control monitor 204 (e.g., agent control monitor 204d described above) to carry out their respective actions. By way of example only, such actions include, getting image status based on the certificate to decide if the guest virtual machine can be started, storing a new status if status has changed (e.g., locked/unlocked), obtaining the policy to know how to react to exceptions, and/or storing a changed policy, if there was a request for such a change”); and
configuring, by the number of processor units, the deprovisioning agent using a set of rules retrieved from the configuration repository for deprovisioning the virtual machine (see e.g. paragraph 33: “Image use control monitor 204e also includes the time a leased guest virtual machine will expire… Information in image use control monitor store 204e is used by the other components on use control monitor 204 (e.g., agent control monitor 204d described above) to carry out their respective actions”; paragraph 48: “control module 204 determines whether the previous active usage time for the leased guest virtual machine 102 (determined in operation 320) is close to or equals the total allowed time for which guest virtual machine 102 was leased”; paragraph 57: “control module 204 determines whether or not the reuse time is close to exceeding the total allowed time for reuse of the leased guest virtual machine 102”; and paragraph 61: “any operation that leads to de-provisioning or de-commissioning of the leased image (as shown in operation 350)”).
With respect to claim 3, Barak teaches: The computer implemented method of claim 1 further comprising:
creating, by the number of processor units, a snapshot of the virtual machine (see e.g. paragraph 45: “Backups of guest virtual machines may use the same electronic certificate as the leased guest virtual machine itself, and may contain a point-in-time snapshot of the leased guest virtual machine”) using deprovisioning agent prior to the virtual machine being deprovisioned in response to meeting the set of criteria for deprovisioning the virtual machine (see e.g. paragraph 45: “control module 204 determines whether guest virtual machine 102 release request includes an image deactivation request. The deactivation request indicates that the leased guest virtual machine 102 will not be used anymore by the customer, and may be de-provisioned, as described herein. In some implementations, control module 204 carries out locking one or more backups of the leased guest virtual machine 102 in a memory device in control module 204 to prevent unauthorized usage of the backups. Backups of guest virtual machines may use the same electronic certificate as the leased guest virtual machine itself, and may contain a point-in-time snapshot of the leased guest virtual machine”).
With respect to claim 4, Barak teaches: The computer implemented method of claim 1, wherein monitoring, by the number of processor units, the virtual machine comprises:
observing, by the number of processor units, execution behavior of the virtual machine using a set of watchers (see e.g. paragraph 30: “time monitor module 204b is a monitoring agent for a time for which active guest virtual machine are used actively by a customer at server device 102 who leases that guest virtual machine”); and
monitoring, by the number of processor units, the set of metrics generated by the set of watchers observing the execution behavior using the deprovisioning agent (see e.g. paragraph 41: “control module 204 monitors usage of the leased guest virtual machine 102 by the customer connected at server device 102 using time monitor module 204b”; and paragraph 56: “control module 204 monitors reuse time using time monitor module 204b, similar to the monitoring in operation 310”).
With respect to claim 5, Barak teaches: The computer implemented method of claim 1, wherein deprovisioning, by the number of processor units, the virtual machine comprises:
starting, by the number of processor units, a grace period in response to the set of metrics meeting the set of criteria for deprovisioning the virtual machine (see e.g. paragraph 44: “when the threshold time allowed for active usage of the leased guest virtual machine 102 has expired (or, is close to expiration), control module 204 locks guest virtual machine 102 from further usage…the period of time for which the leased guest virtual machine 102 is locked and is therefore inactive is indicated by the customer as part of the initial request (in operation 302). For example, the customer may know in advance when guest virtual machine 102 to be leased will not be actively used, and may indicate so in the initial request using image reservation system 104. In such implementation, the inactivity period is a planned parameter”; paragraph 60: “control module 204 waits for a period of time before carrying out operation 350. The wait is performed to cover the implementation where the customer might request a reuse again”);
deprovisioning, by the number of processor units, the virtual machine using the deprovisioning agent in response to the grace period ending (see e.g. paragraph 46: “control module 204 determines, after a period of time has elapsed since the last use of the leased guest virtual machine 102, whether a request for reuse of the leased locked image is received from the customer via server device 102. If no, based upon a further confirmation from the customer that originally requested the leasing of the guest virtual machine that guest virtual machine 102 is no longer needed, the flow proceeds to an operation 350”; and Fig. 3, steps 314, 318, 346, 350).
With respect to claim 6, Barak teaches: The computer implemented method of claim 1, wherein the set of metrics is selected from at least one of process IDs, incoming traffic on a port, processor usage (see e.g. paragraph 30: “time monitor module 204b is a monitoring agent for a time for which active guest virtual machine are used actively by a customer at server device 102 who leases that guest virtual machine”), memory usage, input/output operations, or TCP/IP connections.
With respect to claims 8-13: Claims 8-13 are directed to a system comprising a number of processor units that execute program instruction to implement active functions corresponding to the method disclosed in claims 1-6, respectively; please see the rejections directed to claims 1-6 above which also cover the limitations recited in claims 8-13. Note that, Barak also discloses computing devices comprising processors that execute instructions to perform the method disclosed in claims 1-6 (see e.g. paragraph 14).
With respect to claims 15-20: Claims 15-20 are directed to a computer program product comprising a computer readable storage medium having program instructions to implement active functions corresponding to the method disclosed in claims 1-6, respectively; please see the rejections directed to claims 1-6 above which also cover the limitations recited in claims 15-20. Note that, Barak also discloses a computer readable medium comprising instructions to perform the method disclosed in claims 1-6 (see e.g. paragraph 35).
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Barak in view of Rungta (US 2020/0073739 A1; hereinafter Rungta).
With respect to claim 7, Barak teaches: The computer implemented method of claim 1,
Barak does not but Rungta teaches:
wherein the virtual machine is in a serverless computing system (see e.g. Rungta, paragraph 26: “system may allocate, configure, and deploy virtual computing resources for executing an instance of a constraint solver. The virtual computing resources to be deployed may include some or all of: one or more virtual machines… the system may use a “serverless” computing architecture, wherein software containers are allocated to the system's processes from any physical computing resources that are available to the virtual computing environment”).
Barak and Rungta are analogous art because they are in the same field of endeavor: managing allocation and deallocation of virtual computing resources. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Barak with the teachings of Rungta. The motivation/suggestion would be to reduce resource costs and operational overheads.
With respect to claim 14: Claim14 is directed to a system comprising a number of processor units that execute program instruction to implement active functions corresponding to the method disclosed in claim 7; please see the rejection directed to claim 7 above which also covers the limitations recited in claim 14.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Kowalski et al. (US 10,545,776 B1) discloses an on-demand computing service that de-provisions virtual machine instances based on demand (see from column 4, line 52 to column 5, line 2).
Lazrek et al. (US 2024/0168789 A1) discloses an autoscaler that selectively de-provisions VMs responsive to observing certain characteristic(s) satisfying scale-down criteria, such as when a length of a queue drops below a defined threshold, when an average pendency of workloads drops below a defined threshold, when a rate of workloads being received decreases below the threshold, etc. (see paragraph 46).
Roth (US 2017/0242725 A1) discloses a scaling service that terminates and de-provisions virtual machines when corresponding workloads fall below a minimum threshold (see paragraph 79).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30.
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, Kevin L Young can be reached at (571) 270-3180. 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.
/UMUT ONAT/Primary Examiner, Art Unit 2194
Prosecution Insights