DETAILED ACTION
Notice of 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 .
The present office action is responsive to communications received on 2/9/2024. Claims 1-26 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 2/9/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 15 and 23-24 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ericsson (NPL "AKMA SBA Interface Clarifications", 2020, listed in IDS).
Regarding claim 1, Ericsson teaches a method performed by an Authentication and Key Management for Applications, AKMA, Anchor Function, AAnF, in a core network of the cellular communications system for generating a shared secret key for AKMA, the method comprising:
receiving, directly or indirectly from an Application Function, AF, a request for a shared secret key for AKMA, the request comprising an AF ID; (section 6.2 Deriving AKMA Application Key for a specific AF; "the AF sends a Naanf_AKMA_ApplicationKey_Get request to AAnF with the A-KID to request the AKMA Application Key for the UE. The AF also includes its identity (AF Id) in the request.”)
determining whether the AF is authorized to use the AF ID; and (section 6.2 Deriving AKMA Application Key for a specific AF; "The AAnF shall authorize AF. The AAnF shall check whether the AAnF can provide the service to the AF based on the configured local policy or based on the authorization information or policy provided by the NRF using the AF Id.”)
performing one or more actions based on a result of determining whether the AF is authorized to use the AF ID. (section 6.2 Deriving AKMA Application Key for a specific AF; "If [authorization] succeeds, the following procedures are executed. Otherwise, the AAnF shall reject the procedure.“)
Regarding claim 2, Ericsson teaches all the features with respect to claim 1, as outlined above. Ericsson further teaches
wherein the AF ID comprises an AF Fully Qualified Domain Name, FQDN, and a Ua* protocol identifier. (section 6.2 Deriving AKMA Application Key for a specific AF; "AF_ID = FQDN of the AF II Ua* security protocol identifier.")
Regarding claim 15, Ericsson teaches all the features with respect to claim 1, as outlined above. Ericsson further teaches
wherein determining whether the AF is authorized to use the AF ID comprises determining whether the AF is authorized to use the AF ID based on asserted AF information. (section 6.2 Deriving AKMA Application Key for a specific AF; "the AF sends a Naanf_AKMA_ApplicationKey_Get request to AAnF with the A-KID to request the AKMA Application Key for the UE. The AF also includes its identity (AF Id) in the request. The AAnF shall authorize AF. The AAnF shall check whether the AAnF can provide the service to the AF based on the configured local policy or based on the authorization information or policy provided by the NRF using the AF Id.") Here details are shown in Figure 6.2-1: KAF generation from KAKMA.
Regarding claim 23, Ericsson teaches all the features with respect to claim 1, as outlined above. Ericsson further teaches
determining whether the AF is authorized to use the AF ID comprises determining that the AF is authorized to use the AF ID; and (section 6.2 Deriving AKMA Application Key for a specific AF; "The AAnF shall authorize AF. The AAnF shall check whether the AAnF can provide the service to the AF based on the configured local policy or based on the authorization information or policy provided by the NRF using the AF Id.”)
performing the one or more actions based on the result of determining whether the AF is authorized to use the AF ID comprises, responsive to determining that the AF is authorized to use the AF ID: (section 6.2 Deriving AKMA Application Key for a specific AF; "If [authorization] succeeds, the following procedures are executed. Otherwise, the AAnF shall reject the procedure.“)
deriving the shared secret key for AKMA; and (section 6.2 Deriving AKMA Application Key for a specific AF; “The AAnF derives the AKMA Application Key (KAF) from KAKMA.”)
sending, directly or indirectly to the AF, a response message that comprises the shared secret key for AKMA. (section 6.2 Deriving AKMA Application Key for a specific AF; “The AAnF sends Naanf_AKMA_ApplicationKey_Get response to the AF with KAF and the KAF expiration time.”)
Regarding claim 24, Ericsson teaches a method performed by mapping network function, NF, in a core network of the cellular communications system, the method comprising:
receiving a verification request from an Authentication and Key Management for Applications, AKMA, Anchor Function, AAnF, the verification request comprising an Application Function identity, AF ID; (section 6.2 Deriving AKMA Application Key for a specific AF; "the AF sends a Naanf_AKMA_ApplicationKey_Get request to AAnF with the A-KID to request the AKMA Application Key for the UE. The AF also includes its identity (AF Id) in the request.”)
determining whether a particular AF is authorized to use the AF ID; and (section 6.2 Deriving AKMA Application Key for a specific AF; "The AAnF shall authorize AF. The AAnF shall check whether the AAnF can provide the service to the AF based on the configured local policy or based on the authorization information or policy provided by the NRF using the AF Id.”)
sending a verification response to the AAnF, the verification response comprising information that indicates whether the particular AF is authorized to use the AF ID. (section 6.2 Deriving AKMA Application Key for a specific AF; "If [authorization] succeeds, the following procedures are executed. Otherwise, the AAnF shall reject the procedure.“) Here details are shown in Figure 6.2-1: KAF generation from KAKMA.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
Claim 3, 7, 11 and 25-26 are rejected under 35 U.S.C. 103 as being unpatentable over Ericsson (NPL "AKMA SBA Interface Clarifications", 2020, listed in IDS) in view of Rodrigo (US 20230396655 A1).
Regarding claim 3, Ericsson teaches all the features with respect to claim 1, as outlined above. But Ericsson does not teach wherein an associated certificate comprises information comprising: (a) a AF FQDN, (b) information that indicates a set of AF FQDNs, (c) an AF ID, (d) information that indicates a set of AF IDs, or (e) a combination of any two or more of (a)-(d). This aspect of the claim is identified as a difference.
However, Rodrigo in an analogous art explicitly teaches
wherein an associated certificate comprises information comprising: (a) a AF FQDN, (b) information that indicates a set of AF FQDNs, (c) an AF ID, (d) information that indicates a set of AF IDs, or (e) a combination of any two or more of (a)-(d). ([0100] the at least one first security token may comprise at least one first assertion (e.g. client credentials assertion) and/or at least one first access token. Alternatively or in addition, in some embodiments described herein, the at least one second security token may comprise at least one second assertion (e.g. client credentials assertion) and/or at least one second access token. A client credentials assertion can, for example, be a token signed by the first NF node 20. It enables the first NF node 20 to authenticate itself towards a receiving end point (e.g. the first SCP node 10 and/or the second NF node). In some embodiments, a client credentials assertion (CCA) can include an identifier that identifies the first NF node 20 and this identifier can be checked against a certificate by the first NF node 20.) Here reference Rodrigo discloses that certificate/client credentials assertion (CCA)/access token can include identification information. Reference Ericsson discloses that AF can be identified using AF_ID directly, or FQDN indirectly (section 6.2 Deriving AKMA Application Key for a specific AF; "AF_ID = FQDN of the AF II Ua* security protocol identifier.") Therefore, the combination discloses the limitation.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the “deriving AKMA application key for a specific AF” concept of Ericsson, and the “efficient authentication information exchange” approach of Rodrigo. One of ordinary skill in the art would have been motivated to provide improved techniques for handling service requests in a network efficiently (Rodrigo [0183]).
Regarding claims 7 and 11, the scope of the claims is similar to that of claim 3, respectively. Accordingly, the claims are rejected using a similar rationale.
Regarding claim 25, Ericsson teaches all the features with respect to claim 24, as outlined above. Ericsson in view of Rodrigo further teaches
wherein the verification request further comprises a NF Instance ID of the particular AF, and determining whether the particular AF is authorized to use the AF ID comprises determining whether the particular AF is authorized to use the AF ID based on the NF Instance ID of the particular AF and stored associations between NF Instance IDs and AF IDs or sets of AF IDs. ([Rodrigo 0013] the NRF node 60 initiates transmission of a response to the request for an access token towards the first SCP node 10. This response may be referred to herein as an “access token response”. If the authentication at block 206 of FIG. 2 is successful and the first NF node 20 is authorised (e.g. based on a policy stored at the NRF node 60), the response 208 to the request for the access token comprises the access token (as illustrated in FIG. 2 ). The NRF node 60 may issue the access token as described in 3GPP TS 33.501 v16.4.0. The NRF node 60 can use an identifier (e.g. instance identifier) of the first NF node 20 as the subject of the access token. On the other hand, if the authentication at block 206 of FIG. 2 is unsuccessful, the response may instead be indicative that the authentication is unsuccessful.)
Regarding claim 26, Ericsson teaches all the features with respect to claim 24, as outlined above. Ericsson in view of Rodrigo further teaches
wherein the verification request further comprises CCA unique information associated to the particular AF, and determining whether the particular AF is authorized to use the AF ID comprises determining whether the particular AF is authorized to use the AF ID based on the CCA unique information associated to the particular AF and stored associations between CCA unique information and AF IDs or sets of AF IDs. ([Rodrigo 0100] the at least one first security token may comprise at least one first assertion (e.g. client credentials assertion) and/or at least one first access token. Alternatively or in addition, in some embodiments described herein, the at least one second security token may comprise at least one second assertion (e.g. client credentials assertion) and/or at least one second access token. A client credentials assertion can, for example, be a token signed by the first NF node 20. It enables the first NF node 20 to authenticate itself towards a receiving end point (e.g. the first SCP node 10 and/or the second NF node). In some embodiments, a client credentials assertion (CCA) can include an identifier that identifies the first NF node 20 and this identifier can be checked against a certificate by the first NF node 20. Herein, a client credentials assertion may also be referred to as a client assertion.)
Allowable Subject Matter
Claim 4-6, 8-10, 12-14 and 16-22 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 12170898 B2, "Methods and devices for establishing secure communication for applications" by Yu.
US 20240073212 A1, "Communication method and apparatus" by Wu.
US 12382284 B2, "User equipment authentication and authorization procedure for edge data network" by Guo.
US 11968530 B2, “Network authentication for user equipment access to an edge data network" by Guo.
US 12323793 B2, “Edge enabler client identification authentication procedures" by Guo.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAN YANG whose telephone number is (408)918-7638. The examiner can normally be reached on Monday to Friday, 9:00-5:00.
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, Carl Colin can be reached on (571)272-3862. 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.
/HAN YANG/Primary Examiner, Art Unit 2493