Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This office action is in response to the application filed on 06/11/2025. In which, claims 1-20 are pending and being considered, claims 1, 11 and 17 are independent, claims 1-20 are rejected.
Specification
The use of the term “Bluetooth” and “Wi-Fi” stated on Par. (00065 and 00097), are trade names or a marks used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
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.
Claim(s) 1, 4, 7-8, 10-11, 14, 16-17 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Théberge et al. (U.S Pub. No. 20220294825, hereinafter referred to as “Théberge”) further in view of Lapidous et al. (U.S Pub. No. 20200228505, hereinafter referred to as “Lapidous”)
In regards to Claim 1, Théberge teaches a method comprising: detecting, by a meter, a packet en route between a client device and a server, (Par. (0007, 0018); meter (verifier process) detects (identifies) packet en route between a client device and a server (packet is identified to a destination in a flow between server and client)), (Par. (0018); meter (verifier process that is device))
the packet carrying secure-session-setup signaling to facilitate setup of a secure connection between the client device and the server; (Par. (0015, 0019); the packet carrying secure-session-setup (verification connection and encrypted connection between server and client) to facilitate setup of a secure connection between the client device and the server (verification connection and encrypted connection corresponding to packets between client and server)), (Par. (0019); to facilitate setup of a secure connection between the client device and the server (successful connection between server and client corresponding to packets and IP))
reading, by the meter, from the detected packet, a server Internet Protocol (IP) address of the server and a server name of the server, and (Par. (0019); meter (verifier process) reads from the packet (verifies extracts from packet) a server Internet Protocol (IP) address of the server and a server name (destination IP and server name corresponding to connection between client and server))
establishing by the meter a correlation record that specifies for the client device a correlation of the server IP address with the server name; and (Par. (0019); meter (verifier process) establishing by the meter a correlation record (maintains a repository) that specifies for the client device a correlation of the server IP address with the server name (repository with entries that include server name and IP address associated with server))
thereafter detecting, by the meter, packet-data communication en route between the client device and the server IP address, (Par. (0019, 0024); checking of repository of meter (verifier process) to check if destination Ip address and server name are trusted by comparing and determining successful verification connection between client and server))
wherein the established correlation record serves as a basis to determine that the name of the server is the server name specified by the correlation record, (Par. (0019); the established correlation record (entry in repository) serves as a basis to determine that the name of the server is the server name specified by the correlation record (comparing the server name to repository for verification based on IP address)
thereby facilitating recording the detected packet-data communication as being between the client device and the server having the server name. (Par. (0019, 0024); recording the detected packet-data communication (adding entry with server name and IP address corresponding to packet) as being between the client device and the server having the server name (after comparing server name in entry with repository, determining verification and trust and successful connection established between client and server based on packet and identifying server name is the same))
Théberge does not explicitly teach the detected packet-data communication excluding a plaintext indication of a name of the server with which the client device is communicating at the server IP address,
Wherein Lapidous teaches the detected packet-data communication excluding a plaintext indication of a name of the server with which the client device is communicating at the server IP address, (Par. (0192, 0194-0196, 0198-0199); the detected packet-data communication (data recognized from forwarded packet from client and server communication) excluding a plaintext indication of a name of the server (handshake between client and server excludes or is without data in plaintext)), (Par. (0082); excluding a plaintext indication of a name of the server (handshake with plaintext contains server name)) (Par. (0111 and 0113-0114); with which the client device is communicating at the server IP address, (server with IP address with client or user communicating based on IP address associated with server))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge to incorporate the teaching of Lapidous to utilize the above feature because of the analogous concept of client and server authentication based on transmitted packets and client hello messages, with the motivation of regulate access, increase speeds an observe the privacy and security of users on sensitive sites for banking, medical etc. to protect users activities through secure traffic and improve the transmission and intended destination of data. (Lapidous Par. (0003-0005))
In regards to Claim 4, the combination of Théberge and Lapidous teach the method of claim 1, Théberge further teaches the method of claim 1, further comprising: using, by the meter, the established correlation record as the basis to determine that the name of the server is the server name specified by the correlation record; and (Par. (0019); the established correlation record (entry in repository) serves as a basis to determine that the name of the server is the server name specified by the correlation record (comparing the server name to repository for verification based on IP address))
recording, by the meter, the detected packet-data communication as being between the client device and the server having the server name. (Par. (0019, 0024); recording the detected packet-data communication (adding entry with server name and IP address corresponding to packet) as being between the client device and the server having the server name (after comparing server name in entry with repository, determining verification and trust and successful connection established between client and server based on packet and identifying server name is the same))
In regards to Claim 7, the combination of Théberge and Lapidous teach the method of claim 1, Théberge further teaches the method of claim 1, wherein detecting the packet-data communication en route between the client device and the server IP address comprise (Par. (0007, 0018); meter (verifier process) detects (identifies) packet en route between a client device and a server IP address (packet is identified to a destination in a flow between server with destination IP address and client)), (Par. (0018); meter (verifier process that is device)),
detecting the packet-data communication en route through the secure connection between the client device and the server IP address. (Par. (0019); meter (verifier process) reads from the packet (verifies extracts from packet) a server Internet Protocol (IP) address of the server (destination IP and server name corresponding to connection between client and server) and makes secure connection between client and server based on successful establishing based on IP address)
In regards to Claim 8, the combination of Théberge and Lapidous teach the method of claim 1, Théberge further teaches the method of claim 7, wherein the packet-data communication comprises a Hypertext Transfer Protocol Secure (HTTPS) message. (Par. (0015); packets transmitted through HTTP with HTTP message (payload communicating with server and client through HTTP connection)
In regards to Claim 10, the combination of Théberge and Lapidous teach the method of claim 1, Théberge further teaches the method of claim 1, wherein the meter is internal to the client device, and (Par. (0018); meter (verifier process) is internal to the client device (part of intermediate device and connected), (Figure 1 labels 46, 18; meter (verifier process 46) is internal to client device (verifier 46 connected to client device 18))
wherein detecting the packet and thereafter detecting the packet-data communication both occur internal to the client device. (Par. (0018-0019); identifying packets and interconnected communication between client and server and thereafter detecting the packet is successful or unsuccessful)), (Par. (0015); packets transmitted with established end-to-end connection between client and server with web browser application internal through client))
In regards to Claim 11, Théberge teaches a computing system comprising: Par. (0006); system))
at least one processor; (Par. (0021, 0024); processor))
detecting a packet en route between a client device and a server, (Par. (0007, 0018); meter (verifier process) detects (identifies) packet en route between a client device and a server (packet is identified to a destination in a flow between server and client)), (Par. (0018); meter (verifier process that is device))
the packet carrying secure-session-setup signaling to facilitate setup of a secure connection between the client device and the server, (Par. (0015, 0019); the packet carrying secure-session-setup (verification connection and encrypted connection between server and client) to facilitate setup of a secure connection between the client device and the server (verification connection and encrypted connection corresponding to packets between client and server)), (Par. (0019); to facilitate setup of a secure connection between the client device and the server (successful connection between server and client corresponding to packets and IP))
reading from the detected packet, a server Internet Protocol (IP) address of the server and a server name of the server, and (Par. (0019); meter (verifier process) reads from the packet (verifies extracts from packet) a server Internet Protocol (IP) address of the server and a server name (destination IP and server name corresponding to connection between client and server))
establishing by the meter a correlation record that specifies for the client device a correlation of the server IP address with the server name, and (Par. (0019); meter (verifier process) establishing by the meter a correlation record (maintains a repository) that specifies for the client device a correlation of the server IP address with the server name (repository with entries that include server name and IP address associated with server))
thereafter detecting packet-data communication en route between the client device and the server IP address, (Par. (0019, 0024); checking of repository of meter (verifier process) to check if destination Ip address and server name are trusted by comparing and determining successful verification connection between client and server))
wherein the established correlation record serves as a basis to determine that the name of the server is the server name specified by the correlation record, (Par. (0019); the established correlation record (entry in repository) serves as a basis to determine that the name of the server is the server name specified by the correlation record (comparing the server name to repository for verification based on IP address)
thereby facilitating recording the detected packet-data communication as being between the client device and the server having the server name.. (Par. (0019, 0024); recording the detected packet-data communication (adding entry with server name and IP address corresponding to packet) as being between the client device and the server having the server name (after comparing server name in entry with repository, determining verification and trust and successful connection established between client and server based on packet and identifying server name is the same))
Théberge does not explicitly teach non-transitory data storage; and program instructions stored in the non-transitory data storage and executable by the at least one processor to carry out operations including: the detected packet-data communication excluding a plaintext indication of a name of the server with which the client device is communicating at the server IP address,
Wherein Lapidous teaches non-transitory data storage; and (Par. (0020, 0208); non-transitory medium for storage and storage devices))
program instructions stored in the non-transitory data storage and executable by the at least one processor to carry out operations including: (Par. (0019-0020); computer-readable medium)), (Par. (0208); processor with instructions))
the detected packet-data communication excluding a plaintext indication of a name of the server with which the client device is communicating at the server IP address, (Par. (0192, 0194-0196, 0198-0199); the detected packet-data communication (data recognized from forwarded packet from client and server communication) excluding a plaintext indication of a name of the server (handshake between client and server excludes or is without data in plaintext)), (Par. (0082); excluding a plaintext indication of a name of the server (handshake with plaintext contains server name)) (Par. (0111 and 0113-0114); with which the client device is communicating at the server IP address, (server with IP address with client or user communicating based on IP address associated with server))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge to incorporate the teaching of Lapidous to utilize the above feature because of the analogous concept of client and server authentication based on transmitted packets and client hello messages, with the motivation of regulate access, increase speeds an observe the privacy and security of users on sensitive sites for banking, medical etc. to protect users activities through secure traffic and improve the transmission and intended destination of data. (Lapidous Par. (0003-0005))
In regards to Claim 14, the combination of Théberge and Lapidous teach the system of claim 11, Théberge further teaches the computing system of claim 11, wherein the operations additionally include: using the established correlation record as the basis to determine that the name of the server is the server name specified by the correlation record; and (Par. (0019); the established correlation record (entry in repository) serves as a basis to determine that the name of the server is the server name specified by the correlation record (comparing the server name to repository for verification based on IP address))
recording the detected packet-data communication as being between the client device and the server having the server name. (Par. (0019, 0024); recording the detected packet-data communication (adding entry with server name and IP address corresponding to packet) as being between the client device and the server having the server name (after comparing server name in entry with repository, determining verification and trust and successful connection established between client and server based on packet and identifying server name is the same))
In regards to Claim 16, the combination of Théberge and Lapidous teach the system of claim 11, Théberge further teaches the computing system of claim 11, wherein detecting the packet-data communication en route between the client device and the server IP address comprise (Par. (0007, 0018); meter (verifier process) detects (identifies) packet en route between a client device and a server IP address (packet is identified to a destination in a flow between server with destination IP address and client)), (Par. (0018); meter (verifier process that is device)),
detecting the packet-data communication en route through the secure connection between the client device and the server IP address. (Par. (0019); meter (verifier process) reads from the packet (verifies extracts from packet) a server Internet Protocol (IP) address of the server (destination IP and server name corresponding to connection between client and server) and makes secure connection between client and server based on successful establishing based on IP address)
In regards to Claim 17, Théberge teaches detecting a packet en route between a client device and a server, (Par. (0007, 0018); meter (verifier process) detects (identifies) packet en route between a client device and a server (packet is identified to a destination in a flow between server and client)), (Par. (0018); meter (verifier process that is device))
the packet carrying secure- session-setup signaling to facilitate setup of a secure connection between the client device and the server; (Par. (0015, 0019); the packet carrying secure-session-setup (verification connection and encrypted connection between server and client) to facilitate setup of a secure connection between the client device and the server (verification connection and encrypted connection corresponding to packets between client and server)), (Par. (0019); to facilitate setup of a secure connection between the client device and the server (successful connection between server and client corresponding to packets and IP))
reading from the detected packet, a server Internet Protocol (IP) address of the server and a server name of the server, and (Par. (0019); meter (verifier process) reads from the packet (verifies extracts from packet) a server Internet Protocol (IP) address of the server and a server name (destination IP and server name corresponding to connection between client and server))
establishing by the meter a correlation record that specifies for the client device a correlation of the server IP address with the server name; and (Par. (0019); meter (verifier process) establishing by the meter a correlation record (maintains a repository) that specifies for the client device a correlation of the server IP address with the server name (repository with entries that include server name and IP address associated with server))
thereafter detecting packet-data communication en route between the client device and the server IP address, (Par. (0019, 0024); checking of repository of meter (verifier process) to check if destination Ip address and server name are trusted by comparing and determining successful verification connection between client and server))
wherein the established correlation record serves as a basis to determine that the name of the server is the server name specified by the correlation record, (Par. (0019); the established correlation record (entry in repository) serves as a basis to determine that the name of the server is the server name specified by the correlation record (comparing the server name to repository for verification based on IP address)
thereby facilitating recording the detected packet-data communication as being between the client device and the server having the server name. (Par. (0019, 0024); recording the detected packet-data communication (adding entry with server name and IP address corresponding to packet) as being between the client device and the server having the server name (after comparing server name in entry with repository, determining verification and trust and successful connection established between client and server based on packet and identifying server name is the same))
Théberge does not explicitly teach at least one non-transitory computer-readable medium having stored thereon program instructions executable by at least one processor to carry out operations comprising: the detected packet-data communication excluding a plaintext indication of a name of the server with which the client device is communicating at the server IP address;
Wherein Lapidous teaches at least one non-transitory computer-readable medium having stored thereon program instructions executable by at least one processor to carry out operations comprising: (Par. (0020, 0208); non-transitory medium), (Par. (0019-0020); computer-readable medium)), (Par. (0208); processor with instructions))
the detected packet-data communication excluding a plaintext indication of a name of the server with which the client device is communicating at the server IP address; (Par. (0192, 0194-0196, 0198-0199); the detected packet-data communication (data recognized from forwarded packet from client and server communication) excluding a plaintext indication of a name of the server (handshake between client and server excludes or is without data in plaintext)), (Par. (0082); excluding a plaintext indication of a name of the server (handshake with plaintext contains server name)) (Par. (0111 and 0113-0114); with which the client device is communicating at the server IP address, (server with IP address with client or user communicating based on IP address associated with server))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge to incorporate the teaching of Lapidous to utilize the above feature because of the analogous concept of client and server authentication based on transmitted packets and client hello messages, with the motivation of regulate access, increase speeds an observe the privacy and security of users on sensitive sites for banking, medical etc. to protect users activities through secure traffic and improve the transmission and intended destination of data. (Lapidous Par. (0003-0005))
In regards to Claim 19, the combination of Théberge and Lapidous teach the non-transitory computer-readable medium of claim 17, Théberge further teaches the at least one non-transitory computer-readable medium of claim 17, wherein detecting the packet-data communication en route between the client device and the server IP address comprise (Par. (0007, 0018); meter (verifier process) detects (identifies) packet en route between a client device and a server IP address (packet is identified to a destination in a flow between server with destination IP address and client)), (Par. (0018); meter (verifier process that is device)),
detecting the packet-data communication en route through the secure connection between the client device and the server IP address. (Par. (0019); meter (verifier process) reads from the packet (verifies extracts from packet) a server Internet Protocol (IP) address of the server (destination IP and server name corresponding to connection between client and server) and makes secure connection between client and server based on successful establishing based on IP address)
In regards to Claim 20, the combination of Théberge and Lapidous teach the non-transitory computer-readable medium of claim 17, Théberge further teaches The at least one non-transitory computer-readable medium of claim 17, wherein the operations additionally include: using the established correlation record as the basis to determine that the name of the server is the server name specified by the correlation record; and (Par. (0019); the established correlation record (entry in repository) serves as a basis to determine that the name of the server is the server name specified by the correlation record (comparing the server name to repository for verification based on IP address))
recording the detected packet-data communication as being between the client device and the server having the server name. (Par. (0019, 0024); recording the detected packet-data communication (adding entry with server name and IP address corresponding to packet) as being between the client device and the server having the server name (after comparing server name in entry with repository, determining verification and trust and successful connection established between client and server based on packet and identifying server name is the same))
Claim(s) 2 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Théberge et al. (U.S Pub. No. 20220294825, hereinafter referred to as “Théberge”) and Lapidous et al. (U.S Pub. No. 20200228505, hereinafter referred to as “Lapidous”) further in view of Golshan et al. (U.S Pub. No. 20180227292, hereinafter referred to as “Golshan”)
In regards to Claim 2, the combination of Théberge and Lapidous do not explicitly teach wherein the secure connection is a Transport Control Protocol (TCP) secure session.
Wherein Golshan teaches wherein the secure connection is a Transport Control Protocol (TCP) secure session. (Par. (0036); secure session is TCP with client server and server name with IP address))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge and Lapidous to incorporate the teaching of Golshan to utilize the above feature because of the analogous concept of client and server authentication based on transmitted packets with server name and IP addresses, with the motivation of implementing secure connection to govern policies and detect security and fraud suage reasoning to create gateways, increase performance and be aware of theft and leveraging by utilizing secure sessions. (Golshan Par. (0003-0005))
In regards to Claim 12, the combination of Théberge and Lapidous do not explicitly teach wherein the secure connection is a Transport Control Protocol (TCP) secure session.
Wherein Golshan teaches wherein the secure connection is a Transport Control Protocol (TCP) secure session. (Par. (0036); secure session is TCP with client server and server name with IP address))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge and Lapidous to incorporate the teaching of Golshan to utilize the above feature because of the analogous concept of client and server authentication based on transmitted packets with server name and IP addresses, with the motivation of implementing secure connection to govern policies and detect security and fraud suage reasoning to create gateways, increase performance and be aware of theft and leveraging by utilizing secure sessions. (Golshan Par. (0003-0005))
Claim(s) 3 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Théberge et al. (U.S Pub. No. 20220294825, hereinafter referred to as “Théberge”), Lapidous et al. (U.S Pub. No. 20200228505, hereinafter referred to as “Lapidous”) and Golshan et al. (U.S Pub. No. 20180227292, hereinafter referred to as “Golshan”) further in view of Ihlar et al. (U.S Pub. No. 20220086691, hereinafter referred to as “Ihlar”)
In regards to Claim 3, the combination of Théberge and Lapidous teach the method of claim 1, Théberge further teaches the method of claim 2, wherein the secure-session-setup signaling comprises a Client Hello message of a Transport Layer Security (TLS) protocol, (Par. (0018-0019); TLS Client hello packet of TLS connection))
Théberge does not explicitly teach wherein the Client Hello message carries the server name in plaintext in a Server Name Indication (SNI) field, and wherein reading the server name from the detected packet comprises reading the server name from the SNI field of the Client Hello message.
Wherein Lapidous teaches wherein the Client Hello message carries the server name in plaintext in a Server Name Indication (SNI) field, and (Par. (0082); client hello message that contains plaintext and service name indication field SNI))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge to incorporate the teaching of Lapidous to utilize the above feature because of the analogous concept of client and server authentication based on transmitted packets and client hello messages, with the motivation of utilizing SNI fields to specify destination domains and make it easier for VPN or proxies for security reasons in handshake and preventing compromise. (Lapidous Par. (0082-0083))
Théberge, Lapidous and Golshan do not explicitly teach wherein reading the server name from the detected packet comprises reading the server name from the SNI field of the Client Hello message.
Wherein Ihlar teaches wherein reading the server name from the detected packet comprises reading the server name from the SNI field of the Client Hello message.(Par. (0080); detecting in the packet associated with client hello an encrypted SNI)), (Par. (0054-0055); reading the server name (SNI corresponding to server name indication in client hello message with SNI field that is sent))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge, Lapidous and Golshan to incorporate the teaching of Ihlar to utilize the above feature because of the analogous concept of client and server authentication based on transmitted packets with client hello messaging, with the motivation of classifying and differentiating traffic in networks by matching criteria such as names of servers and creating SNI fields to route and flow and connect client and server with encryption techniques. (Ihlar Par. (0003-0007))
In regards to Claim 13, the combination of Théberge and Lapidous teach the system of claim 11, Théberge further teaches The computing system of claim 12, wherein the secure-session-setup signaling comprises a Client Hello message of a Transport Layer Security (TLS) protocol, (Par. (0018-0019); TLS Client hello packet of TLS connection))
Théberge does not explicitly teach wherein the Client Hello message carries the server name in plaintext in a Server Name Indication (SNI) field, and wherein reading the server name from the detected packet comprises reading the server name from the SNI field of the Client Hello message.
Wherein Lapidous teaches wherein the Client Hello message carries the server name in plaintext in a Server Name Indication (SNI) field, and (Par. (0082); client hello message that contains plaintext and service name indication field SNI))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge to incorporate the teaching of Lapidous to utilize the above feature because of the analogous concept of client and server authentication based on transmitted packets and client hello messages, with the motivation of utilizing SNI fields to specify destination domains and make it easier for VPN or proxies for security reasons in handshake and preventing compromise. (Lapidous Par. (0082-0083))
Théberge, Lapidous and Golshan do not explicitly teach wherein reading the server name from the detected packet comprises reading the server name from the SNI field of the Client Hello message.
Wherein Ihlar teaches wherein reading the server name from the detected packet comprises reading the server name from the SNI field of the Client Hello message. (Par. (0080); detecting in the packet associated with client hello an encrypted SNI)), (Par. (0054-0055); reading the server name (SNI corresponding to server name indication in client hello message with SNI field that is sent))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge, Lapidous and Golshan to incorporate the teaching of Ihlar to utilize the above feature because of the analogous concept of client and server authentication based on transmitted packets with client hello messaging, with the motivation of classifying and differentiating traffic in networks by matching criteria such as names of servers and creating SNI fields to route and flow and connect client and server with encryption techniques. (Ihlar Par. (0003-0007))
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Théberge et al. (U.S Pub. No. 20220294825, hereinafter referred to as “Théberge”), Lapidous et al. (U.S Pub. No. 20200228505, hereinafter referred to as “Lapidous”) and Subbarayan et al. (U.S Pub. No. 20170012941, hereinafter referred to as “Subbarayan”) further in view of Das et al. (U.S Pub. No. 20180232425, hereinafter referred to as “Das”)
In regards to Claim 5, the combination of Théberge and Lapidous do not explicitly teach reporting, by the meter, to a back-end system the correlation record, and reporting by the meter to the back-end system the detecting of the packet-data communication en route between the client device and the server IP address; using, by the back-end system, the established correlation record as the basis to determine that the name of the server is the server name specified by the reported correlation record; and recording, by the back-end system, the detected packet-data communication as being between the client device and the server having the server name.
Wherein Subbarayan teaches reporting, by the meter, to a back-end system the correlation record, and (Par. (0172); reporting by the meter (proxy logs data into database) to the backend system (transmission of logs of data to backend server) the correlation record (logs based on data))
reporting by the meter to the back-end system the detecting of the packet-data communication en route between the client device and the server IP address; (Par. (0064); reporting by meter (proxy logging information captured with communication between client and server corresponding to backend)), (Par. (0019-0021); the detecting of the packet-data communication en route between the client device and the server IP address (proxy extracting and identifying packets in communication between client and server)), (Par. (0021-0023); communication en route between the client device and the server IP address (data received associated with client and IP address of server))
recording, by the back-end system, the detected packet-data communication as being between the client device and the server having the server name. (Par. (0080-0083, 0087-00883); generating and sending logs to server backend after matching API name between client and server with messages and ensuring data packets and message received from client to server are legitimate)), (Par. (0080); communication as being between the client device and the server having the server name (API name is server side name that is matched to see if same from extracted API name, if match is found transmitting of message))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge and Lapidous to incorporate the teaching of Subbarayan to utilize the above feature because of the analogous concept of client and server authentication based on transmitted packets, with the motivation of creatin security with client request associated with servers to ensure targeted routing, minimized overloads and create high availability. (Subbarayan Par. (0003))
Théberge, Lapidous and Subbarayan do not explicitly teach using, by the back-end system, the established correlation record as the basis to determine that the name of the server is the server name specified by the reported correlation record; and
Wherein Das teaches using, by the back-end system, the established correlation record as the basis to determine that the name of the server is the server name specified by the reported correlation record; and (Par. (0070); established correlation record (log message) basis to determine that the name of the server is the server name specified (matching log message that includes server name to known pattern)), (Par. (0011, 0090-0091); using the back-end system))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge, Lapidous and Subbarayan to incorporate the teaching of Das to utilize the above feature because of the analogous concept of client and server authentication based on transmitted packets, with the motivation of utilizing back-end systems and logging messages to create analytics and represent interaction between server and map out information with the use of back-end to create optimization and execution by detection of specific log data. (Das Par. (0007-0012))
Claim(s) 6 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Théberge et al. (U.S Pub. No. 20220294825, hereinafter referred to as “Théberge”) and Lapidous et al. (U.S Pub. No. 20200228505, hereinafter referred to as “Lapidous”) further in view of Cang et al. (U.S Pub. No. 20170111414, hereinafter referred to as “Cang”)
In regards to Claim 6, the combination of Théberge and Lapidous do not explicitly teach establishing media-measurement data based on the recording of the detected packet-data communication as being between the client device and the server having the server name; and using the established media-measurement data as a basis to take action.
Wherein Cang teaches establishing media-measurement data based on the recording of the detected packet-data communication as being between the client device and the server having the server name; and (Par. (0053); media measurement data (multimedia data streams) based on recording of the detected packet-data communication (multimedia data streams are formed into data packets) as being between the client device and the server having the server name (client of data packets and determining multimedia data streams according to name of server))
using the established media-measurement data as a basis to take action. (Par. (0055, 0057-0059); the established media-measurement data (the multimedia data streams are used to process packets) as a basis to take action (decoding process and action of separating the video and audio data streams based on packets and multimedia data streams))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge and Lapidous to incorporate the teaching of Cang to utilize the above feature because of the analogous concept of client and server transmission based on server name, with the motivation of analyzing the transmission of streaming data based on protocol and ensuring quality and specific data transmission based on protocols to improve bandwidth with media transmission. (Cang Par. (0004 and 0042-0043))
In regards to Claim 15, the combination of Théberge and Lapidous do not explicitly teach establishing media-measurement data based on the recording of the detected packet-data communication as being between the client device and the server having the server name; and using the established media-measurement data as a basis to take action.
Wherein Cang teaches establishing media-measurement data based on the recording of the detected packet-data communication as being between the client device and the server having the server name; and (Par. (0053); media measurement data (multimedia data streams) based on recording of the detected packet-data communication (multimedia data streams are formed into data packets) as being between the client device and the server having the server name (client of data packets and determining multimedia data streams according to name of server))
using the established media-measurement data as a basis to take action. (Par. (0055, 0057-0059); the established media-measurement data (the multimedia data streams are used to process packets) as a basis to take action (decoding process and action of separating the video and audio data streams based on packets and multimedia data streams))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge and Lapidous to incorporate the teaching of Cang to utilize the above feature because of the analogous concept of client and server transmission based on server name, with the motivation of analyzing the transmission of streaming data based on protocol and ensuring quality and specific data transmission based on protocols to improve bandwidth with media transmission. (Cang Par. (0004 and 0042-0043))
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Théberge et al. (U.S Pub. No. 20220294825, hereinafter referred to as “Théberge”) and Lapidous et al. (U.S Pub. No. 20200228505, hereinafter referred to as “Lapidous”) further in view of St. Pierre et al. (U.S Pub. No. 20200389431, hereinafter referred to as “St. Pierre”)
In regards to Claim 9, the combination of Théberge and Lapidous teach the method of claim 1, Théberge further teaches the method of claim 1, wherein the meter is external to the client device, and (Par. (0018); meter (verifier process) may be external))
Théberge and Lapidous do not explicitly teach wherein detecting the packet and thereafter detecting the packet-data communication both occur external to the client device.
Wherein St. Pierre teaches wherein detecting the packet and thereafter detecting the packet-data communication both occur external to the client device. (Par. (0032, 0050); determining packets occurring external to the client (packets sent from external client and determined and thereafter determining packet is known and authenticated)), (Figure 1 label 108, 102, 104, 121; external to the client (user 108 and external device 108 attacker sending packets to scrubber 104))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge and Lapidous to incorporate the teaching of St. Pierre to utilize the above feature because of the analogous concept of client and server authentication based on packets with IP address information, with the motivation of deep inspection of packets associated with network attacks to reduce computing times and resources and prevent waste of processing by identifying packets in traffic with indication of destination and determining matching and analyzing packets based on information. (St. Pierre Par. (0002-0004))
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Théberge et al. (U.S Pub. No. 20220294825, hereinafter referred to as “Théberge”), and Lapidous et al. (U.S Pub. No. 20200228505, hereinafter referred to as “Lapidous”) further in view of Ihlar et al. (U.S Pub. No. 20220086691, hereinafter referred to as “Ihlar”)
In regards to Claim 18, the combination of Théberge and Lapidous teach the non-transitory computer-readable medium of claim 17, Théberge further teaches the at least one non-transitory computer-readable medium of claim 17, wherein the secure-session-setup signaling comprises a Client Hello message of a Transport Layer Security (TLS) protocol, (Par. (0018-0019); TLS Client hello packet of TLS connection))
Théberge does not explicitly teach wherein the Client Hello message carries the server name in plaintext in a Server Name Indication (SNI) field, and wherein reading the server name from the detected packet comprises reading the server name from the SNI field of the Client Hello message.
Wherein Lapidous teaches wherein the Client Hello message carries the server name in plaintext in a Server Name Indication (SNI) field, and (Par. (0082); client hello message that contains plaintext and service name indication field SNI))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge to incorporate the teaching of Lapidous to utilize the above feature because of the analogous concept of client and server authentication based on transmitted packets and client hello messages, with the motivation of utilizing SNI fields to specify destination domains and make it easier for VPN or proxies for security reasons in handshake and preventing compromise. (Lapidous Par. (0082-0083))
Théberge and Lapidous do not explicitly teach wherein reading the server name from the detected packet comprises reading the server name from the SNI field of the Client Hello message.
Wherein Ihlar teaches wherein reading the server name from the detected packet comprises reading the server name from the SNI field of the Client Hello message. (Par. (0080); detecting in the packet associated with client hello an encrypted SNI)), (Par. (0054-0055); reading the server name (SNI corresponding to server name indication in client hello message with SNI field that is sent))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Théberge and Lapidous to incorporate the teaching of Ihlar to utilize the above feature because of the analogous concept of client and server authentication based on transmitted packets with client hello messaging, with the motivation of classifying and differentiating traffic in networks by matching criteria such as names of servers and creating SNI fields to route and flow and connect client and server with encryption techniques. (Ihlar Par. (0003-0007))
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Calder; Matthew James (U.S Pub. No. 20220141279) “CLIENT-SIDE MEASUREMENT OF COMPUTER NETWORK CONDITIONS”. Considered this reference because it addressed client server authentication and reporting with measurement data associated with content and streaming.
SUN; John Wan Yeung (U.S Pub. No. 20250125956) “COMMUNICATION POLICY ENFORCEMENT USING A SECURE PLAINTEXT LABEL”. Considered this application because it relates to plaintext of server names and determination of server and client based on transmitted IP information and data.
BROWN; Sean (U.S Pub. No. 20180316618) “SYSTEM AND METHOD FOR TRACKING DOMAIN NAMES FOR THE PURPOSES OF NETWORK MANAGEMEN”. Considered this application because it addressed domain name servers and clients with packet detection based on IP addresses and name entries.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HASSAN A HUSSEIN whose telephone number is (571)272-3554. The examiner can normally be reached on 7:30am-5pm.
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, Eleni Shiferaw can be reached on (571)272-3867. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/HASSAN A HUSSEIN/ Examiner, Art Unit 2497
Prosecution Insights