DETAILED ACTION
This office action is responsive to communications filed on January 7, 2026. Claims 1, 6, 8, 13, 15, and 20 have been amended. Claims 1-20 are pending in the application.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on January 7, 2026 has been entered.
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.
Claims 1-3, 7-10, and 14-17 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Kozlova et al. (US 2023/0276211).
Regarding Claim 1, Kozlova teaches a method for onboarding a network slice associated with a wireless network, the method comprising:
providing an onboarding graphical user interface (GUI) (“Provisioning portal 104 provides an interface for use by client device 101 to provision communication services. In some aspects, provisional portal 104 can present a user interface 106 that presents user interface elements (e.g., screens, menus, maps, etc.) as part of a workflow for provisioning a communication service” – See [0033]; The provisioning portal is a GUI for onboarding/provisioning network services);
receiving, from the onboarding GUI, a network slicing topology that specifies one or more network nodes of the wireless network (“the design studio provided by UI 106 may provide a set of basic pre-designed and configured templates to assist users with template design. In some examples, the pre-designed templates may include a Basic eMBB CN (Core Network) NSST, a Basic eMBB RAN (Radio Access Network) NSST, or a Basic 5G NST, etc. The use of such pre-designed templates may allow users to start from a basic topology and configuration rather than starting from scratch. In some examples, UI 106 enables a user to customize a pre-designed template by adding, removing, or updating network functions, network links, or other configuration, etc., to achieve a desired topology or design” – See [0114]; “UI 106 translates a template defined by a user into Topology and Orchestration Specification for Cloud Applications (TOSCA) format. UI 106 sends the template to a validator service” – See [0116]; A validator receives, from the GUI, a user-customized NST/NSST (network slicing topology) that specifies various network functions/nodes in the network);
configuring, through the onboarding GUI based on information retrieved from one or more registration databases, the network slicing topology (“the design studio provided by UI 106 may provide a set of basic pre-designed and configured templates to assist users with template design. In some examples, the pre-designed templates may include a Basic eMBB CN (Core Network) NSST, a Basic eMBB RAN (Radio Access Network) NSST, or a Basic 5G NST, etc. The use of such pre-designed templates may allow users to start from a basic topology and configuration rather than starting from scratch. In some examples, UI 106 enables a user to customize a pre-designed template by adding, removing, or updating network functions, network links, or other configuration, etc., to achieve a desired topology or design” – See [0114]; Using the GUI, network slice templates from a database are customized to configure the network slicing topology);
defining, through the onboarding GUI, one or more network slice workflows based on the configuring, the one or more network slice service workflows each being a defined flow of configured subnet-level services for deploying the network slice, defined for each of plural subnets (“In some aspects, service template selection screen includes template icons 304A-304H (collectively “template icons 304”) that each represent a different service template defined in service templates 110. In some aspects, a template icon can include the name of the template, a description of the template, a network slice template specified by the service template, a priority for network traffic for the provisioned service, and a type of service” – See [0046]; “a mobile network operator may create network slice subnet templates 113. A network slice subnet template 113 can be a blueprint that defines various network slice subnet attributes used to configure a network slice subnet. For example, one or more network slice subnet templates 113 may be used to define networks and services used by a slice subnet and interfaces to such networks and services” – See [0038]; “a user may design, via UI 106, an O-RAN full slice subnet (2-level subnet) by importing the slice subnets as defined by the slice subnet templates of FIGS. 10D and 10E above” – See [0100]; Using the GUI, the operator defines/configures one or more slice subnet templates (network slice workflows), wherein each of the slice subnet templates are a defined flow of subnet services for deploying the slice, defined for each of plural subnets (e.g., O-RAN cell subnet, O-RAN edge subnet, and so on));
generating, through the onboarding GUI, a network slice bundle based on the one or more network slice workflows (“In some examples, the user may, via UI 106, design logical NSTs (end-to-end slices) by combining one or more NSSTs” – See [0126]; The workflows are combined to generate a NST (network slice bundle)); and
registering, through the onboarding GUI, the network slice bundle with the one or more registration databases for deployment of the network slice on the wireless network (“The designed NSTs are stored in an SMO NST Catalog of database 108 and made available for inclusion into Communication Service Templates” – See [0126]; “Deployment unit 122 of provisioning system 102 deploys the network slice in accordance with the NST 111 (1216)” – See [0131]; The NST (network slice bundle) is registered in a database and deployed on the network),
wherein the network slice is deployed via execution of the configured subnet-level services in accordance with the flow of the configured subnet-level services as defined based on the configuring of the network topology (“the user may define additional NF-specific placement attributes or labels. As an example, a user may specify that, for a first NSST, a first NF is to be placed at an Edge in an EMEA region. To define this criteria of the first NSST, the user may add, via UI 106, a first label “Cloud-Domain: Edge” and a second label “Location: EMEA” to the network function in the first NSST” – See [0107]; “Then, at instantiation time, the SMO may determine a best or optimal placement of individual NFs depending on NF-specific user-defined labels, cloud topology, available resources, hardware requirements, SLA requirements, etc. The designed NSSTs are stored in an SMO NSST Catalog of database 108 and made available for inclusion into other NSST or NST designs” – See [0125]; The configured subnet level services are instantiated/executed in accordance with the configured subnet-level services as defined based on the configuring of the network topology. Accordingly, the placement of network functions for deploying the service is based on the configuration specified in the subnet-level service attributes/labels).
Regarding Claim 2, Kozlova teaches the method of Claim 1. Kozlova further teaches that the one or more registration databases includes a network service registry (“database 108 may also include service templates 110” – See [0044]), and wherein the configuring the network slicing technology further comprises:
retrieving, from the network service registry, one or more network services for the network slicing topology (“Other components of control interface element 310 can cause provisioning portal 104 to apply filters to service templates 304 and/or search for specific service templates 304” – See [0047]; A service template for one or more network services is searched/retrieved from the database/registry); and
receiving, from the onboarding GUI for the one or more network nodes in the network slicing topology, a selection of one or more network services from the retrieved one or more network services (“A provisioning portal may receive, from a client device, a selection of a service template specifying network service attributes for a communication service” – See [0064]; A selection of the service template is received from the GUI).
Regarding Claim 3, Kozlova teaches the method of Claim 2. Kozlova further teaches that the one or more registration databases includes a configuration parameters registry (“various attributes from the default values provided by the selected service template” – See [0049]; The database stores default attributes (parameters) associated with the service templates), and wherein the configuring the network slicing technology further comprises:
retrieving, from the configuration parameters registry, one or more configuration parameters for the selected one or more network services (“For example, general slice information portion 326 may include user interface elements allowing a user to modify SLA related attributes from the defaults provided by the network slice template associated with the service template” – See [0051]; The attributes/parameters are retrieved from the database in association with selecting a service template for the selected one or more network services); and
receiving, from the onboarding GUI, a selection of one or more configuration parameters from the retrieved one or more configuration parameters (“General slice information portion 336 includes fields allowing a user to modify SLA related attributes for the network slice to be provisioned for the communication service” – See [0051]; The GUI receives selections of attributes/parameters from the user by allowing the user to modify the default attributes).
Regarding Claim 7, Kozlova teaches the method of Claim 1. Kozlova further teaches that the network slicing topology includes one or more of a radio access network (RAN) domain, transport domain, and a core network domain (“UI 106 provides a design studio that enables users to design slice templates or slice subnet templates of multiple domains, such as RAN, Core, Transport Network” – See [0092]).
Claims 8 and 15 are rejected based on reasoning similar to Claim 1.
Claims 9 and 16 are rejected based on reasoning similar to Claim 2.
Claims 10 and 17 are rejected based on reasoning similar to Claim 3.
Claim 14 is rejected based on reasoning similar to Claim 7.
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.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kozlova et al. (US 2023/0276211) in view of Deviprasad et al. (US 2020/0154280).
Regarding Claim 4, Kozlova teaches the method of Claim 3. Kozlova does not explicitly teach that the defining the one or more network slice workflows further comprises specifying a timing of utilizing the selected one or more configuration parameters for a corresponding selected network service.
However, Deviprasad teaches specifying a timing of utilizing the selected one or more configuration parameters for a corresponding selected network service (“The service request may include other parameters pertaining to the service requested, such as for example, a date, a time period, a location, a price, and/or other criteria that may specify the service requested” – See [0018]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kozlova such that the defining the one or more network slice workflows further comprises specifying a timing of utilizing the selected one or more configuration parameters for a corresponding selected network service. Motivation for doing so would be to enable a user to specify parameters pertaining to a date or time period for deploying the slice/service (See Deviprasad, [0018]).
Claims 11 and 18 are rejected based on reasoning similar to Claim 4.
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kozlova et al. (US 2023/0276211) in view of Priya (US 2022/0294691).
Regarding Claim 5, Kozlova teaches the method of Claim 1. Kozlova does not explicitly teach that the one or more databases include a workflow registry, and wherein the defining the one or more network slice workflows further comprises: retrieving, from the workflow registry, one or more predefined workflows; and assigning at least one of the one or more predefined workflows to the one or more network slice workflows.
However, Priya teaches that the one or more databases include a workflow registry, and wherein the defining the one or more network slice workflows further comprises: retrieving, from the workflow registry, one or more predefined workflows; and assigning at least one of the one or more predefined workflows to the one or more network slice workflows (“Location or site-specific information for a NF deployment may be applied to workflows in a slice design to generate “artifacts.”” – See [0026]; “slice designer tool 200 generally stores workflows for Configuration Information Questionnaire (CIQ) automation and receives vendor NF packages. A CIQ typically lists possible NF or service attributes, which a vendor can select for setting on a per-site basis or a per-feature basis. Via the CIQ, slice designer tool 200 obtains site information for an instance of the vendor NF and generates site-specific artifacts for the NF package based on the workflows and the site information” – See [0027]; “Workflows 220 may be designed, uploaded, and stored in artifact generator 215 to enable CIQ automation in configuration design platform 210. Workflows 220 may supply configuration parameters for NFs with deployment-agnostic slice design. Workflows 220 may include, for example, workflows for IP assignment, data center (DC) networking, element management system (EMS)/network management system (NMS) payload configurations, Kubernetes configuration maps, etc.” – See [0031]; Predefined workflows are stored in a registry. The workflows are assigned to a configuration information questionnaire, which is a network slice configuration workflow).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kozlova such that the one or more databases include a workflow registry, and wherein the defining the one or more network slice workflows further comprises: retrieving, from the workflow registry, one or more predefined workflows; and assigning at least one of the one or more predefined workflows to the one or more network slice workflows. Motivation for doing so would be to supply configuration parameters for NFs with deployment-agnostic slice design (See Priya, [0031]).
Claims 12 and 19 are rejected based on reasoning similar to Claim 5.
Claims 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kozlova et al. (US 2023/0276211) in view of Lu et al. (WO 2019/056956, see attached translation).
Regarding Claim 6, Kozlova teaches the method of Claim 1. Kozlova further teaches that the network slice bundle is registered with the one or more databases (“The designed NSTs are stored in an SMO NST Catalog of database 108 and made available for inclusion into Communication Service Templates” – See [0126]; The NST (network slice bundle) is registered in a database).
Kozlova does not explicitly teach that the defined flow comprises an execution time for executing each of the configured subnet-level services to deploy the network slice.
However, Lu teaches that the defined flow comprises an execution time for executing each of the configured subnet-level services to deploy the network slice (“The NSMF orchestrate the requirements of the NSSIs and/or NFs constituting the NSI according to the information of the NSI management command message, the network resource usage, the existing NSSI/NF, the NST, and the NSST. And generate corresponding NSSI and / or NF management instructions” – See p. 10; “The NSMF records the complete NSI management instruction execution time, that is, the sum of the time spent in the above design, orchestration phase, NSSI/NF deployment phase, (optional) service configuration, and test phase” – See p. 11; The flow comprises an execution time for executing/deploying the network subnet slice instances (subnet-level services) to deploy the network slice instance).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kozlova such that the defined flow comprises an execution time for executing each of the configured subnet-level services to deploy the network slice. Motivation for doing so would be to provide the operator and equipment provider with the execution time of the management instructions at each stage, so that the operator and equipment provider can perform targeted optimization (See Lu, p. 4).
Claims 13 and 20 are rejected based on reasoning similar to Claim 6.
Response to Arguments
Applicant’s arguments filed on January 7, 2026 have been fully considered but they are not persuasive.
On pages 12-13 of the remarks, Applicant argues “As noted in the prior response, however, Kozlova’s GUI screens do not define a network slice workflow as claimed. Notably, the claims recite that the workflow is a defined flow of configured subnet-level services. Conversely, the cited workflow in Kozlova is itself a flow for configuring network slice subnets and service level KPIs to provide in accordance with a service level agreement (SLA), and NOT a flow of configured subnet-level services. Nevertheless, the amended claims specify clearly that the flow is for deploying the network slice, namely, by executing the configured subnet-level services in accordance with the flow of these services as defined based on configuring the network topology. That is, the claimed flow is of an execution of subnet-level services as defined based on configuring of the network topology. Conversely, the workflow in Kozlova is for configuring the network slice, and is not an execution of configured services pursuant to a flow as defined based on configuring the network topology.”
The Examiner respectfully disagrees. Claim 1 specifies “the one or more network slice workflows each being a defined flow of configured subnet-level services for deploying the network slice.” Kozlova’s network slice subnet templates are considered to be equivalent to the claimed “network slice workflows”. Kozlova discloses that each of the network slice subnet templates defines services used by a slice subnet (“a mobile network operator may create network slice subnet templates 113. A network slice subnet template 113 can be a blueprint that defines various network slice subnet attributes used to configure a network slice subnet. For example, one or more network slice subnet templates 113 may be used to define networks and services used by a slice subnet and interfaces to such networks and services” – See [0038]). Thus, Kozlova’s network slice subnet templates are a defined flow of subnet-level services for the network slice.
Kozlova further teaches that the network slice workflows are defined through the onboarding GUI (“FIG. 9A is a conceptual view of a user interface screen for adding a slice subnet template for use in provisioning a network service, according to techniques of the disclosure” – See [0087]; “FIG. 9B is a conceptual view of a user interface screen for adding a network function to a slice subnet template for use in provisioning a network service” – See [0088]). Thus, the network slice subnet templates (network slice workflows) are defined through the user interface (GUI) by adding network slice subnet templates, adding functions to the network slice subnet templates, and so on.
After defining the network slice workflows through the onboarding GUI, Kozlova teaches that the network slice is deployed via execution of the configured subnet-level services in accordance with the flow (“the user may define additional NF-specific placement attributes or labels. As an example, a user may specify that, for a first NSST, a first NF is to be placed at an Edge in an EMEA region. To define this criteria of the first NSST, the user may add, via UI 106, a first label “Cloud-Domain: Edge” and a second label “Location: EMEA” to the network function in the first NSST” – See [0107]; “Then, at instantiation time, the SMO may determine a best or optimal placement of individual NFs depending on NF-specific user-defined labels, cloud topology, available resources, hardware requirements, SLA requirements, etc. The designed NSSTs are stored in an SMO NSST Catalog of database 108 and made available for inclusion into other NSST or NST designs” – See [0125]). The configured subnet-level services are instantiated/executed in accordance with the defined flow.
On page 13, Applicant argues “no such workflows that include respective execution times for configured subnet-level services is generated in Kozlova, let alone based on configuring of a network topology,” with respect to claims 6, 13, and 20. Applicant’s arguments have been considered but are moot based on the new grounds of rejection. In response to the amended limitations, the Examiner relies upon the newly-cited Lu reference.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Scott M Sciacca whose telephone number is (571)270-1919. The examiner can normally be reached Monday thru Friday, 7:30 A.M. - 5:00 P.M. EST.
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, Joseph Avellino can be reached at (571) 272-3905. 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.
/SCOTT M SCIACCA/ Primary Examiner, Art Unit 2478