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 Amendments filed on 06/24/2026.
Response to Arguments
Applicants’ arguments filed on 06/24/2025 with respect to the 103 rejection of claims 1-20 have been considered but are moot in view of the new ground(s) of rejection, which were necessitated by amendment.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 8 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 8 recites “wherein determining ... whether the first MSISDN number matches the second MSISDN includes..; authenticating the user…; and causing redirection of the subscriber device to the web server..”. It is unclear how the act of “determining ... whether the first MSISDN number matches the second MSISDN number” itself “includes” the subsequent act of causing the subscriber device to be redirected. The specification treats the comparison/authentication and subsequent redirection as distinct operations. Paragraph [0057] describes comparing the MSISDNs and determining that the subscriber device is verified, whereas paragraph [0058] separately states that upon completion of verification the authentication module may generate a redirect URL to redirect the subscriber device back to the enterprise web server. Therefore, one of ordinary skill in the art would not be reasonably apprised whether the redirect operation is part of the claimed determination or is a separate method step performed after authentication.
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, 10-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 Yau et al. (U.S. Pat 10277586 B1; Hereinafter “Yau”), Dinan et al. (U.S. Pub 2022/0103531 A1; Hereinafter “Dinan”), Bao et al. (U.S. Pub 2018/0351950 A1; Hereinafter “Bao”), and Fandridi et al. (U.S. Pub 2022/0353249 A1; Hereinafter “Fandridi”),
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, ((Tandon: Fig. 4, step 130-140, steps 228–232, Merchant server 16 retrieves the MSISDN previously stored during onboarding/KYC and sends an authenticate request containing that MSISDN to Authentication System 12. Tandon's browser embodiment begins when the subscriber requests Merchant services”);
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 receive from the web server (i) a return uniform resource locator (URL) for returning the subscriber device to a web server after authentication of the subscriber device, (ii) a token including a communication error-troubleshooting globally unique identifier (GUID) associated with an instance of use of a service associated with the web server; storing, by the authentication module, the second MSISDN number and the return URL for returning the subscriber device to the web server after authentication of the subscriber device; causing, via 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) URL, in response to receiving (i) the return URL for returning the subscriber device to the web server after authentication of the subscriber device, (ii) the token including the communication error-troubleshooting GUID, and (iii) the second MSISDN number from the web server; 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 number using the private IP address.
However, in the related art, Yau teaches receive from the web server (i) a return uniform resource locator (URL) for returning the subscriber device to a web server after authentication of the subscriber device (Yau: Fig. 2col. 3-4, teaches an enterprise application sending authentication request 225 to mobile authentication platform 10 and expressly providing the “URL of the authentication page where the mobile device ... shall be redirected.”. Yau begins with an HTTP request carrying the user-entered MSISDN to enterprise application 220. Yau similarly sends the input MSISDN from enterprise application 220 to the mobile authentication platform.), (ii) a token (Yau: col. 4, line 25-35, teaches that the same authentication request may include a one-time authentication token and a transaction-reference number that uniquely identifies the particular authentication request. “Upon receiving the HTTP-302 response, the mobile device 240 browser or client application will be redirected and submits a HTTP request 265 to the new URL in the HTTP-302 response 262, and carries the transaction reference number, inputted MSISDN 275 and the one-time token 245 as HTTP request parameters.”;
storing, by the authentication module, the second MSISDN number and (Yau: claims 1, 12, and 20, expressly saves authentication information including token/MSISDN/session information in a data store, and receives the redirect URL as part of the pending authentication request. Its claims expressly recite saving the token and alleged MSISDN “saving the token value, the alleged MSISDN value and the GTP session data in a data store; and injecting an HTTP redirect response within a GTP downlink tunnel associated with the alleged MSISDN,”).
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 Tandon with Yau to provide the known web authentication transaction in which the enterprise sends an MSISDN, transaction identifier, token and redirect URL to a mobile network authentication platform and the platform performs an HTTPS capable URL redirect. Both references concern seamless MSISDN authentication of a mobile subscriber accessing an enterprise web service. It would provide a browser compatible mechanism for routing the subscriber through the carrier authentication function while maintaining transaction context.
Tandon in view of Yau does not explicitly teach the token including a communication error-troubleshooting globally unique identifier (GUID) associated with an instance of use of a service associated with the web server; storing, by the authentication module, the return URL for returning the subscriber device to the web server after authentication of the subscriber device; causing, via 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) URL, in response to receiving (i) the return URL for returning the subscriber device to the web server after authentication of the subscriber device, (ii) the token including the communication error-troubleshooting GUID, and (iii) the second MSISDN number from the web server; 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 number using the private IP address.
However, in the related art, Dinan teaches token including a communication error-troubleshooting globally unique identifier (GUID) associated with an instance of use of a service associated with the web server (Dinan: fig. 3, para [96], expressly teaches generating a GUID for each received request, associating it with logs of the transaction resulting from that request, and using the GUID/log entries for transaction tracking for troubleshooting purposes “The GUID and the log entries associated with the GUID may facilitate transaction tracking for troubleshooting purposes. The same GUID may be returned in the primary token exchange response that corresponds to the request, and may be used/submitted by the client (e.g., a merchant) via the merchant portal 330, in order to investigate the associated transaction(s) using the log entries.” Examiner notes that the recited token GUID is merely received and is not subsequently used in performing the authentication, MSISDN comparison, or redirection. Thus, the claim requires only that the received token include the recited GUID; it does not require any functional use of the GUID for troubleshooting or authentication.).
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 include such a per request GUID with the temporary authentication token used in the modified Tandon, it would improve observability and error diagnosis of the distributed authentication transaction without changing Tandon's underlying MSISDN matching authentication determination.
Tandon in view of Yau and Dinan does not explicitly teach storing, by the authentication module, the return URL for returning the subscriber device to the web server after authentication of the subscriber device; causing, via 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) URL, in response to receiving (i) the return URL for returning the subscriber device to the web server after authentication of the subscriber device, (ii) the token including the communication error-troubleshooting GUID, and (iii) the second MSISDN number from the web server; 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 number using the private IP address.
However, in the related art, Bao teaches storing, by the authentication module, the return URL for returning the subscriber device to the web server after authentication of the subscriber device (Bao; para [0109], [0142], teaches registration and storage of application credentials including the callback URL and later verifying a received callback URL against a previously stored URL for the registered service. Thus the combined references provide storage of both pieces of authentication session information);
causing, via 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) URL (Bao: para [0056-0057], Fig. 5, steps 5.2–5.3, Bao teaches client application server 230 responds to the device's login attempt with an HTTP 302 Redirect requesting authentication by network authentication server 220. The request includes the callback URL, and the device follows the redirect to the network authentication server. Bao also expressly states in the later embodiment that application server 1020 may directly redirect the user device to network authentication system 1040 via a 302 Redirect. Yau expressly teaches that redirected request 265 may be submitted using HTTPS to prevent eavesdropping, and claim 2 expressly states the redirected connection URL is over HTTPS. This is combined with Bao's express server-network-authentication redirect direction), in response to receiving (i) the return URL for returning the subscriber device to the web server after authentication of the subscriber device, (ii) the token including the communication error-troubleshooting GUID, and (iii) the second MSISDN number from the web server (Yau receives together in authentication request 225 the transaction identifier, input MSISDN, redirect URL and optional token, and thereafter constructs the HTTP-302 redirect. Yau's redirect contains the URL, transaction reference, MSISDN and token. Dinan merely supplies the known GUID/troubleshooting form of the transaction identifier. Tandon, Fig. 4, step 238 expressly retrieves the network-side MSISDN and compares the MSISDN supplied by Merchant server 16 against the MSISDN stored in Session database 76. If they match, Success is returned); and
identifying the first MSISDN number using the private IP address (Bao: para [0030-0032], [0046], claim 1, teaches determining an MDN from the IP address used by the user device. Its claim 1 expressly recites identifying the IP and authenticating by determining that the telecommunications network previously associated that IP with an MDN).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Tandon's subscriber verification system to employ Bao's callback-URL and redirect based network authentication workflow. Tandon and Bao are directed to the same problem of authenticating a subscriber seeking access to a third-party online service using subscriber identity information available from a telecommunications network. Bao teaches redirecting a subscriber device from an application server to a network authentication server using a callback URL and subsequently returning the subscriber device to the application server with temporary authentication information. It would provide a seamless browser authentication workflow while retaining Tandon's carrier side MSISDN/IP verification.
Tandon in view of Yau, Dinan, and Bao does not explicitly teach 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.
However, in the related art, Fandrini teaches 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 (Fandrini: para [0069], Fig. 2A shows client ClientHello 201, TLS extension 202 and enrichment information 203; Fig. 2B shows interception and addition of enrichment information; Fig. 3A shows receipt of the unencrypted part of the TLS initiator packet, extraction of the TLS-extension enrichment information, storage, TLS completion, and later insertion into HTTPS requests. The detailed disclosure states that, in a mobile-network embodiment, the enrichment information can expressly be MSISDN or “User Equipment Internet Protocol Address (UE IP Address)”, and that the information is placed in a configured extension of a client handshake initiator packet sent toward the TLS termination component. Fandrini further teaches that TLS extensions are part of the first handshake packet, specifically the ClientHello, and claim 30 identifies the initiator packet as a Client Hello packet of a TLS handshake with the enrichment information in the configured extension. The uploaded patent's Fig. 2A visually shows CLIENT HELLO 201 → EXTENSION 202 → ENRICHMENT INFORMATION 203.).
It would have been obvious to one of ordinary skill in the art before the effective filing date to employ Fandrini's TLS-extension enrichment technique in the modified Tandon system to make the MNO managed IP information available during the secure HTTPS authentication transaction while preserving end-to-end HTTPS protection, thereby permitting Tandon's subscriber identification lookup to be performed without reverting to unsecured HTTP header enrichment.
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 Yau, Dinan, Bao, and Fandrini teaches the independent claim 1. Tandon 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 (Tandon: Fig. 3, step 112 retrieves the End User IP allocated to the UE, maps it to the identification elements including MSISDN stored in Session DB 76, and stores the IP in that database.).
As per claim 3, Tandon in view of Yau, Dinan, Bao, and Fandrini 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 Yau, Dinan, Bao, and Fandrini teaches the independent claim 1. Tandon teaches wherein the receiving, by the authentication module, the second MSISDN number, from the web server comprises receiving the second MSISDN number 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 Yau, Dinan, Bao, and Fandrini 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 Yau, Dinan, Bao, and Fandrini 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 Yau, Dinan, Bao, and Fandrini teaches the dependent claim 6. Yau 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 (Yau: fig. 3, col. 4-5, provides mobile authentication platform generation/injection of the URL redirect and expressly teaches an HTTPS redirected request.”)
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 Tandon with Yau to provide the known web authentication transaction in which the enterprise sends an MSISDN, transaction identifier, token and redirect URL to a mobile network authentication platform and the platform performs an HTTPS capable URL redirect. Both references concern seamless MSISDN authentication of a mobile subscriber accessing an enterprise web service. It would provide a browser compatible mechanism for routing the subscriber through the carrier authentication function while maintaining transaction context.
As per claim 8, Tandon in view of Yau, Dinan, Bao, and Fandrini teaches the dependent claim 7. Bao teaches wherein determining, by the authentication module and responsive to causing the redirection of the subscriber device, whether the first MSISDN number matches the second MSISDN includes: authenticating the user based on determining that the first MSISDN number matches the second MSISDN number; and causing redirection of the subscriber device to the web server using the return URL subsequent to authenticating the user (Bao: Fig. 5 steps 5.8–5.9, redirects the device using the callback URL back to the application service after network-side processing. Yau likewise redirects the mobile browser back to the enterprise application.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Tandon's subscriber verification system to employ Bao's callback-URL and redirect based network authentication workflow. Tandon and Bao are directed to the same problem of authenticating a subscriber seeking access to a third-party online service using subscriber identity information available from a telecommunications network. Bao teaches redirecting a subscriber device from an application server to a network authentication server using a callback URL and subsequently returning the subscriber device to the application server with temporary authentication information. It would provide a seamless browser authentication workflow while retaining Tandon's carrier side MSISDN/IP verification.
As per claim 9, Tandon in view of Yau, Dinan, Bao, and Fandrini 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 10, Tandon in view of Yau, Dinan, Bao, and Fandrini teaches the dependent claim 4. Fandrini teaches terminating, by the authentication module, the TLS protocol responsive to the redirected request (Fandrini: para [0069], fig. 2A, teaches the gateway sends the enriched ClientHello to the security-protocol component “where the encryption is terminated.” Fig. 3A then shows completing the handshake, receiving the HTTPS packet stream, decrypting HTTP requests, and forwarding enriched HTTP requests.).
It would have been obvious to one of ordinary skill in the art before the effective filing date to employ Fandrini's TLS-extension enrichment technique in the modified Tandon system to make the MNO managed IP information available during the secure HTTPS authentication transaction while preserving end-to-end HTTPS protection, thereby permitting Tandon's subscriber identification lookup to be performed without reverting to unsecured HTTP header enrichment.
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, 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, and responsive to receiving the first MSISDN number (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) uniform resource locator (URL), in response to receiving the second MSISDN number from the web server; retrieving, by the authentication module, the first MSISDN number 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 number using the private IP address; receiving, by the cloud communication platform and from the authentication module, the first MSISDN number and a token including a communication error- troubleshooting globally unique identifier (GUID) associated with an instance of use of a service associated with the web server; redirecting, by the cloud communication platform and responsive to determining whether the first MSISDN number matches the second MSISDN number, the subscriber device to the web server using a second redirect HTTPS URL.
However, in the related art, Yau teaches receiving, by the cloud communication platform and from the authentication module, the first MSISDN number and a token (Yau: Fig. 2 and detailed description, teaches an enterprise application sending authentication request 225 to mobile authentication platform 10 and expressly providing the “URL of the authentication page where the mobile device ... shall be redirected.”. Yau begins with an HTTP request carrying the user-entered MSISDN to enterprise application 220. Yau similarly sends the input MSISDN from enterprise application 220 to the mobile authentication platform, Yau teaches that the same authentication request may include a one-time authentication token and a transaction-reference number that uniquely identifies the particular authentication request.);
redirecting, by the cloud communication platform and responsive to determining whether the first MSISDN number matches the second MSISDN number, the subscriber device to the web server using a second redirect HTTPS URL (Yau expressly teaches that redirected request 265 may be submitted using HTTPS to prevent eavesdropping, and claim 2 expressly states the redirected connection URL is over HTTPS. This is combined with Bao's express server→network-authentication redirect direction. Yau receives together in authentication request 225 the transaction identifier, input MSISDN, redirect URL and optional token, and thereafter constructs the HTTP-302 redirect. Yau's redirect contains the URL, transaction reference, MSISDN and token.).
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 Tandon with Yau to provide the known web authentication transaction in which the enterprise sends an MSISDN, transaction identifier, token and redirect URL to a mobile network authentication platform and the platform performs an HTTPS capable URL redirect. Both references concern seamless MSISDN authentication of a mobile subscriber accessing an enterprise web service. It would provide a browser compatible mechanism for routing the subscriber through the carrier authentication function while maintaining transaction context.
Tandon in view of Yau does not explicitly teach 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) uniform resource locator (URL), in response to receiving the second MSISDN number from the web server; retrieving, by the authentication module, the first MSISDN number 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 number using the private IP address; a token including a communication error- troubleshooting globally unique identifier (GUID) associated with an instance of use of a service associated with the web server.
However, in the related art, Dinan teaches token including a communication error-troubleshooting globally unique identifier (GUID) associated with an instance of use of a service associated with the web server (Dinan: fig. 3, para [0096], expressly teaches generating a GUID for each received request, associating it with logs of the transaction resulting from that request, and using the GUID/log entries for transaction tracking for troubleshooting purposes “The GUID and the log entries associated with the GUID may facilitate transaction tracking for troubleshooting purposes. The same GUID may be returned in the primary token exchange response that corresponds to the request, and may be used/submitted by the client (e.g., a merchant) via the merchant portal 330, in order to investigate the associated transaction(s) using the log entries.” Examiner notes that the recited token GUID is merely received and is not subsequently used in performing the authentication, MSISDN comparison, or redirection. Thus, the claim requires only that the received token include the recited GUID; it does not require any functional use of the GUID for troubleshooting or authentication.).
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 include such a per request GUID with the temporary authentication token used in the modified Tandon, it would improve observability and error diagnosis of the distributed authentication transaction without changing Tandon's underlying MSISDN matching authentication determination.
Tandon in view of Yau and Dinan does not explicitly teach 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) uniform resource locator (URL), in response to receiving the second MSISDN number from the web server; retrieving, by the authentication module, the first MSISDN number 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 number using the private IP address.
However, in the related art, Bao 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) uniform resource locator (URL) (Bao: para [0056-0057], Fig. 5, steps 5.2–5.3, Bao teaches client application server 230 responds to the device's login attempt with an HTTP 302 Redirect requesting authentication by network authentication server 220. The request includes the callback URL, and the device follows the redirect to the network authentication server. Bao also expressly states in the later embodiment that application server 1020 may directly redirect the user device to network authentication system 1040 via a 302 Redirect. Yau also teaches that redirected request 265 may be submitted using HTTPS to prevent eavesdropping, and claim 2 expressly states the redirected connection URL is over HTTPS. This is combined with Bao's express server-network-authentication redirect direction), in response to receiving the second MSISDN number from the web server (Tandon, Fig. 4, step 238 expressly retrieves the network-side MSISDN and compares the MSISDN supplied by Merchant server 16 against the MSISDN stored in Session database 76. If they match, Success is returned); and
identifying the first MSISDN number using the private IP address (Bao: para [0030-0032], [0046], claim 1, teaches determining an MDN from the IP address used by the user device. Its claim 1 expressly recites identifying the IP and authenticating by determining that the telecommunications network previously associated that IP with an MDN);
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Tandon's subscriber verification system to employ Bao's callback-URL and redirect based network authentication workflow. Tandon and Bao are directed to the same problem of authenticating a subscriber seeking access to a third-party online service using subscriber identity information available from a telecommunications network. Bao teaches redirecting a subscriber device from an application server to a network authentication server using a callback URL and subsequently returning the subscriber device to the application server with temporary authentication information. It would provide a seamless browser authentication workflow while retaining Tandon's carrier side MSISDN/IP verification.
Tandon in view of Yau, Dinan, and Bao does not explicitly teach retrieving, by the authentication module, the first MSISDN number 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.
However, in the related art, Fandrini teaches retrieving, by the authentication module, the first MSISDN number 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 (Fandrini: para [0069], Fig. 2A shows client ClientHello 201, TLS extension 202 and enrichment information 203; Fig. 2B shows interception and addition of enrichment information; Fig. 3A shows receipt of the unencrypted part of the TLS initiator packet, extraction of the TLS-extension enrichment information, storage, TLS completion, and later insertion into HTTPS requests. The detailed disclosure states that, in a mobile-network embodiment, the enrichment information can expressly be MSISDN or “User Equipment Internet Protocol Address (UE IP Address)”, and that the information is placed in a configured extension of a client handshake initiator packet sent toward the TLS termination component. Fandrini further teaches that TLS extensions are part of the first handshake packet, specifically the ClientHello, and claim 30 identifies the initiator packet as a Client Hello packet of a TLS handshake with the enrichment information in the configured extension. The uploaded patent's Fig. 2A visually shows CLIENT HELLO 201 → EXTENSION 202 → ENRICHMENT INFORMATION 203.).
It would have been obvious to one of ordinary skill in the art before the effective filing date to employ Fandrini's TLS-extension enrichment technique in the modified Tandon system to make the MNO managed IP information available during the secure HTTPS authentication transaction while preserving end-to-end HTTPS protection, thereby permitting Tandon's subscriber identification lookup to be performed without reverting to unsecured HTTP header enrichment.
As per claim 12, Tandon in view of Yau, Dinan, Bao, and Fandrini 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 Yau, Dinan, Bao, and Fandrini teaches the independent claim 1. Tandon teaches storing, by the authentication module, the first MSISDN number, wherein the stored MSISDN number remains within the MNO core network during each subsequent operation of the method (Tandon expressly uses databases and memory for subscriber authentication data and retains the Merchant-supplied MSISDN for the pending comparison).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20190052482 A1- A method and a system used by a terminal to connect to a virtual private network (VPN), and a related device to resolve a problem that workload is heavy and an error is easy to occur currently during configuration of an Internet Protocol (IP) address of a VPN gateway for a termina
US 20090132704 A1-A computer implemented method for monitoring a transaction that crosses an enterprise boundary in a composite application includes a provider enterprise of the transaction receiving a request to provide monitoring data regarding the transaction to a requester enterprise of the transaction. The received request includes a correlation token identifying the monitoring data to be provided and the requester enterprise as being authorized to receive the monitoring data
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 LYDIA L NOEL whose telephone number is (571)272-1628. The examiner can normally be reached Odd Weeks-Monday: 8:00 AM 4:00 PM, Tuesday & Wednesday: 9:00 AM 3:00 PM. Even Weeks-Monday: 8:00 AM 4:00 PM, Tuesday through Thursday: 9:00 AM 1:00 PM.
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 at (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
/ALI S ABYANEH/Primary Examiner, Art Unit 2437
Prosecution Insights