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 .
DETAILED ACTION
Response to Amendment
Applicant’s amendment, filed 02/25/2026, has been entered and carefully considered. Claims 2-5, 9-13, 18-21 and 25 are amended. Claims 2, 10 and 18 are independent. Claims 2-25 are currently pending.
Response to Arguments
Applicant's arguments filed 10/26/2022 have been fully considered but they are not persuasive.
Regarding claim 2, Applicant argued that
Applicant argued that
Brahim does not teach or suggest: each routing capability being associated with a routing algorithm for computing a path across a network based on a set of routing criteria.
Examiner respectfully disagrees.
Brahim discloses in Paragraphs 0023, 0034, 0039 discloses the egress peer node provides flow statistics to the SDN controller 140 for use by the SDN controller to determine the flow information, the configuration of the egress peer node by the SDN controller 140 to collect flow statistics and provide the flow statistics to the SDN controller 140 may be based on a flow statistics collection protocol (e.g., Netflow IPFIX or the like), a control protocol (e.g., OpenFlow, BGP FlowSpec, or the like), or the like, as well as various combinations thereof. The egress peer node may already be configured to provide information to the SDN controller 140 at the time that the egress peer node is selected by the SDN controller 140 (e.g., based on previous installation of rules related to collection of flow statistics on the egress peer node), may be configured by the SDN controller 140 to provide information to the SDN controller 140 based on selection of the egress peer node by the SDN controller 140 (e.g., the SDN controller 140 installs rules related to collection of flow statistics on the egress peer node after selection of the egress peer node by the SDN controller 140), or the like. Further In the example of FIG. 2, as indicated by the flow information of flow information table 201, the SDN controller 140 identifies the top three traffic flows, in terms of bandwidth consumption, on egress peer link 122 of egress BR 119-1. The top three traffic flows include a first traffic flow (which is indicated by a source/destination IP address pair of 1.1.1.0/24) for which egress peer link 122 of egress BR 119-1 supports 2.5 M, a second traffic flow (which is indicated by a source/destination IP address pair of 2.2.1.0/24) for which egress peer link 122 of BR 119-1 supports 2 M, and a third traffic flow (which is indicated by a source/destination IP address pair of 3.3.1.0/24) for which egress peer link 122 of BR 119-1 supports 1 M. Examiner noted that computing a path reads on selection of route/flow/path which is same interpretation discloses in Brahim.
Applicant argued that
Brahim does not teach or suggest: identifying, based at least in part on the received indications, one or more network nodes from the plurality of network nodes that support the determined routing capability.
Examiner respectfully disagrees.
Brahim discloses in Fig. 2, the SDN controller 140 identifies the top three traffic flows (identifying and selecting traffic nodes that support the routing criterion), in terms of bandwidth consumption, on egress peer link 122 of egress BR 119-1. The top three traffic flows include a first traffic flow (which is indicated by a source/destination IP address pair of 1.1.1.0/24) for which egress peer link 122 of egress BR 119-1 supports 2.5 M, a second traffic flow (which is indicated by a source/destination IP address pair of 2.2.1.0/24) for which egress peer link 122 of BR 119-1 supports 2 M, and a third traffic flow (which is indicated by a source/destination IP address pair of 3.3.1.0/24) for which egress peer link 122 of BR 119-1 supports 1 M). Further paragraphs 0039-0040 disclose the SDN controller 140 may initiate a management action to attempt to alleviate the congestion on the egress peer link due to the traffic flow. The SDN controller 140 may select, from the set of ingress PE devices that are contributing to congestion of the given traffic flow on the egress peer link (forgoing selection of communication links that are associated with the exclusionary constraints corresponding to the routing criterion). The SDN controller 140 may select, from the set of ingress PE devices that are contributing to congestion on the egress peer link, a selected ingress PE device sending traffic to the egress peer link (e.g., the ingress PE device sending the most traffic to the egress peer link, the ingress PE device sending the next-to-most traffic to the egress peer link, or the like) and may initiate redirection of traffic from being sent from the selected ingress PE device to the egress peer link to being sent from the selected ingress PE device to an alternate egress peer link (e.g., of the same egress peer node or a different egress peer node.
Examiner noted that Applicant’s specification (US 2019/0007305 A1) discloses (selection mechanism) in paragraph 0028 that the method 200 includes determining the routing criterion based on a type of the set of data packets. As represented by block 210b, in some implementations, the method 200 includes selecting the routing criterion from a plurality of routing criteria. In some implementations, the method 200 includes determining the routing criterion by selecting an existing routing criterion. In some implementations, the method 200 includes determining the routing criterion by modifying an existing routing criterion. In some implementations, the method 200 includes determining the routing criterion by creating a new routing criterion. And paragraphs 0024, 0032 discloses exclusionary constraints mechanism as the method 200 includes selecting network nodes and/or communication links that are not associated with exclusionary constraints corresponding to the routing criterion. In some implementations, the routing criterion indicates one or more exclusionary constraints (e.g., characteristics of network nodes and/or communication links that are to be avoided). In such implementations, the method 200 includes forgoing selecting network nodes and/or communication links with characteristics that are among the exclusionary constraints.
Applicant further argued that the cited prior art of record does not disclose determining, based on the routing algorithm associated with the determined routing capability, a route for the first set of data packets through the one or more network nodes and communication links that support the determined routing capability.
Examiner respectfully disagrees.
Chawla discloses Fig. 4, paragraphs 0021-0028, 0033-0040 disclose the management IHS 202 that allows a network administrator or other user of the IHS network to provide a plurality of DCB configuration details that may include the identity of data traffic flows, priorities for data traffic flows, bandwidth allocations for data traffic flows, lossless behavior requests for data traffic flows, congestion notification requests for data traffic flows. At step 404 where a data traffic flow is identified. Paragraphs 0033-0040 disclose a second data traffic flow being identified, a second flow path through the IHS network determined for the second data traffic flow, and the switch IHSs in the second flow path configured to provide a second QoS for the second data traffic flow; and so on. Table A provided above and illustrating the hardware queue in a switch IHS includes a situation in which each of a first data traffic flow and a second data traffic flow have been identified (data traffic flow 1 and data traffic flow 2 in the table), a first flow path for the first data traffic flow and a second flow path for the second data traffic flow determined that each include that switch IHS, and the switch IHS configured to provide a first QoS for the first data traffic flow (90% transmission and receive bandwidth and highest priority for data traffic flow 1) and a second QoS for the second data traffic flow (10% transmission and receive bandwidth and lower priority for data traffic flow 2 relative to data traffic flow 1
Thus, rejection of claim 2 is maintained.
Similar arguments are applied to claims 10 and 18.
Regarding claims 3-9, 11-17 and 19-25, these claims depend from claim 2, 10 and 18 respectively, and thus are rejected for the same reason claim 2, 10 and 18.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
The following claim limitations, of claims 10-17, “criterion determination module, a route determination module and a node link/link determination module, without reciting sufficient structure to achieve the functions or being preceded by a structural modifier. Since the claim limitations invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, claims 7-14 has/have been interpreted to cover the corresponding structure described in the specification that achieves the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitation: Figure 3 discloses the various different module to perform the recited functions and corresponding description that describe the functions of the various modules, and paragraph [0043] [specification] “the memory 306 or the non-transitory computer
readable storage medium of the memory 306 stores the following programs, modules and data structures, or a subset thereof including an optional operating system 308, a routing criterion determination module 310, a node/link identification module 320, a route determination module 330, and a configuration module 340. In various implementations, the routing criterion determination module 310 determines a routing criterion that is to be used to transmit a first set of data packets across a network. To that end, the routing criterion determination module 310 includes instructions 310a, and heuristics and metadata 310b” described above.
If applicant wishes to provide further explanation or dispute the examiner’s interpretation of the corresponding structure, applicant must identify the corresponding structure with reference to the specification by page and line number, and to the drawing, if any, by reference characters in response to this Office action. If applicant does not intend to have the claim limitations treated under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112 , sixth paragraph, applicant may amend the claims so that they will clearly not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, or present a sufficient showing that the claim limitations recite sufficient structure, material, or acts for performing the claimed function to preclude application of 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
For more information, see MPEP § 2173 et seq. and Supplementary Examination Guidelines for Determining Compliance With 35 U.S.C. 112 and for Treatment of Related Issues in Patent Applications, 76 FR 7162, 7167 (Feb. 9, 2011).
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 obviousness-type 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 a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 2-5, 9, 10-13, 17, 18-21 and 25 are provisionally rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-23 of copending Application No. 12,323,322 B2. Although the conflicting claims are not identical, they are not patentably distinct from each other.
One of ordinary skill in the art would conclude that the claims at issue are obvious variants of one another because the method claims in US patent Application 12,323,322 B2 comprise substantially the same limitations as the identified method, system and a non-transitory computer-readable medium claims in the instant application. With regards to the system claims, it would have been obvious to one of ordinary skill in the art to implement the method steps detailed in Claim 1 in a system comprising a system for configurable traffic routing comprising: a plurality of network nodes, each network node including a network interface, a non-transitory memory and one or more processors coupled with the non-transitory memory to perform the steps as described in independent claims.
This is a provisional obviousness-type double patenting rejection because the conflicting claims have not in fact been patented.
Claims 2-5, 9, 10-13, 17, 18-21 and 25 are provisionally rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-20 of US patent 11,050,662 B2. Although the conflicting claims are not identical, they are not patentably distinct from each other.
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 2-3, 9-11, 17-19 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Ould Brahim et al. (US 2018/0167458 A1, hereinafter referred as Brahim). in view of Chawla et al. (US 2015/0026313 A1).
Regarding claim 2, Brahim discloses a method comprising (Fig. 2 discloses the mechanism of a network comprising a controller which configured to discover set of ingress PE devices providing traffic to an egress PE devices): at each of a plurality of a network nodes, indicating over the network one or more routing capabilities supported by the network node (Paragraphs 0034-0040 disclose determined by the SDN controller 140 based on information received by the SDN controller 140 from the egress peer node (e.g., based on processing of flow statistics received from the egress peer node), the configuration of the egress peer node by the SDN controller 140 to collect flow statistics (routing capabilities) and provide the flow information and the providing of the flow information to the SDN controller 140 may be based on a control protocol (e.g., OpenFlow, BGP FlowSpec, Netflow or the like), each routing capability being associated with a routing algorithm for computing a path across a network based on a set of routing criteria (Paragraphs 0023, 0034, 0039 discloses the egress peer node provides flow statistics to the SDN controller 140 for use by the SDN controller to determine the flow information, the configuration of the egress peer node by the SDN controller 140 to collect flow statistics and provide the flow statistics to the SDN controller 140 may be based on a flow statistics collection protocol (e.g., Netflow IPFIX or the like), a control protocol (e.g., OpenFlow, BGP FlowSpec, or the like), or the like, as well as various combinations thereof. The egress peer node may already be configured to provide information to the SDN controller 140 at the time that the egress peer node is selected by the SDN controller 140 (e.g., based on previous installation of rules related to collection of flow statistics on the egress peer node), may be configured by the SDN controller 140 to provide information to the SDN controller 140 based on selection of the egress peer node by the SDN controller 140 (e.g., the SDN controller 140 installs rules related to collection of flow statistics on the egress peer node after selection of the egress peer node by the SDN controller 140), or the like. Further In the example of FIG. 2, as indicated by the flow information of flow information table 201, the SDN controller 140 identifies the top three traffic flows, in terms of bandwidth consumption, on egress peer link 122 of egress BR 119-1. The top three traffic flows include a first traffic flow (which is indicated by a source/destination IP address pair of 1.1.1.0/24) for which egress peer link 122 of egress BR 119-1 supports 2.5 M, a second traffic flow (which is indicated by a source/destination IP address pair of 2.2.1.0/24) for which egress peer link 122 of BR 119-1 supports 2 M, and a third traffic flow (which is indicated by a source/destination IP address pair of 3.3.1.0/24) for which egress peer link 122 of BR 119-1 supports 1 M);
receiving, by a first network node, the indications regarding the one or more routing capabilities supported by each of the plurality of nodes (Paragraph 0034 discloses the traffic flows may be the top N (N≥1) traffic flows on the egress peer link, which may be measured in terms of bandwidth. The SDN controller 140 may identify the set of traffic flows on the egress peer link based on flow information associated with the egress peer link. The flow information associated with the egress peer link may include per-flow bandwidth information that includes, for each of the traffic flows, an indication of the amount of bandwidth of the respective traffic flow that is supported by the egress peer link. The per-flow bandwidth information may be based on flow statistics which may be collected for the traffic flows on the egress peer node and the egress peer link);
determining, at the first network node, a routing capability of the one or more routing capabilities to use to transmit a first set of data packets across the network (Fig. 2, paragraphs 0039-0040 disclose the SDN controller 140 may initiate a management action to attempt to alleviate the congestion on the egress peer link due to the traffic flow. The SDN controller 140 may select, from the set of ingress PE devices that are contributing to congestion of the given traffic flow on the egress peer link. The SDN controller 140 may select, from the set of ingress PE devices that are contributing to congestion on the egress peer link, a selected ingress PE device sending traffic to the egress peer link (e.g., the ingress PE device sending the most traffic to the egress peer link, the ingress PE device sending the next-to-most traffic to the egress peer link, or the like) and may initiate redirection of traffic from being sent from the selected ingress PE device to the egress peer link to being sent from the selected ingress PE device to an alternate egress peer link (e.g., of the same egress peer node or a different egress peer node);
identifying, based at least in part on the received indications, one or more network nodes from the plurality of network nodes that support the determined routing capability (Paragraphs 0034-0040 disclose the SDN controller 140 identifies a first set of traffic flows on the egress peer node and the egress peer link for which ingress PE device discovery is to be performed (which also may be referred to as a first set of traffic flows of interest or, more simply, traffic flows of interest). The traffic flows on the egress peer link may include all of the traffic flows on the egress peer link or a subset of the traffic flows on the egress peer link. The traffic flows may be the top N (N.gtoreq.1) traffic flows on the egress peer link, which may be measured in terms of bandwidth. The SDN controller 140 may identify the set of traffic flows on the egress peer link based on flow information associated with the egress peer link. The flow information associated with the egress peer link may include per-flow bandwidth information that includes, for each of the traffic flows, an indication of the amount of bandwidth of the respective traffic flow that is supported by the egress peer link);
Brahim does not specifically disclose the mechanism of determining, based on the routing algorithm associated with the determined routing capability, a route for the first set of data packets through the one or more network nodes and communication links that support the determined routing capability; and propagating the first set of data packets along the determined route.
In an analogous art, Chawla discloses determining, based on the routing algorithm associated with the determined routing capability, a route for the first set of data packets through the one or more network nodes and communication links that support the determined routing capability; and 3S/N: 17/360,283 propagating the set of data packets along the determined route (Fig. 4, paragraphs 0021-0028, 0033-0040 disclose the management IHS 202 that allows a network administrator or other user of the IHS network to provide a plurality of DCB configuration details that may include the identity of data traffic flows, priorities for data traffic flows, bandwidth allocations for data traffic flows, lossless behavior requests for data traffic flows, congestion notification requests for data traffic flows. At step 404 where a data traffic flow is identified. Paragraphs 0033-0040 disclose a second data traffic flow being identified, a second flow path through the IHS network determined for the second data traffic flow, and the switch IHSs in the second flow path configured to provide a second QoS for the second data traffic flow; and so on. Table A provided above and illustrating the hardware queue in a switch IHS includes a situation in which each of a first data traffic flow and a second data traffic flow have been identified (data traffic flow 1 and data traffic flow 2 in the table), a first flow path for the first data traffic flow and a second flow path for the second data traffic flow determined that each include that switch IHS, and the switch IHS configured to provide a first QoS for the first data traffic flow (90% transmission and receive bandwidth and highest priority for data traffic flow 1) and a second QoS for the second data traffic flow (10% transmission and receive bandwidth and lower priority for data traffic flow 2 relative to data traffic flow 1),
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the technique of Chawla to the system of Brahim to provide systems and methods for configuring and managing a Data Center Bridged (DCB) Information Handling System (IHS) network include a plurality of switch IHSs that are connected together and which also utilize flow based networking to configure and manage the IHS network (Abstract, Chawla).
Regarding claim 10, claim 10 comprises substantially similar limitations as claimed in claim 2, claimed as a system to perform the steps of clam 2.
Regarding claim 10, Brahim discloses a system for configurable traffic routing comprising (Fig. 2 discloses the mechanism of a network comprising a controller which configured to discover set of ingress PE devices providing traffic to an egress PE devices): a plurality of network nodes, each network node including a network interface, (Fig. 2 discloses a controller apparatus which includes a processor and a memory configured to identify a first set of traffic flows on an egress peer link of an egress peer node), wherein each network node supports routing packets according to one or more routing capabilities (Paragraphs 0034-0040 disclose determined by the SDN controller 140 based on information received by the SDN controller 140 from the egress peer node (e.g., based on processing of flow statistics received from the egress peer node), the configuration of the egress peer node by the SDN controller 140 to collect flow statistics (routing capabilities) and provide the flow information and the providing of the flow information to the SDN controller 140 may be based on a control protocol (e.g., OpenFlow, BGP FlowSpec, Netflow or the like);, each routing capability of the one or more routing capabilities being associated with a routing algorithm for computing a path across a network based on a set of routing criteria (Paragraphs 0023, 0034, 0039 discloses the egress peer node provides flow statistics to the SDN controller 140 for use by the SDN controller to determine the flow information, the configuration of the egress peer node by the SDN controller 140 to collect flow statistics and provide the flow statistics to the SDN controller 140 may be based on a flow statistics collection protocol (e.g., Netflow IPFIX or the like), a control protocol (e.g., OpenFlow, BGP FlowSpec, or the like), or the like, as well as various combinations thereof. The egress peer node may already be configured to provide information to the SDN controller 140 at the time that the egress peer node is selected by the SDN controller 140 (e.g., based on previous installation of rules related to collection of flow statistics on the egress peer node), may be configured by the SDN controller 140 to provide information to the SDN controller 140 based on selection of the egress peer node by the SDN controller 140 (e.g., the SDN controller 140 installs rules related to collection of flow statistics on the egress peer node after selection of the egress peer node by the SDN controller 140), or the like. Further In the example of FIG. 2, as indicated by the flow information of flow information table 201, the SDN controller 140 identifies the top three traffic flows, in terms of bandwidth consumption, on egress peer link 122 of egress BR 119-1. The top three traffic flows include a first traffic flow (which is indicated by a source/destination IP address pair of 1.1.1.0/24) for which egress peer link 122 of egress BR 119-1 supports 2.5 M, a second traffic flow (which is indicated by a source/destination IP address pair of 2.2.1.0/24) for which egress peer link 122 of BR 119-1 supports 2 M, and a third traffic flow (which is indicated by a source/destination IP address pair of 3.3.1.0/24) for which egress peer link 122 of BR 119-1 supports 1 M)
wherein each network node transmits an indication of the supported routing capabilities on the network interface (Paragraphs 0034-0040); a communications network with links interconnecting the plurality of network nodes in a physical topology (Fig. 2 discloses the network nodes in a physical topology exchanging communication messages regarding flow statistics, flow tables, source and destination information); the system further including a criterion determination module, a node/link determination module, and a route determination module (Fig. 6 discloses a computer which has a processor/memory and cooperating element to perform the determination steps, I/O device to perform the transmitting/receiving functions, identify paths/links etc.);
wherein the criterion determination module is configured to determine one or more operator-defined routing criteria to transmit a first set of data packets across the communication network (Paragraph 0034 discloses the traffic flows may be the top N (N≥1) traffic flows on the egress peer link, which may be measured in terms of bandwidth. The SDN controller 140 may identify the set of traffic flows on the egress peer link based on flow information associated with the egress peer link. The flow information associated with the egress peer link may include per-flow bandwidth information that includes, for each of the traffic flows, an indication of the amount of bandwidth of the respective traffic flow that is supported by the egress peer link. The per-flow bandwidth information may be based on flow statistics which may be collected for the traffic flows on the egress peer node and the egress peer link), wherein the one or more operator-defined routing criteria are associated with a determined routing 24Attorney Docket No.: 60374.1596USC4/1013047-US.06 capability of the one or more routing capabilites, (Paragraphs 0023, 0034, 0039 discloses in the network 110, the egress BR 119-2 is available as an alternate egress peer node for each of the ingress PE devices 111-1, 111-2, and 111-3. FIG. 2, as indicated by the flow information of flow information table 201, the SDN controller 140 identifies the top three traffic flows, in terms of bandwidth consumption, on egress peer link 122 of egress BR 119-1. The top three traffic flows include a first traffic flow (which is indicated by a source/destination IP address pair of 1.1.1.0/24) for which egress peer link 122 of egress BR 119-1 supports 2.5 M, a second traffic flow (which is indicated by a source/destination IP address pair of 2.2.1.0/24) for which egress peer link 122 of BR 119-1 supports 2 M, and a third traffic flow (which is indicated by a source/destination IP address pair of 3.3.1.0/24) for which egress peer link 122 of BR 119-1 supports 1 M);
wherein the node/link determination module is configured to identify network nodes and communication links in the communication network that satisfy the determined routing capability; and wherein the route determination module is configured to use the routing algorithm of the determined routing capability and the one or more operator-defined routing criteria to identify a route for data packets through the network nodes (Fig. 2, paragraphs 0039-0040 disclose the SDN controller 140 may initiate a management action to attempt to alleviate the congestion on the egress peer link due to the traffic flow. The SDN controller 140 may select, from the set of ingress PE devices that are contributing to congestion of the given traffic flow on the egress peer link. The SDN controller 140 may select, from the set of ingress PE devices that are contributing to congestion on the egress peer link, a selected ingress PE device sending traffic to the egress peer link (e.g., the ingress PE device sending the most traffic to the egress peer link, the ingress PE device sending the next-to-most traffic to the egress peer link, or the like) and may initiate redirection of traffic from being sent from the selected ingress PE device to the egress peer link to being sent from the selected ingress PE device to an alternate egress peer link (e.g., of the same egress peer node or a different egress peer node);
the communication links that support the routing capability and control the network performance metric (Paragraphs 0034-0040 disclose the SDN controller 140 identifies a first set of traffic flows on the egress peer node and the egress peer link for which ingress PE device discovery is to be performed (which also may be referred to as a first set of traffic flows of interest or, more simply, traffic flows of interest). The traffic flows on the egress peer link may include all of the traffic flows on the egress peer link or a subset of the traffic flows on the egress peer link. The traffic flows may be the top N (N.gtoreq.1) traffic flows on the egress peer link, which may be measured in terms of bandwidth. The SDN controller 140 may identify the set of traffic flows on the egress peer link based on flow information associated with the egress peer link. The flow information associated with the egress peer link may include per-flow bandwidth information that includes, for each of the traffic flows, an indication of the amount of bandwidth of the respective traffic flow that is supported by the egress peer link);
Brahim does not specifically disclose the mechanism of wherein the system is operable to configure the set of network nodes and links corresponding to the route identified by the route determination module to exchange a first set of packets traversing the system using the identified route.
In an analogous art, Chawla discloses wherein the system is operable to configure the network nodes and the communication links corresponding to the route identified by the route determination module to exchange a first set of packets traversing the communication network using the identified route (Fig. 4, paragraphs 0021-0028, 0033-0040 disclose the management IHS 202 that allows a network administrator or other user of the IHS network to provide a plurality of DCB configuration details that may include the identity of data traffic flows, priorities for data traffic flows, bandwidth allocations for data traffic flows, lossless behavior requests for data traffic flows, congestion notification requests for data traffic flows. At step 404 where a data traffic flow is identified. Paragraphs 0033-0040 disclose a second data traffic flow being identified, a second flow path through the IHS network determined for the second data traffic flow, and the switch IHSs in the second flow path configured to provide a second QoS for the second data traffic flow; and so on. Table A provided above and illustrating the hardware queue in a switch IHS includes a situation in which each of a first data traffic flow and a second data traffic flow have been identified (data traffic flow 1 and data traffic flow 2 in the table), a first flow path for the first data traffic flow and a second flow path for the second data traffic flow determined that each include that switch IHS, and the switch IHS configured to provide a first QoS for the first data traffic flow (90% transmission and receive bandwidth and highest priority for data traffic flow 1) and a second QoS for the second data traffic flow (10% transmission and receive bandwidth and lower priority for data traffic flow 2 relative to data traffic flow 1),
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the technique of Chawla to the system of Brahim to provide systems and methods for configuring and managing a Data Center Bridged (DCB) Information Handling System (IHS) network include a plurality of switch IHSs that are connected together and which also utilize flow based networking to configure and manage the IHS network (Abstract, Chawla).
Regarding claim 18, claim 18 comprises substantially similar limitations as claimed in claim 2, claimed as a non-transitory computer readable storage medium storing containing logic (Fig. 2 discloses a controller apparatus which includes a processor and a memory configured to identify a first set of traffic flows on an egress peer link of an egress peer node), when executed by one or more processor to perform the steps of clam 2.
Regarding claims 3, 11 and 19, Brahim does not disclose wherein the route taken by the first set of packets traversing the network is different than a second route taken by a second set of packets traversing the network, the second route calculated using a second routing algorithm associated with a second determined routing capability.
In an analogous art, Chawla discloses wherein the route taken by the first set of packets traversing the network is different than a second route taken by a second set of packets traversing the network, the second route calculated using the uniform routing criterion using a second routing algorithm associated with a second determined routing capability (Fig. 5a disclose the three flow and each flow has different routing criteria from the first one. Paragraphs 0033-0040 disclose each flow identifier has its own identity as also disclosed in Fig. 5a, 506, 508 and 510. Paragraph 0039 discloses method 400 may be performed similarly for each of the data traffic flow 2 and the data traffic flow 3 in the data traffic flow sections 508 and 510, respectively. Furthermore, at any time, the network administrator may use the data traffic flow management screen 504 to reconfigure switch IHSs in a flow path to change the QoS for any data traffic flow by providing inputs in the priority input, the minimum bandwidth input, the lossless selector, and/or the congestion notification selector for that data traffic flow).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the technique of Chawla to the system of Brahim to provide systems and methods for configuring and managing a Data Center Bridged (DCB) Information Handling System (IHS) network include a plurality of switch IHSs that are connected together and which also utilize flow based networking to configure and manage the IHS network (Abstract, Chawla).
Regarding claim 9, Brahim discloses wherein two or more network nodes from the plurality of network nodes each receive the indications from other nodes regarding the routing capabilities supported by other network nodes (Fig. 2, paragraphs 0034-0040) and wherein each network node from the two or more network nodes determines a forwarding entry for each routing capability based in part upon the indications received from other network nodes Fig. 2, paragraphs 0034-0040 disclose the flow information of flow information table 202-1 associated with ingress PE device 111-1, the SDN controller 140 determines, for each of the traffic flows traversing the egress peer link 122 of the egress BR 119-1 that is sourced from the ingress PE device 111-1, an indication of an amount of bandwidth of that traffic flow that is sent from ingress PE device 111-1 to the egress peer link 122 of the egress BR 119-1 (e.g., for the traffic flow denoted using 1.1.1.0/24 the ingress PE device 111-1 sends 1 M of data to the egress peer link 122 of the egress BR 119-1 and for the traffic flow denoted using 2.2.1.0/24 the ingress PE device 111-1 sends 1.5 M of data to the egress peer link 122 of the egress BR 119-1). Similarly, in the example of FIG. 2, as indicated by the flow information of flow information table 202-2 associated with ingress PE device 111-2, the SDN controller 140 determines, for each of the traffic flows traversing the egress peer link 122 of the egress BR 119-1 that is sourced from the ingress PE device 111-2, an indication of an amount of bandwidth of that traffic flow that is sent from the ingress PE device 111-2 to the egress peer link 122 of the egress BR 119-1 (e.g., for the traffic flow denoted using 1.1.1.0/24 the ingress PE device 111-2 sends 1 M of data to the egress peer link 122 of the egress BR 119-1 and for the traffic flow denoted using 2.2.1.0/24 the ingress PE device 111-2 sends 0.5 M of data to the egress peer link 122 of the egress BR 119-1).
Regarding claim 25, Brahim discloses receiving the indications from other nodes of two or more network nodes of the plurality of network nodes regarding the routing capabilities supported by other network nodes (Fig. 2, paragraphs 0034-0040) and determining a forwarding entry for each routing capability supported based in part upon the indications received from non-local network nodes (Fig. 2, paragraphs 0034-0040 disclose the flow information of flow information table 202-1 associated with ingress PE device 111-1, the SDN controller 140 determines, for each of the traffic flows traversing the egress peer link 122 of the egress BR 119-1 that is sourced from the ingress PE device 111-1, an indication of an amount of bandwidth of that traffic flow that is sent from ingress PE device 111-1 to the egress peer link 122 of the egress BR 119-1 (e.g., for the traffic flow denoted using 1.1.1.0/24 the ingress PE device 111-1 sends 1 M of data to the egress peer link 122 of the egress BR 119-1 and for the traffic flow denoted using 2.2.1.0/24 the ingress PE device 111-1 sends 1.5 M of data to the egress peer link 122 of the egress BR 119-1). Similarly, in the example of FIG. 2, as indicated by the flow information of flow information table 202-2 associated with ingress PE device 111-2, the SDN controller 140 determines, for each of the traffic flows traversing the egress peer link 122 of the egress BR 119-1 that is sourced from the ingress PE device 111-2, an indication of an amount of bandwidth of that traffic flow that is sent from the ingress PE device 111-2 to the egress peer link 122 of the egress BR 119-1 (e.g., for the traffic flow denoted using 1.1.1.0/24 the ingress PE device 111-2 sends 1 M of data to the egress peer link 122 of the egress BR 119-1 and for the traffic flow denoted using 2.2.1.0/24 the ingress PE device 111-2 sends 0.5 M of data to the egress peer link 122 of the egress BR 119-1).
Regarding claim 17, Brahim discloses wherein more than one node includes a node/link determination module and a route determination module (Fig. 6 discloses a computer which has a processor/memory and cooperating element to perform the determination steps, I/O device to perform the transmitting/receiving functions, identify paths/links etc.).
Claims 4, 12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ould Brahim et al. (US 2018/0167458 A1, hereinafter referred as Brahim). in view of Chawla et al. (US 2015/0026313 A1) and further in view of Ellis et al. (US 2018/0006931 A1).
Regarding claims 4, 12 and 20, the combination of Brahim and Chawla don’t disclose the mechanism of claims 4, 12 and 20.
In an analogous art, Ellis discloses wherein the routing algorithm of the determined routing capability is a shortest path routing algorithm (Paragraph 0168 and paragraphs 0184-0185 disclose OSPF computes the shortest-path tree for each route using a method based on Dijkstra's algorithm. The OSPF routing policies for constructing a route table are governed by link metrics associated with each routing interface. Cost factors may be the distance of a router (round-trip time), data throughput of a link, or link availability and reliability, which may be expressed as simple unitless numbers. This provides a dynamic process of traffic load balancing between routes of equal cost. The lowest latency path information which is used to provide the LLλPS wavelength switching capability may be used to improve OSPF, such as by configuring OSPF to compute the shortest path and/or lowest latency tree (e.g., lowest latency information also may be taken into account for OSPF).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the technique of Ellis to the modified system of Brahim and Chawla to provide capabilities for supporting one or more network zones and associated provider services based on latency information (Paragraph 0005, Ellis).
Claims 5, 7-8, 13, 15-16, 21 and 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Ould Brahim et al. (US 2018/0167458 A1, hereinafter referred as Brahim). in view of Chawla et al. (US 2015/0026313 A1) and further in view of Ye et al. (US 9,559,985 B1).
Regarding claims 5, 13 and 21, The combination of Brahim and Chawla don’t disclose the mechanism of claim 5.
In an analogous art, Ye discloses wherein determining the route for the first set of data packets includes excluding one or more links and/or network nodes based upon the set of routing criteria associated with the determined routing capability (Col. 10, lines 13-36, disclose the traffic engineering application 110 may determine a variety of different algorithms may be used to determine inter-node port weights, such as a least cost routing algorithm in which a least cost (e.g., fewest number of hops) may be weighted more heavily, or a weighted cost multipath routing algorithm, e.g., in which multiple least (or lower) cost paths may be weighted more heavily than higher cost paths. Of course, variations may be applied, for example, to avoid failed links, or to send less traffic on congested links, etc.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the technique of Ye to the modified system of Brahim and Chawla to provide routing and a weighted cost multipath routing with intra-node and inter-node port weights (Abstract, Ye).
Regarding claims 7, 15 and 23, The combination of Brahim and Chawla don’t disclose the mechanism of cited claims.
In an analogous art, Ye discloses wherein the excluded links and/or nodes are part of a shared risk link group (Col. 10, lines 13-36, disclose the traffic engineering application 110 may determine a variety of different algorithms may be used to determine inter-node port weights, such as a least cost routing algorithm in which a least cost (e.g., fewest number of hops) may be weighted more heavily, or a weighted cost multipath routing algorithm, e.g., in which multiple least (or lower) cost paths may be weighted more heavily than higher cost paths. Of course, variations may be applied, for example, to avoid failed links, or to send less traffic on congested links, etc.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the technique of Ye to the modified system of Brahim and Chawla to provide routing and a weighted cost multipath routing with intra-node and inter-node port weights (Abstract, Ye).
Regarding claims 8, 16 and 24, The combination of Brahim and Chawla don’t disclose the mechanism of cited claims.
In an analogous art, Ye discloses wherein the excluded links and/or nodes are excluded based upon an affinity. (Col. 10, lines 13-36, disclose the traffic engineering application 110 may determine a variety of different algorithms may be used to determine inter-node port weights, such as a least cost routing algorithm in which a least cost (e.g., fewest number of hops) may be weighted more heavily, or a weighted cost multipath routing algorithm, e.g., in which multiple least (or lower) cost paths may be weighted more heavily than higher cost paths. Of course, variations may be applied, for example, to avoid failed links, or to send less traffic on congested links, etc.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the technique of Ye to the modified system of Brahim and Chawla to provide routing and a weighted cost multipath routing with intra-node and inter-node port weights (Abstract, Ye).
Claims 6, 14 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Ould Brahim et al. in view of Chawla et al. and further in view of Ye et al. and further in view of Cheung et al. (US 2018/0088746 A1).
Regarding claims 6, 14 and 22 , The combination of Brahim, Chawla and Ye don’t disclose the mechanism of claims 6, 14 and 22 .
In an analogous art, Cheung discloses wherein the excluded links and/or nodes are labeled with a "color." (Paragraph 0161).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the technique of Cheung to the modified system of Brahim, Chawla and Ye to provide the mechanism of an indicator which shows one or more excluded from the path (Paragraph 0161).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Hao et al. (US 2017/0171066 A1) discloses a routing device used for routing a total amount of traffic from a source node to a destination node using parameters such as set an amount of traffic in one iteration; find a length for each link between source node and destination node ; find a best intermediate node ; and send a flow from source node, to destination node through intermediate node (Abstract, Hao).
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 ROMANI OHRI whose telephone number is (571)272-5420. The examiner can normally be reached 8:00am-5: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, UN C CHO can be reached on 5712727919. 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.
/ROMANI OHRI/Primary Examiner, Art Unit 2413
Prosecution Insights