DETAILED ACTION
Claims 1-20 are pending.
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 .
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation is: “The scheduling apparatus is configured to” in claim 16.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
Claim 15 recites the limitation "the parameter" in line 6. There is insufficient antecedent basis for this limitation in the claim.
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-5 and 7-20 are rejected under 35 U.S.C. 103 as being unpatentable over Patel et al. (US 2019/0050263 A1) in further view of Chang et al. (US 2019/0129752 A1).
Regarding claim 1, Patel teaches the invention substantially as claimed including a data processing method, wherein the method is applied to a computing device, the computing device comprises a scheduling apparatus and at least two processing unit sets, each processing unit set comprises at least one processing unit (Abstract: The compute device includes a compute engine to execute an application. The compute device also includes an accelerator pool including multiple accelerator devices. Additionally, the compute device includes an acceleration scheduler logic unit; wherein the compute engine corresponds to a first processing set and the accelerator pool corresponds to a second processing unit set; [0010] The compute device 110 is equipped with a pool of accelerator devices 160 which each may be embodied as any device or circuitry (e.g., a field programmable gate array (FPGA), a co-processor, a graphics processing unit (GPU), etc.) capable of executing operations faster than a general purpose processor. In the illustrative embodiment, the accelerator devices 160 include multiple FPGAs 170, 172. While two FPGAs 170, 172 are shown, it should be understood that in other embodiments, the compute device 110 may include a different number of (e.g., more) FPGAs. The compute device 110 additionally includes an acceleration scheduler logic unit 150, which may be embodied as any dedicated circuitry or device (e.g., a co-processor, an application specific integrated circuit (ASIC), etc.) capable of assigning (e.g., scheduling) the acceleration of functions among the accelerator devices 160.; [0012] The compute engine 210 may be embodied as any type of device or collection of devices capable of performing various compute functions described below. In some embodiments, the compute engine 210 may be embodied as a single device such as an integrated circuit, an embedded system, a field-programmable gate array (FPGA), a system-on-a-chip (SOC), or other integrated system or device. In the illustrative embodiment, the compute engine 210 includes or is embodied as a processor 212 and a memory 214.; [0024] data processing), the scheduling apparatus is communicatively connected to processing units in the at least two processing unit sets ([0010] The compute device 110 additionally includes an acceleration scheduler logic unit 150, which may be embodied as any dedicated circuitry or device (e.g., a co-processor, an application specific integrated circuit (ASIC), etc.) capable of assigning (e.g., scheduling) the acceleration of functions among the accelerator devices 160. In doing so, the acceleration scheduler logic unit 150 offloads the scheduling functions from a general purpose processor of the compute device 110.; [0012] The processor 212, in the illustrative embodiment, also includes the acceleration scheduler logic unit 150, described above with reference to FIG. 1. In other embodiments, the acceleration scheduler logic unit 150 may be separate from the processor 212 (e.g., on a different die).; Fig. 2), and the method comprises:
receiving, by the scheduling apparatus, a data processing request, wherein the data processing request comprises a function identifier ([0023] the method 300 advances to block 334 of FIG. 4, in which the compute device 110 intercepts (e.g., receives), with the acceleration scheduler logic unit 150, the request for acceleration.; [0024] the acceleration scheduler logic unit 150, in the illustrative embodiment, determines parameters of the request for acceleration (e.g., by parsing parameters included in the request), as indicated in block 338. In doing so, and as indicated in block 340, the acceleration scheduler logic unit 150 may determine the type(s) of function(s) to be accelerated. The type of each function (e.g., encryption, compression, convolution, etc.) may be included as a parameter of the request (e.g., as an alphanumeric code or description). In other embodiments, the name of the function may be included in the request, and the acceleration scheduler logic unit 150 may compare the name of the function to a set of data that maps names of functions to types of functions, to determine which type of function is being requested.), and
the function identifier indicates a function that needs to be called to process the data processing request ([0024] The type of each function (e.g., encryption, compression, convolution, etc.) may be included as a parameter of the request (e.g., as an alphanumeric code or description). In other embodiments, the name of the function may be included in the request,);
determining, by the scheduling apparatus, a first processing unit set from the at least two processing unit sets based on the function identifier, and determining a target processing unit in the first processing unit set ([0025] Additionally, in scheduling the requested acceleration, the acceleration scheduler logic unit 150, in the illustrative embodiment, determines a present status of each accelerator device 160, as indicated in block 346. In doing so, the compute device 110 may determine the types of functions each accelerator device 160 is presently configured to accelerate (e.g., which bit streams have been loaded by each accelerator device 160), as indicated in block 348. Additionally, the acceleration scheduler logic unit 150 may determine a present available capacity of each accelerator device 160 (e.g., how heavily loaded each accelerator device 160 is), as indicated in block 350. In doing so, and as indicated in block 352, the acceleration scheduler logic unit 150 may determine a present queue depth (e.g., a number of acceleration functions that have not yet been completed) of each accelerator device 160.; [0026] Further, as indicated in block 354, in scheduling the requested acceleration, the acceleration scheduler logic unit 150, assigns the function(s) to be accelerated to the accelerator device(s) 160 based on the parameters of the request (e.g., from block 338) and the present status of the accelerator devices 160 (e.g., from block 346).); and
processing, by the target processing unit, the data processing request to obtain a data processing result ([0027] Further, the accelerator devices 160 operate on input data from the request(s) for acceleration (e.g., encrypting input data, compressing input data, etc.), as indicated in block 368. Further, the accelerator devices 160 produce output data (e.g., the encrypted form of the data, the compressed form of the data, etc.), as indicated in block 370. Further, the accelerator devices 160 may notify the acceleration scheduler logic unit 150 of completion of acceleration of a function, as indicated in block 372 (e.g., by sending a message to the acceleration scheduler logic unit 150 through the I/O subsystem 218, by setting a predefined value in a register, etc.). In block 374, the acceleration scheduler logic unit 150 determines whether the requested acceleration of a function, or all of the functions in a sequence, is complete… Otherwise (e.g., if acceleration is complete), the method 300 advances to block 376, in which the compute device 110 (e.g., the acceleration scheduler logic unit 150) provides the output data to the corresponding application(s) 140 (e.g., the application(s) 140 that requested acceleration), such as by providing each corresponding application 140 with a reference to (e.g., an address of) the output data in memory (e.g., the memory 214).).
While Patel teaches the scheduling unit capable of offloading tasks between a processor and accelerator devices and also could be within a processor 212 or external to it, Patel does not explicitly teach the scheduling apparatus is communicatively connected to processing units in the at least two processing unit sets.
However, Chang teaches a multi-processor system includes multiple processors arranged in multiple clusters. Different clusters have different power and performance characteristics and a task scheduler to schedule tasks to the processors (See Abstract). Further, Chang teaches the scheduling apparatus is communicatively connected to processing units in the at least two processing unit sets ([0007] a task scheduler which is to schedule tasks to processors arranged in multiple clusters, with different clusters having different power and performance characteristics; Fig. 2).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chang of scheduling tasks among different clusters of processing elements with the processor and accelerators as taught by Patel to dynamically allocate tasks. The modification would have been motivated by the desire of improving resource utilization.
Regarding claim 2, Chang teaches wherein a computing capability of a processing unit in the first processing unit set is lower than a computing capability of a processing unit comprised in a second processing unit set in the at least two processing unit sets ([0003] DVFS can coordinate with task scheduling such that the operating frequency of a processor is adjusted when tasks are placed on or removed from the processor.; [0021]; [0022] In one embodiment, processors in the same cluster have the same processor type, and processors in different clusters have different processor types. Processors of different processor types have different hardware characteristics which may be measured by their capacities (e.g., measured by million instructions per second (MIPS)) and/or energy efficiency (e.g., measured by power consumption). The processors of different processor types share the same instruction set architecture (ISA); that is, they can execute the same programs and software applications. In one embodiment, the processors of different processor types may have different microarchitecture to deliver different compute performance and different power efficiency.; [0024] In one embodiment, the multi-processor system 110 includes a controller 170 to control the power and performance of the multi-processor system 110 to satisfy system performance requirements and power budget. The controller 170 may dynamically manage the power and performance by determining the number of processors to turn on (i.e., activated) and by controlling the operating point (e.g., the frequency and the voltage) of the activated processors.; [0025]).
Regarding claim 3, Chang teaches wherein power consumption of the processing unit in the first processing unit set is lower than power consumption of the processing unit comprised in the second processing unit set in the at least two processing unit sets ([0024] In one embodiment, the multi-processor system 110 includes a controller 170 to control the power and performance of the multi-processor system 110 to satisfy system performance requirements and power budget. The controller 170 may dynamically manage the power and performance by determining the number of processors to turn on (i.e., activated) and by controlling the operating point (e.g., the frequency and the voltage) of the activated processors.; [0025]).
Regarding claim 4, Patel teaches wherein the data processing request is sent by a network interface card in the computing device to the scheduling apparatus ([0010] As shown in FIG. 1, an illustrative system 100 for scheduling acceleration in a pool of accelerator devices includes a compute device 110 in communication with a client device 120 through a network 130. In operation, the compute device 110 executes one or more applications 140 (e.g., each in a container or a virtual machine) on behalf of the client device 120; [0018] The communication circuitry 218 may include a network interface controller (NIC) 220 (e.g., as an add-in device). The NIC 220 may be embodied as one or more add-in-boards, daughter cards, network interface cards, controller chips, chipsets, or other devices that may be used by the compute device 110 to connect with another compute device (e.g., the client device 120, etc.); [0023] In block 326, the compute device 110 executes one or more applications 140. In doing so, the compute device 110 may execute one or more applications 140 on behalf of the client device 120 (e.g., in response to a request from the compute sled 130 for the application to be executed), as indicated in block 328. In the illustrative embodiment, the compute device 110 executes the application(s) 140 with the compute engine 210, as indicated in block 330. In doing so, one or more of the applications 140 may request acceleration, such as by sending a request to the operating system for acceleration of a particular function within the application 140 (e.g., an encryption function, a compression function, a convolution function, etc.)).
Regarding claim 5, Patel teaches wherein the data processing request is from a service run on the computing device ([0023] In the illustrative embodiment, the compute device 110 executes the application(s) 140 with the compute engine 210, as indicated in block 330. In doing so, one or more of the applications 140 may request acceleration, such as by sending a request to the operating system for acceleration of a particular function within the application 140 (e.g., an encryption function, a compression function, a convolution function, etc.)).
Regarding claim 7, Patel teaches wherein the determining, by the scheduling apparatus, a first processing unit set from the at least two processing unit sets based on the function identifier, and determining a target processing unit in the first processing unit set specifically comprises:
determining, by the scheduling apparatus, the first processing unit set from the at least two processing unit sets based on the function identifier and a scheduling rule, and determining the target processing unit in the first processing unit set ([0024] Referring now to FIG. 4, after intercepting the request, the compute device 110 schedules the requested acceleration using the acceleration scheduler logic unit 150 (e.g., offloading the scheduling operations from the processor 212), as indicated in block 336. In doing so, the acceleration scheduler logic unit 150, in the illustrative embodiment, determines parameters of the request for acceleration (e.g., by parsing parameters included in the request), as indicated in block 338. In doing so, and as indicated in block 340, the acceleration scheduler logic unit 150 may determine the type(s) of function(s) to be accelerated. The type of each function (e.g., encryption, compression, convolution, etc.) may be included as a parameter of the request (e.g., as an alphanumeric code or description). In other embodiments, the name of the function may be included in the request, and the acceleration scheduler logic unit 150 may compare the name of the function to a set of data that maps names of functions to types of functions, to determine which type of function is being requested (e.g., scheduling rule)… Additionally or alternatively, the acceleration scheduler logic unit 150 may determine a time period in which the acceleration is to be completed, as indicated in block 344 (e.g., scheduling rule). The acceleration scheduler logic unit 150 may do so by parsing an indicator of a target latency for completing the function, comparing an identifier of the requesting application 140 (e.g., the application that produced the request for acceleration) to a set of target latencies associated with application identifiers, parsing an indication of a priority (e.g., low, medium, high, etc.) from the request and associating the indication of priority with one of a set of predefined latencies (e.g., scheduling rule), and/or through another method.; [0025-26]).
Regarding claim 8, Patel teaches wherein the scheduling rule comprises a request forwarding policy, the request forwarding policy indicates that the function identifier corresponds to the first processing unit set, or the request forwarding policy indicates that the function identifier corresponds to the first processing unit set and another processing unit set, and the another processing unit set is a subset of the at least two processing unit sets ([0024] In doing so, and as indicated in block 340, the acceleration scheduler logic unit 150 may determine the type(s) of function(s) to be accelerated. The type of each function (e.g., encryption, compression, convolution, etc.) may be included as a parameter of the request (e.g., as an alphanumeric code or description). In other embodiments, the name of the function may be included in the request, and the acceleration scheduler logic unit 150 may compare the name of the function to a set of data that maps names of functions to types of functions, to determine which type of function is being requested.; [0025] Additionally, in scheduling the requested acceleration, the acceleration scheduler logic unit 150, in the illustrative embodiment, determines a present status of each accelerator device 160, as indicated in block 346. In doing so, the compute device 110 may determine the types of functions each accelerator device 160 is presently configured to accelerate (e.g., which bit streams have been loaded by each accelerator device 160), as indicated in block 348. Additionally, the acceleration scheduler logic unit 150 may determine a present available capacity of each accelerator device 160 (e.g., how heavily loaded each accelerator device 160 is), as indicated in block 350. In doing so, and as indicated in block 352, the acceleration scheduler logic unit 150 may determine a present queue depth (e.g., a number of acceleration functions that have not yet been completed) of each accelerator device 160.; [0026] Further, as indicated in block 354, in scheduling the requested acceleration, the acceleration scheduler logic unit 150, assigns the function(s) to be accelerated to the accelerator device(s) 160 based on the parameters of the request (e.g., from block 338) and the present status of the accelerator devices 160 (e.g., from block 346). In doing so, the acceleration scheduler logic unit 150 may assign a function to the accelerator device 160 with the shortest queue depth (e.g., the accelerator device 160 that has the least amount of functions presently assigned to it), as indicated in block 356. The acceleration scheduler logic unit 150 may also match a function with an accelerator device 160 that is already configured to perform the type of function for which acceleration has been requested (e.g., the FPGA 170 has already loaded a bit stream to perform a compression function).).
Regarding claim 9, Patel teaches wherein the scheduling rule further comprises a priority policy, and when the function identifier in the data processing request corresponds to the first processing unit set and the another processing unit set, the scheduling apparatus determines the first processing unit set from the first processing unit set and the another processing unit set based on the priority policy ([0024] In doing so, and as indicated in block 340, the acceleration scheduler logic unit 150 may determine the type(s) of function(s) to be accelerated. The type of each function (e.g., encryption, compression, convolution, etc.) may be included as a parameter of the request (e.g., as an alphanumeric code or description). In other embodiments, the name of the function may be included in the request, and the acceleration scheduler logic unit 150 may compare the name of the function to a set of data that maps names of functions to types of functions, to determine which type of function is being requested…Additionally or alternatively, the acceleration scheduler logic unit 150 may determine a time period in which the acceleration is to be completed, as indicated in block 344. The acceleration scheduler logic unit 150 may do so by parsing an indicator of a target latency for completing the function, comparing an identifier of the requesting application 140 (e.g., the application that produced the request for acceleration) to a set of target latencies associated with application identifiers, parsing an indication of a priority (e.g., low, medium, high, etc.) from the request and associating the indication of priority with one of a set of predefined latencies, and/or through another method.; [0025-26])
Regarding claim 10, Patel teaches wherein the scheduling rule comprises a load balancing policy, and the determining a target processing unit in the first processing unit set comprises: determining the target processing unit from the first processing unit set based on the load balancing policy ([0024]; [0025] Additionally, in scheduling the requested acceleration, the acceleration scheduler logic unit 150, in the illustrative embodiment, determines a present status of each accelerator device 160, as indicated in block 346. In doing so, the compute device 110 may determine the types of functions each accelerator device 160 is presently configured to accelerate (e.g., which bit streams have been loaded by each accelerator device 160), as indicated in block 348. Additionally, the acceleration scheduler logic unit 150 may determine a present available capacity of each accelerator device 160 (e.g., how heavily loaded each accelerator device 160 is), as indicated in block 350. In doing so, and as indicated in block 352, the acceleration scheduler logic unit 150 may determine a present queue depth (e.g., a number of acceleration functions that have not yet been completed) of each accelerator device 160.; [0026]).
Regarding claim 11, Patel teaches wherein before the receiving, by the scheduling apparatus, a data processing request, the method further comprises: initializing, by a management unit in the computing device, the computing device ([0023] Subsequently, the method 300 advances to block 320, in which the compute device 110 boots the operating system. In doing so, the compute device 110 may provide device data (e.g., accelerator device data) determined during the BIOS boot process to the operating system (e.g., in an advanced control and power interface (ACPI) table). Afterwards, in block 322, the compute device 110 loads a runtime environment on each accelerator device 160 in the accelerator pool. In doing so, the compute device 110 may cause each accelerator device 160 to load a management bit stream (e.g., a set of code indicative of a configuration of gates in an FPGA 170, 172 to implement one or more functions), as indicated in block 324. The management bit stream may enable each FPGA 170, 172 to perform administrative functions in response to requests from the acceleration scheduler logic unit 150 (e.g., to load a bit stream associated with a particular function to be accelerated, to read an input data set into a local memory of the FPGA 170, 172, to send output data to the memory 214 or to another FPGA 170, 172, etc.).).
Regarding claim 12, Patel teaches wherein the initializing, by a management unit, the computing device comprises: configuring, by the management unit, the scheduling rule for the scheduling apparatus ([0023] Subsequently, the method 300 advances to block 320, in which the compute device 110 boots the operating system. In doing so, the compute device 110 may provide device data (e.g., accelerator device data) determined during the BIOS boot process to the operating system (e.g., in an advanced control and power interface (ACPI) table). Afterwards, in block 322, the compute device 110 loads a runtime environment on each accelerator device 160 in the accelerator pool. In doing so, the compute device 110 may cause each accelerator device 160 to load a management bit stream (e.g., a set of code indicative of a configuration of gates in an FPGA 170, 172 to implement one or more functions), as indicated in block 324.; wherein by programming accelerators to specific functions enables them to receive forwarded requests from the scheduler based on their preconfigured functionality).
Regarding claim 13, Patel teaches wherein the initializing, by a management unit, the computing device comprises: allocating memory space for a functional function corresponding to the function that needs to be called for the data processing request, and storing the functional function in the memory space ([0022];[0023] Subsequently, the method 300 advances to block 320, in which the compute device 110 boots the operating system. In doing so, the compute device 110 may provide device data (e.g., accelerator device data) determined during the BIOS boot process to the operating system (e.g., in an advanced control and power interface (ACPI) table). Afterwards, in block 322, the compute device 110 loads a runtime environment on each accelerator device 160 in the accelerator pool. In doing so, the compute device 110 may cause each accelerator device 160 to load a management bit stream (e.g., a set of code indicative of a configuration of gates in an FPGA 170, 172 to implement one or more functions), as indicated in block 324. The management bit stream may enable each FPGA 170, 172 to perform administrative functions in response to requests from the acceleration scheduler logic unit 150 (e.g., to load a bit stream associated with a particular function to be accelerated, to read an input data set into a local memory of the FPGA 170, 172, to send output data to the memory 214 or to another FPGA 170, 172, etc.).).
Regarding claim 14, Patel teaches wherein the processing, by the target processing unit, the data processing request comprises: calling, by the target processing unit based on the function identifier, the functional function corresponding to the function, and processing the data processing request based on a parameter of the data processing request and the functional function (See Fig 4, specifically step 354 and Fig. 5, step 364).
Regarding claim 15, Patel teaches wherein after the determining, by the scheduling apparatus, a first processing unit set from the at least two processing unit sets based on the function identifier, and determining a target processing unit in the first processing unit set, the method further comprises:
reporting, by the scheduling apparatus, a notification to the target processing unit ([0026] Further, as indicated in block 354, in scheduling the requested acceleration, the acceleration scheduler logic unit 150, assigns the function(s) to be accelerated to the accelerator device(s) 160 based on the parameters of the request (e.g., from block 338) and the present status of the accelerator devices 160 (e.g., from block 346).), and reading, by the target processing unit, the parameter of the data processing request from a memory of the computing device based on the notification, to process the data processing request ([0023] The management bit stream may enable each FPGA 170, 172 to perform administrative functions in response to requests from the acceleration scheduler logic unit 150 (e.g., to load a bit stream associated with a particular function to be accelerated, to read an input data set into a local memory of the FPGA 170, 172, to send output data to the memory 214 or to another FPGA 170, 172, etc.).).
Regarding claim 16, it is a system type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 17, it is a system type claim having similar limitations as claims 2+3 above. Therefore, it is rejected under the same rationale above.
Regarding claim 18, Patel teaches wherein the scheduling apparatus and the first processing unit set are deployed on a same die (Fig. 2, Processor 212 includes Accel. Schedul. Logic Unit 150; [0010] The compute device 110 additionally includes an acceleration scheduler logic unit 150, which may be embodied as any dedicated circuitry or device (e.g., a co-processor, an application specific integrated circuit (ASIC), etc.); [0012] In other embodiments, the acceleration scheduler logic unit 150 may be separate from the processor 212 (e.g., on a different die).), or the scheduling apparatus and the second processing unit set in the at least two processing unit sets are deployed on a same die.
Regarding claim 19, Patel teaches wherein the scheduling apparatus is a pluggable chip on the computing device ([0012] In other embodiments, the acceleration scheduler logic unit 150 may be separate from the processor 212 (e.g., on a different die).).
Regarding claim 20, it is a system type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Patel and Chang, in further view of Chamdani et al. (US 9,424,315 B2).
Regarding claim 6, Patel teaches different requests but neither Patel nor Chang explicitly teach wherein the data processing request is a data query request of a relational database, or the data processing request is a data retrieval and accumulation request of an artificial intelligence (AI) model training service.
However, Chamdani teaches wherein the data processing request is a data query request of a relational database (Claim 1, A method for scheduling database tasks for a relational query), or the data processing request is a data retrieval and accumulation request of an artificial intelligence (AI) model training service.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chamdani with the teachings of Patel and Chang to apply scheduling techniques to database tasks. The modification would have been motivated by the desire of combining known scheduling methods with different tasks to yield predictable results.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee J 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.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195
Prosecution Insights