Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This action is in response to communication filed on 7/14/2026.
Claims 1-20 are pending.
Claims 1, 4, 7, 8, 9, 11, and 20 have been amended.
Response to Arguments
Applicant's argument(s) filed on 7/14/2026 with respect to claim(s) 1-20 have been fully considered but they are not persuasive.
In the communication field, applicant argues in substance that:
a. Regarding claim(s) 1 and 11, Applicant argues (Remark page(s) 7-8)
“Applicant respectfully submits that the prior art rejections are moot in view of the claims as newly presented. Specifically, claim 1 now recites "a clock synchronization engine coupled to each respective hardware clock and that causes each respective hardware clock to agree upon the predetermined release time." Claim 11 recites "a hardware clock communicatively coupled to a clock synchronization engine, the hardware clock receiving information from the clock synchronization engine that causes the hardware clock to agree to a predetermined release time used by other network devices to release network data packets." Claim 20 recites "communicating, by the network device, with a clock synchronization engine to determine a predetermined release for the data packet and agreed to by other network devices." As discussed in paragraph [0032] of the specification: "The clock synchronization engine 130 can use any of a variety of techniques, for example a fault-tolerant clock synchronization system, techniques based on Precision Time Protocol (PTP), etc., for causing the clocks 106A, 116A-116C, to agree on a packet delivery time." It is respectfully submitted that none of the cited prior art, either individually or when combined, disclose this concept. As such, reconsideration of the application is respectfully requested.”
In response to argument [a], Examiners respectfully disagrees.
Therefore, Bshara teaches this limitation at "[0052] Referring to FIG. 1A, the multicast packet 160 arrives at the plurality of the isolated timing hardware (120 A - 120D) at different times. For example, the multicast packet 160 arrives at isolated timing hardware 120A at 12:00:06pm, arrives at 120B at 12:00:02pm, arrives at 120C at 12:00:04pm and arrives at 120D at 12:00:02pm. The isolated timing hardware (120A - 120D) receives the multicast packet 160, obtain the specified time to deliver the packet, which in this case is 12:00: 10pm, and provides either the packet or information to access the packet at the specified time. Therefore, each isolated timing hardware (120A - 120D) releases the multicast packet to its respective recipient at the same specified time of 12:00: 10pm to deliver the packet, such that the recipients receive the packet near simultaneously at 12:00:10pm, since the delay between the isolated timing hardware and the recipient is within a time tolerance. [0071] FIG.5; the host computing devices 515 can be connected to internal data or dedicated timing networks, denoted as networks 506A, 506B. These internal networks can carry data as well as time information. In some embodiments, one of the internal networks is a dedicated time network that only carries timing information. The internal data and/or dedicated time networks 506A-B can be further connected to one or more reference timekeepers 512, which act as a point of reference for time information delivered via the network. For example, each reference timekeeper 512 may be an atomic clock or a GNSS 510 receiver, and may thus act as a source of highly accurate time information for devices 515 within the network 406. In one embodiment, each different reference timekeeper 512 is synchronized to one another, and therefore shares to a high degree of accuracy a common time. For example, each timekeeper 512 may be synchronized to a common GNSS, such as GPS, with a high degree of accuracy (e.g., tens of nanoseconds. [examiner notes: specified time to deliver the packet (e.g., 12:00:10pm) is equivalent to predetermined release time. Each reference timekeeper 512 is equivalent to Hardware clock synchronized by an engine. Atomic clocks (such as cesium or rubidium standards) are frequently used as reference timekeepers in high-precision systems to ensure that all nodes or components remain accurately synchronized without drifting.].
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
1. Claims 1-3, 11-12 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Bshara (WO 2023240168 A1).
With respect to independent claims:
Regarding claim(s) 1, a system for data packet delivery, comprising:
Bshara teaches a plurality of network interface controllers (NICs), each NIC coupled to a respective receiver device, (Bshara, [0057], FIG.2 shows the isolated timing hardware 220 might be embedded within a network interface card (NIC) coupled to host computing device 215. [0065] Each host computing device 515 includes hardware computer memory and/or processors.) each NIC comprising respective memory and (Bshara, [0057], FIG.2 shows the isolated timing hardware 2220 might be embedded within a network interface card (NIC) coupled to host computing device 215. [0065] Each host computing device 515 includes hardware computer memory and/or processors.) a respective hardware clock, and each NIC configured to: (Bshara, [0035] The time tolerance for future delivery of multicast and/or multiple unicast packets can be determined by how closely the clocks of the various isolated timing hardware associated with the various destination host computing devices are synchronized. [0057] In some of these embodiments, the isolated timing hardware 215 might be embedded within a network interface card (NIC). [0087] FIG.2; a single piece of isolated timing hardware 120/220 may include a packet & time-to-deliver packet receiver 226, a packet storage data structure 222, a packet delivery determination component 230, a data structure manager/packet provider 230, a hardware clock 224, a time synchronization agent 226.)
receive a data packet destined for a first one of the respective receiver device coupled to the NIC, (Bshara, [0051] FIG. 1A depicts a logical model of a sender 140 sending a multicast packet 160 to a plurality of recipients (110A- HOD). As explained previously, the isolated timing hardware devices (120A - 120D) may be respective physical offload cards connected to other hardware of respective host computing devices via a Peripheral Component Interconnect (PCI) Express bus. [0054], Referring to FIG. 1A, the multicast packet 160 arrives at the plurality of the isolated timing hardware (120 A - 120D) at different times. [0057], FIG.2 shows the isolated timing hardware 2220 might be embedded within a network interface card (NIC) coupled to host computing device 215. [0065] Each host computing device 515 includes hardware computer memory and/or processors.)
delay release of the data packet to said first one of the respective receiver
device until reaching a predetermined release time, wherein the data packet is loaded in the memory of the NIC while the release is delayed, and (Bshara, [0056] Referring to FIG. 1C, the unicast packet 164 arrives at the isolated timing hardware (124) at 12:00:06pm. The isolated timing hardware (124) receives the unicast packet 164, obtains the specified time to deliver the packet, which in this case is 12:00: 10pm, and provides either the packet or information to access the packet at the specified time. Therefore, the isolated timing hardware (124) releases the unicast packet to its recipient at the same specified time of 12:00: 10pm to deliver the packet, such that the recipient receives the packet near 12:00: 10pm, since the delay between the isolated timing hardware and the recipient is within a time tolerance. Therefore, the unicast packets are provided by the isolated timing hardware to its respective recipient within a time tolerance of the same future specified time to deliver the packet in this embodiment. [0058], FIG.2; receiver 226 provides the packet to a packet storage data structure 222, possibly through the data structure manager 232. The data structure is managed by the data structure manager/packet provider 232. The receiver 226 also provides the time-to-deliver information to the packet delivery determination component 230, in some embodiments. The packet delivery determination component 230 determines when to deliver the packet based on the time-to-deliver information and the hardware clock 224. [examiner notes: each isolated timing hardware may include a network interface card (NIC) and a packet storage data structure 222.])
release, at the predetermined release time, the data packet in the memory for
delivery to said first one of the respective receiver device; and (Bshara, [0058], FIG. 2, packet receiver 226 receives a packet from a data network 204. [examiner notes: the packet receiver 226 is a component of isolated timing hardware 220. Each isolated timing hardware may include a network interface card (NIC) and a packet storage data structure 222.)
a clock synchronization engine coupled to each respective hardware clock and that
causes each respective hardware clock to agree upon the predetermined release time. (Bshara, [0052] Referring to FIG. 1A, the multicast packet 160 arrives at the plurality of the isolated timing hardware (120 A - 120D) at different times. For example, the multicast packet 160 arrives at isolated timing hardware 120A at 12:00:06pm, arrives at 120B at 12:00:02pm, arrives at 120C at 12:00:04pm and arrives at 120D at 12:00:02pm. The isolated timing hardware (120A - 120D) receives the multicast packet 160, obtain the specified time to deliver the packet, which in this case is 12:00: 10pm, and provides either the packet or information to access the packet at the specified time. Therefore, each isolated timing hardware (120A - 120D) releases the multicast packet to its respective recipient at the same specified time of 12:00: 10pm to deliver the packet, such that the recipients receive the packet near simultaneously at 12:00:10pm, since the delay between the isolated timing hardware and the recipient is within a time tolerance. [0071] FIG.5; the host computing devices 515 can be connected to internal data or dedicated timing networks, denoted as networks 506A, 506B. These internal networks can carry data as well as time information. In some embodiments, one of the internal networks is a dedicated time network that only carries timing information. The internal data and/or dedicated time networks 506A-B can be further connected to one or more reference timekeepers 512, which act as a point of reference for time information delivered via the network. For example, each reference timekeeper 512 may be an atomic clock or a GNSS 510 receiver, and may thus act as a source of highly accurate time information for devices 515 within the network 406. In one embodiment, each different reference timekeeper 512 is synchronized to one another, and therefore shares to a high degree of accuracy a common time. For example, each timekeeper 512 may be synchronized to a common GNSS, such as GPS, with a high degree of accuracy (e.g., tens of nanoseconds. [examiner notes: specified time to deliver the packet (e.g., 12:00:10pm) is equivalent to predetermined release time. Each reference timekeeper 512 is equivalent to Hardware clock synchronized by an engine. Atomic clocks (such as cesium or rubidium standards) are frequently used as reference timekeepers in high-precision systems to ensure that all nodes or components remain accurately synchronized without drifting.])
Regarding claim(s) 11 and 20, they are substantially similar to claim 1 and are rejected in the same way. Further, Bshara teaches “one or more processors” at [0056] Each host computing device 515 includes hardware computer memory and/or processors.
With respect to dependent claims:
Regarding claim(s) 2, the system of claim 1,
Bshara teaches wherein each NIC comprises a respective hardware clock, and wherein each NIC is further configured to: synchronize the hardware clock with each hardware clock of the plurality of NICs; and (Bshara, [0071], FIG.5; in addition to the network, the host computing devices 515 can be connected to internal data or dedicated timing networks, denoted as networks 506A, 506B. These internal networks can carry data as well as time information. In some embodiments, one of the internal networks is a dedicated time network that only carries timing information. The internal data and/or dedicated time networks 506A-B can be further connected to one or more reference timekeepers 512, which act as a point of reference for time information delivered via the network. For example, each reference timekeeper 512 may be an atomic clock or a GNSS 510 receiver, and may thus act as a source of highly accurate time information for devices 515 within the network 406. In one embodiment, each different reference timekeeper 512 is synchronized to one another, and therefore shares to a high degree of accuracy a common time. For example, each timekeeper 512 may be synchronized to a common GNSS, such as GPS, with a high degree of accuracy (e.g., tens of nanoseconds). [examiner notes: each isolated timing hardware may include a network interface card (NIC) and a packet storage data structure 222.])
wherein in releasing the data packet at the predetermined release time, the NIC is configured to release the data packet when the synchronized hardware clock for the NIC indicates the predetermined release time. (Bshara, [0051], FIG.1A; the isolated timing hardware (120A - 120D) might be located in an edge router of the provider network, and the multicast packet would be released from the edge router to the ultimate recipient (110A - 110D) at the time-to-deliver time.[0052] Therefore, each isolated timing hardware (120A - 120D) releases the multicast packet to its respective recipient at the same specified time of 12:00: 10pm to deliver the packet, such that the recipients receive the packet near simultaneously at 12:00:10pm, since the delay between the isolated timing hardware and the recipient is within a time tolerance. [0053] Therefore, each isolated timing hardware (122 A - 122D) releases respective ones of the multiple unicast packets to its respective recipient at the same specified time of 12:00: 10pm to deliver the packet, such that the recipients receive the packet near simultaneously at 12:00: 10pm, since the delay between the isolated timing hardware and the recipient is within a time tolerance. [0057] FIG. 2 depicts an example host computing device 215 in which embodiments of the present disclosure can be implemented. FIG. 2 depicts a logical model of a host computing device 215 providing for multicast, multiple unicast, and/or unicast distribution of messages with guaranteed delivery times and/or delivery time synchronization at the receiving host computing device [...] The host computing device 215 of this embodiment also comprises networking computing resources, such as isolated timing hardware 220, that is outside the control of the compute instances 216 [...] the isolated timing hardware 215 might be embedded within a network interface card (NIC) [...] A time synchronization agent 228 synchronizes a hardware clock 224 using information from a data network or a dedicated timing network 206. [0058] A packet & time-to-deliver packet receiver 226 receives a packet from a data network 204. The receiver 226 provides the packet to a packet storage data structure 222, possibly through the data structure manager 232. The data structure is managed by the data structure manager/packet provider 232. The receiver 226 also provides the time-to-deliver information to the packet delivery determination component 230, in some embodiments. The packet delivery determination component 230 determines when to deliver the packet based on the time-to-deliver information and the hardware clock 224. The packet delivery determination component 230 notifies a data structure manager/packet provider 232 to deliver the packet from the data structure 222 to a destination compute instance 216. [examiner notes: each isolated timing hardware may include a network interface card (NIC) and a packet storage data structure 222.])
Regarding claim(s) 3, the system of claim 2,
Bshara teaches wherein each data packet received by the plurality of NICs is multicasted by a sender device configured to tag the data packet with the predetermined release time. (Bshara, [0058] A packet & time-to-deliver packet receiver 226 receives a packet from a data network 204. The receiver 226 provides the packet to a packet storage data structure 222, possibly through the data structure manager 232 [...] The packet delivery determination component 230 notifies a data structure manager/packet provider 232 to deliver the packet from the data structure 222 to a destination compute instance 216. [0054] Therefore, each isolated timing hardware (122 A - 122D) releases respective ones of the multiple unicast packets to its respective recipient at the same specified time of 12:00: 10pm to deliver the packet, such that the recipients receive the packet near simultaneously at 12:00: 10pm, since the delay between the isolated timing hardware and the recipient is within a time tolerance. [examiner notes: each isolated timing hardware may include a network interface card (NIC) and a packet storage data structure 222.])
Claim(s) 12 is/are substantially similar to claim 2, and is thus rejected under substantially the same rationale.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
2. Claim(s) 4-8, 10, 14-17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bshara in view of Fischer (US20070183415 A1).
Regarding claim(s) 4, the system of claim 1,
Bshara teaches wherein: as part of the ingress pipeline, the NIC is configured to perform operations associated with the receipt of data intended for said first one of the respective receiver device coupled to the NIC; and (Bshara, [0056] Referring to FIG. 1C, the unicast packet 164 arrives at the isolated timing hardware (124) at 12:00:06pm. The isolated timing hardware (124) receives the unicast packet 164, obtains the specified time to deliver the packet, which in this case is 12:00: 10pm, and provides either the packet or information to access the packet at the specified time. Therefore, the isolated timing hardware (124) releases the unicast packet to its recipient at the same specified time of 12:00: 10pm to deliver the packet, such that the recipient receives the packet near 12:00: 10pm, since the delay between the isolated timing hardware and the recipient is within a time tolerance. Therefore, the unicast packets are provided by the isolated timing hardware to its respective recipient within a time tolerance of the same future specified time to deliver the packet in this embodiment. [examiner notes: an ingress pipeline is a mechanism for managing and transforming data as it enters a system. An egress pipeline is a mechanism for managing and transforming data as it leaves a system. The isolated timing hardware (124) or the host computing device 215 comprise a NIC to process/buffer received data and transmit/de-queue received data.])
perform operations associated with the transmission of data from said first one of the respective receiver device. (Bshara, [0056] Referring to FIG. 1C, the unicast packet 164 arrives at the isolated timing hardware (124) at 12:00:06pm. The isolated timing hardware (124) receives the unicast packet 164, obtains the specified time to deliver the packet, which in this case is 12:00: 10pm, and provides either the packet or information to access the packet at the specified time. Therefore, the isolated timing hardware (124) releases the unicast packet to its recipient at the same specified time of 12:00: 10pm to deliver the packet, such that the recipient receives the packet near 12:00: 10pm, since the delay between the isolated timing hardware and the recipient is within a time tolerance. Therefore, the unicast packets are provided by the isolated timing hardware to its respective recipient within a time tolerance of the same future specified time to deliver the packet in this embodiment. [examiner notes: an ingress pipeline is a mechanism for managing and transforming data as it enters a system. An egress pipeline is a mechanism for managing and transforming data as it leaves a system. The isolated timing hardware (124) or the host computing device 215 comprise a NIC to process/buffer received data and transmit/de-queue received data. Each isolated timing hardware may include a network interface card (NIC) and a packet storage data structure 222.])
Bshara does not teach wherein each NIC comprises an ingress pipeline and an egress pipeline, and wherein: as part of the ingress pipeline, as part of the egress pipeline, perform operations associated with the transmission of data from the respective receiver device.
Fischer however in the same field of computer networking teaches wherein each NIC comprises an ingress pipeline and an egress pipeline, and wherein: as part of the ingress pipeline, (Fischer, [0031] A loopback path from egress to ingress on a line card of the packet switch is used to re-introduce an egress packet into the ingress pipeline for additional packet processing. Such a mechanism helps to optimize resources needed for packet processing since resources can be re-used by a packet that follows the loopback path as opposed to excessive replication of resources.)
as part of the egress pipeline, (Fischer, [0031] A loopback path from egress to ingress on a line card of the packet switch is used to re-introduce an egress packet into the ingress pipeline for additional packet processing. Such a mechanism helps to optimize resources needed for packet processing since resources can be re-used by a packet that follows the loopback path as opposed to excessive replication of resources.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Bshara by incorporating the teachings of Fischer. The motivation/suggestion would have been because there is a need to reduce complexity and the amount of packet processing resources needed within the packet switch and to increase processing flexibility (Fischer, [0001]).
Regarding claim(s) 5, the system of claim 4,
Bshara-Fischer teaches wherein each NIC is configured to: as part of the ingress pipeline, (Fischer, [0031] A loopback path from egress to ingress on a line card of the packet switch is used to re-introduce an egress packet into the ingress pipeline for additional packet processing. Such a mechanism helps to optimize resources needed for packet processing since resources can be re-used by a packet that follows the loopback path as opposed to excessive replication of resources.) receive the data packet, delay release of the data packet, and release the data packet at the predetermined release time. (Bshara, [0056] Referring to FIG. 1C, the unicast packet 164 arrives at the isolated timing hardware (124) at 12:00:06pm. The isolated timing hardware (124) receives the unicast packet 164, obtains the specified time to deliver the packet, which in this case is 12:00: 10pm, and provides either the packet or information to access the packet at the specified time. Therefore, the isolated timing hardware (124) releases the unicast packet to its recipient at the same specified time of 12:00: 10pm to deliver the packet, such that the recipient receives the packet near 12:00: 10pm, since the delay between the isolated timing hardware and the recipient is within a time tolerance. Therefore, the unicast packets are provided by the isolated timing hardware to its respective recipient within a time tolerance of the same future specified time to deliver the packet in this embodiment. [examiner notes: an ingress pipeline is a mechanism for managing and transforming data as it enters a system. An egress pipeline is a mechanism for managing and transforming data as it leaves a system. The isolated timing hardware (124) or the host computing device 215 comprise a NIC to process/buffer received data and transmit/de-queue received data. Each isolated timing hardware may include a network interface card (NIC) and a packet storage data structure 222.])
The same motivation to combine as the dependent claim 4 applies here.
Regarding claim(s) 6, the system of claim 4,
Bshara-Fischer teaches wherein each NIC is configured to: as part of the ingress pipeline, receive the data packet; and forward the data packet to the egress pipeline, wherein the NIC is configured to, as part of the egress pipeline: (Fischer, [0031] A loopback path from egress to ingress on a line card of the packet switch is used to re-introduce an egress packet into the ingress pipeline for additional packet processing. Such a mechanism helps to optimize resources needed for packet processing since resources can be re-used by a packet that follows the loopback path as opposed to excessive replication of resources.)
delay release of the data packet until the predetermined release time, and release the data packet at the predetermined release time, wherein in releasing the data packet, (Bshara, [0056] Referring to FIG. 1C, the unicast packet 164 arrives at the isolated timing hardware (124) at 12:00:06pm. The isolated timing hardware (124) receives the unicast packet 164, obtains the specified time to deliver the packet, which in this case is 12:00: 10pm, and provides either the packet or information to access the packet at the specified time. Therefore, the isolated timing hardware (124) releases the unicast packet to its recipient at the same specified time of 12:00: 10pm to deliver the packet, such that the recipient receives the packet near 12:00: 10pm, since the delay between the isolated timing hardware and the recipient is within a time tolerance. Therefore, the unicast packets are provided by the isolated timing hardware to its respective recipient within a time tolerance of the same future specified time to deliver the packet in this embodiment.)
the NIC is configured to loop back the released data packet to the ingress pipeline. (Fischer, [0031] A loopback path from egress to ingress on a line card of the packet switch is used to re-introduce an egress packet into the ingress pipeline for additional packet processing. Such a mechanism helps to optimize resources needed for packet processing since resources can be re-used by a packet that follows the loopback path as opposed to excessive replication of resources.)
The same motivation to combine as the dependent claim 4 applies here.
Regarding claim(s) 7, the system of claim 6,
Bshara-Fischer teaches wherein each of the NICs and each of the receiver devices are coupled to a switch; and (Bshara, [0051], FIG.1A; the isolated timing hardware devices (120A - 120D) may be respective physical offload cards connected to other hardware of respective host computing devices via a Peripheral Component Interconnect (PCI) Express bus. In other embodiments, the isolated timing hardware devices (120A - 120D) might be included in one or more switches, such as a top-of-rack (“TOR”) switch, communicatively coupled to a receiving host computing device that hosts a recipient. In other embodiments, the ultimate recipient (110A - 110D) might be outside of a provider network that would include the isolated timing hardware (120A - 120D).)
wherein for each NIC, in looping the released data packet back to the ingress pipeline, (Fischer, [0031] A loopback path from egress to ingress on a line card of the packet switch is used to re-introduce an egress packet into the ingress pipeline for additional packet processing. Such a mechanism helps to optimize resources needed for packet processing since resources can be re-used by a packet that follows the loopback path as opposed to excessive replication of resources.) the NIC is configured to release, through the switch, the released data packet to said first one of the respective receiver device for the NIC. (Bshara, [0055] The isolated timing hardware (124) might be located in an edge router of the provider network, and the unicast packet would be released from the edge router to the ultimate recipient (114) at the time-to-deliver time. [0056] Referring to FIG. 1C, the unicast packet 164 arrives at the isolated timing hardware (124) at 12:00:06pm. The isolated timing hardware (124) receives the unicast packet 164, obtains the specified time to deliver the packet, which in this case is 12:00: 10pm, and provides either the packet or information to access the packet at the specified time. Therefore, the isolated timing hardware (124) releases the unicast packet to its recipient at the same specified time of 12:00: 10pm to deliver the packet, such that the recipient receives the packet near 12:00: 10pm, since the delay between the isolated timing hardware and the recipient is within a time tolerance. Therefore, the unicast packets are provided by the isolated timing hardware to its respective recipient within a time tolerance of the same future specified time to deliver the packet in this embodiment.)
The same motivation to combine as the dependent claim 4 applies here.
Regarding claim(s) 8, the system of claim 7,
Bshara-Fischer teaches wherein each of the receiver devices is coupled to the switch using cables of equal length. (Bshara, [0053], FIG. IB shows a plurality of isolated timing hardware devices (122 A - 122D), each associated with its respective recipient (112A - 112D). As explained previously, the isolated timing hardware devices (122A - 122D) may be respective physical offload cards connected to other hardware of respective host computing devices via a Peripheral Component Interconnect (PCI) Express bus. In other embodiments, the isolated timing hardware devices (122 A - 122D) might be included in one or more switches, such as a top-of-rack (“TOR”) switch, communicatively coupled to a receiving host computing device that hosts a recipient. [0033] does talk about cables of equal length. For example, financial markets currently take tremendous efforts to physically equalize network delay between market participants, down to ensuring that network cables are of equal length to the market participants, to ensure that one market participant does not receive information before another, thus giving them an unfair advantage.)
The same motivation to combine as the dependent claim 4 applies here.
Regarding claim(s) 10, the system of claim 1,
Bshara-Fischer teaches, wherein the predetermined release time is based on a delay of 1-400 microseconds. (Fischer, [0035] Moreover, the service provider network may synchronize isolated timing hardware across multiple host computing devices within microseconds or nanoseconds to a reference timekeeping device (and thus, within microseconds or nanoseconds of other pieces of isolated timing hardware included in or associated with other host computing devices that are also synchronized to the reference timekeeping device). In some embodiments, the time tolerance for future delivery of multicast and/or multiple unicast packets can be determined by how closely the clocks of the various isolated timing hardware associated with the various destination host computing devices are synchronized. [0056] Referring to FIG. 1C, the unicast packet 164 arrives at the isolated timing hardware (124) at 12:00:06pm. The isolated timing hardware (124) receives the unicast packet 164, obtains the specified time to deliver the packet, which in this case is 12:00: 10pm, and provides either the packet or information to access the packet at the specified time. Therefore, the isolated timing hardware (124) releases the unicast packet to its recipient at the same specified time of 12:00: 10pm to deliver the packet, such that the recipient receives the packet near 12:00: 10pm, since the delay between the isolated timing hardware and the recipient is within a time tolerance. Therefore, the unicast packets are provided by the isolated timing hardware to its respective recipient within a time tolerance of the same future specified time to deliver the packet in this embodiment.)
The same motivation to combine as the dependent claim 4 applies here.
Regarding claim(s) 17, the system of claim 16,
Bshara-Fishcher-Daly teach wherein the network device and the receiver device are coupled to a switch; and (Bshara, [003] FIG. IB shows a plurality of isolated timing hardware devices (122 A - 122D), each associated with its respective recipient (112A - 112D). As explained previously, the isolated timing hardware devices (122A - 122D) may be respective physical offload cards connected to other hardware of respective host computing devices via a Peripheral Component Interconnect (PCI) Express bus. In other embodiments, the isolated timing hardware devices (122 A - 122D) might be included in one or more switches, such as a top-of-rack (“TOR”) switch, communicatively coupled to a receiving host computing device that hosts a recipient.) wherein, in looping the released data packet back to the ingress pipeline, the network device is configured to release, through the switch, the released data packet to the receiver device. (Fischer, [0030] The packet switch may be required to process multiple layers of header in the data packet, for example, some data to be transferred over the network may be encapsulated with a TCP header at the Transport Layer to form a TCP packet, then encapsulated with an IP header at the Network Layer to form an IP packet, then encapsulated with one or more MPLS headers to form a MPLS packet, and then encapsulated with an Ethernet header at the Link Layer to form an Ethernet packet. In such an instance, instead of the packet header processor processing all protocol layers in one pass, the data packet can be iteratively processed by the packet switch using an internal loop back technique. An internal loop back may be accomplished by the ingress or egress header processor modifying bytes in the signature header of the packet to instruct the egress buffer manager to switch the packet directly from the egress queue back to an ingress queue whereupon the lower levels of the header can be processed.)
The same motivation to combine as the dependent claim 4 applies here.
Claim(s) 14 is/are substantially similar to claim 4, and is thus rejected under substantially the same rationale.
Claim(s) 15 is/are substantially similar to claim 5, and is thus rejected under substantially the same rationale.
Claim(s) 16 is/are substantially similar to claim 6, and is thus rejected under substantially the same rationale.
Claim(s) 19 is/are substantially similar to claim 10, and is thus rejected under substantially the same rationale.
3. Claim(s) 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Bshara in view of Fischer further in view of Daly (US 20210288910 A1).
Regarding claim(s) 9, the system of claim 4,
Bshara-Fishcher do not teach wherein operations associated with the transmission of the data from said first one of the respective receiver device comprise operations for traffic shaping the data prior to transmission.
Daly teaches however in the same field of computer networking teaches wherein operations associated with the transmission of the data from said first one of the respective receiver device comprise operations for traffic shaping the data prior to transmission. (Daly, [0021], FIG. 1A; a network interface controller, network interface card, SmartNIC, infrastructure processing unit (IPU), data processing unit (DPU), switch, router, and so forth or combination thereof. Controller 102 can program or configure programmable pipeline 150 to perform dropping of packets received from a network via network ports 140 based on receive rate and/or traffic shaping packets prior to transmission to a next device through network ports 140 based on one or more of: per-device, per-port, per-subscriber, per-flow, and/or per-service node. Packet dropping can occur based on meeting or exceeding a specified receive rate of packets.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Bshara by incorporating the teachings of Daly. The motivation/suggestion would have been because there is a need to enables a multi-vendor eco-system for these edge platforms and applications, driving down costs and increasing end-customer choice (Daly, [0002]).
Claim(s) 18 is/are substantially similar to claim 9, and is thus rejected under substantially the same rationale.
4. Claim(s) 13 is rejected under 35 U.S.C. 103 as being unpatentable over Bshara in view of Fischer in view of Daly further in view of D'ELETTO (US 20170180108 A1).
Regarding claim(s) 13, the system of claim 12,
Bshara-Fishcher-Daly teach wherein the data packet is a copy of a data packet multicast to one or more other network devices (Bshara, [0012] FIGS. 8A-8D depict a logical model of a progression of events of a sender sending a set of multicast and/or multiple unicast packets to a plurality of recipients. [0078] FIG. 6 depicts an example sending host computing device 615 in which embodiments of the present disclosure can be implemented. [examiner notes: when a packet is multicasted, the goal is for all subscribed receivers to receive the exact same single stream of data.])
Bshara-Fishcher-Daly do not teach by a sender device comprising a clock that is synchronized with the hardware clock of the network device.
D'ELETTO teaches however in the same field of computer networking teaches by a sender device comprising a clock that is synchronized with the hardware clock of the network device. (D'ELETTO, [0062] Next, sender device 210 (e.g., rate generator 440) may synchronize virtual clock 230 with reflector clock 250 based on the correction information. For example, sender device 210 (e.g., via signaling from rate generator 440 to clock 410) may increase or decrease a clock speed of virtual clock 230 (e.g., corresponding to clock 410) based on the correction information.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify D'ELETTO by incorporating the teachings of Daly. The motivation/suggestion would have been because there is a need to determine a two-way delay (i.e., a round trip delay) between a pair of devices (e.g., a sender device and reflector device) included in a network (D'ELETTO, [0013]).
Conclusion
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WUJI CHEN whose telephone number is (571)270-0365. The examiner can normally be reached on 9am-6pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, VIVEK SRIVASTAVA can be reached on (571) 272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WUJI CHEN/
Examiner, Art Unit 2449
/NICHOLAS P CELANI/Primary Examiner, Art Unit 2449
Prosecution Insights