DETAILED ACTION
The Amendments and Remarks filed 4/23/2026 were received.
PRIOR ART
The following references are prior art:
1. (3/14/2024 IDS) US 2019/0029065 A1 (“Park”) is prior art under 35 U.S.C. 102(a)(1) since it was published on Jan. 24, 2019 before Aug. 4, 2020 the effective filing date of the claimed invention. Park was also cited as D1 against the corresponding European application and an application within Park’s family was cited as D1 against the corresponding international application.
2. (6/27/2025 PTO-892) Appl. No.: 17/713,103 (“Kim”) is prior art under 35 U.S.C. 102(a)(2) since it published as US 2022/0232507 A1, names another inventor Sunhee Kim, and was effectively filed May 25, 2020 before Aug. 4, 2020 the effective filing date of the claimed invention.
CLAIM REJECTIONS — 35 U.S.C. 112
The following is a quotation of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention
Claims 1-2,4,6-7,11-14,17 and 19-20 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Lack of support regarding the destination access management node
Claim 1 recites “setting, by the communication device, the at least one piece of requested network slice information in a radio access control message, to allow a radio access node to select a destination access management node supporting the at least one piece of requested network slice information, wherein the radio access control message does not comprise at least one piece of information relevant to the destination access management node” (emphasis added). Claim 1 is limited to the message not comprising information relevant to the destination access management node that supported the slice information and was allowed to be selected. The Specification does not support this limitation.
The closest support is at page 10-11 of the Specification:
Accordingly, if the network slice information corresponding to the rejection information is rejected due to the network slice supportability of the processing access management node, the operations above can allow the communication device to reach another access management node for requesting service.
In one embodiment, the radio access control message described above does not include at least one piece of information relevant to a destination access management node. In one embodiment, the at least one piece of information relevant to a destination access management includes at least one of 5G-S-TMSI and Globally Unique AMF ID (GUAMI), but is not limited in this regard.
Through such a configuration, it can be avoided the radio access control message being directed to the same access management node that rejects the at least one piece of information corresponding to the rejection information in previous operations.
To summarize, the Specification disclosed that if an access management node rejects slice information, another access management node can be reached and to do so the UE does not get the TMSI or AMF ID of the AMF that rejected. Specifically, the message does not include information relevant to the rejecting AMF (not the new destination AMF).
The Specification is open when it states “the radio access control message described above does not include at least one piece of information relevant to a destination access management node.” It does not use the term “the” to refer to a specific destination access management node, and certainly not the actual destination access management node that supports the requested slice information. Accordingly, this limitation lacks written description support.
Independent claims 7 and 13 recite similar limitations and lack written description support by similar reasoning. The dependent claims lack written description support by virtue of their dependency.
CLAIM REJECTIONS — 35 U.S.C. 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
35 U.S.C. 102 Conditions for patentability; novelty.
(a) NOVELTY; PRIOR ART.—A person shall be entitled to a patent unless—
(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention;
CLAIMS 1, 2, 6, 7, 11-14, 19 AND 20
Claims 1, 2, 6, 7, 11-14, 19 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Park for the reasons given below.
Claim 1
With respect to claim 1, Park disclosed:
A wireless communication method (Park taught [Abstract] a method for a user equipment to update a policy in a wireless communication system may include transmitting a first registration request message to an access and mobility management function (AMF). [0042] FIG. 17 is a flowchart illustrating a registration procedure according to Invention Proposal 2 of this specification. [0631] FIG. 19 is a flowchart illustrating a registration procedure/method of a UE according to the proposal 2 of the present invention.)
comprising: receiving, by a communication device, rejection information corresponding to at least one piece of network slice information, wherein the rejection information comprises a rejection cause corresponding to slice incompatible information ([0576] Invention Proposal 2. Processing of Rejected S-NSSAI [0577] As described in Problem 2, at least some S-NSSAI of the requested NSSAIs of the UE is not allowed by a network and may not be included in the allowed NSSAI. [0596] When a network determines whether to allow S-NSSAIs requested by a UE, the network may use the current location (e.g., served location)/area (e.g., current registration area) of the UE as criteria for determination. There may be a case where the use of a specific slice in a specific location/area/region is impossible or the use of a slice is possible only in a specific location/area/region regardless of whether to allow a slice in a PLMN. [0597] If the network rejects an S-NSSAI for a specific location/area/region ( e.g., registration area or AMF area) for such a reason, the network may provide the UE with such a Reject Cause (e.g., the S-NSSAI is not available in a current registration area). For example, the network may provide the UE with a Reject Cause including/indicating an S-NSSAI not allowed/available in a current registration area. [0598] To this end, the network may deliver rejection-related information to the UE through a field/information element (IE), such as a Reject NSSAI or non-allowed NSSAI, in addition to an allowed NSSAI through a Registration Accept or registration Reject message. For example, the network may include an allowed (S-)NSSAI, a rejected/non-allowed (S-)NSSAI and/or a Reject Cause in a specific field/IE within the Registration Accept or registration Reject message, and may deliver the message to the UE. [0605] There may be a case where one AMF cannot server all of multiple S-NSSAIs requested by a UE at the same time. For example, if the AMF! can support #1, #2 and #4 S-NSSAIs and the AMF2 can support #2, #3 and #5 S-NSSAIs, when a UE requests the #1, #2 and #3 S-NSSAIs as requested NSSAIs, a network may have to reject the #3 S-NSSAI (i.e., AMF! selection) or the #1 S-NSSAI (i.e., AMF2 selection) depending on AMF selection. That is, the network may perform rejection for a specific S-NSSAI depending on a supportable S-NSSAI of a selected serving AMF. Accordingly, in this case, if the UE has moved to a different registration area or a different AMF has been selected, the UE needs to be able to request a rejected S-NSSAI again. [0616] 4a. If an S-NSSAI included in a configured NSSAI has been permanently rejected with respect to a corresponding/current PLMN or all of PLMNs, the UE may update a configured NSSAI list. For example, the UE may remove/ delete the rejected S-NSSAI from the configured NSSAI list. [0606] Or there may be a case where the AMF may serve all of S-NSSAIs requested by a UE, but specific S-NSSSAIs are configured by a network operator so that the specific S-NSSSAIs cannot be served/used at the same time. [0607] If the network determines such co-existence information and determines an S-NSSAI to be allowed (at a current occasion) and an S-NSSAI to be not allowed, it may provide the UE with Reject-related information with respect to the S-NSSAI to be not allowed. That is, the network may provide the UE with information (e.g., not co-existable with other S-NSSAIs) indicating that a Reject Cause for (currently) rejected S-NSSAIs is not co-existable with other S-NSSAIs. [0613] 1. A UE requests a requested NSSAI through a registration procedure. To this end, the UE may transmit the requested NSSAI to the AMF through a registration request. [0615] 3. The AMF may transmit non-allowed/rejected NSSAI information, including non-allowed S-NSSAIs (i.e., rejected S-NSSAIs), a Reject Cause and/or Reject-related additional information in addition to an allowed NSSAI, to the UE. The Examiner finds that Park disclosed receiving, by a communication device (i.e., by the UE), rejection information (i.e., the registration reject message) corresponding to at least one piece of network slice information (i.e., S-NSSAIs requested by a UE,), wherein the rejection information comprises a rejection cause (i.e., the Reject Cause) corresponding to slice incompatible information (e.g., the use of a specific slice in a specific location/area/region is impossible, and/or the requested S-NSSAIs cannot be used at the same time));
and transmitting, by the communication device, a registration request comprising a requested network slice information, wherein the requested network slice information comprises the at least one piece of network slice information corresponding to the received rejection information, wherein the registration request is transmitted in response to the rejection cause, and wherein the rejection cause comprises an indication that the at least one piece of network slice information is supported within a current wireless service area and not compatible with an allowed network slice information ([0596] When a network determines whether to allow S-NSSAIs requested by a UE, the network may use the current location (e.g., served location)/area (e.g., current registration area) of the UE as criteria for determination. There may be a case where the use of a specific slice in a specific location/area/region is impossible or the use of a slice is possible only in a specific location/area/region regardless of whether to allow a slice in a PLMN. For example, in the case of the local area network slice, the UE may be connected to a slice that may be served only within a specific registration area or a configured area over a local area data network (LADN). [0597] If the network rejects an S-NSSAI for a specific location/area/region ( e.g., registration area or AMF area) for such a reason, the network may provide the UE with such a Reject Cause (e.g., the S-NSSAI is not available in a current registration area). For example, the network may provide the UE with a Reject Cause including/indicating an S-NSSAI not allowed/available in a current registration area or an S-NSSAI not allowed/available in a current LADN area. [0599] The UE may write/store a Reject/restriction cause ( e.g., a local area/registration area/AMF) for each rejected S-NSSAI and/or descriptor/identity information thereof ( e.g., an LADN corresponding to the rejected S-NSSAI, a registration area ID, the AMF ID) in the list. [0600] If a UE has moved to a new area/location/region (i.e., if the UE has deviated from a current registration area in which an S-NSSAI has been rejected), the UE may check whether the reattempt of a request for the S-NSSAI rejected in the area/location/region before the movement is possible with reference to the list (i.e., rejected/forbidden NSSAI). For example, if the rejection of an S-NSSAI is given in a registration Area Unit and the UE has Moved to Another Registration Area (i.e., if the UE has deviated from a current registration area in which the S-NSSAI has been rejected), the UE may reattempt a request to use the S-NSSAI rejected in the previous registration area in the new registration area. [0605] There may be a case where one AMF cannot server all of multiple S-NSSAIs requested by a UE at the same time. For example, if the AMF! can support #1, #2 and #4 S-NSSAIs and the AMF2 can support #2, #3 and #5 S-NSSAIs, when a UE requests the #1, #2 and #3 S-NSSAIs as requested NSSAIs, a network may have to reject the #3 S-NSSAI (i.e., AMF! selection) or the #1 S-NSSAI (i.e., AMF2 selection) depending on AMF selection. That is, the network may perform rejection for a specific S-NSSAI depending on a supportable S-NSSAI of a selected serving AMF. Accordingly, in this case, if the UE has moved to a different registration area or a different AMF has been selected, the UE needs to be able to request a rejected S-NSSAI again. [0616] 4a. If an S-NSSAI included in a configured NSSAI has been permanently rejected with respect to a corresponding/current PLMN or all of PLMNs, the UE may update a configured NSSAI list. For example, the UE may remove/ delete the rejected S-NSSAI from the configured NSSAI list. [0606] Or there may be a case where the AMF may serve all of S-NSSAIs requested by a UE, but specific S-NSSSAIs are configured by a network operator so that the specific S-NSSSAIs cannot be served/used at the same time. [0607] If the network determines such co-existence information and determines an S-NSSAI to be allowed (at a current occasion) and an S-NSSAI to be not allowed, it may provide the UE with Reject-related information with respect to the S-NSSAI to be not allowed. That is, the network may provide the UE with information (e.g., not co-existable with other S-NSSAIs) indicating that a Reject Cause for (currently) rejected S-NSSAIs is not co-existable with other S-NSSAIs. [0617] 4b. If an S-NSSAI has not been permanently rejected, but has been temporarily rejected due to each PLMN, each area, a specific time ( e.g., backoff time) and/or impossible co-existence with other S-NSSAIs, the UE may update a "non-allowed/NSSAI restricted/rejected/forbidden" NSSAI list for managing them. [0618] 5. A restriction condition (or the current situation/condition of the UE) of the restriction list updated in 4b step may be changed, and thus restriction may be alleviated ( e.g., the UE moves to another registration area or a backoff timer expires) [0619] 6a/6b. The UE may include the previously rejected S-NSSAI in a registration request and start a registration procedure again. If rejection based on an area has been received, the UE may transmit a request to a new AMF changed due to the AMF change event. [FIG. 17] 6.b Registration Request from UE to (new) AMF). The Examiner finds that Park disclosed transmitting by the communication device, a registration request (FIG. 17, 6b Registration request) comprising a requested network slice information, wherein the requested network slice information comprises the at least one piece of network slice information corresponding to the received rejection information (i.e., the UE may include the previously rejected S-NSSAI in a registration request), wherein the registration request is transmitted in response to the rejection cause (i.e., the UE sends registration request at FIG. 17(6b) to the new AMF because the registration accept with rejection cause for non-allowed NSSAI at FIG. 17(3) from the old AMF was received), and wherein the rejection cause comprises an indication that the at least one piece of network slice information is supported within a current wireless service area and not compatible with an allowed network slice information (i.e., the AMF can support S-NSSAI #1 and #2 but not at the same time and/or the AMF cannot support one of the requested S-NSSAIs but the rejection cause does not indicate that the rejected NSSAI is not allowed/available the Local Area Data Network (LADN));
setting, by the communication device, the at least one piece of requested network slice information in a radio access control message, to allow a radio access node to select a destination access management node supporting the at least one piece of requested network slice information, wherein the radio access control message does not comprise at least one piece of information relevant to the destination access management node, the radio access control message does not comprise at least one piece of information relevant to the destination access management node such that the radio access control message being directed to the same access management node that rejects the at least one piece of information corresponding to the rejection information in previous operations is avoided ([0081] Public Land Mobile Network (PLMN): a network formed to provide mobile communication services to individuals. The PLMN can be formed separately for each operator. [0466] When a UE receives an NSSAI configured with respect to a selected PLMN, the UE needs to include the NSSAI in RRC connection establishment and NAS. An RAN routes initial access to the AMF using the received NSSAI. [0435] A configured NSSAI may be configured in a UE by a home PLMN (HPLMN) for each PLMN. The Configured SSAI becomes PLMN-specific. and the HPLMN indicates a PLMN(s) to which each Configured NSSAI has been applied. [0469] When registration is successfully performed, a UE is provided with a globally unique temporary UE identity (GUTI) by a serving AMF. The UE includes a local unique temporary ID in RRC connection establishment during subsequent initial access so that an RAN whose Temp ID is valid can route an NAS message to a suitable AMF. [0588] If the requested S-NSSAI of the UE included in the configured NSSAI is rejected along with a permanent Reject Cause, the UE may delete the rejected S-NSSAI from the configured NSSAI (list). [0594] After the procedure is performed, the UE can no longer request the (permanently) rejected S-NSSAI from the network (i.e., the UE may not attempt to use the (permanently) rejected S-NSSAI) in a next registration procedure. [0599] If the S-NSSAI has been rejected in a specific location/area/region as described above, the UE may manage the rejected S-NSSAI as a separate list. The list may have a form, such as a temporary Reject NSSAI, an NSSAI restriction list or a rejected/forbidden NSSAI. The UE may write/store a Reject/restriction cause ( e.g., a local area/ registration area/AMF) for each rejected S-NSSAI and/or descriptor/identity information thereof ( e.g., an LADN corresponding to the rejected S-NSSAI, a registration area ID, the AMF ID) in the list. [0616] 4a. If an S-NSSAI included in a configured NSSAI has been permanently rejected with respect to a corresponding/current PLMN or all of PLMNs, the UE may update a configured NSSAI list. For example, the UE may remove/ delete the rejected S-NSSAI from the configured NSSAI list. [0619] 6a/6b. The UE may include the previously rejected S-NSSAI in a registration request and start a registration procedure again. If rejection based on an area has been received, the UE may transmit a request to a new AMF changed due to the AMF change event. [FIG. 17] 6.b Registration Request from UE to (new) AMF). The Examiner finds that Park disclosed setting, by the communication device, the at least one piece of requested network slice information in a radio access control message (i.e., RRC is used for Registration with an AMF, and the UE sets Registration Request 6b in FIG. 17 with requested S-NSSAI in RRC), to allow a radio access node to select a destination access management node supporting the at least one piece of requested network slice information (i.e., the new AMF in FIG. 17 is selected as the destination access manage node), wherein the radio access control message does not comprise at least one piece of information relevant to the destination access management node such that the radio access control message being directed to the same access management node that rejects the at least one piece of information corresponding to the rejection information in previous operations is avoided (i.e., Park implies that the registration request 6b in FIG. 17 does not include the AMF ID of the old AMF (which sent the rejection) in the new RRC message with the Registration Request at 6b such that the old AMF is avoided. The AMF IDs of the AMFs in a PLMN being relevant to each other. The message 6b goes to the new AMF not the old AMF. The message to the new AMF would include the new AMF ID and not the old AMF ID. See MPEP 2144.01 on Implicit Disclosure.))
Claim 2
With respect to claim 2, Park disclosed:
The wireless communication method of claim 1 (see rejection above),
wherein the at least one piece of network slice information comprises at least one piece of Single-Network Slice Selection Assistant Information (S-NSSAI) (Park taught [0633] the UE may receive a Registration Accept message from the AMF as a response to the registration request message (S1920). In this case, if at least one of S-NSSAIs included in the requested NSSAI has been rejected by the AMF, the Registration Accept message may include a Reject Cause for the rejected S-NSSAI along with the rejected S-NSSAI)
and the method further comprises: deriving, by the communication device, at least one piece of requested network slice information for an application based on route selection rules or a local configuration (Park [0450] The NSSP associates the UE with an S-NSSAI and is used by the UE in order to determine a PDU session to which traffic will be routed. [0451] A network slice selection policy is provided for each application of a UE. This includes a rule by which an S-NSSAI can be mapped for each UE application. [0515] The establishment of a PDU session with a DN in a network slice allows data transmission in a network slice. A data network is associated with an S-NSSAI and a DNN. [0516] A network operator may provide a UE with a network slice selection policy (NSSP). The NSSP includes one or more NSSP rules. Each NSSP rule associates a specific S-NSSAI and an application, and may also include a default rule that matches all of applications with an S-NSSAI);
and determining, by the communication device, whether the at least one piece of requested network slice information matches the at least one piece of network slice information corresponding to the rejection information, wherein the registration request is transmitted in response to a result of the determining (Park taught [0633] the UE may receive a Registration Accept message from the AMF as a response to the registration request message (S1920). In this case, if at least one of S-NSSAIs included in the requested NSSAI has been rejected by the AMF, the Registration Accept message may include a Reject Cause for the rejected S-NSSAI along with the rejected S-NSSAI. In this case, the Reject Cause may be configured to indicate that the rejected S-NSSAI is not available in the PLMN and/or a current registration area. [0634] if the S-NSSAI has been rejected for a cause in which the rejected S-NSSAI is not available in a current registration area, the UE may not attempt a use request for the corresponding rejected S-NSSAI in the current registration area until the UE deviates from the registration area. [0600] if the rejection of an S-NSSAI is given in a registration Area Unit and the UE has Moved to Another Registration Area (i.e., if the UE has deviated from a current registration area in which the S-NSSAI has been rejected), the UE may reattempt a request to use the S-NSSAI rejected in the previous registration area in the new registration area. Furthermore, if the S-NSSAI rejected in the current PLMN is deleted from the list (i.e., rejected/forbidden NSSAI) for any reason, the UE may request the corresponding S-NSSAI again although it does not deviate from the current registration area).
Claim 6
With respect to claim 6, Park disclosed:
The wireless communication method of claim 1 (see rejection above),
wherein: the at least one piece of information relevant to a destination access management comprises at least one of 5G-S-TMSI and Globally Unique AMF ID, GUAMI (Park taught [0190] The Msg 3 has to include a UE identity. [0191] the UE transmits its unique identity (e.g., SAE(S)-TMSI or a random number). [0469] When registration is successfully performed, a UE is provided with a globally unique temporary UE identity (GUTI) by a serving AMF. [0470] When an NSSAI and a full local unique temporary ID are received in RRC, if an RAN can reach the AMF corresponding to a locally unique temporary ID, the RAN forwards a request to the corresponding AMF. If not, the RAN selects a suitable AMF based on an NSSAI provided by a UE and transmits the request to the selected AMF. If the RAN cannot select the AMF based on a provided NSSAI, the request is transmitted to a default AMF.),
and the requested network slice information does not comprise at least one piece of allowed network slice information (Park taught [0580] if an S-NSSAI requested by the UE corresponds to an S-NSSAI not allowed in the current PLMN and/or registration area of the UE, the corresponding requested S-NSSAI may be rejected.).
Claim 7
Claim 7 recites limitations similar to limitations of claim 1 and is rejected by the same reasoning.
Claim 12
Claim 12 recites limitations similar to limitations of claim 2 and is rejected by the same reasoning.
Claim 13
Claim 13 recites limitations similar to limitations of claim 1, except that it recites that the communication device “compris[es]: a communication unit; and a processor” to perform the operations, which are taught in Park [0639] (The UE 2020 includes a processor 2021, a memory 2022 and a communication module (or RF section). Processor 2021 implements the previously proposed functions, processes and/or methods. The layers of the wireless interface protocol may be implemented by the processor 2021. The memory 2022 is connected to the processor 2021 and stores various information for driving the processor 2021. The communication module 2023 is coupled to processor 2021 to transmit and/or receive wireless signals.).
Claim 13 is rejected for this reason along with the reasons given for claim 1.
Claim 14
Claim 14 recites limitations similar to limitations of claim 2 and is rejected by the same reasoning.
Claim 19
Claim 19 recites limitations similar to limitations of claim 6 and is rejected by the same reasoning.
Claim 20
Claim 20 recites limitations similar to limitations of claim 6 and is rejected by the same reasoning.
CLAIM REJECTIONS — 35 U.S.C. 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:
35 U.S.C. 103 Conditions for patentability; non-obvious subject matter.
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.
CLAIMS 4, 8, 9, AND 15-17
Claims 4, 8, 9, and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Park in view of Kim.
Claim 4
With respect to claim 4, Park taught:
The wireless communication method of claim 3 (see rejection above),
wherein the rejection cause comprises an indication that the at least one piece of network slice information is not supported within a wireless service area (Park taught [0634] if the S-NSSAI has been rejected for a cause in which the rejected S-NSSAI is not available in a current registration area, the UE may not attempt a use request for the corresponding rejected S-NSSAI in the current registration area until the UE deviates from the registration area. [0600] if the rejection of an S-NSSAI is given in a registration Area Unit and the UE has Moved to Another Registration Area (i.e., if the UE has deviated from a current registration area in which the S-NSSAI has been rejected), the UE may reattempt a request to use the S-NSSAI rejected in the previous registration area in the new registration area.),
the method further comprising: setting, by the communication device, the at least one piece of requested network slice information in a radio access control message, to allow a radio access node to select a destination access management node supporting the at least one piece of requested network slice information (Park taught [0496] The UE needs to include the requested NSSAI in RRC connection establishment and NAS message. An RAN needs to route an NAS signal between the UE and the AMF selected using the requested NSSAI obtained during the RRC connection establishment. [0605] if the AMF1 can support #1, #2 and #4 S-NSSAIs and the AMF2 can support #2, #3 and #5 S-NSSAIs, when a UE requests the #1, #2 and #3 S-NSSAIs as requested NSSAIs, a network may have to reject the #3 S-NSSAI (i.e., AMF1 selection) or the #1 S-NSSAI (i.e., AMF2 selection) depending on AMF selection. That is, the network may perform rejection for a specific S-NSSAI depending on a supportable S-NSSAI of a selected serving AMF. Accordingly, in this case, if the UE has moved to a different registration area or a different AMF has been selected, the UE needs to be able to request a rejected S-NSSAI again.),
wherein the wireless service area comprises a Registration Area (Park taught [0634] the rejected S-NSSAI is not available in a current registration area).
Park taught the limitations of claim 4 discussed above but Park did not explicitly teach that “the method further comprising: performing, by the communication device, a cell reselection in response to the rejection cause, to select a cell outside the wireless service area, and transmitting, by the communication device, the registration request via the selected cell.”
With respect to claim 4, Kim taught:
the method further comprising: performing, by the communication device, a cell reselection in response to the rejection cause, to select a cell outside the wireless service area, and transmitting, by the communication device, the registration request via the selected cell (Kim taught [0318] FIG. 9 shows an example of a method performed by a UE to which the first implementation of the present disclosure is applied. [0324] In step S930, the UE receives, from the AMF of the first PLMN, a registration reject message in response to the first registration request message. The registration reject message includes rejected NSSAI including the first S-NSSAI, and the registration reject message includes a cause value #62 for the rejected NSSAI. The cause value #62 indicates "No network slices available". [0354] According to the first implementation of the present disclosure, as an operation when the UE receives the cause value #62,if the UE has neither allowed NSSAI for the current PLMN or SNPN nor configured NSSAI for the current PLMN and has a default configured NSSAI containing one or more S-NSSAIs that are not included in any of the rejected NSSAI for the PLMN or SNPN, the rejected NSSAI for the current registration area, and the rejected NSSAI for the failed or revoked NSSAA, the UE may stay in the current serving cell, apply the normal cell reselection process, and start an initial registration by generating a requested NSSAI based on that default configured NSSAI. [0366] According to the first implementation of the present disclosure, by determining the S-NSSAI that can be transmitted based on the default configured NSSAI, unnecessary PLMN selection procedure and registration procedure can be efficiently removed).
The Examiner finds that it 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 to implement Kim’s cell reselection NSSAI request technique in Park’s NSSAI requesting method with the motivation to do so being to enable the communication device to proceed with requesting an S-NSSAI that has not yet been rejected, and also to avoid an unnecessary PLMN selection and registration procedure as discussed in [0366]. The Examiner finds that a person of ordinary skill in the art of wireless communication would be familiar with 5G technology and standards and that they would have a reasonable expectations of success of implementing Kim’s technique in Park’s method as discussed above since both Park and Kim are directed to the same 5G technology and similar techniques of requesting an S-NSSAI and handling rejected S-NSSAIs.
Claim 11
Claim 11 recites limitations similar to limitations of claim 4 and is rejected by the same reasoning.
Claim 8
Claim 8 recites limitations similar to limitations of claim 4 and is rejected by the same reasoning.
Claim 9
Claim 9 recites limitations similar to limitations of claim 4 and is rejected by the same reasoning.
Claim 17
Claim 17 recites limitations similar to limitations of claim 4 and is rejected by the same reasoning.
RESPONSE TO ARGUMENTS
Applicant’s arguments filed 4/23/2026 with respect to the rejections under 35 U.S.C. 112 have been considered and are persuasive in view of the claim amendments. The previous rejections under 35 U.S.C. 112 are withdrawn. However, new rejections under 35 U.S.C. 112 are made with respect to the claim amendments.
Applicant’s arguments filed 4/23/2026 with respect to the rejections under 35 U.S.C. 103 have been fully considered but they are not persuasive. Regardless, the limitations were changed, the old rejection under 35 U.S.C. 103 was withdrawn, and a new grounds of rejection under 35 U.S.C. 102 is made.
Argument regarding "not co-existable" S-NSSAIs”
On page 9 Applicant argued:
Park does not teach or suggest the claimed combination. Even assuming, arguendo, that Park's discussion of "not co-existable" S-NSSAIs (Park, [0607]) is considered relevant to incompatibility between requested and allowed slice information, Park still does not teach a follow-on operation in which, after receipt of the recited rejection cause, the communication device sets the requested network slice information in a radio access control message that does not comprise at least one piece of information relevant to the destination access management node, such that the message avoids being directed to the same access management node that previously rejected the corresponding network slice information
The Examiner disagrees. Park does teach such a follow-on operation. See FIG. 17 in which, after receipt of the recited rejection cause (FIG. 17 step 3 with rejected/non-allowed NSSAI), the communication device sets the requested network slice information in a radio access control message (i.e., the UE sets 6b Registration Request) that does not comprise at least one piece of information relevant to the destination access management node, such that the message avoids being directed to the same access management node that previously rejected the corresponding network slice information (i.e., the UE sets the Registration Request 6b such that it does not comprise the AMF ID of the old AMF (that rejected the NSSAI) thereby avoiding the old AMF.)
Argument regarding "omission of information”
On page 9 Applicant argued:
Park does not disclose or suggest an omission of information from the radio access control message so that the subsequent message avoids being directed to the same rejecting access management node.
The Examiner disagrees. Park implies that the registration request 6b in FIG. 17 does not include the AMF ID of the old AMF (which sent the rejection) in the new RRC message with the Registration Request at 6b such that the old AMF is avoided. The AMF IDs of the AMFs in a PLMN being relevant to each other. The message 6b goes to the new AMF not the old AMF. The message to the new AMF would include the new AMF ID and not the old AMF ID. See MPEP 2144.01 on Implicit Disclosure.
CONCLUSION
Applicant's amendment necessitated the new grounds 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 extension fee 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 date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Christopher Davis whose telephone number is 703-756-1832. The examiner can normally be reached Mon-Fri from 11AM to 7PM ET. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ayaz Sheikh, can be reached at telephone number 571-272-3795. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). Examiner interviews are available via a variety of formats see MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
/C.R.D./
Examiner, Art Unit 2476
/AYAZ R SHEIKH/Supervisory Patent Examiner, Art Unit 2476
Prosecution Insights