DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/20/2026 has been entered.
Status of Claims
The present application is being examined under the claims filed 02/20/2026. Claims 13 and 21 have been canceled. Claims 1, 5, 8, 12, and 15 are amended. Claim 22 is new. Claims 1-12, 14-20, and 22 are pending. Claims 1-12, 14-20, and 22 are rejected.
Response to Arguments
I. Applicant’s arguments filed 02/20/2026 have been fully considered but they are not persuasive.
II. Regarding claim 1, applicant argues the applied references, alone or in combination, do not disclose "being programmable to execute respective sets of instruction sequences for a respective power block in order to effectuate power state transitions for one or more devices in the respective power block, the instruction sequences comprising at least one of a plurality of different categories of custom instructions that, when executed by the local power manager, perform a sequence of logic operations to effectuate the power state transitions" as recited in amended independent claim 1. Examiner respectfully disagrees.
Brinks teaches the computing device being programmable (Brinks par. 61, power management policies [executed by the local domain controllers, see par. 62] are programmable at runtime) to execute respective sets of instruction sequences for a respective power block in order to effectuate power state transitions for one or more devices in the respective power block (Brinks par. 58, a policy manager 502 may choose from one or more power management policies 504, which each map operating states to operating points 506 [i.e., instructions for power state transitions; also see par. 48, power management policy will decide when and how the system transitions from one operating point to another]; and FIG. 5 and par. 62, the power manager may further includes a policy execution engine 510 to execute a power management policy), the instruction sequences comprising at least one of a plurality of different categories of custom instructions that, when executed by the local power manager, perform a sequence of logic operations to effectuate the power state transitions (Brinks par. 22, the power manager may have its own dedicated CPU or dedicated state machine to execute power management instructions so that the power manager may control the power consumption of two or more domains; and Brinks par. 68, a clock or power domain will have values for the controlling elements of the power and clock distribution networks that it drives… a set of domain controller functions may allow control over the power state of the domain and transitions between states [i.e., a plurality of different categories of custom instructions]… the power management policy will interact with the domain controller through calls to these functions [i.e., logical operations to effectuate the power state transitions). Therefore, Brinks teaches the limitation of amended claim 1.
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-3, 5-10, 12, 14-17, and 19-22 are rejected under 35 U.S.C. 103 as being unpatentable over Brinks et. al. (US 2012/0054511 A1) [previously cited] in view of Kiss et. al. (US 2021/0255690 A1) [previously cited] and Arm Limited “Arm CoreLink PCK-600 Power Control Kit” [previously cited].
Regarding Claim 1, Brinks discloses a computing device (Brinks FIG. 3, exemplary SOC [also see par. 43]) comprising:
multiple devices arranged in multiple power blocks (Brinks par. 28, components in SoC constitute multiple devices [see instant app. par. 14]; and Brinks FIG. 3 and par. 43, components on SOC are partitioned into domains [i.e., power blocks], also see par. 28), wherein each device of the multiple devices belongs to one of the multiple power blocks (Brinks FIG. 3 and par. 43-44, each component in the SoC is a member of a domain that share voltage and/or clock signals); and
multiple local power managers (Brinks FIG. 5 and par. 58, each domain has a local domain controller 508 [i.e., local power manager]), each local power manager:
being programmable (Brinks par. 61, power management policies [executed by the local domain controllers, see par. 62] are programmable at runtime) to execute respective sets of instruction sequences for a respective power block in order to effectuate power state transitions for one or more devices in the respective power block (Brinks par. 58, a policy manager 502 may choose from one or more power management policies 504, which each map operating states to operating points 506 [i.e., instructions for power state transitions; also see par. 48, power management policy will decide when and how the system transitions from one operating point to another]; and FIG. 5 and par. 62, the power manager may further includes a policy execution engine 510 to execute a power management policy), the instruction sequences comprising at least one of a plurality of different categories of custom instructions that, when executed by the local power manager, perform a sequence of logic operations to effectuate the power state transitions (Brinks par. 22, the power manager may have its own dedicated CPU or dedicated state machine to execute power management instructions so that the power manager may control the power consumption of two or more domains; and Brinks par. 68, a clock or power domain will have values for the controlling elements of the power and clock distribution networks that it drives… a set of domain controller functions may allow control over the power state of the domain and transitions between states [i.e., a plurality of different categories of custom instructions]… the power management policy will interact with the domain controller through calls to these functions [i.e., logical operations to effectuate the power state transitions); and
[accessing] a programmable memory storing the respective sets of instruction sequences (Brinks FIG. 5 and par. 59, each domain controller receives the operating points for its domain, determined by the power management policy [policy information is stored in the memory of the power manager and can be accessed by other system components, see par. 41]; and par. 48, power management policy will decide when and how the system transitions from one operating point to another [i.e., instruction sequence]; and par. 61, management policies can be programmed at runtime).
Brinks does not explicitly teach:
each local power manager comprising a programmable memory storing the respective sets of instruction sequences.
In the analogous art of controlling power mode transitions of multiple devices arranged into power blocks, Kiss teaches multiple local power managers (Kiss FIG. 1 and par. 51, the power controllers 15, 25, 35, 45, 55 [i.e., local power managers] are used to control the supply of power to their associated power domains 10, 20, 30, 40, 50 [i.e., power blocks]), each local power manager:
[“may take the form of Power Policy Units (PPUs) developed by Arm Limited, Cambridge, United Kingdom”] (Kiss par. 48).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Brinks and Kiss, before the effective filing date of the claimed invention, to combine Brinks’ power management solution for multiple devices arranged in multiple power blocks with Kiss’s utilization of an existing local power manager, the motivation being to provide an efficient mechanism for power controllers to control the power modes of their associated power domains within a policy, while allowing power controllers to operate independently (Kiss par. 3-4).
Brinks nor Kiss explicitly teach each local power manager comprising a programmable memory storing the respective sets of instruction sequences.
In analogous art of power domain management, Arm Limited documentation discloses Power Policy Units (PPUs):
being programmable (Arm Limited sec. 3.2 pg. 43, power policy [i.e., instruction sequence] is stored in register 0x000 and can be written to [i.e., programmable memory, note type is RW (read/write)]) to execute respective sets of instruction sequences for a respective power block in order to effectuate power state transitions for one or more devices in the respective power block (Arm Limited sec. 2.6 pg. 35, the PPU uses power modes, such as on (ON), off (OFF), and full retention (FULL_RET), to represent the various power conditions of a domain [i.e., power block], PPU can autonomously change mode [i.e., execute instructions] using a dynamic policy; also see sec. 3.2 pg. 43-44, registers storing instructions to effectuate power state transitions); and
comprising a programmable memory storing the respective sets of instruction sequences (Arm Limited sec. 3.2 pg. 43, power policy [i.e., instruction sequence] is stored in register 0x000 [i.e., memory] and can be written to [i.e., programmable memory, note type is RW (read/write)]);
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Brinks, Kiss, and Arm Limited before him, before the effective filing date of the claimed invention, to modify Kiss’ local domain managers with the PPU domain managers comprising onboard programmable memory as taught Arm Limited. Using the known technique of storing the registers with the memory on the PPU provides the predictable result of having a PPU architecture comprising registers and memory in Kiss, and would yield the described behavior in Kiss of each local domain manager being able to control power mode transitions (Kiss par. 83-84). It would have been obvious to a person having ordinary skill in the art, since a person having ordinary skill in the art would recognize that Kiss was ready for improvement, to incorporate the PPU comprising a programmable memory storing the respective sets of instruction sequences as taught by Arm Limited.
Regarding Claim 2, Brinks in view of Kiss and Arm Limited disclose the computing device of claim 1. Brinks in view of Kiss and Arm Limited further discloses wherein each local power manager further comprises:
trigger logic configured to receive event signal inputs and output trigger signals (Brinks par. 38, individual domain controllers can transition one or more components they are monitoring and controlling in an appropriate domain into and out of the desired power consuming mode [this operation would require input signals for the desired power consuming mode and output signals to transition the components]; and par. 59, domain controller 508 receives operating point 506 and output a signal to the component to transition the components to a desired mode; or Arm Limited pg. 35 Figure 2-8, illustrating inputs and outputs used to signal state transitions [i.e. trigger signals, also see Appendix A.6 detailing PPU signals]);
a power state table configured to store a mapping between trigger signals and power state transitions (Brinks par. 23, power manager provides policies in a policy matrix of which components can be turned off during different chip modes [i.e., table of policies and transitions between policies]; or Kiss FIG. 13 and par. 90-93, power controllers [i.e., local power managers] determine if they receive a power mode transition request [i.e., trigger signal], and a desired power mode for the associated power domain is determined based on power mode constraining information or power mode requests received [i.e., mapping for power state transition], also see FIG. 11, table of transitions in power modes, and the steps taken to achieve those power mode transitions); and
one or more hardware sequencers configured to execute respective instruction sequences when a power state transition is triggered by the trigger logic (Brinks par. 65, domain controllers [i.e., local power managers] are responsible for operations related to transitions between states, including enforcement of low-level inter-domain dependencies, like specific order for domains wake-ups, complex transitions sequences).
Regarding Claim 3, Brinks in view of Kiss and Arm Limited disclose the computing device of claim 2. Brinks in view of Kiss and Arm Limited further discloses:
wherein the power state table, the trigger logic, and the instruction sequences are stored on the programmable memory.
[Each limitation is addressed below]
I. Power state table stored on the programmable memory: (Kiss FIG. 13 and par. 90-93, power controllers [i.e., local power managers] determine if they receive a power mode transition request [i.e., trigger signal], and a desired power mode for the associated power domain is determined based on power mode constraining information or power mode requests received [i.e., mapping between trigger signals and power state transitions]; also see Arm Limited pg. 34-35. PPU implements policy mapped to signals sent on the Q-Channel and/or P-Channel [i.e., mapping between trigger signals and power state transitions stored on the PPU programmable memory]).
II. Trigger logic stored on the programmable memory: (Arm Limited pg. 66 Table A-32, signals which a PPU uses to issues a power mode changes with the Power Control State Machine [i.e., trigger logic stored on the PPU programmable memory; also see pg. 34, PPU takes a software-programmed power domain policy and then controls the low-level hardware control signals]).
III. Instruction sequences stored on the programmable memory: (Brinks par. 65, domain controllers [i.e., local power managers] are responsible for operations related to transitions between states, including complex transitions sequences [i.e., domain controllers store instruction sequences for the power state transition]; or Kiss FIG. 11, table of transitions in power modes, and the steps taken to achieve those power mode transition, and par. 84, PPU [i.e., local controller] can manage the transitions of power modes [i.e., PPU stores the table because it can independently manage the transitions, see Arm Limited pg. 43, Power Mode Transition Configuration Register 0x024 stored on the PPU programmable memory]).
Regarding Claim 5, Brinks in view of Kiss and Arm Limited disclose the computing device of claim 2. Brinks in view of Kiss and Arm Limited further discloses:
wherein the instruction sequences further comprise instructions having one or more operands that represent values of event signal inputs received by the trigger logic, wherein the event signal inputs control the power state transitions (Brinks par. 140, signals sent on wires such as “power_down_req”, “power_down_ok” and “active” [i.e., power state is transitioned based on the event signal on the wire]; and par. 55, SoC domain state expressed by the (F, V) double [i.e., operands that represent value of the mode to change to [i.e., event signal]] is sent to domain controller]).
Regarding Claim 6, Brinks in view of Kiss and Arm Limited disclose the computing device of claim 2. Brinks in view of Kiss and Arm Limited further discloses:
wherein each local power manager is configured to execute conditional instructions (Brinks par. 127, power manager logic may be control-oriented, state machine execution, with efficient evaluation of state transitions conditions; also see par. 58, domain controllers [i.e., local power managers] enforce the policy selected by the power manager) but lacks hardware to perform arithmetic operations (Brinks par. 58, a policy manager 502 may choose from one or more power management policies 504, which each map operating states to operating points 506, and then a local domain controller 508 enforces the operating points [operations are not performed on the local domain controllers, which simply enforce policy calculated by the policy manager]).
Regarding Claim 7, Brinks in view of Kiss and Arm Limited disclose the computing device of claim 2. Brinks in view of Kiss and Arm Limited further discloses:
wherein each local power manager is configured to execute transition sequences for multiple power state tables of multiple respective devices (Brinks par. 62, domain controller 508 [i.e., local power manager] transitions a selected domain from its current state to a new state as indicated by the operating point mapped from the selected power management policy [see par. 23, power state policies may be stored as tables]; and par. 66, domain controllers control each component [i.e., device] of the domain).
Regarding Claim 8, Brinks discloses a computer implemented method, comprising a computer implemented method (Brinks FIG. 3, method occurs on exemplary SOC [also see par. 43]), comprising:
monitoring a trigger signal obtained by a local power manager (Brinks par. 58, a policy manager 502 may choose from one or more power management policies 504, which each map operating states to operating points 506, and then a local domain controller 508 [i.e., local power manager] enforces the operating points [the signal with the points must be obtained by the local domain controller to be enforced]; also see Brinks par. 22, the power manager [includes policy manager, see par. 47] may have its own dedicated state machine and evaluates state transitions to instruct domain controllers to change power modes [i.e., issues trigger signals to be received by local power managers]), wherein multiple devices (Brinks par. 28, components in SOC constitute multiple devices [see instant app. par. 14]) in a computing device are arranged in multiple power blocks (Brinks FIG. 3 and par. 43, components on SOC are partitioned into domains [i.e., power blocks], also see par. 28), wherein each device of the multiple devices belongs to one of the multiple power blocks (Brinks FIG. 3 and par. 43-44, each component in the SoC is a member of a domain that share voltage and/or clock signals), wherein each of the multiple local power managers (Brinks FIG. 5 and par. 58, each domain has a local domain controller 508 [i.e., local power manager]) is programmable to execute respective sets of instruction sequences for a respective power block (Brinks par. 61, power management policies [executed by the local domain controllers, see par. 62] are programmable at runtime; and Brinks par. 58, a policy manager 502 may choose from one or more power management policies 504, which each map operating states to operating points 506 [i.e., instructions for power state transitions; also see par. 48, power management policy will decide when and how the system transitions from one operating point to another], wherein the instruction sequences comprise at least one of a plurality of different categories of custom instructions that, when executed by the local power manager, perform a sequence of logic operations to effectuate a power state transitions (Brinks par. 22, the power manager may have its own dedicated CPU or dedicated state machine to execute power management instructions so that the power manager may control the power consumption of two or more domains; and Brinks par. 68, a clock or power domain will have values for the controlling elements of the power and clock distribution networks that it drives… a set of domain controller functions may allow control over the power state of the domain and transitions between states [i.e., a plurality of different categories of custom instructions]… the power management policy will interact with the domain controller through calls to these functions [i.e., logical operations to effectuate the power state transitions), wherein each of the local power managers [access] a programmable memory storing the respective sets of instruction sequences (Brinks FIG. 5 and par. 59, each domain controller receives the operating points for its domain, determined by the power management policy [policy information is stored in the memory of the power manager and can be accessed by other system components, see par. 41]; and par. 48, power management policy will decide when and how the system transitions from one operating point to another [i.e., instruction sequence]; and par. 61, management policies can be programmed into a policy matrix at runtime);
determining whether a trigger signal for a power state transition is received (Brinks par. 22, power manager has state machine to execute power management instructions [i.e., send a trigger signal] so that the power manager may control the power consumption of two or more domains; and FIG. 5 and par. 58, domain controllers receive an operating point [i.e., receive the trigger signal]);
in response to determining that the trigger signal for the power state transition is received, executing an instruction sequence for the power state transition for one or more devices in the respective power block (Brinks FIG. 5 and par. 57, a domain controller receives an operating point [i.e., trigger signal] and is used to execute the received operating point transitions [i.e., executing an instruction sequence for the power state transition for one or more devices]).
Brinks does not explicitly teach:
each local power manager comprising a programmable memory storing the respective sets of instruction sequences.
In the analogous art of controlling power mode transitions of multiple devices arranged into power blocks, Kiss teaches multiple local power managers (Kiss FIG. 1 and par. 51, the power controllers 15, 25, 35, 45, 55 [i.e., local power managers] are used to control the supply of power to their associated power domains 10, 20, 30, 40, 50 [i.e., power blocks]), each local power manager:
[“may take the form of Power Policy Units (PPUs) developed by Arm Limited, Cambridge, United Kingdom”] (Kiss par. 48).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Brinks and Kiss, before the effective filing date of the claimed invention, to combine Brinks’ power management solution for multiple devices arranged in multiple power blocks with Kiss’s utilization of an existing local power manager, the motivation being to provide an efficient mechanism for power controllers to control the power modes of their associated power domains within a policy, while allowing power controllers to operate independently (Kiss par. 3-4).
Brinks nor Kiss explicitly teach each local power manager comprising a programmable memory storing the respective sets of instruction sequences.
In analogous art of power domain management, Arm Limited documentation discloses Power Policy Units (PPUs):
being programmable (Arm Limited sec. 3.2 pg. 43, power policy [i.e., instruction sequence] is stored in register 0x000 and can be written to [i.e., programmable memory, note type is RW (read/write)]) to execute respective sets of instruction sequences for a respective power block in order to effectuate power state transitions for one or more devices in the respective power block (Arm Limited sec. 2.6 pg. 35, the PPU uses power modes, such as on (ON), off (OFF), and full retention (FULL_RET), to represent the various power conditions of a domain [i.e., power block], PPU can autonomously change mode [i.e., execute instructions] using a dynamic policy; also see sec. 3.2 pg. 43-44, registers storing instructions to effectuate power state transitions); and
comprising a programmable memory storing the respective sets of instruction sequences (Arm Limited sec. 3.2 pg. 43, power policy [i.e., instruction sequence] is stored in register 0x000 [i.e., memory] and can be written to [i.e., programmable memory, note type is RW (read/write)]);
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Brinks, Kiss, and Arm Limited before him, before the effective filing date of the claimed invention, to modify Kiss’ local domain managers with the PPU domain managers comprising onboard programmable memory as taught Arm Limited. Using the known technique of storing the registers with the memory on the PPU provides the predictable result of having a PPU architecture comprising registers and memory in Kiss, and would yield the described behavior in Kiss of each local domain manager being able to control power mode transitions (Kiss par. 83-84). It would have been obvious to a person having ordinary skill in the art, since a person having ordinary skill in the art would recognize that Kiss was ready for improvement, to incorporate the PPU comprising a programmable memory storing the respective sets of instruction sequences as taught by Arm Limited.
Regarding Claim 9, the claim is similar in scope to claim 2 as addressed above and is thus rejected under the same rationale.
Regarding Claim 10, the claim is similar in scope to claim 3 as addressed above and is thus rejected under the same rationale.
Regarding Claim 12, the claim is similar in scope to claim 5 as addressed above and is thus rejected under the same rationale.
Regarding Claim 14, the claim is similar in scope to claim 7 as addressed above and is thus rejected under the same rationale.
Regarding Claim 15, Brinks discloses one or more non-transitory storage media encoded with instructions (Brinks par. 153).
The remainder of claim 15 is similar in scope to claim 1 as addressed above and is thus rejected under the same rationale.
Regarding Claim 16, the claim is similar in scope to claim 2 as addressed above and is thus rejected under the same rationale.
Regarding Claim 17, the claim is similar in scope to claim 3 as addressed above and is thus rejected under the same rationale
Regarding Claim 19, the claim is similar in scope to claim 5 as addressed above, reciting wherein “the instructions comprise instructions having one or more operands…” opposed to “the instruction sequences comprise instructions having one or more operands…”. Multiple instructions would be equivalent to an instruction sequence.
The remaining limitations of claim 19 are similar in scope to claim 5 as addressed above and is thus rejected under the same rationale.
Regarding Claim 20, the claim is similar in scope to claim 6 as addressed above and is thus rejected under the same rationale.
Regarding Claim 22, Brinks, Kiss, and Arm Limited discloses the computing device of claim 1, wherein the plurality of different categories of custom instructions comprises:
toggling a general purpose input/output (GPIO) output (Brinks par. 63, selected policy must be executed by policy execution engine 510 using the domain controllers; and Brinks par. 70, supply an operation voltage and clock frequency value as determined by the operating point to each domain [i.e., a general purpose output, see instant app. par. 37, "GPIO 216 output includes the instruction sequence for a power state transition]");
waiting for an input value for a predetermined timeout period (Kiss par. 94, power mode transition request is issued to the connected higher level power controller from the interface IF0, and an acknowledgement is awaited; also see Kiss par. 39-40, power mode transition may be rejected or power controller may wait for the component to complete the task); and
branching to a different address in the instruction sequence based on a value of an input signal (Brinks par. 70, hardware to implement various operating points and locally transition a given domain includes finite state machines [i.e., based on state transition condition [i.e., input signal], change states [i.e., branch to instruction for accomplishing that state]]).
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Brinks in view of Kiss and Arm Limited, further in view of Kutz et. al. (US 2020/0300910 A1) [previously cited].
Regarding Claim 4, Brinks, Kiss, and Arm Limited discloses the computing device of claim 2. Brinks, Kiss, and Arm Limited does not explicitly disclose wherein the hardware sequencer comprises break point and single-step functionality for debugging. Brinks generally discusses the need to preform debugging (Brinks par. 155), and does so using EDA tools. EDA tools often include break point and single-step functionality for debugging.
In the analogous art of controlling individual components in a computing device, Kutz teaches:
programming and debug subsystem main include a variety of interfaces including JTAG, serial wire debug (SWD), and serial wire viewer (SWV) (Kutz par. 285)
break point and single-step functionality for debugging (Kutz par. 287-294, JTAG and SWD interfaces may be used to support debugging using single-step the CPU or multiple program address breakpoints)
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Brinks, Kiss, Arm Limited, and Kutz before them, before the effective filing date of the claimed invention, to combine Brinks, Kiss, and Arm Limited’s use of debugging tools with Kutz’s use of industry standard debugging practices, the motivation being to ensure functionality of the device (Kutz par. 285).
Regarding Claim 11, the claim is similar in scope to claim 4 as addressed above and is thus rejected under the same rationale.
Regarding Claim 18, the claim is similar in scope to claim 4 as addressed above and is thus rejected under the same rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COLE JIAWEI WENTZEL whose telephone number is (703) 756-4762. The examiner can normally be reached 9:30am-5:30pm (Mon-Fri).
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, Andrew Jung can be reached on (571) 270-3779. 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.
/C.J.W./Examiner, Art Unit 2175
/ANDREW J JUNG/Supervisory Patent Examiner, Art Unit 2175
Prosecution Insights