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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 7/15/2026 has been entered.
Response to Amendment
The Amendment filed 7/15/2026 has been entered. Claim 2 has been cancelled. Claim 24 has been added. Claims 1, 3-16 and 20-24 remain pending in the application. Objections to the specification noted in the previous Office Action have been maintained. Applicant’s amendments to the claims have overcome the rejection under 112(a) noted in the previous Office Action.
Response to Arguments
Applicant’s arguments filed with the Amendment, with respect to rejections under prior art have been fully considered and are moot upon a new ground(s) of rejection, as necessitated by amendment, as outlined below.
Specification
The use of the following trademarks have been noted in this application:
Amazon, Google, IBM, Microsoft - ¶0078
Wherever the trademark appears, each letter of the trademark should be capitalized, or the proper trademark indication should be included. Each instance of the trademark should be accompanied by the generic terminology.
Although the use of trademarks is permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as trademarks.
Prior Art
Listed herein below are the prior art references relied upon in this Office Action:
Stan et al. (US Patent Application Publication 2024/0012387), referred to as Stan herein [cited in Applicant’s IDS dated 6/27/2024].
Coble et al. (US Patent Application Publication 2024/0144558), referred to as Coble herein [previously cited].
Cannon et al. (US Patent Number 6,754,715), referred to as Cannon herein [previously cited].
Paini et al. (US Patent Application Publication 2025/0103986), referred to as Paini herein [previously cited].
Grigore (US Parent Application publication 2022/0391227), referred to as Grigore ‘227 herein [previously cited].
Cooley et al. (US patent Application Publication 2009/0158399), referred to as Cooley herein [previously cited].
Marudhalam et al. (US Patent Number 12,078,985), referred to as Marudhalam herein.
Examiner’s Note
Strikethrough notation in the pending claims has been added by the Examiner.
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.
Claim(s) 1, 3, 5-6, 12-13, 16, 20-21, and 23-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stan in view of Paini in further view of Marudhalam.
Regarding claim 1, Stan discloses a method comprising: receiving an input at an automation hub, the input comprising an indication for a virtual bot process to start and that the virtual bot process includes a streaming capability (Stan, ¶0013, ¶0038, ¶0052, ¶0083-¶0085, ¶0136 – conductor or orchestrator application can start, deploy, and monitor RPA bots in response to user input. Fig. 6 with - ¶0113-¶0119, ¶0139-¶0141 – video streaming is performed in response to execution of the RPA);
In response to receiving the input, initiating, by way of the automation hub, a virtual bot to execute an operation, wherein the operation comprises communicating
generating a graphical representation of the virtual bot executing the operation (Stan, Figs. 6 and 8A-8B with ¶0121-¶0124 – video of execution of an RPA workflow);
and transmitting, to a client device, the graphical representation of the operation for display at the client device in accordance with the streaming capability (Stan, Fig. 10 with ¶0131-¶0134 – RPA video is transmitted to a video streaming service, which transmits video to a client application UI. ¶0090, ¶0140-¶0141 - client)
However, Stan appears not to expressly disclose the limitations in strikethrough above. However, in the same field of endeavor, Paini discloses an RPA bot management system (Paini, Abstract), including
analyzing the graphical representation to detect a pattern indicative of an error and based on the pattern, causing an adjustment to a behavior of the virtual bot that mitigates the error (Paini, Fig. 3 with ¶0067, ¶0070-¶0074 – capturing event data including video of the RPA interruption for analysis. Cross referencing the patterns with historical data to determine past occurrences of the RPA error to identify patterns and perform remedial actions).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified RPA workflow of Stan to include data capture and error mitigation for RPA interruptions based on the teachings of Paini. The motivation for doing so would have been to more efficiently troubleshoot and perform pre-emptive or real time action for bot failures (Paini, ¶0002), and reduce the associated cost and disruption of bot failures (Paini, ¶0074).
However, Stan as modified appears not to expressly disclose wherein the operation comprises communicating with another virtual bot by way of a queue that is part of the automation hub. However, in the same field of endeavor, a task management RPA hub (Marudhalam, Abstract with 4:38-63), including
wherein the operation comprises communicating with another virtual bot by way of a queue that is part of the automation hub (Marudhalam, Abstract – dispatcher bot prepares work tasks based on requests and dispatches the task to a performer bot that performs the work task. 5:64-6:48, 12:56-14:30 – dispatcher bot prepares data corresponding to work to be performed. A mediation module implements a queue for the work. Performer bots retrieve the work data from the queue module).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified RPA workflow of Stan to include dispatcher bots and queues based on the teachings of Marudhalem. The motivation for doing so would have been to implement a more reliable architecture (Marudhalem, 15:3-18), and to facilitate bot specialization (Marudhalem, 5:64-6:56) for improved task performance and efficiency.
Regarding claim 3, Stan as modified discloses the limitations of claim 1 above, and further discloses wherein the virtual bot includes software deployed on a computing system that is configured to perform one or more operations on the computing system including the operation (Stan, Fig. 2 with ¶0002, ¶0038, ¶0064-¶0067, ¶0112-¶0113 – software RPA robot executing tasks. Robots may be triggered by user events).
Regarding claim 5, Stan as modified discloses the elements of claim 1 above, and further discloses wherein generating the graphical representation of the virtual bot executing the operation comprises generating the graphical representation while the virtual bot executes the operation (Stan, Figs. 6 and 8A-8B with ¶0121-¶0124 – video of execution of an RPA workflow. ¶0028 – live stream).
Regarding claim 6, Stan as modified discloses the elements of claim 1 above, and further discloses wherein generating the graphical representation of the virtual bot executing the operation comprises storing the graphical representation in memory (Stan, ¶0123 – video is stored in memory with the RPA workflow).
Regarding claim 12, Stan as modified discloses the elements of claim 1 above, and further discloses wherein initiating the virtual bot to execute the operation is in response to receiving a command from the client device (Stan, Fig. 6 with - ¶0114-¶0119, ¶0139-¶0140 – video streaming is performed in response to execution of the RPA. ¶0083-¶0085, ¶0113, ¶0141 – inputting commands to start the robot).
Regarding claim 13, Stan as modified discloses the elements of claim 1 above, and further discloses wherein the client device is configured to provide a command that terminates execution of the virtual bot (Stan, ¶0083-¶0085 – stop command for robots).
Regarding claim 16, Stan discloses a non-transitory computer-readable medium, having stored thereon program instructions that, upon execution by a computing system, cause the computing system to perform operations comprising (Stan, ¶0004-¶0005 – processor executing instructions stored in hardware memory):
Receiving an input at an automation hub, the input comprising an indication for a virtual bot process to start and that the virtual bot process includes a streaming capability (Stan, ¶0013, ¶0038, ¶0052, ¶0083-¶0085, ¶0136 – conductor or orchestrator application can start, deploy, and monitor RPA bots in response to user input. Fig. 6 with - ¶0113-¶0119, ¶0139-¶0141 – video streaming is performed in response to execution of the RPA);
in response to receiving the input, initiating, by way of the automation hub, a virtual bot to execute an operation, wherein the operation comprises communicating RPA robot executing tasks. Robots may be triggered by user events. ¶0013, ¶0038, ¶0052, ¶0083, ¶0085, ¶0136 – conductor or orchestrator application can start, deploy, and monitor RPA bots);
generating a graphical representation of the virtual bot executing the operation (Stan, Figs. 6 and 8A-8B with ¶0121-¶0124 – video of execution of an RPA workflow); and
transmitting, to a client device, the graphical representation of the operation for display at the client device in accordance with the streaming capability (Stan, Fig. 10 with ¶0131-¶0134 – RPA video is transmitted to a video streaming service, which transmits video to a client application UI. ¶0090, ¶0140-¶0141 - client).
However, Stan appears not to expressly disclose the limitations in strikethrough above. However, in the same field of endeavor, Paini discloses an RPA bot management system (Paini, Abstract), including
analyzing the graphical representation to detect a pattern indicative of an error and based on the pattern, causing an adjustment to a behavior of the virtual bot that mitigates the error (Paini, ¶0067, ¶0070-¶0074 – capturing event data including video of the RPA interruption for analysis. Cross referencing the patterns with historical data to determine past occurrences of the RPA error to identify patterns and perform remedial actions).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified RPA workflow of Stan to include data capture and error mitigation for RPA interruptions based on the teachings of Paini. The motivation for doing so would have been to more efficiently troubleshoot and perform pre-emptive or real time action for bot failures (Paini, ¶0002), and reduce the associated cost and disruption of bot failures (Paini, ¶0074).
However, Stan as modified appears not to expressly disclose wherein the operation comprises communicating with another virtual bot by way of a queue that is part of the automation hub. However, in the same field of endeavor, a task management RPA hub (Marudhalam, Abstract with 4:38-63), including
wherein the operation comprises communicating with another virtual bot by way of a queue that is part of the automation hub (Marudhalam, Abstract – dispatcher bot prepares work tasks based on requests and dispatches the task to a performer bot that performs the work task. 5:64-6:48, 12:56-14:30 – dispatcher bot prepares data corresponding to work to be performed. A mediation module implements a queue for the work. Performer bots retrieve the work data from the queue module).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified RPA workflow of Stan to include dispatcher bots and queues based on the teachings of Marudhalem. The motivation for doing so would have been to implement a more reliable architecture (Marudhalem, 15:3-18), and to facilitate bot specialization (Marudhalem, 5:64-6:56) for improved task performance and efficiency.
Regarding claim 20, Stan as modified discloses a system comprising: one or more processors; and memory, containing program instructions that, upon execution by the one or more processors, cause the system to perform steps comprising (Stan, ¶0004-¶0005 – processor executing instructions stored in hardware memory):
receiving an input at an automation hub, the input comprising an indication for a virtual bot process to start and that the virtual bot process includes a streaming capability (Stan, ¶0013, ¶0038, ¶0052, ¶0083-¶0085, ¶0136 – conductor or orchestrator application can start, deploy, and monitor RPA bots in response to user input. Fig. 6 with - ¶0113-¶0119, ¶0139-¶0141 – video streaming is performed in response to execution of the RPA);
in response to receiving the input, initiating, by way of the automation hub, a virtual bot to execute an operation, wherein the operation comprises communicating
generating a graphical representation of the virtual bot executing the operation (Stan, Figs. 6 and 8A-8B with ¶0121-¶0124 – video of execution of an RPA workflow);
transmitting, to a client device, the graphical representation of the operation for display at the client device in accordance with the streaming capability (Stan, Fig. 10 with ¶0131-¶0134 – RPA video is transmitted to a video streaming service, which transmits video to a client application UI. ¶0090, ¶0140-¶0141 - client);
However, Stan appears not to expressly disclose the limitations in strikethrough above. However, in the same field of endeavor, Paini discloses an RPA bot management system (Paini, Abstract), including
analyzing the graphical representation to detect a pattern indicative of an error and based on the pattern, causing an adjustment to a behavior of the virtual bot that mitigates the error (Paini, ¶0067, ¶0070-¶0074 – capturing event data including video of the RPA interruption for analysis. Cross referencing the patterns with historical data to determine past occurrences of the RPA error to identify patterns and perform remedial actions).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified RPA workflow of Stan to include data capture and error mitigation for RPA interruptions based on the teachings of Paini. The motivation for doing so would have been to more efficiently troubleshoot and perform pre-emptive or real time action for bot failures (Paini, ¶0002), and reduce the associated cost and disruption of bot failures (Paini, ¶0074).
However, Stan as modified appears not to expressly disclose wherein the operation comprises communicating with another virtual bot by way of a queue that is part of the automation hub. However, in the same field of endeavor, a task management RPA hub (Marudhalam, Abstract with 4:38-63), including
wherein the operation comprises communicating with another virtual bot by way of a queue that is part of the automation hub (Marudhalam, Abstract – dispatcher bot prepares work tasks based on requests and dispatches the task to a performer bot that performs the work task. 5:64-6:48, 12:56-14:30 – dispatcher bot prepares data corresponding to work to be performed. A mediation module implements a queue for the work. Performer bots retrieve the work data from the queue module).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified RPA workflow of Stan to include dispatcher bots and queues based on the teachings of Marudhalem. The motivation for doing so would have been to implement a more reliable architecture (Marudhalem, 15:3-18), and to facilitate bot specialization (Marudhalem, 5:64-6:56) for improved task performance and efficiency.
Regarding claim 21, Stan as modified discloses the elements of claim 1 above, and further discloses wherein transmitting the graphical representation is performed based on the virtual bot failing during execution (Paini, ¶0070 – recording the time of interruption of the RPA actions and video recording of the interruption).
Regarding claim 23, Stan as modified discloses the elements of claim 1 above, and further discloses obtaining, from a log collector, a timestamp indicating when the virtual bot failed in executing the operation (Paini, ¶0070 – recording the time of interruption of the RPA actions and video recording of the interruption);
and cross-referencing the timestamp with the graphical representation to determine a failure mode of the virtual bot (Paini, ¶0070 – recording the time of interruption of the RPA actions and video recording of the interruption. ¶0071 – cross-referenced video and time stamps are used of subsequent analysis and troubleshooting efforts. ¶0072 – machine learning algorithm performs the analysis to determine patterns that cause failures in the RPA action sequences and predict future failures and automatically trigger mitigation actions. ¶0073 – cross referencing the patterns with historical data to determine past occurrences to identify patterns and perform remedial actions).
Regarding claim 24, Stan as modified discloses the elements of claim 1 above, and further discloses wherein the operation further comprises generating reports, sending emails, or handling exceptions (Stan, ¶0058 – automation of social messaging application conversations. ¶0044 – automation of email application processes. ¶0062-¶0063 – automation workflow includes error handling and debugging. Paini, ¶0067, ¶0070-¶0074 – capturing event data including video of the RPA interruption for analysis. Cross referencing the patterns with historical data to determine past occurrences of the RPA error to identify patterns and perform remedial actions. Marudhalam, 1:14-23, 9:14-22 – financial report generation).
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stan in view of Paini in further view of Marudhalam in further view of Coble.
Regarding claim 4, Stan as modified discloses the elements of claim 3 above. However, Stan appears not to expressly disclose wherein the computing system is a virtual machine that performs screen captures to obtain the graphical representation of the virtual bot executing the operation (Stan, ¶0098 – presentation of video of a user interface of a remote computing system. ¶0039 - VM).
However, in the same field of endeavor, Coble discloses monitoring of bot automation executing on a remote computer (Coble, Abstract with Fig. 1A with ¶0016), including
wherein the computing system is a virtual machine that performs screen captures to obtain the graphical representation of the virtual bot executing the operation (Coble, Abstract – captured screenshots assembled into video data used to monitor the bot activity. Fig. 1D with ¶0030 – video from screen captures of the user interface that the bot was presented with during an automation run. ¶0016, ¶0019 - VM).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the video of Stan to include screen captures based on the teachings of Coble. The motivation for doing so would have been to enable the monitoring user to see the interface that the bot was presented with, to better enable diagnosis of problems or difficulties encountered by the bot (Coble, ¶0014, ¶0018, and ¶0030).
Claim(s) 7-11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stan in view of Paini in further view of Marudhalam in further view of Cannon.
Regarding claim 7, Stan as modified discloses the elements of claim 6 above. However, Stan appears not to expressly disclose wherein transmitting the graphical representation of the operation for display at the client device comprises retrieving the graphical representation from the memory.
However, in the same field of endeavor, Cannon discloses streaming video data to client computers from a server (Cannon, Abstract), including
wherein transmitting the graphical representation of the operation for display at the client device comprises retrieving the graphical representation from the memory (Cannon, Fig. 1A with 7:1-36, 8:33-46 – data packets retrieved from memory, including volatile memory, for transmission to the client computer. 9:8-14 – RAM memory. 7:16-8:8 – retransmission and play-out buffer for transmitting video frames to the client computer for reproduction. Real-time video and live video frames are recreated as they are streamed from the server. 11:62-12:37 – video frame time stamps within the buffer).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the video streaming of Stan to include retrieving the video from memory based on the teachings of Cannon. The motivation for doing so would have been to improve the service and management of real-time video across networks, especially in network configurations with many clients (Cannon, 2:4-54).
Regarding claim 8, Stan as modified discloses the elements of claim 7 above, and further discloses wherein the memory comprises a volatile memory configured to store a buffer of graphical representations, and wherein the transmitting the graphical representation of the operation for display at the client device comprises streaming the graphical representations to the client device (Stan, ¶0099 – memory includes non-volatile memory. Cannon, Fig. 1A with 7:1-36, 8:33-46 – data packets retrieved from memory, including volatile memory, for transmission to the client computer. Fig. 2 with 8:46-9:14 – server RAM memory. 7:16-8:8 – retransmission and play-out buffer for transmitting video frames to the client computer for reproduction. Real-time video and live video frames are recreated as they are streamed from the server. 11:62-12:37 – video frame time stamps within the buffer. 6:25-39 – buffers maintain video data packets).
Regarding claim 9, Stan as modified discloses the elements of claim 8 above, and further discloses wherein streaming the graphical representations to the client device occurs in real time as the virtual bot is executing the operation (Stan, Figs. 6 and 8A-8B with ¶0121-¶0124 – video of execution of an RPA workflow. ¶0028 – live stream).
Regarding claim 10, Stan as modified discloses the elements of claim 8 above, and further discloses wherein streaming the graphical representations to the client device is responsive to commands receivable from the client device for starting, stopping, rewinding, or sharing the streaming (Stan, Fig. 6 with - ¶0114-¶0119, ¶0139-¶0140 – video streaming is performed in response to execution of the RPA. ¶0083-¶0085, ¶0113, ¶0141 – inputting commands to start the robot. Cannon, Abstract with 1:52-60 – rewind, stop, pause, play).
Regarding claim 11, Stan as modified discloses the elements of claim 1 above, and further discloses wherein streaming the graphical representation to the client device comprises: receiving the graphical representation from a computing system on which the virtual bot executes the operation, wherein the graphical representation comprises
and transmitting, to the client device, a firststreaming service, which transmits video to a client application UI. ¶0090, ¶0140-¶0141 – client. ¶0028 – live stream).
However, in the same field of endeavor, Cannon discloses streaming video data to client computers from a server (Cannon, Abstract), including
wherein the graphical representations are frames of a video segment; storing, in a buffer, the frames in chronological order; and transmitting, to the client device, a first frame of the frames while a second frame of the frames remains stored in the buffer awaiting transmission, wherein the first frame was captured before the second frame was captured (Cannon, Fig. 1A with 7:1-36 – data packets retrieved from memory. 9:8-14 – RAM memory. 7:16-8:8 – retransmission and play-out buffer for transmitting video frames to the client computer for reproduction. Real-time video and live video frames are recreated as they are streamed from the server. 11:62-12:37, 13:13-35 – video frame time stamps within the buffer are stored in chronological order and used to seek to play positions within the video).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the video streaming of Stan to include retrieving the video from a buffer based on the teachings of Cannon. The motivation for doing so would have been to improve the service and management of real-time video across networks, especially in network configurations with many clients (Cannon, 2:4-54).
Claim(s) 14-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stan in view of Paini in further view of Marudhalam in further view of Munteanu.
Regarding claim 14, Stan as modified discloses the elements of claim 1 above, and further discloses wherein the operation comprises the virtual bot representation of a graphical user interface,
However, Stan as modified does not appear to expressly disclose an error caused by a change in location. However, in the same field of endeavor, Munteanu discloses RPA process automation (Munteanu, Abstract), including
the operation comprises the virtual bot entering pre-determined data into a representation of a graphical user interface (Munteanu, ¶0103, ¶0135, ¶0140, ¶0145 – RPA enters text into text fields),
wherein the error was caused by a screen layout of the graphical user interface or input fields of the screen layout having changed since the virtual bot was programmed (Munteanu, ¶0034, ¶0090-¶0091, ¶0126, ¶0138 - errors may occur if elements cannot be found based on location changes between development and runtime).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the RPA of Stan as modified to include entering text into text boxes, and elements changing location based on changes in layout due to version updates based on the teachings of Munteanu. The motivation for doing so would have been to realize robotic process automation for processes that include user interface data entry, thereby reducing associated errors and enabling workers to focus on other tasks, and to enable RPA application to new versions of the interface.
Regarding claim 15, Stan as modified discloses the elements of claim 14 above, and further discloses wherein the graphical user interface comprises a text box and the pre-determined data comprises text to be placed in the text box (Munteanu, ¶0103, ¶0135, ¶0140, ¶0145 – RPA enters text into text fields).
Claim(s) 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stan in view of Paini in further view of Marudhalam in further view of Grigore ‘227 in further view of Cooley.
Regarding claim 22, Stan as modified discloses the elements of claim 1 above. However, Stan as modified appears not to expressly disclose detecting a two step authentication requirement within a graphical user interface associated with the operation; and pausing execution of the virtual bot to receive user input providing a two-step authentication code to the virtual bot.
However, in the same field of endeavor, Grigore ‘227 discloses RPA automation systems (Grigore, Abstract), including
detecting an authentication requirement within a graphical user interface associated with the operation; and pausing execution of the virtual bot to receive user input providing credentials to the virtual bot (Grigore ‘227, ¶0087-¶0088 – the RPA robot has access to stored credentials. When they are not found and the credentials will be needed within the process, during execution of the automation, the RPA robot will prompt the user to enter the credentials).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the RPA of Stan to include entering text into text boxes based on the teachings of Grigore ‘227. The motivation for doing so would have been to enable robotic process automation to successfully perform processes that require credentials, especially for processes where pre-stored credentials cannot be located (Grigore ‘227, ¶0087).
However, Stan as modified appears not to expressly disclose multi-step authentication. However, in the same field of endeavor, Cooley discloses automation of authentication (Cooley, Abstract), including
two-step authentication (Cooley, Figs. 3-4 with ¶0027-¶0033 – learning multi-step authentication patterns and responses, and performing the automation).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the authentication of Stan as modified to include multi-step authentication based on the teachings of Cooley. The motivation for doing so would have been to enable robotic process automation to successfully perform processes that require authentication for instances where more than one authentication step is required, such as for banking, personal social networking sites, and financial transactions (Cooley, ¶0004-¶0006).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL W PARCHER whose telephone number is (303)297-4281. The examiner can normally be reached Monday - Friday, 9:00am - 5:00pm, Mountain Time.
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, William Bashore can be reached at (571)272-4088 (Eastern Time). 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.
/DANIEL W PARCHER/Primary Examiner, Art Unit 2174
