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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 7/22/2026 has been entered. Claims 1- 20 have been examined.
Response to Arguments
Applicant’s arguments with respect to claims 1,9,17 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3,5,9-11,13,17-20 are rejected under 35 U.S.C. 102 (a1) as being anticipated by Cisco et al “ Ultra Cloud Core 5G Session Management Function , Release 2023.04- Configuration and Administration Guide – Chapter – Interfaces Support” – Published – 10-17-2023 (Cisco hereinafter).
Regarding claim 1
Cisco teaches a method of dynamic switching of network function (NF) communication models in a cellular network, the method comprising:
receiving, by a first NF, from a service communication proxy (SCP), a failure message during the first NF running in an indirect communication model, wherein the failure message comprises an error response generated by the SCP and indicates a failure of the SCP, and wherein, in the indirect communication model, the first NF and a second NF of a set of second NFs communicate through the SCP (Section - Indirect Communication for NFs through SCP model D - SMF performs indirect communication for network functions (NFs) through Model D. By default, SMF performs the NRF discovery to select the NF peer, With the SCP Model D support, the SMF send requests to SCP endpoints. SCP performs the NRF discovery and finds the correct peer NF- On receiving an error response, SMF as a client, extracts the NF Type from the "Server" header and triggers the SCP failure handling -Section - SCP Model-D fall back - SCP triggers an error, with the "Server" header indicating "scp") ;
responsive to receiving the failure message, switching, by the first NF, from running in the indirect communication model to running in a direct communication model, wherein, in the direct communication model, the first NF and the second NF of the set of second NFs communicate without the SCP, running the first NF in the direct communication model (Section Indirect Communication for NFs through SCP model D - On receiving an error response, SMF as a client, extracts the NF Type from the "Server" header and triggers the SCP failure handling -Section - SCP Model-D fall back - the SMF does a fallback from model-D to model-A in the following scenarios: • SCP triggers an error, with the "Server" header indicating "scp" and The "retry-and-fallback" action is configured - After a fallback, the subsequent messages for the same resource use the peer selected as part of fallback. For example, in case a fallback to SCP Model A happens during N10 registration Section - SCP Interface In Model A, there is a direct communication without the NRF interaction. No NRF or SCP is used. The consumers are configured with the producer NF profiles and directly communicate with the producer of their choice).
Regarding claim 2
Cisco further teaches
wherein switching from running in the indirect communication model to running in the direct communication model further comprises modifying a configuration setting in the first NF (Section SCP Model -D fallback - If you have configured the SCP failure handling with the "retry" action, then SMF attempts an alternate SCP based on SCP configuration and the retry count configuration. After completion of the configured retry counts or unavailability of any alternate SCPs for retrying, the SMF does a fallback from model-D to model-A in the following scenarios: • SCP triggers an error, with the "Server" header indicating "scp". • The "retry-and-fallback" action is configured – See Also Section – Configuring SCP model D fallback.)
Regarding claim 3
Cisco further teaches
wherein, in the indirect communication model, the SCP communicates with a network repository function (NRF) for discovery of the set of second NFs, and the SCP selects the second NF from the set of second NFs (Section – Indirect Communication for NFs through SCP Model D - SMF performs indirect communication for network functions (NFs) through Model D. By default, SMF performs the NRF discovery to select the NF peer, - Section How it Works - With the SCP Model D support, the SMF send requests to SCP endpoints. SCP performs the NRF discovery and finds the correct peer NF and sends the request to the NF).
Regarding claim 5
Cisco further teaches
wherein, in the direct communication model, the first NF communicates with a network repository function (NRF) for discovery of the set of second NFs, and the first NF selects the second NF from the set of second NFs (Section – SCP Interface - In Model B, there is a direct communication with the NRF interaction. Consumers performs discovery by querying the NRF. Based on the discovery result, the consumer does the selection. The consumer sends the request to the selected producer).
Regarding claim 9
Cisco teaches a computing system to facilitate a cellular network, the computing system comprising:
one or more processing devices; and memory communicatively coupled with and readable by the one or more processing devices and having stored therein processor-readable instructions which, when executed by the one or more processing devices, cause the one or more processing devices to perform operations comprising receiving, by a first NF, from a service communication proxy (SCP), a failure message during the first NF running in an indirect communication model, wherein the failure message comprises an error response generated by the SCP and indicates a failure of the SCP, and wherein, in the indirect communication model, the first NF and a second NF of a set of second NFs communicate through the SCP (Section Indirect Communication for NFs through SCP model D - SMF performs indirect communication for network functions (NFs) through Model D. By default, SMF performs the NRF discovery to select the NF peer, With the SCP Model D support, the SMF send requests to SCP endpoints. SCP performs the NRF discovery and finds the correct peer NF- On receiving an error response, SMF as a client, extracts the NF Type from the "Server" header and triggers the SCP failure handling -Section - SCP Model-D fall back - SCP triggers an error, with the "Server" header indicating "scp") ;
responsive to receiving the failure message, switching, by the first NF, from running in the indirect communication model to running in a direct communication model, wherein, in the direct communication model, the first NF and the second NF of the set of second NFs communicate without the SCP, running the first NF in the direct communication model (Section Indirect Communication for NFs through SCP model D - On receiving an error response, SMF as a client, extracts the NF Type from the "Server" header and triggers the SCP failure handling -Section - SCP Model-D fall back - the SMF does a fallback from model-D to model-A in the following scenarios: • SCP triggers an error, with the "Server" header indicating "scp" and The "retry-and-fallback" action is configured - After a fallback, the subsequent messages for the same resource use the peer selected as part of fallback. For example, in case a fallback to SCP Model A happens during N10 registration Section - SCP Interface In Model A, there is a direct communication without the NRF interaction. No NRF or SCP is used. The consumers are configured with the producer NF profiles and directly communicate with the producer of their choice).
Regarding claim 10
Cisco further teaches
wherein switching from running in the indirect communication model to running in the direct communication model further comprises modifying a configuration setting in the first NF ((Section SCP Model -D fallback - If you have configured the SCP failure handling with the "retry" action, then SMF attempts an alternate SCP based on SCP configuration and the retry count configuration. After completion of the configured retry counts or unavailability of any alternate SCPs for retrying, the SMF does a fallback from model-D to model-A in the following scenarios: • SCP triggers an error, with the "Server" header indicating "scp". • The "retry-and-fallback" action is configured – See Also Section – Configuring SCP model D fallback.)
Regarding claim 11
Cisco further teaches
wherein, in the indirect communication model, the SCP communicates with a network repository function (NRF) for discovery of the set of second NFs, and the SCP selects the second NF from the set of second NFs(Section – Indirect Communication for NFs through SCP Model D - SMF performs indirect communication for network functions (NFs) through Model D. By default, SMF performs the NRF discovery to select the NF peer, - Section How it Works - With the SCP Model D support, the SMF send requests to SCP endpoints. SCP performs the NRF discovery and finds the correct peer NF and sends the request to the NF).
Regarding claim 13
Cisco further teaches
wherein, in the direct communication model, the first NF communicates with a network repository function (NRF) for discovery of the set of second NFs, and the first NF selects the second NF from the set of second NFs (Section – SCP Interface - In Model B, there is a direct communication with the NRF interaction. Consumers performs discovery by querying the NRF. Based on the discovery result, the consumer does the selection. The consumer sends the request to the selected producer).
Regarding claim 17
Cisco teaches one or more non-transitory, computer-readable storage media having computer-readable instructions thereon which, when executed by one or more processing devices, cause the one or more processing devices to perform operations comprising::
receiving, by a first NF, from a service communication proxy (SCP), a failure message during the first NF running in an indirect communication model, wherein the failure message comprises an error response generated by the SCP and indicates a failure of the SCP, and wherein, in the indirect communication model, the first NF and a second NF of a set of second NFs communicate through the SCP (Section Indirect Communication for NFs through SCP model D - SMF performs indirect communication for network functions (NFs) through Model D. By default, SMF performs the NRF discovery to select the NF peer, With the SCP Model D support, the SMF send requests to SCP endpoints. SCP performs the NRF discovery and finds the correct peer NF- On receiving an error response, SMF as a client, extracts the NF Type from the "Server" header and triggers the SCP failure handling -Section - SCP Model-D fall back - SCP triggers an error, with the "Server" header indicating "scp") ;
responsive to receiving the failure message, switching, by the first NF, from running in the indirect communication model to running in a direct communication model, wherein, in the direct communication model, the first NF and the second NF of the set of second NFs communicate without the SCP, running the first NF in the direct communication model (Section Indirect Communication for NFs through SCP model D - On receiving an error response, SMF as a client, extracts the NF Type from the "Server" header and triggers the SCP failure handling -Section - SCP Model-D fall back - the SMF does a fallback from model-D to model-A in the following scenarios: • SCP triggers an error, with the "Server" header indicating "scp" and The "retry-and-fallback" action is configured - After a fallback, the subsequent messages for the same resource use the peer selected as part of fallback. For example, in case a fallback to SCP Model A happens during N10 registration Section - SCP Interface In Model A, there is a direct communication without the NRF interaction. No NRF or SCP is used. The consumers are configured with the producer NF profiles and directly communicate with the producer of their choice).
Regarding claim 18
Cisco further teaches
wherein switching from running in the indirect communication model to running in the direct communication model further comprises modifying a configuration setting in the first NF ((Section SCP Model -D fallback - If you have configured the SCP failure handling with the "retry" action, then SMF attempts an alternate SCP based on SCP configuration and the retry count configuration. After completion of the configured retry counts or unavailability of any alternate SCPs for retrying, the SMF does a fallback from model-D to model-A in the following scenarios: • SCP triggers an error, with the "Server" header indicating "scp". • The "retry-and-fallback" action is configured – See Also Section – Configuring SCP model D fallback.)
Regarding claim 19
Cisco further teaches
wherein, in the indirect communication model, the SCP communicates with a network repository function (NRF) for discovery of the set of second NFs, and the SCP selects the second NF from the set of second NFs (Section – Indirect Communication for NFs through SCP Model D - SMF performs indirect communication for network functions (NFs) through Model D. By default, SMF performs the NRF discovery to select the NF peer, - Section How it Works - With the SCP Model D support, the SMF send requests to SCP endpoints. SCP performs the NRF discovery and finds the correct peer NF and sends the request to the NF).
Regarding claim 20
Cisco further teaches
wherein, in the direct communication model, the first NF communicates with a network repository function (NRF) for discovery of the set of second NFs, and the first NF selects the second NF from the set of second NFs (Section – SCP Interface - In Model B, there is a direct communication with the NRF interaction. Consumers performs discovery by querying the NRF. Based on the discovery result, the consumer does the selection. The consumer sends the request to the selected producer).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 4,12 are rejected under 35 U.S.C. 103 as being unpatentable over Cisco in view of 3GPP et al. “3GPP TS 23.501 V 18.6.0 – System architecture for the 5G system” – 2024 – 06 ( 3GPP hereinafter)
Regarding claim 4
Cisco does not explicitly teach
wherein, in the indirect communication model, the first NF communicates with a network repository function (NRF) for discovery of the set of second NFs, and the first NF selects the second NF from the set of second NFs
However, 3GPP teaches
wherein, in the indirect communication model, the first NF communicates with a network repository function (NRF) for discovery of the set of second NFs, and the first NF selects the second NF from the set of second NFs(Section 5.21.3.3 - For Indirect Communication mode, the SCP or NF Service consumer may subscribe to status change notifications of NF instance from the NRF and selects another NF producer instance within the same NF Set if the original NF producer instance serving the UE is not available anymore – See Section 5.21.3.4, Section 6. 31 -In the case of Indirect Communication without Delegated Discovery, the requester NF uses the discovery result to select a NF instance while the associated NF service instance selection may be done by the requester NF and/or an SCP on behalf of the requester NF – See Section 6.3.2) .
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Cisco to include the teachings of 3GPP. The motivation for doing so is to allow the system to perform NF discovery (Section 6.31 – 3GPP).
Regarding claim 12
Cisco does not explicitly teach
wherein, in the indirect communication model, the first NF communicates with a network repository function (NRF) for discovery of the set of second NFs, and the first NF selects the second NF from the set of second NFs
However, 3GPP teaches
wherein, in the indirect communication model, the first NF communicates with a network repository function (NRF) for discovery of the set of second NFs, and the first NF selects the second NF from the set of second NFs(Section 5.21.3.3 - For Indirect Communication mode, the SCP or NF Service consumer may subscribe to status change notifications of NF instance from the NRF and selects another NF producer instance within the same NF Set if the original NF producer instance serving the UE is not available anymore – See Section 5.21.3.4, Section 6. 31 -In the case of Indirect Communication without Delegated Discovery, the requester NF uses the discovery result to select a NF instance while the associated NF service instance selection may be done by the requester NF and/or an SCP on behalf of the requester NF – See Section 6.3.2) .
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Cisco to include the teachings of 3GPP. The motivation for doing so is to allow the system to perform NF discovery (Section 6.31 – 3GPP).
Claims 6,14 are rejected under 35 U.S.C. 103 as being unpatentable over Cisco in view of Wang et al. Publication No. US 2021/0392522 A1 ( Wang hereinafter)
Regarding claim 6
Cisco does not explicitly teach
monitoring a status of the SCP; responsive to receiving a recovery message indicating a recovery of the SCP, switching, by the first NF, from running in the direct communication model to running in the indirect communication model; and running the first NF in the indirect communication model
However, Wang teaches
monitoring a status of the SCP; responsive to receiving a recovery message indicating a recovery of the SCP, switching, by the first NF, from running in the direct communication model to running in the indirect communication model; and running the first NF in the indirect communication model (¶ 0039 – ¶ 0040 - a first receiving module, configured to receive, when the first NF entity returns to directly communicating with the second network entity, a second notification message indicating that the first SCP network element is restored to a valid state or the second SCP network element is restored to a valid state; and ¶ 0040 the switching module is further configured to switch, according to the second notification message, to indirectly communicating with the second NF entity by using the first SCP network element or the second SCP network element).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Cisco to include the teachings of Wang. The motivation for doing so is to allow the system to simplify the call flow and reduces the number of transactions the NF must manager by delegating discovery and selection entirely to the SCP .
Regarding claim 14
Cisco does not explicitly teach
monitoring a status of the SCP; responsive to receiving a recovery message indicating a recovery of the SCP, switching, by the first NF, from running in the direct communication model to running in the indirect communication model; and running the first NF in the indirect communication model
However, Wang teaches
monitoring a status of the SCP; responsive to receiving a recovery message indicating a recovery of the SCP, switching, by the first NF, from running in the direct communication model to running in the indirect communication model; and running the first NF in the indirect communication model (¶ 0039 – ¶ 0040 - a first receiving module, configured to receive, when the first NF entity returns to directly communicating with the second network entity, a second notification message indicating that the first SCP network element is restored to a valid state or the second SCP network element is restored to a valid state; and ¶ 0040 the switching module is further configured to switch, according to the second notification message, to indirectly communicating with the second NF entity by using the first SCP network element or the second SCP network element).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Cisco to include the teachings of Wang. The motivation for doing so is to allow the system to simplify the call flow and reduces the number of transactions the NF must manager by delegating discovery and selection entirely to the SCP .
Claims 7,15 are rejected under 35 U.S.C. 103 as being unpatentable over Cisco in view of Wang in view of Gochkov et al. Publication No.US 2019/0347352 A1 ( Gochkov hereinafter)
Regarding claim 7
Cisco in view of Wang further teaches wherein monitoring the status of the SCP (Wang - ¶ 0039 – ¶ 0040). However, Cisco in view of Wang does not explicitly teach
sending a dummy signal to the SCP periodically; and receiving, from the SCP, a response indicating whether the SCP is recovered from the failure
Gochkov teaches
sending a dummy signal to a proxy periodically; and receiving, from the proxy, a response indicating whether the proxy is recovered from the failure ( ¶ 0053 - monitoring is performed on a periodic basis such as, for example, every minute. However, monitoring may be performed with any other frequency - ¶ 0058 – ¶ 0059 - the example agent handles the node restoration (Block 538). An example approach to handling the node restoration is described below in connection with FIG. 8. If no local node failure has been identified ( e.g., block 537 returns a result of NO), or upon handling of the local node restoration (e.g., upon completion of block 538), control proceeds to block 540, where the example remote node monitor 225 determines whether a master node failure has been detected. (Block 540) - the remote node monitor may transmit a dummy query to the database 134 of the master node 130 and review a received response as an indication of whether the master node has encountered a failure. If the example remote node monitor 225 identifies that the master node has encountered a failure (e.g., block 540 returns a result of YES), control proceeds to block 545 where the example remote node monitor 225 handles the master node failure. (Block 545). An example approach to handling the failure of the master node is described below in connection with FIG. 6 -See Also Fig.8).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Cisco in view of Wang to include dummy signal taught by Gochkov. The motivation for doing so is to allow for accurate performance verification and troubleshooting.
Regarding claim 15
Cisco in view of Wang further teaches wherein monitoring the status of the SCP (Wang - ¶ 0039 – ¶ 0040). However, Cisco in view of Wang does not explicitly teach
sending a dummy signal to the SCP periodically; and receiving, from the SCP, a response indicating whether the SCP is recovered from the failure
Gochkov teaches
sending a dummy signal to a proxy periodically; and receiving, from the proxy, a response indicating whether the proxy is recovered from the failure ( ¶ 0053 - monitoring is performed on a periodic basis such as, for example, every minute. However, monitoring may be performed with any other frequency - ¶ 0058 – ¶ 0059 - the example agent handles the node restoration (Block 538). An example approach to handling the node restoration is described below in connection with FIG. 8. If no local node failure has been identified ( e.g., block 537 returns a result of NO), or upon handling of the local node restoration (e.g., upon completion of block 538), control proceeds to block 540, where the example remote node monitor 225 determines whether a master node failure has been detected. (Block 540) - the remote node monitor may transmit a dummy query to the database 134 of the master node 130 and review a received response as an indication of whether the master node has encountered a failure. If the example remote node monitor 225 identifies that the master node has encountered a failure (e.g., block 540 returns a result of YES), control proceeds to block 545 where the example remote node monitor 225 handles the master node failure. (Block 545). An example approach to handling the failure of the master node is described below in connection with FIG. 6 -See Also Fig.8).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Cisco in view of Wang to include the teachings of Gochkov. The motivation for doing so is to allow for accurate performance verification and troubleshooting.
Claims 8,16 are rejected under 35 U.S.C. 103 as being unpatentable over Cisco in view of Wang further in view of Turina et al. Publication No. US 2023/0006888 A1 ( Turina hereinafter)
Regarding claim 8
Cisco in view of Wang further teaches
wherein switching from running in the direct communication model to running in the indirect communication model ( Wang -¶ 0040 - a first receiving module, configured to receive, when the first NF entity returns to directly communicating with the second network entity, a second notification message indicating that the first SCP network element is restored to a valid state or the second SCP network element is restored to a valid state; and ¶ 0040 the switching module is further configured to switch, according to the second notification message, to indirectly communicating with the second NF entity by using the first SCP network element or the second SCP network element).
However, Cisco in view of Wang does not explicitly teach
modifying a configuration setting in the first NF
Turina teaches
modifying a configuration setting in the first NF (¶0019 - wherein the first NF producer node is to migrate from a direct communication mode with a first NF consumer node to an indirect communication mode with the first NF consumer node via a Service Communication Proxy, SCP, node in the communication network. The method in the first NF producer node comprises: updating a stored service address for a network repository function, NRF, node in the communication network to a service address of the SCP node, wherein the NRF node is storing a NF profile for the first NF producer node; and sending a registration request the SCP node, wherein the registration request is a request to register a NF profile for the first NF producer node at the SCP node).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Cisco in view of Wang to include the teachings of Turina. The motivation for doing so is to allow system to migrate from direct communication model to indirect communication model (Turina - ¶0001).
Regarding claim 16
Cisco in view of Wang further teaches
wherein switching from running in the direct communication model to running in the indirect communication model ( Wang -¶ 0040 - a first receiving module, configured to receive, when the first NF entity returns to directly communicating with the second network entity, a second notification message indicating that the first SCP network element is restored to a valid state or the second SCP network element is restored to a valid state; and ¶ 0040 the switching module is further configured to switch, according to the second notification message, to indirectly communicating with the second NF entity by using the first SCP network element or the second SCP network element).
However, Cisco in view of Wang does not explicitly teach
modifying a configuration setting in the first NF
Turina teaches
modifying a configuration setting in the first NF (¶ 0019 - wherein the first NF producer node is to migrate from a direct communication mode with a first NF consumer node to an indirect communication mode with the first NF consumer node via a Service Communication Proxy, SCP, node in the communication network. The method in the first NF producer node comprises: updating a stored service address for a network repository function, NRF, node in the communication network to a service address of the SCP node, wherein the NRF node is storing a NF profile for the first NF producer node; and sending a registration request the SCP node, wherein the registration request is a request to register a NF profile for the first NF producer node at the SCP node).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Cisco in view of Wang to include the teachings of Turina. The motivation for doing so is to allow system to migrate from direct communication model to indirect communication model (Turina - ¶ 0001).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 PM.
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, Oscar A Louie can be reached at (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445
Prosecution Insights