DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to Applicant’s communication filed on 10/07/2024. Claims 1-20 have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/07/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
With regards to Patent No. 12,132,631
Claims 1-3, 6, 8-10,13, 15-17 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-3 of Patent No. US 12,132,631 in view of Ganapathy.
Claims 4,11,18 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-3 of Patent No. US 12,132,631 in view of Li.
Claims 5,12,19 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-3 of Patent No. US 12,132,631 in view of Abley.
Claims 7,14,20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-3 of Patent No. US 12,132,631 in view of Ganapathy further in view of Guim Bernat.
Although the conflicting claims are not identical, they are not patentably distinct from each other because:
See Below for analysis
Claims 1-3, 8-10,15-17, of Instant application
Claims 1-3 of Patent No. US 12,132,631
Claims 1,8,15
A method/system/non transitory for client-side latency detection, comprising:
at least one hardware processor; and at least one memory storing instructions that, when executed by the at least one hardware processor, cause the system to perform a process
generating a first data record that includes a first timestamp associated with a first connection protocol packet, wherein the first timestamp indicates a time that the first connection protocol packet is transmitted from an application client residing on a local device to an application server on a remote system via a plurality of network sockets of the local device that are associated with the application client;
parsing subsequent packets communicated between the application client and the application server to identify, while the plurality of network sockets are open, one or more second connection protocol packets that are expected to follow the first connection protocol packet according to a connection protocol sequence;
associating respective timestamps with the one or more second connection protocol packets in response to identifying the one or more second connection protocol packets via the parsing;
determining a latency measurement for the application client based on the first timestamp included in the first data record and the respective timestamps associated with the one or more second connection protocol packets,
the latency measurement describing a duration of the connection protocol sequence; and while the plurality of network sockets are closed, transmitting the latency measurement to the application client.
Claim 1
A system for on-device latency detection, the system comprising:
at least one hardware processor; and at least one non-transitory memory, coupled to the at least one hardware processor and storing instructions, which when executed by the at least one hardware processor, perform a process, the process comprising:
parsing and extracting packet headers of a plurality of data-connection packets that are transmitted between an application client that is local to the system and an application server that is remote to the system via a plurality of network sockets of the system that are associated with the application client;
generating a plurality of data records that each correspond to a respective data-connection packet, wherein each data record includes the packet header of the respective data-connection packet and a timestamp;
identifying a set of related data records from the plurality of data records based on the packet header that is included in each data record, wherein the related data records correspond to a set of data-connection packets that are related to one another according to a particular communication protocol;
determining one or more latency measurements for the application client based on the timestamps of each of the set of related data records, the one or more latency measurements comprising a latency matrix that includes latency values corresponding to the plurality of network sockets associated with the application client; detecting a query by the application client for the one or more latency measurements for the application client; and
while the plurality of network sockets associated with the application client are closed, providing, from an operating system (OS) kernel level of the system where the one or more latency measurements are determined, to an upper application level where the application client resides, the one or more latency measurements for the application client in response to the query..
Claims 2,9,16
wherein the latency measurement is transmitted from an operating system (OS) kernel level of the local device to the application client residing in an upper application level of the local device.
Claim 2
an application client that is local to the system …while the plurality of network sockets associated with the application client are closed, providing, from an operating system (OS) kernel level of the system where the one or more latency measurements are determined, to an upper application level where the application client resides, the one or more latency measurements for the application client in response to the query.
Claims 3,10,17
transmitting, from the local device to the remote system, the latency measurement for the application client in connection with a dynamic load-balancing operation of the application server.
Claim 3
transmit, from the system where the application client is local, the one or more latency measurements for the application client to the application server in connection with a dynamic load-balancing operation of the application server, wherein the dynamic load-balancing operation of the application server includes receiving latency measurements for a plurality of application clients at different systems.
With regards to claims 1,8,15 the Patent No. US 12,132,631 does not explicitly teach wherein the first timestamp indicates a time that the first connection protocol packet is transmitted, parsing subsequent packets communicated between the application client and the application server to identify, while the plurality of network sockets are open, one or more second connection protocol packets that are expected to follow the first connection protocol packet according to a connection protocol sequence; associating respective timestamps with the one or more second connection protocol packets, the latency measurement describing a duration of the connection protocol sequence.
However, Ganapathy teaches wherein the first timestamp indicates a time that the first connection protocol packet is transmitted, parsing subsequent packets communicated between the application client and the application server to identify, while the plurality of network sockets are open, one or more second connection protocol packets that are expected to follow the first connection protocol packet according to a connection protocol sequence; associating respective timestamps with the one or more second connection protocol packets, the latency measurement describing a duration of the connection protocol sequence (Page 1, Pages 5-7, Page 10, Pages 22- 23).
It would have been obvious to one of ordinary skill in the art at the time of the applicants' invention to modify the teachings of Patent No. US 12,132,631 to include the teachings of Ganapathy. The motivation to do so is to find a suitable architecture and an optimized algorithm to send and receive measurement packets over high-speed links (Ganapathy - Abstract).
With regards to claims 4,11,18, the Patent No. US 12,132,631 does not explicitly teach wherein the connection protocol sequence is a transmission control protocol (TCP) handshake according to which the first connection protocol packet comprises a SYN header value.
However, Li teaches wherein the connection protocol sequence is a transmission control protocol (TCP) handshake according to which the first connection protocol packet comprises a SYN header value (¶0069).
It would have been obvious to one of ordinary skill in the art at the time of the applicants' invention to modify the teachings of Patent No. US 12,132,631 to include the teachings of Li. The motivation to do so is to allow the system to identify a SYN flag as header value that indicates initiation of the TCP connection (three-way handshake) ( LI - ¶ 0069).
With regards to claims 5,12,19, the Patent No. US 12,132,631 does not explicitly teach wherein the connection protocol sequence is a domain name system (DNS) sequence, and wherein the one or more second connection protocol packets are identified based on having an opposite value of a QR bit compared to a QR bit of the first connection protocol packet.
However, Abley teaches herein the connection protocol sequence is a domain name system (DNS) sequence, and wherein the one or more second connection protocol packets are identified based on having an opposite value of a QR bit compared to a QR bit of the first connection protocol packet (¶0022, ¶0025).
It would have been obvious to one of ordinary skill in the art at the time of the applicants' invention to modify the teachings of Patent No. US 12,132,631 to include the teachings of Abley. The motivation to do so is to allow the system determine traceability of network request traffic over a communications network for reducing strain in traffic processing resources ( Abley - Abstract).
With regards to claims 6,13, the Patent No. US 12,132,631 does not explicitly teach that wherein the latency measurement includes a plurality of duration values corresponding the plurality of network sockets based on the one or more second connection protocol packets being communicated via different network sockets.
However, Ganapathy teaches wherein the latency measurement includes a plurality of duration values corresponding the plurality of network sockets based on the one or more second connection protocol packets being communicated via different network sockets (Page 1, Pages 5-7, Page 10, Pages 22- 23),
It would have been obvious to one of ordinary skill in the art at the time of the applicants' invention to modify the teachings of Patent No. US 12,132,631 to include the teachings of Ganapathy. The motivation to do so is to find a suitable architecture and an optimized algorithm to send and receive measurement packets over high-speed links (Ganapathy - Abstract).
With regards to claims 7,14,20, the Patent No. US 12,132,631 does not explicitly teach wherein the first data record is stored in an OS kernel database that is configured to be inaccessible by the application client.
However, Ganapathy teaches wherein the first data record is stored in an OS kernel structure that is configured to be inaccessible by the application client (Page 8, Pages 11-12).
It would have been obvious to one of ordinary skill in the art at the time of the applicants' invention to modify the teachings of Patent No. US 12,132,631 to include the teachings of Ganapathy. The motivation to do so is to find a suitable architecture and an optimized algorithm to send and receive measurement packets over high-speed links (Ganapathy - Abstract).
Patent No. US 12,132,631 in view of Ganapathy does not explicitly teach that the structure is a database. Guim Bernat teaches a kernel database (¶0033 – Kernel database).
It would have been obvious to one of ordinary skill in the art at the time of the applicants' invention to modify the teachings of Patent No. US 12,132,631 to include the teachings of Guim Bernat. The motivation to do so is to allow the system to eliminate the overhead of switching between user space and kernel space.
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.
Claims 1,2,6,8,9,13,15,16 are rejected under 35 U.S.C. 103 as being unpatentable over Ganapathy et al. “ A tool for measuring available network bandwidth in the cloud” September 24, 2015 (Ganapathy hereinafter) in view of Susarla et al. Publication No. US 2016/0283340 A1 ( Susarla hereinafter)
Regarding claim 1,
Ganapathy teaches a method for client-side latency detection, comprising:
generating a first data record that includes a first timestamp associated with a first connection protocol packet, wherein the first timestamp indicates a time that the first connection protocol packet is transmitted from an application client residing on a local device to an application server on a remote system via a plurality of network sockets of the local device that are associated with the application client (Page 1 - The basic principle is to inject probe packets into the network. These packets are time-stamped at sender and receiver - Page 6 - Some important fields in the TWAMP packet which helps in the performance measurements are Sequence Number, Sender sending timestamp (T1), Reflector receiving time-stamp (T2), Receiver sending timestamp(T3). Also Sender receiving time-stamp (T4) can be recorded locally on sender for measuring round trip delay. Page 5 - TWAMP is very similar to TWAMP, but with a change in the architecture, where session-receiver is replaced by a session-reflector. Unlike the session-receiver in the TWAMP, session-reflector in TWAMP does not collect any measurement data, but instead, on reception of any TWAMP measurement packet from the session-sender a response is sent back to the session-sender. Page 8 - session-sender and session-reflector applications running on user-space are built to communicate with the host network stack using the native UDP sockets using the send() system calls. Page 10 – TWAMP measurement packets can be generated and sent at required rate with timestamps of high precision to measure the performance of the high-speed links with high accuracy – Page 20 - Before sending out, the packets are timestamped with the time `T1' in nano-second precision using clock getime system call. The timestamp obtained using the above call is store on struct time spec object which provides the provision to store timestamp in nano-second accuracy - Page 23 - the TWAMP fields are filled in advance except the sending timestamp, which will be update before sending the packet for more accuracy – This section describes the high-level design used for the session-sender and session-reflector module designed using LibPcap socket. From the session-client module, the following parameters are passed to the session-sender module for creating the session - the UDP socket is created for communicating with host network stack. On struct sockaddr in, the destination IP and port received from the session-client are used for sending out the TWAMP measurement packets. On the other hand, to receive the packets from reflector, the socket is with bind() with sender IP and port on which the sender is listening. – Note: the examiner interprets the session reflector as application server that sit on a remote system and is waiting for session to be initiated to provide a service );
parsing subsequent packets communicated between the application client and the application server to identify, while the plurality of network sockets are open, one or more second connection protocol packets that are expected to follow the first connection protocol packet according to a connection protocol sequence (Page 6 - TWAMP defines two set of protocols: control protocol for setting up the TWAMP sessions and other for measuring the performance of the monitored links through transmission and reception of TWAMP measurement packets. A session protocol helps in initiating a TWAMP session between a sender and a reflector, where the information about addresses, ports and security mode is agreed upon during the start of the TWAMP session and another test protocol for transmission and reception of measurement packets. – Some important fields in the TWAMP packet which helps in the performance measurements are Sequence Number. Page 7 - The reflector is consider to be active all the time. On reception of TWAMP-Test packets from the sender, the reflector sends response test packet to the each received TWAMP-Test packet, like a ping-type reflector where response is immediately sent out for each packet – The Last Sequence Number in train _eld instructs the reflector to wait till the last sequence number as mentioned in the packet arrives before sending the response packets. Page 22 - Once the measurement session is completed the socket can be closed using close(sock fd) Page 23 - To receive the reflected packets on session-sender, pcap loop() is called repeatedly over the socket to receive and deliver the TWAMP payload. On reception, the packets are timestamped T4 and the packets are copied to the pre-allocated buffers. Upon reception of the last packet in the train the results are sent to session-client for APC, RTT and other performance measurements - First step in the session-sender is to create a LibPcap socket which can communicate with the network stack);
associating respective timestamps with the one or more second connection protocol packets in response to identifying the one or more second connection protocol packets via the parsing (Page 6 - Some important _elds in the TWAMP packet which helps in the performance measurements are Sequence Number, Sender sending timestamp (T1), Reflector receiving time-stamp (T2), Receiver sending timestamp(T3). Also Sender receiving time-stamp (T4) (not in the TWAMP _elds) can be recorded locally on Sender for measuring round-trip delays Page 27 - Each incoming packet has to be inspected by the application to confirm the packet is a TWAMP measurement packet or not – Page 30 – On arrival of TWAMP packets from sender, the packets are received using the function: nm nextpkt(fd, pktHeader) and timestamped `T2' – Page 36 - The received packets are timestamped (T4). The received packets are stored. After receiving Nth packet, the results (T1, T2, T3 and T4) are sent to the session-client for APC and other network performance measurements and the corresponding packet buffers are made free);
determining a latency measurement for the application client based on the first timestamp included in the first data record and the respective timestamps associated with the one or more second connection protocol packets, the latency measurement describing a duration of the connection protocol sequence (Page 2 - send and receive packets at higher rates has less or no correlation with the modules which calculates the network performance (like available bandwidth, round-trip time, latency - Page 6 - Some important fields in the TWAMP packet which helps in the performance measurements are Sequence Number, Sender sending timestamp (T1), Reflector receiving time-stamp (T2), Receiver sending timestamp(T3). Also Sender receiving time-stamp (T4) (not in the TWAMP fields) can be recorded locally on Sender for measuring round-trip delays - Page 10 – TWAMP measurement packets can be generated and sent at required rate (even at wire-speed) with timestamps of high precision to measure the performance of the high-speed links with high accuracy. Page 20 - Before sending out, the packets are timestamped with the time `T1' in nano-second precision using clock getime(CLOCK REALTIME, time) system call. – Page 22 - on session-sender to receive the reflected packets, recvfrom() call over the socket delivers the TWAMP payload. On reception, the packets are timestamped T4 and the packets is copied to the pre-allocated buffers. Upon reception of the last packet in the train the results are sent to session-client for performance measurements. Page 36 - The received packets are timestamped (T4). The received packets are stored. After receiving Nth packet, the results (T1, T2, T3 and T4) are sent to the session-client for APC and other network performance measurements); and
transmitting the latency measurement to the application client (Page 22 - on session-sender to receive the reflected packets, recvfrom() call over the socket delivers the TWAMP payload. On reception, the packets are timestamped T4 and the packets is copied to the pre-allocated buffers. Upon reception of the last packet in the train the results are sent to session-client for performance measurements – Page 8 TWAMP-Test packets are transported using UDP. Mostly, in the measuring device, session-sender and session-reflector applications running on user-space are built to communicate with the host network stack using the native UDP sockets using the send() or sendto() system calls.- See Also Page 13,26 - These sockets are bi-directional can help to send the session parameter down to kernel module and upon completion of TWAMP measurements, results can be sent back to session-client via Netlink sockets – Page 27 -Once after receiving `N' packets, the timestamp T1,T2,T3 and T4 from the TWAMP packets are copied and sent back to the session-client for APC, RTT and other performance measurements through Netlink sockets. The sk_buff are freed and memory for 'N' next train of TWAMP packets are allocated in the sk_buff and the process continues. Finally, on reception of results for all the trains sent, the Netlink socket is closed. ).
Ganapathy teaches transmitting the latency measurement to the application client and then closing the plurality of sockets (Page 22,Page 26-27). However, Ganapathy does not explicitly teach
while the plurality of network sockets are closed, transmitting the latency measurement to the application client.
Susarla teaches
while the plurality of network sockets are closed, transmitting the latency measurement (Claim 3 - continuing to collect data after the network connection is closed; overwriting at least a portion of the data collected after the network connection is closed, when a threshold amount of the data collected has been buffered and there is no connection over the network socket –¶0052 - trace and I/O statistics are written for a storage volume, when volume collection is enabled. Statistics may include, in one aspect, performance data, such as, IOPS (number of input/output operations that are processed per second), CPU utilization, cache statistics, and the like. Other relevant statistics that can be derived from the I/O activity may also be stored and/or reported in various aspects. ¶ 0059 - the client can store the trace/statistics data in a system readable file that can be exchanged via standard methods to other systems for archival purposes. the connection module closes the connection socket on which the I/O trace data is being transmitted. This may be based on a "close" command from the client. the data collection module collects in-memory data (also referred to as in-memory logging), while waiting for a new network connection. the connection socket uses a dedicated management network port for sending collected data. In general, the connection socket will follow a specific transport protocol, such as, for example the TCP/IP protocol. However, it will be understood that other protocols may also be utilized in carrying out the teachings described herein – Claim 10 - continue to collect data after the network connection is closed; and overwrite at least a portion of the data collected after the network connection is closed, when a threshold amount of the data collected has been buffered and there is no connection over the network socket – ¶0037 - the connection module communicates with the network adapter 240 and manages one or more connections for communicating I/O operations or trace data for evaluation - Note: Since the system is designed to handle more than one connection, then all active /tracing sockets are closed. – the system will continue to send the data internally to the buffer for the client app to access it ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify transmitting the latency measurement to the application client and then closing the plurality of sockets taught by Ganapathy to include the teachings of Susarla. The motivation for doing so is to allow the system to continue data collection and buffering during socket closures to ensure data integrity and system availability.
Regarding claim 2,
Ganapathy further teaches
wherein the latency measurement is transmitted from an operating system (OS) kernel level of the local device to the application client residing in an upper application level of the local device (Page 13 – the final architecture to send TWAMP measurements, then a suitable method to communicate between kernel module and the TWAMP-client application running on the user-space has to be enabled for initiating the TWAMP session and to send back the results obtained from the reflected probe packets for performance measurements - Page 22 - on session-sender to receive the reflected packets, recvfrom() call over the socket delivers the TWAMP payload. On reception, the packets are timestamped T4 and the packets is copied to the pre-allocated buffers. Upon reception of the last packet in the train the results are sent to session-client for performance measurements. Page 27 - on session-sender, the incoming TWAMP packets are received by Net filter hooks at PRE ROUTING stage before the packet is processed by the native host stack. Each incoming packet has to be inspected by the application to confirm the packet is a TWAMP measurement packet or not. The TWAMP packets are timestamped T4 and the sk-buff corresponding to the packet is stored without releasing the memory. Once after receiving `N' packets, the timestamp T1,T2,T3 and T4 from the TWAMP packets are copied and sent back to the session-client for APC, RTT and other performance measurements through Netlink sockets).
Regarding claim 6,
Ganapathy further teaches
wherein the latency measurement includes a plurality of duration values corresponding the plurality of network sockets based on the one or more second connection protocol packets being communicated via different network sockets ( Page I - This thesis focus on finding a suitable architecture and an optimized algorithm to send and receive measurement packets over high-speed links. Five different architectures: Native UDP sockets, LibPcap, Loadable Kernel Modules, Netmap and Data Plane Development Kit (DPDK) are investigated for fast packets processing in Linux systems. Also, the optimized algorithm(s) that suits the specific architecture for sending and receiving measurement packets at various rates are designed. The performance metrics obtained from the measurement systems tested against various rates and burst size using different architectures are compared - Page 6 - For one-way delay measurements clocks needs to be synchronized at Sender and Reflector in both directions (T2-T1 and T4-T3). However, for Round-Trip Time (RTT) measurements it is not needed, since only T4 and T1 are used (RTT = T4-T1) and both the time stamps are generated at the sender Page 18 where the base modules for generating, sending and reflecting TWAMP measurements packets on sender and receiver using the above discussed architectures (UDP socket, LibPcap, Kernel Module, Netmap and DPDK) over the network discussed in next section.- Page 26 - From the session-client the Netlink sockets are created similar to native UDP sockets. Page 55 - simple research experiment was conducted at the receiver, where the incoming TWAMP packets are timestamped enabling different options mentioned below. The results obtained for 50 packets send at 6 Gbps using different timestamping options are shown in table 2 – Note: the system compares latency metric like RTT across multiple socket types and architectures including UDP sockets , Net filters sockets, Libpcap, …, these RTTs (Duration values ) vary based on which socket/architecture is used).
Regarding claim 8,
Ganapathy teaches a system comprising, comprising:
at least one hardware processor; and at least one memory storing instructions that, when executed by the at least one hardware processor, cause the system (Page -16, Page 0036, Fig.15) to perform a process comprising
generating a first data record that includes a first timestamp associated with a first connection protocol packet, wherein the first timestamp indicates a time that the first connection protocol packet is transmitted from an application client to an application server on a remote system via a plurality of network sockets of that are associated with the application client (Page 1 - The basic principle is to inject probe packets into the network. These packets are time-stamped at sender and receiver - Page 6 - Some important fields in the TWAMP packet which helps in the performance measurements are Sequence Number, Sender sending timestamp (T1), Reflector receiving time-stamp (T2), Receiver sending timestamp(T3). Also Sender receiving time-stamp (T4) can be recorded locally on sender for measuring round trip delay. Page 5 - TWAMP is very similar to TWAMP, but with a change in the architecture, where session-receiver is replaced by a session-reflector. Unlike the session-receiver in the OWAMP, session-reflector in TWAMP does not collect any measurement data, but instead, on reception of any TWAMP measurement packet from the session-sender a response is sent back to the session-sender. Page 8 - session-sender and session-reflector applications running on user-space are built to communicate with the host network stack using the native UDP sockets using the send() system calls. Page 10 – TWAMP measurement packets can be generated and sent at required rate with timestamps of high precision to measure the performance of the high-speed links with high accuracy – Page 20 - Before sending out, the packets are timestamped with the time `T1' in nano-second precision using clock getime system call. The timestamp obtained using the above call is store on struct time spec object which provides the provision to store timestamp in nano-second accuracy - Page 23 - the TWAMP fields are filled in advance except the sending timestamp, which will be update before sending the packet for more accuracy – This section describes the high-level design used for the session-sender and session-reflector module designed using LibPcap socket. From the session-client module, the following parameters are passed to the session-sender module for creating the session - the UDP socket is created for communicating with host network stack. On struct sockaddr in, the destination IP and port received from the session-client are used for sending out the TWAMP measurement packets. On the other hand, to receive the packets from reflector, the socket is with bind() with sender IP and port on which the sender is listening. – Note: the examiner interprets the session reflector as application server that sit on a remote system and is waiting for session to be initiated to provide a service );
parsing subsequent packets communicated between the application client and the application server to identify, while the plurality of network sockets are open, one or more second connection protocol packets that are expected to follow the first connection protocol packet according to a connection protocol sequence (Page 6 - TWAMP defines two set of protocols: control protocol for setting up the TWAMP sessions and other for measuring the performance of the monitored links through transmission and reception of TWAMP measurement packets. A session protocol helps in initiating a TWAMP session between a sender and a reflector, where the information about addresses, ports and security mode is agreed upon during the start of the TWAMP session and another test protocol for transmission and reception of measurement packets. – Some important fields in the TWAMP packet which helps in the performance measurements are Sequence Number. Page 7 - The reflector is consider to be active all the time. On reception of TWAMP-Test packets from the sender, the reflector sends response test packet to the each received TWAMP-Test packet, like a ping-type reflector where response is immediately sent out for each packet – The Last Sequence Number in train _eld instructs the reflector to wait till the last sequence number as mentioned in the packet arrives before sending the response packets. Page 22 - Once the measurement session is completed the socket can be closed using close(sock fd) Page 23 - To receive the reflected packets on session-sender, pcap loop() is called repeatedly over the socket to receive and deliver the TWAMP payload. On reception, the packets are timestamped T4 and the packets are copied to the pre-allocated buffers. Upon reception of the last packet in the train the results are sent to session-client for APC, RTT and other performance measurements - First step in the session-sender is to create a LibPcap socket which can communicate with the network stack);
associating respective timestamps with the one or more second connection protocol packets in response to identifying the one or more second connection protocol packets via the parsing (Page 6 - Some important _elds in the TWAMP packet which helps in the performance measurements are Sequence Number, Sender sending timestamp (T1), Reflector receiving time-stamp (T2), Receiver sending timestamp(T3). Also Sender receiving time-stamp (T4) (not in the TWAMP _elds) can be recorded locally on Sender for measuring round-trip delays Page 27 - Each incoming packet has to be inspected by the application to confirm the packet is a TWAMP measurement packet or not – Page 30 – On arrival of TWAMP packets from sender, the packets are received using the function: nm nextpkt(fd, pktHeader) and timestamped `T2' – Page 36 - The received packets are timestamped (T4). The received packets are stored. After receiving Nth packet, the results (T1, T2, T3 and T4) are sent to the session-client for APC and other network performance measurements and the corresponding packet buffers are made free);
determining a latency measurement for the application client based on the first timestamp included in the first data record and the respective timestamps associated with the one or more second connection protocol packets, the latency measurement describing a duration of the connection protocol sequence (Page 2 - send and receive packets at higher rates has less or no correlation with the modules which calculates the network performance (like available bandwidth, round-trip time, latency - Page 6 - Some important fields in the TWAMP packet which helps in the performance measurements are Sequence Number, Sender sending timestamp (T1), Reflector receiving time-stamp (T2), Receiver sending timestamp(T3). Also Sender receiving time-stamp (T4) (not in the TWAMP fields) can be recorded locally on Sender for measuring round-trip delays - Page 10 – TWAMP measurement packets can be generated and sent at required rate (even at wire-speed) with timestamps of high precision to measure the performance of the high-speed links with high accuracy. Page 20 - Before sending out, the packets are timestamped with the time `T1' in nano-second precision using clock getime(CLOCK REALTIME, time) system call. – Page 22 - on session-sender to receive the reflected packets, recvfrom() call over the socket delivers the TWAMP payload. On reception, the packets are timestamped T4 and the packets is copied to the pre-allocated buffers. Upon reception of the last packet in the train the results are sent to session-client for performance measurements. Page 36 - The received packets are timestamped (T4). The received packets are stored. After receiving Nth packet, the results (T1, T2, T3 and T4) are sent to the session-client for APC and other network performance measurements); and
transmitting the latency measurement to the application client (Page 22 - on session-sender to receive the reflected packets, recvfrom() call over the socket delivers the TWAMP payload. On reception, the packets are timestamped T4 and the packets is copied to the pre-allocated buffers. Upon reception of the last packet in the train the results are sent to session-client for performance measurements – Page 8 TWAMP-Test packets are transported using UDP. Mostly, in the measuring device, session-sender and session-reflector applications running on user-space are built to communicate with the host network stack using the native UDP sockets using the send() or sendto() system calls.- See Also Page 13,26 - These sockets are bi-directional can help to send the session parameter down to kernel module and upon completion of TWAMP measurements, results can be sent back to session-client via Netlink sockets – Page 27 -Once after receiving `N' packets, the timestamp T1,T2,T3 and T4 from the TWAMP packets are copied and sent back to the session-client for APC, RTT and other performance measurements through Netlink sockets. The sk_bu are freed and memory for 'N' next train of TWAMP packets are allocated in the sk_bu and the process continues. Finally, on reception of results for all the trains sent, the Netlink socket is closed. ).
Ganapathy teaches transmitting the latency measurement to the application client and then closing the plurality of sockets (Page 22,Page 26-27). However, Ganapathy does not explicitly teach
while the plurality of network sockets are closed, transmitting the latency measurement to the application client.
Susarla teaches
while the plurality of network sockets are closed, transmitting the latency measurement (Claim 3 - continuing to collect data after the network connection is closed; overwriting at least a portion of the data collected after the network connection is closed, when a threshold amount of the data collected has been buffered and there is no connection over the network socket –¶0052 - trace and I/O statistics are written for a storage volume, when volume collection is enabled. Statistics may include, in one aspect, performance data, such as, IOPS (number of input/output operations that are processed per second), CPU utilization, cache statistics, and the like. Other relevant statistics that can be derived from the I/O activity may also be stored and/or reported in various aspects. ¶ 0059 - the client can store the trace/statistics data in a system readable file that can be exchanged via standard methods to other systems for archival purposes. the connection module closes the connection socket on which the I/O trace data is being transmitted. This may be based on a "close" command from the client. the data collection module collects in-memory data (also referred to as in-memory logging), while waiting for a new network connection. the connection socket uses a dedicated management network port for sending collected data. In general, the connection socket will follow a specific transport protocol, such as, for example the TCP/IP protocol. However, it will be understood that other protocols may also be utilized in carrying out the teachings described herein – Claim 10 - continue to collect data after the network connection is closed; and overwrite at least a portion of the data collected after the network connection is closed, when a threshold amount of the data collected has been buffered and there is no connection over the network socket – ¶0037 - the connection module communicates with the network adapter 240 and manages one or more connections for communicating I/O operations or trace data for evaluation - Note: Since the system is designed to handle more than one connection, then all active /tracing sockets are closed. – the system will continue to send the data internally to the buffer for the client app to access it ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify transmitting the latency measurement to the application client and then closing the plurality of sockets taught by Ganapathy to include the teachings of Susarla. The motivation for doing so is to allow the system to continue data collection and buffering during socket closures to ensure data integrity and system availability.
Regarding claim 9,
Ganapathy further teaches
wherein the latency measurement is transmitted from an operating system (OS) kernel level to the application client residing in an upper application level (Page 13 – the final architecture to send TWAMP measurements, then a suitable method to communicate between kernel module and the TWAMP-client application running on the user-space has to be enabled for initiating the TWAMP session and to send back the results obtained from the reflected probe packets for performance measurements - Page 22 - on session-sender to receive the reflected packets, recvfrom() call over the socket delivers the TWAMP payload. On reception, the packets are timestamped T4 and the packets is copied to the pre-allocated buffers. Upon reception of the last packet in the train the results are sent to session-client for performance measurements. Page 27 - on session-sender, the incoming TWAMP packets are received by Net filter hooks at PRE ROUTING stage before the packet is processed by the native host stack. Each incoming packet has to be inspected by the application to confirm the packet is a TWAMP measurement packet or not. The TWAMP packets are timestamped T4 and the sk-buff corresponding to the packet is stored without releasing the memory. Once after receiving `N' packets, the timestamp T1,T2,T3 and T4 from the TWAMP packets are copied and sent back to the session-client for APC, RTT and other performance measurements through Netlink sockets).
Regarding claim 13,
Ganapathy further teaches
wherein the latency measurement includes a plurality of duration values corresponding the plurality of network sockets based on the one or more second connection protocol packets being communicated via different network sockets ( Page I - This thesis focus on finding a suitable architecture and an optimized algorithm to send and receive measurement packets over high-speed links. Five different architectures: Native UDP sockets, LibPcap, Loadable Kernel Modules, Netmap and Data Plane Development Kit (DPDK) are investigated for fast packets processing in Linux systems. Also, the optimized algorithm(s) that suits the specific architecture for sending and receiving measurement packets at various rates are designed. The performance metrics obtained from the measurement systems tested against various rates and burst size using different architectures are compared - Page 6 - For one-way delay measurements clocks needs to be synchronized at Sender and Reflector in both directions (T2-T1 and T4-T3). However, for Round-Trip Time (RTT) measurements it is not needed, since only T4 and T1 are used (RTT = T4-T1) and both the time stamps are generated at the sender. Page 18 where the base modules for generating, sending and reflecting TWAMP measurements packets on sender and receiver using the above discussed architectures (UDP socket, LibPcap, Kernel Module, Netmap and DPDK) over the network discussed in next section.- Page 26 - From the session-client the Netlink sockets are created similar to native UDP sockets. Page 55 - simple research experiment was conducted at the receiver, where the incoming TWAMP packets are timestamped enabling different options mentioned below. The results obtained for 50 packets send at 6 Gbps using different timestamping options are shown in table 2 – Note: the system compares latency metric like RTT across multiple socket types and architectures including UDP sockets , Net filters sockets, Libpcap, …, these RTTs (Duration values ) vary based on which socket/architecture is used)
Regarding claim 15,
Ganapathy teaches at least one non-transitory computer-readable storage medium storing instructions that, when executed by at least one processor of a system( Page -16, Page 0036, Fig.15), cause the system to::
generate a first data record that includes a first timestamp associated with a first connection protocol packet, wherein the first timestamp indicates a time that the first connection protocol packet is transmitted from an application client to an application server on a remote system via a plurality of network sockets of that are associated with the application client ( Page 1 - The basic principle is to inject probe packets into the network. These packets are time-stamped at sender and receiver - Page 6 - Some important fields in the TWAMP packet which helps in the performance measurements are Sequence Number, Sender sending timestamp (T1), Reflector receiving time-stamp (T2), Receiver sending timestamp(T3). Also Sender receiving time-stamp (T4) can be recorded locally on sender for measuring round trip delay. Page 5 - TWAMP is very similar to TWAMP, but with a change in the architecture, where session-receiver is replaced by a session-reflector. Unlike the session-receiver in the OWAMP, session-reflector in TWAMP does not collect any measurement data, but instead, on reception of any TWAMP measurement packet from the session-sender a response is sent back to the session-sender. Page 8 - session-sender and session-reflector applications running on user-space are built to communicate with the host network stack using the native UDP sockets using the send() system calls. Page 10 – TWAMP measurement packets can be generated and sent at required rate with timestamps of high precision to measure the performance of the high-speed links with high accuracy – Page 20 - Before sending out, the packets are timestamped with the time `T1' in nano-second precision using clock getime system call. The timestamp obtained using the above call is store on struct time spec object which provides the provision to store timestamp in nano-second accuracy - Page 23 - the TWAMP fields are filled in advance except the sending timestamp, which will be update before sending the packet for more accuracy – This section describes the high-level design used for the session-sender and session-reflector module designed using LibPcap socket. From the session-client module, the following parameters are passed to the session-sender module for creating the session - the UDP socket is created for communicating with host network stack. On struct sockaddr in, the destination IP and port received from the session-client are used for sending out the TWAMP measurement packets. On the other hand, to receive the packets from reflector, the socket is with bind() with sender IP and port on which the sender is listening. – Note: the examiner interprets the session reflector as application server that sit on a remote system and is waiting for session to be initiated to provide a service );
parse subsequent packets communicated between the application client and the application server to identify, while the plurality of network sockets are open, one or more second connection protocol packets that are expected to follow the first connection protocol packet according to a connection protocol sequence (Page 6 - TWAMP defines two set of protocols: control protocol for setting up the TWAMP sessions and other for measuring the performance of the monitored links through transmission and reception of TWAMP measurement packets. A session protocol helps in initiating a TWAMP session between a sender and a reflector, where the information about addresses, ports and security mode is agreed upon during the start of the TWAMP session and another test protocol for transmission and reception of measurement packets. – Some important fields in the TWAMP packet which helps in the performance measurements are Sequence Number. Page 7 - The reflector is consider to be active all the time. On reception of TWAMP-Test packets from the sender, the reflector sends response test packet to the each received TWAMP-Test packet, like a ping-type reflector where response is immediately sent out for each packet – The Last Sequence Number in train _eld instructs the reflector to wait till the last sequence number as mentioned in the packet arrives before sending the response packets. Page 22 - Once the measurement session is completed the socket can be closed using close(sock fd) Page 23 - To receive the reflected packets on session-sender, pcap loop() is called repeatedly over the socket to receive and deliver the TWAMP payload. On reception, the packets are timestamped T4 and the packets are copied to the pre-allocated buffers. Upon reception of the last packet in the train the results are sent to session-client for APC, RTT and other performance measurements - First step in the session-sender is to create a LibPcap socket which can communicate with the network stack);
associating respective timestamps with the one or more second connection protocol packets in response to identifying the one or more second connection protocol packets via the parsing (Page 6 - Some important _elds in the TWAMP packet which helps in the performance measurements are Sequence Number, Sender sending timestamp (T1), Reflector receiving time-stamp (T2), Receiver sending timestamp(T3). Also Sender receiving time-stamp (T4) (not in the TWAMP _elds) can be recorded locally on Sender for measuring round-trip delays Page 27 - Each incoming packet has to be inspected by the application to confirm the packet is a TWAMP measurement packet or not – Page 30 – On arrival of TWAMP packets from sender, the packets are received using the function: nm nextpkt(fd, pktHeader) and timestamped `T2' – Page 36 - The received packets are timestamped (T4). The received packets are stored. After receiving Nth packet, the results (T1, T2, T3 and T4) are sent to the session-client for APC and other network performance measurements and the corresponding packet buffers are made free);
determining a latency measurement for the application client based on the first timestamp included in the first data record and the respective timestamps associated with the one or more second connection protocol packets, the latency measurement describing a duration of the connection protocol sequence (Page 2 - send and receive packets at higher rates has less or no correlation with the modules which calculates the network performance (like available bandwidth, round-trip time, latency - Page 6 - Some important fields in the TWAMP packet which helps in the performance measurements are Sequence Number, Sender sending timestamp (T1), Reflector receiving time-stamp (T2), Receiver sending timestamp(T3). Also Sender receiving time-stamp (T4) (not in the TWAMP fields) can be recorded locally on Sender for measuring round-trip delays - Page 10 – TWAMP measurement packets can be generated and sent at required rate (even at wire-speed) with timestamps of high precision to measure the performance of the high-speed links with high accuracy. Page 20 - Before sending out, the packets are timestamped with the time `T1' in nano-second precision using clock getime(CLOCK REALTIME, time) system call. – Page 22 - on session-sender to receive the reflected packets, recvfrom() call over the socket delivers the TWAMP payload. On reception, the packets are timestamped T4 and the packets is copied to the pre-allocated buffers. Upon reception of the last packet in the train the results are sent to session-client for performance measurements. Page 36 - The received packets are timestamped (T4). The received packets are stored. After receiving Nth packet, the results (T1, T2, T3 and T4) are sent to the session-client for APC and other network performance measurements); and
transmitting the latency measurement to the application client (Page 22 - on session-sender to receive the reflected packets, recvfrom() call over the socket delivers the TWAMP payload. On reception, the packets are timestamped T4 and the packets is copied to the pre-allocated buffers. Upon reception of the last packet in the train the results are sent to session-client for performance measurements – Page 8 TWAMP-Test packets are transported using UDP. Mostly, in the measuring device, session-sender and session-reflector applications running on user-space are built to communicate with the host network stack using the native UDP sockets using the send() or sendto() system calls.- See Also Page 13,26 - These sockets are bi-directional can help to send the session parameter down to kernel module and upon completion of TWAMP measurements, results can be sent back to session-client via Netlink sockets – Page 27 -Once after receiving `N' packets, the timestamp T1,T2,T3 and T4 from the TWAMP packets are copied and sent back to the session-client for APC, RTT and other performance measurements through Netlink sockets. The sk_bu are freed and memory for 'N' next train of TWAMP packets are allocated in the sk_bu and the process continues. Finally, on reception of results for all the trains sent, the Netlink socket is closed. ).
Ganapathy teaches transmitting the latency measurement to the application client and then closing the plurality of sockets (Page 22,Page 26-27). However, Ganapathy does not explicitly teach
while the plurality of network sockets are closed, transmitting the latency measurement to the application client.
Susarla teaches
while the plurality of network sockets are closed, transmitting the latency measurement (Claim 3 - continuing to collect data after the network connection is closed; overwriting at least a portion of the data collected after the network connection is closed, when a threshold amount of the data collected has been buffered and there is no connection over the network socket –¶0052 - trace and I/O statistics are written for a storage volume, when volume collection is enabled. Statistics may include, in one aspect, performance data, such as, IOPS (number of input/output operations that are processed per second), CPU utilization, cache statistics, and the like. Other relevant statistics that can be derived from the I/O activity may also be stored and/or reported in various aspects. ¶ 0059 - the client can store the trace/statistics data in a system readable file that can be exchanged via standard methods to other systems for archival purposes. the connection module closes the connection socket on which the I/O trace data is being transmitted. This may be based on a "close" command from the client. the data collection module collects in-memory data (also referred to as in-memory logging), while waiting for a new network connection. the connection socket uses a dedicated management network port for sending collected data. In general, the connection socket will follow a specific transport protocol, such as, for example the TCP/IP protocol. However, it will be understood that other protocols may also be utilized in carrying out the teachings described herein – Claim 10 - continue to collect data after the network connection is closed; and overwrite at least a portion of the data collected after the network connection is closed, when a threshold amount of the data collected has been buffered and there is no connection over the network socket – ¶0037 - the connection module communicates with the network adapter 240 and manages one or more connections for communicating I/O operations or trace data for evaluation - Note: Since the system is designed to handle more than one connection, then all active /tracing sockets are closed. – the system will continue to send the data internally to the buffer for the client app to access it ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify transmitting the latency measurement to the application client and then closing the plurality of sockets taught by Ganapathy to include the teachings of Susarla. The motivation for doing so is to allow the system to continue data collection and buffering during socket closures to ensure data integrity and system availability.
Regarding claim 16,
Ganapathy further teaches
wherein the latency measurement is transmitted by an operating system (OS) kernel level (Page 13 – the final architecture to send TWAMP measurements, then a suitable method to communicate between kernel module and the TWAMP-client application running on the user-space has to be enabled for initiating the TWAMP session and to send back the results obtained from the reflected probe packets for performance measurements - Page 22 - on session-sender to receive the reflected packets, recvfrom() call over the socket delivers the TWAMP payload. On reception, the packets are timestamped T4 and the packets is copied to the pre-allocated buffers. Upon reception of the last packet in the train the results are sent to session-client for performance measurements. Page 27 - on session-sender, the incoming TWAMP packets are received by Net filter hooks at PRE ROUTING stage before the packet is processed by the native host stack. Each incoming packet has to be inspected by the application to confirm the packet is a TWAMP measurement packet or not. The TWAMP packets are timestamped T4 and the sk-buff corresponding to the packet is stored without releasing the memory. Once after receiving `N' packets, the timestamp T1,T2,T3 and T4 from the TWAMP packets are copied and sent back to the session-client for APC, RTT and other performance measurements through Netlink sockets).
Claims 3,10, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Ganapathy in view of Susarla further in view of Mouline et al. Publication No. US 2013/0297596 A1 ( Mouline hereinafter).
Regarding claim 3,
Ganapathy does not explicitly teach
transmitting, from the local device to the remote system, the latency measurement for the application client in connection with a dynamic load-balancing operation of the application server
However, Mouline teaches
transmitting, from the local device to the remote system, the latency measurement for the application client in connection with a dynamic load-balancing operation of the application server (¶ 0022 - As seen in FIG. 4, the performance of locally available servers is monitored to determine the performance of available servers. The performance may be measured using conventional metrics, such as availability, response time, etc. In an embodiment, the performance of potential local servers may be monitored using metrics obtained using a network monitoring server 212 or an application which periodically probes the available servers. The network monitoring server may be an external performance monitoring source, which monitors performance as seen by clients, therefore taking into account actual routing, network node performance, etc.- ¶ 0025 - the DNS management system selects whether to deliver the distance-based DNS records or the performance-based DNS records. The selection of which record to deliver can be based on certain criteria, such as performance, cost, load balancing, etc the performance-based DNS records may be selected only if it improves performance by a certain threshold as compared to the distance-based routing DNS records. For instance, the system may deliver the performance- based DNS records only if response time is improved by a certain amount).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ganapathy to include the teachings of Mouline. The motivation for doing so is to allow the system to determine if performance is improved to select a different performance based DNS record (¶ 0025 – Mouline).
Regarding claim 10,
Ganapathy does not explicitly teach
wherein the process further comprises: transmitting, to the remote system, the latency measurement for the application client in connection with a dynamic load-balancing operation of the application server.
However, Mouline teaches
wherein the process further comprises: transmitting, to the remote system, the latency measurement for the application client in connection with a dynamic load-balancing operation of the application server (¶0022 - As seen in FIG. 4, the performance of locally available servers is monitored to determine the performance of available servers). The performance may be measured using conventional metrics, such as availability, response time, etc. In an embodiment, the performance of potential local servers may be monitored using metrics obtained using a network monitoring server or an application which periodically probes the available servers. The network monitoring server may be an external performance monitoring source, which monitors performance as seen by clients, therefore taking into account actual routing, network node performance, etc.- ¶ 0025 - the DNS management system selects whether to deliver the distance-based DNS records or the performance-based DNS records. The selection of which record to deliver can be based on certain criteria, such as performance, cost, load balancing, the performance-based DNS records may be selected only if it improves performance by a certain threshold as compared to the distance-based routing DNS records. For instance, the system may deliver the performance- based DNS records only if response time is improved by a certain amount).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ganapathy to include the teachings of Mouline. The motivation for doing so is to allow the system to determine if performance is improved to select a different performance based DNS record (¶0025 – Mouline).
Regarding claim 17,
Ganapathy does not explicitly teach
wherein the instructions further cause the system to: transmit, to the remote system, the latency measurement for the application client in connection with a dynamic load-balancing operation of the application server.
However, Mouline teaches
wherein the instructions further cause the system to: transmit, to the remote system, the latency measurement for the application client in connection with a dynamic load-balancing operation of the application server. (¶0022 - As seen in FIG. 4, the performance of locally available servers is monitored to determine the performance of available servers. The performance may be measured using conventional metrics, such as availability, response time, etc. In an embodiment, the performance of potential local servers may be monitored using metrics obtained using a network monitoring server 212 or an application which periodically probes the available servers. The network monitoring server may be an external performance monitoring source which monitors performance as seen by clients, therefore taking into account actual routing, network node performance, etc.- ¶0025 - the DNS management system selects whether to deliver the distance-based DNS records or the performance-based DNS records. The selection of which record to deliver can be based on certain criteria, such as performance, cost, load balancing, the performance-based DNS records may be selected only if it improves performance by a certain threshold as compared to the distance-based routing DNS records. For instance, the system may deliver the performance- based DNS records only if response time is improved by a certain amount).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ganapathy to include the teachings of Mouline. The motivation for doing so is to allow the system to determine if performance is improved to select a different performance based DNS record (¶0025 – Mouline).
Claims 4,11,18 are rejected under 35 U.S.C. 103 as being unpatentable over Ganapathy in view of Susarla further in view of Li et al. Publication No. US 2022/0217088 A1 ( Li hereinafter)
Regarding claim 4,
Ganapathy does not explicitly teach
wherein the connection protocol sequence is a transmission control protocol (TCP) handshake according to which the first connection protocol packet comprises a SYN header value.
However, Li teaches
connection protocol sequence is a transmission control protocol (TCP) handshake according to which the first connection protocol packet comprises a SYN header value (¶0069 - if the method determines that a TCP data packet includes a SYN flag, the method skips the addition of congestion data since this packet is used for a three-way handshake to initiate the TCP session – See Also ¶0103).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ganapathy to include the teachings of Li. The motivation for doing so is to allow the system to identify a SYN flag as header value that indicates initiation of the TCP connection (three-way handshake) ( LI - ¶ 0069).
Regarding claim 11,
Ganapathy does not explicitly teach
wherein the connection protocol sequence is a transmission control protocol (TCP) handshake according to which the first connection protocol packet comprises a SYN header value.
However, Li teaches
connection protocol sequence is a transmission control protocol (TCP) handshake according to which the first connection protocol packet comprises a SYN header value (¶ 0069 - if the method determines that a TCP data packet includes a SYN flag, the method skips the addition of congestion data since this packet is used for a three-way handshake to initiate the TCP session – See Also ¶0103).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ganapathy to include the teachings of Li. The motivation for doing so is to allow the system to identify a SYN flag as header value that indicates initiation of the TCP connection (three-way handshake) ( LI - ¶ 0069).
Regarding claim 18,
Ganapathy does not explicitly teach
wherein the connection protocol sequence is a transmission control protocol (TCP) handshake according to which the first connection protocol packet comprises a SYN header value.
However, Li teaches
connection protocol sequence is a transmission control protocol (TCP) handshake according to which the first connection protocol packet comprises a SYN header value (¶0069 - if the method determines that a TCP data packet includes a SYN flag, the method skips the addition of congestion data since this packet is used for a three-way handshake to initiate the TCP session – See Also Para 0103).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ganapathy to include the teachings of Li. The motivation for doing so is to allow the system to identify a SYN flag as header value that indicates initiation of the TCP connection (three-way handshake) ( Li - ¶ 0069).
Claims 5,12,19 are rejected under 35 U.S.C. 103 as being unpatentable over Ganapathy in view of Susarla further in view of Abley et al. Publication No. US 2022/0029924 A1 ( Abley hereinafter)
Regarding claim 5,
Ganapathy does not explicitly teach
wherein the connection protocol sequence is a domain name system (DNS) sequence, and wherein the one or more second connection protocol packets are identified based on having an opposite value of a QR bit compared to a QR bit of the first connection protocol packet.
Abley teaches
wherein the connection protocol sequence is a domain name system (DNS) sequence, and wherein the one or more second connection protocol packets are identified based on having an opposite value of a QR bit compared to a QR bit of the first connection protocol packet (¶ 0029 - In terms of the DNS based example, the queries 30 and responses 32 can be packet-based communications following the DNS protocol using the two types of DNS messages, i.e. queries 30 and replies 32, both having the same format. The precise format of a DNS message was originally specified in RFC 1035 and. The flag field can consist of several sub-fields. The first can be a single bit ("QR") which indicates if the message is a query (0) or a reply (1).). Claim 5 - wherein a DNS protocol is
utilized to structure the first request traffic, the second query request traffic, the first response traffic and the second response traffic).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ganapathy to include the teachings of Abley. The motivation for doing so is to allow the system to determine traceability of network request traffic over a communications network for reducing strain in traffic processing resources ( Abley - Abstract).
Regarding claim 12,
Ganapathy does not explicitly teach
wherein the connection protocol sequence is a domain name system (DNS) sequence, and wherein the one or more second connection protocol packets are identified based on having an opposite value of a QR bit compared to a QR bit of the first connection protocol packet.
Abley teaches
wherein the connection protocol sequence is a domain name system (DNS) sequence, and wherein the one or more second connection protocol packets are identified based on having an opposite value of a QR bit compared to a QR bit of the first connection protocol packet (¶ 0029 - In terms of the DNS based example, the queries 30 and responses 32 can be packet-based communications following the DNS protocol using the two types of DNS messages, i.e. queries 30 and replies 32, both having the same format. The precise format of a DNS message was originally specified in RFC 1035 and. The flag field can consist of several sub-fields. The first can be a single bit ("QR") which indicates if the message is a query (0) or a reply (1).). Claim 5 - wherein a DNS protocol is
utilized to structure the first request traffic, the second query request traffic, the first response traffic and the second response traffic).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ganapathy to include the teachings of Abley. The motivation for doing so is to allow the system to determine traceability of network request traffic over a communications network for reducing strain in traffic processing resources ( Abley - Abstract).
Regarding claim 19,
Ganapathy does not explicitly teach
wherein the connection protocol sequence is a domain name system (DNS) sequence, and wherein the one or more second connection protocol packets are identified based on having an opposite value of a QR bit compared to a QR bit of the first connection protocol packet.
Abley teaches
wherein the connection protocol sequence is a domain name system (DNS) sequence, and wherein the one or more second connection protocol packets are identified based on having an opposite value of a QR bit compared to a QR bit of the first connection protocol packet (¶ 0029 - In terms of the DNS based example, the queries 30 and responses 32 can be packet-based communications following the DNS protocol using the two types of DNS messages, i.e. queries 30 and replies 32, both having the same format. The precise format of a DNS message was originally specified in RFC 1035 and. The flag field can consist of several sub-fields. The first can be a single bit ("QR") which indicates if the message is a query (0) or a reply (1).). Claim 5 - wherein a DNS protocol is
utilized to structure the first request traffic, the second query request traffic, the first response traffic and the second response traffic).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ganapathy to include the teachings of Abley. The motivation for doing so is to allow the system to determine traceability of network request traffic over a communications network for reducing strain in traffic processing resources ( Abley - Abstract).
Claims 7,14,20 are rejected under 35 U.S.C. 103 as being unpatentable over Ganapathy in view of Susarla further in view of Guim Bernat et al. Publication No. US 2021/0255897 A1 ( Guim Bernat hereinafter)
Regarding claim 7,
Ganapathy further teaches
wherein the first data record is stored in an OS kernel structure that is configured to be inaccessible by the application client (Page 8 - In Linux, a standardized buffer format for handling the packets at kernel level is called sk buff. The application data which is fragmented, are queued in the transport layer - Page 11 - In Linux, sk buff is a common data structure for network related queues and buffers in the kernel space. It contains all the control information required for the packet. The sk buff elements are arranged in doubly-linked list fashion. Kernel stores the packet in the format specified in sk buff for the packet to be sent or received packets – Page 12 - LibPcap works in user-space and less OS dependent. But its library has to emulate the functionality the of Berkeley Packet Filter [29] for filtering and buffering the packet at kernel level. The buffer at user-level is used to store packets coming from the kernel and, it prevents the user-level application from accessing kernel-managed memory
However, Ganapathy does not explicitly teach that the structure is a database.
Guim Bernat teaches a kernel database (¶0033 – Kernel database).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ganapathy to include the teachings of Guim Bernat. The motivation for doing so is to allow the system to eliminate the overhead of switching between user space and kernel space.
Regarding claim 14,
Ganapathy further teaches
wherein the first data record is stored in an OS kernel structure that is configured to be inaccessible by the application client (Page 8 - In Linux, a standardized buffer format for handling the packets at kernel level is called sk buff. The application data which is fragmented, are queued in the transport layer - Page 11 - In Linux, sk buff is a common data structure for network related queues and buffers in the kernel space. It contains all the control information required for the packet. The sk buff elements are arranged in doubly-linked list fashion. Kernel stores the packet in the format specified in sk buff for the packet to be sent or received packets – Page 12 - LibPcap works in user-space and less OS dependent. But its library has to emulate the functionality the of Berkeley Packet Filter [29] for filtering and buffering the packet at kernel level. The buffer at user-level is used to store packets coming from the kernel and, it prevents the user-level application from accessing kernel-managed memory
However, Ganapathy does not explicitly teach that the structure is a database.
Guim Bernat teaches a kernel database (¶0033 – Kernel database).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ganapathy to include the teachings of Guim Bernat. The motivation for doing so is to allow the system to eliminate the overhead of switching between user space and kernel space.
Regarding claim 20,
Ganapathy further teaches
wherein the first data record is stored in an OS kernel structure that is configured to be inaccessible by the application client (Page 8 - In Linux, a standardized buffer format for handling the packets at kernel level is called sk buff. The application data which is fragmented, are queued in the transport layer - Page 11 - In Linux, sk buff is a common data structure for network related queues and buffers in the kernel space. It contains all the control information required for the packet. The sk buff elements are arranged in doubly-linked list fashion. Kernel stores the packet in the format specified in sk buff for the packet to be sent or received packets – Page 12 - LibPcap works in user-space and less OS dependent. But its library has to emulate the functionality the of Berkeley Packet Filter [29] for filtering and buffering the packet at kernel level. The buffer at user-level is used to store packets coming from the kernel and, it prevents the user-level application from accessing kernel-managed memory
However, Ganapathy does not explicitly teach that the structure is a database.
Guim Bernat teaches a kernel database (¶0033 – Kernel database).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Ganapathy to include the teachings of Guim Bernat. The motivation for doing so is to allow the system to eliminate the overhead of switching between user space and kernel space.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Oscar A Louie can be reached at (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445