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 .
This office action is responsive to communications filed 3/13/25. Claims 1 – 20 have been examined and are pending.
Priority
The current application is a Continuation of US Application # 17/454,884 (now US Patent No. 12,278,767 B2) filed 11/15/21. The current application is entitled to an effective filing date of 11/15/21
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 8, and 15 are rejected on the ground of non-statutory double patenting as being unpatentable over claim 1, claims 8 + claim1, and claim 15 + claim 1 of U.S. Patent No 12,278,767 B2. as follows. Claims 2-7, 9 - 14 and 16 - 20 depend from claims 1, 8 and 15, respectively. Therefore, similar reasons for rejection apply.
Current Application #19/079,003
US Patent No. 12,278,767 B2
Claim 1. A system comprising: a server system comprising one or more processors in communication with one or more memory devices storing computer readable instructions that when executed by the one or more processors are configured to cause:
receiving, via an edge worker associated with a content delivery network (CDN), a first set of requests to access a first site;
determining that traffic to the first site is to be throttled;
responsive to determining that traffic to the first site is to be throttled,
transmitting instructions to the edge worker, the instructions configured to cause the edge worker to direct at least a portion of a second set of requests to access the first site to a waiting room site prior to being directed to the first site;
determining an update in performance due to throttling; and
determining whether to disable the waiting room site based at least part on the update in performance.
Claim 1. A system comprising: a server system comprising one or more processors in communication with one or more memory devices storing computer readable instructions that when executed by the one or more processors are configured to cause:
enabling a preconfigured waiting room site specific to a first site;
receiving, via an edge worker associated with a content delivery network (CDN), a first set of requests to access a first site;
determining that traffic to the first site is to be throttled;
responsive to determining that traffic to the first site is to be throttled, determining a throttling rate based at least in part on: a number of requests in the first set of requests and/or a degradation rate associated with a degradation in service capacity;
transmitting instructions to the edge worker, the instructions configured to cause the edge worker to direct at least a portion of a second set of requests to access the first site to the waiting room site prior to being directed to the first site, the direction of the at least the portion of the second set of requests to the waiting room site being subject to the throttling rate; and wherein the instructions to the edge worker comprise an indication of the throttling rate;
determining an update in performance due to throttling subject to the throttling rate; and
determining whether to disable the
Claim 8. A non-transitory computer-readable medium storing instructions… executed by one or more processors …to perform:
receiving, via an edge worker associated with a content delivery network (CDN), a first set of requests to access a first site;
determining that traffic to the first site is to be throttled;
responsive to determining that traffic to the first site is to be throttled,
transmitting instructions to the edge worker, the instructions configured to cause the edge worker to direct at least a portion of a second set of requests to access the first site to a waiting room site prior to being directed to the first site;
determining an update in performance due to throttling; and
determining whether to disable the waiting room site based at least part on the update in performance.
Claim 8. A non-transitory computer readable medium storing instructions …executed by one or more processors …to perform:
receiving, via an edge worker associated with a content delivery network (CDN), a first set of requests to access a first site;
determining that traffic to the first site is to be throttled;
responsive to determining that traffic to the first site is to be throttled, determining a throttling rate…; and
transmitting instructions to the edge worker, the instructions configured to cause the edge worker to direct at least a portion of a second set of requests to access the first site to a waiting room site prior to being directed to the first site, the direction of the at least the portion of the second set of requests to the waiting room site being subject to the throttling rate.
[ From claim 1 ]:
determining an update in performance due to throttling subject to the throttling rate; and
determining whether to disable the
Claim 15. A method comprising:
receiving, via an edge worker associated with a content delivery network (CDN), a first set of requests to access a first site;
determining that traffic to the first site is to be throttled;
responsive to determining that traffic to the first site is to be throttled,
transmitting instructions to the edge worker, the instructions configured to cause the edge worker to direct at least a portion of a second set of requests to access the first site to a waiting room site prior to being directed to the first site;
determining an update in performance due to throttling; and
determining whether to disable the waiting room site based at least part on the update in performance.
Claim 15. A method comprising:
receiving, via an edge worker associated with a content delivery network (CDN), a first set of requests to access a first site;
determining that traffic to the first site is to be throttled;
responsive to determining that traffic to the first site is to be throttled, determining a throttling rate…; and
transmitting instructions to the edge worker, the instructions configured to cause the edge worker to direct at least a portion of a second set of requests to access the first site to a waiting room site prior to being directed to the first site, the direction of the at least the portion of the second set of requests to the waiting room site being subject to the throttling rate.
[ From claim 1 ]:
determining an update in performance due to throttling subject to the throttling rate; and
determining whether to disable the
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-3, 5-10, 12-20 are rejected under 35 U.S.C. 103 as being unpatentable over Weihl et al (US 2013/0232249 A1) in view of Abdelal et al (US 2010/0274893 A1)
Re: Claim 1, Weihl teaches a system comprising:
a server system comprising one or more processors in communication with one or more memory devices, the server system configurable to cause:
receiving, via an edge worker associated with a content delivery network (CDN) , a first set of requests to access a first site (Weihl: [0004] – ‘CDN edge server handles requests directed to the CDN’; [0023] ref FIG 2 CDN Edge Server)
determining that traffic to the first site is to be throttled (Weihl: “rate limited”; [0071] As the edge server receives a request it steps through a sequence of checks and calculations to determine how to handle this request given the presence of rate-limiting settings”)
responsive to determining that traffic to the first site is to be throttled (Weihl: [0044] “an edge server … limits origin requests to some maximum rate…”) … [causing] at least a portion of a second set of requests to access the first site to a waiting room site prior to being directed to the first site; (Weihl: [0048] When forward rate limiting is implemented, there may be controls for … detecting when an origin is overloaded based on its responsiveness, and queuing requests when the origin server appears to be overloaded; [0072] “request should be sent to a queue rather than sent forward”)
determining an update in performance due to throttling (Weihl: [0114] – [0118]) and determining whether to disable the waiting room site based at least part on the update in performance.(Weihl: [0047] “… the edge server is instructed to dynamically adjust the rate at which it sends requests to the origin server …. based on an estimated load being sent and a number of failures or slow connections encountered under that load; [0066] “… the rate of requests to the origin preferably is adjusted for failures, timeouts and slowness in responses”; [0071] – [0072] As the edge server receives a request it steps through a sequence of checks and calculations to determine how to handle this request given the presence of rate-limiting settings. … [including determining] if the request should be sent to a queue rather than sent forward ; [0077] “request can go forward to the origin server …” [0084] Forward rate limiting disabled)
Weihl does not explicitly teach:
(i) transmitting instructions to the edge worker, the instructions configured to cause the edge worker to direct at least a portion of a second set of requests to access the first site to a waiting room site prior to being directed to the first site.
Abdelal teaches:
(i) transmitting instructions to the edge worker (Abdelal: [0097]-[0098] ref FIG 7, Edge Proxy) the instructions configured to cause the edge worker to direct at least a portion of a second set of requests to access the first site to a waiting room site (Abdelal: [0098] “The proxies can be represented as a finite queue that holds the arriving messages, and serves them … at a constant rate) prior to being directed to the first site; (Abdelal: [0021] “The method also includes transmitting a second set of a plurality of requests for services to the server at a second transmission rate during a second period of time after the first period of time and limiting the second transmission rate to be less than or equal to the second transmission limit rate during the second period of time.),.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Abdelal re: throttling of a second set of requests to “appropriately adjust a rate of transmitting requests for service to [a] server” (Abdelal: [0064]) with those of Weihl re: determining if the request should be sent to a queue or forwarded to the server (Weihl: [0047]-[0048]; [0071]-[0072], [0077]) since doing so “can advantageously allow clients … to reduce offered load to [an] overloaded server” and so that “throughput can be maximized” (Abdelal: [0064])
Claims 8 and 15 do not teach or define any new limitations above claim 1. Therefore, similar reasons for rejection apply.
Re: Claim 2, Weihl teaches the system of claim 1, wherein the throttling rate is determined based on a number of requests for the first site at which the degradation in service capacity (Weihl [0055] - estimated load based on the number of requests; [0047] “…edge server is instructed to dynamically adjust the rate at which it sends requests to the origin server …. based on an estimated load being sent and a number of failures or slow connections encountered under that load”; wherein Examiner interprets failures or slow connections as “degradation in service capacity”)
Claims 9 and 16 do not teach or define any new limitations above claim 2. Therefore, similar reasons for rejection apply.
Re: Claim 3, Weihl teaches the system of claim 2, including determining degradation in service capacity is identified based on network usage information ([0047]; [0059] – [0060] To effectively adjust the maximum amount of load that an individual server sends forward to the origin, preferably the server tracks how responsive the origin server is in handling connections (both TCP and SSL); [0066]-[0067] “…the rate of requests to the origin preferably is adjusted for failures, timeouts and slowness in responses … where slowness is judged for connections (TCP and SSL))
Claims 10 and 17 do not teach or define any new limitations above claim 3. Therefore, similar reasons for rejection apply.
Re: Claim 5, Weihl teaches the system of claim 1, including:
determining a response to throttling of traffic to the first site (Weihl: [0071] –[0072] As the edge server receives a request it steps through a sequence of checks and calculations to determine how to handle this request given the presence of rate-limiting settings. … [including determining] if the request should be sent to a queue rather than sent forward ; [0102] When the rate of incoming client requests exceeds the limits placed on forwarding requests to the origin server, requests may be placed in a queue to wait for forwarding) and
transmitting updated instructions to the edge worker, wherein the updated instructions cause the waiting room site to be disabled and to cause a third set of requests to access the first site to be directed to the first site (Weihl: [0077] “request can go forward to the origin server …” ; [0084] Forward rate limiting disabled)
Claims 12 and 18 do not teach or define any new limitations above claim 5. Therefore, similar reasons for rejection apply.
Re: Claim 6, Weihl teaches the system of claim 1, including determining a response to throttling of traffic to the first site (Weihl: [0071] –[0072] As the edge server receives a request it steps through a sequence of checks and calculations to determine how to handle this request given the presence of rate-limiting settings. … [including determining] if the request should be sent to a queue rather than sent forward ; [0102] When the rate of incoming client requests exceeds the limits placed on forwarding requests to the origin server, requests may be placed in a queue to wait for forwarding)
Weihl does not explicitly teach:
(i) determining an updated throttling rate based on the response to the throttling of traffic to the first site;
(ii) transmitting updated instructions to the edge worker, wherein the updated instructions cause a third set of requests to access the first site to be throttled subject to the updated throttling rate.
Abdelal teaches:
(i) determining an updated throttling rate (Abdelal: [0022] – [0024] “adjusting the transmission limit rate”) based on the response to the throttling of traffic to the first site (Abdelal: [0022] “adjusting the transmission limit rate may based on an overload value and the transmission limit rate” [0027] – [0028] overload may be determined based on delay threshold and “delay threshold can be based on an average response time to one or more prior requests for services transmitted to the server”); and (ii) transmitting updated instructions to the edge worker (Abdelal: [0097]-[0098] ref FIG 7, Edge Proxy), wherein the updated instructions cause a third set of requests to access the first site to be throttled subject to the updated throttling rate Abdelal: [0022] – [0024] - transmission limit rate adjustment)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Abdelal re: updating (adjusting) the throttling rate of a set of requests to “appropriately adjust a rate of transmitting requests for service to [a] server” (Abdelal: [0064]) with those of Weihl re: request throttling since doing so “can advantageously allow clients … to reduce offered load to [an] overloaded server” and so that “throughput can be maximized” (Abdelal: [0064])
Claims 13 and 19 do not teach or define any new limitations above claim 6. Therefore, similar reasons for rejection apply.
Re: Claim 7, Weihl teaches the system of claim 1, including traffic throttling for multiple CDN sites (Weihl [0047]-[0048]; [0066]; [0071]; [0019] ref FIG 1, CDN Servers 102; [0024] ref FIG 3, multiple CDN servers in a region)
Weihl does not explicitly teach:
the throttling rate is determined further based on traffic to a second site associated with the server system.
Abdelal teaches:
the throttling rate is determined further based on traffic to a second site associated with the server system.(Abdelal: [0016] the method includes receiving a second feedback message from a second downstream server, wherein the second feedback message includes the statistic; [0032] The implementations can be designed to aggregate data structures stored across multiple network elements (e.g., sources, server nodes) to gather network-wide statistics for downstream servers ….. Control parameters can be calculated based on the data structures and distributed to the appropriate action locations (e.g., clients, server nodes; [0105] ref FIG 9 “… bloom filter 1000 stores the number of session rejections for downstream server 904, a failed connection request from a source 902 to the downstream server 904, an overload notification from the downstream server 904, and any other useful communication protocol statistic)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Abdelal re: determining throttling (transmission) rate based on traffic to a second site with those of Wiehl re: traffic throttling for multiple sites in order to “reduce the number of messages causing [an] overload episode before they reach the downstream server to prevent the unnecessary use of network bandwidth and to reduce the processing load on the downstream server … [whereby] the offered load to servers can be reduced to a level that can maximize server throughput … . which can result in protecting the overloaded system from more extreme overloads and/or can enable the server to operate at near optimum load for the entire duration of an overload event.” (Abdelal:[0032])
Claims 14 and 20 do not teach or define any new limitations above claim 7. Therefore, similar reasons for rejection apply.
Claims 4 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Weihl and Abdelal in view of Czerpak et al (EP-3952256-B1)
Re: Claim 4, Weihl teaches the system of claim 1, including traffic throttling for multiple CDN sites (Weihl [0047]-[0048]; [0066]; [0071]; [0019] ref FIG 1, CDN Servers 102; [0024] ref FIG 3, multiple CDN servers in a region)
Weihl and Abdelal do not explicitly teach:
(i) the waiting room site is specific to the first site [and] (ii) the waiting room site was preconfigured prior to determining that the traffic to the first site is to be throttled.
Czerpak teaches:
(i) the waiting room site is specific to the first site [and] (ii) the waiting room site was preconfigured prior to determining that the traffic to the first site is to be throttled. ( Czerpak: [0005] During times of normal load, website visitors arrive at the CDN proxy server and their content requests are directed to the origin application server for the website. During a traffic surge, visitors can be either directed to the origin application server, or directed to a waiting room ….The waiting room is typically a branded web page-- for example a page presenting the user with a logo, a company message, and/or an animated "hourglass" icon. This web page also includes (in code) an embedded refresh directive…. This refresh is essentially another attempt to enter the actual website, and to leave the waiting room web page. Every time that the page refreshes, the visitor has a chance of leaving the waiting room and being admitted to the origin application server. The website owner can control the chance of leaving the waiting room as a configurable parameter, thus controlling the rate of new visitors.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Czerpak re: throttling by redirecting traffic to a pre-configured waiting room site with those of Wiehl re: traffic throttling for multiple sites since doing so provides a customized web page with user-configurable rate control to “ensure that origin application delivery servers do not become overloaded .. [so that] the load on the origin can be handled more effectively and gracefully” (Czerpak [0004])
Claim 11 does not teach or define any new limitations above claim 4. Therefore similar reasons for rejection apply.
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Thomas et al (US 2022/0394079 A1) ( [0008] Requests for [origin server] resources may be received and processed at intermediary proxy servers such as those providing content delivery network (CDN) ….edge servers of a [CDN] network may receive and process requests for the origin resources instead of the origin servers; [0015] “… each edge server of a data center includes a worker script that is associated with a queue for limiting access to an application or resource”; [0040] “when a request is received, a worker is used to decide whether to send the request to the origin server or the user associated with the request [to be] queued in an application queue”; [0011] - [0012]; [0033] Ref FIG 2, “application queues 124A and 124N are enabled … in response to an amount of network traffic exceeding a predefined limit” ; [0043] “… the first edge server assigns the first user associated with the request to a user bucket of an application queue. The user bucket is associated with a time interval based on receipt of the request…. As new requests are received during the current minute time interval, users associated with the new requests are automatically queued in the first user bucket. After the current minute time interval is completed … a second user bucket is generated to queue users associated with requests received in the next minute time interval”
Bhandarkar et al US 20230057068 A1 (Abstract: Techniques for providing request throttling using proportional, integral, and exponential smoothing algorithms are disclosed. A distributed computing system can include a throttler engine that receives a plurality of requests targeting a software component within the distributed computing system. The throttler engine can aggregate the requests into a queue based on a time window. The throttler engine can determine a received request rate and a request rate limit for the software component and then compute a throttled request rate. The throttled request rate can include correction terms derived from proportional and integral computations and a correction term obtained from an exponential smoothing algorithm. The throttler engine can then provide throttled requests from the queue to the software component. [0005] “… the throttler engine can further aggregate a second subset of the plurality of requests based on a second time window ….The second received request rate can be used to update the plurality of correction values, which in turn can be used to update the throttled request rate. [0029]; [0032] - [0035])
Bindal (US 2007/0118653 A1)(Abstract: A system for throttling data traffic on a network to a client includes an application node and a throttle manager. The application node receives requests from the client via the network. The throttle manager is in communication with the application node. The throttle manager is configured to track a parameter that is based on a number of active requests associated with a user identifier associated with the client. The throttle manager is configured to determine whether to restrict responses to the requests responsive to a relationship of the parameter to a threshold; [0007]; [0032] “… a threshold for issuance of the throttle message 46 and a threshold for issuance of a clearance message 54 may be different values. … By setting the threshold for issuance of a clearance message lower than the threshold for issuance of a throttle message, repeated toggling of the user identifier onto and off of the throttle list may be avoided …. the throttle manager 26 may alternatively be configured to determine a number of requests made to a particular application resource of the application node cluster 18 and/or a rate of requests made to that particular application resource … in response to a client request that results in access of the application resource, the number of active requests associated with application resource identifier would increment and the throttle manager 26 would determine if the application resource had received a number or rate of requests above threshold and, if necessary, throttle access for all users to the application resource until the number or rate of requests is below threshold)
Chow et al (US 2016/0094611 A1) (Abstract: In an approach to managing requests to a high utilization website, one or more computer processors receive a first resource usage load status from a first server computer. The one or more computer processors receive a request for content on the first server computer from a client. The one or more computer processors determine whether the first resource usage load is above a pre-defined threshold. Responsive to determining the first resource usage load is above the pre-defined threshold, the one or more computer processors create a queue of a plurality of content requesters, wherein the client is one of the plurality of content requesters. [0014] Web request queue program 106 manages requests for web content from users to a high utilization website.. [0020] - [0022]; [0024]-[0025]. [0030])
Meaney et al (US 20180260290 A1)( Abstract: A computer-implemented failure monitoring system and method are used with at least one server and with a plurality of resource servers. The system includes a computer storage device that stores one or more failure parameters indicative of one or more failure conditions. The system further includes one or more computer processors that include a monitoring component, an analysis component, and a throttling component. The monitoring component obtains information regarding service requests transmitted by the at least one server for which corresponding responses have not been timely received. The analysis component compares the information to the one or more failure parameters and determines whether at least one failure condition exists. The throttling component selectively inhibits transmission of service requests corresponding to the at least one failure condition while the at least one failure condition exists [0007]. [0011] The services provided by a resource provider system can be collectively referred to as “backend services,” and may be implemented … by one or more resource servers of the resource provider system with a specified computational capacity [0033]; [0037])
Raleigh et al (US 2017/0078922 A1)( Abstract: A wireless communication device comprising: one or more network modems enabling the wireless communication device to communicate over a first wireless network; one or more network modems enabling the wireless communication device to communicate with two or more end-point devices over a second wireless network; one or more processors configured to execute one or more instructions; and memory coupled to the one or more processors and configured to provide the one or more processors with the one or more instructions. The one or more instructions, when executed by the processors, cause processors to: establish a first connection between the wireless communication device and a first end-point device; establish a second connection between the wireless communication device and a second end-point device; apply a first control to traffic transmitted by or to the first end-point device; and apply a second control to traffic transmitted by or to the second end-point device. [0263] “…implementing traffic control for network capacity controlled services is provided by intercepting stack API level or application messaging layer requests (e.g., socket open/send requests) … an intercepted request can be copied (e.g., to memory) and queued (e.g., delayed or throttled) [0336] )
Guim Bernat et al (US 2021/0144517 A1)(Abstract: Various aspects of methods, systems, and use cases for multi-entity (e.g., multi-tenant) edge computing deployments are disclosed. Among other examples, various configurations and features enable the management of resources … and service management (e.g., orchestration, connectivity, workload coordination), in edge computing deployments, such as by a plurality of edge nodes of an edge computing environment configured for executing workloads from among multiple tenants.
[0955] The gateway 5405 includes telemetry circuitry. The telemetry circuitry is configured to track the execution of the services …the telemetry circuitry is configured to implement a telemetry model. This model accepts the telemetry data as input and detects or predicts service degradation due to, for example, the number of requests being received by the gateway 5405.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT A SHAW whose telephone number is (571)270-5643. The examiner can normally be reached Monday – Friday 1pm – 5pm.
Examiner interviews are available via telephone, 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, Emmanuel Moise can be reached on (571)272-3865. 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.
/ROBERT A SHAW/Examiner, Art Unit 2455
/EMMANUEL L MOISE/Supervisory Patent Examiner, Art Unit 2455
Prosecution Insights