DETAILED ACTION
Claims 1-16 are presented on 11/12/2024 for examination on merits. Claims 1, 15, and 16 are independent base claims.
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 .
Examiner's Instructions for filing Response to this Office Action
When the Applicant submits amendments regarding to the claims in response the Office Action, the Examiner would appreciate Applicant if a clean copy of the claims is provided to facilitate the prosecution which otherwise requires extra time for editing the marked-up claims from OCR.
Please submit two sets of claims:
Set #1 as in a typical filing which includes indicators for the status of claim and all marked amendments to the claims; and
Set #2 as an appendix to the Arguments/Remarks for a clean version of the claims which has all the markups removed for entry by the Examiner.
Claim Objections
Claims 1, 2, and 8 are objected to because of the following informalities:
Claim 1 recites “where the unencrypted hostname refers to an Encrypted Client Hello (ECH) client-facing server and the encrypted hostname refers to an origin content server” deficiently. Should it have been “where the unencrypted hostname refers to an Encrypted Client Hello (ECH) client-facing server hostname and the encrypted hostname refers to an origin content server hostname?”
Claim 2 recites “where the unencrypted hostname refers to the ECH client-facing server” deficiently. As discussed in claim 1 above, should it be “where the unencrypted hostname refers to the ECH client-facing server hostname?” It is noted that claim 15 recites “an ECH client-facing server hostname.”
Claim 8 recites “where the unencrypted hostname refers to the origin content server” deficiently. For the same reason as discussed in claim 1 above, should it be “where the unencrypted hostname refers to the origin content server hostname?” It is noted that claim 7 uses “the origin server hostname.”
Appropriate correction is required.
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.
Claims 1-15 are 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 pre-AIA the applicant regards as the invention.
The rejection(s) under 35 U.S.C. 112(b) is/are determined by the following reasons:
Claim 1 recites two instances of “an ECH client-facing server” unclearly, the first one in the intercepting step (as “an Encrypted Client Hello (ECH) client-facing server”) and the second in the categorizing step before the matching clause.
Claim 13 recites “cause the interface to receive the category database from a security server” unclearly. It is known that an interface (such as a web browser, mobile app, or API client) typically receives data from a server, most commonly in JSON or XML format, usually including application content (text, images, user profiles) as well as updated configuration data. However, it is unusual and mostly impossible for an interface to receive a database from a security server due to the fact that security servers prevent transfer a database with its structure, and normally prevent direct data dumping of data used for authentication, certificate management, or encryption key management. As such, the scope of the claim is unclear.
Claim 15 recites two instances of “an ECH client-facing server hostname” unclearly, the first one in the “cause an interface” clause (as “an Encrypted Client Hello (ECH) client-facing server hostname”) and the second in the “trigger, in response to” clause.
Claims 2-14 are also rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, because they depend from the rejected base claim 1.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
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.
Claims 1-9, 13, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Savin (US 20230328102 A1) in view of Zhou (CN 117834253 A -Machine Translation), and further in view of Dröse (US 20200267190 A1).
As per claim 1, Savin teaches a proxy (par. 0033: the URL checker service and par. 0062: the service cloud) comprising:
an interface (Savin, par. 0059: the interface with transmitter and receiver) configured to:
intercept, from a client, an initial Transport Layer Security (TLS) client message comprised of metadata that includes an unencrypted hostname and encrypted hostname (Savin par. 0029-0031: the TLS session establishment; the client sends a Client Hello message, which is transmitted unencrypted because the client and the server do not have a shared secret yet), where the unencrypted hostname refers to an Encrypted Client Hello (ECH) client-facing server and the encrypted hostname refers to an origin content server (Savin par. 0033-0034: the TLS Client Hello data with the ECH TLS extension is an ECH message. Savin discloses that, the TLS Client Hello data is split in two parts: an outer (plain text) part and an inner (encrypted) part. The SNI or Server name indication is stored in the encrypted part and it is not extractable; determining the SNI(s) and passing them to the URL checker service for calculating a final web reputation for the request. The URL checker service provides the interface, where the TLS client message is intercepted; par. 0033-0034); and
a processor configured to:
categorize the unencrypted hostname as an ECH client-facing server by matching a specific category in a category database or by matching a hostname in a simple list of ECH client-facing servers (Savin par. 0038-0040 and 0056: extracts a set of all known hostnames matching the received IP address from a database of hostname; matching the hostname; see par. 0030: the domain hostname can be observed in plain text in the Client Hello message, the name of a website being visited can be extracted; par. 0039-0040 and 0056-0058),
However, Savin does not explicitly disclose uploading an initial TLS client message to the server in response to the matching or the unencrypted hostname being categorized. This aspect of the claim is identified as a further difference.
In a related art, Zhou teaches:
matching the hostname and categorizing the unencrypted hostname (Zhou, at the last paragraph of page 8/15 and the first paragraph of 8/16: specify a specific client process, a remote address and/or a remote port. and when the stream data is out of the station, judging whether the data stream is the client hand-hold message of the TLS. if so, uploading the stream data to the intermediary service process; at the last paragraph of page 7/15 and the first and second paragraphs of 8/15 after the new network session is detected to be established, the data filtering module of the client kernel layer will match the new network session with the preset filtering rule. if the matching is successful, monitoring the session data of the new network session. In one example, the pre-set filtering rule may be specified by an intermediary person module (TLS session manager), which may specify the pre-set filtering rule and initiate the kernel layer data filtering module. The preset filtering rule may include local/remote IP address or port, name or classification of the client application, SNI (Server Name Indication) information in the TLS request. In this way, the support to the client process condition in the pre-set filtering rule can determine the TLS flow of the processes to be analyzed in addition to the connection of the addresses and ports to be analyzed.
Savin and Zhou are analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify Savin’s system with Zhou’s teachings of filtering the client hello and judging whether the data stream is the client hand-hold message of the TLS for categorization. For this combination, the motivation would have been to improve the level of communications with techniques of message filtering and classification.
However, Savin and Zhou as combined above do not explicitly disclose a fallback connection that allows the client continues to upload an initial TLS client message. This aspect of the claim is identified as a further difference.
In a related art, Dröse teaches:
trigger, in response to the unencrypted hostname being categorized as the ECH client-facing server, the client to upload an initial TLS client message on a fallback connection to the interface, wherein the fallback connection transmits an origin [server hostname in unencrypted form]/[message] (Dröse, par. 0068-0070 and 0087: UDP Relay Connection. The TLS over TCP connection is treated as a fallback for clients behind restrictive firewall devices; The RTC client 165 will try to establish the TCP streaming connection when the UDP probing timeout occurs. When the client SDK 175 detects a lost connection, it will automatically try to recover by reestablishing a connection. Note that Drose’s authentication response from the streamer 106 is similar to response to the categorization of unencrypted hostname. See also par. 0055-0058: the TCP protocol offers a reliability of the data delivery; Authentication response (server to client): in response to the authentication request, when successful, the RTC client 165 fails to communicate using the default ports, it will proceed and attempt to establish the connection using the TCP fallback; see par. 0068-0070. Note that Drose discloses a condition similar to when the unencrypted hostname is categorized as the ECH client-facing server, the connection is no longer available via the proxy. As such, the fallback connection is triggered).
Dröse is analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify the Savin-Zhou system with Drose’s teachings of fallback connection for continuing on transmitting the initial message. For this combination, the motivation would have been to improve the level of communications with a fallback connection.
As per claim 2, the references as combined above teach the proxy according to claim 1, wherein the processor is configured to extract, in response to the interface intercepting the initial TLS client message, the unencrypted hostname from metadata in the initial TLS client message, where the unencrypted hostname refers to the ECH client-facing server (Savin, the Abstract and par. 0039-0040: the computing device extracts a set of all known hostnames. Note that the listing inside the Client Hello Message (CHM) is equivalently the metadata. Savin discloses the CHM as well as the name of a website being visited can be extracted and checked for the website reputation via a uniform resource locator (URL) reputation checker for example. Also note that the Client Hello data is encrypted; par. 0030-0031).
As per claim 3, the references as combined above teach the proxy according to claim 2, wherein the processor is configured to cause, in response to the hostname in the initial TLS client message being categorized as an ECH client-facing server hostname, the interface to upload an upstream TLS handshake message to the ECH client-facing server identified by the hostname (Zhou, page 8 of 15, the last paragraph: uploading the stream data to the intermediary service process of the user layer through the IO queue. Next, the intermediary service uses the open SSL library to create two TLS session managers for the TLS session, completing the handshake and application data forwarding).
As per claim 4, the references as combined above teach the proxy according to claim 3, wherein the ECH client-facing server comprises a server that supports an ECH extension to a TLS protocol (Savin, par. 0027-0028 and 0031: an encrypted client hello (ECH) extension is supported; the TLS protocol that is used; the addition of an encrypted client hello (ECH) extension to transport layer security (TLS) standard is known to break certain network security features such as safe browsing and advanced content control features. The embodiments of the invention provide technological solution to solving the ECH problem).
As per claim 5, the references as combined above teach the proxy according to claim 3, wherein the processor is configured to cause, in response to the interface receiving a downstream TLS handshake message from the ECH client-facing server, the interface to download the downstream TLS handshake message to the client (Zhou, page 8 of 15, the last paragraph: the data stream is the client hand-hold message of the TLS; judging whether the data stream is the client hand-hold message of the TLS. if so, uploading or downloading the [TLS] stream data to the intermediary service process of the user layer through the IO queue [of] the interface; see the use of interface functions at last paragraph of page 1/15 and first paragraph at page 2/15).
As per claim 6, the references as combined above teach the proxy according to claim 5, wherein metadata in the downstream TLS handshake message comprises one or more cryptographic parameters that acts as notification to the client of an unsuccessful attempt to use ECH (Savin, par. 0039-0040: the computing device extracts a set of all known hostnames, wherein the listing inside the Client Hello Message of via TLS (i.e., the ECH TLS extension) is functionally the metadata; Savin discloses supporting a different set of parameters, including one or more cryptographic parameters, such as keys, ciphers. The parameters are used for connecting directly to HTTP3/QUIC alternative endpoints, provide HTTP Strict Transport Security (HSTS)-like indication. As such, using the parameters as notification to the client of an unsuccessful attempt to use ECH is the intended use).
As per claim 7, the references as combined above teach the proxy according to claim 6, wherein the processor is configured to cause the client to upload the initial TLS client message, with the origin server hostname in unencrypted form, on the fallback connection (Zhou, page 8 of 15, the last paragraph: specify a specific client process … to upload the initial TLS client message. Zhou discloses judging whether the data stream is the client hand-hold message of the TLS. if so, uploading the stream data to the intermediary service process). Drose discloses such a upload may be made over a fallback connection to ensure the best quality when possible (par. 0065-0066).
As per claim 8, the references as combined above teach the proxy according to claim 1, wherein the processor is configured to extract, in response to the interface intercepting the initial TLS client message on the fallback connection, the unencrypted hostname from metadata in the initial TLS client message, where the unencrypted hostname refers to the origin content server. (Drose discloses such a upload may be made over a fallback connection to ensure the best quality when possible; par. 0065-0066).
As per claim 9, the references as combined above teach the proxy according to claim 8, wherein the processor is configured to cause, in response to the hostname in the initial TLS client message not being categorized as an ECH client-facing server hostname, the interface to upload an upstream TLS handshake message to the origin content server identified by the hostname (Savin, par. 0048-0054: extracting data from a TLS session handshake related to the TLS connection request with the hostname-to-Internet Protocol (IP) address pairs in the database, filtering out all known hostnames that have alias (CNAME and HTTPS target) counts higher than a predetermined threshold value (e.g., 1-3); par. 0070-0071: an URL-checking entity 420 and a reputation calculation for an updated connection that requires uploading an upstream TLS handshake message).
As per claim 13, the references as combined above teach the proxy according to claim 1, wherein the processor is configured to cause the interface to receive the category database from a security server (Savin, the service cloud 130 as shown in FIGS. 1 and 4 is a security server; par. 0062-0063: The ECH resolver service, including the ECH resolver 430, may reside in the local network, in the service cloud or elsewhere in the network, effectively receiving data from category data from the server, and it comprises at least an entity for determining the hostnames behind IP addresses received 436, a reducer and prioritizer engines 434 and at least an access to data sources 432.).
As per claim 15, Savin teaches a non-transitory computer-readable medium configured to retain machine-readable instructions that, when executed by a processor, cause the processor to:
cause an interface configured to intercept, from a client, an initial Transport Layer Security (TLS) client message having an Encrypted Client Hello (ECH) client-facing server hostname in unencrypted form and an origin server hostname in encrypted form (Savin, par. 0059: the interface with transmitter and receiver; par. 0029-0031: the TLS session establishment; the client sends a Client Hello message, which is transmitted unencrypted because the client and the server do not have a shared secret yet; par. 0033-0034: the TLS Client Hello data with the ECH TLS extension is an ECH message. Savin discloses that, the TLS Client Hello data is split in two parts: an outer (plain text) part and an inner (encrypted) part. The SNI or Server name indication is stored in the encrypted part and it is not extractable; determining the SNI(s) and passing them to the URL checker service for calculating a final web reputation for the request. The URL checker service provides the interface, where the TLS client message is intercepted; par. 0033-0034); and
categorize a hostname as an ECH client-facing server by matching a specific category in a category database or by matching the hostname in a simple list of ECH client-facing servers (Savin par. 0038-0040 and 0056: extracts a set of all known hostnames matching the received IP address from a database of hostname; matching the hostname; par. 0039-0040 and 0056-0058), and
However, Savin does not explicitly disclose uploading an initial TLS client message to the server in response to the matching or the unencrypted hostname being categorized. This aspect of the claim is identified as a further difference.
In a related art, Zhou teaches:
matching the hostname and categorizing the unencrypted hostname (Zhou, at the last paragraph of page 8/15 and the first paragraph of 8/16: specify a specific client process, a remote address and/or a remote port. and when the stream data is out of the station, judging whether the data stream is the client hand-hold message of the TLS. if so, uploading the stream data to the intermediary service process; at the last paragraph of page 7/15 and the first and second paragraphs of 8/15 after the new network session is detected to be established, the data filtering module of the client kernel layer will match the new network session with the preset filtering rule. if the matching is successful, monitoring the session data of the new network session. In one example, the pre-set filtering rule may be specified by an intermediary person module (TLS session manager), which may specify the pre-set filtering rule and initiate the kernel layer data filtering module. The preset filtering rule may include local/remote IP address or port, name or classification of the client application, SNI (Server Name Indication) information in the TLS request. In this way, the support to the client process condition in the pre-set filtering rule can determine the TLS flow of the processes to be analyzed in addition to the connection of the addresses and ports to be analyzed.
Savin and Zhou are analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify Savin’s system with Zhou’s teachings of filtering the client hello and judging whether the data stream is the client hand-hold message of the TLS for categorization. For this combination, the motivation would have been to improve the level of communications with techniques of message filtering and classification.
trigger, in response to an ECH client-facing server hostname being categorized as the ECH client-facing server, the client to upload an initial TLS client message on a fallback connection to the interface, wherein the fallback connection transmits the origin server hostname in unencrypted form (Dröse par. 0055-0058: the TCP protocol offers a reliability of the data delivery; Authentication response (server to client): in response to the authentication request, when successful, the RTC client 165 fails to communicate using the default ports, it will proceed and attempt to establish the connection using the TCP fallback; see par. 0068-0070. Note that Drose discloses a condition similar to when the unencrypted hostname is categorized as the ECH client-facing server, the connection is no longer available via the proxy. As such, the fallback connection is triggered).
Dröse is analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify the Savin-Zhou system with Drose’s teachings of fallback connection for continuing on transmitting the initial message. For this combination, the motivation would have been to improve the level of communications with a fallback connection.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Savin, Zhou, and Dröse, as applied to claim 1, and further in view of Yagi (US 20160381052 A1).
As per claim 16, Savin teaches a system comprising:
a proxy (Savin, par. 0033: the URL checker service and par. 0062: the service cloud) configured to:
cause an interface to access, in response to uploading a request for the category database, the category database from the security server (Savin, par. 0059: the interface with transmitter and receiver; par. 0029-0031: the TLS session establishment; the client sends a Client Hello message),
cause the interface to intercept, from a client, an initial TLS client message having an ECH client-facing server hostname in unencrypted form (Savin, par. 0030-0032: plain text in the Client Hello message; the client sends a Client Hello message, which is transmitted unencrypted because the client and the server do not have a shared secret yet. Since the domain can be observed in plain text in the Client Hello message),
categorize a hostname as an ECH client-facing server by matching a specific category in the category database or by matching the hostname in a simple list of ECH client-facing servers (Savin par. 0038-0040 and 0056: extracts a set of all known hostnames matching the received IP address from a database of hostname; matching the hostname; par. 0039-0040 and 0056-0058).
However, Savin does not explicitly disclose uploading an initial TLS client message to the server in response to the matching or the unencrypted hostname being categorized. This aspect of the claim is identified as a further difference.
In a related art, Zhou teaches:
matching the hostname and categorizing the unencrypted hostname (Zhou, at the last paragraph of page 8/15 and the first paragraph of 8/16: specify a specific client process, a remote address and/or a remote port. and when the stream data is out of the station, judging whether the data stream is the client hand-hold message of the TLS. if so, uploading the stream data to the intermediary service process; at the last paragraph of page 7/15 and the first and second paragraphs of 8/15 after the new network session is detected to be established, the data filtering module of the client kernel layer will match the new network session with the preset filtering rule. if the matching is successful, monitoring the session data of the new network session. In one example, the pre-set filtering rule may be specified by an intermediary person module (TLS session manager), which may specify the pre-set filtering rule and initiate the kernel layer data filtering module. The preset filtering rule may include local/remote IP address or port, name or classification of the client application, SNI (Server Name Indication) information in the TLS request. In this way, the support to the client process condition in the pre-set filtering rule can determine the TLS flow of the processes to be analyzed in addition to the connection of the addresses and ports to be analyzed.
Savin and Zhou are analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify Savin’s system with Zhou’s teachings of filtering the client hello and judging whether the data stream is the client hand-hold message of the TLS for categorization. For this combination, the motivation would have been to improve the level of communications with techniques of message filtering and classification.
However, Savin and Zhou as combined above do not explicitly disclose a fallback connection that allows the client continues to upload an initial TLS client message. This aspect of the claim is identified as a further difference.
In a related art, Dröse teaches:
trigger, in response to the ECH client-facing server hostname being categorized as the ECH client-facing server, the client to upload the initial TLS client message on a fallback connection to the interface, wherein the fallback connection transmits an origin server hostname in unencrypted form (Dröse par. 0055-0058: the TCP protocol offers a reliability of the data delivery; Authentication response (server to client): in response to the authentication request, when successful, the RTC client 165 fails to communicate using the default ports, it will proceed and attempt to establish the connection using the TCP fallback; see par. 0068-0070. Note that Drose discloses a condition similar to when the unencrypted hostname is categorized as the ECH client-facing server, the connection is no longer available via the proxy. As such, the fallback connection is triggered).
Dröse is analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify the Savin-Zhou system with Drose’s teachings of fallback connection for continuing on transmitting the initial message. For this combination, the motivation would have been to improve the level of communications with a fallback connection.
However, the combination above does not explicitly disclose generating a category database that categorizes the traffic on the Internet. This aspect of the claim is identified as a further difference.
In a related art, Yagi teaches:
a security server configured to: generate, in response to analyzing traffic on the Internet, a category database that categorizes the traffic on the Internet (Yagi, par. 0047-0048: The information collection distribution server 30 extracts predetermined numbers of URLs from respective URL groups identified by analyzing the traffic log by techniques in different categories, and generates a URL list, which is broadly interpreted as the category database; see par. 0048-0051 and 0116 for evaluating the generated URL list in different categories).
Dröse is analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify the Savin-Zhou-Drose system with Yagi’s teachings of using a category database generated for categorizing the traffic on the Internet. For this combination, the motivation would have been to improve the organization of information collection that facilitate the TLS communications.
Claim 10 are rejected under 35 U.S.C. 103 as being unpatentable over Savin, Zhou and Drose, as applied to claim 1, and further in view of Craciun (US 11552925 B1; hereinafter “Craci”).
As per claim 10, the references of Savin, Zhou and Drose as combined above teach the proxy according to claim 9, but do not explicitly disclose using policy rules to ascertain compliance of access to an origin server. This aspect of the claim is identified as a further difference.
In a related art, Craci teaches:
wherein the processor is configured to use policy rules to ascertain compliance of access to an origin server (Craci, col. 2, lines 7-14: The DNS proxy is further configured to transmit a query tracer associating the session identifier with the client identifier to a security server configured to determine an access indicator according to the query tracer, the access indicator indicating whether an access policy selected according to the client identifier allows access; see also col. 19, lines 33-45).
Craci is analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify the Savin-Zhou-Drose system with Craci’s teachings of using an access policy for security compliance. For this combination, the motivation would have been to improve the level of security.
Claims 11-12 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Savin, Zhou and Drose, as applied to claim 1, in view of Craciun (US 11552925 B1; hereinafter “Craci”), as applied to claim 10, and further in view of Harrison (US 20220239960 A1).
As per claim 11, the references of Savin, Zhou, Drose, and Craci as combined above teach the proxy according to claim 10, but none of the references explicitly discloses the interface to allow communications between the client and the origin server. This aspect of the claim is identified as a further difference.
In a related art, Harrison teaches:
wherein the processor is configured to cause, in response to determining access to the origin server as policy compliant, the interface to allow communications between the client and the origin server (Harrison, par. 0032 and 0048-0050: the proxy server 104 … provides a communications interface for the client devices 102 to access the origin servers 110 via the data network 108 which may be, for example, the Internet or an intranet).
Harrison is analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify the Savin-Zhou-Drose-Craci system with Harrison’s teachings of an interface provided to allow communications between the client and the origin server. For this combination, the motivation would have been to improve the level of communications.
As per claim 12, the references of references of Savin, Zhou, Drose, and Craci as combined above teach the proxy according to claim 10, but do not explicitly disclose a interface to download an advisory to the client without allowing communications between the client and the origin server. This aspect of the claim is identified as a further difference.
In a related art, Harrison teaches:
wherein the processor is configured to cause, in response to determining access to the origin server as policy non-compliant, the interface to download an advisory to the client without allowing communications between the client and the origin server (Harrison, par. 0040-0043: the data download session is carried over a split TCP connection 204a, 204b between the client device 102 and the origin server 110. The split TCP connection causes the interface to download an advisory to the client without allowing communications between the client and the origin server).
Harrison is analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify the Savin-Zhou-Drose-Craci system with Harrison’s teachings of using a split TCP connection for downloading between the client and the origin server. For this combination, the motivation would have been to improve the security of communications.
As per claim 14, the references of Savin, Zhou, Drose, and Craci as combined above teach the proxy according to claim 12, Zhou also teaches:
wherein the processor is configured to cause the interface to upload, to a security server, a query that requests the security server to download the category database (Zhou, at the last paragraph of page 8/15 and the first paragraph of 8/16: specify a specific client process, , judging whether the data stream is the client hand-hold message of the TLS. if so, uploading the stream data to the intermediary service process; which includes the client hello as a query to request to download the data).
Zhou is combined with the references of Savin, Drose, and Craci using a similar rationale and motivation.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure as the prior art additionally discloses certain parts of the claim features (See “PTO-892 Notice of Reference Cited”).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DON ZHAO whose telephone number is (571)272.9953. The examiner can normally be reached on Monday to Friday, 7:30 A.M to 5:00 P.M EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Carl G Colin can be reached on 571.272.3862. The fax phone number for the organization where this application or proceeding is assigned is 571.273.8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866.217.9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800.786.9199 (IN USA OR CANADA) or 571.272.1000.
/Don G Zhao/Primary Examiner, Art Unit 2493 02/20/2026