DETAILED ACTION
This action is responsive to amendment filed on August 11th, 2026.
Claims 1, 3~7, 9~11, and 14~17 are examined.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/06/26 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant's arguments filed 08/11/26 have been fully considered but they are not persuasive.
In response to Applicant’s remarks, although Chen discloses that a transmitting end sends data and an address together to a receiving end, the address is that in the memory, so that the receiving end can directly write the data into the memory according to the address in the memory. Furthermore, in Chen, to enable the transmitting end to know the address in the target memory at the receiving end and send the address in the target memory at the receiving end, along with the data to be written into the address in the target memory, to the receiving end, address negotiation between the transmitting end and the receiving end is necessary. Examiner respectfully disagrees. In RDMA, for a read/write operation (or, one-sided), the application typically specifies a starting virtual address. The RNIC then reads or writes a contiguous sequence of bytes from that starting point. The application itself uses the virtual address to identify data buffers for zero-copy transfers. Chen mentions there are four commonly used RDMA operations (also called RDMA verbs). READ and WRITE are one-sided operations, meaning that applications can directly read or write a remote memory without involvement of a remote CPU [¶19]. Chen also taught for the RDMA READ or WRITE operation, since the RoCEv2 data header 240 has included a target address in the memory 122 to be written, the NIC 123 may analyze the RoCEv2 data header 240 to derive the target address and directly store the data in the packet 200 at the target address [¶42]. Chen further taught in fig. 4 of a bitmap data structure 400 for tracking the received packets. The bitmap 400 may be organized into a circular array. The bitmap 400 may have L slots, for example, each of which may include two bits for recording a state of a packet A header 410 of the bitmap 400 corresponds to a packet with a sequence number rcv_next, rev_next indicates a sequence number of a next packet desired to be received by the receiving device [¶68]. Based on the teachings above, the arguments Applicants made are features inherent to RDMA and in Chen. Chen uses the same RDMA RoCEv2 to specifically perform operations that stores RDMA messages in virtual address space of the NIC depending on the packet sequence that is tracked by the bitmap data structure so that the messages (even if arriving out of order) may be placed in contiguous virtual memory address space. Examiner also notes that RoCEv2 (released in 2014) can store and transmit messages using contiguous virtual memory during the registration process even though the underlying physical memory is usually non-contiguous. Where Chen does not mention virtual address explicitly is thus, inherent when the prior art itself teaches RDMA using RoCEv2.
Claim Rejections - 35 USC § 102
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 2, 4~8, 10, 11, and 14~17 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Chen et al. hereinafter Chen (U.S 2022/0309025).
Regarding Claim 1,
Chen taught a data transmission method, applied to a first network device, comprising:
reading data from a memory according to a storage sequence of the data, and storing the data locally [¶40, NIC 113 may read corresponding data from the memory 112 based on the RDMA request, and generate an RDMA message to be sent to the NIC 123],
assigning addresses to the data, wherein the addresses are consecutive virtual addresses representing a reading sequence of the data [¶32, when the application executed by the CPU 111 initiates a request for an RDMA read operation in the host 110, the RDMA request may be sent to the NIC 113. The NIC 113 may read corresponding data from the remote memory 122 based on the RDMA request. The read data, together with an address in the target memory 112 to be written, may be included in the RDMA message; Note: the use of virtual addresses is implicit since RDMA RocEv2 relies on packet requests to specify a single continuous virtual address range and when a message arrives with a specific virtual address, the NIC automatically maps that contiguous virtual address to the scattered physical memory pages in real-time],
assigning each piece of the data to one of at least two transmission paths [¶32, the RDMA message may include data to be sent and an address in the target memory 122 to be written. The RDMA message may be transmitted to the NIC 123 via the plurality of network paths 140; and
for each of the transmission paths, sending, through a first data packet, the data assigned to the transmission path and the addresses of the data to a second network device, wherein the addresses of the data are used for enabling the second network device to write corresponding data into a memory according to the addresses of the data [¶34, NIC 113 may generate at least one packet based on an RDMA message to be transmitted from the NIC 113 to the NIC 123. Then, the NIC 113 may transmit the at least one generated packet from the NIC 113 to the NIC 123 via an RDMA protocol over the plurality of paths 140; ¶32].
Regarding Claim 4,
Chen taught wherein the addresses are ring queue addresses [¶68, bitmap 400 may be organized into a circular array. For example, the bitmap 400 may have L slots, for example, each of which may include two bits for recording a state of a packet A header 410 of the bitmap 400 corresponds to a packet with a sequence number rcv_next, rev_next indicates a sequence number of a next packet desired to be received by the receiving device].
Regarding Claim 5,
Chen taught further comprising: after for each of the transmission paths, sending, through a first data packet, data assigned to the transmission path and addresses of the data to a second network device, in a case of receiving a retransmission request packet sent by the second network device, acquiring an address of retransmitting data carried in the retransmission request packet; determining the retransmitting data according to the address of the retransmitting data; and sending, through a second data packet, the retransmitting data and the address of the retransmitting data to the second network device [¶85, upon entering in the packet loss recovery mode, in response to receiving an ACK from the NIC 123, the NIC 113 may retransmit the packet indicated by the snd_retx, over the path receiving the ACK; ¶86, when the NIC 123 receives a packet with a retransmission tag, it may include the retransmission tag in the ACK for the packet, and transmit the ACK carrying the retransmission tag to the NIC 113].
Regarding Claims 6,
Chen taught further comprising: after assigning each piece of the data to one of at least two transmission paths, and before for each of the transmission paths, sending, through a first data packet, data assigned to the transmission path and addresses of the data to a second network device, for each of the transmission paths, assigning package sequence numbers (PSNs) to the data assigned to the transmission path to form a PSN sequence of the transmission path, wherein in the PSN sequence of one transmission path, the PSNs are increased incrementally according to an assigning sequence of the PSNs from first to last [¶91, the plurality of fields include: a first field indicating an identifier of the first path; a second field indicating a packet sequence number of the first packet; a third field indicating a message sequence number of the RDMA message; and a fourth field indicating a sequence number of the first packet in the RDMA message].
Regarding Claims 7, 8, 10, 11, and 14~17, the claims are similar in scope to claims 1, 2, and 4~6 and therefore, rejected under the same rationale.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 3 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Chen in view of Tian et al. hereinafter Tian (NPL: “Accelerating Distributed Deep Learning using Multi-Path RDMA in Data Center Network”).
Regarding Claims 3 and 9,
Chen-Tian taught wherein the addresses are virtual addresses starting from 0, the addresses of the data increase incrementally according to the reading sequence of the data from first to last [§3.2, Maestro maps each QP to a different (virtual) path (VP), using the IP address associated with each vNIC as a VP id].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was made, to combine, Tian’s teaching of limitations with the teachings of Chen, because the combination provides flexibility in selecting and mapping paths for load balancing [§3.2].
Conclusion
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HEE SOO KIM whose telephone number is (571)270-3229. The examiner can normally be reached M-F 9AM-5PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nicholas Taylor can be reached on (571) 272-3889. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HEE SOO KIM/Primary Examiner, Art Unit 2443
Prosecution Insights