DETAILED ACTION
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 .
This Office Action is in response to the Continuation filed on 10/23/2025.
In the instant Amendment, claims 1-4, 7-8, 10-11, 13, and 17-19 have been amended; and claims 1, 11, and 18 are independent claims. Claims 1-20 have been examined and are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 029/15/2023 has been entered.
Response to Arguments
Applicant’s argument that Tandon fails to disclose “receiving a request to attach to the MNO core network” is not persuasive.
Tandon describes the LTE attach procedure in which UE 90 initiates network attachment through MME 92 (Fig. 3; col. 9, lines 1–17). During this attach/session establishment procedure, Identification System 14 intercepts the Create Session Request signaling and extracts subscriber identification information including MSISDN (col. 9, lines 8–17). Because the Create Session Request is generated as part of the network attach/session establishment procedure, Identification System 14 receives signaling information associated with the attach request including the MSISDN. The claim does not require that the authentication module be the first network entity receiving the attach request, only that it receives the request information including the MSISDN. Accordingly, Tandon teaches the claimed limitation.
Applicant’s argument that Tandon does not disclose receiving “a second MSISDN number and a token” is not persuasive.
Tandon discloses that Merchant server 16 sends an authentication request to Authentication System 12 containing identification values associated with UE 90 including MSISDN, IMSI, IMEI, user location information, and IP address (col. 9, lines 34–41; step 130). These identifiers uniquely identify the service session associated with the subscriber device and therefore function as authentication tokens associated with the service request. The claim does not limit the token to any specific format or structure. Accordingly, the identification values transmitted from the merchant server constitute the claimed token associated with the instance of service use.
Applicants’ arguments filed on 10/23/2025 with respect to the TLS header private IP retrieval of claims 1, 11, and 18 have been considered but are moot in view of the new ground(s) of rejection, which were necessitated by amendment.
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 (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 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 1-8, 9, 11-17, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Tandon et al. (U.S. Application 11184356 B1; Hereinafter “Tandon”) in view of Kang et al. (U.S. Pub 20230209340 A1; Hereinafter “Kang”) and Skog et al. (U.S. Pub 2011/0216726 A1; Hereinafter “Skog”).
As per claims 1, 18, Tandon teaches a method for authenticating a user, the method comprising (Tandon: fig. 1, 3, col. “FIGS. 3-9 provide signaling diagrams illustrating various implementations of subscriber verification system 10. FIG. 3 pertains to a scenario in which UE 90 uses a merchant application installed on UE 90 to request access to Merchant server 16 via an LTE network.”):
receiving, by an authentication module (Identification 14) associated with a mobile network operator (MNO) core network, a request to attach to the MNO core network, the request to attach to the MNO core network including a first Mobile Station Integrated Services Digital Network (MSISDN) number registered with a subscriber device (UE 90) (Tandon: step 102-108, “UE 90 initiates the process in step 102 by sending an attach request toward MME 92. In step 104, MME 92 sends a Create Session Request message to SGW 22. In step 106, Identification System 14 receives the Create Session Request message from SGW 22, wherein the Create Session Request message is intercepted by GTP-Proxy 62 of Identification System 14. Identification System 14 decodes the intercepted Create Session Request message and extracts information elements (IEs) therefrom that identify UE 90, including MSISDN, IMSI, IMEI, and/or User Location Information (ULI) (also referred to herein as “identification values”). Identification System 14 stores the extracted IEs in Session database 76.”);
receiving, by the authentication module, a second MSISDN number and a token for an instance of use service associated with a web server (Merchant servers 16) responsive to a request to connect with the web server, wherein the request to connect is triggered by the subscriber device (Tandon: step 130-140, “In step 122, subsequent to establishing the data session, when a subscriber tries to connect to Merchant server 16 using the Merchant application installed on UE 90, UE 90 sends an HTTPS request toward Merchant server 16… in step 130, Merchant server 16 triggers an API authentication request toward Authentication System 12. The authentication request contains the set of the identification values associated with UE 90 received in the HTTPS request—i.e., MSISDN, IMSI, IMEI, ULI, and End User IP Address—and also includes the source Public IP Address and Port number from which the HTTPS request was received…In step 132, Authentication System 12 sends an identification request toward Identification System 14 via an internal API. The identification request includes all information that Authentication system 12 received from Merchant server 16 in the authentication request”).
determining, by the authentication module (Tandon: step 132-140, “in step 138, Identification module 74 uses the Public IP Address and Port information provided by Merchant server 16 to retrieve a set of identification values i.e., MSISDN, IMSI, IMEI, ULI, End User IP Address-stored in Session database 76…Identification module 74 compares the identification values associated with UE 90 stored in Session database 76 against the identification values Merchant server 16 received with the HTTPS request and provided in the identification request.”); and
providing, by the authentication module, an authentication indicator responsive to the determination of whether the first MSISDN number matches the second MSISDN number (Tandon: step 140 “If the set of values received in the identification request matches the corresponding values stored in Session database 76, Identification system 14 sends a Success identification response to Authentication System 12 in step 140.”).
Tandon does not explicitly teach causing, by the authentication module, redirection of the subscriber device with which the first MSISDN number is registered, from the web server to the authentication module using a first redirect Hypertext Transfer Protocol Secure (HTTPS) uniform resource locator (URL), in response to receiving the second MSISDN number and the token from the web server; wherein, upon redirection of the subscriber device, the first MSISDN is retrieved by the authentication module by receiving, at the authentication module, an MNO managed subscriber device private IP address via a header of a transport layer security (TLS) protocol from the subscriber device, in response to the causing the redirection of the subscriber device; and identifying the first MSISDN using the private IP address.
However, in the related art, Kang teaches causing, by the authentication module, redirection of the subscriber device with which the first MSISDN number is registered, from the web server to the authentication module, using a first redirect Hypertext Transfer Protocol Secure (HTTPS) uniform resource locator URL (Kang: fig. 5A-B, para [92-97], [98-100], “with reference to FIG. 5A, the ECS 120 may explicitly notify the terminal of the selected authentication type, and even if the selected authentication type is not explicitly provided, the terminal may determine the authentication type through provision of predetermined information that the terminal may determine, that is, for example, a reply to the SM-DP+ server address to be authenticated. As an example, the ECS may request redirection to the SM-DP+ server address to be authenticated with the HTTP(s) “302 Found” response structure that replies when the ECS selects the OAuth/Open ID authentication method, and in this case, one of the following examples may be included. Example 1) Http(s) Response—302 Found. Include the following in the header…. redirect URL=<ECS address encrypted with AES as address to reply>..”, “ ..An example of the transmitted message may be a message such as ES9+.AuthenticateClient Request (MatchingID=ICCID1, AuthRequest (Nonce, eUICC Signature) (step 5b-50)….. When the SM-DP+ server 150 receives the AuthenticateClientRequest message, the SM-DP+ server 150 may perform a validation verification process including subscription information included in the AuthenticateClientRequest message,”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to incorporate the redirect authentication technique of Kang, in order to securely redirect the subscriber device to an authentication module for verification (Kaang: para [76]).
Tandon in view of Khang does not explicitly teach wherein, upon redirection of the subscriber device, the first MSISDN is retrieved by the authentication module by receiving, at the authentication module, an MNO managed subscriber device private IP address via a header of a transport layer security (TLS) protocol from the subscriber device, in response to the causing the redirection of the subscriber device; and identifying the first MSISDN using the private IP address.
However, in the related art, Skog teaches wherein, upon redirection of the subscriber device, the first MSISDN is retrieved by the authentication module by receiving, at the authentication module, an MNO managed subscriber device private IP address via a header of a transport layer security (TLS) protocol from the subscriber device, in response to the causing the redirection of the subscriber device (Skog: para[6], “the WAP gateway node may alternatively be provided by a mobile services operator”, para [25], “The IP address and the MSISDN are stored as a record 118 within the mapping session database 80 within the WAP gateway 70….Once this connection is established, the user may generate a request 130 for access to a particular WAP application 85 ("service") on a web server. This request is forwarded from the mobile terminal 45 to the WAP gateway 70. The WAP gateway 70 forwards the mobile terminal request 138 to the requested application 85. The WAP gateway 70 may determine the IP address of the mobile terminal 45 by examining the IP packet header to determine the IP address of the mobile terminal.”); and
identifying the first MSISDN using the private IP address (Skog: fig. 5A-B, para [25], “The MSISDN of the mobile terminal 45 is determined by examining the mapping session database 80 and the associated IP address via the application program interface 88. The determined MSISDN is placed in an HTTP header of packets used to contact the WAP application 85.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to modify the subscriber verification system of the modified Tandon to incorporate the IP-to-MSISDN subscriber identification technique of Skog in order to identify the subscriber device based on network session information such as the assigned IP address (Skog: para [25]).
Furthermore, Tandon also teaches the hardware components of claim 18 such as a data storage device storing processor-readable instructions; and a processor operatively connected to the data storage device and configured to execute the instructions to perform operations that include: (Tandon: fig. 2, col. 7 “FIG. 2 provides a block diagram depicting structures of Authentication System 12 and Identification System 14. FIG. 2 depicts that Authentication System 12 comprises a processor 44 and a non-transitory computer readable medium (Memory) 46.”).
As per claims 2, 13, and 19, Tandon in view of Kang and Skog teaches the independent claim 1. Skog teaches wherein the request to attach to the MNO core network further comprises: storing, by the authentication module in a database, the private IP address associated with the first MSISDN number para [25], “, the IP address and the MSISDN of the mobile terminal 45 are transmitted over the PPP connection from the access server 60 to the WAP gateway 70 as an accounting request message 115 to enable mapping between these identifiers. The IP address and the MSISDN are stored as a record 118 within the mapping session database 80 within the WAP gateway 70.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to modify the subscriber verification system of the modified Tandon to incorporate the IP-to-MSISDN subscriber identification technique of Skog in order to identify the subscriber device based on network session information such as the assigned IP address (Skog: para [25]).
As per claim 3, Tandon in view of Kang and Skog teaches the dependent claim 2. Tandon teaches wherein determining whether the first MSISDN number matches the second MSISDN number is further in response to receiving, at the authentication module, the first MSISDN number, associated with the private IP address, from the database (Tandon: : step 138 “Identification module 74 compares the identification values associated with UE 90 stored in Session database 76 against the identification values Merchant server 16 received with the HTTPS request and provided in the identification request.”).
As per claim 4, Tandon in view of Kang and Skog teaches the independent claim 1. Tandon teaches wherein the receiving, by the authentication module, the second MSISDN number and the token, from the web server comprises receiving the second MSISDN number and the token via a cloud communication platform (Tandon: step 132 “In step 132, Authentication System 12 sends an identification request toward Identification System 14 via an internal API.” Col. 7 “Authentication System 12 can be deployed on a cloud to handle authentication requests from Merchant's online platform server over Hyper Text Transfer Protocol Secured (HTTPS)/Virtual Private Network (VPN) to authenticate the mobile subscriber”).
As per claims 5, 15, and 20, Tandon in view of Kang and Skog teaches the dependent claim 4. Tandon teaches providing the authentication indicator including a positive authentication indicator to the web server (Tandon: step 140-144, “If the set of values received in the identification request matches the corresponding values stored in Session database 76, Identification system 14 sends a Success identification response”); and causing the request to connect to be approved based on the authentication indicator including the positive authentication indicator (Tandon: step 140-144, “in step 144, Authentication system sends a successful authentication response toward Merchant server 16. In step 146, Merchant server 16 sends a successful HTTPS response to Identification System 16, which is then forwarded to UE 90 in step 148. At this point, UE 90 is successfully authenticated and is granted access to Merchant server 16”).
As per claims 6, 16, Tandon in view of Kang teaches the dependent claim 4. Tandon teaches receiving, by the cloud communication platform and from the web server, a public IP address associated with the request to connect with the web server (Tandon: step 122-130 “In step 122, subsequent to establishing the data session, when a subscriber tries to connect to Merchant server 16 using the Merchant application installed on UE 90, UE 90 sends an HTTPS request toward Merchant server 16… in step 130, Merchant server 16 triggers an API authentication request toward Authentication System 12. The authentication request contains the set of the identification values associated with UE 90 received in the HTTPS request—i.e., MSISDN, IMSI, IMEI, ULI, and End User IP Address—and also includes the source Public IP Address and Port number from which the HTTPS request was received.” Para[13], “Authentication System 12 can be deployed on a cloud to handle authentication requests from Merchant's online platform server over Hyper Text Transfer Protocol Secured (HTTPS)/Virtual Private Network (VPN) to authenticate the mobile subscriber”); and
determining, by the cloud communication platform, that the MNO core network is associated with the subscriber device (Tandon: fig. 3, step 130-140, “Upon receiving the authentication request from Merchant server 16, Authentication System 12 performs a lookup for applicable Identification System 14 based on the source Public IP Address and Port information received in the authentication request”).
As per claims 7, 17, Tandon in view of Kang of Skog teaches the dependent claim 6. Kang teaches generating, by the cloud communication platform based on determining that the MNO core network is associated with the subscriber device, the first redirect HTTPS URL to cause the subscriber device to be redirected to the authentication module; and causing the generated first redirect HTTPS URL to be provided to the subscriber device (Kang: fig. 3, para[91-97] “the ECS 120 may generate a nonce value, which is arbitrary data (step 5b-20), and reply a message including an ECS&DP+ authentication method, an SM-DP+ server address to be authenticated, and a generated nonce value to the first terminal 300 (step 5b-30). As described above with reference to FIG. 5A, the ECS 120 may explicitly notify the terminal of the selected authentication type, and even if the selected authentication type is not explicitly provided, the terminal may determine the authentication type through provision of predetermined information that the terminal may determine, that is, for example, a reply to the SM-DP+ server address to be authenticated. As an example, the ECS may request redirection to the SM-DP+ server address to be authenticated with the HTTP(s) “302 Found” response structure that replies when the ECS selects the OAuth/Open ID authentication method, and in this case, one of the following examples may be included.”)
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to incorporate the redirect authentication technique of Kang, in order to securely redirect the subscriber device to an authentication module for verification (Kang: para [76]).
As per claim 8, Tandon in view of Kang and Skog teaches the dependent claim 7. Kang teaches generating, by the authentication module, a second redirect URL to cause the subscriber device to be redirected to the web server; and causing the second redirect URL to be provided to the subscriber device (Kang: para[97] “the terminal may determine that the ECS requests to authenticate with ECS&DP+ instead of an OAuth/Open ID method, the ODSA1 500 may transmit received data to the LPA1 510 with an internal operation of the first terminal 300 (steps 5b-40), and then perform the DP+ authentication procedure as follows. In the case of an OAuth/Open ID authentication method, a code received as a response type requires a client id, redirection URI, and binding, and the initial Http(s) response—302 Found includes the client id and redirection URI and should be transmitted. The OAuth2.0/OIDC sever may issue a client ID for the ECS in advance through a prior contract and have information on redirection URI, and when the terminal requests authentication with a specific client ID and redirection URI, the OAuth2.0/OIDC sever may verify the information, issue a code, and reply.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to incorporate the redirect authentication technique of Kang, in order to securely redirect the subscriber device to an authentication module for verification (Kang: para [76]).
As per claim 9, Tandon in view of Kang and Skog teaches the dependent claim 4. Tandon teaches wherein the cloud communication platform and the web server are external to the MNO core network (Tandon: fig. 10, col. 6, “Authentication System 12 can be deployed on a cloud to handle authentication requests from Merchant's online platform server over Hyper Text Transfer Protocol Secured (HTTPS)/Virtual Private Network (VPN) to authenticate the mobile subscriber”).
As per claim 11, Tandon teaches a method for authenticating a user, the method comprising (Tandon: fig. 1, 3, col. “FIGS. 3-9 provide signaling diagrams illustrating various implementations of subscriber verification system 10. FIG. 3 pertains to a scenario in which UE 90 uses a merchant application installed on UE 90 to request access to Merchant server 16 via an LTE network.”):
receiving, by an authentication module (identification 14) associated with a mobile network operator (MNO) core network, a request to attach the MNO core network, the request to attach to the MNO core network including a first Mobile Station Integrated Services Digital Network (MSISDN) number registered with a subscriber device (UE 90) (Tandon: step 102-108, “In step 106, Identification System 14 receives the Create Session Request message from SGW 22, wherein the Create Session Request message is intercepted by GTP-Proxy 62 of Identification System 14. Identification System 14 decodes the intercepted Create Session Request message and extracts information elements (IEs) therefrom that identify UE 90, including MSISDN, IMSI, IMEI, and/or User Location Information (ULI) (also referred to herein as “identification values”). Identification System 14 stores the extracted IEs in Session database 76.”);
receiving, by a cloud communication platform and from a web server, a second MSISDN number and a token for an instance of use of a service associated with the web server, responsive to a request to connect with the web server, wherein the request to connect is triggered by the subscriber device (Tandon: para[30], “In step 122, subsequent to establishing the data session, when a subscriber tries to connect to Merchant server 16 using the Merchant application installed on UE 90, UE 90 sends an HTTPS request toward Merchant server 16… in step 130, Merchant server 16 triggers an API authentication request toward Authentication System 12. The authentication request contains the set of the identification values associated with UE 90 received in the HTTPS request—i.e., MSISDN, IMSI, IMEI, ULI, and End User IP Address—and also includes the source Public IP Address and Port number from which the HTTPS request was received.” Para[13], “Authentication System 12 can be deployed on a cloud to handle authentication requests from Merchant's online platform server over Hyper Text Transfer Protocol Secured (HTTPS)/Virtual Private Network (VPN) to authenticate the mobile subscriber”);
determining, by the cloud communication platform, (Tandon: step 132-140, “Upon receiving the authentication request from Merchant server 16, Authentication System 12 performs a lookup for applicable Identification System 14 based on the source Public IP Address and Port information received in the authentication request. In step 132, Authentication System 12 sends an identification request toward Identification System 14 via an internal API.… Upon receiving the identification response, in step 142, Authentication System 12 validates the identification values provided by Identification System 14 against the identification values previously stored in Subscriber database 52 of Authentication System 12”); and
providing, by the cloud communication platform and to the web server, an authentication indicator responsive to the determination of whether the first MSISDN number matches the second MSISDN number (Tandon: step 144-148, “if the subscriber is successfully validated, then, in step 144, Authentication system sends a successful authentication response toward Merchant server 16. In step 146, Merchant server 16 sends a successful HTTPS response to Identification System 16, which is then forwarded to UE 90 in step 148. At this point, UE 90 is successfully authenticated and is granted access to Merchant server 16.”).
Tandon does not explicitly causing, by the cloud communication platform, redirection of the subscriber device with which the first MSISDN number is registered, from the web server to the authentication module, using a first redirect Hypertext Transfer Protocol Secure (HTTPS); wherein, upon redirection of the subscriber device, the first MSISDN is retrieved by the authentication module by receiving, at the authentication module, an MNO managed subscriber device private IP address via a header of a transport layer security (TLS) protocol from the subscriber device, in response to the causing the redirection of the subscriber device; and identifying the first MSISDN using the private IP address.
However, in the related art, Kang teaches causing, by the cloud communication platform, redirection of the subscriber device with which the first MSISDN number is registered, from the web server to the authentication module, using a first redirect Hypertext Transfer Protocol Secure (HTTPS) (Kang: fig. 5A-B, para [92-97], “with reference to FIG. 5A, the ECS 120 may explicitly notify the terminal of the selected authentication type, and even if the selected authentication type is not explicitly provided, the terminal may determine the authentication type through provision of predetermined information that the terminal may determine, that is, for example, a reply to the SM-DP+ server address to be authenticated. As an example, the ECS may request redirection to the SM-DP+ server address to be authenticated with the HTTP(s) “302 Found” response structure that replies when the ECS selects the OAuth/Open ID authentication method, and in this case, one of the following examples may be included. Example 1) Http(s) Response—302 Found. Include the following in the header…. redirect URL=<ECS address encrypted with AES as address to reply>..” para[98-100], “.An example of the transmitted message may be a message such as ES9+.AuthenticateClient Request (MatchingID=ICCID1, AuthRequest (Nonce, eUICC Signature) (step 5b-50)….. When the SM-DP+ server 150 receives the AuthenticateClientRequest message, the SM-DP+ server 150 may perform a validation verification process”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to incorporate the redirect authentication technique of Kang, in order to securely redirect the subscriber device to an authentication module for verification (Kaang: para [76]).
Tandon in view of Khang does not explicitly teach wherein, upon redirection of the subscriber device, the first MSISDN is retrieved by the authentication module by receiving, at the authentication module, an MNO managed subscriber device private IP address via a header of a transport layer security (TLS) protocol from the subscriber device, in response to the causing the redirection of the subscriber device; and identifying the first MSISDN using the private IP address.
However, in the related art, Skog teaches wherein, upon redirection of the subscriber device, the first MSISDN is retrieved by the authentication module by receiving, an MNO managed subscriber device private IP address via a header of a transport layer security (TLS) protocol from the subscriber device, in response to the causing the redirection of the subscriber device (Skog: para[6], “the WAP gateway node may alternatively be provided by a mobile services operator”, para [25], “The IP address and the MSISDN are stored as a record 118 within the mapping session database 80 within the WAP gateway 70….Once this connection is established, the user may generate a request 130 for access to a particular WAP application 85 ("service") on a web server. This request is forwarded from the mobile terminal 45 to the WAP gateway 70. The WAP gateway 70 forwards the mobile terminal request 138 to the requested application 85. The WAP gateway 70 may determine the IP address of the mobile terminal 45 by examining the IP packet header to determine the IP address of the mobile terminal.”) ; and
identifying the first MSISDN using the private IP address (Skog: fig. 5A-B, para [25], “The MSISDN of the mobile terminal 45 is determined by examining the mapping session database 80 and the associated IP address via the application program interface 88. The determined MSISDN is placed in an HTTP header of packets used to contact the WAP application 85.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to modify the subscriber verification system of the modified Tandon to incorporate the IP-to-MSISDN subscriber identification technique of Skog in order to identify the subscriber device based on network session information such as the assigned IP address (Skog: para [25]).
As per claim 12, Tandon in view of Kang and Skog teaches the independent claim 11. Tandon teaches wherein the second MSISDN number is associated with the subscriber device (Tandon: col. (320, “The authentication request contains the set of the identification values associated with UE 90 received in the HTTPS request—i.e., MSISDN, IMSI, IMEI, ULI, and End User IP Address—and also includes the source Public IP Address and Port number from which the HTTPS request was received.”).
As per claim 14, Tandon in view of Kang and Skog teaches the independent claim 11. Tandon teaches receiving, by the cloud communication platform and from the authentication module, the first MSISDN number (Tandon: step 140, “Next, in step 138, Identification module 74 uses the Public IP Address and Port information provided by Merchant server 16 to retrieve a set of identification values i.e., MSISDN, IMSI, IMEI, ULI, End User IP Address-stored in Session database 76…Identification system 14 sends a Success identification response to Authentication System 12 in step 140. The identification response further contains the set of identification values retrieved from Session database 76”).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Tandon et al. (U.S. Application 11184356 B1; Hereinafter “Tandon”) in view of Kang et al. (U.S. Pub 20230209340 A1; Hereinafter “Kang”), Skog et al. (U.S. Pub 2011/0216726 A1; Hereinafter “Skog”), and Newell et al. (U.S. Pub 20190342283 A1; Hereinafter “Newell”).
As per claim 10, Tandon in view of Kang and Skog teaches the independent claim 1.
Tandon in view of Kang does not teach terminating, by the authentication module, the TLS protocol responsive to the redirected request.
However, in the related art, Newell teaches terminating, by the authentication module, the TLS protocol responsive to the redirected request (Newell: para[52-53], “If the application 147 is not authenticated or requires re-authentication, the application service 107 can redirect the application 147 to identity provider 118 with instructions to obtain an authentication credential or token, such as an authentication assertion, from the identity provider 118 and present the credential to the authentication service 107. In one scenario, the application service 107 can issue a redirect message to the application 147 with instructions to redirect to the identity provider 118…The security layer, or the additional TLS encryption layer, can be terminated at the authentication proxy 122. If the application 147 applies an initial encryption layer to the authentication request, this initial encryption layer can be terminated at the identity provider 118.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Tandon with Newell, it will improve the server performance (Newell: para [78).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LYDIA L NOEL whose telephone number is (571)272-1628. 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, Alexander Lagor can be reached on (571)-270-5143. 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.
/L.L.N./Examiner, Art Unit 2437
/MENG LI/Primary Examiner, Art Unit 2437