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
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. Claim have priority date of provisional application, 11/05/2022.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Claim Rejections - 35 USC § 102 / 103
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.
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(s) 1-11, 29-38 and 40-46 are rejected under 35 U.S.C. 102(a)(2) as anticipated by or, in the alternative, under 35 U.S.C. 103 as obvious over US 20230105597 A1 Baskaran; Sheeba Backia Mary et al.
Basakaran solves the same technical problem as that of the instant application. Basakaran teaches “if a 5G registered user equipment (“UE”) moves between different access points (e.g., trusted network access point (“TNAP”), TNAP mobility) after its primary authentication with a 5G Network, a UE may be expected to perform re-authentication using an extensible authentication protocol (“EAP”) re-authentication protocol (“ERP”) with a trusted network gateway function (“TNGF”), if the ERP is supported by the UE and the network functions and/or entities (e.g., TNAP, TNGF, AMF and authentication server function (“AUSF”)). During re-authentication, a TNGF may need to provide a target TNAP with the security context derived from a root re-authentication key (“rRK”) (e.g., a key derived from security context established during primary authentication) to setup access security.” (Basakaran [0056]).
Regarding Claims 1, 30, 41, and 44
In the terms Claim 1, as analogous to claims 31, 41 and 44, Baskaran teaches An apparatus for wireless communication at a user equipment (UE) (Fig. 1 102 UE, Fig. 2 200 Remote unit 102; ¶37), comprising:
one or more memories; and one or more processors, coupled to the one or more memories (Fig. 2 202 204 ¶44), configured to:
perform a registration procedure with a mobility function of a 5G core network (Fig. 7, ¶60 “The UE connects to a TNAN and it also registers to 5GC over the TNAN by using an EAP-based procedure during a primary authentication. “);
derive a main key, associated with a trusted network gateway function (TNGF), based on the registration procedure (¶79-81 after final authentication . . . “ The UE 702 also derives the anchor key K.sub.SEAF and from that key it derives the K.sub.AMF followed by NAS security keys” where either K.sub.AFM or K.sub.SEAF teach main key)
determine a root key based on the main key (Basakaran Fig. 7, ¶60 “a TNGF key (“K.sub.TNGF”) is created in the UE and in the AMF from the K.sub.AMF after successful authentication”)
derive a first pairwise master key (PMK), associated with a trusted network, from the root key (Basakaran Fig. 7, ¶60 “The TNGF key may be transferred from the AMF to the TNGF (e.g., within an N2 initial context setup request) . . . The TNGF derives a TNAP key (“K.sub.TNAP”) which is provided to the TNAP to setup access security. The TNAP key may depend on a non-3GPP access technology (e.g., it is a pairwise master key in IEEE 802.11).”);
communicate with a first access point (AP) for the trusted network (¶73 “TNAP1 706” Fig. 7, ¶75 “In a first communication 718 transmitted between the UE 702 and the source-TNAP1 706, layer-2 (“L2”) connection setup is performed. The communications 700 include a successful primary authentication using an EAP method 719”); and
derive a second PMK, associated with a second AP ((¶73 “TNAP2 704” Fig. 7), from the first PMK (Baskaran ¶57 “more than one TNAP key (e.g., K.sub.TNAP or rMSK (when rMSK, derived from rRK either directly or indirectly, may be used as new K.sub.TNAP)) for different TNAPs may be derived from the same root re-authentication key (“rRK”) to support TNAP mobility for a UE among several TNAPs, thus a key may be used with other TNAPs.”).
Thus Baskaran teaches all the elements of the claim. With regards to “derive a second PMK, associated with a second AP from the first PMK.” Basakaran teaches deriving the second PMK from the root key, which slightly differs from the claimed step of deriving the second PMK from the first PMK. However, as Baskaran also teaches that the first PMK is derived from the root key, the claim is essentially re-arranging the parts of Baskaran, since deriving the second PMK from the root key could also be done in two steps (derive first PMK and then derive second PMK from the first PMK), based on all of the teachings and to achieve the essential purpose of Basakaran.
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the invention of Basakaran to “to support TNAP mobility for a UE among several TNAPs” ¶57) since it has been held that rearranging parts of an invention involved only routine skill in the art. In re Japikse, 86 USPQ 70 (CCPA 1950).
Regarding Claims 2 and 31
Basakaran teaches The apparatus of claim 1, wherein the one or more processors are further configured to:
determine to access the trusted network; determine to access the first AP (¶85 “a 4-way handshake may be executed which establishes a security context between a WLAN AP and the UE 702 that is used to protect unicast and multicast traffic over the air. All messages between the UE 702 and the TNAP may be encrypted and integrity protected from this step onwards..”); and
determine to access the second AP for the trusted network (Fig. 7 ¶87 “If the UE 702 moves from a current TNAP to a different TNAP and if the TNGF 708 remains the same, an ERP based re-authentication procedure 745 may be used.”).
Regarding Claims 3 and 32
Basakaran teaches The apparatus of claim 2, wherein, to determine to access the second AP, the one or more processors are configured to:
receive a broadcast from the second AP; and determine that the second AP is in a same trusted network as the first AP based on a mobility domain identity (MDID) indicated in the broadcast ((¶88-89 “The TNAP (e.g., TNGF 708) sends the EAP-Initiate and/or re-authentication start message to the UE 702 along with target TNAP ID. . . UE 702 sends a registration request in an EAP-Initiate and/or re-authentication request over the L2 connection to the target-TNAP2 704 with the ng-RKSI. . .”).
Regarding Claims 4 and 33
Basakaran teaches The apparatus of claim 1, wherein the main key is a KTNGF key (Basakaran Fig. 7, ¶60 “a TNGF key (“K.sub.TNGF”) is created in the UE and in the AMF from the K.sub.AMF after successful authentication”).
Regarding Claims 5, 34, 42 and 45
Basakaran teaches The apparatus of claim 1, wherein, to determine the root key, the one or more processors are configured to: apply a key derivation function (KDF) to the main key to determine the root key (Basakaran Fig. 7, ¶60 “a TNGF key (“K.sub.TNGF”) is created in the UE and in the AMF from the K.sub.AMF after successful authentication”).
Regarding Claims 6, 43, and 46
Basakaran teaches The apparatus of claim 1, wherein, to determine the root key, the one or more processors are configured to: derive the root key from the main key based on a usage type distinguisher (¶65 “ The rRK may be derived from either an EMSK or a DSRK. For the purpose of rRK derivation, derivation of a usage-specific root key (“USRK”) or a domain-specific USRK (“DSUSRK”) for re-authentication may be used.”).
Regarding Claims 7 and 35
Basakaran teaches The apparatus of claim 1, wherein the root key is a KFT key (Basakaran Fig. 7, ¶60 “a TNGF key (“K.sub.TNGF”) is created in the UE and in the AMF from the K.sub.AMF after successful authentication”).
Regarding Claims 8 and 36
Basakaran teaches The apparatus of claim 1, wherein the first PMK is a PMK-R0 (¶85 “ If IEEE 802.11 is used, the K.sub.TNAP is a pairwise master key (“PMK”)”).
Regarding Claims 9 and 37
Basakaran teaches The apparatus of claim 1, wherein the second PMK is a PMK-R1 (¶85 “ If IEEE 802.11 is used, the K.sub.TNAP is a pairwise master key (“PMK”)”).
Regarding Claims 10 and 38
Basakaran teaches The apparatus of claim 1, wherein the one or more processors are further configured to: transmit to, or receive from, the second AP using encryption based on the second PMK (¶85 “All messages between the UE 702 and the TNAP may be encrypted and integrity protected from this step onwards.”; ¶97 “..the EAP re-authentication procedure may be successful and the TNGF 708 may derive the K.sub.TNAP (specific to the target TNAP) and the re-authentication MSK (“rMSK”) (e.g., K.sub.TNAP key is used to establish a security context between the UE 702 and the target-TNAP2 704 to setup access security)”).
Regarding Claims 11 and 39
Basakaran teaches The apparatus of claim 1, wherein the one or more processors are further configured to:
transmit, to the second AP, an authentication request (Fig. 7 746 ¶88 “ an EAP re-authentication procedure may be initiated (e.g., via L2 connection setup). The UE 702 informs the target-TNAP2 704 that it supports ERP.”);
transmit, to the second AP, a reassociation request based on a response to the authentication request (¶88-89 “The TNAP (e.g., TNGF 708) sends the EAP-Initiate and/or re-authentication start message to the UE 702 along with target TNAP ID. . . UE 702 sends a registration request in an EAP-Initiate and/or re-authentication request over the L2 connection to the target-TNAP2 704 with the ng-RKSI. . .”); and
transmit to, or receive from, the second AP using encryption based on the second PMK (¶97 “..the EAP re-authentication procedure may be successful and the TNGF 708 may derive the K.sub.TNAP (specific to the target TNAP) and the re-authentication MSK (“rMSK”) (e.g., K.sub.TNAP key is used to establish a security context between the UE 702 and the target-TNAP2 704 to setup access security)”).
Claim(s) 12 and 39 are rejected under 35 U.S.C. 103 as obvious over US 20230105597 A1 Baskaran; Sheeba Backia Mary et al in view of US 20160112869 A1 Lee; Soo Bum et al.
Regarding Claims 12 and 39
Basakaran teaches The apparatus of claim 1, wherein the one or more processors are further configured to:
transmit, to the second AP, a reassociation request based on a response to the FT request ((¶88-89 “The TNAP (e.g., TNGF 708) sends the EAP-Initiate and/or re-authentication start message to the UE 702 along with target TNAP ID. . . UE 702 sends a registration request in an EAP-Initiate and/or re-authentication request over the L2 connection to the target-TNAP2 704 with the ng-RKSI. . .”); and
transmit to, or receive from, the second AP using encryption based on the second PMK (¶85 “All messages between the UE 702 and the TNAP may be encrypted and integrity protected from this step onwards.”; ¶97 “..the EAP re-authentication procedure may be successful and the TNGF 708 may derive the K.sub.TNAP (specific to the target TNAP) and the re-authentication MSK (“rMSK”) (e.g., K.sub.TNAP key is used to establish a security context between the UE 702 and the target-TNAP2 704 to setup access security)”). .
Basakaran does not teach transmit, to the first AP, a fast basic service set (BSS) transition (FT) request.
Lee teaches transmit, to the first AP, a fast basic service set (BSS) transition (FT) request (Lee ¶82 “[0082] In some aspects, authentication message exchange 715a is an EAP-RP exchange and authentication message exchange 715b is a fast BSS transition (FT) authentication. When the AP 104j receives the second authentication protocol reauthentication request from the STA 106, it may request a key from the local ER server 706a. In response to receiving the key request, the local ER server 706a may generate the second PMK RMK-R1-2”)).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the invention of Basakaran to include the teachings of Lee, in order for authentication within wireless communication systems. (Lee ¶3)
Pertinent Prior Art(s)
The prior art made of record though not relied upon in the current rejection is considered pertinent to applicant's disclosure:
US 20160112869 A1 Lee; Soo Bum et al.
Lee ¶70 “the authentication server 501 may create a master session key (MSK1), and provide the MSK1 to the WLC 506a. The WLC 506a may then derive a pairwise master key (PMK) based on the MSK1 and provide the PMK to the AP 104a (this key is shown as PMK-R1-1 in FIG. 5).”
Lee ¶72 “This authentication may not require the WLC 506a to exchange messages with the authentication server 501 when the STA 106 authenticates with the AP 104b. Instead, the WLC 506a derives a second PMK, shown as PMK-R1-2 in FIG. 5 based on the first master session key (MSK1) provided by the authentication server 501 when the STA 106 authenticated with AP 104a.”
US 20220150694 A1 Lehtovirta; Vesa et al.
Abstract: A method for key derivation for non-3GPP access. The method includes determining a particular non-3GPP access type, wherein the particular non-3GPP access type is one of N different particular non-3GPP access types (N>1), and each one of the N particular non-3GPP access types is associated with a unique access type distinguisher value. The method also includes generating (s604) a first access network key using a key derivation function and the unique access type distinguisher value with which the determined particular non-3GPP access type is associated, thereby generating a first access network key for the particular non-3GPP access type.
[0038] (1) A TNGF key (instead of an N3IWF key) is created in UE 102 and in AMF 106 after the successful authentication. The TNGF key is derived using the key derivation function of Annex A.9 in TS 33.501 with an input value which is specific to the Trusted access e.g. the “trusted non-3GPP access” value 0x03 as (instead of the more generic value “non-3GPP access” value 0x02). The TNGF key is transferred from the AMF to TNGF-CP in step 10a (within the N2 Initial Context Setup Request). From the TNGF key, TNGF-CP 151 derives a TNAP key, which depends on the non-3GPP access technology used. For example, in case of IEEE 802.11, the TNAP key is a Pairwise Master Key (PMK) and then the TNAP key is transferred from and then from TNGF-CP to TNAP in step 10b (within an AAA message). UE 102 derives the TNGF key and the TNAP key after the successful authentication in step 8.
US 20230231720 A1 Kunz; Andreas et al.
[0046] When a UE moves from a source TNAP to a target TNAP within the area of the same TNGF, it does not need to perform a full authentication. Instead, the UE is re-authenticated by the TNGF (ER Server) and a fresh rMSK key is derived by the TNGF and provided to the Target/New TNAP to establish security over the air between UE and the Target TNAP. In the 5G system supporting ERP, the UE performs the role of peer, the TNAP performs the role of ER authenticator, and the TNGF performs the role of ER Server (i.e., Local ER Server). Note that in the 5G system, the AUSF takes the role of the backend authentication server (i.e., EAP Server).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to UMAIR AHSAN whose telephone number is (571)272-1323. The examiner can normally be reached Monday - Friday 10-5 PM EST or by emailing UMAIR.AHSAN@USPTO.GOV.
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, Alison Slater can be reached at (571) 270-0375. 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.
/UMAIR AHSAN/Primary Examiner, Art Unit 2647
Prosecution Insights