DETAILED ACTION
This communication is in response to the application filed on 3/06/2024 in which claims 1-13 are pending in the application. Claim 1 is in independent form.
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 .
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they do not include the following reference sign(s) mentioned in the description: "Figure S1" at [0041] and [0042] and "Figure S2" at [0041]. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
The drawings are objected to because:
T, and
Box 131 of Fig. 2C reads “Server that does not allows an ISO to be attached…”, but should read “does not allow” to be consistent with [0060] of the specification.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because it substantially restates claim 1 in claim-form phrasing ("The method comprises..."), and also carries the grammatical error of claim 1, "configuring a virtual networking". A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
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.
The disclosure is objected to because of the following informalities:
[0057] contains placeholders “The different types 111, 1XX, 1XX will be discussed in order”.
[0059] recites, “API patch is used to make the hose pxeboot on the next boot” but “hose” should read “host”.
The acronym “ISO” is given two different meanings. [0036] and the rest of the claims defines it as “Optical Disc Image (ISO)”, but [0058] defines it as “Identical Storage Image of Optical Media (ISO)”.
The term “coreswitch” is named as one word at [0036] where [0060] and Fig. 2C, boxes 133 and 135 name it as two words, “Core Switch”.
[0010] and [0012] uses “V-Twin” and “V-Twins” where [0034] uses “vTwin”.
Capitalization of certain terms need to be consistent: “pxelinux” at [0036] versus “PXELINUX” at [0059] to [0061] and in the figures; “VCenter” at [0042] and [0044] versus everywhere else.
[0043] recites [(an _C_ would dentote verification and correction), and “lockdownMode fives a more human readable]. [an _C_ would dentote] should read [a “_C_” would denote] and [“lockdownMode fives a] should read [“lockdownMode” gives a].
[0054] recites “FIGS.2A-D are a detailed view of Fig. 1” should read “are detailed views”. Additionally, the brief description of the drawings does not mention Figure S1 or Figure S2 that is referenced in [0041] and [0042].
Appropriate correction is required.
35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, requires the specification to be written in “full, clear, concise, and exact terms.” The specification is replete with terms which are not clear, concise and exact. The specification should be revised carefully in order to comply with 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112. Examples can be seen above.
Claim Objections
Claims 1-13 are objected to because of the following informalities:
In claims 1 and 12, “configurating a virtual networking” should be corrected to either “configuring virtual networking” or “configuring a virtual network”.
In claims 3, 4, and 5, a transitional phrase after ‘The method of claim 2,” is missing, such as “wherein” or “further comprising” before “detecting a hardware architecture…”.
In claims 4 and 5, the single article “a” disagrees with the plural term “images” of “Optical Disc Images”.
In claims 4 and 5, the article “an” is often used where “a” is required. For example, “an customized installation Optical Disc Images”.
In claim 11, the singular verb “comprises” disagrees with the plural subject “combat systems”.
In claim 12, “Virtual Tactical system” has inconsistent capitalization and does not conform to the terminology used elsewhere (“virtualized tactical system”, “virtual tactical environment”).
In claims 12 and 13, the word “Claim” is capitalized where in other claims it is in lowercase.
Appropriate correction is required.
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 1 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 1 recites the limitation "the virtualized tactical machines" in the last step. There is insufficient antecedent basis for this limitation in the claim. Claim 1 earlier recites “virtual machines essential for the operation of a virtualized tactical system” and “installing tactical virtual machines,” but “virtualized tactical machines” is never introduced. For examination purposes, the examiner has interpreted “the virtualized tactical machines” as the tactical machines recited earlier in claim 1. Claims 2 – 13 which depend on claim 1 are similarly rejected.
Claim 1 recites the limitation "the host hardware architecture" in the second step of the claim. There is insufficient antecedent basis for this limitation in the claim. The previous step of “determining at least one host hardware architecture” permits more than one architecture, and the singular “the host hardware architecture” is unclear which architecture the installing step is based on. For examination purposes, the examiner has interpreted “the host hardware architecture” as the at least one hardware architecture determined in claim 1. Claims 2 – 13 which depend on claim 1 are similarly rejected.
The term “essential” in claims 1 and 13 is a relative term which renders the claim indefinite. The term “essential” 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. There is no standard for which virtual machines being deployed and configured for the operation of a virtualized tactical system should . Claims 2 – 13 which depend on claim 1 are similarly rejected.
Claim 2 recites the limitation "the hypervisor deployment methodology". There is insufficient antecedent basis for this limitation in the claim. Claim 1, which claim 2 depends on, never recites a “methodology”, only a step of installing hypervisors. For examination purposes, the examiner has interpreted “the hypervisor deployment methodology” as the step of installing hypervisors recited in claim 1. Claims 3 – 5 which depend on claim 2 are similarly rejected.
Claims 3, 4, and 5 recite the limitation "the hypervisor". There is insufficient antecedent basis for this limitation in the claim. Claim 1, which claims 3, 4, and 5 depend on, introduces “hypervisors” in the plural, and it is unclear whether each claim is directed to one of the previously installed hypervisors, to each of them, or to a separately introduced hypervisor. For examination purposes, the examiner has interpreted “the hypervisor” as each hypervisor installed under claim 1.
Claim 4 recites the limitation "the host" in line 2 of the claim. There is insufficient antecedent basis for this limitation in the claim. Claim 1, which claim 4 depends on, only mentions “host” as a modifier within “host hardware architecture,” but never positively introduces a “host”. For examination purposes, the examiner has interpreted “the host” as the physical server on which the hypervisor is to be installed.
Claim 9 recites the limitation "the tactical virtual machine". There is insufficient antecedent basis for this limitation in the claim. Claim 1, which claim 9 depends on, recites “tactical virtual machines” in the plural, and it is unclear whether claim 9 covers all of them, one of them, or a new machine. For examination purposes, the examiner has interpreted “the tactical virtual machine” as each tactical virtual machine recited in claim 1. Claims 10 and 11 which depend on claim 9 are similarly rejected.
Claim 11 recites the limitation "the combat systems". There is insufficient antecedent basis for this limitation in the claim. Claims 9, which claim 11 depends on, recites a “combat system” in the singular. For examination purposes, the examiner has interpreted “the combat systems” as the combat system of claim 9.
Claim 13 recites the limitation "the configuration of virtual machines". There is insufficient antecedent basis for this limitation in the claim. Claim 1, which claim 13 depends on, recites the act of “configuring virtual machines”, but never a “configuration”. For examination purposes, the examiner has interpreted “the configuration of virtual machines” as the configuring of virtual machines recited in claim 1, performed for each tactical system, where that configuring includes host names, MAC addresses, Internet Protocol addresses, and networking uplinks.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 3, 4, 5, and 7 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Claims 3, 4, and 5 each read "The method of claim 2, detecting a hardware architecture ..." with no transitional phrase, such as "wherein" or "further comprising", that links the added language to claim 2.
Claim 7 does not further limit claim 1 from which it depends on. Claim 1 already recites “applying security guidelines and configurations to ensure the system’s integrity”, and the claim 7 recitation of “application of security guidelines across the system” just restates the “applying security guidelines” step already stated in claim 1, and does not further limit.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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 – 13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more.
Step 1:
Claims 1 – 13 are directed to a method and therefore is a process, which is one of the statutory categories of inventions.
Step 2A, Prong 1:
Claim 1 recites the limitations “determining at least one host hardware architecture,” and “installing hypervisors on each host within a system based on the host hardware architecture,” which, as drafted, are functions that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. For example, a person could mentally observe a host and determine its hardware architecture and decide on the basis of that architecture how the hypervisor is to be installed on each host. The limitations encompass a human mind carrying out the functions through observation, evaluation, judgement and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas under Prong 1 (MPEP 2106.04(a)(2)(III)).
Step 2A, Prong 2:
The judicial exception is not integrated into a practical application. The additional limitations “deploying and configuring virtual machines essential for the operation of a virtualized tactical system,” “configuring a virtual networking, configuring virtual management, and installing tactical virtual machines,” “applying security guidelines and configurations to ensure the system’s integrity,” and “deploying the virtualized tactical machines,” are recited at a high level of generality without any restriction on how they are accomplished and no description of the mechanism for accomplishing them, which is equivalent to the words “apply it” and amounts to no more than mere instructions to apply the judicial exception (MPEP 2106.05(f)). The limitations “hosts,” “hypervisors,” “virtual machines,” “virtual networking,” and “virtual management” on which these acts are performed on are recited generically and do no more than link the abstract idea to a generic virtualization computing environment (MPEP 2106.05(h)). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception.
Step 2B:
The limitations of “deploying and configuring virtual machines essential for the operation of a virtualized tactical system,” “configuring a virtual networking, configuring virtual management, and installing tactical virtual machines,” “applying security guidelines and configurations to ensure the system’s integrity,” and “deploying the virtualized tactical machines,” amounts to no more than mere instructions to apply the judicial exception and are well-understood, routine, and conventional activity when claimed at this level of generality (MPEP 2106.05(d)). The recited the recited “hosts,” “hypervisors,” “virtual machines,” “virtual networking,” and “virtual management” are generic components recited at a high level of generality and do no more than link the abstract idea to a generic virtualization computing environment. Accordingly, the additional elements do not amount to significantly more than the judicial exception, thus cannot provide an inventive concept.
Dependent Claims:
Claim 2 recites “wherein the hypervisor deployment methodology is adaptable to various hardware manufacturers and licensing levels” which describes a characteristic of the recited deployment determination and is part of the abstract idea rather than an additional element beyond it (MPEP 2106.04(a)(2)), and does not amount to significantly more. Claim 3 recites “detecting a hardware architecture and license that allows the hypervisor to be installed using Application Programming Interface (API) mounted customized Optical Disc Images (ISO) and installing the hypervisor using Application Programming Interface (API) mounted customized Optical Disc Images (ISO),” in which “detecting…” is a mental observation and evaluation (MPEP 2106.04(a)(2)(III)) and the recited API mounted ISO installation is recited at a high level of generality without any restriction on how it is accomplished and no description of the mechanism for accomplishing it, which is equivalent to the words “apply it” and amounts to no more than mere instructions to apply the judicial exception (MPEP 2106.05(f)), and does not amount to significantly more.
Claim 4 recites “detecting a hardware architecture and license that allows the hypervisor to be installed by pulling information from the host via an Application Programming Interface (API) to allow network booting of an customized installation Optical Disc Images (ISO) and installing the hypervisor by pulling information from the host via an Application Programming Interface (API) to allow network booting of an customized installation Optical Disc Images (ISO),” in which “detecting…” is a mental observation and evaluation (MPEP 2106.04(a)(2)(III)) and the recited network booting via an API, is recited at a high level of generality without any restriction on how it is accomplished and no description of the mechanism for accomplishing it, which is equivalent to the words “apply it” and amounts to no more than mere instructions to apply the judicial exception (MPEP 2106.05(f)), and does not amount to significantly more.
Claim 5 recites “detecting a hardware architecture and license that allows the hypervisor to be installed by pulling information from a network switch or user input to allow network booting of a customized installation Optical Disc Images (ISO) and installing the hypervisor by pulling information from a network switch or user input to allow network booting of an customized installation Optical Disc Images (ISO),” ),” in which “detecting…” is a mental observation and evaluation (MPEP 2106.04(a)(2)(III)) and the recited network booting via a network switch or user input is recited at a high level of generality without any restriction on how it is accomplished and no description of the mechanism for accomplishing it, which is equivalent to the words “apply it” and amounts to no more than mere instructions to apply the judicial exception (MPEP 2106.05(f)), and does not amount to significantly more.
Claim 6 recites “wherein the applying security guidelines and configurations further comprises verification of security guidelines across the system,” which itself is mental process that can be performed by a human mind through observation, evaluation, judgement, and/or opinion, or even with the aid of pen and paper (MPEP 2106.04(a)(2)(III)), and does not amount to significantly more.
Claim 7 recites “wherein the applying security guidelines and configurations further comprises application of security guidelines across the system,” which recites the execution act of applying the security guidelines, is recited at a high level of generality without any restriction on how it is accomplished and no description of the mechanism for accomplishing it, which is equivalent to the words “apply it” and amounts to no more than mere instructions to apply the judicial exception (MPEP 2106.05(f)), and does not amount to significantly more.
Claim 8 recites “wherein the applying security guidelines and configurations further comprises generating reports that will be used to certify the security posture of a virtualized tactical system,” which is insignificant extra-solution activity of mere outputting of the results of the abstract process (MPEP 2106.05(g)), and does not amount to significantly more.
Claim 9 recites “wherein the tactical virtual machine is a combat system capable of tracking and guiding weapons to destroy a target,” which specifies the use of the deployed tactically virtual machine and does no more than generally link the use of the abstract idea to a particular field of use (MPEP 2106.05(h)), and does not amount to significantly more.
Claim 10 recites “wherein configuring a virtual network, configuring virtual management, and installing tactical virtual machines, is unique to each instance of the combat system to include a plurality of distinct virtual networks to ensure operability,” which specifies that the configuration is tailored to each instance and describes their content, namely “a plurality of distinct virtual networks,” rather than reciting an additional element beyond the exception (MPEP 2106.05(a)(2)), and does not amount to significantly more.
Claim 11 recites “wherein the combat systems further comprises at least twenty (20) distinct virtual networks,” which describes the content of the configuration, namely the number of distinct virtual networks, rather than reciting additional elements beyond the exception (MPEP 2106.04(a)(2)), and does not amount to significantly more.
Claim 12 recites “wherein configuring a virtual networking, configuring virtual management, and installing tactical virtual machines, is unique to each Virtual Tactical system,” which specifies that the configuration is tailored to each system rather than reciting an additional element beyond the exception (MPEP 2106.05(a)(2)), and does not amount to significantly more.
Claim 13 recites “wherein deploying and configuring virtual machines essential for the operation of a virtualized tactical system, is unique to all tactical systems and wherein the configuration of virtual machines includes hostnames, MAC addresses, Internet Protocol Addresses, and Networking uplinks,” which specifies that the deployment and configuration is tailored to all systems and describes its content, namely “hostnames, MAC addresses, Internet Protocol Addresses, and Networking uplinks,” rather than reciting an additional element beyond the exception (MPEP 2106.05(a)(2)), and does not amount to significantly more.
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.
Claim(s) 1 and 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bronheim et al. (US 10,678,558) (hereinafter Bronheim) in view of Shilawat et al. (US 2023/0021216 A1) (hereinafter Shilawat) in view of Atur et al. (US 11,528,186) (hereinafter Atur).
As per claim 1, Bronheim primarily teaches the invention as claimed including:
a method for automating the deployment, configuration, and security of virtualized tactical systems, the method comprising:
determining at least one host hardware architecture (col. 3:12-14 each of the host 110 and 120 boots up and sends its hardware information to the DCM system 130);
installing hypervisors on each host within a system (col. 3:16-22 when the DCM system 130 receives the hardware information from each of the host OS 110 and 120 ... the DCM system 130 may then send a second API request to the application 132; col. 3:49-52 the user may also provision a request to the DCM system 130 via the virtualization management system 140 to initialize the selected hosts 110 and 120 to a hypervisor with the defined set of configurations);
deploying and configuring virtual machines (col. 5:61-64 the virtualization management system 240 deploys the hypervisor 214 into the host 210 to initiate creation and execution of the VM1 215 through VMn 216 in the host 210; col. 6:30-36 configure hosts ... define networks, create virtual machines ... use templates from the management system (e.g., VM templates that are used for creating new VMs with predefined settings and preinstalled disk images));
configuring a virtual networking, configuring virtual management, and installing (col. 5:8-10 such configuration may include but not limited to network configurations and services to be run by the selected hosts OS 210 and 220; col. 5:44-51 the plugin component 234 places the hosts 210, 220 in a state such that the hosts 210, 220 are managed by the virtualization management system 240 ... initializing and configuring virtualization in the hosts 210, 220; col. 5:52-54 the virtualization management system 240 deploys VMs 215, 216 and VMs 225, 226 on the hosts 210 and 220, respectively);
Bronheim does not explicitly teach:
installing hypervisors based on the host hardware architecture;
virtual machines essential for the operation of a virtualized tactical system;
installing tactical virtual machines;
applying security guidelines and configurations to ensure the system's integrity; and
deploying the virtualized tactical machines.
However, Shilawat teaches:
virtual machines essential for the operation of a virtualized tactical system ([0044] a cloud-in-a-box appliance may include a container provided as a PaaS (e.g., a Linux container, hypervisor such as Xen, Oracle VirtualBox, Oracle VM, KVM, VMware ESX/ESXi, Hyper-V, etc.) that runs one or more virtual machines; [0027] having readily available capabilities that include elastic computation, advanced analytics, and artificial intelligence (AI)/machine learning (ML), as disclosed herein, will provide tremendous value to warfighters at the edge);
installing tactical virtual machines ([0029] autonomous cyber defense capabilities deployed at the tactical edge; [0044] pools of containers within a cloud-in-a-box appliance-based operational system may support large numbers of virtual machines and the ability to scale services up and/or down according to varying requirements);
applying security guidelines and configurations to ensure the system's integrity ([0033] vulnerability scanners may be used to remediate compromised or misconfigured hosts through automated patch distribution or security technical implementation guide (STIG) remediation. Secure industry standard templates ... may be adapted to maintain secure configurations of hosts and network devices, preventing unapproved modifications and reverting any misconfiguration or unauthorized changes to a known good state; [0035] the integrated capability may automatically provision required security controls for the tactical community at machine speed); and
deploying the virtualized tactical machines ([0029] implementations of the disclosed subject matter provide autonomous cyber defense capabilities deployed at the tactical edge and [0044]).
Shilawat and Bronheim are both concerned with deploying and running virtual machines on host computing platforms and are therefore combinable/modifiable. Bronheim deploys and runs its virtual machines regardless of the software they run, so swapping in the tactical virtual machines of Shilawat is a simple substitution of one known element for another. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the tactical virtual machines of Shilawat as the virtual machines deployed by the automated provisioning of Bronheim, because the substitution would predictably yield the tactical virtual machines of Shilawat deployed by the automated method of Bronheim. This substitution requires no change to how the automated method of Bronheim initializes the hosts or deploys the virtual machines.
Shilawat further teaches automated remediation of hosts through patch distribution or security technical implementation guide (STIG) remediation using secure industry standard templates ([0033]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bronheim in view of Shilawat by applying the automated security remediation of Shilawat to the hosts and virtual machines provisioned by Bronheim, because it would provision the required security controls at machine speed ([0035]) rather than at the pace of manual configuration. The hosts of Bronheim are hardened without cybersecurity personnel configuring each one by hand.
Bronheim in view of Shilawat do not explicitly teach:
installing hypervisors based on the host hardware architecture.
However, Atur teaches installing hypervisors based on the host hardware architecture (col. 11:66-col. 12:5 there may be a kickstarter associated with each SKU (stock keeping unit) defining a type of server 1302. Accordingly, the kickstarter installed at step 1402 may be that which corresponds to the SKU of the server 1302. The kickstarter may include a profile of the server 1302, such as according to the Basic, EPA-1, EPA1-test, and/or EPA2 system profile types).
Atur and Bronheim are both concerned with automated initialization of bare-metal servers and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bronheim in view of Shilawat in view of Atur by selecting the kickstarter that carries the hypervisor according to each host's SKU, because the matching image would be delivered to each server without a technician identifying the hardware or accessing its BMC (col. 14:41-43). Bronheim applies one user-defined configuration to the selected hosts, so adding the SKU-keyed selection of Atur extends the same automated deployment to systems built from more than one server model.
As per claim 7, Shilawat further teaches wherein the applying security guidelines and configurations further comprises application of security guidelines across the system ([0033] secure industry standard templates ... may be adapted to maintain secure configurations of hosts and network devices; [0035] the integrated capability may automatically provision required security controls for the tactical community at machine speed).
Claim(s) 2, 4, and 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bronheim in view of Shilawat in view of Atur in view of Cisneros et al. (US 2019/0095593 A1) (hereinafter Cisneros).
As per claim 2, Atur further teaches wherein the hypervisor deployment methodology is adaptable to various hardware manufacturers (col. 11:66-col. 12:3 there may be a kickstarter associated with each SKU (stock keeping unit) defining a type of server 1302. Accordingly, the kickstarter installed at step 1402 may be that which corresponds to the SKU of the server 1302; col. 12:10-14 the kickstarter may include computer instructions that instruct the server 1302 to communicate with the machine initialization module (MIM) 118 using the baseboard management controller (BMC) IP address with which the server 1302 was configured by a manufacturer; col. 14:31-43 many vendors, such as DELL, QUANTA, and SUPERMICRO, provide an interface for mounting of a bootable ISO file ... in the automated approach, the ISO file is transferred directly to the BMC according to an interface provided by the vendor).
Bronheim in view of Shilawat in view of Atur do not explicitly teach wherein the hypervisor deployment methodology is adaptable to various licensing levels.
However, Cisneros teaches wherein the deployment methodology is adaptable to various licensing levels ([0012] when the service OS or provisioning engine boot, the licensing state of the computing device is inventoried and upgradeable devices can be flagged for a user. If the user expresses interest in an upgrade, the provisioning engine can collect available licenses, costs, SKUs, etc. from a license device; [0031] the provisioning engine 120 can apply the decrypted license information to the computing device 200).
Cisneros and Bronheim are both concerned with automated provisioning of server computing devices and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bronheim in view of Shilawat in view of Atur in view of Cisneros because it would give the deployment a simple, secure, and fast way to read and apply license keys through the BMC ([0010]). The licenses stay tied to the unit like a hardware component ([0010]). The check runs before any operating system exists on the server ([0016]), so no operator inspects entitlements by hand.
As per claim 4, the combination of references above teaches detecting a hardware architecture (Bronheim col. 3:13-15 each of the host 110 and 120 boots up and sends its hardware information to the DCM system 130; Atur col. 11:59-62 the configuration of the server 1302 may be represented using a JAVASCRIPT Object Notation (JSON) file that describes the hardware, firmware, and/or software versions of the server 1302) and license (Cisneros [0012] the licensing state of the computing device is inventoried and upgradeable devices can be flagged for a user; [0030] the provisioning engine 120 can provide encrypted license information to the BMC 110 to obtain decrypted license information. The encryption engine 218 can provide an API to the provisioning engine 120 to obtain the decrypted license information) that allows the hypervisor to be installed by pulling information from the host via an Application Programming Interface (API) (Bronheim col. 3:17-22 when the DCM system 130 receives the hardware information from each of the host OS 110 and 120 ... the DCM system 130 may then send a second API request to the application 132; Atur col. 12:10-14 the kickstarter may include computer instructions that instruct the server 1302 to communicate with the machine initialization module (MIM) 118 using the baseboard management controller (BMC) IP address) to allow network booting of a customized installation Optical Disc Images (ISO) (Atur col. 13:17-25 the EFI image may be obtained from a boot configuration file including the above-described instructions to configure the server IP address, network gateway, and retrieve and install the operating system kernel ... written in IPXE (an open source implementation of the Preboot Execution Environment client firmware and bootloader) scripting language; col. 14:26-29 the server system 1302 receives 1502 the ISO file including the EFI image, such as using the BMC IP address of the server system 1302 over a network; col. 11:66-col. 12:3) and installing the hypervisor by pulling information from the host via an Application Programming Interface (API) to allow network booting of a customized installation Optical Disc Images (ISO) (same passages, Bronheim col. 3:17-22 and Atur col. 12:10-14, col. 13:17-25, and col. 14:26-29).
As per claim 5, the combination of references above teaches detecting a hardware architecture (Bronheim col. 3:13-15; Atur col. 11:59-62) and license (Cisneros [0012]; [0030]) that allows the hypervisor to be installed by pulling information from ... user input (Bronheim col. 3:44-46 the user may select one or more of the hosts 110 and 120 and define a set of configurations for the selected hosts 110 and 120; col. 3:49-52 the user may also provision a request to the DCM system 130 via the virtualization management system 140 to initialize the selected hosts 110 and 120 to a hypervisor with the defined set of configurations) to allow network booting of a customized installation Optical Disc Images (ISO) (Atur col. 13:17-25; col. 14:26-29; col. 11:66-col. 12:3) and installing the hypervisor by pulling information from ... user input to allow network booting of a customized installation Optical Disc Images (ISO) (same passages).
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bronheim in view of Shilawat in view of Atur in view of Cisneros in view of Maity et al. (US 9,026,635) (hereinafter Maity).
As per claim 3, the combination of references above teaches detecting a hardware architecture (Bronheim col. 3:13-15 each of the host 110 and 120 boots up and sends its hardware information to the DCM system 130; Atur col. 11:59-62 the configuration of the server 1302 may be represented using a JAVASCRIPT Object Notation (JSON) file that describes the hardware, firmware, and/or software versions of the server 1302) and license (Cisneros [0012] the licensing state of the computing device is inventoried and upgradeable devices can be flagged for a user; [0030] the encryption engine 218 can provide an API to the provisioning engine 120 to obtain the decrypted license information) that allows the hypervisor to be installed.
Bronheim in view of Shilawat in view of Atur in view of Cisneros do not explicitly teach installing the hypervisor using Application Programming Interface (API) mounted customized Optical Disc Images (ISO).
However, Maity teaches installing the hypervisor using Application Programming Interface (API) mounted customized Optical Disc Images (ISO) (abstract establishing a Web Socket connection between a web server of a baseboard management controller (BMC) and a browser program of a computing device in a network ... emulating, at the BMC, virtual media to the host computer; col. 9:26-30 the USB connection allows the BMC 120 to emulate USB mass storage devices, such as a floppy, CD-ROM, or hard disk drive, to the host computer 110 ... those emulated devices can be used by the host computer 110 as boot-up devices; col. 9:45-47 the emulated CD-ROM device may be utilized to redirect the content of an ISO image 148 on the computing device 140 to the host computer 110).
Maity and Bronheim are both concerned with remote management of host computers over a network and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bronheim in view of Shilawat in view of Atur in view of Cisneros in view of Maity by delivering the customized installation ISO of Atur through the virtual media redirection of Maity, because the host would read the image with the standard CD-ROM driver of its operating system, and custom hardware drivers may be unnecessary (col. 9:50-55). The serving side only needs a browser that complies with the HTML5 standard and reads the ISO without any native calls (col. 9:62-64). Adding the redirection of Maity gives the combination one delivery mechanism that behaves the same on every host, instead of the separate mounting interface each vendor provides in Atur.
Claim(s) 6 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bronheim in view of Shilawat in view of Atur in view of Williams et al. (US 8,561,175) (hereinafter Williams).
As per claim 6, Bronheim in view of Shilawat in view of Atur do not explicitly teach wherein the applying security guidelines and configurations further comprises verification of security guidelines across the system.
However, Williams teaches verification of security guidelines across the system (col. 2:22-26 automatically initiating the network audit based on the configuration information to gather information about the network; electronically applying a network policy to the gathered network information; determining compliance with the network policy; col. 5:20-23 the compliance server 10 is coupled to the audit servers 12 and the audit repository 14 for tracking, from a central location, the overall health of the global network in terms of security and/or regulation compliance).
Williams and Bronheim are both concerned with centralized management of networked computer systems and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bronheim in view of Shilawat in view of Atur in view of Williams because it would track the security compliance of every deployed host from a central location (col. 5:20-23). Each violation found becomes a task that is monitored until completion (col. 2:26-28). Shilawat applies the security templates host by host, so adding Williams gives the combination a single point that follows every host and every open violation.
As per claim 8, Williams further teaches wherein the applying security guidelines and configurations further comprises generating reports that will be used to certify the security posture of a virtualized tactical system (col. 5:30-34 the compliance server 10 also provides consolidated visibility into the security of the network and the various assessments that have been made about policy compliance, via various types of reports that may be generated manually or automatically based on predetermined conditions; col. 17:64-66 the P&V engine may calculate a standardized score representing the organization's security posture).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bronheim in view of Shilawat in view of Atur in view of Roberts ("Virtualization of AEGIS: A Study of the Feasibility of Applying Open Architecture Technology to the Surface Navy's Most Complex Automated Weapon System," Naval Postgraduate School thesis, September 2011) (hereinafter Roberts).
As per claim 9, Bronheim in view of Shilawat in view of Atur do not explicitly teach wherein the tactical virtual machine is a combat system capable of tracking and guiding weapons to destroy a target.
However, Roberts teaches a combat system capable of tracking and guiding weapons to destroy a target (section III.B.2, page 15 the AWS is responsible for allowing Navy warships to detect, track, and prosecute multi-mission contacts and targets; section III.A.2, page 13, listing the Weapons Control System, Fire Control System, Guided Missile Vertical Launching System, and Standard Guided Missile among the ten AEGIS subsystems) implemented as the tactical virtual machine (abstract, page v a locally-constructed test platform, designed to simulate a portion of the U.S. Navy's AEGIS Combat System; section I.D, page 4 VMware virtual software, running on Intel-based Dell blade servers is proposed as a technical solution; section IV.A, pages 25 to 26 and fig. 7, the AEGIS-VM blade server).
Roberts and Bronheim are both concerned with running computing workloads as virtual machines on commodity server hardware and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bronheim in view of Shilawat in view of Atur in view of Roberts by deploying the AEGIS combat-system components of Roberts as the tactical virtual machines, because it would replace the legacy AEGIS computer cabinets with a smaller commodity server rack that uses less space, power, and cooling aboard ship. The commodity hardware provides the same computing performance as the proprietary equipment it replaces. The same virtualized server design can be used on every AEGIS platform without computing hardware adapted to each baseline.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bronheim in view of Shilawat in view of Atur in view of Roberts in view of Khandekar et al. (US 7,577,722) (hereinafter Khandekar).
As per claim 10, Roberts further teaches configuring a virtual network ... to include a plurality of distinct virtual networks to ensure operability (section IV.D.4, pages 38 to 39 VLANs use logical connections rather than physical connections ... most relevant to AEGIS ... is the isolation of iSCSI traffic ... separation of SAN traffic from other network traffic provides switch-based security enhancements such as port blocking and address filtering; section IV.D.3, page 38 this would likely prove critical to AEGIS threat engagement, tracking, and prosecution).
Bronheim in view of Shilawat in view of Atur in view of Roberts do not explicitly teach wherein configuring a virtual network, configuring virtual management, and installing tactical virtual machines, is unique to each instance of the combat system.
However, Khandekar teaches wherein the configuring is unique to each instance of the deployed system (col. 3:12-14 the system administrator therefore gives this machine a new identity by assigning it a new hostname and a new IP address; col. 8:57-62 staging is the step of taking the model VM and stripping off its identity (Security ID in Microsoft Windows operating systems, IP Address, etc.) and configuring it such that next time it is booted, it runs a tool to assign a new identity (a new SID, computer name, IP address, etc.)).
Khandekar and Bronheim are both concerned with deploying virtual machines onto physical host platforms and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bronheim in view of Shilawat in view of Atur in view of Roberts in view of Khandekar by having each deployed instance of the combat system take its identity from the staging tool of Khandekar at deployment, rather than from the user-defined configuration of Bronheim, because the configuration would then be authored once and reused for every deployment instead of edited by hand each time. Since the staging tool assigns a fresh identity on every run, each instance the method deploys necessarily comes out configured uniquely. Each deployed system can also be addressed and managed individually over the network by the virtualization management system of Bronheim.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bronheim in view of Shilawat in view of Atur in view of Roberts in view of Khandekar in view of Chang (US 10,205,657) (hereinafter Chang).
As per claim 11, Bronheim in view of Shilawat in view of Atur in view of Roberts in view of Khandekar do not explicitly teach wherein the combat systems further comprises at least twenty (20) distinct virtual networks.
However, Chang teaches at least twenty (20) distinct virtual networks (col. 1:19-22 VXLAN can deploy millions of virtual networks within a data center through a tenant ID (i.e., VXLAN ID, or VXLAN Network Identifier (VNI), or VXLAN Segment ID) with 24 bits).
Chang and Bronheim are both concerned with networking virtual machines in a data center and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bronheim in view of Shilawat in view of Atur in view of Roberts in view of Khandekar in view of Chang because it would run as many separate virtual networks as needed over the existing physical network without adding switching hardware. Unlike the VLANs of Roberts, the VXLAN networks are not confined to a single physical network segment.
Claim(s) 12 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bronheim in view of Shilawat in view of Atur in view of Khandekar.
As per claim 12, Bronheim in view of Shilawat in view of Atur do not explicitly teach wherein configuring a virtual networking, configuring virtual management, and installing tactical virtual machines, is unique to each Virtual Tactical system.
However, Khandekar teaches wherein the configuring is unique to each deployed system (col. 3:12-14 the system administrator therefore gives this machine a new identity by assigning it a new hostname and a new IP address; col. 8:57-62 staging is the step of taking the model VM and stripping off its identity ... and configuring it such that next time it is booted, it runs a tool to assign a new identity (a new SID, computer name, IP address, etc.); col. 9:17-19 clone an existing, pre-built model VM and configure a few parameters, such as host name, IP address, etc.).
Khandekar and Bronheim are both concerned with deploying virtual machines onto physical host platforms and are therefore combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bronheim in view of Shilawat in view of Atur in view of Khandekar by having each deployed Virtual Tactical system take its identity from the staging tool of Khandekar at deployment, rather than from the user-defined configuration of Bronheim, because the configuration would then be authored once and reused for every deployment instead of edited by hand each time. Since the staging tool assigns a fresh identity on every run, each Virtual Tactical system the method deploys necessarily comes out configured uniquely. Each deployed system can also be addressed and managed individually over the network by the virtualization management system of Bronheim.
As per claim 13, Khandekar further teaches wherein deploying and configuring virtual machines essential for the operation of a virtualized tactical system, is unique to all tactical systems (col. 8:57-62) and wherein the configuration of virtual machines includes hostnames, MAC addresses, Internet Protocol Addresses (col. 10:9-12 the user will usually also need to specify the desired OS configuration, for example, hostname, IP address, MAC address of the network cards), and Networking uplinks (col. 10:5-7 the user thus specifies the hardware characteristics of the desired machine, such as memory size, number, type and size of disks, number of network cards; Bronheim col. 5:8-10 network configurations and services to be run by the selected hosts OS 210 and 220).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Price (US 11,163,890) discloses bash scripts that “automatically assess the compliance of various aspects of the target computer system” against STIG-parsed security settings and generate a STIG-formatted output file (Abstract), which relates to the claimed invention of automated verification of, and reporting to, compliance with the system’s security guidelines.
Roach (US 11,509,678) discloses systems and methods that “dynamically conduct automatic security assessments to determine security compliance for one or more applications” (Abstract) which relates to the claimed automated verification of compliance with the system’s security guidelines.
The DMTF Redfish Specification (DSP0266), version 1.20.0, discloses “an interoperable, multivendor, remote, and out-of-band capable interface” for platform management (§1 Scope, ¶1), whose VirtualMedia resource exposes an InsertMedia action that attaches an ISO image to the host through the management controller, which relates to the claimed installation using an API mounted ISO.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THANH NGO whose telephone number is (571)270-3019. The examiner can normally be reached M-F 9am to 6pm ET, first F of biweek off.
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.
/T.N./ Examiner, Art Unit 2198
/PIERRE VITAL/ Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights