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 .
Summary
This action is in reply to Applicant's Amendments and Remarks filed on 06/29/2026.
Claims 1-9 and 11-19 are pending.
Claims 10 and 20 are cancelled.
Response to Arguments
Applicant's arguments dated 06/29/2026 with respect to claims 1-9 and 11-19 have been considered but they are moot as they are not applicable to the combination of prior arts used in this 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 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’) and with further in view of Liang et al. (US 20230080088 A1, of record, hereinafter ‘LIANG’).
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.);
receiving support indications in response to the cell selection, support indications indicates whether the corresponding network supports an internet protocol (IP) multimedia subsystem (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. 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.); 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
receiving a plurality of support indications in response to the cell selection, wherein each of the plurality of support indications corresponds to a respective network of a plurality of networks operating the selected cell, and each of the plurality of support indications indicates whether the respective network supports an internet protocol (IP) multimedia subsystem (IMS) emergency service;
selecting, from the plurality of support indications, a support indication that corresponds to the selected SNPN, wherein the support indication indicates whether the selected SNPN supports the IMS emergency service;
forwarding, from a radio resource control (RRC} layer of the UE, 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 a radio resource control (RRC} layer of the UE, 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-55 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-55: [0003]).
VIVO, with evidence by 3GPP700, and LI-55 do not explicitly disclose
receiving a plurality of support indications in response to the cell selection, wherein each of the plurality of support indications corresponds to a respective network of a plurality of networks operating the selected cell, and each of the plurality of support indications indicates whether the respective network supports an internet protocol (IP) multimedia subsystem (IMS) emergency service;
selecting, from the plurality of support indications, a support indication that corresponds to the selected SNPN, wherein the support indication indicates whether the selected SNPN supports the IMS emergency service.
In an analogous art, LIANG teaches receiving a plurality of support indications in response to the cell selection, wherein each of the plurality of support indications corresponds to a respective network of a plurality of networks operating the selected cell, and each of the plurality of support indications indicates whether the respective network supports an internet protocol (IP) multimedia subsystem (IMS) emergency service (
Fig. 1, [0044] FIG. 1 shows a schematic diagram of an application scenario according to an embodiment of the disclosure. As shown, the SNPN and the PLMN are connected to a same base station, which can be called a shared base station. …. different PLMNs and SNPNs correspond to different network identifiers…
Fig. 2, [0048] FIG. 2 shows a flowchart of an indication method for an IMS emergency service state according to an embodiment of the disclosure. The process includes: following steps.
[0049] S201: a base station connected to an SNPN and a PLMN sends system information of a serving cell, where the system information includes first indication information for indicating whether the SNPN supports an IMS emergency service and second indication information for indicating whether the PLMN supports the IMS emergency service.
[0050] In this step, the number of SNPNs may be one or more, and the number of PLMNs may also be one or more. The system information sent by the base station includes the first indication information for indicating whether the SNPN supports the IMS emergency service and the second indication information for indicating whether the PLMN supports the IMS emergency service, so that the support state of the PLMN for the IMS emergency service and the support state of the SNPN for the IMS emergency service can be respectively indicated in the system information.
[0051] S202: a terminal within coverage of the base station receives the system information, and determines whether to allow an IMS emergency service request to be initiated on the SNPN or PLMN according to the system information.
[0052] The terminal working in the SNPN mode within the coverage of the base station receives the system information sent by the base station, and determines whether to allow the IMS emergency service to be initiated on the SNPN according to the first indication information in the system information.);
selecting, from the plurality of support indications, a support indication that corresponds to the selected SNPN, wherein the support indication indicates whether the selected SNPN supports the IMS emergency service (
[0053] When the terminal working in the SNPN mode needs to initiate an IMS emergency service request, the terminal sends the IMS emergency service request to the serving base station if it is determined according to the received first indication information that the SNPN connected to the serving base station of the terminal supports the IMS emergency service. The terminal gives up initiating the IMS emergency service request if it is determined according to the received first indication information that the SNPN connected to the serving base station of the terminal does not support 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 indication for an IP Multimedia Subsystem (IMS) emergency service state SNMN mode when camping on a shared cell of LIANG 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 enabling the terminal working in the SNPN mode to obtain the support state of the SNPN for the IMS emergency service for each of the plurality of networks sharing the cell (LIANG: [0004, 0005, 0047]).
Regarding claim 2, VIVO with evidence by 3GPP700, in view of LI-55 and LIANG, 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 and LIANG, 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 and LIANG, 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 and LIANG, 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 and LIANG, 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’) in view of Liang et al. (US 20230080088 A1, of record, hereinafter ‘LIANG’) 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 and LIANG, teaches the method of claim 1.
VIVO with evidence by 3GPP700, LI-55 and LIANG, 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, LI-55 and LIANG 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’) in view of Liang et al. (US 20230080088 A1, of record, hereinafter ‘LIANG’) 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 and LIANG, 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, LI-55 and LIANG 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, LI-55 and LIANG 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’) in view of Liang et al. (US 20230080088 A1, of record, hereinafter ‘LIANG’) 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 and LIANG, teaches the method of claim 1.
VIVO with evidence by 3GPP700, LI-55 and LIANG, 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, LI-55 and LIANG 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:
Chandramouli et al. (GB 2605771 A), describing Method, Apparatus And Computer Program
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights