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 .
This Office Action is in response to the amendment filed on 5/7/2026. This action is made FINAL.
Claims 1, 2, 4, 6 and 22-32 are pending and they are presented for examinations.
Response to Arguments
Applicant's arguments filed regarding claim 1 (page 7-8), “Smith’s discussion of command tags likewise concerns tags or IDS that may mark, identify, order, re-order, shuffle, position, or identify commands in a command stream”… “Paltashev, like Smith, does not cure this deficiency. Paltashev’s wait command writes a value to a virtual wait register and completes when a fence value in a pared register matches or exceeds the supplied value, with compare logic checking the register and blocking GPU pipeline execution.”… “Paltashev fails to teach or reasonably suggest performing a synchronization operation based on a consumer fence value associated with processing of in-order commands, wherein the consumer fence value associated with processing of in-order commands, wherein the consumer fence value corresponds to an order position associated with the in-order command.”
The examiner would like to point out to Smith in view of Paltashev discloses the above limitation.
In particular, Smith teaches processing of in-order commands (serialized instructions) and performing synchronization operations using fence/barrier.
Paltashev also teaches processing of commands/instruction and performing synchronization operation using fence/barrier.
In addition, Paltashev explicitly discloses in Figure. 7. (shown below) fence/wait register pairs are allocated/used for synchronization purpose (emphasis added). Furthermore, the command order (i.e. command 1, command 2, command 3) correspond to fence value (i.e. fence 0, fence 1, fence 2).
PNG
media_image1.png
516
726
media_image1.png
Greyscale
Therefore, argument is not persuasive.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, both Smith and Paltashev discloses synchronization of instruction(s)/command(s) utilizing fence(s)/barrier(s). Therefore, argument is not persuasive.
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.
Claim(s) 1, 2, 4, 6, 23-26 and 28-31 is/are rejected on the ground of nonstatutory double patenting as being unpatentable over claim(s) 1-10 of U.S. Patent No. 12,067,428. Although the claims at issue are not identical, they are not patentably distinct from each other because:
Instant
Patent No. 12,067,428
1. An apparatus comprising: processing circuitry to: perform a synchronization operation based on a consumer fence value associated with processing of in-order commands, wherein the consumer fence value corresponds to an order position associated with the in-order commands.
2. The apparatus of claim 1, wherein the processing circuitry is further to execute a producer thread to generate commands and further to execute a consumer thread to process the commands, wherein the producer and consumer threads are synchronized in response to receiving an application command.
1. An apparatus to facilitate thread synchronization, comprising: one or more processors to execute a producer thread to generate a plurality of commands, execute a consumer thread to process the plurality of commands and synchronize the producer thread with the consumer thread, including updating a producer fence value upon generation of in-order commands, updating a consumer fence value upon processing of the in-order commands and performing a synchronization operation based on the consumer fence value, wherein the producer fence value and the consumer fence value each correspond to an order position of the in-order commands.
4. The apparatus of claim 2, wherein to execute the producer thread comprises to determine whether a first command of the commands is an in-order command of the in-order commands, wherein to execute the producer thread further comprises to update a producer fence value upon determining that the first command is the in-order command.
2. The apparatus of claim 1, wherein the synchronization operation synchronizes the producer thread and the consumer thread up to an in-order command associated with the consumer fence value.
3. The apparatus of claim 2, wherein the one or more processors initiate the synchronization operation receiving an application command.
4. The apparatus of claim 2, wherein executing the producer thread comprises producing a first of the plurality of commands and determining whether the first command is the in-order command.
5. The apparatus of claim 4, wherein executing the producer thread further comprises updating the producer fence value upon determining that the first command is the in-order command.
6. The apparatus of claim 4, wherein the processing circuitry is further to insert the first command into a command queue upon determining that the first command is not the in-order command, wherein to execute the consumer thread includes to retrieve the first command from a command queue, wherein to execute the consumer thread further includes to update a consumer fence value upon determining that the first command is the in-order command and execute the first command.
6. The apparatus of claim 5, further comprises inserting the first command into a command queue upon a determination that the first command is not the in-order command.
7. The apparatus of claim 6, wherein executing the consumer thread comprises retrieving the first command from the command queue.
8. The apparatus of claim 7, wherein executing the consumer thread further comprises determining whether the first command is the in-order command.
9. The apparatus of claim 8, wherein executing the consumer thread further comprises updating the consumer fence value upon determining that the first command is the in-order command.
10. The apparatus of claim 7, wherein executing the consumer thread further comprises executing the first command.
As per claims 23-31, these are method and computer-readable medium claims corresponding to the apparatus claims 1, 2, 4, and 6. Therefore, rejected based on similar rationale.
Claim(s) 22, 27 and 32 is/are rejected on the ground of nonstatutory double patenting as being unpatentable over claim(s) *** of U.S. Patent No. 12,067,428 in view of Smith (Pub 20190205244).
As per claims 22, 27 and 32. It would have been obvious to combine the teachings of Pat. No. 12,067,428 into teachings of Smith (paragraph 771) wherein graphics processor circuitry(ies) (GPUs)is/are used, because this would enhance the teachings of Pat. No. 12,067,428, since GPUs are highly threaded machines, it allows coordination of threads via fences/barriers/synchronizations.
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.
Claim(s) 1, 2, 4, 6 and 22-32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Smith (Pub 20190205244) in view of Paltashev et al. (Pub 20100110089) (hereafter Paltashev).
As per claim 1, Smith teaches:
An apparatus comprising:
processing circuitry to:
perform a synchronization operation based on a consumer fence value associated with processing of in-order commands, wherein the consumer fence value corresponds to an order position associated with the in-order commands. ([Paragraph 40], Example embodiments described herein may include computer system(s) with one or more central processor units (e.g. CPU, multicore CPU, etc.) and possibly one or more I/O unit(s) coupled to one or more memory systems that may contain one or more memory controllers and memory devices. [Paragraph 51], A CPU may use memory ordering. For example, memory ordering may be altered, controlled, modified, etc. by using one or more serializing instructions. For example, a memory barrier (also compiler barrier, memory fence, fence instruction, etc.) may be a class of (e.g. type of, prefix to, etc.) an instruction, directive, macro, routine, function, etc. that may cause hardware (e.g. CPU, etc.) and/or software (e.g. compiler, etc.) to enforce an ordering constraint (e.g. restriction, control, semantic, etc.) on memory operations (e.g. reads, writes, etc.) that may be issued (executed, scheduled, etc.) before and after the memory barrier instruction. A hardware memory barrier may be an instruction provided in different CPU architectures (e.g. Intel IA64 mfence/sfence/lfence instructions, ARMv7 dmb/dsb instructions, etc.). Other instructions (e.g. Intel CPUID instruction, ARMv7 isb, etc.) may also be serializing instructions and/or perform synchronization, etc. Different memory barrier instructions may have different functions and semantics. [Paragraph 366], In one embodiment, for example, command tags etc. may be used to mark, identify, order, re-order, shuffle, position, and/or perform ordering and/or other operations on one or more commands. For example, in one embodiment, a command tag, ID, etc. (e.g. a first 32-bit integer, an ID field, and/or other identifying number, bit field, etc.) may be used to uniquely identify a command in a command stream. (Tags may be reused, or rollover, but only one command may correspond to a tag field and be live, in use, in flight, etc. at any one time). For example, in one embodiment, an additional tag field (e.g. atomic operation tag, etc.) may be added to the command (e.g. use an additional field, use a special command format, populate an otherwise normally unused field, etc.). For example, in one embodiment, the atomic operation tag, for example, may include one or more of the following (but not limited to the following): the atomic operation number (e.g. an identifier, number, tag, ID etc. unique at any one time within the memory system); the number of commands (e.g. transactions, requests, etc.) in the atomic operation; the order of execution of commands (e.g. a number that indicates, starting with 0, the order of execution, etc.); flags, fields, data, and/or other information on any interactions with other atomic operations (e.g. if atomic operations are to be chained, linked, executed together, etc.); source identification (e.g. CPU number, stacked memory package identification, system component identification, etc; timestamp or other timing information, etc; any other information (e.g. actions to be performed on errors, hints and/or flexibility on command execution, etc.).)
Although Smith silently discloses consumer/producer fence ([Paragraph 9]).
Smith does not explicitly state consumer fence; and consumer fence value corresponds to an order position associated with the in-order commands.
Paltashev teaches consumer fence; and consumer fence value corresponds to an order position associated with the in-order commands. ([Paragraph 36], An internal wait command can be configured to write a certain value to a virtual wait register. The write can be completed when the fence value residing in a paired register matches or more than value supplied by the wait command. Special compare logic can be associated with the pairs of fence-wait registers. This command can be associated with spinlock because GPU hardware may be checking the content of the fence register until the content is updated to a desired value and block at this moment in the GPU pipeline execution. [Paragraph 54], One should note that in GPU B input stream the internal wait command may be inserted before draw commands, which are intended to use the surface rendered by GPU A. The address in this wait command can reside in the range of GPU B fence/wait register block, where actual fence/wait synchronization can be executed… Additionally, a particular producer/consumer block combination may be derived from single CPU synchronization patterns, described above. For the producer/consumer pairs, fence/wait register pairs can be assigned in consumer synchronization register block. [Paragraph 63] [Fig. 7], In GPU D 710 sync register block, the driver can be configured to allocate three pairs of fence/wait registers 712, 714, and 716 for GPU A 702, B 704, and C 706, respectively and map them to GPU D 710 context address space. In each context command stream buffer for GPU A 702, B, 704, C 706, and D 710 the driver can be configured to insert a fence command directed to a desired fence/wait pair in the GPU D 710 address space. The Fence commands 718 can be configured to follow trigger commands 720 flushing content of GPU caches to memory. Additionally, in the command stream buffer for GPU D 710, the driver can also be configured to insert internal wait commands with CSP block ID and directed to a desired register pair allocated for GPU A 702, B 704, C 706, and D 710. [Paragraph 64], Additionally, a combination of fence and wait commands executed on multiple GPUs can create a synchronization barrier 708 when all three contexts in the first three GPUs (GPU A 702, GPU B 704, and GPU C 706) reach the point where GPU D 710 starts processing command and data stream.)
It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Smith wherein synchronization operation(s) is/are performed based on a fence value associated with in-order commands (serialized commands), into teachings of Paltashev wherein the fence value is a consumer fence value and the consumer fence value corresponds to an order position, because this would enhance the teachings of Smith wherein by having the consumer fence value corresponds to an order position associated with the in-order commands (i.e. pair) via special compare logic, it allows checking of content of a fence register until appropriate/desired value to continue/synchronize/execute of the in-order commands. [Paltashev paragraph 36]
As per claim 2, rejection of claim 1 is incorporated:
Paltashev teaches wherein the processing circuitry is further to execute a producer thread to generate commands and further to execute a consumer thread to process the commands, wherein the producer and consumer threads are synchronized in response to receiving an application command. ([Paragraph 36], An internal wait command can be configured to write a certain value to a virtual wait register. The write can be completed when the fence value residing in a paired register matches or more than value supplied by the wait command. Special compare logic can be associated with the pairs of fence-wait registers. This command can be associated with spinlock because GPU hardware may be checking the content of the fence register until the content is updated to a desired value and block at this moment in the GPU pipeline execution. [Paragraph 54], One should note that in GPU B input stream the internal wait command may be inserted before draw commands, which are intended to use the surface rendered by GPU A. The address in this wait command can reside in the range of GPU B fence/wait register block, where actual fence/wait synchronization can be executed… Additionally, a particular producer/consumer block combination may be derived from single CPU synchronization patterns, described above. For the producer/consumer pairs, fence/wait register pairs can be assigned in consumer synchronization register block. [Paragraph 63] [Fig. 7], In GPU D 710 sync register block, the driver can be configured to allocate three pairs of fence/wait registers 712, 714, and 716 for GPU A 702, B 704, and C 706, respectively and map them to GPU D 710 context address space. In each context command stream buffer for GPU A 702, B, 704, C 706, and D 710 the driver can be configured to insert a fence command directed to a desired fence/wait pair in the GPU D 710 address space. The Fence commands 718 can be configured to follow trigger commands 720 flushing content of GPU caches to memory. Additionally, in the command stream buffer for GPU D 710, the driver can also be configured to insert internal wait commands with CSP block ID and directed to a desired register pair allocated for GPU A 702, B 704, C 706, and D 710. [Paragraph 64], Additionally, a combination of fence and wait commands executed on multiple GPUs can create a synchronization barrier 708 when all three contexts in the first three GPUs (GPU A 702, GPU B 704, and GPU C 706) reach the point where GPU D 710 starts processing command and data stream.)
Smith also teaches ([Paragraph 9], In another embodiment, the apparatus may be operable for receiving a read command or write command. Still yet, one or more faulty components of the apparatus maybe identified. In response to the identification of the one or more faulty components of the apparatus, at least one timing may be adjusted in connection with the read command or write command. [Paragraph 70], Code may use a read/write semaphore that may be similar to a read/write spin lock except that waiting processes are suspended instead of spinning until the semaphore becomes open. Many kernel control paths may concurrently acquire a read/write semaphore for reading; however, every writer kernel control path must have exclusive access to the protected resource. Therefore, the read/write semaphore can be acquired for writing only if no other kernel control path is holding it for either read or write access. Read/write semaphores may improve concurrency inside the kernel and may thus improve system performance. The kernel may handle all processes waiting for a read/write semaphore in strict FIFO order.)
As per claim 4, rejection of claim 2 is incorporated:
Smith teaches wherein to execute the producer thread comprises to determine whether a first command of the commands is an in-order command of the in-order commands, wherein to execute the producer thread further comprises to update a producer fence value upon determining that the first command is the in-order command. ([Paragraph 51], A CPU may use memory ordering. For example, memory ordering may be altered, controlled, modified, etc. by using one or more serializing instructions. For example, a memory barrier (also compiler barrier, memory fence, fence instruction, etc.) may be a class of (e.g. type of, prefix to, etc.) an instruction, directive, macro, routine, function, etc. that may cause hardware (e.g. CPU, etc.) and/or software (e.g. compiler, etc.) to enforce an ordering constraint (e.g. restriction, control, semantic, etc.) on memory operations (e.g. reads, writes, etc.) that may be issued (executed, scheduled, etc.) before and after the memory barrier instruction. A hardware memory barrier may be an instruction provided in different CPU architectures (e.g. Intel IA64 mfence/sfence/lfence instructions, ARMv7 dmb/dsb instructions, etc.). Other instructions (e.g. Intel CPUID instruction, ARMv7 isb, etc.) may also be serializing instructions and/or perform synchronization, etc. Different memory barrier instructions may have different functions and semantics. [Paragraph 64], In Linux, a spin lock may use a spinlock_t structure with two fields: slock, the spin lock state with 1 corresponding to unlocked, and negative values/0 corresponding to locked; break_lock, a flag that signals that a process is busy waiting for the lock. Macros (e.g. spin_lock, spin_unlock, spin_lock_irqsave, spin_unlock_irqrestore, etc.) may be used to initialize, test, set, etc. spin locks and may be atomic to ensure that a spin lock will be updated properly even when multiple processes running on different CPUs attempt to modify a spin lock at the same time. Spin locks may be global and therefore may be required to be protected against concurrent access. [Paragraph 65], If a kernel control path wishes to write to the data structure, the kernel control path may acquire the write version of the read/write spin lock that may grant exclusive access to the data structure. When using read/write spin locks, requests issued by kernel control paths to get/release a lock for reading (e.g. using read_lock( ), etc.) or writing (e.g. using write_lock( ), etc.) may have the same priority; readers must wait until the writer has finished; a writer must wait until all readers have finished.)
Paltashev teaches consumer/producer fence ([Paragraph 36], An internal wait command can be configured to write a certain value to a virtual wait register. The write can be completed when the fence value residing in a paired register matches or more than value supplied by the wait command. Special compare logic can be associated with the pairs of fence-wait registers. This command can be associated with spinlock because GPU hardware may be checking the content of the fence register until the content is updated to a desired value and block at this moment in the GPU pipeline execution. [Paragraph 54], One should note that in GPU B input stream the internal wait command may be inserted before draw commands, which are intended to use the surface rendered by GPU A. The address in this wait command can reside in the range of GPU B fence/wait register block, where actual fence/wait synchronization can be executed… Additionally, a particular producer/consumer block combination may be derived from single CPU synchronization patterns, described above. For the producer/consumer pairs, fence/wait register pairs can be assigned in consumer synchronization register block. [Paragraph 63] [Fig. 7], In GPU D 710 sync register block, the driver can be configured to allocate three pairs of fence/wait registers 712, 714, and 716 for GPU A 702, B 704, and C 706, respectively and map them to GPU D 710 context address space. In each context command stream buffer for GPU A 702, B, 704, C 706, and D 710 the driver can be configured to insert a fence command directed to a desired fence/wait pair in the GPU D 710 address space. The Fence commands 718 can be configured to follow trigger commands 720 flushing content of GPU caches to memory. Additionally, in the command stream buffer for GPU D 710, the driver can also be configured to insert internal wait commands with CSP block ID and directed to a desired register pair allocated for GPU A 702, B 704, C 706, and D 710. [Paragraph 64], Additionally, a combination of fence and wait commands executed on multiple GPUs can create a synchronization barrier 708 when all three contexts in the first three GPUs (GPU A 702, GPU B 704, and GPU C 706) reach the point where GPU D 710 starts processing command and data stream.)
As per claim 6, rejection of claim 4 is incorporated:
Smith teaches wherein the processing circuitry is further to insert the first command into a command queue upon determining that the first command is not the in-order command, wherein to execute the consumer thread includes to retrieve the first command from a command queue, wherein to execute the consumer thread further includes to update a consumer fence value upon determining that the first command is the in-order command and execute the first command. ([Paragraph 51], A CPU may use memory ordering. For example, memory ordering may be altered, controlled, modified, etc. by using one or more serializing instructions. For example, a memory barrier (also compiler barrier, memory fence, fence instruction, etc.) may be a class of (e.g. type of, prefix to, etc.) an instruction, directive, macro, routine, function, etc. that may cause hardware (e.g. CPU, etc.) and/or software (e.g. compiler, etc.) to enforce an ordering constraint (e.g. restriction, control, semantic, etc.) on memory operations (e.g. reads, writes, etc.) that may be issued (executed, scheduled, etc.) before and after the memory barrier instruction. A hardware memory barrier may be an instruction provided in different CPU architectures (e.g. Intel IA64 mfence/sfence/lfence instructions, ARMv7 dmb/dsb instructions, etc.). Other instructions (e.g. Intel CPUID instruction, ARMv7 isb, etc.) may also be serializing instructions and/or perform synchronization, etc. Different memory barrier instructions may have different functions and semantics. [Paragraph 70], The kernel may handle all processes waiting for a read/write semaphore in strict FIFO order. Each reader or writer that finds the semaphore closed may be inserted in the last position of a semaphore wait queue list. When the semaphore is released, the process in the first position of the wait queue list are checked. The first process is always woken. If the process is a writer, the other processes in the wait queue continue to sleep. If the process is a reader, all readers at the start of the wait queue, up to the first writer, are also woken and get the lock. However, readers that have been queued after a writer continue to sleep.)
Paltashev teaches consumer/producer fence ([Paragraph 36], An internal wait command can be configured to write a certain value to a virtual wait register. The write can be completed when the fence value residing in a paired register matches or more than value supplied by the wait command. Special compare logic can be associated with the pairs of fence-wait registers. This command can be associated with spinlock because GPU hardware may be checking the content of the fence register until the content is updated to a desired value and block at this moment in the GPU pipeline execution. [Paragraph 54], One should note that in GPU B input stream the internal wait command may be inserted before draw commands, which are intended to use the surface rendered by GPU A. The address in this wait command can reside in the range of GPU B fence/wait register block, where actual fence/wait synchronization can be executed… Additionally, a particular producer/consumer block combination may be derived from single CPU synchronization patterns, described above. For the producer/consumer pairs, fence/wait register pairs can be assigned in consumer synchronization register block. [Paragraph 63] [Fig. 7], In GPU D 710 sync register block, the driver can be configured to allocate three pairs of fence/wait registers 712, 714, and 716 for GPU A 702, B 704, and C 706, respectively and map them to GPU D 710 context address space. In each context command stream buffer for GPU A 702, B, 704, C 706, and D 710 the driver can be configured to insert a fence command directed to a desired fence/wait pair in the GPU D 710 address space. The Fence commands 718 can be configured to follow trigger commands 720 flushing content of GPU caches to memory. Additionally, in the command stream buffer for GPU D 710, the driver can also be configured to insert internal wait commands with CSP block ID and directed to a desired register pair allocated for GPU A 702, B 704, C 706, and D 710. [Paragraph 64], Additionally, a combination of fence and wait commands executed on multiple GPUs can create a synchronization barrier 708 when all three contexts in the first three GPUs (GPU A 702, GPU B 704, and GPU C 706) reach the point where GPU D 710 starts processing command and data stream.)
As per claim 22, rejection of claim 1 is incorporated:
Smith teaches wherein the processing circuitry is coupled to a memory, the processing circuitry comprising graphics processing circuitry or application processing circuitry. ([Paragraph 144], Even still, while embodiments are described where any one or more of the foregoing optional architectures, capabilities, and/or features may or may not be incorporated into a memory system, additional embodiments are contemplated where a processing unit (e.g. CPU, GPU, PIM, MIP, combinations of these and/or other similar processing functions, units, etc.) is provided in combination with or in isolation of the memory system, where such processing unit is operable to cooperate with such memory system to accommodate, cause, prompt and/or otherwise cooperate, coordinate, etc.)
As per claims 23-27, these are method claims corresponding to the apparatus claims 1, 2, 4, 6 and 22. Therefore, rejected based on similar rationale.
As per claims 28-32, these are computer-readable medium claims corresponding to the apparatus claims 1, 2, 4, 6 and 22. Therefore, rejected based on similar rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONG U KIM whose telephone number is (571)270-1313. The examiner can normally be reached 9:00am - 5:00pm.
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, Bradley Teets can be reached at 5712723338. 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.
/DONG U KIM/Primary Examiner, Art Unit 2197
Prosecution Insights