Prosecution Insights
Last updated: April 19, 2026
Application No. 17/682,015

SYSTEM, METHOD AND APPARATUS FOR PEER-TO-PEER COMMUNICATION

Non-Final OA §103
Filed
Feb 28, 2022
Examiner
RIGOL, YAIMA
Art Unit
2135
Tech Center
2100 — Computer Architecture & Software
Assignee
Altera Corporation
OA Round
3 (Non-Final)
75%
Grant Probability
Favorable
3-4
OA Rounds
3y 2m
To Grant
92%
With Interview

Examiner Intelligence

Grants 75% — above average
75%
Career Allow Rate
464 granted / 619 resolved
+20.0% vs TC avg
Strong +18% interview lift
Without
With
+17.5%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
18 currently pending
Career history
637
Total Applications
across all art units

Statute-Specific Performance

§101
5.5%
-34.5% vs TC avg
§103
54.0%
+14.0% vs TC avg
§102
9.2%
-30.8% vs TC avg
§112
17.5%
-22.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 619 resolved cases

Office Action

§103
Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . DETAILED ACTION As per the instant application having Application No. 17/682,015, the amendment filed on 1/12/2026 is herein acknowledged. Claims 1, 12 and 17 have been amended and claim 16 has been canceled. Claims 1-15 and 17-20 are pending. In the response to this Office action, the Examiner respectfully requests that support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line numbers in the specification and/or drawing figure(s). This will assist the Examiner in prosecuting this application. Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. 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 1/12/2026 has been entered. CLAIM CONSTRUCTION Note the claim language recited as “configurable” “programmable” as recited in the claims do not require the recited structure (i.e., the claimed circuit) to actually be configured or programmed to perform the listed functionalities. As such the claims do not require the claimed circuit or apparatus actually perform the listed functionality, but merely that the functionality not be expressly precluded. See MPEP 2103 (C ). For example, reciting “PTP circuit configure to…” or “PTP circuit programmed to…” would more positively recite the listed functionalities. REJECTIONS BASED ON PRIOR ART Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1-7, 9-10, 12-14, and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Kalyanasundharam et al., US Patent Application Publication Number 20200226081 (herein "KALYANASUNDHARAM") in view of Kegel et al., US Patent Application Publication Number 20160062911 (herein "KEGEL") and Malladi et al. (US 20210373951) (herein MALLADI). Regarding claim 1, KALYANASUNDHARAM discloses an apparatus (FIG. 3, platform 300) comprising: a first downstream port to couple to a first peer device (FIG. 4, 1 of the ports at port controllers 412, FIG. 5, port at port controller 522, connected to FIG. 3, module 320 as first peer device); a second downstream port to couple to a second peer device (FIG. 4, 1 of the ports at port controllers 412, FIG. 5, port at port controller 522, connected to FIG. 3, module 330 as second peer device); and a peer-to-peer (PTP) circuit to receive a memory access request from the first peer device, the memory access request having a target associated with the second peer device ([0022] "Any CCIX protocol component that sends or receives CCIX requests is referred to as a CCIX agent. The agent may be a Request Agent, a Home Agent, or a Slave Agent. A Request Agent is a CCIX Agent that is the source of read and write transactions.". E.g. thus, the ports of the PTP circuit may receive or send requests from/to any peer device), wherein the PTP circuit is to convert the memory access request from a coherent protocol to a memory protocol to generate a converted memory access request ([0032], "Light-weight memory protocol controller 570 is a coherent slave controller to send requests to and receive responses from a memory module through the CCIX port using a subset of CCIX protocol memory transaction types including only non-cacheable transactions and non-snooping transactions. In this embodiment, light-weight memory protocol controller 570 is a CCIX memory coherent slave/probe filter (MCS/PF) which maintains a memory directory (574) for the memory module, and a memory access request queue 572. The MCS/PF operates as a CCIX slave controller to manage access to an external memory module that does not perform CCIX coherent agent functionality. The probe filter operates to filter out cache coherence probes directed to the memory address space of the memory module managed by light-weight memory protocol controller 570. Memory directory 574 is employed to provide directory-based coherence for the external memory module, fulfilling directory-based coherence requests locally at the agent, and transforming access requests that may include coherency-related requests to a form using only the light-weight set of requests as listed in FIG. 7." FIG. 7 contains only memory access protocol requests for non-cacheable memory accesses. E.g. converting the request from a coherent protocol to a memory protocol, in response to a non-cacheable memory access request "directed to the memory address space" of memory module "managed by light-weight memory protocol controller 570" that does not perform coherency functionality) and send the converted memory access request to the second peer device ([0022] "Any CCIX protocol component that sends or receives CCIX requests is referred to as a CCIX agent. The agent may be a Request Agent, a Home Agent, or a Slave Agent. A Request Agent is a CCIX Agent that is the source of read and write transactions." E.g. thus, the ports of the PTP circuit may receive or send requests from/to any peer device). KALYANASUNDHARAM does not explicitly disclose wherein: the PTP circuit is configurable such that, in response to receiving another memory access request from the first peer device, the PTP circuit is to determine, based upon (1) whether one or more configured address ranges associated with the another memory access request and/or (2) whether one or more particular downstream requestors associated with the another memory access request, whether to send the another memory access request to a host processor coupled to the apparatus; the PTP circuit is also programmable to send the another memory access request via the host for all potential downstream requestors; and the one or more configured address ranges and the one or more particular downstream requestors are associated with one or more security concerns. KEGEL discloses wherein the PTP circuit is configurable such that, in response to receiving another memory access request from the first peer device, the PTP circuit is to determine, based upon whether (1) one or more configured address ranges associated with the another memory access request and/or (2) whether one or more particular downstream requestors associated with the another memory access request, whether to send the another memory access request to a host processor coupled to the apparatus (FIGs. 1-3, receive memory request from a peer device /peripheral device 210-1 to 210-N at PTP circuit /routing controller 220, which determines whether to send the memory request to a host processor /IOMMU 230, based on address ranges associated with the memory request, [0015] "The routing controller may include a device that makes a routing decision to determine whether the DMA request is to be routed via a first route that uses an IOMMU to process the request, or a second route that does not use an IOMMU to process the request. The routing controller may analyze the request to determine whether one or more conditions are satisfied. For example, the routing controller may determine whether routing via the second route is enabled, whether the virtual address is within a range of virtual addresses to be routed via the second route, whether a requested type of access (e.g., read access, write access, etc.) is permitted, or the like." IOMMU here may be interpreted as a host processor that oversees the routing controller. [0037] "In some embodiments, routing controller 220 controls routing for multiple peripheral devices 210. In this case, routing controller 220 may assign a set of enable fields that indicate which peripheral devices 210 are associated with routing decisions. For example, routing controller 220 may make routing decisions for memory access requests received from a first set of peripheral devices 210, and may not make routing decisions for memory access requests received from a second set of peripheral devices 210 (e.g., may forward requests received from the second set of peripheral devices 210 to IOMMU 230)." Thus, based on one or more particular requestors associated with the memory access request); and the one or more configured address ranges and the one or more particular downstream requestors are associated with one or more security concerns ([0067] "If the virtual address is within the range (block 550-YES), then process 500 may include determining whether a requested access type is permitted (block 560). For example, if routing controller 220 determines that the virtual address is within the range, then routing controller 220 may determine whether an access type, identified in the memory access request, is permitted." [0072] "As an example, assume that a memory access request, that identifies a particular virtual address, includes a request to write to main memory 250. Further, assume that the access control bit indicates that the particular virtual address, or a physical address associated with the particular virtual address, is read-only. In this case, routing controller 220 routes the memory access request via the first route toward main memory 250 (e.g., that includes IOMMU 230). IOMMU 230 may deny access, may provide an error, etc." [0033]-[0034] "routing controller 220 assigns multiple sets of registers (e.g., zero sets of registers, four sets of registers, eight sets of registers, etc.). In this case, the entire group of multiple sets may be enabled or disabled (e.g., using a routing control field associated with IOMMU 230) to enable or disable routing decisions (e.g., for a particular peripheral device 210, for a set of peripheral devices 210, for all peripheral devices 210, etc.) Additionally, or alternatively, routing controller 220 may set access control for a particular set of registers and/or a particular set of peripheral devices 210 using an access control field, as described herein in connection with block 340." Thus, address range and particular devices are associated with security concerns, access permissions). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify KALYANASUNDHARAM's multi-protocol memory system to further include KEGEL'S address range host routing for security concerns, to provide enhanced security (see KEGEL [0018]). The combination of KALYANASUNDHARAM and KEGEL does not expressly disclose the PTP circuit is also programmable to send the another memory access request via the host for all potential downstream requestors; however, regarding these limitations, MALLADI teaches (“[0087] As mentioned above, some embodiments implement a hierarchical structure with a master controller (which may be implemented in an FPGA or in an ASIC) being part of the server-linking switch 112, and a slave controller being part of the enhanced capability CXL switch 130, to provide a load-store interface (i.e., an interface having cache-line (e.g., 64 byte) granularity and that operates within the coherence domain without software driver involvement). Such a load-store interface may extend the coherence domain beyond an individual server, or CPU or host, and may involve a physical medium that is either electrical or optical (e.g., an optical connection with electrical-to-optical transceivers at both ends). In operation, the master controller (in the server-linking switch 112) boots (or “reboots”) and configures all the servers 105 on the rack. The master controller may have visibility on all the hosts, and it may (i) discover each server and discover how many servers 105 and memory modules 135 exist in the server cluster, (ii) configure each of the servers 105 independently, (iii) enable or disable some blocks of memory (e.g., enable or disable any of the memory modules 135) on different servers, based on, e.g., the configuration of the racks, (iv) control access (e.g., which server can control which other server), (v) implement flow control (e.g. it may, since all host and device requests go through the master, transmit data from the one server to another server, and perform flow control on the data), (vi) group or batch requests or packets (e.g., multiple cache requests being received by the master from different servers 105), and (vii) receive remote software updates, broadcast communications, and the like. In batch mode, the server-linking switch 112 may receive a plurality of packets destined for the same server (e.g., destined for a first server) and send them together (i.e., without a pause between them) to the first server. For example, server-linking switch 112 may receive a first packet, from a second server, and a second packet, from a third server, and transmit the first packet and the second packet, together, to the first server. Each of the servers 105 may expose, to the master controller, (i) an IPMI network interface, (ii) a system event log (SEL), and (iii) a board management controller (BMC), enabling the master controller to measure performance, to measure reliability on the fly, and to reconfigure the servers 105.” where the master controller of MALLADI is interpreted to correspond to the host via which all memory access requests are sent to the rest of the servers 105 which correspond to the claimed downstream requesters, see FIG. 1E and related text). Before the effective date of the invention, it would have been obvious to one of ordinary skill in the art to include the PTP circuit is also programmable to send the another memory access request via the host for all potential downstream requestors as taught by MALLADI since doing so would provide the benefits of enhanced performance and reliability since it allows for “enabling the master controller to measure performance, to measure reliability on the fly, and to reconfigure the servers 105” (par. 0087). Regarding claim 2, KALYANASUNDHARAM discloses further comprising a system address decoder to determine that a target address of the memory access request is associated with the second peer device ([0032], "The MCS/PF operates as a CCIX slave controller to manage access to an external memory module that does not perform CCIX coherent agent functionality. The probe filter operates to filter out cache coherence probes directed to the memory address space of the memory module managed by light-weight memory protocol controller 570. Memory directory 574 is employed to provide directory-based coherence for the external memory module, fulfilling directory-based coherence requests locally at the agent, and transforming access requests that may include coherency-related requests to a form using only the light-weight set of requests as listed in FIG. 7." FIG. 7 contains only memory access protocol requests for non-cacheable memory accesses. E.g. probe filter filters based on memory address, a target memory access request "directed to the memory address space" of memory module "managed by light-weight memory protocol controller 570" that does not perform coherency functionality). Regarding claim 3, KALYANASUNDHARAM discloses wherein the PTP circuit is to convert the memory access request based at least in part on a determination that the target address of the memory access request is associated with the second peer device ([0032], "The probe filter operates to filter out cache coherence probes directed to the memory address space of the memory module managed by light-weight memory protocol controller 570. Memory directory 574 is employed to provide directory-based coherence for the external memory module, fulfilling directory-based coherence requests locally at the agent, and transforming access requests that may include coherency-related requests to a form using only the light-weight set of requests as listed in FIG. 7." FIG. 7 contains only memory access protocol requests for non-cacheable memory accesses. E.g. converting the request from a coherent protocol to a memory protocol, in response to a non-cacheable memory access request "directed to the memory address space" of memory module "managed by light-weight memory protocol controller 570" that does not perform coherency functionality). Regarding claim 4, KALYANASUNDHARAM discloses wherein the PTP circuit is to determine whether the memory access request is cacheable ([0032], "The probe filter operates to filter out cache coherence probes directed to the memory address space of the memory module managed by light-weight memory protocol controller 570. Memory directory 574 is employed to provide directory-based coherence for the external memory module, fulfilling directory-based coherence requests locally at the agent, and transforming access requests that may include coherency-related requests to a form using only the light-weight set of requests as listed in FIG. 7." FIG. 7 contains only memory access protocol requests for non-cacheable memory accesses. E.g. probe filter filters based on memory address, a target memory access request "directed to the memory address space" of memory module "managed by light-weight memory protocol controller 570" that does not perform coherency functionality, thus determining whether the request is cacheable). Regarding claim 5, KALYANASUNDHARAM discloses wherein in response to a determination that the memory access request is uncacheable, the PTP circuit is to convert the memory access request from the coherent protocol to the memory protocol ([0032], "The probe filter operates to filter out cache coherence probes directed to the memory address space of the memory module managed by light-weight memory protocol controller 570. Memory directory 574 is employed to provide directory-based coherence for the external memory module, fulfilling directory-based coherence requests locally at the agent, and transforming access requests that may include coherency-related requests to a form using only the light-weight set of requests as listed in FIG. 7." FIG. 7 contains only memory access protocol requests for non-cacheable memory accesses. E.g. converting the request from a coherent protocol to a memory protocol, in response to a non-cacheable memory access request "directed to the memory address space" of memory module "managed by light-weight memory protocol controller 570" that does not perform coherency functionality, thus are uncacheable). Regarding claim 6, KALYANASUNDHARAM discloses wherein in response to a determination that a second memory access request received from the first peer device is cacheable, the apparatus is to send the second memory access request to the host processor coupled to the apparatus and not convert the second memory access request to the memory protocol ([0021], "Each port controller 412 is connected to data interconnect fabric 404 for allowing CPU 411, and potentially other processing elements, to access memory expansion modules 430. Thus, requests are sent to a host processor. [0032], "The probe filter operates to filter out cache coherence probes directed to the memory address space of the memory module managed by light-weight memory protocol controller 570. Memory directory 574 is employed to provide directory- based coherence for the external memory module, fulfilling directory-based coherence requests locally at the agent, and transforming access requests that may include coherency-related requests to a form using only the light-weight set of requests as listed in FIG. 7." FIG. 7 contains only memory access protocol requests for non-cacheable memory accesses. [0030], "ACM 550 is connected to data interconnect fabric 504 and to I/O hub 520 and receives and fulfills cache coherency requests from an external processing accelerator over the communication link. ACM 550 instantiates a full CCIX master agent having the capability to use a full set of CCIX protocol memory transaction types (see FIG. 6) for making and fulfilling memory access requests to memory attached to host or other accelerators." E.g. cacheable requests, targeted to memory that support caching coherency, are not filtered and not transformed/converted, are made to memory of the host as coherent cache data, thus sent to the host). Regarding claim 7, KALYANASUNDHARAM discloses wherein the PTP circuit is to receive a response for the converted memory access request from the second peer device and send the response to the first peer device ([0032], "Light-weight memory protocol controller 570 is a coherent slave controller to send requests to and receive responses from a memory module through the CCIX port using a subset of CCIX protocol memory transaction types including only non-cacheable transactions and non- snooping transactions." [0022] "Any CCIX protocol component that sends or receives CCIX requests is referred to as a CCIX agent. The agent may be a Request Agent, a Home Agent, or a Slave Agent. A Request Agent is a CCIX Agent that is the source of read and write transactions.". E.g. thus, the ports of the PTP circuit may receive or send requests/responses from/to any peer device). Regarding claim 9, wherein the coherent protocol and the memory protocol comply with Compute Express Link (CXL) Specification 2.0, and the apparatus comprises a switch that complies with the CXL Specification 2.0 (MALLADI teaches “[0061] The CXL interconnects in the system may comply with a cache coherent protocol such as the CXL 1.1 standard, or, in some embodiments, with the CXL 2.0 standard, with a future version of CXL, or any other suitable protocol (e.g., cache coherent protocol). The memory modules 135 may be directly attached to the processing circuits 115 as shown, and the top of rack Ethernet switch 110 may be used for scaling the system to larger sizes (e.g., with larger numbers of servers 105).” The stiches of MALLADI would thus comply with CXL Specification 2.0). Regarding claim 10, KALYANASUNDHARAM discloses wherein the PTP circuit comprises a cacheability detector to determine whether the memory access request is cacheable ([0032], "The probe filter operates to filter out cache coherence probes directed to the memory address space of the memory module managed by light-weight memory protocol controller 570. Memory directory 574 is employed to provide directory- based coherence for the external memory module, fulfilling directory-based coherence requests locally at the agent, and transforming access requests that may include coherency-related requests to a form using only the light-weight set of requests as listed in FIG. 7." FIG. 7 contains only memory access protocol requests for non-cacheable memory accesses. E.g. probe filter filters based on memory address, a target memory access request "directed to the memory address space" of memory module "managed by light-weight memory protocol controller 570" that does not perform coherency functionality, thus a cacheability detector determining whether the request is cacheable). Regarding claim 12, KALYANASUNDHARAM discloses a method comprising: receiving, in a switch (FIG. 3, switch 350 as PTP circuit) coupled to a first peer device and a second peer device (connected to FIG. 3, module 320 as first peer device, connected to FIG. 3, module 330 as second peer device), a memory access request of a coherent protocol from the first peer device ([0022] "Any CCIX protocol component that sends or receives CCIX requests is referred to as a CCIX agent. The agent may be a Request Agent, a Home Agent, or a Slave Agent. A Request Agent is a CCIX Agent that is the source of read and write transactions.". E.g. thus, may receive or send requests from/to any peer device. CCIX requests have coherent protocols as seen in FIG. 6); and in response to determining that the memory access request is uncacheable, converting the memory access request to a converted memory access request of a memory protocol and sending the converted memory access request to the second peer device ([0032], "Light-weight memory protocol controller 570 is a coherent slave controller to send requests to and receive responses from a memory module through the CCIX port using a subset of CCIX protocol memory transaction types including only non-cacheable transactions and non-snooping transactions. In this embodiment, light- weight memory protocol controller 570 is a CCIX memory coherent slave/probe filter (MCS/PF) which maintains a memory directory (574) for the memory module, and a memory access request queue 572. The MCS/PF operates as a CCIX slave controller to manage access to an external memory module that does not perform CCIX coherent agent functionality. The probe filter operates to filter out cache coherence probes directed to the memory address space of the memory module managed by light-weight memory protocol controller 570. Memory directory 574 is employed to provide directory- based coherence for the external memory module, fulfilling directory-based coherence requests locally at the agent, and transforming access requests that may include coherency-related requests to a form using only the light-weight set of requests as listed in FIG. 7." FIG. 7 contains only memory access protocol requests for non-cacheable memory accesses. E.g. converting the request from a coherent protocol to a memory protocol, in response to a non-cacheable memory access request "directed to the memory address space" of memory module "managed by light-weight memory protocol controller 570" that does not perform coherency functionality). KALYANASUNDHARAM does not expressly disclose and in response to receiving another memory access request from the first peer device, determining, based upon (1) whether one or more configured address ranges are associated with the another memory access request and/or (2) whether one or more particular downstream requestors are associated with the another memory access request, whether to send the another memory access request to a host processor coupled to the switch, and sending the another memory access request via the host processor for all potential downstream requestors. wherein the one or more configured address ranges and the one or more particular downstream requestors are associated with one or more security concerns. KEGEL discloses and in response to receiving another memory access request from the first peer device, determining, based upon (1) whether one or more configured address ranges are associated with the another memory access request and/or (2) whether one or more particular downstream requestors are associated with the another memory access request, whether to send the another memory access request to a host processor coupled to the switch, … (FIGs. 1-3, receive memory request from a peer device /peripheral device 210-1 to 210-N at PTP circuit /routing controller 220, which determines whether to send the memory request to a host processor /IOMMU 230, based on address ranges associated with the memory request, [0015] "The routing controller may include a device that makes a routing decision to determine whether the DMA request is to be routed via a first route that uses an IOMMU to process the request, or a second route that does not use an IOMMU to process the request. The routing controller may analyze the request to determine whether one or more conditions are satisfied. For example, the routing controller may determine whether routing via the second route is enabled, whether the virtual address is within a range of virtual addresses to be routed via the second route, whether a requested type of access (e.g., read access, write access, etc.) is permitted, or the like." IOMMU here may be interpreted as a host processor that oversees the routing controller. [0037] "In some embodiments, routing controller 220 controls routing for multiple peripheral devices 210. In this case, routing controller 220 may assign a set of enable fields that indicate which peripheral devices 210 are associated with routing decisions. For example, routing controller 220 may make routing decisions for memory access requests received from a first set of peripheral devices 210, and may not make routing decisions for memory access requests received from a second set of peripheral devices 210 (e.g., may forward requests received from the second set of peripheral devices 210 to IOMMU 230)." Thus, based on one or more particular requestors associated with the memory access request); and wherein the one or more configured address ranges and the one or more particular downstream requestors are associated with one or more security concerns as ([0067] "If the virtual address is within the range (block 550-YES), then process 500 may include determining whether a requested access type is permitted (block 560). For example, if routing controller 220 determines that the virtual address is within the range, then routing controller 220 may determine whether an access type, identified in the memory access request, is permitted." [0072] "As an example, assume that a memory access request, that identifies a particular virtual address, includes a request to write to main memory 250. Further, assume that the access control bit indicates that the particular virtual address, or a physical address associated with the particular virtual address, is read-only. In this case, routing controller 220 routes the memory access request via the first route toward main memory 250 (e.g., that includes IOMMU 230). IOMMU 230 may deny access, may provide an error, etc." [0033]-[0034] "routing controller 220 assigns multiple sets of registers (e.g., zero sets of registers, four sets of registers, eight sets of registers, etc.). In this case, the entire group of multiple sets may be enabled or disabled (e.g., using a routing control field associated with IOMMU 230) to enable or disable routing decisions (e.g., for a particular peripheral device 210, for a set of peripheral devices 210, for all peripheral devices 210, etc.) Additionally, or alternatively, routing controller 220 may set access control for a particular set of registers and/or a particular set of peripheral devices 210 using an access control field, as described herein in connection with block 340." Thus, address range and particular devices are associated with security concerns, access permissions). The combination of KALYANASUNDHARAM and KEGEL does not expressly disclose and sending the another memory access request via the host processor for all potential downstream requestors; however, regarding these limitations, MALLADI teaches (“[0087] As mentioned above, some embodiments implement a hierarchical structure with a master controller (which may be implemented in an FPGA or in an ASIC) being part of the server-linking switch 112, and a slave controller being part of the enhanced capability CXL switch 130, to provide a load-store interface (i.e., an interface having cache-line (e.g., 64 byte) granularity and that operates within the coherence domain without software driver involvement). Such a load-store interface may extend the coherence domain beyond an individual server, or CPU or host, and may involve a physical medium that is either electrical or optical (e.g., an optical connection with electrical-to-optical transceivers at both ends). In operation, the master controller (in the server-linking switch 112) boots (or “reboots”) and configures all the servers 105 on the rack. The master controller may have visibility on all the hosts, and it may (i) discover each server and discover how many servers 105 and memory modules 135 exist in the server cluster, (ii) configure each of the servers 105 independently, (iii) enable or disable some blocks of memory (e.g., enable or disable any of the memory modules 135) on different servers, based on, e.g., the configuration of the racks, (iv) control access (e.g., which server can control which other server), (v) implement flow control (e.g. it may, since all host and device requests go through the master, transmit data from the one server to another server, and perform flow control on the data), (vi) group or batch requests or packets (e.g., multiple cache requests being received by the master from different servers 105), and (vii) receive remote software updates, broadcast communications, and the like. In batch mode, the server-linking switch 112 may receive a plurality of packets destined for the same server (e.g., destined for a first server) and send them together (i.e., without a pause between them) to the first server. For example, server-linking switch 112 may receive a first packet, from a second server, and a second packet, from a third server, and transmit the first packet and the second packet, together, to the first server. Each of the servers 105 may expose, to the master controller, (i) an IPMI network interface, (ii) a system event log (SEL), and (iii) a board management controller (BMC), enabling the master controller to measure performance, to measure reliability on the fly, and to reconfigure the servers 105.” where the master controller of MALLADI is interpreted to correspond to the host via which all memory access requests are sent to the rest of the servers 105 which correspond to the claimed downstream requesters, see FIG. 1E and related text). Before the effective date of the invention, it would have been obvious to one of ordinary skill in the art to include the PTP circuit is also programmable to send the another memory access request via the host for all potential downstream requestors as taught by MALLADI since doing so would provide the benefits of enhanced performance and reliability since it allows for “enabling the master controller to measure performance, to measure reliability on the fly, and to reconfigure the servers 105” (par. 0087). Regarding claim 13, KALYANASUNDHARAM discloses further comprising in response to determining that the memory access request is cacheable, sending the memory access request to a host processor coupled to the switch ([0021], "Each port controller 412 is connected to data interconnect fabric 404 for allowing CPU 411, and potentially other processing elements, to access memory expansion modules 430. Thus, requests are sent to a host processor. [0032], "The probe filter operates to filter out cache coherence probes directed to the memory address space of the memory module managed by light-weight memory protocol controller 570. Memory directory 574 is employed to provide directory-based coherence for the external memory module, fulfilling directory-based coherence requests locally at the agent, and transforming access requests that may include coherency-related requests to a form using only the light-weight set of requests as listed in FIG. 7." FIG. 7 contains only memory access protocol requests for non-cacheable memory accesses. E.g. cacheable requests, targeted to memory that support caching coherency, are not filtered and not transformed/converted). Regarding claim 14, KALYANASUNDHARAM discloses further comprising receiving, in the switch, a response from the second peer device and sending the response to the first peer device ([0032], "Light-weight memory protocol controller 570 is a coherent slave controller to send requests to and receive responses from a memory module through the CCIX port using a subset of CCIX protocol memory transaction types including only non-cacheable transactions and non-snooping transactions." [0022] "Any CCIX protocol component that sends or receives CCIX requests is referred to as a CCIX agent. The agent may be a Request Agent, a Home Agent, or a Slave Agent. A Request Agent is a CCIX Agent that is the source of read and write transactions.". E.g. thus, the ports of the PTP circuit may receive or send requests/responses from/to any peer device). Regarding claim 16, wherein: the memory access request is to write data to the second peer device; and the data is to be sent from the first peer device to the second peer device via the switch (MALLADI TEACHES “[0063] In some embodiments, as mentioned above, the enhanced capability CXL switch 130 includes an FPGA (or ASIC) controller 137 and provides additional features beyond switching of CXL packets. The controller 137 of the enhanced capability CXL switch 130 may also act as a management device for the memory modules 135 and help with host control plane processing, and it may enable rich control semantics and statistics. The controller 137 may include an additional “backdoor” (e.g., 100 gigabit Ethernet (GbE)) network interface circuit 125. In some embodiments, the controller 137 presents as a CXL Type 2 device to the processing circuits 115, which enables the issuing of cache invalidate instructions to the processing circuits 115 upon receiving remote write requests. In some embodiments, DDIO technology is enabled, and remote data is first pulled to last level cache (LLC) of the processing circuit and later written to the memory modules 135 (from cache). As used herein, a “Type 2” CXL Device is one that can initiate transactions and that implements an optional coherent cache and host-managed device memory and for which applicable transaction types include all CXL.cache and all CXL.memory transactions.” And explains “[0087] As mentioned above, some embodiments implement a hierarchical structure with a master controller (which may be implemented in an FPGA or in an ASIC) being part of the server-linking switch 112, and a slave controller being part of the enhanced capability CXL switch 130, to provide a load-store interface (i.e., an interface having cache-line (e.g., 64 byte) granularity and that operates within the coherence domain without software driver involvement). Such a load-store interface may extend the coherence domain beyond an individual server, or CPU or host, and may involve a physical medium that is either electrical or optical (e.g., an optical connection with electrical-to-optical transceivers at both ends). In operation, the master controller (in the server-linking switch 112) boots (or “reboots”) and configures all the servers 105 on the rack.” Thus, the switches storing or writing data from other servers/processors). Regarding claim 17, KALYANASUNDHARAM discloses a system comprising: a host processor ([0021], "multiple CPU cores or other processors may be connected to data interconnect fabric 404, with data interconnect fabric 404 operable to communicatively link any of the processors to either port controller using addresses on data interconnect fabric 404"); a first peer device (FIG. 3, module 320 as first peer device); a second peer device (FIG. 3, module 330 as second peer device); and a switch having a first port coupled to the host processor (FIG. 3, switch 350 as PTP circuit with FIG. 4, 402 as first port connected to CPU 411), a second port coupled to the first peer device (FIG. 4, 1 of the ports at port controllers 412 as second port, connected to FIG. 3, module 320 as first peer device), and a third port coupled to the second peer device (FIG. 4, 1 of the ports at port controllers 412 as third port, connected to FIG. 3, module 320 as second peer device), wherein the switch comprises: a peer-to-peer (PTP) circuit (FIG. 3, switch 350 as PTP circuit) to receive a first memory access request having a uncacheable attribute, the first memory access request directed from the first peer device to the second peer device ([0022] "Any CCIX protocol component that sends or receives CCIX requests is referred to as a CCIX agent. The agent may be a Request Agent, a Home Agent, or a Slave Agent. A Request Agent is a CCIX Agent that is the source of read and write transactions.". E.g. thus, the ports of the PTP circuit may receive or send requests from/to any peer device. [0032], "Memory directory 574 is employed to provide directory-based coherence for the external memory module, fulfilling directory-based coherence requests locally at the agent, and transforming access requests that may include coherency-related requests to a form using only the light-weight set of requests as listed in FIG. 7." FIG. 7 contains only memory access protocol requests for non- cacheable memory accesses. E.g. a non-cacheable memory access request "directed to the memory address space" of memory module "managed by light-weight memory protocol controller 570" that does not perform coherency functionality, thus have a uncacheable attribute), and convert the first memory access request from a coherent protocol to a memory protocol to generate a converted first memory access request and send the converted first memory access request to the second peer device ([0032], "Light-weight memory protocol controller 570 is a coherent slave controller to send requests to and receive responses from a memory module through the CCIX port using a subset of CCIX protocol memory transaction types including only non-cacheable transactions and non- snooping transactions. In this embodiment, light-weight memory protocol controller 570 is a CCIX memory coherent slave/probe filter (MCS/PF) which maintains a memory directory (574) for the memory module, and a memory access request queue 572. The MCS/PF operates as a CCIX slave controller to manage access to an external memory module that does not perform CCIX coherent agent functionality. The probe filter operates to filter out cache coherence probes directed to the memory address space of the memory module managed by light-weight memory protocol controller 570. Memory directory 574 is employed to provide directory-based coherence for the external memory module, fulfilling directory-based coherence requests locally at the agent, and transforming access requests that may include coherency-related requests to a form using only the light-weight set of requests as listed in FIG. 7." FIG. 7 contains only memory access protocol requests for non-cacheable memory accesses. E.g. converting the request from a coherent protocol to a memory protocol, in response to a non-cacheable memory access request "directed to the memory address space" of memory module "managed by light-weight memory protocol controller 570" that does not perform coherency functionality). KALYANASUNDHARAM does not explicitly disclose wherein: in response to receiving a second memory access request from the first peer device, the PTP circuit is to determine, based upon (1) one or more configured address ranges associated with the second memory access request and/or (2) one or more particular downstream requestors associated with the second memory access request, whether to send the second memory access request to a host; and the one or more configured address ranges and the one or more particular downstream requestors are associated with one or more security concerns. KEGEL discloses wherein: the PTP circuit is configurable such that, in response to receiving a second memory access request from the first peer device, the PTP circuit is to determine, based upon (1) whether one or more configured address ranges associated with the second memory access request and/or (2) whether one or more particular downstream requestors associated with the second memory access request, whether to send the second memory access request to a host (FIGs. 1-3, receive memory request from a peer device /peripheral device 210-1 to 210- N at PTP circuit /routing controller 220, which determines whether to send the memory request to a host processor /IOMMU 230, based on address ranges associated with the memory request, [0015] "The routing controller may include a device that makes a routing decision to determine whether the DMA request is to be routed via a first route that uses an IOMMU to process the request, or a second route that does not use an IOMMU to process the request. The routing controller may analyze the request to determine whether one or more conditions are satisfied. For example, the routing controller may determine whether routing via the second route is enabled, whether the virtual address is within a range of virtual addresses to be routed via the second route, whether a requested type of access (e.g., read access, write access, etc.) is permitted, or the like." IOMMU here may be interpreted as a host processor that oversees the routing controller. [0037] "In some embodiments, routing controller 220 controls routing for multiple peripheral devices 210. In this case, routing controller 220 may assign a set of enable fields that indicate which peripheral devices 210 are associated with routing decisions. For example, routing controller 220 may make routing decisions for memory access requests received from a first set of peripheral devices 210, and may not make routing decisions for memory access requests received from a second set of peripheral devices 210 (e.g., may forward requests received from the second set of peripheral devices 210 to IOMMU 230)." Thus, based on one or more particular requestors associated with the memory access request); and the one or more configured address ranges and the one or more particular downstream requestors are associated with one or more security concerns ([0067] "If the virtual address is within the range (block 550-YES), then process 500 may include determining whether a requested access type is permitted (block 560). For example, if routing controller 220 determines that the virtual address is within the range, then routing controller 220 may determine whether an access type, identified in the memory access request, is permitted." [0072] "As an example, assume that a memory access request, that identifies a particular virtual address, includes a request to write to main memory 250. Further, assume that the access control bit indicates that the particular virtual address, or a physical address associated with the particular virtual address, is read-only. In this case, routing controller 220 routes the memory access request via the first route toward main memory 250 (e.g., that includes IOMMU 230). IOMMU 230 may deny access, may provide an error, etc." [0033]-[0034] "routing controller 220 assigns multiple sets of registers (e.g., zero sets of registers, four sets of registers, eight sets of registers, etc.). In this case, the entire group of multiple sets may be enabled or disabled (e.g., using a routing control field associated with IOMMU 230) to enable or disable routing decisions (e.g., for a particular peripheral device 210, for a set of peripheral devices 210, for all peripheral devices 210, etc.) Additionally, or alternatively, routing controller 220 may set access control for a particular set of registers and/or a particular set of peripheral devices 210 using an access control field, as described herein in connection with block 340." Thus, address range and particular devices are associated with security concerns, access permissions). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify KALYANASUNDHARAM's multi-protocol memory system to further include KEGEL'S address range host routing for security concerns, to provide enhanced security (see KEGEL [0018]). The combination of KALYANASUNDHARAM and KEGEL does not expressly disclose the PTP circuit is also programmable to send the another memory access request via the host processor for all potential downstream requestors; however, regarding these limitations, MALLADI teaches (“[0087] As mentioned above, some embodiments implement a hierarchical structure with a master controller (which may be implemented in an FPGA or in an ASIC) being part of the server-linking switch 112, and a slave controller being part of the enhanced capability CXL switch 130, to provide a load-store interface (i.e., an interface having cache-line (e.g., 64 byte) granularity and that operates within the coherence domain without software driver involvement). Such a load-store interface may extend the coherence domain beyond an individual server, or CPU or host, and may involve a physical medium that is either electrical or optical (e.g., an optical connection with electrical-to-optical transceivers at both ends). In operation, the master controller (in the server-linking switch 112) boots (or “reboots”) and configures all the servers 105 on the rack. The master controller may have visibility on all the hosts, and it may (i) discover each server and discover how many servers 105 and memory modules 135 exist in the server cluster, (ii) configure each of the servers 105 independently, (iii) enable or disable some blocks of memory (e.g., enable or disable any of the memory modules 135) on different servers, based on, e.g., the configuration of the racks, (iv) control access (e.g., which server can control which other server), (v) implement flow control (e.g. it may, since all host and device requests go through the master, transmit data from the one server to another server, and perform flow control on the data), (vi) group or batch requests or packets (e.g., multiple cache requests being received by the master from different servers 105), and (vii) receive remote software updates, broadcast communications, and the like. In batch mode, the server-linking switch 112 may receive a plurality of packets destined for the same server (e.g., destined for a first server) and send them together (i.e., without a pause between them) to the first server. For example, server-linking switch 112 may receive a first packet, from a second server, and a second packet, from a third server, and transmit the first packet and the second packet, together, to the first server. Each of the servers 105 may expose, to the master controller, (i) an IPMI network interface, (ii) a system event log (SEL), and (iii) a board management controller (BMC), enabling the master controller to measure performance, to measure reliability on the fly, and to reconfigure the servers 105.” where the master controller of MALLADI is interpreted to correspond to the host via which all memory access requests are sent to the rest of the servers 105 which correspond to the claimed downstream requesters, see FIG. 1E and related text). Before the effective date of the invention, it would have been obvious to one of ordinary skill in the art to include the PTP circuit is also programmable to send the another memory access request via the host for all potential downstream requestors as taught by MALLADI since doing so would provide the benefits of enhanced performance and reliability since it allows for “enabling the master controller to measure performance, to measure reliability on the fly, and to reconfigure the servers 105” (par. 0087). Regarding claim 18, KALYANASUNDHARAM discloses wherein the switch is to receive a third memory access request having a cacheable attribute, the third memory access request directed from the first peer device to the second peer device, and send the third memory access request to the host processor ([0021], "Each port controller 412 is connected to data interconnect fabric 404 for allowing CPU 411, and potentially other processing elements, to access memory expansion modules 430. Thus, requests are sent to a host processor. [0032], "The probe filter operates to filter out cache coherence probes directed to the memory address space of the memory module managed by light-weight memory protocol controller 570. Memory directory 574 is employed to provide directory-based coherence for the external memory module, fulfilling directory-based coherence requests locally at the agent, and transforming access requests that may include coherency-related requests to a form using only the light-weight set of requests as listed in FIG. 7." FIG. 7 contains only memory access protocol requests for non-cacheable memory accesses. [0030], "ACM 550 is connected to data interconnect fabric 504 and to I/O hub 520 and receives and fulfills cache coherency requests from an external processing accelerator over the communication link. ACM 550 instantiates a full CCIX master agent having the capability to use a full set of CCIX protocol memory transaction types (see FIG. 6) for making and fulfilling memory access requests to memory attached to host or other accelerators." E.g. cacheable requests, targeted to memory that support caching coherency, are not filtered and not transformed/converted, are made to memory of the host as coherent cache data, thus sent to the host). Regarding claim 19, KALYANASUNDHARAM discloses wherein the PTP circuit is to receive a response for the converted first memory access request from the second peer device and send the response to the first peer device ([0032], "Light-weight memory protocol controller 570 is a coherent slave controller to send requests to and receive responses from a memory module through the CCIX port using a subset of CCIX protocol memory transaction types including only non-cacheable transactions and non-snooping transactions." [0022] "Any CCIX protocol component that sends or receives CCIX requests is referred to as a CCIX agent. The agent may be a Request Agent, a Home Agent, or a Slave Agent. A Request Agent is a CCIX Agent that is the source of read and write transactions.". E.g. thus, the ports of the PTP circuit may receive or send requests/responses from/to any peer device). Claims 8, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over KALYANASUNDHARAM in view of KEGEL and MALLADI, and further in view of Jones et al., US Patent Number 6470429 (herein "JONES"). Regarding claim 8, KALYANASUNDHARAM discloses wherein the PTP circuit is to send the converted response to the first peer device ([0032], "Light-weight memory protocol controller 570 is a coherent slave controller to send requests to and receive responses from a memory module through the CCIX port using a subset of CCIX protocol memory transaction types including only non-cacheable transactions and non- snooping transactions." [0022] "Any CCIX protocol component that sends or receives CCIX requests is referred to as a CCIX agent. The agent may be a Request Agent, a Home Agent, or a Slave Agent. A Request Agent is a CCIX Agent that is the source of read and write transactions.". E.g. thus, the ports of the PTP circuit may receive or send requests/responses from/to any peer device). KALYANASUNDHARAM, KEGEL and MALLADI do not explicitly disclose convert the response from the memory protocol to the coherent protocol to generate a converted response. JONES discloses convert the response from the memory protocol to the coherent protocol to generate a converted response (col. 6 lines 41-53, "Host bridge unit 210 of the preferred embodiment includes a cache coherence controller 212 that preferably implements the coherence protocol. A memory request by the processor or I/O device is transmitted to the host bridge unit 210. The host bridge unit 210 identifies memory requests that are non-cacheable before they are sent to the cache coherence controller 212. Thus, the cache coherence controller 212 for non-cacheable memory requests can skip the cache coherence directory lookup and evaluation. For non-cacheable memory requests, the host bridge unit 210 will return a coherent indication to its processor indicating that main memory 102 of the processor that owns the memory request data contains the most recent copy." E.g. the response of a memory protocol address lookup is converted by skipping coherence directory lookup /evaluation and adding a coherent indication in as part of response). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify KALYANASUNDHARAM's multi-protocol memory system with KEGEL'S address range host routing for security concerns, and MALLADI, to further include JONES' conversion of response to coherent protocol, to further reduce the access time for processor and peripheral device memory requests (see JONES col. 2 lines 37-38). Regarding claim 15, KALYANASUNDHARAM discloses further comprising receiving the response of the memory protocol and sending the converted response to the first peer device ([0032], "Light-weight memory protocol controller 570 is a coherent slave controller to send requests to and receive responses from a memory module through the CCIX port using a subset of CCIX protocol memory transaction types including only non-cacheable transactions and non-snooping transactions." [0022] "Any CCIX protocol component that sends or receives CCIX requests is referred to as a CCIX agent. The agent may be a Request Agent, a Home Agent, or a Slave Agent. A Request Agent is a CCIX Agent that is the source of read and write transactions.". E.g. thus, the ports of the PTP circuit may receive or send requests/responses from/to any peer device). KALYANASUNDHARAM, KEGEL and MALLADI do not explicitly disclose converting the response to the coherent protocol to generate a converted response. JONES discloses converting the response to the coherent protocol to generate a converted response (col. 6 lines 41-53, "Host bridge unit 210 of the preferred embodiment includes a cache coherence controller 212 that preferably implements the coherence protocol. A memory request by the processor or I/O device is transmitted to the host bridge unit 210. The host bridge unit 210 identifies memory requests that are non-cacheable before they are sent to the cache coherence controller 212. Thus, the cache coherence controller 212 for non-cacheable memory requests can skip the cache coherence directory lookup and evaluation. For non-cacheable memory requests, the host bridge unit 210 will return a coherent indication to its processor indicating that main memory 102 of the processor that owns the memory request data contains the most recent copy." E.g. the response of a memory protocol address lookup is converted by skipping coherence directory lookup /evaluation and adding a coherent indication in as part of response). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify KALYANASUNDHARAM's multi-protocol memory system with KEGEL'S address range host routing for security concerns, and MALLADI to further include JONES' conversion of response to coherent protocol, to further reduce the access time for processor and peripheral device memory requests (see JONES col. 2 lines 37-38). Regarding claim 20, KALYANASUNDHARAM discloses wherein the PTP circuit is to send the converted response to the first peer device ([0032], "Light-weight memory protocol controller 570 is a coherent slave controller to send requests to and receive responses from a memory module through the CCIX port using a subset of CCIX protocol memory transaction types including only non-cacheable transactions and non- snooping transactions." [0022] "Any CCIX protocol component that sends or receives CCIX requests is referred to as a CCIX agent. The agent may be a Request Agent, a Home Agent, or a Slave Agent. A Request Agent is a CCIX Agent that is the source of read and write transactions.". E.g. thus, the ports of the PTP circuit may receive or send requests/responses from/to any peer device), the coherent protocol and the memory protocol comply with Compute Express Link (CXL) Specification 2.0 (MALLADI teaches “[0061] The CXL interconnects in the system may comply with a cache coherent protocol such as the CXL 1.1 standard, or, in some embodiments, with the CXL 2.0 standard, with a future version of CXL, or any other suitable protocol (e.g., cache coherent protocol). The memory modules 135 may be directly attached to the processing circuits 115 as shown, and the top of rack Ethernet switch 110 may be used for scaling the system to larger sizes (e.g., with larger numbers of servers 105).” “[0084] In the embodiment of FIG. 1E, the server-linking switch 112 may group or batch multiple cache requests received from different servers 105, and it may group packets, reducing control overhead. The enhanced capability CXL switch 130 may include a slave controller (e.g., a slave FPGA or a slave ASIC) to (i) route data to different memory types based on workload, (ii) virtualize processor-side addresses to memory-side addresses, and (iii) facilitate coherent requests between different servers 105, bypassing the processing circuits 115. The system illustrated in FIG. 1E may be CXL 2.0 based, it may include distributed shared memory within a rack, and it may use the ToR server-linking switch 112 to natively connect with remote nodes.”). KALYANASUNDHARAM, KEGEL and MALLADI do not explicitly disclose convert the response from the memory protocol to the coherent protocol. JONES discloses convert the response from the memory protocol to the coherent protocol (col. 6 lines 41-53, "Host bridge unit 210 of the preferred embodiment includes a cache coherence controller 212 that preferably implements the coherence protocol. A memory request by the processor or I/O device is transmitted to the host bridge unit 210. The host bridge unit 210 identifies memory requests that are non-cacheable before they are sent to the cache coherence controller 212. Thus, the cache coherence controller 212 for non-cacheable memory requests can skip the cache coherence directory lookup and evaluation. For non-cacheable memory requests, the host bridge unit 210 will return a coherent indication to its processor indicating that main memory 102 of the processor that owns the memory request data contains the most recent copy." E.g. the response of a memory protocol address lookup is converted by skipping coherence directory lookup /evaluation and adding a coherent indication in as part of response). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify KALYANASUNDHARAM's multi-protocol memory system with KEGEL'S address range host routing for security concerns and MALLADI, to further include JONES' conversion of response to coherent protocol, to further reduce the access time for processor and peripheral device memory requests (see JONES col. 2 lines 37-38). Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over KALYANASUNDHARAM in view of KEGEL and MALLADI, and further in view of Wilkins et al., US Patent Application Publication Number 20180095882 (herein "WILKINS"). Regarding claim 11, KALYANASUNDHARAM, KEGEL and MALLADI do not explicitly disclose wherein the PTP circuit comprises a tag remapper to remap a source tag of the memory access request to a remapped source tag and send the converted memory access request having the remapped source tag to the second peer device. WILKINS discloses wherein the PTP circuit comprises a tag remapper to remap a source tag of the memory access request to a remapped source tag and send the converted memory access request having the remapped source tag to the second peer device ([0034], "In one or more embodiments, the packet manager (124) may include functionality to modify the tag (156) of the physical address (154) in the reference (160) prior to sending the packet (170) to the host computer (102), in order to indicate that the page has a cacheability status of "cacheable". For example, the non-cacheable setting of the tag (156) in the reference (160) may correspond to an input/output address space (or unused address space) of the host computer (102), in which case it may be necessary to modify the tag (156) prior to sending the packet (170) so that the reference (160) corresponds to an address space (e.g., a memory address space) that is actually used by the host computer (102) to address non-persistent (132) storage and/or persistent storage (138). Furthermore, modifying the tag (156) in the packet (170) to indicate that the corresponding page (134, 139) has a cacheability status of "cacheable" permits the host caches (136) to be used (e.g., to obtain the performance benefits of caching on the host computer (102))." E.g. modifying/remapping the source tag of the request before sending it to the host (which is the second peer device here)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify KALYANASUNDHARAM's multi-protocol memory system with KEGEL'S address range host routing for security concerns and MALLADI, to further include WILKINS' request tag remapper for non-cacheable data, to allow devices/processors to have coherent, shared access to the memory of the host computer (see WILKINS [0015]). ACKNOWLEDGEMENT OF ISSUES RAISED BY APPLICANT Response to Amendment Applicant's arguments filed on 1/12/2026 with respect to claims 1-15 and 17-20 have been considered but are moot in view of the new ground(s) of rejection. CLOSING COMMENTS a. STATUS OF CLAIMS IN THE APPLICATION a(1) CLAIMS REJECTED IN THE APPLICATION Per the instant office action, claims 1-15 and 17-20 have received a first action on the merits and are subject to a non-final rejection. a(2) CLAIMS NO LONGER UNDER CONSIDERATION Claim 16 has been canceled. b. DIRECTION OF FUTURE CORRESPONDENCES Any inquiry concerning this communication or earlier communications from the examiner should be directed to YAIMA RIGOL whose telephone number is (571)272-1232. The examiner can normally be reached Monday-Friday 9:00AM-5:00PM. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jared I. Rutz can be reached on (571) 272-5535. 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. March 17, 2026 /YAIMA RIGOL/ Primary Examiner, Art Unit 2135
Read full office action

Prosecution Timeline

Feb 28, 2022
Application Filed
Jul 26, 2022
Response after Non-Final Action
Mar 18, 2025
Non-Final Rejection — §103
Jun 23, 2025
Response Filed
Sep 05, 2025
Final Rejection — §103
Jan 12, 2026
Request for Continued Examination
Jan 24, 2026
Response after Non-Final Action
Mar 17, 2026
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12591522
COMPUTER-READABLE RECORDING MEDIUM HAVING STORED THEREIN MEMORY ACCESS CONTROL PROGRAM, MEMORY ACCESS CONTROL METHOD, AND INFORMATION PROCESSING APPARATUS
2y 5m to grant Granted Mar 31, 2026
Patent 12585581
MEMORY MODULE HAVING VOLATILE AND NON-VOLATILE MEMORY SUBSYSTEMS AND METHOD OF OPERATION
2y 5m to grant Granted Mar 24, 2026
Patent 12579073
APPARATUS AND METHOD FOR INTELLIGENT MEMORY PAGE MANAGEMENT
2y 5m to grant Granted Mar 17, 2026
Patent 12578899
MEMORY DEVICE, MEMORY SYSTEM, MEMORY CONTROLLER, AND OPERATION METHOD
2y 5m to grant Granted Mar 17, 2026
Patent 12566716
SYSTEMS AND METHODS FOR TIMESTEP SHARED MEMORY MULTIPROCESSING BASED ON TRACKING TABLE MECHANISMS
2y 5m to grant Granted Mar 03, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
75%
Grant Probability
92%
With Interview (+17.5%)
3y 2m
Median Time to Grant
High
PTA Risk
Based on 619 resolved cases by this examiner. Grant probability derived from career allow 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