DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-6, 8-11, and 13-19 are pending. Claims 7, 12, and 20 are cancelled.
Response to Arguments
Regarding: Prior Art Rejections:
Applicant’s amendments and arguments regarding the rejection of claims 1-6, 8-11, and 13-19 under 35 U.S.C 103 have been fully considered and are moot due to new grounds of rejection necessitated by amendment.
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, 2, 8, 9, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. US 20220129306 A1 in view of Kapoor et al. US 12210898 B1 in view of Baracaldo et al. US 20170090975 A1.
Wang and Kapoor are cited in a previous office action.
Regarding claim 1, Wang teaches the invention substantially as claimed including:
A method for device constellation, the method comprising:
receiving a first request, the first request including a plurality of first request parameters ([0079] attributes of the task flow; [0095] the definer module 5231 receives a request for executing a task flow … the definer module 5231 retrieves metadata information for the task flow);
receiving a second request from a second request queue for data processing ([0061] It can also be understood that in actual production or service practice, multiple task flows can be run in parallel. For each task flow, a plurality of devices may be involved. Supposing there are two similar task flows to be executed in the edge devices in parallel, one of the task flows may comprise a series of subtasks which are to be run on devices B, C, and A. The devices B, C, and A may respectively receive the assigned subtask from the edge agent 423 and turn back the running result to the edge agent 423 respectively as shown by lines 431, 432 and 433. The other task flow may comprise a series of subtasks which are to be run on devices D, E, and A. Similarly, devices D, E, and A may communicate with the edge agent 423 to execute the task flow as shown by dotted lines 434, 435 and 436), the second request including a plurality of second request parameters ([0079] attributes of the task flow; [0095] the definer module 5231 receives a request for executing a task flow … the definer module 5231 retrieves metadata information for the task flow), and the plurality of second request parameters being different from the plurality of first request parameters ([0061] multiple task flows can be run in parallel; Examiner notes: each task flow is to have their own unique metadata and attributes);
decomposing the first request into one or more first tasks ([0060] A process of production or service may be a process of executing the task flow, including a series of subtasks executed on the edge devices; [0061] one of the task flows may comprise a series of subtasks which are to be run on devices B, C, and A. The devices B, C, and A may respectively receive the assigned subtask from the edge agent 423 and turn back the running result to the edge agent 423 respectively as shown by lines 431, 432 and 433);
decomposing the second request into one or more second tasks, the one or more second tasks being different from the one or more first tasks ([0061] The other task flow may comprise a series of subtasks which are to be run on devices D, E, and A. Similarly, devices D, E, and A may communicate with the edge agent 423 to execute the task flow as shown by dotted lines 434, 435 and 436);
selecting one or more edge devices based at least in part on the plurality of first request parameters and the plurality of second request parameters ([0096] the definer module may determine a cluster of edge devices to execute the task flow from a set of edge devices, which comprises: the definer module retrieving attributes of the task flow and a set of edge devices respectively; selecting a group of edge devices from the set of edge devices as a cluster of edge devices to execute the task flow based on a mapping relationship of the attributes between the task flow and the set of edge devices);
assigning, to the one or more selected edge devices, the one or more first tasks and the one or more second tasks to cause the one or more selected edge devices to perform the one or more first tasks and the one or more second tasks ([0061] one of the task flows may comprise a series of subtasks which are to be run on devices B, C, and A … The other task flow may comprise a series of subtasks which are to be run on devices D, E, and A) by:
identifying one or more first models that run on a first edge device of the one or more selected edge devices ([0060] It can be understood that industrial/intelligent production or service functions can be carried out or realized in the edge computing environment. The edge devices may be requested to perform various tasks to fulfil a workload, either to accomplish production missions or to implement service functions; [0081] edge devices have their own attributes or characteristics and may be adapted to execute various tasks. The attributes of the edge devices may be properties, type, power, parameter, index, configuration and the like. For purpose of simplicity, the attributes of the devices may also be marked as tags. The definer module 5231 may determine the cluster of edge devices for execution of the task flow based on a mapping relationship of the tags between the task flow and the edge devices);
causing the one or more selected edge devices to perform the one or more first tasks and the one or more second tasks such that at least one edge device of the one or more selected edge devices performs at least one first task associated with the first request queue and at least one second task associated with the second request queue ([0061] ([0061] one of the task flows may comprise a series of subtasks which are to be run on devices B, C, and A … The other task flow may comprise a series of subtasks which are to be run on devices D, E, and A; Examiner notes: device A processes subtasks from both workflows); and
receiving one or more task results from the one or more selected edge devices (([0098] in response to one or more last subtasks being completed by one or more last edge devices, the one or more last edge devices sending one or more final running results to a receiver module);
wherein the method is performed using one or more processors ([0104] a processor to carry out aspects of the present disclosure).
Wang does not explicitly teach identifying one or more first models that run on a first edge device of the one or more selected edge devices; determining a second model based on the plurality of first request parameters and the plurality of second request parameters, the second model being different from any one of the one or more first models; deploying the second model to the first edge device;
However, Kapoor teaches identifying one or more first models that run on a first edge device of the one or more selected edge devices (the existing model (e.g., the version prior to the update) is currently deployed (also referred to herein as the current shard, Col 4 38-40; Examiner notes: Wang teaches the edge devices of the claimed invention. Kapoor teaches the concept of identifying existing models deployed on shards. The combination of Wang and Kapoor results in edge devices hosting models of which the system is able to identify for execution/model updating purposes);
determining a second model based on the plurality of first request parameters and the plurality of second request parameters, the second model being different from any one of the one or more first models ((at 410, a determination is made that a model is to be added to a shard. According to various embodiments, the system determines that the model is to be added to the shard in response to determining that the model is created or updated (e.g., that the model is an updated model of a model currently deployed, Col 18 4-9; Examiner notes: subtasks from different workflows require the usage of the same resource capabilities seen in the sharing of device A in Wang); deploying the second model to the first edge device (the new or updated model may be allocated (e.g., allocated based on a setting in a configuration mapping of models to shards, and/or copied/downloaded) to the selected shard on which the new or updated model is to be deployed, Col 2 67 – Col 3 4);
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Kapoor’s model management system with the system of Wang to provide the edge devices of Wang with new or updated machine learning models in order to execute assigned tasks. A person of ordinary skill in the art would have been motivated to make this combination to provide Wang’s system with the advantage of model scalability in big data processing systems (see Kapoor Col 1 13-21 At scale, the number of accesses or queries performed against the one or more datasets is very large, the number of organizations for which one or more datasets is stored is very large, and the models used in connection with analyzing the data become resource intensive as the models become more sophisticated as additional features are introduced. This creates a problem for maintaining models in memory for analyzing the applicable one or more datasets).
Wang and Kapoor do not explicitly teach the request from a first request queue for data collection, a second request from a second request queue for data processing, and the second request queue being different from the first request queue.
However, Baracaldo teaches the request from a first request queue for data collection ([0007] admitting, by the processor, the first job request from the first queue to a data analytics system and/or a data storage system to be processed), a second request from a second request queue for data processing ([0007] other received job requests stored in other queues), and the second request queue being different from the first request queue (Fig 4; [0006] The system also includes a plurality of queues, each queue being configured to store job requests having different estimated complexities and user skill levels with respect to job requests stored in other queues).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Baracaldo’s multiple job queue system with the existing system. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of organizing job requests for system resources based on varying levels of demand (see Baracaldo [0078] The service class may be based on a current service plan to which the user and/or organization is currently enrolled (some users may pay money on a recurring or one-off basis to have their job request(s) receive higher dispatch priority than other job requests of the same type). The service class may further be based on expected resource consumption of the job request (as the expected resource consumption is increased, the service class will be correspondingly decreased), and/or a job classification policy that is set by an administrator of the data analytics and/or data storage systems 414, in various embodiments).
Regarding claim 2, Wang, Kapoor, and Baracaldo teach the method of claim 1.
Wang further teaches fusing the one or more task results received from the one or more selected edge devices to generate a course of actions (Fig 6A; [0076] The running results of the two subtasks may need to be sent as the input to a third device to run the next subtask).
Regarding claim 8, Wang, Kapoor, and Baracaldo teach the method of claim 1.
Wang further teaches receiving one or more additional requests ([0061] multiple task flows can be run in parallel; Examiner notes: system receives requests to run multiple task flows either concurrently or for future processing); and
decomposing the one or more additional requests into a plurality of subrequests ([0061] one of the task flows may comprise a series of subtasks which are to be run on devices B, C, and A … The other task flow may comprise a series of subtasks which are to be run on devices D, E, and A);
Baracaldo further teaches storing the plurality of sub-requests into one of the first request queue and the second request ([0079] The plurality of queues 406a, . . . , 406l, are each configured to store job requests having different estimated complexities and user skill levels with respect to job requests stored in other queues. For example, in a three queue system, the job requests may be split into three categories, high priority, regular priority, and low priority. These classifications may be based on estimated complexity and user skill level associated with each job request stored to a respective queue, with job requests stored in the high priority queue given priority in selection for admission over job requests stored in the regular priority queue. Likewise, job requests stored in the regular priority queue are given priority in selection for admission over job requests stored in the low priority queue).
Regarding claim 9, Wang, Kapoor, and Baracaldo teach the method of claim 8.
Wang further teaches wherein at least one first task of the one or more first tasks or at least one second task of the one or more second tasks is generated based on the plurality of sub-requests ([0061] The devices B, C, and A may respectively receive the assigned subtask from the edge agent 423 and turn back the running result to the edge agent 423 respectively as shown by lines 431, 432 and 433. The other task flow may comprise a series of subtasks which are to be run on devices D, E, and A. Similarly, devices D, E, and A may communicate with the edge agent 423 to execute the task flow as shown by dotted lines 434, 435 and 436).
Regarding claim 14, it is the system of claim 1. Therefore, it is rejected for the same reasons as claim 1.
Wang further teaches one or more memories comprising instructions stored thereon; and one or more processors configured to execute the instructions and perform operations ([0104] The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure).
Regarding claim 15, it is the system of claim 2. Therefore, it is rejected for the same reasons as claim 2.
Claims 3, 4, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. US 20220129306 A1 in view of Kapoor et al. US 12210898 B1 in view of Baracaldo et al. US 20170090975 A1 in view of Levien et al. US 20130081049 A1.
Levien is cited in a previous office action.
Regarding claim 3, Wang, Kapoor, and Baracaldo teach the method of claim 1.
Wang further teaches wherein the plurality of first request parameters include one or more collection parameters ([0080] the definer module 5231 may obtain tags for each subtask of the task flow. The tags may indicate basic requirements for the attributes of the edge devices; [0081] attributes of the edge devices may be properties, type, power, parameter, index, configuration and the like).
Wang does not explicitly teach wherein the one or more collection parameters include at least one selected from a group consisting of a location parameter, a field-of-view parameter, a sensor parameter, and a timing parameter.
However, Levien teaches wherein the one or more collection parameters include at least one selected from a group consisting of a location parameter, a field-of-view parameter, a sensor parameter, and a timing parameter ([0069] task portion two-or-more discrete interface subtask acquiring module 52 acquiring one or more subtasks (e.g., "take a picture of the Eiffel Tower from your location") that correspond to portions of a task (e.g. "take a 360-degree picture of the Eiffel Tower at night") requested by a task requestor (e.g., a person using a smartphone in Centerville, Ohio, requests a 360-degree picture of the Eiffel Tower for a grade school science project), wherein the task of acquiring data (e.g., the 360-degree image data of the location) is configured to be carried out by two or more discrete interface devices (e.g., two or more cellular phones, smartphones, network-connected cameras will provide image data to carry out the task of acquiring data; [0087] the task is "take a 360-degree picture of Times Square when the new Reebok ad pops up at 8:01:32 a.m).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Levien’s request parameters specifying request location, field of view, timing, and sensor information with the existing system. A person of ordinary skill in the art would have been motivated to make this combination to provide Wang’s system with the advantage of providing edge devices with instructions of data collection tasking (see Levien [0009] the task of acquiring data is configured to be carried out by two or more discrete interface devices, transmitting at least one of the one or more subtasks to at least two of the two or more discrete interface devices).
Regarding claim 4, Wang, Kapoor, Baracaldo, and Levien teach the method of claim 3.
Wang further teaches wherein the selecting one or more edge devices comprises selecting the one or more edge devices based at least in part on at least one of the collection parameters ([0081] The definer module 5231 may determine the cluster of edge devices for execution of the task flow based on a mapping relationship of the tags between the task flow and the edge devices; Examiner notes: based upon instructions in the request specifying the task and resource requirements, the definer module selects edge devices that fit the request).
Regarding claims 16 and 17, they are the systems of claims 3 and 4 respectively. Therefore, they are rejected for the same reasons as claims 3 and 4 respectively.
Claims 5, 6, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. US 20220129306 A1 in view of Kapoor et al. US 12210898 B1 in view of Baracaldo et al. US 20170090975 A1 in view of Yadav US 20210201091 A1.
Yadav is cited in a previous office action.
Regarding claim 5, Wang, Kapoor, and Baracaldo teach the method of claim 1.
Wang, Kapoor, and Baracaldo do not explicitly teach wherein the plurality of request parameters include one or more monitoring parameters, wherein the one or more monitoring parameters include at least one selected from a group consisting of a model parameter, a fusion function parameter, and a target parameter.
However, Yadav teaches wherein the plurality of second request parameters include one or more monitoring parameters, wherein the one or more monitoring parameters include at least one selected from a group consisting of a model parameter, a fusion function parameter, and a target parameter ([0038] a task may involve determining that an environment 2 is occupied by people 4a, 4b. If the environment 2 is occupied, the luminaires 6a, 6b, 6c, 6d may be turned on or the light 10 from the luminaires 6a, 6b, 6c, 6d may be brightened. As another example, a task may involve determining whether people 4a, 4b in the environment 2 are engaging in a type of activity which requires particular light 10 characteristics 8, such as an activity which requires people 4a, 4b to focus for an extended time while working. In response to determining that the task has been performed, light 10 characteristics 8 of luminaires 6a, 6b, 6c, 6d which promote alertness may be set. The plurality of sensors 14 may comprise sensors 14a, 14b, 14c of one type or multiple types and are arranged to provide data to perform a set of preselected tasks. The plurality of sensors 14 may be selected from a passive infrared (“PIR”) sensor, a thermopile sensor, a microwave sensor, an image sensor, a sound sensor, and/or any other sensor modality).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Yadav’s process of machine learning algorithm and resource allocation for a task of targeting of some object to monitor with the existing system. A person of ordinary skill in the art would have been motivated to make this combination to provide the system with the advantage of determining the necessary sensors and algorithms to best perform a computer vision task (see Yadav [0005] the system selects a specific sensor or a combination of sensors along with a corresponding machine learning algorithm to achieve enhanced performance in performing a task).
Regarding claim 6, Wang, Kapoor, Baracaldo, and Yadav teach the method of claim 5.
Yadav further teaches wherein the selecting one or more edge devices comprises selecting the one or more edge devices based at least in part on at least one of the monitoring parameters ([0038] a task may involve determining whether people 4a, 4b in the environment 2 are engaging in a type of activity which requires particular light 10 characteristics 8, such as an activity which requires people 4a, 4b to focus for an extended time while working … The plurality of sensors 14 may be selected from a passive infrared (“PIR”) sensor, a thermopile sensor, a microwave sensor, an image sensor, a sound sensor, and/or any other sensor modality; Examiner notes: in order to detect the presence of people performing some activity, the sensors listed are selected based on the task).
Regarding claims 18 and 19, they are the systems of claims 5 and 6 respectively. Therefore, they are rejected for the same reasons as claims 5 and 6 respectively.
Claims 10, 11, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. US 20220129306 A1 in view of Yadav US 20210201091 A1 in view of Baracaldo et al. US 20170090975 A1.
Regarding claim 10, Wang teaches the invention substantially as claimed including:
A method for device constellation, the method comprising:
receiving a task assignment via a task orchestrator (Fig 5 Edge Agent receives task flows to schedule, edge devices receive task assignments from Edge Agent), the task assignment including one or more task parameters ([0079] attributes of the task flow; [0095] the definer module 5231 receives a request for executing a task flow … the definer module 5231 retrieves metadata information for the task flow; [0071] the sender module 5232 may be configured to send a request with the metadata information to one or more edge devices involved in cluster 1 to start the execution of the task), the one or more task parameters including a set of collection parameters ([0080] the definer module 5231 may obtain tags for each subtask of the task flow. The tags may indicate basic requirements for the attributes of the edge devices; [0081] attributes of the edge devices may be properties, type, power, parameter, index, configuration and the like);
conducting a first task and a second task according to the task assignment including the one or more task parameters to collect and process data ([0061] It can also be understood that in actual production or service practice, multiple task flows can be run in parallel. For each task flow, a plurality of devices may be involved. Supposing there are two similar task flows to be executed in the edge devices in parallel, one of the task flows may comprise a series of subtasks which are to be run on devices B, C, and A. The devices B, C, and A may respectively receive the assigned subtask from the edge agent 423 and turn back the running result to the edge agent 423 respectively as shown by lines 431, 432 and 433. The other task flow may comprise a series of subtasks which are to be run on devices D, E, and A. Similarly, devices D, E, and A may communicate with the edge agent 423 to execute the task flow as shown by dotted lines 434, 435 and 436; [0072] The containers in each of the edge devices may run the assigned subtask and the one or more proxy modules in each of the devices may manage the data of task flow. The one or more proxy modules in each of the edge devices may manage or route the task flow according to the metadata information; [0073] the receiver module 5233 may be configured to receive a final running result/s from a corresponding last edge device/s in the cluster, rather than receiving a running result of each subtask from each device; Examiner notes: running a subtask on the edge devices accumulates and processes data as part of calculations/measurements required to input and output results),
transmitting the task result to a computing device ([0062] each of the edge devices may receive a task request from the edge agent 423 and may output the running result to the edge agent 423);
wherein the method is performed using one or more processors ([0104] a processor to carry out aspects of the present disclosure).
Wang does not explicitly teach the one or more task parameters including a set of monitoring parameters; activating one or more models based at least in part on the monitoring parameters includes: receiving at least one model of the one or more models via the task orchestrator; and activating the at least one received model; and generating a task result associated with the first task and the second task by applying the one or more models to the collected and processed data;
However, Yadav teaches wherein the one or more task parameters including a set of monitoring parameters ([0038] a task may involve determining that an environment 2 is occupied by people 4a, 4b. If the environment 2 is occupied, the luminaires 6a, 6b, 6c, 6d may be turned on or the light 10 from the luminaires 6a, 6b, 6c, 6d may be brightened. As another example, a task may involve determining whether people 4a, 4b in the environment 2 are engaging in a type of activity which requires particular light 10 characteristics 8, such as an activity which requires people 4a, 4b to focus for an extended time while working. In response to determining that the task has been performed, light 10 characteristics 8 of luminaires 6a, 6b, 6c, 6d which promote alertness may be set. The plurality of sensors 14 may comprise sensors 14a, 14b, 14c of one type or multiple types and are arranged to provide data to perform a set of preselected tasks. The plurality of sensors 14 may be selected from a passive infrared (“PIR”) sensor, a thermopile sensor, a microwave sensor, an image sensor, a sound sensor, and/or any other sensor modality); activating one or more models based at least in part on the monitoring parameters ([0050] selecting for each sensor 14a, 14b, 14c of the plurality of sensors 14 selected, via the assessment artificial intelligence program 62, a machine learning algorithm 44a, 44b, 44c, 44d from a predetermined set of machine learning algorithms 44 based on the determined quality metric 46a, 46b, 46c of the sensor data 18a, 18b, 18c that yields the desired accuracy for performing the given task 16 (step 240); Examiner notes: the contents of the given task are considered when selecting which model to utilize on each sensor) includes: receiving at least one model of the one or more models via the task orchestrator ([0049] For every sensor (e.g., 14a, 14b, 14c) of the plurality of sensors 14 which the assessment artificial intelligence program 62 determines to use, a machine learning algorithm (from the predefined set of machine learning algorithms 44 (shown in FIG. 3)) is used to provide a classification output (e.g., 50a, 50b)); and activating the at least one received model ([0049] A classification output 50a, 50b is an output from the machine learning algorithm (e.g., 44a, 44b, 44c, 44d) for a particular sensor (e.g., 14a, 14b, 14c) and is a result generated by performing the task 16);
generating a task result associated with the first task and the second task by applying the one or more models to the collected and processed data (([0009] receiving a classification output from each selected machine learning algorithm for each selected sensor, wherein the classification output is a result generated by performing the task; Examiner notes: machine learning algorithms are applied to process collected sensor data);
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Yadav’s process of machine learning algorithm and resource allocation for a task of targeting of some object to monitor with the system of Wang. A person of ordinary skill in the art would have been motivated to make this combination to provide Wang’s system with the advantage of determining the necessary sensors and algorithms to best perform a computer vision task (see Yadav [0005] the system selects a specific sensor or a combination of sensors along with a corresponding machine learning algorithm to achieve enhanced performance in performing a task).
Wang and Yadav do not explicitly teach a first task associated with a first request queue for data collection, a second task associated with a second request queue for data processing, the second request queue being different from the first request queue.
However, Baracaldo teaches a first task associated with a first request queue for data collection ([0007] admitting, by the processor, the first job request from the first queue to a data analytics system and/or a data storage system to be processed; Examiner notes the first queue collects and stores data pertaining to job requests and their characteristics), a second task associated with a second request queue for data processing ([0007] other received job requests stored in other queues; Examiner notes: the queues store data to be processed by the system resources), the second request queue being different from the first request queue (Fig 4; [0006] The system also includes a plurality of queues, each queue being configured to store job requests having different estimated complexities and user skill levels with respect to job requests stored in other queues).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Baracaldo’s multiple job queue system with the existing system. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of organizing job requests for system resources based on varying levels of demand (see Baracaldo [0078] The service class may be based on a current service plan to which the user and/or organization is currently enrolled (some users may pay money on a recurring or one-off basis to have their job request(s) receive higher dispatch priority than other job requests of the same type). The service class may further be based on expected resource consumption of the job request (as the expected resource consumption is increased, the service class will be correspondingly decreased), and/or a job classification policy that is set by an administrator of the data analytics and/or data storage systems 414, in various embodiments).
Regarding claim 11, Wang, Yadav, and Baracaldo teach the method of claim 10.
Yadav further teaches the task orchestrator includes an indication of a model pipeline, the model pipeline including the one or more models ([0043] the assessment artificial intelligence program 62 can determine which machine learning algorithm from a predetermined set of machine learning algorithms 44 (shown in FIG. 3) should be used to perform the task).
Regarding claim 13, Wang and Yadav teach the method of claim 11.
Wang further teaches wherein the transmitting the task result to a computing device comprises transmitting the task result via the task orchestrator ([0073] the receiver module 5233 may be configured to receive a final running result/s from a corresponding last edge device/s in the cluster, rather than receiving a running result of each subtask from each device).
Conclusion
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to HARRISON LI whose telephone number is (703) 756-1469. The
examiner can normally be reached Monday-Friday 9:00am-5:30pm 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, Aimee Li can be reached on (571) 272-4169. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H.L./
Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights