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 Amendment
The amendments filed on 05/04/2026 have been considered. Claims 1, 4, 8, 11, 15, and 18 have been amended. Thus, claims 1-20 are pending and presented for examination.
Applicant's arguments filled on 05/04/2026 with respect to the 35 U.S.C. 101 rejections have been fully considered and are persuasive. Thus, the 35 U.S.C. 101 rejections have been withdrawn.
Applicant's arguments filled on 05/04/2026 with respect to the 35 U.S.C. 112(b) rejections have been fully considered and are persuasive. Thus, the 35 U.S.C. 112(b) rejections have been withdrawn.
Applicant's arguments filled on 05/04/2026 with respect to the 35 U.S.C. 103 rejections have been fully considered but are moot because of the new ground of rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As per claims 1, 8, and 15, these claims call for "wherein the enhanced networking interface performs initial processing on initial data to generate the encoded data, wherein the initial processing comprises converting the video stream from an analog format to a digital format, and wherein the enhanced networking interface obtains the initial data from the local data source via remote direct memory access (RDMA)". However these limitations are not supported by the specification.
These limitations require that the enhanced networking interface obtain the raw analog video stream from the local data source via RDMA, and then itself convert the video stream from an analog format to a digital format to generate the encoded data. This means that the claim calls for the encoding to be performed inside the enhanced networking interface. However, the specification describes the opposite arrangement: per paragraph [0039], the data is obtained by the local data sources in an analog format and encoded to a digital format by a video management service (VMS) application in the local data source, and it is this already-encoded data that is transmitted to the enhanced networking interface. There is no support in the specification for the enhanced networking interface performing the analog to digital conversion, generating the encoded data, or obtaining un-encoded analog data from the local data source via RDMA. Since the specification fails to support these limitations, these limitations are found to be new matter and therefore rejected under U.S.C. 112(a).
As per claims 2-7, 9-14, and 16-20, these claims are rejected as being dependent on a claim rejected under U.S.C. 112(a).
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Tork et al. ("Lynx: A SmartNIC-driven Accelerator-centric Architecture for Network Servers", hereinafter "Tork") in view of Titus et al. (US 20100026802 A1), hereinafter "Titus” further in view of Kim et al, (“GPUnet: Networking Abstractions for GPU Programs”, hereinafter “Kim”)
Claim 1
Tork teaches: A system, comprising: (page 117, Abstract, "We propose Lynx, an accelerator-centric network server architecture that offloads the server data and control planes to the SmartNIC, and enables direct networking from accelerators via a lightweight hardware-friendly I/O mechanism.") a processor; (Page 120, "We observe that the resulting implementation does not run any application logic on the CPU, besides a series of GPU kernel invocation commands. In fact, the accelerated system design which minimizes the CPU involvement is not specific to systems with GPUs") a processing system operatively connected to the processor;
PNG
media_image1.png
175
448
media_image1.png
Greyscale
(Figure 2 depicts the Accelerator (processing system) operatively connected to the processor (CPU)) a processing system storage; (Page 122, "An mqueue consists of two producer-consumer ring buffers called receive (RX) and transmit (TX) queues, and their respective notification and completion registers for producer-consumer synchronization. Mqueues and their status registers are located in accelerators' local memory.") an enhanced networking interface operatively connected to the processing system, (Page 117, Abstract, "We propose Lynx, an accelerator-centric network server architecture that offloads the server data and control planes to the SmartNIC.") wherein the enhanced networking interface is programmed to: obtain encoded data (…) from a (…) data source, (…) (Page 118, "The SNIC runs a full network stack and a generic network server that listens on the application-specified ports…" Page 127, "A client sends 28×28 grayscale images from the standard MNIST dataset…") perform a metadata analysis of the encoded data to obtain metadata associated with the encoded data; (Page 124, "The metadata occupies 4 bytes, and includes (1) total message size, (2) error status from the Bluefield (if a connection error is detected), and (3) notification register (doorbell) for the queue. The accelerator polls this notification register while waiting for a new message." EN: This denotes the system analyzing the incoming encoded data (the packet) to find its length (total message size).) store the metadata in the processing system storage, (Page 122, "Mqueues and their status registers are located in accelerators' local memory." Page 124, "To reduce the number of RDMA operations for updating the mqueue, we append control metadata to each message." EN: this denotes metadata which get sent to the mqueues which reside in the GPU's memory (processing system storage).) wherein the processing system is programmed to: obtain the metadata from the processing system storage; (Page 124, "The accelerator polls this notification register while waiting for a new message." EN: The GPU polls the message queue in its local memory to retrieve the message and its metadata.) perform a computer vision (CV) inferencing on the encoded data using the metadata to obtain inferencing data, (Page 118, "We evaluate the system performance and scalability using microbenchmarks and realistic applications. For example, we develop a LeNet [27] model-serving server for digit recognition, implemented entirely on the GPU." Page 127, "and the server returns the recognized digit by running the LeNet inference on the GPU." EN: the recognized digit returned by the server denotes the inferencing data.)
Tork does not distinctly disclose: the data source being a "local data source"; the encoded data being "associated with a video stream"; "wherein the enhanced networking interface performs initial processing on initial data to generate the encoded data, wherein the initial processing comprises converting the video stream from an analog format to a digital format"; "wherein the CV inferencing comprises one of a list consisting of: facial recognition processing using machine learning, object detection processing, three-dimensional image generation, and road condition monitoring"; and "provide (…) data to the processor; and perform, by the processor, a remediation action based on the (…) data."
However, Titus teaches: a "local data source" (Para 189, "In block 41, the computer system 11 obtains source video from the video sensors 14 and/or the video recorders 15." Para 130, "Each video sensor 14 can be coupled to the computer system 11 using, for example, a direct connection (e.g., a firewire digital camera interface) or a network.") encoded data "associated with a video stream" (Para 77, "a video encoder (block 224) that compresses raw digital video for video streaming or storage using any available compression scheme (JPEG, MJPEG, MPEG1, MPEG2, MPEG4, H.263, H.264, Wavelet, or any other)" Para 131, "The system may also modulate the bandwidth and quality of video streamed over a network by controlling a video encoder and streaming protocol.") [wherein the enhanced networking interface] “performs initial processing on initial data to generate the encoded data, wherein the initial processing comprises converting the video stream from an analog format to a digital format” (Para 77, "Block 221 represents a raw (uncompressed) digital video input. This can be obtained, for example, through analog to digital capture of an analog video signal or decoding of a digital video signal." Para 101, "Block 254 is a standard analog camera with no intelligent components on board; but it is connected to an IP video management platform (block 256) that performs video digitization and compression as well as content analysis and activity inference." EN: Titus's video digitization of the analog camera signal denotes converting the video stream from an analog format to a digital format, and the subsequent compression denotes generating the encoded data from that initial data. Titus further teaches that these components "may be implemented on any processing hardware (general purpose processor, microcontroller, DSP, ASIC, FPGA, or other processing device)" (Para 79), i.e., on programmable hardware of the same type as Tork's FPGA-based enhanced networking interface (Tork, Page 119, "Each packet passing through the NIC is processed by the FPGA logic customized by the programmer.").) "wherein the CV inferencing comprises one of a list consisting of: facial recognition processing using machine learning, object detection processing, three-dimensional image generation, and road condition monitoring"; (Para 191, "In block 51, objects are detected via movement. Any motion detection algorithm for detecting movement between frames at the pixel level can be used for this block." Para 192, "In block 52, objects are detected via change. Any change detection algorithm for detecting changes from a background model can be used for this block." Para 199, "In block 56, each object is classified. … Classification can be performed by a number of techniques, and examples of such techniques include using a neural network classifier …" EN: The claim requires the CV inferencing to comprise only one member of the recited list. Titus's content analysis detects objects in the video via movement and via change and classifies the detected objects, which denotes object detection processing.) “provide (…) data to the processor;” (Para 87, "The content analysis module (block 235) on the video processing platform (block 232) generates primitives that are transmitted to the back-end processing platform (block 239).") “and perform, by the processor, a remediation action based on the (…) data." (Abstract, "The system can undertake a response, such as an alarm, based on extracted event occurrences.")
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine Tork's method of acquiring inferencing data with Titus's teachings of locally sourced video stream data, of object detection processing performed on the video data, and of providing the data (generated from locally sourced data) to the processor and the processor performing a remediation action. Combining the teachings would create a system in which Tork's processing system executes Titus's object detection processing as the CV inferencing on video stream data obtained from a local source, and in which the system processor takes in the resulting inferencing data and performs a remediation action.
The motivation for doing so would be to enable the system to intelligently adapt its operational parameters and resource allocation based on locally sourced data. (Para 109, "In general, alerts may be used for a variety of command and control functions, which may further include, but are not limited to, controlling image enhancement software … and controlling other sensors.") Executing Titus's object detection processing on Tork's GPU-based processing system would further allow the compute-intensive video content analysis to keep pace with the continuous video input stream, enabling the system to generate real-time remediation actions. (Para 149, "Real-time extraction of the video primitives from the video stream is desirable to enable the system to be capable of generating real-time alerts, and to do so, since the video provides a continuous input stream, the system cannot fall behind.")
Further, before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to implement Titus's video digitization and compression at Tork's FPGA-based enhanced networking interface, such that the enhanced networking interface performs the initial processing that generates the encoded data. Titus suggests implementing these components on an FPGA or other processing device (Para 79), and Tork's Innova enhanced networking interface is exactly such an FPGA that processes each packet passing through it (Page 119). The motivation for doing so would be to free the host and processing system resources by implementing these services on the specialized networking hardware which has less performance cost. (Tork, Page 118, "At the same time, specialized SNIC cores, which are less efficient for general-purpose computations, are sufficient to drive hardware-accelerated network services with negligible performance cost.") Doing so would also reduce the bandwidth consumed downstream of the interface, since the encoded data is compressed. (Titus, Para 131, "The system may also modulate the bandwidth and quality of video streamed over a network by controlling a video encoder and streaming protocol.")
Tork in view of Titus does not teach: "wherein the enhanced networking interface obtains the initial data from the local data source via remote direct memory access (RDMA)."
However, Kim teaches: "wherein the enhanced networking interface obtains the initial data from the local data source via remote direct memory access (RDMA)." (Page 203, Section 3.1, "Remote Direct Memory Access (RDMA) allows remote peers to read from and write directly into application buffers over the network." Page 202, "the NIC can place network packets directly in local GPU memory." Page 206, Section 5.2, "The NIC performs all low-level packet management tasks, assembles application-level messages and stores them directly in application memory." Page 210, Section 7.2, describing the face verification workload in which the client reads "a (random) 136x136 grayscale image" from a file and performs "Send verification request to server", whereupon the RDMA-capable NIC delivers the image data directly into the server's memory. EN: Kim denotes a networking interface (the RDMA-capable NIC) that obtains source image data from the data source over an RDMA transport and places it directly into application memory without host processor involvement. Kim is directed to the same accelerator-centric network servers as Tork; Tork cites Kim as reference [26] (Page 121) and adopts Kim's benchmark (Page 128, Section 6.4, "Face Verification server benchmark has been used in prior works [26] for measuring GPU-side network I/O performance.").)
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to configure the enhanced networking interface of Tork in view of Titus to obtain the initial data from Titus's local data source via RDMA, as taught by Kim. Combining the teachings would create a system in which the RDMA-capable enhanced networking interface obtains the source video data directly from the local data source's memory for its initial processing. Tork's enhanced networking interface already contains the hardware required for this acquisition. (Tork, Page 118, "For remote access, the SNIC uses its internal hardware-accelerated RDMA engine to efficiently read from/write to the mqueues via one-sided RDMA.")
The motivation for doing so would be to eliminate redundant data copies and remove the processor from the data-acquisition path, thereby increasing performance. (Kim, Page 202, "Direct transfers between the NIC and GPU eliminate redundant PCIe transfers and data copies to system memory, improving data transfer throughput and reducing latency …" Page 201, "Native GPU networking cuts the CPU out of GPU-NIC interactions, simplifying code and increasing performance.") By obtaining the data via RDMA, the continuous video input stream can be ingested at high bandwidth in real time, which Titus teaches is necessary so that "the system cannot fall behind." (Titus, Para 149.)
Claim 2
Tork in view of Titus teaches all the limitations of claim 1, Tork further teaches:
wherein the processing system comprises a graphics processing unit (GPU). (Page 118, “We prototype Lynx on a system with multiple local and remote NVIDIA GPUs, as well as one Intel Visual Compute Accelerator” EN: Tork describes a system where the “processing system” referred to as the “accelerator” in the text consists of graphics processing units (GPUs).
Claim 3
Tork in view of Titus teaches all the limitations of claim 2, Tork further teaches:
wherein the processing system storage comprises GPU direct storage. (Page 118, “For remote access, the SNIC uses its internal hardware accelerated RDMA engine to efficiently read from/write to the mqueues via one-sided RDMA.” Page 122, “For example, peer-to-peer GPU access is readily available via GPUdirectRDMA [38] in NVIDIA GPUs” EN: Paragraph 44 of the instant application states that “GPU direct storage” as a storage that allows for a “direct connection” via RDMA “without requiring the use of the compute resource set [CPU].” This is functionally the same as in Tork’s teaching; which denotes accessing GPU memory using GPUDirect RDMA. )
Claim 4
Tork in view of Titus teaches all the limitations of claim 1, Tork further teaches:
wherein the enhanced networking interface accesses the processing system storage via the RDMA, (Page 122, “It runs on the SNIC, and uses one-sided RDMA to access the mqueues in the accelerator.”) and wherein the processing system accesses the processing system storage (…). (Page 124, “The accelerator polls this notification register while waiting for a new message.” EN: this denotes an architecture where the MQueues (storage) are located inside the accelerator’s own local memory. The accelerator accesses this storage by “polling” the memory addresses to check for new messages.)
Tork does not disclose “via the RDMA” for the processing system accessing the processing system storage in the same embodiment.However, In the motivation section of Tork’s paper, Tork discusses various GPU-centric server designs, one of which include “GPU-centric” system where the GPU performs RDMA operations itself to enable “higher performance in certain workloads” (Tork, Page 121).
Therefore, before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to incorporate the GPU-initiated RDMA capabilities into the GPU accessing the storage. The motivation for doing so would be to achieve higher performance in certain workloads and improve efficiency. Page 121, “whereas GPUrdma implements full support for RDMA verbs. These works show that the GPU-centric design enables higher performance in certain workloads, is more efficient and easier to program than the traditional CPU-driven approach discussed in §3.2.”
Claim 5
Tork in view of Titus teaches all the limitations of claim 1, Titus further teaches:
wherein the encoded data is video stream data generated by a video camera, (Para 130, “The video sensors 14 provide source video to the computer system 11 … Examples of a video sensor 14 include: a video camera…”) and wherein the encoded data is encoded using a video management system (VMS) application. (Para 76, “the video surveillance system… may be on a processing device … on board a video management device such as a digital video camera, network video server, DVR, or Network Video Recorder (NVR)” Para 77, “Block 222 represents a hardware platform housing the main components… The hardware platform may contain other components such as… a video encoder (block 224) that compresses raw digital video for video streaming or storage using any available compression scheme (JPEG, MJPEG, MPEG1…”)
before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine Titus’s video data that’s encoded using a video management system into Tork’s processing system.
The motivation for doing so would be enable the processing system to ingest and analyze encoded video data and thus provide services to the end user. Para 73, “The system is capable of analyzing video data from live sources or from recorded media. … The system may be used to produce, for example, security or market research reports that can be tailored according to the needs of an operator…“
Claim 6
Tork in view of Titus teaches all the limitations of claim 1, Titus further teaches:
wherein the metadata comprises timestamps for the video stream data. (Para 202, “The event discriminator checks all video primitives being generated according to FIG. 5 and determines if any video primitives exist which have the following properties: a timestamp between 9:00 a.m. and 5:00 p.m.”)
before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine Titus’s timestamps data into Tork’s processing system.
The motivation for doing so would be to enable efficient analysis on the data. Page 232, “The video content can be reanalyzed with the additional embodiment in a relatively short time because only the video primitives are reviewed and because the video source is not reprocessed. This provides a great efficiency improvement over current state-of-the-art systems.”
Claim 7
Tork in view of Titus teaches all the limitations of claim 1, Tork further teaches:
wherein the enhanced networking interface comprises: a network interface card, a field programmable gate array (FPGA), and (…). (Page 123, “Implementation We prototype Lynx using two SNICs: Mellanox Bluefield with ARM cores and Mellanox Innova Flex with an FPGA (see §2 for details))
Tork does not disclose “a data processing unit” in the same embodiment.
However, Tork discloses “a data processing unit” in a different embodiment. (Page 119, “Processor-based SNIC … Figure 2b shows the architecture of the Mellanox Bluefield SNIC we use in this paper. It features eight 64-bit ARM A72 cores running at 800 MHz, connected to the NIC ASIC and to the host via an internal PCIe switch.” EN: Tork discloses the Mellanox BlueField SmartNIC comprising ARM processors and FPGA. These components process data packets and application messages, therefore this reads on the broadest reasonable interpretation of “a data processing unit”.)
Tork discloses two architectures of an enhanced networking interface (Page 119, “In this paper we use two SNIC architectures:”. EN: Tork denotes the two architectures: Innova Flex comprises a generic Network Interface card (NIC) combined with an FPGA and Bluefield comprises a generic NIC combined with a DPU (Arm cores) (read section 2 background on page 119 for more details.)
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the FPGA-based networking interface (Innova) to include the data processing unit (ARM cores) from Bluefield.
The motivation for doing so would be to efficiently handle accelerator management tasks using specialized cores, thereby freeing up the main host processor. Page 118, “At the same time, specialized SNIC cores, which are less efficient for general purpose computations, are sufficient to drive hardware-accelerated network services with negligible performance cost.”
Claim 8
Tork teaches: A method for managing hardware resources, comprising: (Lynx runs on the SNIC and serves requests from clients via TCP/UDP. It manages accelerators connected via PCIe in the same server and via RDMA-capable NICs in other servers.)
The rest of claim 8 recite identical limitations to method claim 1. Therefore claim 8 is rejected under the same rationale as claim 1.
Claim 9-14
Claims 9-14 are method claims that recite the same limitations of claims 2-7, therefore, claims 9-14 are rejected under the same rationale as claim 2-7.
Claim 15
Titus teaches: A non-transitory computer readable medium (Para 42, “A "computer-readable medium" may refer to any storage device used for storing data accessible by a computer. Examples of a computer-readable medium may include: a magnetic hard disk; a floppy disk; an optical disk…”) comprising computer readable program code, (Para 129, “. A computer system 11 comprises a computer 12 having a computer-readable medium 13 embodying software to operate the computer 12 according to the invention.) which when executed by a computer processor enables the computer processor (Para 40, “A "computer" may refer to one or more apparatus and/or one or more systems that are capable of accepting a structured input, processing the structured input according to prescribed rules, and producing results of the processing as output.”) to perform a method for managing information handling systems, the method comprising: (Abstract, “A video surveillance system is set up, calibrated, tasked, and operated. The system extracts video primitives and extracts event occurrences from the video primitives using event discriminators. The extracted video primitives and event occurrences may be used to create and define additional video analytic rules. The system can undertake a response, such as an alarm, based on extracted event occurrences.”)
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to combine the work of Tork and Titus in order to use non-transitory computer hardware to run their system.
The motivation for doing so would be to allow the system to be “capable of processing the video data” (para 73, Titus).
The rest of claim 15 recite identical limitations to method claim 1. Therefore claim 15 is rejected under the same rationale as claim 1.
Claim 16-20
Claim 16-20 are non-transitory computer readable medium claims that recite the same limitations as claim 2-5 and 7. Therefore, claims 16-20 are rejected under the same rationale as claim 2-5 and 7.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NAYMUR RAHMAN ALI whose telephone number is (571)272-0007. The examiner can normally be reached Mon-Fri. 9:30-6:30 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, Alexey Shmatov can be reached at (571)270-3428. 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.
/NAYMUR RAHMAN ALI/Examiner, Art Unit 2123
/ALEXEY SHMATOV/Supervisory Patent Examiner, Art Unit 2123
Prosecution Insights