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 .
Response to Arguments
Applicant’s arguments with respect to claims 1-19 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-5, 9-10 and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over US 2026/0052100 A1 to Holl et al. (hereafter refers as Holl) in view of US 2014/0328350 A1 to Hao et al. (hereafter refers as Hao) and further in view of US 2020/0252488 A1 to Zha et al. (hereafter refers as Zha).
Regarding claim 1, Holl teaches a method of forwarding data messages between endpoint processing units (EPUs) that are connected through a network (a method for forwarding data messages, i.e. synchronization data, between graphic processing units (GPUs) that are connected through a network, Fig. 2-4, 7-8) and that perform computations to collectively execute a distributed application (wherein the GPUs are worked collectively to perform computations for a distributed application, paragraphs [6, 36, 46-47, 68]), the method comprising:
generating, for each computation of each source EPU (for each synchronization data, i.e. computation result, of each source GPU, paragraphs [51-52, 88-89]), a data message flow (generating for each transmission of synchronization data, a path configuration, paragraph [52]) comprising one or more data messages that store a result of the computation (wherein the path configuration comprises a path for transmission of the synchronization data, paragraphs [52, 63-65, 68-69]), said generating comprising specifying for each data message an Ethernet frame for forwarding the data message to a destination in the network (wherein the generation includes specifying for each synchronization an Ethernet frame, paragraphs [41, 45], for forwarding the synchronization message/data to a destination in the network, i.e. path configuration, Fig. 2, element 273, and paragraphs [47-48, 52, 65]); and
using, at each forwarding element that forwards each data message (at each switching element, Fig. 2-4, for forwarding each synchronization data/message, paragraphs [47, 50, 52, 61-63, 69, 92-93]), to identify an egress port of the forwarding element to forward the data message along a path through the network to the data message's destination (each switching element in a switch fabric, using the path configuration, to identify an egress port of the switch element to forward the synchronization data/message along a path through the network to a destination, paragraphs [40, 47-50, 61-63, 69, 92-93] and Fig. 3-4).
However, Holl does not explicitly teach specifying for each data mesage “an Ethernet header comprising a destination media access control (DMAC) address field that instead of a destination MAC (media access control) address, stores a tag for forwarding the data message to a destination in the network” and using “the tag stored in the DMAC address field of the data message's header to identify an egress port” of the forwarding element to forward the data message along a path through the network to the data message's destination.
Hao teaches a method of forwarding data messages between endpoint (method for forwarding data messages between endpoints/nodes, Fig. 1) comprising:
generating, for source endpoint, a data message flow comprising one or more data messages (generating for each source node, a flow/path comprising one or more data messages, paragraphs [19-21] and Fig. 1), said generating comprising specifying for each data message an Ethernet header (specifying for each data message, an Ethernet header, paragraph [20-22]) comprising an Ethernet header comprising a destination media access control (DMAC) address field that instead of a destination MAC (media access control) address, stores a tag for forwarding the data message to a destination in the network (instead of destination MAC address, a destination MAC address field stores net-id and/or address-ID for forwarding the data message(s) to a destination in the network, paragraphs [28-29, 34, 39]); and
using, at each forwarding element that forwards each data message, the tag stored in the DMAC address field of the data message's header to identify an egress port of the forwarding element to forward the data message along a path through the network to the data message's destination (at each of a switching/forwarding element, using the net-id and/or address-ID stored in the DMAC address field to identify an egress port to forward the data message along a path to a destination, paragraphs [23-24, 28-30, 38-39]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of the Ethernet header comprising the destination media access control (DMAC) address field that instead of the destination MAC (media access control) address, stores a tag for forwarding the data message to a destination in the network and using the tag stored in the DMAC address field of the data message's header to identify an egress port of the forwarding element to forward the data message along a path through the network to the data message's destination as taught by Hao, with the teachings of Holl, for a purpose of reducing the cost of network without compromising advantage of forwarding by using the tag for forwarding instead of the DMAC address (see Hao, paragraphs [2-5, 17-19]).
However, the combination of Holl and Hao does not explicitly the Ethernet header comprising “a field that identifies the data message as an Ethernet frame”.
Zha teaches an Ethernet header comprising a field that identifies the data message as an Ethernet frame (Ethernet header includes a field identifying that a frame is an Ethernet type frame, paragraphs [173-178]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of an Ethernet header comprising a field that identifies the data message as an Ethernet frame as taught by Zha, with the teachings of Ethernet header as taught by combination of Holl and Hao, for a purpose of maintaining format for the data frame by including the field for identifying the data frame as the Ethernet frame even when the data frame has been modified (see Zha, paragraphs [44, 90, 91, 173-177]).
Regarding claim 2, Holl further teaches wherein the EPUs are graphics processing units (GPUs) (GPUs, Fig. 2-4).
Regarding claim 3, Holl further teaches wherein the EPUs comprise at least one of graphics processing units (GPUs) (GPUs, Fig. 2-4) and central processing units (CPUs) (GPUs are replaced by CPUs, paragraph [44]).
Regarding claim 4, Hao further teaches wherein the data message is a revised Ethernet frame as the data message's header stores the forwarding tag in the DMAC field instead of storing a DMAC address (wherein the data message is a revised Ethernet frame to store the net-id and/or address-ID, instead of destination MAC address, for forwarding the data message(s) to a destination in the network, paragraphs [28-29, 34, 39]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of wherein the data message is a revised Ethernet frame as the data message's header stores the forwarding tag in the DMAC field instead of storing a DMAC address as taught by Hao, with the teachings of data message as taught by Holl, for a purpose of reducing the cost of network without compromising advantage of forwarding by using the tag for forwarding (see Hao, paragraphs [2-5, 17-19]).
Regarding claim 5, Hao further teaches wherein the forwarding elements comprise switches with data plane circuits that are custom designed and manufactured to perform forwarding operations based on the tags (wherein the switches are configured to transmit data messages, i.e. data plane circuits, based on the net-id and/or address-ID, paragraphs [5, 19, 20, 23]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of wherein the forwarding elements comprise switches with data plane circuits that are custom designed and manufactured to perform forwarding operations based on the tags as taught by Friedman, with the teachings of forwarding elements comprise switches as taught by Holl, for a purpose of reducing cost of network without compromising advantage of forwarding by using the tag for forwarding (see Hao, paragraphs [2-5, 17-19]).
Regarding claim 9, Holl teaches a method of forwarding data messages between endpoint processing units (EPUs) that are connected through a network (a method for forwarding data messages, i.e. synchronization data, between graphic processing units (GPUs) that are connected through a network, Fig. 2-4, 7-8) and that perform computations to collectively execute a distributed application (wherein the GPUs are worked collectively to perform computations for a distributed application, paragraphs [6, 36, 46-47, 68]), the method comprising:
generating, for each computation of each source EPU (for each synchronization data, i.e. computation result, of each source GPU, paragraphs [51-52, 88-89]), a data message flow (generating for each transmission of synchronization data, a path configuration, paragraph [52]) comprising one or more data messages that store a result of the computation (wherein the path configuration comprises a path for transmission of the synchronization data, paragraphs [52, 63-65, 68-69]), said generating comprising specifying for each data message an Ethernet frame for forwarding the data message to a destination in the network (wherein the generation includes specifying for each synchronization an Ethernet frame, paragraphs [41, 45], for forwarding the synchronization message/data to a destination in the network, i.e. path configuration, Fig. 2, element 273, and paragraphs [47-48, 52, 65]); and
using, at each forwarding element that forwards each data message (at each switching element, Fig. 2-4, for forwarding each synchronization data/message, paragraphs [47, 50, 52, 61-63, 69, 92-93]), to identify an egress port of the forwarding element to forward the data message along a path through the network to the data message's destination (each switching element in a switch fabric, using the path configuration, to identify an egress port of the switch element to forward the synchronization data/message along a path through the network to a destination, paragraphs [40, 47-50, 61-63, 69, 92-93] and Fig. 3-4).
However, Holl does not explicitly teach specifying for each data message “an Ethernet header comprising a source media access control (SMAC) address field that instead of a source MAC (media access control) address, stores a tag for forwarding the data message to a destination in the network” and using “the tag stored in the SMAC address field of the data message's header to identify an egress port” of the forwarding element to forward the data message along a path through the network to the data message's destination.
Hao teaches a method of forwarding data messages between endpoint (method for forwarding data messages between endpoints/nodes, Fig. 1) comprising:
generating, for source endpoint, a data message flow comprising one or more data messages (generating for each source node, a flow/path comprising one or more data messages, paragraphs [19-21] and Fig. 1), said generating comprising specifying for each data message an Ethernet header (specifying for each data message, an Ethernet header, paragraph [20-22]) comprising an Ethernet header comprising a source media access control (SMAC) address field that instead of a source MAC (media access control) address, stores a tag for forwarding the data message to a destination in the network (wherein a source MAC address field stores net-id and/or address-ID, instead of source MAC address, for forwarding the data message(s) to a destination in the network, paragraphs [28-29, 34, 39]); and
using, at each forwarding element that forwards each data message, the tag stored in the SMAC address field of the data message's header to identify an egress port of the forwarding element to forward the data message along a path through the network to the data message's destination (at each of a switching/forwarding element, using the net-id and/or address-ID stored in the SMAC address field to identify an egress port to forward the data message along a path to a destination, paragraphs [23-24, 28-30, 38-39]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of the Ethernet header comprising the source media access control (SMAC) address field that instead of a source MAC (media access control) address, stores a tag for forwarding the data message to a destination in the network and using the tag stored in the SMAC address field of the data message's header to identify an egress port of the forwarding element to forward the data message along a path through the network to the data message's destination as taught by Hao, with the teachings of Holl, for a purpose of reducing the cost of network without compromising advantage of forwarding by using the tag for forwarding instead of the SMAC address (see Hao, paragraphs [2-5, 17-19]).
However, the combination of Holl and Hao does not explicitly the Ethernet header comprising “a field that identifies the data message as an Ethernet frame”.
Zha teaches an Ethernet header comprising a field that identifies the data message as an Ethernet frame (Ethernet header includes a field identifying that a frame is an Ethernet type frame, paragraphs [173-178]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of an Ethernet header comprising a field that identifies the data message as an Ethernet frame as taught by Zha, with the teachings of Ethernet header as taught by combination of Holl and Hao, for a purpose of maintaining format for the data frame by including the field for identifying the data frame as the Ethernet frame even when the data frame has been modified (see Zha, paragraphs [44, 90, 91, 173-177]).
Regarding claim 10, Holl teaches a method of forwarding data messages between endpoint processing units (EPUs) that are connected through a network (a method for forwarding data messages, i.e. synchronization data, between graphic processing units (GPUs) that are connected through a network, Fig. 2-4, 7-8) and that perform computations to collectively execute a distributed application (wherein the GPUs are worked collectively to perform computations for a distributed application, paragraphs [6, 36, 46-47, 68]), the method comprising:
generating, for each computation of each source EPU (for each synchronization data, i.e. computation result, of each source GPU, paragraphs [51-52, 88-89]), a data message flow (generating for each transmission of synchronization data, a path configuration, paragraph [52]) comprising one or more data messages that store a result of the computation (wherein the path configuration comprises a path for transmission of the synchronization data, paragraphs [52, 63-65, 68-69]), said generating comprising specifying for each data message an Ethernet frame for forwarding the data message to a destination in the network (wherein the generation includes specifying for each synchronization an Ethernet frame, paragraphs [41, 45], for forwarding the synchronization message/data to a destination in the network, i.e. path configuration, Fig. 2, element 273, and paragraphs [47-48, 52, 65]); and
using, at each forwarding element that forwards each data message (at each switching element, Fig. 2-4, for forwarding each synchronization data/message, paragraphs [47, 50, 52, 61-63, 69, 92-93]), to identify an egress port of the forwarding element to forward the data message along a path through the network to the data message's destination (each switching element in a switch fabric, using the path configuration, to identify an egress port of the switch element to forward the synchronization data/message along a path through the network to a destination, paragraphs [40, 47-50, 61-63, 69, 92-93] and Fig. 3-4).
However, Holl does not explicitly teach specifying for each data message “an Ethernet header comprising a source media access control (SMAC) and destination media access control (DMAC) address fields, and (ii) instead of storing SMAC and DMAC addresses in the SMAC and DMAC address fields, storing a tag for forwarding the data message to a destination in the network partially in the SMAC address filed and partially in the DMAC address field” and using “the tag stored in the SMAC and DMAC address fields of the data message's header to identify an egress port” of the forwarding element to forward the data message along a path through the network to the data message's destination.
Hao teaches a method of forwarding data messages between endpoint (method for forwarding data messages between endpoints/nodes, Fig. 1) comprising:
generating, for source endpoint, a data message flow comprising one or more data messages (generating for each source node, a flow/path comprising one or more data messages, paragraphs [19-21] and Fig. 1), said generating comprising specifying for each data message an Ethernet header (specifying for each data message, an Ethernet header, paragraph [20-22]) comprising an Ethernet header comprising a source media access control (SMAC) and destination media access control (DMAC) address fields, and (ii) instead of storing SMAC and DMAC addresses in the SMAC and DMAC address fields, storing a tag for forwarding the data message to a destination in the network partially in the SMAC address filed and partially in the DMAC address field (instead of the source and destination MAC addresses, the source MAC and destination MAC address fields store net-id and/or address-ID for forwarding the data message(s) to a destination in the network, paragraphs [28-29, 34, 39]); and
using, at each forwarding element that forwards each data message, the tag stored in the SMAC and DMAC address fields of the data message's header to identify an egress port of the forwarding element to forward the data message along a path through the network to the data message's destination (at each of a switching/forwarding element, using the net-id and/or address-ID stored in the SMAC and DMAC address fields to identify an egress port to forward the data message along a path to a destination, paragraphs [23-24, 28-30, 38-39]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of an Ethernet header comprising a source media access control (SMAC) and destination media access control (DMAC) address fields, and (ii) instead of storing SMAC and DMAC addresses in the SMAC and DMAC address fields, storing a tag for forwarding the data message to a destination in the network partially in the SMAC address filed and partially in the DMAC address field and using the tag stored in the SMAC and DMAC address fields of the data message's header to identify an egress port of the forwarding element to forward the data message along a path through the network to the data message's destination as taught by Hao, with the teachings of Holl, for a purpose of reducing the cost of network without compromising advantage of forwarding by using the tag for forwarding instead of the DMAC address and the SMAC address (see Hao, paragraphs [2-5, 17-19]).
However, the combination of Holl and Hao does not explicitly the Ethernet header comprising “a field that identifies the data message as an Ethernet frame”.
Zha teaches an Ethernet header comprising a field that identifies the data message as an Ethernet frame (Ethernet header includes a field identifying that a frame is an Ethernet type frame, paragraphs [173-178]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of an Ethernet header comprising a field that identifies the data message as an Ethernet frame as taught by Zha, with the teachings of Ethernet header as taught by combination of Holl and Hao, for a purpose of maintaining format for the data frame by including the field for identifying the data frame as the Ethernet frame even when the data frame has been modified (see Zha, paragraphs [44, 90, 91, 173-177]).
Regarding claim 14, the combination of Holl, Hao and Zha further teaches wherein each data message does not store any layer 3 (L3) network address (wherein each data message only stores the MAC addresses, see Holl, paragraphs [6, 29, 32], see Hao, paragraphs [21-27], see Zha, paragraphs [42-46, 172-177]).
Regarding claim 15, the combination of Holl, Hao and Zha further teaches wherein each data message does not store any layer 4 (L4) network address (wherein each data message only stores the MAC addresses, see Holl, paragraphs [6, 29, 32], see Hao, paragraphs [21-27], see Zha, paragraphs [42-46, 172-177]).
Regarding claim 16, the combination of Holl, Hao and Zha further teaches wherein each data message does not store any network address (wherein each data message only stores the MAC addresses, see Holl, paragraphs [6, 29, 32], see Hao, paragraphs [21-27], see Zha, paragraphs [42-46, 172-177]).
Claims 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over US 2026/0052100 A1 to Holl et al. (hereafter refers as Holl) in view of US 2014/0328350 A1 to Hao et al. (hereafter refers as Hao) and US 2020/0252488 A1 to Zha et al. (hereafter refers as Zha) as applied to claims above, and further in view of US 10,382,401 B1 to Lee et al. (hereafter refers as Lee) and US 9,160,633 B1 to Ruble et al. (hereafter refers as Ruble).
Regarding claim 6, the combination of Holl, Hao and Zha does not explicitly teach switches “manually” configured with match-action records that store tag values in match fields of the match-action records.
Lee teaches switches manually configured with match-action records that store tag values in match fields of the match-action records (a routing table is manually provisioned by an administrator, col. 21, line 67 – col. 22, line 5).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of switches manually configured with match-action records that store tag values in match fields of the match-action records as taught by Lee, with the teachings of Holl, Hao and Zha, for a purpose of increase efficiency in establishing the match-action records that store tag values by manually configured, thus allowing the switch to perform the match-action at the beginning (see Lee, col. 21, line 67 – col. 22, line 5).
However, the combination of Holl, Hao, Zha and Lee does not explicitly teach “wherein the forwarding elements further comprise off-the-shelf third-party switches that perform forwarding operations by performing match-action operations based on values stored in the DMAC address fields of the data messages, said third party switches configured not to perform L2 learning operations”.
Ruble teaches the forwarding elements further comprise off-the-shelf third-party switches (off-the-shelf switching elements have a function that permits disabling MAC learning traps, col. 7, lines 28-50) that perform forwarding operations by performing match-action operations based on values stored in the DMAC address fields of the data messages (perform forwarding operation using lookup in the MAC table, col. 3, lines 10-40), said third party switches configured not to perform L2 learning operations (switches are configured to disable MAC learning trap, col. 4, lines 19-40, col. 5, lines 38-52, col. 7, lines 28-50).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of wherein the forwarding elements further comprise off-the-shelf third-party switches that perform forwarding operations by performing match-action operations based on values stored in the DMAC address fields of the data messages, said third party switches configured not to perform L2 learning operations as taught by Ruble, with the teachings of combination of Holl, Hao, Zha and Lee, for a purpose of increase efficiency in learning the MAC address by preventing learning the MAC address associated with tag that previously learned (see Lee, col. 4, lines 19-40, col. 5, lines 38-52, col. 7, lines 28-50).
Regarding claim 7, the combination of Holl, Hao and Zha does not explicitly teach switches “manually” configured with match-action records that store tag values in match fields of the match-action records.
Lee teaches switches manually configured with match-action records that store tag values in match fields of the match-action records (a routing table is manually provisioned by an administrator, col. 21, line 67 – col. 22, line 5).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of switches manually configured with match-action records that store tag values in match fields of the match-action records as taught by Lee, with the teachings of combination of Holl, Hao and Zha, for a purpose of increase efficiency in establishing the match-action records that store tag values by manually configured, thus allowing the switch to perform the match-action at the beginning (see Lee, col. 21, line 67 – col. 22, line 5).
However, the combination of Holl, Hao, Zha and Lee does not explicitly teach “wherein the forwarding elements further comprise off-the-shelf third-party switches that perform forwarding operations by performing match-action operations based on values stored in the DMAC address fields of the data messages, said third party switches configured not to perform L2 learning operations”.
Ruble teaches the forwarding elements further comprise off-the-shelf third-party switches (off-the-shelf switching elements have a function that permits disabling MAC learning traps, col. 7, lines 28-50) that perform forwarding operations by performing match-action operations based on values stored in the DMAC address fields of the data messages (perform forwarding operation using lookup in the MAC table, col. 3, lines 10-40), said third party switches configured not to perform L2 learning operations (switches are configured to disable MAC learning trap, col. 4, lines 19-40, col. 5, lines 38-52, col. 7, lines 28-50).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of wherein the forwarding elements further comprise off-the-shelf third-party switches that perform forwarding operations by performing match-action operations based on values stored in the DMAC address fields of the data messages, said third party switches configured not to perform L2 learning operations as taught by Ruble, with the teachings of combination of Holl, Hao, Zha and Lee, for a purpose of increase efficiency in learning the MAC address by preventing learning the MAC address associated with tag that previously learned (see Lee, col. 4, lines 19-40, col. 5, lines 38-52, col. 7, lines 28-50).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over US 2026/0052100 A1 to Holl et al. (hereafter refers as Holl) in view of US 2014/0328350 A1 to Hao et al. (hereafter refers as Hao) and US 2020/0252488 A1 to Zha et al. (hereafter refers as Zha) as applied to claims above, and further in view of US 2004/0105440 A1 to Strachan et al. (hereafter refers as Strachan).
Regarding claim 11, the combination of Holl, Hao and Zha does not explicitly teach “each header further comprises an Ethernet Start of a Frame (SOF) field, an Ethernet CRC (cyclic redundancy check) field, and Ethernet End of a Frame (EOF) field”.
Strachan teaches each header further comprises an Ethernet Start of a Frame (SOF) field, an Ethernet CRC (cyclic redundancy check) field, and Ethernet End of a Frame (EOF) field (a header of Ethernet frame comprises an SOF, CRC field and EOF field, paragraph [25] and Fig. 3).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of each header further comprises an Ethernet Start of a Frame (SOF) field, an Ethernet CRC (cyclic redundancy check) field, and Ethernet End of a Frame (EOF) field as taught by Strachan, with the teachings of combination of Holl, Hao and Zha, for a purpose of increase compatibility of the teaching by employing the Ethernet frame structure with the SOF field, CRC field and EOF field (see Strachan, paragraph [25] and Fig. 3).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over US 2026/0052100 A1 to Holl et al. (hereafter refers as Holl) in view of US 2014/0328350 A1 to Hao et al. (hereafter refers as Hao) and US 2020/0252488 A1 to Zha et al. (hereafter refers as Zha) as applied to claims above, and further in view of US 2021/0219175 A1 to Xu et al. (hereafter refers as Xu).
Regarding claim 13, the combination of Holl, Hao and Zha further teaches the data payload related to EPU computation (synchronization data is payload related to GPU computation, see Holl, paragraphs [46-47]).
However, the combination of Holl, Hao and Zha does not explicitly teach wherein in each data message, “a field that specifies whether the data message contains control payload for a control operation or data payload related to EPU computation”.
Xu teaches in each data message, a tag is stored in the data message header (in each Ethernet data message, a tag is stored in the data message header, paragraph [150]) along with a field that specifies whether the data message contains control payload for a control operation or data payload related to computation (along with a field specifying whether the data message contains control payload or data payload related to feedback, paragraph [279]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of in each data message, a tag is stored in the data message header along with a field that specifies whether the data message contains control payload for a control operation or data payload related to computation as taught by Xu, with the teachings of the data payload related to EPU computation as taught by combination of Holl, Hao and Zha, for a purpose of increase efficiency by clearly specifying whether the data message contains control payload for a control operation or data payload related to EPU computation (see Xu, paragraph [279]).
Claims 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over f US 2026/0052100 A1 to Holl et al. (hereafter refers as Holl) in view of US 2014/0328350 A1 to Hao et al. (hereafter refers as Hao) and US 2020/0252488 A1 to Zha et al. (hereafter refers as Zha)as applied to claims above, and further in view of US 2013/0329549 A1 to Kusama et al. (hereafter refers as Kusama).
Regarding claim 17, the combination of Holl, Hao and Zha does not explicitly teach “wherein a network address for a destination connected to the network is a common address known to different units for the destination”.
Kusama teaches a network address for a destination connected to the network is a common address known to different units for the destination (a network address for a destination is a common address known to different terminals for the destination, Fig. 14, destination of T2 is A2 to different terminals, i.e. terminal MT and T1, Fig. 14 and paragraphs [106-108]).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the claimed invention to incorporate the teachings of the network address for the destination connected to the network is a common address known to different EPUs for the destination as taught by Kusama, with the teachings of EPUs as taught by combination of Holl, Hao and Zha, for a purpose of increase efficiency in identifying the destination by using the common address for the destination (see Kusama, Fig. 14 and paragraphs [106-108]).
Regarding claim 18, the combination of Holl, Hao, Zha and Kusama further teaches wherein the destinations for different data message flows comprise destination EPUs that receive results computed by source EPUs (wherein the different flows/paths comprises destination GPUs that receives synchronizations data computed by source GPUs, see Holl, Fig. 2-4), wherein each EPU is both a source EPU for some data message flows and a destination EPU for other data message flows (wherein each GPU/terminal node is both a source GPU/terminal and a destination GPU/terminal, i.e. request and response, see Holl, Fig. 1-4 and paragraphs [43, 50-51], see Kusama, Fig. 13-14).
Regarding claim 19, the combination of Holl, Hao, Zha and Kusama further teaches wherein the tag are not network addresses because different source EPUs use different tags to send different data message flows storing different results to one destination having one network address in the network (wherein vlan tag is not a network address since, different source terminals uses different tags to send different messages flows, see Holl, paragraphs [40, 47-50, 61-63, 69, 92-93] and Fig. 3-4, to one destination having one address, see Kusama, Fig. 13-14 and paragraphs [57-59, 101, 107-109]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2015/0319009 A1 discloses different nodes uses different VLAN tags to send messages to a common destination (Fig. 2A).
US 2023/0327988 A1 discloses a modified packet comprising tags instead of MAC address (Fig. 3B-3C).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, 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 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 DUNG B. HUYNH whose telephone number is (571)270-7642. The examiner can normally be reached M-F 9:00 AM - 6:00 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, Ian N. Moore can be reached at 571-272-3085. 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.
/DUNG B HUYNH/Primary Examiner, Art Unit 2469 August 17, 2026
Prosecution Insights