DETAILED ACTION
This action is in response to an amendment to application 16/808154, filed on 2/4/2026. Claims 1-33 are pending. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-33 are rejected under 35 U.S.C. 103 as being unpatentable over NVIDIA et al., “CUDA CUFFT LIBRARY,” PG-05327-032_V02, August, 2010, hereinafter “NVIDIA,” and USPGPUB 2008/0276220, hereinafter “Munshi.”
Regarding claim 1, NVIDIA discloses “A non-transitory machine-readable medium having stored thereon an application programming interface (API) which, (see, e.g., NVIDIA, pg. 4; “This document describes CUFFT, the NVIDIA® CUDA™ Fast Fourier Transform (FFT) library . . . with applications that include computational physics and general signal processing”; pg. 11; “CUFFT API Functions”) if called, causes one or more processors to at least:
receive, as input to the API call, a set of API input parameters indicating one or more properties of a fast Fourier transform (FFT) operation; and
(see, e.g., NVIDIA, pg. 8, 12)
PNG
media_image1.png
260
620
media_image1.png
Greyscale
PNG
media_image2.png
108
482
media_image2.png
Greyscale
PNG
media_image3.png
124
574
media_image3.png
Greyscale
select one or more FFT implementations, from a set of FFT implementations with the one or more properties indicated by the set of API input parameters based, at least in part, on one or more performance characteristics of a hardware device to perform the one or more FFT implementations, (see, e.g., NVIDIA, pg. 4; “efficiently computing discrete Fourier transforms”; pg. 22-23:
PNG
media_image4.png
389
707
media_image4.png
Greyscale
PNG
media_image5.png
245
716
media_image5.png
Greyscale
NVIDIA does not appear to disclose the further limitations “wherein selecting the one or more FFT implementations comprises querying one or more data structures including at least the set of FFT implementations using the one or more performance characteristics of the hardware device to identify one or more candidate FFT implementations, and selecting the one or more FFT implementations from the one or more candidate FFT implementations.” Stated more simply, NVIDIA does not disclose querying a data structure for hardware implementation and performance details and selecting an implementation based on the information in the data structure.
Munshi discloses (at fig. 4 & associated text; para. 38-40) “a data structure (or a compute device data structure) representing a plurality of physical compute devices associated with one or more corresponding capabilities” where an “application may send the compute capability requirement to a system application by calling APIs” and “process 400 may select a set of physical compute devices” such that the “selection may be determined based on a matching between the compute capability requirement against the compute capabilities stored in the capability data structure.”
Munshi and NVIDIA are directed toward API interprocess communication, and toward performance optimization, and therefore are analogous art. On or before the effective filing date of the instant application, one of ordinary skill in the art would have deemed it obvious to try to combine the FFT execution of NVIDIA with the hardware performance data analysis of Munshi, thereby obtaining the invention of the instant claim. A clear and predictable benefit of so combining would have appeared as the ability improve program execution optimization by providing easily referenced hardware performance data. Accordingly, the instant claim is unpatentable over the combination of NVIDIA and Munshi.
Regarding claim 2, the combination of NVIDIA and Munshi renders obvious “The non-transitory machine-readable medium of claim 1, wherein: the one or more performance characteristics are stored in a database comprising one or more parameters of the one or more FFT implementations, (see, e.g., NVIDIA, pg. 11; “FFTW provides a simple configuration mechanism called a plan that completely specifies the optimal — that is, the minimum floating point operation (flop) — plan of execution for a particular FFT size and data type. The advantage of this approach is that once the user creates a plan, the library stores whatever state is needed to execute the plan multiple times without recalculation of the configuration.”) and the database comprise[s] the one or more data structures.” (Munshi, para. 30; 38-40).
Regarding claim 3, the combination of NVIDIA and Munshi renders obvious “The non-transitory machine-readable medium of claim 2, wherein the one or more parameters include: a FFT size; (see, e.g., NVIDIA, pg. 12)
PNG
media_image2.png
108
482
media_image2.png
Greyscale
a FFT type; a precision at which the one or more FFT implementations are to be computed; (see, e.g., NVIDIA, pg. 8)
PNG
media_image1.png
260
620
media_image1.png
Greyscale
or a direction of the one or more FFT implementations.” (see, e.g., NVIDIA, pg. 8)
PNG
media_image3.png
124
574
media_image3.png
Greyscale
Regarding claim 4, the combination of NVIDIA and Munshi renders obvious “The non-transitory machine-readable medium of claim 2, wherein the one or more parameters are encoded as a placeholder type in source code and a data object to perform the one or more FFT implementations.” (see, e.g., NVIDIA pg. 23-29 “CUFFT Code Examples” provide examples of encoding additional parameters in source code and determining and using data objects to perform FFT operations).
Regarding claim 5, the combination of NVIDIA and Munshi renders obvious “The non-transitory machine-readable medium of claim 1, wherein the API is a device API that is to be performed, at least in part, by a graphics processing unit.” (see, e.g., NVIDIA, pg. 4; “leverage the floating-point power and parallelism of the GPU”).
Regarding claim 6, the combination of NVIDIA and Munshi renders obvious “The non-transitory machine-readable medium of claim 5, wherein the one or more FFT operations are to be performed on a device processor.” (see, e.g., NVIDIA, pg. 4; “leverage the floating-point power and parallelism of the GPU”).
Regarding claim 7, NVIDIA discloses “A system, comprising: one or more processors to execute instructions to implement an application programming interface (API) which, (see, e.g., NVIDIA, pg. 4; “This document describes CUFFT, the NVIDIA® CUDA™ Fast Fourier Transform (FFT) library . . . with applications that include computational physics and general signal processing”; pg. 11; “CUFFT API Functions”) if called, cause the one or more processors to at least:
receive, as input to the API call, a set of API input parameters indicating one or more properties of a fast Fourier transform (FFT) operation; and
(see, e.g., NVIDIA, pg. 8, 12)
PNG
media_image1.png
260
620
media_image1.png
Greyscale
PNG
media_image2.png
108
482
media_image2.png
Greyscale
PNG
media_image3.png
124
574
media_image3.png
Greyscale
select one or more FFT implementations from a set of FFT implementations with the one or more properties indicated by the set of API input parameters based, at least in part, on one or more performance characteristics of a hardware device to perform the one or more FFT implementations.” (see, e.g., NVIDIA, pg. 4; “efficiently computing discrete Fourier transforms”; pg. 22-23
PNG
media_image4.png
389
707
media_image4.png
Greyscale
PNG
media_image5.png
245
716
media_image5.png
Greyscale
NVIDIA does not appear to disclose the further limitations “wherein selecting the one or more FFT implementations comprises querying one or more data structures including at least the set of FFT implementations using the one or more performance characteristics of the hardware device to identify one or more candidate FFT implementations, and selecting the one or more FFT implementations from the one or more candidate FFT implementations.” Stated more simply, NVIDIA does not disclose querying a data structure for hardware implementation and performance details and selecting an implementation based on the information in the data structure.
Munshi discloses (at fig. 4 & associated text; para. 38-40) “a data structure (or a compute device data structure) representing a plurality of physical compute devices associated with one or more corresponding capabilities” where an “application may send the compute capability requirement to a system application by calling APIs” and “process 400 may select a set of physical compute devices” such that the “selection may be determined based on a matching between the compute capability requirement against the compute capabilities stored in the capability data structure.”
Munshi and NVIDIA are directed toward API interprocess communication, and toward performance optimization, and therefore are analogous art. On or before the effective filing date of the instant application, one of ordinary skill in the art would have deemed it obvious to try to combine the FFT execution of NVIDIA with the hardware performance data analysis of Munshi, thereby obtaining the invention of the instant claim. A clear and predictable benefit of so combining would have appeared as the ability improve program execution optimization by providing easily referenced hardware performance data. Accordingly, the instant claim is unpatentable over the combination of NVIDIA and Munshi.
Regarding claim 8, the combination of NVIDIA and Munshi renders obvious “The system of claim 7, wherein the one or more performance characteristics are stored in a database comprising one or more parameters of the one or more FFT implementations, (see, e.g., NVIDIA, pg. 11; “FFTW provides a simple configuration mechanism called a plan that completely specifies the optimal — that is, the minimum floating point operation (flop) — plan of execution for a particular FFT size and data type. The advantage of this approach is that once the user creates a plan, the library stores whatever state is needed to execute the plan multiple times without recalculation of the configuration.”) and the database comprises the one or more data structures.” (Munshi, para. 30; 38-40).
Regarding claim 9, the combination of NVIDIA and Munshi renders obvious “The system of claim 8, wherein the one or more parameters are encoded in a source code” (see, e.g., NVIDIA pg. 23-29 “CUFFT Code Examples”) but does not appear to disclose the further limitation “using C++11 or later.” However, on or before the effective filing date of the instant application, C++11 was known in the art as a version of the ISO/IEC standard for C++.1 Also on or before the effective filing date of the instant application, one of ordinary skill in the art would have deemed it obvious to try to implement the FFT API of NVIDIA in C++11, thereby obtaining the invention of the instant claim. A clear and predictable benefit of so combining would have appeared as the ability to use a widely-accepted standard of C++. Accordingly, the instant claim is unpatentable over the combination of NVIDIA and Munshi.
Regarding claim 10, the combination of NVIDIA and Munshi renders obvious “The system of claim 9, wherein the one or more parameters are encoded using a first keyword, and wherein the one or more FFT implementations are inferred from the one or more parameters during compilation of a source code.” (see, e.g., NVIDIA pg. 23-29 “CUFFT Code Examples” provide examples of inferring FFT implementations from source code parameters and keywords).
Regarding claim 11, the combination of NVIDIA and Munshi renders obvious “The system of claim 10, wherein the first keyword represents different data objects corresponding to different FFT implementations based, at least in part on the one or more parameters.” (see, e.g., NVIDIA pg. 23-29 “CUFFT Code Examples” provide examples of using parameters to determine and use different data objects corresponding to different FFT implementations).
Regarding claim 12, the combination of NVIDIA and Munshi renders obvious “The system of claim 9, wherein the one or more parameters include: a FFT size; (see NVIDIA, pg. 12)
PNG
media_image2.png
108
482
media_image2.png
Greyscale
a FFT type; a precision at which the one or more FFT implementations are to be computed; (see, e.g., NVIDIA, pg. 8)
PNG
media_image1.png
260
620
media_image1.png
Greyscale
or a direction of the one or more FFT implementations.” (see, e.g., NVIDIA, pg. 8)
PNG
media_image3.png
124
574
media_image3.png
Greyscale
Regarding claim 13, the combination of NVIDIA and Munshi renders obvious “The system of claim 8, wherein the one or more parameters are provided by a user as source code and used to determine a data object for the one or more FFT implementations that is not known to the user prior to compilation of the source code.” (see, e.g., NVIDIA pg. 23-29 “CUFFT Code Examples” provide examples of determining and using data objects that are not known to the user prior to compilation).
Regarding claim 14, NVIDIA discloses “A method, comprising: using an application programming interface (API) (see, e.g., NVIDIA, pg. 4; “This document describes CUFFT, the NVIDIA® CUDA™ Fast Fourier Transform (FFT) library . . . with applications that include computational physics and general signal processing”; pg. 11; “CUFFT API Functions”) to, if called:
receive, as input to the API call, a set of API input parameters indicating one or more properties of a fast Fourier transform (FFT) operation; and
(see, e.g., NVIDIA, pg. 8, 12)
PNG
media_image1.png
260
620
media_image1.png
Greyscale
PNG
media_image2.png
108
482
media_image2.png
Greyscale
PNG
media_image3.png
124
574
media_image3.png
Greyscale
select one or more FFT implementations from a set of one or more FFT implementations with the one or more properties indicated by the set of API input parameters based, at least in part, on one or more performance characteristics of a hardware device to perform the one or more FFT implementations.” (see, e.g., NVIDIA, pg. 4; “efficiently computing discrete Fourier transforms”; pg. 11; “The FFTW model works well for CUFFT because different kinds of FFTs require different thread configurations and GPU resources, and plans are a simple way to store and reuse configurations.”; pg. 22-23:
PNG
media_image4.png
389
707
media_image4.png
Greyscale
PNG
media_image5.png
245
716
media_image5.png
Greyscale
NVIDIA does not appear to disclose the further limitations “wherein selecting the one or more FFT implementations comprises querying one or more data structures including at least the set of FFT implementations using the one or more performance characteristics of the hardware device to identify one or more candidate FFT implementations, and selecting the one or more FFT implementations from the one or more candidate FFT implementations.” Stated more simply, NVIDIA does not disclose querying a data structure for hardware implementation and performance details and selecting an implementation based on the information in the data structure.
Munshi discloses (at fig. 4 & associated text; para. 38-40) “a data structure (or a compute device data structure) representing a plurality of physical compute devices associated with one or more corresponding capabilities” where an “application may send the compute capability requirement to a system application by calling APIs” and “process 400 may select a set of physical compute devices” such that the “selection may be determined based on a matching between the compute capability requirement against the compute capabilities stored in the capability data structure.”
Munshi and NVIDIA are directed toward API interprocess communication, and toward performance optimization, and therefore are analogous art. On or before the effective filing date of the instant application, one of ordinary skill in the art would have deemed it obvious to try to combine the FFT execution of NVIDIA with the hardware performance data analysis of Munshi, thereby obtaining the invention of the instant claim. A clear and predictable benefit of so combining would have appeared as the ability improve program execution optimization by providing easily referenced hardware performance data. Accordingly, the instant claim is unpatentable over the combination of NVIDIA and Munshi.
Regarding claim 15, the combination of NVIDIA and Munshi renders obvious “The method of claim 14, wherein one or more parameters indicating the one or more performance characteristics are stored in a database comprising one or more additional parameters of the one or more FFT implementations, (see, e.g., NVIDIA, pg. 11; “FFTW provides a simple configuration mechanism called a plan that completely specifies the optimal — that is, the minimum floating point operation (flop) — plan of execution for a particular FFT size and data type. The advantage of this approach is that once the user creates a plan, the library stores whatever state is needed to execute the plan multiple times without recalculation of the configuration.”) and the database comprises the one or more data structures.” (Munshi, para. 30; 38-40).
Regarding claim 16, the combination of NVIDIA and Munshi renders obvious “The method of claim 14, wherein the one or more additional parameters includes one or more configuration parameters indicating how to select the one or more FFT implementations from a plurality of FFT implementations.” (see, e.g., NVIDIA, pg. 8)
PNG
media_image1.png
260
620
media_image1.png
Greyscale
Regarding claim 17, the combination of NVIDIA and Munshi renders obvious “The method of claim 15, wherein the one or more configuration parameters includes: a graphics processing unit architecture; elements per thread; a first memory space to read from; a second memory space to write to; or a block dimension.” (see, e.g., NVIDIA, pg. 9, 23)
Regarding claim 18, the combination of NVIDIA and Munshi renders obvious “The method of claim 14, wherein the one or more FFT implementations are to be performed by one or more graphics processing units (GPUs).” (see, e.g., NVIDIA, pg. 4; “leverage the floating-point power and parallelism of the GPU”).
Regarding claim 19, the combination of NVIDIA and Munshi renders obvious “The method of claim 18, wherein the one or more operands of the one or more FFT implementations are to be loaded from one or more on-board memories of the one or more GPUs without further loading the one or more operands from global memory.” (see, e.g., NVIDIA, pg. 23)
PNG
media_image6.png
128
822
media_image6.png
Greyscale
Regarding claim 20, the combination of NVIDIA and Munshi renders obvious “The method of claim 15, wherein the one or more additional parameters encode functionality of one or more operands of the one or more FFT implementations that include one or more of: dimensionality; type; parallelism; precision; or size.”
(see, e.g., NVIDIA, pg. 8, 12)
PNG
media_image1.png
260
620
media_image1.png
Greyscale
PNG
media_image2.png
108
482
media_image2.png
Greyscale
PNG
media_image3.png
124
574
media_image3.png
Greyscale
Regarding claim 21, NVIDIA discloses “One or more processors comprising: circuitry to use an application programming interface (API) to, (see, e.g., NVIDIA, pg. 4; “This document describes CUFFT, the NVIDIA® CUDA™ Fast Fourier Transform (FFT) library . . . with applications that include computational physics and general signal processing”; pg. 11; “CUFFT API Functions”) if called:
receive, as input to the API call, a set of API input parameters indicating one or more properties of a fast Fourier transform (FFT) operation; and
(see, e.g., NVIDIA, pg. 8, 12)
PNG
media_image1.png
260
620
media_image1.png
Greyscale
PNG
media_image2.png
108
482
media_image2.png
Greyscale
PNG
media_image3.png
124
574
media_image3.png
Greyscale
select one or more FFT implementations from a set of FFT implementations with the one or more properties indicated by the set of API output parameters based, at least in part, on one or more performance characteristics of hardware device to perform the one or more FFT implementations.” (see, e.g., NVIDIA, pg. 4; “efficiently computing discrete Fourier transforms”; pg. 11; “The FFTW model works well for CUFFT because different kinds of FFTs require different thread configurations and GPU resources, and plans are a simple way to store and reuse configurations.”; pg. 22-23
PNG
media_image4.png
389
707
media_image4.png
Greyscale
PNG
media_image5.png
245
716
media_image5.png
Greyscale
NVIDIA does not appear to disclose the further limitations “wherein selecting the one or more FFT implementations comprises querying one or more data structures including at least the set of FFT implementations using the one or more performance characteristics of the hardware device to identify one or more candidate FFT implementations, and selecting the one or more FFT implementations from the one or more candidate FFT implementations.” Stated more simply, NVIDIA does not disclose querying a data structure for hardware implementation and performance details and selecting an implementation based on the information in the data structure.
Munshi discloses (at fig. 4 & associated text; para. 38-40) “a data structure (or a compute device data structure) representing a plurality of physical compute devices associated with one or more corresponding capabilities” where an “application may send the compute capability requirement to a system application by calling APIs” and “process 400 may select a set of physical compute devices” such that the “selection may be determined based on a matching between the compute capability requirement against the compute capabilities stored in the capability data structure.”
Munshi and NVIDIA are directed toward API interprocess communication, and toward performance optimization, and therefore are analogous art. On or before the effective filing date of the instant application, one of ordinary skill in the art would have deemed it obvious to try to combine the FFT execution of NVIDIA with the hardware performance data analysis of Munshi, thereby obtaining the invention of the instant claim. A clear and predictable benefit of so combining would have appeared as the ability improve program execution optimization by providing easily referenced hardware performance data. Accordingly, the instant claim is unpatentable over the combination of NVIDIA and Munshi.
Regarding claim 22, the combination of NVIDIA and Munshi renders obvious “The one or more processors of claim 21, wherein the one or more performance characteristics are stored in a database comprising one or more parameters of the one or more FFT implementations, (see, e.g., NVIDIA, pg. 11; “FFTW provides a simple configuration mechanism called a plan that completely specifies the optimal — that is, the minimum floating point operation (flop) — plan of execution for a particular FFT size and data type. The advantage of this approach is that once the user creates a plan, the library stores whatever state is needed to execute the plan multiple times without recalculation of the configuration.”) and the database comprises the one or more data structures.” (Munshi, para. 30; 38-40).
Regarding claim 23, the combination of NVIDIA and Munshi renders obvious “The one or more processors of claim 22, wherein the one or more parameters include: a FFT size; (see, NVIDIA, pg. 12)
PNG
media_image2.png
108
482
media_image2.png
Greyscale
a FFT type; a precision at which the one or more FFT implementations are to be computed; or a direction of the one or more FFT implementations.” (see, e.g., NVIDIA, pg. 8)
PNG
media_image3.png
124
574
media_image3.png
Greyscale
Regarding claim 24, the combination of NVIDIA and Munshi renders obvious “The one or more processors of claim 21, wherein the one or more performance characteristics indicate one or more operands that are to be loaded from one or more on-board memories of one or more graphics processing units (GPUs).” (see, e.g., NVIDIA, pg. 23)
PNG
media_image6.png
128
822
media_image6.png
Greyscale
Regarding claim 25, the combination of NVIDIA and Munshi renders obvious “The one or more processors of claim 23, wherein the one or more FFT implementations are stored in a database accessible to a compiler.” (see, e.g., NVIDIA, pg. 4; “This document describes CUFFT, the NVIDIA® CUDA™ Fast Fourier Transform (FFT) library . . . with applications that include computational physics and general signal processing”; pg. 11; “CUFFT API Functions”)
Regarding claim 26, the combination of NVIDIA and Munshi renders obvious “The one or more processors of claim 25, wherein the API is a device API that is to be performed at least in part by a graphics processing unit.” (see, e.g., NVIDIA, pg. 4; “leverage the floating-point power and parallelism of the GPU”).
Regarding claim 27, NVIDIA discloses “One or more processors comprising: circuitry to:
process a signal (see, e.g., NVIDIA, pg. 4; “This document describes CUFFT, the NVIDIA® CUDA™ Fast Fourier Transform (FFT) library . . . with applications that include computational physics and general signal processing”; pg. 11; “CUFFT API Functions”) based, at least in part, on performing an application programming interface (API), that, if called, is to:
receive, as input to the API call, a set of API input parameters indicating one or more properties of a fast Fourier transform (FFT) operation; and
(see, e.g., NVIDIA, pg. 8, 12)
PNG
media_image1.png
260
620
media_image1.png
Greyscale
PNG
media_image2.png
108
482
media_image2.png
Greyscale
PNG
media_image3.png
124
574
media_image3.png
Greyscale
select one or more FFT implementations from a set of FFT implementations with the one or more properties indicated by the set of API input parameters based, at least in part, on one or more performance characteristics of a hardware device to perform the one or more FFT implementations.” (see, e.g., NVIDIA, pg. 4; “efficiently computing discrete Fourier transforms”; pg. 11; “The FFTW model works well for CUFFT because different kinds of FFTs require different thread configurations and GPU resources, and plans are a simple way to store and reuse configurations.”; pg. 22-23
PNG
media_image4.png
389
707
media_image4.png
Greyscale
PNG
media_image5.png
245
716
media_image5.png
Greyscale
NVIDIA does not appear to disclose the further limitations “wherein selecting the one or more FFT implementations comprises querying one or more data structures including at least the set of FFT implementations using the one or more performance characteristics of the hardware device to identify one or more candidate FFT implementations, and selecting the one or more FFT implementations from the one or more candidate FFT implementations.” Stated more simply, NVIDIA does not disclose querying a data structure for hardware implementation and performance details and selecting an implementation based on the information in the data structure.
Munshi discloses (at fig. 4 & associated text; para. 38-40) “a data structure (or a compute device data structure) representing a plurality of physical compute devices associated with one or more corresponding capabilities” where an “application may send the compute capability requirement to a system application by calling APIs” and “process 400 may select a set of physical compute devices” such that the “selection may be determined based on a matching between the compute capability requirement against the compute capabilities stored in the capability data structure.”
Munshi and NVIDIA are directed toward API interprocess communication, and toward performance optimization, and therefore are analogous art. On or before the effective filing date of the instant application, one of ordinary skill in the art would have deemed it obvious to try to combine the FFT execution of NVIDIA with the hardware performance data analysis of Munshi, thereby obtaining the invention of the instant claim. A clear and predictable benefit of so combining would have appeared as the ability improve program execution optimization by providing easily referenced hardware performance data.
NVIDIA also does not appear to disclose the underlined portion of the following limitation: “one or more circuits to process an audio signal.” However, on or before the effective filing date of the instant application, using FFT operations to process audio signals was known in the art.2 Official Notice is hereby invoked to that effect. Also on or before the effective filing date of the instant application, one of ordinary skill in the art would have deemed it obvious to incorporate the CUFFT library of NVIDIA and Munshi with the noticed FFT audio signal processing, thereby obtaining the invention of the instant claim. A clear and predictable benefit of so combining (i.e., motivation) would have been the ability to simplify and/or improve FFT audio signal processing by, e.g. “allow[ing] users to leverage the floating-point power and parallelism of the GPU without having to develop a custom, GPU-based FFT implementation.” (NVIDIA, pg. 4). Accordingly, the instant claim is unpatentable over the combination of NVIDIA and Munshi.
Regarding claim 28, the combination of NVIDIA and Munshi renders obvious “The one or more processors of claim 27, wherein the API is a device API that is performed, at least in part, by one or more graphics processing units (GPUs).” (see, e.g., NVIDIA, pg. 4; “leverage the floating-point power and parallelism of the GPU”).
Regarding claim 29, the combination of NVIDIA and Munshi renders obvious “The one or more processors of claim 27, wherein the one or more performance characteristics are to be stored in a database comprising one or more parameters of the one or more FFT implementations, (see, e.g., NVIDIA, pg. 11; “FFTW provides a simple configuration mechanism called a plan that completely specifies the optimal — that is, the minimum floating point operation (flop) — plan of execution for a particular FFT size and data type. The advantage of this approach is that once the user creates a plan, the library stores whatever state is needed to execute the plan multiple times without recalculation of the configuration.”) and the database comprises the one or more data structures.” (Munshi, para. 30; 38-40).
Regarding claim 30, the combination of NVIDIA and Munshi renders obvious “The one or more processors of claim 29, wherein the one or more parameters include: a FFT size; (see, e.g., NVIDIA, pg. 12)
PNG
media_image2.png
108
482
media_image2.png
Greyscale
a FFT type; a precision at which the one or more FFT implementations are to be computed; (see, e.g., NVIDIA, pg. 8)
PNG
media_image1.png
260
620
media_image1.png
Greyscale
or a direction of the one or more FFT implementations.” (see, e.g., NVIDIA, pg. 8)
PNG
media_image3.png
124
574
media_image3.png
Greyscale
Regarding claim 31, the combination of NVIDIA and Munshi renders obvious “The one or more processors of claim 29, wherein the one or more FFT implementations are accessible by a compiler through one or more runtime libraries.” (see, e.g., NVIDIA, pg. 4; “This document describes CUFFT, the NVIDIA® CUDA™ Fast Fourier Transform (FFT) library.”; pg. 11; “CUFFT API Functions”).
Regarding claim 32, the combination of NVIDIA and Munshi renders obvious “The one or more processors of claim 29, wherein the one or more FFT implementations are stored in a data store.” (see, e.g., NVIDIA, pg. 4; “This document describes CUFFT, the NVIDIA® CUDA™ Fast Fourier Transform (FFT) library . . . with applications that include computational physics and general signal processing”; pg. 11; “CUFFT API Functions”)
Regarding claim 33, the combination of NVIDIA and Munshi renders obvious “The one or more processors of claim 32, wherein the API is a device API that is performed, at least in part, by one or more graphics processing units (GPUs).” (see, e.g., NVIDIA, pg. 4; “leverage the floating-point power and parallelism of the GPU”).
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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-33 of 16/808154 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-33 of copending Application No. 17/856937, claims 1-33 of copending application 17/856940, and claims 1-3 and 5-32 of copending application 17/856943. Although the claims at issue are not identical, they are not patentably distinct from each other, as demonstrated in the example claims below. This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
16/808154 (this)
17/856937
17/856940
17/856943
1. A non-transitory machine-readable medium having stored thereon an application programming interface (API), which, if called, causes one or more processors to at least:
receive, as input to the API call, a set of API input parameters indicating one or more properties of a fast Fourier transform (FFT) operation; and
select one or more FFT implementations, from a set of FFT implementations with the one or more properties indicated by the set of API input parameters based, at least in part, on one or more performance characteristics of a hardware device to perform the one or more FFT implementations, wherein selecting the one or more FFT implementations comprises querying one or more data structures including at least the set of FFT implementations using the one or more performance characteristics of the hardware device to identify one or more candidate FFT implementations, and selecting the one or more FFT implementations from the one or more candidate FFT implementations.
3. The non-transitory machine-readable medium of claim 2, wherein the one or more parameters include: a FFT size;
a FFT type;
a precision for computing the FFT;
a direction of the FFT.
1. A machine-readable medium having stored thereon a set of instructions that, when executed by one or more processors, cause the one or more processors to, in response to a call to an application programming interface (API), at least:
perform a Fast Fourier Transform (FFT) operation based on a plurality of parameters received by the API, wherein the plurality of parameters include: a precision parameter to identify a floating point precision to utilize in the FFT operation;
a dimension parameter corresponding to a dimension of the FFT operation;
a thread-limit parameter to specify a maximum number of threads to be utilized in performing the FFT operation;
a stride parameter;
a batch parameter to specify a number of transforms; and
a type parameter to specify an input of the FFT operation being complex or real, wherein performing the FFT operation comprises: selecting, based at least in part on the thread-limit parameter and performance information associated with each of a plurality of FFT implementations, an FFT implementation from the plurality of FFT implementations; and performing the FFT operation using the selected FFT implementation.
2. The machine-readable medium of claim 1, wherein the API, if performed by the one or more processors, further causes the one or more processors to at least specify a direction of the FFT operation.
1. A machine-readable medium having stored thereon a set of instructions that, when executed by one or more processors, cause the one or more processors to, in response to a call
to an application programming interface (API), at least:
perform a forward Fast Fourier Transform (FFT) operation based on a plurality of parameters received by the API, wherein the plurality of parameters include: a precision parameter to identify a floating point precision to utilize in the FFT operation;
a dimension parameter corresponding to a dimension of the FFT operation;
a thread-limit parameter to specify a maximum number of threads to be utilized in performing the FFT operation;
a stride parameter;
a batch parameter to specify a number of transforms; and
a type parameter to specify an input of the FFT operation being complex or real, wherein performing the FFT operation comprises: selecting, based at least in part on the thread-limit parameter and performance information associated with each of a plurality of FFT implementations, an FFT implementation from the plurality of FFT implementations and performing the FFT operation using the selected FFT implementation.
1. A machine-readable medium having stored thereon a set of instructions that, when executed by one or more processors, cause the one or more processors to, in response to a call
to an application programming interface (API),
at least:
perform a backward Fast Fourier Transform (FFT) operation based on a plurality of parameters received by the API, wherein the plurality of parameters include: a precision parameter to identify a floating point precision to utilize in the FFT operation;
a dimension parameter corresponding to a dimension of the FFT operation;
a thread-limit parameter to specify a maximum number of threads to be utilized in performing the FFT operation;
a stride parameter;
a batch parameter to specify a number of transforms; and
a type parameter to specify an input of the FFT operation being complex or real, wherein performing the FFT operation comprises: selecting, based at least in part on the thread-limit parameter and performance information associated with each of a plurality of FFT implementations, an FFT implementation from the plurality of FFT implementations; and performing the FFT operation using the selected FFT implementation..
Response to Arguments
Applicant makes no substantive argument in traversal of the standing non-statutory double patenting rejections, and those rejections are updated and maintained. Regarding the rejections under 35 U.S.C. 102 and 103, Applicant’s arguments in traversal have been carefully considered but are moot in view of the foregoing new grounds of rejection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RYAN D. COYER whose telephone number is (571) 270-5306 and whose fax number is (571) 270-6306. The examiner normally can be reached via phone on Monday-Friday 12pm-10pm Eastern Time. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui, can be reached on 571-272-3708. 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.
/Ryan D. Coyer/Primary Examiner, Art Unit 2191
1 https://en.wikipedia.org/wiki/C%2B%2B11
2 https://www.nti-audio.com/en/support/know-how/fast-fourier-transform-fft (2017) https://www.ap.com/news/more-about-ffts (2016)
https://processing.org/reference/libraries/sound/FFT.html (2014)