CTNF 18/608,071 CTNF 101628 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Information Disclosure Statement The information disclosure statements submitted on 03/18/2024, 04/11/2024, 06/20/2025, 09/03/2025, 01/07/2026, and 01/29/26 have been considered by the Examiner and made of record in the application file. Claim Objections Claims 1, 11, and 20 are objected to because of the following informality: The acronym SBI is not defined in either the claims or the attached specification. For examination purposes, it will be presumed to mean “service-based interface”. Appropriate correction is required. Claim Rejections – 35 U.S.C. § 103 07-20-aia AIA 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. 07-23-aia AIA 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. 07-20-02-aia AIA 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. 07-21-aia AIA Claim s 1-4, 7, 9-14, 17, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mohan Raj et al. (US 20240007858 A1) in view of Muhanna et al. (US20230284008 A1) . Consider claim 1 , Mohan Raj et al. disclose a PLMN communication method comprising: storing, in memory accessible by the SEPP, an originating and target network mapping database containing records including mappings between originating network identifiers and target network identifiers (see Figure 5, “ SEPP 500 may also include interface configuration database 506 which can include any storage medium that is configured to store and maintain database tables that contain entries including identification information such as target NF type identifiers, the requestor NF type identifiers, and/or the network identifiers, and the like ” (see paragraph 0061)); determining, by the SEPP, an originating network identifier ( “SEPP 500 may include an interface configuration manager (ICM) 504…ICM 504 may be configured for receiving, by a SEPP and from an NF service consumer, an initial NF request message; obtaining a target NF type identifier, a requestor NF type identifier, and a network identifier from the initial NF request message” (see paragraph 0060)); determining, by the SEPP, a target network identifier ( “SEPP 500 may include an interface configuration manager (ICM) 504…ICM 504 may be configured for receiving, by a SEPP and from an NF service consumer, an initial NF request message; obtaining a target NF type identifier, a requestor NF type identifier, and a network identifier from the initial NF request message” (see paragraph 0060)); accessing, by the SEPP and using the originating and target network identifiers determined from the message, the originating and target network mapping database ( “the interface configuration manager is configured to access a local interface configuration database to determine if a corresponding interface at the SEPP is configured to block or allow one or more NF request messages” (see paragraph 0036)); locating, by the SEPP and in the originating and target network mapping database, a record corresponding to the originating network identifier and/or the target network identifier ( “the interface configuration manager 334 may cross-reference the obtained identification information with entries contained in the interface configuration database 332” (see paragraph 0056)); determining, by the SEPP and from the record, whether the message should be allowed to flow from an originating network corresponding to the originating network identifier to a target network corresponding to the target network identifier ( “Once the identification information is obtained, the interface configuration manager 334 can determine if a SBA interface at the supporting SEPP (e.g., vSEPP 324) is configured to allow (and/or block) one or more particular NF request message types originating from the indicated requestor NF type and sent to the indicated target NF type (over the associated interface). In some embodiments, the interface configuration manager 334 may cross-reference the obtained identification information with entries contained in the interface configuration database 332” (see paragraph 0056)); when the SEPP determines that the message should be allowed to flow from the originating network to the target network, forwarding the message to the target network ( “If the interface configuration manager 334 determines that an entry matches the identification information (e.g., target NF type identifier, the requestor NF type identifier, and/or the network identifier), then interface configuration manager 334 will acknowledge the associated SEPP interface (i.e., interfaced used by the target NF type and requestor NF type) as being designated to allow the communication of the NF discovery request message from the SEPP” (see paragraph 0056)); and when the SEPP determines that the message should not be allowed to flow from the originating network to the target network, preventing forwarding of the message to the target network ( “If interface configuration manager 334 cannot locate an entry in interface configuration database 332 that includes entry information that matches the identification information, then interface configuration manager 334 will determine that the interface is blocked to the NF request message” (see paragraph 0056)). However, Mohan Raj et al. fail to disclose wherein the method comprises receiving, by the SEPP, an inter-PLMN SBI request message originating from a network function (NF) in a network served by the SEPP; determining, from the inter-PLMN SBI request message, an originating network identifier; and determining, by the SEPP and from the inter-PLMN SBI request message, a target network identifier. In the same field of endeavor, Muhanna et al. disclose a method comprising receiving, by the SEPP, an inter-PLMN SBI request message originating from a network function (NF) in a network served by the SEPP (the Roaming Hub (RH) “can comprise a rhSBI (Service-Based Interface) bus extended within the RH between the pRH-SEPP (producer SEPP) and cRH-SEPP (consumer SEPP) and can be configured to allow the pRH-SEPP to terminate traffic over to the rhSBI towards the rhSCP (Service Communication Proxy)” (see paragraph 0019). Referring to Figure 5A, block 112 comprises the pSEPP receiving an inter-PLMN SBI request message from the vNRF (visitor Network Repository Function)); determining, from the inter-PLMN SBI request message, an originating network identifier (see Figure 5A, at block 114 “the hNRF processes the Discovery Request and identifies the target NF Service Producer or Producers in the HPLMN network” (see paragraph 0092)); and determining, from the inter-PLMN SBI request message, a target network identifier (see Figure 5B, at block 145 “the hNRF processes the Discovery Request and identifies the target NF Service Producer or Producers in the HPLMN network” (see paragraph 0112)). Therefore, 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 method disclosed by Mohan Raj et al. to use inter-PLMN SBI requests to identify the originating and target networks as taught by Muhanna et al. in order to efficiently transmit the relevant information using 5G architecture. Consider claim 2, and as applied to claim 1 above, Mohan Raj et al., as modified by Muhanna et al., further disclose wherein the records include mappings between allowed or blocked originating network identifiers for target networks indicated by the target network identifiers( “whether the initial NF request message is to be blocked includes cross-referencing one or more of the target NF type identifier, the requestor NF type identifier, and the network identifier with entries in an interface configuration database to locate a matching entry” (see paragraph 0022)). Consider claim 3, and as applied to claim 1 above, Mohan Raj et al., as modified by Muhanna et al., further disclose wherein the records include mappings between allowed or blocked target network identifiers for originating networks indicated by the originating network identifiers ( “whether the initial NF request message is to be blocked includes cross-referencing one or more of the target NF type identifier, the requestor NF type identifier, and the network identifier with entries in an interface configuration database to locate a matching entry” (see paragraph 0022)). Consider claim 4, and as applied to claim 1 above, Mohan Raj et al., as modified by Muhanna et al., further disclose wherein originating and target network identifiers in the records include PLMN identifiers or SEPP identifiers ( “entries of interface configuration database table 400 can also further indicate a specific network identifier (e.g., a target/intended PLMN) in addition to the target NF type and/or requestor NF type” (see paragraph 0053)). Consider claim 7, and as applied to claim 1 above, Mohan Raj et al. fail to disclose wherein determining the originating network identifier from the message includes performing a domain name system (DNS) lookup using a fully qualified domain name (FQDN) constructed from the message and treating the FQDN as the originating network identifier when the DNS lookup returns a success response. In the same field of endeavor, Muhanna et al. disclose wherein the method comprises performing a domain name system (DNS) lookup using a fully qualified domain name (FQDN) constructed from the message (“the pSEPP performs a DNS query for the hNRF FQDN based on the common hNRF from the 3gpp.sbi.target.apiroot header” (see paragraph 0195). Referring to Figure 8, “at block 314 , [the pSEPP] sends Discovery Request to the identified hNRF by setting the authority header to hNRF in case of direct communication or, if via SCP, it keeps 3gpp.sbi.target.apiroot as the identified hNRF FQDN and sets the authority header to SCP” (see paragraph 0195)). Therefore, 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 method disclosed by Mohan Raj et al. to perform a domain name system (DNS) lookup using a fully qualified domain name (FQDN) constructed from the message as taught by Muhanna et al. in order to reliably and completely identify the correct originating and target networks. Consider claim 9, and as applied to claim 1 above, Mohan Raj et al., as modified by Muhanna et al., further disclose wherein determining whether the message should be allowed to flow from the originating network to the target network includes determining whether the originating network identifier determined from the message matches an originating network identifier in the record and determining whether the target network identifier determined from the message matches a target network identifier in the record ( “If the interface configuration manager 334 determines that an entry matches the identification information (e.g., target NF type identifier, the requestor NF type identifier, and/or the network identifier), then interface configuration manager 334 will acknowledge the associated SEPP interface (i.e., interfaced used by the target NF type and requestor NF type) as being designated to allow the communication of the NF discovery request message from the SEPP…If interface configuration manager 334 cannot locate an entry in interface configuration database 332 that includes entry information that matches the identification information, then interface configuration manager 334 will determine that the interface is blocked to the NF request message” (see paragraph 0056)). Consider claim 10, and as applied to claim 1 above, Mohan Raj et al. fail to disclose wherein the SEPP operates as one of: a hosted SEPP, a non-hosted SEPP, a roaming hub, a producer SEPP (P-SEPP) and a consumer SEPP (C-SEPP). In the same field of endeavor, Muhanna et al. disclose a method wherein the SEPP operates as one of: a hosted SEPP, a non-hosted SEPP, a roaming hub, a producer SEPP (P-SEPP) and a consumer SEPP (C-SEPP) (see Figure 3, PLMN A and PLMN B comprise a C-SEPP and P-SEPP, respectively. The interconnecting roaming hub additionally comprises an RH SEPP). Therefore, 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 system disclosed by Mohan Raj et al. to operate the SEPP as either a C-SEPP, P-SEPP, or RH SEPP as taught by Muhanna et al. in order to configure the component SEPPs to function according to their respective roles. Consider claim 11, Mohan Raj et al. disclose a communication system comprising: a SEPP including at least one processor and a memory (see Figure 5, “SEPP 500 may include an interface configuration manager (ICM) 504. ICM 504 may be any suitable entity (e.g., software stored in memory and executing on at least one processor)” (see paragraph 0060)); an originating and target network mapping database stored in the memory and containing a record storing mappings between originating network identifiers and target network identifiers (see Figure 5, “ SEPP 500 may also include interface configuration database 506 which can include any storage medium that is configured to store and maintain database tables that contain entries including identification information such as target NF type identifiers, the requestor NF type identifiers, and/or the network identifiers, and the like ” (see paragraph 0061)); and an originating and target network mapper/validator implemented by the at least one processor for receiving a message originating from a network function (NF) in a network served by the SEPP (see Figure 5, “ICM 504 may be configured for receiving, by a SEPP and from an NF service consumer, an initial NF request message; obtaining a target NF type identifier, a requestor NF type identifier, and a network identifier from the initial NF request message; utilizing the target NF type identifier, the requestor NF type identifier, and the network identifier to determine whether the initial NF request message is to be blocked by an associated service based interface at the SEPP” (see paragraph 0060)), accessing, using the originating and target network identifiers determined from the message, the originating and target network mapping database ( “the interface configuration manager is configured to access a local interface configuration database to determine if a corresponding interface at the SEPP is configured to block or allow one or more NF request messages” (see paragraph 0036)), locating, in the originating and target network mapping database, a record corresponding to the originating network identifier and/or the target network identifier ( “the interface configuration manager 334 may cross-reference the obtained identification information with entries contained in the interface configuration database 332” (see paragraph 0056)), determining, from the record, whether the message should be allowed to flow from an originating network corresponding to the originating network identifier to a target network corresponding to the target network identifier ( “Once the identification information is obtained, the interface configuration manager 334 can determine if a SBA interface at the supporting SEPP (e.g., vSEPP 324) is configured to allow (and/or block) one or more particular NF request message types originating from the indicated requestor NF type and sent to the indicated target NF type (over the associated interface). In some embodiments, the interface configuration manager 334 may cross-reference the obtained identification information with entries contained in the interface configuration database 332” (see paragraph 0056)), when the originating and target network mapper/validator determines that the message should be allowed to flow from the originating network to the target network, forwarding the message to the target network ( “If the interface configuration manager 334 determines that an entry matches the identification information (e.g., target NF type identifier, the requestor NF type identifier, and/or the network identifier), then interface configuration manager 334 will acknowledge the associated SEPP interface (i.e., interfaced used by the target NF type and requestor NF type) as being designated to allow the communication of the NF discovery request message from the SEPP” (see paragraph 0056)), and when the originating and target network mapper/validator determines that the message should not be allowed to flow from the originating network to the target network, preventing forwarding of the message to the target network ( “If interface configuration manager 334 cannot locate an entry in interface configuration database 332 that includes entry information that matches the identification information, then interface configuration manager 334 will determine that the interface is blocked to the NF request message” (see paragraph 0056)). However, Mohan Raj et al. fail to disclose a system wherein the originating and target network mapper/validator implemented by the at least one processor is configured for receiving an inter-PLMN SBI request message originating from a network function (NF) in a network served by the SEPP; determining, from the inter-PLMN SBI request message, an originating network identifier; and determining, from the inter-PLMN SBI request message, a target network identifier. In the same field, Muhanna et al. disclose receiving an inter-PLMN SBI request message originating from a network function (NF) in a network served by the SEPP (the Roaming Hub (RH) “can comprise a rhSBI (Service-Based Interface) bus extended within the RH between the pRH-SEPP (producer SEPP) and cRH-SEPP (consumer SEPP) and can be configured to allow the pRH-SEPP to terminate traffic over to the rhSBI towards the rhSCP (Service Communication Proxy)” (see paragraph 0019). Referring to Figure 5A, block 112 comprises the pSEPP receiving an inter-PLMN SBI request message from the vNRF (visitor Network Repository Function)); determining, from the inter-PLMN SBI request message, an originating network identifier (see Figure 5A, at block 114 “the hNRF processes the Discovery Request and identifies the target NF Service Producer or Producers in the HPLMN network” (see paragraph 0092)); and determining, from the inter-PLMN SBI request message, a target network identifier (see Figure 5B, at block 145 “the hNRF processes the Discovery Request and identifies the target NF Service Producer or Producers in the HPLMN network” (see paragraph 0112)). Therefore, 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 system disclosed by Mohan Raj et al. to use inter-PLMN SBI requests to identify the originating and target networks as taught by Muhanna et al. in order to efficiently transmit the relevant information using 5G architecture. Consider claim 12, and as applied to claim 11 above, Mohan Raj et al., as modified by Muhanna et al., disclose wherein the records include mappings between allowed or blocked originating network identifiers for target networks indicated by the target network identifiers ( “whether the initial NF request message is to be blocked includes cross-referencing one or more of the target NF type identifier, the requestor NF type identifier, and the network identifier with entries in an interface configuration database to locate a matching entry” (see paragraph 0022)). Consider claim 13, and as applied to claim 11 above, Mohan Raj et al., as modified by Muhanna et al., disclose wherein the records include mappings between allowed or blocked target network identifiers for originating networks indicated by the originating network identifiers ( “whether the initial NF request message is to be blocked includes cross-referencing one or more of the target NF type identifier, the requestor NF type identifier, and the network identifier with entries in an interface configuration database to locate a matching entry” (see paragraph 0022)). Consider claim 14, and as applied to claim 11 above, Mohan Raj et al., as modified by Muhanna et al., disclose wherein originating and target network identifiers in the records include PLMN identifiers or SEPP identifiers ( “entries of interface configuration database table 400 can also further indicate a specific network identifier (e.g., a target/intended PLMN) in addition to the target NF type and/or requestor NF type” (see paragraph 0053)). Consider claim 17, and as applied to claim 11 above, Mohan Raj et al. fail to disclose wherein the originating and target network identifier validator/mapper is configured to determine the originating network identifier from the message by performing a domain name system (DNS) lookup using a fully qualified domain name (FQDN) constructed from the message and treating the FQDN as the originating network identifier when the DNS lookup returns a success response. In the same field of endeavor, Muhanna et al. disclose wherein the originating and target network identifier validator/mapper is configured to determine the originating network identifier from the message by performing a domain name system (DNS) lookup using a fully qualified domain name (FQDN) constructed from the message and treating the FQDN as the originating network identifier when the DNS lookup returns a success response (“the pSEPP performs a DNS query for the hNRF FQDN based on the common hNRF from the 3gpp.sbi.target.apiroot header” (see paragraph 0195). Referring to Figure 8, “at block 314 , [the pSEPP] sends Discovery Request to the identified hNRF by setting the authority header to hNRF in case of direct communication or, if via SCP, it keeps 3gpp.sbi.target.apiroot as the identified hNRF FQDN and sets the authority header to SCP” (see paragraph 0195)). Therefore, 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 system disclosed by Mohan Raj et al. to perform a domain name system (DNS) lookup using a fully qualified domain name (FQDN) constructed from the message as taught by Muhanna et al. in order to reliably and completely identify the correct originating and target networks. Consider claim 19, and as applied to claim 11 above, Mohan Raj et al., as modified by Muhanna et al., disclose wherein the originating and target network identifier validator/mapper is configured to determine whether the message should be allowed to flow from the originating network to the target network by determining whether the originating network identifier determined from the message matches an originating network identifier in the record and determining whether the target network identifier determined from the message matches a target network identifier in the record ( “If the interface configuration manager 334 determines that an entry matches the identification information (e.g., target NF type identifier, the requestor NF type identifier, and/or the network identifier), then interface configuration manager 334 will acknowledge the associated SEPP interface (i.e., interfaced used by the target NF type and requestor NF type) as being designated to allow the communication of the NF discovery request message from the SEPP…If interface configuration manager 334 cannot locate an entry in interface configuration database 332 that includes entry information that matches the identification information, then interface configuration manager 334 will determine that the interface is blocked to the NF request message” (see paragraph 0056)). Consider claim 20 , Mohan Raj et al. disclose a non-transitory computer readable medium having stored thereon executable instructions that when executed by a processor of a computer control the computer to perform steps ( “the subject matter described herein may be implemented using one or more computer readable media having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps” (paragraph 0025)) comprising: storing, in memory accessible by security edge protection proxy (SEPP), an originating and target network mapping database containing records including mappings between originating network identifiers and target network identifiers (Referring to Figure 5, “ SEPP 500 may also include interface configuration database 506 which can include any storage medium that is configured to store and maintain database tables that contain entries including identification information such as target NF type identifiers, the requestor NF type identifiers, and/or the network identifiers, and the like ” (see paragraph 0061)); accessing, by the SEPP and using the originating and target network identifiers determined from the message, the originating and target network mapping database ( “the interface configuration manager is configured to access a local interface configuration database to determine if a corresponding interface at the SEPP is configured to block or allow one or more NF request messages” (see paragraph 0036)); locating, by the SEPP and in the originating and target network mapping database, a record corresponding to the originating network identifier and/or the target network identifier ( “the interface configuration manager 334 may cross-reference the obtained identification information with entries contained in the interface configuration database 332” (see paragraph 0056)); determining, by the SEPP and from the record, whether the message should be allowed to flow from an originating network corresponding to the originating network identifier to a target network corresponding to the target network identifier ( “Once the identification information is obtained, the interface configuration manager 334 can determine if a SBA interface at the supporting SEPP (e.g., vSEPP 324) is configured to allow (and/or block) one or more particular NF request message types originating from the indicated requestor NF type and sent to the indicated target NF type (over the associated interface). In some embodiments, the interface configuration manager 334 may cross-reference the obtained identification information with entries contained in the interface configuration database 332” (see paragraph 0056)); when the SEPP determines that the message should be allowed to flow from the originating network to the target network, forwarding the message to the target network ( “If the interface configuration manager 334 determines that an entry matches the identification information (e.g., target NF type identifier, the requestor NF type identifier, and/or the network identifier), then interface configuration manager 334 will acknowledge the associated SEPP interface (i.e., interfaced used by the target NF type and requestor NF type) as being designated to allow the communication of the NF discovery request message from the SEPP” (see paragraph 0056)); and when the SEPP determines that the message should not be allowed to flow from the originating network to the target network, preventing forwarding of the message to the target network ( “If interface configuration manager 334 cannot locate an entry in interface configuration database 332 that includes entry information that matches the identification information, then interface configuration manager 334 will determine that the interface is blocked to the NF request message” (see paragraph 0056)). However, Mohan Raj et al. fail to disclose a non-transitory computer readable medium comprising receiving, by the SEPP, an inter-PLMN SBI request message originating from a network function (NF) in a network served by the SEPP; determining, by the SEPP and from the inter-PLMN SBI request message, an originating network identifier; and determining, by the SEPP and from the inter-PLMN SBI request message, a target network identifier. In the same field, Muhanna et al. disclose a non-transitory computer readable medium comprising receiving, by the SEPP, an inter-PLMN SBI request message originating from a network function (NF) in a network served by the SEPP (the Roaming Hub (RH) “can comprise a rhSBI (Service-Based Interface) bus extended within the RH between the pRH-SEPP (producer SEPP) and cRH-SEPP (consumer SEPP) and can be configured to allow the pRH-SEPP to terminate traffic over to the rhSBI towards the rhSCP (Service Communication Proxy)” (see paragraph 0019). Referring to Figure 5A, block 112 comprises the pSEPP receiving an inter-PLMN SBI request message from the vNRF (visitor Network Repository Function)); determining, by the SEPP and from the inter-PLMN SBI request message, an originating network identifier (see Figure 5A, at block 114 “the hNRF processes the Discovery Request and identifies the target NF Service Producer or Producers in the HPLMN network” (see paragraph 0092)); and determining, by the SEPP and from the inter-PLMN SBI request message, a target network identifier (see Figure 5B, at block 145 “the hNRF processes the Discovery Request and identifies the target NF Service Producer or Producers in the HPLMN network” (see paragraph 0112)). Therefore, 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 non-transitory computer readable medium disclosed by Mohan Raj et al. to use inter-PLMN SBI requests to identify the originating and target networks as taught by Muhanna et al. in order to efficiently transmit the relevant information using 5G architecture . 07-21-aia AIA Claim s 5, 6, 8, 15, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mohan Raj et al. (US 20240007858 A1) in view of Muhanna et al. (US20230284008) , and further in view of ETSI ( 3GPP TS 29.500 version 17.12.0 Release 17 ) . Consider claim 5 , and as applied to claim 1 above, Mohan Raj et al. as modified by Muhanna et al. fail to disclose wherein determining the originating network identifier from the message includes reading the originating network identifier from a 3gpp-Sbi-Originating-Network-Id header of the message. In the same field of endeavor, ETSI discloses wherein the originating network identifier may be accessed via a 3gpp-Sbi-Originating-Network-Id header of the message ( “The header contains the PLMN Identity (MCC-MNC) of the source PLMN or the SNPN ID (MCC-MNC-NID) of the source SNPN of the received HTTP messages” (see Page 37, Clause 5.2.3.2.15). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to alter the method disclosed by Mohan Raj et al. as modified by Muhanna et al. to read the originating network identifier from the 3gpp-Sbi- Originating-Network-Id header as taught by ETSI in order to access the relevant information in accordance with 3GPP specifications. Consider claim 6 , and as applied to claim 5 above, Mohan Raj et al. as modified by Muhanna et al. fail to disclose wherein determining the target network identifier from the message includes determining the target network identifier from a 3gpp-Sbi-Target-apiRoot header of the message. In the same field of endeavor, ETSI discloses wherein the target network identifier may be accessed via a 3gpp-Sbi-Target-apiRoot header of the message ( “The [3gpp-Sbi-Target-apiRoot] header contains the apiRoot of the target URI (see clause 4.4 of 3GPP TS 29.501 [5]) in a request sent to an SCP when using Indirect Communication. This header contains the apiRoot of the selected or changed target URI in a response sent to an HTTP client, when SCP selected or reselected a new HTTP server to route the request and no Location HTTP header is included in the HTTP response. It may also be used in a request sent to a SEPP and in a request between SEPPs (see clause 6.1.4.3.2)” (see Page 24, Clause 5.2.3.2.4)). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to alter the method disclosed by Mohan Raj et al. as modified by Muhanna et al. to read the target network identifier from the 3gpp-Sbi-Target-apiRoot header as taught by ETSI in order to access the relevant information in accordance with 3GPP specifications. Consider claim 8 , and as applied to claim 1 above , Mohan Raj et al. as modified by Muhanna et al. fail to disclose determining the originating network identifier from the message includes reading a dynamically assigned message identifier from the message and using the dynamically assigned message identifier to determine the originating network identifier. In the same field of endeavor, ETSI discloses determining the originating network identifier from the message includes reading a dynamically assigned message identifier from the message and using the dynamically assigned message identifier to determine the originating network identifier (the 3gpp-Sbi-Originating-Network_Id comprises an “srcinfo” value which “shall only be present when SCP or SEPP was unable to uniquely determine the value, i.e. PLMN ID, and has decided to insert the header with the value derived by configuration as described in Table 5.2.3.2.1-1” (see Page 38, Clause 5.2.3.2.15). A second “srcfqdn” value “shall indicate FQDN of SCP or SEPP that inserted the header when srcinfo is present” (see Page 38, Clause 5.2.3.2.15)). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to alter the method disclosed by Mohan Raj et al. as modified by Muhanna et al. to determine the originating network identifier from the message by reading a dynamically assigned message identifier from the message and using the dynamically assigned message identifier to determine the originating network identifier as taught by ETSI in order to access the relevant information in accordance with 3GPP specifications. Consider claim 15 , and as applied to claim 11 above, Mohan Raj et al. as modified by Muhanna et al. fail to disclose wherein the originating and target network identifier validator/mapper is configured to read the originating network identifier from a 3gpp-Sbi-Originating-Network-Id header of the message. In the same field of endeavor, ETSI discloses wherein the originating network identifier may be accessed via a 3gpp-Sbi-Originating-Network-Id header of the message ( “The header contains the PLMN Identity (MCC-MNC) of the source PLMN or the SNPN ID (MCC- MNC-NID) of the source SNPN of the received HTTP messages” (see Page 37, Clause 5.2.3.2.15). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to alter the system disclosed by Mohan Raj et al. as modified by Muhanna et al. to read the originating network identifier from the 3gpp-Sbi-Originating-Network-Id header as taught by ETSI in order to access the relevant information in accordance with 3GPP specifications. Consider claim 16 , and as applied to claim 15 above, Mohan Raj et al. as modified by Muhanna et al. fail to disclose wherein the originating and target network identifier validator/mapper is configured to read the target network identifier from a 3gpp-Sbi-Target-apiRoot header of the message. In the same field of endeavor, ETSI discloses wherein the target network identifier may be accessed via a 3gpp-Sbi-Target-apiRoot header of the message ( “The [3gpp-Sbi-Target-apiRoot] header contains the apiRoot of the target URI (see clause 4.4 of 3GPP TS 29.501 [5]) in a request sent to an SCP when using Indirect Communication. This header contains the apiRoot of the selected or changed target URI in a response sent to an HTTP client, when SCP selected or reselected a new HTTP server to route the request and no Location HTTP header is included in the HTTP response. It may also be used in a request sent to a SEPP and in a request between SEPPs (see clause 6.1.4.3.2)” (see Page 24, Clause 5.2.3.2.4)). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to alter the system disclosed by Mohan Raj et al. as modified by Muhanna et al. to read the target network identifier from the 3gpp-Sbi-Target- apiRoot header as taught by ETSI in order to access the relevant information in accordance with 3GPP specifications. Consider claim 18 , and as applied to claim 11 above , Mohan Raj et al. as modified by Muhanna et al. fail to disclose determining the originating network identifier from the message by reading a dynamically assigned message identifier from the message and using the dynamically assigned message identifier to determine the originating network identifier. In the same field of endeavor, ETSI discloses determining the originating network identifier from the message includes reading a dynamically assigned message identifier from the message and using the dynamically assigned message identifier to determine the originating network identifier (the 3gpp-Sbi-Originating-Network_Id comprises an “srcinfo” value which “shall only be present when SCP or SEPP was unable to uniquely determine the value, i.e. PLMN ID, and has decided to insert the header with the value derived by configuration as described in Table 5.2.3.2.1-1” (see Page 38, Clause 5.2.3.2.15). A second “srcfqdn” value “shall indicate FQDN of SCP or SEPP that inserted the header when srcinfo is present” (see Page 38, Clause 5.2.3.2.15)). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to alter the originating and target network identifier validator/mapper disclosed by Mohan Raj et al. as modified by Muhanna et al. to determine the originating network identifier from the message by reading a dynamically assigned message identifier from the message and using the dynamically assigned message identifier to determine the originating network identifier as taught by ETSI in order to access the relevant information in accordance with 3GPP specifications. Conclusion Any inquiry concerning this communication from the examiner should be directed to ALEXANDER WU whose telephone number is (571)272-3360. The examiner can normally be reached Monday - Friday, 8:30 am - 5:00 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 Application/Control Number: 18/508,364 Page 11 Art Unit: 2642 http:/www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, RAFAEL PEREZ-GUTIERREZ can be reached at (571)272-7915. 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 httos://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. /ALEXANDER WU/Examiner, Art Unit 2642 /Rafael Pérez-Gutiérrez/Supervisory Patent Examiner, Art Unit 2642 Application/Control Number: 18/608,071 Page 2 Art Unit: 2642 Application/Control Number: 18/608,071 Page 3 Art Unit: 2642 Application/Control Number: 18/608,071 Page 4 Art Unit: 2642 Application/Control Number: 18/608,071 Page 5 Art Unit: 2642 Application/Control Number: 18/608,071 Page 6 Art Unit: 2642 Application/Control Number: 18/608,071 Page 7 Art Unit: 2642 Application/Control Number: 18/608,071 Page 8 Art Unit: 2642 Application/Control Number: 18/608,071 Page 9 Art Unit: 2642 Application/Control Number: 18/608,071 Page 10 Art Unit: 2642 Application/Control Number: 18/608,071 Page 11 Art Unit: 2642 Application/Control Number: 18/608,071 Page 12 Art Unit: 2642 Application/Control Number: 18/608,071 Page 13 Art Unit: 2642 Application/Control Number: 18/608,071 Page 14 Art Unit: 2642 Application/Control Number: 18/608,071 Page 15 Art Unit: 2642 Application/Control Number: 18/608,071 Page 16 Art Unit: 2642 Application/Control Number: 18/608,071 Page 17 Art Unit: 2642 Application/Control Number: 18/608,071 Page 18 Art Unit: 2642 Application/Control Number: 18/608,071 Page 19 Art Unit: 2642 Application/Control Number: 18/608,071 Page 20 Art Unit: 2642 Application/Control Number: 18/608,071 Page 21 Art Unit: 2642 Application/Control Number: 18/608,071 Page 22 Art Unit: 2642 Application/Control Number: 18/608,071 Page 23 Art Unit: 2642 Application/Control Number: 18/608,071 Page 24 Art Unit: 2642
Prosecution Insights