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 Office Action is in response to the U.S. patent application 19042598 filed on January 31, 2025.
Original claims 1-21 remain pending and have been examined in this application.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on April 2, 2025, September 23, 2025, April 22, 2026, and August 17, 2026, comply with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 3, 4 and 10 are objected to because of the following informalities:
Claim 3, line 1, change “password is” to “password” (emphasis added).
Claim 4, line 1, a claim cannot depend upon itself. For the purpose of applying art, the Examiner assumes that claim 4 is dependent on claim 1.
Claim 4, line 1, change “authenticate” to “authenticated”.
Claim 10, line 1, change “io decrypted” to “decrypted”.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-7 and 10-21 are rejected under 35 USC 101 as being directed to an abstract idea without being integrated into a practical application or being significantly more.
Regarding claims 1, 20 and 21, said claims are directed to an abstract idea as reciting the limitations “validat[ing] the endpoint using the PSK and the session authentication cookie, wherein the validation of the endpoint is based at least in part on a determination that the endpoint has previously authenticated with credentials.” Broadly interpreted, the aforementioned steps are directed to mental processes as said steps could be performed in the human mind. Therefore, the claims recite an abstract idea.
Said abstract idea and/or judicial exception is not integrated into a practical application as the claim does not recite any other active steps that could be considered that the abstract idea is being integrated into a practical application. It’s noted that the claims recite the operations “obtain[ing] an authentication request from an endpoint …” However, said steps are not sufficient to consider that the abstract idea is being interpreted into a practical application. Said operations are recited at a high level of generality in data gathering, which are a form of insignificant extra-solution activity. It’s also noted that the claims recite additional limitation/elements (i.e., processors, memory, etc.,). However, said additional elements are recited at a high-level of generality (i.e., as a generic computing device performing a generic computer functions) such that it amounts no more than mere instructions to apply the exception or abstract idea using generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The claims do not include additional elements/limitations/embodiments that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as an ordered combination do not amount to significantly more than the abstract idea. As mentioned above, although the claims recite additional elements, said elements taken individually or as a combination, do not result in the claim amounting to significantly more than the abstract idea because the additional elements perform generic computer content distributing functions routinely used in information technology field. As discussed above, the additional elements recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception using a generic computer component. Therefore, the claim is directed to non-statutory subject matter.
Regarding dependent claims 2-7 and 10-19, such claims are also rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter for the same reasons addressed above as the claims recite an abstract idea and the claims do not positively recite any other operations that could be considered as the abstract idea is being integrated into a practical application or significantly more. It’s noted that claim 6 recites “assign[ing] the session authentication cookie to the endpoint …;” Claim 7 recites the limitations: “decrypting the authentication request …”, etc., authentication cookie…;” Claim 16 recites “provid[ing] the session authentication cookie to the endpoint …;” Said steps are either directed to mental processes and/or in a form of insignificant extra-solution activities. Therefore, claims 2-7 and 10-19 are also rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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.
This application 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.
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.
(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-13, 20 and 21are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Rajadurai (“Rajadurai”; CN112087754A).
Per claim 1: Rajadurai discloses a system, comprising:
one or more processors (Rajadurai page 16, see paragraph beginning as “A processor (130) is configured to execute instructions stored in a memory (120).”) configured to:
obtain an authentication request from an endpoint (Rajadurai page 18, within para. beginning as “At step S602 of stage 3, the IAB relay device”, see “DU (150) sends an IKE-AUTH request including an AUTH value (i.e., IKEv2 value) to the CU (210)”), wherein: (i) the authentication request is encrypted using a pre-shared key (PSK) (Rajadurai page 16, within paraph beginning as “In one embodiment, the IAB donor device (200)”, see “The IAB donor device (200) uses KIAB as a shared secret to perform an IKEv2 process between the IAB donor device (200) and the IAB relay device (100). The KIAB and IPsec security association (SA) encryption key is used for establishing IPsec SA between the IAB donor device (200) and the IAB relay device (100).”), and (ii) a payload of the authentication request includes a session authentication cookie (Rajadurai page 12, within paraph beginning as “In one embodiment, the network forcibly uses dynamic PSK”, see “the IAB relay device indicates that it uses dynamic PSK to generate AUTH value in the provider ID payload. … in the IKE_AUTH request message, the IAB node can set the ID type as ID-KEY-ID, and the value is set as reserved value”; Rajadurai page 14, within paragraph beginning as “The authentication controller”, see “In the present disclosure, the term "IKE value", "IKEv2 value", "IKEv2 AUTH value" and "AUTH value" meaning the same and can be used interchangeably.”; [NOTE: Each of these terms is being interpreted as representing Applicant’s claimed “session authentication cookie”]);validate the endpoint using the PSK and the session authentication cookie, wherein the validation of the endpoint is based at least in part on a determination that the endpoint has previously authenticated with credentials (Rajadurai page 7, within paraph beginning as “Another object of the embodiments herein is to establish the F1”, see “object of the embodiments herein is to establish the F1 interface security with the IAB donor device by skipping the authentication process using the pre-configured security credentials”; Rajadurai page 14, see paragraph “IAB donor device (200) through sending the second request to the IAB relay device (100) to establish the F1 interface security of the IAB relay device (100), wherein the second request comprises for IPsec security association (Security Association, SA) established AUTH value and other parameters.”); and
a memory coupled to the one or more processors and configured to provide the one or more processors with instructions (Rajadurai page 16, see paragraph beginning as “A processor (130) is configured to execute instructions stored in a memory (120).”).
Per claim 2: Rajadurai disclosed the system of claim 1. Rajadurai further disclosed an arrangement wherein the authentication request is a request for authentication using Internet Key Exchange version 2 (IKEv2) protocol (Rajadurai page 18, within para. beginning as “At step S602 of stage 3, the IAB relay device”, see “DU (150) sends an IKE-AUTH request including an AUTH value (i.e., IKEv2 value) to the CU (210)”; Rajadurai page 11, within para. beginning as “The method includes generating, by the IAB relay device”, see “using PSK to generate internet key exchange (IKE) version 2 AUTH value, for performing mutual authentication”; Rajadurai page 17, within the para. beginning as “At step S504”, see ” the DU (150) generates an IKEv2 AUTH payload using PSK (obtained at step S506) specified in the Internet Key Exchange Protocol version 2 (IKEv2) IETF RFC”).
Per claim 3: Rajadurai disclosed the system of claim 1. Rajadurai further disclosed an arrangement wherein the session authentication cookie is a one-time password is (OTP) (Rajadurai page 11, within the paragraph beginning as “The embodiment of the invention claims a method for authentication”, see “For each deployment or restart of the IAB node, the key will be new. …Each IKEv2 authentication is derived from an independent unique PSK”).
Per claim 4: Rajadurai disclosed the system of claim 4. Rajadurai further disclosed an arrangement wherein gateway assigns the session authentication cookie to the endpoint after the endpoint has authenticate using login credentials (Rajadurai page 17, within paragraph starting with “FIG. 4 is a flowchart S400…”, see “FIG. 4 is a flowchart S400 illustrating a method for generating and using the dynamic PSK for authentication at the IAB relay device (100) … In step S402, the method includes generating a PSK based on the layer security key. In one embodiment, the method allows a PSK generator (112) to generate PSK based on a layer security key. In step S403, the method includes generating IKE values using PSK. In one embodiment, the method allows the IKE value generator (113) to use PSK (as a shared secret) to generate the IKE value.”).
Per claim 5: Rajadurai disclosed the system of claim 4. Rajadurai further disclosed an arrangement wherein the session authentication cookie is a unique OTP associated with a particular session between the endpoint and a gateway (Rajadurai page 16, within the paragraph beginning as “In one embodiment, the IAB donor device (200) and the IAB relay device (100”, see “As long as the IAB relay device (100) is connected to the IAB donor device (200), or until the IAB relay device (100) is re-authenticated, KIAB is kept effective”; Rajadurai page 17, within paragraph starting with “FIG. 4 is a flowchart S400…”, see “FIG. 4 is a flowchart S400 illustrating a method for generating and using the dynamic PSK for authentication at the IAB relay device (100) … In step S402, the method includes generating a PSK based on the layer security key. In one embodiment, the method allows a PSK generator (112) to generate PSK based on a layer security key. In step S403, the method includes generating IKE values using PSK. In one embodiment, the method allows the IKE value generator (113) to use PSK (as a shared secret) to generate the IKE value.”); Rajadurai page 11, within the paragraph beginning as “The embodiment of the invention claims a method for authentication, the method by integrated access and backhaul (IAB) relay device”, see “Each IKEv2 authentication is derived from an independent unique PSK”; Rajadurai page 12, within the paragraph beginning with “Traditionally…”, see “The NAS/AS layer security key is used for deriving the PSK, wherein the PSK is further used for directly calculating the AUTH value (i.e., IKEv2 value).”; [NOTE: the above is interpreted as the PSK remains viable until the end of a session (i.e., relay/donor discommection occurs), and when a new PSK is generated, a new IKE value is generated using the new PSK, …accordingly, each IKE value remains viable throughout a session.).
Per claim 6: Rajadurai disclosed the system of claim 5. Rajadurai further disclosed an arrangement wherein the gateway comprises one or more servers (Rajadurai page 5, within the paragraph beginning as “Internet is a human-centric connection network…”, see “server”; Rajadurai FIG. 1A, see “AMF/UPF”).
Per claim 7: Rajadurai disclosed the system of claim 1. Rajadurai further disclosed an arrangement wherein the PSK is used to decrypt the authentication request (Rajadurai page 16, within paraph beginning as “In one embodiment, the IAB donor device (200)”, see “The IAB donor device (200) uses KIAB as a shared secret to perform an IKEv2 process between the IAB donor device (200) and the IAB relay device (100). The KIAB and IPsec security association (SA) encryption key is used for establishing IPsec SA between the IAB donor device (200) and the IAB relay device (100).”; Rajadurai page 14, within the paragraph beginning as “The authentication controller (110) is configured…”, see “In the present disclosure, the term " PSK ", " pre-shared key " and " KIAB " can be used interchangeably.”).
Per claim 8: Rajadurai disclosed the system of claim 1. Rajadurai further disclosed an arrangement wherein validating the endpoint using the PSK and the session authentication cookie comprises: decrypting the authentication request to obtain a decrypted authentication package, wherein the authentication request is decrypted based at least in part on the PSK; obtaining the session authentication cookie from the decrypted authentication package; and authenticating the session authentication cookie (Rajadurai page 16, within paraph beginning as “In one embodiment, the IAB donor device (200)”, see “The IAB donor device (200) uses KIAB as a shared secret to perform an IKEv2 process between the IAB donor device (200) and the IAB relay device (100). The KIAB and IPsec security association (SA) encryption key is used for establishing IPsec SA between the IAB donor device (200) and the IAB relay device (100).”; Rajadurai page 14, within the paragraph beginning as “The authentication controller (110) is configured…”, see “In the present disclosure, the term " PSK ", " pre-shared key " and " KIAB " can be used interchangeably.”; Rajadurai page 12, within the paragraph beginning with “In one embodiment, the network forcibly…”, see “the IAB relay device indicates that it uses dynamic PSK to generate AUTH value in the provider ID payload.”; Rajadurai page 18, within the paragraph beginning as “At step S504…”, “the DU (150) generates an IKEv2 AUTH payload using PSK (obtained at step S506) specified in the Internet Key Exchange Protocol version 2 (IKEv2) IETF RFC,”; Rajadurai page 19, within the paragraph beginning as “At step S602…”, see “In step S605, the DU (150) sends an IKE-AUTH request including an AUTH value (i.e., IKEv2 value) to the CU (210). In step S607, in response to receiving the request, CU (210) uses the AS security key (e.g., KgNB) to derive KIAB. In step S608, CU (210) uses the KIAB corresponding to the UE as MSK/PSK/ shared secret to calculate IKEV2 value, and verifies the AUTH value received from the IAB relay device (100).”).
Per claim 9: Rajadurai disclosed the system of claim 1. Rajadurai further disclosed an arrangement wherein the authenticating the session authentication cookie comprises:
decrypting the authentication request to obtain a decrypted authentication package, wherein the authentication request is decrypted based at least in part on the PSK; and obtaining the session authentication cookie from the decrypted authentication package; and authenticating the session authentication cookie obtained from the decrypted authentication package (Rajadurai page 16, within paraph beginning as “In one embodiment, the IAB donor device (200)”, see “The IAB donor device (200) uses KIAB as a shared secret to perform an IKEv2 process between the IAB donor device (200) and the IAB relay device (100). The KIAB and IPsec security association (SA) encryption key is used for establishing IPsec SA between the IAB donor device (200) and the IAB relay device (100).”; Rajadurai page 14, within the paragraph beginning as “The authentication controller (110) is configured…”, see “In the present disclosure, the term " PSK ", " pre-shared key " and " KIAB " can be used interchangeably.”; Rajadurai page 12, within the paragraph beginning with “In one embodiment, the network forcibly…”, see “the IAB relay device indicates that it uses dynamic PSK to generate AUTH value in the provider ID payload.”; Rajadurai page 18, within the paragraph beginning as “At step S504…”, “the DU (150) generates an IKEv2 AUTH payload using PSK (obtained at step S506) specified in the Internet Key Exchange Protocol version 2 (IKEv2) IETF RFC,”; Rajadurai page 19, within the paragraph beginning as “At step S602…”, see “In step S605, the DU (150) sends an IKE-AUTH request including an AUTH value (i.e., IKEv2 value) to the CU (210). In step S607, in response to receiving the request, CU (210) uses the AS security key (e.g., KgNB) to derive KIAB. In step S608, CU (210) uses the KIAB corresponding to the UE as MSK/PSK/ shared secret to calculate IKEV2 value, and verifies the AUTH value received from the IAB relay device (100).”).
Per claim 10: Rajadurai disclosed the system of claim 9. Rajadurai further disclosed an arrangement wherein the session authentication cookie obtained from the io decrypted authentication package is authenticated against a gateway-side copy of a session authentication cookie assigned to the endpoint for a particular session (Rajadurai page 19, within the paragraph beginning as “At step S602…”, see “In step S605, the DU (150) uses the AUTH value generation mechanism specified in the IKEv2 IETF RFC, and uses the KIAB as the MSK/PSK/ shared secret to calculate the IKEV2 value. In step S605, the DU (150) sends an IKE-AUTH request including an AUTH value (i.e., IKEv2 value) to the CU (210). In step S607, in response to receiving the request, CU (210) uses the AS security key (e.g., KgNB) to derive KIAB. In step S608, CU (210) uses the KIAB corresponding to the UE as MSK/PSK/ shared secret to calculate IKEV2 value, and verifies the AUTH value received from the IAB relay device (100).”).
Per claim 11: Rajadurai disclosed the system of claim 1. Rajadurai further disclosed an arrangement wherein the credentials comprise a user identifier and passcode (Rajadurai page 14, within the paragraph beginning with “In another embodiment, the DU function…”, see “IAB relay device (100) identifier”; Rajadurai page 11, within the paragraph beginning with “The embodiment of the invention claims a method for authentication…”, see “each installation will have an independent key generated by a password”).
Per claim 12: Rajadurai disclosed the system of claim 1. Rajadurai further disclosed an arrangement wherein the session authentication cookie is correlated to a user for a particular session between the endpoint and a gateway (Rajadurai page 16, within the paragraph beginning as “In one embodiment, the IAB donor device (200) and the IAB relay device (100”, see “As long as the IAB relay device (100) is connected to the IAB donor device (200), or until the IAB relay device (100) is re-authenticated, KIAB is kept effective”; Rajadurai page 17, within paragraph starting with “FIG. 4 is a flowchart S400…”, see “FIG. 4 is a flowchart S400 illustrating a method for generating and using the dynamic PSK for authentication at the IAB relay device (100) … In step S402, the method includes generating a PSK based on the layer security key. In one embodiment, the method allows a PSK generator (112) to generate PSK based on a layer security key. In step S403, the method includes generating IKE values using PSK. In one embodiment, the method allows the IKE value generator (113) to use PSK (as a shared secret) to generate the IKE value.”); Rajadurai page 11, within the paragraph beginning as “The embodiment of the invention claims a method for authentication, the method by integrated access and backhaul (IAB) relay device”, see “Each IKEv2 authentication is derived from an independent unique PSK”; Rajadurai page 12, within the paragraph beginning with “Traditionally…”, see “The NAS/AS layer security key is used for deriving the PSK, wherein the PSK is further used for directly calculating the AUTH value (i.e., IKEv2 value).”; [NOTE: the above is interpreted as the PSK remains viable until the end of a session (i.e., relay/donor disconnection occurs), and when a new PSK is generated, a new IKE value is then generated using the new PSK, …accordingly, each IKE value remains viable throughout a session.).
Per claim 13: Rajadurai disclosed the system of claim 1. Rajadurai further disclosed an arrangement wherein PSK is generated after completion of a gateway authentication session or login (Rajadurai page 18, within the paragraph beginning as “Similarly, in step S508…”, see “performing authentication with the core network through the IAB donor device (200), establishing an AS security context in step S505, and performing other subsequent steps. At step S506, the MT (140) and CU (210) derive the PSK (i.e., KIAB) using the KgNB generated in step S505”).
Per claim 20: Rajadurai disclosed a method, comprising:
obtaining an authentication request from an endpoint (Rajadurai page 18, within para. beginning as “At step S602 of stage 3, the IAB relay device”, see “DU (150) sends an IKE-AUTH request including an AUTH value (i.e., IKEv2 value) to the CU (210)”), wherein: (i) the authentication request is encrypted using a pre-shared key (PSK) (Rajadurai page 16, within paraph beginning as “In one embodiment, the IAB donor device (200)”, see “The IAB donor device (200) uses KIAB as a shared secret to perform an IKEv2 process between the IAB donor device (200) and the IAB relay device (100). The KIAB and IPsec security association (SA) encryption key is used for establishing IPsec SA between the IAB donor device (200) and the IAB relay device (100).”), and (ii) a payload of the authentication request includes a session authentication cookie (Rajadurai page 12, within paraph beginning as “In one embodiment, the network forcibly uses dynamic PSK”, see “the IAB relay device indicates that it uses dynamic PSK to generate AUTH value in the provider ID payload. … in the IKE_AUTH request message, the IAB node can set the ID type as ID-KEY-ID, and the value is set as reserved value”; Rajadurai page 14, within paragraph beginning as “The authentication controller”, see “In the present disclosure, the term "IKE value", "IKEv2 value", "IKEv2 AUTH value" and "AUTH value" meaning the same and can be used interchangeably.”; [NOTE: Each of these terms is being interpreted as representing Applicant’s claimed “session authentication cookie”]); and
validating the endpoint using the PSK and the session authentication cookie, wherein the io validation of the endpoint is based at least in part on a determination that the endpoint has previously authenticated with credentials (Rajadurai page 7, within paraph beginning as “Another object of the embodiments herein is to establish the F1”, see “object of the embodiments herein is to establish the F1 interface security with the IAB donor device by skipping the authentication process using the pre-configured security credentials”; Rajadurai page 14, see paragraph “IAB donor device (200) through sending the second request to the IAB relay device (100) to establish the F1 interface security of the IAB relay device (100), wherein the second request comprises for IPsec security association (Security Association, SA) established AUTH value and other parameters.”).
Per claim 21: Rajadurai disclosed a computer program product embodied in a non-transitory computer readable medium and comprising computer instructions for:
obtaining an authentication request from an endpoint (Rajadurai page 18, within para. beginning as “At step S602 of stage 3, the IAB relay device”, see “DU (150) sends an IKE-AUTH request including an AUTH value (i.e., IKEv2 value) to the CU (210)”), wherein: (i) the authentication is request is encrypted using a pre-shared key (PSK) (Rajadurai page 16, within paraph beginning as “In one embodiment, the IAB donor device (200)”, see “The IAB donor device (200) uses KIAB as a shared secret to perform an IKEv2 process between the IAB donor device (200) and the IAB relay device (100). The KIAB and IPsec security association (SA) encryption key is used for establishing IPsec SA between the IAB donor device (200) and the IAB relay device (100).”), and (ii) a payload of the authentication request includes a session authentication cookie (Rajadurai page 12, within paraph beginning as “In one embodiment, the network forcibly uses dynamic PSK”, see “the IAB relay device indicates that it uses dynamic PSK to generate AUTH value in the provider ID payload. … in the IKE_AUTH request message, the IAB node can set the ID type as ID-KEY-ID, and the value is set as reserved value”; Rajadurai page 14, within paragraph beginning as “The authentication controller”, see “In the present disclosure, the term "IKE value", "IKEv2 value", "IKEv2 AUTH value" and "AUTH value" meaning the same and can be used interchangeably.”; [NOTE: Each of these terms is being interpreted as representing Applicant’s claimed “session authentication cookie”]); and
validating the endpoint using the PSK and the session authentication cookie, wherein the validation of the endpoint is based at least in part on a determination that the endpoint has previously authenticated with credentials (Rajadurai page 7, within paraph beginning as “Another object of the embodiments herein is to establish the F1”, see “object of the embodiments herein is to establish the F1 interface security with the IAB donor device by skipping the authentication process using the pre-configured security credentials”; Rajadurai page 14, see paragraph “IAB donor device (200) through sending the second request to the IAB relay device (100) to establish the F1 interface security of the IAB relay device (100), wherein the second request comprises for IPsec security association (Security Association, SA) established AUTH value and other parameters.”).
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 of this title, 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 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Rajadurai (“Rajadurai”; CN112087754A) in view of Rohini et al. (“Rohini”; CN116762382A).
Per claim 14: Rajadurai disclosed the system of claim 1. Rajadurai did not explicitly disclose an arrangement wherein the PSK is generated in response to a gateway receiving a getconfig request from the endpoint.
However, in an analogous art, Rohini further disclosed an arrangement wherein the PSK is generated in response to a gateway receiving a getconfig request from the endpoint (Rohini page 14, within the paragraphs beginning as “At 3 …” and “At 7 …”, see “At 3, the UE (500) initiates an initial service provisioning procedure with the SEAL server. In this step, the UE (500) sends a 5G-GUTI or a routing identifier. At 4, the SEAL server sends a key request to the designated AUSF. At 5, the designated AUSF derives the MSGin5G service key (KMSG) from the KAUSF. or, EMSK is KAUSF, MSK is KMSG. At 6, the AUSF sends back the derived KMSG in the key response. At 7, the SEAL server derives the pre-shared key KMSG-PSK from the KMSG and sends an initial service provisioning response to the 5GMSGS client at 8. After receiving the initial service provision response, the 5GMSGS client derives the KMSG-PSK at 9.”; [NOTE: Rohini’s “provisioning procedure” may be interpreted as the claimed “getconfig request” in that it effectively requests, and obtains via a response, the pre-shared key KMSG-PSK configuration.]).
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 modify Rajadurai to include, as taught by Rohini, an arrangement wherein the PSK is generated in response to a gateway receiving a getconfig request from the endpoint. Motivation for modifying would have been to utilize initiating configuration requests to automatically trigger PSK generation, in order to increase a user-friendliness, attractiveness and broadened adoption of the Rajadurai/Rohini combination within the security field.
Per claim 15: The Rajadurai/Rohini combination made obvious the system of claim 14. Rajadurai did not explicitly disclose an arrangement wherein the gateway provides the PSK to the endpoint via a getconfig response sent by the gateway to the endpoint in response to the getconfig request.
However, Rohini further disclosed an arrangement wherein the gateway provides the PSK to the endpoint via a getconfig response sent by the gateway to the endpoint in response to the getconfig request (Rohini page 14, within the paragraphs beginning as “At 3 …” and “At 7 …”, see “At 3, the UE (500) initiates an initial service provisioning procedure with the SEAL server. In this step, the UE (500) sends a 5G-GUTI or a routing identifier. At 4, the SEAL server sends a key request to the designated AUSF. At 5, the designated AUSF derives the MSGin5G service key (KMSG) from the KAUSF. or, EMSK is KAUSF, MSK is KMSG. At 6, the AUSF sends back the derived KMSG in the key response. At 7, the SEAL server derives the pre-shared key KMSG-PSK from the KMSG and sends an initial service provisioning response to the 5GMSGS client at 8. After receiving the initial service provision response, the 5GMSGS client derives the KMSG-PSK at 9.”; [NOTE: Rohini’s “provisioning procedure” may be interpreted as the claimed “getconfig request” in that it effectively requests, and obtains via a response, the pre-shared key KMSG-PSK configuration.]).
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 modify Rajadurai to include, as taught by Rohini, an arrangement wherein the gateway provides the PSK to the endpoint via a getconfig response sent by the gateway to the endpoint in response to the getconfig request. Motivation for modifying would have been to utilize initiating configuration requests to automatically trigger PSK generation and a returned-response, in order to increase a user-friendliness, attractiveness and broadened adoption of the Rajadurai/Rohini combination within the security field.
Claims 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Rajadurai (“Rajadurai”; CN112087754A) in view of Rajadurai et al. (“Rajadurai’696”; US20220150696A1).
Per claim 16: Rajadurai disclosed the system of claim 1. Rajadurai did not explicitly disclose an arrangement wherein a gateway provides the session authentication cookie to the endpoint via a secure connection.
However, in an analogous art, Rajadurai’696 further disclosed an arrangement wherein a gateway provides the session authentication cookie to the endpoint via a secure connection (Rajadurai’696 para. [0149], “Before sending the access token to the EES (334), the UE (310) and the EES (334) establish a secure TLS connection using a EES server certificate. It is required to protect and to provide the access token to an authentic the EES (334).”; [NOTE: Rajadurai’696’s “access token” is being interpreted as the claimed “cookie”]).
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 modify Rajadurai to include, as taught by Rajadurai’696, an arrangement wherein a gateway provides the session authentication cookie to the endpoint via a secure connection. Motivation for modifying would have been to utilize a secure connection to transfer the session authentication cookie, in order to increase a security, user-friendliness, attractiveness and broadened adoption of the Rajadurai/Rajadurai’696 combination within the security field.
Per claim 17: Rajadurai disclosed the system of claim 1. Rajadurai did not explicitly disclose an arrangement wherein validating the endpoint using the PSK and the session authentication cookie comprises: in response to determining that validation of the endpoint using the PSK and the session cookie fails, failing the authentication request.
However, in an analogous art, Rajadurai’696 further disclosed an arrangement wherein validating the endpoint using the PSK and the session authentication cookie comprises: in response to determining that validation of the endpoint using the PSK and the session cookie fails, failing the authentication request (Rajadurai’696 para. [0152], “In case, if the access token obtained from the ECS (340) is not valid (due to time limitation), then the EEC (312) requests ECS (340) for a new access token.”; [NOTE: Rajadurai’696’s “access token” is being interpreted as the claimed “cookie”]).
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 modify Rajadurai to include, as taught by Rajadurai’696, an arrangement wherein validating the endpoint using the PSK and the session authentication cookie comprises: in response to determining that validation of the endpoint using the PSK and the session cookie fails, failing the authentication request. Motivation for modifying would have been to utilize the validity of the session cookie (as a second authentication factor), in order to increase a security, user-friendliness, attractiveness and broadened adoption of the Rajadurai/Rajadurai’696 combination within the security field.
Per claim 18: The Rajadurai/Rajadurai’696 combination made obvious the system of claim 17. Rajadurai further disclosed an arrangement wherein: the authentication request is a request for authentication using Internet Key Exchange version 2 (IKEv2) protocol (Rajadurai page 18, within para. beginning as “At step S602 of stage 3, the IAB relay device”, see “DU (150) sends an IKE-AUTH request including an AUTH value (i.e., IKEv2 value) to the CU (210)”; Rajadurai page 11, within para. beginning as “The method includes generating, by the IAB relay device”, see “using PSK to generate internet key exchange (IKE) version 2 AUTH value, for performing mutual authentication”; Rajadurai page 17, within the para. beginning as “At step S504”, see ” the DU (150) generates an IKEv2 AUTH payload using PSK (obtained at step S506) specified in the Internet Key Exchange Protocol version 2 (IKEv2) IETF RFC”). Rajadurai did not explicitly disclose an arrangement wherein: the authentication request is deemed to have failed if decryption of a payload comprised in the authentication request using a gateway-side PSK fails.
However, Rajadurai’696 further disclosed an arrangement wherein the authentication request is deemed to have failed if decryption of a payload comprised in the authentication request using a gateway-side PSK fails (Rajadurai’696 para. [0182], “protected using application layer protection for example, JSON Web Encryption (JWE)”; Rajadurai’696 para. [0152], “In case, if the access token obtained from the ECS (340) is not valid (due to time limitation), then the EEC (312) requests ECS (340) for a new access token.”; [NOTE: Rajadurai’696’s “access token” is being interpreted as the claimed “cookie”]).
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 modify Rajadurai to include, as taught by Rajadurai’696, an arrangement wherein: the authentication request is deemed to have failed if decryption of a payload comprised in the authentication request using a gateway-side PSK fails. Motivation for modifying would have been to utilize the validity of payload decryption (as a third authentication factor), in order to increase a security, user-friendliness, attractiveness and broadened adoption of the Rajadurai/Rajadurai’696 combination within the security field.
Per claim 19: The Rajadurai/Rajadurai’696 combination made obvious the system of claim 17. Rajadurai did not explicitly disclose an arrangement wherein the authentication request is deemed to have failed if the session authentication cookie is not valid.
However, in an analogous art, Rajadurai’696 further disclosed an arrangement wherein the authentication request is deemed to have failed if the session authentication cookie is not valid (Rajadurai’696 para. [0152], “In case, if the access token obtained from the ECS (340) is not valid (due to time limitation), then the EEC (312) requests ECS (340) for a new access token.”; [NOTE: Rajadurai’696’s “access token” is being interpreted as the claimed “cookie”]).
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 modify Rajadurai to include, as taught by Rajadurai’696, an arrangement wherein the authentication request is deemed to have failed if the session authentication cookie is not valid. Motivation for modifying would have been to utilize the validity of the session cookie (as a second authentication factor), in order to increase a security, user-friendliness, attractiveness and broadened adoption of the Rajadurai/Rajadurai’696 combination within the security field.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Paul J Skwierawski whose telephone number is (571)272-2642. The examiner can normally be reached 6:00am-3:30pm weekdays.
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 supervisory primary examiner (SPE) Luu Pham can be reached on (571) 270-5002. 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.
/Paul Skwierawski/
Patent Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
