DETAILED ACTION
This action is made in response to the communication filed on March 16, 2025. This action is made non-final. Claim 72 is an independent claim. Claims 1-72 were canceled. Claims 72-87 are pending.
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 .
Priority
This application is a national stage entry under 35 U.S.C. 371 of International Patent Application PCT/CN2022/119396, filed September 16, 2022.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on July 08, 2025 is in compliance with the provisions of 37 CFR 1.97 and has been considered by the examiner.
Claim Objections
Claims 73, 75-78, 81 and 84-86 are objected to because of the following informalities:
Each of the claims 73, 75-78, 81 and 84-86 recites “wherein when the instructions executed by the one or more processors, further cause the apparatus at least to”. The clause lacks a subject for “further cause”. The limitation should apparently read: “wherein the instructions, when executed by the one or more processors, further cause the apparatus at least to”, consistent with the corresponding language of claim 72.
Claim 84 recites “when the first set of network function instances are activated”. The subject of the clause, “the first set” is singular. The limitation should apparently read: “is activated”.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
6. 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.
7. 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.
8. 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.
9. Claims 72-75 and 78 are rejected under 35 U.S.C. § 103 as being unpatentable over Ni et al. (US2017/0346682A1), hereafter Ni, in view of Opschroef et al. (US2017/0250827 A1), hereafter Opschroef, and further in view of Feng et al. (US2017/0012968 A1), hereafter Feng.
Regarding claim 72, Ni teaches an apparatus, comprising: one or more processors; and one or more memories storing instructions that, when executed by the one or more processors cause the apparatus at least to: perform the operation below. Ni teaches “a computer-readable medium storing instructions that, when executed by one or more processors of a network entity, cause the network entity” to perform the upgrade ([0054]). The apparatus comprises “memory or storage medium” coupled to its hardware, e.g., ROM, or a flash memory ([0112]-[0113]). The network entity is, e.g., an MME, P-GW, or S-GW ([0066]).
cause a creating of a first set of network function instances which is redundant for a second set of network function instances. Ni’s software migration is “achieved by adding to the existing one or more instances implementing the mobile network function according to the current, i.e. old, software, another one or more instances implementing the mobile network function according to the new, i.e. upgraded, software” ([0065]). Further, “the upgrade operation is typically driven by the management entity of a mobile network,” and this operation includes increasing the serving capacity of the new software version, e.g., by successively adding instances ([0088]-[0089]; Fig. 6, step 605; [0067], step 403). At step 401 of Fig. 4, “the new software version with limited capacity is started/added, but it is not serving any live traffic yet,” while the old instances serve all traffic ([0067]). The new set is redundant for the serving set: it implements the same mobile network function ([0065], [0067]), and “protection by redundancy against failure is still provided” during the upgrade ([0072]).
cause services being served by the second set of network function instances to be transferred to the first set of network function instances. At steps 402, “new control traffic that comprises new service requests is routed to the established one or more instances of the new software version, while existing traffic is still supported by the old software version” (Ni, [0067]). At step 403-405, the serving capacity of the new version is increased and that of the old version is decreased until “there is no or very little traffic left” served by the old instances ([0067]). Users served by an old-version instance may be passively or actively migrated “to an instance implemented by the new software version” ([0079]), and “all the remaining traffic is switched to the new software version instance(s)” ([0089], Fig. 6, step 609). The traffic decider carries out the routing that transfers the service load: it “separates incoming traffic into either new or old traffic (i.e. already ongoing sessions started before the upgrade, and new sessions)” and routes new sessions to the new-version instance while ongoing sessions remain on the old-version instance ([0086], Fig. 5; [0081]).
Ni does not teach that the creating uses a new root certificate updated in a migration of certificate authority (CA), wherein respective certificates for the second set of network function instances are to be updated in the migration of CA. Ni’s software migration is performed for a software version change. Ni does not disclose a migration of CA or any updating of certificates.
Opschroef cures this deficiency. Opschroef teaches a CA migration in which a new root certificate is updated: “an update from an old trusted anchor certificate to a new trusted anchor certificate, wherein each of said trusted anchor certificates is a root point of a chain of certificates” ([0043]). Such certificate secure TLS/IPSec connections between network elements of mobile networks ([0002]-[0003]). When the trust anchor changes, the certificates of the deployed entities are to be updated: each entity must receive a new end-entity certificate signed under the new anchor ([0009], “the new entity will eventually also sign new EE certificates to be deployed to the EEs”), and an entity that has not yet been updated cannot connect to one that has ([0011]-[0016], Fig. 2). In the combination, these deployed certificate-holding entities correspond to Ni’s in-service (second) set of instances.
Opschroef is analogous art. It is in the same field of endeavor as the claimed invention, namely PKI-based security between elements of a mobile communication network. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Ni such that the instance replacement and service transfer are performed for a migration of CA in which a new root certificate is updated, as taught by Opschroef. In the combination, Ni’s management entity, which drives the upgraded operation (Ni, [0088]), creates the replacement (first) set of instances upon the CA migration rather than upon a software version change. The in-service (second) set continues serving existing traffic under the old root certificate. New requests are routed to the replacement instances, and the old instances are removed once they no longer serve any user (Ni, [0068]).
One of ordinary skill would have been motivated to make this modification because Opschroef identifies the harm to be avoided: during the CA migration window, “the secure connection cannot be established, because peer B does not possess and utilize the new TA yet” ([0016]). Opschroef also seeks “an efficient automatic trust anchor update” ([0049]), and concedes that cross-certification between the old and new anchors is not universally supported ([0024]-[0025]). Ni supplies that continuity: “Ongoing services/sessions/bearers are not disrupted” ([0071]).
This modification uses a known technique to improve a similar method in the same way. Ni’s instance replacement maintains service through a disruptive change to the instances, and applying it to Opschroef’s trust anchor migration addresses the broken connections that its migration window risks ([0011-0016]). It yields the predictable result that services continued uninterrupted through the CA migration, because no entity is asked to establish a connection it cannot validate. One of ordinary skill would have had a reasonable expectation of success because Ni’s procedure require only that there be an old set of instances and a new set of instances; it does not depend on the nature of the difference between them. The traffic is routed based on whether a session is ongoing or new ([0086], Fig. 5; [0081]). The procedure therefore operates the same way whether the sets differ in software version, as in Ni, or in certificate chain, as in the combination.
Ni in view of Opschroef does not expressly teach creating the first set of network function instances using the updated root certificate, i.e., provisioning the newly created instances with certificates chained to the new root certificate.
Feng cures this deficiency. Feng teaches certificate provisioning at instantiation: “during or after instantiation of the virtualized network function entity,” the virtualized network management entity installs initial credential information onto the entity, “so that the virtualized network function entity obtains, from a certificate authority by using the initial credential information, a formal certificate issued by a network operator” ([0006]-[0008]; Fig. 1, steps 101-102). In the combination, an instance instantiated after the new root certificate is updated obtains its certificate under the new root certificate, because the new trust anchor signs the new end-entity certificates (Opschroef: [0009]).
Feng is analogous art. It is directed to certificate configuration for virtualized network function instances in an NFV system, the same field of endeavor as Ni and the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Ni and Opschroef such that the replacement instances are provisioned with certificates at instantiation, as taught by Feng. One of ordinary skill would have been motivated to do so because, after the migration of CA, only the new trust anchor is valid and a connection cannot be established without it (Opschroef: [0016], [0043]); a replacement instance therefore cannot take over the transferred services unless it holds a certificate chained to the new root certificate. Feng’s method “can resolve a problem of a security risk in existing network function virtualization” ([0005]).
Applying Feng’s provisioning technique to the replacement instances of the combination yields the predictable result that the first set of network function instances operates under the new root certificate while the second set of network function instances continues operating under the old root certificate until services are transferred. One of ordinary skill would have had a reasonable expectation of success because Ni’s management entity already drives the upgrade operation, including the creation of instances ([0088]-[0089]), and controls the distribution of requests ([0065]), and Feng’s enrollment is likewise performed by a virtualized network management entity ([0006]-[0008]).
Claim 73:
Regarding claim 73, Ni in view of Opschroef and Feng teaches the limitations of claim 72 as set forth above. Ni and Feng do not teach receive a notification that the migration of CA is about to occur, and wherein causing the creating of the first set of network function instances is performed in response to the receiving of the notification.
Under the broadest reasonable interpretation in light of the specification, which describes sending the notification when the CA migration is detected or anticipated (Specification: [0046]-[0047]), “about to occur” requires no particular degree of imminence; the recited notification encompasses any notification of a forthcoming migration of CA.
Opschroef further teaches receive a notification that the migration of CA is about to occur. The CA Key Update Announcement Content is a data structure used “to announce this event when a CA updates its own key pair” ([0030]). The announcement is pushed from CA to the end entity ([0032], which “automatically gets notified when new TA is available” ([0033]). Opschroef’s automated TA update procedure uses this announcement, which “triggers the EEs that a new TA is conveyed ([0050]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination such that the management entity receives a notification that the migration of CA is about to occur, i.e., the announcement taught by Opschroef, and performs the creating of the first set of network function instances in response to the receiving of the notification. One of ordinary skill would have been motivated to do so because creating the replacement instances upon the announcement allows the service to be transferred before the post-migration period, in which only the new trust anchor is valid and certificates under the old root certificate can no longer establish connections (Opschroef: [0016], [0043]). Using the announcement as the trigger yields the predictable result that the creating of the first set of network function instances begins without manual intervention, as Opschroef’s automated procedure intends ([0050]). One of ordinary skill would have had a reasonable expectation of success because Ni’s upgrade operation is already driven by its management entity (Ni: [0088]); the announcement merely determines when that operation begins.
Claim 74:
Regarding claim 74, Ni in view of Opschroef and Feng teaches the limitations of claim 72 as set forth above. The combination further teaches causing each network function instance of the first set of network function instances to be signed with respective new certificates which are generated or updated based on the new root certificate.
Feng teaches that each instantiated network function entity obtains its own certificate: the entity “obtains, from a certificate authority by using the initial credential information, a formal certificate issued by a network operator” ([0006]-[0008]). Opschroef teaches certificates generated based on the new root certificate: an updated entity is provided with “a new end entity certificate (EEA’s certificate) signed with the private key related to the new trust anchor’s certificate” ([0012]), and “the new TA will eventually also sign new EE certificates to be deployed to the EES” ([0009]). In the combination, each network function instance of the first set of network function instances is signed with its own new certificate issued under the new root certificate. The rationale for the combination is set forth in the rejection of claim 72.
Claim 75:
Regarding claim 75, Ni in view of Opschroef and Feng teaches the limitations of claim 72 as set forth above. The combination further teaches to activate the first set of network function instances; and configure the first set of network function instances so that the first set of network function instances is specific for the migration of CA.
Ni teaches activating the first set of network function instances. The new instances are started and begin serving new service requests [(0067], steps 401-402), until all remaining traffic is switched to them ([0089], step 609). Ni also teaches configuring the new instances for the upgrade: “Upgrade agents are installed and configured according to the protocol-specific rules on each version” ([0086]). Feng teaches configuring each new instance at instantiation: the management entity “installs the initial credential information onto the virtualized network function entity” ([0006]-[0008]). In the combination, this configuration makes the first set of network function instances specific for the migration of CA: that set is configured with the migration-specific rules and with certificates chained to the new root certificate, and is thereby the only set of instances that operates under the root certificate updated in the migration of CA. The rational for the combination is set forth in the rejection of claim 72.
Claim 78:
Regarding claim 78, Ni in view of Opschroef and Feng teaches the limitations of claim 72 as set forth above. The combination further teaches to deactivate the second set of network function instances. Ni teaches that the serving capacity of the old software version is decreased “by (successively) removing instances” ([0067]), that the last old instance is removed once it is “no longer serving any user” ([0068]), and that the removed old instances are cleaned up ([0092]). Removing the old instance from service deactivates them. The rationale for the combination is set forth in the rejection of claim 72.
10. Claims 77 and 79 rejected under 35 U.S.C. § 103 as being unpatentable over Ni in view of Opschroef and Feng as applied to claims 72 and 78 above, and further in view of 3GPP TS 29.510, (published as ETSI TS 129 510 V15.6.0, “5G; 5G System; Network function repository services; Stage 3”), hereafter TS 29.510.
Regarding claim 77, Ni in view of Opschroef and Feng teaches the limitations of claim 72 as set forth above. The combination does not disclose update for each network function instance of the second set of network function instances, a status and priority maintained in a network repository function (NRF).
TS 29.510 cures this deficiency. TS29.510 teaches a network repository function that maintains an NF profile for each registered network function instance. The NF profile includes the “nfStatus” attribute, the “Status of the NF Instance,” and may include a “priority” attribute, a “Priority (relative to other NFs of the same type) in the range of 0-65535, to be used for NF selection; lower values indicate a higher priority” (§ 6.1.6.2.2, Table 6.1.6.2.2-1, pp. 46-48). TS 29.510 further teaches updating these attributes. The NFUpdate service operation “allows an NF Instance to replace, or update partially, the parameters of its NF profile” (§ 5.2.2.1, p. 11); the partial update is an HTTTP PATCH request that “shall be used to add/delete/replace individual parameters of the NF Instance” (§ 5.2.2.3, p. 14). The NRF “shall notify NFs subscribed to receiving notifications of changes of the NF profile, if… nfStatus is changed” (§ 6.1.6.2.2, NOTE 5, p. 49).
TS 29.510 is analogous art. It is directed to the management of network function instances in a 5G core network, the same field of endeavor as Ni and the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Ni, Opschroef and Ni such that the instances of the first and second sets of network function instances register their profiles with an NRF and, during the migration of CA, the status and priority maintained there for each instance of the second set of network function instances are updated using the NFUpdate operation taught by TS 29.510.
One of ordinary skill would have been motivated to do so because TS 29.510 defines a status that matches the condition of the second set of network function instances. An NF instance may have an “UNDISCOVERABLE” status, for example, “in shutting down scenario where the NF is still able to process requests for existing resources or sessions but cannot accept new resource creation or session establishment” (§ 6.1.6.3.7, Table 6.1.6.3.7-1, p. 70). Each instance of the second set of network function instances is in that condition while the services being served by those instances are transferred to the first set of network function instances. Updating the status of each instance of the second set therefore uses the “UNDISCOVERABLE” status as TS 29.510 intends. Updating the priority values of the instances of the second set so that they are less preferred serves the stated purpose of the priority attribute, “to be used for NF selection” (§ 6.1.6.2.2, Table 6.1.6.2.2-1, p. 48 and NOTE 4, p. 49).
Applying the NFUpdate operation to the second set of network function instances yields the predictable result that the NRF’s stored status and priority for each instance are changed and, because the nfStatus is changed, NFs subscribed to receiving notifications of changes of the NF profile are notified (§ 6.1.6.2.2, NOTE 5, p. 49). One of ordinary skill would have had a reasonable expectation of success because registration and profile updates are the NRF’s standard service operations (§ 5.2.2, p.11), and Ni’s management entity already drives the upgrade operation (Ni: [0088]).
Claim 79:
Regarding claim 79, Ni in view of Opschroef and Feng teaches the limitations of claim 78 as set forth above. The combination further teaches deleting or locking the second set of network function instances. Ni’s old instances are removed and cleaned up ([0067]-[0068], [0092]). Ni, Opschroef and Feng do not teach de-registering each network function instance of the second set of network function instances from a network repository function (NRF).
TS 29.510 cures this deficiency. TS 29.510 teaches the NFDeregister service operation, which “allows an NF instance to deregister its NF profile in the NRF” (§ 5.2.2.1, p. 11). The operation “removes the profile of a Network Function previously registered in the NRF” by deleting the resource identified by the NF instance ID (§ 5.2.2.4, pp. 15-16). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Ni, Opschroef and Ni such that, when the second set of network function instances is deactivated, each instance is de-registered from an NRF using the NFDeregister operation taught by TS 29.510, and the instances are then deleted, as taught by Ni. One of ordinary skill would have been motivated to do so because a SUSPENDED NF instance “is not operative and cannot be discovered by other NFs” (§ 6.1.6.3.7, Table 6.1.6.3.7-1, p. 70), and de-registering each deactivated instance of the second set of network function instances removes it from discovery affirmatively.
Applying the NFDeregister operation to de-register the instances of the second set of network function instances yields the predictable result that the de-registered instances can no longer be discovered via the NRF. One of ordinary skill would have had a reasonable expectation of success because deregistration is one of NRF’s standard service operations (TS 29.510: § 5.2.2.1, p. 11), and Ni’s procedures already removes the old instances (Ni: [0067]-[0068]).
11. Claim 76 is rejected under 35 U.S.C. § 103 as being unpatentable over Ni in view of Opschroef and Feng as applied to claim 72 above, and further in view of Patil et al. (US 2020/0314615 A1), hereafter Patil.
Regarding claim 76, Ni in view of Opschroef and Feng teaches the limitations of claim 72 as set forth above. The combination does not teach cause each network function instance of the first set of network function instances to be registered to a network repository function (NRF), with an indicator indicating at least one of the following information: each network function instance of the first set of network function instances has a high priority; or each network function instance of the first set of network function instances is specific for the migration of CA.
Patil cures this deficiency. Patil teaches registering a new version of a network function to a network repository function (NRF), with an indicator indicating its priority. To deploy an updated network function, a value for a priority is assigned to it, and “[a]fter assigning the value, the operator may instantiate and register the network function 202 at NRF 214,” whereupon “the newly registered network function 202 or service version may then begin to accept messages” (Patil: [0034]). The NF profile that a network function sends during registration ([0058]) includes an NF status and a priority ([0062]; Fig. 6C). Priorities are assigned to network function and service version instances, including “an instance of a Canary release” ([0027], [0046]), are stored at the NRF, and are “retrieved and used to route messages” ([0047]). A message is routed “to a network function or a service whose priority is equal to or higher than that of the message” ([0027]).
Patil is analogous art. It is directed to registering and routing among versions of network function instances in a 5G service-based architecture, the same field of endeavor as Ni and the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Ni, Opschroef and Ni such that each network function instance of the first set of network function instances is registered to an NRF with an indicator indicating a high priority, per the registration taught by Patil. One of ordinary skill would have been motivated to do so because Patil states that “it is important to control routing messages or transactions to or around Canary releases,” and Patil achieves “such control” over routing “by assigning priorities” to network functions and services ([0027]).
In the combination, the network function instances of the first set of network function instances must take over the services being served by the second set of network function instances. Under Patil’s rule that a message is routed “to a network function or a service whose priority is equal to or higher than that of the message” (Patil: [0027]), registering each instance of the first set of network function instances with a high priority permits those instances to receive messages of any priority, and thereby to serve the services being transferred. Registering each instance of the first set with a high priority yields the predictable result that the registered priorities are stored at the NRF and are retrieved and used to route messages to those instances (Patil: [0047]). One of ordinary skill would have had a reasonable expectation of success because assigning a priority and then instantiating and registering the network function at the NRF is Patil’s disclosed deployment sequence ([0034]), and Ni already instantiates the new instance in the upgrade operation driven by its management entity, where that sequence can be performed.
The claimed indicator is recited in the alternative. The combination renders obvious the first alternative, an indicator indicating that each network function instance of the first set of network function instances has a high priority.
12. Claim 80 is rejected under 35 U.S.C. § 103 as being unpatentable over Ni in view of Opschroef and Feng as applied to claim 72 above, and further in view of 3GPP TS 28.531 V17.4.0, (“Management and orchestration; Provisioning”), hereafter TS 28.531.
Regarding claim 80, Ni in view of Opschroef and Feng teaches the limitations of claim 72 as set forth above. The combination does not teach wherein the second set of network function instances is deployed in a network slice subnet instance.
TS 28.531 cures this deficiency. TS 28.531 teaches network functions deployed in a network slice subnet instance (NSSI). The constituents of an NSSI included network function instances: a modification request for a network slice subnet is decomposed “into modification requests for each NSSI constituent,” and “a requested NSSI constituent” may be an “NF instance” (§ 7.7). When an NSSI is allocated, the network function instance within it are deployed: when “the NSSI to be created contains virtualization part (i.e. VNF or VL),” the network slice subnet management service provider “determines new VNF instance(s) that need to be deployed… according to the necessary network function(s)” (§ 7.3).
TS 28.531 is analogous art. It is directed to the provisioning and management of network slice instances and their constituent network function instances in a 5G network, the same field of endeavor as Ni and the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Ni, Opschroef and Feng such that the second set of network function instances is deployed in a network slice subnet instance, as taught by TS 28.531. One of ordinary skill would have been motivated to do so because, in creating a network slice subnet instance, TS 28.531 derives for its constituents requirements including “isolation requirements” (§ 7.3, step 4.1b.1), isolation being among the defined network slice related requirements (§ 5.2.1, NOTE 1). Deploying the second set of network function instances in a network slice subnet instance allows the instances operating under the old root certificate to be managed and isolated as a unit.
Deploying the second set of network function instances in a network slice subnet instance yields the predictable result that those instances are manageable together through the network slice management services specified in TS 28.531: the network slice subnet instance may be allocated, activated and deactivated through those services (§ 6.5.2; § 5.1.10-5.1.11). One of ordinary skill in the art would have had a reasonable expectation of success because network function instances are among the defined constituents of a network slice subnet instance (§ 7.7), and that inclusion does not alter how the combination of Ni, Opschroef and Feng create those instances or transfer services to them.
13. Claims 81, 82, 84, 86 and 87 are rejected under 35 U.S.C. § 103 as being unpatentable over Ni in view of Opschroef and Feng as applied to claim 72 above, and further in view of 3GPP TS 28.531 V17.4.0, (“Management and orchestration; Provisioning”), hereafter TS 28.531, and further in view of Lu et al. (WO 2018171430 A1, citations are to the attached machine translation obtained from the European Patent Office website), hereafter Lu.
Regarding claim 81, Ni in view of Opschroef and Feng teaches the limitations of claim 72 as set forth above. The combination does not teach cause a creating of a first network slice subnet instance which is redundant for a second network slice subnet instance, wherein the second set of network function instances is deployed in the second network slice subnet instance; wherein the creating of the first set of network function instances is triggered by the creating of the first network slice subnet instance.
TS 28.531 cures these deficiencies in part. TS 28.531 teaches network functions deployed in a network slice subnet instance (NSSI). When “the NSSI to be created contains virtualization part (i.e. VNF or VL), the network slice subnet management service provider “determines new VNF instances (s) that need to be deployed” (§ 7.3, step 4.1b.2); such a “requested NSSI constituent” may be an “NF instance” (§ 7.7).
TS 28.531 further teaches creating of network function instances triggered by the creating of a network slice subnet instance. When creating a new NSSI, the provider first “create the NetworkSliceSubnet MOI” (§ 7.3, step 4.1b.1); then, “[i]f the required NSSI constituent is NF instance, NSSMS_P invokes NF Creation Procedure as described in clause 7.10” (§ 7.3, step 4.1b.3b). Clause 7.10, in turn, describes “the procedure of creating a new network function instance” (§ 7.10).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination such that the second set of network function instances is deployed in a second network slice subnet instance, as taught by TS 28.531. It would have been obvious to further create the first set of network function instances through the allocation of a first network slice subnet instance, also as taught by TS 28.531. The creating of the first set of network function instances is thereby triggered by the creating of the first network slice subnet instance (§ 7.3, steps 4.1b.1, 4.1b.3b). Such triggering follows the provisioning architecture specified by TS 28.531: “NSI creation may trigger NSSI(s) creation” (§ 4.1), and NSSI allocation in turn invokes, for each required NSSI constituent that is an NF instance, the “NF Creation Procedure” (§ 7.3, steps 4.1b.3, 4.1b.3b).
One of ordinary skill would have been motivated to do so because provisioning a network slice subnet includes a feasibility check ensuring the network slice subnet requirements are satisfied “without impacting existing services” (§ 5.1.6, Step 3; § 7.3, step 2). The first set of network function instances can therefore be created while the second set of network function instances continues to serve. The modification yields the predictable result that the first set of network function instances is configured as constituents of the first network slice subnet instance: the provider “configures the NetworkSliceSubnet MOI with the DN of the MOI for NSSI constituent (§ 7.3, steps 4.1b.4). One of ordinary skill would have had a reasonable expectation of success because network function instance creation is an expressly specified step of the NSSI allocation procedure specified by TS 28.531: (§ 7.3, steps 4.1b.2, 4.1b.3b), and the modification does not alter how the combination of Ni, Opschroef and Feng creates the network function instances themselves.
TS 28.531 does not teach causing a creating of a first network slice subnet instance which is redundant for a second network slice subnet instance. Lu cures the remaining deficiency. Lu teaches causing a creating of a first network slice subnet instance which is redundant for a second network slice subnet instance. Lu describes a network slice management process that “automatically create new NSSIs to replace faulty NSSIs” ([0167]). A network slice self-healing implementation function (i.e., NS-SH-IF) sends an NSSI creation request, and the receiving management function (i.e., NSSMF 2)”creates NSSI 2 based on the received request” ([0174, step S706; Fig. 7 of the original WO publication). NSSI 2 is then activated, loading “the user service information on NSSI 1” “in order to restore services” ([0178], step S710). Lu expressly describes the replacing instance as “a redundant network slice subnet instance” or “a newly created network slice subnet instance” ([0132]). Lu’s replacing instance (i.e., NSSSI 2) corresponds to the claimed first network slice subnet instance; Lu’s NSSI 1 corresponds to the claimed second network slice subnet instance.
Lu is analogous art. It is directed to the management of network slice instances and the replacement of network slice subnet instances in a mobile communication network, the same field of endeavor as Ni and the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Ni, Opschroef, Feng and TS 28.531 such that the first network slice subnet instance is redundant for the second network slice subnet instance, as taught by Lu. One of ordinary skill would have been motivated to do so because Lu teaches that automatically creating a new NSSI to replace a failed NSSI restores service “without manual intervention, while ensuring service continuity and consistency as much as possible, thereby improving the overall reliability of the network slice instance” (Lu, [0183]). In the combination, the migration of CA (i.e., the migration in Opschroef, as set forth in the rejection of claim 72), rather than a fault, is the event upon which the second set of network function instance is to be replaced.
This modification yields the predictable result that the services running on the second network slice subnet instance continues on the first network slice subnet instance: in Lu, activating the newly created NSSI loads “the user service information on NSSI 1… in order to restore services” ([[0178, step S710). One of ordinary skill would have had a reasonable expectation of success because Lu’s method creates, configures, and activates the new NSSI to take over the services of the replaced NSSI ([0174]-[0178]), and the modification does not alter how the combination of Ni, Opschroef and Feng transfers services served by the second set of network function instances to the first set of network function instances, as set forth in the rejection of claim 1 above.
Claim 82:
Regarding claim 82, Ni in view of Opschroef, Feng, TS 28.531 and Lu teaches the limitations of claim 81 as set forth above. Ni, Opschroef and Feng do not teach sending from a network slice management function (NSMF) to a network slice subnet management function (NSSMF), a request for creating the first network slice subnet instance.
TS 28.531 teaches sending from a network slice management function (NSMF) to a network slice subnet management function (NSSMF), a request for creating the first network slice subnet instance. For the network slice instance allocation procedure, when creating a new NSI, the Network Slice Management Service Provider (NSMS Provider) derives “the network slice subnet related requirements” (§ 7.2, step 3b-1) and “invokes the NSSI allocation procedure as described in clause 7.3” (§ 7.2, step 3b-2). The NSSI allocation procedure begins when the Network Slice Subnet Management Service Provider “receives an AllocateNssi request” from the “Network Slice Subnet Management Service Consumer (NSSMS_C)” (§ 7.3, step 1); the NSMS_Provider, having invoked the procedure of clause 7.3, act as the NSSMS_C. The NSMS_Provider is the entity performing the network slice management , i.e., a network slice management function; the network slice subnet management service provider is the entity performing network slice subnet management, i.e., a network slice subnet management function.
Lu shows the same direction in the claim’s own terms. THE NSMF module includes the NS-SH-IF module ([0167]; Figs. 2-4 of the original WIPO publication). The NS-SH-IF sends “an NSSI creation request” to NSSMF 2 ([0174], step S706; Fig. 7 of the original WIPO publication), and NSSMF 2 “creates NSSI 2based on the received request” ([0174]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination such that the request for creating the first network slice subnet instance is sent from the NSMF to the NSSMF, as taught by TS 28.531 and Lu. One of ordinary skill would have been motivated to do so because the NSSMS_P is the entity holding subnet-level knowledge: it checks the feasibility of the network slice subnet related requirement (§ 7.3, step 2) and provides network slice subnet capability information (§ 7.8.2). Lu states the benefit of such management: the method “can improve the efficiency of managing network slice instances” ([0006]).
The modification yields the predictable result that the NSSMF carries out the allocation and returns the NSSI allocation result, including the DN of the NetworkSliceSubnet MOI, to the requester (§ 7.3, step 5). One of ordinary skill would have had a reasonable expectation of success because the combination already creates the first network slice subnet instance through the NSSI allocation procedure specified by TS28.531 as set forth in the rejection of claim 81, and sending the AllocateNssi request from the slice-level manager is that procedure’s own first step (§ 7.2, step 3b-2; § 7.3).
Claim 84:
Regarding claim 84, Ni in view of Opschroef, Feng, TS 28.531 and Lu teaches the limitations of claim 81 as set forth above. Ni, Opschroef, Feng and Lu do not teach activating the first network slice subnet instance, when the first set of network function instances are activated.
TS 28.531 further teaches activating a network slice subnet instance, when its constituent network function instances are activated. In the NSSI activation procedure, the network slice subnet provisioning management service provider “identifies inactive constituents (e.g., NSSI, NF) of the NSSI and decides to activate those constituents” (§ 5.1.10, Step 1), and requests the NF related provisioning management service provider “to activate the NF (e.g., activate the NF in sleep mode, turn on the ports)” (§ 5.1.10, Step 4). The provider then “receives response indicating that NSSI constituents are all activated” (§ 5.1.10, step 5) and “activates the network slice subnet instance” (§ 5.1.10, Step 6). The network slice subnet instance is thus activated when its constituent network function instance are activated. In the combination, the first set of network function instances are the constituents of the first network slice subnet instance (as set forth in the rejection of claim 81); activating the first network slice subnet instance according to the procedure of § 5.1.10 therefore activates it when the first set of network function instances are activated.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Ni, Opschroef, Feng, TS 28.531, and Lu as applied to claim 81 above such that the first network slice subnet instance is activated when the first set of network function instances are activated, as taught by TS 28.531 (§ 5.1.10). One of ordinary skill would have been motivated to do so because activating the network slice subnet instance only after its constituents are confirmed active (§ 5.1.10, Steps 5 and 6), ensures the instance becomes active only when able to serve. The modification yields the predictable result that when the first network slice subnet instance is activated, its constituent network function instances are already activated (§ 5.1.10, Steps 5 and 6), and the instance is available “to be used by the NSI” (§ 4.1). One of ordinary skill would have had a reasonable expectation of success because TS 28.531 specifies activation of an NSSI as a provisioning operation performed on an instance that “has already been created” (§ 5.1.10, Pre-conditions; § 4.1). Lu’s method activates the newly created NSSI ([0178], step S710). Conditioning that activation on the constituent instances being active does not alter how the combination as applied to claim 81 creates the first network slice subnet instance or the first set of network function instances.
Claim 86:
Regarding claim 86, Ni in view of Opschroef, Feng, TS 28.531 and Lu teaches the limitations of claim 81 as set forth above. Ni, Opschroef, Feng and Lu do not teach deleting the second network slice subnet instance.
TS 28.531 further teaches deleting a network slice subnet instance. For the network slice subnet instance deallocation procedure, the network slice subnet management service provider receives an NSSI deallocation request “indicating that the NetworkSliceSubnet MOI is no longer needed for the given requirement,” (§ 7.5, step 1). The provider “may decide to terminate the NSSI” (§ 7.5, step 3-a). It “invokes NF deletion procedure as described in clause 7.12 only if the NF is dedicated for this NSSI and not being used by any other NSSI in the network” (§ 7.5, step 3-b), in which the NF management service provider “deletes the ManagedFunction MOI” (§ 7.12, step 3). At the network slice subnet level, deallocation exists “[t]o terminate or disassociate an existing NSSI which was used by the NSI or NSSI, but no longer needed” (§ 5.1.4, Goal), and [t]he provider may terminate the requested NSSI to modify the requested NSSI without termination” (§ 6.5.4.1). An NSSI that is not terminated is instead disassociated from its consumer or kept “for later use” (§ 5.1.4, Step 1); the termination branch of the deallocation procedure thus removes the network slice subnet instance itself. Terminating the network slice subnet instance is deleting it.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination such that the second network slice subnet instance is deleted, as taught by TS 28.531. One of ordinary skill would have been motivated to do so because, once the services served by the second set of network function instances are transferred to the first set (as recited in claim 72), the second network slice subnet instance is an existing NSSI that is “no longer needed,” which is the condition on which § 5.1.4 specifies deallocation (Begins when). The modification yields the predictable result that the constituent network function instances dedicated to the second network slice subnet instance are deleted with that instance (§ 7.5, step 3-b; § 7.12, steps 2 and 3). One of ordinary skill would have had a reasonable expectation of success because NSSI deallocation is a specified operation with an express termination branch (§ 7.5, steps 1, 3-a), and the modification does not alter the transfer of the services to the first set of network function instances as set forth in the rejection of claim 72 above.
Claim 87:
Regarding claim 87, Ni in view of Opschroef, Feng, TS 28.531 and Lu teaches the limitations of claim 81 as set forth above. Ni, Opschroef and Feng do not teach wherein the first network slice subnet instance is a core network slice subnet instance.
Lu further teaches a network slice subnet instance which is a core network slice subnet instance. In Lu, a network slice can include core networks, and “may only include access networks and core networks” ([0089]). A network slice instance can consist of network slice subnet instances and/or network functions, and network functions “may include physical network functions and/or virtual network functions” ([0090]). A network slice subnet instance “can be a collection of network functions divided by domain, such as a core network slice subnet instance, an access network slice subnet instance” ([0091]). TS 28.531 is consistent with this division by domain: the general information describing a network slice subnet instance includes the “network slice subnet type (e.g., RAN eMBB, CN eMBB)” (§ 4.4).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination such that the first network slice subnet instance is a core network slice subnet instance, as taught by Lu. The modification selects the core network slice subnet instance from among the domain species Lu expressly discloses ([0091]). One of ordinary skill would have been motivated to do so because Lu’s network slice subnet instance is “a collection of network functions divided by domain,” which is an arrangement that “facilitate network management system administration” ([0091]). The modification yields the predictable result that the first network slice subnet instance is a core network slice subnet instance, described by its corresponding network slice subnet type (TS 28.531: “CN eMBB,” § 4.4). One of ordinary skill would have had a reasonable expectation of success because the core network slice subnet instance is an expressly disclosed species of network slice subnet instance (Lu: [0091]), and the selection does not alter how the combination creates the first network slice subnet instance or the first set of network function instances, as set forth in the rejections of claims 72 and 81 above.
14. Claims 83 is rejected under 35 U.S.C. § 103 as being unpatentable over Ni in view of Opschroef, Feng, TS 28.531 and Lu as applied to claims 72 and 82 above, and further in view of Yang et al. (US 11,240,745 B2), hereafter Yang.
Regarding claim 83, Ni in view of Opschroef, Feng, TS 28.531 and Lu teaches the limitations of claim 82 as set forth above. The combination does not teach an identity of the second network slice subnet instance.
Claim 12 recites the identity of the second network slice subnet instance and an indictor in the alternative. Under the broadest reasonable interpretation, the recited “at least one of” requires only one of the alternatives; a request comprising the identity of the second network slice subnet instance therefore satisfies the limitation.
Yang cures this deficiency. Yang teaches a request sent from an NSMF to an NSSMF that comprises an identity of the to-be-modified network slice subnet instance: “S601. An NSMF sends a modification request message to an NSSMF, to request to modify a first NSSI” (col. 10, ll. 7-8), where the “parameters included in the modification request message are shown in the first embodiment” (col. 10, ll. 9-11), namely “an identifier of the to-be-modified first network slice subnet instance, for example, an NSSI ID, and an updated related requirement of the NSSI” (col. 9, ll. 31-34). When the NSSMF “the NSSMF determines that the first NSSI is not allowed to be modified” (S602, col. 10, ll. 12-14), the NSSMF creates a new instance in its place: “S603. The NSSMF creates a second NSSI based on the updated network slice subnet related requirement in the modification request message” (col. 10, ll. 29-31). The NSSMF then “adds the newly created second NSSI to a first NSI based on a first NSI ID to which the first NSSI belongs” (col. 10, ll. 34-36) and “deletes the first NSSI from the NSI” (col. 12, ll. 34-36). Yang’s identified “first NSSI” corresponds to the claimed second network slice subnet instance; Yang’s newly created “second NSSI” corresponds to the claimed first network slice subnet instance.
Yang is analogous art. It is directed to the management and modification of network slice subnet instances by network slice management functions in a mobile network, the same field of endeavor as TS 28,531, Lu, and the claimed invention.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combination of Ni, Opschroef, Feng, TS 28.531 and Lu such that the request for creating the first network slice subnet instance comprises an identity of the second network slice subnet instance, as taught by Yang. One of ordinary skill would have been motivated to do so because the NSSMF must know which instance it is to act on. Yang specifies “adding, by the first network device, the second NSSI to an NSI to which the first NSSI belongs, and deleting the first NSSI from the NSI” (col. 2, ll. 49-52). Additionally, per Yang, “NSSIs included in NSIs are updated thereby eliminating redundancy of the NSIs” (col. 2, ll. 53-54). The identity carried in Yang’s request message supplies that knowledge (col .9, ll. 31-34; col. 10, ll. 9-11).
In the combination, the second network slice subnet instance, in which the second set of network function instances is deployed (claim 81), is retired and replaced rather than modified in place, which is the circumstance of Yang’s second embodiment (S602, col. 10, ll. 12-14). The instance identified in the request is therefore the second network slice subnet instance, and the request comprises its identity. The proposed modification applies a known technique (carrying the identifier of the instance concerned in the slice subnet management request, Yang, col. 9, ll. 29-34) to a known method ready for improvement (the NSMF-to-NSSMF request taught by TS 28,531 and Lu, as set forth in the rejection of claim 82 above), and yields the predictable result described in Yang: the NSSMF adds the newly created instance to the network slice instance to which the identified instance belongs (col. 10, ll. 34-38) and deletes the identified instance from it (col. 12, ll. 34-36). One of ordinary skill would have had a reasonable expectation of success because Yang’s NSSMF receives the identity carried in the request message and acts on the instance it identifies (col. 9, ll. 31-34; col. 10, ll. 12-14; col. 12, ll. 34-36), and including the identity in the request does not alter how the combination, as set forth in the rejection of claims 81 and 82 above, creates the first network slice subnet instance.
15. Claims 85 is rejected under 35 U.S.C. § 103 as being unpatentable over Ni in view of Opschroef, Feng, TS 28.531 and Lu as applied to claims 72 and 81 above, and further in view of Shimojou et al. (US 2020/0045624 A1), hereafter Shimojou.
Regarding claim 85, Ni in view Opschroef, Feng, TS 28.531 and Lu teach the limitations of claim 81 as set forth above. The combination does not disclose update a network slice selection function (NSSF) with a network slice instance for the first network slice subnet instance.
Shimojou cures this deficiency. Shimojou teaches update a network slice selection function (NSSF) with a network slice instance. Shimojou discloses a network slice management function (NSMF) having “a function of generating and managing a slice” and a network slice sub-network management function (NSSMF) having “a function of generating and managing a part oof a slice (network slice sub-network)” ([0029]). In a case of generating a slice, the NSMF transmits a request for a service related to the request for starting a service” ([0083], Steps 3 to 5 of Fig. 6). “Then, the NSMF generates an NSI-ID related to the slice for a service related to the request for starting a service” and “transmits a slice instance update notification to the NSSF”; the notification “includes information of the generated NSI-ID, the SST, and the SD” ([0038], Steps 6 and 7b). “The NSSF updates the slice management table using the AMF-ID of the identified AMF and the information of the NSI-ID, the SST, and the SD included in the slice instance update notification” ([0038], Step 8), and “the slice management table retained in the NSSF is normally updated based on an instruction from the NSMF” ([0039]. The slice management table is retained in the NSSF ([0031]) and stores “identification information of NSIs (NSI-IDs) related to slices” ([0033]). In the combination, the slice sub-network generated in Shimojou’s flow is the first network slice subnet instance, created as recited in claim 81, and the generated NSI-ID identifies the network slice instance to which that subnet instance belongs (TS 28.531 §4.1,; (Lu [0090]). By transmitting the slice instance update notification, the apparatus therefore updates the NSSF with the network slice instance for the first network slice subnet instance; the slice management table retained in the NSSF is “normally updated based on the instruction from the NSMF” (Shimojou [0039]).
Shimojou is analogous art. It is directed to the generation and management of network slices and their constituent slice sub-networks in a mobile network, the same field of endeavor as TS 28.531, Lu and the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Ni, Opschroef, Feng, TS 28.531 and Lu such that the apparatus updates a network slice selection function (NSSF) with the network slice instance for the first network slice subnet instance, by transmitting the slice instance update notification taught by Shimojou. One of ordinary skill would have been motivated to make this modification in order to update the slice management table retained in the NSSF “to latest information” ([0036]), so that “the NSSF can select… an AMF corresponding to the slice, so that processing for a service is suitably executed by the selected AMF” ([0045]).
This modification applies a known technique (updating the NSSI’s slice management table when a slice is newly generated) to improve a similar device in the same way: the combined system of Ni, Opschroef, Feng, TS 28.531 and Lu, like Shimojou, generates network slice subnet instances for its network slice instances. The predictable result is that the NSSF’s slice management table lists the network slice instance for the newly created first network slice subnet instance. One of ordinary skill would have had a reasonable expectation of success because the slice instance update notification is Shimojou’s specified processing for a newly generated slice ([0039]), and the combined system of Ni, Opschroef, Feng, TS 28.531 and Lu already creates the first network slice subnet instance, as set forth in the rejection of claim 81 above.
Conclusion
16. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Hu (US 2022/0132413 A1) discloses a network slice management method in which a first network device, which may be an NSMF and/or an NSSFM, creates a network slice instance and then sends a notification message to an NSSF. The notification message includes the identifier of the created network slice instance and indicates that the instance can provide a service ([0026-0027], [0040]-[0041], [0201]-[0204]).The NSSF records a mapping relationship for the identifier and uses it to perform network slice selection (0202-0203]).
17. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BIN QING ZHENG whose telephone number is (703)756-1535. The examiner can normally be reached on M-F at 10:00 am - 06:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip J. Chea can be reached on 571-272-3951. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
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.
/BIN QING ZHENG/
Examiner, Art Unit 2499
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights