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 .
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)(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, 5, and 7 – 10 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by 3GPP (“3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on authentication and key management for applications based on 3GPP credential in 5G (Release 16)," 3GPP TR 33.835 1.0.1, September 9th 2019, 92 pages.)
Regarding claim 1, 3GPP shows a method, comprising: receiving, by a unified data management entity (pg. 35, Fig. 6.4.2.1-1 showing “UDM/ARPF”), an authentication request carrying a user terminal identifier (pg. 35, steps 1 – 3 showing the UEAuthentication request containing “user identity”); determining, by the unified data management entity, that the authentication request is a generic (Section 1, pg. 10 and Section 6.13.1, pg. 47) bootstrapping architecture (GBA) authentication request (Section 6.4.2, pg. 34) based on a dedicated authentication request message name or type of the authentication request (pg. 35 steps 3-4, where the message contains UEAuthentication_Get); generating, by the unified data management entity, a first authentication vector (pg. 35, step 4, the message containing “5G HE AV= . . .”) of a user terminal represented by the user terminal identifier (pg. 3 step 1 showing the UE represented by its “user identity”) , wherein the first authentication vector is different from a second authentication vector of the user terminal, the first authentication vector is a GBA authentication vector (Sections 4.1 – 4.2, pg. 34), and the second authentication vector is an authentication vector (Figure 6.17.2.2.1 and pg. 67, Steps 1 – 2 which supports an authentication vectors with CK and IK, and an authentication vectors with those values replaced CK’ and IK’; see also Section 6.7.1 – 6.7.2, pg. 42, Section 6.11.2, pg. 46, supporting authentication with vectors containing CK and IK) and sending, by the unified data management entity, a GBA authentication response carrying the first authentication vector (pg. 35, steps 4-7).
Regarding claim 2, 3GPP shows the method according to claim 1, wherein the first authentication vector is an authentication vector with 5-tuple parameters (CK', IK', RAND, AUTN, XRES), wherein CK' is a cypher key, IK' is an integrity protection key, RAND is a random number, AUTN is an authentication token, and XRES is an expected response (pg. 67, steps 1 and 2); and the second authentication vector is an authentication vector with 5-tuple parameters (CK, IK, RAND, AUTN, XRES), wherein CK is a cypher key, IK is an integrity protection key, RAND is a random number, AUTN is an authentication token, and XRES is an expected response (pg. 67, steps 1 – 2, where step 1 notes the authentication vector initially generated by the UDM/ARPF contains CK and IK, and then generates CK’ and IK’ and to replace CK and IK and thus generates the above claimed “first authentication vector” from this “second authentication vector”), wherein the cipher key CK' is different from the cipher key CK, or the integrity protection key IK' is different from the integrity protection key IK (pg. 67 step 1 discussing the process for generated CK’ and IK’ and replacing CK and IK with these values; CK’ and IK’ are implicitly different from CK and IK given this discussion of their generation and subsequent use as replacement values). Regarding claim 5, 3GPP further shows wherein receiving, by the unified data management entity, the authentication request carrying the user terminal identifier comprises: receiving, by the unified data management entity from a bootstrapping server function entity, the authentication request carrying the user terminal identifier (pg. 3, see Figure 6.4.2.1-1, showing the AUSF performing the BSF entity operations, i.e., sending the UEAuthentication message to achieve the bootstrapping).
Regarding claim 7, 3GPP shows a method, comprising: sending, by a bootstrapping server function entity, an authentication request carrying a user terminal identifier pg. 3, see Figure 6.4.2.1-1, showing the AUSF performing the BSF entity operations, i.e., sending the UEAuthentication message to achieve the bootstrapping, said message containing “user identity”), wherein the authentication request is with a dedicated authentication request message name or type indicating (pg. 35 steps 3-4, where the message contains UEAuthentication_Get) that the authentication request is an authentication request for generic (Section 1, pg. 10 and Section 6.13.1, pg. 47) bootstrapping architecture (GBA) authentication (Section 6.4.2, pg. 34); and receiving, by the bootstrapping server function entity, a GBA authentication response (pg. 35, step 4) carrying a first authentication vector (see “AV= . . . ”) of a user terminal represented by the user terminal identifier (pg. 3, discussing the UE represented by its “user identity”), wherein the first authentication vector is different from a second authentication vector of the user terminal, the first authentication vector is a GBA authentication vector, and the second authentication vector is an authentication vector (Figure 6.17.2.2.1 and pg. 67, Steps 1 – 2 which supports an authentication vectors with CK and IK, and an authentication vectors with those values replaced CK’ and IK’; see also Section 6.7.1 – 6.7.2, pg. 42, Section 6.11.2, pg. 46, supporting authentication with vectors containing CK and IK).
Regarding claim 8, 3GPP further shows receiving, by the bootstrapping server function entity before sending the authentication request, a request carrying the user terminal identifier (pg. 35, steps 1 and 2).
Regarding claim 9, 3GPP further shows determining, by the bootstrapping server function entity before sending the authentication request, information about a unified data management entity based on the user terminal identifier (pgs. 35 and 37, where the UDM information gathering is implicit given the message is routed to the “UDM/ARPF” as show in the figures on said pages; the information that causes said routing is interpreted as the broadly claimed “information about . . . ”).
Regarding claim 10, 3GPP shows the method according to claim 7, wherein the first authentication vector is an authentication vector with 5-tuple parameters (CK', IK', RAND, AUTN, XRES), wherein CK' is a cypher key, IK' is an integrity protection key, RAND is a random number, AUTN is an authentication token, and XRES is an expected response (pg. 67, steps 1 and 2); and the second authentication vector is an authentication vector with 5-tuple parameters (CK, IK, RAND, AUTN, XRES), wherein CK is a cypher key, IK is an integrity protection key, RAND is a random number, AUTN is an authentication token, and XRES is an expected response (pg. 67, steps 1 – 2, where step 1 notes the authentication vector initially generated by the UDM/ARPF contains CK and IK, and then generates CK’ and IK’ and to replace CK and IK and thus generates the above claimed “first authentication vector” from this “second authentication vector”), wherein the cipher key CK' is different from the cipher key CK, or the integrity protection key IK' is different from the integrity protection key IK (pg. 67 step 1 discussing the process for generated CK’ and IK’ and replacing CK and IK with these values; CK’ and IK’ are implicitly different from CK and IK given this discussion of their generation and subsequent use as replacement values).
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 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.
Claims 11, 12, 15 and 17 - 20 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP in view of Torvinen (US-20200100101-A1).
Regarding claim 11, 3GPP shows receiving (e.g., by the “UDM/ARPF” shown in Fig. 6.4.2.1-1 on pg. 35), an authentication request carrying a user terminal identifier (pg. 35, steps 1 – 3 showing the UEAuthentication request containing “user identity”); determining that the authentication request is a generic (Section 1, pg. 10 and Section 6.13.1, pg. 47) bootstrapping architecture (GBA) authentication request (Section 6.4.2, pg. 34) based on a dedicated authentication request message name or type of the authentication request (pg. 35 steps 3-4, where the message contains UEAuthentication_Get); generating a first authentication vector (pg. 35, step 4, the message containing “5G HE AV= . . .”) of a user terminal represented by the user terminal identifier (pg. 3 step 1 showing the UE represented by its “user identity”) , wherein the first authentication vector is different from a second authentication vector of the user terminal, the first authentication vector is a GBA authentication vector (Sections 4.1 – 4.2, pg. 34), and the second authentication vector is an authentication vector (Figure 6.17.2.2.1 and pg. 67, Steps 1 – 2 which supports an authentication vectors with CK and IK, and an authentication vectors with those values replaced CK’ and IK’; see also Section 6.7.1 – 6.7.2, pg. 42, Section 6.11.2, pg. 46, supporting authentication with vectors containing CK and IK) and sending a GBA authentication response carrying the first authentication vector (pg. 35, steps 4-7). 3GPP does show where the above steps are performed by an apparatus such as the UDM shown on pg. 35, but does not discuss where it is comprising: at least one processor; and a memory coupled to the at least one processor and storing programming instructions for execution by the at least one processor to cause the apparatus to perform operations. Torvinen shows a UDM comprising at least one processor and a memory coupled to the at least one processor and storing programming instructions for execution by the at least one processor to cause the apparatus to perform operations ([57], Fig. 19). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the technical disclosure of 3GPP with the hardware disclosed by Torvinen in order to ensure a reliable implementation of the software functionality disclosed by 3GPP, software being understood to require a corresponding hardware implementation to execute the software functionality.
Regarding claim 12, 3GPP in view of Torvinen shows the apparatus according to claim 11, wherein the first authentication vector is an authentication vector with 5-tuple parameters (CK', IK', RAND, AUTN, XRES), wherein CK' is a cypher key, IK' is an integrity protection key, RAND is a random number, AUTN is an authentication token, and XRES is an expected response (3GPP, pg. 67, steps 1 and 2); and the second authentication vector is an authentication vector with 5-tuple parameters (CK, IK, RAND, AUTN, XRES), wherein CK is a cypher key, IK is an integrity protection key, RAND is a random number, AUTN is an authentication token, and XRES is an expected response (3GPP, pg. 67, steps 1 – 2, where step 1 notes the authentication vector initially generated by the UDM/ARPF contains CK and IK, and then generates CK’ and IK’ and to replace CK and IK and thus generates the above claimed “first authentication vector” from this “second authentication vector”), wherein the cipher key CK' is different from the cipher key CK, or the integrity protection key IK' is different from the integrity protection key IK (3GPP, pg. 67 step 1 discussing the process for generated CK’ and IK’ and replacing CK and IK with these values; CK’ and IK’ are implicitly different from CK and IK given this discussion of their generation and subsequent use as replacement values). Regarding claim 15, 3GPP in view of Torvinen further shows wherein receiving the authentication request carrying the user terminal identifier comprises: receiving, from a bootstrapping server function entity, the authentication request carrying the user terminal identifier (3GPP, pg. 3, see Figure 6.4.2.1-1, showing the AUSF performing the BSF entity operations, i.e., sending the UEAuthentication message to achieve the bootstrapping).
Regarding claim 17, 3GPP shows sending an authentication request carrying a user terminal identifier (pg. 3, see Figure 6.4.2.1-1, showing the AUSF performing the BSF entity operations, i.e., sending the UEAuthentication message to achieve the bootstrapping, said message containing “user identity”), wherein the authentication request is with a dedicated authentication request message name or type indicating (pg. 35 steps 3-4, where the message contains UEAuthentication_Get) that the authentication request is an authentication request for generic (Section 1, pg. 10 and Section 6.13.1, pg. 47) bootstrapping architecture (GBA) authentication (Section 6.4.2, pg. 34); and receiving a GBA authentication response (pg. 35, step 4) carrying a first authentication vector (see “AV= . . . ”) of a user terminal represented by the user terminal identifier (pg. 3, discussing the UE represented by its “user identity”), wherein the first authentication vector is different from a second authentication vector of the user terminal, the first authentication vector is a GBA authentication vector, and the second authentication vector is an authentication vector (Figure 6.17.2.2.1 and pg. 67, Steps 1 – 2 which supports an authentication vectors with CK and IK, and an authentication vectors with those values replaced CK’ and IK’; see also Section 6.7.1 – 6.7.2, pg. 42, Section 6.11.2, pg. 46, supporting authentication with vectors containing CK and IK).
3GPP does show where the above steps are performed by an apparatus such as the UDM shown on pg. 35, but does not discuss where it is comprising: at least one processor; and a memory coupled to the at least one processor and storing programming instructions for execution by the at least one processor to cause the apparatus to perform operations. Torvinen shows a UDM comprising at least one processor and a memory coupled to the at least one processor and storing programming instructions for execution by the at least one processor to cause the apparatus to perform operations ([57], Fig. 19). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the technical disclosure of 3GPP with the hardware disclosed by Torvinen in order to ensure a reliable implementation of the software functionality disclosed by 3GPP, software being understood to require a corresponding hardware implementation to execute the software functionality. Regarding claim 18, 3GPP in view of Torvinen further shows the programming instructions for execution by the at least one processor to cause the apparatus to perform operations further comprising: receiving a request carrying the user terminal identifier before the sending authentication request (3GPP, pg. 35, steps 1 and 2).
Regarding claim 19, 3GPP in view of Torvinen further shows the programming instructions for execution by the at least one processor to cause the apparatus to perform operations further comprising: determining information about a unified data management entity based on the user terminal identifier before the sending authentication request (3GPP, pgs. 35 and 37, where the UDM information gathering is implicit given the message is routed to the “UDM/ARPF” as show in the figures on said pages; the information that causes said routing is interpreted as the broadly claimed “information about . . . ”).
Regarding claim 20, 3GPP in view of Torvinen shows the apparatus according to claim 17, wherein the first authentication vector is an authentication vector with 5-tuple parameters (CK', IK', RAND, AUTN, XRES), wherein CK' is a cypher key, IK' is an integrity protection key, RAND is a random number, AUTN is an authentication token, and XRES is an expected response (3GPP, pg. 67, steps 1 and 2); and the second authentication vector is an authentication vector with 5-tuple parameters (CK, IK, RAND, AUTN, XRES), wherein CK is a cypher key, IK is an integrity protection key, RAND is a random number, AUTN is an authentication token, and XRES is an expected response (3GPP, pg. 67, steps 1 – 2, where step 1 notes the authentication vector initially generated by the UDM/ARPF contains CK and IK, and then generates CK’ and IK’ and to replace CK and IK and thus generates the above claimed “first authentication vector” from this “second authentication vector”), wherein the cipher key CK' is different from the cipher key CK, or the integrity protection key IK' is different from the integrity protection key IK (3GPP, pg. 67 step 1 discussing the process for generated CK’ and IK’ and replacing CK and IK with these values; CK’ and IK’ are implicitly different from CK and IK given this discussion of their generation and subsequent use as replacement values).
Subject Matter Allowable over Prior Art
Claims 3 and 13 are objected to, and would be allowable if rewritten in independent form, incorporating the details of their respective parent claims. Claims 6 and 16 are objected to by virtue of the dependence on claims 3 and 13. Claims 4 and 14 are objected to, and would be allowable if rewritten in independent form, incorporating the details of their respective parent claims.
Regarding claims 3 and 13, said claims recite further details regarding the creation of the CK’, IK’, and ATUN parameters, discussed in claim 2, along with related derivation functions. As the 3GPP NPL shows, there are anticipated prior art mechanisms for performing authentication in the claimed 3GPP environment. However, the particular functions and values claimed in claims 3 and 13 are lacking in the prior art.
Regarding claims 4 and 14, said claims recite further details regarding the authentication vectors of claims 1 and 11. While authentication vectors with, e.g., CK, IK, RAND and ATUN are anticipated by the prior art (as discussed in the rejections above), the other details recited in claim 4 and 14 are lacking, particularly the use of the 4-tuple vector utilizing the Kgba parameter.
As noted in the examination of parent application 17/706,977, additional prior art relevant to Applicant’s disclosure includes:
Akman (Akman, Gizem, Valtteri Niemi, and Ville Junnila. "Providing Identity Privacy in 5G Networks by Using Pseudonyms." (Year: 2018)), providing further discussion of both the 4G and 5G authentication processes (pg. 34), and disclosing the similarity of 4G and 5G authentication procedures (e.g., pg. 25, showing an authentication request with the RAND and ATUN parameters, pg. 34, further discussing 4G and 5G key exchange along with a UE initiating an authentication process analogous to the presently claimed process, and pg. 37, showing an authentication vector AV with analogous parameters to those discussed in claim 2).
Basin (Basin, David, et al. "A formal analysis of 5G authentication." Proceedings of the 2018 ACM SIGSAC conference on computer and communications security. (Year: 2018)), also discussing 5G AKA process, along with the motivation for the changes from the, e.g., 4G process to the 5G process (i.e., enhanced security; pg. 1383, right column).
Khan (Khan, Haibat, and Keith M. Martin. "On the Efficacy of New Privacy Attacks against 5G AKA." ICETE (2). (Year: 2019)), providing background discussion of the 5G key exchange process (where the present application claims an evolution/advancement of the 5G AKA process discussed therein; see Khan, pg. 432 – 434). 5G’s support for multiple authentication processes is also discussed (pg. 1385 - 1386, Section 2 and 2.2).
Grech (US-20140051394-A1), discussing a traditional 5G authentication exchange ([42]) along with support for re-authentication/synchronization, a process which creates an additional, different authentication vector ([19,23,36-41]).
Furthermore, Ebrahimpour (Ebrahimpour, Ghader, Siavash Khorsandi, and Ali Piroozi. "Introducing the GBA Covert Channel in IP Multimedia Subsystem (IMS)." International Symposium on Computer Networks and Distributed Systems. Cham: Springer International Publishing. (Year: 2013)) is also highly relevant to the bootstrapping functionality presently claimed.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - 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, Glenton B Burgess can be reached at (571) 272 - 3949. 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.
JOHN MACILWINEN
Primary Examiner
Art Unit 2442
/JOHN M MACILWINEN/Primary Examiner, Art Unit 2454