DETAILED ACTION
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
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 06/11/2026 has been entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/12/2026, 07/27/2026, 08/24/2026 and 09/09/2026 are being considered by the examiner.
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, 3 – 6, 8 – 10, 12 – 13, 15 – 18, 21 – 24 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over the prior art of record, Ashwathnarayan et al., (US 2020/0364088 A1) (hereinafter “Ashwathnarayan”) in view of SCHLUESSLER et al., (US 2022/0180588 A1) (hereinafter “Schluessler”).
Regarding claim 1, Ashwathnarayan discloses; one or more processors [i.e., (see figure 12) Directed Acyclic Graph of heterogeneous processors (CPU, camara, iGPU, dGPU i.e., (para 0162 – 063) processors coordinated via synchronization objects], comprising:
circuity to: in response to a second application programming (API) call of second software library [i.e., an already-created SciSync imported as an external semaphore into a parallel-computing/API model (para 108, 128 – 129) i.e., signalExternalSemaphoresAsync() as an API that enqueues a signal operation on externally allocated semaphore objects in a specified stream (para 0128) i.e., the application invoking the API and the API enqueuing the signal operation (para 0129)], update a counter value of a timeline semaphore [i.e., a semaphore release and a SciSyncFence containing <Sema-Offset, thresholdValue>, wherein thresholdValue is the value the semaphore contains when the GPU executes the signal operation (para 0129) i.e., for a D3D12_FENCE, signaling sets the semaphore to the value specified by EXTERNAL_SEMAPHORE_PARAMS::params::fence::value (para 0133)] at a memory address indicated by a handle [i.e., SyncCreate() sets the semaphore primitive, allocates the semaphore pool, obtains a handle, and save MemHandle; the signaler/waiter then map the MemHandle and save the resulting mapped address (para 0154 – 0155) i.e., semaphore address + value, determining the semaphore offset, and reconstruction the address from semaPool+offset (para 0156 – 0157), (see figure 11)] identified by the second API [i.e., an already-created SciSync is imported as an external semaphore using EXTERNAL_SEMAPHORE_HANDLE_DESC, which contains the SciSyncObj pointer/handle. ImportExternalSemaphore() maps the resources into the API model’s address space (para 0109 - 0111)], [i.e., IPC by exposing SciSync as a handle and application passing around handles representing SciSync (para 0164)], wherein a first API of a first software library created the timeline semaphore [i.e., SyncCreate() sets the synchronization primitive to a semaphore, allocates the semaphore pool, and create/returns the synchronization handle (para 0154), (see figure 1)].
Ashwathnarayan does not disclose;
from an exported handle of the timeline semaphore and exported the handle of the timeline semaphore.
However, Schluessler discloses;
from an exported handle of the timeline semaphore [i.e., shared-fence/resource handle mechanism – CreateSharedHandle() produces the HANDLE subsequent supplied to OpenSharedHandle() (para 0209)], exported the handle of the timeline semaphore [i.e., an existing interface for sharing resources across processes in modern API; ID3D12Device::OpenSharedHandle() opens shared resources, shared heaps, and importantly shared fences; its HANDLE parameter can be the output of ID3D12DEVICE::CreateSharedHandle() (para 0209)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Ashwathnarayan by adapting the teachings of Schluessler to resource sharing for multiple instances executed on the same graphics execution unit (See; Schluessler; page 1, para 0001).
Regarding claim 3, Ashwathnarayan discloses; the one or more processors of claim 1, wherein the second API imports the handle for the timeline semaphore by at least creating a data structure corresponding to the handle for the timeline semaphore [i.e., (figure 10) Unified Sync imported, mapped, and associated with internal data structures i.e., (para 0109) semaphore descriptors reference SciSyncObj pointer].
Regarding claim 4, Ashwathnarayan discloses; the one or more processors of claim 1, memory address indicated by the handle corresponds to an identification of the handle for the timeline semaphore [i.e., (para 0109 – 0110) EXTERNAL_SEMAPHORE_DESC is a data structure containing the synchronization-object pointer/handle used by ImportExternalSemaphore() i.e., (para 0106 – 0109) handle parameters used to identify internal attributes and mapping i.e., (see 816 figure 8) parameter mapping].
Regarding claim 5, Ashwathnarayan discloses; the one or more processors of claim 1, wherein the circuitry is to perform a workload with an operation that references the handle [i.e., (figure 9 and 11) workloads enqueued on streams that wait on or signal semaphore handles i.e., (para 0108)].
Regarding claim 6, Ashwathnarayan discloses; the one or more processors of claim 1, wherein the timeline semaphore corresponds to a monotonically increasing integer [i.e., (para 0129) semaphore thresholdValue written upon signal i.e., (figure 11) incrementing semaphore value upon release].
Regarding claim 8, Ashwathnarayan discloses; the one or more processors of claim 1, wherein the circuitry is to receive the handle indicating the timeline semaphore from an application, and wherein the application received the handle from the first API [i.e., (figure 44A – 44D) application receives UnifiedSync/semaphore object from API i.e., (para 0162)].
Regarding claim 9, Ashwathnarayan discloses; the one or more processors of claim 1, wherein the timeline semaphore corresponds to synchronizing a first workload and second workload [i.e., (figure 9) device queue and stream synchronization i.e., (figure 12) synchronization between heterogenous workloads i.e., (para 0162 – 0163)].
Regarding claim 10, Ashwathnarayan discloses; a system [i.e., (see figure 17)], comprising a memory storing instructions that, as a result of execution by one or more processors [i.e., (see figures 17 and 19)], cause the system to:
in response to a second application programming (API) call of second software library [i.e., an already-created SciSync imported as an external semaphore into a parallel-computing/API model (para 108, 128 – 129) i.e., signalExternalSemaphoresAsync() as an API that enqueues a signal operation on externally allocated semaphore objects in a specified stream (para 0128) i.e., the application invoking the API and the API enqueuing the signal operation (para 0129)], update a counter value of a timeline semaphore [i.e., a semaphore release and a SciSyncFence containing <Sema-Offset, thresholdValue>, wherein thresholdValue is the value the semaphore contains when the GPU executes the signal operation (para 0129) i.e., for a D3D12_FENCE, signaling sets the semaphore to the value specified by EXTERNAL_SEMAPHORE_PARAMS::params::fence::value (para 0133)] at a memory address indicated by a handle [i.e., SyncCreate() sets the semaphore primitive, allocates the semaphore pool, obtains a handle, and save MemHandle; the signaler/waiter then map the MemHandle and save the resulting mapped address (para 0154 – 0155) i.e., semaphore address + value, determining the semaphore offset, and reconstruction the address from semaPool+offset (para 0156 – 0157), (see figure 11)] identified by the second API [i.e., an already-created SciSync is imported as an external semaphore using EXTERNAL_SEMAPHORE_HANDLE_DESC, which contains the SciSyncObj pointer/handle. ImportExternalSemaphore() maps the resources into the API model’s address space (para 0109 - 0111)], [i.e., IPC by exposing SciSync as a handle and application passing around handles representing SciSync (para 0164)], wherein a first API of a first software library created the timeline semaphore [i.e., SyncCreate() sets the synchronization primitive to a semaphore, allocates the semaphore pool, and create/returns the synchronization handle (para 0154), (see figure 1)].
Ashwathnarayan does not disclose;
from an exported handle of the timeline semaphore and exported the handle of the timeline semaphore.
However, Schluessler discloses;
from an exported handle of the timeline semaphore [i.e., shared-fence/resource handle mechanism – CreateSharedHandle() produces the HANDLE subsequent supplied to OpenSharedHandle() (para 0209)], exported the handle of the timeline semaphore [i.e., an existing interface for sharing resources across processes in modern API; ID3D12Device::OpenSharedHandle() opens shared resources, shared heaps, and importantly shared fences; its HANDLE parameter can be the output of ID3D12DEVICE::CreateSharedHandle() (para 0209)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Ashwathnarayan by adapting the teachings of Schluessler to resource sharing for multiple instances executed on the same graphics execution unit (See; Schluessler; page 1, para 0001).
Regarding claim 12, Ashwathnarayan discloses; the system of claim 10, wherein the second API is to identify the handle for the timeline semaphore during import based, at least in part, on the identification of a parameter of the handle or a parameter of a call of the second API [i.e., (para 0106) and (step 816 figure 8) handle identification during import].
Regarding claim 13, Ashwathnarayan discloses; the system of claim 10, wherein the one or more processors are to perform a workload with an operation that references the handle [i.e., (figures 9 and 11) workload referencing handle].
Regarding claim 15, Ashwathnarayan discloses; the system of claim 10, wherein the timeline semaphore corresponds to controlling access to a computing resource [i.e., (para 0162 – 0163) controlling access to shared computing resources].
Regarding claim 16, Ashwathnarayan discloses; the system of claim 10, wherein the timeline semaphore is to be referenced by a first stream and a second stream, and wherein the first stream and the second stream are to be synchronized based on reading a value corresponding to the timeline semaphore [i.e., (figures 9 and 11) streams synchronized by semaphore value i.e., (para 0156 – 0157), (see figure 11) stream A signals using semaphore address/value, receiving side drives address and performs acquire/wait associated with stream B].
Regarding claim 17, Ashwathnarayan discloses; a non-transitory machine-readable medium having stored thereon one or more instructions [i.e., (see figures 17 and 19)], which if performed by one or more processors, cause one or more processors to at least [i.e., (para 0108 – 0129)]:
in response to a second application programming (API) call of second software library [i.e., an already-created SciSync imported as an external semaphore into a parallel-computing/API model (para 108, 128 – 129) i.e., signalExternalSemaphoresAsync() as an API that enqueues a signal operation on externally allocated semaphore objects in a specified stream (para 0128) i.e., the application invoking the API and the API enqueuing the signal operation (para 0129)], update a counter value of a timeline semaphore [i.e., a semaphore release and a SciSyncFence containing <Sema-Offset, thresholdValue>, wherein thresholdValue is the value the semaphore contains when the GPU executes the signal operation (para 0129) i.e., for a D3D12_FENCE, signaling sets the semaphore to the value specified by EXTERNAL_SEMAPHORE_PARAMS::params::fence::value (para 0133)] at a memory address indicated by a handle [i.e., SyncCreate() sets the semaphore primitive, allocates the semaphore pool, obtains a handle, and save MemHandle; the signaler/waiter then map the MemHandle and save the resulting mapped address (para 0154 – 0155) i.e., semaphore address + value, determining the semaphore offset, and reconstruction the address from semaPool+offset (para 0156 – 0157), (see figure 11)] identified by the second API [i.e., an already-created SciSync is imported as an external semaphore using EXTERNAL_SEMAPHORE_HANDLE_DESC, which contains the SciSyncObj pointer/handle. ImportExternalSemaphore() maps the resources into the API model’s address space (para 0109 - 0111)], [i.e., IPC by exposing SciSync as a handle and application passing around handles representing SciSync (para 0164)], wherein a first API of a first software library created the timeline semaphore [i.e., SyncCreate() sets the synchronization primitive to a semaphore, allocates the semaphore pool, and create/returns the synchronization handle (para 0154), (see figure 1)].
Ashwathnarayan does not disclose;
from an exported handle of the timeline semaphore and exported the handle of the timeline semaphore.
However, Schluessler discloses;
from an exported handle of the timeline semaphore [i.e., shared-fence/resource handle mechanism – CreateSharedHandle() produces the HANDLE subsequent supplied to OpenSharedHandle() (para 0209)], exported the handle of the timeline semaphore [i.e., an existing interface for sharing resources across processes in modern API; ID3D12Device::OpenSharedHandle() opens shared resources, shared heaps, and importantly shared fences; its HANDLE parameter can be the output of ID3D12DEVICE::CreateSharedHandle() (para 0209)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Ashwathnarayan by adapting the teachings of Schluessler to resource sharing for multiple instances executed on the same graphics execution unit (See; Schluessler; page 1, para 0001).
Regarding claim 18, Ashwathnarayan discloses; the non-transitory machine-readable medium of claim 17, wherein the one or more instructions further cause the one or more processors to at least:
create, by the first API, the timeline semaphore [i.e., (figures 10 – 11), (para 0128 – 0129) creates semaphore], and
signal, with a driver, the timeline semaphore based on the handle, and wherein to signal includes an operation that causes the timeline semaphore to modify the counter value [i.e., (figures 10 – 11), (para 0128 – 0129) creates semaphore and signal via driver].
Regarding claim 21, Ashwathnarayan discloses; the non-transitory machine-readable medium of claim 17, wherein the one or more instructions further cause the one or more processors to at least: generate a first work stream and a second work stream, and wherein the first work stream and the second work stream are synchronized based on operations corresponding to the timeline semaphore [i.e., (figure 9) shows a device queue and a parallel computing API stream coordinating using SciSyncFence i.e., (figure 11) i.e., (para 0108 – 0109) describes work submitted to queues and streams, generating fences and waiting across streams using imported semaphore i.e., (para 0128 – 0129) semaphore release operations include writing a threshold value used for synchronization].
Regarding claim 22 Ashwathnarayan discloses; the non-transitory machine-readable medium of claim 17, wherein the first API has a queue of operations, and wherein the queue of operations includes a wait operation that references the timeline semaphore [i.e., (figure 9) device queue waits on SciSyncFence generated by another queue i.e., (figure 11) streamWaitEvent(stream, WaitEvent) corresponds to wait operation referencing a semaphore i.e., (para 0108) device queue waits for generated SciSyncFence i.e., (para 0123 – 0126) wait operations reference external semaphores passed as parameters].
Regarding claim 23, Ashwathnarayan discloses; the non-transitory machine-readable medium of claim 17, wherein the first software library and the second software library reference the timeline semaphore to synchronize operations for graphics processing [i.e., (figure 13) CUDA and NVMedia/OpenGL interop synchronization via SciSync i.e., (para 0162 – 0163) synchronization object coordinates execution and memory access across UMDs including graphics i.e., (figure 12) GPU synchronization via semaphore between processing stages i.e., (para 0164) SciSync correlates CUDA events and graphics synchronization].
Regarding claim 24, Ashwathnarayan discloses; a method comprising:
Identifying a timeline semaphore at an address in memory from a first application programming interface (API) of a first software library [i.e., (para 0154 – 0155) semaphore primitives selected; semaphore pool allocated; MemHandle stored; signaler/waiter map handle and save mapped address i.e., (figures 10 and 11) semaphore pool address calculates and used];
generating a handle indicating the address of the timeline semaphore using the first software library [i.e., (para 0154 – 0156), (see figures 10 – 11) allocation returns handle/MemHandle; mapping yields address; semaphore identified in pool by address/offset i.e., (see step 812 of figure 8) handle provided to UMDs];
causing the timeline semaphore to be imported to a second software library [i.e., (para 0108 – 0110) already-created SciSync imported as external semaphore; ImportExternalSemaphore() maps resources into receiving API’s address space] based, at least in part, on an identification of a parameter of the handle [i.e., (para 0109) external semaphore import uses a descriptor referencing a SciSyncobj pointer i.e., (figure 10) UnifiedSync imported and associated with internal data structures i.e., (para 0122 – 0124) wait APIs accept parameters identifying external semaphore handles]; and
in response to receiving a second API call [i.e., (para 0128 – 0129)] of the second software library, updating a counter value [i.e., (para 0129) <Sema-Offset, thresholdValue> i.e., (para 0033) D3D12-fence semaphore set to specified fence value] of the timeline semaphore at the address in memory indicated by the handle [i.e., (para 0128) SignalExternalSemaphoresAsync() enqueues a signal operation i.e., (para 0129) signal operation writes semaphore offset and threshold value i.e., (see figure 11) semaphore release operation modifies semaphore at calculated memory address].
Ashwathnarayan does not disclose;
where the handle is identified by the second API from an exported handle of the timeline semaphore.
However, Schluessler discloses;
where the handle is identified by the second API from an exported handle of the timeline semaphore [i.e., shared-fence/resource handle mechanism – CreateSharedHandle() produces the HANDLE subsequent supplied to OpenSharedHandle() (para 0209)], [i.e., an existing interface for sharing resources across processes in modern API; ID3D12Device::OpenSharedHandle() opens shared resources, shared heaps, and importantly shared fences; its HANDLE parameter can be the output of ID3D12DEVICE::CreateSharedHandle() (para 0209)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Ashwathnarayan by adapting the teachings of Schluessler to resource sharing for multiple instances executed on the same graphics execution unit (See; Schluessler; page 1, para 0001).
Regarding claim 29, Ashwathnarayan discloses; the method of claim 24, wherein the method further comprises:
signaling the timeline semaphore, wherein signaling includes causing a parameter of the timeline semaphore to increase in value [i.e., (para 0129) semaphore threshold value increases when signaled]; and
releasing references to the timeline semaphore [i.e., (figure 11) release operation modifies semaphore state i.e., (para 0106) deallocation and removal of UMD references after use].
Allowable Subject Matter
Claims 7, 14, 19 – 20, 25 – 28 and 30 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding claim 7;
the prior art of record, Ashwathnarayan in view of Schluessler discloses the one or more processors of claim 1,
However, Ashwathnarayan in view of Schluessler do not disclose “wherein the counter value of the timeline semaphore is increased by one or more when it is signaled by a first driver corresponding to the first API or when it is signaled by a second driver corresponding to the second API”.
These claimed limitations are not present in the prior arts of record and would not have been obvious. They in combination with other elements cited present subject matter that is novel and nonobvious. Thus, claim 7 is objected being dependent upon rejected base claim.
Regarding claim 14;
the prior art of record, Ashwathnarayan in view of Schluessler discloses the system of claim 10,
However, Ashwathnarayan in view of Schluessler do not disclose “wherein the first API created the timeline semaphore and exported the handle, and wherein the memory address indicated by the handle corresponds to a data structure for the handle for the timeline semaphore imported by the second API”.
These claimed limitations are not present in the prior arts of record and would not have been obvious. They in combination with other elements cited present subject matter that is novel and nonobvious. Thus, claim 14 is objected being dependent upon rejected base claim.
Regarding claim 19;
the prior art of record, Ashwathnarayan in view of Schluessler discloses the non-transitory machine-readable medium of claim 18,
However, Ashwathnarayan in view of Schluessler do not disclose “wherein the counter value of the timeline semaphore is increased by a value of one or more when it is signaled by a driver”.
These claimed limitations are not present in the prior arts of record and would not have been obvious. They in combination with other elements cited present subject matter that is novel and nonobvious. Thus, claim 19 is objected being dependent upon rejected base claim.
Regarding claim 20;
the prior art of record, Ashwathnarayan in view of Schluessler discloses the non-transitory machine-readable medium of claim 18,
However, Ashwathnarayan in view of Schluessler do not disclose “wherein the handle is a pointer for an operating system to read or write data at the memory address for the timeline semaphore”.
These claimed limitations are not present in the prior arts of record and would not have been obvious. They in combination with other elements cited present subject matter that is novel and nonobvious. Thus, claim 20 is objected being dependent upon rejected base claim.
Regarding claim 25;
the prior art of record, Ashwathnarayan in view of Schluessler discloses the method of claim 24,
However, Ashwathnarayan in view of Schluessler do not disclose “wherein the method further comprises: signaling, with a driver, the timeline semaphore based on the handle that references the address for the timeline semaphore, wherein another driver also signals the timeline semaphore”.
These claimed limitations are not present in the prior arts of record and would not have been obvious. They in combination with other elements cited present subject matter that is novel and nonobvious. Thus, claim 25 is objected being dependent upon rejected base claim.
Regarding claim 26;
the prior art of record, Ashwathnarayan in view of Schluessler discloses the method of claim 24,
However, Ashwathnarayan in view of Schluessler do not disclose “wherein the parameter of the handle comprises a counter parameter or wait parameter of the timeline semaphore”.
These claimed limitations are not present in the prior arts of record and would not have been obvious. They in combination with other elements cited present subject matter that is novel and nonobvious. Thus, claim 26 is objected being dependent upon rejected base claim.
Regarding claim 27;
the prior art of record, Ashwathnarayan in view of Schluessler discloses the method of claim 24,
However, Ashwathnarayan in view of Schluessler do not disclose “wherein causing the timeline semaphore to be imported further comprises: requesting, by an application, that the first API create and export the handle corresponding to the timeline semaphore, providing, by the application, the exported handle to the second API, identifying, by the second API, a parameter that indicates the exported handle; and importing the exported handle”.
These claimed limitations are not present in the prior arts of record and would not have been obvious. They in combination with other elements cited present subject matter that is novel and nonobvious. Thus, claim 27 is objected being dependent upon rejected base claim.
Regarding claim 30;
the prior art of record, Ashwathnarayan in view of Schluessler discloses the method of claim 24,
However, Ashwathnarayan in view of Schluessler do not disclose “further comprising: providing a first queue; providing a first stream; and providing a second stream, and wherein the first queue, the first stream, and the second stream have operations that correspond to a count value of the timeline semaphore”.
These claimed limitations are not present in the prior arts of record and would not have been obvious. They in combination with other elements cited present subject matter that is novel and nonobvious. Thus, claim 30 is objected being dependent upon rejected base claim.
Response to Arguments
Applicant’s arguments with respect to pending claim(s) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED A RONI whose telephone number is (571)270-7806. The examiner can normally be reached M-F 9:00-5:00 pm (EST).
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/SYED A RONI/Primary Examiner, Art Unit 2432
Prosecution Insights