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 filed 20 January 2026 have been fully considered but they are not persuasive.
Applicant contends that Hasti does not teach “transforming the imperative requests to execute the lifecycle management operations into declarative requests,” as recited in independent claim 1, because “Hasti teaches converting declarative intent into imperative execution steps.” Remarks at pages 10 and 11. Further, “the Office Action has not established a motivation to reverse Hasti’s logic.” Id. Although applicant recognizes that Hasti disloses transforming from declarative to imperative and “vice versa,” Hasti’s disclosure of “vice versa” is merely “boilerplate” and “could [not] possibly teach or suggest the transformation” in claim 1.
The Examiner respectfully disagrees. Hasti’s disclosure of “vice versa” is not merely a “boilerplate” disclosure. Hasti discloses bi-directional transformations – “reformat/convert commands formatted according to the declarative model supported by the container orchestration platform into reformatted commands formatted according to the imperative model supported by the distributed storage architecture, and vice versa” (col. 6:41-45); “functionality that can reformat/convert commands formatted according to the declarative model supported by the container orchestration platform into reformatted commands formatted according to the imperative model supported by the distributed storage architecture, and vice versa” (col. 7:47-51); “reformatting commands between the imperative model and the declarative model in order to facilitate communication and execution of commands between the applications and the worker nodes” (col. 9:31-34); and “[t]he distributed control plane 128 may include a plurality of control plane controllers that are configured to reformat/convert commands formatted according to the declarative model supported by the container orchestration platform 102 into reformatted commands formatted according to the imperative model supported by the distributed storage architecture 112, and vice versa” (col. 9:34-41).
Hasti does not merely use “vice versa” as boilerplate; to the contrary, Hasti specifically discloses bi-directional transformations between imperative and declarative forms. Even if the example embodiments provided by Hasti are directed toward transforming from imperative to declarative form, a person having ordinary skill in the art would have found it obvious to convert from imperative to declarative in view of Hasti’s bi-directional transformations between imperative and declarative forms.
Therefore, the Examiner maintains that a person having ordinary skill in the art would have found “transforming the imperative request . . . into declarative requests,” as recited in independent claim 1, obvious in view of Hasti’s disclosure of bi-directional transformations.
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-5, 10, 12-14, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hasti (US 12,079,519) and further in view of Banerjee (US 2022/0035650).
Regarding claim 1, Hasti teaches: A computer-implemented method for managing lifecycles of network functions in multiple cloud environments, the method comprising:
receiving imperative requests to execute lifecycle management operations for the network functions running in the multiple cloud environments at a declarative service (col. 9:9-17, “the worker nodes of the distributed storage architecture 112 may be capable of executing commands (formatted according to the imperative model, such as commands comprising programming instructions or executable steps. In some embodiments, a snapshot command formatted according to the imperative model may include programming instructions or executable steps that a worker node can execute in order to create a snapshot”);
transforming the imperative requests to execute the lifecycle management operations into declarative requests to execute the lifecycle management operations at the declarative service (col. 9:23-27, “a distributed control plane 128 is provided for reformatting commands between the imperative model and the declarative model in order to facilitate communication and execution of commands between the applications and the worker nodes”); and
managing executions of the lifecycle management operations at the multiple cloud environments from a central network function lifecycle orchestrator based on the declarative requests to execute the lifecycle management operations (col. 24:32-49, “the command 1102 may be formatted according to a declarative model as attributes specified through a custom resource specification of a custom resource definition within the distributed database 304 of the container orchestration platform 102 . . . In response to determining that the second worker node 116 is operational, the distributed control plane 128 may route the command 1102 to the second control plane controller 138 paired with the second worker node 116”).
Hasti does not teach; however, Banerjee discloses: network functions in multiple cloud environments (¶ 4, “This technology can be used to provide Cloud-Native Network Functions (CNFs), which are containerized applications that provide NFV capabilities”).
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 network functions in multiple cloud environments, as taught by Banerjee, in the same way to the method for managing lifecycles, as taught by Hasti. Both inventions are in the field of Kubernetes platforms, and combining them would have predictably resulted in “an ecosystem of technologies, such as, Kubernetes, Docker and Helm charts, that help development, deployment and lifecycle-management of containerized applications,” as indicated by Banerjee (¶ 4).
Regarding claim 3, Hasti teaches: The computer-implemented method of claim 1, wherein the declarative requests include Kubernetes Custom Resources (col. 16:45-48, “A custom resource definition 402 may be used to define custom objects (custom resources) within the container orchestration platform 102 (Kubernetes), such as to define a volume custom object”).
Regarding claim 4, Banerjee teaches: The computer-implemented method of claim 1, wherein managing the executions of the lifecycle management operations at the multiple cloud environments includes managing the executions of the lifecycle management operations at the multiple cloud environments (¶ 26, “The virtual infrastructures 104 and 106 are computing environments that offer compute, storage and network as resources for hosting or deployment of services or applications, which may reside in one or more public clouds”) from the central network function lifecycle orchestrator using a virtual infrastructure plugin for at least some of the multiple cloud environments (¶ 74, “when a lifecycle management operation of the CNF is requested to be executed in the container-based virtual infrastructure 406, the central orchestrator 110 sends a command to the Helm package manager 442 via the local operator 444 with the reference to the needed Helm chart so that the Helm package manager 442 can retrieve the Helm chart from the repository 154 to execute the lifecycle management operation of the CNF”).
Regarding claim 5, Banerjee teaches: The computer-implemented method of claim 1, wherein at least one of the cloud environments is a virtual machine-based virtual infrastructure or a container-based virtual infrastructure (¶ 26, “the distributed computing system 100 includes an orchestration server 102 that is connected to a plurality of virtual machine (VM)-based virtual infrastructures (VIs) 104 and container-based virtual infrastructures (VIs) 106 through a communications network 108”).
Claims 10, 12-14, and 19 recite commensurate subject matter as claims 1 and 3-5. Therefore, they are rejected for the same reasons.
Claim(s) 2, 11, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hasti and Banerjee, as applied above, and further in view of the Melkilk (US 2021/0326162).
Regarding claim 2, Hasti and Banerjee do not teach; however, Melkilk discloses: the imperative requests include application programming interfaces (APIs) (¶ 43, “the NFVO 666 provides an API 670 which is usable by other components for network service and VNF lifecycle management (LCM)”) in accordance with a standard specification of European Telecommunications Standards Institute (ETSI) (¶ 3, “The European Telecommunications Standard Institute (ETSI) network functions virtualization (NFV) industry specification group (ISG) has defined a reference NFV architecture”).
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 imperative requests include application programming interfaces (APIs) in accordance with a standard specification of European Telecommunications Standards Institute (ETSI), as taught by Melkilk, in the same way to the imperative request, as taught by Hasti. Both inventions are in the field of managing containers, and combining them would have predictably resulted in “monitoring of Virtual Network Functions (VNFs) in a system employing a Network Function Virtualization (NFV) architecture,” as indicated by Melkilk (¶ 1).
Claims 11 and 20 recite commensurate subject matter as claim 2. Therefore, they are rejected for the same reasons.
Claim(s) 6, 7, 15, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hasti and Banerjee, as applied above, and further in view Yi (B. Yi, X. Wang, M. Huang, and K. Li, ‘‘Design and implementation of network-aware VNF migration mechanism,’’ IEEE Access, vol. 8, pp. 44346–44358, 2020.).
Regarding claim 6, Hasti and Banerjee do not teach; however, Yi discloses: executing a node overload virtual network function (VNF) migration by the central network function lifecycle orchestrator (Page 44350, Section V., “the network-aware VNF migration mechanism is designed and presented respectively to address the physical node and link overloaded situations”).
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 executing a node overload virtual network function (VNF) migration by the central network function lifecycle orchestrator, as taught by Yi, in the same way to the managing the executions of the lifecycle management operations, as taught by Hasti and Banerjee. Both inventions are in the field of managing VNFs, and combining them would have predictably resulted in a method, wherein the “service performance is improved and the load balance is achieved after the VNF migration,” as indicated by Yi (abstract).
Regarding claim 7, Hasti and Banerjee do not teach; however, Yi discloses: executing a link overload virtual network function (VNF) migration by the central network function lifecycle orchestrator (Page 44350, Section V., “the network-aware VNF migration mechanism is designed and presented respectively to address the physical node and link overloaded situations”).
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 executing a link overload virtual network function (VNF) migration by the central network function lifecycle orchestrator, as taught by Yi, in the same way to the managing the executions of the lifecycle management operations, as taught by Hasti and Banerjee. Both inventions are in the field of managing VNFs, and combining them would have predictably resulted in a method, wherein the “service performance is improved and the load balance is achieved after the VNF migration,” as indicated by Yi (abstract).
Claims 15 and 16 recite commensurate subject matter as claims 6 and 7. Therefore, they are rejected for the same reasons.
Claim(s) 8, 9, 17 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hasti and Banerjee, as applied above, and further in view of the Friedman (US 11,122,129).
Regarding claim 8, Hasti and Banerjee do not teach; however, Friedman discloses: migrating cloud-native network functions (CNFs) from a first cloud environment to a second cloud environment by the central network function lifecycle orchestrator (col. 2:28-30, “A network function migration may occur when there is a need to migrate a function from one physical hardware device to another”).
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 migrating cloud-native network functions (CNFs) from a first cloud environment to a second cloud environment by the central network function lifecycle orchestrator, as taught by Friedman, in the same way to the imperative request, as taught by Hasti and Banerjee. Both inventions are in the field of managing VNFs, and combining them would have predictably resulted in “virtual network function migration,” as indicated by Friedman (col. 1:8-9).
Regarding claim 9, Friedman discloses: The computer-implemented method of claim 8, wherein migrating the CNFs from the first cloud environment to the second cloud environment includes deploying new CNFs in the second cloud environment, gradually diverting traffic to the CNFs in the second cloud environment until there is no traffic to the CNFs in the first cloud environment, and removing the CNFs in the first cloud environment (col. 16:38-42, “an intelligent load balancer gradually redirects traffic from the old VNF instance to the new VNF instance until the new VNF instance has completely taken over the network function”).
Claims 17 and 18 recite commensurate subject matter as claims 8 and 9. Therefore, they are 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