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 .
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
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, 4-9, 12-17, and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 1 requires “determine whether a master application corresponding to the virtual machines has accepted a minion application corresponding to a first one of the virtual machines.”
The limitation of “determine whether a master application corresponding to the virtual machines has accepted a minion application corresponding to a first one of the virtual machines,” as drafted, is a system that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting “[a] system to manage a plurality of virtual machines of a shared computing resource, the system comprising: interface circuitry; programmable circuitry; and machine readable instructions to cause the programmable circuitry,” nothing in the claim element precludes the step from practically being performed in the mind. For example, “determine whether a master application corresponding to the virtual machines has accepted a minion application corresponding to a first one of the virtual machines” in the context of this claim encompasses the user viewing data on a terminal and mentally determining if a minion application has been accepted. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Process” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claim additionally recites “at least one of scan or monitor the plurality of virtual machines” and “in response to the determination that the master application has not accepted the minion application, cause the master application to accept the minion application.” The scanning/monitoring and accepting the minion application amounts to insignificant extra solution activity of mere data gathering. See MPEP § 2106.05(g). The scanning/monitoring amounts to collecting data and the accepting the minion application amounts to recording information. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of “at least one of scan or monitor the plurality of virtual machines” and “in response to the determination that the master application has not accepted the minion application, cause the master application to accept the minion application” amounts to no more than insignificant extra solution activity of mere data gathering. See MPEP § 2106.05(g). The claim is not patent eligible.
Regarding claim 4, it additionally recites accepting a key, which amounts to mere data gathering. See MPEP § 2106.05(g). Accordingly, claim 4 is ineligible.
Regarding claim 5, it additionally recites determining and configuring. The determining can be performed mentally. The configuring amounts to mere data gathering. See MPEP § 2106.05(g). Accordingly, claim 5 is ineligible.
Regarding claim 6, it additionally recites scanning for compliance, which amounts to mere data gathering. See MPEP § 2106.05(g). Accordingly, claim 6 is ineligible.
Regarding claim 7, it additionally recites providing an enforcement request, which amounts to mere data gathering. See MPEP § 2106.05(g). Accordingly, claim 7 is ineligible.
Regarding claim 8, it additionally recites determining whether the application has been accepted, which can be performed mentally. Accordingly, claim 8 is ineligible.
Claims 9, 12-17, and 20 recite commensurate subject matter as claims 1 and 4-8. Therefore, they are rejected for the same reasons.
Claim Rejections - 35 USC § 112
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 5-8 and 13-16 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.
The term “determine whether the minion application is properly configured” in claim 5 is a relative term which renders the claim indefinite. The term “properly configured” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Claim 13 corresponds to claim 5; therefore, it is indefinite for the same reasons.
The term “scan . . . for compliance” in claim 6 is a relative term which renders the claim indefinite. The term “scan . . . for compliance” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Claim 14 corresponds to claim 6; therefore, it is indefinite for the same reasons. Claims 7, 8, 15, and 16 depend on claim 6 or 14; therefore, they are rejected for the same reason.
Claim Rejections - 35 USC § 103
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 2, 4, 9, 10, 12, 17, 18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over NPL 1 (SALT AS A CLOUD CONTROLLER, available at https://web.archive.org/web/20220627182754/https://docs.saltproject.io/en/latest/topics/tutorials/cloud_controller.html) and further in view of NPL 2 (Accepting the minion keys, available at https://web.archive.org/web/20221004012143/https://docs.saltproject.io/salt/install-guide/en/latest/topics/accept-keys.html).
Regarding claim 1, NPL 1 teaches: A system to manage a plurality of virtual machines of a shared computing resource (“In Salt 0.14.0, an advanced cloud control system was introduced, allowing private cloud VMs to be managed directly with Salt. This system is generally referred to as Salt Virt.”), the system comprising: interface circuitry; programmable circuitry; and machine readable instructions to cause the programmable circuitry to:
at least one of scan or monitor the plurality of virtual machines (Using Salt Virt, “Now that the new VM has been prepared, it can be seen via the virt.query command: salt-run virt.query This command will return data about all of the hypervisors and respective virtual machines”); and
a master application corresponding to the virtual machines (Using Salt Virt, “The Salt Virt runner will now automatically select a hypervisor to deploy the new virtual machine on. Using salt:// assumes that the CentOS virtual machine image is located in the root of the Salt File Server on the master”) and a minion application corresponding to a first one of the virtual machines (Using Salt Virt, “When a VM is initialized using virt.init, the image is copied to the hypervisor using cp.cache_file and will be mounted and seeded with a minion”).
NPL 1 does not teach; however, NPL 2 teaches: determine whether a master application accepted a minion application (Accepting keys, “When a new minion checks in, the key will wait in Unaccepted keys until it is accepted. Call salt-key to see the current state of key management: salt-key Example response: Unaccepted Keys: db1”); and
in response to the determination that the master application has not accepted the minion application, cause the master application to accept the minion application (Accepting keys, “In this example, to accept keys, run: salt-key -a db1”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of determine whether a master application accepted a minion application; and in response to the determination that the master application has not accepted the minion application, cause the master application to accept the minion application, as taught by Accepting the minion keys, in the same way to the master a, as taught by NPL 1. Both inventions are in the field of salt masters and minions, and combining them would have predictably resulted in providing “secure communication,” as indicated by NPL 2 (About the Salt key exchange).
Regarding claim 2, NPL 1 teaches: The system as defined in claim 1, wherein the programmable circuitry is to: scan the virtual machines for a corresponding minion application installed thereon; and install a minion application on each of the virtual machines not having a minion application installed thereon (USING SALT VIRT, “When a VM is initialized using virt.init, the image is copied to the hypervisor using cp.cache_file and will be mounted and seeded with a minion. Seeding includes setting pre-authenticated keys on the new machine. A minion will only be installed if one can not be found on the image using the default arguments to seed.apply.”).
Regarding claim 4, NPL 2 teaches: The system as defined in claim 1, wherein the programmable circuitry is to cause the master application to accept the minion application by directing the master application to accept a key of the minion application (Accepting keys, “In this example, to accept keys, run: salt-key -a db1”).
Claims 9, 10, 12, 17, 18, and 20 recite commensurate subject matter as claims 1, 2, and 4. Therefore, they are rejected for the same reasons.
Claim(s) 3, 11, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over NPL 1 and NPL 2, as applied above, and further in view of Carey (US 2016/0241490).
Regarding claim 3, NPL 1 and NPL 2 do not teach; however, Carey discloses: determine whether the master application is installed on at least one of the virtual machines (¶ 16, “the set of deployment topology data (e.g., a set of historical installation data, a record of dynamic management servers) may be analyzed. Based on corresponding data analytics, it can be determined to establish the dynamic management server”); and install the master application on the at least one of the virtual machines upon determination that none of the virtual machines has the master application installed thereon (¶ 57, “At block 470, the dynamic management server is established. The dynamic management server is communicatively connected with both the deployment server and the set of virtual machines (e.g., a gateway in between)” and “The dynamic management server may be established local to the set of virtual machines to deliver assets efficiently while meeting performance benchmarks (e.g., quickly and reliably)”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of determine whether the master application is installed on at least one of the virtual machines; and install the master application on the at least one of the virtual machines upon determination that none of the virtual machines has the master application installed thereon, as taught by Carey, in the same way to plurality of VMs, as taught by NPL 1 and NPL 2. Both inventions are in the field of providing management services to a plurality of VMs, and combining them would have predictably resulted in “managing asset deployment for a shared pool of configurable computing resources,” as indicated by Carey (¶ 1).
Claims 11 and 19 recite commensurate subject matter as claim 3. Therefore, they are rejected for the same reasons.
Claim(s) 5 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over NPL 1 and NPL 2, as applied above, and further in view of NPL 3 (CONFIGURING THE SALT MINION, available at https://web.archive.org/web/20221001142527/https://docs.saltproject.io/en/latest/ref/configuration/minion.html).
Regarding claim 5, NPL 1 and NPL 2 do not teach; however, NPL 3 discloses: scan the minion application to determine whether the minion application is properly configured (INCLUDE CONFIGURATION, “Configuration can be loaded from multiple files. The order in which this is done is: The minion config file itself”), and in response to the minion application not being properly configured, configure the minion application (KEEPALIVE SETTINGS, “Sets the ZeroMQ TCP keepalive count. May be used to tune issues with minion disconnects.”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of scan the minion application to determine whether the minion application is properly configured, and in response to the minion application not being properly configured, configure the minion application, as taught by NPL 3, in the same way to minions, as taught by NPL 1 and NPL 2. Both inventions are in the field of managing salt minions, and combining them would have predictably resulted in making the minions “amazingly simple and easy to configure,” as indicated by NPL 3 (CONFIGURING THE SALT MINION).
Claim 13 recites commensurate subject matter as claim 5. Therefore, it is rejected for the same reason.
Claim(s) 6-8 and 14-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over NPL 1 and NPL 2, as applied above, and further in view of De Santis (US 2015/0012920).
Regarding claim 6, NPL 1 and NPL 2 do not teach; however, De Santis discloses: the programmable circuitry is to scan each minion application of the virtual machines for compliance (¶ 13, “the compliance system may comprise a triggering unit adapted for triggering by the compliance agent a compliance scan for ensuring that the VM may comply with the compliance rule”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of scan the minion application to determine whether the minion application is properly configured, and in response to the minion application not being properly configured, configure the minion application, as taught by De Santis, in the same way to minions, as taught by NPL 1 and NPL 2. Both inventions are in the field of managing salt minions, and combining them would have predictably resulted in a method to “prevent the diffusion of the problem, like viruses, worms, spyware, etc,” as indicated by De Santis (¶ 5).
Regarding claim 7, De Santis discloses: The system as defined in claim 6, wherein the programmable circuitry is to enforce compliance policies of each of the minion applications by providing an enforcement request to a configuration service (¶ 61, “the compliance system--as shown--may comprise an applying 510 unit adapted for applying a remediation action to the VM using content of the copy of the compliance repository volume creating for reverting back the VM to a compliant state”).
Regarding claim 8, De Santis discloses: The system as defined in claim 7, wherein the programmable circuitry is to determine whether the master application has accepted the minion application in response to the enforcement request being provided to the configuration service (¶ 32, “the method may also comprise attaching back the virtual machine to the network. After such an operation, the VM may again be fully functional within the context of a data center. No further bottleneck may be expected. Such a re-attaching back to the computer network may be performed after the compliance scan that may have been performed after the remediation action”).
Claims 14-16 recite commensurate subject matter as claims 6-8. Therefore, they are rejected for the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 9:00-5:00.
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, Pierre Vital can be reached at (571) 272-4215. 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.
/JACOB D DASCOMB/ Primary Examiner, Art Unit 2198
Prosecution Insights