DETAILED ACTION
This action is in response to communication filed on 12/11/2025.
Claims 1-13 are pending.
Claim 14, 19-21 have been cancelled.
Claims 15-18 have been withdrawn.
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 .
Election/Restrictions
Applicant’s election of Group 1 (claims 1-13) without traverse is acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 3/26/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-13 are rejected under 35 U.S.C. 103 as being unpatentable over Wyatt et al. (US 2017/0346853) in view of Huang et al. (US 2011/0117905).
Regarding claim 1, Wyatt discloses a method performed by a client application, comprising:
obtaining one or more configuration parameters for establishing a Transport Layer Security, TLS, session between the client application and a trusted server application, the one or more configuration parameters comprising either: a certificate of the trusted server application, a hash of the certificate of the trusted server application, or a Pre-Shared Key, PSK (Wyatt discloses obtaining configuration parameter, including pinning information such as hashes of certificates or public keys, for establishing TLS sessions. The client application (AMD) has prior knowledge of pinning information (hashes) for trusted servers, obtained from policies or trusted stores; see [0072] “AMD 304 may periodically perform active MITM detection methods without triggering by a network change event. Certificate or key pinning is a well-known method in which an application has prior knowledge of pinning information, i.e., the certificates, or the certificate chain information, or the public key information contained in such certificates, that are considered allowable for connection to a particular destination host”);
performing a TLS handshake procedure with a server application, wherein either: during the TLS handshake procedure the client application receives a certificate from the server application, or the TLS handshake procedure is performed with PSK authentication based on the PSK comprised in the one or more configuration parameters (Wyatt discloses performing a TLS handshake where the client receives the server’s certificate and chain during the handshake for verification; [0188] “During the TLS handshake protocol a certificate or certificate chain for a destination host are sent from the destination host to CSP 310”);
determining that an error has occurred based on either: a comparison of either: (i) the certificate of the trusted server application comprised in the one or more configuration parameters and the certificate received from the server application during the TLS handshake or (ii) the hash of the certificate of the trusted server application and a computed hash of the certificate received from the server application during the TLS handshake; or failed PSK authentication (Wyatt discloses determining errors based on hash or certificate comparisons during the TLS handshake. The client computes and compares hashes (e.g., SHA256, or SPKI hashes) of received certificates against pinned/expected values; see [0072] “If an application makes a network connection to a particular destination host and the received certificates or certificate chain information do not match the pinning information, the pinned network connection is said to fail”).
The prior art does not explicitly disclose responsive to determining that the error has occurred, performing one or more actions that directly or indirectly trigger reinitialization of the one or more configuration parameters.
Huang in the field of the same endeavor discloses techniques for LTE RRC connection re-establishment in a cellular network, where upon detecting an error (e.g., radio resource failure, bottom layer error), the terminal initiates a re-establishment request with a cause value, triggering reinitialization of configuration of parameters. In particular, Huang teaches the following:
responsive to determining that the error has occurred, performing one or more actions that directly or indirectly trigger reinitialization of the one or more configuration parameters (Huang discloses that upon determining a failure/error, the LTE terminal performs actions (initiating RRC connection re-establishment request) that trigger reinitialization of the configuration parameters in the cellular network; see [0056] “the LTE terminal initiates the RRC connection re-establishment request to a network side, wherein the RRC connection re-establishment request includes a failure cause value indicating the failure reason”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Huang to incorporate techniques for LTE RRC connection re-establishment in a cellular network. One of ordinary skill would have been motivated to combine the prior art to explicitly incorporate a standardized re-establishment request mechanism upon detecting connection errors, thereby enhancing the reliability and recovery process for secure TLS sessions in cellular network by triggering reinitialization of configuration parameters in a predictable manner.
Regarding claim 2, Wyatt-Huang discloses the method of claim 1 wherein:
the one or more configuration parameters comprise the hash of the certificate of the trusted server application (Wyatt [0213] “a policy may additionally specify pinning information for certificates for a particular DESTHOST, where pinning information is information that can be used to verify that a particular certificate, or a public key contained in a certificate, is present for communications to that particular DESTHOST. Pinning information may be collected by CSPs on computing devices: by observing actual certificates in use for a DESTHOST; or by observing HPKP directives in HTTP headers sent from a DESTHOST (HPKP is the Request for Comments (RFC) 7469, Public Key Pinning Extension for HTTP)”);
the method further comprises computing a hash of the certificate received from the server application during the TLS handshake (Wyatt [0210] “a CSP (operating in any of modes (1), (2), or (3)) observes the server certificate chain information that is part of a TLS handshake protocol for a DESTHOST. The CSP may determine, according to a policy 318 having a common use certificate checking qualifier, whether the certificate chain used matches one of the certificates used in an historical store of certificate information by DESTHOST, or matches certificate information for DESTHOST obtained by the CSP requesting current certificate information for DESTHOST from security server 320”); and
determining that the error has occurred comprises:
comparing the hash of the certificate of the trusted server application comprised in the one or more configuration parameters and the hash of the received certificate (Wyatt [0210] “…whether the certificate chain used matches one of the certificates used in an historical store of certificate information by DESTHOST… If the certificate chain information matches, the CSP allows the network connection to continue… If the certificate does not succeed, the CSP warns the user, or sends a notice to security server 320… or breaks the network connection…” and [0213] “…pinning information is information that can be used to verify that a particular certificate, or a public key contained in a certificate, is present for communications to that particular DESTHOST”); and
determining that there is an error based on a result of comparing the hash of the certificate of the trusted server application comprised in the one or more configuration parameters and the hash of the received certificate (Wyatt [0215] “In any of the above embodiments for policy based detection of a certificate being used where the certificate does not match a commonly used certificate or a certificate allowed by policy, such a detection is considered another form of MITM detection, and one or more of the previously responses to MITM detection are taken” and [0188] “SP 310 may inspect the certificates for anomalies (such as invalid values in certificate fields, or expired certificates) and may interrogate locally cached or remote certificate revocation list information. In an embodiment, anomalies in certificates may be reported to security server 320, and CSP 310 may display a warning on computing device 200, or break the network connection, or a combination thereof”).
Regarding claim 3, Wyatt-Huang discloses the method of claim 2 wherein the one or more configuration parameters comprise an Internet Protocol, IP, address associated to the trusted server application, an indication of a security protocol type, and a TLS for Authentication record, TLSA, that contains the hash of the certificate of the trusted server application (Wyatt [0037] “These communication protocols may include TCP/IP, UDP, HTTP protocols, wireless application protocol (WAP), BLUETOOTH, Zigbee, 802.11, 802.15, 6LoWPAN, LiFi, Google Weave, NFC, GSM, CDMA, other cellular data communication protocols, wireless telephony protocols, Internet telephony, IP telephony, digital voice, voice over broadband (VoBB), broadband telephony, Voice over IP (VoIP), vendor-specific protocols, customized protocols, and others”).
Regarding claim 4, Wyatt-Huang discloses the method of claim 3 wherein the one or more configuration parameters further comprise a port number (Wyatt [0223] “Whether and HTTPS or a TLS connection is being requested may be known initially by the requested port (e.g., port 443 is conventionally used for HTTPS while port 80 is used for HTTP, port 995 is conventionally used to make a secure POPS connection, while port 110 is used for non-encrypted POPS connections, and similarly for various other protocols), or by a known history of network connection behavior for a given CAPP. In an embodiment, security server 320 has stored information about which destination hosts a given CAPP connects to, and characteristics of how the CAPP connects, including which port(s), which protocol(s), and whether communications are encrypted or not”).
Regarding claim 5, Wyatt-Huang discloses the method of claim 3 wherein the one or more configuration parameters further comprise an authentication domain name (Wyatt discloses configuration parameters for TLS sessions that include a hostname (i.e., an authentication domain name) associated with certificates used in establishing secure connections. Specifically, Wyatt describes how certificates in TLS configuration are tied to host names, which serve as domain names for authentication purposes in SSL/TLS nomenclature. This hostname is part of the configuration for verifying and establishing TLS connections, as it identifies the host for certificate association during the handshake; see [0011] “SSL intercept is a process to decipher and inspect the content of data being transmitted via Secure Sockets Layer (SSL) or Transport Layer Security (TLS), and is possible because certificates can be created that are associated with a particular hostname, or common name, in SSL nomenclature”).
Regarding claim 6, Wyatt-Huang discloses the method of claim 1 further comprising, responsive to determining that the error has occurred, aborting setup of the TLS session (Wyatt [0188] “anomalies in certificates may be reported to security server 320, and CSP 310 may display a warning on computing device 200, or break the network connection, or a combination thereof”).
Regarding claim 7, Wyatt-Huang discloses the method of claim 1 wherein performing one or more actions that directly or indirectly trigger reinitialization of the one or more configuration parameters comprises reporting a TLS error to a network node (Wyatt discloses a context security proxy (CSP) on a computing device that inspects TLS certificate during the TLS handshake protocol for anomalies (e.g., invalid value or expired certficates), which constitutes detection of a TLS error. Upon detection, the CSP reports these anomalies to a security server (a network node). This reporting can lead to breaking the network connection or other respondes, which indirectly triggers reinitialization by necessitating a reset of the TLS session parameters (e.g., re-performing the handshake with fresh configuration to attempt reconnection); see [0188] “During the TLS handshake protocol a certificate or certificate chain for a destination host are sent from the destination host to CSP 310. In an embodiment, CSP 310 may inspect the certificates for anomalies (such as invalid values in certificate fields, or expired certificates) and may interrogate locally cached or remote certificate revocation list information. In an embodiment, anomalies in certificates may be reported to security server 320, and CSP 310 may display a warning on computing device 200, or break the network connection, or a combination thereof”).
Regarding claim 8, Wyatt-Huang discloses the method of claim 7 further comprising, responsive to reporting a TLS error to a network node (Huang [0028] “Step S01, in the case that the security has been activated, in order to keep the RRC connection, the UE at the state of connection (RRC_CONNECTED) sends an RRC connection re-establishment request message (RRCConnectionReestablishmentRequest) to the network side”), receiving a message comprising one or more re-initialized configuration parameters for establishing a TLS session between the client application and a trusted server application (Huang [0029-0034] “Step S02, the network side receives the re-establishment request sent from the UE and delivers an RRC connection re-establishment message (RRCConnectionReestablishment). After the UE receives the message, related procedures are as follows: 1. stopping related timers; 2. restoring SRB1 according to the configuration of radio resource; 3. configuring integrality protection used previously for the bottom layer reactivation; and 4. configuring a encryption algorithm used previously for the bottom layer reactivation. Step S03, The UE sends an RRC connection re-establishment complete message is (RRCConnectionReestablishmentComplete) to the network side, then the procedure of RRC connection re-establishment ends”).
Regarding claim 9, Wyatt-Huang discloses the method of claim 1 wherein performing one or more actions that directly or indirectly trigger reinitialization of the one or more configuration parameters (Wyatt discloses performing actions in response to detected anomalies (e.g., in certificates during TLS setup) that trigger changes to network configurations, including switching connections which indirectly reinitializes parameters like certificates or security settings; see [0014] “Responses to detection include one or more of displaying a warning to a user of the computing device, providing an option to disconnect the network connection, blocking the network connection, switching to a different network connection, applying a policy, and sending anomaly information to a security server”)
comprises sending, to a network node, a message for modification of the IP connectivity session (Wyatt discloses sending messages to network nodes (e.g., security servers or access points) in response to anomalies, and switching networks involves sending association or configuration requests to modify connectivity (e.g., to a new Wi-Fi AP or cell station, altering the IP session); see [0196] “When the Wi-Fi security method being used is not allowed by the policy, the CSP takes one or more of the following actions: displays a warning on computing device 200; notifies security server 320 (which in an embodiment displays a warning on an administrator console); presents an option for a user of computing device 200 to select whether to use the network connection or not; prevents the network connection from being made; and switches to a different physical network connection”)
that comprises an indication of a request for re-initialization of the one or more configuration parameters (Wyatt discloses sending anomaly information as an indication that triggers re-initialization (e.g., of certificates or policies); see [0014] “Responses to detection include one or more of displaying a warning to a user of the computing device, providing an option to disconnect the network connection, blocking the network connection, switching to a different network connection, applying a policy, and sending anomaly information to a security server”)
for establishing a TLS session between the client application and a trusted server application (Wyatt discloses that the parameters (e.g., certificates) are for establishing TLS sessions between apps and servers; [0188] “During the TLS handshake protocol a certificate or certificate chain for a destination host are sent from the destination host to CSP 310. In an embodiment, CSP 310 may inspect the certificates for anomalies (such as invalid values in certificate fields, or expired certificates) and may interrogate locally cached or remote certificate revocation list information”).
Regarding claim 10, Wyatt-Huang discloses the method of claim 1 wherein the client application is a Domain Name System, DNS, client, and the server application is a DNS resolver (Wyatt [0205] “policy 318 for Wi-Fi security methods may divine for a given network name (ESSID or SSID), that a particular Wi-Fi security method is used. But this provides only partial protection against an impostor MITM. In an embodiment, policy 318 may specify that one or more active verification probes be performed. For example, on the legitimate “CORP-EXAMPLE” network there are certain internal-only network resources that are visible (e.g., via DNS) or reachable (e.g., via communications on the “CORP-EXAMPLE” network) only visible or reachable on the CORP-EXAMPLE network. An active verification probe is a connection made from an AMD or a CSP to such an internal-only network resource. Policy 318 specifies the type and identifier for the internal-only network resource, together with what the expected response from a probe should be. For example, a probe type could be a DNS TXT (Text Record) query. The expected result in the policy would be the response value expected from the query”).
Regarding claim 11, Wyatt-Huang discloses the method of claim 1 wherein the client application is implemented on a wireless communication device for a cellular communications system (Wyatt [0042] “Some example computing devices include portable electronic devices (e.g., mobile communications devices) such as the Apple iPhone®, the Apple iPad®, the Palm Pre™, or any computing device running the Apple iOS™, Android™ OS, Google Chrome OS, Symbian OS®, Windows 10, Windows Mobile® OS, Palm OS® or Palm Web OS™, or any of various operating systems used for Internet of Things (IoT) devices”), and
obtaining the one or more configuration parameters comprises obtaining the one or more configuration parameters from a network node in a core network of the cellular communications system (Huang [0029-0033] “Step S02, the network side receives the re-establishment request sent from the UE and delivers an RRC connection re-establishment message (RRCConnectionReestablishment). After the UE receives the message, related procedures are as follows: 1. stopping related timers; 2. restoring SRB1 according to the configuration of radio resource; 3. configuring integrality protection used previously for the bottom layer reactivation; and 4. configuring a encryption algorithm used previously for the bottom layer reactivation”).
Regarding claim 12, Wyatt-Huang discloses the method of claim 11 wherein the cellular communication system is either a Fifth Generation System, 5GS, or an Evolved Packet System, EPS (Wyatt [0240] “a smartphone may communicate with a DESTHOST via a BLUETOOTH connection to the IoT hub, which in turn communicates via a cellular data connection (e.g., LTE) with the DESTHOST”).
Regarding claim(s) 13, do(es) not teach or further define over the limitation in claim(s) 1 respectively. Therefore claim(s) 13 is/are rejected for the same rationale of rejection as set forth in claim(s) 1 respectively.
Conclusion
For the reason above, claims 1-13 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
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, Chris Parry can be reached at 571-272-8328. 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.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451