DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The amendment to the claims filed on 09/12/2025 complies with the requirements of 37 CFR 1.121(c) and has been entered. Claims 13, 16, and 17 have been cancelled. Claims 1, 2, 7, 9, 11, 14, 15 and 18-20 are been amended. Objection to Claims 7, 14 and 15 is withdrawn after amendment. Rejection of Claims 9-10 under 35 U.S.C. 112(b) is withdrawn after amendment.
Response to Arguments
Applicant’s alacrity to advance prosecution of the present application is appreciated. Applicant's arguments filed 09/12/2025 (hereinafter Resp.) have been fully considered as follows:
Regarding Applicant’s argument that “Chiba, fails to teach network slice specific congestion control” – See Resp.¶3:8, Examiner respectfully disagrees. Chiba et al., U.S. Patent Application Publication No. 2020/0382990 (hereinafter Chiba) discloses, for example, a congestion control process that depends on the parameters of a network slice – See [¶0154] (“the third congestion control in the present embodiment is control signal congestion control directed to the parameters of the DNN and the S-NSSAI,” e.g., to “prevent the UE-initiated session management request directed to the parameters of . . . the S-NSSAI #A” – See [¶0153], i.e., congestion control can be applied to all slices with a certain slice/NSSAI specific parameter; or “the fourth congestion control having the DNN #A and the S-NSSAI #A as parameters may be congestion control in which the first congestion control having the DNN #A as a parameter and the second congestion control having the S-NSSAI #A as a parameter are simultaneously performed” – See [¶0157], i.e., the congestion control process specifically applies to the S-NSSAI #A slice the UE subscribed to; see also § 5.6.1, 3GPP TS 23.501:104-105 V16.6.0 (2020-09), “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16)” (hereinafter 3GPP TS 23.501)). Therefore, Applicant’s argument as to Chiba failing to teach network slice specific congestion control is not persuasive.
Applicant’s argument that “Chiba fails to teach consulting a cognitive layer of the network node to determine a network slice specific congestion control process” – See Resp., ¶3:9 has merits but is not persuasive. Chiba does not disclose a cognitive layer or a cognitive function. However, Chiba discloses that slice specific rules apply in case of congestion detection – See [¶0170]( “the network slice associated rules may be preconfigured in the UE or may be notified from the network in a rejection notification regarding the PDU session establishment” because of congestion so that the UE may derive “information for identifying another NW slice relevant to information for identifying an NW slice notified in the rejection in response to the first PDU session establishment request”). For example, Chiba discloses slice specific back-off timers and priority management rules for “back-off timers in a case that a plurality of different congestion controls are activated for one or a plurality of PDU session establishments by the same UE,” whereby a UE attempts sessions with two slices, each one with its own network-defined back-off timer – See [¶0171] (stating also that “a timer value held by the UE may be overwritten with a timer value generated by prioritized congestion control”). Furthermore, Chiba teaches that the behavior of the UE in case of slice congestion “may be congestion control initiated and performed by the UE_A 10 based on rules and/or policies” whereby “the policy and/or the rule may include one or more of the network slice-associated rule and/or a priority management rule for a back-off timer, and/or a Network Slice Selection Policy (NSSP), which may further be preconfigured in the UE_A 10 or received from a network” – See [¶0335]. Even though rule and policy based control is a more classic/traditional form of “intelligence” in network management (e.g., PCRF performing QoS management between a UE and a Core Network), when compared with newer network analytics and cognitive functions known in the art, the present Specification discloses that the “cognitive layer” recommending the congestion control process can be rule-based – See [¶0033] (“a cognitive layer comprises a combination of semantic information with statistical data from the usage of the available congestion control processes for the selection process” wherein “semantic information includes, without limitation, . . . a type of congestion control process (e.g., learning-based (e.g., Monte Carlo-based, supervised learning, unsupervised learning, reinforcement learning, etc.) or rule-based (e.g., loss-based, delay-based, capacity-based, hybrid, etc.)”). This is no different from Chiba stating that the congestion control process initiated at the UE for a specific network slice is based on rules and/or policies received from a network. Therefore, lack of claiming specific structure and/or processes supported by the present Specification that would distinguish the claimed cognitive layer from Chiba’s rule-based network “intelligence,” Applicant’s argument that Chiba fails to teach consulting a cognitive layer of the network node to determine a network slice specific congestion control process, is not persuasive.
In sum, Applicant's arguments filed 09/12/2025 have been fully considered but they are not persuasive.
Applicant’s arguments regarding the amendment are also moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for the teaching or matter specifically challenged in the argument, i.e., optimization using a cognitive layer.
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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2, 4, 7-10, 12, 14-15, 18-22, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Chiba et al., U.S. Patent Application Publication No. 2020/0382990 (hereinafter Chiba), and further in view of Ravichandran et al., "Mechanism of dynamic, impact-aware and context aware orchestration of cognitive functions in 5G networks," 2018 IEEE International Conference on Advanced Networks and Telecommunications Systems (ANTS), and references included therein (hereinafter Ravichandran1).
Regarding Amended Claim 1, teaches a computer-implemented method for dynamic congestion control for network slices (“mechanism and a communication control method for implementing management processing such as congestion control for each network slice” – See [¶0009], whereby “a Network Slice is a logical network that provides a specific network capability and a network characteristic” – See [¶0130] and a “Network Slice Instance (NSI) . . . is an entity of each of one or a plurality of Network Slices configured in the core network” and “may include a virtual Network Function (NF) generated using a Network Slice Template (NST)” and “associated with a resource request for providing a required communication service or capability, and is a logical expression of one or a plurality of Network Functions (NFs)” – See [¶0131]), the method comprising:
obtaining a recommendation from a network node for a congestion control process (“[t]he congestion control . . . includes one or more congestion controls of the congestion controls from the first to the fourth congestion controls” – See [¶0148]; , the network recommends a congestion control process based on where the “control signal congestion control [is] directed [to],” – See [¶0149], i.e., “the first congestion control . . . is control signal congestion control directed to the DNN, . . . in connectivity using all types of S-NSSAI available for the UE, and may be a connection to the DNN #A through a network slice to which the UE can connect” – See [¶0150] and the UE performs a “first identification process to identify which type of congestion control to apply among the congestion controls from the first congestion control to the fourth congestion control and second identification process to identify the DNN and/or the S-NSSAI associated with the congestion control to be applied” – See [¶0173])
whereby the NW recommends the congestion control based on parameters of the DNN, parameters of the S-NSSAI or a combination of them (“in a case that control signal congestion with respect to S-NSSAI #A is detected on an NW and the NW recognizes it as a UE initiated session management request directed only to the parameters of the S-NSSAI #A, the NW may apply the second congestion control” – See [¶0151] or “the fourth congestion control . . . [which] is control signal congestion control directed to the parameters of the DNN and the S-NSSAI and may be congestion control caused by connectivity to the DNN via a network slice selected based on the S-NSSAI in a congested state” – See [¶0156]) and
for a plurality of interfaces of a network slice (“the NF may be a function apparatus such as an MME, an SGW, a PGW, a CPF, an AMF, an SMF, or a UPF, or may be a function such as Mobility Management (MM) or Session Management (SM), or capability information” – See [¶0054], whereby one NF “may have connectivity with another NF and may be connected to each apparatus via another NF” – See [¶0071] and “the NRF provides the NF with information of found NF instances or holds information of available NF instances or services supported by the instances” – See [¶0076]; then a NW slice has a plurality of interfaces as shown in Fig. 4, e.g., for “relaying NAS (N1) signaling between the UE and the AMF, processing N2 signaling transmitted from the SMF and relayed by the AMF” – See [¶0080] because each NW slice instance (NSI) “may be an aggregation including a plurality of NFs” – See [¶0131]; therefore the NSI includes the plurality of interfaces between the included NFs “generated using a Network Slice Template (NST)” – See [¶0131])
based on at least one condition related to the network slice (“the NW may transmit different values to the UE as cause values depending on whether the congestion control is the second congestion control or the third congestion control, or the first congestion control or the fourth congestion control” – See [¶0243], e.g., “the fourth congestion control” is directed to “the parameters of the DNN and the S-NSSAI and may be congestion control caused by connectivity to the DNN via a network slice selected based on the S-NSSAI in a congested state” – See [¶0156] or the UE’s “first PDU session is rejected because of a temporary cause,” e.g., one of the 5GMM PDU session rejection causes due to DNN or N-SSAI1)
wherein application of the congestion control process addresses the at least one condition related to the network slice (e.g., when “the NW may transmit different values to the UE as cause values depending on whether the congestion control is second congestion control or the fourth congestion control” – See [¶0244], “the fourth congestion control . . . may be congestion control to restrict all connections to the DNN via a network slice selected based on the S-NSSAI #A and may be congestion control to restrict a connection to the DNN #A in all types of connectivity” in case of UE requesting “connectivity to the DNN via a network slice selected based on the S-NSSAI in a congested state” – See [¶0156]; similarly, the “second congestion control . . . indicates control signal congestion control directed to parameters of S-NSSI . . . and the NW recognizes it as a UE initiated session management request directed only to the parameters of the S-NSSAI” and in “case that the second congestion control is applied . . . [it] may prevent the UE-initiated session management request directed only to the S-NSSAI” – See [¶0151]; i.e., “congestion control to restrict all connections to the DNN via a network slice selected based on the S-NSSAI” – See [¶0152] to relieve the congested condition of the NW slice); and
applying the congestion control process in a protocol stack for the plurality of interfaces of the network slice (the UE initiated “SM message may be an NAS message used in a procedure for session management and may be a control message transmitted and/or received between the UE_A 10 and the SMF A 230 via the AMF A 240” and “the SM message may include . . . a PDU session reject message” – See [¶00141]; i.e., the congestion control process applies to the protocol stack of NAS, and across the Nx interfaces between NFs, i.e., “it may be congestion control to restrict all connections to the DNN via a network slice selected based on the S-NSSAI #A” – See [¶0152] wherein the “[t]he SMF A 230 transmits a PDU session establishment reject message to the UE_A 10 via the AMF A 240 using the N11 interface, and the AMF A 240 that has received the PDU session establishment request message transmits the PDU session establishment reject message to the UE_A 10 using the N1 interface” – See [¶0314] whereby the SMF, AMF and NR access NFs may be part of the same NW slice/NSI, as explained supra; i.e., the congestion control is applied in a protocol stack for the plurality of interfaces of a NW slice comprising all the NFs necessary to connected to DN_A, as shown in Fig. 4)
wherein obtaining the recommendation comprises consulting a cognitive layer of the network to determine a best or improved congestion control process specific to the network slice (“the PCRF performs QoS management for a communication path between the UE_A 10, the DN_A 5” and “generate and/or manage a Policy and Charging Control (PCC) rule and/or a routing rule used by each apparatus to transmit and/or receive user data” – See [¶0058] based on context data from “a UDM FE (application front end) and a User Data Repository (UDR)” – See [¶0078]; then, in preparation for responding to each congestion control signal with a recommended congestion process, a “first timer may be configured to be associated with at least one of a congestion control unit which an NW applies,” wherein “the identification information indicating one or more NW slices” – See [¶0140], “to a back-off timer received from the NW . . . for a plurality of relevant NW slices based on information for identifying one NW slice . . . in units of back-off timers for preventing reconnection or a combination of an APN/DNN and one NW slice” – See [¶¶0141-42], and “rules configured in the UE_A 10 to collectively manage a plurality of back-off timers that have occurred in a plurality of PDU sessions . . . [e.g.,] in a case that conflicting or overlapping congestion control is applied” – See [¶0146], and “rules for associating information identifying a plurality of network slices. Note that the network slice association rules may be received [dynamically] in the PDU session reject message” – See [¶0145]; furthermore, the NW may change dynamically the parameters and type of congestion control process to be applied to a specific PDU session message by exchanging 21 types of indication information applicable to 15 described UE behaviors in case of congestion detected for UE initiated sessions – See [¶¶0158-73]).
Chiba does not explicitly teach a cognitive layer of the network that is configured to determine a best or improved congestion control process specific to the network slice. Ravichandran1 teaches that “[t]he resources and the services running on each slice need to be orchestrated, while all slices have to be orchestrated at the network level” – See I, ¶1:col2, at page 1, presenting “a case for effective orchestration of the CFs in a dynamic and contextaware manner taking into consideration service/slice SLAs, and KPIs, user mobility, service characteristics and dynamic network conditions, while complying with policy constraints” – See id., ¶1:col1, at page 2; i.e., using a cognitive layer to execute the logic in Fig. 3 for “[i]mpact-aware and context-aware determination of actions to resolve (predicted) fault or performance issues in a service or slice, considering impacts on other services and slices, and the affected common resources” – See II., ¶3:col2, at page 2, Fig. 1 showing a E2E Cognitive Function Orchestrator layer based on CFs distributed at slice level, and Fig. 3.
Thus, Ravichandran1 and Chiba each teaches slice level performance management. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the recommendations for the type of congestion control process and the indication information exchanged between the network and the UE when a congestion cause occurs at slice level could have been obtained from a cognitive layer orchestrating CFs distributed at slice level to determine a best or improved congestion control process specific to the network slice, as taught in Ravichandran1, because a congestion control process is a type of slice level performance management. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination through techniques known in the art because Chiba teaches means to expose NFs according to 3GPP standards – See [¶0075]. Finally, the combination the predictable result of dynamically assessing the impact of congestion control actions on a service/slice on other services and slices and perform self-adaptation for improvement, as taught by Ravichandran1.
Therefore, Amended Claim 1 is obvious over Chiba in view of Ravichandran1.
Regarding Claim 2, dependent from Amended Claim 1, Chiba does not teach the method of Claim 1, wherein the network node comprises a machine learning model, and wherein the machine learning model comprises an unsupervised machine learning model. However, Ravichandran1 teaches the network node comprises a machine learning model (“Cognitive functions and analytics engines are now seen as an integral part of management and orchestration . . . employing one or more of artificial intelligence, machine learning or deep learning techniques to address an issue – its output could be prediction, recommendation, root cause determination, resolution or a combination of these” – See I., ¶2:col1, at page 1, and “the CFs are activated at the appropriate place in the network in a context-aware manner, taking into consideration aspects such as user mobility, session type, Key Performance Indicators (KPIs), SLAs, dynamic network conditions, location of the users involved in the session” – See id., ¶3:col2, at page 1 and Fig. 1 showing CF deployed in NFs at slice level, wherein, e.g., “a CF performing log analysis to determine the root cause may comprise of NLP to examine the event logs, employ machine learning (ML) techniques on the performance metrics and decoded event logs” – See III., ¶8:col2, at page 2, whereby machine learning (ML) techniques include using ML models.
Although Ravichandran1 does not explicitly teach wherein the machine learning model comprises an unsupervised machine learning model, Ravichandran1 references “Ayoubi et al [2]” as related work – See II., ¶1:col.1, at page 2, whereby Ayoubi et al, “Machine Learning for Cognitive Network Management”, IEEE Communications Magazine, Jan. 2018, pp 150-165, (hereinafter Ayoubi) teaches that an unsupervised ML technique “uses unlabeled training datasets to create models that find dominating structure or patterns in the data . . . appropriate for clustering, outliers detection, and density estimation problems,” specifically, “k-nearest neighbors (k-NN), decision trees (DTs), and neural networks (NNs) have been used in both supervised and unsupervised learning. k-means operates only in unsupervised learning” – See Ayoubi, ¶1,¶3 :col2, at page 159 and Table 1 (showing unsupervised ML techniques used for fault management, and a person of ordinary skills in the art would recognize that using the cause value related to the N-SSAI congestion in a congestion control process, as taught in Chiba, may be an example of ML unsupervised model driven fault management).
Therefore, Claim 2 is obvious over Chiba in view of Ravichandran1.
Regarding Claim 4, dependent from Claim 1, Chiba further teaches wherein the at least one condition related to the network slice comprises at least one of a specification of the network slice, a status of the network, a traffic flow in other network slices, and a topology of the network (“the UE_A 10, an apparatus in the access network, and/or an apparatus in the core network, and an apparatus in a data network may associate one or more pieces of identification information with the PDU session for management,” such as a SM reject message, wherein “these pieces of identification information may include . . . a Traffic Flow Template (TFT) . . . identification information of the DN_A 5 [e.g., associated with topology], Network Slice Instance (NSI) identification information [e.g., associated with slice specification], Dedicated Core Network (DCN) identification information, or access network identification information [e.g., associated with topology]; in addition, “a cause value may be information for identifying a congestion control among the congestion controls from the first congestion control to the fourth congestion control the congestion control that the NW notifies the UE indicates based on the rejection of the PDU session establishment” – See [¶0238], wherein the cause value is associated with a congested condition of the DNN and/or the S-NSSAI, as disclosed in 3GPP 24.501:208-209).
Therefore, Claim 4 is obvious over Chiba in view of Ravichandran1.
Regarding Amended Claim 7, dependent from Amended Claim 1, Chiba further teaches extracting the at least one condition related to the network slice, wherein the extracting comprises obtaining the at least one condition from at least one of a network slice request and a network knowledge database (“for each congestion control from the first congestion control to the fourth congestion control, the NW may transmit a different value to the UE as a cause value” and “[t]he UE may interpret each value transmitted as a cause value in advance” – See [¶0239], e.g., the network “UDR stores data necessary for the UDM FE for provision and policy profiles necessary for the PCF” – See [¶0078], and cause values associated with DNN and S-NSSAI congestion are, e.g., cause #22, 67, or 69 as defined in 3GPP TS 24.501:209)
Therefore, Amended Claim 7 is obvious over Chiba in view of Ravichandran1.
Regarding Claim 8, dependent from Amended Claim 7, Chiba further teaches obtaining a network topology of a network slice instance for the network slice request2 (“Network Slice Instance (NSI) . . . is an entity of each of one or a plurality of Network Slices configured in the core network_B 190” which “may include a virtual Network Function (NF) generated using a Network Slice Template (NST) . . . associated with a resource request for providing a required communication service or capability, and is a logical expression of one or a plurality of Network Functions (NFs),” i.e., “an aggregation including a plurality of NFs in the core network_B 190” and “[t]he UE_A 10 . . . can be allocated to one or a plurality of network slices, based on NSSAI and/or S-NSSAI” – See [¶0131], i.e., based on “information indicating an operation of network slices expected in terms of function and service” – See [¶0132] such as connectivity to DN_A as shown in Fig. 4),
wherein the network topology comprises a plurality of network functions and a plurality of links between the plurality of network functions (“core network_B may include at least one of an Authentication Server Function (AUSF), an Access and Mobility Management Function (AMF)_A 240, an Unstructured Data Storage Network Function (UDSF), a Network Exposure Function (NEF), an Network Repository Function (NRF), a Policy Control Function (PCF), a Session Management Function (SMF)_A 230, a Unified Data Management (UDM), a User Plane Function (UPF)_A 235, an Application Function (AF), or a Non-3GPP InterWorking Function (N3IWF)” which “may also be configured as Network Functions (NFs)” – See [¶0063] in a topology containing a plurality of links between the plurality of network functions because the Network Slice Template (NST) “is associated with a resource request for providing a required communication service or capability, and is a logical expression of one or a plurality of Network Functions (NFs)” – See [¶0131] and as shown, e.g., in Fig. 4)
Therefore, Claim 8 is obvious over Chiba in view of Ravichandran1.
. Regarding Amended Claim 9, dependent from Amended Claim 7, Chiba further teaches determining the plurality of interfaces included in the network slice instance, e.g., based on the access/core NFs3 included in the NSI used by “the UE_A 10 [to] transmit and/or receive the user data to and/or from an apparatus, such as an application server that is deployed in the DN_A 5 by using a PDU session” – See [¶0031], Fig. 1 and Figs. 3 and 4, distinguishing NFs and interfaces for UTRAN/E-UTRAN access to network B (Fig. 3) and for NR access to network A (Fig. 4 and [¶0064]).
Therefore, Amended Claim 9 is obvious over Chiba in view of Ravichandran1.
Regarding Claim 10, dependent from Amended Claim 9, Chiba further teaches wherein the plurality of interfaces comprises interfaces in a user plane or in a control plane of the network (Fig. 4 shows a plurality of interfaces to NFs such as a “User Plane Function (UPF)_A 235” and an “AMF A 240 which may also be a Common Control Plane Network Function (Common CPNF, or CCNF)” – See [¶0067], also noting that “a User Plane (U-Plane or UP) may be a communication path for transmitting and/or receiving user data” and “a Control Plane (C-Plane or CP) may be a communication path for transmitting and/or receiving a control message” – See [¶0046]).
Therefore, Claim 10 is obvious over Chiba in view of Ravichandran1.
Regarding Claim 12, dependent from Claim 8, Chiba further teaches wherein the applying the congestion control process for a plurality of interfaces of a network slice comprises applying the congestion control process in the plurality of network functions (e.g., “[t]he second congestion control . . . indicates control signal congestion control directed to parameters of S-NSSI. For example, in a case that control signal congestion with respect to S-NSSAI #A is detected on an NW and the NW recognizes it as a UE initiated session management request directed only to the parameters of the S-NSSAI #A, the NW may apply the second congestion control” – See [¶0151] and “the second congestion control may be congestion control to restrict all connections based on the S-NSSAI #A” – See [¶0152]; then, when “the UE_A 10 may include . . . identification information . . . in the PDU session establishment request message and transmit them to request establishment of a PDU session belonging to a network slice, to indicate a network slice to which the PDU session belongs requested by the UE_A 10, or to indicate a network slice to which the PDU session is to belong” – See [¶0291] “[t]he SMF A 230 within the core network_B 190 receives the PDU session establishment request message and performs the third condition determination . . . to determine whether the SMF A 230 accepts a request of the UE_A 10” – See [¶0295] and “the SMF A 230 transmits the PDU session establishment reject message to the AMF A 240 using the N11 interface, and the AMF A 240 that has received the PDU session establishment request message transmits the PDU session establishment reject message to the UE_A 10 using the N1 interface” – See [¶0314] indicating that “a request to establish a PDU session belonging to a network slice has been rejected or indicate a network slice that is not allowed to belong to the PDU session” – See [¶0317]; i.e., the second congestion control process is applied in the plurality of network functions, e.g. SMF and AMF).
Therefore, Claim 12 is obvious over Chiba in view of Ravichandran1.
Regarding Amended Claims 14 and 15, Chiba teaches a network node for dynamic congestion control for network slices,
wherein the network node may comprise: at least one processor; at least one memory connected to the at least one processor and storing program code that is executed by the at least one processor to perform operations (e.g., Figs. 7 and 8 show an AMF and a SMF comprising network connection unit and the storage unit which are connected to a controller via a bus whereby, for an AMF, the storage unit stores a context and stores programs, data, and the like necessary for each operation of the node – See [¶¶0091,0094,0095])
further comprising execution of the steps of Amended Claims 1 and 2, respectively, recited with the same language, only from the perspective of the network node. Because the network node determines what type of congestion control process is applied, as explained in Regarding Amended Claim 1, supra, Amended Claims 14 and 15 are obvious over Chiba in view of Ravichandran1.
Regarding Amended Claim 18, Chiba also teaches a computer program comprising program code to be executed by processing circuitry of a network node (“A program running on an apparatus according to the present invention may serve as a program that controls a Central Processing Unit (CPU) and the like to cause a computer to operate in such a manner as to implement the functions of the above-described embodiment according to the present invention. Programs or information handled by the programs are temporarily stored in a volatile memory such as a Random Access Memory (RAM), a non-volatile memory such as a flash memory, a Hard Disk Drive (HDD), or another storage device system” – See [¶0370]), whereby execution of the program code causes the network node to perform operations comprising the steps of Amended Claim 1, which is obvious over Chiba in view of Ravichandran1.
Therefore, Claim 18 is obvious over Chiba in view of Ravichandran1.
Regarding Amended Claim 19, dependent from Amended Claim 18, it merely recites the steps of Amended Claim 18 wherein the network node is limited by the same features as recited in Amended Claim 2. Because Amended Claims 2 and 18 are obvious over Chiba in view of Ravichandran1, Claim 19 is also obvious over Chiba in view of Ravichandran1.
Regarding Amended Claim 20, Chiba teaches a computer program product comprising a non-transitory storage medium including program code to be executed by processing circuitry of a network node (“a program for implementing such functions of the embodiment according to the present invention may be recorded on a computer-readable recording medium,” i.e., a product – See [¶0371]) whereby execution of the program code causes the network node to perform operations comprising the steps of Amended Claim 1. Because Amended Claim 1 is obvious over Chiba in view of Ravichandran1, Amended Claim 20 is also obvious over Chiba in view of Ravichandran1.
Regarding Claim 22, dependent from Amended Claim 1, Chiba further teaches the method of claim 1 comprising:
obtaining a plurality of recommendations (the UE may obtain “priority management rules for back-off timers in a case that a plurality of different congestion controls are activated for one or a plurality of PDU session establishments by the same UE and a plurality of timers are provided from the network,” e.g., when “the first PDU session establishment request for a combination of a DNN_l and a slice_l by the UE is subjected to congestion control based on both a DNN and slice information, and the UE receives a first timer #1” and “the UE makes a second PDU session establishment request for a combination of the DNN_l and a slice_2, is subjected to congestion control based solely on the DNN, and receives a first timer #2. At this time, the UE may manage a behavior of PDU session re-establishment of the UE using the dominant first timer #2, based on the priority management rules for the back-off timers” – See [¶0171], i.e., the network recommends the back-off timer values and the priority management rules in case of DNN and/or slice congestion condition)
for a plurality of congestion control processes (“performing, by the UE_A 10, first identification process to identify which type of congestion control to apply among the congestion controls from the first congestion control to the fourth congestion control and second identification process to identify the DNN and/or the S-NSSAI associated with the congestion control to be applied” – See [¶0173], i.e., the network recommendations are for each one of the congestion control processes because each one applies at least to the DNN and/or the slice accessed in the PDU session message – See [¶0172] (“managing a timer for each session management instance (on a per PDU session basis) in a case that a plurality of different congestion controls are applied to one or a plurality of PDU session establishments by the same UE and a plurality of timers are provided from the network”))
for a plurality of interfaces of a plurality of network slices based on at least one condition related to the respective network slice (when to one or a plurality of PDU session establishments by the same UE request access to DNN_1 through slice_l and slice_2, “the UE_A 10 transmits the PDU session establishment request message to the AMF A 240 in the core network_B 190 via the NR node_A 122 using the Nl interface” and “[t]he AMF A receives the PDU session establishment request message and performs third condition determination” – See [¶0287], whereby if the condition is false, “the SMF A 230 transmits the PDU session establishment reject message to the AMF A 240 using the N11 interface, and the AMF A 240 that has received the PDU session establishment request message transmits the PDU session establishment reject message to the UE_A 10 using the N1” – See [¶0314], and “the third condition determination may be [false] in a case that the network determines that the network is congested” – See [¶0283], e.g., when each of slice_1 and slice_2 of the one DNN are congested, and at least the AMF, the SMF and the RAN NFs in each slice, as shown in Fig. 4, interact through the N1, N2, and N11 interfaces to send a PDU session reject message to the UE based on the congestion condition value cause #69 of the respective network slice, e.g. using indication information 16th and 17th, infra, whereby , congestion condition value cause #69 is obtained when “the AMF shall send back to the UE . . . a back-off timer value and 5GMM cause #69 ‘insufficient resources for specific slice’ as specified in subclause 5.4.5.3.1 case f “ – See § 5.4.5.2.4, 3GPP TS 24.501:209, as explained supra;) and
applying a network-slice specific congestion control process in a protocol stack for the plurality of interfaces of the respective network slice (“the UE_A 10 performs a fourth process based on the reception of the PDU session establishment reject message” – See [¶0328], i.e., “recognizing, by the UE_A 10, the matter indicated by the SMF A 230. Furthermore, the fourth process may be a process of storing, by the UE_A 10, the received identification information as a context” – See [¶0340] and “identify which type of congestion control to be applied among the congestion controls from the first congestion control to the fourth congestion control and to identify the DNN and/or the S-NSSAI associated with the congested management to be applied based on one or more pieces of identification information” – See [¶0342]; e.g., “In the first identification process, the type of congestion control to apply in a case that any one or two or more combinations of the following cases are met may be identified as second congestion control,” including 14th to 17th identification information – See [¶¶0183-190]; whereby, e.g., the “16th identification information . . . is one or more pieces of Indication information indicating that the present procedure has been rejected” and “[t]he NW may indicate congestion control applied by the NW based on the 16th identification information” – See [¶0247] and the “17th identification information . . . is one or more pieces of Value information indicating that the present procedure has been rejected” – See [¶0252]; and “the second identification process may be a process of identifying a corresponding DNN and/or S-NSSAI for a type of congestion control identified in the first identification process” – See [¶0213], e.g., “an S-NSSAI corresponding to the second congestion control, . . . may be determined based on the 17th identification information” – See [¶0216], therefore “each apparatus may perform processing based on identification information transmitted and/or received in the present procedure based on the completion of the present procedure” – See [¶0350], i.e., “[t]he transmission and/or reception of the PDU session reject message in the above-described procedure causes the core network_B 190 to notify the UE_A 10 of congestion control to be applied, and the UE_A 10 can apply the congestion control indicated by the core network_B 190” – See [¶0354] and Fig. 11).
Furthermore, Ravichandran1 teaches that applying a network-slice specific congestion control process in a protocol stack for the plurality of interfaces of the respective network slice can be done through “[i]mpact-aware and context-aware determination of actions” as shown in Fig. 3.
Therefore, Claim 22 is obvious over Chiba in view of Ravichandran1.
In sum, Claims 1-2, 4, 7-10, 12, 14-15, 18-22, as amended, are rejected under 35 U.S.C. 103 as obvious over Chiba in view of Ravichandran1.
Claims 3, 5-6, and 11, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Chiba in view of Ravichandran1 as applied to Claims 1, 2, and 7, as amended, above, and further in view of Ravichandran et al., U.S. Patent Application No. 2020/0186411 (hereinafter Ravichandran2).
Regarding Claim 3, dependent from Claim 2, Chiba in view of Ravichandran1 further teaches wherein the cognitive layer comprises declarative and statistical knowledge encapsulated in the cognitive layer describing a plurality of congestion control processes (the “Performance monitoring module (PERF-MON)” of the Cognitive Function Orchestrator “collects relevant inputs about the status and performance of the NEs hosting the CFs” including statistical knowledge such as “analysis latency, latency to obtain the results, resource occupancy levels, etc.” – See Ravichandran1, III., ¶2:col2, at page 3, as well as declarative knowledge, e.g., the triggers for preventive/corrective actions include “[c]ongestion in network segment(s) hosting the CF; Change in a service or slice characteristics; Change in policy” – See id., IV.A., ¶1:col2, at page 4, and this knowledge can improve on Chiba’s slice level congestion control processes through techniques known in the art).
Ravichandran1 further teaches that “[t]he CF-O may obtain relevant performance metrics either directly from the NEs hosting the CFs, through the SO, I-SLO and/or from nodes delegated by them, depending on network topology and policy constraints” – See III.A.,¶2:col1, at page 3, and by reference information extracted from a plurality of metrics of an operating process (e.g., the Ayoubi reference discloses in Figs. 2-4, an improved MAPE model with a cognitive control loop in each of the FCAPS network management functions can retrieve data from and/or log created knowledge to the knowledge source). However, Chiba in view of Ravichandran1 does not explicitly teach wherein the statistical knowledge comprises information extracted from a plurality of metrics of an operating congestion control process from the plurality of congestion control processes.
Ravichandran2 teaches a communication network wherein “[e]ach of the E2E network slices 107 may be composed of one or more network slice subnets 106 across network segments 101 that may be 'stitched' together (i.e., communicatively interconnected to each other)” and “interconnections among network slice subnets 106 may be based on one or more standard protocols (e.g., transmission control protocol/Internet protocol (TCP/IP), general packet radio service tunneling protocol (GTP), etc.) and/or other proprietary protocols” – See [¶0028], and wherein a network node comprises at least one of a cognitive layer and a machine learning model (“cognitive functions (CFs) 108 in the communication network 100” – See [¶0021] and Fig. 1C; wherein “[o]ne or more CFs 108 may be employed at some of the nodes ( e.g., network elements 105, domain orchestration device 102, etc.) of the communication network 100 . . . the CFs 108 may be part of an existing node, or may be a plug-in on top of an existing node . . . may be custom built for a particular network slice subnet, or may be common across network slice subnets (i.e., may be slice agnostic)” and “the scope or coverage (for data collection and analysis) of the CFs 108 in the network subnets may be at node level” – See [¶0029]) and the communication network includes an end-to-end cognitive orchestration (E2ECO) device that “may perform orchestration of cognitive functions (CFs) 108 in the communication network 100” – See [¶0021] and Fig. 1C.
Ravichandran2 further teaches wherein the declarative knowledge comprises knowledge encapsulated in the cognitive layer describing a plurality of congestion control processes (“The FPPM 209 may . . . predict/detect fault or performance issue in one or more service(s)/slice(s) using pre-provisioned inputs (PPP-RULES) that may be adapted by the EAAM 205 (ADAPT-PPP-RULES)” – See [¶¶0088-89]; and “FPIRM 210 may . . . determine possible resolutions for the determined root cause using ADAPTED-RES-RULES” – See [¶¶0094-95] whereby the rules are declarative knowledge encapsulated in the cognitive layer associated with a plurality of congestion control processes as described in Figs. 4, 5A and 5B) and
wherein the statistical knowledge comprises information extracted from a plurality of metrics of an operating congestion control process from the plurality of congestion control processes (“The MONIM 207 may be responsible for collecting the fault, performance, and event data from various NEs, as well as actual SLA/KPI trends, resource occupancy trends, etc.” and “may store the collected information in the CDB 211” and “in conjunction with FIGS. 5A and 5B, the MONIM 207 may perform pre-processing of the data using preprovisioned rules, and then may passes the information to the FPPM 209” – See [¶0086], Fig. 2, and Figs. 5A/B describing fault/performance management processes which may be congestion control processes following NW slice activation).
Thus, Ravichandran2 and Chiba in view of Ravichandran1 each teaches end-to-end slice level performance management processes including congestion control using statistical and declarative knowledge collected by CFs at node/slice level. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the functions of extracting a plurality of metrics of an operating process and applying knowledge encapsulated in the cognitive layer describing a plurality of rules applicable to an operating process, such as Fault and Performance management at slice level, further managed in the E2ECO device/cognitive layer described by Ravichandran2, could have been substituted in for the recommendation from the network for one of a congestion control process and associated indication information, as taught by Chiba in view of Ravichandran1, because in both cases the objective of the managed functions is to provide for detecting and solving congestion/performance degradation at network slice level. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution through techniques known in the art. Finally, the substitution achieves the predictable result of maintaining SLAs through dynamic detection, analysis, and appropriate resolution of a performance degradation using rules and metrics at NF level collected by CFs as taught by Ravichandran2, while maintaining compliance with 3GPP TS 24.501 DNN/NSSAI related cause values, as taught by Chiba.
Therefore, Claim 3 is obvious over Chiba in view of Ravichandran1 and further in view of Ravichandran2.
Regarding Claim 5, depending from Amended Claim 2, Chiba in view of Ravichandran1 discloses by reference to Ayouba that ML models obtained by unsupervised training are used in fault localization and prediction as traffic load and metrics prediction – See Table 1, Ayouba, at page 160.
Ravichandran2 further teaches wherein the obtaining comprises processing inputs to the cognitive layer to obtain an output from the cognitive layer comprising the recommendation for the congestion control process (“the control logic 400 may include the step of determining a fault or a performance, issue and one or more associated causes, related to a set of network slices in the communication network 100” and “determining one or more possible resolutions for the fault or the performance issue based on the one or more associated causes” – See [¶0104] by “aggregating a set of events or a set of performance trends over a pre-defined period of time, and determining the fault or the performance issue and the one or more associated causes by evaluating the set of events or the set of performance trends” i.e., by processing inputs – See [¶0108] and “identifying a possible resolution with a high suitability and at least one of a low impact on or a low conflict with the set of services, the set of other services, the set of network slices, or the set of other network slices,” i.e., obtaining an output recommendation – See [¶0109])
wherein the inputs comprise at least one key performance indicator, KPI, associated with the at least one condition related to the network slice (“upon activating the service or the network slice, determining a set of parameters to be monitored to compute the set of KPI's” – See [¶0105] and further “comparing a set of actual KPI's with a set of corresponding target KPI's for the set of services or the set of network slices” – See [¶0107], specifically ”collect data on the ACTUAL-SLA-KPIs (and associated trends) of various services and slices” to “detect fault/performance issue(s) in one or more services/ slices, using pre-provisioned inputs which were then adapted . . . based on learning” – See [¶¶0174-75], i.e., at least one KPI is associated with at least one condition/issue in a network slice)
Therefore, Claim 5 is obvious over Chiba in view of Ravichandran1 and further in view of Ravichandran2.
Regarding Claim 6, dependent from Amended Claim 1, Chiba in view of Ravichandran1 teaches wherein the applying the congestion control process in a protocol stack for the plurality of interfaces of the network slice, as explained in Regarding Amended Claim 1, supra. Chiba further teaches application of the congestion control process to a traffic flow (“an apparatus in the. . . network . . . may associate one or more pieces of identification information with the PDU session for management” which “may include . . . Traffic Flow Template (TFT)” and the “Network Slice Instance (NSI) identification information” – See [¶0031] and a “first timer may be configured to be associated with at least one of a congestion control unit which an NW applies” on “a per identification information basis,” i.e., may be based on the indicated traffic flow in the identification information).
Ravichandran2 further teaches application of the congestion control process to a traffic flow through the plurality of interfaces using a transport protocol (on the one hand, as shown in Fig. 1C, “[t]he interconnections among network slice subnets 106 may be based on one or more standard protocols (e.g., transmission control protocol/Internet protocol (TCP/IP), general packet radio service tunneling protocol (GTP), etc.) and/or other proprietary protocols” – See [¶0028], and, on the other hand, EXT interfaces are used for the orchestration of CFs to perform service/slice level performance at the cognitive layer, as shown in Fig. 1A, wherein “interface EXT1 may employ any standard protocol (e.g., http, REST, SNMP, etc.) . . . EXT2 interface (or each of the interfaces EXT21, EXT22 ... EXT2m) may employ any standard protocol (e.g., http, REST, SNMP, netconf/yang, etc.) . . . interface EXT3 (or each of the interfaces EXT31, EXT32 ... EXT3m) may employ any standard protocol (e.g., REST/RESTCONF, netconf/yang, etc.) . . . interfaces EXT41, EXT42 ... EXT4m may employ any standard protocol (e.g., SNMP, netconf/yang, openflow, REST etc.) or any other proprietary protocol,” i.e., using application level transport protocols – See [¶0025]).
Therefore, Claim 6 is obvious over Chiba in view of Ravichandran1 and further in view of Ravichandran2.
Regarding Amended Claim 11, dependent from Amended Claim 7, the method in Chiba in view of Ravichandran1 teaches normalizing and transforming the at least one condition into the at least one KPI (e.g., Chiba teaches a cause value representing the network congestion condition, as explained in Regarding Amended Claim 7, supra, and Ravichandran1 teaches that “root cause identification can be split into event log analysis, relevant KPI(s) trend analysis, resource occupancy trend analysis, reasoning (e.g., using decision tree or deep learning techniques)”– See III.B., ¶3:col.1, at page 3).
However, Chiba in view of Ravichandran1 does not teach the mapping between the KPI trend analysis and the condition.
Ravichandran2 further teaches monitoring the at least one condition related to the network slice (“high-level intent (HLI)” may drive “operating the network at high reliability (say, five 9's) while adhering to service level agreement (SLA) or key performance indicator (KPI) values of the service or the slice” – See [¶0035] and requires “parameters and events to monitor for a slice along with conditions (active slices, geo location, class of users, etc.)” which “may be provisioned at the time of slice creation[/instantiation]” – See [¶¶0047-48] and further “extract[ing] relevant information from the information reported by the CFs and various NEs in the network (including alarms, events, service/slice SLA/KPI trends, etc.)” – See [¶0174]),
wherein the extracting comprises normalizing and transforming the at least one condition into the at least one KPI (“the PPM 201 may be responsible for determining the parameters to be monitored (MO-PAR) so as to determine the performance levels of the nodes, services and slices, and to determine conformance to the HLI” – See [¶0062] and Fig. 2, including “mapping of events/parameters to be monitored and analyzed to the corresponding cognitive analysis type required” e.g., “latency KPI may require regression along with deep learning, congestion monitoring may require decision tree analysis” – See [¶0051], and “may process the current value of HLI . . . for triggering preventive actions” based on, e.g., “KPI thresholds (target vs actual)” – See [¶0114], therefore normalizing and transforming the current condition into at least one KPI).
Therefore, Amended Claim 11 is obvious over Chiba in view of Ravichandran1 and further in view of Ravichandran2.
In sum, Claims 3, 5-6, and 11, as amended, are rejected under 35 U.S.C. 103 as obvious over Chiba in view of Ravichandran1 and further in view of Ravichandran2.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Cheng et al., U.S. Patent Application No. 2016/0044530 discloses a congestion management method with congestion mitigation process;
Seetharaman et al., U.S. Patent Application No. 2022/0021590 discloses method and apparatus for determining a network slice template hierarchy based on the updated service requirement set;
Sciancalepore et al., U.S. Patent Application No. 2020/0059521 discloses slice management in 5G IoT;
Rath et al., U.S. Patent Application No. 2020/0084279 discloses enabling network aware applications and applications aware networks by a sense analyze decide respond (SADR) framework using machine learning techniques to analyze network state;
Dao et al., U.S. Patent Application No. 2021/0235288 discloses policy optimization in a communication network using network data analytics (NWDA) function on network traffic to obtain network performance measurement data, receive the measurement data from the network elements, and transmit a policy input based on the received measurement data;
Lau et al., U.S. Patent Application No. 2019/0168696 discloses dynamic wireless configuration of a vehicle via a network slice to facilitate improved subscriber experiences;
Sudarsan et al., U.S. Patent Application No. 2020/0267596 disclosing congestion control in wireless network and performing one or more action to mitigate or remove the cause of the congestion or degradation;
Kucera et al., U.S. Patent Application No. 2021/0084523 disclosing controlling transmission of a data flow in a communication network, comprising defining a quality of service setting for at least one data flow and associating at least one network slice to the at least one data flow to be transmitted;
3GPP TS 23.502 V16.6.0 (2020-09),”Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 16)”;
3GPP TS 28.531 V16.7.0 (2020-09), “Technical Specification Group Services and System Aspects; Management and orchestration; Provisioning; (Release 16)”;
3GPP TS 24.501 V16.6.0 (2020-09), “Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3; (Release 16)”;
Vasilakos et al., “Integrated Methodology to Cognitive Network & Slice Management in Virtualized 5G Networks,” May 2020, available at https://arxiv.org/abs/2005.04830;
Bin et al., “Machine Learning for Network Slicing Resource Management: A Comprehensive Survey,” arXiv, January 20, 2020, to appear in ZTE Communications, 2020, available at https://arxiv.org/pdf/2001.07974.
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 LUCIA GHEORGHE GRADINARIU whose telephone number is (571)272-1377. The examiner can normally be reached Monday-Friday 9:00am - 5:00pm 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.
/L.G.G./Examiner, Art Unit 2478
/JOSEPH E AVELLINO/Supervisory Patent Examiner, Art Unit 2478
1 See 3GPP TS 24.501 V16.6.0 (2020-09), “Technical Specification Group Core Network and Terminals;
Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3; (Release 16)” (hereinafter 3GPP TS 24.501) teaching in § 5.4.5.2.4 that “if the Request type IE is set to ‘initial request’ or ‘existing PDU session’” and “ S-NSSAI only based congestion control is activated for the S-NSSAI” then “the AMF shall send back to the UE the 5GSM message which was not forwarded, a back-off timer value and 5GMM cause #69 ‘insufficient resources for specific slice’” – See 3GPP TS 24.501:208-209
2 A person of ordinary skills in the art would look at 3GPP TS 28.530 V16.3.0 (2020-09), “Technical Specification Group Services and System Aspects; Management and orchestration; Concepts, use cases and requirements (Release 16)” (hereinafter 3GPP TS 28.530) for details of using network slicing in response to request for a service – See, e.g., Figure 4.1.3.1, Figure 4.1.6.1 and Figure 4.4.1.1.
3 A person of ordinary skills in the art would also consult 3GPP TS 23.501 V16.6.0 (2020-09), “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16)” (hereinafter 3GPP TS 23.501), referenced by Chiba, e.g., Figure 4.2.3-1.
Prosecution Insights