DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to Applicant’s communication filed on 07/27/2026 Claims 1-4,6-8,10-16,18-25 have been examined. Claims 5,9,17 are cancelled.
Response to Arguments
Applicant’s arguments, see Remarks – Pages 13-14, filed on 7/27/2026, with respect to the rejections of claims 1,10,13,22 under 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Zahid et al. Publication No. US 2016/0127236 ( Zahid-236 hereinafter).
Note: the Zahid et al. Publication No. US 2016/0127236 ( Zahid-236 hereinafter) is different than the Zahid et al. 20160014049 that was previously used to reject cancelled claim 5.
With regards to 101 rejection. Applicant amendment overcome the rejection. Therefore, the rejection is withdrawn.
With regards to 112 rejection. Applicant amendment overcome the rejection. Therefore, the rejection is withdrawn
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3,7,10,11,13-15,19,21-23,25 are rejected under 35 U.S.C. 103 as being unpatentable over Plenderleith et al. Patent No. US 10,630,579 B1 (Plenderleith hereinafter) in view of Zahid et al. Publication No. US 2016/0127236 ( Zahid-236 hereinafter) .
Regarding claim 1,
Plenderleith teaches a method, applied to a first network device, and comprising:
obtaining first topology information comprising connection relationships between N second network device and P third network devices, wherein the N second network devices are upstream of the P third network devices, wherein N is an integer greater than or equal to 2, and wherein P is an integer greater than or equal to l (Col.2, lines 10-20 -The control system determines separate network paths using network topology information – Col.3, lines 20-30 -FIG. 1 is a diagram of an example network environment 100 in which separate network paths are determined and path information is sent to source devices for use in encapsulating network packets. In the example network environment 100, a simplified network area 110 is depicted that includes a number of network devices (e.g., routers, switches, or other types of network devices), including network devices 112, 114, 116, 118, 120, and 122. Fig.1 shows a topology with a first source device (130) and a second source device (132) upstream devices of a destination device (134).
obtaining communication relationships of M data flows from the N second network devices to the fourth network devices through P third network devices, wherein each of the communication relationships comprises source address information and destination address information, wherein K is an integer greater than or equal to one, and wherein M is an integer greater than or equal to 2 ( Col.2, lines 5-15 - In some solutions, a control system receives a request to keep network flows separate from a first source device to a destination device and from a second source device to the destination device so that the network flows - Col.6, lines 35-40 – the network path separation list can list two or more source devices by their IP addresses and a destination device by its IP address. For example, a network path separation list associated with the example network environment 200 can list: [first source device 130 IP address, second source device 132 IP address, destination device 134 IP address]. The network path separation list indicates that network traffic ( e.g., network flows) for each of the source devices should take different paths through at least a portion of the network to the destination device).
determining, M paths of the M data flows are from the N second network devices to the P third network devices (Fig. 5 & Col.11,lines 30-50 - At 520, separate network paths are determined through the computer network for the first network flow and the second network flow.. the separate network paths are determined based on topology of the computer network and/or hashing information for the computer network); and
sending the M paths to the N second network devices to cause the N second network devices to transmit M data flows through ports (Fig. 5 & Col.11,lines 30-50 - At 530, path information is sent to the first source device and the second source device. The first and second source 45 devices use the path information to encapsulate network packets that will then take the separate network paths through the computer network to the destination device).
However, Plenderleith does not explicitly teach
sequentially traversing egress ports on the N second network devices based on first sorting information to obtain a first mapping relationship, wherein the first sorting information indicates sorting of quantities of the N second network devices corresponding to the K fourth network devices, and wherein the first mapping relationship indicates mapping relationships between the egress ports and the K fourth network devices;
determining, based on the first mapping relationship, M paths of the M data flows from the N second network devices, sending the M paths to the N second network devices to cause the N second network devices to transmit the M data flows through the egress ports.
Zahid-236 teaches
sequentially traversing egress ports on the N second network devices based on first sorting information to obtain a first mapping relationship, wherein the first sorting information indicates sorting of quantities of the N second network devices corresponding to the K fourth network devices, and wherein the first mapping relationship indicates mapping relationships between the egress ports and the K fourth network devices (¶0044 -The mechanism traverses the fabric in the indexing order and assigns target LIDs of the end nodes,
and thus the corresponding routes to each Switch port. For the end nodes connected to the same leaf Switch, the indexing order can depend on the switch port to which the end node is connected (i.e., port numbering sequence). For each port, the mechanism can maintain a port usage counter, and can use this port usage counter to select a least-used port each time a new route is added. ¶ 0059 - (line 4 of above listing 1) – ¶0055 Listing 1 -line 4 - the mechanism can sort connected end nodes in a partitioning specific order Sort end nodes in partitioning specific order – Listing 1 – Line 8 - Set LFTlid - cn:hca port on Sw – Note: This mapping relationship create an LFT relationship between the nodes LID and its port – ¶ 0034 - l HCA ports on the end nodes and all Switches are addressed using local identifiers (LIDs). Each entry in an LFT consists of a destination LID (DLID) and an output port. ¶0061 - The pFTree mechanism can maintain a table for each switch, storing the count of routed nodes for each partition. This counter can be used to decide the selection of the port if several switches with marked partitions are available to route a node. The switch with the maximum number of already routed nodes for a partition can be selected).
determining, based on the first mapping relationship, M paths of the M data flows from the N second network devices, sending the M paths to the N second network devices to cause the N second network devices to transmit the M data flows through the egress ports ( ¶0059 - The pFTree mechanism can then call a function, such as ROUTE DOWNG, ING BY ASCENDING (line 9 of above listing 1), and move up in the tree to select a port at the next level to route the LID, as shown in the listing 2. – ¶ 0061 - In accordance with an embodiment, after the down going port is set for a LID at a Switch, the mechanism can assign upward ports for it on all the connected downward switches by descending down the tree calling (ROUTEUP GOINGBYDESCENDING of listing 3). Again, the selection of the up-going port can first be based on the load criterion and then on the partition marking of the remote Switches, in the upward direction. The process can then be repeated by moving up to the next level in the tree until all LFTs are set. ¶ 0044 - The fat-tree routing mechanism aims to generate LFTs that evenly spread shortest-path routes across the links in the network fabric. The mechanism traverses the fabric in the indexing order and assigns target LIDs of the end nodes,
and thus the corresponding routes, to each Switch port- ¶ 0025 -The SM can calculate routing tables (i.e., the connections/routes between each pair of nodes within the tree) at network initialization time ¶0029 -IB routing generally can be based on linear forwarding tables (LFTs) stored in the switches. the subnet manager exchanges control packets, which are referred to as Subnet management packets (SMPs), with Subnet management agents (SMAS). The Subnet management agents reside on every IB subnet device. By using SMPs, the subnet manager is able to discover the fabric, configure end nodes and switches, and receive notifications from SMAs - ¶0068 - the pFTree mechanism can work recursively to set up LFTs on all relevant switches for the LIDs associated with each end node. Each entry in an LFT consists of a destination LID (DLID) and an output port. Only one entry per LID in the table is supported. When a packet arrives at a switch, its output port is determined by looking up the DLID in the forwarding table of the switch. The routing is deterministic as packets take the same path in the network between a given Source-destination pair (LID pair ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Plenderleith to include the teachings of Zahid-236. The motivation for doing so is to allow the system to utilize the tree routing in order to generate LFTs that evenly spread shortest-path routes across the links in the network fabric ( Zahid-236 – ¶0044).
Regarding claim 2,
Plenderleith further teaches
wherein the M data flows comprise a first data flow and a second data flow (Col.11, lines 40-60 - The first and second source devices use the path information to encapsulate network packets that will then take the separate network paths through the computer network to the destination device – Col.9, lines 58-65 - the control system 450 can send path information to the first source device 130 and the second source device 132, as indicated at 452. The first source device 130 can use the path information (e.g., a first network path indicator) to encapsulate a flow of network packets sent to the first destination device 434. The second source device 132 can use the path information ( e.g., a second network path) indicator) to encapsulate a flow of network packets sent to the second destination device 436).
wherein first source address information of the first data flow and second source address information of the second data flow correspond to different second network devices, wherein first destination address information of the first data flow and second destination address information of the second data flow correspond to a same fourth network device ( Col.2, lines 5-15 - In some solutions, a control system receives a request to keep network flows separate from a first source device to a destination device and from a second source device to the destination device so that the network flows -- Col.6, lines 35-40 – the network path separation list can list two or more source devices by their IP addresses and a destination device by its IP address. For example, a network path separation list associated with the example network environment 200 can list: [first source device 130 IP address, second source device 132 IP address, destination device 134 IP address]. The network path separation list indicates that network traffic ( e.g., network flows) for each of the source devices should take different paths through at least a portion of the network to the destination device).
wherein the M paths comprise a first path and a second path, and wherein the first path corresponds to the first data flow, the second path corresponds to the second data flow (Fig.5&Col. 11, lines 32-50 -At 520, separate network paths are determined through the computer network for the first network flow and the second network flow, and Separate network paths are those that traverse different routers for at least a portion of the paths. For example, the paths may begin at different network locations but then converge at a specific router that directs each network flow along a different outbound path to the destination device.
the first path and the second path correspond to different third network devices ( Fig.1 shows that Path 1(first flow) is directed to Network device 114 and Path 2 (second flow) is directed to network device 120. Col.11, lines 35-50 -Separate network paths (first and second flows) are those that traverse different routers for at least a portion of the paths. For example, the paths may begin at different network locations but then converge at a specific router that directs each network flow along a different outbound path to the destination device).
Regarding claim 3,
Plenderleith further teaches
wherein the M paths further indicate the egress ports of the M data flows on the N second network devices (Col.4, lines 30-40 - network device 112 can direct the network packets of the first network flow (network packets addressed from the first source device 130) to network device 114 ( e.g., via a first network port of network device 112). The network device 112 can direct the network packets of the second network flow (network packets addressed from the second source device 132) to network device 120 ( e.g., via a second network port of network device 112- Col.5, lines 1-15 the control system 150 calculates different network path indicators ( e.g., different source port numbers) for each of the source devices).
Regarding claim 7,
Plenderleith further teaches
wherein obtaining the communication relationships comprises receiving the communication relationships from the N second network devices (Col.9, lines 10-20 - a control system receives a request to keep network flows separate from a first source device to a first destination device and from a second source device to a second destination device so that the network flows traverse separate routers and/or separate links for at least a portion of the separate network paths. – Col 8 lines 15-30 - the determination can be based on a request that is received from another computing device or service, from a network administrator, from one of the devices involved in the network flows (e.g., from one of the source devices), or from another source – Col.8, lines 55-65 - the flow description information identifies one or more specific types of network flows that are to be kept separate, which can be identified by network protocol and port number (e.g., TCP flows with destination port 80). In some implementations, the network environment 300 is part of a software defined network).
Regarding claim 10,
Plenderleith teaches method, applied to a second network device, and
comprising:
sending communication relationships of Q data flows to a first network device, wherein each of the communication relationships comprises source address information and destination address information, and wherein Q is an integer greater than or equal to 1 ( Col.2, lines 5-15 - In some solutions, a control system receives a request to keep network flows separate from a first source device to a destination device and from a second source device to the destination device so that the network flows -- Col.6, lines 35-40 – the network path separation list can list two or more source devices by their IP addresses and a destination device by its IP address. For example, a network path separation list associated with the example network environment 200 can list: [first source device 130 IP address, second source device 132 IP address, destination device 134 IP address]. The network path separation list indicates that network traffic ( e.g., network flows) for each of the source devices should take different paths through at least a portion of the network to the destination device);
receiving, from the first network device, Q paths of the Q data flows and transmitting the Q data flows based on the Q paths(Fig.5, Col.11, lines 43-55 - At 530, path information is sent to the first source device and the second source device. The first and second source 45 devices use the path information to encapsulate network packets that will then take the separate network paths through the computer network to the destination device).
However, Plenderleith does not explicitly teach
wherein the Q paths are based on a mapping relationship obtained by sequentially traversing egress ports on N second network devices based on first sorting information, wherein the first sorting information indicates sorting of Quantities of the N second network devices corresponding to K fourth network devices, wherein N is an integer greater than or equal to 2, and wherein k is an integer greater than 1,
Zahid-236 teaches
wherein the Q paths are based on a mapping relationship obtained by sequentially traversing egress ports on N second network devices based on first sorting information, wherein the first sorting information indicates sorting of Quantities of the N second network devices corresponding to K fourth network devices, wherein N is an integer greater than or equal to 2, and wherein k is an integer greater than 1 (¶0044 -The mechanism traverses the fabric in the indexing order and assigns target LIDs of the end nodes, and thus the corresponding routes to each Switch port. For the end nodes connected to the same leaf Switch, the indexing order can depend on the switch port to which the end node is connected (i.e., port numbering sequence). For each port, the mechanism can maintain a port usage counter, and can use this port usage counter to select a least-used port each time a new route is added. ¶0059 - (line 4 of above listing 1) – ¶ 0055 Listing 1 -line 4 - the mechanism can sort connected end nodes in a partitioning specific order Sort end nodes in partitioning specific order – Listing 1 – Line 8 - Set LFTlid - cn:hca port on Sw – Note: This mapping relationship create an LFT relationship between the nodes LID and its port – ¶0034 - l HCA ports on the end nodes and all Switches are addressed using local identifiers (LIDs). Each entry in an LFT consists of a destination LID (DLID) and an output port. ¶ 0061 - The pFTree mechanism can maintain a table for each switch, storing the count of routed nodes for each partition. This counter can be used to decide the selection of the port if several switches with marked partitions are available to route a node. The switch with the maximum number of already routed nodes for a partition can be selected. ¶0068 - the pFTree mechanism can work recursively to set up LFTs on all relevant switches for the LIDs associated with each end node. Each entry in an LFT consists of a destination LID (DLID) and an output port. Only one entry per LID in the table is supported. When a packet arrives at a switch, its output port is determined by looking up the DLID in the forwarding table of the switch. The routing is deterministic as packets take the same path in the network between a given Source-destination pair (LID pair – See Also ¶ 0025, ¶ 0029 and ¶ 0059).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Plenderleith to include the teachings of Zahid-236. The motivation for doing so is to allow the system to utilize the tree routing in order to generate LFTs that evenly spread shortest-path routes across the links in the network fabric ( Zahid-236 – ¶ 0044).
Regarding claim 11,
Plenderleith further teaches
wherein each of the communication relationships further comprises path information further indicating egress ports of the Q data flows on the second network device(Col.4, lines 30-40 - network device 112 can direct the network packets of the first network flow (network packets addressed from the first source device 130) to network device 114 ( e.g., via a first network port of network device 112). The network device 112 can direct the network packets of the second network flow (network packets addressed from the second source device 132) to network device 120 ( e.g., via a second network port of network device 112- Col.5, lines 1-15 the control system 150 calculates different network path indicators ( e.g., different source port numbers) for each of the source devices).
Regarding claim 13,
Plenderleith teaches a first network device comprising:
a memory configured to store program instructions and at least one processor coupled to the memory and configured to obtain first topology information comprising connection relationships between N second network device and P third network devices, wherein the N second network devices are upstream of the P third network devices, wherein N is an integer greater than or equal to 2, and wherein P is an integer greater than or equal to l (Col.2, lines 10-20 -The control system determines separate network paths using network topology information – Col.3, lines 20-30 -FIG. 1 is a diagram of an example network environment 100 in which separate network paths are determined and path information is sent to source devices for use in encapsulating network packets. In the example network environment 100, a simplified network area 110 is depicted that includes a number of network devices (e.g., routers, switches, or other types of network devices), including network devices 112, 114, 116, 118, 120, and 122. Fig.1 shows a topology with a first source device (130) and a second source device (132) upstream devices of a destination device (134).
obtain communication relationships of M data flows from the N second network devices to k fourth network devices through the P third network devices, wherein each of the communication relationships comprises source address information and destination address information, and wherein K is an integer greater than or equal to 1, wherein M is an integer greater than or equal to 2 ( Col.2, lines 5-15 - In some solutions, a control system receives a request to keep network flows separate from a first source device to a destination device and from a second source device to the destination device so that the network flows 0 Col.6, lines 35-40 – the network path separation list can list two or more source devices by their IP addresses and a destination device by its IP address. For example, a network path separation list associated with the example network environment 200 can list: [first source device 130 IP address, second source device 132 IP address, destination device 134 IP address]. The network path separation list indicates that network traffic ( e.g., network flows) for each of the source devices should take different paths through at least a portion of the network to the destination device).
determine M paths of the M data flows are from the N second network devices to the P third network devices (Fig. 5 Col.11,lines 30-50 - At 520, separate network paths are determined through the computer network for the first network flow and the second network flow.. the separate network paths are determined based on topology of the computer network and/or hashing information for the computer network); and
send the M paths to the N second network devices (Fig.5, Col.11, lines 43-55 - At 530, path information is sent to the first source device and the second source device. The first and second source 45 devices use the path information to encapsulate network packets that will then take the separate network paths through the computer network to the destination device).
However, Plenderleith does not explicitly teach
sequentially traversing egress ports on the N second network devices based on first sorting information to obtain a first mapping relationship, wherein the first sorting information indicates sorting of quantities of the N second network devices corresponding to the K fourth network devices, and wherein the first mapping relationship indicates mapping relationships between the egress ports and the K fourth network devices;
determining, based on the first mapping relationship, M paths of the M data flows from the N second network devices, sending the M paths to the N second network devices to cause the N second network devices to transmit the M data flows through the egress ports.
Zahid-236 teaches
sequentially traversing egress ports on the N second network devices based on first sorting information to obtain a first mapping relationship, wherein the first sorting information indicates sorting of quantities of the N second network devices corresponding to the K fourth network devices, and wherein the first mapping relationship indicates mapping relationships between the egress ports and the K fourth network devices (¶0044 -The mechanism traverses the fabric in the indexing order and assigns target LIDs of the end nodes,
and thus the corresponding routes to each Switch port. For the end nodes connected to the same leaf Switch, the indexing order can depend on the switch port to which the end node is connected (i.e., port numbering sequence). For each port, the mechanism can maintain a port usage counter, and can use this port usage counter to select a least-used port each time a new route is added. ¶ 0059 - (line 4 of above listing 1) – ¶0055 Listing 1 -line 4 - the mechanism can sort connected end nodes in a partitioning specific order Sort end nodes in partitioning specific order – Listing 1 – Line 8 - Set LFTlid - cn:hca port on Sw – Note: This mapping relationship create an LFT relationship between the nodes LID and its port – Para 0034 - l HCA ports on the end nodes and all Switches are addressed using local identifiers (LIDs). Each entry in an LFT consists of a destination LID (DLID) and an output port. ¶0061 - The pFTree mechanism can maintain a table for each switch, storing the count of routed nodes for each partition. This counter can be used to decide the selection of the port if several switches with marked partitions are available to route a node. The switch with the maximum number of already routed nodes for a partition can be selected. ).
determining, based on the first mapping relationship, M paths of the M data flows from the N second network devices, sending the M paths to the N second network devices to cause the N second network devices to transmit the M data flows through the egress ports ( ¶059 - The pFTree mechanism can then call a function, such as ROUTE DOWNG, ING BY ASCENDING (line 9 of above listing 1), and move up in the tree to select a port at the next level to route the LID, as shown in the listing 2. – ¶ 0061 - In accordance with an embodiment, after the down going port is set for a LID at a Switch, the mechanism can assign upward ports for it on all the connected downward switches by descending down the tree calling (ROUTEUP GOINGBYDESCENDING of listing 3). Again, the selection of the up-going port can first be based on the load criterion and then on the partition marking of the remote Switches, in the upward direction. The process can then be repeated by moving up to the next level in the tree until all LFTs are set. ¶ 0044 - The fat-tree routing mechanism aims to generate LFTs that evenly spread shortest-path routes across the links in the network fabric. The mechanism traverses the fabric in the indexing order and assigns target LIDs of the end nodes,
and thus the corresponding routes, to each Switch port- ¶ 0025 -The SM can calculate routing tables (i.e., the connections/routes between each pair of nodes within the tree) at network initialization time ¶ 0029 -IB routing generally can be based on linear forwarding tables (LFTs) stored in the switches. the subnet manager exchanges control packets, which are referred to as Subnet management packets (SMPs), with Subnet management agents (SMAS). The Subnet management agents reside on every IB subnet device. By using SMPs, the subnet manager is able to discover the fabric, configure end nodes and switches, and receive notifications from SMAs - ¶0068 - the pFTree mechanism can work recursively to set up LFTs on all relevant switches for the LIDs associated with each end node. Each entry in an LFT consists of a destination LID (DLID) and an output port. Only one entry per LID in the table is supported. When a packet arrives at a switch, its output port is determined by looking up the DLID in the forwarding table of the switch. The routing is deterministic as packets take the same path in the network between a given Source-destination pair (LID pair ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Plenderleith to include the teachings of Zahid-236. The motivation for doing so is to allow the system to utilize the tree routing in order to generate LFTs that evenly spread shortest-path routes across the links in the network fabric ( Zahid-236 – ¶0044).
Regarding claim 14,
Plenderleith further teaches
wherein the M data flows comprise a first data flow and a second data flow (Col.11, lines 40-60 - The first and second source devices use the path information to encapsulate network packets that will then take the separate network paths through the computer network to the destination device – Col.9, lines 58-65 - the control system 450 can send path information to the first source device 130 and the second source device 132, as indicated at 452. The first source device 130 can use the path information (e.g., a first network path indicator) to encapsulate a flow of network packets sent to the first destination device 434. The second source device 132 can use the path information ( e.g., a second network path) indicator) to encapsulate a flow of network packets sent to the second destination device 436).
wherein first source address information of the first data flow and second source address information of the second data flow correspond to different second network devices, wherein first destination address information of the first data flow and second destination address information of the second data flow correspond to a same fourth network device ( Col.2, lines 5-15 - In some solutions, a control system receives a request to keep network flows separate from a first source device to a destination device and from a second source device to the destination device so that the network flows -- Col.6, lines 35-40 – the network path separation list can list two or more source devices by their IP addresses and a destination device by its IP address. For example, a network path separation list associated with the example network environment 200 can list: [first source device 130 IP address, second source device 132 IP address, destination device 134 IP address]. The network path separation list indicates that network traffic ( e.g., network flows) for each of the source devices should take different paths through at least a portion of the network to the destination device).
wherein the M paths comprise a first path and a second path, and wherein the first path corresponds to the first data flow, the second path corresponds to the second data flow (Fig.5, Col. 11, lines 32-50 -At 520, separate network paths are determined through the computer network for the first network flow and the second network flow, and Separate network paths are those that traverse different routers for at least a portion of the paths. For example, the paths may begin at different network locations but then converge at a specific router that directs each network flow along a different outbound path to the destination device.
the first path and the second path correspond to different third network devices ( Fig.1 shows that Path 1(first flow) is directed to Network device 114 and Path 2 (second flow) is directed to network device 120. Col.11, lines 35-50 -Separate network paths (first and second flows) are those that traverse different routers for at least a portion of the paths. For example, the paths may begin at different network locations but then converge at a specific router that directs each network flow along a different outbound path to the destination device).
Regarding claim 15,
Plenderleith further teaches
wherein the M paths further indicate egress ports of the M data flows on the N second network devices (Col.4, lines 30-40 - network device 112 can direct the network packets of the first network flow (network packets addressed from the first source device 130) to network device 114 ( e.g., via a first network port of network device 112). The network device 112 can direct the network packets of the second network flow (network packets addressed from the second source device 132) to network device 120 ( e.g., via a second network port of network device 112- Col.5, lines 1-15 the control system 150 calculates different network path indicators ( e.g., different source port numbers) for each of the source devices-)
Regarding claim 19,
Plenderleith further teaches
Wherein the at least one processor is further configured to execute the program instructions to cause the first network device to receive the communication relationships from the N second network devices (Col.9, lines 10-20 - a control system receives a request to keep network flows separate from a first source device to a first destination device and from a second source device to a second destination device so that the network flows traverse separate routers and/or separate links for at least a portion of the separate network paths. – Col 8 lines 15-30 - the determination can be based on a request that is received from another computing device or service, from a network administrator, from one of the devices involved in the network flows (e.g., from one of the source devices), or from another source – Col.8, lines 55-65 - the flow description information identifies one or more specific types of network flows that are to be kept separate, which can be identified by network protocol and port number (e.g., TCP flows with destination port 80). In some implementations, the network environment 300 is part of a software defined network).
Regarding claim 21,
Plenderleith further teaches
wherein the first network device is a controller or one of the P third network devices (Col.4, lines 1-10 - control system 150 is also present in the example
network environment 150. The control system 150 can be implemented by software and/or hardware resources running on one or more computing devices (e.g., as a centralized service, a distributed service, or multiple instances of a service). As depicted at 155, the control system 150 performs operations for determining separate network paths and sending path information to source devices).
Regarding claim 22,
Plenderleith teaches a second network device
comprising:
a memory configured to store program instructions; at least one processor coupled to the memory and configured to execute the program instructions : to cause the second network device (Fig.1, Col. 3, lines 40-50- source device) to
determine communication relationships of Q data flows , wherein each of the communication relationships comprises source address information and destination address information , and wherein Q is integer greater than or equal to 1 ( Col.7, lines 30-50 - a first network packet of a communication from a source device to a destination device (e.g., the first network packet at the beginning of a network flow from first source device 130 to destination device 134) can be a special network packet ( e.g., identified by network packet header parameters as containing a network path separation list). The special network packet can be identified by the network devices (e.g., by network device 212 and/or by other network devices within the network area 110) and the network path separation list can be extracted and stored for use in determining when separate network paths should be used -Col.6, lines 35-40 – the network path separation list can list two or more source devices by their IP addresses and a destination device by its IP address. For example, a network path separation list associated with the example network environment 200 can list: [first source device 130 IP address, second source device 132 IP address, destination device 134 IP address]. The network path separation list indicates that network traffic ( e.g., network flows) for each of the source devices should take different paths through at least a portion of the network to the destination device) and
a transceiver coupled to the at least one processor and configured to send communication relationships of Q data flows to a first network device, ( Col.2, lines 5-15 - In some solutions, a control system receives a request to keep network flows separate from a first source device to a destination device and from a second source device to the destination device so that the network flows).
receive Q paths from the first network device , wherein the Q paths indicate paths used when the second network device transmits the Q data flows and transmit the Q data flow based on the Q path (Fig.5, Col.11, lines 43-55 - At 530, path information is sent to the first source device and the second source device. The first and second source 45 devices use the path information to encapsulate network packets that will then take the separate network paths through the computer network to the destination device - Col. 9, lines 20-60 – The control system sends path information to the source devices for use in encapsulating network packets to use the separate network paths. In some solutions, a network path separation - the control system 450 can send path information to the first source device 130 and the second source device 132, as indicated at 452. The first source device 130 can use the path information (e.g., a first network path indicator) to encapsulate a flow of network packets sent to the first destination device 434);
However, Plenderleith does not explicitly teach
wherein the Q paths are based on a mapping relationship obtained by sequentially traversing egress ports on N second network devices based on first sorting information, wherein the first sorting information indicates sorting of Quantities of the N second network devices corresponding to K fourth network devices, wherein N is an integer greater than or equal to 2, and wherein k is an integer greater than 1,
Zahid-236 teaches
wherein the Q paths are based on a mapping relationship obtained by sequentially traversing egress ports on N second network devices based on first sorting information, wherein the first sorting information indicates sorting of Quantities of the N second network devices corresponding to K fourth network devices, wherein N is an integer greater than or equal to 2, and wherein k is an integer greater than 1(¶0044 -The mechanism traverses the fabric in the indexing order and assigns target LIDs of the end nodes, and thus the corresponding routes to each Switch port. For the end nodes connected to the same leaf Switch, the indexing order can depend on the switch port to which the end node is connected (i.e., port numbering sequence). For each port, the mechanism can maintain a port usage counter, and can use this port usage counter to select a least-used port each time a new route is added. ¶0059 - (line 4 of above listing 1) –¶0055 Listing 1 -line 4 - the mechanism can sort connected end nodes in a partitioning specific order Sort end nodes in partitioning specific order – Listing 1 – Line 8 - Set LFTlid - cn:hca port on Sw – Note: This mapping relationship create an LFT relationship between the nodes LID and its port – ¶ 0034 - l HCA ports on the end nodes and all Switches are addressed using local identifiers (LIDs). Each entry in an LFT consists of a destination LID (DLID) and an output port. ¶0061 - The pFTree mechanism can maintain a table for each switch, storing the count of routed nodes for each partition. This counter can be used to decide the selection of the port if several switches with marked partitions are available to route a node. The switch with the maximum number of already routed nodes for a partition can be selected. ¶ 0068 - the pFTree mechanism can work recursively to set up LFTs on all relevant switches for the LIDs associated with each end node. Each entry in an LFT consists of a destination LID (DLID) and an output port. Only one entry per LID in the table is supported. When a packet arrives at a switch, its output port is determined by looking up the DLID in the forwarding table of the switch. The routing is deterministic as packets take the same path in the network between a given Source-destination pair (LID pair – See Also ¶0025, ¶ 0029 and ¶0059).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Plenderleith to include the teachings of Zahid-236. The motivation for doing so is to allow the system to utilize the tree routing in order to generate LFTs that evenly spread shortest-path routes across the links in the network fabric ( Zahid-236 – ¶0044).
Regarding claim 23,
Plenderleith further teaches
wherein each of the communication relationships further comprises path information indicating egress ports of the Q data flows on the second network device(Col.4, lines 30-40 - network device 112 can direct the network packets of the first network flow (network packets addressed from the first source device 130) to network device 114 ( e.g., via a first network port of network device 112). The network device 112 can direct the network packets of the second network flow (network packets addressed from the second source device 132) to network device 120 ( e.g., via a second network port of network device 112- Col.5, lines 1-15 the control system 150 calculates different network path indicators ( e.g., different source port numbers) for each of the source devices).
Regarding claim 25,
Plenderleith further teaches
wherein the M data flows comprise a third data flow and a fourth data flow, wherein third source address information of the third data flow and fourth source address information of the fourth data flow correspond to a same second network device, (Col.8, lines 30-60- the flow description information can indicate which network flows are to be kept separate ( e.g., indicating that network flows from the first source device 130 to the destination device 134 are to be kept separate from network flows from the second source device 132 to the destination device 134). The control system 350 can send the flow description information to a group of network devices (e.g., to some or all of the network devices within the network area 110). The network devices can use the flow description information for flow-based routing to switch between separate network paths for different flows according to the flow description information - the flow description information identifies one or more specific types of network flows that are to be kept separate, which can be identified by network protocol and port number (e.g., TCP flows with destination port 80).).
and wherein the M paths comprise: a third path corresponding to the third data flow; and a fourth path corresponding to the fourth data flow, wherein the fourth path is different from the third path (Col.8, lines 55-70 – The network devices can use the flow description information for flow-based routing to switch between separate network paths for different flows according to the flow description information. For example network device 112 can receive a first network flow from the first source device 130 to the first destination device 434 and send it along a first network path (e.g., via a first network port) to network device 114. The network device 112 can receive a second network flow from the second source device 132 to the second destination device 436 and send it along a second network path ( e.g., via a second network port) to network device 120).
Claims 4, 16 are rejected under 35 U.S.C. 103 as being unpatentable over Plenderleith in view of Zahid-236 further in view of Dimitropoulos et al. Publication No. US 2010/0214947 A1 ( Dimitropoulos hereinafter)
Regarding claim 4,
Plenderleith does not explicitly teach
Wherein a first sorting information is based on a second mapping relationship , wherein the second mapping relationship is based on the communication relationships and the first topology information, wherein the second mapping relationship is between a second network device corresponding to the source address information of each of the M data flows and a fourth network device corresponding to the destination address information of each of the M data flows
However, Dimitropoulos teaches
Wherein a first sorting information is based on a second mapping relationship , wherein the second mapping relationship is based on the communication relationships and the first topology information, wherein the second mapping relationship is between a second network device corresponding to the source address information of each of the M data flows and a fourth network device corresponding to the destination address information of each of the M data flows (¶0021 - root node is introduced representing destination d. In block 302, the list of device sets for destination d is sorted by length, i.e., by the number of devices contained in each device set. – ¶0017 - The Source-destination pairs observed at a network device, including but not limited to routers, Switches, or other types of network nodes, may be analyzed against hypothetical topologies and routing paths between various network devices. ¶ 0018 - a network topology that may be discovered using flow-based traffic information. The topology is not known in advance. The path between a source and a destination via a sequence of routers may be denoted by p. For each source-destination pair, {R} denotes the set of network devices, which may include routers, Switches, or any other type of network node, at which a particular source-destination pair is observed. {R} is the device set of path p. The following traffic flow records are obtained from the network topology of FIG. 1 by a traffic measurement utility: S->d is observed at router r; S->d is observed at router r; and S->d is observed at router r. Therefore, destination di has two distinct source destination pairs: S->d and S->d. Device set {r, r. corresponds to S->d, and device set {r} corresponds to S->d. Device set {r, r. corresponds to S->d, and ¶ 0020 - the topological information is included in the individual trees).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Plenderleith to include the teachings of Dimitropoulos. The motivation for doing so is to allow the system to determine a network topology from a set of traffic records (Dimitropoulos – ¶ 0005).
Regarding claim 16,
Plenderleith does not explicitly teach
Wherein the first sorting information is based on a second mapping relationship , wherein the second mapping relationship is based on the communication relationships and the first topology information, wherein the second mapping relationship is between a second network device corresponding to the source address information of each of the M data flows and a fourth network device corresponding to the destination address information of each of the M data flows
However, Dimitropoulos teaches
wherein the first sorting information is based on a second mapping relationship , wherein the second mapping relationship is based on the communication relationships and the first topology information, wherein the second mapping relationship is between a second network device corresponding to the source address information of each of the M data flows and a fourth network device corresponding to the destination address information of each of the M data flows (¶0021 - root node is introduced representing destination d. In block 302, the list of device sets for destination d is sorted by length, i.e., by the number of devices contained in each device set. – ¶0017 - The Source-destination pairs observed at a network device, including but not limited to routers, Switches, or other types of network nodes, may be analyzed against hypothetical topologies and routing paths between various network devices. ¶ 0018 - a network topology that may be discovered using flow-based traffic information. The topology is not known in advance. The path between a source and a destination via a sequence of routers may be denoted by p. For each source-destination pair, {R} denotes the set of network devices, which may include routers, Switches, or any other type of network node, at which a particular source-destination pair is observed. {R} is the device set of path p. The following traffic flow records are obtained from the network topology of FIG. 1 by a traffic measurement utility: S->d is observed at router r; S->d is observed at router r; and S->d is observed at router r. Therefore, destination di has two distinct source destination pairs: S->d and S->d. Device set {r, r. corresponds to S->d, and device set {r} corresponds to S->d. Device set {r, r. corresponds to S->d, and ¶ 0020 - the topological information is included in the individual trees).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Plenderleith to include the teachings of Dimitropoulos. The motivation for doing so is to allow the system to determine a network topology from a set of traffic records (Dimitropoulos – ¶ 0005).
Claims 6, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Plenderleith in view of Zahid-236 further in view of Yeh et al. Publication No. US 2021/0006495 A1 ( Yeh hereinafter)
Regarding claim 6,
Plenderleith in view of Zahid-236 teaches
wherein sequentially traversing the egress ports based on the first sorting information: sequentially traversing the egress ports based on the first sorting information to obtain a third mapping relationship (Zahid-236 - ¶0044 -The mechanism traverses the fabric in the indexing order and assigns target LIDs of the end nodes, and thus the corresponding routes to each Switch port. For the end nodes connected to the same leaf Switch, the indexing order can depend on the switch port to which the end node is connected (i.e., port numbering sequence). For each port, the mechanism can maintain a port usage counter, and can use this port usage counter to select a least-used port each time a new route is added. ¶0059 - (line 4 of above listing 1) –¶0055 Listing 1 -line 4 - the mechanism can sort connected end nodes in a partitioning specific order Sort end nodes in partitioning specific order – Listing 1 – Line 8 - Set LFTlid - cn:hca port on Sw – Note: This mapping relationship create an LFT relationship between the nodes LID and its port – ¶ 0034 - l HCA ports on the end nodes and all Switches are addressed using local identifiers (LIDs). Each entry in an LFT consists of a destination LID (DLID) and an output port. ¶0061 - The pFTree mechanism can maintain a table for each switch, storing the count of routed nodes for each partition. This counter can be used to decide the selection of the port if several switches with marked partitions are available to route a node. The switch with the maximum number of already routed nodes for a partition can be selected. ¶ 0068 - the pFTree mechanism can work recursively to set up LFTs on all relevant switches for the LIDs associated with each end node. Each entry in an LFT consists of a destination LID (DLID) and an output port. Only one entry per LID in the table is supported. When a packet arrives at a switch, its output port is determined by looking up the DLID in the forwarding table of the switch. The routing is deterministic as packets take the same path in the network between a given Source-destination pair (LID pair – See Also ¶0025, ¶ 0029 and ¶0059 – Note: same motivation as claim 1).
However, Plenderleith in view of Zahid-236 does not explicitly teach
wherein the third mapping relationship indicates an optional quantity of the egress ports corresponding to each of the K fourth network devices; and determining the second mapping relationship based on the third mapping relationship .
Yeh teaches
wherein the third mapping relationship indicates an optional quantity of the egress ports corresponding to each of the K fourth network devices; and determining the second mapping relationship based on the third mapping relationship (¶0015 - The identified set of ports may include all of those ports on the destination network node which may serve as egress ports from which the packet may be output in order to reach its local destination node, which ultimately leads to the global destination network node – the eligible ports are returned in the form of a bitmap - - the EPPB is in the form of a vector, made up of the number of bits as there are ports on the destination network node. An eligible port may be denoted by a "1" and an ineligible port may be denoted with a "0". Claim 7 - an output of the first routing lookup identifies a set of eligible ports, which are a set of physical ports on the ingress internal node which are able to serve as egress ports from which the packet may be output in order to reach the local destination node Claim 10- mapping the destination node address to a smaller index; the routing step further includes performing a second routing lookup in a fabric lookup routing table, wherein: an input of the second routing lookup is the smaller index; and an output from the second routing lookup identifies a set of eligible ports, which are a set of physical ports on the ingress internal node which are able to serve as egress ports from which the packet may be output in order to reach the local destination node – Claim 12 - wherein: the routing step further includes a step of identifying, from the set of eligible ports, a subset of eligible physical ports which are available for use, based on a status of the set of eligible ports).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Plenderleith in view of Zahid-236 to include the teachings of Yeh. The motivation for doing so is to allow the system to identify, from the set of eligible physical ports, the subset of physical ports which are available for use (Yeh – ¶0019).
Regarding claim 18,
Plenderleith in view of Zahid-236 teaches
sequentially traversing the egress ports based on the first sorting information to obtain a third mapping relationship (Zahid-236 - ¶0044 -The mechanism traverses the fabric in the indexing order and assigns target LIDs of the end nodes, and thus the corresponding routes to each Switch port. For the end nodes connected to the same leaf Switch, the indexing order can depend on the switch port to which the end node is connected (i.e., port numbering sequence). For each port, the mechanism can maintain a port usage counter, and can use this port usage counter to select a least-used port each time a new route is added. ¶0059 - (line 4 of above listing 1) –¶0055 Listing 1 -line 4 - the mechanism can sort connected end nodes in a partitioning specific order Sort end nodes in partitioning specific order – Listing 1 – Line 8 - Set LFTlid - cn:hca port on Sw – Note: This mapping relationship create an LFT relationship between the nodes LID and its port – ¶ 0034 - l HCA ports on the end nodes and all Switches are addressed using local identifiers (LIDs). Each entry in an LFT consists of a destination LID (DLID) and an output port. ¶0061 - The pFTree mechanism can maintain a table for each switch, storing the count of routed nodes for each partition. This counter can be used to decide the selection of the port if several switches with marked partitions are available to route a node. The switch with the maximum number of already routed nodes for a partition can be selected. ¶ 0068 - the pFTree mechanism can work recursively to set up LFTs on all relevant switches for the LIDs associated with each end node. Each entry in an LFT consists of a destination LID (DLID) and an output port. Only one entry per LID in the table is supported. When a packet arrives at a switch, its output port is determined by looking up the DLID in the forwarding table of the switch. The routing is deterministic as packets take the same path in the network between a given Source-destination pair (LID pair – See Also ¶0025, ¶ 0029 and ¶0059 – Note: same motivation as claim 13).
However, Plenderleith in view of Zahid-236 does not explicitly teach
wherein the third mapping relationship indicates an optional quantity of the egress ports corresponding to each of the K fourth network devices; and determining the second mapping relationship based on the third mapping relationship
Yeh teaches
wherein the third mapping relationship indicates an optional quantity of the egress ports corresponding to each of the K fourth network devices; and determining the second mapping relationship based on the third mapping relationship (¶0015 - The identified set of ports may include all of those ports on the destination network node which may serve as egress ports from which the packet may be output in order to reach its local destination node, which ultimately leads to the global destination network node – the eligible ports are returned in the form of a bitmap - the EPPB is in the form of a vector, made up of the number of bits as there are ports on the destination network node. An eligible port may be denoted by a "1" and an ineligible port may be denoted with a "0". Claim 7 - an output of the first routing lookup identifies a set of eligible ports, which are a set of physical ports on the ingress internal node which are able to serve as egress ports from which the packet may be output in order to reach the local destination node Claim 10- mapping the destination node address to a smaller index; the routing step further includes performing a second routing lookup in a fabric lookup routing table, wherein: an input of the second routing lookup is the smaller index; and an output from the second routing lookup identifies a set of eligible ports, which are a set of physical ports on the ingress internal node which are able to serve as egress ports from which the packet may be output in order to reach the local destination node – Claim 12 - wherein: the routing step further includes a step of identifying, from the set of eligible ports, a subset of eligible physical ports which are available for use, based on a status of the set of eligible ports).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Plenderleith in view of Zahid-236 to include the teachings of Yeh. The motivation for doing so is to allow the system to identify, from the set of eligible physical ports, the subset of physical ports which are available for use (Yeh – ¶0019).
Claims 8,12,20,24 are rejected under 35 U.S.C. 103 as being unpatentable over Plenderleith in view of Zahid-236 further in view of Higgins et al. Publication No. US 2021/0029064 A1 ( Higgins hereinafter) .
Regarding claim 8,
Plenderleith teaches the M data flows ( Col.11, lines 40-60). However Plenderleith does not explicitly teach that the data flows correspond to one of a plurality of artificial intelligence (Al) set communication tasks
Higgins teaches
data flows correspond to one of a plurality of artificial intelligence (Al) set communication tasks (¶0028 - communication management platform 102 may provide a user interface with which to receive artificial intelligence scripting language code and may generate conversational flows , message templates, scheduling parameters, and/or the like for the mass communication task – ¶ 0064 - Modules 280 may include a message structure/content AI module 280-1 that analyzes a message structure and/or content using artificial intelligence (AI) techniques to determine information regarding a message in a message channel. Modules 280 may include a dynamic automated message/content construction module 280-2 that dynamically generates message content using machine learning techniques to enable messaging with a user).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Plenderleith to include the teachings of Higgins. The motivation for doing so is to allow the system to provide real-time traffic optimization, and proactive, self-healing network management.
Regarding claim 12,
Plenderleith teaches one or more data flows of the Q data flows ( Col.11, lines 40-60). However Plenderleith does not explicitly teach that the one or more data flows correspond to one of a plurality of artificial intelligence (Al) set communication tasks
Higgins teaches
one or more data flows correspond to one of a plurality of artificial intelligence (Al) set communication tasks (¶ 0028 - communication management platform 102 may provide a user interface with which to receive artificial intelligence scripting language code and may generate conversational flows , message templates, scheduling parameters, and/or the like for the mass communication task – ¶0064 - Modules 280 may include a message structure/content AI module 280-1 that analyzes a message structure and/or content using artificial intelligence (AI) techniques to determine information regarding a message in a message channel. Modules 280 may include a dynamic automated message/content construction module 280-2 that dynamically generates message content using machine learning techniques to enable messaging with a user).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Plenderleith to include the teachings of Higgins. The motivation for doing so is to allow the system to provide real-time traffic optimization, and proactive, self-healing network management.
Regarding claim 20,
Plenderleith teaches the M data flows ( Col.11, lines 40-60). However Plenderleith does not explicitly teach that the data flows correspond to one of a plurality of artificial intelligence (Al) set communication tasks
Higgins teaches
data flows correspond to one of a plurality of artificial intelligence (Al) set communication tasks (¶ 0028 - communication management platform 102 may provide a user interface with which to receive artificial intelligence scripting language code and may generate conversational flows , message templates, scheduling parameters, and/or the like for the mass communication task – ¶ 0064 - Modules 280 may include a message structure/content AI module 280-1 that analyzes a message structure and/or content using artificial intelligence (AI) techniques to determine information regarding a message in a message channel. Modules 280 may include a dynamic automated message/content construction module 280-2 that dynamically generates message content using machine learning techniques to enable messaging with a user).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Plenderleith to include the teachings of Higgins. The motivation for doing so is to allow the system to provide real-time traffic optimization, and proactive, self-healing network management.
Regarding claim 24,
Plenderleith teaches the one or more data flow of the Q data flows ( Col.11, lines 40-60). However Plenderleith does not explicitly teach that the one or more data flows correspond to one of a plurality of artificial intelligence (Al) set communication tasks
Higgins teaches
One or more data flows correspond to one of a plurality of artificial intelligence (Al) set communication tasks (¶0028 - communication management platform 102 may provide a user interface with which to receive artificial intelligence scripting language code and may generate conversational flows , message templates, scheduling parameters, and/or the like for the mass communication task – ¶ 0064 - Modules 280 may include a message structure/content AI module 280-1 that analyzes a message structure and/or content using artificial intelligence (AI) techniques to determine information regarding a message in a message channel. Modules 280 may include a dynamic automated message/content construction module 280-2 that dynamically generates message content using machine learning techniques to enable messaging with a user).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Plenderleith to include the teachings of Higgins. The motivation for doing so is to allow the system to provide real-time traffic optimization, and proactive, self-healing network management.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Zahavi et al. “Fat -Trees Routing and Node ordering Providing Contention Tree Traffic for MPI Global Collectives” - 2011
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 YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Oscar A Louie can be reached at (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445
