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 responsive to a response filed on March 17th, 2026. In this Office Action,
Claims 1, 3-12, 14-20, 22-26 are pending.
Claims 1, 3-12, 14-20, 22-24, and 26 are rejected.
Claim 25 is objected to.
Response to Amendment
The amendments filed on March 17th, 2026 have been entered.
Claims 1, 3-6, 8, 12, 14-17, 19-20, and 22-23 have been amended.
Claims 2, 13, and 21 have been canceled.
Claim 24-26 have been added.
Response to Arguments
Applicant’s arguments filed on March 17th, 2026 have been fully considered, but are moot in view of the new grounds of rejection, as presented in this Office Action.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-12, 14-18, 20, and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Golestani et al. (Patent No. 6,115,749), hereinafter Golestani; in view of Williams (Pub. No. US 2024/0220418), hereinafter Williams.
Claim 1. Golestani discloses a computer-implemented method for reducing network congestion caused by multicast communications (See Col. 2 lines 24-28; a system and method that essentially establishes a multicast "window" to control transmission of a multicast in a computer network to curb congestion), the method comprising:
receiving at a local endpoint, via a network (“Packet network”; See Fig. 1), first data for multicast from a first remote endpoint (See Col. 60-67 and Col. 7 lines 1-14 controlling congestion due to a multicast in a computer network 300; a multicast manager 310, associated with a multicast sender 315, that receives from a receiver an acknowledgment packet containing a delivery status of individual data packets of a multicast delivered to the receiver 320 (receiving first data for multicast from a first remote endpoint)… the multicast manager and packet monitor are only illustrated in the sender; where these functionalities or their equivalents may be executed at the receivers or at other points of the network);
determining a congestion state of the network based on the first data (See Col. 2 lines 36-48; managing multicasts by tracking unacknowledged packets for each multicast receiver and allowing only a certain "window" of packets to remain at least partially unacknowledged at a given time. In this manner, multicast transmission of packets is done with separate consideration of the congestion status of the path of each receiver. See Col. 4 lines 55-60; The sender and receivers in response to network congestion, will adjust their subscription, i.e., sending or receiving, of data packets… i.e., congestion state is determined based on the received unacknowledged packets (based on the first data) containing a delivery status of individual data packets of a multicast delivered to the receiver); and
performing one or more operations to reduce an amount of second data that is transmitted via the network based on the congestion state of the network, wherein performing the one or more operations to reduce the amount of second data comprises reducing a number of tokens that permit data to be transmitted via the network based on a comparison between a first number of multicast [packets] previously transmitted from the local endpoint to the first remote endpoint and a second number of multicast [packets] previously transmitted from the first remote endpoint to the local endpoint (See Col. 4 lines 55-67; The congestion control methodology employed is a regime of receiving less data packets; upon detection of congestion in the packet network, the sender will adjust the data packets transmission by transmitting only "high priority" packets (reduce an amount of second data that is transmitted). See also Col. 7 lines 6-49; a packet monitor 330, associated with the sender 315, that analyzes the delivery status and modifies the number of tokens in the token pools 340 associated with each of the receivers 320 ... The size of the token pool 340 associated with the ith receiver 320, W.sub.-- i, determines the maximum number of data packets 370 that may be outstanding to the ith receiver 320 at any point of time, i.e., the maximum number of data packets 370 that may be transmitted by the sender 315 while it still awaits their acknowledgments 350. The multicast manager 310 controls the transmission of new data packets 370 to prevent the number of data packets 370 that may be outstanding to the ith receiver 320 from exceeding W.sub.-- i. The sender 315 may not transmit any new data packets 370 to any particular receiver 320 unless there is a token available in every token pool 340. When the sender 315 transmits a new data packet 370, the packet monitor 330 removes a token from all of the token pool 340 ... to adjust the size of the token pool 340, such as removing tokens (reducing a number of tokens that permit data to be transmitted) when acknowledgments are received; the acknowledgment packet 350 typically contains a bit (having a state that is a function of the delivery status) 360 corresponding to each of the individual data packets 370. See Col. 8 lines 17-22; it is also possible to adjust the window size W of each receiver based on variations in the network traffic load in accordance with some algorithm. See also Col. 2 lines 36-48, Col. 3 lines 8-14, and Col. 5 lines 34-38).
Golestani doesn’t explicitly disclose the first data for multicast comprising a first received multicast request and the multicast [packets] are multicast requests.
However, Williams discloses managing tokens to facilitate distribution of multicast requests (See Parag. [0045]; token manager 120 can be utilized to grant tokens to requesting processing nodes 104 to facilitate distribution of certain types of multicast requests ... See also Parag. [0118-0120]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the packets exchanged between the sender and receiver, taught by Golestani, as multicast requests, as taught by Williams. This would be convenient to facilitate distribution of certain types of multicast requests via the system fabric while avoiding the development of livelocks (Williams, Parag. [0045]).
Claim 3. Golestani in view of Williams discloses the computer-implemented method of claim 2,
Golestani discloses the computer-implemented method further comprising: computing a reduction to a watermark based on the number of tokens consumed over a period of time, wherein the tokens that permit data to be transmitted are generated based on the watermark (See Col. 2 lines 36-48; managing multicasts by tracking unacknowledged packets for each multicast receiver and allowing only a certain "window" (watermark) of packets to remain at least partially unacknowledged at a given time. See Col. 5 lines 25-32; In order to describe this multicast window mechanism, the use of a token pool embodiment is preferred over a sliding window embodiment in order to easily accommodate out of order acceptance of acknowledgments, where desired. See Col. 7 lines 33-40; adjust the size of the token pool 340, such as removing tokens when acknowledgments are received i.e., applicant’s specification (Parag. [0025]) discloses reduction to a watermark is equivalent to a number of tokens consumed over a period of time due to the multicast network congestion management); and responsive to determining that the reduction to the watermark is less than a constant value, reducing the watermark by the constant value (See Col. 7 lines 15-23; The size of the token pool 340 associated with the ith receiver 320, W.sub i, determines the maximum number of data packets 370 that may be outstanding to the ith receiver 320 at any point of time, i.e., the maximum number of data packets 370 that may be transmitted by the sender 315 while it still awaits their acknowledgments 350. The multicast manager 310 controls the transmission of new data packets 370 to prevent the number of data packets 370 that may be outstanding to the ith receiver 320 from exceeding W. See also Col. 8 lines 17-22; it is also possible to adjust the window size W of each receiver based on variations in the network traffic load in accordance with some algorithm).
Claim 4. Golestani in view of Williams discloses the computer-implemented method of claim 1,
Golestani discloses the computer-implemented method further comprising, when the second data is being transmitted, reducing the number of tokens based on the second data (See Col. 4 lines 55-60; The sender and receivers in response to network congestion, will adjust their subscription, i.e., sending or receiving, of data packets (the second data). See Col. 7 lines 33-40; to adjust the size of the token pool 340, such as removing tokens (reducing a number of tokens) when acknowledgments are received; the acknowledgment packet 350 typically contains a bit (having a state that is a function of the delivery status) 360 corresponding to each of the individual data packets 370).
Claim 5. Golestani in view of Williams discloses the computer-implemented method of claim 1,
Golestani further discloses wherein determining the congestion state of the network comprises updating, based on the first data, one or more entries in a first data structure, wherein each entry included in the one or more entries is associated with a respective remote endpoint, including a first entry included in the one or more entries that is associated with the first remote endpoint (See Col. 7 lines 50-56; Following the reception of the acknowledgment packets 350, the sender 315 measures the round trip time of each data packet 370. A received acknowledgment packet 350 may contain acknowledgments for more than one data packet 370. The sender 315 then proceeds to update both the round trip time estimate and the time-out for the corresponding receiver 320 (respective remote endpoint)).
Claim 6. Golestani in view of Williams discloses the computer-implemented method of claim 5,
Golestani further discloses wherein updating the one or more entries in the first data structure comprises decrementing or incrementing the one or more entries to indicate that the first multicast is contributing to network congestion (See Col. 7 lines 50-63; The sender 315 then proceeds to update both the round trip time estimate and the time-out for the corresponding receiver 320. The time-out is a time counter that is initialized when a data packet 370 is transmitted and is subsequently decreased until an acknowledgment packet 350 for that data packet 370 is received. Those skilled in the art are aware that time-out counters may be implemented whereby the time measurement is increased. The time-out value is at least the round trip time estimate for the corresponding receiver 320).
Williams further discloses the multicast is for the first received multicast request (See Parag. [0045]; token manager 120 can be utilized to grant tokens to requesting processing nodes 104 to facilitate distribution of certain types of multicast requests ... See also Parag. [0118-0120]).
Claim 7. Golestani in view of Williams discloses the computer-implemented method of claim 6,
Golestani discloses the computer-implemented method further comprising, when the second data is being transmitted, incrementing or decrementing the one or more entries in the first data structure (See Col. 7 lines 50-63; Following the reception of the acknowledgment packets 350, the sender 315 measures the round trip time of each data packet 370. A received acknowledgment packet 350 may contain acknowledgments for more than one data packet 370. The sender 315 then proceeds to update both the round trip time estimate and the time-out for the corresponding receiver 320. The time-out is a time counter that is initialized when a data packet 370 is transmitted and is subsequently decreased until an acknowledgment packet 350 for that data packet 370 is received).
Claim 8. Golestani in view of Williams discloses the computer-implemented method of claim 5,
Golestani discloses the computer-implemented method further comprising: updating, based on the second data, one or more entries in a second data structure that indicates outstanding data from one or more remote endpoints, wherein each entry included in the one or more entries in the second data structure is associated with a respective remote endpoint, including a first entry included in the one or more entries that is associated with the first remote endpoint (See Col. 6 lines 40-51; method B as the preferred multicast window mechanism. The essence of this preferred multicast window mechanism is that it separately controls the number of outstanding packets for each receiver (remote endpoints) and keeps it below the corresponding window size W.sub.i (updating for outstanding data). By outstanding packets of a receiver i, what is meant is the number of packets sent by the sender, for which the sender is still waiting to receive an acknowledgment from receiver i. Keeping the number of outstanding packets for each receiver i in the multicast group below the corresponding window size W.sub.-- i is the essence of the invention. See Col. 7 lines 15-23; The size of the token pool 340 associated with the ith receiver 320, W.sub.-- i, determines the maximum number of data packets 370 that may be outstanding to the ith receiver 320 at any point of time, i.e., the maximum number of data packets 370 that may be transmitted by the sender 315 while it still awaits their acknowledgments 350. The multicast manager 310 controls the transmission of new data packets 370 to prevent the number of data packets 370 that may be outstanding to the ith receiver 320 from exceeding W.sub.-- i); and updating the one or more entries in the first data structure based on the one or more entries in the second data structure (See Col. 6 lines 11-21; In the second type of multicast window mechanism (method B), one token pool is established for each receiver. In this method, a packet may not be sent until a token is available in every pool. When a packet is sent, one token is consumed from each pool. When an acknowledgment for a packet is received from the ith receiver, a token will be returned to the corresponding pool, without waiting for that packet to be acknowledged by the other receivers. See Col. 7 lines 50-56; Following the reception of the acknowledgment packets 350, the sender 315 measures the round trip time of each data packet 370. A received acknowledgment packet 350 may contain acknowledgments for more than one data packet 370. The sender 315 then proceeds to update both the round trip time estimate and the time-out for the corresponding receiver 320).
Claim 9. Golestani in view of Williams discloses the computer-implemented method of claim 5,
Golestani discloses the computer-implemented method further comprising: storing, in a second data structure, one or more expiration times associated with the first data; and in response to the one or more expiration times elapsing, updating, based on lapsing of the one or more expiration times, one or more entries in the first data structure to indicate that the first data no longer contributes to network congestion (See Col. 7 lines 50-63; Following the reception of the acknowledgment packets 350, the sender 315 measures the round trip time of each data packet 370. A received acknowledgment packet 350 may contain acknowledgments for more than one data packet 370. The sender 315 then proceeds to update both the round trip time estimate and the time-out (one or more expiration times) for the corresponding receiver 320. The time-out is a time counter that is initialized when a data packet 370 is transmitted and is subsequently decreased until an acknowledgment packet 350 for that data packet 370 is received (the time-out is stored with the memory of the system; see Fig. 2). Those skilled in the art are aware that time-out counters may be implemented whereby the time measurement is increased. The time-out value is at least the round trip time estimate for the corresponding receiver 320. See also Col. 7 lines 64-67 and Col. 8 lines 1-6).
Claim 10. Golestani in view of Williams discloses the computer-implemented method of claim 9,
Golestani discloses the computer-implemented method further comprising computing the one or more expiration times based on when the first data was received, a round trip time, and a delay between data being sent See Col. 7 lines 50-63; Following the reception of the acknowledgment packets 350, the sender 315 measures the round trip time of each data packet 370. A received acknowledgment packet 350 may contain acknowledgments for more than one data packet 370 (the first data was received). The sender 315 then proceeds to update both the round trip time estimate and the time-out (one or more expiration times) for the corresponding receiver 320. The time-out is a time counter that is initialized when a data packet 370 is transmitted and is subsequently decreased until an acknowledgment packet 350 for that data packet 370 is received. Those skilled in the art are aware that time-out counters may be implemented whereby the time measurement is increased. The time-out value is at least the round trip time estimate for the corresponding receiver 320.
Claim 11. Golestani in view of Williams discloses the computer-implemented method of claim 5,
Golestani discloses the computer-implemented method further comprising: storing, in a second data structure, one or more indications of the first data being outstanding; and updating at least one entry in the first data structure based on the one or more indications of the first data being outstanding (See Col. 6 lines 40-51; method B as the preferred multicast window mechanism. The essence of this preferred multicast window mechanism is that it separately controls the number of outstanding packets for each receiver and keeps it below the corresponding window size W.sub.i (one or more indications of the first data being outstanding is stored within the memory of the system; see Fig. 2). By outstanding packets of a receiver i, what is meant is the number of packets sent by the sender, for which the sender is still waiting to receive an acknowledgment from receiver i. Keeping the number of outstanding packets for each receiver i in the multicast group below the corresponding window size W.sub.-- i is the essence of the invention… See Col. 7 lines 50-56; Following the reception of the acknowledgment packets 350, the sender 315 measures the round trip time of each data packet 370. A received acknowledgment packet 350 may contain acknowledgments for more than one data packet 370. The sender 315 then proceeds to update both the round trip time estimate and the time-out for the corresponding receiver 320).
Claim 12. Golestani discloses one or more non-transitory computer-readable media storing instructions that, when executed by at least one processor, cause the at least one processor to perform steps for reducing network congestion (See Col. 2 lines 24-28; a system and method that essentially establishes a multicast "window" to control transmission of a multicast in a computer network to curb congestion. See Col. 4 lines 18-28 and Fig. 2; The computer 200 includes processing circuitry 210, e.g., having at least one conventional processor, conventional volatile memory 220, e.g., random access memory, and non-volatile memory 230, e.g., a hard disk drive. The processing circuitry 210, volatile memory 220 and non-volatile memory 230 are associated with each other and cooperatively operate to execute the system of the present invention), the steps comprising:
receiving at a local endpoint, via a network (“Packet network”; See Fig. 1), first data for multicast from a first remote endpoint (See Col. 60-67 and Col. 7 lines 1-14 controlling congestion due to a multicast in a computer network 300; a multicast manager 310, associated with a multicast sender 315, that receives from a receiver an acknowledgment packet containing a delivery status of individual data packets of a multicast delivered to the receiver 320 (receiving first data for multicast from a first remote endpoint)… the multicast manager and packet monitor are only illustrated in the sender; where these functionalities or their equivalents may be executed at the receivers or at other points of the network);
determining a congestion state of the network based on the first data (See Col. 2 lines 36-48; managing multicasts by tracking unacknowledged packets for each multicast receiver and allowing only a certain "window" of packets to remain at least partially unacknowledged at a given time. In this manner, multicast transmission of packets is done with separate consideration of the congestion status of the path of each receiver. See Col. 4 lines 55-60; The sender and receivers in response to network congestion, will adjust their subscription, i.e., sending or receiving, of data packets… i.e., congestion state is determined based on the received unacknowledged packets (based on the first data) containing a delivery status of individual data packets of a multicast delivered to the receiver); and
performing one or more operations to reduce an amount of second data that is transmitted via the network based on the congestion state of the network, wherein performing the one or more operations to reduce the amount of second data comprises reducing a number of tokens that permit data to be transmitted via the network based on a comparison between a first number of multicast [packets] previously transmitted from the local endpoint to the first remote endpoint and a second number of multicast [packets] previously transmitted from the first remote endpoint to the local endpoint (See Col. 4 lines 55-67; The congestion control methodology employed is a regime of receiving less data packets; upon detection of congestion in the packet network, the sender will adjust the data packets transmission by transmitting only "high priority" packets (reduce an amount of second data that is transmitted). See also Col. 7 lines 6-49; a packet monitor 330, associated with the sender 315, that analyzes the delivery status and modifies the number of tokens in the token pools 340 associated with each of the receivers 320 ... The size of the token pool 340 associated with the ith receiver 320, W.sub.-- i, determines the maximum number of data packets 370 that may be outstanding to the ith receiver 320 at any point of time, i.e., the maximum number of data packets 370 that may be transmitted by the sender 315 while it still awaits their acknowledgments 350. The multicast manager 310 controls the transmission of new data packets 370 to prevent the number of data packets 370 that may be outstanding to the ith receiver 320 from exceeding W.sub.-- i. The sender 315 may not transmit any new data packets 370 to any particular receiver 320 unless there is a token available in every token pool 340. When the sender 315 transmits a new data packet 370, the packet monitor 330 removes a token from all of the token pool 340 ...).
Golestani doesn’t explicitly disclose the first data for multicast comprising a first received multicast request and the multicast [packets] are multicast requests.
However, Williams discloses managing tokens to facilitate distribution of multicast requests (See Parag. [0045]; token manager 120 can be utilized to grant tokens to requesting processing nodes 104 to facilitate distribution of certain types of multicast requests ... See also Parag. [0118-0120]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the packets exchanged between the sender and receiver, taught by Golestani, as multicast requests, as taught by Williams. This would be convenient to facilitate distribution of certain types of multicast requests via the system fabric while avoiding the development of livelocks (Williams, Parag. [0045]).
Claims 14 and 15 are taught by Golestani in view of Williams as described for claims 3 and 5, respectively.
Claim 16. Golestani in view of Williams discloses the one or more non-transitory computer-readable media of claim 15,
Golestani further discloses wherein updating the one or more entries in the first data structure comprises decrementing the one or more entries to indicate that the first multicast is contributing to network congestion (See Col. 7 lines 50-63; The sender 315 then proceeds to update both the round trip time estimate and the time-out for the corresponding receiver 320. The time-out is a time counter that is initialized when a data packet 370 is transmitted and is subsequently decreased until an acknowledgment packet 350 for that data packet 370 is received), and the instructions, when executed by the at least one processor, further cause the at least one processor to perform the step of: when the second data is being transmitted, incrementing the one or more entries in the first data structure (See Col. 7 lines 50-63; time-out counters may be implemented whereby the time measurement is increased. The time-out value is at least the round trip time estimate for the corresponding receiver 320).
Williams further discloses the multicast is for the first received multicast request (See Parag. [0045]; token manager 120 can be utilized to grant tokens to requesting processing nodes 104 to facilitate distribution of certain types of multicast requests ... See also Parag. [0118-0120]).
Claims 17-18 are taught by Golestani in view of Williams as described for claims 8-9, respectively.
Claim 20. Golestani discloses a system, comprising:
one or more memories storing instructions; and one or more processors that are coupled to the one or more memories and, when executing the instructions, are configured to (See Col. 4 lines 18-28 and Fig. 2; The computer 200 includes processing circuitry 210, e.g., having at least one conventional processor, conventional volatile memory 220, e.g., random access memory, and non-volatile memory 230, e.g., a hard disk drive. The processing circuitry 210, volatile memory 220 and non-volatile memory 230 are associated with each other and cooperatively operate to execute the system of the present invention):
receive at a local endpoint, via a network (“Packet network”; See Fig. 1), first data for multicast (See Col. 60-67 and Col. 7 lines 1-14 controlling congestion due to a multicast in a computer network 300; a multicast manager 310, associated with a multicast sender 315, that receives from a receiver an acknowledgment packet containing a delivery status of individual data packets of a multicast delivered to the receiver 320 (receive first data for multicast from a first remote endpoint)… the multicast manager and packet monitor are only illustrated in the sender; where these functionalities or their equivalents may be executed at the receivers or at other points of the network),
determine a congestion state of the network based on the first data (See Col. 2 lines 36-48; managing multicasts by tracking unacknowledged packets for each multicast receiver and allowing only a certain "window" of packets to remain at least partially unacknowledged at a given time. In this manner, multicast transmission of packets is done with separate consideration of the congestion status of the path of each receiver. See Col. 4 lines 55-60; The sender and receivers in response to network congestion, will adjust their subscription, i.e., sending or receiving, of data packets… i.e., congestion state is determined based on the received unacknowledged packets (based on the first data) containing a delivery status of individual data packets of a multicast delivered to the receiver), and
perform one or more operations to reduce an amount of second data that is transmitted via the network based on the congestion state of the network, wherein performing the one or more operations to reduce the amount of second data comprises reducing a number of tokens that permit data to be transmitted via the network based on a comparison between a first number of multicast [packets] previously transmitted from the local endpoint to the first remote endpoint and a second number of multicast [packets] previously transmitted from the first remote endpoint to the local endpoint (See Col. 4 lines 55-67; The congestion control methodology employed is a regime of receiving less data packets; upon detection of congestion in the packet network, the sender will adjust the data packets transmission by transmitting only "high priority" packets (reduce an amount of second data that is transmitted). See also Col. 7 lines 6-49; a packet monitor 330, associated with the sender 315, that analyzes the delivery status and modifies the number of tokens in the token pools 340 associated with each of the receivers 320 ... The size of the token pool 340 associated with the ith receiver 320, W.sub.-- i, determines the maximum number of data packets 370 that may be outstanding to the ith receiver 320 at any point of time, i.e., the maximum number of data packets 370 that may be transmitted by the sender 315 while it still awaits their acknowledgments 350. The multicast manager 310 controls the transmission of new data packets 370 to prevent the number of data packets 370 that may be outstanding to the ith receiver 320 from exceeding W.sub.-- i. The sender 315 may not transmit any new data packets 370 to any particular receiver 320 unless there is a token available in every token pool 340. When the sender 315 transmits a new data packet 370, the packet monitor 330 removes a token from all of the token pool 340 ... to adjust the size of the token pool 340, such as removing tokens (reducing a number of tokens that permit data to be transmitted) when acknowledgments are received; the acknowledgment packet 350 typically contains a bit (having a state that is a function of the delivery status) 360 corresponding to each of the individual data packets 370. See Col. 8 lines 17-22; it is also possible to adjust the window size W of each receiver based on variations in the network traffic load in accordance with some algorithm. See also Col. 2 lines 36-48, Col. 3 lines 8-14, and Col. 5 lines 34-38).
Golestani doesn’t explicitly disclose the first data for multicast comprising a first received multicast request and the multicast [packets] are multicast requests.
However, Williams discloses managing tokens to facilitate distribution of multicast requests (See Parag. [0045]; token manager 120 can be utilized to grant tokens to requesting processing nodes 104 to facilitate distribution of certain types of multicast requests ... See also Parag. [0118-0120]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the packets exchanged between the sender and receiver, taught by Golestani, as multicast requests, as taught by Williams. This would be convenient to facilitate distribution of certain types of multicast requests via the system fabric while avoiding the development of livelocks (Williams, Parag. [0045]).
Clam 26. Golestani in view of Williams discloses the computer-implemented method of claim 1,
Golestani further discloses wherein the number of tokens permit data to be transmitted from the local endpoint to one or more remote endpoints via the network (See also Col. 7 lines 6-49; a packet monitor 330, associated with the sender 315, that analyzes the delivery status and modifies the number of tokens in the token pools 340 associated with each of the receivers 320 ... The size of the token pool 340 associated with the ith receiver 320, W.sub.-- i, determines the maximum number of data packets 370 that may be outstanding to the ith receiver 320 at any point of time, i.e., the maximum number of data packets 370 that may be transmitted by the sender 315 while it still awaits their acknowledgments 350. The multicast manager 310 controls the transmission of new data packets 370 to prevent the number of data packets 370 that may be outstanding to the ith receiver 320 from exceeding W.sub.-- i. The sender 315 may not transmit any new data packets 370 to any particular receiver 320 unless there is a token available in every token pool 340).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Golestani et al. (Patent No. 6,115,749), hereinafter Golestani; in view of Williams et al. (Pub. No. US 2024/0220418), hereinafter Williams; and further in view of Klenk (Pub. No. US 2021/0036881), hereinafter Klenk.
Claim 19. Golestani in view of Williams discloses the one or more non-transitory computer-readable media of claim 12,
Golestani in view of Williams doesn’t explicitly disclose wherein the first received multicast request is received during an all-reduce operation.
However, Klenk discloses wherein the first received multicast request is received during an all-reduce operation (See abstract; An injection policy comprising the issuing of credits enables each endpoint to limit the amount of collective communication primitives injected into the network simultaneously to reduce network congestion caused by increased network traffic due to the multicast capability of the network devices. See Parag. [0156]; an all-reduce operation can be performed by having each endpoint transmit their data elements to other endpoints to perform intermediate reduction operations).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the multicast operations, taught by Golestani in view of Williams, to be performed during an all-reduce operation, as taught by Klenk. This would be convenient to overcome issues such as the limited ability to scale with large ML/DL training applications (Klenk, Parag. [0004-0006]).
Claims 22-24 are rejected under 35 U.S.C. 103 as being unpatentable over Golestani et al. (Patent No. 6,115,749), hereinafter Golestani; in view of Williams et al. (Pub. No. US 2024/0220418), hereinafter Williams; and further in view of Lee et al. (Pub. No. US 2023/0246946), hereinafter Lee.
Claim 22. Golestani in view of Williams discloses the computer-implemented method of claim 1,
Golestani in view of Williams doesn’t explicitly disclose wherein the first data is received at a switch for the local endpoint, wherein the local endpoint performs multicast communications via the switch.
However, Lee discloses wherein the first data is received at a switch for a first local endpoint, wherein the first local endpoint performs multicast communications via the switch (See Parag. [0040-0044]; The computing device 111 may comprise a multicast flow analyzer 119. The multicast flow analyzer 119 may be configured to receive the multicast of content (received multicast response) from the multicast router 120 and other data from the multicast router 120 and the network devices 121-123 via the network 124 or another network .. the multicast flow analyzer 119 may be configured to receive data associated with multicast leave requests and multicast join requests (received multicast request) from the network devices 121-123 ...).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify Golestani in view of Williams, to include wherein the first data is received at a switch for a first local endpoint, wherein the first local endpoint performs multicast communications via the switch, as taught by Lee. This would be convenient to determine quality control issues related to the multicast of the content (Lee, Parag. [0043]).
Claim 23. Golestani in view of Williams and Lee discloses the computer-implemented method of claim 22,
Golestani in view of Williams doesn’t explicitly disclose wherein the local endpoint is a destination endpoint for the first data.
However, Lee discloses wherein the first local endpoint is a destination endpoint for the first data (See Parag. [0040-0044]; The computing device 111 may comprise a multicast flow analyzer 119. The multicast flow analyzer 119 may be configured to receive the multicast of content (received multicast response) from the multicast router 120 and other data from the multicast router 120 and the network devices 121-123 via the network 124 or another network .. the multicast flow analyzer 119 may be configured to receive data associated with multicast leave requests and multicast join requests (received multicast request) from the network devices 121-123 ...).
Claim 24. Golestani in view of Williams discloses the computer-implemented method of claim 1,
Golestani in view of Williams doesn’t explicitly disclose wherein the first data further comprises at least one received multicast response.
However, Lee discloses wherein the first data further comprises at least one received multicast response (See Parag. [0040-0044]; The computing device 111 may comprise a multicast flow analyzer 119. The multicast flow analyzer 119 may be configured to receive the multicast of content (received multicast response) from the multicast router 120 and other data from the multicast router 120 and the network devices 121-123 via the network 124 or another network .. the multicast flow analyzer 119 may be configured to receive data associated with multicast leave requests and multicast join requests from the network devices 121-123 ...).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify Golestani in view of Williams, to include the first data further comprises at least one received multicast response, as taught by Lee. This would be convenient to determine quality control issues related to the multicast of the content (Lee, Parag. [0043]).
Allowable Subject Matter
Claim 25 is 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.
The following is the reason for objecting to claim 25:
With regards to claim 25, Golestani et al. (Patent No. 6,115,749); in view of Williams et al. (Pub. No. US 2024/0220418) fails to fairly teach or suggest “wherein reducing the number of tokens based on the comparison between the first number of multicast requests and the second number of multicast requests comprises reducing the number of tokens upon determining that the first number of multicast requests is greater than the second number of multicast requests.”
In addition, no other prior art of records teaches or suggests the instant claim as a whole.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Guim Bernat et al. (US 2017/0180270) – Related art in the area related to adaptive multicast schemes, (Abstract; Described herein are devices and techniques for distributing application data. A device can communicate with one or more hardware switches. The device can receive, from a software stack, a multicast message including a constraint that indicates how application data is to be distributed. The constraint including a listing of the set of nodes and a number of nodes to which the application data is to be distributed. The device may receive, from the software stack, the application data for distribution to a plurality of nodes. The plurality of nodes being a subset of the set of nodes equaling the number of nodes. The device may select the plurality of nodes from the set of nodes. The device also may distribute a copy of the application data to the plurality of nodes based on the constraint. Also described are other embodiments).
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 ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7: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 Louie can be reached on 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Abdelbasst Talioua/Primary Examiner, Art Unit 2445
Prosecution Insights