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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for 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 cited in their 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.
Response to Amendment
The Amendments filed 9/09/2026 have been entered. Claims 1-20 remain pending in the present Office Action.
The Amendments to the Drawings and Specification have been fully considered and are sufficient to overcome the Objections presented in the previous Office Action.
The Amendments to the Claims have been fully considered and are sufficient to overcome the Objections and Rejections under 35 U.S.C. 112(b) presented in the previous Office Action.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory 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-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of copending Application No. 18/745,851 (reference application).
Although the claims at issue are not identical (see Table 1 below) they are not patentably distinct from each other because it would have been obvious to one of ordinary skill in the art to utilize an “acceleration processor unit (APU)” as a type of processor in order to realize the APU, system and method disclosed in the claims of the instant application in view of the one or more processors, system and method disclosed in the claims of the reference application, respectively.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Table 1: Claim comparison of the instant application with reference application 18/745,851
Claim
18/754,000 (instant application)
18/745,851
1
An acceleration processor unit (APU) comprising:
one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores;
one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs);
an L2 cache;
one or more fabric interconnects;
a memory controller; and
one or more input/output (I/O) bus interfaces;
at least one comprising a peripheral component interconnect express (PCIe) interface;
wherein:
the APU is to, in response to a call to an application programming interface (API), add an external semaphore signal node to a graph, wherein the call to the API is to include:
a graph identifier parameter;
a node identifier parameter;
a dependencies parameter;
a number of dependencies parameter;
a node parameters parameter;
wherein the external semaphore signal node, when performed, is to update a semaphore used by another API.
One or more processors comprising:
one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores;
one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs);
an L2 cache;
one or more fabric interconnects;
a memory controller; and
one or more input/output (I/O) bus interfaces;
at least one comprising a peripheral component interconnect express (PCIe) interface;
wherein:
the one or more processors are to, in response to a call to an application program interface (API), add an external semaphore signal node to a graph, wherein the API call is to include:
a graph identifier parameter;
a node identifier parameter;
a dependencies parameter;
a number of dependencies parameter;
a node parameters parameter; and
wherein the external semaphore signal node, if performed, is to update a semaphore used by another API.
2
The APU of claim 1, wherein the APU is to update parameters of the external semaphore signal node in an executable graph instantiated from the graph.
The one or more processors of claim 1, wherein the one or more processors are further to update parameters of the external semaphore signal node in an executable graph instantiated from the graph.
3
The APU of claim 1, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore signal node.
The one or more processors of claim 1, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore signal node.
4
The APU of claim 1, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore signal node in memory.
The one or more processors of claim 1, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore signal node in memory.
5
The APU of claim 1, wherein the dependencies parameter is to specify dependencies of the external semaphore signal node.
The one or more processors of claim 1, wherein the dependencies parameter is to specify dependencies of the external semaphore signal node.
6
The APU of claim 1, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore signal node.
The one or more processors of claim 1, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore signal node.
7
The APU of claim 1, wherein the node parameters parameter is to specify parameters for the external semaphore signal node.
The one or more processors of claim 1, wherein the node parameters parameter is to specify parameters for the external semaphore signal node.
8
A system comprising: memory; and an acceleration processor unit (APU) comprising: one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); an L2 cache; one or more fabric interconnects; a memory controller; and one or more input/output (I/O) bus interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface; wherein: the APU is to, in response to a call to an application programming interface (API), add an external semaphore signal node to a graph, wherein the call to the API is to include: a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; a node parameters parameter; and wherein the external semaphore signal node, when performed, is to update a semaphore used by another API.
A system comprising: memory; and one or more processors comprising: one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); an L2 cache; one or more fabric interconnects; a memory controller; and one or more input/output (I/O) bus interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface; wherein: the one or more processors are to, in response to a call to an application program interface (API), add an external semaphore signal node to a graph, wherein the API call is to include: a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; a node parameters parameter; and wherein the external semaphore signal node, if performed, is to update a semaphore used by another API.
9
The system of claim 8, wherein the call to the API is to create the external semaphore signal node.
The system of claim 8, wherein the API call is further to create the external semaphore signal node.
10
The system of claim 8, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore signal node.
The system of claim 8, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore signal node.
11
The system of claim 8, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore signal node in memory.
The system of claim 8, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore signal node in memory.
12
The system of claim 8, wherein the dependencies parameter is to specify dependencies of the external semaphore signal node.
The system of claim 8, wherein the dependencies parameter is to specify dependencies of the external semaphore signal node.
13
The system of claim 8, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore signal node.
The system of claim 8, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore signal node.
14
The system of claim 8, wherein the node parameters parameter is to specify parameters for the external semaphore signal node.
The system of claim 8, wherein the node parameters parameter is to specify parameters for the external semaphore signal node.
15
A method comprising: in response to a call to an application programming interface (API), adding an external semaphore signal node to a graph, wherein the call is to include: a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; a node parameters parameter; and wherein the external semaphore signal node, when performed, is to update a semaphore used by another API; wherein adding the external semaphore signal node to the graph is to be performed by an acceleration processor unit (APU) comprising: one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); an L2 cache; one or more fabric interconnects; a memory controller; and one or more input/output (I/O) bus interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface.
A method comprising: in response to a call to an application program interface (API), adding an external semaphore signal node to a graph, wherein the API call is to include: a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; a node parameters parameter; and wherein the external semaphore signal node, if performed, is to update a semaphore used by another API; wherein adding the external semaphore signal node to the graph is to be performed by one or more processors comprising: one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); an L2 cache; one or more fabric interconnects; a memory controller; and one or more input/output (I/O) bus interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface.
16
The method of claim 15, wherein the call to the API is to create the external semaphore signal node.
The method of claim 15, wherein the API call is further to create the external semaphore signal node.
17
The method of claim 15, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore signal node.
The method of claim 15, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore signal node.
18
The method of claim 15, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore signal node in memory.
The method of claim 15, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore signal node in memory.
19
The method of claim 15, wherein the dependencies parameter is to specify dependencies of the external semaphore signal node.
The method of claim 15, wherein the dependencies parameter is to specify dependencies of the external semaphore signal node.
20
The method of claim 15, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore signal node.
The method of claim 15, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore signal node.
Claims 1 and 3-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-17 of U.S. Patent No. 12,608,245 B2 in view of Ashwathnarayan et al. (U.S. Pub. No. 2020/0364088), hereinafter Ashwathnarayan. The claims of the instant application and the claims of the reference patent are compared in Table 2 below, with differences between the claims in bold. Unless indicated otherwise, the claims of the instant application have been compared to the claim of the same number in the reference patent.
Regarding claims 1, 8, and 15 of the instant application, it would have been obvious to one of ordinary skill in the art to utilize an “acceleration processor unit (APU)” as a type of processor in order to realize the APU, system and method disclosed in the claims of the instant application in view of the processor, system and method disclosed in claims 1, 7 and 13 of the reference patent, respectively. Further, it would have been obvious to one of ordinary skill in the art that the “processor is to perform an application program interface (API) to add” as recited by claims 1, 7, and 13 of the reference patent is analogous to the “the APU is to, in response to a call to an application program interface (API), add” as the reference claims later recite “wherein the API call” in reference to the previously recited “perform an application program interface (API)”. An API, as is known in the art, is a library of functions which are called to perform of the functions, as is evidenced by at least Ashwathnarayan and the CUDA Runtime API cited in the section titled Claim Rejections - 35 USC § 103 below.
Further regarding claims 1, 8 and 15 of the instant application, claims 1, 7, and 13 of the reference patent teach all of the limitations except that the “input/output (I/O) interfaces” of the reference patent are “I/O bus interfaces” as recited in the instant application, and differ in a “semaphore wait node” as recited by the reference patent which, if performed, is to cause the graph to “wait” on a semaphore vs. a “semaphore signal node” are recited by the instant application, which, if performed, is to cause the graph to “update” a semaphore.
However, Ashwathnarayan teaches an “I/O bus interface” and teaches buses as a known and obvious type of interface ([0321] – “processor 2010 coupled using a bus or interface”; [0352] – “any form of bus or interface”; [0404] – “communication paths interconnecting various components in FIG. 27 may be implemented using any suitable protocols, such as PCI (Peripheral Component Interconnect) based protocols (e.g., PCI-Express), or other bus or point-to-point communication interfaces”; [0475] – “one or more interface bus(es) 3410 […] one or more Peripheral Component Interconnect buses ( e.g., PCI, PCI Express), memory busses, or other types of interface busses.”; [0477] – “platform controller hub 3430 enables peripherals to connect to memory device 3420 and processor 3402 via a high-speed I/O bus”; [0542] – “I/O unit 4006 implements a Peripheral Component Interconnect Express ("PCie") interface for communications over a PCie bus.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that the “input/output (I/O) interfaces”, of which at least one is a PCIe interface, as recited by the claims of the reference patent could be “input/output (I/O) bus interfaces” as recited by the claims of the instant application, as buses are a type of I/O interface known in the art, and specifically the PCIe interface protocol as recited by the reference claims uses a bus as evidenced by the above cited portions of Ashwathnarayan. Further, bus interfaces such as PCIe buses may be high-speed I/O interfaces, thus, using a high-speed bus could enable fast communications and data transfer via the interfaces (Ashwathnarayan: [0316], [0477] and [0560]).
Ashwathnarayan further teaches a semaphore wait operation which, if performed, is to cause code to wait on a semaphore, and a semaphore signal operation which, if performed, is to cause code to update a semaphore as obvious variants ([0061] – “a parallel computing platform and application programming interface model stream can wait and signal synchronization object by treating it as a type of external semaphore”; [0063] – “parallel computing platform and application programming interface model interops supports externally allocated semaphore, such as Vulkan semaphores”; [0115] – “wait and signal operations occur in pair for Vulkan semaphores”; [0116] – “WaitExternalSemaphoresAsync() is a supported API. In at least one embodiment, WaitExternalSemaphoresAsync() enqueues a wait operation on a set of externally allocated semaphore objects in a specified stream.”; [0119]-[0120] – “waiting on semaphore waits until semaphore reaches a signaled state. In at least one embodiment, a semaphore reaches a singled state and is then reset to an unsigned state. In at least one embodiment, for every signal operation, there is exactly one corresponding wait operation. […] waiting on a semaphore waits until the value of semaphore is greater than or equal to _EXTERNAL_SEMAPHORE_PARAMS::params::fence::value.”; [0128] – “SignalExternalSemaphoresAsync() is a supported API. In at least one embodiment, SignalExternalSemaphoresAsync() enqueues a signal operation on a set of externally allocated semaphore objects in a specified stream.”; [0132]-[0133] – “signaling semaphore sets it to a signaled state […] semaphore is set to value specified in _EXTERNAL_SEMAPHORE_PARAMS::params::fence::value”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that the “semaphore signal node” which, if performed, causes the graph to “update” a semaphore claimed in the instant application is an obvious variant of the “semaphore wait node” which, if performed, causes the graph to “wait” on a semaphore claimed in the reference patent. Synchronization interoperability, such as waiting on and signaling (i.e., updating by setting to a signaled state) external semaphores, wherein waits and signals always occur in pairs for certain types of external semaphores, e.g., Vulkan semaphores (Ashwathnarayan: [0115]) allows applications to have a finer grain control of efficiently describing dependencies between tasks that spans across hardware and software boundaries (ASHWATHNARAYAN: [0062] and [0063]).
Claims 3-7, 9-14, and 16-20 of the instant application recite additional limitations that are substantially the same or identical to limitations recited in claims 1-17 of the reference patent, as indicated in Table 2.
Specifically, the limitations recited in 3-7, 9-14, and 16-20 of the instant application differ from the limitations recited in claims 1-17 of the reference patent only in ways which amount to the “semaphore signal node” as recited in the instant applications vs. the “semaphore wait node” as recited in the reference patent. As presented above with respect to claims 1, 8, and 15, a semaphore signal and semaphore wait are obvious variants as taught by Ashwathnarayan.
Claim 2 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,608,245 B2 in view of Ashwathnarayan et al. (U.S. Pub. No. 2020/0364088), hereinafter Ashwathnarayan, and further in view of CUDA C++ Programming Guide (NPL Document U on PTO-892 mailed 5/01/2026). The claims of the instant application and the claims of the reference patent are compared in Table 2 below, with differences between the claims in bold.
Regarding claim 2 of the instant application, claim 1 of the reference patent in view of Ashwathnarayan teaches all of the limitations except wherein the APU is to “update parameters of the external semaphore signal node in an executable graph instantiated from the graph”. However, CUDA C++ Programming Guide teaches processors are to “update parameters of a node in an executable graph instantiated from the graph” (Section 1.3 A Scalable Programming Model – the CUDA parallel programming model disclosed therein is designed to leverage multiple CPU and GPU cores on a processor chip; Section 3.2.6.6. CUDA Graphs – “Work submission using graphs is separated into three distinct stages: definition, instantiation, and execution. During the definition phase, a program creates a description of the operations in the graph along with the dependencies between them. Instantiation takes a snapshot of the graph template, validates it, and performs much of the setup and initialization of work with the aim of minimizing what needs to be done at launch. The resulting instance is known as an executable graph.”; Section 3.2.6.6.4. Updating Instantiated Graphs – “CUDA provides a lightweight mechanism known as “Graph Update,” which allows certain node parameters to be modified in-place without having to rebuild the entire graph. […] CUDA provides two mechanisms for updating instantiated graphs, whole graph update and individual node update. Whole graph update allows the user to supply a topologically identical cudaGraph_t object whose nodes contain updated parameters. Individual node update allows the user to explicitly update the parameters of individual nodes. Using an updated cudaGraph_t is more convenient when a large number of nodes are being updated, or when the graph topology is unknown to the caller (i.e., The graph resulted from stream capture of a library call). Using individual node update is preferred when the number of changes is small and the user has the handles to the nodes requiring updates.”).
It would have been obvious to one of ordinary skill in the art to have modified the processor which is to create an external semaphore signal node to be added to a graph as taught by the claims of the reference patent in view of Ashwathnarayan, to further update parameters of the node in an executable graph instantiated from the graph as taught by CUDA C++ Programming Guide. Updating parameters of nodes in an executable graph instantiated from a defined graph enables modification of a graph, e.g., when the graph has become out of date, and subsequent execution of a modified graph with improved performance and efficiency, as well as with reduced overhead, as re-instantiation of the graph is avoided (CUDA C++ Programming Guide: 3.2.6.6.4. Updating Instantiated Graphs).
Table 2: Claim comparison of the instant application with U.S. Patent No. 12,608,245 B2
Claim
18/754,000 (instant application)
U.S. Patent No. 12,608,245 B2
1
An acceleration processor unit (APU) comprising:
one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores;
one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs);
an L2 cache;
one or more fabric interconnects;
a memory controller; and
one or more input/output (I/O) bus interfaces;
at least one comprising a peripheral component interconnect express (PCIe) interface;
wherein:
the APU is to, in response to a call to an application programming interface (API), add an external semaphore signal node to a graph, wherein the call to the API is to include:
a graph identifier parameter;
a node identifier parameter;
a dependencies parameter;
a number of dependencies parameter;
a node parameters parameter;
wherein the external semaphore signal node, when performed, is to update a semaphore used by another API.
A processor comprising:
one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores;
one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs);
an L2 cache;
one or more fabric interconnects;
a memory controller; and
one or more input/output (I/O) interfaces;
at least one comprising a peripheral component interconnect express (PCIe) interface;
wherein:
the processor is to perform an application program interface (API) to create an external semaphore wait node to be added to a graph, wherein the API call is to include:
a graph identifier parameter;
a node identifier parameter;
a dependencies parameter;
a number of dependencies parameter; and
a node parameters parameter; and
the external semaphore wait node, if performed, is to cause the graph to wait on a semaphore used by another API.
2
The APU of claim 1, wherein the APU is to update parameters of the external semaphore signal node in an executable graph instantiated from the graph.
See claim 1
3
The APU of claim 1, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore signal node.
See claim 2: The APU of claim 1, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore wait node.
4
The APU of claim 1, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore signal node in memory.
See claim 3: The APU of claim 1, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore wait node in memory.
5
The APU of claim 1, wherein the dependencies parameter is to specify dependencies of the external semaphore signal node.
See claim 4: The APU of claim 1, wherein the dependencies parameter is to specify dependencies of the external semaphore wait node.
6
The APU of claim 1, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore signal node.
See claim 5: The APU of claim 1, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore wait node.
7
The APU of claim 1, wherein the node parameters parameter is to specify parameters for the external semaphore signal node.
See claim 6: The APU of claim 1, wherein the node parameters parameter is to specify parameters for the external semaphore wait node.
8
A system comprising: memory; and an acceleration processor unit (APU) comprising: one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); an L2 cache; one or more fabric interconnects; a memory controller; and one or more input/output (I/O) bus interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface; wherein: the APU is to, in response to a call to an application programming interface (API), add an external semaphore signal node to a graph, wherein the call to the API is to include: a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; a node parameters parameter; and wherein the external semaphore signal node, when performed, is to update a semaphore used by another API.
See claim 7: A system comprising: memory; and a processor comprising: one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); an L2 cache; one or more fabric interconnects; a memory controller; and one or more input/output (I/O) interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface; wherein: the processor is to perform an application program interface (API) to create an external semaphore wait node to be added to a graph, wherein the API call is to include: a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; and a node parameters parameter; and the external semaphore wait node, if performed, is to cause the graph to wait on a semaphore used by another API.
9
The system of claim 8, wherein the call to the API is to create the external semaphore signal node.
See claim 7: “an application program interface (API) to create an external semaphore wait node to be added to a graph, wherein the API call is to”
10
The system of claim 8, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore signal node.
See claim 8: The system of claim 7, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore wait node.
11
The system of claim 8, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore signal node in memory.
See claim 9: The system of claim 7, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore wait node in memory.
12
The system of claim 8, wherein the dependencies parameter is to specify dependencies of the external semaphore signal node.
See claim 10: The system of claim 7, wherein the dependencies parameter is to specify dependencies of the external semaphore wait node.
13
The system of claim 8, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore signal node.
See claim 11: The system of claim 7, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore wait node.
14
The system of claim 8, wherein the node parameters parameter is to specify parameters for the external semaphore signal node.
See claim 12: The system of claim 7, wherein the node parameters parameter is to specify parameters for the external semaphore wait node.
15
A method comprising: in response to a call to an application programming interface (API), adding an external semaphore signal node to a graph, wherein the call is to include:
a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; a node parameters parameter; and wherein the external semaphore signal node, when performed, is to update a semaphore used by another API; wherein adding the external semaphore signal node to the graph is to be performed by an acceleration processor unit (APU) comprising:
one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); an L2 cache; one or more fabric interconnects; a memory controller; and one or more input/output (I/O) bus interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface.
See claim 13: A method comprising: performing an application program interface (API) to create an external semaphore wait node to be added to a graph, wherein the API call is to include:
a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; and a node parameters parameter; wherein the external semaphore wait node, if performed, is to cause the graph to wait on a semaphore used by another API; and
wherein the API is to be performed by a processor comprising:
one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); an L2 cache; one or more fabric interconnects; a memory controller; and one or more input/output (I/O) interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface.
16
The method of claim 15, wherein the call to the API is to create the external semaphore signal node.
See claim 13: “an application program interface (API) to create an external semaphore wait node to be added to a graph, wherein the API call is to”
17
The method of claim 15, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore signal node.
See claim 14: The method of claim 13, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore wait node.
18
The method of claim 15, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore signal node in memory.
See claim 15: The method of claim 13, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore wait node in memory.
19
The method of claim 15, wherein the dependencies parameter is to specify dependencies of the external semaphore signal node.
See claim 16: The method of claim 13, wherein the dependencies parameter is to specify dependencies of the external semaphore wait node.
20
The method of claim 15, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore signal node.
See claim 17: The method of claim 13, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore wait node.
Claims 1 and 3-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-17 of U.S. Patent No. 12,625,744 B2 in view of Ashwathnarayan et al. (U.S. Pub. No. 2020/0364088), hereinafter Ashwathnarayan. The claims of the instant application and the claims of the reference patent are compared in Table 3 below, with differences between the claims in bold. Unless indicated otherwise, the claims of the instant application have been compared to the claim of the same number in the reference patent.
It would have been obvious to one of ordinary skill in the art to utilize an “acceleration processor unit (APU)” as a type of processor in order to realize the APU, system and method disclosed in the claims of the instant application in view of the processor, system and method disclosed the claims of the reference patent, respectively. Further, it would have been obvious to one of ordinary skill in the art that the “processor is to perform an application program interface (API) to add” as recited by claims 1, 7, and 13 of the reference patent is analogous to the “the APU is to, in response to a call to an application program interface (API), add” as the reference claims later recite “wherein the API call” in reference to the previously recited “perform an application program interface (API)”. An API, as is known in the art, is a library of functions which are called to perform of the functions, as is evidenced by at least Ashwathnarayan and the CUDA Runtime API cited in the section titled Claim Rejections - 35 USC § 103 below.
Regarding claims 1, 8, and 15 of the instant application, claims 1, 7, and 13 of the reference patent teach all of the limitations except that the “input/output (I/O) interfaces” of the reference patent are “I/O bus interfaces” as recited in the instant application, and differ in a “semaphore wait node” as recited by the reference patent which, if performed, is to cause the graph to “wait” on a semaphore vs. a “semaphore signal node” are recited by the instant application, which, if performed, is to cause the graph to “update” a semaphore.
However, Ashwathnarayan teaches an “I/O bus interface” and teaches buses as a known and obvious type of interface ([0321] – “processor 2010 coupled using a bus or interface”; [0352] – “any form of bus or interface”; [0404] – “communication paths interconnecting various components in FIG. 27 may be implemented using any suitable protocols, such as PCI (Peripheral Component Interconnect) based protocols (e.g., PCI-Express), or other bus or point-to-point communication interfaces”; [0475] – “one or more interface bus(es) 3410 […] one or more Peripheral Component Interconnect buses ( e.g., PCI, PCI Express), memory busses, or other types of interface busses.”; [0477] – “platform controller hub 3430 enables peripherals to connect to memory device 3420 and processor 3402 via a high-speed I/O bus”; [0542] – “I/O unit 4006 implements a Peripheral Component Interconnect Express ("PCie") interface for communications over a PCie bus.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that the “input/output (I/O) interfaces”, of which at least one is a PCIe interface, as recited by the claims of the reference patent could be “input/output (I/O) bus interfaces” as recited by the claims of the instant application, as buses are a type of I/O interface known in the art, and specifically the PCIe interface protocol as recited by the reference claims uses a bus as evidenced by the above cited portions of Ashwathnarayan. Further, bus interfaces such as PCIe buses may be high-speed I/O interfaces, thus, using a high-speed bus could enable fast communications and data transfer via the interfaces (Ashwathnarayan: [0316], [0477] and [0560]).
Ashwathnarayan further teaches a semaphore wait operation which, if performed, is to cause code to wait on a semaphore, and a semaphore signal operation which, if performed, is to cause code to update a semaphore as obvious variants ([0061] – “a parallel computing platform and application programming interface model stream can wait and signal synchronization object by treating it as a type of external semaphore”; [0063] – “parallel computing platform and application programming interface model interops supports externally allocated semaphore, such as Vulkan semaphores”; [0115] – “wait and signal operations occur in pair for Vulkan semaphores”; [0116] – “WaitExternalSemaphoresAsync() is a supported API. In at least one embodiment, WaitExternalSemaphoresAsync() enqueues a wait operation on a set of externally allocated semaphore objects in a specified stream.”; [0119]-[0120] – “waiting on semaphore waits until semaphore reaches a signaled state. In at least one embodiment, a semaphore reaches a singled state and is then reset to an unsigned state. In at least one embodiment, for every signal operation, there is exactly one corresponding wait operation. […] waiting on a semaphore waits until the value of semaphore is greater than or equal to _EXTERNAL_SEMAPHORE_PARAMS::params::fence::value.”; [0128] – “SignalExternalSemaphoresAsync() is a supported API. In at least one embodiment, SignalExternalSemaphoresAsync() enqueues a signal operation on a set of externally allocated semaphore objects in a specified stream.”; [0132]-[0133] – “signaling semaphore sets it to a signaled state […] semaphore is set to value specified in _EXTERNAL_SEMAPHORE_PARAMS::params::fence::value”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that the “semaphore signal node” which, when performed, causes the graph to “update” a semaphore claimed in the instant application is an obvious variant of the “semaphore wait node” which, if performed, causes the graph to “wait” on a semaphore claimed in the reference patent. Synchronization interoperability, such as waiting on and signaling external semaphores, wherein waits and signals always occur in pairs for certain types of external semaphores, e.g., Vulkan semaphores (Ashwathnarayan: [0115]) allows applications to have a finer grain control of efficiently describing dependencies between tasks that spans across hardware and software boundaries (ASHWATHNARAYAN: [0062] and [0063]).
Claims 3-7, 9-14, and 16-20 of the instant application recite additional limitations that are substantially the same or identical to limitations recited in claims 1-17 of the reference patent, as indicated in Table 3.
Specifically, the limitations recited in 3-7, 9-14, and 16-20 of the instant application differ from the limitations recited in claims 1-17 of the reference patent only in ways which amount to the “semaphore signal node” as recited in the instant applications vs. the “semaphore wait node” as recited in the reference patent. As presented above with respect to claims 1, 8, and 15, a semaphore signal and semaphore wait are obvious variants as taught by Ashwathnarayan.
Claim 2 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,625,744 B2 in view of Ashwathnarayan, and further in view of CUDA C++ Programming Guide (NPL Document U on PTO-892 mailed 5/01/2026). The claims of the instant application and the claims of the reference patent are compared in Table 2 below, with differences between the claims in bold.
Regarding claim 2 of the instant application, claim 1 of the reference patent in view of Ashwathnarayan teaches all of the limitations except wherein the APU is to “update parameters of the external semaphore signal node in an executable graph instantiated from the graph”. However, CUDA C++ Programming Guide teaches processors are to “update parameters of a node in an executable graph instantiated from the graph” (Section 1.3 A Scalable Programming Model – the CUDA parallel programming model disclosed therein is designed to leverage multiple CPU and GPU cores on a processor chip; Section 3.2.6.6. CUDA Graphs – “Work submission using graphs is separated into three distinct stages: definition, instantiation, and execution. During the definition phase, a program creates a description of the operations in the graph along with the dependencies between them. Instantiation takes a snapshot of the graph template, validates it, and performs much of the setup and initialization of work with the aim of minimizing what needs to be done at launch. The resulting instance is known as an executable graph.”; Section 3.2.6.6.4. Updating Instantiated Graphs – “CUDA provides a lightweight mechanism known as “Graph Update,” which allows certain node parameters to be modified in-place without having to rebuild the entire graph. […] CUDA provides two mechanisms for updating instantiated graphs, whole graph update and individual node update. Whole graph update allows the user to supply a topologically identical cudaGraph_t object whose nodes contain updated parameters. Individual node update allows the user to explicitly update the parameters of individual nodes. Using an updated cudaGraph_t is more convenient when a large number of nodes are being updated, or when the graph topology is unknown to the caller (i.e., The graph resulted from stream capture of a library call). Using individual node update is preferred when the number of changes is small and the user has the handles to the nodes requiring updates.”).
It would have been obvious to one of ordinary skill in the art to have modified the processor which is to create an external semaphore signal node to be added to a graph as taught by the claims of the reference patent in view of Ashwathnarayan, to further update parameters of the node in an executable graph instantiated from the graph as taught by CUDA C++ Programming Guide. Updating parameters of nodes in an executable graph instantiated from a defined graph enables modification of a graph, e.g., when the graph has become out of date, and subsequent execution of a modified graph with improved performance and efficiency, as well as with reduced overhead, as re-instantiation of the graph is avoided (CUDA C++ Programming Guide: 3.2.6.6.4. Updating Instantiated Graphs).
Table 3: Claim comparison of the instant application with U.S. Patent No. 12,625,744 B2
Claim
18/754,000 (instant application)
U.S. Patent No. 12,625,744 B2
1
An acceleration processor unit (APU) comprising:
one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores;
one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs);
an L2 cache;
one or more fabric interconnects;
a memory controller; and
one or more input/output (I/O) bus interfaces;
at least one comprising a peripheral component interconnect express (PCIe) interface;
wherein:
the APU is to, in response to a call to an application programming interface (API), add an external semaphore signal node to a graph, wherein the call to the API is to include:
a graph identifier parameter;
a node identifier parameter;
a dependencies parameter;
a number of dependencies parameter;
a node parameters parameter;
wherein the external semaphore signal node, when performed, is to update a semaphore used by another API.
A processor comprising:
one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores;
one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs);
an L2 cache;
one or more fabric interconnects;
a memory controller; and
one or more input/output (I/O) interfaces;
at least one comprising a peripheral component interconnect express (PCIe) interface;
wherein:
the processor is to perform an application program interface (API) to create an external semaphore wait node to be added to a graph, wherein the API call is to include:
a graph identifier parameter;
a node identifier parameter;
a dependencies parameter;
a number of dependencies parameter; and
a node parameters parameter; and
the external semaphore wait node, if performed, is to cause the graph to wait on a semaphore used by another API.
2
The APU of claim 1, wherein the APU is to update parameters of the external semaphore signal node in an executable graph instantiated from the graph.
See claim 1
3
The APU of claim 1, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore signal node.
See claim 2: The processor of claim 1, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore wait node.
4
The APU of claim 1, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore signal node in memory.
See claim 3: The processor of claim 1, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore wait node in memory.
5
The APU of claim 1, wherein the dependencies parameter is to specify dependencies of the external semaphore signal node.
See claim 4: The processor of claim 1, wherein the dependencies parameter is to specify dependencies of the external semaphore wait node.
6
The APU of claim 1, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore signal node.
See claim 5: The processor of claim 1, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore wait node.
7
The APU of claim 1, wherein the node parameters parameter is to specify parameters for the external semaphore signal node.
See claim 6: The processor of claim 1, wherein the node parameters parameter is to specify parameters for the external semaphore wait node.
8
A system comprising: memory; and an acceleration processor unit (APU) comprising: one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); an L2 cache; one or more fabric interconnects; a memory controller; and one or more input/output (I/O) bus interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface; wherein: the APU is to, in response to a call to an application programming interface (API), add an external semaphore signal node to a graph, wherein the call to the API is to include: a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; a node parameters parameter; and wherein the external semaphore signal node, when performed, is to update a semaphore used by another API.
See claim 7: A system comprising: memory; and a processor comprising: one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); an L2 cache; one or more fabric interconnects; a memory controller; and one or more input/output (I/O) interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface; wherein: the processor is to perform an application program interface (API) to create an external semaphore wait node to be added to a graph, wherein the API call is to include: a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; and a node parameters parameter; and the external semaphore wait node, if performed, is to cause the graph to wait on a semaphore used by another API.
9
The system of claim 8, wherein the call to the API is to create the external semaphore signal node.
See claim 7: “an application program interface (API) to create an external semaphore wait node to be added to a graph, wherein the API call is to”
10
The system of claim 8, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore signal node.
See claim 8: The system of claim 8, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore wait node.
11
The system of claim 8, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore signal node in memory.
See claim 9: The system of claim 8, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore wait node in memory.
12
The system of claim 8, wherein the dependencies parameter is to specify dependencies of the external semaphore signal node.
See claim 10: The system of claim 8, wherein the dependencies parameter is to specify dependencies of the external semaphore wait node.
13
The system of claim 8, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore signal node.
See claim 11: The system of claim 8, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore wait node.
14
The system of claim 8, wherein the node parameters parameter is to specify parameters for the external semaphore signal node.
See claim 12: The system of claim 8, wherein the node parameters parameter is to specify parameters for the external semaphore wait node.
15
A method comprising: in response to a call to an application programming interface (API), adding an external semaphore signal node to a graph, wherein the call is to include:
a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; a node parameters parameter; and wherein the external semaphore signal node, when performed, is to update a semaphore used by another API; wherein adding the external semaphore signal node to the graph is to be performed by an acceleration processor unit (APU) comprising:
one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); an L2 cache; one or more fabric interconnects; a memory controller; and one or more input/output (I/O) bus interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface.
See claim 13: A method comprising: performing an application program interface (API) to create an external semaphore wait node to be added to a graph, wherein the API call is to include:
a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; and a node parameters parameter; wherein the external semaphore wait node, if performed, is to cause the graph to wait on a semaphore used by another API; and
wherein the API is to be performed by a processor comprising:
one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores; one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs); an L2 cache; one or more fabric interconnects; a memory controller; and one or more input/output (I/O) interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface.
16
The method of claim 15, wherein the call to the API is to create the external semaphore signal node.
See claim 13: “an application program interface (API) to create an external semaphore wait node”
17
The method of claim 15, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore signal node.
See claim 14: The method of claim 15, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore wait node.
18
The method of claim 15, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore signal node in memory.
See claim 15: The method of claim 15, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore wait node in memory.
19
The method of claim 15, wherein the dependencies parameter is to specify dependencies of the external semaphore signal node.
See claim 16: The method of claim 15, wherein the dependencies parameter is to specify dependencies of the external semaphore wait node.
20
The method of claim 15, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore signal node.
See claim 17: The method of claim 15, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore wait node.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ashwathnarayan et al. (U.S. Pub. No. 2020/0364088), hereinafter Ashwathnarayan, in view of CUDA C++ Programming Guide (NPL Document U on attached PTO-892) and CUDA Runtime API (NPL Document V on attached PTO-892).
Regarding claim 1, Ashwathnarayan teaches an acceleration processor unit (APU) (FIG. 35, processor 3500, described in [0481]-[0490]; [0098] – “at least two heterogeneous processing cores comprises a central processing unit (CPU) and a graphics processing unit (GPU) […] at least two heterogeneous processing cores comprises an accelerator”; [0238] – “GPU(s) 1808 and/or other accelerator(s) 1814.”; [0344] – “graphics acceleration module 2346 may be a GPU”; [0481] – “a processor 3500 having one or more processor cores 3502A-3502N, an integrated memory controller 3514, and an integrated graphics processor 3508”; [0488] – “processor cores 3502A-3502N are heterogeneous […] processor 3500 can be implemented on one or more chips”; [0489] – “configure ALUs of graphics processor 3510 to perform one or more machine learning algorithms, neural network architectures, use cases, or training techniques described herein”; [0438] – “a parallel processor or GPGPU as described herein is communicatively coupled to host/processor cores to accelerate graphics operations, machine-learning operations, pattern analysis operations, and various general purpose GPU (GPGPU) functions”; [0449] – “instructions to accelerate machine learning or deep learning algorithms, training, or inferencing”) comprising:
one or more core complexes, wherein the one or more core complexes include one or more central processing unit (CPU) cores ([0481] – “FIG. 35 is a block diagram of a processor 3500 having one or more processor cores 3502A-3502N”; [0488] – “processor cores 3502A-3502N are heterogeneous”; [0490] – “processor 3500 utilizes computing resources (e.g., CPUs, ASICs, GPUs, FPGAs)”; [0098] – “at least two heterogeneous processing cores comprises a central processing unit (CPU) and a graphics processing unit (GPU).”);
one or more graphics complexes, wherein the one or more graphics complexes include one or more compute units (CUs) ([0481] – “and an integrated graphics processor 3508”; [0485] – “processor 3500 additionally includes graphics processor 3508 to execute graphics processing operations.”; [0490] – “processor 3500 utilizes computing resources (e.g., CPUs, ASICs, GPUs, FPGAs)”; [0098] – “at least two heterogeneous processing cores comprises a central processing unit (CPU) and a graphics processing unit (GPU).”);
an L2 cache ([0481]-[0482] – “each of processor cores 3502A-3502N includes one or more internal cache units 3504A-3504N. In at least one embodiment, each processor core also has access to one or more shared cached units 3506. In at least one embodiment, internal cache units 3504A-3504N and shared cache units 3506 represent a cache memory hierarchy within processor 3500. In at least one embodiment, cache memory units 3504A-3504N may include at least one level of instruction and data cache within each processor core and one or more levels of shared mid-level cache, such as a Level 2 (L2)”);
one or more fabric interconnects ([0485] – “display controller 3511 may also be a separate module coupled with graphics processor 3508 via at least one interconnect”; [0486] – “a ring based interconnect unit 3512 is used to couple internal components of processor 3500. In at least one embodiment, an alternative interconnect unit may be used”; [0520]-[0521] – “FIGS. 39A-39B illustrate thread execution logic 3900 including an array of processing elements of a graphics processor core […] scalable execution units are interconnected via an interconnect fabric”; [0538] – execution logic 3900 may be utilized to implemented other embodiments, e.g. that described with FIG. 35);
a memory controller ([0481] – “an integrated memory controller 3514”); and
one or more input/output (I/O) bus interfaces ([0483] and [0487] – I/O link 3513 and/or bus controller units 3516 managing a set of peripheral buses);
at least one comprising a peripheral component interconnect express (PCIe) interface ([0483] – “processor 3500 may also include a set of one or more bus controller units 3516 and a system agent core 3510. In at least one embodiment, one or more bus controller units 3516 manage a set of peripheral buses, such as one or more PCI or PCI express busses.”; [0487] – “I/O link 3513 represents at least one of multiple varieties of I/O interconnects, including an on package I/O interconnect which facilitates communication between various processor components and a high-performance embedded memory module 3518”; [0312] – “standardized interconnects (e.g., PCIe)”; [0402] – “communication link technologies or protocols, such as, but not limited to PCI Express”);
wherein:
the APU is to ([0490] – “Processor 3500 may be utilized to implement one or more embodiments described elsewhere in this disclosure, such as those described in connection with FIGS. 1-34 and 36-43.”; [0175] – “a system is to obtain 1402 one or more attributes associated with how two or more heterogeneous processing cores support coordinating access to shared memory. In at least one embodiment, shared memory may refer to memory to be accessed (e.g., read and/or write) by two or more UMDs. In at least one embodiment, a heterogeneous processing core may refer to those described elsewhere in this disclosure, such as processor cores described in connection with FIG. 35. In at least one embodiment, a graph-based framework is used to determine a manner in which to coordinate access between heterogeneous processing cores. In at least one embodiment, a first UMD signals and a second UMD wait”; [0098] – “at least two heterogeneous processing cores include two or more UMDs. In at least one embodiment, at least two heterogeneous processing cores comprises a central processing unit (CPU) and a graphics processing unit (GPU).”), in response to a call to an application program interface (API), add an external semaphore signal [operation] to a [stream] ([0061] – “capabilities of parallel computing platform and application programming interface model external semaphores and parallel computing platform and application programming interface model streams are enhanced using techniques described herein. In at least one embodiment, a parallel computing platform and application programming interface model stream can wait and signal synchronization object by treating it as a type of external semaphore.”; [0071] – “a parallel computing platform and API model refers to an API model that can be used by software developers and software engineers to write code that uses a graphics processing unit (GPU) for general purpose processing. […] parallel computing platform and API models can be implemented using CUDA”; [0090] – “external semaphore wait/signal APIs can designate hand-off points for parallel computing platform and application programming interface model access to shared buffer and application can invoke external memory APIs”; [0128] – “SignalExternalSemaphoresAsync() is a supported API. In at least one embodiment, SignalExternalSemaphoresAsync( ) enqueues a signal operation on a set of externally allocated semaphore objects in a specified stream.”; [0129] – “applications invokes SignalExternalSemaphoresAsync( ) […] API enqueues a signal operation in a parallel computing platform and application programming interface model stream. In at least one embodiment, a signal operation is represented as semaphore release”), wherein call to the API is to include: a [stream] identifier parameter ([0135] – “SignalExternalSemaphoresAsync() accepts one or more parameters as input parameters. […] a parameter stream refers to stream to enqueue signal operations in.”); […] and wherein the external semaphore signal [operation], when performed, is to update a semaphore ([0128]-[0129] – “SignalExternalSemaphoresAsync( ) enqueues a signal operation on a set of externally allocated semaphore objects in a specified stream. In at least one embodiment, operations will be executed […] In at least one embodiment, a signal operation is represented as semaphore release […] GPU executes a previously enqueued signal operation.”; [0132]-[0133] – “semantics of signaling a semaphore depend on type of object. […] signaling semaphore sets it to a signaled state. […] semaphore is set to value specified in EXTERNAL_SEMAPHORE_PARAMS::params::fence::value.”) used by another API ([0115]-[0120] – “wait and signal operations occur in pair for Vulkan semaphores. […] SciSync ensures that a wait is enqueued after a signal is enqueued, which is supported by fact that API which performs a wait is to accept a SciSynceFence that is generated when a signal is enqueued. […] WaitExternalSemaphoresAsync() is a supported API. In at least one embodiment, WaitExternalSemaphoresAsync() enqueues a wait operation on a set of externally allocated semaphore objects in a specified stream. […] waiting on semaphore waits until semaphore reaches a signaled state. […] for every signal operation, there is exactly one corresponding wait operation. […] waiting on a semaphore waits until value of semaphore is greater than or equal to _EXTERNAL_SEMAPHORE_PARAMS::params::fence::value.” The semaphore is waited on by another API “WaitExternalSemaphoresAsync()”, which waits until the semaphore is set to a signaled state, i.e., updated by the external semaphore signal operation. Alternatively, the semaphore “used by another API” may be taught by the semaphore being allocated by another graphics API, e.g., Vulkan, as described in paragraphs [0063] and [0089] of Ashwathnarayan, where the semaphore is externally allocated and imported into parallel computing platform and application programming interface model’s address space to be used for signal and wait operations, as described in paragraphs [0110]-[0111] of Ashwathnarayan.).
Ashwathnarayan fails to expressly teach call to the API adds a node to a graph, wherein the call to the API is to include: a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; and a node parameters parameter; and wherein the node is performed.
However, the CUDA C++ Programming Guide teaches a call to an API to add a node to a graph based, at least in part, on parameters of the API call, wherein the node represents an operation, and wherein the node is performed (Section 3.2.6.6. CUDA Graphs – “CUDA Graphs present a new model for work submission in CUDA. A graph is a series of operations […] During the definition phase, a program creates a description of the operations in the graph along with the dependencies between them. […] An executable graph may be launched into a stream, similar to any other CUDA work”; Section 3.2.6.6.1 Graph Structure: "an operation forms a node in the graph. The dependencies between the operations are the edges. These dependencies constrain the execution sequence of the operations. An operation may be scheduled at any time once the nodes on which it depends are complete."; Section 3.2.6.6.2 Creating a Graph Using Graph APIs: in the example code, each API cudaGraphAddKernelNode (e.g., “cudaGraphAddKernelNode(&a, graph, NULL, 0, &nodeParams);”) adds a node to the graph based on parameters of the API, e.g., “&a, graph, NULL, 0, &nodeParams”; Section 3.2.6.6.5 Using Graph APIs – “Graph execution is done in streams for ordering with other asynchronous work. However, the stream is for ordering only; it does not constrain the internal parallelism of the graph, nor does it affect where graph nodes execute”).
Ashwathnarayan and CUDA C++ Programming Guide are considered to be analogous art to the claimed invention because they are in the same field as the claimed invention of executing programs written for a parallel computing platform and application interface. Ashwathnarayan teaches the parallel computing platform and application programming interface model may be CUDA ([0061]). Ashwathnarayan also teaches the SignalExternalSemaphoresAsync() API within the parallel computing platform and application programming model enqueues a signaling operation on an external semaphore in a stream ([0128] and [0129]). The CUDA C++ Programming Guide teaches that an operation forms a node within a CUDA graph (Section 3.2.6.6.1), and teaches a graph may be created from existing stream-based APIs, where work launched into a stream may be appended to a graph (Section 3.2.6.6.3 Creating a Graph Using Stream Capture). Further, the CUDA C++ Programming Guide teaches CUDA graphs are a model for work submission providing several advantages over the work submission mechanism of streams which include reducing CPU launch costs and enabling optimization by presenting the whole workflow (Section 3.2.6.6). Lastly, Ashwathnarayan suggests using synchronization objects (e.g., external semaphores – see [0061]) in graph-based execution frameworks ([0064]). Therefore, it would have been obvious to one of ordinary skill in the art to have modified the API call which adds the external semaphore signal operation to a stream, where the external semaphore signal operation, when performed, is to update a semaphore used by another API as taught by Ashwathnarayan, to instead add a node to a graph as taught by CUDA C++ Programming Guide, where the external semaphore signal operation forms the added node, and the operations which form the nodes are executed in the sequence defined by the graph’s dependencies. Doing so enables optimizations to be performed on work submitted in CUDA and reduces costs for setting up and launching the work (CUDA C++ Programming Guide: Section 3.2.6.6.).
The combination of Ashwathnarayan in view of CUDA C++ Programming Guide fails to expressly teach the API call is to include: a graph identifier parameter; a node identifier parameter; a dependencies parameter; a number of dependencies parameter; and a node parameters parameter.
However, CUDA Runtime API teaches the API call (Section 5.29 Graph Management, Pages 315-316 – cudaGraphAddKernelNode is an API call) is to include: a graph identifier parameter (Pages 315-316 – cudaGraphAddKernelNode has parameter “graph” which indicates the “Graph to which to add the node”); a node identifier parameter (Pages 315-316 – cudaGraphAddKernelNode has parameter “pGraphNode” which “Returns newly created node”); a dependencies parameter (Pages 315-316 – cudaGraphAddKernelNode has parameter “pDependencies” which indicates the “Dependencies of the node”); a number of dependencies parameter (Pages 315-316 – cudaGraphAddKernelNode has parameter “numDependencies” which indicates the “Number of dependencies”); and a node parameters parameter (Pages 315-316 – cudaGraphAddKernelNode has parameter “pNodeParams” which indicates “Parameters for the GPU execution node”).
The CUDA Runtime API is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor in ordering the execution of dependent operations within a graph. The CUDA Runtime API discloses a list of APIs to add different types of nodes to a CUDA graph, many of which require parameters corresponding to the graph to which a node should be added, the node identifier, the dependencies of the node, the number of dependencies, and the parameters of the node (Section 5.29). Therefore, it would have been obvious to one of ordinary skill prior to the filing date of the claimed invention to have modified the API call which adds a node corresponding to the external semaphore signal operation to a graph as disclosed by Ashwathnarayan in view of the CUDA C++ Programming Guide to include the parameters taught by CUDA Runtime API. Properly defining nodes and their edges representing dependencies between nodes in a CUDA graph ensures proper order of execution of the operations (CUDA C++ Programming Guide: Section 3.2.6.6.1). Further, using graphs enables optimizations to be performed on work submitted in CUDA and reduces costs for setting up and launching the work when compared to work submitted through streams (CUDA C++ Programming Guide: Section 3.2.6.6.). Ashwathnarayan also suggests implementing synchronization objects which are waited on and signaled (e.g., external semaphores – [0061]) into graph based execution frameworks ([0064]).
Regarding claim 2, the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide and the CUDA Runtime API teaches the APU of claim 1, wherein the APU (see Ashwathnarayan: FIG. 35, processor 3500, described in [0481]-[0490]; [0098]; [0238]; [0344]; [0438]; [0449]) is to update parameters of the external semaphore signal node in an executable graph instantiated from the graph (see CUDA C++ Programming Guide: Section 1.3 A Scalable Programming Model – the CUDA parallel programming model disclosed therein is designed to leverage multiple CPU and GPU cores on a processor chip; Section 3.2.6.6. CUDA Graphs – “Work submission using graphs is separated into three distinct stages: definition, instantiation, and execution. During the definition phase, a program creates a description of the operations in the graph along with the dependencies between them. Instantiation takes a snapshot of the graph template, validates it, and performs much of the setup and initialization of work with the aim of minimizing what needs to be done at launch. The resulting instance is known as an executable graph.”; Section 3.2.6.6.4. Updating Instantiated Graphs – “CUDA provides a lightweight mechanism known as “Graph Update,” which allows certain node parameters to be modified in-place without having to rebuild the entire graph. […] CUDA provides two mechanisms for updating instantiated graphs, whole graph update and individual node update. Whole graph update allows the user to supply a topologically identical cudaGraph_t object whose nodes contain updated parameters. Individual node update allows the user to explicitly update the parameters of individual nodes. Using an updated cudaGraph_t is more convenient when a large number of nodes are being updated, or when the graph topology is unknown to the caller (i.e., The graph resulted from stream capture of a library call). Using individual node update is preferred when the number of changes is small and the user has the handles to the nodes requiring updates.”).
It would have been obvious to one of ordinary skill in the art to have modified the APU which, in response to an API call, adds an external semaphore signal operation to a stream and specifies parameters of the external semaphore signal operation as taught by Ashwathnarayan (see Ashwathnarayan: [0128]-[0135]), to instead create (and add) a node to a graph as taught by CUDA C++ Programming Guide, where the external semaphore signal operation forms the created node in the graph, and such that the APU may further update parameters of the created node formed by the external semaphore signal operation in an executable graph instantiated from the graph as taught by CUDA C++ Programming Guide. Using CUDA graphs instead of streams enables optimizations to be performed on work submitted in CUDA and reduces costs for setting up and launching the work (CUDA C++ Programming Guide: Section 3.2.6.6.). Further, updating parameters of nodes in an executable graph instantiated from a defined graph enables modification of a graph, e.g., when the graph has become out of date, and subsequent execution of a modified graph with improved performance and efficiency, as well as with reduced overhead, as re-instantiation of the graph is avoided (CUDA C++ Programming Guide: 3.2.6.6.4. Updating Instantiated Graphs).
Regarding claim 3, the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide and the CUDA Runtime API teaches the APU of claim 1, wherein the graph identifier parameter is to specify the graph to which to add the external semaphore signal node (see CUDA Runtime API: Section 5.29, Pages 315-316 – cudaGraphAddKernelNode has parameter “graph” which indicates the “Graph to which to add the node […] Creates a new kernel execution node and adds it to graph”).
It would have been obvious to one of ordinary skill prior to the filing date of the claimed invention to have modified the API call which adds a node corresponding to the external semaphore signal operation (the “external semaphore signal node”) to a graph as disclosed by the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide, as explained with respect to claim 1, to include the parameters taught by CUDA Runtime API. Properly defining nodes and their edges representing dependencies between nodes in creation of a CUDA graph ensures proper order of execution of the operations (CUDA C++ Programming Guide: Section 3.2.6.6.1). Further, using graphs enables optimizations to be performed on work submitted in CUDA and reduces costs for setting up and launching the work when compared to work submitted through streams (CUDA C++ Programming Guide: Section 3.2.6.6.). Ashwathnarayan also suggests implementing synchronization objects which are waited on and signaled (e.g., external semaphores – [0061]) into graph based execution frameworks ([0064]).
Regarding claim 4, the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide and the CUDA Runtime API teaches the APU of claim 1, wherein the node identifier parameter is an outgoing parameter to return a pointer to a location of the external semaphore signal node in memory (see CUDA Runtime API: Section 5.29, Pages 315-316 – the API call cudaGraphAddKernelNode represented by the code: “__host__cudaError_t cudaGraphAddKernelNode(cudaGraphNode_t *pGraphNode, cudaGraph_t graph, const cudaGraphNode_t *pDependencies, size_t numDependencies, const cudaKernelNodeParams *pNodeParams”, has input (i.e., “outgoing”) parameter “*pGraphNode” which “Returns newly created node […] Creates a new kernel execution node […] A handle to the new node will be returned in pGraphNode.” A pointer (i.e., a variable that points to a memory address) is conventionally indicated by an asterisk * in front of an identifier of a variable (e.g., *pNodeParams) in programming languages such as C and C++, as is known in the art).
It would have been obvious to one of ordinary skill prior to the filing date of the claimed invention to have modified the API call which adds a node corresponding to the external semaphore signal operation (the “external semaphore signal node”) to a graph as disclosed by the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide, as explained with respect to claim 1, to include the parameters taught by CUDA Runtime API. Properly defining nodes and their edges representing dependencies between nodes in creation of a CUDA graph ensures proper order of execution of the operations (CUDA C++ Programming Guide: Section 3.2.6.6.1). Further, using graphs enables optimizations to be performed on work submitted in CUDA and reduces costs for setting up and launching the work when compared to work submitted through streams (CUDA C++ Programming Guide: Section 3.2.6.6.). Ashwathnarayan also suggests implementing synchronization objects which are waited on and signaled (e.g., external semaphores – [0061]) into graph based execution frameworks ([0064]).
Regarding claim 5, the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide and the CUDA Runtime API teaches the APU of claim 1, wherein the dependencies parameter is to specify dependencies of the external semaphore signal node (see CUDA Runtime API: Section 5.29, Pages 315-316 cudaGraphAddKernelNode has parameter “pDependencies” which indicates the “Dependencies of the node”).
It would have been obvious to one of ordinary skill prior to the filing date of the claimed invention to have modified the API call which adds a node corresponding to the external semaphore signal operation (the “external semaphore signal node”) to a graph as disclosed by the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide, as explained with respect to claim 1, to include the parameters taught by CUDA Runtime API. Properly defining nodes and their edges representing dependencies between nodes in creation of a CUDA graph ensures proper order of execution of the operations (CUDA C++ Programming Guide: Section 3.2.6.6.1). Further, using graphs enables optimizations to be performed on work submitted in CUDA and reduces costs for setting up and launching the work when compared to work submitted through streams (CUDA C++ Programming Guide: Section 3.2.6.6.). Ashwathnarayan also suggests implementing synchronization objects which are waited on and signaled (e.g., external semaphores – [0061]) into graph based execution frameworks ([0064]).
Regarding claim 6, the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide and the CUDA Runtime API teaches the APU of claim 1, wherein the number of dependencies parameter is to specify a number of dependencies of the external semaphore signal node (see CUDA Runtime API: Section 5.29, Pages 315-316 cudaGraphAddKernelNode has parameter “numDependencies” which indicates the “Number of dependencies […] It is possible for numDependencies to be 0, in which case the node will be placed at the root of the graph.”).
It would have been obvious to one of ordinary skill prior to the filing date of the claimed invention to have modified the API call which adds a node corresponding to the external semaphore signal operation (the “external semaphore signal node”) to a graph as disclosed by the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide, as explained with respect to claim 1, to include the parameters taught by CUDA Runtime API. Properly defining nodes and their edges representing dependencies between nodes in creation of a CUDA graph ensures proper order of execution of the operations (CUDA C++ Programming Guide: Section 3.2.6.6.1). Further, using graphs enables optimizations to be performed on work submitted in CUDA and reduces costs for setting up and launching the work when compared to work submitted through streams (CUDA C++ Programming Guide: Section 3.2.6.6.). Ashwathnarayan also suggests implementing synchronization objects which are waited on and signaled (e.g., external semaphores – [0061]) into graph based execution frameworks ([0064]).
Regarding claim 7, the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide and the CUDA Runtime API teaches the APU of claim 1, wherein the node parameters parameter is to specify parameters for the external semaphore signal node (see CUDA Runtime API: Section 5.29, Pages 315-316 cudaGraphAddKernelNode has parameter “pNodeParams” which indicates “Parameters for the GPU execution node”).
It would have been obvious to one of ordinary skill prior to the filing date of the claimed invention to have modified the API call which adds a node corresponding to the external semaphore signal operation (the “external semaphore signal node”) to a graph as disclosed by the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide, as explained with respect to claim 1, to include the parameters taught by CUDA Runtime API. Properly defining nodes and their edges representing dependencies between nodes in creation of a CUDA graph ensures proper order of execution of the operations (CUDA C++ Programming Guide: Section 3.2.6.6.1). Further, using graphs enables optimizations to be performed on work submitted in CUDA and reduces costs for setting up and launching the work when compared to work submitted through streams (CUDA C++ Programming Guide: Section 3.2.6.6.). Ashwathnarayan also suggests implementing synchronization objects which are waited on and signaled (e.g., external semaphores – [0061]) into graph based execution frameworks ([0064]).
Regarding claim 8, Ashwathnarayan teaches A system comprising: memory; and an acceleration processor unit (APU) (FIG. 34, system 3400 with processor(s) 3402 and memory device 3420; [0481] – “FIG. 35 is a block diagram of a processor 3500 having one or more processor cores 3502A-3502N, an integrated memory controller 3514”; [0484] – “one or more integrated memory controllers 3514 to manage access to various external memory devices (not shown).”; [0490] – “Processor 3500 may be utilized to implement one or more embodiments described elsewhere in this disclosure, such as those described in connection with FIGS. 1-34 and 36-43.” Processor 3500 could be implemented in system 3400 with memory device 3420. As described with respect to the acceleration processor unit (APU) of claim 1, processor 3500 is an APU.) comprising: the APU of claim 1. Accordingly, claim 8 is rejected as being unpatentable over Ashwathnarayan in view of CUDA C++ Programming Guide and CUDA Runtime API for the same reasons presented with respect to claim 1 above.
Regarding claim 9, the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide and the CUDA Runtime API teaches the system of claim 8, wherein the call to the API is to create the external semaphore signal node (see CUDA C++ Programming Guide: Section 3.2.6.6.2 Creating a Graph Using Graph APIs: in the example code for creating a graph, each API cudaGraphAddKernelNode (e.g., “cudaGraphAddKernelNode(&a, graph, NULL, 0, &nodeParams);”) creates a node as explained in the comments of the code and adds the node to the graph based on parameters of the API, e.g., “&a, graph, NULL, 0, &nodeParams”.).
It would have been obvious to one of ordinary skill in the art to have modified the API call which adds an external semaphore signal operation to a stream as taught by Ashwathnarayan, to instead create (and add) a node to a graph as taught by CUDA C++ Programming Guide, where the external semaphore signal operation forms the created node. Doing so enables optimizations to be performed on work submitted in CUDA and reduces costs for setting up and launching the work (CUDA C++ Programming Guide: Section 3.2.6.6.). Further, the CUDA C++ Programming Guide teaches an operation forms a node in a graph (Section 3.2.6.6.1. Graph Structure) and a graph may be created from existing stream-based APIs, where work launched into a stream may be appended to a graph, e.g. as a set of nodes (Section 3.2.6.6.3 Creating a Graph Using Stream Capture).
Claims 10-14 recite substantially the same limitations as claims 3-7, respectively, applied to the system of claim 8. Accordingly, claims 10-14 are rejected as being unpatentable over Ashwathnarayan in view of CUDA C++ Programming Guide and CUDA Runtime API for the same reasons presented with respect to claims 3-7 above.
Regarding claim 15, Ashwathnarayan teaches A method comprising: the operations performed by the acceleration processor unit (APU) of claim 1. Accordingly, claim 15 is rejected as being unpatentable over Ashwathnarayan in view of CUDA C++ Programming Guide and CUDA Runtime API for the same reasons presented with respect to claim 1 above.
Claim 16 recites substantially the same limitations as claim 9, applied to the method of claim 15. Accordingly, claim 16 is rejected as being unpatentable over Ashwathnarayan in view of CUDA C++ Programming Guide and CUDA Runtime API for the same reasons presented with respect to claim 9 above.
Claims 17-20 recite substantially the same limitations as claims 3-6, respectively, applied to the method of claim 15. Accordingly, claims 17-20 are rejected as being unpatentable over Ashwathnarayan in view of CUDA C++ Programming Guide and CUDA Runtime API for the same reasons presented with respect to claims 3-6 above.
Response to Arguments
Applicant's arguments with respect to the double patenting rejections, see pages 11-12 of the Remarks filed 9/09/2026 have been fully considered but they are not persuasive.
Regarding the arguments presented for U.S. Patent Application No. 18/745,851:
Applicant must file a terminal disclaimer as a complete and proper response to a double patenting rejection. Applicant’s statement of filing a terminal disclaimer upon allowance is not a proper response. See MPEP 804. A complete response to a nonstatutory double patenting (NSDP) rejection is either a reply by the Applicant showing that the claims subject to the rejection are patentably distinct from the reference claims or the filing of a terminal disclaimer in accordance with 37 CFR 1.321 in the pending application(s) with a reply to the Office action (see MPEP 1490 for a discussion of terminal disclaimers). Such a response is required even when the nonstatutory double patenting rejection is provisional.
Regarding the arguments presented for U.S. Patent No. 12,608,245 B2 in view of Ashwathnarayan and U.S. Patent No. 12,625,744 B2 in view of Ashwathnarayan:
Applicant argues the pending claims are patentably distinct from the reference patents in view of Ashwathnarayan “the cited combination does not render obvious the limitation, as recited in amended claim 1, that "the APU is to, in response to a call to an application programming interface (API), add an external semaphore signal node to a graph, ... wherein the external semaphore signal node, when performed, is to update a semaphore used by another API.”
Examiner disagrees. Regarding the argued limitations of claim 1 of the instant application “the APU is to, in response to a call to an application program interface (API), add an external semaphore signal node to a graph, […] and wherein the external semaphore signal node, when performed, is to update a semaphore used by another API”, each claim 1 of the reference patents recites the limitations “the processor is to perform an application program interface (API) to create an external semaphore wait node to be added to a graph, […] and the external semaphore wait node, if performed, is to cause the graph to wait on a semaphore used by another API” where differences between the limitations are bolded.
It would have been obvious to one of ordinary skill in the art to utilize an “acceleration processor unit (APU)” as a type of processor in order to realize the APU, system and method disclosed in the claims of the instant application in view of the processor disclosed in each claim 1 of the reference patents, respectively. Further, it would have been obvious to one of ordinary skill in the art that the “APU is to perform an application program interface (API) to add” as recited by each claim 1 of the reference patent is analogous to the “one or more processor are to, in response to a call to an application program interface (API), add” as the reference claims later recite “wherein the API call” in reference to the previously recited “perform an application program interface (API)”. An API, as is known in the art, is a library of functions which are called to perform of the functions, as is evidenced by at least Ashwathnarayan and the CUDA Runtime API cited in the section titled Claim Rejections - 35 USC § 103 above.
The reference claims differ in a “semaphore wait node” as recited by the reference patents which, if performed, is to cause the graph to “wait” on a semaphore vs. a “semaphore signal node” are recited by the instant application, which, when performed, is to cause the graph to “update” a semaphore.
However, Ashwathnarayan teaches a semaphore wait operation which, if performed, is to cause code to wait on a semaphore, and a semaphore signal operation which, when performed, is to cause code to update a semaphore as obvious variants ([0061] – “a parallel computing platform and application programming interface model stream can wait and signal synchronization object by treating it as a type of external semaphore”; [0063] – “parallel computing platform and application programming interface model interops supports externally allocated semaphore, such as Vulkan semaphores”; [0115] – “wait and signal operations occur in pair for Vulkan semaphores”; [0116] – “WaitExternalSemaphoresAsync() is a supported API. In at least one embodiment, WaitExternalSemaphoresAsync() enqueues a wait operation on a set of externally allocated semaphore objects in a specified stream.”; [0119]-[0120] – “waiting on semaphore waits until semaphore reaches a signaled state. In at least one embodiment, a semaphore reaches a singled state and is then reset to an unsigned state. In at least one embodiment, for every signal operation, there is exactly one corresponding wait operation. […] waiting on a semaphore waits until the value of semaphore is greater than or equal to _EXTERNAL_SEMAPHORE_PARAMS::params::fence::value.”; [0128] – “SignalExternalSemaphoresAsync() is a supported API. In at least one embodiment, SignalExternalSemaphoresAsync() enqueues a signal operation on a set of externally allocated semaphore objects in a specified stream.”; [0132]-[0133] – “signaling semaphore sets it to a signaled state […] semaphore is set to value specified in _EXTERNAL_SEMAPHORE_PARAMS::params::fence::value”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that the “semaphore signal node” which, when performed, causes the graph to “update” a semaphore claimed in the instant application is an obvious variant of the “semaphore wait node” which, if performed, causes the graph to “wait” on a semaphore claimed in the reference patent. Synchronization interoperability, such as waiting on and signaling (i.e., updating by setting to a signaled state) external semaphores, wherein waits and signals always occur in pairs for certain types of external semaphores, e.g., Vulkan semaphores (Ashwathnarayan: [0115]) allows applications to have a finer grain control of efficiently describing dependencies between tasks that spans across hardware and software boundaries (ASHWATHNARAYAN: [0062] and [0063]).
Accordingly, the double patenting rejections of the claims as being unpatentable over U.S. Patent No. 12,608,245 B2 in view of Ashwathnarayan and U.S. Patent No. 12,625,744 B2 in view of Ashwathnarayan are maintained.
Applicant's arguments with respect to the rejections of claims 1-20 under 35 U.S.C. 103 as being unpatentable over Ashwathnarayan in view of CUDA C++ Programming Guide and CUDA Runtime API, see pages 12-16 of the Remarks filed 9/09/2026 have been fully considered but they are not persuasive.
Regarding the arguments that the cited portions of Ashwathnarayan fails to “disclose or suggest an external semaphore signal operation as a node in a graph that, when performed, updates a semaphore used by another API” and that the cited portions of the CUDA C++ Programming Guide “do not disclose or suggest that the operation is an "external semaphore signal node," nor do they disclose or suggest that "the external semaphore signal node, when performed, is to update a semaphore used by another API," as recited in amended claim 1” and that the cited portions of the CUDA Runtime API “do not disclose or suggest that "the external semaphore signal node, if performed, is to update a semaphore used by another API," as recited in amended claim 1.”
In response to applicant's 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).
None of Ashwathnarayan, the CUDA C++ Programming Guide nor the CUDA Runtime API alone is relied upon alone teach the claimed “external semaphore signal node” and “the external semaphore signal node, when performed, is to update a semaphore used by another API” as recited in claim 1. Rather, the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide is relied upon to teach the external semaphore signal node. As shown in the rejection of claim 1 presented above in the section titled Claim Rejections - 35 USC § 103, Ashwathnarayan teaches an API call, SignalExternalSemaphoresAsync() within the parallel computing platform and application programming model, i.e. CUDA, enqueues a signaling operation on an external semaphore (i.e., an “external semaphore signal” operation) in a stream ([0061], [0128] and [0129]). The CUDA C++ Programming Guide teaches that an operation forms a node within a CUDA graph (Section 3.2.6.6.1), and teaches a graph may be created from existing stream-based APIs, where work launched into a stream may be appended to a graph (Section 3.2.6.6.3 Creating a Graph Using Stream Capture). Further, the CUDA C++ Programming Guide teaches CUDA graphs are a model for work submission providing several advantages over the work submission mechanism of streams which include reducing CPU launch costs and enabling optimization by presenting the whole workflow (Section 3.2.6.6). Therefore, it would have been obvious to one of ordinary skill in the art to have modified the API call which adds an external semaphore signal operation to a stream as taught by Ashwathnarayan, to instead add a node to a graph as taught by CUDA C++ Programming Guide, where the external semaphore signal operation forms the added node. Doing so would enable optimizations to be performed on work submitted in CUDA and reduces costs for setting up and launching the work (CUDA C++ Programming Guide: Section 3.2.6.6.).
Further, the combination of Ashwathnarayan in view of CUDA C++ Programming Guide teaches “the external semaphore signal node, when performed, is to update a semaphore used by another API" as recited in amended claim 1.
Ashwathnarayan teaches the external semaphore signal [operation], when performed, is to update a semaphore ([0128]-[0129] – “SignalExternalSemaphoresAsync( ) enqueues a signal operation on a set of externally allocated semaphore objects in a specified stream. In at least one embodiment, operations will be executed […] In at least one embodiment, a signal operation is represented as semaphore release […] GPU executes a previously enqueued signal operation.”; [0132]-[0133] – “semantics of signaling a semaphore depend on type of object. […] signaling semaphore sets it to a signaled state. […] semaphore is set to value specified in EXTERNAL_SEMAPHORE_PARAMS::params::fence::value.”) used by another API ([0115]-[0120] – “wait and signal operations occur in pair for Vulkan semaphores. […] SciSync ensures that a wait is enqueued after a signal is enqueued, which is supported by fact that API which performs a wait is to accept a SciSynceFence that is generated when a signal is enqueued. […] WaitExternalSemaphoresAsync() is a supported API. In at least one embodiment, WaitExternalSemaphoresAsync() enqueues a wait operation on a set of externally allocated semaphore objects in a specified stream. […] waiting on semaphore waits until semaphore reaches a signaled state. […] for every signal operation, there is exactly one corresponding wait operation. […] waiting on a semaphore waits until value of semaphore is greater than or equal to _EXTERNAL_SEMAPHORE_PARAMS::params::fence::value.” The semaphore is waited on by another API “WaitExternalSemaphoresAsync()”, which waits until the semaphore is set to a signaled state, i.e., updated by the external semaphore signal operation. Alternatively, the semaphore “used by another API” may be taught by the semaphore being allocated by another graphics API, e.g., Vulkan, as described in paragraphs [0063] and [0089] of Ashwathnarayan, where the semaphore is externally allocated and imported into and imported into parallel computing platform and application programming interface model’s address space to be used for signal and wait operations, as described in paragraphs [0110]-[0111] of Ashwathnarayan.).
For the same reasons already discussed with respect to the combination of Ashwathnarayan in view of the CUDA C++ Programming Guide relied upon to teach an “external semaphore signal node”, it would have been obvious to one of ordinary skill in the art to have modified the API call which adds the external semaphore signal operation to a stream, where the external semaphore signal operation, if performed, is to update a semaphore used by another API as taught by Ashwathnarayan, to instead add a node to a graph as taught by CUDA C++ Programming Guide, where the external semaphore signal operation forms the added node, and the operations of the nodes are executed in the sequence defined by the graph. Doing so would enable optimizations to be performed on work submitted in CUDA and reduces costs for setting up and launching the work (CUDA C++ Programming Guide: Section 3.2.6.6.).
No additional arguments were presented with respect to claims 2-20. Accordingly, Examiner’s response with respect to the arguments presented for claim 1 are applicable to claims 2-20.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
“NVIDIA Toolkit Release Notes for CUDA 11.2” (NPL document cited and provided with the attached PTO-892) teaches CUDA Graph enhancements include the new graph node type “external semaphore signal”, with new APIs to add a node of type external semaphore signal to a graph and to set parameters of graph nodes of this type (see page 8). It further teaches support for adding these nodes to a graph by capturing calls to cuSignalExternalSemaphoresAsync() (see page 8).
Wilt et al. (U.S. Patent No. 8,539,516) teaches synchronizing access to a memory buffer among two or more APIs using a semaphore, where a “semaphore acquire” CUDA command and a “semaphore release” CUDA command are used (see Col. 2, lines 7-25 and Col. 7, line 65-Col. 8, line 21).
JONES et al. (U.S. Pub. No. 2021/0149719) teaches parameters of one or more nodes of an executable graph are modified to modify a workload performed when the executable graph is launched, where API calls may be used to modify each node, and wherein executable graph was generated from a task graph using instantiation (see [0285], [0293] and [0298]).
Gould et al. (U.S. Patent No. 8,271,996) teaches API calls are used in connection with operations on semaphores, wherein operations on semaphores may include decrementing or incrementing a value of the semaphore (see Col. 21, lines 35-58 and Col. 42, lines 1-18).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 8:00 am - 4:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
