Prosecution Insights
Last updated: May 29, 2026
Application No. 18/609,968

METHOD AND APPARATUS TO DELIVER MULTIPLE NAS CONTAINERS VIA A SINGLE ACCESS STRATUM MESSAGE

Non-Final OA §102§103
Filed
Mar 19, 2024
Examiner
DUFFIELD, JEREMY S
Art Unit
2498
Tech Center
2400 — Computer Networks
Assignee
Nokia Technologies Oy
OA Round
1 (Non-Final)
49%
Grant Probability
Moderate
1-2
OA Rounds
1y 6m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 49% of resolved cases
49%
Career Allowance Rate
218 granted / 443 resolved
-8.8% vs TC avg
Strong +52% interview lift
Without
With
+52.1%
Interview Lift
resolved cases with interview
Typical timeline
3y 9m
Avg Prosecution
22 currently pending
Career history
467
Total Applications
across all art units

Statute-Specific Performance

§101
0.8%
-39.2% vs TC avg
§103
95.4%
+55.4% vs TC avg
§102
1.8%
-38.2% vs TC avg
§112
1.6%
-38.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 443 resolved cases

Office Action

§102 §103
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 . Priority No priority claims have been filed. Therefore, the effective filing date for the claims is 19 March 2024. Information Disclosure Statement The Information Disclosure Statement filed on 21 May 2025 complies with all applicable rules and regulations. Therefore, the information referred to therein has been considered. Drawings No issues have been found with the drawings filed 19 March 2024. Specification No issues have been found with the specification filed 19 March 2024. Claim Objections Claims 1, 3, 6, and 9-13 are objected to because of the following informalities: Regarding claim 1, line 9—“the subsequent network function”, lacks sufficient antecedent basis for the claim. In order to overcome this objection, line 9 may be amended to state --a subsequent network function--, for example. Regarding claim 1, line 11—“a first network function”, appears to be referring to “a first network function” of line 8. In order to overcome this objection, line 11 may be amended to state --the first network function--, for example. Regarding claim 1, line 13—“a subsequent network function”, appears to be referring to “the subsequent network function” of line 9. In order to overcome this objection, line 13 may be amended to state --the subsequent network function--, for example. Regarding claim 1, line 13—“the second container”, lacks sufficient antecedent basis, but appears to be referring to “a subsequent container” of line 11. In order to overcome this objection, line 13 may be amended to state --the subsequent container--, for example. Regarding claim 1, line 14—“the second encrypted payload”, lacks sufficient antecedent basis, but appears to be referring to “a subsequent encrypted payload” of lines 7-8. In order to overcome this objection, line 14 may be amended to state --the subsequent encrypted payload--, for example. Regarding claim 3, line 1—“the first routing information” lacks sufficient antecedent basis, but appears to be referring to “routing information for a first network function” of claim 1. In order to overcome this objection, line 1 may be amended to state --the routing information for the first network function--, for example. Regarding claim 3, lines 1-2—“a first temporary identifier”, appears to be referring to “a first temporary identifier” of claim 1. In order to overcome this objection, lines 1-2 may be amended to state --the first temporary identifier--, for example. Regarding claim 3, line 2—“the second routing information” lacks sufficient antecedent basis, but appears to be referring to “routing information for a subsequent network function” of claim 1. In order to overcome this objection, line 2 may be amended to state --the temporary identifier comprising the routing information for the subsequent network function--, for example. Regarding claim 6, lines 4-5 and 7—“the subsequent container”, lacks sufficient antecedent basis, but appears to be referring to “a second container” of line 3. In order to overcome this objection, lines 4-5 and 7 may be amended to state --the second container--, for example. Regarding claim 6, lines 6 and 8—“the subsequent routing information” lacks sufficient antecedent basis, but appears to be referring to “routing information for a subsequent network function” of line 4. In order to overcome this objection, lines 6 and 8 may be amended to state --the routing information for the subsequent network function--, for example. Regarding claim 9, line 1—“the subsequent routing information” lacks sufficient antecedent basis, but appears to be referring to “routing information for a subsequent network function” of claim 6. In order to overcome this objection, line 1 may be amended to state --the temporary identifier comprising the routing information for the subsequent network function--, for example. Regarding claim 10, line 5—“a user equipment (UE)”, appears to be referring to “A user equipment (UE)” of line 1. In order to overcome this objection, line 5 may be amended to state --the UE--, for example. Regarding claim 10, line 14—“a first network function”, appears to be referring to “a first network function” of line 11. In order to overcome this objection, line 14 may be amended to state --the first network function--, for example. Regarding claim 10, line 16—“a subsequent network function”, appears to be referring to “a subsequent network function” of line 12. In order to overcome this objection, line 16 may be amended to state --the subsequent network function--, for example. Regarding claim 10, line 16—“the second container”, lacks sufficient antecedent basis, but appears to be referring to “a subsequent container” of line 14. In order to overcome this objection, line 16 may be amended to state --the subsequent container--, for example. Regarding claim 10, line 17—“the second encrypted payload”, lacks sufficient antecedent basis, but appears to be referring to “a subsequent encrypted payload” of lines 10-11. In order to overcome this objection, line 17 may be amended to state --the subsequent encrypted payload--, for example. Regarding claim 11, lines 7-8 and 10—“the subsequent container”, lacks sufficient antecedent basis, but appears to be referring to “a second container” of line 6. In order to overcome this objection, lines 7-8 and 10 may be amended to state --the second container--, for example. Regarding claim 11, line 8—“the subsequent encrypted payload”, lacks sufficient antecedent basis for the claim. In order to overcome this objection, line 8 may be amended to state --a subsequent encrypted payload--, for example. Regarding claim 11, lines 9 and 11—“the subsequent routing information” lacks sufficient antecedent basis, but appears to be referring to “routing information for a subsequent network function” of line 7. In order to overcome this objection, lines 9 and 11 may be amended to state --the routing information for the subsequent network function--, for example. Regarding claim 12, line 3—“a user equipment (UE)”, appears to be referring to “a user equipment (UE)” of line 2. In order to overcome this objection, line 3 may be amended to state --the UE--, for example. Regarding claim 12, line 12—“a first network function”, appears to be referring to “a first network function” of line 9. In order to overcome this objection, line 12 may be amended to state --the first network function--, for example. Regarding claim 12, line 14—“a subsequent network function”, appears to be referring to “a subsequent network function” of line 10. In order to overcome this objection, line 14 may be amended to state --the subsequent network function--, for example. Regarding claim 12, line 14—“the second container”, lacks sufficient antecedent basis, but appears to be referring to “a subsequent container” of line 12. In order to overcome this objection, line 14 may be amended to state --the subsequent container--, for example. Regarding claim 12, line 15—“the second encrypted payload”, lacks sufficient antecedent basis, but appears to be referring to “a subsequent encrypted payload” of lines 8-9. In order to overcome this objection, line 15 may be amended to state --the subsequent encrypted payload--, for example. Regarding claim 13, lines 5-6 and 8—“the subsequent container”, lacks sufficient antecedent basis, but appears to be referring to “a second container” of line 4. In order to overcome this objection, lines 5-6 and 8 may be amended to state --the second container--, for example. Regarding claim 13, line 6—“the subsequent encrypted payload”, lacks sufficient antecedent basis for the claim. In order to overcome this objection, line 6 may be amended to state --a subsequent encrypted payload--, for example. Regarding claim 13, lines 7 and 9—“the subsequent routing information” lacks sufficient antecedent basis, but appears to be referring to “routing information for a subsequent network function” of line 5. In order to overcome this objection, lines 7 and 9 may be amended to state --the routing information for the subsequent network function--, for example. Appropriate correction is required. Claim Rejections - 35 USC § 102 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: A person shall be entitled to a patent unless – (a)(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. (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. 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-6 and 8-13 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by Faccin et al. (US 2016/0286600 A1). Regarding claim 1, Faccin teaches a method, comprising: receiving, at an access stratum (AS) layer, e.g., the RRC layer handles broadcasted system information related to the access stratum and transport of non-access stratum (NAS) messages (Para. 55); access stratum 230 (Fig. 2, el. 230), of a user equipment (UE), e.g., client device 102/202/402 (Fig. 1, el. 102; Fig. 2, el. 202; Fig. 4, el. 402), a plurality of non access stratum (NAS) payloads, wherein a first NAS payload of the plurality of NAS payloads is received from a first NAS sublayer and a subsequent payload of the plurality of NAS payloads is received from a subsequent NAS sublayer, e.g., NAS messages for each logical instance of the client device 202 may be multiplexed over the one RRC connection 208 (e.g., the one RRC signaling link layer of a communication protocol stack) (Fig. 2, el. 208; Para. 82); allow for a device to be split into multiple logical instances, and for each logical instance to be represented by a unique NAS context, wherein each NAS context may be associated with one of a plurality of MMEs, where each of the plurality of MMEs is dedicated to one or more services—NAS sublayers--, and the radio link between the device and an access node is thereby shared by a plurality of NAS contexts (Para. 63); multiple concurrent NAS contexts may be beneficial because specific services (e.g., an M2M service, a World Wide Web search service, a video streaming service)—NAS sublayers-- may be delivered and controlled by specific and dedicated MMEs (i.e., delivered and controlled by specific and dedicated functionality in a core network) (Para. 66); encrypting, by the UE, the first payload with a first encryption generating a first encrypted payload and the subsequent payload with a subsequent encryption generating a subsequent encrypted payload, wherein the first encryption is associated with a first network function and the subsequent encryption is associated with the subsequent network function, e.g., obtaining 1202, at the client device, a plurality of contexts with a plurality of serving nodes (e.g., MMEs)—network functions--, and associating 1204 each of the plurality of contexts with a separate set of credentials, where each set of credentials may uniquely identify one context in the plurality of contexts, and associating 1206 each set of credentials with data corresponding to a respective context, and encrypting 1208 the data corresponding to a respective context based on the set of credentials associated with the context (Fig. 12; Para. 239); a first set of keys associated with the first data may be received, and a second set of keys associated with the second data may also be received, and integrity protection and ciphering may be applied to the first data using the first set of keys and to the second data using the second set of keys (Para. 259); generating, by the UE, a first message that includes a first temporary identifier comprising routing information for a first network function and a first container and a subsequent container, wherein the first container includes the first encrypted payload and a temporary identifier comprising routing information for a subsequent network function, and the second container includes the second encrypted payload, e.g., the RRC message—first message-- used to carry NAS signaling may have an inner container (which may be in or outside a packet data convergence protocol service data unit (PDCP SDU)) having the format: RRC_MSG (<UEID1, NAS_MSG>; <UEID2, NAS_MSG>; . . . ), --RRC_MSG () is the first container and <UEID2, NAS_MSG> is the second container--, where the UEID can be an SAE-Temporary Mobile Subscriber identity (S-TMSI) (where SAE stands for System Architecture Evolution and S-TMSI=MME Code (MMEC)+MME Mobile Subscriber Identity (M-TMSI)) or MME identifier (MMEI)+M-TMSI assigned by the MME serving the specific contexts, or a different label (Para. 135, 136); encrypting 1208 the data corresponding to a respective context based on the set of credentials associated with the context (Fig. 12; Para. 239); a first set of keys associated with the first data may be received, and a second set of keys associated with the second data may also be received, and integrity protection and ciphering may be applied to the first data using the first set of keys and to the second data using the second set of keys (Para. 259); and transmitting, by the UE, the first message to a first apparatus, e.g., access node 104/426 (Fig. 1, el. 104; Fig. 4, el. 426); in order to use the model in which there is a single RRC connection for multiple NAS contexts (e.g., multiplexed RRC), an access node may be enabled to route more than one NAS message in the same RRC message to the appropriate MMEs (Para. 135); when an access node within the RAN 228 receives a communication from a client device 202, the access node may be able to determine how to forward the communication based at least on the VESM tag 213 packaged with the NAS payload 215 and the physical address of the client device 202 or the identity of the client device 202 (Para. 91); sending 1210 the data via a radio link shared by the plurality of contexts (Fig. 12, el. 1210; Para. 239). Regarding claim 2, Faccin teaches the method of claim 1, wherein the first network function temporary identifier is a serving temporary mobile subscriber identifier (S-TMSI) for a mobility management function, e.g., the RRC message used to carry NAS signaling may have an inner container (which may be in or outside a packet data convergence protocol service data unit (PDCP SDU)) having the format: RRC_MSG (<UEID1, NAS_MSG>; <UEID2, NAS_MSG>; . . . ), where the UEID can be an SAE-Temporary Mobile Subscriber identity (S-TMSI) (where SAE stands for System Architecture Evolution and S-TMSI=MME Code (MMEC)+MME Mobile Subscriber Identity (M-TMSI)) or MME identifier (MMEI)+M-TMSI assigned by the MME serving the specific contexts, or a different label (Faccin-Para. 135, 136). Regarding claim 3, Faccin teaches the method of claim 1, wherein the first routing information is a first temporary identifier and the second routing information is a subsequent temporary identifier, e.g., the RRC message used to carry NAS signaling may have an inner container (which may be in or outside a packet data convergence protocol service data unit (PDCP SDU)) having the format: RRC_MSG (<UEID1, NAS_MSG>; <UEID2, NAS_MSG>; . . . ), where the UEID can be an SAE-Temporary Mobile Subscriber identity (S-TMSI) (where SAE stands for System Architecture Evolution and S-TMSI=MME Code (MMEC)+MME Mobile Subscriber Identity (M-TMSI)) or MME identifier (MMEI)+M-TMSI assigned by the MME serving the specific contexts, or a different label (Faccin-Para. 135, 136). Regarding claim 4, Faccin teaches the method of claim 3, wherein the first temporary identifier is a serving temporary mobile subscriber identifier (S-TMSI) for the first network function and the subsequent temporary identifier is an S-TMSI for the subsequent network function, e.g., the RRC message used to carry NAS signaling may have an inner container (which may be in or outside a packet data convergence protocol service data unit (PDCP SDU)) having the format: RRC_MSG (<UEID1, NAS_MSG>; <UEID2, NAS_MSG>; . . . ), where the UEID can be an SAE-Temporary Mobile Subscriber identity (S-TMSI) (where SAE stands for System Architecture Evolution and S-TMSI=MME Code (MMEC)+MME Mobile Subscriber Identity (M-TMSI)) or MME identifier (MMEI)+M-TMSI assigned by the MME serving the specific contexts, or a different label (Faccin-Para. 135, 136). Regarding claim 5, Faccin teaches the method of claim 1, wherein the first apparatus is a radio access network (RAN), e.g., access node 104/426 (Faccin-Fig. 1, el. 104; Fig. 4, el. 426), wherein the access node 104 may be included within a radio access network (RAN) 106 (Faccin-Fig. 1, el. 106; Para. 53). Regarding claim 6, Faccin teaches a method, comprising: receiving, by a first apparatus, e.g., access node 104/426 (Fig. 1, el. 104; Fig. 4, el. 426), a first message from a second apparatus, e.g., client device 102/202/402 (Fig. 1, el. 102; Fig. 2, el. 202; Fig. 4, el. 402); in order to use the model in which there is a single RRC connection for multiple NAS contexts (e.g., multiplexed RRC), an access node may be enabled to route more than one NAS message in the same RRC message to the appropriate MMEs (Para. 135); when an access node within the RAN 228 receives a communication from a client device 202, the access node may be able to determine how to forward the communication based at least on the VESM tag 213 packaged with the NAS payload 215 and the physical address of the client device 202 or the identity of the client device 202 (Para. 91); sending 1210 the data via a radio link shared by the plurality of contexts (Fig. 12, el. 1210; Para. 239), the first message including a first container and a second container, wherein the first container includes a temporary identifier comprising routing information for a subsequent network function, and the subsequent container includes the subsequent encrypted payload, e.g., the RRC message—first message-- used to carry NAS signaling may have an inner container (which may be in or outside a packet data convergence protocol service data unit (PDCP SDU)) having the format: RRC_MSG (<UEID1, NAS_MSG>; <UEID2, NAS_MSG>; . . . ), --RRC_MSG () is the first container and <UEID2, NAS_MSG> is the second container--, where the UEID can be an SAE-Temporary Mobile Subscriber identity (S-TMSI) (where SAE stands for System Architecture Evolution and S-TMSI=MME Code (MMEC)+MME Mobile Subscriber Identity (M-TMSI)) or MME identifier (MMEI)+M-TMSI assigned by the MME serving the specific contexts, or a different label (Para. 135, 136); encrypting 1208 the data corresponding to a respective context based on the set of credentials associated with the context (Fig. 12; Para. 239); a first set of keys associated with the first data may be received, and a second set of keys associated with the second data may also be received, and integrity protection and ciphering may be applied to the first data using the first set of keys and to the second data using the second set of keys (Para. 259); reading, by the first apparatus, the subsequent routing information, e.g., when an access node within the RAN 228 receives a communication from a client device 202, the access node may be able to determine how to forward the communication based at least on the VESM tag 213 packaged with the NAS payload 215 and the physical address of the client device 202 or the identity of the client device 202 (Para. 91); the access node may use a new or stored VESM tag for NAS routing to carry NAS signaling to the correct MME, wherein VESM tags may be used to make multiple active logical instances of a client device appear to the core network as separate logical connections (Para. 94); the context-unique identifier may be a combination of the unique identifier derived for the logical instance of the device and a physical address/identifier of the device, wherein the context-unique identifiers may be referred to herein as context-unique identifiers or virtual evolved session management (VESM) tags (i.e., VESM tags), wherein the physical address/identifier of the device may be, for example, a global unique temporary identifier (GUTI), or a radio network temporary identifier (e.g., an identifier of an RRC connection that is dedicated to the device) (Para. 49); and transmitting, by the first apparatus, the subsequent container to the subsequent network function based on the subsequent routing information, e.g., when an access node within the RAN 228 receives a communication from a client device 202, the access node may be able to determine how to forward the communication based at least on the VESM tag 213 packaged with the NAS payload 215 and the physical address of the client device 202 or the identity of the client device 202, and an access node within the RAN 228 may be able to direct the NAS payload to a first MME (e.g., MME A 240) associated with a first core network 236, or a second MME (e.g., MME B 248) associated with the second core network, core network B 238 (Para. 91); the access node may use a new or stored VESM tag for NAS routing to carry NAS signaling to the correct MME, wherein VESM tags may be used to make multiple active logical instances of a client device appear to the core network as separate logical connections (Para. 94). Regarding claim 8, Faccin teaches the method of claim 6, wherein the second apparatus is a radio access network (RAN), e.g., the access node 104 may be included within a radio access network (RAN) 106 (Faccin-Fig. 1, el. 106; Para. 53); the single radio link 108 may be established between the client device 102 and the access node 104 of the RAN 106. (Faccin-Fig. 1, el. 108; Para. 54). Regarding claim 9, Faccin teaches the method of claim 6, wherein the subsequent routing information is a serving temporary mobile subscriber identifier (S-TMSI) for the subsequent network function, e.g., the RRC message used to carry NAS signaling may have an inner container (which may be in or outside a packet data convergence protocol service data unit (PDCP SDU)) having the format: RRC_MSG (<UEID1, NAS_MSG>; <UEID2, NAS_MSG>; . . . ), where the UEID can be an SAE-Temporary Mobile Subscriber identity (S-TMSI) (where SAE stands for System Architecture Evolution and S-TMSI=MME Code (MMEC)+MME Mobile Subscriber Identity (M-TMSI)) or MME identifier (MMEI)+M-TMSI assigned by the MME serving the specific contexts, or a different label (Faccin-Para. 135, 136). Regarding claim 10, Faccin teaches a user equipment (UE), e.g., client device 102/202/402 (Fig. 1, el. 102; Fig. 2, el. 202; Fig. 4, el. 402), comprising: at least one processor, e.g., processing circuit 1006 (Fig. 10, el. 1006); and at least one memory, e.g., memory device 1008 (Fig. 10, el. 1006), storing instructions which, when executed by the at least one processor, e.g., the processing circuit 1006 may be adapted for processing, including the execution of programming, which may be stored on the memory device 1008 (Para. 215), cause the UE at least to perform: receiving, at an access stratum (AS) layer, e.g., the RRC layer handles broadcasted system information related to the access stratum and transport of non-access stratum (NAS) messages (Para. 55); access stratum 230 (Fig. 2, el. 230), of a user equipment (UE), a plurality of non access stratum (NAS) payloads, wherein a first NAS payload of the plurality of NAS payloads is received from a first NAS sublayer and a subsequent payload of the plurality of NAS payloads is received from a subsequent NAS sublayer, e.g., NAS messages for each logical instance of the client device 202 may be multiplexed over the one RRC connection 208 (e.g., the one RRC signaling link layer of a communication protocol stack) (Fig. 2, el. 208; Para. 82); allow for a device to be split into multiple logical instances, and for each logical instance to be represented by a unique NAS context, wherein each NAS context may be associated with one of a plurality of MMEs, where each of the plurality of MMEs is dedicated to one or more services—NAS sublayers--, and the radio link between the device and an access node is thereby shared by a plurality of NAS contexts (Para. 63); multiple concurrent NAS contexts may be beneficial because specific services (e.g., an M2M service, a World Wide Web search service, a video streaming service)—NAS sublayers-- may be delivered and controlled by specific and dedicated MMEs (i.e., delivered and controlled by specific and dedicated functionality in a core network) (Para. 66); encrypting, by the UE, the first payload with a first encryption generating a first encrypted payload and the subsequent payload with a subsequent encryption generating a subsequent encrypted payload, wherein the first encryption is associated with a first network function and the subsequent encryption is associated with a subsequent network function, e.g., obtaining 1202, at the client device, a plurality of contexts with a plurality of serving nodes (e.g., MMEs)—network functions--, and associating 1204 each of the plurality of contexts with a separate set of credentials, where each set of credentials may uniquely identify one context in the plurality of contexts, and associating 1206 each set of credentials with data corresponding to a respective context, and encrypting 1208 the data corresponding to a respective context based on the set of credentials associated with the context (Fig. 12; Para. 239); a first set of keys associated with the first data may be received, and a second set of keys associated with the second data may also be received, and integrity protection and ciphering may be applied to the first data using the first set of keys and to the second data using the second set of keys (Para. 259); generating, by the UE, a first message that includes a first temporary identifier comprising routing information for a first network function and a first container and a subsequent container, wherein the first container includes the first encrypted payload and a temporary identifier comprising routing information for a subsequent network function, and the second container includes the second encrypted payload, e.g., the RRC message—first message-- used to carry NAS signaling may have an inner container (which may be in or outside a packet data convergence protocol service data unit (PDCP SDU)) having the format: RRC_MSG (<UEID1, NAS_MSG>; <UEID2, NAS_MSG>; . . . ), --RRC_MSG () is the first container and <UEID2, NAS_MSG> is the second container--, where the UEID can be an SAE-Temporary Mobile Subscriber identity (S-TMSI) (where SAE stands for System Architecture Evolution and S-TMSI=MME Code (MMEC)+MME Mobile Subscriber Identity (M-TMSI)) or MME identifier (MMEI)+M-TMSI assigned by the MME serving the specific contexts, or a different label (Para. 135, 136); encrypting 1208 the data corresponding to a respective context based on the set of credentials associated with the context (Fig. 12; Para. 239); a first set of keys associated with the first data may be received, and a second set of keys associated with the second data may also be received, and integrity protection and ciphering may be applied to the first data using the first set of keys and to the second data using the second set of keys (Para. 259); and transmitting, by the UE, the first message to a first apparatus, e.g., access node 104/426 (Fig. 1, el. 104; Fig. 4, el. 426); in order to use the model in which there is a single RRC connection for multiple NAS contexts (e.g., multiplexed RRC), an access node may be enabled to route more than one NAS message in the same RRC message to the appropriate MMEs (Para. 135); when an access node within the RAN 228 receives a communication from a client device 202, the access node may be able to determine how to forward the communication based at least on the VESM tag 213 packaged with the NAS payload 215 and the physical address of the client device 202 or the identity of the client device 202 (Para. 91); sending 1210 the data via a radio link shared by the plurality of contexts (Fig. 12, el. 1210; Para. 239). Regarding claim 11, Faccin teaches an apparatus, e.g., access node 104/426 (Fig. 1, el. 104; Fig. 4, el. 426), comprising: at least one processor, e.g., processing circuit 1606 (Fig. 16, el. 1606); and at least one memory, e.g., memory device 1608 (Fig. 16, el. 1608), storing instructions which, when executed by the at least one processor, e.g., the processing circuit 1606 may be adapted for processing, including the execution of programming, which may be stored on the memory device 1608 (Para. 250), cause the apparatus at least to perform: receiving, by the apparatus, a first message from a second apparatus, e.g., client device 102/202/402 (Fig. 1, el. 102; Fig. 2, el. 202; Fig. 4, el. 402); in order to use the model in which there is a single RRC connection for multiple NAS contexts (e.g., multiplexed RRC), an access node may be enabled to route more than one NAS message in the same RRC message to the appropriate MMEs (Para. 135); when an access node within the RAN 228 receives a communication from a client device 202, the access node may be able to determine how to forward the communication based at least on the VESM tag 213 packaged with the NAS payload 215 and the physical address of the client device 202 or the identity of the client device 202 (Para. 91); sending 1210 the data via a radio link shared by the plurality of contexts (Fig. 12, el. 1210; Para. 239), the first message including a first container and a second container, wherein the first container includes a temporary identifier comprising routing information for a subsequent network function, and the subsequent container includes the subsequent encrypted payload, e.g., the RRC message—first message-- used to carry NAS signaling may have an inner container (which may be in or outside a packet data convergence protocol service data unit (PDCP SDU)) having the format: RRC_MSG (<UEID1, NAS_MSG>; <UEID2, NAS_MSG>; . . . ), --RRC_MSG () is the first container and <UEID2, NAS_MSG> is the second container--, where the UEID can be an SAE-Temporary Mobile Subscriber identity (S-TMSI) (where SAE stands for System Architecture Evolution and S-TMSI=MME Code (MMEC)+MME Mobile Subscriber Identity (M-TMSI)) or MME identifier (MMEI)+M-TMSI assigned by the MME serving the specific contexts, or a different label (Para. 135, 136); encrypting 1208 the data corresponding to a respective context based on the set of credentials associated with the context (Fig. 12; Para. 239); a first set of keys associated with the first data may be received, and a second set of keys associated with the second data may also be received, and integrity protection and ciphering may be applied to the first data using the first set of keys and to the second data using the second set of keys (Para. 259); reading, by the apparatus, the subsequent routing information, e.g., when an access node within the RAN 228 receives a communication from a client device 202, the access node may be able to determine how to forward the communication based at least on the VESM tag 213 packaged with the NAS payload 215 and the physical address of the client device 202 or the identity of the client device 202 (Para. 91); the access node may use a new or stored VESM tag for NAS routing to carry NAS signaling to the correct MME, wherein VESM tags may be used to make multiple active logical instances of a client device appear to the core network as separate logical connections (Para. 94); the context-unique identifier may be a combination of the unique identifier derived for the logical instance of the device and a physical address/identifier of the device, wherein the context-unique identifiers may be referred to herein as context-unique identifiers or virtual evolved session management (VESM) tags (i.e., VESM tags), wherein the physical address/identifier of the device may be, for example, a global unique temporary identifier (GUTI), or a radio network temporary identifier (e.g., an identifier of an RRC connection that is dedicated to the device) (Para. 49); and transmitting, by the apparatus, the subsequent container to the subsequent network function based on the subsequent routing information, e.g., when an access node within the RAN 228 receives a communication from a client device 202, the access node may be able to determine how to forward the communication based at least on the VESM tag 213 packaged with the NAS payload 215 and the physical address of the client device 202 or the identity of the client device 202, and an access node within the RAN 228 may be able to direct the NAS payload to a first MME (e.g., MME A 240) associated with a first core network 236, or a second MME (e.g., MME B 248) associated with the second core network, core network B 238 (Para. 91); the access node may use a new or stored VESM tag for NAS routing to carry NAS signaling to the correct MME, wherein VESM tags may be used to make multiple active logical instances of a client device appear to the core network as separate logical connections (Para. 94). Regarding claim 12, the claim is analyzed with respect to claim 10. Faccin further teaches a processor-readable medium, e.g., memory device 1008 (Faccin-Fig. 10, el. 1006), storing instructions which, when executed by at least one processor, e.g., processing circuit 1006 (Faccin-Fig. 10, el. 1006), of a user equipment (UE), e.g., client device 102/202/402 (Faccin-Fig. 1, el. 102; Fig. 2, el. 202; Fig. 4, el. 402), cause the UE at least to perform the steps. Regarding claim 13, the claim is analyzed with respect to claim 11. Faccin further teaches a processor-readable medium, e.g., memory device 1608 (Fig. 16, el. 1608), storing instructions which, when executed by at least one processor, e.g., processing circuit 1606 (Fig. 16, el. 1606), of an apparatus, e.g., access node 104/426 (Fig. 1, el. 104; Fig. 4, el. 426), cause the apparatus at least to perform the steps. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Faccin in view of Zakrzewski (US 2015/0146519 A1). Regarding claim 7, Faccin teaches the method of claim 6. Faccin further teaches…a mobility management (MM) function, e.g., the three logical contexts are serviced by three physical MMEs (e.g., serving nodes), MME A 420, MME B 422, MME C 424, wherein any physical MME can be split into multiple logical instances of itself, wherein MME D 432 is logically split into MME D1 434, MME D2 436, and MME D3 438 (Faccin-Fig. 4; Para. 97). Faccin does not clearly teach wherein the first apparatus is a mobility management (MM) function. Zakrzewski teaches wherein the first apparatus is a mobility management (MM) function, e.g., proxy MME 604/808 (Fig. 6, el. 604; Fig. 8, el. 808); proxy MME 808 terminates the NAS protocol and forwards all NAS signaling to main MME 802, wherein during this operation, the proxy MME 808 may inspect, for example sniff the content of NAS messages that it forwards between UE 804 and main MME 802, wherein the inspection (sniffing) of NAS messages may allow the proxy MME 808 to build up UE 804 context information, which may mirror information stored at main MME 802 (Para. 88). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Faccin to include wherein the first apparatus is a mobility management (MM) function, using the known method of enabling a proxy MME to receive NAS messages from an access node, inspect the NAS messages, and then to forward them to a main MME, as taught by Zakrzewski, in combination with the NAS signaling system of Faccin, for the purpose of maintaining service continuity and preventing any data flow interruption while services are being provided (Zakrzewski-Para. 5). Relevant Prior Art The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Huang et al. (US 2021/0266702 A1)—Huang et al. discloses a first MME of LTE core network 101 may receive the Attach Request, determine that LTE UE 107 and/or the Attach Request should be forwarded to a second MME and/or to LTE-5G IWF 105, and may accordingly forward the Attach Request to the second MME (Para. 19). Jin (US 2017/0238215 A1)—Jin discloses The first mobility management entity 1006 is further configured to forward, to the second mobility management entity 1007, the downlink data sent by the first gateway 1004 (Para. 403). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY DUFFIELD whose telephone number is (571)270-1643. The examiner can normally be reached Monday - Friday, 7:00 AM - 3:00 PM (ET). 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, Yin-Chen Shaw can be reached at (571) 272-8878. 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. 11 February 2026 /Jeremy S Duffield/Primary Examiner, Art Unit 2498
Read full office action

Prosecution Timeline

Mar 19, 2024
Application Filed
Feb 11, 2026
Non-Final Rejection (signed) — §102, §103
Apr 02, 2026
Non-Final Rejection mailed — §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12634701
PROXIMITY-BASED AND MULTI-TIME-BASED DEACTIVATION AND/OR ACTIVATION RELATED TO A TOKEN
4y 1m to grant Granted May 19, 2026
Patent 12615154
TECHNIQUES TO CONTROL APPLETS FOR CONTACTLESS CARDS
2y 0m to grant Granted Apr 28, 2026
Patent 12609833
SIGNING VIDEO FOR REDUCED BIT RATE
2y 5m to grant Granted Apr 21, 2026
Patent 12598067
Method, Device, and System for Updating Anchor Key in a Communication Network for Encrypted Communication with Service Applications
3y 9m to grant Granted Apr 07, 2026
Patent 12591642
SYSTEM FOR STEGANALYSIS DETECTION OF METADATA IN A VIDEO STREAM FOR PROVIDING REAL-TIME DATA
2y 5m to grant Granted Mar 31, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
49%
Grant Probability
99%
With Interview (+52.1%)
3y 9m (~1y 6m remaining)
Median Time to Grant
Low
PTA Risk
Based on 443 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month