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 .
DETAILED ACTION
This action is responsive to the application filed on 11/11/2024.
Claims 1-4, 7-11, 15-17, 19-22, 25, 27, and 30-31 are pending in the case. Claims 5-6, 12-14, 18, 23-24, 26, 28-29, 32-40 have been canceled. Claims 1, 7, and 31 are independent claims.
This application is the national stage of PCT Application No. PCT/CN2022/092886, filed on 5/13/2022.
Claim Interpretation
Claims 3, 7-9, 16, 20, 22, 27, and 30-31 recite the limitation "in a case that". Each of the "in a case that" clauses indicates that the associated limitations occur only when the criteria of these clauses are met. However, the present claims never affirmatively require such events to occur. The broadest reasonable interpretation of these limitations does not require these conditional steps to be performed. See Ex parte Schulhauser, 2013-007847 (PTAB 2016) (precedential) (MPEP 2111.04 II) where the board held that when method steps are to be carried out only upon the occurrence of a condition precedent, the broadest reasonable interpretation holds that those steps are not required to be performed. As such, the limitations followed by "in case" clauses do not appear to have patentable weight since they are contingent upon a condition occurring.
Examiner suggests, for example, for claim 3 “The method of claim 1, further comprising determining that a service network identifier of a terminal is different from a home network identifier; and wherein the application key confirmation request is sent by the AAnF to the proxy entity in case that a service network identifier of a terminal is different from a home network identifier” or similar.
Claim Rejections - 35 USC § 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:
A person shall be entitled to a patent unless –
(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.
Claims 1-4, 7-11, 16-17, 19, 21-22, 25, 27, and 30-31 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Kunz et al., US Patent Publication No 20230136693, filed on 10/29/2021, (hereinafter Kunz).
As for independent claim 1, Khare discloses A key management method, the method comprising:
receiving, by a proxy entity in a service network (V-AAnF as a proxy), an application key confirmation request sent by an anchor function network element (AAnF) (the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413 ) of authentication and key management for applications (AKMA) in a home network (The V-AAnF may provide the AKMA security context to the related LI network function on request).
(Kunz paragraph [0099] discloses “At step 10, in one embodiment, the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), the SUPI, the A-KID, and potentially other parameters. The V-AAnF 413, in one embodiment, stores the information for potential requests for legal interception.”
Paragraph [0070] discloses “FIG. 2 depicts a procedure flow 200 for key provisioning to V-AAnF at Application Session Establishment Request. In one embodiment, procedure 200 describes the usage of a V-AAnF as a proxy in the VPLMN to receive the AKMA security context from the HPLMN AAnF. The V-AAnF may provide the AKMA security context to the related LI network function on request.”)
PNG
media_image1.png
718
606
media_image1.png
Greyscale
As for claim 2, the limitations of parent claim 1 have been discussed above. Kunz discloses
the method of claim 1, wherein
the application key confirmation request comprises at least one of:
AKMA application key (A-KID).
(Kunz paragraph [0099] discloses “At step 10, in one embodiment, the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), the SUPI, the A-KID, and potentially other parameters. The V-AAnF 413, in one embodiment, stores the information for potential requests for legal interception.”
The application key confirmation request comprises at least one of; Examiner chose to map to “AKMA application key”.)
expiration time of the AKMA application key.
an AF identifier of an application function (AF) in the home network.
an AKMA key identifier of a terminal.
or a subscription permanent identifier (SUPI) of the terminal.
As for claim 3, the limitations of parent claim 1 have been discussed above, Kunz discloses
the method of claim 1, wherein
the application key confirmation request is sent by the AAnF to the (V-AAnF as a proxy) proxy entity (the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413) in case that a service network identifier of a terminal is different from a home network identifier (user equipment (“UE”) device, the serving network comprising a visited public land mobile network (“VPLMN”) that is different from a home PLMN (“HPLMN”) associated with the UE).
(Kunz paragraph [0099] discloses “At step 10, in one embodiment, the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), the SUPI, the A-KID, and potentially other parameters. The V-AAnF 413, in one embodiment, stores the information for potential requests for legal interception.”
Paragraph [0070] discloses “FIG. 2 depicts a procedure flow 200 for key provisioning to V-AAnF at Application Session Establishment Request. In one embodiment, procedure 200 describes the usage of a V-AAnF as a proxy in the VPLMN to receive the AKMA security context from the HPLMN AAnF. The V-AAnF may provide the AKMA security context to the related LI network function on request.”
Paragraph [0051] discloses “In one embodiment, the method 900 includes determining 905 a serving network of a user equipment (“UE”) device, the serving network comprising a visited public land mobile network (“VPLMN”) that is different from a home PLMN (“HPLMN”) associated with the UE. In one embodiment, the method 900 includes selecting 910 a network function within the serving network for provisioning an authentication and key management for applications (“AKMA”) security context for an application function (“AF”) based on a name for the serving network. In one embodiment, the method 900 includes sending 915 the security context to the network function, and the method 900 ends.”)
PNG
media_image2.png
613
527
media_image2.png
Greyscale
As for claim 4, the limitations of parent claim 1 have been discussed above, Kunz discloses
The method of claim 1, further comprising:
sending, by the proxy entity (V-AAnF as a proxy ), an application key confirmation response to the AAnF (V-AAnF 413 acknowledges the request and sends (see messaging 422) a Key Provisioning Response back to the AAnF 417).
storing (the V-AAnF 309 stores the latest information), by the proxy entity (V-AAnF as a proxy), the application key confirmation request (selects the V-AAnF 309 and forwards (see messaging 328) the request in a Naanf_AKMA_KeyRegistration Request service operation).
(Kunz paragraph [0086] discloses “In a second option, Option B 324, in one embodiment, after AKMA key material is generated, the AUSF 311 selects the AMF 307 based on SN of the UE 305 and sends (see messaging 326) the generated A-KID and K.sub.AKMA to the AMF 307 together with the SUPI of the UE 305 using the Namf_AKMA_KeyRegistration Request service operation. The AMF 307, in one embodiment, selects the V-AAnF 309 and forwards (see messaging 328) the request in a Naanf_AKMA_KeyRegistration Request service operation. In one embodiment, V-AAnF 309 stores the latest information sent by the AUSF 311. The V-AAnF 309 sends (see messaging 330) the response to the AMF 307, which forwards (see messaging 332) the response to the AUSF 311 using the Naanf_AKMA_AnchorKey_Register Response service operation via the AMF 307.”
Paragraph [0100] discloses “At step 11, in one embodiment, the V-AAnF 413 acknowledges the request and sends (see messaging 422) a Key Provisioning Response back to the AAnF 417.”
Paragraph [0070] discloses “FIG. 2 depicts a procedure flow 200 for key provisioning to V-AAnF at Application Session Establishment Request. In one embodiment, procedure 200 describes the usage of a V-AAnF as a proxy in the VPLMN to receive the AKMA security context from the HPLMN AAnF. The V-AAnF may provide the AKMA security context to the related LI network function on request.”)
PNG
media_image1.png
718
606
media_image1.png
Greyscale
As for independent claim 7, Kunz discloses A key management method, applied in a roaming scenario, the method comprising:
receiving, by an application function (AF) in a home network (the UE 407 initiates communication (see messaging 404) with the AKMA AF 415), a service network identifier (Serving Network Name (“SN”) of the current VPLMN 401) and an AKMA key identifier (A-KID) sent by a terminal (UE 407).
(Kunz paragraph [0091] discloses “At step 2, in one embodiment, the UE 407 generates the AKMA Anchor Key (K.sub.AKMA) and the A-KID from the K.sub.AUSF before initiating communication with an AKMA AF 415. When the UE 407 initiates communication (see messaging 404) with the AKMA AF 415, in one embodiment, it may include the derived A-KID in the Application Session Establishment Request message. In one embodiment, the UE 407 may derive K.sub.AF before sending the message or afterwards. The UE 407 may include the Serving Network Name (“SN”) of the current VPLMN 401 in the request.”
Kunz describes step 2 of FIG. 4 disclose above.)
sending, by the AF, an application key acquisition request to an AAnF in the home network (the AF 415 sends (see messaging 406) the request towards the AAnF 417), wherein the application key acquisition request carries the service network identifier (request may include the A-KID and the AF_ID and the Serving Network Name (SN)), and the service network identifier is used to trigger the AAnF to send an application key confirmation request to a proxy entity (V-AAnF as a proxy ) in a service network (the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413) in case that the service network identifier of the terminal is different from a home network identifier (UE 407 included the Serving Network Name in step 1, then the AAnF 417 detects (see block 412) that the UE 407 is not located in the HPLMN 405 and is located in a different network);
(Kunz paragraph [0092] discloses “At step 3, in one embodiment, when the AF 415 is about to request AKMA Application Key for the UE 407 from the AAnF 417, e.g., when UE 407 initiates application session establishment request, the AF 415 sends (see messaging 406) the request towards the AAnF 417 via NEF service API (not shown). The request may include the A-KID and the AF_ID and the Serving Network Name (SN) if available. The AF_ID, in one embodiment, consists of the FQDN of the AF and the Ua* security protocol identifier. The latter parameter, in one embodiment, identifies the security protocol that the AF 415 will use with the UE 407. The AF 415 may directly send the request message to the AAnF 417 if no NEF is required.”
Paragraph [0099] discloses “At step 10, in one embodiment, the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), the SUPI, the A-KID, and potentially other parameters. The V-AAnF 413, in one embodiment, stores the information for potential requests for legal interception.”
Paragraph [0070] discloses “FIG. 2 depicts a procedure flow 200 for key provisioning to V-AAnF at Application Session Establishment Request. In one embodiment, procedure 200 describes the usage of a V-AAnF as a proxy in the VPLMN to receive the AKMA security context from the HPLMN AAnF. The V-AAnF may provide the AKMA security context to the related LI network function on request.”
Paragraph [0095] discloses “At step 6, in one embodiment, if the UE 407 included the Serving Network Name in step 1, then the AAnF 417 detects (see block 412) that the UE 407 is not located in the HPLMN 405 and is located in a different network. Alternatively, in one embodiment, the AUSF 419 provides the Serving Network Name together with the K.sub.AKMA after primary authentication as shown in FIG. 5, step 4. The AAnF 417 may skip steps 7 and 8 in this case.”
Kunz discloses step 3 in FIG.4 with HPLMN 405.)
and receiving, by the AF, an application key acquisition response fed back from the AAnF (the AAnF verifies the request, generates the K.sub.AF, and sends (see messaging 408) the response to the AF 415), wherein the application key acquisition response comprises AKMA application key information of the AF (AF 415 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), and potentially other parameters).
(Kunz paragraph [0093] discloses “In one embodiment, at step 4, the AAnF verifies the request, generates the K.sub.AF, and sends (see messaging 408) the response to the AF 415 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), and potentially other parameters.”)
As for claim 8, the limitations of parent claim 7 has been discussed above, Kunz discloses
the method of claim 7, wherein
the AKMA application key information comprises at least one of:
AKMA application key.
expiration time of the AKMA application key (K.sub.AF expiration time (KAFexptime)).
or SUPI of the terminal.
(Kunz paragraph [0093] discloses “In one embodiment, at step 4, the AAnF verifies the request, generates the K.sub.AF, and sends (see messaging 408) the response to the AF 415 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), and potentially other parameters.”
the AKMA application key information comprises at least one of; Examiner chose to map “expiration time of the AKMA application key”)
As for claim 9, the limitations of parent claim 7 have been discussed above, Kunz discloses the method of claim 7, wherein
sending, by the AF (), the application key acquisition request to the AAnF in the home network (the AF 415 sends (see messaging 406) the request towards the AAnF 417) comprises at least one of:
(Kunz paragraph [0092] discloses “At step 3, in one embodiment, when the AF 415 is about to request AKMA Application Key for the UE 407 from the AAnF 417, e.g., when UE 407 initiates application session establishment request, the AF 415 sends (see messaging 406) the request towards the AAnF 417 via NEF service API (not shown). The request may include the A-KID and the AF_ID and the Serving Network Name (SN) if available. The AF_ID, in one embodiment, consists of the FQDN of the AF and the Ua* security protocol identifier. The latter parameter, in one embodiment, identifies the security protocol that the AF 415 will use with the UE 407. The AF 415 may directly send the request message to the AAnF 417 if no NEF is required.”
Kunz discloses in FIG.4 the AAnF 417 is part of the HPLMN 405.)
sending, by the AF, a first application key acquisition request to the AAnF (the AF 415 sends (see messaging 406) the request towards the AAnF 417 ) in case that the AF requires terminal identification (Serving Network Name request to the AUSF 419 and includes the SUPI of the UE 407).
(Kunz paragraph [0092] discloses “At step 3, in one embodiment, when the AF 415 is about to request AKMA Application Key for the UE 407 from the AAnF 417, e.g., when UE 407 initiates application session establishment request, the AF 415 sends (see messaging 406) the request towards the AAnF 417 via NEF service API (not shown). The request may include the A-KID and the AF_ID and the Serving Network Name (SN) if available. The AF_ID, in one embodiment, consists of the FQDN of the AF and the Ua* security protocol identifier. The latter parameter, in one embodiment, identifies the security protocol that the AF 415 will use with the UE 407. The AF 415 may directly send the request message to the AAnF 417 if no NEF is required.”
Paragraph [0095] discloses “At step 6, in one embodiment, if the UE 407 included the Serving Network Name in step 1, then AAnF 417 detects (see block 412) that the UE 407 is not located in the HPLMN 405 and is located in a different network. Alternatively, in one embodiment, the AUSF 419 provides the Serving Network Name together with the K.sub.AKMA after primary authentication as shown in FIG. 5, step 4. AAnF 417 may skip steps 7 and 8 in this case”
Paragraph [0096] discloses “At step 7, in one embodiment, the AAnF 417 sends (see messaging 414) a Serving Network Name request to the AUSF 419 and includes the SUPI of the UE 407. Alternatively, the AAnF 417 may directly contact the UDM about the Serving Network Name. The AUSF 419 may contact the UDM if the Serving Network Name is not stored anymore for the specific SUPI”
Kunz discloses that UE not in the HPLMN will go through step 7/8 to further validate the SUPI of the UE is still valid for the service name. Kunz discloses SUPI is the subscription permanent identifier of the UE.)
or sending, by the AF, a second application key acquisition request to the AAnF (the AF 415 sends (see messaging 406) the request towards the AAnF 417) in the home network in case that the AF in the home network does not require terminal identification (AF 415 sends (see messaging 410) the Application Session Establishment Response to the UE 407).
(Kunz paragraph [0092] discloses “At step 3, in one embodiment, when the AF 415 is about to request AKMA Application Key for the UE 407 from the AAnF 417, e.g., when UE 407 initiates application session establishment request, the AF 415 sends (see messaging 406) the request towards the AAnF 417 via NEF service API (not shown). The request may include the A-KID and the AF_ID and the Serving Network Name (SN) if available. The AF_ID, in one embodiment, consists of the FQDN of the AF and the Ua* security protocol identifier. The latter parameter, in one embodiment, identifies the security protocol that the AF 415 will use with the UE 407. The AF 415 may directly send the request message to the AAnF 417 if no NEF is required.”
Paragraph [0094] discloses “At step 5, in one embodiment, the AF 415 sends (see messaging 410) the Application Session Establishment Response to the UE 407”
Kunz discloses step 6 in FIG.4 to determine if the UE not in the HPLMN to further proceed validate the SUPI of the UE for the service name. Step 5 is a result that the UE is part of the HPLMN, therefore, the AAnF already validated the SUPI of the UE.)
As for claim 10, the limitations of parent claim 9 have been discussed above, Kunz discloses
the method of claim 9, wherein
the first application key acquisition request or the second application key acquisition request comprises at least one of:
an AKMA key identifier of the terminal.
or an AF identifier of the AF in the home network (AF_ID).
(Kunz paragraph [0092] discloses “At step 3, in one embodiment, when the AF 415 is about to request AKMA Application Key for the UE 407 from the AAnF 417, e.g., when UE 407 initiates application session establishment request, the AF 415 sends (see messaging 406) the request towards the AAnF 417 via NEF service API (not shown). The request may include the A-KID and the AF_ID and the Serving Network Name (SN) if available. The AF_ID, in one embodiment, consists of the FQDN of the AF and the Ua* security protocol identifier. The latter parameter, in one embodiment, identifies the security protocol that the AF 415 will use with the UE 407. The AF 415 may directly send the request message to the AAnF 417 if no NEF is required.”
Kunz discloses in FIG.4 the AF is requesting service to AAnF 417 within HPLMN 405 which is the serving network anchored by AAnF 417.)
As for claim 11, the limitations of parent claim 10 have been discussed above, Kunz discloses
The method of claim 10, wherein
the first application key acquisition request or the second application key acquisition request (AF 415 sends (see messaging 406) the request towards the AAnF) comprises the AKMA key identifier (AF_ID) and the service network identifier (Serving Network Name (SN)).
(Kunz paragraph [0092] discloses “At step 3, in one embodiment, when the AF 415 is about to request AKMA Application Key for the UE 407 from the AAnF 417, e.g., when UE 407 initiates application session establishment request, the AF 415 sends (see messaging 406) the request towards the AAnF 417 via NEF service API (not shown). The request may include the A-KID and the AF_ID and the Serving Network Name (SN) if available. The AF_ID, in one embodiment, consists of the FQDN of the AF and the Ua* security protocol identifier. The latter parameter, in one embodiment, identifies the security protocol that the AF 415 will use with the UE 407. The AF 415 may directly send the request message to the AAnF 417 if no NEF is required.”)
the AKMA key identifier (A-KID) carries the service network identifier (Visited Network Identifier (e.g., SN)).
(Kunz paragraph [0087] discloses “In one embodiment, the A-KID identifies the K.sub.AKMA key of the UE 305. In further embodiments, the A-KID shall be in network access identifier (“NAI”) format, e.g., username@realm. The username part may include the RID and the AKMA Temporary UE Identifier (A-TID), and the realm part may include Visited Network Identifier (e.g., SN). In one embodiment, the A-TID may be derived from K.sub.AUSF. The AUSF 311 may use the RID received from the UDM 313 to derive A-KID”)
or the first application key acquisition request (AF 415 sends (see messaging 406) the request towards the AAnF 417) or the second application key acquisition request carries the service network identifier through a separate field (Serving Network Name (SN) if available).
(Kunz paragraph [0092] discloses “At step 3, in one embodiment, when the AF 415 is about to request AKMA Application Key for the UE 407 from the AAnF 417, e.g., when UE 407 initiates application session establishment request, the AF 415 sends (see messaging 406) the request towards the AAnF 417 via NEF service API (not shown). The request may include the A-KID and the AF_ID and the Serving Network Name (SN) if available. The AF_ID, in one embodiment, consists of the FQDN of the AF and the Ua* security protocol identifier. The latter parameter, in one embodiment, identifies the security protocol that the AF 415 will use with the UE 407. The AF 415 may directly send the request message to the AAnF 417 if no NEF is required.”)
As for claim 16, the limitations of parent claim 7 have been discussed above, Kunz discloses
the method of claim 7,
further comprising at least one of:
receiving, by the AF, an error response fed back from the AAnF, and sending the error response to the terminal, wherein the error response is sent in case that the AKMA key of the terminal is not stored in the AAnF.
or receiving, by the AF (AKMA AF 613), an application session establishment request sent by the terminal (When the UE 607 initiates communication (see messaging 616) with the AKMA AF 613, in one embodiment, it includes the derived A-KID in the Application Session Establishment Request message) and feeding back an application session establishment response to the terminal (the AF 613 sends (see messaging 628) the Application Session Establishment Response to the UE 607), wherein the application session establishment request carries the service network identifiers (Visited Network Identifier (e.g., SN)).
(Kunz paragraph [0107] discloses “At step 5, in one embodiment, the UE 607 generates the AKMA Anchor Key (K.sub.AKMA) and the A-KID from the K.sub.AUSF before initiating communication with an AKMA AF 613. When the UE 607 initiates communication (see messaging 616) with the AKMA AF 613, in one embodiment, it includes the derived A-KID in the Application Session Establishment Request message. In one embodiment, the UE 607 derives K.sub.AF before or after sending the message. “
Paragraph [0114] discloses “In one embodiment, at step 9, the AF 613 sends (see messaging 628) the Application Session Establishment Response to the UE 607.”
Paragraph [0087] discloses “In one embodiment, the A-KID identifies the K.sub.AKMA key of the UE 305. In further embodiments, the A-KID shall be in network access identifier (“NAI”) format, e.g., username@realm. The username part may include the RID and the AKMA Temporary UE Identifier (A-TID), and the realm part may include Visited Network Identifier (e.g., SN). In one embodiment, the A-TID may be derived from K.sub.AUSF. The AUSF 311 may use the RID received from the UDM 313 to derive A-KID”
The method further comprising at least one of, examiner chose to map “receiving, by the AF, an application session establishment request sent by the and feeding back an application session establishment response to the, wherein the application session establishment request carries the service network identifiers”).
As for claim 17, the limitations of parent claim 7 have been discussed above, Kunz discloses
the method of claim 7,
further comprising:
discovering, by the AF (the AF 613 sends (see messaging 618) the request towards the AAnF 617 via a NEF 615 service API), the AAnF through NRF (Network Exposure Function (“NEF”) (which is responsible for making network data and resources easily accessible to customers and network partners, e.g., via one or more APIs), a Network Repository Function (“NRF”) (which provides NF service registration and discovery, enabling NFs to identify appropriate services in one another and communicate with each other over Application Programming Interfaces (“APIs”)), or other NFs defined for the 5GC).
(Kunz paragraph [0061] discloses “In various embodiments, the mobile core network 140 may also include an Network Exposure Function (“NEF”) (which is responsible for making network data and resources easily accessible to customers and network partners, e.g., via one or more APIs), a Network Repository Function (“NRF”) (which provides NF service registration and discovery, enabling NFs to identify appropriate services in one another and communicate with each other over Application Programming Interfaces (“APIs”)), or other NFs defined for the 5GC. In certain embodiments, the mobile core network 140 may include an authentication, authorization, and accounting (“AAA”) server.”
Paragraph [0108] discloses “In one embodiment, at step 6, when the AF 613 is about to request the AKMA Application Key for the UE 607 from the AAnF 617, e.g., when UE 607 initiates application session establishment request, the AF 613 sends (see messaging 618) the request towards the AAnF 617 via a NEF 615 service API. The request may include the A-KID and the AF_ID. The AF_ID, in one embodiment, consists of the FQDN of the AF 613 and the Ua* security protocol identifier. The latter parameter, in one embodiment, identifies the security protocol that the AF 613 will use with the UE 607. The AF 613 may directly send the request message to the AAnF 617 if no NEF 615 is required; otherwise, the NEF 615 sends (see messaging 620) the request to the AAnF 617.”
Kunz discloses that AAnF is a network function deployed and stored in NRF. )
As for claim 19, the limitations of parent claim 16 have been discussed above, Kunz discloses
the method of claim 16, wherein
The application session establishment request comprises an AKMA key identifier of AKMA (When the UE 607 initiates communication (see messaging 616) with the AKMA AF 613, in one embodiment, it includes the derived A-KID in the Application Session Establishment Request message), wherein the AKMA key identifier carries the service network identifier (Visited Network Identifier (e.g., SN))
(Kunz paragraph [0107] discloses “At step 5, in one embodiment, the UE 607 generates the AKMA Anchor Key (K.sub.AKMA) and the A-KID from the K.sub.AUSF before initiating communication with an AKMA AF 613. When the UE 607 initiates communication (see messaging 616) with the AKMA AF 613, in one embodiment, it includes the derived A-KID in the Application Session Establishment Request message. In one embodiment, the UE 607 derives K.sub.AF before or after sending the message. “
Paragraph [0087] discloses “In one embodiment, the A-KID identifies the K.sub.AKMA key of the UE 305. In further embodiments, the A-KID shall be in network access identifier (“NAI”) format, e.g., username@realm. The username part may include the RID and the AKMA Temporary UE Identifier (A-TID), and the realm part may include Visited Network Identifier (e.g., SN). In one embodiment, the A-TID may be derived from K.sub.AUSF. The AUSF 311 may use the RID received from the UDM 313 to derive A-KID”)
or the application session establishment request comprises the AKMA key identifier (When the UE 407 initiates communication (see messaging 404) with the AKMA AF 415, in one embodiment, it may include the derived A-KID in the Application Session Establishment Request message) and the service network identifier (The UE 407 may include the Serving Network Name (“SN”) of the current VPLMN 401 in the request); wherein,
(Kunz paragraph [0091] discloses “At step 2, in one embodiment, the UE 407 generates the AKMA Anchor Key (K.sub.AKMA) and the A-KID from the K.sub.AUSF before initiating communication with an AKMA AF 415. When the UE 407 initiates communication (see messaging 404) with the AKMA AF 415, in one embodiment, it may include the derived A-KID in the Application Session Establishment Request message. In one embodiment, the UE 407 may derive K.sub.AF before sending the message or afterwards. The UE 407 may include the Serving Network Name (“SN”) of the current VPLMN 401 in the request.”)
The AKMA key identifier is an identifier of an AKMA key of the terminal (the A-KID identifies the K.sub.AKMA key of the UE 305).
(Kunz paragraph [0087] discloses “In one embodiment, the A-KID identifies the K.sub.AKMA key of the UE 305. In further embodiments, the A-KID shall be in network access identifier (“NAI”) format, e.g., username@realm. The username part may include the RID and the AKMA Temporary UE Identifier (A-TID), and the realm part may include Visited Network Identifier (e.g., SN). In one embodiment, the A-TID may be derived from K.sub.AUSF. The AUSF 311 may use the RID received from the UDM 313 to derive A-KID”)
As for claim 21, the limitations of parent claim 7 have been discussed above, Kunz discloses a key management method according to claim 7, the method comprising: 1
receiving, by the AAnF (AAnF 417 ) in the home network, the application key acquisition request sent by the AF (the AF 415 sends (see messaging 406) the request towards the AAnF 417 via NEF service API (not shown). The request may include the A-KID and the AF_ID and the Serving Network Name (SN) if available) in the home network, wherein the application key acquisition request carries the service network identifier (Serving Network Name (SN) if available).
(Kunz paragraph [0092] discloses “At step 3, in one embodiment, when the AF 415 is about to request AKMA Application Key for the UE 407 from the AAnF 417, e.g., when UE 407 initiates application session establishment request, the AF 415 sends (see messaging 406) the request towards the AAnF 417 via NEF service API (not shown). The request may include the A-KID and the AF_ID and the Serving Network Name (SN) if available. The AF_ID, in one embodiment, consists of the FQDN of the AF and the Ua* security protocol identifier. The latter parameter, in one embodiment, identifies the security protocol that the AF 415 will use with the UE 407. The AF 415 may directly send the request message to the AAnF 417 if no NEF is required.”)
generating, by the AAnF in the home network, an AKMA application key of the AF based on an AKMA key (The request may include the A-KID and the AF_ID and the Serving Network Name (SN) if available) of the terminal (the AAnF verifies the request, generates the K.sub.AF, and sends (see messaging 408) the response to the AF 415);
(Kunz paragraph [0092] discloses “At step 3, in one embodiment, when the AF 415 is about to request AKMA Application Key for the UE 407 from the AAnF 417, e.g., when UE 407 initiates application session establishment request, the AF 415 sends (see messaging 406) the request towards the AAnF 417 via NEF service API (not shown). The request may include the A-KID and the AF_ID and the Serving Network Name (SN) if available. The AF_ID, in one embodiment, consists of the FQDN of the AF and the Ua* security protocol identifier. The latter parameter, in one embodiment, identifies the security protocol that the AF 415 will use with the UE 407. The AF 415 may directly send the request message to the AAnF 417 if no NEF is required.”
Paragraph [0093] discloses “In one embodiment, at step 4, the AAnF verifies the request, generates the K.sub.AF, and sends (see messaging 408) the response to the AF 415 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), and potentially other parameters.”)
feeding back, by the AAnF in the home network, the application key acquisition response to the AF (the AAnF verifies the request, generates the K.sub.AF, and sends (see messaging 408) the response to the AF), wherein the application key acquisition response comprises the AKMA application key information of the AF (with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), and potentially other parameters); and
(Kunz paragraph [0093] discloses “In one embodiment, at step 4, the AAnF verifies the request, generates the K.sub.AF, and sends (see messaging 408) the response to the AF 415 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), and potentially other parameters.”)
sending, by the AAnF in the home network, the application key confirmation request to the proxy entity (V-AAnF as a proxy) in the service network (the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), the SUPI, the A-KID, and potentially other parameters).
(Kunz paragraph [0099] discloses “At step 10, in one embodiment, the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), the SUPI, the A-KID, and potentially other parameters. V-AAnF 413, in one embodiment, stores the information for potential requests for legal interception.”
Paragraph [0070] discloses “FIG. 2 depicts a procedure flow 200 for key provisioning to V-AAnF at Application Session Establishment Request. In one embodiment, procedure 200 describes the usage of a V-AAnF as a proxy in the VPLMN to receive the AKMA security context from the HPLMN AAnF. The V-AAnF may provide the AKMA security context to the related LI network function on request.”)
As for claim 22, the limitations of parent claim 21 have been discussed above, Kunz discloses
the method of claim 21, wherein
receiving, by the AAnF in the home network, the application key acquisition request sent by the AF in the home network (the AF 415 sends (see messaging 406) the request towards the AAnF 417) comprises at least one of:
receiving, by the AAnF in the home network, a first application key acquisition request sent by the AF (the AF 415 sends (see messaging 406) the request towards the AAnF 417), wherein the first application key acquisition request is used to indicate that the AF requires terminal identification (The request may include the A-KID and the AF_ID and the Serving Network Name (SN) if available);
(Kunz paragraph [0092] discloses “At step 3, in one embodiment, when the AF 415 is about to request AKMA Application Key for the UE 407 from the AAnF 417, e.g., when UE 407 initiates application session establishment request, the AF 415 sends (see messaging 406) the request towards the AAnF 417 via NEF service API (not shown). The request may include the A-KID and the AF_ID and the Serving Network Name (SN) if available. The AF_ID, in one embodiment, consists of the FQDN of the AF and the Ua* security protocol identifier. The latter parameter, in one embodiment, identifies the security protocol that the AF 415 will use with the UE 407. The AF 415 may directly send the request message to the AAnF 417 if no NEF is required.”
Paragraph [0095] discloses “At step 6, in one embodiment, if the UE 407 included the Serving Network Name in step 1, then AAnF 417 detects (see block 412) that the UE 407 is not located in the HPLMN 405 and is located in a different network. Alternatively, in one embodiment, the AUSF 419 provides the Serving Network Name together with the K.sub.AKMA after primary authentication as shown in FIG. 5, step 4. AAnF 417 may skip steps 7 and 8 in this case;”
Paragraph [0096] discloses “At step 7, in one embodiment, the AAnF 417 sends (see messaging 414) a Serving Network Name request to the AUSF 419 and includes the SUPI of the UE 407. Alternatively, the AAnF 417 may directly contact the UDM about the Serving Network Name. The AUSF 419 may contact the UDM if the Serving Network Name is not stored anymore for the specific SUPI.”
Examiner chose to map “receiving, by the AAnF in the home network, a first application key acquisition request sent by the AF, wherein the first application key acquisition request is used to indicate that the AF requires terminal identification.”
Kunz discloses the A-KID contains the SUPI of the UE. Step 6 discloses the UE is not located in the HPLMN, therefore, step 7/8 are necessary to validate the UE with AUSF.)
or receiving, by the AAnF in the home network, a second application key acquisition request sent by the AF, wherein the second application key acquisition request is used to indicate that the AF does not require terminal identification, wherein the AKMA application key information fed back from the AAnF does not comprise SUPI of the terminal in case that the AAnF receives the second application key acquisition request.
As for claim 25, the limitations of parent claim 21 have been discussed above, Kunz discloses
the method of claim 21, further comprising:
determining that the AAnF provides services to the AF (the AAnF 617 may not provide the K.sub.AF to the AF 613) and a proxy entity (a V-AAnF) in the service network based on authorization information or policy (does have a LI policy), wherein the authorization information or policy (does have a LI policy) is provided by a local policy (if the VPLMN 601 has AKMA LI enhancements, then the AAnF 617 provides the K.sub.AF and the K.sub.AF expiration time together with the SUPI of the UE 607 to the network function for storing the AKMA LI context, e.g., a V-AAnF 611 in the VPLMN 601.) or NRF in the home network.
(Kunz paragraph [0109] discloses “At step 7, in one embodiment, the AAnF 617 detects (see block 622), based on the SN name where the UE 607 is roaming, and
[0110] if the VPLMN 601 has no AKMA LI enhancements, but does have a LI policy, then the AAnF 617 may not provide the K.sub.AF to the AF 613 and indicates a NULL encryption.”
Paragraph [0111] discloses “if the VPLMN 601 has AKMA LI enhancements, then the AAnF 617 provides the K.sub.AF and the K.sub.AF expiration time together with the SUPI of the UE 607 to the network function for storing the AKMA LI context, e.g., a V-AAnF 611 in the VPLMN 601.”)
As for claim 27, the limitations of parent claim 21 have been discussed above, Kunz discloses
the method of any of claim 21, wherein
sending the application key confirmation request (the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), the SUPI, the A-KID, and potentially other parameters) to the proxy entity (V-AAnF as a proxy) in the service network comprises:
sending the application key confirmation request (the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), the SUPI, the A-KID, and potentially other parameters) to the proxy entity (V-AAnF as a proxy) in case that a service network identifier of the terminal is different from a home network identifier (AAnF 417 detects (see block 412) that the UE 407 is not located in the HPLMN 405 and is located in a different network); wherein
(Kunz paragraph [0070] discloses “FIG. 2 depicts a procedure flow 200 for key provisioning to V-AAnF at Application Session Establishment Request. In one embodiment, procedure 200 describes the usage of a V-AAnF as a proxy in the VPLMN to receive the AKMA security context from the HPLMN AAnF. The V-AAnF may provide the AKMA security context to the related LI network function on request.”
Paragraph [0099] discloses “At step 10, in one embodiment, the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), the SUPI, the A-KID, and potentially other parameters. V-AAnF 413, in one embodiment, stores the information for potential requests for legal interception.”
Paragraph [0095] discloses “At step 6, in one embodiment, if the UE 407 included the Serving Network Name in step 1, then AAnF 417 detects (see block 412) that the UE 407 is not located in the HPLMN 405 and is located in a different network. Alternatively, in one embodiment, the AUSF 419 provides the Serving Network Name together with the K.sub.AKMA after primary authentication as shown in FIG. 5, step 4. AAnF 417 may skip steps 7 and 8 in this case;”
Kunz FIG.4 discloses once AAnF 417 detects UE 407 is not located in the HPLMN 405, the AAnF perform UE validation and proceeds to step 10 to request update to the V-AAnF, the proxy entity, to update the AKMA context of the UE.)
the method further comprises:
receiving an application key confirmation response sent by the proxy entity (the V-AAnF 413 acknowledges the request and sends (see messaging 422) a Key Provisioning Response back to the AAnF 417).
(Kunz paragraph [0100] discloses “At step 11, in one embodiment, the V-AAnF 413 acknowledges the request and sends (see messaging 422) a Key Provisioning Response back to the AAnF 417.”)
As for claim 30, the limitations of parent claim 21 have been discussed above, Kunz discloses
the method of claim 21, further comprising:
discovering the proxy entity in the-network elements of the service network through an NRF in the service network and the home network (Network Exposure Function (“NEF”) (which is responsible for making network data and resources easily accessible to customers and network partners, e.g., via one or more APIs), a Network Repository Function (“NRF”) (which provides NF service registration and discovery, enabling NFs to identify appropriate services in one another and communicate with each other over Application Programming Interfaces (“APIs”)), or other NFs defined for the 5GC), in case that the service network identifier of the terminal is different from the home network identifier (AAnF 417 detects (see block 412) that the UE 407 is not located in the HPLMN 405 and is located in a different network).
(Kunz paragraph [0061] discloses “In various embodiments, the mobile core network 140 may also include an Network Exposure Function (“NEF”) (which is responsible for making network data and resources easily accessible to customers and network partners, e.g., via one or more APIs), a Network Repository Function (“NRF”) (which provides NF service registration and discovery, enabling NFs to identify appropriate services in one another and communicate with each other over Application Programming Interfaces (“APIs”)), or other NFs defined for the 5GC. In certain embodiments, the mobile core network 140 may include an authentication, authorization, and accounting (“AAA”) server.”
Paragraph [0108] discloses “In one embodiment, at step 6, when the AF 613 is about to request the AKMA Application Key for the UE 607 from the AAnF 617, e.g., when UE 607 initiates application session establishment request, the AF 613 sends (see messaging 618) the request towards the AAnF 617 via a NEF 615 service API. The request may include the A-KID and the AF_ID. The AF_ID, in one embodiment, consists of the FQDN of the AF 613 and the Ua* security protocol identifier. The latter parameter, in one embodiment, identifies the security protocol that the AF 613 will use with the UE 607. The AF 613 may directly send the request message to the AAnF 617 if no NEF 615 is required; otherwise, the NEF 615 sends (see messaging 620) the request to the AAnF 617.”
Paragraph [0095] discloses “At step 6, in one embodiment, if the UE 407 included the Serving Network Name in step 1, then AAnF 417 detects (see block 412) that the UE 407 is not located in the HPLMN 405 and is located in a different network. Alternatively, in one embodiment, the AUSF 419 provides the Serving Network Name together with the K.sub.AKMA after primary authentication as shown in FIG. 5, step 4. AAnF 417 may skip steps 7 and 8 in this case;”
Kunz discloses V-AAnF is a proxy and network function in the NRF.)
As for independent claim 31, Kunz discloses a key management method, applied in a roaming scenario, and performed by a terminal, the method comprising:
sending a service network identifier (Serving Network Name (“SN”) of the current VPLMN 401) and an AKMA key identifier (A-KID) to an application function (AF) in a home network (the UE 407 initiates communication (see messaging 404) with the AKMA AF 415), wherein the service network identifier (Serving Network Name in step 1, then the AAnF 417 detects (see block 412) that the UE 407 is not located in the HPLMN 405 and is located in a different network) is used to trigger an AAnF in the home network to send an application key confirmation request to a proxy entity in a service network (the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), the SUPI, the A-KID, and potentially other parameters) in case that the service network identifier of the terminal is different from a home network identifier (Serving Network Name in step 1, then the AAnF 417 detects (see block 412) that the UE 407 is not located in the HPLMN 405 and is located in a different network), and the AKMA key identifier is an identifier of an AKMA key of the terminal(the A-KID identifies the K.sub.AKMA key of the UE 305).
(Kunz paragraph [0091] discloses “At step 2, in one embodiment, the UE 407 generates the AKMA Anchor Key (K.sub.AKMA) and the A-KID from the K.sub.AUSF before initiating communication with an AKMA AF 415. When the UE 407 initiates communication (see messaging 404) with the AKMA AF 415, in one embodiment, it may include the derived A-KID in the Application Session Establishment Request message. In one embodiment, the UE 407 may derive K.sub.AF before sending the message or afterwards. The UE 407 may include the Serving Network Name (“SN”) of the current VPLMN 401 in the request.”
Paragraph [0095] discloses “At step 6, in one embodiment, if the UE 407 included the Serving Network Name in step 1, then the AAnF 417 detects (see block 412) that the UE 407 is not located in the HPLMN 405 and is located in a different network. Alternatively, in one embodiment, the AUSF 419 provides the Serving Network Name together with the K.sub.AKMA after primary authentication as shown in FIG. 5, step 4. AAnF 417 may skip steps 7 and 8 in this case”
Paragraph [0099] discloses “At step 10, in one embodiment, the AAnF 417 sends (see messaging 420) a Key Provisioning Request to the V-AAnF 413 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), the SUPI, the A-KID, and potentially other parameters. V-AAnF 413, in one embodiment, stores the information for potential requests for legal interception.”
Paragraph [0087] discloses “In one embodiment, the A-KID identifies the K.sub.AKMA key of the UE 305. In further embodiments, the A-KID shall be in network access identifier (“NAI”) format, e.g., username@realm. The username part may include the RID and the AKMA Temporary UE Identifier (A-TID), and the realm part may include Visited Network Identifier (e.g., SN). In one embodiment, the A-TID may be derived from K.sub.AUSF. The AUSF 311 may use the RID received from the UDM 313 to derive A-KID”)
Claim Rejections - 35 USC § 103
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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application is 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 15 is rejected under 35 U.S.C. 103 as being unpatentable over Kunz in view of Jalkanen et al., US Patent Publication 20210234928, published on 7/29/2021 (hereinafter Jalkanen).
As for claim 15, the limitations of parent claim 9 have been discussed above, Kunz discloses
the method of claim 9, wherein
whether the AF requires the terminal identification is indicated
(Kunz paragraph [0095] discloses “At step 6, in one embodiment, if the UE 407 included the Serving Network Name in step 1, then AAnF 417 detects (see block 412) that the UE 407 is not located in the HPLMN 405 and is located in a different network. Alternatively, in one embodiment, the AUSF 419 provides the Serving Network Name together with the K.sub.AKMA after primary authentication as shown in FIG. 5, step 4. AAnF 417 may skip steps 7 and 8 in this case”
Paragraph [0096] discloses “At step 7, in one embodiment, the AAnF 417 sends (see messaging 414) a Serving Network Name request to the AUSF 419 and includes the SUPI of the UE 407. Alternatively, the AAnF 417 may directly contact the UDM about the Serving Network Name. The AUSF 419 may contact the UDM if the Serving Network Name is not stored anymore for the specific SUPI.”
Kunz discloses step 7/8 to validate the SUPI of UE with AUSF.)
Kunz does not appear to explicitly disclose “indicated by a policy in the AF” . However, in a similar field of endeavor, Jalkanen discloses a method indicated by a policy in the AF (the charging and policy scheme being accessible with an application function initiated for the terminal device; in response to an assignment of the network slice and an assignment of the charging and policy scheme for the communication session generate an acknowledgement to the terminal device).
(Jalkanen paragraph [0010] discloses “According to a second aspect, a network node is provided, the network node comprising: at least one processor; at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the network node to perform: receive a registration request from a terminal device, the registration request comprising data indicating a unique transaction identifier for the terminal device; assign on a basis of the unique transaction identifier a network slice of a mobile communication network providing communication service to the terminal device, the network slice being accessible with a session management function initiated for the terminal device, assign a charging and policy scheme to be applied to the terminal device; the charging and policy scheme being accessible with an application function initiated for the terminal device; in response to an assignment of the network slice and an assignment of the charging and policy scheme for the communication session generate an acknowledgement to the terminal device, the acknowledgement indicating an acceptance to the registration request for causing a setup of the communication session between the terminal device and the application function through a user plane function.”)
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Jalkanen with Kunz for the benefit of having a method using a policy within the AF to determine whether a terminal identification is requires by the AAnF. Further benefit to combine is to make the method more effective since it is the service(s) for the UE is available prior to the AKMA procedure.
Claims 20 is rejected under 35 U.S.C. 103 as being unpatentable over Kunz in view of Guo et al., US Patent Publication No. 20230086032, effective filing on 4/27/2021 (hereinafter Guo).
As for claim 20, the limitations of parent claim 16 have been discussed above, Kunz discloses
the method of claim 16, further comprising:
feeding back, by the AF, (the AF 415 sends (see messaging 410) the Application Session Establishment Response to the UE 407) (the AAnF verifies the request, generates the K.sub.AF, and sends (see messaging 408) the response to the AF 415 ), wherein the (the K.sub.AF, the K.sub.AF expiration time (KAFexptime), and potentially other parameters).
(Kunz paragraph [0093] discloses “In one embodiment, at step 4, the AAnF verifies the request, generates the K.sub.AF, and sends (see messaging 408) the response to the AF 415 with the K.sub.AF, the K.sub.AF expiration time (KAFexptime), and potentially other parameters.”
Paragraph [0094] discloses “At step 5, in one embodiment, the AF 415 sends (see messaging 410) the Application Session Establishment Response to the UE 407.”)
Kunz does not appear to explicitly disclose the method comprising feeding back rejection information for application session to the terminal in case of receiving an error response fed back from the AAnF wherein the rejection information comprises a response failure reason. However, in a similar field of endeavor, Guo discloses a method for managing feeding back rejection information for application session to the terminal (the application function network element indicates a first application session establishment failure to the terminal device) in case of receiving an error response fed back from the AAnF (the AKMA anchor function network element indicates a request failure in a communication key between a terminal device and an application function) wherein the rejection information comprises a response failure reason (the identification information of the first key cannot be determined).
(Guo paragraph [0056] discloses “In the method, after re-authentication occurs, if the first key corresponding to the identification information of the first key cannot be determined, the authentication server function network element indicates to the AKMA anchor function network element that the first key cannot be determined, so that the AKMA anchor function network element indicates a request failure in a communication key between a terminal device and an application function network element to the application function network element, and the application function network element indicates a first application session establishment failure to the terminal device. In this way, the terminal device can re-initiate an application session establishment procedure. Therefore, it is ensured that the terminal device and the application function network element successfully agree on the communication key between the terminal device and the application function network element, to implement secure communication between the terminal device and the application function network element.”)
Accordingly, it would have been obvious to person of ordinary skill in the art before the effective filing date of the claimed invention to combine Gou with Kunz for the benefit of having a method to feed error condition from the application function to the terminal when requesting for AKMA Key service. Further benefit to combine is providing a more effective way to manage the AKMA key context information in the database so that the correct communication key between the terminal device and application function.
Conclusion
Below are references not relied upon but are pertinent to applicant’s disclosure:
Peng et al., US Patent Application No. 20220295272, published on 9/15/2022 [CON 4/28/2020] (hereinafter Peng)
[0095] In some embodiments, the third network function includes an Authentication and Key Management Application (AKMA) anchor function (AAnF).
[0106] In some embodiments, the first network function comprises an Authentication and Key Management Application (AKMA) anchor function (AAnF).
You et al., US Patent Publication No. 20230232240, published on 7/20/2023 [foreign priority 10/16/2020] (hereinafter You)
[0070] For example, the query message may carry a network function name (such as the AAnF) and/or a network type (such as the AAnF type) and a user identifier SUPI and/or the location information of the first network function node. The third network function node may be a network repository function (NRF), that is, the NRF queries the AAnF storing the AKMA context of the user according to the SUPI and/or the UDM location information and the AAnF network function name and/or the AAnF network type in the query message and then sends a query response message to the UDM.
[0072] For example, the fourth network function node may be an AUSF, and the subscription change request may carry a network function name (such as the AAnF) and/or a network type (such as the AAnF type) and a user identifier SUPI and/or the location information of the first network function node. That is, the AUSF queries the AAnF storing the AKMA context of the user according to the SUPI and/or the UDM location information and the AAnF network function name and/or the AAnF network type and sends the query result to the UDM in the form of the subscription change request response message.
[0081] The second network function node may be an AAnF, and the AAnF is used for storing the AKMA context of the user.
[0087] In this embodiment of the present application, the fourth network function node may be an AUSF, the second network function node may be an AAnF, and the AAnF is used for storing the AKMA context of the user.
[0089] The first network function node may be a UDM, that is, after the AUSF receives the subscription change request message sent by the UDM, the AUSF queries the AAnF storing the AKMA context of the user according to the user identifier in the message.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSEPH K NGUYEN whose telephone number is (571)467-6390. The examiner can normally be reached Monday-Friday 8am-5pm.
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, Jeanette J Parker can be reached at 571-270-3647. 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.
/JOSEPH KHANH NGUYEN/Examiner, Art Unit 2646
/JEANETTE J PARKER/Supervisory Patent Examiner, Art Unit 2646
Prosecution Insights