DETAILED ACTION
The current office action is in response to the communication filed on 5/30/25.
The applicant amended claims 1-20 in the Preliminary Amendment received on 6/30/25.
Claims 1-20 are pending.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
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 .
Paper Submitted
It is hereby acknowledged that the following papers have been received and placed of record in the file:
Information Disclosure Statement(s) as received on 6/19/25 and 1/15/26 are considered by the Examiner.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Objections
Claims 2-3 and 10-20 are objected to because of the following informalities:
The limitation “…the data segment…” in claim 2, line 3, should be “…[[the]] a particular data segment…” (emphasis added) in order to resolve the lack of antecedent basis in the limitations. Appropriate correction is required. Similar corrections are required in claim 11, line 3; and claim 16, line 3.
The limitation “…the data segment…” in claim 3, lines 3, 5 and 7, should be “…the particular data segment…” (emphasis added) in order to resolve the lack of antecedent basis in the limitations. Appropriate correction is required. Similar corrections are required in claim 12, lines 3, 5 and 7-8; and claim 17, lines 2-3, 3, 5-6 and 8.
The limitation “…the instructions…” in claim 10, line 5, should be “…the computer instructions…” (emphasis added) in order to resolve the lack of antecedent basis in the limitations. Appropriate correction is required. Similar corrections are required in claim 13, line 2; claim 14, line 2; claim 15, line 5; claim 19, line 2; and claim 20, line 2.
The limitation “…a first data segment…” in claim 10, lines 11-12, should be “…[[a]] the first data segment…” (emphasis added) in order to resolve the lack of antecedent basis in the limitations. Appropriate correction is required.
All dependent claims are objected to as having the same deficiencies as the claims they depend from.
Note: For examination purposes, the claims will be interpreted based on the claim language suggested by the Examiner.
Claim Rejections - 35 USC § 102
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 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-7 and 9-19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by “Iny et al.” (US PGPUB 2022/0368635) (Hereinafter Iny).
With respect to claim 1, Iny teaches a method (Abstract) comprising:
receiving a data flow (Segment Load Balancer receives two flows; Fig. 6, [0185]);
splitting the data flow into a plurality of data segments, wherein the plurality of data segments comprises a first data segment (Segment Load Balancer segments flow A into two segments, and flow B into three segments; Fig. 6, [0187]);
sending the plurality of data segments along at least two paths, wherein the first data segment is sent along a first path (Segment Load Balancer arranges for all packets belonging to a first or new segment to be transmitted via a same path. The Segment Load Balancer updates an entry so that a new segment will start with the next packet and the Segment Load Balancer selects a new path to be used starting with the next packet; Fig. 6, [0171], [0181], [0187]), wherein the first data segment comprises indication information, and wherein the indication information indicates to at least one node on the first path to cache the first data segment after receiving the first data segment (the Segment Load Balancer tags each packet with an indication configured to indicate whether the packet is SLB or non-SLB. A packet is received by a reordering point, e.g. at the egress switch, destination host, or tunnel endpoint. The reordering point classifies the packet to a flow and determines whether or not the flow was assigned to SLB or not based on a tag in the packet. If the packet was assigned to SLB, then the reordering point assigns the packet to a FIFO buffer associated with the segment sequence identifier of the packet. The packet is stored along with any tags the packet may have; Fig. 6, [0188], [0217]-[0219]); and
instruct the at least one node to send the first data segment (the reordering point forwards the packet via the output network port to the destination host; Fig. 6, [0188], [0217]-[0219]).
With respect to claim 2, Iny teaches the method of claim 1, wherein each data segment of the plurality of data segments comprises at least one data packet, and wherein each data packet of the data segment comprises the indication information (Segment Load Balancer arranges for all packets belonging to a first or new segment to be transmitted via a same path. The Segment Load Balancer tags each packet with an indication configured to indicate whether the packet is SLB or non-SLB; Fig. 6, [0171], [0181], [0187]-[0188], [0217]-[0219]).
With respect to claim 3, Iny teaches the method of claim 2, wherein the method is implemented by a first node, wherein each data packet further comprises flow information corresponding to the data segment, wherein the flow information comprises a segment identifier allocated by the first node to the data segment and one of a node identifier of the first node or a port identifier used by a node that receives and caches the data segment (packets are encoded with SLB flag, segment sequence identifier, flow ID, destination and source address, etc.; Fig. 6, [0189], [0193], [0203], [0219]).
With respect to claim 4, Iny teaches the method of claim 1, wherein the indication information further indicates address information of the at least one node (packets are encoded with SLB flag, segment sequence identifier, flow ID, destination and source address, etc.; Fig. 6, [0189], [0193], [0203], [0219]).
With respect to claim 5, Iny teaches the method of claim 1, further comprising recording sending paths of the plurality of data segments when the plurality of data segments are sent (Load Balancer segments a flow according to segmentation criterion to tag packets with a sequence identifier (e.g. number), an end of segment (EOS) flag and/or other flag(s)/tag(s), and to arrange that all packets of the same segment will be transmitted via the same path, e.g. by arranging that the packets will be transmitted through the same output port towards a spine switch, e.g. by tagging the packets the same entropy label and/or with the same VLAN tag; Fig. 6, [0075], [0086], [0105]).
With respect to claim 6, Iny teaches the method of claim 5, wherein recording the sending paths comprises recording an identifier of a corresponding port for sending each of the plurality of data segments (Load Balancer segments a flow according to segmentation criterion to tag packets with a sequence identifier (e.g. number), an end of segment (EOS) flag and/or other flag(s)/tag(s), and to arrange that all packets of the same segment will be transmitted via the same path, e.g. by arranging that the packets will be transmitted through the same output port towards a spine switch, e.g. by tagging the packets the same entropy label and/or with the same VLAN tag; Fig. 6, [0075], [0086], [0105], [0152], [0162], [0167], [0181]).
With respect to claim 7, Iny teaches the method of claim 6, wherein the plurality of data segments further comprises a second data segment, wherein sending the plurality of data segments along the at least two paths comprises: sending the second data segment through a first port; and sending the first data segment through a second port, wherein the second port is different from the first port, and wherein the first data segment is a next data segment of the second data segment (Segment Load Balancer arranges for all packets belonging to a first or new segment to be transmitted via a same path. The Segment Load Balancer updates an entry so that a new segment will start with the next packet and the Segment Load Balancer selects a new path to be used starting with the next packet. Load Balancer segments a flow according to segmentation criterion to tag packets with a sequence identifier (e.g. number), an end of segment (EOS) flag and/or other flag(s)/tag(s), and to arrange that all packets of the same segment will be transmitted via the same path, e.g. by arranging that the packets will be transmitted through the same output port towards a spine switch, e.g. by tagging the packets the same entropy label and/or with the same VLAN tag; Fig. 6, [0075], [0086], [0105], [0152], [0162], [0167], [0171], [0181], [0187]).
With respect to claim 9, Iny teaches a data transmission method (Abstract) comprising:
receiving a data segment of a data flow from a second node (Segment Load Balancer arranges for all packets belonging to a first or new segment to be transmitted via a same path. The Segment Load Balancer updates an entry so that a new segment will start with the next packet and the Segment Load Balancer selects a new path to be used starting with the next packet; Fig. 6, [0171], [0181], [0187]), wherein the data segment comprises indication information, and wherein the indication information indicates to at least one node on a first path to cache the data segment after the at least one node receives the data segment (the Segment Load Balancer tags each packet with an indication configured to indicate whether the packet is SLB or non-SLB. A packet is received by a reordering point, e.g. at the egress switch, destination host, or tunnel endpoint. The reordering point classifies the packet to a flow and determines whether or not the flow was assigned to SLB or not based on a tag in the packet. If the packet was assigned to SLB, then the reordering point assigns the packet to a FIFO buffer associated with the segment sequence identifier of the packet. The packet is stored along with any tags the packet may have.; Fig. 6, [0188], [0217]-[0219]);
caching the data segment based on the indication information (the Segment Load Balancer tags each packet with an indication configured to indicate whether the packet is SLB or non-SLB. A packet is received by a reordering point, e.g. at the egress switch, destination host, or tunnel endpoint. The reordering point classifies the packet to a flow and determines whether or not the flow was assigned to SLB or not based on a tag in the packet. If the packet was assigned to SLB, then the reordering point assigns the packet to a FIFO buffer associated with the segment sequence identifier of the packet. The packet is stored along with any tags the packet may have.; Fig. 6, [0188], [0217]-[0219]); and
sending the data segment based on an indication of the second node (the reordering point forwards the packet via the output network port to the destination host; Fig. 6, [0188], [0217]-[0219]).
The limitations of claims 10-14 are rejected in the analysis of claims 1-3 and 5-6 respectively and these claims are rejected on that basis. Furthermore, Iny discloses a data transmission node comprising memory and one or more processors ([0229], [0232], [0234]) as recited in claim 10.
The limitations of claim 15 are rejected in the analysis of claim 9 above and this claim is rejected on that basis. Furthermore, Iny discloses a data transmission node comprising memory and one or more processors ([0229], [0232], [0234]) as recited in claim 15.
With respect to claim 16, Iny teaches the data transmission node of claim 15, wherein the data segment comprises at least one data packet, and wherein each data packet of the data segment comprises indication information (Segment Load Balancer arranges for all packets belonging to a first or new segment to be transmitted via a same path. The Segment Load Balancer tags each packet with an indication configured to indicate whether the packet is SLB or non-SLB; Fig. 6, [0171], [0181], [0187]-[0188], [0217]-[0219]).
With respect to claim 17, Iny teaches the data transmission node of claim 16, wherein each data packet of the data segment further comprises flow information corresponding to the data segment, wherein the flow information comprises a segment identifier allocated by the second node to the data segment and one of a node identifier of the data transmission node or a port identifier used when the data transmission node receives the data segment (packets are encoded with SLB flag, segment sequence identifier, flow ID, destination and source address, etc.; Fig. 6, [0189], [0193], [0203], [0219]).
With respect to claim 18, Iny teaches the data transmission node of claim 15, wherein the indication information further indicates address information of the at least one node (packets are encoded with SLB flag, segment sequence identifier, flow ID, destination and source address, etc.; Fig. 6, [0189], [0193], [0203], [0219]).
With respect to claim 19, Iny teaches the data transmission node of claim 15, wherein the one or more processors are configured to further execute the instructions to cause the data transmission node to send the data segment when receiving a first message from the second node, wherein the first message indicates to the data transmission node to send the data segment, wherein the first message comprises flow information of the data segment, and wherein the flow information identifies the data segment (packets are encoded with SLB flag, segment sequence identifier, flow ID, destination and source address, etc. The Segment Load Balancer tags each packet with an indication configured to indicate whether the packet is SLB or non-SLB. A packet is received by a reordering point, e.g. at the egress switch, destination host, or tunnel endpoint. The reordering point classifies the packet to a flow and determines whether or not the flow was assigned to SLB or not based on a tag in the packet. If the packet was assigned to SLB, then the reordering point assigns the packet to a FIFO buffer associated with the segment sequence identifier of the packet. The packet is stored along with any tags the packet may have. the reordering point forwards the packet via the output network port to the destination host; Fig. 6, [0188]-[0189], [0193], [0203], [0217]-[0219]).
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.
Claims 8 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Iny in view of “Shalev et al.” (US PGPUB 2019/0363989) (Hereinafter Shalev).
With respect to claim 8, Iny teaches the method of claim 1. Iny does not teach wherein receiving the data flow comprises receiving the first data flow from a second node, and wherein the method further comprises: determining that a destination node that receives the data flow completed sending the plurality of data segments; and sending, by a first node, an acknowledgement message to the second node in response to determining that the destination node completed sending the plurality of data segments, wherein the acknowledgement message indicates that the destination node completed sending the plurality of data segments.
However, Shalev teaches wherein receiving the data flow comprises receiving the first data flow from a second node, and wherein the method further comprises: determining that a destination node that receives the data flow completed sending the plurality of data segments; and sending, by a first node, an acknowledgement message to the second node in response to determining that the destination node completed sending the plurality of data segments, wherein the acknowledgement message indicates that the destination node completed sending the plurality of data segments (when the packets arrive at the destination, the receiving port logic validates the packets, and the channel adapter puts the received packets at the destination in the receive queue and processes them and the channel adapter creates an acknowledge (ACK) and sends the ACK back to the source host; [0038]).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate sending an acknowledgement message to Iny because Iny discloses tracking a flow ([0148]) and Shalev suggests sending an acknowledgement message ([0038]).
One of ordinary skill in the art would be motivated to utilize the teachings of Shalev in the Iny system in order to ensure reliable packet delivery.
With respect to claim 20, Iny teaches the data transmission node of claim 19. Iny does not teach wherein the one or more processors are configured to further execute the instructions to cause the data transmission node to: receive at least one acknowledgement message from a destination node of the data flow, wherein the acknowledgement message indicates that the destination node completed sending at least one data packet of the data segment; and send the at least one acknowledgement message to the second node.
However, Shalev teaches wherein the one or more processors are configured to further execute the instructions to cause the data transmission node to: receive at least one acknowledgement message from a destination node of the data flow, wherein the acknowledgement message indicates that the destination node completed sending at least one data packet of the data segment; and send the at least one acknowledgement message to the second node (when the packets arrive at the destination, the receiving port logic validates the packets, and the channel adapter puts the received packets at the destination in the receive queue and processes them and the channel adapter creates an acknowledge (ACK) and sends the ACK back to the source host; [0038]).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate sending an acknowledgement message to Iny because Iny discloses tracking a flow ([0148]) and Shalev suggests sending an acknowledgement message ([0038]).
One of ordinary skill in the art would be motivated to utilize the teachings of Shalev in the Iny system in order to ensure reliable packet delivery.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
Lam et al. US 2022/0166721. Discloses dynamically controlling path switching.
Burgess et al. US 2016/0269238. Discloses transferring data between network nodes via multiple paths.
Dipasquale. US 2013/0148671. Discloses transporting data from sending node to destination node.
Biederman et al. US 7,089,320. Discloses combining data in intermediate device.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Johnny B Aguiar whose telephone number is (571)272-3563. The examiner can normally be reached on Monday to Friday 7:30 am - 5:30 pm EST.
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, Joon Hwang can be reached on (571) 272-4036. 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.
/JOHNNY B AGUIAR/
Primary Examiner, Art Unit 2447
September 28, 2026
