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 .
Response to Arguments
Applicant's arguments filed 6/25/2026 have been fully considered, but cannot be held as persuasive. On pages 10 – 11, Applicant argues that particular items in the cited 3GPP TR 33.845 NPL document are not a “direct equivalent”, and that “AKMA and GBA” are “different architectures with different entities and procedures”. Applicant’s argument has been considered, but cannot be held as persuasive. As an initial matter, the Examiner notes that the section referenced by Applicant to support their assertion is not relied upon in the pending rejections. Items in prior art being “direct equivalent” to claim items cannot be held as persuasive when the differences relied upon are not positively recited or otherwise required as the claims. Additionally, the standard to support a rejection under the applicable statues requires, e.g., teaching or suggesting the relevant claim language (rather than direct equivalency). Applicant should to incorporate details into their pending claims that positively recite the argued differences (such as claim language that recites or requires some of the “different architectures with different entities and procedures”) in order for this argument to be persuasive.
Finally, Applicant’s argument that the “BSF and HSS in the 5GC” cannot be held as persuasive as the previously presented rejection of, e.g., claim 5, and the present rejection of, e.g., claim 1 do not assert or rely on a “direct equivalent of the BSF and HSS in the 5GC”. For example, the prior rejection of claim 5 and the present rejection of claim 1 do not make any assertion regarding such an “equivalence”. As noted in the prior rejection of claim 5, the AUSF performs BSF entity operations, and thus effectively operates as a “bootstrapping server function” (BSF) as it is performing a “bootstrapping server function” via sending the claimed authentication request. The functionality is recited broadly, and a device performing the recited “bootstrapping function” is considered within the broadest reasonable interpretation of a “bootstrapping function entity”. Such an interpretation does not rely on an AUSF being a “direct equivalent” to some other device. Applicant’s arguments rely on a combination of unclaimed subject matter (features relating to “different architectures with different entities and procedures”) and reading in particular definitions into claims (what can correspond to a BSF as well as what the broadest reasonable interpretation can be for a device performing bootstrapping functionality) when those definitions are not recited or otherwise required by the claims.
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, 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”), from a bootstrapping server function entity (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) 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 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), from a bootstrapping server function entity (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) 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 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),
wherein the apparatus is a bootstrapping server function entity (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).
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 sending the 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 sending the 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.
Conclusion
Additional prior art relevant to Applicant’s disclosure includes:
You (US-11751051-B2), particularly Fig. 9 and col. 16 line 45 – col. 17 line 43.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
