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.
Priority
Applicant' s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Specifically, priority is claimed as a CON of Application No. 17/549,627.
Drawings
The drawings are objected to because FIG 23A contains reference number 2318 which is not oriented in the same direction as the figure. See 37 C.F.R. 1.84(p)(1).
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
Applicant is reminded of the proper content of an abstract of the disclosure.
A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art.
If the patent is of a basic nature, the entire technical disclosure may be new in the art, and the abstract should be directed to the entire disclosure. If the patent is in the nature of an improvement in an old apparatus, process, product, or composition, the abstract should include the technical disclosure of the improvement. The abstract should also mention by way of example any preferred modifications or alternatives.
Where applicable, the abstract should include the following: (1) if a machine or apparatus, its organization and operation; (2) if an article, its method of making; (3) if a chemical compound, its identity and use; (4) if a mixture, its ingredients; (5) if a process, the steps.
Extensive mechanical and design details of an apparatus should not be included in the abstract. The abstract should be in narrative form and generally limited to a single paragraph within the range of 50 to 150 words in length.
See MPEP § 608.01(b) for guidelines for the preparation of patent abstracts.
The abstract of the disclosure is objected to because it is not within the range of 50 to 150 words in length. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
The disclosure is objected to because of the following informalities: In paragraph [0078], line 9, “update signal node parameters API 130” is recited, but should be corrected to “update signal node parameters API 138” in accordance with the reference numbers used in FIG. 1.
Appropriate correction is required.
The use of the terms FORTRAN, PYTHON, JAVA, MICROSOFT, and BLUETOOTH, which are trade names or marks used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
Claim Objections
Claims 2, 9, and 15-16 are objected to because of the following informalities:
In claim 2, line 1, “the API” is unclear whether it is referring to the previously recited API performed by the processor (see claim 1, line 13) or the previously recited API call (see claim 1, line 14).
In claim 9, line 1, “the API” is unclear whether it is referring to the previously recited API performed by the processor (see claim 8, line 15) or the previously recited API call (see claim 8, line 16).
In claim 15, line 9, “wherein the API” is unclear whether it is referring to the previously recited API (see claim 15, line 2) or the previously recited API call (see claim 15, line 3).
In claim 16, line 1, “the API” is unclear whether it is referring to the previously recited API which is performed (see claim 15, line 2) or the previously recited API call (see claim 15, line 3).
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 8, and 15 recite “perform[/performing] an application program interface (API)” in lines 13, 15, and 2, respectively. However, an API is an interface (e.g., a library of computing functions of a program that can be invoked, i.e., called, by other programs to communicate with the program), and it is not clear what is meant by “perform” an interface; such as to call the interface to invoke a function provided by the interface, or to perform a corresponding function in response to a call to the interface, or to initialize the interface for execution, or to download the interface, or to generate the interface as part of a development process, etc.
For the following analysis, the Examiner will consider the limitations “perform/performing an application program interface (API)” as referring to --perform/performing an application program interface (API) function--.
Claim 1 recites the limitation "the API call" in line 14. There is insufficient antecedent basis for this limitation in the claim. Although an API is previously recited in the claim, an “API call” is not.
Claim 8 recites the limitation “the API call” in line 16. There is insufficient antecedent basis for this limitation in the claim. Although an API is previously recited in the claim, an “API call” is not.
Claim 15 recites the limitation “the API call” in line 3. There is insufficient antecedent basis for this limitation in the claim. Although an API is previously recited in the claim, an “API call” is not.
Claim 15 recites the limitation “wherein the API is to be performed” in line 9. For the same reasons presented above with respect to the limitations “perform[/performing] an application program interface (API)” as recited in claims 1, 8 and 15 , this limitation is indefinite.
Claims 2-7, 9-14, and 16-20 depend from claims 1, 8 and 15, and therefore inherit the deficiencies of claims 1, 8, and 15.
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 processor, 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 perform an application program interface (API) to 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; and
a node parameters parameter.
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) bus interfaces;
at least one comprising a peripheral component interconnect express (PCIe) interface;
wherein:
the processor is to perform an application program interface (API) to 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; and
a node parameters parameter.
2
The APU of claim 1, wherein the API is further to create the external semaphore signal node.
The processor of claim 1, wherein the API is further to create the external semaphore signal node.
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 processor 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 processor 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 processor 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 processor 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 processor 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 perform an application program interface (API) to 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; and a node parameters parameter.
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) bus interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface; wherein: the processor is to perform an application program interface (API) to 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; and a node parameters parameter.
9
The system of claim 8, wherein the API is further to create the external semaphore signal node.
The system of claim 8, wherein the API 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: performing an application program interface (API) to 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; and a node parameters parameter; wherein the API 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: performing an application program interface (API) to 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; and a node parameters parameter; 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) bus interfaces; at least one comprising a peripheral component interconnect express (PCIe) interface.
16
The method of claim 15, wherein the API is further to create the external semaphore signal node.
The method of claim 15, wherein the API 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-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 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 vs. a “semaphore signal node” are recited by the instant application.
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 and a semaphore signal 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” claimed in the instant applications is an obvious variant of the “semaphore wait node” 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 2-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 2-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.
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 perform an application program interface (API) to 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; and
a node parameters parameter.
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 API is further to create the external semaphore signal node.
See claim 1: “an application program interface (API) to create an external semaphore wait node”
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 perform an application program interface (API) to 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; and a node parameters parameter.
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 API is further to create the external semaphore signal node.
See claim 7: “an application program interface (API) to create an external semaphore wait 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.
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:
performing an application program interface (API) to 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; and a node parameters parameter;
wherein the API 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 API is further 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 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-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.
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 vs. a “semaphore signal node” are recited by the instant application.
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 and a semaphore signal 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” claimed in the instant applications is an obvious variant of the “semaphore wait node” 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 2-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 2-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.
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 perform an application program interface (API) to 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; and
a node parameters parameter.
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 API is further to create the external semaphore signal node.
See claim 1: “an application program interface (API) to create an external semaphore wait node”
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 perform an application program interface (API) to 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; and a node parameters parameter.
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 API is further to create the external semaphore signal node.
See claim 7: “an application program interface (API) to create an external semaphore wait 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.
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:
performing an application program interface (API) to 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; and a node parameters parameter;
wherein the API 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 API is further 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).”) perform an application program interface (API) to 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 the API call 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.”); […].
Ashwathnarayan fails to expressly teach the API adds a 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; and a node parameters parameter.
However, the CUDA C++ Programming Guide teaches 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 (Section 3.2.6.6. CUDA Graphs – “During the definition phase, a program creates a description of the operations in the graph along with the dependencies between them.”; 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”.).
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). 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 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 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 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 API is further 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 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.).
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 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 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 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 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 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.
Claims 9-14 recite substantially the same limitations as claims 2-7, respectively, applied to the system of claim 8. Accordingly, claims 9-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 2-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.
Claims 16-20 recite substantially the same limitations as claims 2-6, respectively, applied to the method of claim 15. Accordingly, claims 16-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 2-6 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Codeacademy (NPL Document W cited on attached PTO-892: “Pointers” and provided with the Information Disclosure Statement filed 5/01/2026) teaches a pointer is a variable that stores a memory address, i.e., a specific location in memory where data is location, and is declared with an asterisk character * in front of the identifier (see pages 1-2).
W3Schools (NPL Document X cited on attached PTO-892: “C++ Pointers” and provided with the Information Disclosure Statement filed 5/01/2026) teaches a pointer variable in C++ is created with the * operator and is a variable that stores the memory address as its value (see pages 1-2).
Borkovic (U.S. Patent No. 11,847,507) teaches a neural network graph may include nodes representing operations to be executed by an engine in a neural network processor, and semaphores may be used for synchronization between operations in the neural network graph (Col. 4, lines 34-48 and Col. 5, lines 57-64). Further, a driver of an acceleration engine of the neural network processor may provide an API that defines functions for feeding data to the acceleration engine and for defining operations to perform on the data (see Col. 22, lines 12-36).
Agarwal et al. (U.S. Pub. No. 2019/0171497) teaches a graph compiler determines dependencies between nodes of a graph, corresponding to a plurality of kernels to be executed, and inserts semaphore read and write instructions at the appropriate places of producer and consumer kernels, wherein the inserted instructions cause the producer kernel to indicate when a dependency has been resolved (see [0022]-[0023] and [0044]).
Nicol et al. (U.S. Pub. No. 2019/0138373) teaches data flow processing models a computation process based on a data flow graph, where the nodes include processing tasks (e.g., kernels) and the arcs describe the flow of data between nodes, and synchronization between kernels may use semaphores (see [0025]).
Takeda (U.S. Pub. No. 2020/0310937) teaches an API for creating a nodes for tasks, for creating a graph from the nodes, and for executing a task graph process (see [0037]). It further teaches creating a mutex associated with an allocated remote procedure call node (RPC), and using the mutex for managing forward dependencies of the allocated RPC node (see [0102]-[0107]).
Dixon et al. (U.S. Pub. No. 2009/0217294) teaches it is known in the art how to combine multiple API calls into a single API call to perform the same operations as the multiple API call, as multiple API calls may be inefficient (see [0006]).
McCloghrie et al. (U.S. Patent No. 6,286,052) teaches one of ordinary skill in the art would recognize two or more API calls may be combined into a single call, or that any one call may be broken down into multiple calls (see Col. 19, lines 58-63).
Nickolls et al. (U.S. Patent No. 7,861,060) teaches it is known in the art that communication between a CPU and GPU can be managed by a driver program on the CPU that supports an API which defines function calls supported by the GPU, and a programmer invokes those functions using calls from the API in an application program, and particulars of the API such as names and parameters of particular function calls are a matter of design choice, such that a person of ordinary skill in the art is capable of creating suitable APIs (see Col. 25 line 65-Col. 26, line 61).
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: 9:00 am - 5: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
Prosecution Insights