DETAILED ACTION
This Office Action, based on application 18/612,716 filed 21 March 2024, is filed in response to applicant’s amendment and remarks filed 23 December 2025 and supplemental amendment filed 5 January 2026. Claims 1-19 are currently pending and have been fully considered below.
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 .
Response to Arguments
Applicant’s remarks, submitted 23 December 2025 in response to the Office Action mailed 2 October 2025, have been fully considered below.
Drawing Objections
The Office withdraws the objections in response to the replacement drawings filed 23 December 2025 and 5 January 2026.
Claim Rejections under 35 U.S.C. § 103
The applicant traverses the prior art rejection alleging cited prior art does not disclose each feature required by Claim 1. Specifically, the applicant alleges LI does not disclose “wherein the logic is configured, in response to receiving a request to change the value of the semaphore at the first input … if the synchronization mutex is in an acquired state, not to change the value of the semaphore in response to the request, at least while the synchronization mutex remains in the acquired state”. Applicant’s remarks have been fully considered; however, the Office finds applicant’s arguments not persuasive thus maintains the rejection of record. The applicant alleges the following:
The Examiner cites steps 305 and 310 in Figure 3B of Li against the feature of claim 1 that "...the logic is configured, in response to receiving a request to change the value of the semaphore at the first input... if the synchronization mutex is in an acquired state, not to change the value of the semaphore in response to the request, at least while the synchronization mutex remains in the acquired state".
However, steps 305 and 310 occur in response to a request to update the status information. Thus, this behavior of the mutex of Li does not occur "in response to receiving a request to change the value of the semaphore" as required by claim 1.
A change to the value of the semaphore in Li instead only occurs in steps 210 and 215 in Figure 3A, or in step 325 in Figure B. Whether or not these steps are carried out is not contingent on the status of the mutex. There is no disclosure in Li of blocking of access to its semaphore if its mutex is already in an acquired state. Thus, Li does not teach or suggest "if the synchronization mutex is in an acquired state, not to change the value of the semaphore in response to the request, at least while the synchronization mutex remains in the acquired state" required by claim 1 (underlining added).
In response, the Office respectfully notes Fig 3b is directed to a process “for releasing a memory block after the task is executed by the processor” (¶[0034]) and further teaches that “when the semaphore is released, the semaphore value is incremented to reflect that the memory block released by the task is available for other tasks” (¶[0035]). Thus, even if the applicant may characterize Fig 3b’s Steps 305 and 310 as occurring in response to a request to update the status information performed at Step 315 – a position that the Office respectfully disagrees given the description of ¶[0034-0035], the Office asserts such a characterization allows for a characterization that performance of any of the actions (including updating the status) subsequent to Steps 305 and 310 is a request for performing the respective action which would include Steps 315, 320, and particularly 325 which is directed to changing the value of a semaphore. The Office maintains LI teaches the noted limitation since the semaphore is incremented (Fig 3b – Step 325) only after the mutex becomes available (Fig 3b – Step 305 => YES; analogous to ‘if the synchronization mutex is in the unacquired state’).
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.
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.
Claim(s) 1-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over LI (US PGPub 2004/0039884) in further view of TERRELL (US PGPub 2008/0005741) with motivation provided by TANENBAUM (Structured Computer Organization, 6th Edition; Page 8).
With respect to Claim 1, LI discloses an integrated circuit (¶[0013] – “Additionally, throughout this specification, the system memory will be discussed as being accessed and allocated by a processor or microprocessor and it should be understood that the present invention may be implemented in any computing and/or electronic device where processors and/or microprocessors <{e.g. integrated circuit}> perform such functions, for example, PCs, servers, internet devices, embedded devices, or any computing device and the term device will be used to generally describe such devices. The exemplary memory management system of the present invention may be used for any type of device (or system), but may be particularly useful for real-time embedded systems.”) comprising:
a semaphore configured to store a value (¶[0006] – “Furthermore, a system, comprising a semaphore corresponding to a memory pool, the memory pool including memory blocks, a value of the semaphore being equal to a number of free memory blocks in the memory pool”); and
logic for operating the semaphore, wherein the logic comprises:
a synchronization mutex, switchable between any of one or more acquired states and an unacquired state (¶[0035] – “ the task 130 may release <{e.g. ‘unacquired state’}> the mutex 117 so that other tasks that have acquired the semaphore 118 may acquire the mutex 117”); and
a first input for receiving requests to change the value of the semaphore (¶[0020] – “As will be described in greater detail below, a task <{e.g. ‘a first input’}> may acquire a semaphore. Part of the acquisition of the semaphore includes decrementing the semaphore value); and
wherein the logic is configured, in response to receiving a request to change the value of the semaphore at the first input (¶[0020] – “As will be described in greater detail below, a task <{e.g. ‘a first input’}> may acquire a semaphore. Part of the acquisition of the semaphore includes decrementing the semaphore value),
if the synchronization mutex is in the unacquired state (Fig 3B, Step 305 – “Is mutex available?”; => YES):
to switch the synchronization mutex to a first acquired state; then to change the value of the semaphore in response to the request; and then
to switch the synchronization mutex to the unacquired state (Fig 3B, Step 315 – “Acquire mutex and update status” => Step 320 – “Release mutex” => Step 325 – “Release and increment semaphore”; ¶[0035]; ¶[0036] – this section teaches that Steps 320 and 325 may be performed in reverse order enabling “the semaphore value may be incremented and the semaphore may become available sooner for any tasks that are suspended awaiting the semaphore to become available”), and
if the synchronization mutex is in an acquired state (Fig 3B, Step 305 – “Is mutex available?” => NO), not to change the value of the semaphore in response to the request, at least while the synchronization mutex remains in the acquired state (Fig 3B, Step 310 – “Temporarily suspend task”; ¶[0034] – “If the mutex is not available, the process continues to step 310 where the task is temporarily suspended until the mutex 117 becomes available”).
LI may not explicitly disclose wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry.
However, TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
LI and TERRELL are analogous art because they are from the same field of endeavor of controlling access to a common resource. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of LI and TERRELL before him or her, to modify the implementation of the semaphore and related functions of LI to be performed in hardware as taught by TERRELL. A motivation for doing so would have been due to user decisions to put certain functions in hardware and others in software is based on such factors as cost, speed, reliability, and frequency of expected changes (TANENBAUM). Therefore, it would have been obvious to combine LI and TERRELL to obtain the invention as specified in the instant claims.
With respect to Claim 2, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
LI further discloses wherein the logic is configured to receive requests to change the value of the semaphore from any of a plurality of sources (¶[0035] – “When the semaphore is released, the semaphore value is incremented to reflect that the memory block released by the task is available for other tasks”).
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 3, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
LI further discloses wherein the logic comprises a plurality of inputs, including the first input, for receiving requests to change the value of the semaphore (¶[0035] – “When the semaphore is released, the semaphore value is incremented to reflect that the memory block released by the task is available for other tasks”)..
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 4, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
LI further discloses wherein the integrated circuit comprises a processor (¶[0013] – “the present invention may be implemented in any computing and/or electronic device where processors and/or microprocessors perform such functions“) and wherein the logic is configured to receive requests to change the value of the semaphore from a software process executing on the processor (¶[0020] – “As will be described in greater detail below, a task may acquire a semaphore. Part of the acquisition of the semaphore includes decrementing the semaphore value).
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 5, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
LI further discloses wherein the logic is configured to receive requests to change the value of the semaphore from hardware circuitry of the integrated circuit (¶[0020] – “As will be described in greater detail below, a task may acquire a semaphore. Part of the acquisition of the semaphore includes decrementing the semaphore value).
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 6, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
LI further disclose wherein the logic is configured, in response to receiving the request to change the value of the semaphore at the first input (¶[0020] – “As will be described in greater detail below, a task may acquire a semaphore. Part of the acquisition of the semaphore includes decrementing the semaphore value), if the synchronization mutex is in an acquired state (Fig 3B, Step 305 – “Is mutex available?” => NO): to wait until the synchronization mutex is no longer in the acquired state (Fig 3B, Step 310 – “Temporarily suspend task”; ¶[0034] – “If the mutex is not available, the process continues to step 310 where the task is temporarily suspended until the mutex 117 becomes available”); then to switch the synchronization mutex to the first acquired state; then to change the value of the semaphore in response to the request; and then to switch the synchronization mutex to the unacquired state (Fig 3B, Step 310 – “Temporarily Suspend Task” => Step 315 – “Acquire mutex and update status” => Step 320 – “Release mutex” => Step 325 – “Release and increment semaphore”; ¶[0035]; ¶[0036] – this section teaches that Steps 320 and 325 may be performed in reverse order enabling “the semaphore value may be incremented and the semaphore may become available sooner for any tasks that are suspended awaiting the semaphore to become available”).
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 7, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
LI further discloses wherein the logic comprises logic for detecting that the synchronization mutex is in the first acquired state before changing the value of the semaphore in response to the request (Fig 3B, Step 315 – “Acquire mutex and update status” => … => Step 325 – “Release and increment semaphore”).
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 8, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
LI further discloses wherein the logic comprises logic for verifying that the value of the semaphore has been changed, in response to the request, before switching the synchronization mutex to the unacquired state (Fig 3B, Step 320 – “Release mutex” => Step 325 – “Release and increment semaphore”; ¶[0035]; ¶[0036] – this section teaches that Steps 320 and 325 may be performed in reverse order enabling “the semaphore value may be incremented and the semaphore may become available sooner for any tasks that are suspended awaiting the semaphore to become available”).
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 9, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
LI further discloses wherein the logic comprises an output for indicating whether the synchronization mutex is in an acquired state (¶[0034] – “In step 305, the process determines whether the mutex 117 is available”).
TERRELL discloses wherein the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 10, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
LI further discloses wherein the logic comprises an input for receiving requests to read the value of the semaphore (¶[0020] – “As will be described in greater detail below, a task may acquire a semaphore. Part of the acquisition of the semaphore includes decrementing the semaphore value. For example, if the semaphore 118 was acquired by a task, the value of the semaphore would be decremented from four to three. As will become apparent below, the value of the semaphore for any memory pool will be equal to the number of free memory blocks available in that memory pool”).
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 11, the combination of LI and TERRELL disclose the integrated circuit of claim 10.
LI further discloses wherein the logic is configured, in response to receiving a request to read the value of the semaphore, if the synchronization mutex is in the unacquired state, to switch the synchronization mutex to an acquired state and to output an indication that the mutex is in the acquired state (Fig 3A, Step 210 – “Is semaphore available?” => YES => … => Step 233 – “Is mutex available?” => YES => Step 237 – “Acquire mutex and update status information”).
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 12, the combination of LI and TERRELL disclose the integrated circuit of claim 10.
LI further discloses wherein the logic is configured to receive requests to read the value of the semaphore from any of a plurality of sources (¶[0035] – “When the semaphore is released, the semaphore value is incremented to reflect that the memory block released by the task is available for other tasks”).
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 13, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
LI further discloses wherein the logic comprises a latch, and is configured to set the latch in response to receiving a request to change the value of the semaphore at the first input, or in response to receiving a request to read the value of the semaphore at a further input of the logic (¶[0020] – “As will be described in greater detail below, a task may acquire a semaphore. Part of the acquisition of the semaphore includes decrementing the semaphore value. For example, if the semaphore 118 was acquired by a task, the value of the semaphore would be decremented from four to three. As will become apparent below, the value of the semaphore for any memory pool will be equal to the number of free memory blocks available in that memory pool”).
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 14, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
LI further discloses wherein the logic is configured, in response to receiving a request to change the value of the semaphore (¶[0020] – “As will be described in greater detail below, a task may acquire a semaphore. Part of the acquisition of the semaphore includes decrementing the semaphore value), if the synchronization mutex is in the unacquired state (Fig 3B, Step 305 – “Is mutex available?”; => YES): to switch the synchronization mutex to the first acquired state; then to change the value of the semaphore in response to the request; and then, in response to a cessation of the request to change the value of the semaphore, to switch the synchronization mutex to the unacquired state (Fig 3B, Step 315 – “Acquire mutex and update status” => Step 320 – “Release mutex” => Step 325 – “Release and increment semaphore”; ¶[0035]; ¶[0036] – this section teaches that Steps 320 and 325 may be performed in reverse order enabling “the semaphore value may be incremented and the semaphore may become available sooner for any tasks that are suspended awaiting the semaphore to become available”).
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 15, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
LI further discloses wherein the request to change the value of the semaphore, received at the first input, is a request to increment the value of the semaphore, and wherein the first input is arranged only to receive requests to increment the value of the semaphore (¶[0035] – “When the semaphore is released, the semaphore value is incremented to reflect that the memory block released by the task is available for other tasks.“).
TERRELL discloses wherein the semaphore is a hardware semaphore (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 16, the combination of LI and TERRELL disclose the integrated circuit of claim 15.
LI further discloses wherein the logic comprises a second input for receiving requests to decrement the value of the semaphore (¶[0020] – “As will be described in greater detail below, a task may acquire a semaphore. Part of the acquisition of the semaphore includes decrementing the semaphore value), and wherein the logic is configured, in response to receiving a request to decrement the value of the semaphore at the second input, if the synchronization mutex is in the unacquired state (Fig 3B, Step 305 – “Is mutex available?”; => YES): to switch the synchronization mutex to an acquired state; then to decrement the value of the hardware semaphore in response to the request; and then to switch the synchronization mutex to the unacquired state (Fig 3B, Step 315 – “Acquire mutex and update status” => Step 320 – “Release mutex” => Step 325 – “Release and increment semaphore”; ¶[0035]; ¶[0036] – this section teaches that Steps 320 and 325 may be performed in reverse order enabling “the semaphore value may be incremented and the semaphore may become available sooner for any tasks that are suspended awaiting the semaphore to become available”), and if the synchronization mutex is in an acquired state (Fig 3B, Step 305 – “Is mutex available?” => NO), not to decrement the value of the hardware semaphore in response to the request, at least while the synchronization mutex remains in the acquired state (Fig 3B, Step 310 – “Temporarily suspend task”; ¶[0034] – “If the mutex is not available, the process continues to step 310 where the task is temporarily suspended until the mutex 117 becomes available”).
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
With respect to Claim 17, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
LI further discloses wherein the semaphore is configured to store a multi-bit value (¶[0020] – “As will be described in greater detail below, a task may acquire a semaphore. Part of the acquisition of the semaphore includes decrementing the semaphore value. For example, if the semaphore 118 was acquired by a task, the value of the semaphore would be decremented from four to three. As will become apparent below, the value of the semaphore for any memory pool will be equal to the number of free memory blocks available in that memory pool”).
TERRELL discloses wherein the semaphore is a hardware semaphore (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
Claim(s) 18 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over LI (US PGPub 2004/0039884) in further view of TERRELL (US PGPub 2008/0005741) and NAMJOSHI et al (US PGPub 2012/0054394) with motivation provided by TANENBAUM (Structured Computer Organization, 6th Edition; Page 8).
With respect to Claim 18, the combination of LI and TERRELL disclose the integrated circuit of claim 1.
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
LI and TERRELL may not explicitly disclose wherein the logic comprises access control circuitry, separate from the synchronization mutex, for controlling access to the synchronization mutex or the semaphore, wherein the access control circuitry comprises a mutex-request output that is coupled to a first mutex-request input of the synchronization mutex, and is configured to use the mutex-request output to switch the synchronization mutex to the first acquired state in response to the request to change the value of the semaphore received at the first input.
However, NAMJOSHI discloses wherein the logic comprises access control circuitry (Fig 2A, Step 203 – “Lock Secondary Lock”), separate from the synchronization mutex, for controlling access to the synchronization mutex or the semaphore, wherein the access control circuitry comprises a mutex-request output that is coupled to a first mutex-request input of the synchronization mutex, and is configured to use the mutex-request output to switch the synchronization mutex to the first acquired state in response to the request to change the value of the semaphore received at the first input (¶[0040] – “FIG. 2A is a flow diagram illustrating a biased_lock process 200. When the biased_lock process is called, it is determined at decision 201 if the calling thread is the lock owner, for example by comparing the thread ID of the calling thread to the owner Thread ID stored in the bias-lock data structure. secondary lock at step 203. Once the secondary lock has been acquired, the calling thread then competes for the primary lock and attempts to lock the primary lock at step 204.”).
LI, TERRELL, and NAMJOSHI are analogous art because they are from the same field of endeavor of controlling access to a common resource. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of LI, TERRELL, and NAMJOSHI before him or her, to modify the semaphore and related functions of the combination of LI and TERRELL to include access control circuitry as taught by NAMJOSHI. A motivation for doing so would have been to enable a lock process where a dominant process may perform a lock operation with a reduced number of fence operations (¶[0036]). Therefore, it would have been obvious to combine LI, TERRELL, and NAMJOSHI to obtain the invention as specified in the instant claims.
With respect to Claim 19, the combination of LI, TERRELL, and NAMJOSHI disclose the integrated circuit of claim 18,
TERRELL discloses wherein the semaphore is a hardware semaphore, and the logic is asynchronous hardware logic circuitry (¶[0073] – “For instance, the hardware mutex can be generalized to support a generic counting semaphore.”).
NAMJOSHI further discloses wherein the logic further comprises a second input for receiving requests to change the value of the semaphore, and is configured to pass requests received at the second input directly to a second mutex-request input of the synchronization mutex without passing through the access control circuitry, and wherein the synchronization mutex comprises a second mutex-grant output, corresponding to the second mutex-request input, that is coupled to the access control circuitry for use by the access control circuitry in determining when to change the value of the semaphore in response to a request received at the second input (¶[0040] – “FIG. 2A is a flow diagram illustrating a biased_lock process 200. When the biased_lock process is called, it is determined at decision 201 if the calling thread is the lock owner, for example by comparing the thread ID of the calling thread to the owner Thread ID stored in the bias-lock data structure. If the calling thread is the owner of the lock, the primary lock is locked at step 202. .
Conclusion
THIS ACTION IS MADE FINAL. 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 ERIC T LOONAN whose telephone number is (571)272-6994. The examiner can normally be reached M-F 8am-5pm.
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, Arpan Savla can be reached at 571-272-1077. 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.
/ERIC T LOONAN/Examiner, Art Unit 2137