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 12/03/2025 has been entered.
Response to Amendment
The amendment to the claims filed on 11/07/2025 complies with the requirements of 37 CFR 1.121(c) and has been entered. Objection to Claim 6 is withdrawn. Claims 1-20, as amended, are pending.
Response to Arguments
Applicant's Arguments/Remarks filed 11/07/2025 (hereinafter Resp.) have been fully considered as follows.
Applicant argues that by Ohlsson et al., WIPO Published Patent Application No. 2020202078, corresponding to US Published Patent Application No. 2022/0174464, (hereinafter Ohlsson), “does not disclose system information signaling that includes ‘a cell identifier for the network device, a tracking area code associated with the network device, and identifier of the plurality of core network,’ as recited by amended claim 1” and “’indicators of whether the plurality of core networks support emergency services, wherein an indicator for each core network of the plurality of core networks supported by the network device indicates whether each core network supports emergency services,’ as recited in claim 1, as amended” – See Resp.,12:¶1.Examiner respectfully disagrees with this narrow reading of Ohlsson.
First, Ohlsson discloses “method includes indicating, in a System Information Block, SIB, whether a network supports an Internet Protocol, IP, Multimedia Subsystem, IMS, emergency communication service, the indication associated to a network identifier, the network identifier identifying the network” whereby, in an embodiment, “the indication is comprised in an ims-EmergencySupport SIB parameter” – See [¶¶0016-17] noting that “in SIB1 the information indicating whether emergency is supported, ‘ims-EmergencySupport’ parameter, is not indicated per network/Cell Identity (ID)” – See [¶0146]. A person of ordinary skills in the art would know that in NR, the broadcasted SIB1 comprises a ims-EmergencySupport parameter – See, e.g., 3GPP TS 38.331 V17.3.0 (2022-12), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 17)” (hereinafter 3GPP TS 38.331), at page 410-415, indicating ims-EmergencySupport and eCallOverIMS-Support), further disclosing cell access information, including plmn-IdentityList; trackingAreaCode; and cellldentity; see also Ohlsson:[¶0142](referencing 3GPP TS 36.331 for RRC messages in E-UTRAN). Therefore, SIB parameters are obvious to one of ordinary skills in the art and inherent to Ohlsson’s disclosure.
Second, Ohlsson teaches “an indicator for each core network of the plurality of core networks supported by the network device indicates whether each core network supports emergency services,” as required by Amended Claim 1, as a SIB Enhancement – See, e.g., [¶0145](“the System Information, SIB, could separate the ‘ims-EmergencySupport’ per PLMN (per network identity/identifier) and the wireless device 22, via processing circuitry 84, can decide network identity, e.g., PLMN (with or without PLMN ID extensions, NID or CAG ID) based on the indicated support.”); see also [¶0146](because in current SIB1 specifications “the same indication is used for all networks/cell IDs sharing the same physical cell . . . some embodiments of the present disclosure may provide for extending the SIB1 indication to be set per network/cell ID”). Therefore, not only that Ohlsson explicitly teaches the required limitation but Applicant’s argument that “Ohlosson discloses that a wireless device may be allowed to access only certain closed access group (CAG) cells” – See Resp.,11:¶3 (emphasis added) is without merit.
In sum, Applicant’s arguments against Ohlsson are unpersuasive. Applicant’s arguments with are also moot because the new ground of rejection over Schliwa-Bertling et al., U.S. Patent Application Publication No. 2020/0336885 explicitly teaching the amended limitations as further explained in the present Office Action.
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-10, and 13-20, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Schliwa-Bertling et al., U.S. Patent Application Publication No. 2020/0336885 (hereinafter Schliwa-Bertling), and further in view of Ohlsson et al., U.S. Patent Application Publication No. 2022/0174464, (hereinafter Ohlsson).
Regarding Amended Claim 1, Schliwa-Bertling teaches a method, comprising:
receiving, by a network device and from a plurality of core networks (“3GPP decided that a NR and E-UTRA/LTE can provide access to 5GC” and that “a cell providing access using E-UTRA can provide access via EPC as well as 5GC” meaning “that such cell can be serving UEs connected to either core networks and thus provide the respective services,” i.e., can receive information from multiple core networks – See [¶0004]) network data identifying the plurality of core networks supported by the network device and emergency service data identifying one or more of the plurality of core networks that support emergency services (“a multi-access wireless device or user equipment to access emergency services” – See [¶0007], using “ a method of controlling access of a wireless device for Emergency Services . . . comprises the step of determining for the wireless device at least one of one or more other core network or system . . . is able to support ES and is in the same Public Land Mobile Network, PLMN, as the first core network or system or in one or more other PLMN” and “sending to the wireless device a message comprising ES information indicating that ES is provided by the at least one of the one or more other core network or system or the one or more radio access node capable of connecting to one or more other core network” – See [¶0012]);
generating, by the network device and based on the network data and the emergency service data, system information that includes a cell identifier for the network device, a tracking area code associated with the network device, and identifiers of the plurality of core networks and indicators of whether the plurality of core networks support emergency services (as taught in prior art, the E-UTRA/LTE base station “may broadcast support for Internet Multimedia Subsystem, IMS, emergency call in SysteminformationBlockTypel (SIB1) sent over the radio interface” as “shown in bold/underlined in the ASN of SIB Type 1 of Table 1 below as specified in 3GPP TS 36.331” – See [¶0005], indicating cell access information comprising: plmn-IdentityList–each PLMN indicating a pair Mobile Country Code/Mobile Network Code (MCC/MNC) allocated to a public operator; trackingAreaCode; cellldentity, and ims-EmergencySupport-r9 ENUMERATED {true} “indicat[ing] if the E-UTRAN/EPC system (EPS) support emergency call support using limited service mode” – See [¶0006]; see also SIB 1 description in 3GPP TS 38.331 V17.3.0 (2022-12), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 17)” (hereinafter 3GPP TS 38.331), at page 410-415, indicating ims-EmergencySupport and eCallOverIMS-Support in NR; equivalent to the referenced SysteminformationBlockType1 (SIB1) in E-UTRA/LTE and described in 3GPP TS 36.331 V17.3.0 (2022-12), “Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (Release 17)”, at page 448-458)
wherein an indicator for each core network of the plurality of core networks supported by the network device indicates whether each core network supports emergency services (“To mitigate the delay to access to Emergency services in a multi-system environment, i.e., an environment that supports multiple accesses and multiple core networks . . . the 5GC/5GS provides the . . . wireless device . . . with information indicating . . . that different core network or system or cell (i.e., radio access node), such as EPC/EPS or eNB respectively in the same PLMN or other PLMN supports ES” – See [¶0055], whereby “the information is obtained [by a UE] from a broadcast signaling over a broadcast channel or from a dedicated signaling” – See [¶0121] and Fig. 4, so that “[i]f there is no EPC/EPS that supports ES, the UE can fallback to another network that supports ES such as 2G, 3G network” whereby “the information about the frequencies of other RATs (e.g. 2G CS, 3G CS) that are candidate to provide ES based on the information provided in the 5G system information” – See [¶¶0072-74]); and
providing, by the network device, the system information to a user equipment to inform the user equipment about which of the plurality of core networks support emergency services (“The information about the Core network/system that supports ES is provided to the UE while the UE is connected to 5GC to avoid the need for the UE to look and connect to yet another Core network/system or cell that does not support ES, when it needs to send an Emergency request” – See [¶0057], e.g., “provide the UE with network assistance to obtain fast access to Emergency Services requiring fallback from 5G system to another system, e.g. EPS, or 2G or 3G because ES is not supported by the 5G system. The information is provided to the UE while the UE is connected to 5GC over a 3GPP radio access network such as eNB or gNB or over a non-3GPP access network such as WLAN, to help the UE connect to a system capable of providing ES without further redirection or fallbacks” – See [¶0075]).
In sum, Schliwa-Bertling discloses that the information about the one or more core network/system that supports ES is provided beforehand to the UE using system information broadcasting while the UE is connected to 5GC, noting that as of the time of filing the ims-EmergencySupport parameter of the SysteminformationBlockType1 Information Element as disclosed in 3GPP TS 36.331 “only indicate if the E-UTRAN/EPC system (EPS) support emergency call support using limited service mode,” requiring the UE “to connect (or attach) to the EPS, as per FIG. 5.3.2.1-1 from 3GPP TS 23.401, simplified in FIG. 1B (prior art) to determine if ES is supported,” i.e., delaying UE’s access to ES and other services/feature available in basic service mode – See [¶0006] and Fig. 1B; see also [¶0042] (during the registration procedure, “the UE receives an indication from the network indicating that basic service mode is supported via Non-Access Stratum, NAS, message comprising Emergency Service support indication and Voice over IMS, VoIMS support indication. The indications are further described in 3GPP TS 23.401 (clauses 4.3.5.8 and 4.3.12) and 3GPP TS 23.167”; furthermore, 3GPP TS 23.401 V17.7.0 (2022-12), “Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 17)” (hereinafter 3GPP TS 23.401), at page 13, indicates that “Enhancements to support interworking of EPS with 5GS are captured in TS 23.501 [83] and TS 23.502 [84]”; specifically, § 4.13.4 of 3GPP TS 23.502 V18.0.0 (2022-12), “Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 18),” December 2022 (hereinafter 3GPP TS 23.502) describes, at page 327-329, that “5GS supports Emergency Services” and “Emergency Services Fallback” indicated to the UE “on per-TA-list and per-RAT basis”).
To combat this delay, Schliwa-Bertling discloses that “information about the Core network/system that supports ES is provided to the UE while the UE is connected to 5GC to avoid the need for the UE to look and connect to yet another Core network/system or cell that does not support ES, when it needs to send an Emergency request,” i.e., in basic service mode – See [¶0057], teaching that such information is provided to the UE on a broadcast channel (and read by 5GC capable UEs) or dedicated signaling (e.g., during UE’s 5G NAS registration) – See [¶¶0059-68]. While Schliwa-Bertling discloses what ES information is provided, i.e., per core network/system capable of ES, Schliwa-Bertling does not disclose a specific format for the broadcasted as system information, e.g., if/when using SysteminformationBlockType1 to convey such information.
To be sure, Ohlsson, like Schliwa-Bertling, discloses the limitation of the SIB1 signaling in prior art when it comes to multiple core networks sharing the same radio access1 – See [¶0146](“in SIB1 the information indicating whether emergency is supported, ‘ims-EmergencySupport’ parameter, is not indicated per network/Cell Identity (ID); in other words, the same indication is used for all networks/cell IDs sharing the same physical cell”).
Ohlsson, teaching “methods, systems, and apparatuses for indicating to and/or directing a wireless device to a network that supports emergency services” – See [¶0014], specifically teaches SIB enhancement to support per core network ES information for assisting a UE with requesting emergency services – See [¶0145](“the System Information, SIB, could separate the ‘ims-EmergencySupport’ per PLMN (per network identity/identifier) and the wireless device 22, via processing circuitry 84, can decide network identity, e.g., PLMN . . . based on the indicated support,” i.e., “a per-network emergency support indication may be provided (e.g., sent by network node 16 to WD 22) via the ‘ims-EmergencySupport’ SIB parameter”)(emphasis added).
Thus, Schliwa-Bertling and Ohlsson each teaches a method in a wireless communication system with one or more core networks available for a UE to access through a network access device and providing support for emergency services, whereby the indication is broadcasted for the UE in a system information block/message. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the enhanced SIB containing per-network ES support indication using ‘ims-EmergencySupport’ per PLMN (per network identity/identifier), as taught in Ohlsson, could have been combined with the step of generating system information that includes identifiers of the one or more core networks supporting ES, as taught by Schliwa-Bertling, because both methods rely on broadcasted system information, e.g., SIB1/ SysteminformationBlockType1, comprising a list of PLMNs and emergency services availability, to send such indication to the UE. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination through techniques known in the art. Finally, the combination achieves the predictable result of reducing the delay to access to Emergency services in multiple core networks, as taught by Schliwa-Bertling while reusing an existing system information format enhanced for multiple core network support, as taught by Ohlsson – See [¶0055].
Therefore, Amended Claim 1 is obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Claim 2, dependent from Amended Claim 1, Schliwa-Bertling further teaches the method of claim 1, further comprising:
receiving, from the user equipment, an emergency call directed to one of the plurality of core networks that supports emergency services, as selected by the user equipment based on the identifiers and the indicators included in the system information (“Step 410: at this step, the UE performs the step of determining the network to connect to for an emergency request based on the received ES information from the 5GC/SGS” – See [¶0139] and Figs. 2 and 4; furthermore, “the network node executes the step 500 of determining for a UE connected to a 5GC/5GS that one or more other core networks/ systems other than the 5GC or 5GS should provide Emergency services for the UE . . . in response to receiving a request indicating emergency from a UE or receiving a request for a service that requires emergency handling, e.g., a request for voice service” – See [¶0145] and Fig. 5)
directing the emergency call to the one of the plurality of core networks that supports emergency services (“If the UE has received ES information indicating more than one network/systems supporting ES than 5GS within the same PLMN or different PLMNs, the UE may use the priority provided in the ES information to select the other network/system to fallback to for sending the emergency request” – See [¶0141], and “may be required to suspend or release the connection to 5GC prior to sending the emergency request to the other network that supports ES” – See [¶0140]).
Ohlsson further describes the scenario wherein the UE is camped on the 5GS and makes an Emergency Service Request to an EPC supporting ES, as shown in Fig. 16 – See [¶0136] whereby, “some embodiments may provide for the NG-RAN (e.g., network node 16a) to trigger a handover or redirection still within NR but to a different PLMN by e.g., indicating the target CN PLMN ID” received from the UE – See [¶0137].
Therefore, Claim 2 is obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Claim 3, dependent from Amended Claim 1, Schliwa-Bertling teaches the method of claim 1 further comprising receiving service data identifying service types provided by the plurality of core networks (“[t]he UE receives an indication from the network indicating that basic service mode is supported via Non-Access Stratum, NAS, message comprising Emergency Service support indication and Voice over IMS, VoIMS support indication. The indications are further described in 3GPP TS 23.401 (clauses 4.3.5.8 and 4.3.12) and 3GPP TS 23.167” – See [¶0042], whereby § 4.3.12 of 3GPP TS 23.401:54-56, indicates that “[a] serving network shall provide an Access Stratum broadcast indication to UEs as to whether eCall Over IMS is supported” and that “[f]or emergency services other than eCall, the UEs in limited service state determine that the cell supports emergency services over E-UTRAN from a broadcast indicator in AS,” i.e., the broadcasted system information indicates emergency services supported by the PLMN list2) ;
generating, based on the network data and the service data, a list identifying the plurality of core networks and priorities associated with service types provided by the plurality of core networks (“the ES information may provide one or more other networks/systems that support ES and may provide an order of priority that the UE may use to select the network or system in the event of Emergency. The priority may be provided on the basis of PLMNs associated to the network/system or based on the technology type. For instance, LTE/EPC has priority over 2G, 3G systems”– See [¶0137]) and
providing the list to the user equipment to inform the user equipment about the priorities associated with the service types provided by the plurality of core networks (“If the UE has received ES information indicating more than one network/systems supporting ES than 5GS within the same PLMN or different PLMN s, the UE may use the priority provided in the ES information to select the other network/system to fallback to for sending the emergency request” – See [¶0141]).
Therefore, Claim 3 is obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Claim 4, dependent from Claim 3, Schliwa-Bertling further teaches the method of claim 3, further comprising:
receiving, from the user equipment, a request for a first service type, directed to one of the plurality of core networks that supports the first service type, as selected by the user equipment based on the list wherein the one of the plurality of core networks is associated with a greatest priority for the first service type relative to the plurality of core networks other than the one of the plurality of core networks (“the UE performs the step of determining the network to connect to for an emergency request based on the received ES information from the 5GC/5GS” – See [¶0139], whereby “[i]f the UE has received ES information indicating more than one network/systems supporting ES than 5GS within the same PLMN or different PLMNs, the UE may use the priority provided in the ES information to select the other network/system to fallback to for sending the emergency request” – See [¶0141], the “UE [is] connected to a 5GC/5GS that one or more other core networks/ systems other than the 5GC or 5GS should provide Emergency services for the UE” and the “request [is] for a service that requires emergency handling, e.g., a request for voice service” – See [¶0145] and the priority is per service type as required for 5GS and disclosed in § 6.7, 3GPP TS 22.261:26-27; see also Note 2); and
directing the request for the first service type to the one of the plurality of core networks that supports the first service type (“require[ing the UE] to suspend or release the connection to 5GC prior to sending the emergency request to the other network that supports ES” – See [¶0140], and/or using “fallback [service] to for sending the emergency request” – See [¶0141]).
Therefore, Claim 4 is obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Claim 5, dependent from Claim 4, Schliwa-Bertling further teaches the method of claim 4, further comprising:
receiving, from the user equipment, a request for a second service type directed to another one of the plurality of core networks that supports the second service type as selected by the user equipment based on the list (“the UE receives an indication from the network indicating that basic service mode is supported,” in a “message comprising Emergency Service support indication and Voice over IMS, VoIMS support indication” as “further described in 3GPP TS 23.401 (clauses 4.3.5.8 and 4.3.12) and 3GPP TS 23.167” – See [¶0042], i.e., emergency services and VoIMS emergency services are two service types; see also SIB1 description in 3GPP TS 38.331: 410-415 wherein both ims-EmergencySupport and eCallOverIMS-Support are indicated to the UE with respective enumerated Boolean type indicating support per PLMN, whereby the first service type, ims-EmergencySupport, “[i]ndicates whether the cell supports IMS emergency bearer services for UEs in limited service mode” and the second service type, eCallOverIMS-Support, “[i]ndicates whether the cell supports eCall over IMS services as defined in TS 23.501”, whereby 3GPP TS 23.501:257-258 teaches that in shared RAN, a “cell connected to EPC and 5GC broadcasts separate broadcast indicator for EPC and 5GC to indicate support of emergency services by the EPC and 5GC,” and, similarly “[w]hen an E-UTRA cell is connected to EPC and 5GC, the cell broadcasts separate Access stratum broadcast indication for 5GC and EPC to indicate support of eCall over IMS by 5GC and EPC”; therefore, support for the first and the second service type is per core network, hence the UE in limited service mode with the 5GC can receive Emergency Services because in limited service state does not require a valid subscription; however, on the one hand, “[e]mergency calls for eCall Over IMS may only be performed if the UE has a USIM” – See id.:257, and on the other hand, “[f]or an Emergency Registered UE over a given Access Type: the UE shall not initiate the UE Requested PDU Session Establishment procedure for normal service over this Access Type” and “the UE may attempt to receive normal service over another Access Type” – See id.:260-261, therefore, the UE would direct a eCall over IMS request to the EPC based on the USIM)
wherein the other one of the plurality of core networks is associated with a greatest priority for the second service type relative to the plurality of core networks other than the other one of the plurality of core networks (“The priority may be provided on the basis of PLMNs associated to the network/system or based on the technology type. For instance, LTE/EPC has priority over 2G, 3G systems” – See [¶0137]; hence LTE/EPC will be the first priority for the second service type)
directing the request for the second service type to the other one of the plurality of core networks that supports the second service type (“the NG-RAN is able to trigger handover or redirection from NR to E-UTRA connected to 5GC at QoS Flow establishment for IMS Emergency Services (e.g. voice)” – See 3GPP TS 23.501:257; see also Schliwa-Bertling:[¶0057] (when VoIMS/eCall over IMS is not “supported by 5GC/5GS, the latter suggests or instructs the UE that it should connect to other core network/system/cell such as EPC/EPS/cell represented by for example an eNB, in order to receive” the service).
Therefore, Claim 5 is obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Claim 6, dependent from Amended Claim 1, although Schliwa-Bertling teaches that SysteminformationBlockTypel (SIB1) is used to broadcast support for ES by one or more other core networks, including per-network ES indication information, Schliwa-Bertling does not teach a specific format for SIB 1 to convey such indication, as explained in Regarding Amended Claim 1 supra.
However, Ohlsson teaches the system information includes an emergency support bit for each of the plurality of core networks and the indicators of whether the plurality of core networks support emergency services (“the System Information, SIB, could separate the ‘ims-EmergencySupport’ per PLMN (per network identity/identifier)” for “a per-network emergency support indication” – See [¶0145], e.g., “extending the SIB1 indication,” specifically the ims-EmergencySupport parameter, “to be set per network/cell ID” – See [¶0146]. Because 3GPP TS 38.331: 412-413 already defines the type for the ims-EmergencySupport parameter as an enumerated Boolean (“ENUMERATED {true}”), it is inherent that a 1 bit per network, e.g., per each PLMN in the plmn-IdentityList field, would suffice for supporting the indication3).
Therefore, Claim 6 is obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Claim 7, dependent from Amended Claim 1, while Schliwa-Bertling does not disclose support for private networks, Ohlsson further teaches the method of claim 1, wherein the user equipment is connected to a private network supported by the network device (“the indication of whether the network supports the IMS emergency communication service is associated to . . . a combination of the PLMN ID and the NID [that] identifies a standalone non public network, SNPN, to which the indication of whether the network supports the IMS emergency communication service is associated to.” – See [¶0017] and Fig. 1, or a “non-public network, NPN” – See [¶0019]; see also 3GPP TS 38.331:411 disclosing SIB1 parameter cellAccessRelatedInfo further containing imsEmergencySupportForSNPN indicators, each associated with the corresponding SNPN identity– See id.:518).
Therefore, Claim 7 is obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Amended Claim 8, Schliwa-Bertling in view of Ohlsson teaches a network device, comprising: one or more processors configured to execute the combined steps of Claims 1 and 2, as amended, recited with the same language (e.g., in Fig. 2, “[i]f NG-RAN is an LTE eNB it may be able to connect to network 106, 5GC, and/or to Network 106b, such as an Evolved Packet Core, EPC” – See [¶0077] and/or “may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 160, such as, for example, LTE, NR, WiFi wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 160” – See [¶0084] wherein “processing circuitry 170 can be configured to perform the described functionality. The benefits provided by such functionality are not limited to processing circuitry 170 alone or to other components of network node 160 but are enjoyed by network node 160 as a whole, and/or by end users and the wireless network generally” – See [¶0087]).
Therefore, Amended Claim 8 is obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Claims 9 and 10, each dependent from Amended Claim 8, each merely recite the steps of Claims 6 and 7, respectively, as amended, with no other limitations. Because each of Claims 6-8, as amended, is obvious over Schliwa-Bertling in view of Ohlsson, Claims 9 and 10 are also obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Claim 13, dependent from Amended Claim 8, Schliwa-Bertling further teaches the network device of claim 8, wherein the network device is a radio access network device – See, e.g., [¶0119] (“FIG. 4 illustrates a method performed by a UE connected or connecting to a first network, such as 5GC using NG-RAN which may be gNB or eNB”)
Therefore, Claim 13 is obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Claim 14, dependent from Amended Claim 8, Schliwa-Bertling further teaches the network device of claim 8, wherein a quantity of the plurality of core networks is greater than or equal to two (“to obtain fast access to Emergency Services requiring fallback from 5G system to another system, e.g. EPS, or 2G or 3G because ES is not supported by the 5G system” – See [¶0075], e.g., “[i]f there is no EPC/EPS that supports ES, the UE can fallback to another network that supports ES such as 2G, 3G network” – See [¶0072]), and at least one of the plurality of core networks supports emergency services (“at least one of one or more other core network . . . is able to support ES” – See [¶0009], e.g., “ES information indicate that 5GC does not support ES and indicate support of ES by the other network” – See [¶0130]).
Therefore, Claim 14 is obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Amended Claim 15, Schliwa-Bertling teaches a non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a network device (“Device readable medium 180 may comprise any form of volatile or non-volatile computer readable memory” and “may store any suitable instructions, data or information, including a computer program, software, an application including one or more of logic, rules, code, tables, etc. and/or other instructions capable of being executed by processing circuitry 170 and, utilized by network node 160” – See [¶0088] and Figure 2), cause the network device to: execute the steps disclosed in Amended Claim 1. Because Amended Claim 1 is obvious over Schliwa-Bertling in view of Ohlsson, Amended Claim 15 is also obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Claims 16 and 17, dependent from Amended Claim 15, taken together they merely recite the steps of Claim 4 performed by the device in Amended Claim 15, with no other limitations. Because Claims 4 and 15, as amended, are obvious over Schliwa-Bertling in view of Ohlsson, each of Claims 16 and 17 is obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Claims 18 and 19, dependent from Claim 16, they merely describe the steps of Claim 5 performed by the device in Claim 16, with no other limitations. Because each of the Claims 5 and 16 is obvious over Schliwa-Bertling in view of Ohlsson, each of Claims 18 and 19 is obvious over Schliwa-Bertling in view of Ohlsson.
Regarding Claim 20, dependent from Amended Claim 15, the claim language merely recites the steps of the method in Claim 2, dependent from Amended Claim 1, performed together in combination by the device in Amended Claim 15. Because each of Claims 2 and 15, as amended, is obvious over Schliwa-Bertling in view of Ohlsson, Claim 20 is also obvious over Schliwa-Bertling in view of Ohlsson.
In sum, Claims 1-10, and 13-20, as amended, are rejected under 35 U.S.C. 103 as obvious over Schliwa-Bertling in view of Ohlsson.
Claims 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over over Schliwa-Bertling in view of Ohlsson as applied to Amended Claim 8 above, and further in view of 3GPP TS 23.251 V17.0.0 (2022-03), “Technical Specification Group Services and System Aspects; Network Sharing; Architecture and functional description (Release 17)” (hereinafter 3GPP TS 23.251).
Regarding Claims 11 and 12, each dependent from Amended Claim 8, even though both Schliwa-Bertling and Ohlsson disclose multiple core networks of different generations, none of them require access that the core networks be different. Furthermore, the indication of ES support through the broadcasted SIB1 information is associated with each PLMN ID in the plmn-IdentityList, therefore agnostic to the type of core network of each PLMN in the list. Because Schliwa-Bertling teaches that “a 5GS herein comprises a 5GC and a 5G RAN as accessed by the UE” – See [¶00056] and that “at least one of one or more other core network or system . . . belong[ing] to one or more other PLMN . . . is able to support ES” – See [¶0009], Schliwa-Bertling further teaches the network device wherein the plurality of core networks are fifth-generation standalone core networks.
Similarly, because Schliwa-Bertling teaches “one or more other core network or system, such as 4G EPC or EPS” – See [¶0009] even though the UE may receive the ES indication from a NG-RAN connected to a 5GC – See [¶0056], Schliwa-Bertling further teaches the network device wherein the plurality of core networks are fourth-generation evolved packet core networks.
To be sure, 3GPP TS 23.251 teaches that “a shared RAN is configured to indicate available core network operators for selection by UEs, each cell in shared radio access network shall in the broadcast system information include information concerning available core network operators in the shared network” and “the Broadcast System Information broadcasts a basic set of PLMN IDs and optionally one or more additional set of PLMN IDs . . . (see TS 36.331 [11])” – See 3GPP TS 23.251:9-10 and “[a] supporting UE decodes the broadcast system information to determine available core network operators in the shared network” and “[t]he core network operators together with all conventional networks are candidate PLMNs for the PLMN selection procedure that shall be performed by the UE as specified in TS 23.122 [4]” – See id.. 3GPP TS 23.251:9 further teaches two reference architecture for network sharing: one in which the core network operators also share core network nodes in Figure 1, and one in which only the radio access network is shared in Figure 2. It would be obvious for a person of ordinary skills in the art that the first reference architecture is more suitable for core networks using the same technology, e.g., 5G core only or 4G EPC only, because this would facilitate sharing of core components. Thus, Schliwa-Bertling in view of Ohlsson and 3GPP TS 23.251 each teaches multiple core networks sharing radio access for the respective technology supporting UEs. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the reference architecture sharing also core network components as taught by 3GPP TS 23.251 could have been combined with the network access device and method taught in Schliwa-Bertling in view of Ohlsson because both provide for shared access to either 5GC or 4G EPC multiple networks. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination through techniques known in the art. Finally, the combination achieves the predictable result of sharing core network components as taught in 3GPP TS 23.251.
Therefore, Claims 11-12 are rejected under 35 U.S.C. 103 as obvious over Schliwa-Bertling in view of Ohlsson and further in view of 3GPP TS 23.251.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Tang et al., U.S. Patent Application Publication No. 20220141636 as presented in previous office actions;
Ianev et al., U.S. Patent Application Publication No. 2024/0323828 as presented in previous office actions;
Bakker, U.S. Patent Application Publication No. 2021/0112394, disclosing emergency services handling with the UE in dual registration with a first core network and a second core network;
Arshad et al., U.S. Patent Application Publication No. 2020/0120470 discloses method allowing the wireless device to have immediate access to emergency services and no delaying emergency fallback procedure is performed;
Jin et al., U.S. Patent Application Publication No. 20240251330, disclosing a method for selecting another cell or PLMN when a disaster condition occurs and controlling an access in the selected another cell or PLMN in a mobile communication system;
Shih et al., U.S. Patent Application Publication No. 2022/0361098 discloses method of selecting an acceptable cell in an SNPN based on the SNPN support of IMS emergency service;
Kadiri et al., U.S. Patent Application Publication No. 2019/0021048 discloses methods, systems, and devices for wireless communication that provide for identification, on a per-PLMN basis of a type of core network associated with each PLMN in a list of networks associated with a base station;
Yanxia, CN Patent Application Publication No. 115134797 discloses method and apparatus for routing a first emergency service request to a core network function network element corresponding to a second type of network;
Weiwei et al., WIPO Patent Application Publication No. WO2020035000 discloses a method for obtaining a method for obtaining network configuration information for policy control based on analytics of each slice network list sent by the data analysis network element;
3GPP TS 23.401 V17.7.0 (2022-12), “Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 17)”;
3GPP TS 36.331 V17.3.0 (2022-12), “Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (Release 17)”;
3GPP TS 38.331 V17.3.0 (2022-12), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 17)”;
3GPP TS 23.501 V18.0.0 (2022-12), “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 18),” December 2022;
3GPP TS 23.502 V18.0.0 (2022-12), “Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 18),” December 2022;
3GPP TS 23.167 V17.2.0 (2021-09), “Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) emergency sessions (Release 17)”;
3GPP TS 23.251 V17.0.0 (2022-03), “Technical Specification Group Services and System Aspects; Network Sharing; Architecture and functional description (Release 17)”;
3GPP TS 32.130 V17.5.0 (2022-12), “Technical Specification Group Services and System Aspects; Telecommunication management; Network sharing; Concepts and requirements (Release 17),” December 2022;
3GPP TS 24.501 V18.1.0 (2022-12), “Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3; (Release 18),” December 2022;
3GPP TS 22.261 V18.8.0 (2022-12), “Technical Specification Group Services and System Aspects; Service requirements for the 5G system; Stage 1 (Release 18),” December 2022.
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 Multi-Operator Core Networks (MOCNs) are described in 3GPP TS 23.251 V17.0.0 (2022-03), “Technical Specification Group Services and System Aspects; Network Sharing; Architecture and functional description (Release 17)” (hereinafter 3GPP TS) whereby “a shared RAN is configured to indicate available core network operators for selection by UEs, each cell in shared radio access network shall in the broadcast system information include information concerning available core network operators in the shared network” and “the Broadcast System Information broadcasts a basic set of PLMN IDs and optionally one or more additional set of PLMN IDs . . . (see TS 36.331 [11])” – See 3GPP TS 23.251:9-10 and “[a] supporting UE decodes the broadcast system information to determine available core network operators in the shared network” and “[t]he core network operators together with all conventional networks are candidate PLMNs for the PLMN selection procedure that shall be performed by the UE as specified in TS 23.122 [4]” – See id. and Figure 2, showing a Multi-Operator Core Network (MOCN) in which multiple CN nodes are connected to the same RNC and the CN nodes are operated by different operators. In general, PLMN handling for network sharing is discussed for both public and private networks in § 5.8 of 3GPP TS 23.501 V17.7.0 (2022-12), “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 17),” (hereinafter 3GPP TS 23.501), noting that the broadcast system information for network sharing “is specified in TS 38.331 [28] for NR, TS 36.331 [51] for E-UTRA and related UE access stratum idle mode procedures in TS 38.304 [50] for NR and TS 36.304 [52] for E-UTRA”– See 3GPP TS 23.501:280; and that “[t]he cell connected to EPC and 5GC broadcasts separate broadcast indicator for EPC and 5GC to indicate support of emergency services by the EPC and 5GC” – See id.:257.
2 In Rel-18, SIB1 contains “configuration information that is common for all UEs and barring information applied to the unified access control” whereby “PLMN/SNPN specific configuration [is] provided in uac-BarringPerPLMN-List. The parameters are specified by providing an index to the set of configurations (uac-BarringInfoSetList)” – See 3GPP TS 38.331:414; furthermore, “[e]ach access category can be configured with access parameters” per each access identity, for each PLMN – See id.:915-916, wherein Unified Access Control is defined in § 4.5 of 3GPP TS 24.501 V18.1.0 (2022-12), “Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3; (Release 18)” (hereinafter 3GPP TS 24.501) defining the Access Identities a UE could use when accessing a service in Table 4.5.2.1, at page 69, and the Access Categories that a PLMN may support in Table 4.5.2.2, at page 71-74, e.g., Access Category 2 is for emergency session while categories 32-63 are based on operator classification which the UE learns/stores and “definitions are valid in the PLMN which provided them and in a PLMN equivalent to the PLMN which provided them, or in the SNPN which provided them and in an SNPN equivalent to the SNPN which provided them, as specified in annex C” – See id.:81; Section 4.5 3GPP TS 24.501:67 indicates that the “set of access identities and access categories [are] defined in 3GPP TS 22.261”; see also § 6.22 of 3GPP TS 22.261 V18.8.0 (2022-12), “Technical Specification Group Services and System Aspects; Service requirements for the 5G system; Stage 1 (Release 18),” December 2022 (hereinafter 3GPP TS 26.261) describing Access Identities in Table 6.22.2.2-1, at page 40, and Access Categories in Table 6.22.2.3-1, at page 41.
3 It is noted that a similar logic applies to the eCallOverIMS-Support parameter that is also of type enumerated Boolean – See 3GPP TS 38.331:413.