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 action is responsive to the preliminary amendment filed at 7/12/2024.
Claims 1-20 are presented for examination.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirely as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d) or (f).
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, or 365(c) is acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 9/3/2024 and 3/21/2025. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Specification
The disclosure is objected to because of the following informalities:
“in which not only a user-mode context and a kernel-mode context need to be switched, but also all scheduling statuses of a task before switching need to be processed during task switching (note: there are multiple similar issues around the whole specification, such as “Not
“a switching solution B” at line 1 of [00193] should be: a switching solution 2.
“if the second task and several consecutive tasks all initiate requests of preconfigured request types.
[00265] is identical to [00267].
Appropriate correction is required.
Claim Objections
Claims 9 and 13 are objected to because of the following informalities:
“wherein the scheduling a third task by using a native scheduling procedure” at lines 1-2 of claim 9 should be: wherein the scheduling the third task by using the native scheduling procedure.
Claim 13 is rejected for failing to cure the deficiency from its respective parent claim by dependency. In addition, claim 13 is objected due to same reason as explained at I above.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2, 5-9 and 13 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding to Claim 2, the meaning of limitation “switching only from the user-mode context of the first task to the user-mode context of the second task” is not clear, particularly, it is not clear that whether Applicant intended to delete word “only” from the limitation or not. The original specification does include similar descriptions as support for such “only”. However, according to the preliminary amendment made on the specification, Applicant deleted the word “only” from those descriptions at the specification. Such as, “switching only from the user-mode context of the first task to the user-mode context of the second task” at last two lines of [0026] was amended to: switching
Claims 4-9 and 13 are rejected for failing to cure the deficiency from their respective parent claim by dependency (note: the dependency is claim 2).
In addition, for claim 5, the limitation “the target task is the second task or a last task in at least one task that continuously runs after the second task, and the second task and the at least one task both trigger a request of the preconfigured request type” is not clear.
First of all, the language of “continuously runs after the second task” is not clear. This particular claimed invention is directed to context switch between different tasks, such as see limitations “switching at least from a user-mode context of the first task to a user-mode context of a second task” and “running the second task in the user mode” from claim 1. In this way, it is not clear that whether the claimed “at least one task that continuously runs after the second task” would include the tasks due to context switch (such type of task sequence as: task2-> task3 due to context switch from task2-> task1 due to context switch from task3 -> task 2 due to context switch from task1-> task4 due to completion of task2) OR such language requires no context switch occurred after the second task until the claimed “a last task” (such type of task sequence as: task2-> task3 due to completion of task2 -> task4 due to completion of task3 -> lasttask due to completion of task4 -> task1 due to context switch from lasttask). If it includes the tasks due to context switch, then 1. there is no reason to include the word “continuously” (i.e., just language like: at least one task that runs after the second task); 2. whether the resumption of second task would be included to such claimed “at least one task that continuously runs after the second task”. If it does not includes the tasks due to context switch, then the existence of “a last task in at least one task that continuously runs after the second task” would conflict with limitations “switching from a user mode context of the target task to a user-context of a third task … suspending the target task” when “the target task is the second task”.
Secondly, it is not clear that “the second task and the at least one task both trigger a request of the preconfigured request type” requires “a request” being “a second request of entering the kernel entry” OR such “a request” being a third request. If it is the second request, then whether the determination to result context switch described by lines 7-13 of claim 5 is required to be occurred for each of “the second task and the at least one task” that “trigger a request of the preconfigured request type” OR such determination is performed for a last task from “the at least one task” that triggers “a request of the preconfigured request type”.
For the purpose of examination, Examiner interprets the limitations above as:
the target task is a last task in at least one task that continuously runs after the second task (note: here examiner interprets “continuously runs” as: no context switch occurs between the second task and the last task), and the last task from the at least one task triggers the second request of the preconfigured request type.
For claim 6, “the targe task is the second task or a last task in at least one task that continuously runs after the second task; and when the target task is the last task in the at least one task, the second task and each task that is in the at least one task and that runs before the target task both trigger a request of the preconfigured request type” is rejected due to similar reason as explained at the rejection of claim 5 above. For the purpose of examination interprets the limitation above as:
the targe task is the second task or a last task in at least one task that each of the second task and each task that is in the at least one task and that runs before the target task s a third request of the preconfigured request type.
Claims 7-9 and 13 are rejected for failing to cure the deficiency from their respective parent claim by dependency (note: the dependency is claim 6). In addition,
For claim 7, the meaning of “when the target task is not blocked” is not clear. Claim 7 depends on claim 6; according to claim 6, such claimed “target task” has both of “a target kernel-mode context” and “state of the target task in the user mode”. It is not clear that such target task is blocked or not is based on either one of kernel mode/side or user mode/side OR both of kernel mode/side and user mode/side. For the purpose of examination, examiner interprets “the target task is not blocked” as such target task is not blocked at either one of kernel mode/side or user mode/side.
For claim 8, the limitation “when the target task is blocked” is rejected as same as the rejection of claim 7 above. Similarly, examiner interprets “the target task is blocked” as such target task is blocked at either one of kernel mode/side or user mode/side.
For claim 8, the meaning of “the native scheduling procedure needs to process all scheduling statuses from the first task to each task in the at least one task” is not clear. First of all, it is not clear whether Applicant intended to mean processing all scheduling statuses of tasks including the first task, the second and all tasks in the at least one task OR processing/modifying all scheduling statuses of first task into each task from the at least one task. For the purpose of examination, examiner interprets the limitations above as the native scheduling procedure needs to process all scheduling statuses of a plurality of tasks including the first task, the second task and the at least one task.
Claims 9 and 13 are rejected for failing to cure the deficiency from their respective parent claim by dependency (note: the dependency is claim 8). In addition,
For claim 9, it is not clear that “each task” at line 2 of claim 9 is referred to “each task in the at least one task” OR each of “from the first task to each task in the at least one task”. For the purpose of examination, examiner interprets this “each task” as: each task from the plurality of task including the first task, the second task and the at least one task. In addition, the meaning of “wherein the second scheduling status of each task is a scheduling status in the scheduling statuses of the task other than a first scheduling status of the task”. First of all, the claims do provide sufficient description or definition to define the scope of claimed “the scheduling statuses” (like what kind of information or statuses are included and what kind of information or statuses are not included). Secondly, the language used to define claimed “first scheduling statuses” from claim 1 is “the first scheduling status of the first task comprises a suspended state of the first task in the user mode and a running time from a moment of starting to run the first task to a moment of suspending the first task”. The words “comprises” is open-end, i.e., such claimed first scheduling status is possible to include more than what is defined or required by at claim 1 which result the scope of “other than a first scheduling status of the task” is not clear neither.
Claim 13 is rejected for failing to cure the deficiency from their respective parent claim by dependency (note: the dependency is claim 9). In addition,
For claim 13, the meaning of “a scheduling status of the task” is not clear. Claim 13 depends on claim 9 and claim 9 specifies two different scheduling statuses, i.e., claimed “second scheduling status” and claimed “first scheduling status”. It is not clear “a scheduling status” from claim 13 is referred, any one of the first and the second OR both.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 14 and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Regarding to Claim 14, Claim 14 recites “A computer-readable storage medium”. However, there is no evidence in the specification to define such computer-readable storage medium under BRI to exclude signal per se. Signals are directed to a non-statutory subject matter. Thus, Claim 14 is rejected under 35 U.S.C. 101 for directing to a non-statutory subject matter. Examiner suggests amend the claim element as “A non-transitory computer-readable storage medium” in order to draw the claim to non-transitory subject matter.
Regarding to Claim 20, Claim 20 is directed “A computer program product, comprising a computer program”. According to the specification, particularly “When functions are implemented in a form of a software functional unit and sold or used as an independent product … implemented in a form of a software product” from [00282]. Such claimed “A computer program product” under BRI can be pure software only. Pure software systems are directed to a non-statutory subject matter. Applicant is advised to amend to claim to include hardware components to overcome the 101 rejection.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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-2, 4, 14-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Yamada et al. (US 8521995 B2, hereafter Yamada) in view of Van De Ven et al. (US 20110161981 A1, hereafter Van).
Regarding to claim 1, Yamada discloses: A method of task processing (see Fig. 7, lines 57-66 of col. 17; “Referring now to FIG. 7, shown is a flow diagram of a method for handling context switch operations in accordance with an embodiment of the present invention … a first thread (i.e., thread A) that is executing a UTM application and a second thread (i.e., thread B) that is executing a non-UTM application”), comprising:
detecting, in a kernel mode, a type of a first request of entering a kernel entry, wherein the kernel entry is an entry from a user mode to the kernel mode, and the first request is triggered by a first task in the user mode, the user mode comprising a plurality of tasks, the tasks including threads or processes (see Fig. 7, lines 57-20 of cols. 17-18; “the various operations performed both in a user mode such as different threads executing in user mode namely a first thread (i.e., thread A) that is executing a UTM application and a second thread (i.e., thread B) that is executing a non-UTM application … execution of the UTM application in the first thread (block 610) … During the course of the transaction, a timer interrupt may occur. Accordingly, a ring transition 615 occurs which passes control to the kernel mode”. Also see claim 1, “receiving control in a kernel mode via a ring transition from a first user thread during execution of an unbounded transactional memory (UTM) transaction in the first user thread”);
when the type of the first request indicates that the first task is suspended in the user mode, switching at least from a user-mode context of the first task to a user-mode context of a second task and recording a first scheduling status of the first task, wherein the first scheduling status of the first task comprises a suspended state of the first task in the user mode (see Fig. 7, lines 57-23 of cols. 17-18; “different threads executing in user mode namely a first thread (i.e., thread A) that is executing a UTM application and a second thread (i.e., thread B) that is executing a non-UTM application”, “a ring transition 615 occurs which passes control to the kernel mode. However, instead of aborting the transaction, the transaction can be suspended, e.g., by setting various one or more indicators in a TSR, including suspending execution of an ejection handler … The OS may then save the first thread's context. This context may include the UTM state including the TSR register. To enable the context switch, the OS further restores the context of the second thread to the machine state”. Note: the first thread is suspended at the user mode at the time the OS saves first thread’s context, and thus the context saved for the first thread is reasonable to be considered as claimed suspended state of the first task in the user mode); and
running the second task in the user mode (see Fig. 7, lines 60-64 of col. 17, lines 17-23 of col. 18; “different threads executing in user mode namely … and a second thread (i.e., thread B) that is executing a non-UTM application” and “To enable the context switch, the OS further restores the context of the second thread to the machine state. Accordingly, control passes to the second thread for execution of its application (blocks 625 and 630). Accordingly, this thread may continue, e.g., until it hits a timer or other interrupt, which again causes a ring transition back to the kernel mode (block 635)”).
Yamada does not disclose: the first scheduling status further comprises a running time from a moment of starting to run the first task to a moment of suspending the first task.
However, Van discloses: switching at least from a [user-mode] context of the first task to a [user-mode] context of a second task and recording a first scheduling status of the first task, wherein the first scheduling status of the first task comprises a running time from a moment of starting to run the first task to a moment of suspending the first task (see [0013]-[0014]; “it is determined whether a context switch is to occur (e.g., based on a request by an Operating System (OS)). In one embodiment, information regarding P-state of a process being switched out is stored and the stored state is restored when the process is scheduled back in”, “execution history of the process (e.g., including task time slice information which indicates one or more previous execution durations for the process/task) being switched in is provided … The process scheduler may store or cause storage (e.g., via some other logic) data regarding execution duration of each process that is executing. In some embodiments, the process scheduler may store the execution duration data periodically and/or upon switching out of a process”. Note: the language of “a process being switched out” from [0013] implies that such process is suspended or stopped due to context switch process, and thus the execution duration included in saved/stored state of the process being switched out is reasonable to be considered as claimed “a running time from a moment of starting to run the first task to a moment of suspending the first task”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the stored/saved task’s context in response to context switching from Yamada by including the stored/saved task’s context including execution duration of the task to be switched out from Van, and thus the combination of Yamada and Van would disclose the missing limitation from Yamada, since it would provide a mechanism “to improve dynamic P-state selection” that dynamic changes processor performances (see [0011] and from Van).
Regarding to Claim 2, the rejection of Claim 1 is incorporated and further the combination of Yamada and Van discloses: wherein the switching at least from a user-mode context of the first task to a user-mode context of a second task when the type of the first request indicates that the first task is suspended in the user mode is:
when the type of the first request indicates that the first task is suspended in the user mode, and the type of the first request is a preconfigured request type, switching only from the user-mode context of the first task to the user-mode context of the second task (see Fig. 7, lines 57-23 of cols. 17-18 from Yamada; “both in a user mode such as different threads executing in user mode namely a first thread (i.e., thread A) that is executing a UTM application and a second thread (i.e., thread B) that is executing a non-UTM application” and “During the course of the transaction, a timer interrupt may occur … a ring transition 615 occurs which passes control to the kernel mode. However, instead of aborting the transaction, the transaction can be suspended, e.g., by setting various one or more indicators in a TSR, including suspending execution of an ejection handler … The OS may then save the first thread's context. This context may include the UTM state including the TSR register. To enable the context switch, the OS further restores the context of the second thread to the machine state”. Note: the descriptions of a timer interrupt and ring transition are reasonable imply the context switching discussed at lines 57-23 of cols. 17-18 is in response to certain preconfigured request type for performing context switch).
Regarding to Claim 4, the rejection of Claim 2 is incorporated and further the combination of Yamada and Van discloses: wherein the preconfigured request type is related to a service scenario, and a quantity of occurrences of the preconfigured request type in the service scenario is greater than a quantity of occurrences of a non-preconfigured request type in the service scenario (see Fig. 7, lines 53-65 of col. 16 and lines 57-20 of cols. 17-18 from Yamada; “OS events including external interrupts, page faults and OS system calls, embodiments provide mechanisms to effectively manage the large amount of UTM properties upon an OS context switch. In different embodiments, hardware support may suspend the transaction during kernel operation” and “During the course of the transaction, a timer interrupt may occur. Accordingly, a ring transition 615 occurs which passes control to the kernel mode. However, instead of aborting the transaction, the transaction can be suspended … The OS may then save the first thread's context. This context may include the UTM state including the TSR register. To enable the context switch, the OS further restores the context of the second thread to the machine state”. According to lines 53-65 of col. 16 from Yamada, there are multiple different types of OS events are able to cause kernel entry and/or context switch; however, during the execution of processes described by lines 57-20 of cols. 17-18, only timer interrupt, i.e., claimed preconfigured request type, that causes the kernel entry and context switch occurs, other types of OS events, i.e., claimed non-preconfigured request type, do not occurs, and thus the quantity of occurrences of timer interrupt is greater than a quantity of occurrences of other types of OS events).
Regarding to Claim 14, Claim 14 is a product claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above (Note: also see lines 15-30 of col. 19, claims 8 and 12 from Yamada for claimed “A computer-readable storage medium, storing a computer program”).
Regarding to Claim 15, Claim 15 is a system claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above (note: also see Fig. 8 and lines 43-57 of col. 18 Yamada for claimed “A computer device”).
Regarding to Claim 16, Claim 16 is a system claim corresponds to method Claim 2 and is rejected for the same reason set forth in the rejection of Claim 2 above.
Regarding to Claim 18, Claim 18 is a system claim corresponds to method Claim 4 and is rejected for the same reason set forth in the rejection of Claim 4 above.
Regarding to Claim 19, Claim 19 is a system claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above (note: also see Fig. 8, lines 43-57 of col. 18 from Yamada for claimed “A chip system”).
Regarding to Claim 20, Claim 20 is a system claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above (note: also see Fig. 8, lines 43-57 of col. 18, lines 15-30 of col. 19 from Yamada for claimed “A computer program product”).
Claims 3, 6-9, 13 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Yamada et al. (US 8521995 B2, hereafter Yamada) in view of Van De Ven et al. (US 20110161981 A1, hereafter Van) and further in view of Jayamohan et al. (US 20100083261 A1, hereafter Jayamohan).
Regarding to Claim 3, the rejection of Claim 1 is incorporated and further the combination of Yamada and Van discloses: wherein the switching at least from a user-mode context of the first task to a user-mode context of a second task when the type of the first request indicates that the first task is suspended in the user mode is specifically:
when the type of the first request indicates that the first task is suspended in the user mode, and the type of the first request is a non-preconfigured request type, switching from the user-mode context of the first task to the user-mode context of the second task (see Fig. 7, lines 53-65 of col. 16, lines 57-23 of cols. 17-18 from Yamada; “different threads executing in user mode namely a first thread (i.e., thread A) that is executing a UTM application and a second thread (i.e., thread B) that is executing a non-UTM application”, “During the course of the transaction, a timer interrupt may occur. Accordingly, a ring transition 615 occurs which passes control to the kernel mode. However, instead of aborting the transaction, the transaction can be suspended, e.g., by setting various one or more indicators in a TSR, including suspending execution of an ejection handler … The OS may then save the first thread's context. This context may include the UTM state including the TSR register. To enable the context switch, the OS further restores the context of the second thread to the machine state”. In response to timer interrupt, i.e., claimed non-preconfigured request type occurs, a context switch process is performed to switching the user mode context of the first thread to the user mode context of the second thread).
The combination of Yamada and Van does not disclose: switching from a kernel-mode context of the first task to a kernel-mode context of the second task.
However, Jayamohan discloses: switching from the user-mode context of the first task to the user-mode context of the second task and switching from a kernel-mode context of the first task to a kernel-mode context of the second task (see [0004] and [0021]-[0022]; “a user portion of primary thread is switched to a user portion of a UMS thread …The primary thread may then transfer into kernel mode via an implicit switch. A kernel portion of the UMS thread is then executed in kernel mode using the context information migrated from the kernel portion of the primary thread that was executing the user portion of the UMS thread prior to entry into kernel mode”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the context switch from the combination of Yamada and Van by including context switch on both of user-level context and kernel-level context between two threads from Jayamohan, and thus the combination of Yamada, Van and Jayamohan would disclose the missing limitations from the combination of Yamada and Van, since “Each of the threads in the exemplary multi-processor environment 100 comprises a kernel portion that resides in kernel mode 112, and a user portion that resides in user mode 114” (see [0021]-[0022] from Jayamohan).
Regarding to Claim 6, the rejection of Claim 2 is incorporated and further the combination of Yamada and Van discloses: wherein after the running the second task in the user mode, the method further comprises: detecting a type of a second request of entering the kernel entry, wherein the second request is triggered by a target task in the user mode, and the target task is the second task or a last task in at least one task that continuously runs after the second task; and when the target task is the last task in the at least one task, the second task and each task that is in the at least one task and that runs before the target task both trigger a request of the preconfigured request type (see Fig. 7, lines 19-43 of col. 18 from Yamada; “control passes to the second thread for execution of its application (blocks 625 and 630). Accordingly, this thread may continue, e.g., until it hits a timer or other interrupt, which again causes a ring transition back to the kernel mode (block 635)”); Note: according to BRI of the claim limitation, the whole limitations of “the target task is the second task or a last task in at least one task that continuously runs after the second task; and when the target task is the last task in the at least one task, the second task and each task that is in the at least one task and that runs before the target task both trigger a request of the preconfigured request type” can be the claimed target task being claimed second task without considering the claimed target task as claimed last task; under such interpretation, the limitation “when the target task is the last task in the at least one task, the second task and each task that is in the at least one task and that runs before the target task both trigger a request of the preconfigured request type” is not given patentable weight.
when the type of the second request indicates that the target task is suspended in the user mode, and the type of the second request is a non-preconfigured request type, recording a first scheduling status of the target task, wherein the first scheduling status of the target task comprises a suspended state of the target task in the user mode and a running time from a moment of starting to run the target task to a moment of suspending the target task (see Fig. 7, lines 53-65 of col. 16, lines 19-43 of col. 18 from Yamada and [0013]-[0014] from Van; “OS events including external interrupts, page faults and OS system calls, embodiments provide mechanisms to effectively manage the large amount of UTM properties upon an OS context switch. In different embodiments, hardware support may suspend the transaction during kernel operation”, “until it hits a timer or other interrupt, which again causes a ring transition back to the kernel mode (block 635). Now, the OS performs operations to enable the context switch back to the first thread (block 640). These operations may mirror those discussed above with regard to block 620”, “the process scheduler may store the execution duration data periodically and/or upon switching out of a process”. Note: according to lines 53-65 of col. 16 from Yamada, there are multiple different types of OS events are able to cause kernel entry and/or context switch described by lines 57-43 of cols. 17-18 caused by timer interrupt, and thus one of other types of OS events can be considered as claimed non-preconfigured request type).
The combination of Yamada and Van does not disclose: switching from a first kernel-mode context of the first task to a target kernel-mode context of the target task.
However, Jayamohan discloses:
switching from a first kernel-mode context of the first task to a target kernel-mode context of the target task (see [0042]-[0043]; “in the example of the UMS thread 102, the OS kernel may switch from the kernel portion 120 of the primary thread 106 to the kernel portion 116 once the UMS thread 102 enters kernel mode 112 … The directed switch enables a kernel portion of a primary thread to switch to a kernel portion of UMS thread for the purpose of continuing execution of the UMS thread in kernel mode”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the context switch from the combination of Yamada and Van by including context switch on both of user-level context and kernel-level context between two threads from Jayamohan, and thus the combination of Yamada, Van and Jayamohan would disclose the missing limitations from the combination of Yamada and Van, since “Each of the threads in the exemplary multi-processor environment 100 comprises a kernel portion that resides in kernel mode 112, and a user portion that resides in user mode 114” (see [0021]-[0022] from Jayamohan).
Regarding to Claim 7, the rejection of Claim 6 is incorporated and further the combination of combination of Yamada, Van and Jayamohan discloses: wherein when the target task is not blocked, after the switching from the first kernel-mode context of the first task to the target kernel-mode context of the target task, the method further comprises: returning to the user mode to continue to run the target task (see [0069] from Jayamohan; “if the UMS thread completes kernel mode execution without blocking and continues to execute the user portion of UMS thread”)
Regarding to Claim 8, the rejection of Claim 6 is incorporated and further the combination of Yamada, Van and Jayamohan discloses: wherein when the target task is blocked, the method further comprises: scheduling a third task by using a native scheduling procedure, and switching from the target task to the third task, wherein the native scheduling procedure needs to process all scheduling statuses from the first task to each task in the at least one task; and running the third task in the user mode (see the rejection of claim 7 above. Note: the whole claim 8 is a method claim under conditional language having steps/actions to be performed, particularly such steps/actions are performed under the opposite condition required by claim 7, and thus the whole claim 8 under BRI can be interpreted as the same steps/actions from claim 7 to be performed under the condition of “when the target task is not blocked” as required by claim 7).
Note1: for the purpose of compact prosecution, Applicant is suggested to review [0107] from Jayamohan. [0107] from Jayamohan states “if the OS kernel determines that the kernel portion 116 of the UMS thread 102 is blocked (“yes” at decision block 720), the primary thread 106 may awake from its blocked state at block 734. During this awake state, the primary thread 106 may exit kernel mode 112 into user mode 114, where the user portion 122 of the primary thread 106 may execute the user mode scheduler 204 and switch to the user portion of another UMS thread, such as user portion 220, for execution”. Also see [0035] from Jayamohan; “the user mode scheduler 204 may periodically check the completion list 202 for threads that have been queued in user mode”. Thereby, such user mode scheduler, i.e., claimed native scheduling procedure needs to process all scheduling of all tasks.
Note2: Examiner rejected claim 6 under the condition of the target task being the claimed second task, and thus under BRI of claims 6 and 8, there is no such “at least one task that continuously runs after the second task” at claim 8.
Regarding to Claim 9, the rejection of Claim 8 is incorporated and further the combination of Yamada, Van and Jayamohan discloses: wherein the scheduling a third task by using a native scheduling procedure is: modifying a second scheduling status from the first task to each task in the at least one task from a scheduling status, of each task, in a case in which the task starts to run to a scheduling status corresponding to each task when it is determined that the native scheduling procedure is performed on the third task, wherein the second scheduling status of each task is a scheduling status in the scheduling statuses of the task other than a first scheduling status of the task (see the rejection of claim 7 above. Note: once again, claim 9 depends on claim 8 which the whole claim 8 is a method claim under conditional language having steps/actions to be performed, particularly such steps/actions are performed under the opposite condition required by claim 7, and thus the whole claims 8-9 under BRI can be interpreted as the same steps/actions from claim 7 to be performed under the condition of “when the target task is not blocked” as required by claim 7).
Regarding to Claim 13, the rejection of Claim 9 is incorporated and further the combination of Yamada, Van and Jayamohan discloses: wherein during scheduling of simplified fair scheduling, before performing the scheduling a third task by using a native scheduling procedure, the method further comprises: synchronizing a task in a first queue and a scheduling status of the task in the first queue to a second queue, and synchronizing, to the second queue, information that has been output by the third task from the first queue, wherein the second queue is a queue used for the native scheduling procedure; and synchronizing information about a location, in the second queue, of the task in the first queue to the first queue, wherein the information about the location is used to adjust a location, in the first queue, of the task in the first queue (see the rejection of claim 7 above. Note: once again, claim 13 depends on claim 9 and claim 9 depends on claim 8 which the whole claim 8 is a method claim under conditional language having steps/actions to be performed, particularly such steps/actions are performed under the opposite condition required by claim 7, and thus the whole claims 8-9, 13 under BRI can be interpreted as the same steps/actions from claim 7 to be performed under the condition of “when the target task is not blocked” as required by claim 7).
Regarding to Claim 17, Claim 17 is a system claim corresponds to method Claim 3 and is rejected for the same reason set forth in the rejection of Claim 3 above.
Claims 5 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Yamada et al. (US 8521995 B2, hereafter Yamada) in view of Van De Ven et al. (US 20110161981 A1, hereafter Van) and further in view of Waters et al. (US 20220237439 A1, hereafter Waters).
Regarding to Claim 5, the rejection of Claim 2 is incorporated and further the combination of Yamada and Van discloses: wherein after the running the second task in the user mode, the method further comprises: detecting a type of a second request of entering the kernel entry, wherein the second request is triggered by a target task in the user mode (see Fig. 7, lines 19-43 of col. 18 from Yamada; “control passes to the second thread for execution of its application (blocks 625 and 630). Accordingly, this thread may continue, e.g., until it hits a timer or other interrupt, which again causes a ring transition back to the kernel mode (block 635)”);
when the type of the second request indicates that the target task is suspended in the user mode, and the type of the second request is the preconfigured request type, recording a first scheduling status of the target task, and switching from a user-mode context of the target task to a user-mode context of first task, wherein the first scheduling status of the target task comprises a suspended state of the target task in the user mode and a running time from a moment of starting to run the target task to a moment of suspending the target task; and running the first task in the user mode (see Fig. 7, lines 19-43 of col. 18 from Yamada and [0013]-[0014] from Van; “until it hits a timer or other interrupt, which again causes a ring transition back to the kernel mode (block 635). Now, the OS performs operations to enable the context switch back to the first thread (block 640). These operations may mirror those discussed above with regard to block 620”, “the process scheduler may store the execution duration data periodically and/or upon switching out of a process”).
The combination of Yamada and Van does not disclose: the target task is the second task or a last task in at least one task that continuously runs after the second task, and the second task and the at least one task both trigger a request of the preconfigured request type;
the first task to be switched in is a third task.
However, Waters discloses: the target task is the second task or a last task in at least one task that continuously runs after the second task, and the second task and the at least one task both trigger a request of the preconfigured request type; context switching occurred to switch from the target task to a third task, running the third task (see [0120], [0122]-[0123]; “neural task manager 310 may support intra-queue context switch and inter-queue context switch … An intra-queue context switch occurs when there is a context switch within a task queue 1004. In an inter-queue context switch, a first task queue 1004 currently being in execution is terminated and neural task manager 310 is switched to another queue” and “After neural task manager 310 completes a task queue 1004, neural task manager 310 may also perform an inter-queue context switch to dequeue another task queue 1004”. After context switch occurred between first task and second task resided within same queue, a next context switch, particularly inter-queue context switch, is occurred due to a last task continuously runs after the second task complete, and thus a third task from other queue is switched in).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the process of context switch among two different tasks from the combination of Yamada and Van by including the process of context switch among two difference tasks located at two different queues from Waters, and thus the combination of Yamada, Van and Waters would disclose the missing limitations from the combination of Yamada and Van, since it is well-known and understood to enqueuing tasks into task FIFO queues to temporality store the tasks to be executed (see [0057] and [0101] from Waters; “Neural task manager 310 may receive a task list from a compiler executed by CPU 208, store tasks in its task queues, choose a task to perform, and send task commands to other components of the neural processor circuit 218 for performing the chosen task”).
Regarding to Claim 12, the rejection of Claim 1 is incorporated, the combination of Yamada and Van does not disclose: wherein the second task is in a first queue, the first queue is a first in first out queue, and the second task is a task that first enters the first queue among the tasks in the first queue.
However, Waters discloses: wherein the second task is in a first queue, the first queue is a first in first out queue, and the second task is a task that first enters the first queue among the tasks in the first queue (see [0101], [0119]-[0120] and [0123]; “segments 1150 are executed in a first-in-first-out (FIFO) manner until the segments 1150 in the task queue 1004 are executed or until there is a context switch” and “In an inter-queue context switch, a first task queue 1004 currently being in execution is terminated and neural task manager 310 is switched to another queue”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the process of context switch among two different tasks from the combination of Yamada and Van by including the process of context switch among two difference tasks located at two different queues from Waters, and thus the combination of Yamada, Van and Waters would disclose the missing limitations from the combination of Yamada and Van, since it is well-known and understood to enqueuing tasks into task FIFO queues to temporality store the tasks to be executed (see [0057] and [0101] from Waters; “Neural task manager 310 may receive a task list from a compiler executed by CPU 208, store tasks in its task queues, choose a task to perform, and send task commands to other components of the neural processor circuit 218 for performing the chosen task”).
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Yamada et al. (US 8521995 B2, hereafter Yamada) in view of Van De Ven et al. (US 20110161981 A1, hereafter Van) and further in view of Nozue et al. (US 5627987 A, hereafter Nozue).
Regarding to Claim 10, the rejection of Claim 1 is incorporated, the combination of Yamada and Van does not disclose: wherein during scheduling of a remote procedure call (RPC), the first request comprises information about the second task, and the information about the second task is used to schedule the second task.
However, Nozue discloses: wherein during scheduling of a remote procedure call (RPC), the first request comprises information about the second task, and the information about the second task is used to schedule the second task (see lines 10-41 of col. 46; “when the user program 412 on the logical address space 451 called up the user program 417 on the logical address space 456, the OS 411 carries out the context switching operation including the saving of the context of the user program 412, switching from the logical address space 451 to the logical address space 456, and the loading of the context of the user program 417, such that the user program 417 can be executed next … realize the remote procedure call (RPC) of direct call up type using the logical addresses rather than the usual RPC of indirect call up type using the program names”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the request to trigger context switch from the combination of Yamada and Van by including context switch between two user programs trigger by RPC from one of the two user programs from Nozue, and thus the combination of Yamada, Van and Nozue would disclose the missing limitations from the combination of Yamada and Van, since it would provide another particular context switching trigger example to be executed (see lines 10-41 of col. 46 from Nozue).
Regarding to Claim 11, the rejection of Claim 10 is incorporated and further the combination of Yamada, Van and Nozue discloses: wherein the method further comprises:
recording the first request and information associated with the first task (see Fig. 7, lines 57-19 of cols. 17-18 from Yamada; “a timer interrupt may occur. Accordingly, a ring transition 615 occurs which passes control to the kernel mode … The OS may then save the first thread's context. This context may include the UTM state including the TSR register. To enable the context switch, the OS further restores the context of the second thread to the machine state”. Note: claimed “recording” is broad without specifying how to record claimed first request, “the ring transition 615” from Yamada implies that the timer interrupt is somehow recorded, the saved first thread’s context requires recording claimed “information associated with the first task”);
running the second task to obtain a return result (see Fig. 7, lines 17-25 of col. 18 from Yamada; “control passes to the second thread for execution of its application. Accordingly, this thread may continue, e.g., until it hits a timer or other interrupt, which again causes a ring transition back to the kernel mode (block 635)”. Note: without further clarification, “causes a ring transition back to the kernel mode” is reasonable to be considered as certain return result achieved by running the second thread);
returning the return result to the first task based on the information associated with the first task; and switching from the second task back to the first task to continue to run the first task (see Fig. 7, lines 21-42 of col. 18 from Yamada; “at block 645, another ring transition occurs to return control back to thread A. At block 650, thread A may resume execution. In one embodiment, this resumed execution may include a jump to the ejection handler, as the TSR associated with this thread indicates the lost event. Accordingly, the ejector may execute recovery code for handling the lost event. While the scope of the present invention is not limited in this regard, such recovery code may include restarting of the transaction, execution in another UTM mode or so forth”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Reid (US 20110125986 A1) discloses: In a cooperatively scheduled multithreaded system whereRPC_get operations perform context switches but RPC_put operations do not perform context switches, a long sequence of RPC operations could be transformed into a long sequence of RPC_put operations (which do not perform context switches) followed by a long sequence of RPC_get operations (see [0105]).
Gorti (US 20070174328 A1) discloses: performing a context switch via remote procedure call would require return result back to the caller (see [0005]-[0011]).
Shaylor (US 20040117793 A1) discloses: The sender of the request calls the microkernel and the microkernel copies the request into the driver (or other task) and then switches user mode execution to that task to process the request. When processing of the request is complete, the microkernel copies any results back to the sender task and the user mode context is switched back to the sender task (see [0042]).
Pohl et al. (US 8954968 B1) discloses: After the first thread has executed for the duration of the time slice, scheduler 24 performs a “context switch” to select a second thread of the same priority from the run queue for execution and further places the first thread at the end of the run queue. Thus, scheduler 24 selects and executes threads stored in the run queue in a First-In, First-Out (FIFO) manner (see lines 11-31 of col. 6).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHI CHEN whose telephone number is (571)272-0805. The examiner can normally be reached on M-F from 9:30AM to 5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on 571-270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Zhi Chen/
Patent Examiner, AU2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights