DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web (PTO/SB/439).
Claim Objections
Claim 10 is objected to because of the following informalities: the phrase “communicating a continuation request for receive by the service provider system” should be corrected to “communicating a continuation request for receipt by the service provider system.” Appropriate correction is required.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 5-11, and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kothandaraman et al. (US 20220094741 A1) in view of Tian et al. (US 20190158626 A1).
As per claim 1, Kothandaraman teaches the invention substantially as claimed including a method comprising:
receiving, by a processing device, a request originated from a client device ([0001], One or more implementations relate to cloud computing environments, and more specifically to incremental processing of requests by mobile applications in a distributed system of a cloud computing environment; and [0078], priming client 414 of client application 402 makes a request to obtain data from cloud computing environment 404... the request is received by priming records API 426);
determining, by the processing device, using a timer that the client timeout value has elapsed ([0078], API timer is used to measure the elapsed time in processing of the request by cloud computing environment 404; and [0086], if there are more tasks to perform for handling the request, then at block 516 priming records API 426 checks if the elapsed time (e.g., process time) from the start of handling the request (started at block 504) exceeds a first predetermined threshold... If at block 516 the process time exceeds the first predetermined threshold ... then at block 520 priming records API 426 adds a relay token with a bookmark value to the payload, task processing is terminated, and processing continues with block 522) ;
communicating, by the processing device, a timeout response for receipt by the client device ([0080], During the processing of accounts, consider a case when the threshold time set at the server side (e.g., by priming records API 426) is exceeded (e.g., it is taking too long to process the entire request). In this case, a response containing only account records may be sent to the mobile client application with a relay token), the timeout response including a call identifier that identifies the request ([0080], a response containing only account records may be sent to the mobile client application with a relay token);
storing, by the processing device, a result payload in a storage device, the result payload generated by the execution module based on the request payload ([0084], information describing what tasks have already been processed are stored in a database in cloud resources 430 and may be retrieved from the database by reference to the relay token and associated bookmark value (which are sent in each relay request); and [0086], At block 524, priming records API 426 sends the payload to priming client 414 of client application 402 to complete request processing by cloud computing environment 404. Client application then consumes the payload as requested by the user);
receiving, by the processing device, a continuation request from the client device having the call identifier ([0080], Since the request is broken down across multiple server calls, it is necessary for the client application to send the relay token in all subsequent server calls, to remind the server from where processing of the request should continue; and [0084], subsequent requests that are increments of the entire request will have a relay token);
obtaining, by the processing device, the result payload from the storage device based on the call identifier ([0084], In an embodiment, information describing what tasks have already been processed are stored in a database in cloud resources 430 and may be retrieved from the database by reference to the relay token and associated bookmark value (which are sent in each relay request)); and
communicating, by the processing device, a continuation response for receipt by the client device, the continuation response including the result payload ([0086], At block 524, priming records API 426 sends the payload to priming client 414 of client application 402 to complete request processing by cloud computing environment 404. Client application then consumes the payload as requested by the user).
Kothandaraman fails to specifically teach, the request including a client timeout value and a request payload indicating an action to be performed by an execution module.
However, Tian teaches, receiving, by a processing device, a request originated from a client device ([0050], a client sends a service request to a server), the request including a client timeout value ([0050], The service request carries a timeout duration) and a request payload indicating an action to be performed by an execution module ([0062], the service requested by the service request may generally include a plurality of sub-services; and [0073], service request is configured to indicate data reading from the server).
Tian also teaches, determining, by the processing device, using a timer that the client timeout value has elapsed ([0065], during processing of the service requested by the service request, it is queried whether the expiration time is reached at a predetermined time interval. When the expiration time is reached and the processing of the service is uncompleted, a processing operation of the service requested by the service request is terminated; and [0067], the server does not process the service according to the completion situations of processing the plurality of sub-services included in the service, but processes the service requested by the service request based on the expiration time according to a certain time rule).
Kothandaraman and Tian are analogous because they are each related to task management. Kothandaraman teaches a method of managing tasks in accordance with time constraints including continuing task execution once a predetermined time constraint is exceeded. ([0012], perform incremental processing of a large API request based not only on the size of the payload (e.g., the data being returned in response to the request), but on an adaptive model measuring server utilization, hyper-text transport protocol (HTTP) timeout scenarios, and different client needs in terms of response time); and [0082], If this is a continuation of processing of multiple increments of the request (e.g., this is a relay), then at block 512 priming records API 426 continues to implement the request by starting continued processing of the request from where the processing was left off from a previous request. In an embodiment, one purpose of the relay is to break up a request from a single client into smaller manageable chunks, which are spread across multiple server calls from the same client. Since the request is broken down across multiple server calls, it is necessary for the client application to send the relay token in all subsequent server calls, to remind the server from where processing of the request should continue ). Tian teaches executing client requests based on timing constraints included in the requests. (Abstract, interface circuitry receives a request from a client device. The request requests the apparatus to perform a task of information processing and includes a timeout duration. The time duration indicates a maximum duration during which the apparatus is to send a result associated with performing the task to the client device. The processing circuitry determines an expiration time based on a present system time of the apparatus and the timeout duration. The expiration time indicates a final time for the apparatus to send the result associated with performing the task to the client device. The processing circuitry also performs the task of information processing requested by the client device based on the expiration time). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the client requests of Kothandaraman would be modified to include timing constraints as taught by Tian resulting in a system that provides task management in accordance with time constraints that are included in client requests. Therefore, it would have been obvious to combine the teachings of Kothandaraman and Tian.
As per claim 2, Kothandaraman teaches, wherein the request, the timeout response, the continuation request, and the continuation response are configured in compliance with a hypertext transfer protocol (HTTP) ([0024], User systems 12 (e.g., operated by customers) can communicate with database system 16 using TCP/IP and, at a higher network level, other common Internet protocols to communicate, such as the Hyper Text Transfer Protocol (HTTP)... In an example where HTTP is used, each user system 12 can include an HTTP client commonly referred to as a “web browser” or simply a “browser” for sending and receiving HTTP signals to and from an HTTP server of the database system 16. Such an HTTP server can be implemented as the sole network interface 20 between database system 16 and network 14; and [0032], network interface 20 is implemented as a set of HTTP application servers 100.sub.1-100.sub.N. Each application server 100, also referred to herein as an “app server,” is configured to communicate with tenant database 22 and tenant data 23 stored therein, as well as system database 24 and system data 25 stored therein, to serve requests received from user systems 12).
As per claim 5, Kothandaraman teaches, wherein the storing of the result payload is performed subsequent to the communicating of the timeout response ([0082], If this is a continuation of processing of multiple increments of the request (e.g., this is a relay), then at block 512 priming records API 426 continues to implement the request by starting continued processing of the request from where the processing was left off from a previous request; and [0085], if there are no more tasks to perform for handling the request, then at block 522 priming records AP1 426 prepares the payload containing the results from processing all tasks from the task list; Examiner Note: Kothandaraman continues execution after a time threshold has elapsed: [0086], If at block 516 the process time exceeds the first predetermined threshold ... then at block 520 priming records API 426 adds a relay token with a bookmark value to the payload, task processing is terminated, and processing continues with block 522).
As per claim 6, Kothandaraman teaches, wherein the storing of the result payload is performed prior to the receiving of the continuation request from the client device having the call identifier ([0084], information describing what tasks have already been processed are stored in a database in cloud resources 430 and may be retrieved from the database by reference to the relay token and associated bookmark value (which are sent in each relay request); Examiner Note: Kothandaraman’s stored information is used for subsequent requests: [0082], it is necessary for the client application to send the relay token in all subsequent server calls, to remind the server from where processing of the request should continue; and [0086], if there are more tasks to perform for handling the request, then at block 516 priming records API 426 checks if the elapsed time (e.g., process time) from the start of handling the request (started at block 504) exceeds a first predetermined threshold. If the process time has not been exceeded, then at block 518 priming records API 426 checks if the payload size storing the results of the processing the request exceeds a second predetermined threshold. If the payload size has not been exceeded, then priming records API 426 continues processing at block 512 with processing of additional tasks).
As per claim 7, Kothandaraman teaches, wherein the continuation response is configured as a hypertext transfer protocol (HTTP) response ([0032], network interface 20 is implemented as a set of HTTP application servers 100.sub.1-100.sub.N. Each application server 100, also referred to herein as an “app server,” is configured to communicate with tenant database 22 and tenant data 23 stored therein, as well as system database 24 and system data 25 stored therein, to serve requests received from user systems 12).
As per claim 8, Kothandaraman teaches, further comprising processing the request payload by the execution module concurrently with the determining that the client timeout value has elapsed and the communicating of the timeout response for receipt by the client device ([0080], During the processing of accounts, consider a case when the threshold time set at the server side (e.g., by priming records API 426) is exceeded (e.g., it is taking too long to process the entire request). In this case, a response containing only account records may be sent to the mobile client application with a relay token).
As per claim 9, Kothandaraman teaches, further comprising generating, by the processing device, the call identifier as identifying the request ([0079], a relay may be identified by a relay token having a bookmark value (e.g., indicating how much of the request has been processed so far). A relay token acts like a bookmark for the API to know from where request processing should commence in multi-relay (server) requests; and [0086], If at block 516 the process time exceeds the first predetermined threshold or at block 518 the payload size exceeds the second predetermined threshold, then at block 520 priming records API 426 adds a relay token with a bookmark value to the payload, task processing is terminated, and processing continues with block 522).
As per claim 10, Kothandaraman teaches the invention substantially as claimed including a client device ([0065], client application 402 includes service processor 406, offline utility component 408, web component resolver 410, web container 412, priming client 414, and client database (DB) 416. In one embodiment, client application is running on a mobile computing device, such as a smart phone or a tablet computer) comprising:
a processing device ([0074], cloud computing environment 404 includes at least one server 405 including one or more of task pre-processor 418, task post-processor 420, task processor 422, web component service 424, priming records API 426, and logging service 428); and
a computer-readable storage medium ([0094], implementations can be embodied in the form of various types of hardware, software, firmware, or combinations thereof...Any of the software components or functions described in this application can be implemented as software code to be executed by one or more processors...The software code can be stored as non-transitory instructions on any type of tangible computer-readable storage medium (referred to herein as a “non-transitory computer-readable storage medium”)) storing instructions that, responsive to execution by the processing device, causes the processing device to perform operations including:
generating a request for receipt by a service provider system ([0001], One or more implementations relate to cloud computing environments, and more specifically to incremental processing of requests by mobile applications in a distributed system of a cloud computing environment; and [0078], priming client 414 of client application 402 makes a request to obtain data from cloud computing environment 404... the request is received by priming records API 426);
receiving a timeout response ([0080], During the processing of accounts, consider a case when the threshold time set at the server side (e.g., by priming records API 426) is exceeded (e.g., it is taking too long to process the entire request). In this case, a response containing only account records may be sent to the mobile client application with a relay token) including a call identifier that identifies the request ([0080], a response containing only account records may be sent to the mobile client application with a relay token), the timeout response received responsive to a determination by the service provider system using a timer that the client timeout value has elapsed ([0078], API timer is used to measure the elapsed time in processing of the request by cloud computing environment 404; and [0086], if there are more tasks to perform for handling the request, then at block 516 priming records API 426 checks if the elapsed time (e.g., process time) from the start of handling the request (started at block 504) exceeds a first predetermined threshold... If at block 516 the process time exceeds the first predetermined threshold ... then at block 520 priming records API 426 adds a relay token with a bookmark value to the payload, task processing is terminated, and processing continues with block 522);
communicating a continuation request for receive by the service provider system, the continuation request including the call identifier ([0080], Since the request is broken down across multiple server calls, it is necessary for the client application to send the relay token in all subsequent server calls, to remind the server from where processing of the request should continue; and [0084], subsequent requests that are increments of the entire request will have a relay token); and
receiving a continuation response from the service provider system, the continuation response including a result payload generated by the service provider system based on the request payload ([0086], At block 524, priming records API 426 sends the payload to priming client 414 of client application 402 to complete request processing by cloud computing environment 404. Client application then consumes the payload as requested by the user).
Kothandaraman fails to specifically teach, the request including a client timeout value and a request payload indicating an action to be performed by an execution module.
However, Tian teaches, generating a request for receipt by a service provider system ([0050], the client may generate the service request based on the timeout duration and sends the service request carrying the timeout duration to the server, to inform the server of the maximum duration for feeding back the service processing result to the client. Accordingly, the server receives the service request sent by the client), the request including a client timeout value ([0050], The service request carries a timeout duration) and a request payload indicating an action to be performed by an execution module ([0062], the service requested by the service request may generally include a plurality of sub-services; and [0073], service request is configured to indicate data reading from the server).
The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 11, this claim is similar to claim 2 and is rejected for the same reasons.
As per claim 13, Kothandaraman teaches, wherein the call identifier is generated by the service provider system ([0079], a relay may be identified by a relay token having a bookmark value (e.g., indicating how much of the request has been processed so far). A relay token acts like a bookmark for the API to know from where request processing should commence in multi-relay (server) requests; and [0086], If at block 516 the process time exceeds the first predetermined threshold or at block 518 the payload size exceeds the second predetermined threshold, then at block 520 priming records API 426 adds a relay token with a bookmark value to the payload, task processing is terminated, and processing continues with block 522); Examiner Note: Kothandaraman’s “priming records API” is a part of its service provider system: [0019], application platform 18 enables the creation, management and execution of one or more applications developed by the provider of the on-demand database service, users accessing the on-demand database service via user systems 12, or third-party application developers accessing the on-demand database service via user systems 12; and [0020], application platform 18 includes ...priming records API 426).
As per claim 14, Kothandaraman teaches, wherein the continuation request is configured to cause the service provider system to locate the result payload from a storage device based on the call identifier ([0082], it is necessary for the client application to send the relay token in all subsequent server calls, to remind the server from where processing of the request should continue; and [0084], information describing what tasks have already been processed are stored in a database in cloud resources 430 and may be retrieved from the database by reference to the relay token and associated bookmark value (which are sent in each relay request). A first request (not needing a continuation) does not have a relay token; only subsequent requests that are increments of the entire request will have a relay token), the result payload stored subsequent to processing of the request payload by an execution module as performing an action specified by the request ([0085], if there are no more tasks to perform for handling the request, then at block 522 priming records API 426 prepares the payload containing the results from processing all tasks from the task list).
As per claim 15, Kothandaraman teaches the invention substantially as claimed including a system comprising:
an interface module ([0019], application platform 18 enables the creation, management and execution of one or more applications developed by the provider of the on-demand database service; and [0020], application platform 18 includes task processor 422, task pre-processor 418, task post-processor 420, web component service 424, priming records API 426, logging service 428, and cloud resources 430, as described herein) configured to:
receive a request from a client device ([0001], One or more implementations relate to cloud computing environments, and more specifically to incremental processing of requests by mobile applications in a distributed system of a cloud computing environment; and [0078], priming client 414 of client application 402 makes a request to obtain data from cloud computing environment 404... the request is received by priming records API 426);
communicate the request payload to an execution module ([0024], distribute incoming HTTP requests evenly over a number of servers; and [0082], one purpose of the relay is to break up a request from a single client into smaller manageable chunks, which are spread across multiple server calls from the same client);
communicate a timeout response for receipt by the client device responsive to expiration of the client timeout value ([0080], During the processing of accounts, consider a case when the threshold time set at the server side (e.g., by priming records API 426) is exceeded (e.g., it is taking too long to process the entire request). In this case, a response containing only account records may be sent to the mobile client application with a relay token), the timeout response including a call identifier that identifies the request ([0080], a response containing only account records may be sent to the mobile client application with a relay token);
receive a continuation request from the client device having the call identifier ([0080], Since the request is broken down across multiple server calls, it is necessary for the client application to send the relay token in all subsequent server calls, to remind the server from where processing of the request should continue; and [0084], subsequent requests that are increments of the entire request will have a relay token); and
communicate a continuation response for receipt by the client device, the continuation response including a result payload ([0086], At block 524, priming records API 426 sends the payload to priming client 414 of client application 402 to complete request processing by cloud computing environment 404. Client application then consumes the payload as requested by the user); and
the execution module configured to generate the result payload by executing an action specified in the request based on the request payload ([0084], information describing what tasks have already been processed are stored in a database in cloud resources 430 and may be retrieved from the database by reference to the relay token and associated bookmark value (which are sent in each relay request); and [0086], At block 524, priming records API 426 sends the payload to priming client 414 of client application 402 to complete request processing by cloud computing environment 404. Client application then consumes the payload as requested by the user).
Kothandaraman fails to specifically teach, the request including a client timeout value and a request payload.
However, Tian teaches, receive a request from a client device ([0050], a client sends a service request to a server), the request including a client timeout value ([0050], The service request carries a timeout duration) and a request payload ([0062], the service requested by the service request may generally include a plurality of sub-services; and [0073], service request is configured to indicate data reading from the server).
The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 16, Kothandaraman teaches, wherein the interface module is configured to:
receive the result payload from the execution module ([0075], Web component service 424 communicates with task processor 422 to fulfill user requests. Priming records API 426 queries cloud resources 430 as needed and generates results in response to user requests); and
cause the result payload to be stored in a storage device as associated with the call identifier ([0084], information describing what tasks have already been processed are stored in a database in cloud resources 430 and may be retrieved from the database by reference to the relay token and associated bookmark value (which are sent in each relay request)).
As per claim 17, Kothandaraman teaches, wherein the interface module is configured to obtain the result payload from the storage device responsive to the continuation request based on the call identifier ([0082], it is necessary for the client application to send the relay token in all subsequent server calls, to remind the server from where processing of the request should continue; and [0084], information describing what tasks have already been processed are stored in a database in cloud resources 430 and may be retrieved from the database by reference to the relay token and associated bookmark value (which are sent in each relay request)).
As per claim 18, this claim is similar to claim 2 and is rejected for the same reasons.
As per claim 19, Kothandaraman teaches wherein the interface module is configured to generate the call identifier ([0079], a relay may be identified by a relay token having a bookmark value (e.g., indicating how much of the request has been processed so far). A relay token acts like a bookmark for the API to know from where request processing should commence in multi-relay (server) requests; and [0086], If at block 516 the process time exceeds the first predetermined threshold or at block 518 the payload size exceeds the second predetermined threshold, then at block 520 priming records API 426 adds a relay token with a bookmark value to the payload, task processing is terminated, and processing continues with block 522)).
As per claim 20, Tian teaches, wherein the interface module is configured to set a timer based on the client timeout value ([0055], the server determines an expiration time based on a current system time and the timeout duration. The expiration time is configured to indicate a final time for feeding back the service processing result to the client).
Claims 3-4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Kothandaraman-Tian as applied to independent claims 1 and 10 and in further view of Speller et al. (US 10331424 B1).
As per claim 3, Speller teaches, wherein the request is a GET request, a POST request, a PUT request, a DELETE request, a PATCH request, a HEAD request, a CONNECT request, an OPTIONS request, or a TRACE request (Column 3, Lines 34-38, The XModule 210 can query the web service 104 for data using any suitable technique. For example, the XModule 210 can make HTTP-based requests (e.g., GET or POST) to the web service 104, which returns an HTTP response).
The combination of Kothandaraman-Tian and Speller are analogous because they are each related to task management including responding to client requests comprising tasks. Kothandaraman teaches a method of managing tasks in accordance with time constraints including continuing task execution once a predetermined time constraint is exceeded. Tian teaches executing client requests based on timing constraints included in the requests. Speller teaches a method of task management including receiving and responding to client requests utilizing the HTTP protocol. (Column 3, Lines 18-22, a web service 202 (e.g., an application programming interface (“API”) over a web protocol, such as HTTP) that conforms to the specification 206 is connected to the back-end 104 of the data provider 102; and Column 3, Lines 34-38, the XModule 210 can query the web service 104 for data using any suitable technique. For example, the XModule 210 can make HTTP-based requests (e.g., GET or POST) to the web service 104, which returns an HTTP response). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the task management system taught by the combination of Kothandaraman-Tiam would be modified to include HTTP requests as taught by Speller resulting in a system that provides task management in accordance with time constraints that are included in HTTP client requests. Therefore, it would have been obvious to combine the teachings of the combination of Kothandaraman-Tian and Speller.
As per claim 4, Speller teaches, wherein the continuation request is a GET request (Column 3, Lines 34-38, The XModule 210 can query the web service 104 for data using any suitable technique. For example, the XModule 210 can make HTTP-based requests (e.g., GET or POST) to the web service 104, which returns an HTTP response; and Column 14, Lines 1-5, The redirectLink in this response instructs the XModule to make a subsequent GET request to https://api.example.com/form_receipt?transaction_id=Sm9obiUyMFNtaXRo, which will return the final page's content in the sequence).
As per claim 12, Speller teaches wherein the request is a POST request (Column 3, Lines 34-38, The XModule 210 can query the web service 104 for data using any suitable technique. For example, the XModule 210 can make HTTP-based requests (e.g., GET or POST) to the web service 104, which returns an HTTP response) and the continuation request is a GET request (Column 3, Lines 34-38, The XModule 210 can query the web service 104 for data using any suitable technique. For example, the XModule 210 can make HTTP-based requests (e.g., GET or POST) to the web service 104, which returns an HTTP response; and Column 14, Lines 1-5, The redirectLink in this response instructs the XModule to make a subsequent GET request to https://api.example.com/form_receipt?transaction_id=Sm9obiUyMFNtaXRo, which will return the final page's content in the sequence).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is as follows:
Aleti et al. (US 11385936)-Teaches client requests including a timeout value and the HTTP protocol:
Column 7, Lines 28-32, client devices 102 communicate with one or more host applications 114 to exchange information. The communication between a client device 102 and a host application 114 may, for example, be based on the Hypertext Transfer Protocol (HTTP) or any other network protocol; and
Column 42, Lines 40-49, A determination is made whether the request status violates a policy or whether a timer expired. For example, the policies to move a search query may be based on one or more of time, user, role, application, quota of search queries, etc. If the request status does not does not violate a policy or if a timer has not expired, the flow proceeds to end 2506. If the request status violates a policy or if the timer expired for the request, an update command is issued to move the processes of the request to the new workload pool.’
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MELISSA A HEADLY whose telephone number is (571)272-1972. The examiner can normally be reached Monday- Friday 9-5:30pm.
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, Bradley Teets can be reached at 571-272-3338. 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.
/MELISSA A HEADLY/Examiner, Art Unit 2197
Prosecution Insights