DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is the initial Office Action based on the application filed 09/23/2024. Claims 21-40 are presented for examination and have been considered below.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 21-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-18 of U.S. Patent No. 12,099,405 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because every limitation claimed in the present application is anticipated by the claimed invention of U.S. Patent No. 12,099,405 B2, as follows:
Present application
US 12,099,405
21. A method for reducing observed processing latency in a reception device, the method comprising: receiving, by a network layer, a first portion of first data, the first data consisting of the first portion and a second portion; receiving, by a transport layer, the first portion of the first data from the network layer; receiving, by an application layer, the first portion of the first data from the transport layer; initializing, by the application layer, data processing on the first data after receiving the first portion of the first data and before receiving a second portion of the first data; receiving, by the network layer, the second portion of the first data; in response to at least one error being detected in the first data, the network layer alerting the application layer to cancel processing the data; or in response to no error being detected in the first data, the network layer alerting the transport layer to (i) finalize receiving the first data and (ii) perform a transport layer error detection.
22. The method of claim 21, wherein performing the error-correction process comprises rolling back an application state to a prior state.
23. The method of claim 22 further comprising, before initializing the data processing, establishing an application checkpoint, wherein performing the error-correction process comprises rolling back an application state to the application checkpoint.
24. The method of claim 23, wherein establishing the application checkpoint is in response to receiving the first portion of the first data.
25. The method of claim 22 further comprising disregarding the first data after rolling back the application state.
26. The method of claim 22 further comprising re-attempting processing the first data after rolling back the application state.
27. The method of claim 21, wherein performing the error-correction process comprises ceasing data processing on the first data.
28. The method of claim 21, wherein performing the error-correction process comprises re- initializing the reception device to a safe state.
29. The method of claim 21 further comprising: in response to at least one error being detected in the first data in the transport error detection, the transport layer alerting the application layer to cancel processing the data.
30. The method of claim 21 further comprising: in response to no error being detected in the first data in the transport error detection, the transport layer alerting to (i) finalize the data processing and (ii) commit a data-processing result.
31. The method of claim 21, wherein the method is performed by at least one of a field- programmable gate array (FPGA) and an Application-Specific Integrated Circuit (ASIC) of the reception device.
32. A semiconductor device comprising: a first circuit block configured to receive at least a portion of first data and at least a portion of additional data; a second circuit block configured to receive at least a portion of the first data from the first circuit block; a third circuit block configured to initialize data processing on the at least a portion of first data and before receiving at least a portion of additional data; a fourth circuit block, in response to at least one error being detected in the first data, a network layer alerting an application layer to cancel processing the data; or a fifth circuit block, in response to no error being detected in the first data, the network layer alerting the transport layer to (i) finalize receiving the first data and (ii) perform a transport layer error detection.
33. The semiconductor device of claim 33, wherein: the fifth circuit block, in response to at least one error being detected in the first data in the transport error detection, the transport layer alerting the application layer to cancel processing the data.
34. The semiconductor device of claim 33, wherein: the fifth circuit block, in response to no error being detected in the first data in the transport error detection, the transport layer alerting to (i) finalize the data processing and (ii) commit a data- processing result.
35. The semiconductor device of claim 33, wherein: the third circuit block is further configured to, before initializing the data processing, establish an application checkpoint in response to receiving at least a portion of the first data, andthe fourth circuit block is configured to perform the error-correction process comprising rolling back an application state to the application checkpoint.
36. The semiconductor device of claim 33, wherein: the fourth circuit block is configured to perform the error-correction process comprising rolling back an application state to the application checkpoint.
37. The semiconductor device of claim 33, the fourth circuit block is configured to perform the error-correction process comprises re-initializing the semiconductor device to a safe state.
38. A system comprising: a processor; Anda memory comprising instructions that, when executed by the processor, control the processor to implement a method for reducing observed processing latency in networked communication, the networked communication having a reception device having a network layer, an application layer, and a layer lower than the application layer, the method comprising: receiving, by the network layer, a first portion of first data, the first data consisting of the first portion and a second portion; receiving, by the transport layer, the first portion of the first data from the network layer; receiving, by the application layer, the first portion of the first data from the transport layer; initializing, by the application layer, data processing on the first data after receiving the first portion of the first data and before receiving the second portion of the first data; receiving, by the network layer, the second portion of the first data; in response to at least one error being detected in the first data, the network layer alerting the application layer to cancel processing the data; in response to no error being detected in the first data, the network layer alerting the transport layer to (i) finalize receiving the first data and (ii) perform a transport layer error detection.
39. The system of claim 38, the memory further comprising instructions that, when executed by the processor, control the processor to, in response to no error being detected in the first data in the transport error detection, the transport layer alerting to (i) finalize the data processing and (ii) commit a data-processing result.
40. The system of claim 38, the memory further comprising instructions that, when executed by the processor, control the processor to, in response to at least one error being detected in the first data in the transport error detection, the transport layer alerting the application layer to cancel processing the data.
1. A method for reducing observed processing latency in a reception device, the reception device having a network layer, an application layer, and a layer lower than the application layer, the method comprising: receiving, by a reception device, a first portion of first data, the first data consisting of the first portion and a second portion; initializing, by the reception device, data processing on the first data after receiving the first portion of the first data and before receiving the second portion of the first data; receiving, by the reception device, the second portion of the data; in response to at least one error being detected in the first data or the processing of the first data, the network layer alerting the application layer of by the reception device to perform an error-correction process; receiving, by the reception device, a first portion of second data, the second data consisting of the first portion of the second data and a second portion of the second data; initializing, by the reception device, data processing on the second data after receiving the first portion of the second data and before receiving the second portion of the second data, the data processing being distinct from calculation of an error-detection code or an error-detection process of the second data; and in response to no error being detected in the second data or the processing of the second data, the network layer alerting the application layer to (i) finalize, by the reception device, the data processing on the second data, (ii) commit a data-processing result of the second data, and (iii) performing a transport layer error detection.
2. The method of claim 1, wherein performing the error-correction process comprises rolling back an application state to a prior state.
3. The method of claim 2 further comprising, before initializing the data processing, establishing an application checkpoint, wherein performing the error-correction process comprises rolling back an application state to the application checkpoint.
4. The method of claim 3, wherein establishing the application checkpoint is in response to receiving the first portion of the first data.
5. The method of claim 2 further comprising disregarding the first data after rolling back the application state.
6. The method of claim 2 further comprising re-attempting processing the first data after rolling back the application state.
7. The method of claim 1, wherein performing the error-correction process comprises ceasing data processing on the first data.
8. The method of claim 7, wherein performing the error-correction process comprises ceasing data processing on the first data.
9. The method of claim 1, wherein performing the error-correction process comprises re-initializing the reception device to a safe state.
10. The method of claim 1, wherein the data processing on the first data is distinct from an error-detection process.
11. The method of claim 1 further comprising performing an error detection process.
12. The method of claim 11, wherein the error detection process is performed after receiving the second portion of the first data.
13. The method of claim 1, wherein the method is performed by at least one of a field-programmable gate array (FPGA) and an Application-Specific Integrated Circuit (ASIC) of the reception device.
14. A semiconductor device comprising: a first circuit block configured to receive a first portion of first data and a first portion of second data; a second circuit block configured to initialize data processing on the first data after the first circuit block receives the first portion of first data and before first circuit block receives the first portion of the second data; a third circuit block configured to, in response to at least one error being detected in the first data or the processing of the first data, a network layer alerts an application layer to begin to perform an error-correction process; a fourth circuit block configured to receive a first portion of second data, the second data consisting of the first portion of the second data and a second portion of the second data; and a fifth circuit block configured to initialize data processing on the second data after receiving the first portion of the second data and before receiving the second portion of the second data, the data processing being distinct from calculation of an error-detection code or an error-detection process of the second data, in response to no error being detected in the second data or the processing of the second data, cause the network layer to alert the application layer to (i) finalize, by the fifth circuit block, the data processing on the second data, (ii) commit a data-processing result of the second data, and (iii) perform a transport layer error detection.
15. The semiconductor device of claim 14, wherein the third circuit block is configured to perform the error-correction process comprising rolling back an application state to a prior state.
16. The semiconductor device of claim 14, wherein the second circuit block is further configured to, before initializing the data processing, establish an application checkpoint in response to receiving the first portion of data, and the third circuit block is configured to perform the error-correction process comprising rolling back an application state to the application checkpoint.
17. The semiconductor device of claim 14, the third circuit block is configured to perform the error-correction process comprises re-initializing the semiconductor device to a safe state.
18. A system comprising: a processor; and a memory comprising instructions that, when executed by the processor, control the processor to implement a method for reducing observed processing latency in networked communication, the networked communication having a reception device having a network layer, an application layer, and a layer lower than the application layer, the method comprising: receiving a first portion of first data, the first data consisting of the first portion and a second portion; initializing data processing on the first data after receiving the first portion of the first data and before receiving the second portion of the first data; receiving the second portion of the first data; in response to at least one error being detected in the first data or the processing of the first data, the network layer alerting the application layer to perform an error-correction process; receiving, by the reception device, a first portion of second data, the second data consisting of the first portion of the second data and a second portion of the second data; initializing, by the reception device, data processing on the second data after receiving the first portion of the second data and before receiving the second portion of the second data, the data processing being distinct from calculation of an error-detection code or an error-detection process of the second data; and in response to no error being detected in the second data or the processing of the second data, the network layer alerting the application layer to (i) finalize, by the reception device, the data processing on the second data, (ii) commit a data-processing result of the second data, and (iii) performing a transport layer error detection.
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.
Claim(s) 21-40 are rejected under 35 U.S.C. 103 as being unpatentable over US 7,203,722 B2 to Elnozahy (“Elnozahy”) and further in view of US 2018/0183901 A1 to Lariviere et al. (“Lariviere”).
Claim 21: Elnozahy teaches a method for reducing observed processing latency in a reception device, the method comprising:
receiving, by a network layer, a first portion of first data, the first data consisting of the first portion and a second portion (e.g. Fig. 3 and col. 5, ln. 15-35, describes a frame parser (306) that delineates a received frame (200) into a network portion (301) and a data portion (302). These are, respectively, the first portion and second portion of the claimed "first data”);
receiving, by a transport layer, the first portion of the first data from the network layer; receiving, by the network layer, the second portion of the first data and receiving, by an application layer, the first portion of the first data from the transport layer (e.g. The system includes a Network Interface Card (NIC 112) and server CPUs (111) (Fig. 1, col. 4, ln. 40-60). The NIC and its embedded processor handle lower-level (network/transport layer) processing, while the server processor runs the application (web server 303). Data flows from the network, through the NIC, to the application. This teaches the layered reception architecture);
initializing, by the application layer, data processing on the first data after receiving the first portion of the first data and before receiving a second portion of the first data (e.g. Col. 5, ln. 35-50 states: "Simultaneously with the processing of network portion 301 of frame 200... the data portion 302 of frame 200 is being processed by the server application." The data portion is forwarded to the application (col. 2, ln. 5-10) while the network portion is still being verified. This directly teaches "initializing, by the application layer, data processing... after receiving the first portion... and before receiving a second portion.");
canceling processing the data in response to at least one error being detected in the first data (e.g. Col. 5, ln. 50-60 describes that the frame verification unit (304) determines if the frame is reliable. "If frame verification unit 304 detects an error condition of some sort, further processing of the request data is terminated." This teaches "in response to at least one error being detected... alerting the application layer to cancel processing."); or finalizing receiving the first data and (ii) performing a transport layer error detection in response to no error being detected in the first data (e.g. Col. 5, ln. 55-65 describes that if the frame is verified as reliable, the frame formatter (308) formats the requested data for transmission. The verification process itself (col. 5, ln. 30-35) involves checking the network layer header (e.g., IP) and transport layer header (e.g., TCP) for errors, which teaches "perform a transport layer error detection." Successful verification implies finalization of reception).
While Elnozahy's system performs the functions of error detection and cancellation, it does not explicitly recite this specific inter-layer alerting as a method step (e.g. "the network layer alerting the application layer" and "the network layer alerting the transport layer.").
However, Lariviere's system includes a message analyzer (414, Fig. 4B) that evaluates received data messages to determine if portions were sent optimistically (par. [0146]). Based on this analysis, a message processor (416) takes an action (par. [0147]), such as canceling the message or allowing it to proceed. This teaches the concept of implementing a defined control flow (like an alert pathway) based on an analysis of message portion integrity. Furthermore, Lariviere explicitly teaches canceling or rolling back processing of optimistically sent messages (par. [0077], [0082]). This reinforces and elaborates on the cancellation action mentioned in Elnozahy.
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the system of Elnozahy with the teachings of Lariviere in order to manage incomplete or speculative data flows in a high-performance context (like an electronic exchange, which is a type of server system).
Claim 22: Elnozahy and Lariviere teach the method of claim 21, but fail to teach performing the error-correction process comprises rolling back an application state to a prior state. Lariviere, however, teaches mitigating optimistic behavior which can involve causing the optimistic message to be "dropped or discarded" (par. [0086]) and the general concept of transaction state management. In the field of fault-tolerant computing and database systems, rolling back to a checkpoint is a standard, well-known technique for recovering from an aborted operation. It would have been obvious to employ this conventional technique to efficiently implement the "canceling processing" taught by both references. See, e.g., In re Venner, 262 F.2d 91 (C.C.P.A. 1958) (application of a known technique to a similar problem in an analogous art is obvious).
Claim 23: Elnozahy and Lariviere teach the method of claim 22 further comprising, before initializing the data processing, establishing an application checkpoint, wherein performing the error-correction process comprises rolling back an application state to the application checkpoint. Lariviere, however, teaches mitigating optimistic behavior which can involve causing the optimistic message to be "dropped or discarded" (par. [0086]) and the general concept of transaction state management. In the field of fault-tolerant computing and database systems, rolling back to a checkpoint is a standard, well-known technique for recovering from an aborted operation. It would have been obvious to employ this conventional technique to efficiently implement the "canceling processing" taught by both references. See, e.g., In re Venner, 262 F.2d 91 (C.C.P.A. 1958) (application of a known technique to a similar problem in an analogous art is obvious).
Claim 24: Elnozahy and Lariviere teach the method of claim 23, wherein establishing the application checkpoint is in response to receiving the first portion of the first data. Lariviere, however, teaches mitigating optimistic behavior which can involve causing the optimistic message to be "dropped or discarded" (par. [0086]) and the general concept of transaction state management. In the field of fault-tolerant computing and database systems, rolling back to a checkpoint is a standard, well-known technique for recovering from an aborted operation. It would have been obvious to employ this conventional technique to efficiently implement the "canceling processing" taught by both references. See, e.g., In re Venner, 262 F.2d 91 (C.C.P.A. 1958) (application of a known technique to a similar problem in an analogous art is obvious).
Claim 25: Elnozahy and Lariviere teach the method of claim 22 further comprising disregarding the first data after rolling back the application state. Lariviere, however, teaches mitigating optimistic behavior which can involve causing the optimistic message to be "dropped or discarded" (par. [0086]) and the general concept of transaction state management. In the field of fault-tolerant computing and database systems, rolling back to a checkpoint is a standard, well-known technique for recovering from an aborted operation. It would have been obvious to employ this conventional technique to efficiently implement the "canceling processing" taught by both references. See, e.g., In re Venner, 262 F.2d 91 (C.C.P.A. 1958) (application of a known technique to a similar problem in an analogous art is obvious).
Claim 26: Elnozahy and Lariviere teach the method of claim 22 further comprising re-attempting processing the first data after rolling back the application state. Lariviere, however, teaches mitigating optimistic behavior which can involve causing the optimistic message to be "dropped or discarded" (par. [0086]) and the general concept of transaction state management. In the field of fault-tolerant computing and database systems, rolling back to a checkpoint is a standard, well-known technique for recovering from an aborted operation. It would have been obvious to employ this conventional technique to efficiently implement the "canceling processing" taught by both references. See, e.g., In re Venner, 262 F.2d 91 (C.C.P.A. 1958) (application of a known technique to a similar problem in an analogous art is obvious).
As per claims 35-36, the claims features rejected similarly to claims 22-26.
Claim 27: Elnozahy and Lariviere teach the method of claim 21, but fail to teach performing the error-correction process comprises ceasing data processing on the first data. However, these claim variants (ceasing processing, re-initializing to a safe state) are merely conventional and obvious alternatives or implementations of the broader "cancel processing" step taught by Elnozahy and reinforced by Lariviere. Choosing a specific type of cancellation is a matter of routine design choice.
As per claim 37, the claimed features are rejected similarly to claim 27 above.
Claim 28: Elnozahy and Lariviere teach the method of claim 21, but fail to teach performing the error-correction process comprises re- initializing the reception device to a safe state. However, Lariviere teaches that upon detection of improper optimistic messaging behavior, the system takes defined corrective actions. While Lariviere discusses actions such as discarding messages, disconnecting connections, and delaying processing, it also provides a broader teaching relevant to system recovery. Furthermore, Lariviere teaches that the system may implement "fault tolerance" and manage system state to handle erroneous conditions (¶[0053]). More specifically, Lariviere teaches that when optimistic messaging is detected, the system may need to "mitigate the spread of problems" and ensure the system operates as intended (¶[0036]). One of ordinary skill in the art would recognize that returning a system to a known safe state is a conventional and well-known technique for handling error conditions and preventing error propagation in fault-tolerant systems. Therefore, a person of ordinary skill in the art would understand that one standard method for handling an error condition that requires termination of processing is to re-initialize the affected components or the entire device to a known safe state. This is a fundamental technique in system design, embedded systems, and fault-tolerant computing.
Claim 29: Elnozahy and Lariviere teach the method of claim 21 further comprising: in response to at least one error being detected in the first data in the transport error detection, the transport layer alerting the application layer to cancel processing the data. For instance, Elnozahy teaches that upon successful verification, the system proceeds to format and send a response (col. 5, ln. 60-65), which inherently involves finalizing reception and processing. Performing additional error detection at the transport layer is a standard part of network protocol stacks. Lariviere discusses error detection (e.g., TCP checksum) as a trigger for action (par. [0077]). Coordinating finalization actions between layers is a routine systems integration task. Therefore, adding these details is obvious.
Claim 30: Elnozahy and Lariviere teach the method of claim 21 but fail to further comprising: in response to no error being detected in the first data in the transport error detection, the transport layer alerting to (i) finalize the data processing and (ii) commit a data-processing result. However, Elnozahy teaches that upon successful verification, the system proceeds to format and send a response (col. 5, ln. 60-65), which inherently involves finalizing reception and processing. Performing additional error detection at the transport layer is a standard part of network protocol stacks. Lariviere discusses error detection (e.g., TCP checksum) as a trigger for action (par. [0077]). Coordinating finalization actions between layers is a routine systems integration task. Therefore, adding these details is obvious.
As per claims 33, 34 and 38-40, the claimed features are rejected similarly to claims 29-30 above.
Claim 31: Elnozahy and Lariviere teach the method of claim 21, but fail to teach that the method is performed by at least one of a field- programmable gate array (FPGA) and an Application-Specific Integrated Circuit (ASIC) of the reception device. However, Elnozahy teaches using an NIC with an embedded processor for local frame processing (col. 4, ln. 55-60). Lariviere explicitly teaches implementing its system using FPGAs or other reconfigurable logic (par. [0052], [0055]). Implementing an obvious method in a known type of high-performance hardware is itself obvious. See In re Iwahashi, 888 F.2d 1370 (Fed. Cir. 1989).
As per claims 32-37 (Semiconductor Device / Circuit Blocks): These claims merely recite the method of claim 21 in apparatus form as a set of circuit blocks. Since the method is obvious, and it was well-known to implement logical functions in dedicated hardware (e.g., the NIC in Elnozahy, the FPGA in Lariviere), claiming the obvious method as a hardware apparatus is also obvious. See In re Mills, 916 F.2d 680 (Fed. Cir. 1990) (when a method is obvious, an apparatus capable of performing that method is also obvious).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GUERRIER MERANT whose telephone number is (571)270-1066. The examiner can normally be reached Monday-Friday 8:00 Am - 5:00 PM.
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, Mark Featherstone can be reached at 571-270-3750. 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.
/GUERRIER MERANT/Primary Examiner, Art Unit 2111 2/6/2026