Prosecution Insights
Last updated: July 17, 2026
Application No. 18/238,369

NETWORK-ON-CHIP ARCHITECTURE WITH DESTINATION VIRTUALIZATION

Non-Final OA §103
Filed
Aug 25, 2023
Examiner
BOKHARI, SYED M
Art Unit
2473
Tech Center
2400 — Computer Networks
Assignee
Amd
OA Round
3 (Non-Final)
83%
Grant Probability
Favorable
3-4
OA Rounds
1m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 83% — above average
83%
Career Allowance Rate
704 granted / 852 resolved
+24.6% vs TC avg
Strong +18% interview lift
Without
With
+18.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 0m
Avg Prosecution
20 currently pending
Career history
876
Total Applications
across all art units

Statute-Specific Performance

§101
0.5%
-39.5% vs TC avg
§103
94.0%
+54.0% vs TC avg
§102
1.0%
-39.0% vs TC avg
§112
0.7%
-39.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 852 resolved cases

Office Action

§103
DETAILED ACTION The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, anycorrection of the statutory basis for the rejection will not be considered a new ground ofrejection if the prior art relied upon, and the rationale supporting the rejection, would bethe same under either status. Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/27/2026 has been entered. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or no obviousness. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claim(s) 1 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kasibhatla et al. (US 12,506,696 B2) in view of Yoshida et al. (US 2013/0028083 A1). Regarding claim 1, Kasibhatla et al. teach an integrated circuit (IC), comprising: an initiator comprising circuitry (Figs. 1, [col 2 ln 15-24], FPGA (or other programmable integrated circuit) may include an internal network on chip (NoC) comprising NoC rows and NoC columns; clusters coupled to the NoC, each cluster comprising a network access point (NAP) and programmable logic; or any suitable combination thereof), Kasibhatla et al. teach and a network on chip (NoC) configured to receive data from the initiator to be transmitted to a first target (Figs. 1, [col 4 ln 11-18, col ln 28-31], the architecture of an FPGA 102 with on-chip networking capabilities, according to some example embodiments. The FPGA 102 includes an external NoC 104 and an internal NoC 120, which provide high-throughput and easy-to-use access between peripherals and the FPGA core 122. The FPGA core 122 is surrounded by the external NoC 104 and includes the clusters 118, which are units of programmable logic configurable by the user. The initiator NAP 106 or the responder NAP 108 generates raw data flits, which are received by another NAP. The transfer happens through the routers of the iNoC 120), Kasibhatla et al. teach the NoC comprising: an ingress logic block configured to assign a first virtual destination ID to the data, wherein the first virtual destination ID corresponds to a first decoder switch in the NoC (Figs. 1 and 6, [col 2 ln 64-67, col 3 ln 1, col 10 ln 64-67, col 11 ln 1-4], each packet may be assigned a virtual channel by the sending router. Each router may have data storage for one or more flits on each virtual channel. When a head flit of a packet arrives at an output port of a router, the output port assigns a virtual channel to the packet. Arbiter 602 determines a virtual channel for the received flit and stores the data in a corresponding one of the FIFOs 604A-604N (for N+1 virtual channels). Data from each of the FIFOs 604A-604N is fed into a corresponding one of the stage one switches 606A-606N (decoder switch) . Based on the destination identifier of the flit, the route computation unit 610 determines whether the flit is routed to the stage two switch 608A or the stage two switch 608B), Kasibhatla et al. teach and wherein the NoC comprises a plurality of decoder switches, each decoder switch of the plurality of decoder switches corresponding to a different virtual destination ID (Figs. 1 and 6, [col 10 ln 43-47, col 10 ln 64-67, col 11 ln 1-4], the switched input block component 600 comprises an arbiter 602, FIFOs 604A-604N, stage one switches 606A-606N (decoder switches). FIFOs 604A-604N (for N+1 virtual channels). Data from each of the FIFOs 604A-604N is fed into a corresponding one of the stage one switches 606A-606N. Based on the destination identifier of the flit, the route computation unit 610 determines whether the flit is routed to the stage two switch 608A or the stage two switch 608B), Kasibhatla et al. teach and a plurality of NoC switches configured to route the data using the first virtual destination ID to the first decoder switch (Figs. 1 and 6, [col 5 ln 38-42, ln 49-54, col 11 ln 1-8], combination of internal NoC 120 and external NoC 104 may allow any access point in the FPGA 102 to access any interface IP responder interface. A NoC node, or simply referred to herein as a node, is a component of the network that is connected, and in communication with, other nodes. Each node comprises at least one router to direct network traffic within the node (e.g., to a NAP of the node) or to another node (e.g., based on a destination identifier of a packet). Data from each of the FIFOs 604A-604N is fed into a corresponding one of the stage one switches 606A-606N. Based on the destination identifier of the flit, the route computation unit 610 determines whether the flit is routed to the stage two switch 608A or the stage two switch 608B. Each of the stage two switches 608A-608B corresponds to a different output direction of the router slice), Kasibhatla et al. teach wherein the first decoder switch is connected to a plurality of targets and is configured to decode an address in the data to assign a target destination ID corresponding to the first target (Figs. 1 and 5-6, [col 2 ln 67, col 3 ln 1, col 11 ln 9-16], each stage two switch 608A-608B receives flits destined for a single output direction of the router slice. The stage two switch determines which port of the output direction to use to send the flit to its destination (target). For example, in fig. 5, the slice 524 has three output ports to send data to the South, to the slice 526. Thus, all traffic for the slice 526 is provided to a single stage two switch, which then determines which of the three output ports to write the data to. When a head flit of a packet arrives at an output port of a router, the output port assigns a virtual channel to the packet). Kasibhatla et al. is teaching a network-on-chip receiving data from initiator and transmits it, via selected virtual channels, to the destination. Kasibhatla et al., however, fail to expressly described the assigning a target destination ID for routing the data to destination. (Emphasis added). Regarding claim 1, Yoshida et al. teach a plurality of NoC switches configured to route the data using the first virtual destination ID to the first decoder switch, wherein the first decoder switch is connected to a plurality of targets and is configured to decode an address in the data to assign a target destination ID corresponding to the first target (Figs. 5-6, [0142, 0165], the virtual channel choosing section 813 chooses one virtual channel 817, to which an output channel 818 has already been allocated, on an input port (801) basis by reference to the virtual channel information 901. Contents of virtual channel information 901 to be stored in the virtual channel information management section 806. To distinguish the respective virtual channels 817, the virtual channel information 901 includes an input port number to identify the input port 801 and a virtual channel number to identify the virtual channel 817. When a flit is stored in any of the virtual channels 817, destination address information to find the destination of that flit, the number of the output port 805 for use to send that flit to its destination, and the number of the output channel 818 used are written). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kasibhatla et al. by incorporating the features as taught by Yoshida et al. in order to provide a more effective and efficient system that is capable of routing the data using the first virtual destination ID to the first decoder switch, wherein the first decoder switch is connected to a plurality of targets and is configured to decode an address in the data to assign a target destination ID corresponding to the first target. The motivation is to support an improved method for arranging a transmission schedule for a traffic flow that runs through a plurality of routers connected together through a distributed bus (see [0003]). Regarding claim 11, Kasibhatla et al. teach a method, comprising: receiving, at a NoC, data from an initiator (Figs. 1, [col 4 ln 11-18, col ln 28-31], the architecture of an FPGA 102 with on-chip networking capabilities, according to some example embodiments. The FPGA 102 includes an external NoC 104 and an internal NoC 120, which provide high-throughput and easy-to-use access between peripherals and the FPGA core 122. The FPGA core 122 is surrounded by the external NoC 104 and includes the clusters 118, which are units of programmable logic configurable by the user. The initiator NAP 106 or the responder NAP 108 generates raw data flits, which are received by another NAP. The transfer happens through the routers of the iNoC 120), Kasibhatla et al. teach decoding an address associated with the data to generate a first virtual destination ID corresponding to a first decoder switch of a plurality of decoder switches in the NoC (Figs. 1 and 6, [col 2 ln 64-67, col 3 ln 1, col 10 ln 64-67, col 11 ln 1-4], each packet may be assigned a virtual channel by the sending router. Each router may have data storage for one or more flits on each virtual channel. When a head flit of a packet arrives at an output port of a router, the output port assigns a virtual channel to the packet. Arbiter 602 determines a virtual channel for the received flit and stores the data in a corresponding one of the FIFOs 604A-604N (for N+1 virtual channels). Data from each of the FIFOs 604A-604N is fed into a corresponding one of the stage one switches 606A-606N (decoder switch) . Based on the destination identifier of the flit, the route computation unit 610 determines whether the flit is routed to the stage two switch 608A or the stage two switch 608B), Kasibhatla et al. teach each decoder switch of the plurality of decoder switches corresponding to a different virtual destination ID (Figs. 1 and 6, [col 10 ln 43-47, col 10 ln 64-67, col 11 ln 1-4], the switched input block component 600 comprises an arbiter 602, FIFOs 604A-604N, stage one switches 606A-606N (decoder switches). FIFOs 604A-604N (for N+1 virtual channels). Data from each of the FIFOs 604A-604N is fed into a corresponding one of the stage one switches 606A-606N. Based on the destination identifier of the flit, the route computation unit 610 determines whether the flit is routed to the stage two switch 608A or the stage two switch 608B), Kasibhatla et al. teach routing the data through a plurality of switches of the NoC using the first virtual destination ID to reach the first decoder switch (Figs. 1 and 6, [col 5 ln 38-42, ln 49-54, col 11 ln 1-8], combination of internal NoC 120 and external NoC 104 may allow any access point in the FPGA 102 to access any interface IP responder interface. A NoC node, or simply referred to herein as a node, is a component of the network that is connected, and in communication with, other nodes. Each node comprises at least one router to direct network traffic within the node (e.g., to a NAP of the node) or to another node (e.g., based on a destination identifier of a packet). Data from each of the FIFOs 604A-604N is fed into a corresponding one of the stage one switches 606A-606N. Based on the destination identifier of the flit, the route computation unit 610 determines whether the flit is routed to the stage two switch 608A or the stage two switch 608B. Each of the stage two switches 608A-608B corresponds to a different output direction of the router slice), Kasibhatla et al. teach the first decoder switch connected to a plurality of targets; determining a target destination ID at the first decoder switch corresponding to a first target of the plurality of targets, wherein the first target is a target of the data; and routing the data through a remaining portion of the NoC using the target destination ID (Figs. 1 and 5-6, [col 2 ln 67, col 3 ln 1, col 11 ln 9-16], each stage two switch 608A-608B receives flits destined for a single output direction of the router slice. The stage two switch determines which port of the output direction to use to send the flit to its destination (target). For example, in fig. 5, the slice 524 has three output ports to send data to the South, to the slice 526. Thus, all traffic for the slice 526 is provided to a single stage two switch, which then determines which of the three output ports to write the data to. When a head flit of a packet arrives at an output port of a router, the output port assigns a virtual channel to the packet). Kasibhatla et al. is teaching a network-on-chip receiving data from initiator and transmits it, via selected virtual channels, to the destination. Kasibhatla et al., however, fail to expressly described the assigning a target destination ID for routing the data to destination. (Emphasis added). Regarding claim 11, Yoshida et al. teach the first decoder switch connected to a plurality of targets; determining a target destination ID at the first decoder switch corresponding to a first target of the plurality of targets, wherein the first target is a target of the data; and routing the data through a remaining portion of the NoC using the target destination ID (Figs. 5-6, [0142, 0165], the virtual channel choosing section 813 chooses one virtual channel 817, to which an output channel 818 has already been allocated, on an input port (801) basis by reference to the virtual channel information 901. Contents of virtual channel information 901 to be stored in the virtual channel information management section 806. To distinguish the respective virtual channels 817, the virtual channel information 901 includes an input port number to identify the input port 801 and a virtual channel number to identify the virtual channel 817. When a flit is stored in any of the virtual channels 817, destination address information to find the destination of that flit, the number of the output port 805 for use to send that flit to its destination, and the number of the output channel 818 used are written). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kasibhatla et al. by incorporating the features as taught by Yoshida et al. in order to provide a more effective and efficient system that is capable of routing the data using the first virtual destination ID to the first decoder switch, wherein the first decoder switch is connected to a plurality of targets and is configured to decode an address in the data to assign a target destination ID corresponding to the first target. The motivation is to support an improved method for arranging a transmission schedule for a traffic flow that runs through a plurality of routers connected together through a distributed bus (see [0003]). Claim(s) 2-3, 6, 12-13 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kasibhatla et al. (US 12,506,696 B2) in view of Yoshida et al. (US 2013/0028083 A1) as applied to claims 1 and 11 above, and further in view of Klenk et al. (US 2021/0036881 A1). Kasibhatla et al. and Yoshida et al. disclose the claimed limitations as described in paragraph 5 above. Kasibhatla et al. and Yoshida et al. do not expressly disclose the following features: regarding claim 2, wherein the ingress logic block is configured to assign the same first virtual destination ID to any traffic that is destined for each of the plurality of targets; regarding claim 3, wherein the NoC transmits data to the plurality of targets only through the first decoder switch, wherein each of the plurality of targets corresponds to a different target destination ID; regarding claim 6, wherein the NoC comprises: a second NoC switch disposed between the first decoder switch and the target, wherein the second NoC switch is configured to route the data using the target destination ID; regarding claim 12, the method further comprising: assigning the same first virtual destination ID to any traffic that is destined for each of the plurality of targets; regarding claim 13, wherein the NoC transmits data to the plurality of targets only through the first decoder switch, wherein each of the plurality of targets corresponds to a different target destination ID; regarding claim 16, wherein routing the data through the remaining portion of the NoC using the target destination ID comprises: using a NoC switch disposed between the first decoder switch and the target, wherein the NoC switch is configured to route the data using the target destination ID. Regarding claim 2, Klenk et al. teach wherein the ingress logic block is configured to assign the same first virtual destination ID to any traffic that is destined for each of the plurality of targets (Fig. 2, [0016, 0056-0057, 0149, 0151], a network 200 including a plurality of endpoints connected to a plurality of network devices, in accordance with some embodiments. As depicted in FIG. 2, eight endpoints 212, 214, 216, 218, 222, 224, 226, 228 are connected to four network devices 202, 204, 206, 208. The network devices 202, 204, 206, 208 are referred to as switches in fig. 2. A first endpoint 212 and a second endpoint 214 are connected to ports P0 and P1 of the first network device 202. A third endpoint 216 and a fourth endpoint 218 are connected to ports P0 and P1 of a second network device 204. A fifth endpoint 222 and a sixth endpoint 224 are connected to ports P0 and P1 of a third network device 206. A seventh endpoint 226 and an eighth endpoint 228 are connected to ports P0 and P1 of a fourth network device 208. Furthermore, the first network device 202 is connected from port P4 of the first network device 202 to port P4 of the third network device 206; connected from port P5 of the first network device 202 to port P6 of the fourth network device 208; and connected from port P7 of the first network device 202 to port P4 of the second network device 204. The second network device 204 is connected from port P5 of the second network device 204 to port P6 of the third network device 206; and connected from port P7 of the second network device 204 to port P7 of the fourth network device 208. The third network device 206 is also connected from port P7 of the third network device 206 to port P4 of the fourth network device 208. All connections are bi-directional. Each of the four network devices 202, 204, 206, 208 shown in fig. 2 can be similar to the network device 110 of fig. 1A. More specifically, each of the network devices 202, 204, 206, 208 can include logic 130 (or equivalent) and the MCR table 132 (or equivalent). The fabric manager 150 is configured to create an MCR. As part of step 702, each endpoint registers an existing memory allocation with the fabric manager 150. The memory allocation refers to a range of addresses allocated within a virtual address space (VAS) local to the endpoint. The fabric manager 150 maps the memory allocation for that endpoint to a particular MCR allocated within a shared memory space and maps a network identifier for that endpoint to the particular MCR. In other words, a range of network addresses can be allocated to the fabric manager 150 and requests to map a memory allocation in the endpoint to a particular MCR can be made by a write request to one of the network addresses allocated to the fabric manager 150. An endpoint, such as endpoint 0 112, transmits a data packet to the network device 110 that represents a multicast primitive. In some embodiments, the data packet includes a header and a payload. The header can include a field for a destination address that specifies a network address included within the range of addresses allocated to the MCR. The network device 110 includes logic 130 that decodes the header of the packet and determines that the destination address is associated with a network address corresponding to the MCR. Responsive to determining the network address corresponds with the MCR, the logic 130 looks up an entry in the MCR table 132 corresponding to the MCR in order to identify the participating endpoints in the network. The participating endpoints can be identified by a list of endpoint identifiers included in a target ID field of the MCR table 132 entry). Regarding claim 3, Klenk et al. teach wherein the NoC transmits data to the plurality of targets only through the first decoder switch, wherein each of the plurality of targets corresponds to a different target destination ID (Fig. 2, [0016, 0056, 0151], eight endpoints 212, 214, 216, 218, 222, 224, 226, 228 are connected to four network devices 202, 204, 206, 208. The network devices 202, 204, 206, 208 are referred to as switches. An endpoint, such as endpoint 0 112, transmits a data packet to the network device 110 that represents a multicast primitive. In some embodiments, the data packet includes a header and a payload. The header can include a field for a destination address that specifies a network address included within the range of addresses allocated to the MCR. The network device 110 includes logic 130 that decodes the header of the packet and determines that the destination address is associated with a network address corresponding to the MCR. Responsive to determining the network address corresponds with the MCR, the logic 130 looks up an entry in the MCR table 132 corresponding to the MCR in order to identify the participating endpoints in the network. The participating endpoints can be identified by a list of endpoint identifiers included in a target ID field of the MCR table 132 entry. Therefore, as shown in the fig. 7, each switch of fig. 2 has multiple end points (EP 0 , EP 1) at the ports 122, 124 and EP 2, EP 3 at the ports 126, 128 of each switch 110 (fig. 2). The packets is transmitted to the plurality of targets through the one decoder switch 110). Regarding claim 6, Klenk et al. teach wherein the NoC comprises: a second NoC switch disposed between the first decoder switch and the target, wherein the second NoC switch is configured to route the data using the target destination ID (Fig. 2, illustrates a network including a plurality of endpoints connected to a plurality of network devices, in accordance with some embodiments, see teachings in [0056-0057, 0151], switch 2 206 (second NoC switch) is disposed between decoder switch 0 202 (first decoder) and the parget EP 4, EP 5. The second switch 2 206 is to route the data to the target destination via EP 4 2222 or FP 5 224”); Regarding claim 12, Klenk et al. teach the method further comprising: assigning the same first virtual destination ID to any traffic that is destined for each of the plurality of targets (Fig. 2, [0016, 0056-0057, 0149, 0151] a network 200 including a plurality of endpoints connected to a plurality of network devices, in accordance with some embodiments. As depicted in FIG. 2, eight endpoints 212, 214, 216, 218, 222, 224, 226, 228 are connected to four network devices 202, 204, 206, 208. The network devices 202, 204, 206, 208 are referred to as switches in fig. 2. A first endpoint 212 and a second endpoint 214 are connected to ports P0 and P1 of the first network device 202. A third endpoint 216 and a fourth endpoint 218 are connected to ports P0 and P1 of a second network device 204. A fifth endpoint 222 and a sixth endpoint 224 are connected to ports P0 and P1 of a third network device 206. A seventh endpoint 226 and an eighth endpoint 228 are connected to ports P0 and P1 of a fourth network device 208. Furthermore, the first network device 202 is connected from port P4 of the first network device 202 to port P4 of the third network device 206; connected from port P5 of the first network device 202 to port P6 of the fourth network device 208; and connected from port P7 of the first network device 202 to port P4 of the second network device 204. The second network device 204 is connected from port P5 of the second network device 204 to port P6 of the third network device 206; and connected from port P7 of the second network device 204 to port P7 of the fourth network device 208. The third network device 206 is also connected from port P7 of the third network device 206 to port P4 of the fourth network device 208. All connections are bi-directional. Each of the four network devices 202, 204, 206, 208 shown in fig. 2 can be similar to the network device 110 of fig. 1A. More specifically, each of the network devices 202, 204, 206, 208 can include logic 130 (or equivalent) and the MCR table 132 (or equivalent). The fabric manager 150 is configured to create an MCR. As part of step 702, each endpoint registers an existing memory allocation with the fabric manager 150. The memory allocation refers to a range of addresses allocated within a virtual address space (VAS) local to the endpoint. The fabric manager 150 maps the memory allocation for that endpoint to a particular MCR allocated within a shared memory space and maps a network identifier for that endpoint to the particular MCR. In other words, a range of network addresses can be allocated to the fabric manager 150 and requests to map a memory allocation in the endpoint to a particular MCR can be made by a write request to one of the network addresses allocated to the fabric manager 150. An endpoint, such as endpoint 0 112, transmits a data packet to the network device 110 that represents a multicast primitive. In some embodiments, the data packet includes a header and a payload. The header can include a field for a destination address that specifies a network address included within the range of addresses allocated to the MCR. The network device 110 includes logic 130 that decodes the header of the packet and determines that the destination address is associated with a network address corresponding to the MCR. Responsive to determining the network address corresponds with the MCR, the logic 130 looks up an entry in the MCR table 132 corresponding to the MCR in order to identify the participating endpoints in the network. The participating endpoints can be identified by a list of endpoint identifiers included in a target ID field of the MCR table 132 entry). Regarding claim 13, Klenk et al. teach wherein the NoC transmits data to the plurality of targets only through the first decoder switch, wherein each of the plurality of targets corresponds to a different target destination ID (Fig. 2, [0016, 0056, 0151], eight endpoints 212, 214, 216, 218, 222, 224, 226, 228 are connected to four network devices 202, 204, 206, 208. The network devices 202, 204, 206, 208 are referred to as switches. An endpoint, such as endpoint 0 112, transmits a data packet to the network device 110 that represents a multicast primitive. In some embodiments, the data packet includes a header and a payload. The header can include a field for a destination address that specifies a network address included within the range of addresses allocated to the MCR. The network device 110 includes logic 130 that decodes the header of the packet and determines that the destination address is associated with a network address corresponding to the MCR. Responsive to determining the network address corresponds with the MCR, the logic 130 looks up an entry in the MCR table 132 corresponding to the MCR in order to identify the participating endpoints in the network. The participating endpoints can be identified by a list of endpoint identifiers included in a target ID field of the MCR table 132 entry. Therefore, as shown in the fig. 7, each switch of fig. 2 has multiple end points (EP 0 , EP 1) at the ports 122, 124 and EP 2, EP 3 at the ports 126, 128 of each switch 110 (fig. 2). The packets is transmitted to the plurality of targets through the one decoder switch 110). Regarding claim 16, Klenk et al. teach wherein routing the data through the remaining portion of the NoC using the target destination ID comprises: using a NoC switch disposed between the first decoder switch and the target, wherein the NoC switch is configured to route the data using the target destination ID (Fig. 2, [0056-0057, 0151], switch 2 206 (second NoC switch) is disposed between decoder switch 0 202 (first decoder) and the parget EP 4, EP 5. The second switch 2 206 is to route the data to the target destination via EP 4 2222 or FP 5 224”). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kasibhatla et al. with Yoshida et al. by incorporating the features as taught by Klenk et al. in order to provide a more effective and efficient system that is capable of configuring ingress logic block to assign the same first virtual destination ID to any traffic that is destined for each of the plurality of target, and the plurality targets are connected to each decoder switch. The motivation is to support an improved method to perform computations associated with multiple processors participating in a shared global memory system (see [0003]). Claim(s) 4 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kasibhatla et al. (US 12,506,696 B2) in view of Yoshida et al. (US 2013/0028083 A1) and Klenk et al. (US 2021/0036881 A1) as applied to claims 1 and 11 above, and further in view of Cheng (US 2018/0083868 A1). Kasibhatla et al., Yoshida et al., and Klenk et al. disclose the claimed limitations as described in paragraph 5 above. Kasibhatla et al., Yoshida et al., and Klenk et al. do not expressly disclose the following features: regarding claim 4, wherein the first decoder switch is configured to use a different port to route data to each of the plurality of targets; regarding claim 14, further comprising: transmitting data from the first decoder switch to each of the plurality of targets using a different port on the first decoder switch. Regarding claim 4, Cheng teaches wherein the first decoder switch is configured to use a different port to route data to each of the plurality of targets (Fig. 1, [0022], fabric 100 is shown to include any number of processing element (PE) 102 interconnected through switches 104. PEs 102 and switches 104 may sometimes be referred to as nodes in the fabric 100. The switches 104 may be configured with any number of input and output ports 106 that may link the switch to other switches or to PEs 102. Any given switch 104 may have zero, one, two or more PEs 102 linked to and/or otherwise associated with that switch). Regarding claim 14, Cheng teaches further comprising: transmitting data from the first decoder switch to each of the plurality of targets using a different port on the first decoder switch (Fig. 1, [0022], fabric 100 is shown to include any number of processing element (PE) 102 interconnected through switches 104. PEs 102 and switches 104 may sometimes be referred to as nodes in the fabric 100. The switches 104 may be configured with any number of input and output ports 106 that may link the switch to other switches or to PEs 102. Any given switch 104 may have zero, one, two or more PEs 102 linked to and/or otherwise associated with that switch). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kasibhatla et al. with Yoshida et al., and Klenk et al. by incorporating the features as taught by Cheng in order to provide a more effective and efficient system that is capable of using different port, by the decoder switch, to route data to each of the plurality of targets. The motivation is to support an improved method for distributed network routing table systems with improved support for multiple network topologies (see [0001]). Claim(s) 5, 7, 15 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kasibhatla et al. (US 12,506,696 B2) in view of Yoshida et al. (US 2013/0028083 A1) and Klenk et al. (US 2021/0036881 A1) as applied to claims 1 and 11 above, and further in view of Tran et al. (US 2016/0234115 A1). Kasibhatla et al. Yoshida et al., and Klenk et al. disclose the claimed limitations as described in paragraph 5 above. disclose the claimed limitations as described in paragraph 5 above. Kasibhatla et al. Yoshida et al., and Klenk et al. do not expressly disclose the following features: regarding claim 5, wherein data flows between the initiator and the first decoder switch along a same path in the NoC regardless of which of the plurality of targets is an ultimate destination of the data; regarding claim 7, wherein the second NoC switch does not store routing information corresponding to the first virtual destination ID, and wherein the plurality of NoC switches do not store routing information corresponding to the target destination ID; regarding claim 15, further comprising: transmitting data received from the initiator to each of the plurality of targets via the first decoder switch, wherein data flows between the initiator and the first decoder switch along a same path in the NoC regardless of which of the plurality of targets is an ultimate destination of the data; regarding claim 17, wherein the NoC switch does not store routing information corresponding to the first virtual destination ID. Regarding claim 5, Tran et al. teach wherein data flows between the initiator and the first decoder switch along a same path in the NoC regardless of which of the plurality of targets is an ultimate destination of the data (Fig. 2, [0038], each PE 102 in the system is associated with one or multiple PE Virtual Address. Looking at the whole picture, all PEs 102s in a device must have different PE virtual addresses and any two PEs should not have the same PE virtual address. The number of PE virtual addresses for a PE 102 is at least equal to the number of local lookup tables, which can be accessed by that PE 102. When an ISME 100 receives a packet, it determines which PE 102 it will send the packet to and which local lookup table will be used for performing lookup for that packet based on the destination PE virtual address embedded in the packet. To this end, the ISME 100 uses its Routing Tables 600 as depicted by the example in FIG. 6. Upon receiving a packet, the ISME 100 attracts the destination PE virtual address inside the packet and uses it as an index for a Routing Table 600. For each destination PE virtual address, the Routing Table 600 returns the output port ID for the ISME 100 to forward the packet to, and the table ID for performing a local lookup if the packet is sent to a local PE port. In other words, the routing table are changed but the routing path remains the same). Regarding claim 7, Tran et al. teach wherein the second NoC switch does not store routing information corresponding to the first virtual destination ID, and wherein the plurality of NoC switches do not store routing information corresponding to the target destination ID (Fig. 3, [0026, 0038, 0041], routing module 204 is shown to include a routing table address generation module 316 includes deterministic mode table entry selection module 600 (fig. 6a). Hash generation module 604 may be configured to generate a hash value based on the destination location ID (DLID), selected fields from the packet header and/or the switch ID. The hash value may be computed using any of a number of known hashing functions or algorithms that are configured to transform data of an arbitrary size to another typically smaller and fixed size value. The generated hash value is then processed by mask and shift module 606, in the same manner as described above with respect to module 602, to extract certain bit fields from the hash value, as specified by the CSRs 302. The processed DLID and hash value are then combined by combination logic 608, which may be configured, for example, to perform a bitwise OR operation, to generate the table entry selection). Regarding claim 15, Tran et al. teach further comprising: transmitting data received from the initiator to each of the plurality of targets via the first decoder switch, wherein data flows between the initiator and the first decoder switch along a same path in the NoC regardless of which of the plurality of targets is an ultimate destination of the data (Fig. 2, [0038], each PE 102 in the system is associated with one or multiple PE Virtual Address. Looking at the whole picture, all PEs 102s in a device must have different PE virtual addresses and any two PEs should not have the same PE virtual address. The number of PE virtual addresses for a PE 102 is at least equal to the number of local lookup tables, which can be accessed by that PE 102. When an ISME 100 receives a packet, it determines which PE 102 it will send the packet to and which local lookup table will be used for performing lookup for that packet based on the destination PE virtual address embedded in the packet. To this end, the ISME 100 uses its Routing Tables 600 as depicted by the example in FIG. 6. Upon receiving a packet, the ISME 100 attracts the destination PE virtual address inside the packet and uses it as an index for a Routing Table 600. For each destination PE virtual address, the Routing Table 600 returns the output port ID for the ISME 100 to forward the packet to, and the table ID for performing a local lookup if the packet is sent to a local PE port. In other words, the routing table are changed but the routing path remains the same). Regarding claim 17, Tran et al. teach wherein the NoC switch does not store routing information corresponding to the first virtual destination ID (Fig. 3, [0026, 0038, 0041], routing module 204 is shown to include a routing table address generation module 316 includes deterministic mode table entry selection module 600 (fig. 6a). Hash generation module 604 may be configured to generate a hash value based on the destination location ID (DLID), selected fields from the packet header and/or the switch ID. The hash value may be computed using any of a number of known hashing functions or algorithms that are configured to transform data of an arbitrary size to another typically smaller and fixed size value. The generated hash value is then processed by mask and shift module 606, in the same manner as described above with respect to module 602, to extract certain bit fields from the hash value, as specified by the CSRs 302. The processed DLID and hash value are then combined by combination logic 608, which may be configured, for example, to perform a bitwise OR operation, to generate the table entry selection). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kasibhatla et al. with Yoshida et al. and Klenk et al. by incorporating the features as taught by Tran et al. in order to provide a more effective and efficient system that is capable of having data flows between the initiator and the first decoder switch along a same path in the NoC regardless of which of the plurality of targets is an ultimate destination of the data; the second NoC switch does not store routing information corresponding to the first virtual destination ID, and wherein the plurality of NoC switches do not store routing information corresponding to the target destination ID; transmitting data received from the initiator to each of the plurality of targets via the first decoder switch, wherein data flows between the initiator and the first decoder switch along a same path in the NoC regardless of which of the plurality of targets is an ultimate destination of the data; wherein the NoC switch does not store routing information corresponding to the first virtual destination ID. The motivation is to support an improved method to an interconnect element which is used to build a bigger interconnection network for a multi-engine network processor (see [0001]). Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kasibhatla et al. (US 12,506,696 B2) in view of Yoshida et al. (US 2013/0028083 A1) as applied to claims 1 and 11 above, and further in view of Tran et al. (US 2016/0234115 A1). Kasibhatla et al. and Yoshida et al. disclose the claimed limitations as described in paragraph 5 above. Kasibhatla et al. and Yoshida et al. do not expressly disclose the following features: regarding claim 8, a second decoder switch of the plurality of decoder switches corresponding corresponds to a second virtual destination ID, wherein the second decoder switch controls access to a different set of unique targets than the first decoder switch, and wherein the plurality of NoC switches comprises routing information for both the first virtual destination ID and the second virtual destination ID. Regarding claim 8, Tran et al. teach a second decoder switch of the plurality of decoder switches corresponding corresponds to a second virtual destination ID, wherein the second decoder switch controls access to a different set of unique targets than the first decoder switch, and wherein the plurality of NoC switches comprises routing information for both the first virtual destination ID and the second virtual destination ID (Fig. 2, [0027, 0029], packet source is configured to send packets on all or a few primary input ports of the first ISME 100. The ISME 100 will then route the packets to its local PEs 102s or to next downstream ISME 100. Here, the packet routing decision is based on the destination PE's virtual address embedded in each packet. Once packets are completely processed by the proper PEs 102 as defined by the network features of the system, packets are forwarded to the last ISME 100. As shown in the fig, 2, the packet forwarding is performed via ISME 100, for destination 204, to the first ISME 100 connected to PE 4 and the second ISME 100 connected to PE 8. The lookup tables in the interconnect element 100 is built from a pool of memory tiles 110, which allow the lookup tables to be configured in different sizes depending on the needs of PEs 102s. As different PEs 102s have different lookup requirements, the sizes of the lookup tables should be reconfigured accordingly. In addition, different PEs 102s are configured to access different lookup tables independently. In some embodiments, two or more PEs 102s can access the same lookup table if these PEs 102s have the same network features). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kasibhatla et al. with Yoshida et al. by incorporating the features as taught by Tran et al. in order to provide a more effective and efficient system that is capable of having the NoC further comprises: a second decoder switch corresponding to a second virtual destination ID, wherein the second decoder switch controls access to a different set of unique targets than the first decoder switch, wherein the plurality of NoC switches comprises routing (information for both the first virtual destination ID and the second virtual destination ID. The motivation is to support an improved method to an interconnect element which is used to build a bigger interconnection network for a multi-engine network processor (see [0001]). Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kasibhatla et al. (US 12,506,696 B2) in view of Yoshida et al. (US 2013/0028083 A1) in view of Tran et al. (US 2016/0234115 A1) as applied to claims 1 above, and further in view of Cheng (US 2018/0083868 A1). Kasibhatla et al., Yoshida et al. and Tran et al. disclose the claimed limitations as described in paragraph 5 above. Kasibhatla et al., Yoshida et al. and Tran et al. do not expressly disclose the following features: regarding claim 9, further comprising: a second initiator configured to use a third NoC switch to route data to the first decoder switch using the first virtual destination ID and to the second decoder switch using the second virtual destination ID. Regarding claim 9, Cheng teaches further comprising: a second initiator configured to use a third NoC switch to route data to the first decoder switch using the first virtual destination ID and to the second decoder switch using the second virtual destination ID (Fig. 1, [0022, 0024], the fabric 100 in this illustration is laid out in a 2-dimensional array (along the x and y axis) for simplicity. In some embodiments, the fabric may be extended into a third dimension (along the z axis) and/or into higher dimensions not shown. In this simplified example, the switches are shown to be connected only to adjacent switches, although this need not be the case. In general, the switches 104 and PEs 102 may be arranged in any of a wide variety of topologies ranging from relatively simple configurations to more complex configurations. Fabric topologies may be chosen depending on their suitability to a particular application. Data or other information may be transmitted from one PE to any other PE by encapsulating the data in a packet that includes a header specifying a destination node address (DLID) and other routing information. The packet may then be routed along a path through any number of switches that each determines the next step in the path based on the packet header contents and further based on routing tables and CSRs within that switch, as will be described in greater detail below. Each packet with a given DLID may generally be routed through the same path because the hash function will map the DLID (and other packet header fields associated with the DLID in an invariant manner) to the same value for each such packet. In adaptive mode, however, packets with the same DLID may take different paths due to the randomization function). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kasibhatla et al. with Yoshida et al. and Tran et al. by incorporating the features as taught by Cheng in order to provide a more effective and efficient system that is capable of using a second initiator configured to use a third NoC switch to route data to the first decoder switch using the first virtual destination ID and to the second decoder switch using the second virtual destination ID. The motivation is to support an improved method for distributed network routing table systems with improved support for multiple network topologies (see [0001]). Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kasibhatla et al. (US 12,506,696 B2) in view of Yoshida et al. (US 2013/0028083 A1) as applied to claims 1 above, and further in view of Qi et al. (US 2023/0090429 A1). Kasibhatla et al. and Yoshida et al. disclose the claimed limitations as described in paragraph 5 above. Kasibhatla et al. and Yoshida et al. do not expressly disclose the following features: regarding claim 20, further comprising: performing hierarchical address decoding in the NoC where a contiguous address space addressed to one decoder switch is split to different physical addresses and mapped to individual pseudo-channels. Regarding claim 20, Qi et al. teach further comprising: performing hierarchical address decoding in the NoC where a contiguous address space addressed to one decoder switch is split to different physical addresses and mapped to individual pseudo-channels (Fig. 4, [0095, 0098-0100], memory controller 420 can further include a frontside arbitration controller 450. The frontside arbitration controller 450 is communicatively coupled with the memory unit 440 and a second group of hardware components in a NOC 475 to manage data flow between the memory unit 440 and the NOC 475 and components coupling to the NOC 475. For example, the second group of hardware components can include the NOC 475 and hardware components coupled with the NOC 475, e.g., one or more central processing units (CPUs) 479 or digital signal processing units (DSPs) 477, as described above. The data buses 471a-d under the second memory access protocol can be AXI agents (e.g., 8 AXI agents from the frontside arbitration controller 450), each of the AXI buses having a separate data load and data store channel of 128 bit. In some implementations, hardware components 410a-d of the first group of hardware components can each have one or more AXI agents 471i directly coupled with the NOC 475 for data communication. The arbitration controller 450 can further include a burst mode unit 457 for supporting the burst mode of data transfer. In some implementations, the data buses 471a-d coupled with the second group of hardware components can support burst mode for one or more hardware components of the second group of hardware components to access the shared memory. The burst mode for data transfer is controlled by the burst mode unit 457 of the frontside arbitration controller 450. The burst mode requires data access to the same memory bank. Even though the burst mode can be pre-determined and pointed to a contiguous range of memory addresses in the same physical memory bank, the memory controller described in this specification can map the contiguous memory addresses to different (e.g., non-contiguous) addresses and split the original burst mode addresses to different memory banks or memory bank groups based on one or more interleaving schemes. It would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kasibhatla et al. with Yoshida et al. by incorporating the features as taught by Qi et al. in order to provide a more effective and efficient system that is capable of performing hierarchical address decoding in the NoC where a contiguous address space addressed to one decoder switch is split to different physical addresses and mapped to individual pseudo-channels. The motivation is to support an improved method for optimizing performing AI computation with a memory controller architecture (see [0006]). Allowable Subject Matter Claims 10 and 18-19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED M BOKHARI whose telephone number is (571)270-3115. The examiner can normally be reached Monday through Friday. 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, Kwang B Yao can be reached at 5712723182. 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. /SYED M BOKHARI/Examiner, Art Unit 2473 5/20/2026 /KWANG B YAO/Supervisory Patent Examiner, Art Unit 2473
Read full office action

Prosecution Timeline

Show 5 earlier events
Feb 03, 2026
Final Rejection mailed — §103
Mar 21, 2026
Interview Requested
Mar 27, 2026
Applicant Interview (Telephonic)
Mar 27, 2026
Examiner Interview Summary
Apr 03, 2026
Response after Non-Final Action
Apr 27, 2026
Request for Continued Examination
Apr 29, 2026
Response after Non-Final Action
May 28, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12684362
Enhanced Uplink Spectrum Sharing
3y 3m to grant Granted Jul 14, 2026
Patent 12684631
STATIC SELECTION OF A SESSION MANAGEMENT FUNCTION OR USER PLANE FUNCTION IN A 5G CORE NETWORK
3y 3m to grant Granted Jul 14, 2026
Patent 12676785
EFFICIENT FAIL OVER TO BACKUP LINK
4y 9m to grant Granted Jul 07, 2026
Patent 12672141
COMMUNICATION METHOD AND APPARATUS
3y 8m to grant Granted Jun 30, 2026
Patent 12659989
SPECTRUM SHAPING FOR WIRELESS COMMUNICATIONS
3y 1m to grant Granted Jun 16, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
83%
Grant Probability
99%
With Interview (+18.2%)
3y 0m (~1m remaining)
Median Time to Grant
High
PTA Risk
Based on 852 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month