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 .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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,7,8,14,15 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 6820261 B1, Bloch, 1999-07-14 in view of CN 106681836 A, Wang, 2016-12-28 and US 8032884 B2, Parekh, 2006-10-31.
Bloch teaches the following substantially as claimed.
1. A computer-implemented method for thread management, comprising:
creating a first thread,
Page 9, Column 2, line 11: In a threading mechanism, the present invention is a system and method for providing automatic value inheritance when a parent thread creates a child thread. Upon the creation of a child thread, the system iterates over all of the inheritable thread-local values associated with the parent thread and initializes the child's values of these inheritable thread-local values, based on an appropriate childValue method.
It is implicit from the description of the parent (first) thread creating a child (second) thread that it would have been created.
(… ) and the first thread has a first thread context;
Page 9, Column 2, line 11: In a threading mechanism, the present invention is a system and method for providing automatic value inheritance when a parent thread creates a child thread. Upon the creation of a child thread, the system iterates over all of the inheritable thread-local values associated with the parent thread and initializes the child's values of these inheritable thread-local values, based on an appropriate childValue method.
This application’s specification describes context as including thread-local variables (values).
creating a second thread through the first thread,
Page 9, Column 2, line 11: In a threading mechanism, the present invention is a system and method for providing automatic value inheritance when a parent thread creates a child thread. Upon the creation of a child thread, the system iterates over all of the inheritable thread-local values associated with the parent thread and initializes the child's values of these inheritable thread-local values, based on an appropriate childValue method.
(…) and the second thread inherits the first thread context;
Page 9, Column 2, line 11: In a threading mechanism, the present invention is a system and method for providing automatic value inheritance when a parent thread creates a child thread. Upon the creation of a child thread, the system iterates over all of the inheritable thread-local values associated with the parent thread and initializes the child's values of these inheritable thread-local values, based on an appropriate childValue method.
Bloch does not teach the following.
wherein the first thread is a kernel-level thread,
Wang does however.
Page 1, Paragraph 3: multiple threads concurrently access the signal quantity mechanism is divided into two types, one type is the user state signal quantity synchronization mechanism, multiple user state thread contention request user state of signal quantity, guaranteeing the order when the plurality of user mode threads concurrently access data access. the other type is the kernel of the signal quantity synchronization mechanism, applying kernel signal quantity of the plurality of kernel threads, ensures that the plurality of kernel threads concurrent sequential access data access.
Page 3, Paragraph 2: the second thread is the two kinds of thread A, and different from the type of the first thread. when the first thread is a user thread, the second thread is a kernel thread, the first thread is a kernel thread, the second thread is a user thread
Bloch does not teach the following.
wherein the second thread is a user-level thread,
Page 1, Paragraph 3: Wang does however.
multiple threads concurrently access the signal quantity mechanism is divided into two types, one type is the user state signal quantity synchronization mechanism, multiple user state thread contention request user state of signal quantity, guaranteeing the order when the plurality of user mode threads concurrently access data access. the other type is the kernel of the signal quantity synchronization mechanism, applying kernel signal quantity of the plurality of kernel threads, ensures that the plurality of kernel threads concurrent sequential access data access.
Page 3, Paragraph 2: the second thread is the two kinds of thread A, and different from the type of the first thread. when the first thread is a user thread, the second thread is a kernel thread, the first thread is a kernel thread, the second thread is a user thread
Bloch does not teach the following.
after the second thread is stored in a run queue,
Parekh does however.
Page 10, Column 3, line 9: Each processor 304 comprises a local run queue 314 and a handoff state variable 315. Each processor local run queue, e.g., 314-1, 314-2, . . . , 314-P, represents a local run queue to that particular processor. Runnable threads awaiting execution by processor 304 may be stored in local run queue 314. Processor 304 checks local run queue 314 and global run queue 312 for a runnable thread to be executed by the processor
Bloch does not teach the following.
controlling the first thread to enter an idle loop state;
Parekh does however.
Page 10 Column 4, line 50: processor from among processors 304-1, 304-2, . . . , 304-P enters an idle loop
Page 11, Column 5, line 1: FIG. 4 depicts a method embodiment for transferring threads. As depicted in FIG. 4, the method comprises identifying a runnable thread, as shown at 410. Identifying a runnable thread comprises a scheduler identifying a thread transitioning from a non runnable state 306 to a runnable state 310 (FIG. 3). The method further comprises looking for a processor which is idle before placing the runnable thread in a run queue, as shown at 420. Looking for a processor which is idle 420 comprises executing instructions associated with an idle hand off mechanism 317 to determine an idle processor from a number of processors using a processor search algorithm. The method further comprises transferring the runnable thread to the idle processor when an idle processor is identified, as shown at 430. If an idle processor is identified, executable instructions associated with the idle hand off mechanism execute to transfer the runnable thread directly to the idle processor without placing the runnable thread in a run queue by setting the value of a handoff state variable 315 to the handle of the runnable thread. However, according to some embodiments, when an idle processor is not identified, executable instructions, e.g., run queue mechanism instructions, execute to place the runnable thread in a run queue, e.g. a scheduler run queue 312 or a local run queue 314-1, 314-2, . . . , 314-P associated with one of a number of processors 304-1, 304-2, 304-P (FIG. 3).
Bloch does not teach the following.
and selecting the second thread from the run queue through a scheduling thread, and executing the second thread.
Parekh does however.
Page 10, Column 3, line 9: Each processor 304 comprises a local run queue 314 and a handoff state variable 315. Each processor local run queue, e.g., 314-1, 314-2, . . . , 314-P, represents a local run queue to that particular processor. Runnable threads awaiting execution by processor 304 may be stored in local run queue 314. Processor 304 checks local run queue 314 and global run queue 312 for a runnable thread to be executed by the processor
Page 9, Column 2, Line 10: Embodiments comprise systems, methods, and devices, comprising computer executable instructions for transferring threads. At least one embodiment comprises a computing system comprising a number of processors (each of the processors comprising a local run queue mechanism), a memory in communication with at least one of the number of processors, and a scheduler in communication with at least one of the number of processors. The scheduler comprises a run queue mechanism. Computer executable instructions are storable in memory and are executable on at least one of the number of processors to identify a runnable thread received by the scheduler, identify an idle processor among the number of processors, and transfer the runnable thread to the idle processor bypassing an existing local run queue of the processor.
Wang provides the context of user and kernel threads. Perekh provides a run queue, idle looping and a scheduler (scheduling thread). It would have been obvious to one skilled in the art at the time of this application’s filing to combine these elements with the design of Bloch as this would provide user-level threads access to the resources of kernel threads.
Bloch teaches the following substantially as claimed.
The following claim inherits from claim 1 and therefore inherits the same rejection.
7. The computer-implemented method of claim 1,
wherein the first thread context comprises a thread-local variable of the first thread.
Page 9, Column 2, line 11: In a threading mechanism, the present invention is a system and method for providing automatic value inheritance when a parent thread creates a child thread. Upon the creation of a child thread, the system iterates over all of the inheritable thread-local values associated with the parent thread and initializes the child's values of these inheritable thread-local values, based on an appropriate childValue method.
The following limitations correspond to those of claim 1 and therefore inherit the same rejections.
8. A non-transitory, computer-readable medium storing one or more instructions executable by a computer system to perform one or more operations, comprising:
creating a first thread, wherein the first thread is a kernel-level thread, and the first thread has a first thread context;
creating a second thread through the first thread, wherein the second thread is a user-level thread, and the second thread inherits the first thread context;
after the second thread is stored in a run queue,
controlling the first thread to enter an idle loop state;
and selecting the second thread from the run queue through a scheduling thread, and executing the second thread.
The following limitations correspond to those of claim 7 and therefore inherit the same rejections.
14. The non-transitory, computer-readable medium of claim 8, wherein the first thread context comprises a thread-local variable of the first thread.
The following limitations correspond to those of claim 1 and therefore inherit the same rejections.
15. A computer-implemented system, comprising: one or more computers; and one or more computer memory devices interoperably coupled with the one or more computers and having tangible, non-transitory, machine-readable media storing one or more instructions that, when executed by the one or more computers, perform one or more operations, comprising:
creating a first thread, wherein the first thread is a kernel-level thread, and the first thread has a first thread context;
creating a second thread through the first thread, wherein the second thread is a user-level thread, and the second thread inherits the first thread context;
after the second thread is stored in a run queue,
controlling the first thread to enter an idle loop state;
and selecting the second thread from the run queue through a scheduling thread, and executing the second thread.
Claim(s) 2,9,16 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 6820261 B1, Bloch, 1999-07-14 in view of US 8032884 B2, Parekh, 2006-10-31 and CN 106681836 A, Wang, 2016-12-28 as well as in view of GB 2449455 A, Oezer, 2008-11-26.
The following claim inherits from claim 1 and therefore inherits the same rejection.
Bloch does not teach the following.
2. The computer-implemented method of claim 1, comprising:
receiving a first signal through the scheduling thread; in response to the first signal, controlling, through the scheduling thread, the second thread to stop being executed;
Oezer does however.
Page 21, Paragraph 3: Viewed from a second aspect, the present invention provides a method of managing multiple program threads executed by processing circuitry of a data processing apparatus, the multiple program threads including at least one high priority program thread and at least one lower priority program thread, and the data processing apparatus having at least one storage unit shared between the multiple program threads and comprising multiple entries for storing information for reference by the processing circuitry when executing said program threads, the method comprising the steps of: detecting a condition indicating an adverse effect caused by a lower priority program thread being executed by the processing circuitry and resulting from sharing of the at least one storage unit between the multiple program threads; on detection of said condition, issuing an alert signal; and responsive to the alert signal, employing a scheduler to temporarily halt execution of the lower priority program thread causing said adverse effect.
Bloch does not teach the following.
and re-storing the second thread in the run queue.
Parekh does however.
(4) When a thread becomes ready for execution by a processor it is said to be a "runnable" thread. The scheduler places the runnable thread on a run queue.
Oezer provides stopping a thread in response to a signal through a scheduler (scheduling thread). Perekh provides the placing of a thread to a run queue. It would have been obvious to one skilled in the art at the time of this application’s filing to combine these elements with the design of Bloch in view of Wang and Perekh as this step would prime a second thread to run the resources of a first thread without conflict once the first thread is set to idle.
The following limitations correspond to those of claim 2 therefore inherit the same rejections.
9. The non-transitory, computer-readable medium of claim 8, comprising:
receiving a first signal through the scheduling thread; in response to the first signal, controlling, through the scheduling thread, the second thread to stop being executed;
and re-storing the second thread in the run queue.
The following limitations correspond to those of claim 2 and therefore inherit the same rejections.
16. The computer-implemented system of claim 15, comprising:
receiving a first signal through the scheduling thread; in response to the first signal, controlling, through the scheduling thread, the second thread to stop being executed;
and re-storing the second thread in the run queue.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 6820261 B1, Bloch, 1999-07-14 in view of US 8032884 B2, Parekh, 2006-10-31 and CN 106681836 A, Wang, 2016-12-28 as well as in view of GB 2449455 A, Oezer, 2008-11-26 and US 20040230794 A1, England, 2003-05-02.
Bloch does not teach the following.
The following claim inherits from claim 2 and therefore inherits the same rejection.
3. The computer-implemented method of claim 2,
wherein the first signal is triggered by a timer.
England does however.
[0094] Operating systems 134(1) and 134(2) are generally running on some hardware that supports a timer interrupt. At some point in time, the timer ticks 1302, which wakes up the operating system 134(1)'s scheduler, whereupon the scheduler stops the currently executing thread
England provides a timer to trigger stopping thread execution. It would have been obvious to one skilled in the art at the time of this application’s filing to combine this element with the design of Bloch in view of Wang, Perekh and Oezer as stopping a second thread execution and placing it in a queue in response to a signal from a timer would prime the it to run the resources of a first thread without conflict once the first thread is set to idle.
The following limitations correspond to those of claim 3 therefore inherit the same rejections.
10. The non-transitory, computer-readable medium of claim 9,
wherein the first signal is triggered by a timer.
The following limitations correspond to those of claim 3 therefore inherit the same rejections.
17. The computer-implemented system of claim 16,
wherein the first signal is triggered by a timer.
Claim(s) 4,5 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 6820261 B1, Bloch, 1999-07-14 in view of US 8032884 B2, Parekh, 2006-10-31 and CN 106681836 A, Wang, 2016-12-28 as well as in view of CN 101069161 B, NISHIKAWA, 2010-10-06. And JP 2011191901 A, NAKAJIMA, 2011-09-29.
The following claim inherits from claim 1 and therefore inherits the same rejection.
Bloch does not teach the following.
4. The computer-implemented method of claim 1, comprising:
receiving a second signal through the first thread;
Nishikawa does however.
[0076 the thread receives the signal of synchronous wait for interrupt state 58
Bloch does not teach the following.
in response to the second signal, marking the second thread to be in a signal interrupt state;
Nishikawa does however.
[0076] the thread (…) transferred to interrupt (suspended) state 60.
Bloch does not teach the following.
and processing the second signal through a signal processing thread.
Nakajima does however.
SOLUTION: The signal processor processing a signal received from the outside includes: a means accumulating the received signals; and a means starting a plurality of signal processing threads for processing the accumulated received signals
Nishikawa provides a thread receiving a signal as well as a thread being transferred (and thereby being marked) to an interrupt state. Nakajima provides signal processing threads. It would have been obvious to one skilled in the art at the time of this application’s filing to combine these elements with the design of Bloch in view of Wang and Perekh as placing a second thread in signal interrupt state would allow for more efficient use of resources in any intermittent period before it’s necessary to resume execution.
The following claim inherits from claim 4 and therefore inherits the same rejection.
Bloch does not teach the following.
5. The computer-implemented method of claim 4, wherein, after the marking,
the second thread to be in a signal interrupt state.
Nishikawa does however.
[0076] the thread (…) transferred to interrupt (suspended) state 60.
Nishikawa provides a thread receiving a signal as well as a thread being transferred an interrupt state. It would have been obvious to one skilled in the art at the time of this application’s filing to combine these elements with the design of Bloch in view of Wang, Perekh, and Nakajima as placing a second thread in signal interrupt state would allow for more efficient use of resources in any intermittent period before it’s necessary to resume execution.
The following limitations correspond to those of claim 4 and therefore inherit the same rejections.
11. The non-transitory, computer-readable medium of claim 8, comprising:
receiving a second signal through the first thread; in response to the second signal, marking the second thread to be in a signal interrupt state;
and processing the second signal through a signal processing thread.
The following limitations correspond to those of claim 5 therefore inherit the same rejections.
12. The non-transitory, computer-readable medium of claim 11, wherein, after the marking,
the second thread to be in a signal interrupt state.
The following limitations correspond to those of claim 4 and therefore inherit the same rejections.
18. The computer-implemented system of claim 15, comprising:
receiving a second signal through the first thread; in response to the second signal, marking the second thread to be in a signal interrupt state;
and processing the second signal through a signal processing thread.
The following limitations correspond to those of claim 5 and therefore inherit the same rejections.
19. The computer-implemented system of claim 18, wherein,
after the marking, the second thread to be in a signal interrupt state.
Claim(s) 6,13,20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 6820261 B1, Bloch, 1999-07-14 in view of US 8032884 B2, Parekh, 2006-10-31 and CN 106681836 A, Wang, 2016-12-28 as well as in view of CN 101069161 B, NISHIKAWA, 2010-10-06, JP 2011191901 A, NAKAJIMA, 2011-09-29, and JP 2000040022 A, LIANG, 2000-02-08.
The following claim inherits from claim 5 and therefore inherits the same rejection.
Bloch does not teach the following.
6. The computer-implemented method of claim 5, comprising:
determining whether the second thread is in an execution state;
Liang does however.
[0008] The present invention provides an execution multi-thread time profiling method capable of time-profiling a multi-threaded application by various methods, an execution state determination method of a selected thread, a time profiling system, and a computer-readable recording medium.
and interrupting execution of the second thread if the second thread is in the execution state.
Oezer does however.
Page 21, Paragraph 3: Viewed from a second aspect, the present invention provides a method of managing multiple program threads executed by processing circuitry of a data processing apparatus, the multiple program threads including at least one high priority program thread and at least one lower priority program thread, and the data processing apparatus having at least one storage unit shared between the multiple program threads and comprising multiple entries for storing information for reference by the processing circuitry when executing said program threads, the method comprising the steps of: detecting a condition indicating an adverse effect caused by a lower priority program thread being executed by the processing circuitry and resulting from sharing of the at least one storage unit between the multiple program threads; on detection of said condition, issuing an alert signal; and responsive to the alert signal, employing a scheduler to temporarily halt execution of the lower priority program thread causing said adverse effect.
Liang provides a determination of the execution state of a thread. Oezer provides halting the execution of a thread. It would have been obvious to one skilled in the art at the time of this application’s filing to combine these elements with the design of Bloch in view of Wang, Perekh, Nishikawa and Nakajima as interrupting a second thread after its determined to be executing would allow for more efficient use of resources in any intermittent period before it’s necessary to resume execution.
13. The non-transitory, computer-readable medium of claim 12, comprising:
determining whether the second thread is in an execution state;
and interrupting execution of the second thread if the second thread is in the execution state.
20. The computer-implemented system of claim 19, comprising:
determining whether the second thread is in an execution state;
and interrupting execution of the second thread if the second thread is in the execution state.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner
should be directed to Luke Absher whose telephone number is (571) 270-1057. The examiner can
normally be reached M-F: 8:00 am - 4:00 pm. 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 US PTO 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.
/LUCAS DONALD ABSHER/
Examiner, Art Unit 2194
/KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights