DETAILED ACTION
Claims 1-20 are presented for examination.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 4-10 and 12-16 are rejected under 35 U.S.C. 103 as being unpatentable over Kishore et al. (US 2015/0160974 A1) in view of Bachmutsky et al. (US 2019/0317802 A1).
As to claim 1, Kishore teaches a method comprising:
generating, by a host system, a work descriptor identifying a plurality of workflow tasks
to be performed by a hardware device (“Job creation user interface 304 can provide a graphical user interface, command-line user interface, or other user interface via which an analyst (i.e., a user authorized to access analytics system 300) can define jobs to be executed using system 300”; paragraph [0048] and “Analytics system 300 can be used to manage and execute any number of jobs or workflows (a workflow can include multiple jobs with dependencies, and multiple independent or interlinked workflows can be concurrently defined). An analyst can interact with job creation user interface 304 to define one or more jobs to be executed.”; paragraph [0055]);
adding a plurality of timestamp logging tasks to the work descriptor, wherein each of the
plurality of timestamp logging tasks corresponds to one of the plurality of workflow tasks and
instructs the hardware device to log a timestamp in response to an event associated with a
respective workflow task (“Defining a job can include identifying a data table (or other data object) that the job produces and identifying one or more data tables (or other data objects) that are used as inputs to the job. In some embodiments, defining a job can also include providing other information, such as a due date/time by which the job should be completed, a start date/time at which execution of the job should begin, and/or an estimated execution time indicating how long the job is expected to take to execute”.; paragraph [0055] and “Monitoring interface 306 can receive information from workflow manager 302 regarding the execution and/or completion of jobs. In some embodiments, monitoring interface 306 can present a graphical user interface (e.g., via operator console 214 of FIG. 2) to allow analysts, system administrators, or other operators of system 300 to review the performance of the system. Monitoring interface 306 can also provide notification or alerting services, e.g., by emailing or texting designated operators if certain events occur (e.g., various error conditions or system crashes). In some embodiments, monitoring interface 306 can also perform invalidation of data generated by various jobs.”; paragraph [0053]); and
executing the tasks by the hardware device (“Task runner 312 can coordinate execution of the jobs by distributed computing systems 314. For example, when workflow manager 302 determines that a job is ready for execution, workflow manager 302 can dispatch the job, e.g., by delivering a descriptor for the job to task runner 312. Task runner 312 can identify specific computing resources within distributed computing systems 314 that are available for use and that have the requisite capabilities to execute the job, and can instruct those resources to execute the job. Once jobs are completed, task runner 312 can report the completion status to workflow manager 302.”; paragraph [0050]).
Kishore does not teach storing the work descriptor with the plurality of timestamp logging tasks in a work queue of the host system, wherein the work queue is accessible by the hardware device.
However, Bachmutsky teaches storing the work descriptor with the plurality of tasks in a work queue of the host system, wherein the work queue is accessible by the hardware device (“Ingress queues 302 are used for buffering received work requests instructions or workloads for execution by an application or accelerator specified by a work request or CWD. Egress queues 308 can be used to buffer instructions or workloads and scheduling execution by a selected application or accelerator specified by a work request or CWD. In some examples, an application or accelerator can have dedicated ingress and egress queues. An application or accelerator can pull work from output queues 158 instead of being interrupted”; paragraph [0052]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Bachmutsky to the system of Kishore because Bachmutsky teaches the hardware device can pull work from the queue directly instead of being interrupted which might improve performance of the system, especially latency sensitive applications.
As to claim 2, Kishore as modified by Bachmutsky teaches the method of claim 1, further comprising associating each timestamp logging task with a respective workflow task based on user input (see Kishore: a list of all user identifiers that were used to interact with an online service during a specific time period (e.g., one day, one week, one month) can be generated as an interval data object. A particular user identifier will appear in the list for intervals during which the user interacted with the service.; paragraph [0065]).
As to claim 4, Kishore as modified by Bachmutsky teaches the method of claim 1, further comprising: notifying the hardware device about the work descriptor in the work queue (see Bachmutsky: Ingress queues 302 are used for buffering received work requests instructions or workloads for execution by an application or accelerator specified by a work request or CWD. Egress queues 308 can be used to buffer instructions or workloads and scheduling execution by a selected application or accelerator specified by a work request or CWD. In some examples, an application or accelerator can have dedicated ingress and egress queues. An application or accelerator can pull work from output queues 158 instead of being interrupted; paragraph [0052]).
As to claim 5, Kishore as modified by Bachmutsky teaches the method of claim 4, wherein the hardware device is to access the work descriptor in the work queue upon receiving a notification (see Bachmutsky: An application or accelerator can pull work from output queues 158 instead of being interrupted; paragraph [0052]).
As to claim 6, Kishore as modified by Bachmutsky teaches the method of claim 1, wherein the hardware device is one of: a network interface controller, a graphics processing unit, a data processing unit, or a central processing unit (see Kishore: A processing job can be defined as desired and can include any number, type, and combination of data-processing operations; paragraph [0032] and Processing unit(s) 204 can include a single processor, which can have one or more cores, or multiple processors. In some embodiments, processing unit(s) 204 can include a general-purpose primary processor as well as one or more special-purpose co-processors such as graphics processors, digital signal processors, or the like; paragraphs [0033]-[0035]).
As to claim 7, Kishore as modified by Bachmutsky teaches the method of claim 1, further comprising: receiving, by the host system, a first log comprising a first plurality of timestamps logged by the hardware device according to the plurality of timestamp logging tasks for events associated with workflow tasks (see Kishore: This information can be obtained from activity logs 506 maintained by the online service provider, e.g., using logging system 316 of FIG. 3. Logs 506 can include an entry for each transaction of a user with the online service (or for selected transactions), and each entry can indicate the date/time, the type of transaction (e.g., logging in or out, uploading or downloading a file, purchasing an item, posting content, etc.), the user identifier, and other information as desired.; paragraph [0070]).
As to claim 8, Kishore as modified by Bachmutsky teaches the method of claim 7, wherein the timestamps logged by the hardware device according to the plurality of timestamp logging tasks for events associated with workflow tasks are grouped based on the work descriptor (see Kishore: "import activity logs" job 512 can read an activity log 506 that covers a relevant time interval (in this case, a one-hour period) and generate a database table 514 that can include a deduplicated list of all user identifiers that had at least one transaction entry in activity log 506. In some embodiments, the table can include other information, such as how many or what kind(s) of transactions were logged for each user identifier. Like job 508, job 512 can be a job that is scheduled to run periodically (e.g., once per hour). Unlike job 508, job 512 can be an interval job that generates a separate data table 514 for each hour's activity log 506. Accordingly, job 512 can generate hourly activity data tables 514 at a rate of 24 tables per day, and tables 514 can be retained for as long as desired (e.g., 30 days, 90 days, one year). In some embodiments, hourly activity data tables 512 can be consumed by a number of different jobs including later jobs within workflow 500 as well as other jobs (not shown) outside workflow 500. For instance, hourly activity data tables 512 can be used to generate statistical data regarding system usage over the course of a day; paragraph [0072]).
As to claim 9, Kishore as modified by Bachmutsky teaches the method of claim 7, wherein the timestamps logged by the hardware device according to the plurality of timestamp logging tasks for events associated with workflow tasks correspond to a plurality of distributed clocks on the hardware device, each distributed clock of the plurality of distributed clocks being spatially proximal to hardware associated with an event of the events associated with workflow tasks (see Kishore: “Job execution with dependency-based scheduling can be implemented in a variety of standalone computer systems and/or distributed-computing architectures”; paragraph [0033] and “Task runner 312 can coordinate execution of the jobs by distributed computing systems 314. For example, when workflow manager 302 determines that a job is ready for execution, workflow manager 302 can dispatch the job, e.g., by delivering a descriptor for the job to task runner 312. Task runner 312 can identify specific computing resources within distributed computing systems 314 that are available for use and that have the requisite capabilities to execute the job, and can instruct those resources to execute the job. Once jobs are completed, task runner 312 can report the completion status to workflow manager 302”; paragraph [0050]).
As to claim 10, Kishore as modified by Bachmutsky teaches the method of claim 7, further comprising: receiving, by the host system, a second log comprising a second plurality of timestamps logged by the hardware device according to the plurality of timestamp logging tasks for events associated with workflow tasks (see Kishore: "daily active list" job 516, "7-day active list" job 520, and "28-day active list" job 524 can each operate by merging and deduplicating multiple tables (or lists) of active users; these jobs differ in the number of input tables and duration of time covered by each table. Accordingly, a job can be defined with runtime-settable parameters to specify the number of input tables and duration to be covered by each input table, and workflow manager 302 can choose appropriate parameters when creating an instance of the job.; paragraph [0098]).
As to claim 12, Kishore as modified by Bachmutsky teaches the method of claim 1, wherein the event associated with the respective workflow task is one of: a breakpoint event, an initiation event of a stage of the respective workflow task, a completion event of the stage of the respective workflow task, or a completion event of the respective workflow task (see Kishore: Once jobs are completed, task runner 312 can report the completion status to workflow manager 302; paragraph [0050]).
As to claim 13, Kishore teaches a system (server system 200; Fig. 2 and paragraph [0034]) comprising:
one or more processing units to (processing unit(s) 204; Fig. 2 and paragraph [0034])
generate, by a host system, a work descriptor identifying a plurality of workflow
tasks to be performed by a hardware device (“Job creation user interface 304 can provide a graphical user interface, command-line user interface, or other user interface via which an analyst (i.e., a user authorized to access analytics system 300) can define jobs to be executed using system 300”; paragraph [0048] and “Analytics system 300 can be used to manage and execute any number of jobs or workflows (a workflow can include multiple jobs with dependencies, and multiple independent or interlinked workflows can be concurrently defined). An analyst can interact with job creation user interface 304 to define one or more jobs to be executed.”; paragraph [0055]);
add a plurality of timestamp logging tasks to the work descriptor, wherein each of
the plurality of timestamp logging tasks corresponds to one of the plurality of workflow
tasks and instructs the hardware device to log a timestamp in response to an event
associated with a respective workflow task (“Defining a job can include identifying a data table (or other data object) that the job produces and identifying one or more data tables (or other data objects) that are used as inputs to the job. In some embodiments, defining a job can also include providing other information, such as a due date/time by which the job should be completed, a start date/time at which execution of the job should begin, and/or an estimated execution time indicating how long the job is expected to take to execute”.; paragraph [0055] and “Monitoring interface 306 can receive information from workflow manager 302 regarding the execution and/or completion of jobs. In some embodiments, monitoring interface 306 can present a graphical user interface (e.g., via operator console 214 of FIG. 2) to allow analysts, system administrators, or other operators of system 300 to review the performance of the system. Monitoring interface 306 can also provide notification or alerting services, e.g., by emailing or texting designated operators if certain events occur (e.g., various error conditions or system crashes). In some embodiments, monitoring interface 306 can also perform invalidation of data generated by various jobs.”; paragraph [0053]); and
executing the tasks by the hardware device (“Task runner 312 can coordinate execution of the jobs by distributed computing systems 314. For example, when workflow manager 302 determines that a job is ready for execution, workflow manager 302 can dispatch the job, e.g., by delivering a descriptor for the job to task runner 312. Task runner 312 can identify specific computing resources within distributed computing systems 314 that are available for use and that have the requisite capabilities to execute the job, and can instruct those resources to execute the job. Once jobs are completed, task runner 312 can report the completion status to workflow manager 302.”; paragraph [0050]).
Kishore does not teach store the work descriptor with the plurality of timestamp logging tasks in a work queue of the host system accessible by the hardware device.
However, Bachmutsky teaches storing the work descriptor with the plurality of tasks in a work queue of the host system, wherein the work queue is accessible by the hardware device (“Ingress queues 302 are used for buffering received work requests instructions or workloads for execution by an application or accelerator specified by a work request or CWD. Egress queues 308 can be used to buffer instructions or workloads and scheduling execution by a selected application or accelerator specified by a work request or CWD. In some examples, an application or accelerator can have dedicated ingress and egress queues. An application or accelerator can pull work from output queues 158 instead of being interrupted”; paragraph [0052]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Bachmutsky to the system of Kishore because Bachmutsky teaches the hardware device can pull work from the queue directly instead of being interrupted which might improve performance of the system, especially latency sensitive applications.
As to claim 14, see rejection of claim 2 above.
As to claim 15, see rejection of claim 4 above.
As to claim 16, see rejection of claim 7 above.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Kishore et al. (US 2015/0160974 A1) in view of Bachmutsky et al. (US 2019/0317802 A1) further in view of Gupta et al. (US 2023/0267396 A1).
As to claim 3, Kishore as modified by Bachmutsky does not teach the method of claim 2, wherein each of the plurality of timestamp logging tasks further instructs the hardware device to log, in response to the event associated with the respective workflow task, a unique identifier associated with the respective workflow task to a log.
However, Gupta teaches to log, in response to the event associated with the respective workflow task, a unique identifier associated with the respective workflow task to a log (The event log 304 can be the output of step 204 of the process in FIG. 2, for example. The ad hoc task data 302, in this example, includes a process identifier (“1234”), a description (“Upgrade database version to 2.8 in DC1”), a category (“C1”), a sub-category (“SC1”), a location (“L1”) and a list of ad hoc tasks with corresponding identifies (TID1-TID6). The event log 304 includes activity names corresponding to the ad hoc tasks that are linked to a case ID. The event log 304 may include additional fields in some embodiments, such as start and complete timestamps for each of the activities and contextual factors (meta-attributes) corresponding to the location, category, and/or subcategory, for example.; paragraph [0024]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Gupta to the system of Kishore as modified by Bachmutsky because Kishore teaches a workflow includes multiple jobs, logging jobs data, and by apply the teaching of Gupta, by logging the associated workflow ID to the job log record, the log record would clearly identified the relationship between workflow and jobs, which enabling report for the jobs and workflow more effective.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Kishore et al. (US 2015/0160974 A1) in view of Bachmutsky et al. (US 2019/0317802 A1) further in view of Kang et al. (US 2023/0209181 A1).
As to claim 11, Kishore as modified by Bachmutsky teaches the method of claim 1, further comprising: periodically using a plurality of timestamps logged by the hardware device to obtain latency related statistical information of the hardware device.
However, Kang teaches periodically using a plurality of timestamps logged by the hardware device to obtain latency related statistical information of the hardware device (The timekeeping module 120 may monitor operating times of the sensors, times taken for the operations (e.g., sensing) of the sensors, and a time taken for an operation for the target task by the processor 130 and/or the external device all. Accordingly, the timekeeping module 120 may calculate an end-to-end latency (e.g., the task latency) from a sensing time point of a sensor (e.g., a timestamp recorded for sensing) based on the monitored time information. Accordingly, the electronic device 100 of one or more embodiments implemented as a real-time system (e.g., an AR device, a simultaneous localization and mapping (SLAM) device, and various mechanical control devices) measuring or controlling a motion may minimize an error caused by an end-to-end latency occurring in an end-to-end operation.; paragraph [0067]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Kang to the system of Kishore as modified by Bachmutsky because Kang teaches a method to correct, based on the task latency, a task result processed according to localization of the electronic device determined for the sensing time point of the reference sensing data based on the determined time difference, the reference sensing data, and the other sensing data (abstract).
Claims 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kishore et al. (US 2015/0160974 A1) in view of Bachmutsky et al. (US 2019/0317802 A1) further in view of Friedman et al. (US 2019/0158429 A1).
As to claim 17, Kishore teaches a non-transitory computer-readable storage medium comprising instructions that, when executed by a processing device, cause the processing device to perform operations comprising (Computer programs incorporating various features of the present invention may be encoded and stored on various computer readable storage media; suitable media include magnetic disk or tape, optical storage media such as compact disk (CD) or DVD (digital versatile disk), flash memory, and other non-transitory media; paragraph [0132]):
generating, by a host system, a traceable work descriptor, wherein the traceable work
descriptor comprises a plurality of first tasks and a plurality of second tasks (“Job creation user interface 304 can provide a graphical user interface, command-line user interface, or other user interface via which an analyst (i.e., a user authorized to access analytics system 300) can define jobs to be executed using system 300”; paragraph [0048] and “Analytics system 300 can be used to manage and execute any number of jobs or workflows (a workflow can include multiple jobs with dependencies, and multiple independent or interlinked workflows can be concurrently defined). An analyst can interact with job creation user interface 304 to define one or more jobs to be executed.”; paragraph [0055]);
add a plurality of timestamp logging tasks to the work descriptor, wherein each of
the plurality of timestamp logging tasks corresponds to one of the plurality of workflow
tasks and instructs the hardware device to log a timestamp in response to an event
associated with a respective workflow task (“Defining a job can include identifying a data table (or other data object) that the job produces and identifying one or more data tables (or other data objects) that are used as inputs to the job. In some embodiments, defining a job can also include providing other information, such as a due date/time by which the job should be completed, a start date/time at which execution of the job should begin, and/or an estimated execution time indicating how long the job is expected to take to execute”.; paragraph [0055] and “Monitoring interface 306 can receive information from workflow manager 302 regarding the execution and/or completion of jobs. In some embodiments, monitoring interface 306 can present a graphical user interface (e.g., via operator console 214 of FIG. 2) to allow analysts, system administrators, or other operators of system 300 to review the performance of the system. Monitoring interface 306 can also provide notification or alerting services, e.g., by emailing or texting designated operators if certain events occur (e.g., various error conditions or system crashes). In some embodiments, monitoring interface 306 can also perform invalidation of data generated by various jobs.”; paragraph [0053]); and
executing the tasks by the hardware device (“Task runner 312 can coordinate execution of the jobs by distributed computing systems 314. For example, when workflow manager 302 determines that a job is ready for execution, workflow manager 302 can dispatch the job, e.g., by delivering a descriptor for the job to task runner 312. Task runner 312 can identify specific computing resources within distributed computing systems 314 that are available for use and that have the requisite capabilities to execute the job, and can instruct those resources to execute the job. Once jobs are completed, task runner 312 can report the completion status to workflow manager 302.”; paragraph [0050]).
Kishore does not teach the hardware device is a NIC, wherein the plurality of first tasks is associated with instructing a network interface controller (NIC) to deliver a packet; providing the NIC access to the traceable work descriptor.
Kishore teaches the hardware device can be a processing unit(s) 204, which can include a single processor, which can have one or more cores, or multiple processors. In some embodiments, processing unit(s) 204 can include a general-purpose primary processor as well as one or more special-purpose co-processors such as graphics processors, digital signal processors, or the like (paragraphs [0033]-[0035]).
However, Bachmutsky teaches storing the work descriptor with the plurality of tasks in a work queue of the host system, wherein the work queue is accessible by the hardware device (“Ingress queues 302 are used for buffering received work requests instructions or workloads for execution by an application or accelerator specified by a work request or CWD. Egress queues 308 can be used to buffer instructions or workloads and scheduling execution by a selected application or accelerator specified by a work request or CWD. In some examples, an application or accelerator can have dedicated ingress and egress queues. An application or accelerator can pull work from output queues 158 instead of being interrupted”; paragraph [0052]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Bachmutsky to the system of Kishore because Bachmutsky teaches the hardware device can pull work from the queue directly instead of being interrupted which might improve performance of the system, especially latency sensitive applications.
Friedman teaches the hardware device is a NIC, wherein the plurality of first tasks is associated with instructing a network interface controller (NIC) to deliver a packet (According to some examples, NIC 150 includes circuitry 154 to support a transmit (Tx) scheduler 155 or a quanta descriptor (QD) logic 157 to facilitate scheduling of data to be transmitted from computing platform 105 through link(s) 160 via one or more packets. For these examples, descriptor data that describes respective blocks of data to be scheduled for transmission may be stored in a first queue included in system memory 120 (not shown in FIG. 1). Also, information associated with a grouping of descriptor data that separately describe individual blocks of data may be stored in a second queue in system memory 120 (not shown in FIG. 1). The information associated with the grouping of descriptor data may be referred to as a “quanta descriptor” or a “QD”. As described in more detail below, individual QDs may be pulled from system memory 120 and temporarily stored at a memory 152 at NIC 150. For example, the individual QDs may be temporarily stored in a QD cache included in memory 152 (not shown in FIG. 1) and used for scheduling blocks of data for transmission via one or more packets transmitted through link(s) 160; paragraph [0017]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Friedman to the system of Kishore as modified by Bachmutsky, given the teaching Kishore above regarding the hardware device can be any type of processor, because Friedman teaches processing data could be transmitting a large amount of data using NIC, which overcome the current used in traditional method (paragraph [0015]).
As to claim 18, see rejection of claim 2 above.
As to claim 19, Kishore as modified by Bachmutsky and Friedman teaches the non-transitory computer-readable storage medium of claim 17, wherein providing the NIC access to the traceable work descriptor includes storing the traceable work descriptor in a work queue of the host system accessible by the NIC (see Bachmutsky: “Ingress queues 302 are used for buffering received work requests instructions or workloads for execution by an application or accelerator specified by a work request or CWD. Egress queues 308 can be used to buffer instructions or workloads and scheduling execution by a selected application or accelerator specified by a work request or CWD. In some examples, an application or accelerator can have dedicated ingress and egress queues. An application or accelerator can pull work from output queues 158 instead of being interrupted”; paragraph [0052]) and (see Friedman: multiple slots of descriptor queues 212-1 to 212-n may be associated with single memory address slots on respective QD queues 214-1 to 214-n; paragraph [0026]).
As to claim 20, Kishore as modified by Bachmutsky and Friedman teaches the non-transitory computer-readable storage medium of claim 17, wherein the plurality of first tasks associated with instructing the NIC to deliver the packet includes at least one of:
reading, by the NIC, the traceable work descriptor (see Friedman: logic flow 900 at block 904 may obtain the first descriptor from the first queue based on the received information. For these examples, QD logic 157 may obtain the first descriptor; paragraph [0078]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Paranthaman et al. (US 2022/0365812 A1) teaches a method of modernizing a legacy batch based on at least one functional context. The method includes at least one of: preprocessing, a plurality of metadata associated with a plurality of batches to obtain a plurality of derived data; generating, the functional context based on the plurality of derived data; determining, an average elapsed time for at least one application from the at least one functional context; parsing, log of the at least one consistent long running job to identify step and associated file referenced in the at least one long running job; determining, a hotspot based on at least program; and recommending, at least one batch design associated with at least one batch job in a future state.
Kakaiya et al. (US 2023/0289229 A1) teaches methods and apparatus relating to confidential computing extensions for highly scalable accelerators are described. One or more embodiments provide extensions for scalable accelerator(s) to be able to directly assign accelerator work-queue(s) to Trusted Execution Environment (TEE) Virtual Machines (TVMs).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DIEM K CAO whose telephone number is (571)272-3760. The examiner can normally be reached Monday-Friday 8:00am-4: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, April Blair can be reached at 571-270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/DIEM K CAO/Primary Examiner, Art Unit 2196
DC
March 30, 2026
Prosecution Insights