DETAILED ACTION
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 .
Claims 1 – 20 are pending for examination. Claims 1, 8 and 15 are amended.
Examiner’s Note
The prior art rejection below cites particular paragraphs, columns, and/or line numbers in the references for the 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 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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/14/2026 has been entered.
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 – 5, 7 - 10, 12, and 14 - 18 of copending Application No. 18/114,628 (reference application 628) in view of in view of Rideout (US PAT 8,001531 hereinafter Rideout).
Claims 1 - 20 of current application (18/114,671 hereinafter 671)
Claims 1 - 5, 7- 10, and 14 – 18 of co-pending application (18/114,628 hereinafter 628)
1. One or more processors comprising: circuitry, respond to an application programming interface (API) call by encoding, within context information an indication of whether one or more memory operations to be performed are dependent on one or more other memory operations. (Note: 628 teaches context data structure to be context information)
2. The one or more processors of claim 1, wherein the context information is to indicate to the circuitry a context to be used to perform the one or more memory operations and the one or more other memory operations.
3. The one or more processors of claim 1, wherein the one or more memory operations are to be performed after the one or more other memory operations complete.
4. The one or more processors of claim 1, wherein the context information is to indicate to the circuitry a current context of a device to be used to perform the one or more memory operations and the one or more other memory operations.
5. The one or more processors of claim 1, wherein the indication comprises a flag to indicate to the circuitry that at least one of the one or more memory operations is to be performed synchronously.
6. The one or more processors of claim 1, wherein the indication comprises a flag to indicate to the circuitry that at least one of the one or more memory operations is to be performed asynchronously.
7. (Previously Presented) The one or more processors of claim 1, wherein the API call specifies one or more input values indicating one or more flags comprising the indication (Note: claim 1 of 628 teaches this claim).
8. (Currently Amended) A computer-implemented method comprising: responding to encoding, in response to receiving an application programming interface (API) call, by encoding, within context information, an indication within context information of whether one or more memory operations to be performed are dependent on one or more other memory operations.
(Note: 628 teaches context data structure to be context information).
9. (Previously Presented) The computer-implemented method of claim 8, wherein the context information is to indicate a context to be used to perform the one or more memory operations and the one or more other memory operations.
10. (Original) The computer-implemented method of claim 8, wherein the one or more memory operations are to be performed after the one or more other memory operations complete.
11. (Previously Presented) The computer-implemented method of claim 8, wherein the context information is to indicate a current context of a device to be used to perform the one or more memory operations and the one or more other memory operations (taught in claims 8-9 of 628).
12. (Original) The computer-implemented method of claim 8, wherein the indication comprises a flag to indicate that at least one of the one or more memory operations is to be performed synchronously (taught in claim 8 and 10 of 628).
13. (Original) The computer-implemented method of claim 8, wherein the indication comprises a flag to indicate that at least one of the one or more memory operations is to be performed asynchronously (taught in claim 10 of 628).
14. (Previously Presented) The computer-implemented method of claim 8, wherein the API call specifies one or more input values indicating one or more flags comprising the indication. (taught in claim 8 of 628)
15. A computer system comprising: one or more processors, and memory storing executable instructions that, if executed by the one or more processors to:
respond to an application programming interface (API) call by encoding, within context information, an indication ofto be performed are dependent on one or more other memory operations.
(Note: 628 teaches context data structure to be claimed context information).
16. The computer system of claim 15, wherein the context information is to indicate, to the one or more processors, a context to be used to perform the one or more memory operations and the one or more other memory operations (Note: taught in claim 15 of 628).
17. (Original) The computer system of claim 15, wherein the one or more memory operations are to be performed after the one or more other memory operations complete (taught in claims 15 and 17 of 628)
18. (Currently Amended) The computer system of claim 15, wherein the context information is to indicate, to the one or more processors, a current context of a device to be used to perform the one or more memory operations and the one or more other memory operations.
19. (Original) The computer system of claim 15, wherein the indication comprises a flag to indicate to the one or more processors that at least one of the one or more memory operations is to be performed synchronously (taught in claim 15 of 628)
.
20. (Original) The computer system of claim 15, wherein the indication comprises a flag to indicate to the one or more processors that at least one of the one or more memory operations is to be performed asynchronously.
1. One or more processors, comprising: circuitry to:
receive an application programming interface (API) call comprising an API input parameter indicating a value of a flag; and in response to the API call; cause the flag to be set to the indicated value within a primary context data structure to indicate whether one or more memory operations to be performed are dependent on one or more other memory operations, wherein the primary context data structure is a default context of an accelerator and comprises information defining behaviors of the accelerator during execution of one or more software kernels, and wherein setting the flag causes the accelerator to force a memory operation that is neither explicitly synchronous nor explicitly asynchronous to be performed synchronously such that a subsequent operation is not performed until the memory operation completes during execution of the one or more software kernels.
2. The one or more processors of claim 1, wherein the primary context data structure indicates a context to be used by one or more graphics processing units (GPUs) to perform the one or more memory operations and the one or more other memory operations.
3. The one or more processors of claim 1, wherein the one or more memory operations are to be performed by the circuitry after the one or more other memory operations complete.
7.The one or more processors of claim 1, wherein the circuitry, in response to the API call, is to receive one or more input values indicating a device to be used to perform the one or more memory operations and the one or more other memory operations.
4. The one or more processors of claim 1, wherein the flag is to indicate to the circuitry that at least one of the one or more memory operations is to be performed synchronously.
5. The one or more processors of claim 1, wherein the flag is to indicate to the circuitry that at least one of the one or more memory operations is to be performed asynchronously. one or more memory operations comprise a memory copy operation between host memory and device memory.
8. (Currently Amended) A computer-implemented method comprising: receiving an application programming interface (API) call comprising an API input parameter indicating a value of a flag; and
in response to receipt of the API call: causing the flag to be set to the indicated value in a primary context data structure to indicate whether one or more memory operations to be performed are dependent on one or more other memory operations, wherein the primary context data structure is a default context of an accelerator and comprises information defining behaviors of the accelerator during execution of one or more software kernels, and wherein setting the flag causes the accelerator to force a memory operation that is neither explicitly synchronous nor explicitly asynchronous to be performed synchronously such that a subsequent operation is not performed until the memory operation completes during execution of the one or more software kernels.
9. (Currently Amended) The computer-implemented method of claim 8, wherein the primary context data structure comprises a default context to be used by the accelerator to perform the one or more memory operations and the one or more other memory operations the accelerator comprises a graphics processing unit (GPU).
10. (Currently Amended) The computer-implemented method of The computer-implemented method of wherein the one or more memory operations comprise at least one memory operation that is not explicitly indicated to be performed either synchronously or asynchronously the accelerator is to determine, based at least on the flag, whether to perform at least one of the one or more memory operations synchronously.
14. (Currently Amended) The computer-implemented method of claim 8, wherein the API call comprises one or more input values indicating a device to be used to perform the one or more memory operations and the one or more other memory operations.
15. A computer system comprising: one or more processors and memory storing executable instructions that, if performed by the one or more processors, cause the one or more processors to: receive an application programming interface (API) call comprising an API input parameter indicating a value of a flag; and
in response to the API call:
cause the flag to be set to the indicated value within a primary context data structure to indicate whether one or more memory operations to be performed are dependent on one or more other memory operations, wherein the primary context data structure is a default context of an accelerator and comprises information defining behaviors of the accelerator during execution of one or more software kernels, and wherein setting the flag causes the accelerator to force a memory operation that is neither explicitly synchronous nor explicitly asynchronous to be performed synchronously such that a subsequent operation is not performed until the memory operation completes during execution of the one or more software kernels.
16. The computer system of claim 15, wherein the primary context data structure comprises default context to be used by the accelerator to perform the one or more memory operations and the one or more other memory operations.
17. (Original) The computer system of claim 15, wherein the one or more memory operations are to be performed by the one or more processors after the one or more other memory operations complete.
18. (Previously Presented) The computer system of claim 15, wherein the flag is to indicate to the one or more processors that at least one of the one or more memory operations is to be performed synchronously.
As to claims 1, 8 and 15, 628 does not but Rideout teaches respond to an application programming interface (API) call by encoding (“…Function call serializer 154 may be configured to serialize each graphics API call invoked by graphics application 160 and transmit the serialized API calls to host system 105 over communication link 120. As is known, serialization generally refers to a process of encoding data as an ordered sequence of bytes. The reverse operation, extracting data from a serialized stream of bytes, is referred to as de-serialization. In the context of the present invention, each graphics API call and any associated parameters, may be serialized….” Col. 7 lines 5 – 30) and (“…That is, rather than simply execute the graphics API call, the instrumented driver may identify which graphics API call was invoked by the graphics application, along with any associated parameters, and encode this information as a serialized steam of bytes…” figure 8 and associated text, especially col. 12 lines 48 – 65).
It 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 was made to modify 628 by applying the teachings of Rideout because Rideout would provide fundamental implementation to encode information/parameters to an API call to communicate with target system.
Claims 1 - 20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 – 2, 5, 8 – 9, 12, 14 - 16, and 19 of copending Application No. 18/114,664 (referred as 664) in view of Rideout (US PAT 8,001531 hereinafter Rideout).
Claims 1 – 20 of current application 18/114,671 (hereinafter 671)
Claims 1 - 2, 5, 8 – 9, 12, 14 – 16, and 19 of co-pending application 18/114,664 (hereinafter 664).
1. (Currently Amended) One or more processors comprising: circuitry to respond to an application programming interface (API) call by encoding, within context information, an indication of whether one or more memory operations to be performed are dependent on one or more other memory operations.
2.(Previously Presented) The one or more processors of claim 1, wherein the context information is to indicate to the circuitry a context to be used to perform the one or more memory operations and the one or more other memory operations (Note: taught in claim 1 of 664)
3.(Previously Presented) The one or more processors of claim 1, wherein the one or more memory operations are to be performed after the one or more other memory operations complete. (Note: taught in claim 1 of 664)
4.(Previously Presented) The one or more processors of claim 1, wherein the indication comprises a flag to indicate to the circuitry that at least one of the one or more memory operations is to be performed synchronously (Note: taught in claims 1 and 2 of 664).
5.(Previously Presented) The one or more processors of claim 1, wherein the indication comprises a flag to indicate to the circuitry that at least one of the one or more memory operations is to be performed asynchronously (Note: taught in claims 1 and 2 of 664).
6.(Previously Presented) The one or more processors of claim 1, wherein the indication comprises a flag to indicate to the circuitry that at least one of the one or more memory operations is to be performed asynchronously (Note: taught in claims 1 and 2 of 664).
7.(Previously Presented) The one or more processors of claim 1, wherein the API call specifies one or more input values indicating one or more flags comprising the indication (Note: taught in claim 1 of 664).
8. (Currently Amended) A computer-implemented method comprising: responding to an application programming interface (API) call, by encoding, within context information, an indication of whether one or more memory operations to be performed are dependent on one or more other memory operations.
9. (Previously Presented) The computer-implemented method of claim 8, wherein the context information is to indicate a context to be used to perform the one or more memory operations and the one or more other memory operations (Note: taught in claim 9 of 664).
.
10. (Original) The computer-implemented method of claim 8, wherein the one or more memory operations are to be performed after the one or more other memory operations complete (Note: taught in claim 8 of 664).
11. (Previously Presented) The computer-implemented method of claim 8, wherein the context information is to indicate a current context of a device to be used to perform the one or more memory operations and the one or more other memory operations (Note: taught in claim 9 of 664).
12. (Original) The computer-implemented method of claim 8, wherein the indication comprises a flag to indicate that at least one of the one or more memory operations is to be performed synchronously (Note: taught in claim 8 of 664).
13. (Original) The computer-implemented method of claim 8, wherein the indication comprises a flag to indicate that at least one of the one or more memory operations is to be performed asynchronously (Note: taught in claim 8 of 664).
14. (Previously Presented) The computer-implemented method of claim 8, wherein the API call specifies one or more input values indicating one or more flags comprising the indication (Note: taught in claim 8 of 664).
15. (Currently Amended) A computer system comprising: one or more processors; and memory storing executable instructions that, if executed by the one or more processors, cause the one or more processors to: respond to an application programming interface (API) call by encoding, within context information, an indication of whether one or more memory operations to be performed are dependent on one or more other memory operations.
16. (Previously Presented) The computer system of claim 15, wherein the context information is to indicate, to the one or more processors, a context to be used to perform the one or more memory operations and the one or more other memory operations.
17. (Original) The computer system of claim 15, wherein the one or more memory operations are to be performed after the one or more other memory operations complete (Note: taught in claim 15 of 664).
18. (Previously Presented) The computer system of claim 15, wherein the context information is to indicate, to the one or more processors, a current context of a device to be used to perform the one or more memory operations and the one or more other memory operations (Note: taught in claim 16 of 664).
.
19. (Original) The computer system of claim 15, wherein the indication comprises a flag to indicate to the one or more processors that at least one of the one or more memory operations is to be performed synchronously (Note: claim 15 of 664 recites synchronously).
20. (Original) The computer system of claim 15, wherein the indication comprises a flag to indicate to the one or more processors that at least one of the one or more memory operations is to be performed asynchronously (Note: claim 15 of 664 recites synchronously).
1.(Currently Amended) One or more processors comprising: circuitry to; cause, in response to an application programming interface (API) call, an indication to be read from a primary context data structure, wherein: the primary context data structure is a device primary context of a graphics processor; and
the indication comprises a context flag stored in the device primary context; and
dependent upon the indication, cause:
a next operation to be delayed until completion of at least one of one or more memory operations when the indication indicates synchronous performance, or the next operation to be performed before or while the at least one of the one or more memory operations is performed when the indication indicates asynchronous performance
2. (Currently Amended) The one or more processors of claim 1, wherein the primary context data structure indicates a context to be used by the circuitry to perform the one or more memory operations and the one or more memory operations.
5. (Currently Amended) The one or more processors of claim 1, wherein the circuitry, in further response to the API call, is to receive one or more input values indicating a device to be used to perform the one or more memory operations and the one or more memory operations.
8.(Currently Amended) A computer-implemented method comprising: in response to an application programming interface (API) call causing an indication to be read from a primary context data structure, wherein: the primary context data structure is a device primary context of a graphics processor; and the indication comprises a context flag stored in the device primary context; and dependent upon the indication, causing: a next operation to be delayed until completion of at least one of one or more memory operations when the indication indicates synchronous performance, or the next operation to be performed before or while the at least one of the one or more memory operations is performed when the indication indicates asynchronous performance
9.(Currently Amended) The computer-implemented method of claim 8, wherein the primary context data structure indicates a context to be used to perform the one or more memory operations and the one or more
12. (Currently Amended) The computer-implemented method of claim 8, wherein the API is to receive one or more input values indicating a device to be used to perform the one or more memory operations and the one or more memory operations.
14. (Currently Amended) The computer-implemented method of The computer-implemented method of wherein the API is to receive one or more input values indicating a storage location to which a state of a context to be used to perform the one or more memory operations and the one or more memory operations is to be stored.
15. (Currently Amended) A computer system comprising: one or more processors; and memory storing executable instructions that, if performed by the one or more processors, cause the computer system to: in response to an application programming interface (API) call;
cause an indication to be read from a primary context data structure, wherein: the primary context data structure is a device primary context of a graphics processor; and
the indication comprises a context flag stored in the device primary context; and dependent upon the indication, cause: a next operation to be delayed until completion of at least one of one or more memory operations when the indication indicates synchronous performance, or the next operation to be performed before or while the at least one of the one or more memory operations is performed when the indication indicates asynchronous performance
16. (Currently Amended) The computer system of claim 15, wherein the primary context data structure indicates a context to be used by the one or more processors to perform the one or more memory operations and the one or more memory operations.
19. (Currently Amended) The computer system of claim 15, wherein the executable instructions further cause the computer system, in further response to the API call, to receive one or more input values indicating a device to be used to perform the one or more memory operations and the one or more memory operations
As to claims 1, 8 and 15, 664 does not but Rideout teaches respond to an application programming interface (API) call by encoding (“…Function call serializer 154 may be configured to serialize each graphics API call invoked by graphics application 160 and transmit the serialized API calls to host system 105 over communication link 120. As is known, serialization generally refers to a process of encoding data as an ordered sequence of bytes. The reverse operation, extracting data from a serialized stream of bytes, is referred to as de-serialization. In the context of the present invention, each graphics API call and any associated parameters, may be serialized….” Col. 7 lines 5 – 30) and (“…That is, rather than simply execute the graphics API call, the instrumented driver may identify which graphics API call was invoked by the graphics application, along with any associated parameters, and encode this information as a serialized steam of bytes…” figure 8 and associated text, especially col. 12 lines 48 – 65).
It 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 was made to modify 664 by applying the teachings of Rideout because Rideout would provide fundamental implementation to encode information/parameters to an API call to communicate with target system.
Claims 1 - 20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 - 4 , 8 – 11, and 15 - 18 of copending Application No. 18/114,637 (referred as 637) in view of Rideout (US PAT 8,001531 hereinafter Rideout).
Claims 1 – 20 of current application 18/114,671 (hereinafter 671)
Claims 1 – 4, 7 – 11, 14 - 18 of co-pending application 18/114,637 (hereinafter 637)
1. (Currently Amended) One or more processors comprising: circuitry to respond to an application programming interface (API) call by encoding, within context information, an indication of whether one or more memory operations to be performed are dependent on one or more other memory operations.
2. (Previously Presented) The one or more processors of claim 1, wherein the context information is to indicate to the circuitry a context to be used to perform the one or more memory operations and the one or more other memory operations.
3. (Previously Presented) The one or more processors of claim 1, wherein the one or more memory operations are to be performed after the one or more other memory operations complete.
4. (Previously Presented) The one or more processors of claim 1, wherein the context information is to indicate to the circuitry a current context of a device to be used to perform the one or more memory operations and the one or more other memory operations.
5. (Previously Presented) The one or more processors of claim 1, wherein the indication comprises a flag to indicate to the circuitry that at least one of the one or more memory operations is to be performed synchronously (Note: taught in claim 16 of 664).
6. (Previously Presented) The one or more processors of claim 1, wherein the indication comprises a flag to indicate to the circuitry that at least one of the one or more memory operations is to be performed asynchronously (Note: taught in claim 16 of 664).
7. (Previously Presented) The one or more processors of claim 1, wherein the API call specifies one or more input values indicating one or more flags comprising the indication (Note: Claim 1 of 637 teaches this claim).
8. (Currently Amended) A computer-implemented method comprising: responding to an application programming interface (API) call, by encoding, within context information, an indication of whether one or more memory operations to be performed are dependent on one or more other memory operations.
9. (Previously Presented) The computer-implemented method of claim 8, wherein the context information is to indicate a context to be used to perform the one or more memory operations and the one or more other memory operations.
10. (Original) The computer-implemented method of claim 8, wherein the one or more memory operations are to be performed after the one or more other memory operations complete.
11. (Previously Presented) The computer-implemented method of claim 8, wherein the context information is to indicate a current context of a device to be used to perform the one or more memory operations and the one or more other memory operations.
12. (Original) The computer-implemented method of claim 8, wherein the indication comprises a flag to indicate that at least one of the one or more memory operations is to be performed synchronously (Note: this claim is taught in claim 8 of 637).
13. (Original) The computer-implemented method of claim 8, wherein the indication comprises a flag to indicate that at least one of the one or more memory operations is to be performed asynchronously (Note: this claim is taught in claim 8 of 637).
14. (Previously Presented) The computer-implemented method of claim 8, wherein the API call specifies one or more input values indicating one or more flags comprising the indication (Note: Claim 8 of 637 teaches this claim).
15. (Currently Amended) A computer system comprising: one or more processors; and memory storing executable instructions that, if executed by the one or more processors, cause the one or more processors to: respond to an application programming interface (API) call by encoding, within context information, an indication of whether one or more memory operations to be performed are dependent on one or more other memory operations.
16. (Previously Presented) The computer system of claim 15, wherein the context information is to indicate, to the one or more processors, a context to be used to perform the one or more memory operations and the one or more other memory operations.
17. (Original) The computer system of claim 15, wherein the one or more memory operations are to be performed after the one or more other memory operations complete.
18. (Previously Presented) The computer system of claim 15, wherein the context information is to indicate, to the one or more processors, a current context of a device to be used to perform the one or more memory operations and the one or more other memory operations.
19. (Original) The computer system of claim 15, wherein the indication comprises a flag to indicate to the one or more processors that at least one of the one or more memory operations is to be performed synchronously (Note: claim 15 of 664 read on this claim).
20. (Original) The computer system of claim 15, wherein the indication comprises a flag to indicate to the one or more processors that at least one of the one or more memory operations is to be performed asynchronously (Note: read on claim 15 of 664)
1. (Currently Amended) One or more processors, comprising circuitry to:
in response to receipt of an application programming interface (API) call, retrieve one or more flags from a graphics processing unit (GPU) context, wherein: the GPU context corresponds to a data structure that stores the one or more flags, the data structure associated with a subset of memory operations performed by a GPU; and the one or more flags indicate whether the subset of memory operations are to be performed synchronously or asynchronously; and return, to a device from which the API call was received, information indicating retrieval of the one or more flags.
2. (Previously Presented) The one or more processors of claim 1, wherein the one or more flags include a context flag of a context to be used by the circuitry to perform the subset of memory operations and one or more other memory operations.
3. (Previously Presented) The one or more processors of claim 1, wherein the subset of memory operations are to be performed after one or more other memory operations complete.
4. (Previously Presented) The one or more processors of claim 1, wherein the one or more flags are further to indicate a current context of a device to be used to perform the subset of memory operations and one or more other memory operations.
8.(Currently Amended) A computer-implemented method comprising: in response to an application programming interface (API) call, retrieving one or more flags from a graphics processing unit (GPU) context, wherein: the GPU context corresponds to a data structure that stores the one or more flags, the data structure associated with a subset of memory operations performed by a GPU; and the one or more flags indicate whether the subset of memory operations to be performed using the GPU context are to be performed synchronously or asynchronously; and returning, to a device from which the API call was received, information indicating retrieval of the one or more flags.
9. (Previously Presented) The computer-implemented method of claim 8, wherein the one or more flags include a context flag of a context to be used to perform the subset of memory operations and one or more other memory operations.
10.(Previously Presented) The computer-implemented method of claim 8, wherein the subset of memory operations are to be performed after one or more other memory operations complete.
11. (Previously Presented) The computer-implemented method of claim 8, wherein the one or more flags are further to indicate a current context of a device to be used to perform the subset of memory operations and one or more other memory operations.
15. (Currently Amended) A computer system comprising: one or more processors; and memory storing executable instructions that, if performed by the one or more processors, cause the computer system to: in response to an application programming interface (API) call, retrieve one or more flags [[of]] from a graphics processing unit (GPU) context, wherein: the GPU context corresponds to a data structure that stores the one or more flags, the data structure associated with a subset of memory operations performed by a GPU; and the one or more flags indicate whether a subset of memory operations to be performed using the GPU context are to be performed synchronously or asynchronously; and return, to a device from which the API call was received, information indicating retrieval of the one or more flags.
16. (Previously Presented) The computer system of claim 15, wherein the one or more flags include a context flag of a context to be used by the computer system to perform the subset of memory operations and one or more other memory operations.
17. (Previously Presented) The computer system of claim 15, wherein the subset of memory operations are to be performed after one or more other memory operations complete.
18. (Previously Presented) The computer system of claim 15, wherein the one or more flags are further to indicate a current context of a device to be used to perform the subset of operations and one or more other memory operations.
As to claims 1, 8 and 15, 637 does not but teaches Andrei does not but Rideout teaches respond to an application programming interface (API) call by encoding (“…Function call serializer 154 may be configured to serialize each graphics API call invoked by graphics application 160 and transmit the serialized API calls to host system 105 over communication link 120. As is known, serialization generally refers to a process of encoding data as an ordered sequence of bytes. The reverse operation, extracting data from a serialized stream of bytes, is referred to as de-serialization. In the context of the present invention, each graphics API call and any associated parameters, may be serialized….” Col. 7 lines 5 – 30) and (“…That is, rather than simply execute the graphics API call, the instrumented driver may identify which graphics API call was invoked by the graphics application, along with any associated parameters, and encode this information as a serialized steam of bytes…” figure 8 and associated text, especially col. 12 lines 48 – 65).
It 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 was made to modify 637 by applying the teachings of Rideout because Rideout would provide fundamental implementation to encode information/parameters to an API call to communicate with target system.
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 (i.e., changing from AIA to pre-AIA ) 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.
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 Andrei et al., (US PUB 2020/0293367 hereinafter Andrei) in view of Rideout (US PAT 8,001531 hereinafter Rideout).
Andrei reference was cited in previous office action.
As to claim 1, Andrei teaches a processor comprising:
circuitry (“..one or more integrated circuit devices...” figure 2A and para. 0048) [respond to an application programming interface (API) call by encoding within] context information (figure 16A - B, element 1603 manages context information, determines there is no dependency, and figure16B, element 1603 is updated to indicate there is a dependency in flush memory operation. Note: specification, para. 0057 – 0069, defines “context” as commands to manage context in memory operation dependencies of kernels being executed using a context on graphics processor. Element 1603 and 1613 are used to manage dependencies operations of kernels as disclosed) indication of whether one or more memory operations to be performed are dependent on one or more other memory operations (“...As shown in FIG. 16B, embodiments described herein provide a mechanism by which a dependency relationship can be declared between kernels and thread groups for those kernels can be executed without clearing the shared local memory 1520. In one embodiment, a programmer can declare that multiple kernels (e.g., kernel 0, kernel 1) have a dependency relationship. For example, kernel #1 can be declared as depending on output generated by kernel #0. The compiler for the kernel can recognize the dependency declaration and generate instructions to configure the engine block partition 1424 to bypass the flush of the shared local memory 1520...” para. 0219 - 0220).
While Andrei teaches API call (“…employs an API call…” para. 0148) directs/cause GPU to perform memory operations, Andrei does not but Rideout teaches respond to an application programming interface (API) call by encoding (“…Function call serializer 154 may be configured to serialize each graphics API call invoked by graphics application 160 and transmit the serialized API calls to host system 105 over communication link 120. As is known, serialization generally refers to a process of encoding data as an ordered sequence of bytes. The reverse operation, extracting data from a serialized stream of bytes, is referred to as de-serialization. In the context of the present invention, each graphics API call and any associated parameters, may be serialized….” Col. 7 lines 5 – 30) and (“…That is, rather than simply execute the graphics API call, the instrumented driver may identify which graphics API call was invoked by the graphics application, along with any associated parameters, and encode this information as a serialized steam of bytes…” figure 8 and associated text, especially col. 12 lines 48 – 65).
It 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 was made to modify Andrei by applying the teachings of Rideout because Rideout would provide fundamental implementation to encode information/parameters to an API call to communicate with target system.
As to claim 2, Andrei modified by Rideout teaches The one or more processors of claim 1, Andrei teaches wherein the context information is to indicate to the circuitry a context to be used to perform the one or more memory operations and the one or more other operations (“As shown in FIG. 16B, embodiments described herein provide a mechanism by which a dependency relationship can be declared between kernels and thread groups for those kernels can be executed without clearing the shared local memory 1520. In one embodiment, a programmer can declare that multiple kernels (e.g., kernel 0, kernel 1) have a dependency relationship. For example, kernel #1 can be declared as depending on output generated by kernel #0. The compiler for the kernel can recognize the dependency declaration and generate instructions to configure the engine block partition 1424 to bypass the flush of the shared local memory 1520...” para. 0221 – 0222).
As to claim 3, Andrei modified by Rideout teaches the one or more processors of claim 1, Andrei teaches wherein the one or more memory operations are to be performed after the one or more other memory operations complete (“The multi-core processor 1308 can include control logic to assist with sequencing and synchronization of data transfers and shared memory operations performed by the media processor...” para. 0207).
As to claim 4, Andrei modified by Rideout teaches the one or more processors of claim 1, Andrei teaches wherein the context information is to indicate to the circuitry a current context of a device to be used to perform the one or more memory operations and the one or more other operations (figure 16B, element 1603 which is claim context information, is updated to be current context to indicate there is a dependency in flush memory operation) and (“...As shown in FIG. 16B, embodiments described herein provide a mechanism by which a dependency relationship can be declared between kernels and thread groups for those kernels can be executed without clearing the shared local memory 1520. In one embodiment, a programmer can declare that multiple kernels (e.g., kernel 0, kernel 1) have a dependency relationship. For example, kernel #1 can be declared as depending on output generated by kernel #0. The compiler for the kernel can recognize the dependency declaration and generate instructions to configure the engine block partition 1424 to bypass the flush of the shared local memory 1520...” para. 0221 - 0222).
As to claim 5, Andrei modified by Rideout teaches The one or more processors of claim 1, Andrei teaches wherein the indication comprises a flag (“...The partition of the parallel processor can detect that the first kernel and the second kernel are interdependent, or otherwise have a dependency relationship (block 2004). A scheduler within the partition of the parallel processor can detect the interdependence between the kernels based on compiler inserted metadata or flags that are generated based on programmer inserted dependency data...” para. 0232) to indicate to the circuitry that at least one of the one or more memory operations is to be performed synchronously (“....Kernels having a dependency relationship can be executed back to back...” para. 0210) and (“...As shown in FIG. 16B, embodiments described herein provide a mechanism by which a dependency relationship can be declared between kernels and thread groups for those kernels can be executed without clearing the shared local memory 1520. In one embodiment, a programmer can declare that multiple kernels (e.g., kernel 0, kernel 1) have a dependency relationship. For example, kernel #1 can be declared as depending on output generated by kernel #0. The compiler for the kernel can recognize the dependency declaration and generate instructions to configure the engine block partition 1424 to bypass the flush of the shared local memory 1520...” para. 0221 - 0222).
As to claim 6, Andrei modified by Rideout teaches The one or more processors of claim 1, Andrei teaches wherein the indication comprises a flag (“...The partition of the parallel processor can detect that the first kernel and the second kernel are interdependent, or otherwise have a dependency relationship (block 2004). A scheduler within the partition of the parallel processor can detect the interdependence between the kernels based on compiler inserted metadata or flags that are generated based on programmer inserted dependency data...” para. 0232) to indicate to the circuitry that at least one of the one or more memory operations is to be performed asynchronously (figure 16A, element 1603 which is claim context information, determines there is no dependency) and (“..an additional method 2000 of local memory sharing between kernels. Method 2000 can be performed on a parallel processor, such as a GPGPU described...” para. 0231 and figure 20).
As to claim 7, Andrei modified by Rideout teaches The one or more processors of claim 1, Andrei teaches [wherein the API call] specifies one or more input values indicating one or more flags comprising the indication (“...As shown in FIG. 16B, embodiments described herein provide a mechanism by which a dependency relationship can be declared...” para. 0220) and (“...The partition of the parallel processor can detect that the first kernel and the second kernel are interdependent, or otherwise have a dependency relationship (block 2004). A scheduler within the partition of the parallel processor can detect the interdependence between the kernels based on compiler inserted metadata or flags that are generated based on programmer inserted dependency data...” para. 0232).
As to claim 8, this is a computer-implemented method claim of claim 1. See rejection for claim 1 above.
As to claims 9 – 14, see rejection for claims 2 – 7 above.
As to claim 15, this is a system claim of claim 1. See rejection for claim 1 above. Further, Andrei teaches one or more processors and memory storing executable instructions (“...one or more processor(s) 102 and a system memory...” figure 1 and para. 0041).
As to claims 16 – 20, see rejection for claims 2 – 6 above.
Response to Arguments
I. Reference Missing from Notice of References (pages 5 – 6 of remark).
Applicant argued
“In the Office Action, the Office introduced a new reference, Bhatti, in the rejection of claims 1-20. Office Action at 31-36. However, Bhatti does not appear in any Notice of References (PTO-892) issued by the Examiner or in any Information Disclosure Statement submitted by Applicant. Following a telephone conference with Examiner Huang on February 13, 2026, an Office Communication was mailed on February 19, 2026 (Office Communication), acknowledging the omission. Following telephone conferences on February 20, 2026, with Supervisory Examiner Young and on February 25, 2026, with Examiner Huang again, agreement was reached that Bhatti would be cited in the next PTO-892 following receipt of this response.
Yet, in the Advisory Action mailed April 9, 2026 (Advisory Action), Examiner Huang maintains that "Once the reference number is cited, it is in the record and no need to redundantly send it." Advisory Action, Continuation Sheet p.1. Applicant disagrees.
Applicant's concern is not just that the reference is "in the record," but that it appears on the face of the issued patent: When the Office of Data Management (ODM) processes an allowed patent application, references cited in Information Disclosure Statements (IDS) and PTO-892 are printed on the front page of the issued patent. Consequently, a reference cited only in an Office Communication is likely to be overlooked by the ODM and not printed on the face of the patent. Therefore, Applicant respectfully requests again that the Bhatti reference be cited in the next PTO-892 following receipt of this response to ensure that the reference will appear on the face of the issued patent.”
In response,
Reference cited in PTO-90 is still considered to be on record. As requested, examiner cites it in PTO-892.
II. Double Patenting
Applicant argued
“A. Claims 1-7 and 15-20 over Claims 1-7 and 15-20 of '628 application in View of Andrei
Claim 1-7 and 15-20 are provisionally rejected on the grounds of nonstatutory double patenting, as allegedly being unpatentable over claims 1-7 and 15-20 of co-pending '628 application in view of Andrei. Because claims 1-7, 15, 16, and 18 have been amended, Applicant respectfully submits that the rejections are now moot. Furthermore, because the claims of co- pending '628 application may change during the course of prosecution, Applicant respectfully submits that addressing the rejections at this point is premature. Accordingly, because the double patenting rejections are provisional, should these rejections be maintained in a future action, Applicant will address the rejections at a time the claims are indicated as allowable.
B. Claims 8-14 over Claims 8-14 of '628 application
Claim 8-14 are provisionally rejected on the grounds of nonstatutory double patenting as allegedly being unpatentable over claims 8-14 of co-pending '628 application. Because claims 8, 9, and 11 have been amended, Applicant respectfully submits that the rejections are now moot. Furthermore, because the claims co-pending '628 application may change during the course of prosecution, Applicant respectfully submits that addressing the rejections at this point is premature. Accordingly, because the double patenting rejections are provisional, should these rejections be maintained in a future action, Applicant will address the rejections at a time the claims are indicated as allowable.
C. Claims 1-20 over Claims 1-20 of '637 application in View of Andrei
Claim 1-20 are provisionally rejected on the grounds of nonstatutory double patenting as allegedly being unpatentable over claims 1-20 of '637 application in view of Andrei. Because claims 1-9, 11, 15, 16, and 18 have been amended, Applicant respectfully submits that the rejections are now moot. Furthermore, because the claims of the '637 application may change during the course of prosecution, Applicant respectfully submits that addressing the rejections at this point is premature. Accordingly, because the double patenting rejections are provisional, should these rejections be maintained in a future action, Applicant will address the rejections at a time the claims are indicated as allowable” (pages 6 - 7 of remark).
In response,
The amended claims are still under Double Patenting rejection.
III. Claims 1-20 Are Allowable under 35 U.S.C. § 103 over Andrei in View of Bhatti (pages 7 – 10 of remark)
Applicant’s arguments, with respect to the rejections under 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Andrei and Rideout.
Applicant argued
“Claims 1-20 stand rejected under 35 U.S.C. § 103(a) as allegedly being unpatentable over Andrei in view of Bhatt.
With regard to rejections under 35 U.S.C. § 103, the Examiner must provide evidence that, as a whole, shows that the legal determination sought to be proved (i.e., the reference teachings establish a prima facie case of obviousness) is more probable than not. M.P.E.P. § 2142. Accordingly, "the key to supporting any rejection under 35 U.S.C. § 103 is the clear articulation of the reason(s) why the claimed invention would have been obvious." M.P.E.P. § 2142; see KSR International Co. v. Teleflex, Inc., 550 U.S.398, 82 U.S.P.Q. 2d 1385, 1395-97 (2007).
A. Independent Claim 1
Applicant's claim 1 recites:
1. One or more processors comprising:
circuitry to respond to an application programming interface (API) call by encoding, within context information, an indication of whether one or more memory operations to be performed are dependent on one or more other memory operations.
Applicant respectfully submits that Andrei in view of Bhatti fails to disclose all of these features.
In particular, amended claim 1 recites, in part, "encoding, within context information, an indication of whether one or more memory operations to be performed are dependent." Example embodiments of such subject matter can be found at least in figure 13 and paragraphs [0177-90] of Applicant's originally filed specification. In the Office Action, the Office cites paragraph [0066] of Bhatti as allegedly disclosing "encode in response to receiving an application programming interface (API) call." Office Action at 32. Applicant respectfully submits that this interpretation is unreasonable under the broadest reasonable interpretation standard.
The cited portion of Bhatti describes encoding values "as an API response," but does not describe encoding "in response to" as claimed. The Office appears to be interpreting "response" as a particular thing, such as a reply, a return message, etc.; however, for that interpretation to be correct, "response" would need to be preceded by an article "a" or "the." However, as claimed, "response" is not preceded by an article, indicating that it refers to a reaction rather than a particular thing. Consequently, encoding a value as "an API response," as described by Bhatti, cannot be said to teach or suggest that the encoding occurs as a reaction as claimed. However, without conceding the propriety of the Office's rejection, Applicant has amended claim 1 to clarify that "encoding ... an indication" is performed "within context information."
For at least these reasons, Andrei in view of Bhatti is not believed to disclose each feature of Applicant's independent claim 1. Thus, Applicant respectfully submits that independent claim 1 stands allowable under 35 U.S.C. § 103 at least over Andrei in view of Bhatti and respectfully requests that the rejection of this claim be withdrawn.” (pages 7 - 8 of remark).
In response,
Amended claim 1 is taught by Andrei and Rideout. Rideout teaches amended limitation respond to API call by encoding when API call is invoked, the call with all information/parameters are encoded/serialized (Col. 7 lines 5 – 30) and (figure 8 and associated text, especially col. 12 lines 48 – 65).
B. Independent Claims 8 and 15
Applicant argued
Applicant respectfully submits that claims 8 and 15 are allowable at least for reasons including some of those discussed above in connection with claim 1. For example, claim 8 recites "responding to an application programming interface (API) call, by encoding, within context information, an indication." Likewise, claim 15 recites "respond[ing] to an application programming interface (API) call by encoding, within context information, an indication." For at least reasons discussed above, Applicant respectfully submits that the proposed combination of Andrei and Bhatti does not teach or suggest such subject matter as recited in claims 8 and 15.
Therefore, Applicant respectfully submits that claims 8 and 15 are allowable under 35 U.S.C. § 103 over Andrei in view of Bhatti.
Therefore, for at least the foregoing reasons, Applicant respectfully submits that claims 8 and 15 are allowable under 35 U.S.C. § 103 over Andrei in view of Bhatti. Withdrawal of the pending rejection under 35 U.S.C. § 103 is, therefore, respectfully requested.” (pages 8 - 9 of remark).
In response,
Examiner refers to response for claim 1 above.
IV. Dependent Claims 2-7, 9-14, and 16-20 Are Allowable Over Andrei and Bhatti
Applicant argued
“Claims 2-7, 9-14, and 16-20 each depend from one of claims 1, 8, or 15 described above. Accordingly, Applicant respectfully submits that claims 2-7, 9-14, and 16-20 are allowable at least for depending from an allowable independent claim. In addition, Applicant respectfully submits that at least some of claims 2-7, 9-14, and 16-20 additionally recite patentable subject matter not taught or otherwise rendered obvious by Andrei or Bhatti, individually or in combination.
For at least reasons discussed above, Applicant respectfully submits that claims 2-7, 9-14, and 16-20 are allowable under 35 U.S.C. § 103 over Andrei and Bhatti. Withdrawal of the pending rejections of these claims, therefore, is respectfully requested.” (page 9 of remark).
In response,
Dependent claims 2-7, 9-14, and 16-20 are rejected over Andrei and Rideout as rejected above.
Conclusion
The prior art made of record but not relied upon request is considered to be pertinent to applicant’s disclosure.
Ratan, US PAT 6,421,738, discloses method for Capturing And Encoding Full-screen Video Graphics when a graphic API call is invoked (title, abstract and figures 1 – 6).
Chodor, (US PUB 2023/0138635), discloses a method for encoding OpenCL API calls (title, abstract and figures 1 – 22B).
Levchenko, (US PUB 2020/0073939), discloses method for encoding function call with parameters and direction function (title, abstract and figures 1 – 29).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHUONG N HOANG whose telephone number is (571)272-3763. The examiner can normally be reached 9:5-30.
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.
/PHUONG N HOANG/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
