DETAILED ACTION
Claims 1-19 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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
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(s) is/are: hardware logic arranged to and an output, arranged to in claim 10 and analysis logic arranged to in claim 14.
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.
For clarity of the record, the Examiner would like to point to claim 10 which discloses the hardware logic and output are executed by a classical computer.
Claim 10 recites hardware logic arranged to determine a class ID and a resource ID for a task and also for any parent task of the task. Since the function of determining a class ID and resource ID for a task is not coextensive with a general purpose classical computer, paragraph [0042] of the specification is read upon to disclose an algorithm for the resource management unit. Thus, the Examiner’s interpretation of “hardware logic arranged to determine a class ID and a resource ID for a task and also for any parent task of the task” as recited in claim 10 is any classical computer that uses a unit for determining IDs of a task and its parent.
Claim 10 further recites an output, arranged to output the class IDs and the resource IDs for both the task itself and any parent task of the task for storage associated with the task in the task queue. The terms ‘output’ and ‘storage’/’for storage associated with the task’ are unclear, i.e. it is not clear what is meant and for which technical features the protection is sought for. Thus, the Examiner’s interpretation of “an output, arranged to output the class IDs and the resource IDs for both the task itself and any parent task of the task for storage associated with the task in the task queue” as recited in claim 10 is any classical computer that stores class ID and resource ID parameters for each task and its intermediate parents in the tasks’ entry in the task queue.
For clarity of the record, the Examiner would like to point to claim 14 which discloses the analysis logic is executed by a classical computer.
Claim 14 recites analysis logic arranged to examining tasks in a task queue and parameters associated with the tasks. Since the function of examining tasks in a task queue and their parameters is not coextensive with a general purpose classical computer, paragraph [0043] of the specification is read upon to disclose an algorithm for the analysis logic. Thus, the Examiner’s interpretation of “analysis logic arranged to examining tasks in a task queue and parameters associated with the tasks” as recited in claim 14 is any classical computer that uses logic to examine a task queue and its parameters.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2 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.
Claims 2 and 15 recite the limitation selecting a task in the task queue with a parent task class ID and parent resource ID that does not match the class ID and resource ID of any tasks that precede it in the task queue. Under the most reasonable interpretation, given the specification, the examiner comes to understand the application as a task pipeline with multiple stages executing on a GPU without GPU synchronization barriers following executing of all task instances at each stage. However, It is unclear how a correct scheduling precedence is achieved as:
Claim 1, on which claim 2 depends, recites “selecting a task”. Claim 2 further recites “selecting a task”. However, it is unclear whether these two recited tasks are the same or different tasks. Corrections to this limitation of the claims are required to more accurately represent the interpretation above. If the interpretation above is inaccurate corrections to this limitation of the claims are required to more clearly define the scope of the claims.
Claim 19 recites the limitation parameters associated with the tasks, wherein the parameters comprise a class ID and a resource ID for both the task itself and any parent task of the task. Under the most reasonable interpretation, given the specification, the examiner comes to understand the application as a task pipeline with multiple stages executing on a GPU without GPU synchronization barriers following executing of all task instances at each stage. However, the parameters associated with the tasks are unclear as: Claim 10, on which claim 19 depends, recites “a class ID” and “a resource ID”. Claim 19 further recites “a class ID” and “a resource ID”. However, it is unclear whether these are the same IDs or different IDs. Corrections to this limitation of the claims are required to more accurately represent the interpretation above. If the interpretation above is inaccurate corrections to this limitation of the claims are required to more clearly define the scope of the claims.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claim 1 is directed to A method of operating a graphics processing unit (GPU), the method comprising scheduling tasks within the GPU by: a series of steps, and is therefore directed to a process, which is one of the four statutory categories.
Step 2A, Prong One:
Claim 1 recites the limitations:
examining tasks in a task queue and parameters associated with the tasks, wherein the parameters comprise a class ID and a resource ID for both the task itself and any parent task of the task, wherein a class ID identifies a class of the task from a hierarchy of task classes and a resource ID of the task identifies resources allocated and/or written to by the task;
selecting a task for execution based on an order of the tasks in the queue and the parameters;
all of which can be performed in the human mind through observation, evaluation, judgement and opinion, with the aid of pen and paper, and are therefore reciting a mental process.
Accordingly, claim 1 recites a judicial exception (i.e., an abstract idea).
Examiner notes that the interpretation of the recited system as a “mental
process” is reasonable, because the broadest reasonable interpretation of the claim
language recites an embodiment with one compute operation, one component, and one
compute instance— a human can mentally replicate this embodiment since no functions
specific to computer technology are recited.
Step 2A, Prong Two:
The additional element recited in claim 1 includes:
sending the selected task for execution
Regarding the additional element (i), the limitation recited amounts to insignificant extra-solution activity of transmitting data over a network, as it is merely sending data based on the judicial exception, which is not indicative of integration into a practical application. See MPEP 2106.04(d) and 2106.05(g).
Furthermore, the additional element results in sending the result of the exception, which is insignificant extra-solution activity. This additional element fails to integrate the judicial exception into a practical application. See MPEP 2106.04(d).
Step 2B:
Regarding the additional element (i), the limitation recited is insignificant extra-solution activity which necessary data outputting. Further, the additional element (i) is transmitting data over a network, which has been identified by the courts as well-understood, routine, and conventional activity. See MPEP 2106.05(d). The courts have found adding insignificant extra-solution activity and well-understood, routine and conventional activity is not enough to amount to significantly more than the recited judicial exception. See MPEP 2106.05(a) and 2106.05(g).
The combination of these additional elements amounts to a method comprising steps with can be performed mentally, and comprising steps of insignificant extra-solution and well-understood, routine and conventional activity.
Therefore, the additional elements, when considered individually and in combination, fail to add an inventive concept to the claim.
Consequently, claim 1 as a whole does not amount to significantly more than the recited judicial exceptions and the claim is not eligible.
Claim 2 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. Further claim 2 recites selecting a task in the task queue with a parent task class ID and parent resource ID that does not match the class ID and resource ID of any tasks that precede it in the task queue which can be performed in the human mind through observation, evaluation, judgement and opinion, with the aid of pen and paper, and are therefore reciting a mental process.
Claim 2 does not recite any additional elements beyond those recited in claim 1. Accordingly, for the same reasons presented with respect to claim 1, the additional elements are not indicative of integration into a practical application, nor do they amount to significantly more than the recited judicial exceptions. Thus, claim 2 is not eligible.
Claim 3 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. The additional elements recited in claim 1 were not indicative of integration into a practical application as they recite steps of insignificant extra-solution activity.
Claim 3 recites the additional element wherein a resource ID is assigned to a task when the task is created which amounts to mere instructions to apply the exception.
This additional element of mere instructions to apply the exception is not indicative of integration into a practical application. Further, these additional elements of mere instructions to apply the exception are not enough to amount to significantly more than the recited judicial exceptions. Even when considered in combination with the additional elements of claim 1, the additional elements do not amount to significantly more than the recited judicial exceptions and do not provide an inventive concept. Thus, claim 3 is not eligible.
Claim 4 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. Further claim 4 recites wherein selecting a task for execution is additionally based on a master unit that issued the task in the task queue which can be performed in the human mind through observation, evaluation, judgement and opinion, with the aid of pen and paper, and are therefore reciting a mental process.
Claim 4 does not recite any additional elements beyond those recited in claim 1. Accordingly, for the same reasons presented with respect to claim 1, the additional elements are not indicative of integration into a practical application, nor do they amount to significantly more than the recited judicial exceptions. Thus, claim 4 is not eligible.
Claim 5 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. The additional elements recited in claim 1 were not indicative of integration into a practical application as they recite steps of insignificant extra-solution activity.
Claim 5 recites the additional element wherein the task queue comprises tasks queued for execution and tasks currently running which amounts to mere instructions to apply the exception.
This additional element of mere instructions to apply the exception is not indicative of integration into a practical application. Further, these additional elements of mere instructions to apply the exception are not enough to amount to significantly more than the recited judicial exceptions. Even when considered in combination with the additional elements of claim 1, the additional elements do not amount to significantly more than the recited judicial exceptions and do not provide an inventive concept. Thus, claim 5 is not eligible.
Claim 6 is dependent on claim 1, and therefore inherits the same judicial exception recited in claim 1. Further claim 6 recites determining a class ID and a resource ID for a task and also for any parent task of the task, wherein a class ID identifies a class of the task from a hierarchy of task classes and a resource ID of the task identifies resources allocated and/or written to by the task; which can be performed in the human mind through observation, evaluation, judgement and opinion, with the aid of pen and paper, and are therefore reciting a mental process.
Claim 6 recites the additional element outputting the class IDs and resource IDs for both the task itself and any parent task of the task for storage associated with the task in a task queue which amounts to mere data outputting, and is therefore insignificant extra-solution activity. This additional element of insignificant extra-solution activity is not indicative of integration into a practical application. Even when considered in combination with the additional elements of claim 1, the additional elements comprise steps of insignificant extra-solution activity, which are not indicative of integration into a practical application.
This additional element of insignificant extra-solution activity is further considered to be the well-understood, routine and conventional activity identified by the courts of receiving and transmitting data over a network. See MPEP 2106.05(d). This additional element is not enough to amount to significantly more than the recited judicial exceptions. Even when considered in combination with the additional elements of claim 1, the additional elements do not provide an inventive concept and do not amount to significantly more than the recited judicial exceptions. Thus, claim 6 is not eligible.
Claim 7 is dependent on claim 6, and therefore inherits the same judicial exception recited in claims 1 and 6. Further claim 7 recites wherein determining a resource ID for a task comprises assigning a resource ID to the task which can be performed in the human mind through observation, evaluation, judgement and opinion, with the aid of pen and paper, and are therefore reciting a mental process.
Claim 7 does not recite any additional elements beyond those recited in claims 1 and 6. Accordingly, for the same reasons presented with respect to claims 1 and 6, the additional elements are not indicative of integration into a practical application, nor do they amount to significantly more than the recited judicial exceptions. Thus, claim 7 is not eligible.
Claim 8 is dependent on claim 7, and therefore inherits the same judicial exception recited in claims 1, 6 and 7. Further claim 8 recites allocating resources to the task; and assigning a resource ID for the allocated resources to the task which can be performed in the human mind through observation, evaluation, judgement and opinion, with the aid of pen and paper, and are therefore reciting a mental process.
Claim 8 does not recite any additional elements beyond those recited in claim(s) 1, 6 and 7. Accordingly, for the same reasons presented with respect to claims 1, 6 and 7, the additional elements are not indicative of integration into a practical application, nor do they amount to significantly more than the recited judicial exceptions. Thus, claim 8 is not eligible.
Claim 9 is dependent on claim 6, and therefore inherits the same judicial exception recited in claims 1 and 6. The additional elements recited in claims 1 and 6 were not indicative of integration into a practical application as they recite mere instructions to apply the exception and steps of insignificant extra-solution activity.
Claim 9 recites the additional element wherein the resources comprise shared register, coefficient registers or local memory registers which amounts to merely indicating a field of use or technological environment in which to apply the exception. This additional element of linking the exception to a technological environment is not indicative of integration into a practical application. Even when considered in combination with the additional elements of claims 1 and 6, the elements insignificant extra-solution activity and an attempt to limit the exception to a technological environment, which are not indicative of integration into a practical application.
This additional element, even when limiting the use of the idea to one particular
environment, is not enough to amount to significantly more than the recited judicial
exceptions. Even when considered in combination with the additional elements of
claims 1 and 6, the additional elements do not provide an inventive concept and do
not amount to significantly more than the recited judicial exceptions. Thus, claim 9 is not
eligible.
Claim 10 recites A resource management unit of a graphics processing unit (GPU), comprising: the logic to perform the steps of the method of claim 6. Thus, for the same reasons presented with respect to claim 6, claim 10 is rejected because the claimed invention is directed to an abstract idea without significantly more.
For clarity of the record, the additional elements recited above amount to mere instructions to apply the exception, which is neither indicative of integration into a practical application nor amounts to significantly more than the recited judicial exceptions.
Claims 11-13 recite substantially the same limitations as those recited in claims 7-9 respectively, applied to the apparatus of claim 10. Thus, for the same reasons presented with respect to claims 7-9, claims 11-13 are directed to an abstract idea without significantly more and are not eligible.
Claim 14 recites Scheduling and processing logic of a graphics processing unit (GPU), comprising: the logic to perform the steps of claim 1. Thus, for the same reasons presented with respect to claim 1, claim 14 is rejected because the claimed invention is directed to an abstract idea without significantly more.
For clarity of the record, the additional elements recited above amount to mere instructions to apply the exception, which is neither indicative of integration into a practical application nor amounts to significantly more than the recited judicial exceptions.
Claims 15-18 recite substantially the same limitations as those recited in claims 2-5, respectively, applied to the apparatus of claim 14. Thus, for the same reasons presented with respect to claims 2-5, claims 15-18 are directed to an abstract idea without significantly more and are not eligible.
Claim 19 recites A graphics processing unit (GPU) comprising: the resource management unit as set forth in claim 10; a task queue; a plurality of resources; and the steps of claim 6. Thus, for the same reasons presented with respect to claims 6 and 10, claim 19 is rejected because the claimed invention is directed to an abstract idea without significantly more.
For clarity of the record, the additional elements recited above amount to mere instructions to apply the exception, which is neither indicative of integration into a practical application nor amounts to significantly more than the recited judicial exceptions.
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-19 are rejected under 35 U.S.C. 103 as being unpatentable over Simon et al. (G.B. Pub. No. 2585306 A), hereinafter Simon, in view of Rastogi (U.S. Pub. No. 9223628 B2).
Regarding claim 1, Simon teaches A method of operating a graphics processing unit (GPU) ([0025] – “FIG. 1 is a schematic diagram showing a processor 100 which may be a GPU or other highly parallel processing unit”), the method comprising scheduling tasks within the GPU by:
examining tasks in a task queue and parameters associated with the tasks ([0027] – “scheduler 102 comprises a task scheduling engine 106, a task queue 108 […] As shown in FIG. 1, the scheduler 102 receives tasks 110 and these tasks 110 are added to the task queue 108 by the task scheduling engine 106 and then selectively scheduled for execution by the processing unit 104 as described in detail below. The tasks 110 may be of different types (e.g. they may relate to different types of computation and/or different types of data)”),
wherein the parameters comprise a class ID and a resource ID for both the task itself ([0028] – “Each task 110 that is received by the scheduler 102 (and hence by the task scheduling engine 106) has an identifier which identifies the type of the task and this identifier may be referred to as the task type I D. [...] (the task type ID) may, in various examples, be referred to as the Data Master ID and identify both the type of the task and the source of the task”; [0029] – “A task 110 that is received by the scheduler 102 (and hence by the task scheduling engine 106) may have another identifier in addition to the task type ID. The second identifier, where provided, identifies the data group to which the task applies and may be referred to as the data group ID. In various examples, all tasks 110 received by the scheduler 102 (and hence by the task scheduling engine 106) may have both a task type ID and a data group ID”),
wherein a class ID identifies a class of the task ([0028] – “Each task 110 that is received by the scheduler 102 (and hence by the task scheduling engine 106) has an identifier which identifies the type of the task and this identifier may be referred to as the task type I D. [...] (the task type ID) may, in various examples, be referred to as the Data Master ID and identify both the type of the task and the source of the task”; [0032] – “The data 120 associated with each task 110 in the queue 108 may take any form and in various examples it may comprise a plurality of state bits, as shown in FIG. 1. These state bits comprise one or more state bits 122 that track task specific dependencies [...] and these state bits 122 are updated by the task scheduling engine 106 when one of the dependencies complete”)
selecting a task for execution based on an order of the tasks in the queue and the parameters ([0030] – “The task scheduling engine 106 within the scheduler 102 adds tasks 110 that are received to the task queue 108 and then selectively schedules tasks from the queue 108 for execution by the processing unit 104”; [0038] – “Tasks are selected from those stored in the task queue 106 and the selection is made based on the wakeup event state data 109 and the state data 120 for each task”; [0037] – “state data may be updated (in block 304) by clearing the corresponding state bit(s), e.g. one or more bits 122, for the task(s) that relate to the completed dependency or updating a counter value [...] wakeup event state data to indicate a wakeup event for the particular task type ID (and optionally data group ID) associated with the task that relates to the completed dependency (block 306)”; [0039] – “The task scheduling engine 106 selects a task type by first identifying candidate task types (block 402) based on the wakeup event state data 109 and the contents of the task queue 108. Only those task types with a task in the task queue 108 (as added in block 204 of FIG. 2) and associated wakeup event state data 109 (e.g. an associated wakeup event state bit) set to indicate a wakeup event (as set in block 306 of FIG. 3) are candidate (or valid) task types. Having identified the candidate task types (in block 402), one of these candidate task types is selected (block 404)”);
and sending the selected task for execution ([0030] – “tasks 110 remain in the task queue 108 until execution is complete”).
Simon fails to expressly teach and any parent task of the task
from a hierarchy of task classes
and a resource ID of the task identifies resources allocated and/or written to by the task;
However, Rastogi teaches and any parent task of the task ([38] – “Task data may specify any number of prerequisites (e.g., a parent task) or no prerequisites, if none are needed”; [42] – “for each new task added to the dependency model all of the prerequisites for the task are known”)
from a hierarchy of task classes ([19] – “Some of the tasks 130, 150, and 160 may be significant tasks (e.g., primary tasks, critical tasks, or mandatory tasks) […] the other tasks 110, 120, and 140 may be tasks of lesser importance (e.g., secondary tasks, preparatory tasks, or optional tasks)”)
and a resource ID of the task identifies resources allocated and/or written to by the task ([29] – “assign a task to a data processing resource. For example, the data processing resource may be identified by an enumerated value. The developer may assign the task to the enumerated value, and all tasks assigned to the enumerated value will share the same data processing resource and its resource constraints, if any”; [36] – “task data (e.g., task dependency data) specifies a task identifier (e.g., Task ID) that uniquely identifies the task within DGTaskExecutor. For example, the task identifier may be an enumerated value. Task data may also specify a data processing resource to be utilized by the task, as well as one or more constraints on the data processing resource”; [37] – “Task data (e.g., task configuration data) may specify an ability to constrain a number of concurrently executing tasks that may utilize a particular data processing resource. The task data may specify usage of the data processing resource [...] The task data may specify a constraint upon the usage of the data processing resource. [...] The task data may specify information (e.g., metadata) pertinent to the data processing resource”);
Simon and Rastogi are considered to be analogous art to the claimed invention because they are in the same field as the claimed invention of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the methods of Simon to incorporate the task data such that the task data specifies the resource requirements of the task as taught by Rastogi. Incorporating the methods of Rastogi may reduce the likelihood of overburdening the data processing resource and avoid deadlocks (see Rastogi: [37] and [41]).
Regarding claim 2, the combination of Simon in view of Rastogi teaches The method according to claim 1, wherein selecting a task for execution based on an order of the tasks in the queue and the parameters comprises:
Simon further teaches selecting a task in the task queue with a parent task class ID and parent resource ID that does not match the class ID and resource ID of any tasks that precede it in the task queue ([0042] – “Having identified a task of the selected task type and optionally having a task type and data group ID that matches a wakeup event in the wakeup event state data (in block 406), a check is performed on the dependencies of the identified task (block 408). If all the task dependencies of the identified task are met ('Yes' in block 408), as indicated by the state data 122 (which may, for example, track task specific dependencies) for the identified task, then the identified task is sent for execution and the state data (e.g. bit 124) associated with the identified task is set to indicate that it has been sent for execution (block 410). If however, it is determined that not all the task dependencies of the identified task are met ('No' in block 408), the identified task is not yet ready for execution”).
Regarding claim 3, the combination of Simon in view of Rastogi teaches The method according to claim 1,
Simon further teaches wherein a resource ID is assigned to a task when the task is created ([0028] – “Each task 110 that is received by the scheduler 102 (and hence by the task scheduling engine 106) has an identifier which identifies the type of the task and this identifier may be referred to as the task type ID”; [0031] – “each task that is received by the task scheduling 106 and stored in the task queue 108 comprises a task type ID 116 and may also comprise a data group ID 118”).
Regarding claim 4, the combination of Simon in view of Rastogi teaches The method according to claim 1,
Simon further teaches wherein selecting a task for execution is additionally based on a master unit that issued the task in the task queue ([0028] – “Tasks of different types may be generated by different entities (which may be part of the processor 100 but are not shown in FIG. 1) and in various examples these entities which generate tasks may be referred to as Data Masters”).
Regarding claim 5, the combination of Simon in view of Rastogi teaches The method according to claim 1,
Simon further teaches wherein the task queue comprises tasks queued for execution and tasks currently running ([0036] – “In response to receiving a task 110 (block 202), the task scheduling engine 106 adds the task to the task queue 108 (block 204). […] The state data 120 for the newly added task are set by the task scheduling engine 106 (block 206) to indicate that the task is not currently executing in the processor block (e.g. bit 124) and to identify any task specific dependencies (e.g. bits 122)”; [0030] – “tasks 110 remain in the task queue 108 until execution is complete”).
Regarding claim 6, the combination of Simon in view of Rastogi teaches The method according to claim 1, further comprising managing task dependencies within the task queue of the GPU by:
Simon further teaches determining a class ID and a resource ID for a task ([0028] – “Each task 110 that is received by the scheduler 102 (and hence by the task scheduling engine 106) has an identifier which identifies the type of the task and this identifier may be referred to as the task type I D. [...] (the task type ID) may, in various examples, be referred to as the Data Master ID and identify both the type of the task and the source of the task”; [0029] – “A task 110 that is received by the scheduler 102 (and hence by the task scheduling engine 106) may have another identifier in addition to the task type ID. The second identifier, where provided, identifies the data group to which the task applies and may be referred to as the data group ID. In various examples, all tasks 110 received by the scheduler 102 (and hence by the task scheduling engine 106) may have both a task type ID and a data group ID”)
wherein a class ID identifies a class of the task ([0032] – “The data 120 associated with each task 110 in the queue 108 may take any form and in various examples it may comprise a plurality of state bits, as shown in FIG. 1. These state bits comprise one or more state bits 122 that track task specific dependencies [...] and these state bits 122 are updated by the task scheduling engine 106 when one of the dependencies complete”)
Simon fails to expressly teach and also for any parent task of the task,
from a hierarchy of task classes
and a resource ID of the task identifies resources allocated and/or written to by the task;
and outputting the class IDs and resource IDs for both the task itself and any parent task of the task for storage associated with the task in a task queue.
However, Rastogi further teaches and also for any parent task of the task ([38] – “Task data may specify any number of prerequisites (e.g., a parent task) or no prerequisites, if none are needed”; [42] – “for each new task added to the dependency model all of the prerequisites for the task are known”),
from a hierarchy of task classes ([19] – “Some of the tasks 130, 150, and 160 may be significant tasks (e.g., primary tasks, critical tasks, or mandatory tasks) […] the other tasks 110, 120, and 140 may be tasks of lesser importance (e.g., secondary tasks, preparatory tasks, or optional tasks)”)
and a resource ID of the task identifies resources allocated and/or written to by the task ([29] – “assign a task to a data processing resource. For example, the data processing resource may be identified by an enumerated value. The developer may assign the task to the enumerated value, and all tasks assigned to the enumerated value will share the same data processing resource and its resource constraints, if any”; [36] – “task data (e.g., task dependency data) specifies a task identifier (e.g., Task ID) that uniquely identifies the task within DGTaskExecutor. For example, the task identifier may be an enumerated value. Task data may also specify a data processing resource to be utilized by the task, as well as one or more constraints on the data processing resource”; [37] – “Task data (e.g., task configuration data) may specify an ability to constrain a number of concurrently executing tasks that may utilize a particular data processing resource. The task data may specify usage of the data processing resource [...] The task data may specify a constraint upon the usage of the data processing resource. [...] The task data may specify information (e.g., metadata) pertinent to the data processing resource”);
and outputting the class IDs and resource IDs for both the task itself and any parent task of the task for storage associated with the task in a task queue ([15] – “The task dependency data may be accessed from a cache (e.g., to avoid runtime costs)”; [37] – “The task data may specify information (e.g., metadata) pertinent to the data processing resource”; [78] – “accessing 620 task dependency data of the second task (e.g., from a cache)”; [81] – “accessing 620 may be performed by the dependency module 520”; [42] – “for each new task added to the dependency model all of the prerequisites for the task are known”).
Simon and Rastogi are considered to be analogous art to the claimed invention because they are in the same field as the claimed invention of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the methods of Simon to incorporate the task data such that the task data specifies the resource requirements of the task and is stored associated with the task as taught by Rastogi. Incorporating the methods of Rastogi may reduce the likelihood of overburdening the data processing resource and avoid deadlocks (see Rastogi: [37] and [41]).
Regarding claim 7, the combination of Simon in view of Rastogi teaches The method according to claim 6,
Rastogi further teaches wherein determining a resource ID for a task comprises assigning a resource ID to the task ([29] – “assign a task to a data processing resource. For example, the data processing resource may be identified by an enumerated value […] assign the task to the enumerated value”; [36] – “task data (e.g., task dependency data) specifies a task identifier (e.g., Task ID) that uniquely identifies the task within DGTaskExecutor. For example, the task identifier may be an enumerated value. Task data may also specify a data processing resource to be utilized by the task, as well as one or more constraints on the data processing resource”).
Simon and Rastogi are considered to be analogous art to the claimed invention because they are in the same field as the claimed invention of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the methods of Simon to incorporate the resource task data such that the task data specifies the resource requirements of the task as taught by Rastogi. Incorporating the methods of Rastogi may reduce the likelihood of overburdening the data processing resource and avoid deadlocks (see Rastogi: [37] and [41]).
Regarding claim 8, the combination of Simon in view of Rastogi teaches The method according to claim 7, wherein assigning a resource ID to the task comprises:
Rastogi further teaches allocating resources to the task ([62] – “A resource queue class (e.g., Resource Queue 330) may manage a number of data processing resources available with respect to a given data processing resource”;
[63] – “a resource manager class (e.g., Resource Manager 320) may manage one or more processing resources, one or more resource queries (e.g., queries regarding capacity, constraints, or status of a data processing resource)”; [51] – “once all prerequisites have completed, this state may be used to indicate that the task is to wait for resources to become available so that the task can execute” );
and assigning a resource ID for the allocated resources to the task ([29] – “assign a task to a data processing resource. For example, the data processing resource may be identified by an enumerated value […] assign the task to the enumerated value”; [36] – “task data (e.g., task dependency data) specifies a task identifier (e.g., Task ID) that uniquely identifies the task within DGTaskExecutor. For example, the task identifier may be an enumerated value. Task data may also specify a data processing resource to be utilized by the task, as well as one or more constraints on the data processing resource”).
Simon and Rastogi are considered to be analogous art to the claimed invention because they are in the same field as the claimed invention of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the methods of Simon to incorporate the resource task data such that the task data specifies the resource requirements of the task and the resources to allocate as taught by Rastogi. Incorporating the methods of Rastogi may reduce the likelihood of overburdening the data processing resource and avoid deadlocks (see Rastogi: [37] and [41]).
Regarding claim 9, the combination of Simon in view of Rastogi teaches The method according to claim 6,
Rastogi further teaches wherein the resources comprise shared registers, coefficient registers or local memory registers ([89] – “the data processing resource is at least one of a hardware resource, a software resource, a network resource, or a service resource”; [90] – “the data processing resource is at least one of a database connection or the processor of the machine”).
Simon and Rastogi are considered to be analogous art to the claimed invention because they are in the same field as the claimed invention of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the methods of Simon to incorporate the data processing resources such that the resources comprise registers as taught by Rastogi. Incorporating the methods of Rastogi may reduce the likelihood of overburdening the data processing resource and avoid deadlocks (see Rastogi: [37] and [41]).
Regarding claim 10, Simon teaches hardware logic arranged to determine a class ID and a resource ID for a task ([0028] – “Each task 110 that is received by the scheduler 102 (and hence by the task scheduling engine 106) has an identifier which identifies the type of the task and this identifier may be referred to as the task type I D. [...] (the task type ID) may, in various examples, be referred to as the Data Master ID and identify both the type of the task and the source of the task”; [0029] – “A task 110 that is received by the scheduler 102 (and hence by the task scheduling engine 106) may have another identifier in addition to the task type ID. The second identifier, where provided, identifies the data group to which the task applies and may be referred to as the data group ID. In various examples, all tasks 110 received by the scheduler 102 (and hence by the task scheduling engine 106) may have both a task type ID and a data group ID”)
wherein a class ID identifies a class of the task ([0032] – “The data 120 associated with each task 110 in the queue 108 may take any form and in various examples it may comprise a plurality of state bits, as shown in FIG. 1. These state bits comprise one or more state bits 122 that track task specific dependencies [...] and these state bits 122 are updated by the task scheduling engine 106 when one of the dependencies complete”)
Simon fails to expressly teach A resource management unit of a graphics processing unit (GPU), comprising:
and also for any parent task of the task,
from a hierarchy of task classes
and a resource ID of the task identifies resources allocated and/or written to by the task;
and an output, arranged to output the class IDs and resource IDs for both the task itself and any parent task of the task for storage associated with the task in a task queue.
However, Rastogi teaches A resource management unit of a graphics processing unit (GPU) ([59] – “resource manager 320”; [110] – “processor 1202 (e.g., […] a graphics processing unit (GPU) [..])”), comprising:
and also for any parent task of the task ([38] – “Task data may specify any number of prerequisites (e.g., a parent task) or no prerequisites, if none are needed”; [42] – “for each new task added to the dependency model all of the prerequisites for the task are known”),
from a hierarchy of task classes ([19] – “Some of the tasks 130, 150, and 160 may be significant tasks (e.g., primary tasks, critical tasks, or mandatory tasks) […] the other tasks 110, 120, and 140 may be tasks of lesser importance (e.g., secondary tasks, preparatory tasks, or optional tasks)”)
and a resource ID of the task identifies resources allocated and/or written to by the task ([29] – “assign a task to a data processing resource. For example, the data processing resource may be identified by an enumerated value. The developer may assign the task to the enumerated value, and all tasks assigned to the enumerated value will share the same data processing resource and its resource constraints, if any”; [36] – “task data (e.g., task dependency data) specifies a task identifier (e.g., Task ID) that uniquely identifies the task within DGTaskExecutor. For example, the task identifier may be an enumerated value. Task data may also specify a data processing resource to be utilized by the task, as well as one or more constraints on the data processing resource”; [37] – “Task data (e.g., task configuration data) may specify an ability to constrain a number of concurrently executing tasks that may utilize a particular data processing resource. The task data may specify usage of the data processing resource [...] The task data may specify a constraint upon the usage of the data processing resource. [...] The task data may specify information (e.g., metadata) pertinent to the data processing resource”);
and an output, arranged to output the class IDs and resource IDs for both the task itself and any parent task of the task for storage associated with the task in a task queue ([15] – “The task dependency data may be accessed from a cache (e.g., to avoid runtime costs)”; [37] – “The task data may specify information (e.g., metadata) pertinent to the data processing resource”; [78] – “accessing 620 task dependency data of the second task (e.g., from a cache)”; [81] – “accessing 620 may be performed by the dependency module 520”; [42] – “for each new task added to the dependency model all of the prerequisites for the task are known”).
Claims 11-13 recite substantially the same limitations as those recited in claims 7-9. As such, claims 11-13 are rejected as being unpatentable over Simon in view of Rastogi for the same reasons presented with respect to claims 7-9.
Regarding claim 14, Simon teaches Scheduling and processing logic of a graphics processing unit (GPU) ([0025] – “a processor 100 which may be a GPU or other highly parallel processing unit”), comprising:
analysis logic arranged to examining tasks in a task queue and parameters associated with the tasks, wherein the parameters comprise a class ID and a resource ID for both the task itself ([0026] – “The processing block 104 comprises hardware logic for executing the instructions within tasks that are scheduled for execution by the scheduler 102. The processing block 104 therefore comprises may arithmetic logic units”; [0028] – “Each task 110 that is received by the scheduler 102 (and hence by the task scheduling engine 106) has an identifier which identifies the type of the task and this identifier may be referred to as the task type I D. [...] (the task type ID) may, in various examples, be referred to as the Data Master ID and identify both the type of the task and the source of the task”; [0029] – “A task 110 that is received by the scheduler 102 (and hence by the task scheduling engine 106) may have another identifier in addition to the task type ID. The second identifier, where provided, identifies the data group to which the task applies and may be referred to as the data group ID. In various examples, all tasks 110 received by the scheduler 102 (and hence by the task scheduling engine 106) may have both a task type ID and a data group ID”)
wherein a class ID identifies a class of the task ([0032] – “The data 120 associated with each task 110 in the queue 108 may take any form and in various examples it may comprise a plurality of state bits, as shown in FIG. 1. These state bits comprise one or more state bits 122 that track task specific dependencies [...] and these state bits 122 are updated by the task scheduling engine 106 when one of the dependencies complete”)
and selection logic arranged to select a task for execution based on an order of the tasks in the queue and the parameters ([0030] – “The task scheduling engine 106 within the scheduler 102 adds tasks 110 that are received to the task queue 108 and then selectively schedules tasks from the queue 108 for execution by the processing unit 104”; [0038] – “Tasks are selected from those stored in the task queue 106 and the selection is made based on the wakeup event state data 109 and the state data 120 for each task”; [0037] – “state data may be updated (in block 304) by clearing the corresponding state bit(s), e.g. one or more bits 122, for the task(s) that relate to the completed dependency or updating a counter value [...] wakeup event state data to indicate a wakeup event for the particular task type ID (and optionally data group ID) associated with the task that relates to the completed dependency (block 306)”; [0039] – “The task scheduling engine 106 selects a task type by first identifying candidate task types (block 402) based on the wakeup event state data 109 and the contents of the task queue 108. Only those task types with a task in the task queue 108 (as added in block 204 of FIG. 2) and associated wakeup event state data 109 (e.g. an associated wakeup event state bit) set to indicate a wakeup event (as set in block 306 of FIG. 3) are candidate (or valid) task types. Having identified the candidate task types (in block 402), one of these candidate task types is selected (block 404)”)
and send the selected task for execution ([0030] – “tasks 110 remain in the task queue 108 until execution is complete”).
Simon fails to expressly teach and any parent task of the task,
from a hierarchy of task classes
and a resource ID of the task identifies resources allocated and/or written to by the task;
However, Rastogi teaches and any parent task of the task ([38] – “Task data may specify any number of prerequisites (e.g., a parent task) or no prerequisites, if none are needed”; [42] – “for each new task added to the dependency model all of the prerequisites for the task are known”),
from a hierarchy of task classes ([19] – “Some of the tasks 130, 150, and 160 may be significant tasks (e.g., primary tasks, critical tasks, or mandatory tasks) […] the other tasks 110, 120, and 140 may be tasks of lesser importance (e.g., secondary tasks, preparatory tasks, or optional tasks)”)
and a resource ID of the task identifies resources allocated and/or written to by the task ([29] – “assign a task to a data processing resource. For example, the data processing resource may be identified by an enumerated value. The developer may assign the task to the enumerated value, and all tasks assigned to the enumerated value will share the same data processing resource and its resource constraints, if any”; [36] – “task data (e.g., task dependency data) specifies a task identifier (e.g., Task ID) that uniquely identifies the task within DGTaskExecutor. For example, the task identifier may be an enumerated value. Task data may also specify a data processing resource to be utilized by the task, as well as one or more constraints on the data processing resource”; [37] – “Task data (e.g., task configuration data) may specify an ability to constrain a number of concurrently executing tasks that may utilize a particular data processing resource. The task data may specify usage of the data processing resource [...] The task data may specify a constraint upon the usage of the data processing resource. [...] The task data may specify information (e.g., metadata) pertinent to the data processing resource”);
Simon and Rastogi are considered to be analogous art to the claimed invention because they are in the same field as the claimed invention of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the methods of Simon to incorporate the task data such that the task data specifies the resource requirements of the task as taught by Rastogi. Incorporating the methods of Rastogi may reduce the likelihood of overburdening the data processing resource and avoid deadlocks (see Rastogi: [37] and [41]).
Claims 15-18 recite substantially the same limitations as those recited in claims 2-5. As such, claims 15-18 are rejected as being unpatentable over Simon in view of Rastogi for the same reasons presented with respect to claims 2-5.
Regarding claim 19, Simon teaches A graphics processing unit (GPU) ([0025] – “a processor 100 which may be a GPU or other highly parallel processing unit”) comprising:
a task queue ([0027] – “a task queue 108”);
analysis logic arranged to examining tasks in said task queue and parameters associated with the tasks, wherein the parameters comprise a class ID and a resource ID for both the task itself ([0026] – “The processing block 104 comprises hardware logic for executing the instructions within tasks that are scheduled for execution by the scheduler 102. The processing block 104 therefore comprises may arithmetic logic units”; [0028] – “Each task 110 that is received by the scheduler 102 (and hence by the task scheduling engine 106) has an identifier which identifies the type of the task and this identifier may be referred to as the task type I D. [...] (the task type ID) may, in various examples, be referred to as the Data Master ID and identify both the type of the task and the source of the task”; [0029] – “A task 110 that is received by the scheduler 102 (and hence by the task scheduling engine 106) may have another identifier in addition to the task type ID. The second identifier, where provided, identifies the data group to which the task applies and may be referred to as the data group ID. In various examples, all tasks 110 received by the scheduler 102 (and hence by the task scheduling engine 106) may have both a task type ID and a data group ID”)
wherein a class ID identifies a class of the task ([0032] – “The data 120 associated with each task 110 in the queue 108 may take any form and in various examples it may comprise a plurality of state bits, as shown in FIG. 1. These state bits comprise one or more state bits 122 that track task specific dependencies [...] and these state bits 122 are updated by the task scheduling engine 106 when one of the dependencies complete”)
and selection logic arranged to select a task for execution based on an order of the tasks in the queue and the parameters ([0030] – “The task scheduling engine 106 within the scheduler 102 adds tasks 110 that are received to the task queue 108 and then selectively schedules tasks from the queue 108 for execution by the processing unit 104”; [0038] – “Tasks are selected from those stored in the task queue 106 and the selection is made based on the wakeup event state data 109 and the state data 120 for each task”; [0037] – “state data may be updated (in block 304) by clearing the corresponding state bit(s), e.g. one or more bits 122, for the task(s) that relate to the completed dependency or updating a counter value [...] wakeup event state data to indicate a wakeup event for the particular task type ID (and optionally data group ID) associated with the task that relates to the completed dependency (block 306)”; [0039] – “The task scheduling engine 106 selects a task type by first identifying candidate task types (block 402) based on the wakeup event state data 109 and the contents of the task queue 108. Only those task types with a task in the task queue 108 (as added in block 204 of FIG. 2) and associated wakeup event state data 109 (e.g. an associated wakeup event state bit) set to indicate a wakeup event (as set in block 306 of FIG. 3) are candidate (or valid) task types. Having identified the candidate task types (in block 402), one of these candidate task types is selected (block 404)”)
and send the selected task for execution ([0030] – “tasks 110 remain in the task queue 108 until execution is complete”).
Simon fails to expressly teach the resource management unit as set forth in claim 10;
a plurality of resources;
and any parent task of the task,
from a hierarchy of task classes
and a resource ID of the task identifies resources of said plurality of resources allocated and/or written to by the task;
However, Rastogi teaches the resource management unit as set forth in claim 10 ([59] – “resource manager 320”);
a plurality of resources ([29] – “one or more data processing resources may be used at a time”);
and any parent task of the task ([38] – “Task data may specify any number of prerequisites (e.g., a parent task) or no prerequisites, if none are needed”; [42] – “for each new task added to the dependency model all of the prerequisites for the task are known”),
from a hierarchy of task classes ([19] – “Some of the tasks 130, 150, and 160 may be significant tasks (e.g., primary tasks, critical tasks, or mandatory tasks) […] the other tasks 110, 120, and 140 may be tasks of lesser importance (e.g., secondary tasks, preparatory tasks, or optional tasks)”)
and a resource ID of the task identifies resources of said plurality of resources allocated and/or written to by the task ([29] – “assign a task to a data processing resource. For example, the data processing resource may be identified by an enumerated value. The developer may assign the task to the enumerated value, and all tasks assigned to the enumerated value will share the same data processing resource and its resource constraints, if any”; [36] – “task data (e.g., task dependency data) specifies a task identifier (e.g., Task ID) that uniquely identifies the task within DGTaskExecutor. For example, the task identifier may be an enumerated value. Task data may also specify a data processing resource to be utilized by the task, as well as one or more constraints on the data processing resource”; [37] – “Task data (e.g., task configuration data) may specify an ability to constrain a number of concurrently executing tasks that may utilize a particular data processing resource. The task data may specify usage of the data processing resource [...] The task data may specify a constraint upon the usage of the data processing resource. [...] The task data may specify information (e.g., metadata) pertinent to the data processing resource”);
Simon and Rastogi are considered to be analogous art to the claimed invention because they are in the same field as the claimed invention of task scheduling. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the methods of Simon to incorporate the task data such that the task data specifies the resource requirements of the task as taught by Rastogi. Incorporating the methods of Rastogi may reduce the likelihood of overburdening the data processing resource and avoid deadlocks (see Rastogi: [37] and [41]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jay et al. (US 2004/0250000 A1) teaches a method for tracking network work requests after they are sent to hardware for execution by creating a tracking list for each work queue (see Abstract, [0005]-[0007], [0014])
Abdolrashidi et al. (WIREFRAME: Supporting Data-dependent Parallelism through Dependency Graph Execution in GPUs; Proceedings of MICRO-50, October 2017, pages 600-611) teaches scheduling tasks on a GPU at a thread block (TB) level considering intra-TB dependencies and GPU barriers (see Abstract)
Martin (US 8935705 B2) teaches a method for representing a task as a dependency data structure whose nodes are executable components and whose arcs show dependency relationships (see [22]-[23], [27])
WANG (CN 102902573 A) teaches a method for processing a task based on a shared resource using preset conditions (see Abstract, [0041], [0044], [0046])
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Julianne C. LaPointe whose telephone number is (571) 270-5457. The examiner can normally be reached M - T: 7:30am - 5pm ET.
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, Kevin Young can be reached at (571) 270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JULIANNE CATHERINE LAPOINTE/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights