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 .
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.
Applicant is advised that this Double Patenting rejection will not be held in abeyance. See MPEP § 804(I)(B)(1); 37 CFR § 1.111(b).
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 2, 3, 6, 10, 25, 26, and 28 of U.S. Patent No. 12,182,635. Although the claims at issue are not identical, they are not patentably distinct from each other because all of the features of the instant claims can be found in the conflicting claims, and thus are anticipated by those claims.
Instant Claims
Claims of U.S. Patent 12,182,635
1. A processor comprising: a register; and processing circuitry that, when in operation, is configured to: read, by a first thread executing on the processor, a thread ID for a second thread stored in the register corresponding to a resource; overwrite, by the first thread, the thread ID for the second thread with a thread ID for the first thread; sleep, by the first thread; wake, by the first thread, based on a wake message sent by a third thread upon release of the resource, the third thread having read the thread ID for the first thread from the register after the first thread was sleeping; and execute, by the first thread, a task that uses the resource based on waking from the wake message sent by the third thread.
1. A system comprising: a memory controller configured to maintain a datastore representing a lock of a resource; and a hybrid threading processor (HTP) configured to execute a first thread to: obtain a lock value from the datastore (as discussed in the 103 rejection below, the examiner takes Official Notice that register memory was well known in the art); responsive to the lock value corresponding to a thread identifier of a second thread and indicating that the resource is locked: store the thread identifier of the second thread obtained from the lock value in the first thread; write a second thread identifier corresponding to the first thread into the lock value in the datastore to replace the thread identifier for the second thread in the lock value; and sleep the first thread, the thread identifier being a unique destination value for the second thread, threads of the HTP each having a different thread identifier from each other; continue execution using the resource based on a first wake message corresponding to the resource, wherein the first wake message originated from a third thread and granted the first thread the lock without interacting with the lock value in the datastore; and release the lock by sending a second wake message to the second thread based on the thread identifier stored in the first thread to awake the second thread to use the resource, the first thread being a link in a last-in-first-out (LIFO) chain that includes the second thread and the third thread, and wherein any thread that writes a thread identifier to the lock value does not have the lock when the thread identifier is written to the lock value.
2. The processor of claim 1, wherein the processing circuitry is configured to: complete, by the first thread, the task; and send, by the first thread, a wake message to the second thread to indicate that the resource is no longer in use by the first thread.
1. A system comprising: a memory controller configured to maintain a datastore representing a lock of a resource; and a hybrid threading processor (HTP) configured to execute a first thread to: obtain a lock value from the datastore; responsive to the lock value corresponding to a thread identifier of a second thread and indicating that the resource is locked: store the thread identifier of the second thread obtained from the lock value in the first thread; write a second thread identifier corresponding to the first thread into the lock value in the datastore to replace the thread identifier for the second thread in the lock value; and sleep the first thread, the thread identifier being a unique destination value for the second thread, threads of the HTP each having a different thread identifier from each other; continue execution using the resource based on a first wake message corresponding to the resource, wherein the first wake message originated from a third thread and granted the first thread the lock without interacting with the lock value in the datastore; and release the lock by sending a second wake message to the second thread based on the thread identifier stored in the first thread to awake the second thread to use the resource, the first thread being a link in a last-in-first-out (LIFO) chain that includes the second thread and the third thread, and wherein any thread that writes a thread identifier to the lock value does not have the lock when the thread identifier is written to the lock value.
3. The processor of claim 2, wherein the thread ID for the second thread is maintained in a data space for the first thread until the wake message to the second thread is sent.
1. A system comprising: a memory controller configured to maintain a datastore representing a lock of a resource; and a hybrid threading processor (HTP) configured to execute a first thread to: obtain a lock value from the datastore; responsive to the lock value corresponding to a thread identifier of a second thread and indicating that the resource is locked: store the thread identifier of the second thread obtained from the lock value in the first thread; write a second thread identifier corresponding to the first thread into the lock value in the datastore to replace the thread identifier for the second thread in the lock value; and sleep the first thread, the thread identifier being a unique destination value for the second thread, threads of the HTP each having a different thread identifier from each other; continue execution using the resource based on a first wake message corresponding to the resource, wherein the first wake message originated from a third thread and granted the first thread the lock without interacting with the lock value in the datastore; and release the lock by sending a second wake message to the second thread based on the thread identifier stored in the first thread to awake the second thread to use the resource, the first thread being a link in a last-in-first-out (LIFO) chain that includes the second thread and the third thread, and wherein any thread that writes a thread identifier to the lock value does not have the lock when the thread identifier is written to the lock value.
4. The processor of claim 1, wherein the thread ID for the second thread is overwritten in the register prior to the second thread getting access to the resource.
1. A system comprising: a memory controller configured to maintain a datastore representing a lock of a resource; and a hybrid threading processor (HTP) configured to execute a first thread to: obtain a lock value from the datastore; responsive to the lock value corresponding to a thread identifier of a second thread and indicating that the resource is locked: store the thread identifier of the second thread obtained from the lock value in the first thread; write a second thread identifier corresponding to the first thread into the lock value in the datastore to replace the thread identifier for the second thread in the lock value; and sleep the first thread, the thread identifier being a unique destination value for the second thread, threads of the HTP each having a different thread identifier from each other; continue execution using the resource based on a first wake message corresponding to the resource, wherein the first wake message originated from a third thread and granted the first thread the lock without interacting with the lock value in the datastore; and release the lock by sending a second wake message to the second thread based on the thread identifier stored in the first thread to awake the second thread to use the resource, the first thread being a link in a last-in-first-out (LIFO) chain that includes the second thread and the third thread, and wherein any thread that writes a thread identifier to the lock value does not have the lock when the thread identifier is written to the lock value.
5. The processor of claim 1, wherein the register is sixty-four bits.
3. The system of claim 2, wherein the datastore is sixty-four bits.
6. The processor of claim 1, wherein the first thread and the second thread are links in a last-in-first-out (LIFO) chain that includes at least one other thread.
1. A system comprising: a memory controller configured to maintain a datastore representing a lock of a resource; and a hybrid threading processor (HTP) configured to execute a first thread to: obtain a lock value from the datastore; responsive to the lock value corresponding to a thread identifier of a second thread and indicating that the resource is locked: store the thread identifier of the second thread obtained from the lock value in the first thread; write a second thread identifier corresponding to the first thread into the lock value in the datastore to replace the thread identifier for the second thread in the lock value; and sleep the first thread, the thread identifier being a unique destination value for the second thread, threads of the HTP each having a different thread identifier from each other; continue execution using the resource based on a first wake message corresponding to the resource, wherein the first wake message originated from a third thread and granted the first thread the lock without interacting with the lock value in the datastore; and release the lock by sending a second wake message to the second thread based on the thread identifier stored in the first thread to awake the second thread to use the resource, the first thread being a link in a last-in-first-out (LIFO) chain that includes the second thread and the third thread, and wherein any thread that writes a thread identifier to the lock value does not have the lock when the thread identifier is written to the lock value.
7. The processor of claim 6, wherein threads that make up the LIFO chain read the register to access the resource while the resource is being used by a primary thread, and wherein a different LIFO chain is created when a different thread than the primary thread holds the resource when a new thread reads the register to access the resource.
1. A system comprising: a memory controller configured to maintain a datastore representing a lock of a resource; and a hybrid threading processor (HTP) configured to execute a first thread to: obtain a lock value from the datastore; responsive to the lock value corresponding to a thread identifier of a second thread and indicating that the resource is locked: store the thread identifier of the second thread obtained from the lock value in the first thread; write a second thread identifier corresponding to the first thread into the lock value in the datastore to replace the thread identifier for the second thread in the lock value; and sleep the first thread, the thread identifier being a unique destination value for the second thread, threads of the HTP each having a different thread identifier from each other; continue execution using the resource based on a first wake message corresponding to the resource, wherein the first wake message originated from a third thread and granted the first thread the lock without interacting with the lock value in the datastore; and release the lock by sending a second wake message to the second thread based on the thread identifier stored in the first thread to awake the second thread to use the resource, the first thread being a link in a last-in-first-out (LIFO) chain that includes the second thread and the third thread, and wherein any thread that writes a thread identifier to the lock value does not have the lock when the thread identifier is written to the lock value.
8. The processor of claim 1, wherein the register can hold exactly three types of values, a first type that indicates that no thread is using the resource, a second type that is a thread ID of a thread waiting to use the resource, and a third type that indicates that the resource is in use without identifying a thread that is using the resource.
2. The system of claim 1, wherein contents of the datastore correspond to one of unlocked, locked, or a thread identifier, wherein contents that correspond to locked and the thread identifier indicate that the resource is locked.
9. The processor of claim 8, wherein a given thread that encounters the first type uses the resource immediately.
6. The system of claim 5, wherein the second value is unlocked, and wherein the action includes the HTP configured to execute the fourth thread to: set the lock by changing contents of the datastore to locked; and continue execution including using the resource based on the second value being unlocked.
10. The processor of claim 9, wherein the given thread reads the register upon completion of use of the resource to get a next thread ID to send a wake message to enable a next thread to use the resource.
10. The system of claim 8, wherein the HTP configured to execute the fourth thread to: determine that the current value is a second thread identifier; and send a third wake message that includes the second thread identifier to awake another thread to use the resource.
11. The processor of claim 9, wherein a given thread that encounters the second type or the third type waits until a wake message from a different thread to use the resource, the different thread having used the resource prior to the given thread.
6. The system of claim 5, wherein the second value is unlocked, and wherein the action includes the HTP configured to execute the fourth thread to: set the lock by changing contents of the datastore to locked; and continue execution including using the resource based on the second value being unlocked.
12. A non-transitory machine readable media including instructions that, when executed by processing circuitry of a processor, cause the processing circuitry to perform operations comprising: reading, by a first thread, a thread ID for a second thread stored in a register corresponding to a resource; overwriting, by the first thread, the thread ID for the second thread with a thread ID for the first thread; sleeping, by the first thread; waking, by the first thread, based on a wake message sent by a third thread upon release of the resource, the third thread having read the thread ID for the first thread from the register after the first thread was sleeping; and executing, by the first thread, a task that uses the resource based on waking from the wake message sent by the third thread.
25. Non-transitory machine readable media including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations comprising: obtaining, by a first thread executing in processing circuitry, a lock value from a datastore representing a lock of a resource; responsive to the lock value corresponding to a thread identifier of a second thread and indicating that the resource is locked: storing the thread identifier of the second thread obtained from the lock value in the first thread; writing a second thread identifier corresponding to the first thread into the lock value in the datastore to replace the thread identifier for the second thread in the lock value; and sleeping the first thread, the thread identifier being a unique destination value for the second thread, threads of the processing circuitry each having a different thread identifier from each other; continuing execution of the first thread using the resource based on a first wake message corresponding to the resource, wherein the first wake message originated from a third thread and granted the first thread the lock without interacting with the lock value in the datastore; and releasing the lock by sending a second wake message, from the first thread, to the second thread based on the thread identifier stored in the first thread to awake the second thread to use the resource, the first thread being a link in a last-in-first-out (LIFO) chain that includes the second thread and the third thread, and wherein any thread that writes a thread identifier to the lock value does not have the lock when the thread identifier is written to the lock value.
13. The non-transitory machine readable media of claim 12, wherein the operations comprise: completing the task; and sending a wake message to the second thread to indicate that the resource is no longer in use by the first thread.
25. Non-transitory machine readable media including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations comprising: obtaining, by a first thread executing in processing circuitry, a lock value from a datastore representing a lock of a resource; responsive to the lock value corresponding to a thread identifier of a second thread and indicating that the resource is locked: storing the thread identifier of the second thread obtained from the lock value in the first thread; writing a second thread identifier corresponding to the first thread into the lock value in the datastore to replace the thread identifier for the second thread in the lock value; and sleeping the first thread, the thread identifier being a unique destination value for the second thread, threads of the processing circuitry each having a different thread identifier from each other; continuing execution of the first thread using the resource based on a first wake message corresponding to the resource, wherein the first wake message originated from a third thread and granted the first thread the lock without interacting with the lock value in the datastore; and releasing the lock by sending a second wake message, from the first thread, to the second thread based on the thread identifier stored in the first thread to awake the second thread to use the resource, the first thread being a link in a last-in-first-out (LIFO) chain that includes the second thread and the third thread, and wherein any thread that writes a thread identifier to the lock value does not have the lock when the thread identifier is written to the lock value.
14. The non-transitory machine readable media of claim 13, wherein the thread ID for the second thread is maintained in a data space for the first thread until the wake message to the second thread is sent.
25. Non-transitory machine readable media including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations comprising: obtaining, by a first thread executing in processing circuitry, a lock value from a datastore representing a lock of a resource; responsive to the lock value corresponding to a thread identifier of a second thread and indicating that the resource is locked: storing the thread identifier of the second thread obtained from the lock value in the first thread; writing a second thread identifier corresponding to the first thread into the lock value in the datastore to replace the thread identifier for the second thread in the lock value; and sleeping the first thread, the thread identifier being a unique destination value for the second thread, threads of the processing circuitry each having a different thread identifier from each other; continuing execution of the first thread using the resource based on a first wake message corresponding to the resource, wherein the first wake message originated from a third thread and granted the first thread the lock without interacting with the lock value in the datastore; and releasing the lock by sending a second wake message, from the first thread, to the second thread based on the thread identifier stored in the first thread to awake the second thread to use the resource, the first thread being a link in a last-in-first-out (LIFO) chain that includes the second thread and the third thread, and wherein any thread that writes a thread identifier to the lock value does not have the lock when the thread identifier is written to the lock value.
15. The non-transitory machine readable media of claim 12, wherein the thread ID for the second thread is overwritten in the register prior to the second thread getting access to the resource.
25. Non-transitory machine readable media including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations comprising: obtaining, by a first thread executing in processing circuitry, a lock value from a datastore representing a lock of a resource; responsive to the lock value corresponding to a thread identifier of a second thread and indicating that the resource is locked: storing the thread identifier of the second thread obtained from the lock value in the first thread; writing a second thread identifier corresponding to the first thread into the lock value in the datastore to replace the thread identifier for the second thread in the lock value; and sleeping the first thread, the thread identifier being a unique destination value for the second thread, threads of the processing circuitry each having a different thread identifier from each other; continuing execution of the first thread using the resource based on a first wake message corresponding to the resource, wherein the first wake message originated from a third thread and granted the first thread the lock without interacting with the lock value in the datastore; and releasing the lock by sending a second wake message, from the first thread, to the second thread based on the thread identifier stored in the first thread to awake the second thread to use the resource, the first thread being a link in a last-in-first-out (LIFO) chain that includes the second thread and the third thread, and wherein any thread that writes a thread identifier to the lock value does not have the lock when the thread identifier is written to the lock value.
16. The non-transitory machine readable media of claim 12, wherein the first thread and the second thread are links in a last-in-first-out (LIFO) chain that includes at least one other thread.
25. Non-transitory machine readable media including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations comprising: obtaining, by a first thread executing in processing circuitry, a lock value from a datastore representing a lock of a resource; responsive to the lock value corresponding to a thread identifier of a second thread and indicating that the resource is locked: storing the thread identifier of the second thread obtained from the lock value in the first thread; writing a second thread identifier corresponding to the first thread into the lock value in the datastore to replace the thread identifier for the second thread in the lock value; and sleeping the first thread, the thread identifier being a unique destination value for the second thread, threads of the processing circuitry each having a different thread identifier from each other; continuing execution of the first thread using the resource based on a first wake message corresponding to the resource, wherein the first wake message originated from a third thread and granted the first thread the lock without interacting with the lock value in the datastore; and releasing the lock by sending a second wake message, from the first thread, to the second thread based on the thread identifier stored in the first thread to awake the second thread to use the resource, the first thread being a link in a last-in-first-out (LIFO) chain that includes the second thread and the third thread, and wherein any thread that writes a thread identifier to the lock value does not have the lock when the thread identifier is written to the lock value.
17. The non-transitory machine readable media of claim 16, wherein threads that make up the LIFO chain read the register to access the resource while the resource is being used by a primary thread, and wherein a different LIFO chain is created when a different thread than the primary thread holds the resource when a new thread reads the register to access the resource.
25. Non-transitory machine readable media including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations comprising: obtaining, by a first thread executing in processing circuitry, a lock value from a datastore representing a lock of a resource; responsive to the lock value corresponding to a thread identifier of a second thread and indicating that the resource is locked: storing the thread identifier of the second thread obtained from the lock value in the first thread; writing a second thread identifier corresponding to the first thread into the lock value in the datastore to replace the thread identifier for the second thread in the lock value; and sleeping the first thread, the thread identifier being a unique destination value for the second thread, threads of the processing circuitry each having a different thread identifier from each other; continuing execution of the first thread using the resource based on a first wake message corresponding to the resource, wherein the first wake message originated from a third thread and granted the first thread the lock without interacting with the lock value in the datastore; and releasing the lock by sending a second wake message, from the first thread, to the second thread based on the thread identifier stored in the first thread to awake the second thread to use the resource, the first thread being a link in a last-in-first-out (LIFO) chain that includes the second thread and the third thread, and wherein any thread that writes a thread identifier to the lock value does not have the lock when the thread identifier is written to the lock value.
18. The non-transitory machine readable media of claim 12, wherein the register can hold exactly three types of values, a first type that indicates that no thread is using the resource, a second type that is a thread ID of a thread waiting to use the resource, and a third type that indicates that the resource is in use without identifying a thread that is using the resource.
26. The non-transitory machine readable media of claim 25, wherein contents of the datastore correspond to one of unlocked, locked, or a thread identifier, wherein contents that correspond to locked and the thread identifier indicate that the resource is locked.
19. The non-transitory machine readable media of claim 18, wherein a given thread that encounters the first type uses the resource immediately.
28. The non-transitory machine readable media of claim 27, wherein the second value is unlocked, and wherein the action includes: setting the lock by changing contents of the datastore to locked; and continuing execution of the fourth thread including using the resource based on the second value being unlocked.
20. The non-transitory machine readable media of claim 19, wherein the given thread reads the register upon completion of use of the resource to get a next thread ID to send a wake message to enable a next thread to use the resource.
10. The system of claim 8, wherein the HTP configured to execute the fourth thread to: determine that the current value is a second thread identifier; and send a third wake message that includes the second thread identifier to awake another thread to use the resource.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Shah et al. (U.S. Patent Application Publication Number 2005/0055593) and Michael et al. (U.S. Patent Application Publication Number 2005/0066064).
Regarding Claim 1, Shah discloses a processor (Figure 5, item 500, paragraph 0051) comprising:
a memory (Figure 5, item 550, paragraph 0046; i.e., Shah discloses a memory 550 but does not expressly state that the memory is a register; the examiner takes Official Notice that register memory was well known in the art); and
processing circuitry (Figure 5, items 530 and 540, paragraphs 0048-0049) that, when in operation, is configured to:
read, by a first thread executing on the processor, a thread ID (paragraph 0018) for a second thread stored in the register corresponding to a resource (Figure 1, item 120, paragraphs 0016-0017);
overwrite the thread ID for the second thread with a thread ID for the first thread (paragraph 0048; i.e., the first thread ID can be prioritized by being placed at the front of the queue, overwriting any other thread ID that was already there);
sleep, by the first thread (paragraph 0036; i.e., the first thread may be temporarily prevented from executing [i.e., is paused, which is equivalent to the claimed “sleep” - see instant application at paragraph 0098]);
wake, by the first thread, based on a wake message sent by a third thread (Figure 5, item 540) upon release of the resource, the third thread having read the thread ID for the first thread from the register after the first thread was sleeping (paragraph 0049; i.e., the first thread is notified [awoken, since it was previously paused/placed in an sleep state] that the lock is available); and
execute, by the first thread, a task that uses the resource based on waking from the wake message sent by the third thread (paragraphs 0005 and 0049; i.e., the first thread can execute its desired task after it is awoken by the third thread [i.e., the lock releaser 540 thread]).
Shah does not expressly disclose the first thread overwrites the thread ID for the second thread with a thread ID for the first thread.
In the same field of endeavor (e.g., shared resource locking techniques), Michael teaches the first thread overwrites the thread ID for the second thread with a thread ID for the first thread (Figure 3, item 350, paragraph 0035; i.e., the acquiring process [the “first thread”] replaces the old ID [the ID of the “second thread”] with its own ID using a compare-and-swap procedure).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Michael’s teachings of shared resource locking techniques with the teachings of Shah, for the purpose of making access to the lock faster. More specifically, the first thread is able to immediately place its ID into the queue rather than having to wait for a separate component to do so.
Regarding Claims 2 and 13, Shah discloses wherein the processing circuitry is configured to:
complete, by the first thread, the task; and
send, by the first thread, a wake message to the second thread to indicate that the resource is no longer in use by the first thread (Figure 2, item 255, paragraph 0036).
Regarding Claims 3 and 14, Shah discloses wherein the thread ID for the second thread is maintained in a data space for the first thread until the wake message to the second thread is sent (Figure 5, item 550, paragraph 0046).
Regarding Claims 4 and 15, Michael teaches wherein the thread ID for the second thread is overwritten in the register prior to the second thread getting access to the resource (paragraph 0035; i.e., the old thread could be “dead” and therefore never have accessed the resource).
Regarding Claim 5, Shah discloses that the memory/register contains a number of bits (paragraph 0018; i.e., the thread IDs may be address values, unique thread identifier values, or some other values, which would take the form of bits in the type of system disclosed in Shah). However, Shah does not expressly disclose wherein the register is sixty-four bits. It has been held that "where the general conditions of a claim are disclosed in the prior art, it is not inventive to discover the optimum or workable ranges by routine experimentation." In re Aller, 220 F.2d 454, 456, 105 USPQ 233, 235 (CCPA 1955). Therefore, it would have been obvious to one of ordinary skill in the art to have made the register sixty-four bits depending on the specific design requirements of the system.
Regarding Claims 6 and 16, Shah discloses wherein the first thread and the second thread are links in a chain that includes at least one other thread (paragraph 0032). Shah does not expressly disclose a last-in-first-out (LIFO) chain, however states that the chain may use any scheme. The examiner takes Official Notice that LIFO is a well known type of scheme for queues.
Regarding Claims 7 and 17, Shah discloses wherein threads that make up the LIFO chain read the register to access the resource while the resource is being used by a primary thread (Figure 1, item 120, paragraphs 0016-0017), and wherein a different LIFO chain is created when a different thread than the primary thread holds the resource when a new thread reads the register to access the resource (paragraphs 0004-0005; i.e., different queues/chains can be created for the resources).
Regarding Claims 8 and 18, Shah discloses wherein the register can hold exactly three types of values, a first type that indicates that no thread is using the resource, a second type that is a thread ID of a thread waiting to use the resource, and a third type that indicates that the resource is in use without identifying a thread that is using the resource (paragraph 0018).
Regarding Claims 9 and 19, Shah discloses wherein a given thread that encounters the first type uses the resource immediately (Figure 2, items 220 and 230, paragraphs 0019 and 0030-0031).
Regarding Claims 10 and 20, Shah discloses wherein the given thread reads the register upon completion of use of the resource to get a next thread ID to send a wake message to enable a next thread to use the resource (Figure 5, item 597, paragraph 0049).
Regarding Claim 11, Shah discloses wherein a given thread that encounters the second type or the third type waits until a wake message from a different thread to use the resource, the different thread having used the resource prior to the given thread (paragraphs 0036 and 0049).
Regarding Claim 12, Shah discloses a non-transitory machine readable media (paragraph 0053) including instructions that, when executed by processing circuitry of a processor (Figure 5, item 500, paragraph 0051), cause the processing circuitry to perform operations comprising:
reading, by a first thread, a thread ID (paragraph 0018) for a second thread stored in a memory (Figure 5, item 550, paragraph 0046; i.e., Shah discloses a memory 550 but does not expressly state that the memory is a register; the examiner takes Official Notice that register memory was well known in the art) corresponding to a resource (Figure 1, item 120, paragraphs 0016-0017);
overwriting the thread ID for the second thread with a thread ID for the first thread (paragraph 0048; i.e., the first thread ID can be prioritized by being placed at the front of the queue, overwriting any other thread ID that was already there);
sleeping, by the first thread (paragraph 0036; i.e., the first thread may be temporarily prevented from executing [i.e., is paused, which is equivalent to the claimed “sleep” - see instant application at paragraph 0098]);
waking, by the first thread, based on a wake message sent by a third thread (Figure 5, item 540) upon release of the resource, the third thread having read the thread ID for the first thread from the register after the first thread was sleeping (paragraph 0049; i.e., the first thread is notified [awoken, since it was previously paused/placed in an sleep state] that the lock is available); and
executing, by the first thread, a task that uses the resource based on waking from the wake message sent by the third thread (paragraphs 0005 and 0049; i.e., the first thread can execute its desired task after it is awoken by the third thread [i.e., the lock releaser 540 thread]).
Shah does not expressly disclose the first thread overwrites the thread ID for the second thread with a thread ID for the first thread.
In the same field of endeavor, Michael teaches the first thread overwrites the thread ID for the second thread with a thread ID for the first thread (Figure 3, item 350, paragraph 0035; i.e., the acquiring process [the “first thread”] replaces the old ID [the ID of the “second thread”] with its own ID using a compare-and-swap procedure).
The motivation discussed above with regards to Claim 1 applies equally as well to Claim 12.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure because each reference discloses a method for performing chained locking for a shared resource.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FAISAL M ZAMAN whose telephone number is (571)272-6495. The examiner can normally be reached Monday - Friday, 8 am - 5 pm, alternate Fridays.
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, Andrew J. Jung can be reached at 571-270-3779. 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.
/FAISAL M ZAMAN/ Primary Examiner, Art Unit 2175
Prosecution Insights