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
03/06/2026 has been entered.
Summary
This action is in reply to Applicant's Amendments and Remarks filed on 03/06/2026.
Claims 1-9 and 11-19 are pending.
Claims 10 and 20 are cancelled.
Response to Arguments
Applicant's arguments dated 03/06/2026 with respect to claims 1-9 and 11-19 have been fully considered but they are not persuasive.
The Applicant presented argument that Vivo does not disclose a support indication that is specific to a selected SNPN. Instead, Vivo consistently describes a cell-level IMS emergency support indication, which is insufficient to meet the claimed SNPN-specific limitation." (REMARKS, Page 9)
The Examiner respectfully disagrees.
The Examiner first presents that the instant Application Specification discloses-
[0113] Step S140: the UE receives a support indication associated with the selected SNPN in response to the cell selection. The support indication indicates whether the selected SNPN supports IMS emergency service.
[0114] In one embodiment, the support indication may be an IMS emergency call support indication (e.g., ims-EmergencySupport) included in system information (e.g., SIB1) received from a cell that the UE camps on. In one embodiment, the support indication may be an eCall over IMS support indication included in system information (e.g., SIB1) from a cell that the UE camps on or connects to determine whether the cell and/or the network supports eCall over IMS.
Now, the Examiner presents that Vivo discloses –
Page 2, 8.1.5 Conclusions for UEs with a PLMN subscription
- Network selection and registration.
- Once an SNPN has been selected the UE attempts registration using the PLMN credentials.
Page 4, Solution #23:
6.23.2 Functional Description
- AMF of SNPN needs include an indication for Emergency Services Support within the Registration Accept to the UE also for UE in SNPN access mode;
- NG-RAN of SNPN needs to support related broadcast indicator that the cell supports Emergency Services over NG-RAN in order to support UEs in limited service state.
Observation 5: In limited service state, UE should be informed about if a cell support emergency service over NG-RAN of SNPN.
In order to support emergency service, UE in SNPN Access Mode shall be able to identify whether SNPN(s) can support emergency service or not. According the following description, a bit indicator is enough for nonshared SNPN only cell.
Page 5, Solution #23:
6.23.4 Impacts on services, entities and interfaces
NG-RAN of SNPN
Include related broadcast indicator that the cell supports Emergency Services over NG-RAN for UEs in limited service state, and if the NG-RAN is shared by more than one network, and the networks do not have the same support for Emergency Services, the broadcast indicator is related to those networks that supports Emergency Services.
Proposal 3: A bit indicator is introduced in SIB1 to indicate whether SNPN(s) in the cell support Emergency service.
From above Vivo disclosure, iit is obvious that UE in SNPN AM, after selecting SNPN, gets an indication from AMP via SNPN that the SNPN of the Cell provide Emergency Services support.
The indication can be provided during registration to specific SNPN, or via cell broadcast via SIB1, the cell of the SNPN may include only the SNPN or plurality of SNPNs, which is similar to the disclosure in the instant Application Specification [0114].
Accordingly, claims 1 and 11 with substantially similar features are rejected.
Dependent claims 2-9 and 12-19 being dependent on claims 1 and 11 are also rejected for the same reason as above.
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 of this title, 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.
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-4, 6, 8, 11-14, 16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Vivo (R2-2100840 “Support of IMS voice and emergency service for SNPN”, of IDS, hereinafter ‘VIVO’), with evidence by 3GPP TR 23.700-7 V17.0.0, of record, hereinafter ‘3GPP700’, in view of Li et al. (US 20230363055 A1 with priority of PCT/CN2021/071730, of record, hereinafter ‘LI-55’).
Regarding claim 1, VIVO teaches a method performed by a user equipment (UE) for emergency service (Page 2 Section 2 Discussion
Section 2.1 2.1 Conclusions in SA2
…. Conclusions related to the support of IMS voice and emergency service
8.1.4 Conclusions on SNPN selection for UEs.
Page 4 Section 2.3 Support of emergency service for SNPN
Solution #23:
6.23.2 Functional Description
Based on the above service requirements the following impacts for support of emergency services by SNPN are foreseen for the specifications under SA WG2 control:
- AMF of SNPN needs include an indication for Emergency Services Support within the Registration Accept to the UE also for UE in SNPN access mode;
- NG-RAN of SNPN needs to support related broadcast indicator that the cell supports Emergency Services over NG-RAN in order to support UEs in limited service state.
The functionality that is already described in TS 23.501 [4] clause 5.16.4.1 for PLMN access, need to apply to SNPN NG-RAN, 5GC belonging to SNPN and UE operating in SNPN access mode.
Observation 4: In normal service state, the support of emergency service for SNPN is handled by NAS. There is no additional RAN impact.
Observation 5: In limited service state, UE should be informed about if a cell support emergency service over NG-RAN of SNPN.
Next, we will focus on the support of emergency service in limited service state.
..... Thus, UE in SNPN Access Mode shall stay in any cell selection state if the UE cannot find a suitable cell to camp on, which can refer to the following specification. In R17 eNPN, emergency service is supported for SNPN. It is reasonable that UE in SNPN Access Mode shall attempt to find an acceptable cell when the UE is in any cell selection state.
(Construed that VIVO disclosing –
in R17 cell supporting Emergency Service indicates support for Emergency Service, and for limited service case to get Emergency Service UE in SNPN Access Mode will access any cell supporting Emergency Service)), the method comprising:
while operating in a standalone non-public network (SNPN) access mode (AM), performing an SNPN selection to select an SNPN (
Page 2 Section 2 Discussion
Section 2.1
According to the description in TS 23.700-07, SA2 has achieved the following interim conclusions related the support of IMS voice and emergency service:
8.1.5 Conclusions for UEs with a PLMN subscription
- Network selection and registration.
-To enable a UE with PLMN subscription to select an SNPN, the UE needs to enter SNPN access mode.
- Once the UE has entered SNPN access mode, SNPN selection is performed as described in clause 8.1.4.
- Once an SNPN has been selected the UE attempts registration using the PLMN credentials.
Page 4 Section 2.3 Support of emergency service for SNPN
Solution #23:
6.23.2 Functional Description
Based on the above service requirements the following impacts for support of emergency services by SNPN are foreseen for the specifications under SA WG2 control:
- NG-RAN of SNPN needs to support related broadcast indicator that the cell supports Emergency Services over NG-RAN in order to support UEs in limited service state.
Observation 4: In normal service state, the support of emergency service for SNPN is handled by NAS. There is no additional RAN impact.
Observation 5: In limited service state, UE should be informed about if a cell support emergency service over NG-RAN of SNPN.
..... Thus, UE in SNPN Access Mode shall stay in any cell selection state if the UE cannot find a suitable cell to camp on, which can refer to the following specification. In R17 eNPN, emergency service is supported for SNPN. It is reasonable that UE in SNPN Access Mode shall attempt to find an acceptable cell when the UE is in any cell selection state.
Page 5:
In R16, it is common understanding that UE in SNPN Access Mode only selects SNPNs. From our understanding, it is also applied to the case that UE in SNPN Access Mode finds an acceptable cell.
(Construed that a UE in SNPN AM performing an SNPN selection for selecting a cell supporting emergency service when in limited service states, the cell indicating support for emergency service));
performing a cell selection to select a cell in response to the selection of the SNPN selection (
Pages 4-5 Section 2.3 Support of emergency service for SNPN
…… Thus, UE in SNPN Access Mode shall stay in any cell selection state if the UE cannot find a suitable cell to camp on, which can refer to the following specification. In R17 eNPN, emergency service is supported for SNPN. It is reasonable that UE in SNPN Access Mode shall attempt to find an acceptable cell when the UE is in any cell selection state.
In R16, it is common understanding that UE in SNPN Access Mode only selects SNPNs. From our understanding, it is also applied to the case that UE in SNPN Access Mode finds an acceptable cell.
Proposal 2: In Any cell selection state, UE in SNPN Access Mode shall attempt to find an acceptable cell of any SNPN to camp on.
(Construes UE performing an SNPN selection for selecting a cell supporting emergency service when in limited service states, the cell indicating support for emergency service));
receiving a support indication specific to the selected SNPN in response to the cell selection (
Page 2, 8.1.5 Conclusions for UEs with a PLMN subscription
- Network selection and registration.
- Once an SNPN has been selected the UE attempts registration using the PLMN credentials.
Page 4, Solution #23:
6.23.2 Functional Description
- AMF of SNPN needs include an indication for Emergency Services Support within the Registration Accept to the UE also for UE in SNPN access mode;
- NG-RAN of SNPN needs to support related broadcast indicator that the cell supports Emergency Services over NG-RAN in order to support UEs in limited service state.
Observation 5: In limited service state, UE should be informed about if a cell support emergency service over NG-RAN of SNPN.
In order to support emergency service, UE in SNPN Access Mode shall be able to identify whether SNPN(s) can support emergency service or not. According the following description, a bit indicator is enough for nonshared SNPN only cell.
Page 5, Solution #23:
6.23.4 Impacts on services, entities and interfaces
NG-RAN of SNPN
Include related broadcast indicator that the cell supports Emergency Services over NG-RAN for UEs in limited service state, and if the NG-RAN is shared by more than one network, and the networks do not have the same support for Emergency Services, the broadcast indicator is related to those networks that supports Emergency Services.
Proposal 3: A bit indicator is introduced in SIB1 to indicate whether SNPN(s) in the cell support Emergency service…..), wherein the support indication indicates whether the selected SNPN supports an internet protocol (IP) multimedia subsystem (IMS) emergency service (Pages 4-5 Section 2.3 Support of emergency service for SNPN
Solution #23:
- AMF of SNPN needs include an indication for Emergency Services Support within the Registration Accept to the UE also for UE in SNPN access mode;
- NG-RAN of SNPN needs to support related broadcast indicator that the cell supports Emergency Services over NG-RAN in order to support UEs in limited service state.
Observation 4: In normal service state, the support of emergency service for SNPN is handled by NAS.
Observation 5: In limited service state, UE should be informed about if a cell support emergency service over NG-RAN of SNPN.
In order to support emergency service, UE in SNPN Access Mode shall be able to identify whether SNPN(s) can support emergency service or not. According the following description, a bit indicator is enough for nonshared SNPN only cell.
…… This indicator is set to "support" if any AMF in a non-shared environment or at least one of the PLMN's in a shared environment supports IMS emergency bearer services. It is suggested to follow the design principle of PLMN to avoid repetitive discussion.
Solution #23:
6.23.4 Impacts on services, entities and interfaces
NG-RAN of SNPN
Include related broadcast indicator that the cell supports Emergency Services over NG-RAN for UEs in limited service state, and if the NG-RAN is shared by more than one network, and the networks do not have the same support for Emergency Services, the broadcast indicator is related to those networks that supports Emergency Services.
Proposal 3: A bit indicator is introduced in SIB1 to indicate whether SNPN(s) in the cell support Emergency service.
ims-EmergencySupport:
Indicates whether the cell supports IMS emergency bearer services for UEs in limited service mode. If absent, IMS emergency call is not supported by the network in the cell for UEs in limited service mode.);
determining, by a radio resource control (RRC) layer of the UE, whether the support indication indicates that the selected SNPN supports the IMS emergency service (
Page 5
In order to support emergency service, UE in SNPN Access Mode shall be able to identify whether SNPN(s) can support emergency service or not……
Solution #23:
6.23.4 Impacts on services, entities and interfaces
NG-RAN of SNPN
Include related broadcast indicator that the cell supports Emergency Services over NG-RAN for UEs in limited service state, and if the NG-RAN is shared by more than one network, and the networks do not have the same support for Emergency Services, the broadcast indicator is related to those networks that supports Emergency Services.
Proposal 3: A bit indicator is introduced in SIB1 to indicate whether SNPN(s) in the cell support Emergency service.
ims-EmergencySupport:
Indicates whether the cell supports IMS emergency bearer services for UEs in limited service mode. If absent, IMS emergency call is not supported by the network in the cell for UEs in limited service mode.
(Construed that since SIB1 is part of a RRC signalling providing system information as known in the art, e.g. see LI-55 [0225, 0227, 0236] below, UE determines in RRC layer whether SNPN(s) in the cell support Emergency service by presence or absence of bit indicator for ims-EmergencySupport in SIB1)); and
performing the cell selection to select an acceptable cell of another SNPN supporting the IMS emergency service in response to determining that (1) the UE supports a voice service, (11) the UE is operating in the SNPN AM, and (iii) the selected cell does not support the IMS emergency service for the selected SNPN based on the support indication (
Pages 2-5 Section 2 Discussion
Section 2.1
According to the description in TS 23.700-07, SA2 has achieved the following interim conclusions related the support of IMS voice and emergency service:
…..
- Solution #23 is recommended for normative work to support emergency services with SNPN.
- Solution #56 is recommended for normative work to support SNPN selection for "voice centric" UEs as the result of voice domain selection.
…..
- Once the UE has entered SNPN access mode, SNPN selection is performed as described in clause 8.1.4.
(See clause 8.1.4 in 3GPP TR 23.700-7 V17.0.0 presented below)
Page 4:
Thus, UE in SNPN Access Mode shall stay in any cell selection state if the UE cannot find a suitable cell to camp on, which can refer to the following specification. In R17 eNPN, emergency service is supported for SNPN. It is reasonable that UE in SNPN Access Mode shall attempt to find an acceptable cell when the UE is in any cell selection state.
Page 5:
In order to support emergency service, UE in SNPN Access Mode shall be able to identify whether SNPN(s) can support emergency service or not. According the following description, a bit indicator is enough for nonshared SNPN only cell. But for RAN shared scenario, it is not clear if the preference of SA2 is a group indicator per SNPN or an indicator for all shared SNPN(s).
Actually, there exists same discussion for PLMN case in R9. Finally, an ims-EmergencySupport IE in SIB1 is introduced to indicates whether the cell supports IMS emergency bearer services for UEs in limited service mode. This indicator is set to "support" if any AMF in a non-shared environment or at least one of the PLMN's in a shared environment supports IMS emergency bearer services. It is suggested to follow the design principle of PLMN to avoid repetitive discussion.
Solution #23:
6.23.4 Impacts on services, entities and interfaces
NG-RAN of SNPN
Proposal 3: A bit indicator is introduced in SIB1 to indicate whether SNPN(s) in the cell support Emergency service.
ims-EmergencySupport:
Indicates whether the cell supports IMS emergency bearer services for UEs in limited service mode. If absent, IMS emergency call is not supported by the network in the cell for UEs in limited service mode.
(Construed that selection of SNPN follow the same design principle of PLMN, the SNPN cell broadcasts support for Emergency Service in ims-EmergencySupport IE in SIB1, the selection process of SNPN is to follow 3GPP700 Clause 8.1.4))
Page 4:
Solution #56:
6.56.4 Impacts on services, entities and interfaces
UE:
- the "voice centric" UE should maintain a list of SNPNs where voice service was not possible in SNPN access mode;
- the UE has the subscription for the other PLMN or SNPN, then the UE can register to the PLMN network or the SNPN.
Thus, UE in SNPN Access Mode shall stay in any cell selection state if the UE cannot find a suitable cell to camp on, which can refer to the following specification. In R17 eNPN, emergency service is supported for SNPN. It is reasonable that UE in SNPN Access Mode shall attempt to find an acceptable cell when the UE is in any cell selection state.
3GPP700 discloses -
(Page 105, Clause 6.23.2)
the UE uses either a PLMN 3GPP access (with emergency support), or an SNPN (with emergency support), and if neither are available the UE uses a PLMN non-3GPP access, if available
(Clause 6.23.4)
UE
- Support procedures described in TS 23.501 [4] for emergency services when in SNPN access mode
(Pages 239-240, Clause 8.1.4
Conclusions on SNPN selection for UEs with an SNPN subscription)
- For a UE configured to use SNPNs, automatic SNPN selection is performed in the following order:
…….
- If the UE is unable to find a suitable cell of any available and allowable SNPN based on the above, the UE attempts to camp on an acceptable cell of any available SNPN supporting emergency calls (irrespective of SNPN ID) or of any available PLMN (irrespective of PLMN ID), in limited service state.
- The UE continues automatic SNPN selection based on the above until a suitable cell is found ….
(It is obvious from VIVO, with evidence by 3GPP700, that for UE supporting voice service and operating in SNPN AM, if the current cell does not support IMS emergency service, UE to select an acceptable cell of another SNPN supporting the IMS emergency service)).
VIVO, with evidence by 3GPP700, does not explicitly disclose forwarding, from the RRC layer to a non-access stratum (NAS) layer of the UE, the support indication in response to determining that the support indication indicates that the selected SNPN supports the IMS emergency service.
In an analogous art, LI-55 teaches forwarding, from the RRC layer to a non-access stratum (NAS) layer of the UE, the support indication in response to determining that the support indication indicates that the selected SNPN supports the IMS emergency service (
Fig. 12,
[0223] In another implementation, in response to the UE requiring an IMS or eCall service and a current cell not supporting the IMS or eCall service, the RAN sends the dedicated RRC signaling so as to redirect the UE to a target frequency or a cell that supports the IMS or eCall service.
[0224] In another implementation, in response to an upper layer of the UE indicating the IMS voice or the eCall, a lower layer of the UE only selects or reselects a cell supporting the IMS voice or the eCall.
Fig. 13,
[0225] Referring to FIG. 13, the present disclosure describes various embodiments of a method 1300 for supporting, by a radio access network (RAN), an enhanced non-public network (eNPN). The method 1300 includes a portion or all of the following step: step 1310: sending, by the RAN, an indication in a RRC signaling to a user equipment (UE), wherein the indication indicates whether to support at least one of the following for an non-public network: an internet protocol (IP) multimedia subsystem (IMS) voice, or an emergency call (eCall).
[0227] In another implementation, the RRC signaling comprises at least one of the following: a system information ....
[0229] when USIM is available in UEs accessing IMS via an SNPN; …. it may support emergency services with SNPN; and/or it may support SNPN selection for “voice centric” UEs as the result of voice domain selection.
[0231] In one implementation, for the emergency supporting, there may have some impact on the system Information broadcasting. For the emergency supporting, without the network sharing, in the current system Information the following two parameters may be reused for the SNPN network:
PNG
media_image1.png
200
400
media_image1.png
Greyscale
wherein:
[0232] eCallOverIMS-Support
[0233] Indicates whether the cell supports eCall over IMS services as defined in TS 23.501 [32]. If absent, eCall over IMS is not supported by the network in the cell.
[0234] ims-EmergencySupport
[0235] Indicates whether the cell supports IMS emergency bearer services for UEs in limited service mode. If absent, IMS emergency call is not supported by the network in the cell for UEs in limited service mode.
[0236] In another implementation, once the UE receives these two bits in the SIB1, the UE may forward them to the NAS layer: forward the ims-EmergencySupport to upper layers, if present; or forward the eCallOverlMS-Support to upper layers, if present.
(It is obvious, that UE determines in RRC layer that ims-Emergency is supported by SNPN network when the corresponding optional bits are present in SIB1 as in VIVO, and then explicitly disclose that the support indication forwarded from RRC layer to NAS layer,
and when UE supporting voice service and operating in SNPN AM, if the current cell does not support IMS emergency service, UE to select an acceptable cell of another SNPN supporting the IMS emergency service)).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to take the technique of processing IMS emergency service support by UE of LI-055 to system of supporting IMS voice and emergency service for SPSN of VIVO with evidence by 3GPP700 in order to take the advantage of providing a method for enhancing the support for SNPN along with subscription/credentials owned by an entity separate from the SNPN, the support UE onboarding and provisioning for non-public networks, and the support for voice or internet protocol (IP) multimedia subsystem (IMS) emergency services for SNPN. (LI-055: [0003]).
Regarding claim 2, VIVO with evidence by 3GPP700, in view of LI-55, teaches the method of claim 1, wherein the support indication indicates whether the selected SNPN supports the IMS emergency service over a next-generation radio access network (NG-RAN) (Page 5:
Solution #23:
6.23.4 Impacts on services, entities and interfaces
NG-RAN of SNPN
Include related broadcast indicator that the cell supports Emergency Services over NG-RAN for UEs in limited service state, and if the NG-RAN is shared by more than one network, and the networks do not have the same support for Emergency Services, the broadcast indicator is related to those networks that supports Emergency Services.
Proposal 3: A bit indicator is introduced in SIB1 to indicate whether SNPN(s) in the cell support Emergency service).
Regarding claim 3, VIVO with evidence by 3GPP700, in view of LI-55, teaches the method of claim 1, wherein the selected SNPN operates the selected cell (Page 5:
In R16, it is common understanding that UE in SNPN Access Mode only selects SNPNs. From our understanding, it is also applied to the case that UE in SNPN Access Mode finds an acceptable cell.
Proposal 2: In Any cell selection state, UE in SNPN Access Mode shall attempt to find an acceptable cell of any SNPN to camp on.).
Regarding claim 4, VIVO with evidence by 3GPP700, in view of LI-55, teaches the method of claim 1, wherein the UE is operated in a normal service state for the selected cell, and the support indication is carried in at least one of a NAS message in a registration procedure or system information (Page 4, Section 2.3 Support of emergency service for SNPN:
Solution #23:
- AMF of SNPN needs include an indication for Emergency Services Support within the Registration Accept to the UE also for UE in SNPN access mode;
- NG-RAN of SNPN needs to support related broadcast indicator that the cell supports Emergency Services over NG-RAN in order to support UEs in limited service state.
The functionality that is already described in TS 23.501 [4] clause 5.16.4.1 for PLMN access, need to apply to SNPN NG-RAN, 5GC belonging to SNPN and UE operating in SNPN access mode.
The functionality that is already described in TS 23.501 [ 4] clause 5 .16.4.1 for PLMN access, need to apply to SNPN NG-RAN, 5GC belonging to SNPN and UE operating in SNPN access mode.
Observation 4: In normal service state, the support of emergency service for SNPN is handled by NAS.
(TS 23.501v16.8.0, of IDS, Pages 215-216, clause 5.16.4.1, disclosing When the UE is camped normally in the cell, i.e. not in limited service state, during Registration procedure described in TS 23.502 [3] clause 4.2.2.2, the serving AMF includes an indication for Emergency Services Support within the Registration Accept to the UE.)).
Regarding claim 6, VIVO with evidence by 3GPP700, in view of LI-55, teaches the method of claim 1, wherein the UE is operated in a limited service state for the selected cell, and the support indication is carried in System Information Block 1 (SIB1) (Page 5,
Solution #23:
NG-RAN of SNPN
Include related broadcast indicator that the cell supports Emergency Services over NG-RAN for UEs in limited service state, and if the NG-RAN is shared by more than one network, and the networks do not have the same support for Emergency Services, the broadcast indicator is related to those networks that supports Emergency Services.
Proposal 3: A bit indicator is introduced in SIB1 to indicate whether SNPN(s) in the cell support Emergency service.).
Regarding claim 8, VIVO with evidence by 3GPP700, in view of LI-55, teaches the method of claim 1, further comprising:
determining that the selected SNPN does not support the IMS emergency service for the UE in a limited service state when the support indication indicating that the selected SNPN supports the IMS emergency service is absent (Page 5:
Actually, there exists same discussion for PLMN case in R9. Finally, an ims-EmergencySupport IE in SIB1 is introduced to indicates whether the cell support IMS emergency bearer services for UEs in limited service mode. This indicator is set to "support" if any AMF in a non-shared environment or at least one of the PLMN's in a shared environment support IMS emergency bearer services. It is suggested to follow the design principle of PLMN to avoid repetitive discussion.
Proposal 3: A bit indicator is introduced in SIB1 to indicate whether SNPN(s) in the cell support Emergency service.
ims-EmergencySupport:
Indicates whether the cell supports IMS emergency bearer services for UEs in limited service mode. If absent, IMS emergency call is not supported by the network in the cell for UEs in limited service mode.).
Regarding claim 11, VIVO teaches a user equipment (UE) (Page 2 Section 2.1: UE), comprising:
a transceiver, used for transmitting and/or receiving signals, at least one non-transitory machine readable medium storing one or more computer-executable instructions, and at least one processor coupled to the transceiver and the at least one non-transitory machine readable medium and configured to execute the one or more computer-executable instructions (Page 2 Section 2 Discussion
Section 2.1 Conclusions in SA2
…. Conclusions related to the support of IMS voice and emergency service
8.1.4 Conclusions on SNPN selection for UEs with an SNPN subscription
- The use of IMC shall be possible when USIM or ISIM is not available in UEs accessing IMS via an SNPN according to Solution #21.
- The reuse of USIM credentials for IMS AKA shall be possible when USIM is available in UEs accessing IMS via an SNPN.
(Construed that UEs, inherently, comprising a transceiver, used for transmitting or receiving signals, a memory, used for storing a program code, and a processor, coupled to the transceiver and the memory, configured to load and execute the program code to perform accessing IMS via an SNPN for communication)).
Further claim 11 is interpreted mutatis mutandis of claim 1 and rejected for the same reason as set forth for claim 1.
Regarding claim 12, the claim is interpreted and rejected for the same reason as set forth for claim 2.
Regarding claim 13, the claim is interpreted and rejected for the same reason as set forth for claim 3.
Regarding claim 14, the claim is interpreted and rejected for the same reason as set forth for claim 4.
Regarding claim 16, the claim is interpreted and rejected for the same reason as set forth for claim 6.
Regarding claim 18, the claim is interpreted and rejected for the same reason as set forth for claim 8.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Vivo (R2-2100840 “Support of IMS voice and emergency service for SNPN”, of IDS, hereinafter ‘VIVO’), with evidence by 3GPP TR 23.700-7 V17.0.0, of record, hereinafter ‘3GPP700’, in view of Li et al. (US 20230363055 A1 with priority of PCT/CN2021/071730, of record, hereinafter ‘LI-55’) and with further in view of Qualcomm et al. (S2-2102765 “Support for IMS emergency services over SNPN”, of IDS, hereinafter ‘QUALCOMM’).
Regarding claim 5, VIVO with evidence by 3GPP700, in view of LI-55, teaches the method of claim 1.
VIVO with evidence by 3GPP700 and LI-55, do not explicitly disclose transmitting an RRC message having a RRC establishment cause or a RRC resume cause which is set as emergency.
In an analogous art, QUALCOMM teaches transmitting an RRC message having a RRC establishment cause or a RRC resume cause which is set as emergency (Page 4:
The UE shall set the RRC establishment cause to emergency as defined in TS 38.331 [28] when it requests an RRC Connection in relation to an emergency session.).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to take the technique of emergency service request by UE of QUALCOM to system of supporting IMS voice and emergency service for SPSN of VIVO with evidence by 3GPP700 and LI-55 in order to take the advantage of providing a method for receiving Emergency Services from PLMN or SNPN (QUALCOMM: Pages 2 and 4).
Regarding claim 15, the claim is interpreted and rejected for the same reason as set forth for claim 5.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Vivo (R2-2100840 “Support of IMS voice and emergency service for SNPN”, of IDS, hereinafter ‘VIVO’), with evidence by 3GPP TR 23.700-7 V17.0.0, of record, hereinafter ‘3GPP700’, in view of Li et al. (US 20230363055 A1 with priority of PCT/CN2021/071730, of record, hereinafter ‘LI-55’) and with further in view of Takahashi et al. (EP 4106367 A1, of record, hereinafter ‘TAKAHASHI’).
Regarding claim 7, VIVO with evidence by 3GPP700, in view of LI-55, teaches the method of claim 6. wherein the UE is operated in the limited service when the UE is unable to find a suitable cell during the cell selection, and the UE has at least one of emergency services (Page 4:
Observation 5: In limited service state, UE should be informed about if a cell support emergency service over NG-RAN of SNPN.
Next, we will focus on the support of emergency service in limited service state.
In R16 NPN, UE in SNPN Access Mode shall not initial emergency service. Moreover, emergency service bearer and ETWS/CMAS are not supported in SNPN. Thus, UE in SNPN Access Mode shall stay in any cell selection state if the UE cannot find a suitable cell to camp on, which can refer to the following specification. In R17 eNPN, emergency service is supported for SNPN. It is reasonable that UE in SNPN Access Mode shall attempt to find an acceptable cell when the UE is in any cell selection state.).
VIVO with evidence by 3GPP700 and LI-55 do not explicitly disclose the UE has at least one of emergency services, earthquake and tsunami warning system (ETWS), and commercial mobile alerting system (CMAS), all of which are received from the selected cell.
In an analogous art. TAKAHASI teaches the UE has at least one of emergency services, earthquake and tsunami warning system (ETWS), and commercial mobile alerting system (CMAS), all of which are received from the selected cell (
[0031] In addition, the cells formed by the gNB 100A to the gNB 100C may be classified into any of the following.
- Acceptable cell: A cell in which the UE 200 camps and acquires limited service (may be called a cell that provides the limited service, the same applies hereinafter). The limited service may include broadcasting of emergency information by ETWS/CMAS.
- Suitable cell: A cell that constitutes a selected or registered PLMN or a cell that constitutes a PLMN of an equivalent PLMN list.
- Non-suitable cell: A cell that is included in NPN (including SNPN) and is not a suitable cell. Even in the non-suitable cell, the UE 200 may camp and acquire the limited service.
Fig. 4, [0077] "For UE operating in SNPN Access Mode, if no suitable SNPN cell is available, UE shall camp to a non-suitable SNPN cell as an acceptable cell to obtain limited service (receive ETWS and CMAS notifications.)."
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to take the technique of emergency service reception of TAKAHASHI to system of supporting IMS voice and emergency service for SPSN of VIVO with evidence by 3GPP700 and LI-55 with evidence by 3GPP700 in order to take the advantage of providing a method for receiving broadcasted emergency Information (which may be called emergency notification) using the Earthquake and Tsunami Warning System (ETWS) or the Commercial Mobile Alert System (CMAS) similarly to PLMN (TAKAHASHI: [0006, 0077]).
Regarding claim 17, the claim is interpreted and rejected for the same reason as set forth for claim 7.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Vivo (R2-2100840 “Support of IMS voice and emergency service for SNPN”, of IDS, hereinafter ‘VIVO’), with evidence by 3GPP TR 23.700-7 V17.0.0, of record, hereinafter ‘3GPP700’, in view of Li et al. (US 20230363055 A1 with priority of PCT/CN2021/071730, of record, hereinafter ‘LI-55’) and with further in view of Wang et al. (US 20230189191 A1 with priority of us-provisional-application US 63028191, of record, hereinafter ‘WANG’).
Regarding claim 9, VIVO with evidence by 3GPP700, in view of LI-55, teaches the method of claim 1.
VIVO with evidence by 3GPP700 and LI-55, do not explicitly disclose deactivating the SNPM AM when the acceptable cell of the other SNPN is absent from the cell selection.
In an analogous art, WANG teaches deactivating the SNPM AM when the acceptable cell of the another SNPN is absent from the cell selection ([0080] An SNPN capable WTRU may be in an SNPN access mode to access an SNPN, and an SNPN capable WTRU may exit SNPN access mode to access a PLMN. The details of activation and deactivation of an SNPN access mode at a WTRU may vary among WTRU implementations.
[0117] the WTRU has deactivated SNPN access mode (e.g., due to loss of SNPN coverage ...).
See also US 63028191 [0076-0077, 0105].
(It is obvious that loss of SNPN coverage indicate absences of any acceptable SNPN cell outside coverage area)).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to take the technique of emergency service reception of WANG to system of supporting IMS voice and emergency service for SPSN of VIVO with evidence by 3GPP700 and LI-55 in order to take the advantage of providing a method for receiving any service through PLMN using different access mode (WANG: [0117]).
Regarding claim 19, the claim is interpreted and rejected for the same reason as set forth for claim 9.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Zhang; Yanxia (US 20230137356 A1), describing CONTROL METHOD AND APPARATUS FOR OBTAINING EMERGENCY SERVICE, TERMINAL, AND READABLE STORAGE MEDIUM
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAH M RAHMAN whose telephone number is (571)272-8951. The examiner can normally be reached 9:30AM-5:30PM PST.
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, UN C CHO can be reached at 571-272-7919. 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.
/SHAH M RAHMAN/Primary Examiner, Art Unit 2413