DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending in this application.
Response to Arguments
Applicant’s arguments regarding the rejections of claims 1-20 under 35 U.S.C. 112b have been fully considered and are persuasive. The rejections have been withdrawn. However, new 35 U.S.C. 112b rejections are applied to claims 1-20 based on the amendments.
Applicant’s arguments regarding the rejections of claims 1-20 under 35 U.S.C. 101 have been fully considered and are persuasive. The rejections have been withdrawn.
Applicant's arguments regarding the 35 U.S.C. 103 rejections of claims 1-20 have been fully considered but they are moot in light of the references being applied in the current rejection. Additionally, in response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
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 1-20 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claims 1, 11, 14, 15, 17, 18, and 20 (line numbers refer to claim 1):
Lines 10-14 recite “generating a resource scheduling strategy according to the workload index parameter, such that a kernel of the server reallocates a computing resource of the server according to the resource scheduling strategy, wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread”. It is unclear what it means by allocating the computing resource to the newly created worker thread since the computing resource is already reallocated. Additionally, it is unclear what recycling the computing resource allocated to the worker thread means since the computing resource is allocated to the newly created worker thread.
Claims 2-10, 12, 13, 16, and 19 are dependent claims of claims 1, 11, 15, and 18, and fail to resolve the deficiencies of claims 1, 11, 15, and 18, so they are rejected for the same reasons.
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.
Claims 1, 3, 10, 14, 15, 16, 17, 18, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Teflioudi et al. (US 20230281055 A1 hereinafter Teflioudi), in view of Howland (US 20070050771 A1), in view of Ippatapu et al. (US 20200326985 A1 hereinafter Ippatapu), in view of Nassi et al. (US 20200192702 A1 hereinafter Nassi), in view of Foukas et al. (US 20220035665 A1 hereinafter Foukas), and further in view of Hoflehner et al. (US 20050071841 A1 hereinafter Hoflehner).
As per claim 1, Teflioudi teaches the invention substantially as claimed including a thread processing method, applied to a scheduling component, the method comprising: a duration for which a worker thread is in a blocked state, wherein the worker thread is in the blocked state after a task corresponding to a function instance is completed and before a next task is acquired (Fig. 3; [0034] As used herein, the term “worker thread” may refer to a thread or thread of execution, which is a sequence of instructions managed independently by a scheduler; [0067] one or more worker threads paused subsequent to the first fetch call; [0059] the worker threads 170 may be paused (e.g., to sleep on a semaphore) upon generating the first portion of the result for the query; [0052] The first subset of results 204 are sent to the user client equipment 102 in a first reply 206, which are received by the client device 102 at a first time 208. During this time, the database execution engine 150 waits for a subsequent fetch request without utilizing additional resources. The client device 102 may later send a fetch request 210; [0049] The one or more worker threads 170 allocated to generate the portion of the result may be paused in between fetch calls, for example, by allowing the one or more worker threads 170 to complete their respective tasks before going to sleep on a semaphore. Upon receiving a subsequent fetch call that requires more than the buffered data, the data execution engine 150 may wake up the paused worker threads 170 to continue performing the remaining tasks associated with the query; [0050] As used herein, the term “fetch call” may refer to a particular type of request that form a part of a query requesting data from the one or more databases 190. For example, the data execution engine 150 may receive, from the client device 102, an open request to initiate the query. Following the initial open request, the data execution engine 150 may receive one or more subsequent fetch calls, each of which requesting at least a portion of the results of the query. That is, a single fetch call may request, from the data execution engine 150, at least a portion of the results associated with the query.);
newly creating a worker thread (claim 6 instantiating one or more new worker threads).
Teflioudi fails to teach a thread processing method, applied to a scheduling component in a server, the method comprising: determining a duration for which a worker thread in the server is in a blocked state, wherein the worker thread is in the blocked state after a task in a task queue corresponding to a function instance in the server is completed and before a next task in the task queue is acquired, wherein the function instance comprises a functional network element comprising a base station; determining a workload index parameter of the worker thread according to the duration of the worker thread in the blocked state; and generating a resource scheduling strategy according to the workload index parameter, such that a kernel of the server reallocates a computing resource of the server according to the resource scheduling strategy, wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread; wherein a resource scheduling cycle is on an order of magnitude of microseconds, and resource scheduling is performed in the blocked state of the worker thread between adjacent tasks.
However, Howland teaches a thread processing method, applied to a scheduling component in a server, the method comprising: determining a duration for which a worker thread in the server is in a blocked state, wherein the worker thread is in the blocked state after a task in a task queue corresponding to a function instance in the server is completed and before a next task in the task queue is acquired; resource scheduling is performed in the blocked state of the worker thread between adjacent tasks ([0021] Referring to FIG. 2, as is represented by line 148, timer thread 100 watches queue 120 of tasks 122, 124, 126. When one of these tasks 122 is ready, timer thread 100 calls the ready task to process, as is represented by line 102; that is, timer thread 100 dispatches task 122. Once task 122 completes, if timer thread 100 is still serving as the timer thread, timer thread again waits on queue 120 of elements waiting for the next one (task 124) to be ready to run, at which time, as is represented by line 104, timer thread 100 dispatches task 124; [0048] Furthermore, referring to FIG. 6, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium 220 providing program code for use by or in connection with a computer 222 or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium 220 can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution, system, apparatus, or device 222; Table 1 // Can't run. Wait letting the next task // determine how long. wait for ( pTask's nextExecutionTime ) - currentTime mseconds; Table 2 Step 218 timerThread = new thread // Obtain new timer // thread timerThread.start( ); // Start it running // Step 206, no. } else { // Nope, top task isn't ready to run. // Steps 208, 210. // We wait based on the execution time of the next // task scheduled to run. Wait for (pTask's nextExecutionTimer) - currentTime mseconds; [0035] if a new task is scheduled while the wait is occurring).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi with the teachings of Howland to reduce resource usage (see Howland [0046] It is an advantage of the present invention that there is provided an improved system and method for scheduling tasks on a minimum number of threads.).
Teflioudi and Howland fail to teach wherein the function instance comprises a functional network element comprising a base station; determining a workload index parameter of the worker thread according to the duration of the worker thread in the blocked state; and generating a resource scheduling strategy according to the workload index parameter, such that a kernel of the server reallocates a computing resource of the server according to the resource scheduling strategy, wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread; wherein a resource scheduling cycle is on an order of magnitude of microseconds.
However, Ippatapu teaches determining a workload index parameter of the worker thread according to the duration of the worker thread in the blocked state ([0045] Based on the above determination of a thread weight coefficient (PC) [0046] PC>1, thread is busy and is servicing jobs. [0047] PC<1, thread is less busy and is servicing less jobs and idle most of the time during the last time interval. [0048] PC=−1, thread is extremely busy servicing jobs. [0049] PC=1, thread is busy and idle equally); and generating a resource scheduling strategy according to the workload index parameter, reallocates a computing resource according to the resource scheduling strategy ([0052] As shown, table 510 provides example formulas to determine a thread weight for different circumstances. In one or more embodiments, the thread weight coefficient (PC) described above can be indicative of the different circumstances. For example, as shown, in example circumstances where a thread is busy and frequently servicing jobs (PC>1), the new weight of the thread can be determined by adding the current thread weight to the determined weight coefficient. In different example circumstances where the thread is less busy and is servicing less jobs and idle most of the time during the last time interval (PC<1), the new weight of the thread can be determined by subtracting the determined weight coefficient from the current thread weight; [0027] Thread weight component 120 can assign weights to threads 140A-B based on the first likelihood and a first share of resources of the multithreaded processor 130 can be assigned by scheduler 160 to threads 140A-B based on respective weights of the threads.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi and Howland with the teachings of Ippatapu to optimize resource usage (see Ippatapu [0027] Thread weight component 120 can assign weights to threads 140A-B based on the first likelihood and a first share of resources of the multithreaded processor 130 can be assigned by scheduler 160 to threads 140A-B based on respective weights of the threads. It should be noted that, the approaches described herein can also be extended or generalized to any scheduler to adaptively tune several metrics for optimizing the usage of CPU resources and improving the overall performance of the system.).
Teflioudi, Howland, and Ippatapu fail to teach wherein the function instance comprises a functional network element comprising a base station; such that a kernel of the server reallocates a computing resource of the server; wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread; wherein a resource scheduling cycle is on an order of magnitude of microseconds.
However, Nassi teaches such that a kernel of the server reallocates a computing resource of the server ([0085] the hyper-kernel can make three separate decisions: (1) which resources to migrate upon certain events, (2) when to migrate them, and (3) to where those resources should move; [0044] each of which has a hyper-kernel running on server hardware).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi, Howland, and Ippatapu with the teachings of Nassi to optimize resource utilization (see Nassi [0043] the hyper-kernel optimizes use of resources).
Teflioudi, Howland, Ippatapu, and Nassi fail to teach wherein the function instance comprises a functional network element comprising a base station; wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread; wherein a resource scheduling cycle is on an order of magnitude of microseconds.
However, Foukas teaches wherein the function instance comprises a functional network element comprising a base station; wherein a resource scheduling cycle is on an order of magnitude of microseconds ([0117] At 704, method 700 may include identifying a number of signal processing tasks that will run on the base station; [0129] if scheduler 20 is running every 20 microseconds).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi, Howland, Ippatapu, and Nassi with the teachings of Foukas to improve the utilization of resources (see Foukas [0047] improvement in the utilization of the CPU resources).
Teflioudi, Howland, Ippatapu, Nassi, and Foukas fail to teach wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread.
However, Hoflehner teaches wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread ([0081] the compiler creates the threads in the thread creation phase and allocates resources for the threads in a subsequent thread resource allocation phase; [0036] the helper may terminate and release all the resources associate with the helper to main thread; [0048] resources, such as logical thread contexts, associated with the terminated helper threads are released back to the thread pool. This enables future requests to immediately recycle the logical thread contexts from the thread pool.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi, Howland, Ippatapu, Nassi, and Foukas with the teachings of Hoflehner to improve thread performance (see Hoflehner [0093] illustrating an improvement of performance by the helper thread).
As per claim 3, Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner teach the method of claim 1. Ippatapu teaches wherein the server is deployed with at least one function instance, and the worker thread is configured for executing a task generated by any one of the at least one function instance, wherein the working thread is plural in number ([0088] an application running on a server; [0033] One or more embodiments can allocate weights to promote a good balance of thread weights between application threads; [0039] a thread (e.g., thread 140A) without any history of operation, is assigned a task)
As per claim 10, Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner teach the method of claim 1. Ippatapu teaches wherein the server is installed with a third-party application program, and the generating the resource scheduling strategy according to the workload index parameter, comprises ([0088] an application running on a server; [0065] Thread weight component 120 can be configured 804 to assign a thread weight to the first thread based on the first likelihood, wherein a share of resources of the multithreaded processor is assigned (e.g., by scheduler 160) to the first thread 140A based on the thread weight of the first thread; [0082] Cloud computing and storage solutions can store and/or process data in third-party data centers): determining, according to the workload index parameter, that the resource scheduling strategy comprises allocating a target computing resource of the server to a worker thread corresponding to the function instance ([0065] Thread weight component 120 can be configured 804 to assign a thread weight to the first thread based on the first likelihood, wherein a share of resources of the multithreaded processor is assigned (e.g., by scheduler 160) to the first thread 140A based on the thread weight of the first thread; [0088] both an application running on a server and the server can be a component; [0066] remote component(s) 910 can be a distributed computer system, connected to a local automatic scaling component and/or programs that use the resources of a distributed computer system; claim 3 wherein the first thread entering the spin mode comprises the first thread entering the spin mode after the first thread completes a processor task of the multithreaded processor); and determining that the resource scheduling strategy further comprises allocating a remaining computing resource of the server to a worker thread corresponding to the third-party application program ([0033] One or more embodiments can allocate weights to promote a good balance of thread weights between application threads, e.g., to improve the overall system performance as compared to other approaches. In an example, thread 140A is weighted a 3, and thread 140B is weighted a 1; claim 7 wherein the resources assigned to the first thread are first resources, and wherein the thread weight component further allocates a second resource to a second thread based on the thread weight of the first thread; [0088] both an application running on a server and the server can be a component; [0066] remote component(s) 910 can be a distributed computer system, connected to a local automatic scaling component and/or programs that use the resources of a distributed computer system).
As per claim 14, it is a thread processing method claim of claim 1, so it is rejected for similar reasons. Additionally, Howland teaches a thread processing method, applied to a monitoring component in a server, the method comprising: determining, when a working cycle of the monitoring component is reached, a duration for which a worker thread in the server is in a blocked state ([0021] Referring to FIG. 2, as is represented by line 148, timer thread 100 watches queue 120 of tasks 122, 124, 126. When one of these tasks 122 is ready, timer thread 100 calls the ready task to process, as is represented by line 102; that is, timer thread 100 dispatches task 122. Once task 122 completes, if timer thread 100 is still serving as the timer thread, timer thread again waits on queue 120 of elements waiting for the next one (task 124) to be ready to run, at which time, as is represented by line 104, timer thread 100 dispatches task 124; [0048] Furthermore, referring to FIG. 6, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium 220 providing program code for use by or in connection with a computer 222 or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium 220 can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution, system, apparatus, or device 222; Table 1 // Can't run. Wait letting the next task // determine how long. wait for ( pTask's nextExecutionTime ) - currentTime mseconds; Table 2 Step 218 timerThread = new thread // Obtain new timer // thread timerThread.start( ); // Start it running // Step 206, no. } else { // Nope, top task isn't ready to run. // Steps 208, 210. // We wait based on the execution time of the next // task scheduled to run. Wait for (pTask's nextExecutionTimer) - currentTime mseconds; [0035] if a new task is scheduled while the wait is occurring; abstract A timer thread monitors status of tasks in the queue and selectively dispatches tasks).
As per claim 15, it is a scheduling component claim of claim 1, so it is rejected for similar reasons. Additionally, Howland teaches a scheduling component, running on a server, the scheduling component comprising a duration monitoring sub-component, an index monitoring sub-component, and a strategy generation sub-component ([0021] Referring to FIG. 2, as is represented by line 148, timer thread 100 watches queue 120 of tasks 122, 124, 126. When one of these tasks 122 is ready, timer thread 100 calls the ready task to process, as is represented by line 102; that is, timer thread 100 dispatches task 122. Once task 122 completes, if timer thread 100 is still serving as the timer thread, timer thread again waits on queue 120 of elements waiting for the next one (task 124) to be ready to run, at which time, as is represented by line 104, timer thread 100 dispatches task 124; [0048] Furthermore, referring to FIG. 6, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium 220 providing program code for use by or in connection with a computer 222 or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium 220 can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution, system, apparatus, or device 222; Table 1 // Can't run. Wait letting the next task // determine how long. wait for ( pTask's nextExecutionTime ) - currentTime mseconds; Table 2 Step 218 timerThread = new thread // Obtain new timer // thread timerThread.start( ); // Start it running // Step 206, no. } else { // Nope, top task isn't ready to run. // Steps 208, 210. // We wait based on the execution time of the next // task scheduled to run. Wait for (pTask's nextExecutionTimer) - currentTime mseconds; [0035] if a new task is scheduled while the wait is occurring; abstract A system for scheduling tasks for execution includes a queue of tasks ordered by scheduled time for execution. A timer thread monitors status of tasks in the queue and selectively dispatches tasks; [0022] Queue 120 of tasks 122, 124, 126 waiting to run is a queue data structure of tasks ordered by `next to run` time. Tasks 122, 124, and 126 are placed on this queue 120 when scheduled for execution. Queue 120 is visible to both timer thread 100 and guard thread 140, and thus is the common object used for signaling purposes between current timer thread 100 and guard thread 140. Both timer thread 100 and guard thread 140 act to reschedule tasks that are already on queue 120, as is represented by lines 148 and 144, and other threads, such as user thread 116, are responsible for scheduling new tasks, as is represented by line 143.).
As per claim 16, Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner teach the scheduling component of claim 15. Howland teaches wherein the server provides a shared memory, and the duration monitoring sub-component is configured for writing the duration of the blocked state into the shared memory; the index monitoring sub-component is configured for reading the duration of the blocked state from the shared memory ([0021] Referring to FIG. 2, as is represented by line 148, timer thread 100 watches queue 120 of tasks 122, 124, 126. When one of these tasks 122 is ready, timer thread 100 calls the ready task to process, as is represented by line 102; that is, timer thread 100 dispatches task 122. Once task 122 completes, if timer thread 100 is still serving as the timer thread, timer thread again waits on queue 120 of elements waiting for the next one (task 124) to be ready to run, at which time, as is represented by line 104, timer thread 100 dispatches task 124; [0048] Furthermore, referring to FIG. 6, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium 220 providing program code for use by or in connection with a computer 222 or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium 220 can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution, system, apparatus, or device 222; Table 1 // Can't run. Wait letting the next task // determine how long. wait for ( pTask's nextExecutionTime ) - currentTime mseconds; Table 2 Step 218 timerThread = new thread // Obtain new timer // thread timerThread.start( ); // Start it running // Step 206, no. } else { // Nope, top task isn't ready to run. // Steps 208, 210. // We wait based on the execution time of the next // task scheduled to run. Wait for (pTask's nextExecutionTimer) - currentTime mseconds; [0050] A data processing system 222 suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program cod).
Additionally, Ippatapu teaches writing the workload index parameter into the shared memory; and the strategy generation sub-component is configured for reading the workload index parameter from the shared memory (Figs. 5, 7, 9; [0051] FIG. 5 depicts a non-limiting, example 500 of a table 510 that can provide different example formulas for different thread weight coefficients described above; [0062] At element 704, method 700 can comprise scheduling, by the scheduling process (e.g., scheduler 160), the thread 140A of the pool of threads (e.g., thread pool 152) for execution by the multithreaded processor 130, based on the thread weight; [0063] FIG. 8 is a flow diagram 800 representing example operations of a system 150 comprising a thread activity analyzer 110 and thread weight component 120 that can facilitate adaptive tuning of thread weights; [0067] local component(s) 920 can comprise thread activity analyzer 110, thread weight component 120, and scheduler 160; [0068] local component(s) 920 can be operably connected to one or more local data store(s) 930, that can be employed to store information on the local component(s) 920; [0082] Computer 1012 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 1044. Remote computer(s) 1044 can be a personal computer, a server; [0082] . A cloud computing environment, the cloud, or other similar terms can refer to computing that can share processing resources and data to one or more computer and/or other device(s) on an as needed basis to enable access to a shared pool of configurable computing resources).
As per claim 17, it is a monitoring component claim of claim 14, so it is rejected for similar reasons. Additionally, Howland teaches a monitoring component, running on a server, the monitoring component comprising a duration monitoring sub-component and an index monitoring sub-component ([0021] Referring to FIG. 2, as is represented by line 148, timer thread 100 watches queue 120 of tasks 122, 124, 126. When one of these tasks 122 is ready, timer thread 100 calls the ready task to process, as is represented by line 102; that is, timer thread 100 dispatches task 122. Once task 122 completes, if timer thread 100 is still serving as the timer thread, timer thread again waits on queue 120 of elements waiting for the next one (task 124) to be ready to run, at which time, as is represented by line 104, timer thread 100 dispatches task 124; [0048] Furthermore, referring to FIG. 6, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium 220 providing program code for use by or in connection with a computer 222 or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium 220 can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution, system, apparatus, or device 222; Table 1 // Can't run. Wait letting the next task // determine how long. wait for ( pTask's nextExecutionTime ) - currentTime mseconds; Table 2 Step 218 timerThread = new thread // Obtain new timer // thread timerThread.start( ); // Start it running // Step 206, no. } else { // Nope, top task isn't ready to run. // Steps 208, 210. // We wait based on the execution time of the next // task scheduled to run. Wait for (pTask's nextExecutionTimer) - currentTime mseconds; [0035] if a new task is scheduled while the wait is occurring; abstract A timer thread monitors status of tasks in the queue and selectively dispatches tasks; [0022] Queue 120 of tasks 122, 124, 126 waiting to run is a queue data structure of tasks ordered by `next to run` time. Tasks 122, 124, and 126 are placed on this queue 120 when scheduled for execution. Queue 120 is visible to both timer thread 100 and guard thread 140, and thus is the common object used for signaling purposes between current timer thread 100 and guard thread 140. Both timer thread 100 and guard thread 140 act to reschedule tasks that are already on queue 120, as is represented by lines 148 and 144, and other threads, such as user thread 116, are responsible for scheduling new tasks, as is represented by line 143.).
As per claim 18, it is a server claim of claim 1, so it is rejected for similar reasons.
As per claim 19, Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner teach the server of claim 16. Hoflehner teaches wherein the resource scheduling strategy comprises recycling the computing resource allocated to the worker thread, and recycling, in a case where the worker thread is in the blocked state, the computing resource allocated to the worker thread ([0081] the compiler creates the threads in the thread creation phase and allocates resources for the threads in a subsequent thread resource allocation phase; [0036] the helper may terminate and release all the resources associate with the helper to main thread; [0048] resources, such as logical thread contexts, associated with the terminated helper threads are released back to the thread pool. This enables future requests to immediately recycle the logical thread contexts from the thread pool.).
Additionally, Nassi teaches the kernel is configured for: acquiring the resource scheduling strategy by using a scheduling class function provided in the kernel ([0085] the hyper-kernel can make three separate decisions: (1) which resources to migrate upon certain events, (2) when to migrate them, and (3) to where those resources should move).
As per claim 20, it is a non-transitory machine-readable storage medium claim of claim 1, so it is rejected for similar reasons. Additionally, Teflioudi teaches a non-transitory machine-readable storage medium, wherein executable codes are stored on the non-transitory machine-readable storage medium, and the executable codes, when executed by a processor of an electronic device, cause the processor to ([0023] In another aspect, there is provided a computer program product including a non-transitory computer readable medium storing instructions. The instructions may cause operations may executed by at least one data processor.).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner, as applied to claim 1 above, in view of Kamran et al. (US 20210224177 A1 hereinafter Kamran).
As per claim 2, Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner teach the method of claim 1. Teflioudi teaches wherein the scheduling component is provided with a delay function ([0036] The worker threads allocated to generate the portion of the result may be paused in between fetch calls, for example, by allowing these worker threads to sleep on a semaphore; The instant specification recites in [0074] that “the delay function may be, for example, a sleep function, a sem-wait function”.), and
the duration for which the worker thread is in the blocked state, comprises ([0067] one or more worker threads paused subsequent to the first fetch call; [0059] the worker threads 170 may be paused (e.g., to sleep on a semaphore) upon generating the first portion of the result for the query; [0052] The first subset of results 204 are sent to the user client equipment 102 in a first reply 206, which are received by the client device 102 at a first time 208. During this time, the database execution engine 150 waits for a subsequent fetch request without utilizing additional resources. The client device 102 may later send a fetch request 210):
the delay function is executed by the worker thread ([0036] The worker threads allocated to generate the portion of the result may be paused in between fetch calls, for example, by allowing these worker threads to sleep on a semaphore;);
determining, in a case where the worker thread executes the delay function after executing the previous task, the delay function is executed ([0036] It should be appreciated that a worker thread may not pause mid-task but must complete an assigned task before it may pause to go to sleep.).
Additionally, Howland teaches the determining the duration for which the worker thread in the server is in the blocked state, comprises ([0021] Referring to FIG. 2, as is represented by line 148, timer thread 100 watches queue 120 of tasks 122, 124, 126. When one of these tasks 122 is ready, timer thread 100 calls the ready task to process, as is represented by line 102; that is, timer thread 100 dispatches task 122. Once task 122 completes, if timer thread 100 is still serving as the timer thread, timer thread again waits on queue 120 of elements waiting for the next one (task 124) to be ready to run, at which time, as is represented by line 104, timer thread 100 dispatches task 124; [0048] Furthermore, referring to FIG. 6, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium 220 providing program code for use by or in connection with a computer 222 or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium 220 can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution, system, apparatus, or device 222; Table 1 // Can't run. Wait letting the next task // determine how long. wait for ( pTask's nextExecutionTime ) - currentTime mseconds; Table 2 Step 218 timerThread = new thread // Obtain new timer // thread timerThread.start( ); // Start it running // Step 206, no. } else { // Nope, top task isn't ready to run. // Steps 208, 210. // We wait based on the execution time of the next // task scheduled to run. Wait for (pTask's nextExecutionTimer) - currentTime mseconds;):
determining, when a working cycle of the scheduling component is reached (abstract A system for scheduling tasks for execution includes a queue of tasks ordered by scheduled time for execution; );
determining a start time and an end time at which the delay function is executed; and determining a time period composed of the start time and the end time as the duration of the blocked state ([0021] Referring to FIG. 2, as is represented by line 148, timer thread 100 watches queue 120 of tasks 122, 124, 126. When one of these tasks 122 is ready, timer thread 100 calls the ready task to process, as is represented by line 102; that is, timer thread 100 dispatches task 122. Once task 122 completes, if timer thread 100 is still serving as the timer thread, timer thread again waits on queue 120 of elements waiting for the next one (task 124) to be ready to run, at which time, as is represented by line 104, timer thread 100 dispatches task 124; Table 1 // Can't run. Wait letting the next task // determine how long. wait for ( pTask's nextExecutionTime ) - currentTime mseconds; Table 2 Step 218 timerThread = new thread // Obtain new timer // thread timerThread.start( ); // Start it running // Step 206, no. } else { // Nope, top task isn't ready to run. // Steps 208, 210. // We wait based on the execution time of the next // task scheduled to run. Wait for (pTask's nextExecutionTimer) - currentTime mseconds;).
Additionally, Foukas teaches wherein a length of the working cycle is on an order of magnitude of microseconds ([0129] if scheduler 20 is running every 20 microseconds).
Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner fail to teach determining, when a working cycle of the scheduling component is reached, whether the delay function is executed by the worker thread.
However, Kamran teaches determining, when a working cycle of the scheduling component is reached, whether the delay function is executed by the worker thread ([0132] After the truck thread 224-1 is resumed, the external scheduler cycle takes a second timestamp to indicate the end of the suspension).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner with the teachings of Kamran to generate accurate performance measurements (see Kamran [0070] advantageously configured to generate highly accurate performance measurements for respective sub-threads).
Claims 4-6 are rejected under 35 U.S.C. 103 as being unpatentable over Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner, as applied to claim 1, in view of Goodson (US 20160085583 A1).
As per claim 4, Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner teach the method of claim 3. Howland teaches wherein the duration of the blocked state is composed of a start time point and an end time point ([0021] Referring to FIG. 2, as is represented by line 148, timer thread 100 watches queue 120 of tasks 122, 124, 126. When one of these tasks 122 is ready, timer thread 100 calls the ready task to process, as is represented by line 102; that is, timer thread 100 dispatches task 122. Once task 122 completes, if timer thread 100 is still serving as the timer thread, timer thread again waits on queue 120 of elements waiting for the next one (task 124) to be ready to run, at which time, as is represented by line 104, timer thread 100 dispatches task 124; Table 1 // Can't run. Wait letting the next task // determine how long. wait for ( pTask's nextExecutionTime ) - currentTime mseconds; Table 2 Step 218 timerThread = new thread // Obtain new timer // thread timerThread.start( ); // Start it running // Step 206, no. } else { // Nope, top task isn't ready to run. // Steps 208, 210. // We wait based on the execution time of the next // task scheduled to run. Wait for (pTask's nextExecutionTimer) - currentTime mseconds); determining a first duration and a second duration of two adjacent blocked states for a target worker thread, wherein the target worker thread is any one of a plurality of worker threads ([0021] Referring to FIG. 2, as is represented by line 148, timer thread 100 watches queue 120 of tasks 122, 124, 126. When one of these tasks 122 is ready, timer thread 100 calls the ready task to process, as is represented by line 102; that is, timer thread 100 dispatches task 122. Once task 122 completes, if timer thread 100 is still serving as the timer thread, timer thread again waits on queue 120 of elements waiting for the next one (task 124) to be ready to run, at which time, as is represented by line 104, timer thread 100 dispatches task 124; abstract A system for scheduling tasks for execution includes a queue of tasks ordered by scheduled time for execution. A timer thread monitors status of tasks in the queue and selectively dispatches tasks. A guard thread monitors status of tasks in the queue and selectively creates timer threads.).
Additionally, Ippatapu teaches the determining the workload index parameter of the worker thread according to the duration of the worker thread in the blocked state ([0045] Based on the above determination of a thread weight coefficient (PC) [0046] PC>1, thread is busy and is servicing jobs. [0047] PC<1, thread is less busy and is servicing less jobs and idle most of the time during the last time interval. [0048] PC=−1, thread is extremely busy servicing jobs. [0049] PC=1, thread is busy and idle equally).
Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner fail to teach determining a time interval between a first start time point in the first duration and a second start time point in the second duration; and determining a workload index parameter of the target worker thread according to the time interval.
However, Goodson teaches determining a time interval between a first start time point in the first duration and a second start time point in the second duration; and determining a workload index parameter of the target worker thread according to the time interval ([0078] the background threads are paused at every interval 610 (e.g., every 1/X seconds when the predefined criteria include pausing at every 1/X seconds). Thus, for a frame rate of 60 frames per second, the background threads are paused approximately every 16.7 milliseconds (16.7 ms≈1/X seconds for X=60).).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner with the teachings of Goodson to reduce delays (see Goodson [0024] This reduces delays in processing).
As per claim 5, Teflioudi, Howland, Ippatapu, Nassi, Foukas, Hoflehner and Goodson teach the method of claim 4. Goodson teaches wherein the determining the workload index parameter of the target worker thread according to the time interval, comprises: determining an idle time point, within the time interval, of the target worker thread in a case where the time interval is less than a first preset interval; determining, according to a plurality of adjacent idle time points of the target worker thread, a first frequency at which the idle time points of the target worker thread occur; and determining the first frequency as the workload index parameter of the target worker thread ([0078] the background threads are paused at every interval 610 (e.g., every 1/X seconds when the predefined criteria include pausing at every 1/X seconds). Thus, for a frame rate of 60 frames per second, the background threads are paused approximately every 16.7 milliseconds (16.7 ms≈1/X seconds for X=60); [0074] For a frame rendering at a frequency or refresh rate of X frames per second (i.e., X hertz), the interval 610 corresponds to 1/X seconds; [0041] the thread control value indicates whether processing of the respective layout object (e.g., layout object 1 (144-1)) is to be suspended in accordance with background-thread-control-timing criteria (e.g., a predefined time interval); [0074] FIG. 6 illustrates a timeline divided into equal intervals 610. Each interval 610 corresponds to an amount of time available within a frame. For a frame rendering at a frequency or refresh rate of X frames per second (i.e., X hertz), the interval 610 corresponds to 1/X seconds or less.).
As per claim 6, Teflioudi, Howland, Ippatapu, Nassi, Foukas, Hoflehner and Goodson the method of claim 5. Goodson teaches further comprising: sorting idle time points of each of the plurality of worker threads according to timing-sequence; determining, according to adjacent idle time points in a sorting result, a second frequency at which the idle time points of the plurality of worker threads occur; and determining a workload index parameter of the plurality of worker threads according to the second frequency ([0078] the background threads are paused at every interval 610 (e.g., every 1/X seconds when the predefined criteria include pausing at every 1/X seconds). Thus, for a frame rate of 60 frames per second, the background threads are paused approximately every 16.7 milliseconds (16.7 ms≈1/X seconds for X=60); [0074] For a frame rendering at a frequency or refresh rate of X frames per second (i.e., X hertz), the interval 610 corresponds to 1/X seconds).
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Teflioudi, Howland, Ippatapu, Nassi, Foukas, Hoflehner and Goodson, as applied to claims 5 and 6 above, in view of Chen (CN109815007A).
The portions pulled from Chen are from a translation of CN109815007A.
As per claim 7, Teflioudi, Howland, Ippatapu, Nassi, Foukas, Hoflehner, and Goodson teach the method of claim 6. Ippatapu teaches generating the resource scheduling strategy according to the workload index parameter ([0052] As shown, table 510 provides example formulas to determine a thread weight for different circumstances. In one or more embodiments, the thread weight coefficient (PC) described above can be indicative of the different circumstances. For example, as shown, in example circumstances where a thread is busy and frequently servicing jobs (PC>1), the new weight of the thread can be determined by adding the current thread weight to the determined weight coefficient. In different example circumstances where the thread is less busy and is servicing less jobs and idle most of the time during the last time interval (PC<1), the new weight of the thread can be determined by subtracting the determined weight coefficient from the current thread weight;).
Additionally, Goodson teaches wherein the first frequency and/or the second frequency are comprised in a target frequency ([0078] the background threads are paused at every interval 610 (e.g., every 1/X seconds when the predefined criteria include pausing at every 1/X seconds). Thus, for a frame rate of 60 frames per second, the background threads are paused approximately every 16.7 milliseconds (16.7 ms≈1/X seconds for X=60); [0074] For a frame rendering at a frequency or refresh rate of X frames per second (i.e., X hertz), the interval 610 corresponds to 1/X seconds).
Teflioudi, Howland, Ippatapu, Nassi, Foukas, Hoflehner and Goodson fail to teach determining, in a case where the target frequency is less than a preset minimum frequency, that the resource scheduling strategy is to newly create a worker thread and allocate the computing resource of the server to the newly created worker thread; and determining, in a case where the target frequency is larger than a preset maximum frequency, that the resource scheduling strategy is to recycle the computing resource allocated to the worker thread.
However, Chen teaches determining, in a case where the target frequency is less than a preset minimum frequency, that the resource scheduling strategy is to newly create a worker thread and allocate the computing resource of the server to the newly created worker thread ([0184] The execution module 209 is used to establish a new thread to execute the pending tasks corresponding to the target pending task quantity when the second judgment module 207 determines that there is no idle time greater than a preset time threshold among all the idle times.); and determining, in a case where the target frequency is larger than a preset maximum frequency, that the resource scheduling strategy is to recycle the computing resource allocated to the worker thread ([0015] When it is determined that there is a target idle time greater than a preset time threshold among all the idle times, the tasks to be processed corresponding to the target number of tasks to be processed are assigned to the thread corresponding to the target idle time.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi, Howland, Ippatapu, Nassi, Foukas, Hoflehner, and Goodson with the teachings of Chen to optimize resource usage (see Chen [0004] it is necessary to control the number of threads to optimize resource utilization).
As per claim 8, Teflioudi, Howland, Ippatapu, Nassi, Foukas, Hoflehner, and Goodson teach the method of claim 6. Ippatapu teaches generating the resource scheduling strategy according to the workload index parameter ([0052] As shown, table 510 provides example formulas to determine a thread weight for different circumstances. In one or more embodiments, the thread weight coefficient (PC) described above can be indicative of the different circumstances. For example, as shown, in example circumstances where a thread is busy and frequently servicing jobs (PC>1), the new weight of the thread can be determined by adding the current thread weight to the determined weight coefficient. In different example circumstances where the thread is less busy and is servicing less jobs and idle most of the time during the last time interval (PC<1), the new weight of the thread can be determined by subtracting the determined weight coefficient from the current thread weight;).
Additionally, Goodson teaches wherein the first frequency and/or the second frequency are comprised in a target frequency ([0078] the background threads are paused at every interval 610 (e.g., every 1/X seconds when the predefined criteria include pausing at every 1/X seconds). Thus, for a frame rate of 60 frames per second, the background threads are paused approximately every 16.7 milliseconds (16.7 ms≈1/X seconds for X=60); [0074] For a frame rendering at a frequency or refresh rate of X frames per second (i.e., X hertz), the interval 610 corresponds to 1/X seconds).
Teflioudi, Howland, Ippatapu, Nassi, Foukas, Hoflehner, and Goodson fail to teach determining, in a case where the target frequency is less than a preset minimum frequency, that the resource scheduling strategy is to newly create a worker thread and allocate the computing resource of the server to the newly created worker thread; and determining, in a case where the target frequency is larger than a preset maximum frequency, that the resource scheduling strategy is to recycle the computing resource allocated to the worker thread.
However, Chen teaches determining, in a case where the target frequency is less than a preset minimum frequency, that the resource scheduling strategy is to newly create a worker thread and allocate the computing resource of the server to the newly created worker thread ([0184] The execution module 209 is used to establish a new thread to execute the pending tasks corresponding to the target pending task quantity when the second judgment module 207 determines that there is no idle time greater than a preset time threshold among all the idle times.); and determining, in a case where the target frequency is larger than a preset maximum frequency, that the resource scheduling strategy is to recycle the computing resource allocated to the worker thread ([0015] When it is determined that there is a target idle time greater than a preset time threshold among all the idle times, the tasks to be processed corresponding to the target number of tasks to be processed are assigned to the thread corresponding to the target idle time.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner, and Goodson with the teachings of Chen to optimize resource usage (see Chen [0004] it is necessary to control the number of threads to optimize resource utilization).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner, as applied to claim 1 above, in view of Tsai et al. (US 20220311558 A1 hereinafter Tsai).
As per claim 9, Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner teach the method of claim 1. Ippatapu teaches the generating the resource scheduling strategy according to the workload index parameter, reallocates the computing resource according to the resource scheduling strategy ([0052] As shown, table 510 provides example formulas to determine a thread weight for different circumstances. In one or more embodiments, the thread weight coefficient (PC) described above can be indicative of the different circumstances. For example, as shown, in example circumstances where a thread is busy and frequently servicing jobs (PC>1), the new weight of the thread can be determined by adding the current thread weight to the determined weight coefficient. In different example circumstances where the thread is less busy and is servicing less jobs and idle most of the time during the last time interval (PC<1), the new weight of the thread can be determined by subtracting the determined weight coefficient from the current thread weight; [0027] Thread weight component 120 can assign weights to threads 140A-B based on the first likelihood and a first share of resources of the multithreaded processor 130 can be assigned by scheduler 160 to threads 140A-B based on respective weights of the threads.).
Additionally, Nassi teaches such that the kernel of the server reallocates the computing resource of the server ([0085] the hyper-kernel can make three separate decisions: (1) which resources to migrate upon certain events, (2) when to migrate them, and (3) to where those resources should move; [0044] each of which has a hyper-kernel running on server hardware).
Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner fail to teach acquiring a generation time of the resource scheduling strategy and a generation time of a previous resource scheduling strategy; discarding the resource scheduling strategy in a case where a time interval between the two generation times is less than a second preset interval, wherein the resource scheduling strategy and the previous resource scheduling strategy correspond to a same function instance; and sending the resource scheduling strategy to the kernel in a case where the time interval between the two generation times is larger than the second preset interval.
However, Tsai teaches acquiring a generation time of the resource scheduling strategy and a generation time of a previous resource scheduling strategy; discarding the resource scheduling strategy in a case where a time interval between the two generation times is less than a second preset interval, wherein the resource scheduling strategy and the previous resource scheduling strategy correspond to a same function instance ([0111] When a blind transmission indication is provided by a DCI format and the receiving timing of the DCI cannot ensure the processing time (e.g., the DCI schedules a PUSCH with a scheduling offset shorter than the minimum time gap between two consecutive PUSCHs), the UE may ignore the scheduling indication for the PUSCH by the PDCCH; Table 1:UL HARQ retransmission(s) scheduling not based on previous/initial transmission packet decoding result in gNB. (e.g., The time duration between two consecutive PUSCH transmissions may <1 RTT)); and sending the resource scheduling strategy to the kernel in a case where the time interval between the two generation times is larger than the second preset interval (Table 1: UL HARQ retransmission(s) Mode UL HARQ scheduling based on previous/initial A retransmission transmission packet decoding result in gNB. (e.g., The time duration between two consecutive PUSCH transmissions should >1 RTT)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi, Howland, Ippatapu, Nassi, Foukas, and Hoflehner with the teachings of Tsai to improve efficiency (see Tsai [0090] improve the efficiency of the wireless communication system.).
Claims 11 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Teflioudi, in view of Howland, in view of Ippatapu, in view of Nassi, in view of Krasilnikov et al. (US 11937103 B1 hereinafter Krasilnikov), in view of Foukas, and further in view of Hoflehner.
As per claim 11, Teflioudi teaches the invention substantially as claimed including a thread processing method, the method comprising: a duration for which a worker thread is in a blocked state, wherein the worker thread is in the blocked state after a task corresponding to a function instance is completed and before a next task is acquired (Fig. 3; [0034] As used herein, the term “worker thread” may refer to a thread or thread of execution, which is a sequence of instructions managed independently by a scheduler; [0067] one or more worker threads paused subsequent to the first fetch call; [0059] the worker threads 170 may be paused (e.g., to sleep on a semaphore) upon generating the first portion of the result for the query; [0052] The first subset of results 204 are sent to the user client equipment 102 in a first reply 206, which are received by the client device 102 at a first time 208. During this time, the database execution engine 150 waits for a subsequent fetch request without utilizing additional resources. The client device 102 may later send a fetch request 210; [0049] The one or more worker threads 170 allocated to generate the portion of the result may be paused in between fetch calls, for example, by allowing the one or more worker threads 170 to complete their respective tasks before going to sleep on a semaphore. Upon receiving a subsequent fetch call that requires more than the buffered data, the data execution engine 150 may wake up the paused worker threads 170 to continue performing the remaining tasks associated with the query; [0050] As used herein, the term “fetch call” may refer to a particular type of request that form a part of a query requesting data from the one or more databases 190. For example, the data execution engine 150 may receive, from the client device 102, an open request to initiate the query. Following the initial open request, the data execution engine 150 may receive one or more subsequent fetch calls, each of which requesting at least a portion of the results of the query. That is, a single fetch call may request, from the data execution engine 150, at least a portion of the results associated with the query.).
Teflioudi fails to teach a thread processing method, applied to a cloud server in which a 5G private network runs, the method comprising: determining a duration for which a worker thread in the cloud server is in a blocked state, wherein the worker thread is in the blocked state after a task in a task queue corresponding to a function instance in the cloud server is completed and before a next ask in the task queue is acquired; determining a workload index parameter of the worker thread according to the duration of the worker thread in the blocked state, wherein the function instance comprises a functional network element in the 5G private network which comprises a base station; and generating a resource scheduling strategy according to the workload index parameter, such that a kernel of the cloud server reallocates a computing resource of the cloud server according to the resource scheduling strategy, wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread; wherein a resource scheduling cycle is on an order of magnitude of microseconds, and resource scheduling is performed in the blocked state of the worker thread between adjacent tasks.
However, Howland teaches a thread processing method, applied to a server, the method comprising: determining a duration for which a worker thread in the server is in a blocked state, wherein the worker thread is in the blocked state after a task in a task queue corresponding to a function instance in the server is completed and before a next task in the task queue is acquired; resource scheduling is performed in the blocked state of the worker thread between adjacent tasks ([0021] Referring to FIG. 2, as is represented by line 148, timer thread 100 watches queue 120 of tasks 122, 124, 126. When one of these tasks 122 is ready, timer thread 100 calls the ready task to process, as is represented by line 102; that is, timer thread 100 dispatches task 122. Once task 122 completes, if timer thread 100 is still serving as the timer thread, timer thread again waits on queue 120 of elements waiting for the next one (task 124) to be ready to run, at which time, as is represented by line 104, timer thread 100 dispatches task 124; [0048] Furthermore, referring to FIG. 6, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium 220 providing program code for use by or in connection with a computer 222 or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium 220 can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution, system, apparatus, or device 222; Table 1 // Can't run. Wait letting the next task // determine how long. wait for ( pTask's nextExecutionTime ) - currentTime mseconds; Table 2 Step 218 timerThread = new thread // Obtain new timer // thread timerThread.start( ); // Start it running // Step 206, no. } else { // Nope, top task isn't ready to run. // Steps 208, 210. // We wait based on the execution time of the next // task scheduled to run. Wait for (pTask's nextExecutionTimer) - currentTime mseconds; [0035] if a new task is scheduled while the wait is occurring).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi with the teachings of Howland to reduce resource usage (see Howland [0046] It is an advantage of the present invention that there is provided an improved system and method for scheduling tasks on a minimum number of threads.).
Teflioudi and Howland fail to teach a thread processing method, applied to a cloud server in which a 5G private network runs; a worker thread in the cloud server; a function instance in the cloud server; determining a workload index parameter of the worker thread according to the duration of the worker thread in the blocked state, wherein the function instance comprises a functional network element in the 5G private network which comprises a base station; and generating a resource scheduling strategy according to the workload index parameter, such that a kernel of the cloud server reallocates a computing resource of the cloud server according to the resource scheduling strategy, wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread; wherein a resource scheduling cycle is on an order of magnitude of microseconds.
However, Ippatapu teaches determining a workload index parameter of the worker thread according to the duration of the worker thread in the blocked state ([0045] Based on the above determination of a thread weight coefficient (PC) [0046] PC>1, thread is busy and is servicing jobs. [0047] PC<1, thread is less busy and is servicing less jobs and idle most of the time during the last time interval. [0048] PC=−1, thread is extremely busy servicing jobs. [0049] PC=1, thread is busy and idle equally); and generating a resource scheduling strategy according to the workload index parameter, reallocates a computing resource according to the resource scheduling strategy ([0052] As shown, table 510 provides example formulas to determine a thread weight for different circumstances. In one or more embodiments, the thread weight coefficient (PC) described above can be indicative of the different circumstances. For example, as shown, in example circumstances where a thread is busy and frequently servicing jobs (PC>1), the new weight of the thread can be determined by adding the current thread weight to the determined weight coefficient. In different example circumstances where the thread is less busy and is servicing less jobs and idle most of the time during the last time interval (PC<1), the new weight of the thread can be determined by subtracting the determined weight coefficient from the current thread weight; [0027] Thread weight component 120 can assign weights to threads 140A-B based on the first likelihood and a first share of resources of the multithreaded processor 130 can be assigned by scheduler 160 to threads 140A-B based on respective weights of the threads.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi and Howland with the teachings of Ippatapu to optimize resource usage (see Ippatapu [0027] Thread weight component 120 can assign weights to threads 140A-B based on the first likelihood and a first share of resources of the multithreaded processor 130 can be assigned by scheduler 160 to threads 140A-B based on respective weights of the threads. It should be noted that, the approaches described herein can also be extended or generalized to any scheduler to adaptively tune several metrics for optimizing the usage of CPU resources and improving the overall performance of the system.).
Teflioudi, Howland, and Ippatapu fail to teach a thread processing method, applied to a cloud server in which a 5G private network runs; a worker thread in the cloud server; a function instance in the cloud server; wherein the function instance comprises a functional network element in the 5G private network which comprises a base station; such that a kernel of the cloud server reallocates a computing resource of the cloud server, wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread; wherein a resource scheduling cycle is on an order of magnitude of microseconds.
However, Nassi teaches such that a kernel of the cloud server reallocates a computing resource of the cloud server ([0085] the hyper-kernel can make three separate decisions: (1) which resources to migrate upon certain events, (2) when to migrate them, and (3) to where those resources should move; [0044] each of which has a hyper-kernel running on server hardware; [0037] Further, the techniques described herein can also be used in conjunction with distributed systems; [0002] Software applications are increasingly operating on large sets of data and themselves becoming increasingly complex. In some cases, distributed computing systems are used to support such applications (e.g., where a large database system distributes portions of data onto a landscape of different server nodes).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi, Howland, and Ippatapu with the teachings of Nassi to optimize resource utilization (see Nassi [0043] the hyper-kernel optimizes use of resources).
Teflioudi, Howland, Ippatapu, and Nassi fail to teach a thread processing method, applied to a cloud server in which a 5G private network runs; a worker thread in the cloud server; a function instance in the cloud server; wherein the function instance comprises a functional network element in the 5G private network which comprises a base station; wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread; wherein a resource scheduling cycle is on an order of magnitude of microseconds.
However, Krasilnikov teaches a thread processing method, applied to a cloud server in which a 5G private network runs; a worker thread in the cloud server; a function instance in the cloud server; wherein the function instance comprises a functional network element in the 5G private network which comprises a base station (Col. 4 lines 55-64 According to some embodiments, a system may comprise one or more control plane servers (CPS s) of a cloud provider network, and a virtualization server (VS) at an edge location or edge premise of the cloud provider network (a location other than a primary data center of the cloud provider network). The VS, which may also be referred to as an RBA processing server or RPS, may comprise a network function accelerator (NFA) for RBAs, and an RBA configuration manager or RCM. The RCM may comprise one or more processes or threads; Col. 7 lines 35-40 both core and RAN network functions can additionally or alternatively be run on an radio-based application processing server (RPS) provisioned as a virtualization server by a cloud provider, for example an edge device provisioned to a customer to implement a private 5G network; Col. 20 lines 1-3 A given RAN node (such as a gNodeB in the case of 5G applications, a 3GPP compliant implementation of a 5G-NR base station); Col. 11 lines 20-24 for example as a multi-edge cloud having physical infrastructure spread across telecommunication data centers, telecommunication aggregation sites, and/or telecommunication base stations within the telecommunication network.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi, Howland, Ippatapu, and Nassi with the teachings of Krasilnikov since 5G provides greater bandwidth (see Krasilnikov Col. 1 lines 15-18 5G technology offers greatly increased bandwidth, thereby broadening the cellular market beyond smartphones to provide last-mile connectivity to desktops, set-top boxes, laptops, Internet of Things (IoT) devices).
Teflioudi, Howland, Ippatapu, Nassi, and Krasilnikov fail to teach wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread; wherein a resource scheduling cycle is on an order of magnitude of microseconds.
However, Foukas teaches wherein a resource scheduling cycle is on an order of magnitude of microseconds ([0129] if scheduler 20 is running every 20 microseconds).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi, Howland, Ippatapu, Nassi, and Krasilnikov with the teachings of Foukas to improve the utilization of resources (see Foukas [0047] improvement in the utilization of the CPU resources).
Teflioudi, Howland, Ippatapu, Nassi, Krasilnikov, and Foukas fail to teach wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread.
However, Hoflehner teaches wherein the resource scheduling strategy comprises newly creating a worker thread and allocating the computing resource to the newly created worker thread, and recycling the worker thread and recycling the computing resource allocated to the worker thread ([0081] the compiler creates the threads in the thread creation phase and allocates resources for the threads in a subsequent thread resource allocation phase; [0036] the helper may terminate and release all the resources associate with the helper to main thread; [0048] resources, such as logical thread contexts, associated with the terminated helper threads are released back to the thread pool. This enables future requests to immediately recycle the logical thread contexts from the thread pool.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi, Howland, Ippatapu, Nassi, Krasilnikov, and Foukas with the teachings of Hoflehner to improve thread performance (see Hoflehner [0093] illustrating an improvement of performance by the helper thread).
As per claim 13, Teflioudi, Howland, Ippatapu, Nassi, Krasilnikov, Foukas, and Hoflehner teach the method of claim 11. Krasilnikov teaches wherein, the functional network element comprises a functional network element in a core network comprised in the 5G private network and/or an access network element in an access network comprised in the 5G private network (Col. 7 lines 35-40 both core and RAN network functions can additionally or alternatively be run on an radio-based application processing server (RPS) provisioned as a virtualization server by a cloud provider, for example an edge device provisioned to a customer to implement a private 5G network; Col. 20 lines 1-3 A given RAN node (such as a gNodeB in the case of 5G applications, a 3GPP compliant implementation of a 5G-NR base station)).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Teflioudi, Howland, Ippatapu, Nassi, Krasilnikov, Foukas, and Hoflehner, as applied to claim 11 above, in view of Kamran.
As per claim 12, Teflioudi, Howland, Ippatapu, Nassi, Krasilnikov, Foukas, and Hoflehner teach the method of claim 11. Teflioudi teaches the duration for which the worker thread is in the blocked state, comprises ([0067] one or more worker threads paused subsequent to the first fetch call; [0059] the worker threads 170 may be paused (e.g., to sleep on a semaphore) upon generating the first portion of the result for the query; [0052] The first subset of results 204 are sent to the user client equipment 102 in a first reply 206, which are received by the client device 102 at a first time 208. During this time, the database execution engine 150 waits for a subsequent fetch request without utilizing additional resources. The client device 102 may later send a fetch request 210):
the delay function is executed by the worker thread ([0036] The worker threads allocated to generate the portion of the result may be paused in between fetch calls, for example, by allowing these worker threads to sleep on a semaphore;);
determining, in a case where the worker thread executes the delay function after executing the previous task, the delay function is executed ([0036] It should be appreciated that a worker thread may not pause mid-task but must complete an assigned task before it may pause to go to sleep.).
Additionally, Howland teaches the determining the duration for which the worker thread in the server is in the blocked state, comprises: determining a start time and an end time at which the delay function is executed; and determining a time period composed of the start time and the end time as the duration of the blocked state ([0021] Referring to FIG. 2, as is represented by line 148, timer thread 100 watches queue 120 of tasks 122, 124, 126. When one of these tasks 122 is ready, timer thread 100 calls the ready task to process, as is represented by line 102; that is, timer thread 100 dispatches task 122. Once task 122 completes, if timer thread 100 is still serving as the timer thread, timer thread again waits on queue 120 of elements waiting for the next one (task 124) to be ready to run, at which time, as is represented by line 104, timer thread 100 dispatches task 124; [0048] Furthermore, referring to FIG. 6, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium 220 providing program code for use by or in connection with a computer 222 or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium 220 can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution, system, apparatus, or device 222; Table 1 // Can't run. Wait letting the next task // determine how long. wait for ( pTask's nextExecutionTime ) - currentTime mseconds; Table 2 Step 218 timerThread = new thread // Obtain new timer // thread timerThread.start( ); // Start it running // Step 206, no. } else { // Nope, top task isn't ready to run. // Steps 208, 210. // We wait based on the execution time of the next // task scheduled to run. Wait for (pTask's nextExecutionTimer) - currentTime mseconds; [0035] if a new task is scheduled while the wait is occurring).
Additionally, Foukas teaches determining, when the resource scheduling cycle of the cloud server is reached ([0129] if scheduler 20 is running every 20 microseconds)..
Additionally, Ippatapu teaches wherein the cloud server is provided with a delay function ([0032] A yield state can correspond to a state where the thread is waiting to execute; [0082] Computer 1012 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 1044. Remote computer(s) 1044 can be a personal computer, a server, a router, a network PC, cloud storage, a cloud service, code executing in a cloud computing environment, a workstation, a microprocessor-based appliance, a peer device, or other common network node and the like, and typically comprises many or all of the elements described relative to computer 1012. A cloud computing environment, the cloud, or other similar terms can refer to computing that can share processing resources and data to one or more computer and/or other device(s) on an as needed basis to enable access to a shared pool of configurable computing resources that can be provisioned and released readily. Cloud computing and storage solutions can store and/or process data in third-party data centers).
Teflioudi, Howland, Ippatapu, Nassi, Krasilnikov, Foukas, and Hoflehner fail to teach determining, when a resource scheduling cycle is reached, whether the delay function is executed by the worker thread.
However, Kamran teaches determining, when a resource scheduling cycle is reached, whether the delay function is executed by the worker thread ([0132] After the truck thread 224-1 is resumed, the external scheduler cycle takes a second timestamp to indicate the end of the suspension).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Teflioudi, Howland, Ippatapu, Nassi, Krasilnikov, Foukas, and Hoflehner with the teachings of Kamran to generate accurate performance measurements (see Kamran [0070] advantageously configured to generate highly accurate performance measurements for respective sub-threads).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HSING CHUN LIN whose telephone number is (571)272-8522. The examiner can normally be reached Mon - Fri 9AM-5PM.
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, Aimee Li can be reached at (571) 272-4169. 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.
/H.L./Examiner, Art Unit 2195
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights