Details
Claims 1-20 are pending.
Claims 1-4, 8-15 and 19-20 are rejected.
Claims 5-7 and 16-18 are objected to.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 4, 8-12, 15 and 19-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Geng et al (Pub. No.: 2022/0345412 A1).
As per claim 1, Geng discloses a computer-implemented method comprising: - receiving, at a sender bump-on-the-wire (Geng, Fig 1 item 112, 113, wherein NIC 112 and/or Netcam Module 113 alone or in combination can be the sender bump-on-the-wire) associated with a sender host (Geng, Fig 1 item 110 “Sender Host”), a data packet destined for a receiver host (Geng, Fig 1,3, paragraph 0025, wherein “when sender host 310 transmits a packet to receiver host 320”), the data packet transmitted by the sender host (Geng, Fig 1,3, paragraph 0025, wherein “when sender host 310 transmits a packet to receiver host 320”), the sender bump-on-the-wire at a position on a data path between the sender host and a receiver host (Geng, Fig 1 item, wherein as shown in Fig 1 a sender host is connected to a receiver host through a network an so when packet is generated by sender host it will be received by the NIC/Netcam Module and then sent to the receiver host. Hence the NIC/Netcam Module is positioned on a data path between the sender host and a receiver host as claimed), wherein the sender host, the receiver host, the sender bump-on-the-wire, and a receiver bump-on-the-wire are clock-synchronized with respect to one another (Geng, Fig 1, paragraph 0022, wherein “Netcam system 140 includes clock synchronization system 141. Netcam system 140 may monitor data observed by the netcam modules implemented in hosts, such as netcam module 131 and 133. Netcam system 140 may detect conditions that require action by the netcam modules and may transmit instructions to affected netcam modules to take coordinated action for a given data flow. Clock synchronization system 141 synchronizes one or more components of each host, such as the NIC, the kernel, or any other component within which the netcam modules act. Details of clock-synchronization are described in commonly-owned U.S. Pat. No. 10,623,173, issued Apr. 14, 2020, the disclosure of which is hereby incorporated by reference herein in its entirety. Each host is synchronized to an extremely precise degree to a same reference clock, enabling precise timestamping across hosts regardless of host location, bandwidth conditions of the host, jitter, and the like”); - recording, at the sender bump-on-the-wire, a sender timestamp of the data packet (Geng, Fig 1, 3, paragraph 0025, wherein “As depicted in FIG. 3, when sender host 310 transmits a packet to receiver host 320, netcam module 113 of receiver [sender] host 320 [310] records sender timestamp 311 … Sender timestamps may be stored in buffers 111 and 131, appended to packets, transmitted for storage in netcam system 140, or any combination thereof”;Fig 6 step 602, paragraph 0043, wherein “Data flow 600 begins with one or more sender hosts (e.g., sender host 110) sending 602 a data flow and applying sender timestamps (e.g., sender timestamp 311)”); - receiving, from a receiver bump-on-the-wire associated with the receiver host, a receiver timestamp of the data packet along with auxiliary information (Geng, Fig 1, 3, paragraph 0025, wherein “Similarly, when receiver host 320 receives the packet, netcam module 133 of receiver host 320 applies receiver timestamp 321. The timestamp reflects a time at which the data packet was sent or received by the relevant component on which the netcam module is installed (e.g., NIC, kernel, etc.)”;Fig 6, paragraph 0043, wherein “Netcam activity then occurs. As described above, the netcam activity may occur at the sender host(s) (e.g., by receiving ACK packets indicating receiver timestamps and using netcam modules to compute one-way delay)”Paragraph 0030, wherein “In some embodiments, data flows may be associated with different priorities. Netcam modules may determine priority of data flows either based on an explicit identifier (e.g., an identifier of a tier of traffic within a data packet header)”; wherein the priority data indicated by an identifier within a data packet header can be on type of auxiliary information.Paragraph 0035, wherein “For example, a netcam module of any host may determine a flow identifier that identifies a data flow to which a packet belongs based on a combination of source address, destination address, source port number, destination port number, and protocol port number. Other combinations of identifiers may be used to identify a data flow to which a packet is a part” ; wherein source address, destination address, source port number, destination port number, and protocol port number can also be type of auxiliary information); - determining, by the sender bump-on-the-wire, a congestion metric based on the sender timestamp, the receiver timestamp, and the auxiliary information (Geng, paragraph 0026-0027, wherein “Because sender host 310 is synchronized to a same reference clock as receiver host 320, the elapsed time between the time of sender timestamp 311 and receiver timestamp 321 reflects a one-way delay for a given packet. In an embodiment, upon receiving a given packet, receiver host 320 transmits an acknowledgment packet to sender host 310 that indicates receiver timestamp 321, by which netcam module 113 can calculate the one-way delay by subtracting the sender timestamp 311 from the receiver timestamp 321 … The netcam system then determines whether the one-way delay exceeds a threshold. For example, after calculating one-way delay, sender host 110 may compare the one-way delay to the threshold … As will be described further below, different thresholds may apply to different data flows depending on one or more attributes of the data flows, such as their priority”; Thus, a congestion metric is determined using calculate one-way delay using the sender timestamp and the receiver timestamp and then compare it to a threshold that is determined using auxiliary information (a threshold determined using one or more attributes of the data flows, such as their priority) ); and - transmitting, from the sender bump-on-the-wire to the sender host, a congestion signal based on the congestion metric (Geng, paragraph 0019, wherein “Netcam module 113 monitors data flow for certain conditions, and triggers functionality based on the monitored data. As an example, netcam module 113 may, responsive to detecting network congestion, instruct all hosts that are part of a data flow to perform one or more of various activities”; wherein the instruction sent to all of the hosts (including the sender host) in response to detection the network congestion can be the congestion signal as claimed);
As per claim 2, claim 1 is incorporated and Geng further discloses wherein the sender bump-on-the-wire is a smart Network Interface Card (NIC) (Geng, paragraph 0018, 0023, wherein “NIC 112 may be any kind of network interface card, such as a smart NIC. NIC 112 interfaces sender host 110 and network 120”, “There are many advantages of netcam environment 100. The netcam modules are edge-based, given that they can run in the kernel or in NICs (e.g., smart NICs) of a host (e.g., physical host, virtual machine, or any other form of host)”);
As per claim 4, claim 1 is incorporated and Geng further discloses wherein the sender bump-on-the-wire and the receiver bump-on-the-wire define a time perimeter different from other time perimeters defined by other bumps-on-the-wire that are implemented on a same network as the sender bump-on-the-wire and the receiver bump-on-the-wire (Geng, Fig 1, paragraph 0022, wherein “Netcam system 140 includes clock synchronization system 141. Netcam system 140 may monitor data observed by the netcam modules implemented in hosts, such as netcam module 131 and 133. Netcam system 140 may detect conditions that require action by the netcam modules and may transmit instructions to affected netcam modules to take coordinated action for a given data flow. Clock synchronization system 141 synchronizes one or more components of each host, such as the NIC, the kernel, or any other component within which the netcam modules act. Details of clock-synchronization are described in commonly-owned U.S. Pat. No. 10,623,173, issued Apr. 14, 2020, the disclosure of which is hereby incorporated by reference herein in its entirety. Each host is synchronized to an extremely precise degree to a same reference clock, enabling precise timestamping across hosts regardless of host location, bandwidth conditions of the host, jitter, and the like”);
As per claim 8, claim 1 is incorporated and Geng further discloses wherein transmitting the congestion signal comprises appending the congestion signal to an acknowledgment packet sent by the sender bump-on-the-wire to the sender host (Geng, paragraph 0019, wherein “Netcam module 113 monitors data flow for certain conditions, and triggers functionality based on the monitored data. As an example, netcam module 113 may, responsive to detecting network congestion, instruct all hosts that are part of a data flow to perform one or more of various activities”);
As per claim 9, claim 1 is incorporated and Geng further discloses wherein the congestion signal is an explicit congestion notification (Geng, paragraph 0019, wherein “Netcam module 113 monitors data flow for certain conditions, and triggers functionality based on the monitored data. As an example, netcam module 113 may, responsive to detecting network congestion, instruct all hosts that are part of a data flow to perform one or more of various activities”);
As per claim 10, claim 1 is incorporated and Geng further discloses wherein the congestion metric is an average congestion (Geng, paragraph 0026-0027, wherein “Because sender host 310 is synchronized to a same reference clock as receiver host 320, the elapsed time between the time of sender timestamp 311 and receiver timestamp 321 reflects a one-way delay for a given packet. In an embodiment, upon receiving a given packet, receiver host 320 transmits an acknowledgment packet to sender host 310 that indicates receiver timestamp 321, by which netcam module 113 can calculate the one-way delay by subtracting the sender timestamp 311 from the receiver timestamp 321 … The netcam system then determines whether the one-way delay exceeds a threshold. For example, after calculating one-way delay, sender host 110 may compare the one-way delay to the threshold … As will be described further below, different thresholds may apply to different data flows depending on one or more attributes of the data flows, such as their priority”);
Claim 11 is rejected under the same rationale as claim 1.
As per claim 12, Geng discloses a computer-implemented method comprising: - receiving, at a sender bump-on-the-wire (Geng, Fig 1 item 112, 113, wherein NIC 112 and/or Netcam Module 113 alone or in combination can be the sender bump-on-the-wire) associated with a sender host (Geng, Fig 1 item 110 “Sender Host”), a data packet destined for a receiver host (Geng, Fig 1,3, paragraph 0025, wherein “when sender host 310 transmits a packet to receiver host 320”), the data packet transmitted by the sender host (Geng, Fig 1,3, paragraph 0025, wherein “when sender host 310 transmits a packet to receiver host 320”), the sender bump-on-the-wire at a position on a data path between the sender host and a receiver host (Geng, Fig 1 item, wherein as shown in Fig 1 a sender host is connected to a receiver host through a network an so when packet is generated by sender host it will be received by the NIC/Netcam Module and then sent to the receiver host. Hence the NIC/Netcam Module is positioned on a data path between the sender host and a receiver host as claimed), wherein the sender host, the receiver host, the sender bump-on-the-wire, and a receiver bump-on-the-wire are clock-synchronized with respect to one another (Geng, Fig 1, paragraph 0022, wherein “Netcam system 140 includes clock synchronization system 141. Netcam system 140 may monitor data observed by the netcam modules implemented in hosts, such as netcam module 131 and 133. Netcam system 140 may detect conditions that require action by the netcam modules and may transmit instructions to affected netcam modules to take coordinated action for a given data flow. Clock synchronization system 141 synchronizes one or more components of each host, such as the NIC, the kernel, or any other component within which the netcam modules act. Details of clock-synchronization are described in commonly-owned U.S. Pat. No. 10,623,173, issued Apr. 14, 2020, the disclosure of which is hereby incorporated by reference herein in its entirety. Each host is synchronized to an extremely precise degree to a same reference clock, enabling precise timestamping across hosts regardless of host location, bandwidth conditions of the host, jitter, and the like”); - appending, at the sender bump-on-the-wire, a sender timestamp of the data packet to the data packet to generate a modified data packet (Geng, Fig 1, 3, paragraph 0025, wherein “As depicted in FIG. 3, when sender host 310 transmits a packet to receiver host 320, netcam module 113 of receiver [sender] host 320 [310] records sender timestamp 311 … Sender timestamps may be stored in buffers 111 and 131, appended to packets, transmitted for storage in netcam system 140, or any combination thereof”;Fig 6 step 602, paragraph 0043, wherein “Data flow 600 begins with one or more sender hosts (e.g., sender host 110) sending 602 a data flow and applying sender timestamps (e.g., sender timestamp 311)”); - transmitting the modified data packet to the receiver bump-on-the-wire en route to the receiver host (Geng, Fig 1, 3, paragraph 0025, wherein “As depicted in FIG. 3, when sender host 310 transmits a packet to receiver host 320, netcam module 113 of receiver [sender] host 320 [310] records sender timestamp 311 … Sender timestamps may be stored in buffers 111 and 131, appended to packets, transmitted for storage in netcam system 140, or any combination thereof”);- determining, by the receiver bump-on-the-wire, a congestion metric based on the sender timestamp, the receiver timestamp, and auxiliary information (Geng, Fig 1, 3, paragraph 0025, wherein “Similarly, when receiver host 320 receives the packet, netcam module 133 of receiver host 320 applies receiver timestamp 321. The timestamp reflects a time at which the data packet was sent or received by the relevant component on which the netcam module is installed (e.g., NIC, kernel, etc.)”;Fig 6, paragraph 0043, wherein “Netcam activity then occurs. As described above, the netcam activity may occur at … receiver hosts (e.g., where sender timestamps are included in the data flow and netcam modules compute one-way delay therefrom))”Paragraph 0030, wherein “In some embodiments, data flows may be associated with different priorities. Netcam modules may determine priority of data flows either based on an explicit identifier (e.g., an identifier of a tier of traffic within a data packet header)”; wherein the priority data indicated by an identifier within a data packet header can be on type of auxiliary information.Paragraph 0035, wherein “For example, a netcam module of any host may determine a flow identifier that identifies a data flow to which a packet belongs based on a combination of source address, destination address, source port number, destination port number, and protocol port number. Other combinations of identifiers may be used to identify a data flow to which a packet is a part” ; wherein source address, destination address, source port number, destination port number, and protocol port number can also be type of auxiliary information); - determining, by the sender bump-on-the-wire, a congestion metric based on the sender timestamp, the receiver timestamp, and the auxiliary information (Geng, paragraph 0026-0027, wherein “Because sender host 310 is synchronized to a same reference clock as receiver host 320, the elapsed time between the time of sender timestamp 311 and receiver timestamp 321 reflects a one-way delay for a given packet. In an embodiment, upon receiving a given packet, receiver host 320 transmits an acknowledgment packet to sender host 310 that indicates receiver timestamp 321, by which netcam module 113 can calculate the one-way delay by subtracting the sender timestamp 311 from the receiver timestamp 321 … The netcam system then determines whether the one-way delay exceeds a threshold. For example, after calculating one-way delay, sender host 110 may compare the one-way delay to the threshold … As will be described further below, different thresholds may apply to different data flows depending on one or more attributes of the data flows, such as their priority”; Thus, a congestion metric is determined using calculate one-way delay using the sender timestamp and the receiver timestamp and then compare it to a threshold that is determined using auxiliary information (a threshold determined using one or more attributes of the data flows, such as their priority) ); and - transmitting, from the receiver bump-on-the-wire to the sender host, a congestion signal based on the congestion metric (Geng, paragraph 0019, wherein “Netcam module 113 monitors data flow for certain conditions, and triggers functionality based on the monitored data. As an example, netcam module 113 may, responsive to detecting network congestion, instruct all hosts that are part of a data flow to perform one or more of various activities”; wherein the instruction sent to all of the hosts (including the sender host) in response to detection the network congestion can be the congestion signal as claimed);
As per claim 13, claim 12 is incorporated and Geng further discloses wherein the receiver bump-on-the-wire is a smart Network Interface Card (NIC) (Geng, paragraph 0018, 0023, wherein “NIC 112 may be any kind of network interface card, such as a smart NIC. NIC 112 interfaces sender host 110 and network 120”, “There are many advantages of netcam environment 100. The netcam modules are edge-based, given that they can run in the kernel or in NICs (e.g., smart NICs) of a host (e.g., physical host, virtual machine, or any other form of host)”);
As per claim 15, claim 12 is incorporated and Geng further discloses wherein the sender bump-on-the-wire and the receiver bump-on-the-wire define a time perimeter different from other time perimeters defined by other bumps-on-the-wire that are implemented on a same network as the sender bump-on-the-wire and the receiver bump-on-the-wire (Geng, Fig 1, paragraph 0022, wherein “Netcam system 140 includes clock synchronization system 141. Netcam system 140 may monitor data observed by the netcam modules implemented in hosts, such as netcam module 131 and 133. Netcam system 140 may detect conditions that require action by the netcam modules and may transmit instructions to affected netcam modules to take coordinated action for a given data flow. Clock synchronization system 141 synchronizes one or more components of each host, such as the NIC, the kernel, or any other component within which the netcam modules act. Details of clock-synchronization are described in commonly-owned U.S. Pat. No. 10,623,173, issued Apr. 14, 2020, the disclosure of which is hereby incorporated by reference herein in its entirety. Each host is synchronized to an extremely precise degree to a same reference clock, enabling precise timestamping across hosts regardless of host location, bandwidth conditions of the host, jitter, and the like”);
As per claim 19, claim 12 is incorporated and Geng further discloses wherein transmitting the congestion signal comprises appending the congestion signal to an acknowledgment packet sent by the receiver host to the sender host, wherein the receiver bump-on-the-wire intercepts the acknowledgment packet to append the congestion signal (Geng, paragraph 0019, wherein “Netcam module 113 monitors data flow for certain conditions, and triggers functionality based on the monitored data. As an example, netcam module 113 may, responsive to detecting network congestion, instruct all hosts that are part of a data flow to perform one or more of various activities”);
Claim 20 is rejected under the same rationale as claim 12.
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 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Geng et al (Pub. No.: 2022/0345412 A1) in view of Krishan et al (US 2018/0083882 A1).
As per claim 3, claim 1 is incorporated and Geng does not explicitly disclose wherein the sender bump-on-the-wire is a Field Programmable Gate Array (FPGA). However, using FPGA is well known in the art. For example, Krishan discloses wherein the sender bump-on-the-wire is a Field Programmable Gate Array (FPGA) (Krishan, paragraph 0024 “TM 110 may be any suitable entity or entities (e.g., software executing on processor(s) 106, an ASIC, an FPGA, or a combination of software, an ASIC, or an FPGA) for performing one or more aspects associated with traffic management and/or traffic related congestion management. For example, TM 110 may include or represent any programmable unit to discard or allow various messages (e.g., IP messages, Diameter messages, HTTP messages, etc.) based on message priority values and a congestion level of RN 104 and/or another node (e.g., node(s) 102 and 112). In some embodiments, TM 110 may be implemented using processor(s) 106 and/or one or more memories, such as memory 108. For example, TM 110 may utilize processor(s) 106 (e.g., using software stored in local memory) and random access memory (RAM)”).
Therefore, it would have it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to incorporate Geng with Krishan to achieve the claimed limitations because this would allow implanting the netcam function to be executed by devices using Field Programmable Gate Array (FPGA).
As per claim 14, claim 12 is incorporated and Geng does not explicitly disclose wherein the receiver bump-on-the-wire is a Field Programmable Gate Array (FPGA). However, using FPGA is well known in the art. For example, Krishan discloses wherein the receiver bump-on-the-wire is a Field Programmable Gate Array (FPGA) (Krishan, paragraph 0024 “TM 110 may be any suitable entity or entities (e.g., software executing on processor(s) 106, an ASIC, an FPGA, or a combination of software, an ASIC, or an FPGA) for performing one or more aspects associated with traffic management and/or traffic related congestion management. For example, TM 110 may include or represent any programmable unit to discard or allow various messages (e.g., IP messages, Diameter messages, HTTP messages, etc.) based on message priority values and a congestion level of RN 104 and/or another node (e.g., node(s) 102 and 112). In some embodiments, TM 110 may be implemented using processor(s) 106 and/or one or more memories, such as memory 108. For example, TM 110 may utilize processor(s) 106 (e.g., using software stored in local memory) and random access memory (RAM)”).
Therefore, it would have it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to incorporate Geng with Krishan to achieve the claimed limitations because this would allow implanting the netcam function to be executed by devices using Field Programmable Gate Array (FPGA).
Allowable Subject Matter
Claims 5-7 and 16-17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAMZA N ALGIBHAH whose telephone number is (571)270-7212. The examiner can normally be reached 7:30 am - 3: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, Wing Chan can be reached on (571) 272-7493. 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.
/HAMZA N ALGIBHAH/Primary Examiner, Art Unit 2441
Prosecution Insights