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 .
DETAILED ACTION
Response to Amendment
This office action is in response to applicant’s amendment filed, 23 July 2026, of application filed, with the above serial number, on 20 December 2023 in which claims 1, 2, 7-8, 11, 14-15, 17, 20 have been amended, claims 12, 18 cancelled, and claims 21-22 have been added. Claims 1-11, 13-17, 19-22 are pending in the application.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-2, 4, 8-9, 11, 15-17, 21-22 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by DHARAMPURIKAR et al (hereinafter “DHARAMPURIKAR”, 2024/0256298).
As per Claim 1, DHARAMPURIKAR discloses a method for deploying network functions (NF) into target cloud computing environments in a cellular telecommunication network, the method comprising:
electronically displaying a NF configuration graphical user interface (GUI) for receiving NF configuration data for a NF deployment (at least paragraph 26; graphical user interface is configured to facilitate the uploading of a data file comprising one or more parameters for configuring a network function provided by one or more of the network devices 105 to configuration manager 101);
electronically receiving, via the NF configuration GUI, the NF configuration data (at least paragraph 26; graphical user interface is configured to facilitate the uploading of a data file comprising one or more parameters for configuring a network function provided by one or more of the network devices 105 to configuration manager 101);
electronically displaying an IP address configuration GUI for receiving IP address data for the NF deployment (at least paragraph 43; Graphical user interface 300 includes a plurality of parameter fields for identifying parameters associated with configuring a network function according to the configuration file being added or edited. The parameter fields include options for selecting or entering a UHN Name/UUID (Universal Unique Identifier), Domain, Vendor (or Network Service Provider) information, Technology, Software Version, IP address);
electronically receiving, via the IP address configuration GUI, an IP address assignments for the NF deployment (at least paragraph 43; Graphical user interface 300 includes a plurality of parameter fields for identifying parameters associated with configuring a network function according to the configuration file being added or edited. The parameter fields include options for selecting or entering a UHN Name/UUID (Universal Unique Identifier), Domain, Vendor (or Network Service Provider) information, Technology, Software Version, IP address….a sending or pushing instruction, a download instruction, a send-to address);
electronically receiving a trigger to build a NF package for deployment to a target environment (at least paragraph 32, 39; configuration manager 101 makes it possible for network service providers to download or create a basis .xls-based template that is then filled out with information for various parameters and uploaded to configuration manager 101 to generate a configuration file in JSON format which can be pushed; Graphical user interface 200 also facilitates creating a new configuration file 205 by selecting a “+” sign, for example, or some other suitable graphical user interface icon. In some embodiments, in response to selecting a configuration file 205 to be edited or in response to a selection to create a new configuration file 205, configuration manager 101 (FIG. 1) causes graphical user interface 300 (FIG. 3) to be displayed for editing and/or creating a configuration file 205);
electronically populating a template with the NF configuration data and the IP address data (at least paragraph 27; configuration manager 101 causes one or more of the plurality of parameter fields included in a graphical user interface to be populated with one or more parameters extracted from the data file according to a mapping between the one or more parameters extracted from the raw data file and one or more corresponding parameter fields of the plurality of parameter fields included in the graphical user interface. In some embodiments, the raw data file is based on a template comprising one or more input fields configured to receive the one or more parameters for configuring the network function and information to facilitate the mapping between the one or more parameters extracted from the data file and the one or more corresponding parameter fields of the plurality of parameter fields included in the graphical user interface; par. 32 configuration manager 101 makes it possible for network service providers to download or create a basis .xls-based template that is then filled out with information for various parameters and uploaded to configuration manager 101 to generate a configuration file in JSON format which can be pushed);
electronically building the NF package using the template with the NF configuration data and the IP address data (at least paragraph 27; configuration manager 101 causes one or more of the plurality of parameter fields included in a graphical user interface to be populated with one or more parameters extracted from the data file according to a mapping between the one or more parameters extracted from the raw data file and one or more corresponding parameter fields of the plurality of parameter fields included in the graphical user interface. In some embodiments, the raw data file is based on a template comprising one or more input fields configured to receive the one or more parameters for configuring the network function and information to facilitate the mapping between the one or more parameters extracted from the data file and the one or more corresponding parameter fields of the plurality of parameter fields included in the graphical user interface); and
electronically deploying the NF package to the target environment (at least paragraph 34; by way of the template/data file, ease of uploading and using the data file to the configuration manager, manipulation capabilities and autonomous generation of the JSON configuration files outside the network orchestrator 109 adds to the network service provider/user ability to control deployment of configuration files in the JSON format to appropriate network devices 105).
As per Claim 2. The method of claim 1, wherein the NF configuration data and the IP address data are provided independent of the target environment and populating the template with the NF configuration data (at least paragraph 32; configuration file in JSON format which can be pushed, directly or indirectly, outside of the network orchestrator 109, from the configuration manager 101 based on a selected configuration file, uniform host name, etc. on a respective internet protocol address and port for the network device 105 so there is minimal to zero manual effort required for creating and validating and sending the JSON configuration file. In some embodiments, one or more of the parameters provided in the data file by a network service provider/user are dynamic parameters that are capable of being added and/or modified by the network service provider/user when adding information to the template for producing the data file) and the IP address data includes:
electronically parsing the NF configuration data based on the target environment to identify relevant NF configuration data for the target environment (at least paragraph 26, 33; The data file is processed to recognize, parse and extract the one or more parameters included in the data file; configuration manager 101 is configured to generate JSON Day1/Day2 configuration files based on given xpath and values (default values), and/or support list type parameters for which a network service provider/user provides a unique identifier or parsing logic (e.g., for list parameters, a key and a value are two parameters coming under specific particular programmable logic device records));
electronically populating relevant portions of the template with the relevant NF configuration data for the target environment (at least paragraph 33; the template format of the data file provides an opportunity for the network service provider/user to provide parsing logic and/or tags capable of being identified by the configuration manager 101 to facilitate the recognition of the parameters in the data file for parsing and extraction to populate the parameter fields in the graphical user interface); and
electronically masking remaining portions of the template (at least paragraph 45; configuration manager 101 then causes the parameter fields to be populated with the parameters included in the data file. If, for example, one or more of the parameter fields is empty after populating the parameter fields according to the parameters included in the data file, the configuration manager 101 causes the empty parameter fields to be filled based on one or more of a default value and/or one or more database parameters).
As per Claim 4. The method of claim 1, further comprising: electronically storing the NF configuration data in a NF configuration data store as a key-value pair (at least paragraph 33, 23, 28; e.g., for list parameters, a key and a value are two parameters coming under specific particular programmable logic device records; data storage and parameters stored in database).
As per Claim 11 / 17. The method of claim 8 / non-transitory computer-readable storage medium of claim 15 wherein the actions further include at least one of: electronically storing the NF configuration data in a NF configuration data store as a key-value pair (at least paragraph 33, 23, 28; e.g., for list parameters, a key and a value are two parameters coming under specific particular programmable logic device records; data storage and parameters stored in database); or
electronically storing the IP address data in an IP Address Management (IPAM) instance.
As per Claim 21. The method of claim 1, wherein the template is usable to electronically build a plurality of NF packages, each of the plurality of NF packages being deployable in a different environment of a plurality of environments, the plurality of environments including the target environment (at least paragraph 14, 20-22; one or more network devices 105a-105n (collectively referred to as network devices 105; configuration manager 101 is remote from the network devices 105; deploy over various target areas; communication networks often involve network services across multiple domains such as radio area network (RAN), base station subsystem (BSS), platform, core network, etc., various technologies (such as 3G, 4G, LTE, 5G, etc.), multiple locations, various software interfaces, multiple devices, etc. that are proprietary and/or optimized by a specific network service provider).
As per Claim 22. The method of claim 21, wherein each of the plurality of environments differs in at least one of required file formats or network component parameters (at least paragraph 14, 20-22; one or more network devices 105a-105n (collectively referred to as network devices 105; configuration manager 101 is remote from the network devices 105; deploy over various target areas; communication networks often involve network services across multiple domains such as radio area network (RAN), base station subsystem (BSS), platform, core network, etc., various technologies (such as 3G, 4G, LTE, 5G, etc.), multiple locations, various software interfaces, multiple devices, etc. that are proprietary and/or optimized by a specific network service provider; paragraph 26; other suitable format).
Claims 8-9, 15-16 do not, in substance, add or define any additional limitations over claims 1-2, 4 and therefore are rejected for similar reasons, supra.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 3, 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over DHARAMPURIKAR in view of Balachandran (hereinafter “Balachandran”, 2023/0239374).
DHARAMPURIKAR fails to disclose wherein the template includes Kubernetes Helm charts YAML files. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Balachandran (at least paragraph 11-13; manages cloud-native network functions (CNFs) packages comprising helm charts stored as YAML files in Kubernetes clusters). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Balachandran’s deployment with DHARAMPURIKAR as Balachandran teaches when the network functions are deployed as containers, developers package all the files in the container and using the Kubernetes Helm charts YAML files are well known for containerized cluster deployment configuration as shown by Balachandran to store the package.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over DHARAMPURIKA in view of Chopra (hereinafter “Chopra”, 2024/0267356).
DHARAMPURIKA fails to disclose electronically storing the IP address data in an IP Address Management (IPAM) instance. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Chopra. Chopra discloses, in an analogous art, storing IP address data for deployed network functions in an IPAM (at least paragraph 45, 8, 109-111). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Chopra’s IPAM with DHARAMPURIKA as Chopra teaches such IP address storage improves reliability and performance of the deployed network functions, having a central inventory would further ease the NF configuration of DHARAMPURIKA and as DHARAMPURIKA teaches storing parameters and the parameters include IP addresses (par. 43) in a single configuration file, having all the IP addresses together in a central inventory is an obvious advantage for easing addressing issues for configuration and deployment and for the GUI user to easily see all the addresses for configuration in DHARAMPURIKA.
Claim(s) 6-7, 13-14, 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over DHARAMPURIKA in view of Basur Shankarappa et al (hereinafter “Basur”, 2023/0100276).
As per Claim 6, 13, 19, DHARAMPURIKA fails to disclose wherein deploying the NF package to the target environment includes: creating a target cluster in the target environment; deploying the NF package to the target cluster; and validating the NF package in the target cluster. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Basur (at least paragraph 54, 32-33, 36-37, 43; Kubernetes cluster template having configuration for network function deployed, selecting cluster meeting requirements, and validating configuration). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Basur’s deployment with DHARAMPURIKA as Basur teaches network functions from different vendors have their own unique set of infrastructure requirements and Basur’s selection of a cluster for a deployed network function that meets those requirements ensures compatibility and operation of the network function to meeting the requirements as required by the user or client.
As per Claim 7, 14, 20. DHARAMPURIKA fails to disclose monitoring the NF package in the target environment for a deviation from the template; and responsive to detecting the deviation, reconciling the NF package with template. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Basur (at least paragraph 44-46, 63-64; managing the life cycle of a network function and ensuring compliance; the instantiation parameters and operational behaviors of the VNFs being described and monitored; VM Controller 616 also monitors VM configuration events and configures Kubernetes worker nodes (e.g., Kubernetes node 680) on the target workload cluster 650. The VM controller 616 also monitors cluster API events with a virtualization or cloud platform (e.g., VMware CAPI/CAPV)). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Basur’s deployment with DHARAMPURIKA as Basur teaches monitoring and managing network function configurations after they are deployed to the cluster to ensure the requirements continue to be met.
Response to Arguments
Applicant's arguments filed 23 July 2026 have been fully considered but they are not persuasive.
Applicant argues DHARAMPURIKA fails to disclose the final 3 limitations of claim 1 including:
electronically populating a template with the NF configuration data and the IP address data
Applicant argues DHARAMPURIKA’s template is a spreadsheet that the user manually fills out and uploads, citing par. 32. However, even if DHARAMPURIKA had a user manually filling the spreadsheet out, which Examiner disagrees with such interpretation, such would not have any impact on DHARAMPURIKA teaches the elements as claimed. DHARAMPURIKA’s template being a ‘spreadsheet’ is one embodiment as par. 32 defines and it still a template, the file extension and type of the template is not claimed or defined to be different or even defined in the specification and thus is irrelevant. Par. 26 offers other formats from .xls as well.
Next, DHARAMPURIKA does not recite in the cited sentence from par. 34 that the user is ‘manually’ populating the template, in fact DHARAMPURIKA teaches, in the very same paragraph, “so there is minimal to zero manual effort required for creating and validating and sending the JSON configuration file”.
And par. 24 “For example, without relying on manual processes for generating a JSON configuration file and/or the network orchestrator 109 to initiate pushing the JSON configuration file to the network devices, a network function can be changed, updated, removed and/or added in a manner that reduces response time, decreases costs, and increases user confidence in the dependability of the communication network.”
And lastly par. 18 “For example, with the manual generation of the JSON configuration file, a user needs to keep a track of the parameter repetition along with correct identifier details, which is a tedious task, along with other human-related errors such as typographical error, mistaken inputs, interpretational issues, etc., which makes validating a manually generated JSON configuration file more cumbersome. Delays caused by error prone manual processes for generating JSON configuration files and wait times caused by dependencies on a network orchestrator, because a network service provider cannot push a configuration to a network device on demand, can result in communication network dependability issues, reduced quality of service, and increased costs.”
And as indicated in the interview and interview summary the claim itself recites “electronically receiving” via a user interface the configuration data that is displayed. Thus if the suggestion is that the term ‘electronically’ defines the action to be without manual interaction, such is not inherent or obvious from the term as the term is claimed to have a user using a user interface receive manual input data.
Notwithstanding, DHARAMPURIKA teaches in par. 27 that the template is filled out from one or more received parameters extracted from a data file and not manual user input. Thus all being apparent that DHARAMPURIKA does not teach such ‘manual’ populating of a template.
electronically building the NF package using the template with the NF configuration data and the IP address data
Applicant argues the generated JSON configuration file is not equivalent to build of a NF package. Applicant has not expanded on why or what the difference is from a built configuration file and a built NF package that configures a device. In par. 45-46 of the application the NF package comprises NF configuration data. It is not clear what the package is, is it a file, is it a JSON file? It is not defined, and thus the argument from Applicant that it is not a JSON file it is different is not persuasive. NF configuration data is NF configuration data packaged however the prior art sees fit including a JSON file. The argument that it is not built as it merely adjusts is not persuasive either as Applicant quotes that the JSON file is ‘generated’ or built. Lastly, par. 38 describes “configuration file 205 is a JSON configuration file. Configuration files 205 included in the configuration file list 201 are optionally other types of configuration files such as an XML configuration file, or some other suitable file type.” And thus the file is a package of files.
electronically deploying the NF package to the target environment
Applicant argues that DHARAMPURIKA pushing a HSON configuration file to an existing network device that is running a deployed NF package is distinct from the claim. Applicant thus admits that DHARAMPURIKA teaches the devices running a NF package and thus the JSON configuration file pushed to configure the device is a NF package. Applicant argues DHARAMPURIKA ‘pushes’ the configuration when DHARAMPURIKA clearly uses the term “deployment’ in par. 34. DHARAMPURIKA clearly teaches deployment of the configuration file to appropriate network devices 105. The claim notably does not even recite where the package is being deployed, the “target environment” could be old network devices that need updating, it is undefined. Applicant argument again amounting to existing devices aren’t a target environment without expanding on what the target environment might be if that is not the target. The argument suggests existing network devices cannot have built NF packages deployed to them. Whether the devices are existing or non-existing, the package is simply being deployed to any arbitrary “target environment”, a new device, an existing device, an entire network, etc.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
The prior art made of record and not relied upon considered pertinent to applicant's disclosure is indicated in PTO form 892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY TODD whose telephone number is (303)297-4763. The examiner can normally be reached 8:30-5 MST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Nicholas Taylor can be reached on 571-272-3889. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/GREGORY TODD/Primary Examiner, Art Unit 2443
