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 .
Response to Arguments
Applicant’s arguments, see pages 6 and 7, filed 30 March 2026, with respect to the rejection under 35 U.S.C. § 101 of claims 1-7 and 15-20 have been fully considered and are persuasive. The rejection under 35 U.S.C. § 101 of claims 1-7 and 15-20 has been withdrawn.
Applicant’s arguments, see page 7, filed 30 March 2026, with respect to the rejection under 35 U.S.C. § 112(b) of claim 19 have been fully considered and are persuasive. The rejection under 35 U.S.C. § 112(b) of claim 19 has been withdrawn.
Applicant's arguments filed 30 March 2026, regarding the rejection under 35 U.S.C. § 103 have been fully considered but they are not persuasive.
Applicant contends that “Parihar's service orchestration deploys services to local control planes; it does not deploy a specific VM with licensed features and manager- describing metadata as part of a desired state.” Remarks 7.
The Examiner respectfully disagrees. Parihar teaches “the local control planes can provide multi-VIM support, including activating and aggregating the VIMs” (col. 10:17-19) and “[t]he orchestration node can perform topology management of network services instances” (col. 7:28-30). Further, Parihar discloses “a centralized network software system which provides access tokens, or keys, to client components in order to enable licensed services and software to run on them” (col. 3:64-67), which the Examiner finds teaches or at least suggests the recited “deploying the VM to execute in the at least one on-premises data center with enablement of a licensed feature” (claim 1).
Additionally, Parihar discloses that “the services and information associated with the local control planes can being aggregated at the orchestration node” (col. 10:38-39), which the Examiner finds teaches or at least suggests the recited “deploying the VM to execute in the at least one on-premises data center with . . . metadata describing the manager VIM appliance as set forth in the desired state” (claim 1).
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-3, 7, 15, 16, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Parihar (US 2020/0379793) and further in view of Sinha (US US2023/0030000).
Regarding claim 1, Parihar teaches: A method of enabling a virtual infrastructure management (VIM) appliance for lifecycle management, the method comprising:
identifying, by a cloud platform executing in a public cloud (¶ 23, “a typical multicloud architecture using two or more public clouds”), a manager VIM appliance for the VIM appliance (¶ 28, “The orchestration nodes can be deployed in each region to manage local nodes such as local control planes and associated VIMs”), the manager VIM appliance and the VIM appliance executing in at least one on-premises data center of an on-premises environment (¶ 52, “The deployment, automation, and management software application 304 can bundle compute, storage and network virtualization into a single platform that can deployed on premises as a private cloud or run as a service within a public cloud” and ¶ 51);
obtaining information related to a management cluster having the manager VIM appliance and a virtual machine (VM) executing the VIM appliance (¶ 37, “The local control planes can use the VIMs to keep inventory of VMs associated with physical resources”);
creating and applying, by the cloud platform in response to the information, a desired state for both the manager VIM appliance and the VIM appliance (¶ 39, “The orchestration node can perform service orchestration to create the end-to-end service among different local control planes and associated VIMs on different clouds” and ¶ 56, “the local control plane can insulate and abstract the VIMs, converting requests to the control plane into actionable requests at the VIMs”), by deploying the VM to execute in the at least one on-premises data center with enablement of a licensed feature ((col. 3:64-67), “a centralized network software system which provides access tokens, or keys, to client components in order to enable licensed services and software to run on them,” keys to enable licensed services corresponds to the recited enablement of a licensed feature) and metadata describing the manager VM appliance as set forth in the desired state (col. 10:38-39, “the services and information associated with the local control planes can being aggregated at the orchestration node,” the information corresponds to the recited metadata); and
updating the cloud platform with a topology of the manager VIM appliance and the VIM appliance in the management cluster (¶ 39, “The orchestration node can perform topology management of network services instances. The orchestration node can serve to bind together different functions of the local control plane and can create an end-to-end service in addition to performing resource coordination in an otherwise dispersed NFV environment”).
Parihar does not teach as clearly as Sinha teaches: creating and applying a desired state for both the manager VIM appliance and the VIM appliance (¶ 12, “an infrastructure administrator 116 to manually configure VIM server 112 after its installation in order to setup the various features/properties of VIM server 112 and its inventory of virtual infrastructure components (shown via step (2)/reference numeral 118)” and ¶ 14, “a desired state definition for VIM server 112 that specifies, among other things, the topology of the virtual infrastructure to be managed by VIM server 112 and the desired features/properties of VIM server 112 and each virtual infrastructure component,” the topology of the virtual infrastructure to be managed corresponds to the VIM appliance).
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 creating and applying a desired state for both the manager VIM appliance and the VIM appliance, as taught by Sinha, in the same way to the method, as taught by Parihar. Both inventions are in the field of configuring VIM appliances, and combining them would have predictably resulted in a method configured to “centrally manage and configure a virtual infrastructure,” as indicated by Sinha (¶ 3).
Regarding claim 2, Parihar teaches: The method of claim 1, wherein the cloud platform includes cloud services (¶ 39, “deploy, by the orchestration node, services to the first and second local control planes”) and the on-premises environment includes agent platform appliances (¶ 52, “the deployment, automation, and management software application 304 can include an integrated software stack that can use software-defined data center (“SDDC”) as an automated lifecycle management tool”), the agent platform appliances including cloud agents cooperating with the cloud services, and wherein the cloud platform performs the steps of identifying, obtaining, creating, and updating using the cloud services and the cloud agents (¶ 55, “a software tool for the management of public, private and hybrid cloud environments. The cloud management platform application 308 can incorporate self-service interfaces, provision system images, enable metering and billing, and provide for some degree of workload optimization through established policies”).
Regarding claim 3, Parihar teaches: The method of claim 2, wherein the cloud agents communicate with services executing in the manager VIM appliance and the VIM appliance (¶ 37, “the first and second local control planes interfacing with different respective VIMs, where the first and second local control planes establish secure communication with the orchestration node”).
Regarding claim 7, Parihar teaches: The method of claim 1, wherein the desired state of the VIM appliance includes enablement of features licensed through cloud platform including the licensed feature (col. 3:64-67, “an entitlement server can include a centralized network software system which provides access tokens, or keys, to client components in order to enable licensed services and software to run on them”).
Claims 15, 16, and 20 recite commensurate subject matter as claims 1, 2, and 7. Therefore, they are rejected for the same reasons.
Claim(s) 4 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Parihar and Sinha, as applied above, and further in view of Strandzhev (US 2017/0005873).
Regarding claim 4, Parihar and Sinha do not teach; however, Strandzhev discloses: the desired state of the manager VIM appliance includes the VM executing the VIM appliance in the management cluster (¶ 42, “The VI management server 802 includes a hardware layer 806 and virtualization layer 808, and runs a virtual-data-center management server virtual machine 810 above the virtualization layer”).
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 the desired state of the manager VIM appliance includes the VM executing the VIM appliance in the management cluster, as taught by Strandzhev, in the same way to the desired state, as taught by Parihar and Sinha. Both inventions are in the field of virtual appliances, and combining them would have predictably resulted in “management of a cloud-computing facility by a VI management server,” as indicated by Strandzhev (¶ 1).
Claim 17 recites commensurate subject matter as claim 4. Therefore, it is rejected for the same reasons.
Claim(s) 6 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Parihar and Sinha, as applied above, and further in view of Thakkar (US 2021/0132981).
Regarding claim 6, Parihar and Sinha do not teach; however, Thakkar discloses: an inventory agent in an agent platform appliance for the VIM appliance collects the metadata (¶ 73, “Hypervisor 1320 includes an agent, shown as operations agent 1342, that cooperates with a management software (operations manager 1341) running in virtualization manager 256c to perform various management operations on VMs 1330” and ¶ 55, “Inventory data 213 includes static inventory data, dynamic utilization data, and inter data center connectivity information, all of which are reported by local control planes 250 of the core, regional, and edge data centers”) and provides the metadata to an inventory service of the cloud platform (¶ 31, “The virtual machine communicates with the EMS to receive initial configuration parameters as well as configuration changes during the lifecycle of the VNF” and ¶ 55, “Updates to the dynamic utilization data and are pushed to central orchestrator 210 by local control planes 250 of the data centers on a periodic basis”).
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 an inventory agent in an agent platform appliance for the VIM appliance collects the metadata and provides the metadata to an inventory service of the cloud platform, as taught by Thakkar, in the same way to the desired state, as taught by Parihar and Sinha. Both inventions are in the field of virtual appliances, and combining them would have predictably resulted in “deploying a virtual network function of a network service in a data center having a cloud management server running a cloud computing management software,” as indicated by Thakkar (abstract).
Claim 19 recites commensurate subject matter as claim 6. Therefore, it is rejected for the same reasons.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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