DETAILED ACTION
This action is in response to communications: Amendment filed May 7, 2026.
Claims 1-4, 7, 8, 21-34 are pending in this case. Claims 1, 21, 22, 28, 29, and 34 have been newly amended. Claims 5, 6, and 9-20 were previously cancelled. No claims have been newly added or cancelled. This action is made FINAL.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 22, and 29 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 1, 22, and 29 have been amended to similarly recite, “…wherein the actions include a render resolution relating to the 3D rendering or a pre-processing resolution relating to the first frame.” However, the specification does not specifically disclose “the actions” include a render resolution relating to the 3D rendering or a pre-processing resolution relating to the first frame, rather “the configuration parameters” include a render resolution relating to the 3D rendering or a pre-processing resolution relating to the first frame (see at least [0390], [0391], [0395], [0431], [0460], [0471], [0480], [0489]). Therefore, the amendment is considered new matter.
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.
Claim(s) 1-4, 21-25, and 28-32 is/are rejected under 35 U.S.C. 103 as being unpatentable over SCHLUESSLER et al. (US 2016/0364827) in view of Ning Chen et al., VCMaker: Content-Aware Configuration Adaptation For Video Streaming and Analysis In Live Augmented Reality, Computer Networks, Volume 200, October 14, 2021 (available online), pp. 1-11.
As to claim 1, SCHLUESSLER et al. disclose a computing device (Figure 13, computing device 1300, further illustrated in Figure 14) comprising: processing circuitry to (e.g. central processing unit (CPU) 1312 and/or graphics processing unit (GPU) 1314 with driver logic 1316 to execute method 1500 of Figure 15): collect, via a hardware tuner coupled to the processing circuitry (runtime metrics-based workload management mechanism 1310 coupled to CPU 1312 and GPU 1314), status of the device during runtime for a first frame (e.g. collect metrics during execution of a draw execution, e.g. during runtime of drawing a frame)(step 1501, [0156] notes application/workload issuing a draw/work unit or rendering operation to graphics driver, where the draw is detected by reception/detection logic 1401 of runtime metrics-based workload management mechanism 1310, where [0139] notes reception/detection logic 1401 may be used to detect, in runtime, each draw of each frame relating to an application that is being processed or running at computing device 1300; step 1503, [0156] notes metrics collector 1403 (of runtime metrics-based workload management mechanism 1310) identifies metrics relating to the draw along with checking a database to access and identify any metrics already stored at the database, step 1505, [0156] notes metric collector 1403 further collects the identified metrics during the execution of the draw); determine configuration parameters based on the status (e.g. determine a configuration plan, e.g. including configuration parameters, based on the collected metrics)(step 1507, [0157] notes evaluation logic 1405 and configuration manager 1407 (of runtime metrics-based workload management mechanism 1310) may evaluate the metrics relating to the draw and prepare an optimal configuration plan for the same or similar subsequent draws, respectively, and further, a determination is made as to whether to proceed with the optimal configuration plan or disregard any configuration plans due to, e.g. insufficient metrics or unknown optimal configuration plan), the configuration parameters relating to one or more of three-dimensional (3D) rendering, pre-processing, or video encoding of a graphics pipeline associated with the processing circuitry (e.g. configuration plan with configuration parameters relating to various rendering and processing, further described below, of a graphics pipeline of GPU 1314)([0146] notes any number of configuration parameters may be taken into configuration by evaluation logic 1405 and/or configuration manager 1407 in setting up appropriate, efficient, and feasible optimal configuration plans, where such configuration parameters may include (without limitation): 1) whether shader constraints are pre-loaded or read by the GPU from memory at runtime; 2) types of and frequencies at which certain hardware/firmware/software components (e.g., GPU, GPU slice, GPU fixed function, CPU, DDR devices, etc.) are access and used; 3) cache partitioning (e.g., statically allocating certain portions of a cache to certain resource types; 4) type and amount of cached accessed and used; 5) whether to resolve depth surfaces at sample time; 6) type of compression format to use for data; 7) whether to unroll loops in shaders; and 8) dispatch width needed to execute a shader on the GPU, and/or the like, where [0120] and [0121] notes a graphics pipeline may be implemented in GPU 1314, as similarly described in at least Figures 3 and 8); and tune the graphics pipeline with the configuration parameters for processing a second frame (e.g. “tune” GPU 1314, implementing the graphics pipeline, with the configuration plan, including the configuration parameters, for execution of subsequent draws, e.g. processing a future frame)(step 1511, [0158] notes if the optimal configuration plan is valid and applicable, it is selected and set up by configuration manager 1407 to be the plan for this particular draw and any same or similar draws that are detected in the future, step 1513, [0158] notes this optimal configuration plan is applied and executed for one or more of the same or similar subsequent draws as they are executed and issued to the GPU as facilitated by execution/application logic 1409 (of runtime metrics-based workload management mechanism 1310)).
As noted above, SCHLUESSLER et al. describes “tuning” its graphics processing unit (GPU) with the configuration plan, comprising the configuration parameters for executing a draw, e.g. for future subsequent frames. Also noted above, SCHLUESSLER et al. describes its GPU may implement one or more graphics pipelines, e.g. Figure 3 illustrates at least 3D pipeline 312 and media pipeline 316. Therefore, it is considered that the one or more graphics pipelines may be further “tuned” since these may be implemented (or encompassed therein) the GPU, thus yielding predictable results, without changing the scope of the invention. Additionally, SCHLUESSLER et al. do not disclose “…wherein the status indicates latency of a streaming service relating to the first frame…wherein the configuration parameters are determined based on actions selected by a reinforcement learning (RL) model to maximize a reward, and wherein the actions include a render resolution relating to the 3D rendering or a pre-processing resolution relating to the first frame.”
Ning Chen et al. disclose wherein the status indicates latency of a streaming service relating to the first frame (e.g. page 3, second 2.2. Latency-accuracy-energy tradeoff notes latency results from the data transmission and image inference, where page 4, section 3.2 Dynamic RoI encoding notes adopting Dynamic RoI Encoding technique to reduce the data transmission latency while keeping a satisfied object detection accuracy, and pages 5 and 6, section 4.2.3 Reward notes end-to-end latency of a frame)…wherein the configuration parameters (configurations, e.g. frames per second (fps) and resolution) are determined based on actions (e.g. determined based on actions) selected by a reinforcement learning (RL) model (e.g. selected by a deep reinforcement learning (RL) agent) to maximize a reward (e.g. to maximize a reward)(page 5, section 4.2.1 Action space notes VCMaker adaptively chooses a configuration (e.g. fps and resolution) for transmission and detection, where deep reinforcement learning (DRL)-agent selects an action a based on the policy πθ (s,a) which is defined as a probability distribution over the action space, and then gets an instant reward, pages 5-6 section 4.2.3. Reward notes VCMaker is likely to get an instant reward rt when receiving at to state st, where page 6, section 4.3. Training methodology of VCMaker, first paragraph further notes DRL aims to maximize the accumulated discounted reward through training a best policy mapping a state to each action), and wherein the actions include a render resolution relating to the 3D rendering or a pre-processing resolution relating to the first frame (e.g. as noted above, page 5, section 4.2.1. Action space notes VCMaker adaptively chooses a configuration (e.g. fps and resolution) for transmission and detection, hence the components of configuration make up the action).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify SCHLUESSLER et al.’s system and method of tuning a pipeline with Ning Chen et al.’s method of selecting configurations using reinforcement learning to further enhance the process of tuning a graphics pipeline more efficiently (see at least pages 1-2, section 1. “Introduction” and page 5, section 4.1. “Basic learning mechanism” of Ning Chen et al.).
As to claim 2, SCHLUESSLER et al. modified with Ning Chen et al. disclose the processing circuitry to facilitate the hardware tuner to: train the RL model including one or more of states, the actions, or rewards (Ning Chen, page 5, section 4. “Learning-based algorithm design,” further section 4.1 “Basic learning mechanism” notes deep reinforcement learning (DRL), e.g. a RL agent, for continuously interacting with the environment and adjusting the policy based on feedback resulting reward; page 5, section 4.2.1 “Action space” notes “actions;” page 5, section 4.2.2. “State space” notes “states;” and pages 5 and 6, section 4.2.3 “Reward” notes “rewards”); and determine the configuration parameters based on the actions relating to the RL model with a maximum reward (Ning Chen, page 6, section 4.3. Training methodology of VCMaker, first paragraph notes DRL aims to maximize the accumulated discounted reward through training a best policy mapping a state to each action).
As to claim 3, SCHLUESSLER et al. modified with Ning Chen et al. disclose the processing circuitry to facilitate the hardware tuner to: determine states for the RL model based on the status (modified with Ning Chen, page 5, section 4.2.2. “State space,” second paragraph notes number of referenced configurations used in VCMaker, which depends on video content, the feedback performance and network status, third paragraph notes selecting an optimal configuration that best match the available network, fourth paragraph notes assigning a high fps when capturing fast-moving objects and a low fps for slow-moving objects); generate actions for the RL model based on the states relating to the RL model (modified with Ning Chen, page 5, section 4.2.1 “Action space” notes for a newly received state, the DRL agent selects an action based on the policy which is defined as the probability distribution over the action space, and then gets an instant reward); and determine rewards for the RL model based on user experience metrics relating to the actions, wherein the user experience metrics comprise end-to-end latency or end quality (modified with Ning Chen, pages 5 and 6, section 4.2.3 “Reward,” e.g. first paragraph notes VCMaker is likely to get an instant reward when receiving action to state, e.g. second paragraph notes modeling the end-to-end latency).
As to claim 4, SCHLUESSLER et al. modified with Ning Chen et al. disclose the processing circuitry to facilitate the hardware tuner to calculate the end-to-end latency as one or more of a sum of time spent on a 3D rendering for the first frame or the second frame, a latency of streaming service relating to the first frame or the second frame, or downlink network transmission time (SCHLUESSLER, as noted in claim 1, runtime metrics-based workload management mechanism 1310 collects metrics relating to the draw, e.g. for drawing a frame, where [0140] notes metrics may refer to or include various characteristics relating to the draw, such as any information that indicates where the draw suffers from bottlenecking during its processing in terms of using various resources, such as time, cache, hardware components, etc.; modified with Ning Chen, pages 5 and 6, section 4.2.3 “Reward,” e.g. second paragraph notes modeling the end-to-end latency, illustrated as an equation of sum of time, which includes the end-to-end latency of a frame f, which is determined by three main components (1) dfstream is the time to stream frame f from the AR device to the edge server; (2) dfinfer represents the time to run the object detection inference on frame f on the edge server; (3) dfback indicates the time to transmit the detection results back to the AR device), wherein the processing circuitry to facilitate the hardware tuner to determine the end quality based on a relationship between the end quality and encode quality (modified with Ning Chen, pages 5 and 6, section 4.2.3 “Reward,” e.g. second paragraph notes image encoding and transfer process adds significant latency, where long latencies may reduce the detection accuracy and further degrade the user’s QoE, thus it is taken as a component of the tuned reward, further modeling the end-to-end latency as noted above).
As to claim 21, SCHLUESSLER et al. modified with Ning Chen et al. disclose the processing circuitry (SCHLUESSLER, e.g. CPU 1312 and/or GPU 1314) is coupled to a memory (SCHLUESSLER, e.g. memory 1308)([0122] thru [0125]), the processing circuitry comprises graphics processing circuitry (SCHLUESSLER, GPU 1314) or application processing circuitry (SCHLUESSLER, CPU 1312).
As to claim 22, SCHLUESSLER et al. modified with Ning Chen et al. disclose a method (SCHLUESSLER, Figure 15, method 1500) comprising the steps as performed by the computing device (SCHLUESSLER, Figure 13, further illustrated in Figure 14) of claim 1. Please see the rejection and rationale for claim 1 above.
Claims 23-25 are similar in scope to claims 2-4, respectively, and are therefore rejected under similar rationale.
Claim 28 is similar in scope to claim 21, and is therefore rejected under similar rationale.
As to claim 29, SCHLUESSLER et al. modified with Ning Chen et al. disclose at least one non-transitory computer-readable medium (SCHLUESSLER, Figure 13, memory 1308) having stored thereon instructions (SCHLUESSLER, e.g. storing software program, [0124]) which, when executed, cause a computing device (SCHLUESSLER, e.g. computing device 1300, further illustrated in Figure 14) to perform operations comprising the operations (SCHLUESSLER, Figure 15, method 1500) as performed by the computing device (SCHLUESSLER, computing device 1300)( SCHLUESSLER, [0110] notes one or more aspects of at least one embodiment may be implemented by representative code stored on a machine-readable medium which represents and/or defines logic within an integrated circuit such as a processor, e.g. the machine-readable medium may include instructions which represent various logic within the processor, and when read by a machine, the instructions may cause the machine to fabricate the logic to perform the techniques described herein) of claim 1. Please see the rejection and rationale for claim 1 above.
Claims 30-32 are similar in scope to claims 2-4, respectively, and are therefore rejected under similar rationale.
Claim(s) 7, 8, 26, 27, 33, and 34 is/are rejected under 35 U.S.C. 103 as being unpatentable over SCHLUESSLER et al. (US 2016/0364827) in view of Ning Chen et al., VCMaker: Content-Aware Configuration Adaptation For Video Streaming and Analysis In Live Augmented Reality, Computer Networks, Volume 200, October 14, 2021 (available online), pp. 1-11 as applied to claims 2, 22, and 29 above, and further in view of Sandeepa Bhuyan et al., End-to-end Characterization of Game Streaming Applications on Mobile Platforms, Proceedings of the ACM on Measurement and Analysis of Computing Systems, Volume 6, Issue 1, Article No. 10, March 2022, pp. 10:1-10:25.
As to claim 7, SCHLUESSLER et al. modified with Ning Chen et al. disclose the processing circuitry to facilitate the hardware tuner to apply a double-Q learning method or an asynchronous advantage actor-critic (A3C) based model (modified with Ning Chen, pages 6 and 7, section 4.3. “Training methodology of VCMaker” notes VCMaker takes good use of the A3C algorithm consisting of the Actor-Critic networks that continually train with policy gradient method, which calculates the gradient of the accumulated reward obtained by following current trained policy), wherein the hardware tuner is further to: collect the latency of streaming service for the first frame from the graphics pipeline; and collect engine utilizations from processing resources implementing the graphics pipeline (SCHLUESSLER, as noted in claim 1, runtime metrics-based workload management mechanism 1310 collects metrics relating to the draw, e.g. for drawing a frame, along with checking a database to access and identify any metrics already stored at the database, the metrics collected of a GPU 1314 implementing a graphics pipeline, where [0140] notes metrics may refer to or include various characteristics relating to the draw, such as any information that indicates where the draw suffers from bottlenecking during its processing in terms of using various resources, such as time, cache, hardware components, etc., and thus configurable device characteristics may include (without limitation): cache size, cache policies, frequencies, sleep state, etc., e.g. such metrics, as collected by metrics collector 1405, may include (without limitation) 1) types of and frequencies at which various hardware components (e.g., CPU, GPU, GPU slice, GPU fixed function, double data rate (DDR) device, etc.) were used, 2) how much shading work it did in reading texture in terms of lighting computation is performed (such as, in some cases, there may be a great deal of computation work to figure out the lighting, but the work involved in reading of the actual texture value may be a small part of the process which may mean, upon evaluation by evaluation logic 1405, shutting down part of the chip because samplers, textures, etc., are not needed and just the computation is needed for the same or similar draw when it appears later in the process, 3) cache amount and policies, cache partitioning/distribution, 4) type of compression format applied, 5) whether depth surfaces were resolved at sample time, and/or the like; modified with Ning Chen, pages 2 and 3, section 2. “Observations and Challenges,” further under section 2.1.1. “Fluctuation in network bandwidth,” e.g. first paragraph notes collecting two ATT-LTE network bandwidth traces from the Mahimahi [22] project, e.g. illustrated in Figure 1, where these traces represent the time-varying capacity of U.S. cellular networks as experienced by a mobile user; page 3, section 2.2. “Latency-accuracy-energy tradeoff,” e.g. first paragraph notes connecting a Nvidia Jetson TX2 to an edge server equipped with RTX2080 Ti GPU through WiFi 2.4 GHz, and streaming videos with diverse configurations from the Jetson to the edge server for inference, and using Python power monitor library to collect the energy information; page 3, section 2.3. “Excessive energy consumption of AR applications,” e.g. first paragraph notes the results from an AR testbed in [23] shows that if continuously transmitting the latest videos captured from a camera to a nearby edge server for object detection, a 3000mAh battery of a mobile device (e.g. a smartphone) is likely to be exhausted within about 2.3 hours, and over 60% if the energy is consumed by the pre-process), but do not disclose, but Sandeepa Bhuyan et al. disclose wherein the hardware tuner is further to: collect encode Peak Signal to Noise Ratio (PSNR), where Sandeepa Bhuyan et al. further disclose collect the latency of streaming service for the first frame from the graphics pipeline (Sandeepa Bhuyan, e.g. pages 10:9 thru 10:19, section 4 “Characterizing Cloud Gaming Through Parameter Setting,” e.g. first paragraph notes performing a thorough parameter sweep to investigate the inefficiencies in the current cloud gaming pipeline, including frame rate (in Sec. 4.1.1)(which further describes how frame rate varies with different configurations of encoding, rendering, network connection, and decoding), image quality (in Sec. 4.1.2)(which further describes the Peak signal-to noise ratio (PSNR), which is one of the most important metrics for quantifying the image quality with different graphics settings, encoding qualities/speeds and resolutions across various games), power and energy efficiency with respect to the network type (in Sec. 4.2.1), bitrate (in Sec. 4.2.2) and various games (in Sec. 4.2.3)); and collect engine utilizations from processing resources implementing the graphics pipeline (Sandeepa Bhuyan, e.g. pages 10:9 thru 10:19, section 4 “Characterizing Cloud Gaming Through Parameter Setting,” e.g. first paragraph notes performing a thorough parameter sweep to investigate the inefficiencies in the current cloud gaming pipeline, including frame rate (in Sec. 4.1.1), image quality (in Sec. 4.1.2), power and energy efficiency with respect to the network type (in Sec. 4.2.1), bitrate (in Sec. 4.2.2) and various games (in Sec. 4.2.3); page 10:19, section 5 “Discussion,” Figure 19, notes the edge device condition-aware scheme under which the client transmits the user preference, battery percentage, network conditions and frame drop statistics to the server during a gameplay as shown in Figure 19).
It would have been obvious to one of ordinary skill in the art at the time of the invention to further modify SCHLUESSLER et al. modified with Ning Chen et al.’s method of collecting metrics, including latency and engine utilizations, to further incorporate collecting additional metrics, including Peak Signal to Noise Ratio (PSNR), as described in Sandeepa Bhuyan et al. to further optimize and enhance power and performance of a graphics pipeline (e.g. implemented in a graphics processing unit) of the system (see at least abstract of Sandeepa Bhuyan et al.).
Claims 26 and 33 are similar in scope to claim 7 above, and are rejected under similar rationale.
As to claim 8, SCHLUESSLER et al. modified with Ning Chen et al. disclose configuration parameters associated with the 3D rendering, pre-processing, and video encoding (as noted in claim 1 above), but do not disclose, but Sandeepa Bhuyan et al. disclose the configuration parameter associated with the 3D rendering includes render resolution relating to the 3D rendering (page 10:19, section 5 “Discussion,” Figure 19, notes determining configuration parameters including frame rendering quality, encoding bitrate, frame resolution, and network connection of the graphics pipeline based on collected statistics noted in claim 1 above, where pipeline illustrates game engine, frame rendering (may be considered three-dimensional rendering), frame encoding (video encoding), frame decoding, and display, where prior to network may be considered pre-processing); the configuration parameter associated with the pre-processing includes one or more of a resolution of a frame after the pre-processing, an indication of on/off of video enhancement, or an indication of a scaling method (e.g. prior to network illustrated in pipeline considered as pre-processing, as noted above, configuration parameters including frame resolution); and the configuration parameter associated with the video encoding includes one or more of a normalized encode bitrate or a maximum allowable encode pass number (e.g. for frame encoding, as noted above, configuration parameters including encoding bitrate).
It would have been obvious to one of ordinary skill in the art at the time of the invention to further modify SCHLUESSLER et al. modified with Ning Chen et al.’s configuration parameters to further incorporate the configuration parameters as described in Sandeepa Bhuyan et al. to further optimize and enhance power and performance of a graphics pipeline (e.g. implemented in a graphics processing unit) of the system (see at least abstract of Sandeepa Bhuyan et al.).
Claim 27 is similar in scope to claim 8, and is therefore rejected under similar rationale.
Claim 34 is similar to claims 8 and 21 combined, and is therefore rejected under similar rationale.
Response to Arguments
Applicant's arguments filed May 7, 2026 have been fully considered but they are not persuasive. Applicant amends independent claims 1, 22, and 29 to similarly recite, “…wherein the status indicates latency of a streaming service relating to the first frame…and wherein the actions include a render resolution relating to the 3D rendering or a pre-processing resolution relating to the first frame.” Applicant argues on pages 10-12 of the Amendment filed that the prior art of record fails to teach or suggest, singly or combined, the limitations of the claims as now amended.
In reply, in light of the amendments of independent claims 1, 22, and 29, the rejection has been modified, where SCHLUESSLER et al. in view of Ning Chen et al are still believed to teach the limitations as amended. Please see the rejection and notes regarding the claims above for details.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACINTA M CRAWFORD whose telephone number is (571)270-1539. The examiner can normally be reached 8:30a.m. to 4:30p.m.
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, King Y. Poon can be reached at (571)272-7440. 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.
/JACINTA M CRAWFORD/Primary Examiner, Art Unit 2617
Prosecution Insights