CTFR 18/148,993 CTFR 101517 DETAILED ACTION 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. The Office Action is in response to claims filed 04/29/2026. Claims 1-2, 5, 8, and 21-28 are pending. Double Patenting 08-33 AIA The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg , 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman , 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi , 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum , 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel , 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington , 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA/25, or PTO/AIA/26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer. Claims 1, 21, and 25 is rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 8, 21 and 24, and 25 and 28 of copending application 18/148,997 (hereafter ‘997) and in view of Palmer et al. Pub. No. US 20230289215 A1 (hereafter Palmer) as exemplified in the table below. Instant Application 18/148,997 1. An apparatus comprising: processing circuitry having a cluster of cores and a memory, the processing circuitry to: initiate broadcasting of a data element from a producer core to one or more consumer cores; and synchronize the broadcast of the data element, wherein synchronizing includes establishing a multi-core barrier for the broadcast of the data element 1. An apparatus comprising: processing circuitry having one or more cluster of cores and a memory, the processing circuitry to: request a data element; determine whether any one or more cores in a first cluster of cores are to be associated with the data element; and upon determining the one or more cores are associated with the data element, broadcast the data element to the one or more cores via an interconnect associated with the first cluster of the cores. Palmer ¶ [0319] states “source SM can communicate with any target SM” 8. The apparatus of claim 1, wherein the first cluster of cores is coupled to gateway circuitry to provide synchronization in broadcasting data elements, and wherein the processing circuitry comprises graphics processing circuitry Palmer ¶ [0274] states “Barriers are useful for example to synchronize all of the CTAs in a CGA for any reason”. ¶ [0239] states “enable CTAs that are concurrently running on SMs to read from, write to, and do atomic accesses to memory allocated to other CTAs running on other SMs”. Examiner’s Note: barriers are multi-core because they synchronize CTAs executing on multiple different SMs. 21. A method comprising: initiating, by processing circuitry of a computing device, broadcasting of a data element from a producer core to one or more consumer cores , wherein the processing circuitry comprises a memory and a cluster of cores including the producer core and the one or more consumer cores ; and synchronizing the broadcast of the data element, wherein synchronizing includes establishing a multi-core barrier for the broadcast of the data element. 21. A method comprising: requesting, by processing circuitry of a computing device, a data element, determining whether one or more cores in a first cluster of cores are to be associated with the data element, and upon determining the one or more cores are associated with the data element, broadcasting the data element to the one or more cores via an interconnect associated with the first cluster of the cores. Palmer ¶ [0319] states “source SM can communicate with any target SM” 24. The method of claim 21, wherein the first cluster of cores is coupled to gateway circuitry to provide synchronization in broadcasting data elements, and wherein the processing circuitry comprises graphics processing circuitry. Palmer ¶ [0274] states “Barriers are useful for example to synchronize all of the CTAs in a CGA for any reason”. ¶ [0239] states “enable CTAs that are concurrently running on SMs to read from, write to, and do atomic accesses to memory allocated to other CTAs running on other SMs”. Examiner’s Note: barriers are multi-core because they synchronize CTAs executing on multiple different SMs. 25. At least one computer-readable medium having stored thereon instructions which, when executed, cause a computing device to perform operations comprising: initiating, by processing circuitry of the computing device, broadcasting of a data element from a producer core to one or more consumer cores , wherein the processing circuitry comprises a memory and a cluster of cores including the producer core and the one or more consumer cores ; and synchronizing the broadcast of the data element, wherein synchronizing includes establishing a multi-core barrier for the broadcast of the data element. 25. At least one computer-readable medium having stored thereon instructions which, when executed, cause a computing device to perform operations comprising: requesting, by processing circuitry of the computing device, a data element, determining whether one or more cores in a first cluster of cores are to be associated with the data element, and upon determining the one or more cores are associated with the data element, broadcasting the data element to the one or more cores via an interconnect associated with the first cluster of the cores. Palmer ¶ [0319] states “source SM can communicate with any target SM” 28. The computer-readable medium of claim 25, wherein the first cluster of cores is coupled to gateway circuitry to provide synchronization in broadcasting data elements, and wherein the processing circuitry comprises graphics processing circuitry. Palmer ¶ [0274] states “Barriers are useful for example to synchronize all of the CTAs in a CGA for any reason”. ¶ [0239] states “enable CTAs that are concurrently running on SMs to read from, write to, and do atomic accesses to memory allocated to other CTAs running on other SMs”. Examiner’s Note: barriers are multi-core because they synchronize CTAs executing on multiple different SMs. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant application and ‘997 overlap in scope. Further, the system including on or more GPUs, the elements of a producer and consumer core, and the multi-core barrier of Palmer would be obvious to combine with the cluster of cores of the instant application. One of ordinary skill in the art would have been motivated to combine these teachings so that “CGAs guarantee all their CTAs execute concurrently”, which enables “other hardware optimizations are possible such as: Multicasting data returned from memory to multiple SMs (CTAs) to save interconnect bandwidth. Direct SM-to-SM communication for lower latency data sharing and improved synchronization between producer and consumer threads in the CGA. Hardware barriers for synchronizing execution across all (or any) threads in a CGA (¶ [0116] – [0119]). One of ordinary skill in the art would recognize the benefits of improving interconnect bandwidth, lower latency data sharing, and improved synchronization. Claim Rejections - 35 USC § 112 07-30-02 AIA The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claim 5, 23, and 27 are rejected under 35 U.S.C. 112(b) as being indefinite. Claim 5, 23, and 27 recites “close a barrier identification (ID) associated with a multi-core barrier.” Claim 5, 23 and 27 later recites “close the barrier ID for the multi-core barrier.” Based on the recited limitations, it appears that the latter limitation is closing an already closed barrier ID. The claim is unclear as to how a barrier identification can be closed multiple times. For the purposes of compact prosecution, the latter closing limitation is interpreted to be the closing of another barrier. Appropriate clarification is required. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim (s) 1, 5, 8, 21, 23-25, and 27-28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Valerio et al. Pat. No. US 20210263785 A1 (hereafter Valerio) in view of Parle et al. Pat. No. US 20240289132 A1 (hereafter Parle) . With regard to claim 1, Valerio teaches an apparatus comprising: processing circuitry having a cluster of cores and a memory, the processing circuitry to (¶ [0225] states “computing device 1900 may include any number and type of hardware and/or software components, such as (without limitation) GPU 1914”. ¶ [0243] states “GPU 1914 is divided into slices, where each slice includes a plurality of slices”. See FIG. 3B and FIG. 20. Examiner’s Note: in FIG. 20, the slice 2000 is the cluster of cores. Sub-Slice 2005A-C are the cores. In FIG. 3B, memory 326A-D is within the GPU ): and synchronize the broadcast of the data element wherein synchronizing includes establishing a multi-core barrier for the broadcast of the data element (¶ [0248] states “sub- slice 2005 includes a barrier synchronization mechanism 2130 that enables multiple independent barriers within each thread group (or workgroup).” ¶ [0249] states “naming barriers enables a creation of multiple independent buffers that have their own barrier, which allows a maximum separation of signal and wait per named barrier. To implement named barriers, barrier synchronization mechanism 2130 receives a global name and maps the global name to a name that is local (or local name) to a sub-slice 2005 that is to be used as a named barrier”). Although Valerio teaches the synchronization of threads using a gateway, Valerio does not explicitly teach the broadcast of a data between multiple cores and the synchronization of a broadcast between multiple cores. However, in an analogous art, Parle teaches initiate broadcasting of a data element from a producer core to one or more consumer cores (¶ [0053] states “SM 204 generates a multicast request packet 224. More specifically, a thread in the CTA executing on SM 204 generates the multicast request packet 224. The SM 204 may be referred to as the “multicast source SM” or “multicast requesting SM” because the thread that generates the multicast request packet is on SM 204”. ¶ [0054] states “The thread that generates the multicast request packet 224, may be referred to as the “leader thread”. ¶ [0056] states “The multicast request packet 224 is transmitted on the request crossbar 208 to the L2 Request Coalescer (LRC) 212.” ¶ [0059] states “An LRC multicast response packet 230 that comprises the requested data received from the L2s slice 220 and information regarding the multiple receivers for the requested data is generated”. ¶ [0060] states “the result data carried in packet 230 is duplicated to two packets 232 and 234 for receiving SMs 204 and 206 as identified in the list of receivers, respectively, at a separation point which is a point in the crossbar at which the common path from an input port to the receiver crossbar 210 separates to a first path to SM 204 and a second path to SM 206”. ¶ [0062] states “a synchronization technique may be utilized by the sender SM 204 and receiver SMs in order to detect completion of the transaction or an errored transaction”. See ¶ [0053] – [0064] for further details. Examiner’s Note: the SM is the core ); and synchronize the broadcast of the data element wherein synchronizing includes establishing a multi-core barrier for the broadcast of the data element (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. The load instruction may specify the barrier address”. ¶ [0084] states “the new load operation include the global memory address to read from (e.g. source data address), destination (receiver) CTAs/SMs, destination shared memory address, and the synchronization entity” and “The synchronization entity may be represented by a barrier ID to indicate completion”. Examiner’s Note: the barrier is used by the source SM and receiving SMs, so it is a multi-core barrier ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the broadcast of a data element and synchronization of the broadcast of the data element with a multi-core barrier of Parle with the cluster of cores and synchronization of threads using a barrier of Valerio. As a result, a multicast source SM broadcasts data and the source SM and receiving SMs synchronize using a barrier. The source SM and receiving SMs are in a cluster of cores. A person having ordinary skill in the art would have motivated to make this combination “to reduce the bandwidth and power required to move the same amount of data and better scale” (¶ [0047]). Specifically, it is to improve L2 bandwidth (¶ [0040] states “L2 cache to SM bandwidth (referred to also as “L2 bandwidth”) improvements”). One of ordinary skill in the art would recognize the efficiency improvement of fetching L2 data once and then broadcasting the result as opposed to fetching L2 data multiple times for the same data. With regard to claim 5, Valerio and Parle teach the apparatus of claim 1 . Valerio additionally teaches wherein the processing circuitry is further to: … close a barrier identification (ID) associated with a multi-core barrier (¶ [0252] states “Once a named barrier is closed, gateway counters 2157 and EU 2110 notification registers for this named barrier are reset so that the next workgroup can use the barrier”. See FIG. 23. ¶ [0026] states “FIG. 23 illustrates one embodiment of pseudo code to implement a convolution kernel flow using named barriers”. ¶ [0266] states “the first named barrier is closed upon completion of execution of the first set of execution threads”. Examiner’s Note: the pseudo code in FIG. 23 includes both signal and wait instructions. This means that there are instructions for producers and consumers in FIG. 23. At the end of FIG. 23, the barriers are closed. The consumer thread closes the named barrier ); and close the barrier ID for the multi-core barrier (¶ [0252] states “Once a named barrier is closed, gateway counters 2157 and EU 2110 notification registers for this named barrier are reset so that the next workgroup can use the barrier”. See FIG. 23. ¶ [0026] states “FIG. 23 illustrates one embodiment of pseudo code to implement a convolution kernel flow using named barriers”. ¶ [0266] states “the first named barrier is closed upon completion of execution of the first set of execution threads”. Examiner’s Note: the pseudo code in FIG. 23 includes both signal and wait instructions. This means that there are instructions for producers and consumers in FIG. 23. At the end of FIG. 23, the barriers are closed. The consumer thread closes the named barrier. In light of the 112(b) rejection, the barrier that is closed in this limitation is a different barrier from the already closed barrier. Multiple different barriers can be closed ). Parle additionally teaches provide confirmation to the producer core that receipt of the data element is complete (¶ [0108] states “an Ack is generated by the destination SM and sent to the source SM ID (the source SM ID information may be included in the received response packet) to signal completion of the operation at the destination SM”); close a barrier identification (ID) associated with a multi-core barrier (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. The load instruction may specify the barrier address (e.g. as a shared memory offset)”. Examiner’s Note: the barrier is used multiple SMs, or cores ); cease the broadcast of the data element (¶ [0109] states “The multicast sender SM keeps track of all outstanding transactions in counters”. ¶ [0114] states “The sender SM keeps track of total outstanding requests, not per receiver SM”. ¶ [0061] states “Each of the one or more receivers of multicast result data sends an ack message to the requester of the multicast data”. ¶ [0108] states “an Ack is generated by the destination SM and sent to the source SM ID (the source SM ID information may be included in the received response packet) to signal completion of the operation at the destination SM”. Examiner’s Note: the sender SM keeps track of outstanding requests. When the sender SM receives an acknowledgement of a completed operation from the destination SM, the broadcast is complete and the transaction is no longer outstanding. When the broadcast is completed, it has ended ); and close the barrier ID for the multi-core barrie r (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. The load instruction may specify the barrier address (e.g. as a shared memory offset)”. Examiner’s Note: the barrier is used by multiple SMs, or cores ). With regard to claim 8, Valerio and Parle teach the apparatus of claim 1 . Valerio additionally teaches wherein the producer core and the one or more consumer cores are to communicate the data element at a shared local memory of a respective core of the cluster of cores, wherein the processing circuitry comprises graphics processing circuitry (¶ [0225] states “computing device 1900 may include any number and type of hardware and/or software components, such as (without limitation) GPU 1914”. ¶ [0243] states “GPU 1914 is divided into slices, where each slice includes a plurality of slices”. See FIG. 3B and FIG. 20. Examiner’s Note: in FIG. 20, the slice 2000 is the cluster of cores. Sub-Slice 2005A-C are the cores. In FIG. 3B, memory 326A-D is within the GPU ). Parle additionally teaches wherein the producer core and the one or more consumer cores are to communicate the data element at a shared local memory of a respective core of the cluster of cores, wherein the processing circuitry comprises graphics processing circuitry (¶ [0096], [0099] states ““Metadata” transported from source SM to destination SMs may include … Data SMEM (shared memory) Offset”. ¶ [0096] also states “Destination SMs may not have metadata that describe how the received data is to be processed (e.g., such as, received data should be written in image-to-column format, etc.), unlike source SMs”. ¶ [0104] states “The shared memory offset represents the offset, from the shared memory base address for the SM, at which the result data should be written”. ¶ [0107] states “The requested data, or the corresponding portion thereof, is written to SMEM data RAM at {SMEM Base Address, SMEM Offset}”. See FIG. 12 for Shared Memory/L1 Cache 1270. Examiner’s Note: both source and destination SMs use the shared memory offset to write received data. Receiving data at cores is communicating the data element ). With regard to claim 21, Valerio teaches a method comprising (¶ [0258] states “Examples may include subject matter such as a method”): initiating, by processing circuitry of a computing device , broadcasting of a data element from a producer core to one or more consumer cores, wherein the processing circuitry comprises a memory and a cluster of cores including the producer core and the one or more consumer cores (¶ [0225] states “computing device 1900 may include any number and type of hardware and/or software components, such as (without limitation) GPU 1914”. ¶ [0243] states “GPU 1914 is divided into slices, where each slice includes a plurality of slices”. See FIG. 3B and FIG. 20. Examiner’s Note: in FIG. 20, the slice 2000 is the cluster of cores. Sub-Slice 2005A-C are the cores. In FIG. 3B, memory 326A-D is within the GPU ); and synchronizing the broadcast of the data element, wherein synchronizing includes establishing a multi-core barrier for the broadcast of the data element (¶ [0248] states “sub-slice 2005 includes a barrier synchronization mechanism 2130 that enables multiple independent barriers within each thread group (or workgroup).” ¶ [0249] states “naming barriers enables a creation of multiple independent buffers that have their own barrier, which allows a maximum separation of signal and wait per named barrier. To implement named barriers, barrier synchronization mechanism 2130 receives a global name and maps the global name to a name that is local (or local name) to a sub-slice 2005 that is to be used as a named barrier”). Although Valerio teaches the synchronization of threads using a gateway, Valerio does not explicitly teach the broadcast of a data between multiple cores and the synchronization of a broadcast between multiple cores. However, in an analogous art, Parle teaches initiating, by processing circuitry of a computing device , broadcasting of a data element from a producer core to one or more consumer cores, wherein the processing circuitry comprises a memory and a cluster of cores including the producer core and the one or more consumer cores (¶ [0053] states “SM 204 generates a multicast request packet 224. More specifically, a thread in the CTA executing on SM 204 generates the multicast request packet 224. The SM 204 may be referred to as the “multicast source SM” or “multicast requesting SM” because the thread that generates the multicast request packet is on SM 204”. ¶ [0054] states “The thread that generates the multicast request packet 224, may be referred to as the “leader thread”. ¶ [0056] states “The multicast request packet 224 is transmitted on the request crossbar 208 to the L2 Request Coalescer (LRC) 212.” ¶ [0059] states “An LRC multicast response packet 230 that comprises the requested data received from the L2s slice 220 and information regarding the multiple receivers for the requested data is generated”. ¶ [0060] states “the result data carried in packet 230 is duplicated to two packets 232 and 234 for receiving SMs 204 and 206 as identified in the list of receivers, respectively, at a separation point which is a point in the crossbar at which the common path from an input port to the receiver crossbar 210 separates to a first path to SM 204 and a second path to SM 206”. ¶ [0062] states “a synchronization technique may be utilized by the sender SM 204 and receiver SMs in order to detect completion of the transaction or an errored transaction”. See ¶ [0053] – [0064] for further details. Examiner’s Note: the SM is the core ); and synchronizing the broadcast of the data element, wherein synchronizing includes establishing a multi-core barrier for the broadcast of the data element (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. The load instruction may specify the barrier address”. ¶ [0084] states “the new load operation include the global memory address to read from (e.g. source data address), destination (receiver) CTAs/SMs, destination shared memory address, and the synchronization entity” and “The synchronization entity may be represented by a barrier ID to indicate completion”. Examiner’s Note: the barrier is used by the source SM and receiving SMs, so it is a multi-core barrier ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the broadcast of a data element and synchronization of the broadcast of the data element with a multi-core barrier of Parle with the cluster of cores and synchronization of threads using a barrier of Valerio. As a result, a multicast source SM broadcasts data and the source SM and receiving SMs synchronize using a barrier. The source SM and receiving SMs are in a cluster of cores. A person having ordinary skill in the art would have motivated to make this combination “to reduce the bandwidth and power required to move the same amount of data and better scale” (¶ [0047]). Specifically, it is to improve L2 bandwidth (¶ [0040] states “L2 cache to SM bandwidth (referred to also as “L2 bandwidth”) improvements”). One of ordinary skill in the art would recognize the efficiency improvement of fetching L2 data once and then broadcasting the result as opposed to fetching L2 data multiple times for the same data. With regard to claim 23, Valerio and Parle teach the method of claim 21 . Valerio additionally teaches further comprising: … closing a barrier identification (ID) associated with a multi-core barrier (¶ [0252] states “Once a named barrier is closed, gateway counters 2157 and EU 2110 notification registers for this named barrier are reset so that the next workgroup can use the barrier”. See FIG. 23. ¶ [0026] states “FIG. 23 illustrates one embodiment of pseudo code to implement a convolution kernel flow using named barriers”. ¶ [0266] states “the first named barrier is closed upon completion of execution of the first set of execution threads”. Examiner’s Note: the pseudo code in FIG. 23 includes both signal and wait instructions. This means that there are instructions for producers and consumers in FIG. 23. At the end of FIG. 23, the barriers are closed. The consumer thread closes the named barrier ); and closing the barrier ID for the multi-core barrier (¶ [0252] states “Once a named barrier is closed, gateway counters 2157 and EU 2110 notification registers for this named barrier are reset so that the next workgroup can use the barrier”. See FIG. 23. ¶ [0026] states “FIG. 23 illustrates one embodiment of pseudo code to implement a convolution kernel flow using named barriers”. ¶ [0266] states “the first named barrier is closed upon completion of execution of the first set of execution threads”. Examiner’s Note: the pseudo code in FIG. 23 includes both signal and wait instructions. This means that there are instructions for producers and consumers in FIG. 23. At the end of FIG. 23, the barriers are closed. The consumer thread closes the named barrier. In light of the 112(b) rejection, the barrier that is closed in this limitation is a different barrier from the already closed barrier. Multiple different barriers can be closed ). Parle additionally teaches providing confirmation to the producer core that receipt of the data element is complete (¶ [0108] states “an Ack is generated by the destination SM and sent to the source SM ID (the source SM ID information may be included in the received response packet) to signal completion of the operation at the destination SM”); closing a barrier identification (ID) associated with a multi-core barrier (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. The load instruction may specify the barrier address (e.g. as a shared memory offset)”. Examiner’s Note: the barrier is used multiple SMs, or cores ); ceasing the broadcast of the data element (¶ [0109] states “The multicast sender SM keeps track of all outstanding transactions in counters”. ¶ [0114] states “The sender SM keeps track of total outstanding requests, not per receiver SM”. ¶ [0061] states “Each of the one or more receivers of multicast result data sends an ack message to the requester of the multicast data”. ¶ [0108] states “an Ack is generated by the destination SM and sent to the source SM ID (the source SM ID information may be included in the received response packet) to signal completion of the operation at the destination SM”. Examiner’s Note: the sender SM keeps track of outstanding requests. When the sender SM receives an acknowledgement of a completed operation from the destination SM, the broadcast is complete and the transaction is no longer outstanding. When the broadcast is completed, it has ended ); and closing the barrier ID for the multi-core barrier (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. The load instruction may specify the barrier address (e.g. as a shared memory offset)”. Examiner’s Note: the barrier is used multiple SMs, or cores ). With regard to claim 24, Valerio and Parle teach the method of claim 21 . Valerio additionally teaches wherein the producer core and the one or more consumer cores are to communicate the data element at a shared local memory of a respective core of the cluster of cores, wherein the processing circuitry comprises graphics processing circuitry (¶ [0225] states “computing device 1900 may include any number and type of hardware and/or software components, such as (without limitation) GPU 1914”. ¶ [0243] states “GPU 1914 is divided into slices, where each slice includes a plurality of slices”. See FIG. 3B and FIG. 20. Examiner’s Note: in FIG. 20, the slice 2000 is the cluster of cores. Sub-Slice 2005A-C are the cores. In FIG. 3B, memory 326A-D is within the GPU ) Parle additionally teaches wherein the producer core and the one or more consumer cores are to communicate the data element at a shared local memory of a respective core of the cluster of cores, wherein the processing circuitry comprises graphics processing circuitry (¶ [0096], [0099] states ““Metadata” transported from source SM to destination SMs may include … Data SMEM (shared memory) Offset”. ¶ [0096] also states “Destination SMs may not have metadata that describe how the received data is to be processed (e.g., such as, received data should be written in image-to-column format, etc.), unlike source SMs”. ¶ [0104] states “The shared memory offset represents the offset, from the shared memory base address for the SM, at which the result data should be written”. ¶ [0107] states “The requested data, or the corresponding portion thereof, is written to SMEM data RAM at {SMEM Base Address, SMEM Offset}”. See FIG. 12 for Shared Memory/L1 Cache 1270. Examiner’s Note: both source and destination SMs use the shared memory offset to write received data. Receiving data at cores is communicating the data element ). With regard to claim 25, Valerio teaches at least one computer-readable medium having stored thereon instructions which, when executed, cause a computing device to perform operations comprising (¶ [0163] states “One or more aspects of at least one embodiment may be implemented by representative code stored on a machine-readable medium which represents and/or defines logic within an integrated circuit such as a processor. For example, the machine-readable medium may include instructions which represent various logic within the processor”): initiating, by processing circuitry of the computing device , broadcasting of a data element from a producer core to one or more consumer cores, wherein the processing circuitry comprises a memory and a cluster of cores including the producer core and the one or more consumer cores (¶ [0225] states “computing device 1900 may include any number and type of hardware and/or software components, such as (without limitation) GPU 1914”. ¶ [0243] states “GPU 1914 is divided into slices, where each slice includes a plurality of slices”. See FIG. 3B and FIG. 20. Examiner’s Note: in FIG. 20, the slice 2000 is the cluster of cores. Sub-Slice 2005A-C are the cores. In FIG. 3B, memory 326A-D is within the GPU ); and synchronizing the broadcast of the data element, wherein synchronizing includes establishing a multi-core barrier for the broadcast of the data element (¶ [0248] states “sub-slice 2005 includes a barrier synchronization mechanism 2130 that enables multiple independent barriers within each thread group (or workgroup).” ¶ [0249] states “naming barriers enables a creation of multiple independent buffers that have their own barrier, which allows a maximum separation of signal and wait per named barrier. To implement named barriers, barrier synchronization mechanism 2130 receives a global name and maps the global name to a name that is local (or local name) to a sub-slice 2005 that is to be used as a named barrier”). Although Valerio teaches the synchronization of threads using a gateway, Valerio does not explicitly teach the broadcast of a data between multiple cores and the synchronization of a broadcast between multiple cores. However, in an analogous art, Parle teaches initiating, by processing circuitry of the computing device, broadcasting of a data element from a producer core to one or more consumer cores, wherein the processing circuitry comprises a memory and a cluster of cores including the producer core and the one or more consumer cores (¶ [0053] states “SM 204 generates a multicast request packet 224. More specifically, a thread in the CTA executing on SM 204 generates the multicast request packet 224. The SM 204 may be referred to as the “multicast source SM” or “multicast requesting SM” because the thread that generates the multicast request packet is on SM 204”. ¶ [0054] states “The thread that generates the multicast request packet 224, may be referred to as the “leader thread”. ¶ [0056] states “The multicast request packet 224 is transmitted on the request crossbar 208 to the L2 Request Coalescer (LRC) 212.” ¶ [0059] states “An LRC multicast response packet 230 that comprises the requested data received from the L2s slice 220 and information regarding the multiple receivers for the requested data is generated”. ¶ [0060] states “the result data carried in packet 230 is duplicated to two packets 232 and 234 for receiving SMs 204 and 206 as identified in the list of receivers, respectively, at a separation point which is a point in the crossbar at which the common path from an input port to the receiver crossbar 210 separates to a first path to SM 204 and a second path to SM 206”. ¶ [0062] states “a synchronization technique may be utilized by the sender SM 204 and receiver SMs in order to detect completion of the transaction or an errored transaction”. See ¶ [0053] – [0064] for further details. Examiner’s Note: the SM is the core ); and synchronizing the broadcast of the data element, wherein synchronizing includes establishing a multi-core barrier for the broadcast of the data element (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. The load instruction may specify the barrier address”. ¶ [0084] states “the new load operation include the global memory address to read from (e.g. source data address), destination (receiver) CTAs/SMs, destination shared memory address, and the synchronization entity” and “The synchronization entity may be represented by a barrier ID to indicate completion”. Examiner’s Note: the barrier is used by the source SM and receiving SMs, so it is a multi-core barrier ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the broadcast of a data element and synchronization of the broadcast of the data element with a multi-core barrier of Parle with the cluster of cores and synchronization of threads using a barrier of Valerio. As a result, a multicast source SM broadcasts data and the source SM and receiving SMs synchronize using a barrier. The source SM and receiving SMs are in a cluster of cores. A person having ordinary skill in the art would have motivated to make this combination “to reduce the bandwidth and power required to move the same amount of data and better scale” (¶ [0047]). Specifically, it is to improve L2 bandwidth (¶ [0040] states “L2 cache to SM bandwidth (referred to also as “L2 bandwidth”). With regard to claim 27, Valerio and Parle teach the computer-readable medium of claim 25 . Valerio additionally teaches wherein the operations further comprise: … closing a barrier identification (ID) associated with a multi-core barrier (¶ [0252] states “Once a named barrier is closed, gateway counters 2157 and EU 2110 notification registers for this named barrier are reset so that the next workgroup can use the barrier”. See FIG. 23. ¶ [0026] states “FIG. 23 illustrates one embodiment of pseudo code to implement a convolution kernel flow using named barriers”. ¶ [0266] states “the first named barrier is closed upon completion of execution of the first set of execution threads”. Examiner’s Note: the pseudo code in FIG. 23 includes both signal and wait instructions. This means that there are instructions for producers and consumers in FIG. 23. At the end of FIG. 23, the barriers are closed. The consumer thread closes the named barrier ); and closing the barrier ID for the multi-core barrier (¶ [0252] states “Once a named barrier is closed, gateway counters 2157 and EU 2110 notification registers for this named barrier are reset so that the next workgroup can use the barrier”. See FIG. 23. ¶ [0026] states “FIG. 23 illustrates one embodiment of pseudo code to implement a convolution kernel flow using named barriers”. ¶ [0266] states “the first named barrier is closed upon completion of execution of the first set of execution threads”. Examiner’s Note: the pseudo code in FIG. 23 includes both signal and wait instructions. This means that there are instructions for producers and consumers in FIG. 23. At the end of FIG. 23, the barriers are closed. The consumer thread closes the named barrier. In light of the 112(b) rejection, the barrier that is closed in this limitation is a different barrier from the already closed barrier. Multiple different barriers can be closed ). Parle additionally teaches providing confirmation to the producer core that receipt of the data element is complete (¶ [0108] states “an Ack is generated by the destination SM and sent to the source SM ID (the source SM ID information may be included in the received response packet) to signal completion of the operation at the destination SM”); closing a barrier identification (ID) associated with a multi-core barrier (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. The load instruction may specify the barrier address (e.g. as a shared memory offset)”. Examiner’s Note: the barrier is used multiple SMs, or cores ); ceasing the broadcast of the data element (¶ [0109] states “The multicast sender SM keeps track of all outstanding transactions in counters”. ¶ [0114] states “The sender SM keeps track of total outstanding requests, not per receiver SM”. ¶ [0061] states “Each of the one or more receivers of multicast result data sends an ack message to the requester of the multicast data”. ¶ [0108] states “an Ack is generated by the destination SM and sent to the source SM ID (the source SM ID information may be included in the received response packet) to signal completion of the operation at the destination SM”. Examiner’s Note: the sender SM keeps track of outstanding requests. When the sender SM receives an acknowledgement of a completed operation from the destination SM, the broadcast is complete and the transaction is no longer outstanding. When the broadcast is completed, it has ended ); and closing the barrier ID for the multi-core barrier (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. The load instruction may specify the barrier address (e.g. as a shared memory offset)”. Examiner’s Note: the barrier is used multiple SMs, or cores ). With regard to claim 28, Valerio and Parle teach the computer-readable medium of claim 25 . Valerio additionally teaches wherein the producer core and the one or more consumer cores are to communicate the data element at a shared local memory of a respective core of the cluster of cores, wherein the processing circuitry comprises graphics processing circuitry (¶ [0225] states “computing device 1900 may include any number and type of hardware and/or software components, such as (without limitation) GPU 1914”. ¶ [0243] states “GPU 1914 is divided into slices, where each slice includes a plurality of slices”. See FIG. 3B and FIG. 20. Examiner’s Note: in FIG. 20, the slice 2000 is the cluster of cores. Sub-Slice 2005A-C are the cores. In FIG. 3B, memory 326A-D is within the GPU ). Parle additionally teaches wherein the producer core and the one or more consumer cores are to communicate the data element at a shared local memory of a respective core of the cluster of cores, wherein the processing circuitry comprises graphics processing circuitry (¶ [0096], [0099] states ““Metadata” transported from source SM to destination SMs may include … Data SMEM (shared memory) Offset”. ¶ [0096] also states “Destination SMs may not have metadata that describe how the received data is to be processed (e.g., such as, received data should be written in image-to-column format, etc.), unlike source SMs”. ¶ [0104] states “The shared memory offset represents the offset, from the shared memory base address for the SM, at which the result data should be written”. ¶ [0107] states “The requested data, or the corresponding portion thereof, is written to SMEM data RAM at {SMEM Base Address, SMEM Offset}”. See FIG. 12 for Shared Memory/L1 Cache 1270. Examiner’s Note: both source and destination SMs use the shared memory offset to write received data. Receiving data at cores is communicating the data element ) . 07-21-aia AIA Claim (s) 2, 22, and 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Valerio in view of Parle and further in view of Jiang et al. Pat. No. US 20210334127 A1 (hereafter Jiang) . With regard to claim 2, Valerio and Parle teach the apparatus of claim 1 . Valerio additionally teaches wherein the processing circuitry is further to generate a producer broadcast instruction associated with the multi-core barrier (¶ [0250] states “producer and consumer threads use the same named barrier to signal to (or wait for) wait for each other. In one embodiment, a producer thread first signals the availability of a resource using the named barrier”. Examiner’s Note: the producer signaling the barrier is the producer broadcast instruction ); and generate a consumer broadcast instruction associated with the one or more consumer cores, wherein the consumer broadcast instruction includes a count of local consumer threads of a consumer core to receive the data element or a total count of consumer threads to receive the data element (¶ [0250] states “producer and consumer threads use the same named barrier to signal to (or wait for) wait for each other … the consumer thread waits for the signal from producer”. Examiner’s Note: the consumer waiting on the barrier is the consumer broadcast instruction ); Parle additionally teaches wherein the processing circuitry is further to generate a producer broadcast instruction associated with the multi-core barrier (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. Examiner’s Note: there are multiple SMs, so the barrier is a multi-core barrier ); and generate a consumer broadcast instruction associated with the one or more consumer cores , wherein the consumer broadcast instruction includes a count of local consumer threads of a consumer core to receive the data element or a total count of consumer threads to receive the data element (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. Examiner’s Note: there are multiple SMs, or cores, that have threads that can wait. The receiving SMs wait on the barrier by calling the wait instruction ). Valerio and Parle do not explicitly teach the consumer broadcast message including a count of local threads and a total count of consumer threads to receive the data element. However, in an analogous art, Jiang teaches and generate a consumer broadcast instruction associated with the one or more consumer cores, wherein the consumer broadcast instruction includes a count of local consumer threads of a consumer core to receive the data element or a total count of consumer threads to receive the data element (¶ [0132] states “Once all threads have sent the barrier instruction, a write-back message is broadcast to all threads to indicate that the barrier operation is complete for all requesting threads”. ¶ [0134] states “In one embodiment, for each barrier identifier, a barrier counter for the identifier and reduction state data can be stored within the reduction state registers. In one embodiment the registers are configured to support up to an 8-bit barrier counter to support up to 256 threads in a thread group”. See TABLE-US-00003 which includes a field called “barrier count”. ¶ [0170] states “enable synchronization between the multiple threads via a merged write, barrier, and read operation”. Examiner’s Note: the barrier count corresponds to the number of local threads to receive data and/or to the total number of consumer threads to receive the element ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine barrier message payload including a barrier counter of Jiang with the producer/source SM and consumer/receiving SM signaling or waiting at a multi-core barrier of Valerio and Parle. As a result, the barrier message sent to the barrier would include multiple fields of data such as types of count. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of reducing I/O and improving performance (¶ [0115] states “The write and read operation of the reduce phase can introduce a large amount of I/O into the processing operation, which can significantly reduce the performance of the reduce operation. To resolve this issue, embodiments described herein provide a system and method to eliminate the read and write operation in the reduce phase by merging the read and write operations into the barrier function”). With regard to claim 22, Valerio and Parle teach the method of claim 21 . Valerio additionally teaches further comprising: generating a producer broadcast instruction associated with the multi-core barrier (¶ [0250] states “producer and consumer threads use the same named barrier to signal to (or wait for) wait for each other. In one embodiment, a producer thread first signals the availability of a resource using the named barrier”. Examiner’s Note: the producer signaling the barrier is the producer broadcast instruction ); and generating a consumer broadcast instruction associated with the one or more consumer cores, wherein the consumer broadcast instruction includes a count of local consumer threads of a consumer core to receive the data element or a total count of consumer threads to receive the data element (¶ [0250] states “producer and consumer threads use the same named barrier to signal to (or wait for) wait for each other … the consumer thread waits for the signal from producer”. Examiner’s Note: the consumer waiting on the barrier is the consumer broadcast instruction ). Parle additionally teaches further comprising: generating a producer broadcast instruction associated with the multi-core barrier (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. Examiner’s Note: there are multiple SMs, so the barrier is a multi-core barrier ). and generating a consumer broadcast instruction associated with the one or more consumer cores , wherein the consumer broadcast instruction includes a count of local consumer threads of a consumer core to receive the data element or a total count of consumer threads to receive the data element (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. Examiner’s Note: there are multiple SMs, or cores, that have threads that can wait. The receiving SMs wait on the barrier by calling the wait instruction ). Valerio and Parle do not explicitly teach the consumer broadcast message including a count of local threads and a total count of consumer threads to receive the data element. However, in an analogous art, Jiang teaches and generating a consumer broadcast instruction associated with the one or more consumer cores, wherein the consumer broadcast instruction includes a count of local consumer threads of a consumer core to receive the data element or a total count of consumer threads to receive the data element (¶ [0132] states “Once all threads have sent the barrier instruction, a write-back message is broadcast to all threads to indicate that the barrier operation is complete for all requesting threads”. ¶ [0134] states “In one embodiment, for each barrier identifier, a barrier counter for the identifier and reduction state data can be stored within the reduction state registers. In one embodiment the registers are configured to support up to an 8-bit barrier counter to support up to 256 threads in a thread group”. See TABLE-US-00003 which includes a field called “barrier count”. ¶ [0170] states “enable synchronization between the multiple threads via a merged write, barrier, and read operation”. Examiner’s Note: the barrier count corresponds to the number of local threads to receive data and/or to the total number of consumer threads to receive the element ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine barrier message payload including a barrier counter of Jiang with the producer/source SM and consumer/receiving SM signaling or waiting at a multi-core barrier of Valerio and Parle. As a result, the barrier message sent to the barrier would include multiple fields of data such as types of count. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of reducing I/O and improving performance (¶ [0115] states “The write and read operation of the reduce phase can introduce a large amount of I/O into the processing operation, which can significantly reduce the performance of the reduce operation. To resolve this issue, embodiments described herein provide a system and method to eliminate the read and write operation in the reduce phase by merging the read and write operations into the barrier function”). With regard to claim 26, Valerio and Parle teach the computer-readable medium of claim 25 . Valerio additionally teaches wherein the operations further comprise: generating a producer broadcast instruction associated with the multi-core barrier (¶ [0250] states “producer and consumer threads use the same named barrier to signal to (or wait for) wait for each other. In one embodiment, a producer thread first signals the availability of a resource using the named barrier”. Examiner’s Note: the producer signaling the barrier is the producer broadcast instruction ); and generating a consumer broadcast instruction associated with the one or more consumer cores, wherein the consumer broadcast instruction includes a count of local consumer threads of a consumer core to receive the data element or a total count of consumer threads to receive the data element (¶ [0250] states “producer and consumer threads use the same named barrier to signal to (or wait for) wait for each other … the consumer thread waits for the signal from producer”. Examiner’s Note: the consumer waiting on the barrier is the consumer broadcast instruction ). Parle additionally teaches wherein the operations further comprise: generating a producer broadcast instruction associated with the multi-core barrier (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. Examiner’s Note: there are multiple SMs, so the barrier is a multi-core barrier ); and generating a consumer broadcast instruction associated with the one or more consumer cores , wherein the consumer broadcast instruction includes a count of local consumer threads of a consumer core to receive the data element or a total count of consumer threads to receive the data element (¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. Examiner’s Note: there are multiple SMs, or cores, that have threads that can wait. The receiving SMs wait on the barrier by calling the wait instruction ). Valerio and Parle do not explicitly teach the consumer broadcast message including a count of local threads and a total count of consumer threads to receive the data element. However, in an analogous art, Jiang teaches and generating a consumer broadcast instruction associated with the one or more consumer cores, wherein the consumer broadcast instruction includes a count of local consumer threads of a consumer core to receive the data element or a total count of consumer threads to receive the data element (¶ [0132] states “Once all threads have sent the barrier instruction, a write-back message is broadcast to all threads to indicate that the barrier operation is complete for all requesting threads”. ¶ [0134] states “In one embodiment, for each barrier identifier, a barrier counter for the identifier and reduction state data can be stored within the reduction state registers. In one embodiment the registers are configured to support up to an 8-bit barrier counter to support up to 256 threads in a thread group”. See TABLE-US-00003 which includes a field called “barrier count”. ¶ [0170] states “enable synchronization between the multiple threads via a merged write, barrier, and read operation”. Examiner’s Note: the barrier count corresponds to the number of local threads to receive data and/or to the total number of consumer threads to receive the element ). It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine barrier message payload including a barrier counter of Jiang with the producer/source SM and consumer/receiving SM signaling or waiting at a multi-core barrier of Valerio and Parle. As a result, the barrier message sent to the barrier would include multiple fields of data such as types of count. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of reducing I/O and improving performance (¶ [0115] states “The write and read operation of the reduce phase can introduce a large amount of I/O into the processing operation, which can significantly reduce the performance of the reduce operation. To resolve this issue, embodiments described herein provide a system and method to eliminate the read and write operation in the reduce phase by merging the read and write operations into the barrier function”) . Response to Arguments 07-37 AIA Applicant's arguments filed 04/29/2026 have been fully considered but they are not persuasive. With regard to the 35 U.S.C. § 103 rejection of claims 1-2, 6, and 8, applicant argues that “the tracking structure 222 is within the LRC at the L2 cache level, not within gateway circuitry of producer and consumer cores.” MPEP § 2144.04(VI)(B) states “In re Harza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960) (Claims at issue were directed to a water-tight masonry structure wherein a water seal of flexible material fills the joints which form between adjacent pours of concrete. The claimed water seal has a "web" which lies in the joint, and a plurality of "ribs" projecting outwardly from each side of the web into one of the adjacent concrete slabs. The prior art disclosed a flexible water stop for preventing passage of water between masses of concrete in the shape of a plus sign (+). Although the reference did not disclose a plurality of ribs, the court held that mere duplication of parts has no patentable significance unless a new and unexpected result is produced.).” 07-37-08 In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., a tracking structure within the gateway circuitry of producer and consumers cores) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns , 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). However, for the sake of argument, even if the claims were to require that the tracking structure be within the gateway circuitry, the combination of Valerio and Parle would teach the limitation. Valerio teaches a gateway in each sub-slice, or core (¶ [0244]). Valerio additionally teaches that each gateway has registers and counters (FIG. 21 and ¶ [0250]). Parle teaches the LRC that stores the tracking structure which further stores information for multicasting (¶ [0057]). In light of MPEP § 2144.04(VI)(B), the tracking structure 222 of Parle could be duplicated to be within each gateway circuitry of producer and consumer nodes in a similar way to the duplication of registers and counters in gateways of slices taught by Valerio. As a result, the source SM multicasts to receiving SMs (Parle ¶ [0069] teaches “The GPU hardware/system also provides efficient mechanisms by which the concurrently-executing CTAs can communicate with one another”) and maintains the tracking structure within its gateway. Examiner maintains 35 U.S.C. § 103 of claims 1-2, 6, and 8. Applicant additionally argues that Parle’s synchronization is fundamentally different from “synchronizing that includes establishing a multi-core barrier” because Parle teaches that the sender SM maintains counters and outstanding requests. 07-37-13 AIA Applicant is reminded that when using arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller , 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Examiner finds applicant’s arguments unpersuasive. The quotes related to outstanding transaction counters cited by the applicant are implementation details that do not entirely teach the claim limitation. However, the combination of Valerio and Parle do fully teach the claim limitations. As explained in the 35 U.S.C. § 103 rejection of claim 1, Parle ¶ [0116] states “In the programming model for the barriers, the source SM issues a load for a defined number of bytes, and the receiving SMs each wait on a barrier for that number of bytes to be received. The load instruction may specify the barrier address.” Parle clearly teaches that the receiving SMs wait on a barrier for a number of bytes from the source SM to be received. When the receiving SMs are waiting on the barrier, they are synchronized. It is also interpreted that the source SM may also be waiting on the barrier because the source SM can also be a receiving SM (see ¶ [0053] – [0054] and [0060]). Additionally, in the combination of Parle and Valerio, Valerio teaches that synchronization between producer and consumers may require that the producer (the source SM/thread in this case) to wait on the barrier when waiting for all consumers to arrive at the barrier (¶ [0250] states “producer and consumer threads use the same named barrier to signal to (or wait for) wait for each other … the consumer thread waits for the signal from producer”). The SMs are interpreted to be cores. Therefore, Parle teaches the barrier that the source SM and receiving SMs use is a multi-core barrier. The source SM and receiving SM are waiting on the barrier so that they can be synchronized. In conclusion, the combination of Valerio and Parle are not fundamentally different from “synchronizing that includes establishing a multi-core barrier.” Examiner maintains 35 U.S.C. § 103 rejection of claim 1 and dependent claims 2, 5, and 8. Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20200402198 A1 teaches SHARED LOCAL MEMORY READ MERGE AND MULTICAST RETURN US 20230370304 A1 teaches PROGRAMMABLE MULTICAST PROTOCOL FOR RING-TOPOLOGY BASED ARTIFICIAL INTELLIGENCE SYSTEMS US 20230315655 A1 teaches FAST DATA SYNCHRONIZATION IN PROCESSORS AND MEMORY US 20230289189 A1 teaches Distributed Shared Memory US 20230289242 A1 teaches HARDWARE ACCELERATED SYNCHRONIZATION WITH ASYNCHRONOUS TRANSACTION SUPPORT US 20230229599 A1 teaches MULTICAST AND REFLECTIVE MEMORY BEHAVIOR FOR MEMORY MODEL CONSISTENCY THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to PETER L YUAN whose telephone number is (571)272-5737. The examiner can normally be reached Mon-Fri 7:30am-5pm. 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, Bradley Teets can be reached at 571-272-3338. 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. /PETER LI YUAN/Examiner, Art Unit 2197 /BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197 Application/Control Number: 18/148,993 Page 2 Art Unit: 2197 Application/Control Number: 18/148,993 Page 3 Art Unit: 2197 Application/Control Number: 18/148,993 Page 4 Art Unit: 2197 Application/Control Number: 18/148,993 Page 5 Art Unit: 2197 Application/Control Number: 18/148,993 Page 6 Art Unit: 2197 Application/Control Number: 18/148,993 Page 7 Art Unit: 2197 Application/Control Number: 18/148,993 Page 8 Art Unit: 2197 Application/Control Number: 18/148,993 Page 9 Art Unit: 2197 Application/Control Number: 18/148,993 Page 10 Art Unit: 2197 Application/Control Number: 18/148,993 Page 11 Art Unit: 2197 Application/Control Number: 18/148,993 Page 12 Art Unit: 2197 Application/Control Number: 18/148,993 Page 13 Art Unit: 2197 Application/Control Number: 18/148,993 Page 14 Art Unit: 2197 Application/Control Number: 18/148,993 Page 15 Art Unit: 2197 Application/Control Number: 18/148,993 Page 16 Art Unit: 2197 Application/Control Number: 18/148,993 Page 17 Art Unit: 2197 Application/Control Number: 18/148,993 Page 18 Art Unit: 2197 Application/Control Number: 18/148,993 Page 19 Art Unit: 2197 Application/Control Number: 18/148,993 Page 20 Art Unit: 2197 Application/Control Number: 18/148,993 Page 21 Art Unit: 2197 Application/Control Number: 18/148,993 Page 22 Art Unit: 2197 Application/Control Number: 18/148,993 Page 23 Art Unit: 2197 Application/Control Number: 18/148,993 Page 24 Art Unit: 2197 Application/Control Number: 18/148,993 Page 25 Art Unit: 2197 Application/Control Number: 18/148,993 Page 26 Art Unit: 2197 Application/Control Number: 18/148,993 Page 27 Art Unit: 2197 Application/Control Number: 18/148,993 Page 28 Art Unit: 2197 Application/Control Number: 18/148,993 Page 29 Art Unit: 2197 Application/Control Number: 18/148,993 Page 30 Art Unit: 2197 Application/Control Number: 18/148,993 Page 31 Art Unit: 2197 Application/Control Number: 18/148,993 Page 32 Art Unit: 2197 Application/Control Number: 18/148,993 Page 33 Art Unit: 2197 Application/Control Number: 18/148,993 Page 34 Art Unit: 2197 Application/Control Number: 18/148,993 Page 35 Art Unit: 2197 Application/Control Number: 18/148,993 Page 36 Art Unit: 2197 Application/Control Number: 18/148,993 Page 37 Art Unit: 2197
Prosecution Insights