DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. Claims 1–20 are pending for examination in the reply filed on 04/22/2026.
Double Patenting
3. 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 claims at issue 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
4. 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/219,013, and further in view of Singh et al., US 9,256,467 B1 (“Singh”).
Singh is cited and applied below, to reject claims 1–20 under § 103, for teaching or suggesting the limitation “perform a first application programming interface (API) … to terminate performance of one or more software workloads identified by the first API.”
It would have been obvious to a person of ordinary skill in the art to combine the claims of the reference patent with the teachings of Singh to provide for the launching and termination of workloads.
5. Although the claims at issue are not identical, they are not patentably distinct (nonobvious) from each other, because at least some of the subject matter claimed in the instant application is already fully disclosed in the copending applications.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
For purposes of illustration, a table has been constructed below to compare the two independent system claims and exemplary dependent claims.
Instant Application No. 18/219,017
Copending Application No. 18/219,013
1. A processor, comprising: one or more circuits to
perform a first application programming interface (API), responsive to an API call including one or more arguments identifying one or more software workloads to be terminated, to select a second API, from among a plurality of candidate APIs based on the one or more arguments of the API call, to terminate performance of one or more software workloads identified by the API call; and
cause performance of the identified one or more software workloads to be terminated, via the selected second API, on multiple compute nodes connected via one or more networks.
1. A processor, comprising: one or more circuits to:
perform a first application programming interface (API), responsive to an API call including one or more arguments identifying one or more software workloads to be monitored, to select a second API, from among a plurality of candidate APIs based on the one or more arguments of the API call, to monitor performance of the one or more software workloads identified by the API call; and
obtain, via the selected second APL status information for the identified one or more software workloads running on multiple compute nodes connected via one or more networks.
2. The processor of claim 1, wherein the first API is to receive one or more input values indicating one or more job identifiers of the one or more software workloads.
2. The processor of claim 1, wherein the first API is to receive one or more input values indicating one or more job identifiers of the one or more software workloads.
…
…
7. The processor of claim 1, wherein the second API is to provide one or more output values indicating one or more statuses of the one or more software workloads based, at least in part, on performing the second API to terminate performance.
7. The processor of claim 1, wherein the second API is to provide one or more output values indicating one or more workload statuses of the one or more software workloads.
6. Claims 1–2, 8–9, and 15–16 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1–2, 9–10, and 15–16 of Copending Application No. 18/219,011, and further in view of Singh et al., US 9,256,467 B1 (“Singh”).
Singh is cited and applied below, to reject claims 1–20 under § 103, for teaching or suggesting the limitation “perform a first application programming interface (API) … to terminate performance of one or more software workloads identified by the first API.”
It would have been obvious to a person of ordinary skill in the art to combine the claims of the reference patent with the teachings of Singh to provide for the launching and termination of workloads.
7. Although the claims at issue are not identical, they are not patentably distinct (nonobvious) from each other, because at least some of the subject matter claimed in the instant application is already fully disclosed in the copending applications.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
For purposes of illustration, a table has been constructed below to compare the two independent system claims.
Instant Application No. 18/219,017
Copending Application No. 18/219,011
1. A processor, comprising: one or more circuits to
perform a first application programming interface (API), responsive to an API call including one or more arguments identifying one or more software workloads to be terminated, to select a second API, from among a plurality of candidate APIs based on the one or more arguments of the API call, to terminate performance of one or more software workloads identified by the API call; and
cause performance of the identified one or more software workloads to be terminated, via the selected second API, on multiple compute nodes connected via one or more networks.
1. A processor, comprising: one or more circuits to: perform a first application programming interface (API), responsive to an API call including one or more arguments identifying one or more software workloads to be launched, to select a second API to perform the one or more software workloads identified by the API call; and
cause the identified one or more software workloads to be launched, via the selected second API, on multiple compute nodes connected via one or more networks.
Examiner’s Remarks
8. Examiner refers to and explicitly cites particular pages, sections, figures, paragraphs or columns and lines in the references as applied to Applicant’s claims to the extent practicable to streamline prosecution.
Although the cited portions of the references are representative of the best teachings in the art and are applied to meet the specific limitations of the claims, other uncited but related teachings of the references may be equally applicable as well. It is respectfully requested that, in preparing responses to the rejections, the Applicant fully considers not only the cited portions of the references, but also the references in their entirety, as potentially teaching, suggesting or rendering obvious all or one or more aspects of the claimed invention.
Abbreviations
9. Where appropriate, the following abbreviations will be used when referencing Applicant’s submissions and specific teachings of the reference(s):
i. figure / figures: Fig. / Figs.
ii. column / columns: Col. / Cols.
iii. page / pages: p. / pp.
References Cited
10. (A) Singh et al., US 9,256,467 B1 (“Singh”).
(B) Kocyan et al., US 2009/0217311 A1 (“Kocyan”).
(C) Thaker et al., US 2015/0006318 A1 (“Thaker”) (Newly cited)
(D) Harwood et al., US 2020/0142753 A1 (“Harwood”).
Singh, Kocyan, and Harwood were cited in the previous Office action.
Notice re prior art available under both pre-AIA and AIA
11. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
A.
12. Claims 1–17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over (A) Singh in view of (B) Kocyan and (C) Thaker.
See “References Cited” section, above, for full citations of references.
13. Regarding claim 1, (A) Singh teaches/suggests the invention substantially as claimed, including:
“A processor, comprising:
one or more circuits to”
(Col. 41: code (e.g., executable instructions, one or more computer programs or one or more applications) executing collectively on one or more processors;
the Examiner notes that all processors (CPUs) have circuits);
“perform a first application programming interface (API), responsive to an API call including one or more arguments identifying one or more software workloads to be terminated … to terminate performance of one or more software workloads identified by the API call”
(Fig. 11 and Col. 29, lines 20–37: a stop task request is received that specifies a task to stop, the requestor is authenticated, and the specified task is stopped thereby freeing resources allocated to the task. In 1102, a computing resource service provider receives an application programming interface call to stop a running task. In some cases, the application programming interface call may be received from a customer or other entity external to the container service to the front end service. In other cases, the container agent may make the application programming interface call in response to a communication from a scheduler to stop a task. The Stop Task may receive, as a parameter, one or more task IDs of running tasks).
“cause performance of the identified one or more software workloads to be terminated ... on multiple compute nodes connected via one or more networks”
(Fig. 11 and Col. 29, lines 20–37: a stop task request is received that specifies a task to stop, the requestor is authenticated, and the specified task is stopped thereby freeing resources;
Col. 2, lines 5–8: creating clusters of software container instances for running software containers for customers of a computing resource service provider;
Col. 2, lines 35–38: Upon receiving a request to start the tasks of the task definition, a scheduler may determine, according to a placement scheme, which software container instances within the cluster to run the tasks;
Col. 4, lines 28–38: The container service 108 may be a service provided by the computing resource service provider 110 to allow the customer 102 to execute the containers 118 within the cluster 116. The container service 108 may be similar to the container service 200 described in conjunction with FIG. 2. The computing resource service provider 110 may be a computing resource service provider similar to the computing resource service provider 1502 described in conjunction with FIG. 15, and may provide one or more computing resource services to its customers individually or as a combination of services of a distributed computer system).
Singh does not teach “a first application programming interface (API) ... to select a second API to ….”
(B) Kocyan, in the context of Singh’s teachings, however teaches or suggests:
“a first application programming interface (API) ... to select a second API to ….”
(¶ 47: The function receiving module receives a first function call from the financial calling application 104 that sends and receives data according to a first API. The first API may be a Q Series API or an L Series API;
¶ 49: The function converting module 204 converts the first function call according to the first API into a second function call according to a second API. The second API may be the O Series API. The second function call is compatible with the second API;
¶ 41: The interface translator 110 receives the invocation of specific functions within a Vertex legacy API like the Q Series API or the L series API;
¶ 42: An adapter pattern, also known as a wrapper or wedge, is a software programming design principal which allows programs with normally incompatible interfaces to work together by wrapping an interface compatible with the calling program around the interface of the program being called;
the Examiner notes: invoking specific functions of a first API necessitates identifying or selecting a corresponding function call of a second API in order to convert the first function call according to the first API into a second function call according to a second API).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (B) Kocyan with those of (A) Singh to receive and convert a first function call to perform a specific task into a corresponding second function call with different APIs. The motivation or advantage to do so is to ensure the interoperability of the distributed and/ or virtual computing environments utilizing different computer systems, configurations, protocols, and/or interfaces.
Singh and Kocyan do not teach “a first application programming interface (API), responsive to an API call including one or more arguments ... to select a second API from among a plurality of candidate APIs based on the one or more arguments of the API call.”
(C) Thaker, in the context of Singh and Kocyan’s teachings, however teaches or suggests implementing:
“a first application programming interface (API), responsive to an API call including one or more arguments ... to select a second API from among a plurality of candidate APIs based on the one or more arguments of the API call”
(abstract: adapting legacy endpoints to modern application protocol interfaces (APIs). A legacy endpoint may provide a powerful and complex API. A modern application may desire access to the legacy endpoint. One or more layers may be added between the modern application and the legacy endpoint. Each layer may provide a different API These layers of APIs may transform the interface from a powerful and complex interface to a more limited but simpler and easier to use interface;
¶ 25: the facade module 230 may be configured to receive function calls from the service module 220, and determine the correct functions in the adapter module 240 to call to provide the results desired by the service module 220 based on the function calls received from the service module 220. The facade module 230 may then call the correct functions in the adapter module 240. After receiving the results from the adapter module 240, the facade module 230 may modify the results to conform to a format desired by the service module 220;
¶ 26: The adapter module 240 may invoke an appropriate proxy function in the proxy module 250 for processing. Invoking the proxy function may include identifying a context of the request and sending additional information to the proxy function based on the context. For example, the adapter module 240 may be configured to receive function calls from the facade module 230, and determine the correct functions in the proxy module 250 to call in order to provide the results desired by the facade module 230 based on the function calls received from the facade module 230.
To illustrate, the SEQUENCE AND PARAMETERS OF PREVIOUSLY RECEIVED CALLS may be the context of the current call, and based on the sequence and parameters of previously received calls, the desired call to the proxy function may be identified and appropriate parameters to the identified call may be generated and sent.).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (C) Thaker with those of (A) Singh and (B) Kocyan to select a second (next) function call having different APIs based on received parameters of the received first function call The motivation or advantage to do so is to adapt distributed nodes with different legacy interfaces to a single (uniform) calling interface to ensure compatibility and interoperability.
14. Regarding claim 2, Singh teaches or suggests:
“wherein the first API is to receive one or more input values indicating one or more job identifiers of the one or more software workloads”
(Fig. 11 and Col. 29, lines 20–37: a stop task request is received that specifies a task to stop, the requestor is authenticated, and the specified task is stopped thereby freeing resources allocated to the task. In 1102, a computing resource service provider receives an application programming interface call to stop a running task. In some cases, the application programming interface call may be received from a customer or other entity external to the container service to the front end service. In other cases, the container agent may make the application programming interface call in response to a communication from a scheduler to stop a task. The Stop Task may receive, as a parameter, one or more task IDs of running tasks).
15. Regarding claim 3, Singh and Kocyan teach or suggest:
“wherein the one or more software workloads are to be identified by the first API based, at least in part, on an output value of a third API to perform the one or more software workloads”
(Singh, Fig. 10 and Col. 27, lines 15–21: requestor may also specify one or more cluster IDs as parameters to the Start Task application programming interface call to indicate into which clusters the task or tasks should be started. Similarly, the requestor may specify one or more container instance IDs as parameters to the StartTask application programming interface call to indicate into which container instances the task or tasks should be started;
Col. 28, lines 47–50: As noted, launching the container image or specified application into the container instance may include generating one or more task IDs for the tasks, storing the task IDs in a data store;
Kocyan, ¶ 56: returning module 212 returns the second data result to the calling application 104 according to the first APL In one embodiment, the returning module 212 returns the second data result to the calling application 104 in response to the invocation by the calling application).
16. Regarding claim 4, Singh and Kocyan teach or suggest:
“wherein the one or more software workloads are to be identified by the first API based, at least in part, on performing a third API to launch the one or more software workloads”
(Singh, Fig. 10 and Col. 27, lines 15–21: requestor may also specify one or more cluster IDs as parameters to the Start Task application programming interface call to indicate into which clusters the task or tasks should be started. Similarly, the requestor may specify one or more container instance IDs as parameters to the StartTask application programming interface call to indicate into which container instances the task or tasks should be started;
Col. 28, lines 47–50: As noted, launching the container image or specified application into the container instance may include generating one or more task IDs for the tasks, storing the task IDs in a data store;
Kocyan, ¶ 56: returning module 212 returns the second data result to the calling application 104 according to the first APL In one embodiment, the returning module 212 returns the second data result to the calling application 104 in response to the invocation by the calling application).
17. Regarding claim 5, Singh and Thaker teach or suggest: “wherein the one or more software workloads are performed using distributed computing
system”
(Singh, Col. 2, lines 5–8: creating clusters of software container instances for running software containers for customers of a computing resource service provider;
Col. 2, lines 35–38: Upon receiving a request to start the tasks of the task definition, a scheduler may determine, according to a placement scheme, which software container instances within the cluster to run the tasks;
Col. 4, lines 28–38: The container service 108 may be a service provided by the computing resource service provider 110 to allow the customer 102 to execute the containers 118 within the cluster 116. The container service 108 may be similar to the container service 200 described in conjunction with FIG. 2. The computing resource service provider 110 may be a computing resource service provider similar to the computing resource service provider 1502 described in conjunction with FIG. 15, and may provide one or more computing resource services to its customers individually or as a combination of services of a distributed computer system;
Thaker, ¶ 48: In a networked deployment, the machine 700 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a distributed ( e.g., peer-to-peer) network environment).
18. Regarding claim 6, Singh and Thaker teach or suggest: “wherein the one or more software workloads are performed using one or more nodes of a high performance distributed computing system”
(Singh, Col. 2, lines 5–8: creating clusters of software container instances for running software containers for customers of a computing resource service provider;
Col. 2, lines 35–38: Upon receiving a request to start the tasks of the task definition, a scheduler may determine, according to a placement scheme, which software container instances within the cluster to run the tasks;
Col. 4, lines 28–38: The container service 108 may be a service provided by the computing resource service provider 110 to allow the customer 102 to execute the containers 118 within the cluster 116. The container service 108 may be similar to the container service 200 described in conjunction with FIG. 2. The computing resource service provider 110 may be a computing resource service provider similar to the computing resource service provider 1502 described in conjunction with FIG. 15, and may provide one or more computing resource services to its customers individually or as a combination of services of a distributed computer system;
Thaker, ¶ 48: In a networked deployment, the machine 700 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a distributed ( e.g., peer-to-peer) network environment).
19. Regarding claim 7, Singh and Kocyan teach or suggest:
“wherein the second API is to provide one or more output values indicating one or more statuses of the one or more software workloads based, at least in part, on performing the second API to terminate performance”
(Singh, Col. 29, line 65 to Col. 30, line 8: specified running task or tasks may be stopped and the resources previously allocated to the task or tasks may be freed/garbage collected … The requestor may also be notified that the task associated with the task ID has been successfully stopped;
Kocyan, ¶ 56: returning module 212 returns the second data result to the calling application 104 according to the first APL In one embodiment, the returning module 212 returns the second data result to the calling application 104 in response to the invocation by the calling application).
20. Regarding claims 8–14, they are a corresponding system claims reciting similar limitations of commensurate scope as the system (processor) of claims 1–7, respectively. Therefore, they are rejected on the same basis as claims 1–7 above, including the following rationale:
Singh teaches or suggests: ”one or more processors and memory to store executable instructions that, if performed by the one or more processors, cause the one or more processors to…”
(Col. 41: code (e.g., executable instructions, one or more computer programs or one or more applications) executing collectively on one or more processors;
Claim 5: one or more processors; memory including instructions that, when executed by the one or more processors).
21. Regarding claims 15–17 and 20, they are the corresponding method claims reciting similar limitations of commensurate scope as the system of claims 1–2, 4 and 7, respectively. Therefore, they are rejected on the same basis as claims 1–2, 4 and 7 above.
B.
22. Claims 18–19 are rejected under 35 U.S.C. 103 as being unpatentable over (A) Singh in view of (B) Kocyan and (C) Thaker, as applied to claims 15 above, and further in view of (D) Harwood.
23. Regarding claim 18, Singh, Kocyan, and Thaker do not teach:
“wherein the one or more software workloads are performed using a deep-learning computing system.”
(D) Harwood however teaches or suggests:
“wherein the one or more software workloads are performed using a deep-learning computing system”
(Fig. 1 and ¶ 14: The hardware accelerator devices 166 include one or more types of hardware accelerator devices including, but not limited to, GPUs, FPGAs, ASICs, TPUs, IPUs, and other types of hardware accelerator devices and systems that are configured to support high-performance computing services provided by the accelerator service platform 130;
¶ 15: The accelerator APis 162 provide libraries, drivers, pre-written code, classes, procedures, scripts, configuration data, etc., which (i) can be called or otherwise utilized by the accelerator devices 164 during execution of workloads (e.g., deep learning model training tasks) by the server nodes 160;
¶ 20: accelerator service platform 130 can be a private or public cloud computing system which implements an XaaS system to provide computing services to end-users or customers for HPC applications such as deep learning applications, machine learning).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (D) Harwood with those of Singh, Kocyan, and Thaker to request, schedule, and execute tasks on a high-performance computing environment. The motivation or advantage to do so is to provide for efficient distribution and execution of applications/tasks requiring computing servers with better performances (e.g. higher processing capability, better quality of service, reliability, etc.) and/or hardware resources optimized for specific functions (e.g. accelerators, XaaS).
24. Regarding claim 19, Harwood teaches or suggests:
“wherein the one or more software workloads are performed using one or more nodes of a deep-learning computing system”
(Fig. 1 and ¶ 14: The hardware accelerator devices 166 include one or more types of hardware accelerator devices including, but not limited to, GPUs, FPGAs, ASICs, TPUs, IPUs, and other types of hardware accelerator devices and systems that are configured to support high-performance computing services provided by the accelerator service platform 130;
¶ 15: The accelerator APis 162 provide libraries, drivers, pre-written code, classes, procedures, scripts, configuration data, etc., which (i) can be called or otherwise utilized by the accelerator devices 164 during execution of workloads (e.g., deep learning model training tasks) by the server nodes 160;
¶ 20: accelerator service platform 130 can be a private or public cloud computing system which implements an XaaS system to provide computing services to end-users or customers for HPC applications such as deep learning applications, machine learning).
Response to Arguments
25. Applicant’s arguments with respect to the claims have been considered but are moot because the arguments do not apply to any of the newly applied teachings or references being used in the current rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
(a) Wu et al., US 2023/0229527 A1, teaching processing application programming interface (API) requests. Embodiments include receiving, at an API wrapper, from a first caller, a first call to an API and sending the first call to the API.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN C WU whose telephone number is (571)270-5906. The examiner can normally be reached Monday through Friday, 8:30 A.M. to 5:00 P.M..
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, Aimee J. Li can be reached on (571)272-4169. 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.
/BENJAMIN C WU/Primary Examiner, Art Unit 2195
July 20, 2026
Prosecution Insights