DETAILED ACTION
This office action is responsive to communications filed on May 21, 2026. Claims 1, 8, and 15 have been amended. Claims 6, 13, and 20 have been canceled. Claims 1-5, 7-12, and 14-19 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 .
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 1-3, 7-10, and 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over Kozlova et al. (US 2023/0276211) in view of Lu et al. (US 2020/0059407).
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 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).
wherein the 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 defining when to execute each of the configured subnet-level services to deploy the network slice.
However, Lu teaches that the defined flow comprises an execution time defining when to execute each of the configured subnet-level services to deploy the network slice (“In an example, the requirement description information of the network slice subnet instance includes at least one of the following: … a serving time requirement for the network slice subnet instance” – See [0158]; “In a specific example, the serving time requirement of a service of the network slice subnet instance may be a start time at which the network slice subnet instance is in an active state and can provide a service” – See [0162]; The defined flow includes a start time when the subnet level services is in an active state (i.e., when to execute each of the configured subnet-level services to deploy the network slice)).
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 defining when to execute each of the configured subnet-level services to deploy the network slice. Motivation for doing so would be to ensure that the configuration can meet the service requirement for the network slice subnet instance (See Lu, [0170]).
Regarding Claim 2, Kozlova in view of Lu 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 in view of Lu 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 in view of Lu 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.
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 Lu et al. (US 2020/0059407) and further in view of Deviprasad et al. (US 2020/0154280).
Regarding Claim 4, Kozlova in view of Lu 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 Lu et al. (US 2020/0059407) and further in view of Priya (US 2022/0294691).
Regarding Claim 5, Kozlova in view of Lu 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.
Response to Arguments
On pages 12-14 of the remarks, Applicant argues in substance that Kozlova does not teach “defining, through the onboarding GUI, one or more network slice workflows based on the configuring,” as recited in independent claim 1. Applicant’s arguments been fully considered but they are not persuasive.
Specifically, Applicant argues that Kozlova’s network slice subnet template (NSST) is not a network slice workflow. Applicant argues that Kozlova’s templates are not defined flows of configured sub-net level services with execution sequences. Applicant further argues that the claimed network slice workflows define a temporal flow of service execution. In response to Applicant’s argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “the network slice workflows are defined flows of configured sub-net level services with execution sequences” and “the network slice workflows define a temporal flow of service execution”) are not recited in the rejected claims. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
With regard to the claimed “network slice workflow”, claim 1 only defines the network slice workflow as “a defined flow of configured subnet-level services for deploying the network slice.” According to the broadest reasonable interpretation, a “flow” of subnet-level services includes a definition of the services/functions that are used for deploying the slice. Kozlova discloses such a flow at [0038] (“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”). Furthermore, Fig. 9A shows a further example wherein specific network functions for providing the service, as well as their interconnections, are included in a NSST. These defined services, network functions, interfaces, and interconnections represent “a defined flow of configured subnet-level services for deploying the network slice”.
On pages 13-15 of the remarks, Applicant argues in substance that Lu et al. (WO 2019/056956) does not teach “the defined flow comprises an execution time defining when to execute each of the configured subnet-level services to deploy the network slice,” as recited in claim 1. 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 et al. (US 2020/0059407).
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.
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
Prosecution Insights