DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . The application has been examined. Claims 1-20 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/17/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Allowable Subject Matter
Claims 2 and 20 are 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 and any intervening claims and overcoming Obviousness Double Patenting Rejection, Claim Objections and 35 USC § 112, 102, and 103 Rejections.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/forms/. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-21 of the U.S. Patent No. 12,294,518. Although the conflicting claims are not identical, they are not patentably distinct from each other because the difference between claims 1-20 of the instant application and claims 1-21 of the U.S. Patent No. 12,294,518 is that the claims of the instant application discloses the scope of the invention to be broader than to the scope of the U.S. Patent No. 12,294,518.
Claim 1 is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 1 of the U.S. Patent No. 12,294,518. Although the conflicting claims are not identical, they are not patentably distinct from each other because the difference between claim 1 of the instant application and claim 1 of the U.S. Patent No. 12,294,518 is that the claims of the instant application discloses apparatus steps which are broader to the apparatus steps of the U.S. Patent No. 12,294,518.
Claim 8 is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 9 of the U.S. Patent No. 12,294,518. Although the conflicting claims are not identical, they are not patentably distinct from each other because the difference between claim 8 of the instant application and claim 9 of the U.S. Patent No. 12,294,518 is that the claims of the instant application are broader to claims of the U.S. Patent No. 12,294,518.
Claim 19 is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 20 of the U.S. Patent No. 12,294,518. Although the conflicting claims are not identical, they are not patentably distinct from each other because the difference between claim 19 of the instant application and claim 20 of the U.S. Patent No. 12,294,518 is that the claims of the instant application are broader to the claims of the U.S. Patent No. 12,294,518.
Claims Comparison Table
Instant Application:
19/174,316
U.S. Patent No. 12,294,518 B2
(common inventive entity and assignee)
Claim 1:
A networking device, comprising: a processor; and computer memory coupled to the processor, wherein the computer memory comprises instructions stored thereon that, when executed by the processor, enable the processor to: receive information describing a data flow directed toward a processing network; determine, based on the information describing the data flow, a size of the data flow; determine the size of the data flow is below a predetermined flow threshold; and in response to determining that the size of the data flow is below a predetermined threshold, bypass a congestion controller that manages data flows in the processing network.
Claim 1:
A networking device, comprising: a processor; and computer memory coupled to the processor, wherein the computer memory comprises instructions stored thereon that, when executed by the processor, enable the processor to: receive information describing a data flow directed toward a processing network; determine, based on the information describing the data flow, a size of the data flow; determine the size of the data flow is below a predetermined flow threshold; and in response to determining that the size of the data flow is below the predetermined flow threshold, bypass a congestion controller that manages data flows in the processing network by disabling an oversubscribe buffer of the congestion controller.
Claim 2:
The networking device of claim 1, wherein the instructions, when executed by the processor, further enable the processor to: determine a size of the processing network; determine the size of the processing network is above a predetermined network size threshold; and in response to determining that the size of the processing network is above the predetermined network size threshold, implement a time synchronization to divide the processing network into a plurality of smaller networks.
Claim 2:
The networking device of claim 1, wherein the instructions, when executed by the processor, further enable the processor to: determine a size of the processing network; determine the size of the processing network is above a predetermined network size threshold; and in response to determining that the size of the processing network is above the predetermined network size threshold, implement a time-division multiplexing (TDM) to divide the processing network into a plurality of smaller networks.
Claim 3:
The networking device of claim 1, wherein the predetermined flow threshold is defined by a number of operations to be performed.
Claim 4:
The networking device of claim 1, wherein the predetermined flow threshold is defined by a number of operations to be performed.
Claim 4:
The networking device of claim 1, wherein the predetermined flow threshold is defined by a percentage of operations to be performed having a message size less than a predetermined message size.
Claim 5:
The networking device of claim 1, wherein the predetermined flow threshold is defined by a percentage of operations to be performed having a message size less than a predetermined message size.
Claim 5:
The networking device of claim 1, wherein the processing network comprises a plurality of processes belonging to a collective and wherein each process in the plurality of processes sends at least one message to every other process in the plurality of processes.
Claim 6:
The networking device of claim 1, wherein the processing network comprises a plurality of processes belonging to a collective and wherein each process in the plurality of processes sends at least one message to every other process in the plurality of processes.
Claim 6:
The networking device of claim 1, wherein the processing network employs all-to-all communication.
Claim 7:
The networking device of claim 1, wherein the processing network employs all-to-all communication.
Claim 7:
The networking device of claim 1, wherein bypassing the congestion controller comprises transmitting the data flow using sender-based packet scheduling.
Claim 8:
The networking device of claim 1, wherein bypassing the congestion controller comprises transmitting the data flow using sender-based packet scheduling.
Claim 8:
A system, comprising: a congestion controller that manages traffic across a network fabric using receiver-based packet scheduling; and a networking device that employs the congestion controller for data flows qualified as a large data flow but bypasses the congestion controller for data flows qualified as a small data flow.
Claim 9:
A system, comprising: a processor; and computer memory coupled to the processor, wherein the computer memory comprises instructions stored thereon that are executable by the processor, wherein the instructions include: a congestion controller that manages traffic across a network fabric using receiver-based packet scheduling; and a networking device that employs the congestion controller for data flows qualified as a large data flow but bypasses the congestion controller for data flows qualified as a small data flow, wherein the networking device bypasses the congestion controller by disabling an oversubscribe buffer of the congestion controller.
Claim 9:
The system of claim 8, wherein the networking device comprises a switch.
Claim 10:
The system of claim 9, wherein the networking device comprises a switch.
Claim 10:
The system of claim 8, wherein the congestion controller is integrated into the networking device.
Claim 11:
The system of claim 9, wherein the congestion controller is integrated into the networking device.
Claim 11:
The system of claim 8, wherein data flows are qualified as the large data flow in response to the networking device determining that the data flow will result in more than a predetermined number of operations being performed during a workflow.
Claim 12:
The system of claim 9, wherein data flows are qualified as the large data flow in response to the networking device determining that the large data flow will result in more than a predetermined number of operations being performed during a workflow.
Claim 12:
The system of claim 11, wherein the workflow comprises a Deep Learning Recommendation Model (DLRM).
Claim 13:
The system of claim 12, wherein the workflow comprises a Deep Learning Recommendation Model (DLRM).
Claim 13:
The system of claim 8, wherein data flows are qualified as the small data flow in response to the networking device determining that the data flow will result in less than a predetermined number of operations being performed during a workflow.
Claim 14:
The system of claim 9, wherein the data flows are qualified as the small data flow in response to the networking device determining that the small data flow will result in less than a predetermined number of operations being performed during a workflow.
Claim 14:
The system of claim 8, wherein the network fabric employs all-to-all communication.
Claim 15:
The system of claim 9, wherein the network fabric employs all-to-all communication.
Claim 15:
The system of claim 8, wherein data flows are sorted between the small data flow and large data flow based on a size of the data flow being compared to a predetermined flow threshold.
Claim 16:
The system of claim 9, wherein data flows are sorted between the small data flow and large data flow based on a size of the data flows being compared to a predetermined flow threshold.
Claim 16:
The system of claim 8, wherein the networking device qualifies the data flows as either the large data flow or the small data flow based on a Quality of Service (QOS) adaptation.
Claim 17:
The system of claim 9, wherein the networking device qualifies the data flows as either the large data flow or the small data flow based on a Quality of Service (QOS) adaptation.
Claim 17:
The system of claim 16, wherein the QoS adaptation is adjusted based on one or more of: changing allocated buffers, shared buffer properties, arbiter prioritization based on an indication of a collective, and arbiter prioritization based on a size of the collective.
Claim 18:
The system of claim 17, wherein the QoS adaptation is adjusted based on one or more of: changing allocated buffers, shared buffer properties, arbiter prioritization based on an indication of a collective, and arbiter prioritization based on a size of the collective.
Claim 18:
The system of claim 16, wherein the QoS adaptation is adjusted based on shared buffer properties and wherein the shared buffer properties comprise at least one of an amount of a shared buffer allocated to a port and a speed with which the port can consume the shared buffer allocated thereto.
Claim 19:
The system of claim 17, wherein the QoS adaptation is adjusted based on shared buffer properties and wherein the shared buffer properties comprise at least one of an amount of a shared buffer allocated to a port and a speed with which the port can consume the shared buffer allocated thereto.
Claim 19:
A device, comprising: processing circuitry; and computer memory coupled to the processing circuitry, wherein the processing circuitry is to execute instructions stored in the computer memory thereby enabling the device to: receive information describing a data flow directed toward a processing network; and based on an analysis of the information describing the data flow, cause the data flow to bypass a congestion controller that manages data flows in the processing network.
Claim 20:
A method, comprising: receiving information describing a data flow directed toward a processing network; determining, based on the received information describing the data flow, a size of the data flow; determining the size of the data flow qualifies the data flow as a small data flow; and in response to determining that the data flow qualifies as the small data flow, bypassing a congestion controller that manages data flows in the processing network by disabling an oversubscribe buffer of the congestion controller.
Claim 20:
The device of claim 19, wherein the analysis of the information describing the data flow causes the data flow to be classified as a small data flow and wherein the processing circuitry is further to execute the instructions stored in the computer memory thereby enabling the device to: determine a size of the processing network; determine the size of the processing network is above a predetermined network size threshold; and in response to determining that the size of the processing network is above the predetermined network size threshold, implement a time-division multiplexing (TDM) to divide the processing network into a plurality of smaller networks.
Claim 20:
A method, comprising: receiving information describing a data flow directed toward a processing network; determining, based on the received information describing the data flow, a size of the data flow; determining the size of the data flow qualifies the data flow as a small data flow; and in response to determining that the data flow qualifies as the small data flow, bypassing a congestion controller that manages data flows in the processing network by disabling an oversubscribe buffer of the congestion controller.
Claim 21:
The method of claim 20, further comprising: determining a size of the processing network; determining the size of the processing network is above a predetermined network size threshold; and in response to determining that the size of the processing network is above the predetermined network size threshold, implementing a time-division multiplexing (TDM) to divide the processing network into a plurality of smaller networks.
Claim Objections
Claims 1, 11, 13, and 15 are objected to because of the following informalities: lack of terminology consistency
Claim 1, line 9, recites “below a predetermined threshold” and should be changed to -- below [[a]]the predetermined flow threshold --.
Similar changes are suggested for subsequent claims.
Claim 11, line 1, recites “wherein data flows” and should be changed to -- wherein the data flows --.
Similar changes are suggested for subsequent claims.
Claim 13, line 2, recites “that the data flow” and should be changed to -- that the large data flow --.
Claim 15, line 2, recites “and large data flow” and should be changed to -- and the large data flow --.
Claim 19, line 7, recites “the information describing the data flow” and should be changed to -- the received information describing the data flow --.
Appropriate correction are required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 2 and 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As noted in MPEP §2161.01: “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. For software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed.”
Regarding claim 2, Applicant’s claimed invention is described in the specification in functional terms, i.e., “determine a size…”, determine the size…”, and “…implement a time synchronization…”, however, in the filed specification para. [0056], specifically “in response to determining that the size of the processing network is above the predetermined network size threshold, implementing a time synchronization to divide the processing network into a plurality of smaller networks”, simply appears to restate the functional claim limitations without reciting any further details as to the algorithm or steps/procedures for how the inventors intended the functions to be performed. As such claim 2 is rejected under 35 U.S.C. § 112(a) for failing to comply with the written description requirement.
Regarding claim 20, Applicant’s claimed invention is described in the specification in functional terms, i.e., “determine a size…”, determine the size…”, and “…implement a time-division multiplexing…”, however, in the filed specification para. [0056], specifically “in response to determining that the size of the processing network is above the predetermined network size threshold, implementing a time synchronization (e.g., time-division multiplexing) to divide the processing network into a plurality of smaller networks”, simply appears to restate the functional claim limitations without reciting any further details as to the algorithm or steps/procedures for how the inventors intended the functions to be performed. As such claim 23 is rejected under 35 U.S.C. § 112(a) for failing to comply with the written description requirement.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 7-11, 13, 15, and 19 are rejected under 35 U.S.C. 102(a)(2) as being unpatentable by Srivastava et al. (2020/0213232, hereinafter Srivastava).
Regarding claim 1, Srivastava discloses a networking device (Srivastava, para. 24), comprising:
a processor (Srivastava, para. 96); and
computer memory (Srivastava, para. 96) coupled to the processor, wherein the computer memory comprises instructions stored thereon that, when executed by the processor, enable the processor to:
receive information describing a data flow directed toward a processing network (Srivastava discloses that the network device 4 receives a plurality of packet flows and processes the packet flows to generate a stream of discrete data units known as cells) (Srivastava, para. 31);
determine, based on the information describing the data flow, a size of the data flow (Srivastava discloses that the ingress fabric endpoint 20A tracks the congestion status of each packet flow by maintaining (determine) a queue length (size) for packets of each received packet flow) (Srivastava, para. 52);
determine the size of the data flow is below a predetermined flow threshold (Srivastava discloses that the ingress fabric endpoint 20A compares the queue length for a packet flow to a threshold to determine whether the packet flow is congested or uncongested; upon determining that the packet flow (data flow) is greater than the threshold, the packet is determined as congested, the ingress endpoint 20A switches data for the packet flow to an external memory, while data for the other packet flows that are uncongested are continued to be stored in the internal memory) (Srivastava, para. 52); and
in response to determining that the size of the data flow is below a predetermined threshold, bypass a congestion controller that manages data flows in the processing network (Srivastava discloses that upon determining that the queue length for the packet flow (data flow) is less than the threshold, the ingress fabric endpoint 20A determines that the flow is uncongested, which the ingress endpoint 20A stores all packet flows in the internal memory) (Srivastava, para. 52).
Regarding claim 7, Srivastava discloses the networking device of claim 1, wherein bypassing the congestion controller comprises transmitting the data flow using sender-based packet scheduling (Srivastava discloses that the merge point merges packets of each of flows 1 and 2 according to a round robin scheduler (packet scheduling)) (Srivastava, Fig. 6; para. 83).
Regarding claim 8, Srivastava discloses a system, comprising:
a congestion controller (Srivastava, para. 83) that manages traffic across a network fabric using receiver-based packet scheduling (Srivastava discloses that the merge point of the sequence module merges packets of each of flows 1 and 2 according to a round robin scheduler (packet scheduling)) (Srivastava, Fig. 6; para. 83); and
a networking device (Srivastava, para. 24) that employs the congestion controller for data flows qualified as a large data flow but bypasses the congestion controller for data flows qualified as a small data flow (Srivastava discloses that the ingress fabric endpoint 20A compares the queue length for a packet flow to a threshold to determine whether the packet flow is congested or uncongested; upon determining that the packet flow (data flow) has become congested, the ingress endpoint 20A switches data for the packet flow to an external memory, while data for the other packet flows that are uncongested are continued to be stored in the internal memory) (Srivastava, para. 52).
Regarding claim 9, Srivastava discloses the system of claim 8, wherein the networking device comprises a switch (Srivastava, para. 24).
Regarding claim 10, Srivastava discloses the system of claim 8, wherein the congestion controller is integrated into the networking device (Srivastava, para. 25).
Regarding claim 11, Srivastava discloses the system of claim 8, wherein data flows are qualified as the large data flow in response to the networking device determining that the data flow will result in more than a predetermined number of operations being performed during a workflow (Srivastava discloses that upon determining that the queue length for the packet flow (data flow) is greater than the threshold (predetermined number), the ingress fabric endpoint 20A determines that the flow is congested, which the ingress endpoint 20A switches data for the packet flows in the external memory) (Srivastava, para. 52).
Regarding claim 13, Srivastava discloses the system of claim 8, wherein data flows are qualified as the small data flow in response to the networking device determining that the data flow will result in less than a predetermined number of operations being performed during a workflow (Srivastava discloses that upon determining that the queue length for the packet flow (data flow) is less than the threshold, the ingress fabric endpoint 20A determines that the flow is uncongested, which the ingress endpoint 20A stores all packet flows in the internal memory) (Srivastava, para. 52).
Regarding claim 15, Srivastava discloses the system of claim 8, wherein data flows are sorted between the small data flow and large data flow based on a size of the data flow being compared to a predetermined flow threshold (Srivastava discloses that the ingress fabric endpoint 20A compares the queue length for a packet flow to a threshold to determine whether the packet flow is congested or uncongested; upon determining that the packet flow (data flow) is greater than the threshold, the packet is determined as congested, the ingress endpoint 20A switches data for the packet flow to an external memory, while data for the other packet flows that are uncongested are continued to be stored in the internal memory) (Srivastava, para. 52).
Regarding claim 19, Srivastava discloses a device, comprising: processing circuitry (Srivastava, para. 96); and computer memory (Srivastava, para. 96) coupled to the processing circuitry, wherein the processing circuitry is to execute instructions stored in the computer memory thereby enabling the device to:
receive information describing a data flow directed toward a processing network (Srivastava discloses that the network device 4 receives a plurality of packet flows and processes the packet flows to generate a stream of discrete data units known as cells) (Srivastava, para. 31); and
based on an analysis of the information describing the data flow, cause the data flow to bypass a congestion controller that manages data flows in the processing network (Srivastava discloses that upon determining that the queue length for the packet flow (data flow) is less than the threshold, the ingress fabric endpoint 20A determines that the flow is uncongested, which the ingress endpoint 20A stores all packet flows in the internal memory) (Srivastava, para. 52).
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 3-6, 12, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Srivastava et al. (2020/0213232, hereinafter Srivastava) as applied to claims 1, 8, and 11 above, and further in view of Zhao et al. (2019/0324856, hereinafter Zhao).
Regarding claim 3, Srivastava discloses the networking device of claim 1, but does not explicitly disclose wherein the predetermined flow threshold is defined by a number of operations to be performed.
In analogous art, Zhao teaches wherein the predetermined flow threshold is defined by a number of operations to be performed (Zhao discloses that the predefined checkpoint criterion (threshold) may specify to generate a checkpoint of an intermediate DL model after a certain number of iterations (number of operations) of the DL training process have been completed) (Zhao, Fig. 5; para. 54-55).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Zhao related to the predetermined flow threshold is defined by a number of operations to be performed and to combine with Srivastava in order to optimize the checkpoint operations in high performance computing applications (Zhao, para. 7).
Regarding claim 4, Srivastava discloses the networking device of claim 1, but does not explicitly disclose wherein the predetermined flow threshold is defined by a percentage of operations to be performed having a message size less than a predetermined message size.
In analogous art, Zhao teaches wherein the predetermined flow threshold is defined by a percentage of operations to be performed having a message size less than a predetermined message size (Zhao discloses that the one or more predefined conditions (percentage of operations and/or message size) that specifies a checkpoint of an intermediate DL model to be generated wherein the conditions have been met for the intermediate DL model to determine a percentage of the number of test samples that were properly classified based on the determined accuracy) (Zhao, Fig. 5; para. 54-55).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Zhao related to the predetermined flow threshold is defined by a percentage of operations to be performed and to combine with Srivastava in order to optimize the checkpoint operations in high performance computing applications (Zhao, para. 7).
Regarding claim 5, Srivastava discloses the networking device of claim 1, but does not explicitly disclose wherein the processing network comprises a plurality of processes belonging to a collective and wherein each process in the plurality of processes sends at least one message to every other process in the plurality of processes.
In analogous art, Zhao teaches wherein the processing network comprises a plurality of processes belonging to a collective and wherein each process in the plurality of processes sends at least one message to every other process in the plurality of processes (Zhao discloses that the one or more predefined conditions (percentage of operations and/or message size) that specifies a checkpoint of an intermediate DL model to be generated wherein the conditions have been met for the intermediate DL model to determine a percentage of the number of test samples that were properly classified based on the determined accuracy) (Zhao, Fig. 5; para. 54-55).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Zhao related to the predetermined flow threshold is defined by a percentage of operations to be performed and to combine with Srivastava in order to optimize the checkpoint operations in high performance computing applications (Zhao, para. 7).
Regarding claim 6, Srivastava discloses the networking device of claim 1, but does not explicitly disclose wherein the processing network employs all-to-all communication.
In analogous art, Zhao teaches wherein the processing network employs all-to-all communication (Zhao discloses that the distributed DL training application using a decentralized cluster of GPU devices that exchange model parameters using a collective communication method such as ring allreduce protocol, allgather, etc.) (Zhao, Fig. 4; para. 50).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Zhao related to the processing network employs all to all communication and to combine with Srivastava in order to optimize the checkpoint operations in high performance computing applications (Zhao, para. 7).
Regarding claim 12, Srivastava discloses the system of claim 11, but does not explicitly disclose wherein the workflow comprises a Deep Learning Recommendation Model (DLRM).
In analogous art, Zhao teaches wherein the workflow comprises a Deep Learning Recommendation Model (DLRM) (Zhao discloses that the deep learning computing platform 110 comprises a plurality of application layers including deep learning model 120, checkpoint optimization module 130, and a deep learning compute module 140) (Zhao, para. 18, 35).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Zhao related to having the workflow comprising a deep learning recommendation model and to combine with Srivastava in order to optimize checkpoint operations in high performance computing applications (Zhao, para. 7).
Regarding claim 14, Srivastava discloses the system of claim 8, but does not explicitly disclose wherein the network fabric employs all-to-all communication.
In analogous art, Zhao teaches wherein the network fabric employs all-to-all communication (Zhao discloses that the distributed DL training application using a decentralized cluster of GPU devices that exchange model parameters using a collective communication method such as ring allreduce protocol, allgather, etc.) (Zhao, Fig. 4; para. 50).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Zhao related to the processing network employs all to all communication and to combine with Srivastava in order to optimize the checkpoint operations in high performance computing applications (Zhao, para. 7).
Claims 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Srivastava et al. (2020/0213232, hereinafter Srivastava) as applied to claim 8 above, and further in view of Meylan et al. (2021/0235465, hereinafter Meylan).
Regarding claim 16, Srivastava discloses the system of claim 8, but does not explicitly disclose wherein the networking device qualifies the data flows as either the large data flow or the small data flow based on a Quality of Service (QOS) adaptation.
In analogous art, Meylan teaches wherein the networking device qualifies the data flows as either the large data flow or the small data flow based on a Quality of Service (QOS) adaptation (Meylan discloses that the service data adaptation protocol may determine one or more quality of service flows) (Meylan, para. 88).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Meylan related to the networking device qualifies the data flows based on QoS adaptation and to combine with Srivastava in order to enhance the efficiency for high reliability and low latency communication operations (Meylan, para. 51).
Regarding claim 17, Srivastava and Meylan discloses the system of claim 16, wherein the QoS adaptation is adjusted based on one or more of: changing allocated buffers (Meylan discloses that the base station schedules the downlink communications and the uplink communications based on the indication of the preference of the UE associated with allocating the buffer) (Meylan, para. 88), shared buffer properties (Meylan discloses that the UE may have a limited amount of available memory because the memory in the UE may be shared with other memory intensive tasks) (Meylan, para. 92), arbiter prioritization based on an indication of a collective, and arbiter prioritization based on a size of the collective.
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Meylan related to the QoS adaptation is adjusted based on changing of allocated buffers and shared buffer properties and to combine with Srivastava and Meylan in order to enhance the efficiency for high reliability and low latency communication operations (Meylan, para. 51).
Regarding claim 18, Srivastava and Meylan discloses the system of claim 16, wherein the QoS adaptation is adjusted based on shared buffer properties and wherein the shared buffer properties comprise at least one of an amount of a shared buffer allocated to a port and a speed with which the port can consume the shared buffer allocated thereto (Meylan discloses that the base station schedules the downlink communications and the uplink communications based on the indication (speed which the port can consume) of the preference of the UE associated with allocating the buffer) (Meylan, para. 94).
Therefore it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the teachings of Meylan related to the QoS adaptation is adjusted based on shared buffer properties and to combine with Srivastava and Meylan in order to enhance the efficiency for high reliability and low latency communication operations (Meylan, para. 51).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW WOO whose telephone number is (571)270-7521. The examiner can normally be reached Telework 9:00AM-6:00PM | IFP M-F 9:00AM-6:00PM.
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, Umar Cheema can be reached at 571-270-3037. 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.
/ANDREW WOO/Examiner, Art Unit 2458
/UMAR CHEEMA/Supervisory Patent Examiner, Art Unit 2458
Prosecution Insights