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 .
Detailed Action
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 03/11/2026 has been entered.
Claims 1-20 are presented for the examination.
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 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of copending Application No 17/945,039. Although the claims at issue are not identical, they are not patentably distinct from each other because both computer systems comprise substantially the same elements.
copending Application No 17/945,039 teaches one or more application processors; one or more direct dataflow compute-in-memory accelerators coupled to the one or more application processors by one or more communication interfaces( one or more application processors; one or more direct dataflow compute-in-memory accelerators coupled to the one or more application processors by one or more communication interfaces)
wherein the one or more direct dataflow compute-in-memory accelerators execute an accelerator task on accelerator task data to generate an accelerator task result( wherein the one or more direct dataflow compute-in-memory accelerators execute an accelerator task on accelerator task data to generate an accelerator task result)
an accelerator driver to stream the accelerator task data from the one or more application processors to the one or more direct dataflow compute-in-memory accelerators and to return the accelerator task result to the one or more application processors( an accelerator driver to stream the accelerator task data from the one or more application processors to the one or more direct dataflow compute-in-memory accelerators and to return the accelerator task result to the one or more application processors).
The difference between claims 1,9, 17 of the copending application and this case is he one or more direct dataflow compute-in-memory accelerators each including a plurality of memory regions and a plurality of processing regions, wherein intermediate results from a given processing region pass through a given memory region to another given processing region for use in further computation without writing out to a separate memory, plurality of compute cores, and an inter- laver communication (ILC) unit, the ILC unit configuration to synchronize data movement between one or more first compute cores and one or more second compute cores of the plurality of compute cores, the one or more first compute cores producing given data and the one or more second compute cores consuming the given data/ wherein the plurality of processing regions are interleaved between the plurality of memory regions, and wherein the plurality of processing regions being configurable for core-to-memory dataflow from one or more of the plurality of compute cores within each of the plurality of processing regions to adjacent ones of the plurality of memory regions, and wherein . It would have been obvious to one of the ordinary skill level in the art to include above feature because this improves speed, efficiency and accuracy of many neural network implementations and provides need exists to transparently leverage the many advantages of in-memory computational processing without necessitating hardware-specific libraries at the high-language level which users typically utilize when creating models for neural networks.
this is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Rejections-35 USC 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) and further in view of Tan (US 20110035522 A1).
As to claim 1, Zheng teaches one or more application processors; one or more direct dataflow compute-in-memory accelerators coupled to the one or more application processors by one or more communication interfaces( acceleration engine 700 further includes DMA engines 746a-746d that can move data between the accelerators 702a-702n, DRAM controllers 742a-742k, and I/O controllers 744a-744p. In the illustrated example, the acceleration engine 700 includes d DMA engines 746a-746d. In some implementations, the DMA engines 746a-746d can be assigned to specific tasks, such as moving data from the DRAM controllers 742a-742d to the accelerators 702a-702n, or moving data between the I/O controllers 744a-744p and the accelerators 702a-702n, col 17, ln 3-14/ The processor bus can connect the acceleration engine 700 to I/O devices such as, for example, input and output devices, memory controllers, storage devices, and/or network interface cards, among other things. In some examples, the I/O controllers 744-744p can enable the acceleration engine 700 to act as an I/O device for a host processor. For example, the acceleration engine 700 can be the recipient of input data from the host processor, and a command indicating an operation to be performed on the input data (e.g., a particular computation or analysis), col 16, ln 37-48/ compiler running on a host processor, col 9, ln 34-35/ The illustrated host system 600 is an example of a computing device, and includes a processor 602, a processor memory 604, at least one storage device 606, various Input/Output (I/O) devices 608, col 12, ln 55-65/ he host system 600 can execute a driver 622, which can also be referred to as a device driver or runtime driver, that manages the acceleration engine 612. The driver 622 can provide an interface between applications executing on the host system 600 (or on another host system) and the acceleration engine 612. For example, the driver 622 can provide an Application Program Interface (API) that defines functions for feeding input data to the acceleration engine 612 and defining the operation to perform on the input data, col 15, ln 22-35),
the one or more direct dataflow compute-in-memory accelerators each including a plurality of memory regions and a plurality of processing regions( the acceleration engine's local memory, col 14, ln 55-56/ acceleration engine 700 further includes DMA engines 746a-746d that can move data between the accelerators 702a-702n, DRAM controllers 742a-742k, and I/O controllers 744a-744p. In the illustrated example, the acceleration engine 700 includes d DMA engines 746a-746d. In some implementations, the DMA engines 746a-746d can be assigned to specific tasks, such as moving data from the DRAM controllers 742a-742d to the accelerators 702a-702n, col 17, ln 3-14/ Having the memory banks 814 be independently accessible can increase the efficiency of the accelerator 802, col 18, ln 8-12/ The processing engine array 810 can output intermediate results, which represent the outputs of individual layers of the neural network. In some cases, the activation engine 816 and/or pooling engine 818 may be enabled for computations called for by certain layers of the neural network. The accelerator 802 can store the intermediate results in the memory subsystem 804 for inputting into the processing engine array 810 to compute results for the next layer of the neural network. The processing engine array 810 can further output final results from a last layer of the neural network. The final results can be stored in the memory subsystem 804 and then be copied out to host processor memory or to another location, col 21, ln 2-16/ Fig.7/Fig.8).
wherein the one or more direct dataflow compute-in-memory accelerators execute an accelerator task on accelerator task data to generate an accelerator task result; and an accelerator driver to stream the accelerator task data from the one or more application processors to the one or more direct dataflow compute-in-memory accelerators and to return the accelerator task result to the one or more application processors( FIG. 6, the host system 600 can execute a driver 622, which can also be referred to as a device driver or runtime driver, that manages the acceleration engine 612. The driver 622 can provide an interface between applications executing on the host system 600 (or on another host system) and the acceleration engine 612. For example, the driver 622 can provide an Application Program Interface (API) that defines functions for feeding input data to the acceleration engine 612 and defining the operation to perform on the input data. In this and other examples, the driver 622 can configure the acceleration engine 612 to perform the operation. For example, the driver 622 can identify a neural network that the acceleration engine 612 is to execute, as well as the location in the processor memory 604 or on the storage device 606 where the compiled code 644 for the neural network is located. The driver 622 can further load into the acceleration engine 612 or cause the acceleration engine 612 to load the compiled code 644, can load or cause the acceleration engine 612 to load the input data on which the neural network is to operate, and/or can cause the acceleration engine 612 to begin executing on the input data. Once the acceleration engine 612 has finished, the acceleration engine 612 can notify the driver 622, and the driver 622 can deliver a result back to the application that requested the result, col 15, ln 21-46).
Gao teaches wherein the plurality of processing regions are interleaved between the plurality of memory regions, and wherein the plurality of processing regions being configurable for core-to-memory dataflow from one or more of the plurality of compute cores within each of the plurality of processing regions to adjacent ones of the plurality of memory regions, and wherein, the plurality of processing regions are interleaved between the plurality of memory regions, and wherein the plurality of processing regions being configurable for core-to-memory dataflow from one or more of the plurality of compute cores within each of the plurality of processing regions to adjacent ones of the plurality of memory regions ( a processor core is on a forwarding plane, para[0065], ln 15-17/ the processor core (also referred to as a forwarding core) belongs to a forwarding plane, and is mainly configured to forward and process a packet in a data flow, para[0021], ln 14-18/FIG. 1 is a schematic scenario diagram before and after a pipeline is spread according to an embodiment of the present disclosure. As shown in FIG. 1, initially, a first processor core receives a packet flow, performs traffic detection and all three processing actions, and spreads an action 3 when determining, according to a traffic detection result, that a preset pipeline spreading condition is met. In one embodiment, for each packet, the first processor core enqueues the packet into a queue after completing an action 2, and a second processor core obtains the packet from the queue and performs the action 3 on the packet. Further, when the action 3 is spread, the first processor core spreads the action 2 if detecting that traffic is still overloaded. After the action 2 is spread, the first processor core enqueues the packet into a queue after completing an action 1, and the second processor core performs the action 2 on the packet. After the second processor core completes the action 2, because the action 3 is still spread, the second processor core enqueues the packet into a queue, so that a next processor core performs the action 3. The action 2 and the action 3 may be performed by a same second processor core or different second processor cores, para[0089] to para[0090]/ Cores in the multi-core processor may share one or more storage areas in a memory, and the storage area is configured to cache a to-be-processed packet. In one embodiment, the storage area may be managed by using multiple queues, and it can be understood that an element enqueued into a queue is actually stored in a storage area corresponding to the queue, para[0168], ln 16-24/ the first processor core modifies spreading attributes of the N processing actions that are not spread, so as to indicate that the processing actions are spread, and then transfers a packet to the second processor core by using a storage area, and the second processor core performs, on the packet, a processing action that is spread. The storage area is configured to store a packet on which a processing action corresponding to the storage area is to be performed, para[0038], ln 1-10).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng with Gao to incorporate above feature because this allows avoids a waste of processing resources to some extent when traffic is relatively low, and can also better support data flow processing when traffic is relatively high.
Ghosh teaches the one or more direct dataflow compute-in-memory accelerators each including a plurality of memory regions and a plurality of processing regions in accelerator, wherein intermediate results from a given processing region pass through a given memory region to another given processing region for use in further computation without writing out to a separate memory/ the processing regions is interleaved between the plurality of memory regions, and wherein the processing regions being configurable for core-to-memory dataflow from one or more of the plurality of compute cores within each of the processing region to adjacent ones of the plurality of memory regions ( methods enable hardware accelerators, para[0036], ln 21-26/ The accelerator includes: a plurality of processor cores, each assigned to a pipeline stage of a plurality of pipeline stages and configured to process the pipeline stage, wherein the plurality of pipeline stages together comprise the computational graph of a deep learning inference neural network and the plurality of processor cores are configured to: receive a plurality of input data units at different times; as a data unit arrives at a processor core, process the data unit in a pipeline stage assigned to the processor core and output the processed data to a next pipeline stage and associated processor core until the data unit is processed through the plurality of the pipeline stages, para[0013/ . Accelerator 65 includes a memory unit 62 and a chip 64. While the memory unit 62 and the chip 64 are shown as separate components, they can be integrated as one component or as part of an integrated system. The chip 64 can include one or more compute units 66, 68 and 70 designed to handle neural network, deep learning, CNNs, machine learning and/or other AI processing tasks. In one embodiment, compute unites 66, 68 and 70 can be processor cores similar to processor cores 26, 28 and 30 in embodiment of FIG. 1., para[0051]/ FIG. 5 illustrates an AI accelerator 90 utilizing a spatial model of computation and the semantic pipeline processing as described earlier. The accelerator 90 can be a chip designed to handle AI processing tasks, such as deep learning inference processing. The accelerator 90 can include memory regions R1, R2 and R3 and processing resources, such as processing cores 92, 94 and 96. Fewer or more memory regions and/or processing resources are possible depending on the implementation of an embodiment. Memory regions can store AI processing data locally and near the hardware resources intended to process them. In the example shown, memory region R1 can store activation map 98 and deep learning weight W_1, which are to be processed in, or used in processing of other data in processor core 92. Memory region R2 can store activation map 100 and deep learning weight W_2, which are to be processed in or used in processing of other data in processor core 94. Memory region R3 can store activation map 102 and deep learning weight W_3, which are to be processed in, or used in processing of other data in processor core 96, para[0054]/ the accelerator 90 utilizes a semantic pipelining technique and can process the input data as they arrive. Processor core 92 can start processing the input data 18, 20, 22, etc. as they arrive in memory region R1 and output the resulting activation map to the next memory region. Pipeline processing (as described in relation to FIGS. 2A-2E and 3) and data produced by each pipeline stage can move across the memory regions of the accelerator 90 through adjacent and/or physically close memory regions, para[0055], ln 3-15).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Gao with Ghosh to incorporate above feature because this allows low latency and high throughput, thereby reducing resource and power consumption while significantly boosting performance.
Tan teaches a plurality of compute cores, and an inter- laver communication (ILC) unit, the ILC unit configured to synchronize data movement between one or more first compute cores and one or more second compute cores of the plurality of compute cores, the one or more first compute cores producing given data and the one or more second compute cores consuming the given data( In FIG. 8A, the first core 804 and the second core 806 process a plurality of functional blocks 808 using a static scheduling scheme. This implementation is based on the observation that the schedule of each block in a PHY processing pipeline is actually static, i.e ……. Adjacent sub-pipelines from different blocks are connected with a synchronized FIFO 812 that manages the delivery of data between the sub-pipelines 8 10. For example, the synchronized FIFO 812 may be established in one of caches 106, 108 discussed above with respect to FIG. 1. Thus, implementations herein allow different PHY processing blocks 808 to streamline across multiple cores 804, 806 while communicating with one another through one or more shared memory synchronized FIFO queues. For example, if two blocks 808 (e.g., Block 2 and Block 3 of FIG. 8A) are running on different cores 804, 806, their access to the shared FIFO 812 must be synchronized. The traditional implementation of a synchronized FIFO uses a counter to synchronize the writer (producer) and reader (consumer) in what is referred to as a counter-based FIFO (CBFIFO), para[0082]/ IG. 8B illustrates a flowchart of an exemplary process 820 carried out by the producer (e.g., first core 804) for processing digital samples using the synchronized FIFO buffer 812. The process is executed by the PHY module of the SDR stack using multiple cores of a multi-core processor 802, para[0085]/ FIG. 8C illustrates a flowchart of an exemplary process 830 carried out by the consumer (e.g., second core 806) for processing digital samples using the synchronized FIFO buffer 812. The process is executed by the PHY module of the SDR stack using multiple cores of a multi-core processor 802, para[0090]).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao with Tan to incorporate above feature because this achieves the full fidelity of state-of-the-art wireless protocols while using standard operating systems and applications in a real-world environment.
3.Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Tan (US 20110035522 A1)and further in view of Lee(US 20210271680 A1).
As to claim 2, Lee teaches one or more direct dataflow compute-in-memory accelerators receive the stream of accelerator task data and execute the accelerator task on the accelerator task data to generate the accelerator task result without placing a load on the one or more application processors( para[0048]/ para[0059]/ para[0062]/ para[0136], ln 1-15).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao and Tan with Lee to incorporate the above feature because this improves performance in in-memory database scenarios.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Tan (US 20110035522 A1) and further in view of O'Brien( US 20070174828 A1).
As to claim 3, O’Brien teaches the accelerator task calls an accelerator model including nodes and edges for execution on the one or more direct dataflow compute-in- memory accelerators, wherein nodes of the accelerator model are mapped to compute cores of the one or more direct dataflow compute-in-memory accelerators and the compute cores are coupled based on the edges of the accelerator model( The call graph for the program is augmented with the new outlined procedures, if any, and the call graph is partitioned into homogenous units based on the assignment of procedures or portions of the procedures to particular ones of the main core and the accelerators. Instructions may be added to the call graph to orchestrate the flow of control among the various partitions., para[0010], ln 1-10/ The degree of matching of each accelerator may be identified by the program partition engine 228 based on the results of the application of these rules. In addition, the negative characteristics of the accelerators, e.g., constraints and timing requirements, may also be evaluated to generate a decision as to which accelerator, or the main core processor, is to be used to execute the identified procedure. Based on this identification of the accelerator or main core processor, the call graph may be annotated to identify which accelerator or main core processor is to execute that procedure in the call graph, para[0050]).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao and Tan with O’Brien to incorporate the feature of the accelerator task calls an accelerator model including nodes and edges for execution on the one or more direct dataflow compute-in- memory accelerators, wherein nodes of the accelerator model are mapped to compute cores of the one or more direct dataflow compute-in-memory accelerators and the compute cores are coupled based on the edges of the accelerator model because this determines which accelerators, or the main core processor, should execute the function.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Tan (US 20110035522 A1)and further in view of Min( US 20160285722 A1).
As to claim 4, Min teaches one or more memories to store an operating system, one or more applications and the accelerator driver for execution on the one or more application processors( the processor memory 210 may store various data and software used during operation of the computing device 102 such as operating systems, applications, programs, libraries, and drivers, para[0024], ln 3-10/ s a result, the CPU of the network device 106 can be dedicated to other tasks, such as application performance management. For ease of discussion, “graphics processing unit” or “GPU” may be used herein to refer to, among other things, a graphics processing unit, a graphics accelerator, or other type of specialized electronic circuit or device, such as a general purpose GPU (GPGPU) or any other device or circuit that is configured to be used by the network device 106 to accelerate graphics tasks and/or perform other parallel computing operations that would benefit from accelerated processing, such as network traffic monitoring, para[0017], ln 11-25).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao and Tan with Min to incorporate the feature of the accelerator task calls an accelerator model including nodes and edges for execution on the one or more direct dataflow compute-in- memory accelerators because this monitors network traffic at a graphics processing unit (GPU) of the computing device.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Tan (US 20110035522 A1) in view of Min( US 20160285722 A1) and further in view of Drepper(US 20200167139 A1).
As to claim 5, Drepper teaches the accelerator driver: receives the streamed accelerator task data from an application programming interface (API) of the operating system executing one on the one or more application processors and passes the streamed accelerator task data to an application programming interface (API) of the accelerator task executing on the one or more direct dataflow compute- in-memory accelerators; and receives the accelerator task result from the application programming interface (API) of the accelerator task and passes the accelerator task result to the application programming interface (API) of the operating system or a given one of the one or more applications executing on the one or more application processors( When the host processor encounters the portions of the host object code that are accelerated in the computer application, the host processor executes one or more operation calls included in the host object code that cause the OS kernel driver to communicate with the accelerator. The communication may request the accelerator to execute the softcore processor object code. The softcore processor object code may include the one or more instructions that enable interacting with the logic block instantiated by transmitting the representation of hardware logic (e.g., a bitstream that was generated using the HDL code) to the accelerator, para[0028]/ wherein the processing device is further to: receive, by the operating system kernel, a request to perform an operation of the softcore processor object code executing on the accelerator from the host processor in response to the host processor executing an operation call included in the first code to interact with the softcore processor object code; receiving a result from the accelerator in response to the accelerator executing an operation in the logic block that is called by the softcore processor object code using the one or more instructions; and transmitting the result to the host processor, para[0142]).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao and Tan and Min with Drepper to incorporate the above feature because this provides enhanced processing capabilities in part due to parallelization that enables performing multiple operations at the same time.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Tan (US 20110035522 A1) in view of Min( US 20160285722 A1) and further in view of Lee( US 20210271680 A1 A1).
As to claim 6, Lee teaches a given one of the one or more applications executing on the one or more application processors initiates the accelerator task on the one or more direct dataflow compute-in-memory accelerators through the accelerator driver(The in-memory database application 520 can interface with the offloading device driver 530 via offloading APIs 525, para[0078], ln 1-3/ main memory or extended memory directly accessible by the one or more processing units; and a near-memory database accelerator driver configured to receive a request to perform a database operation on source data stored in device memory of a near-memory database accelerator comprising at least one database accelerator engine separate from the one or more processing units, offload the database operation to the near-memory database accelerator for execution by the at least one database accelerator engine separate from the one or more processing units, and receive an indication from the near-memory database accelerator that results of the database operation are available; wherein the main memory or extended memory comprises the device memory of the near-memory database accelerator, para[0005], ln 1-25) .
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao and Tan and Min with Lee to incorporate the above feature because this improves performance in in-memory database scenarios.
Claims 7, 8 are rejected under 35 U.S.C. 103 as being unpatentable over in view of Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Tan (US 20110035522 A1)in view of Min( US 20160285722 A1) and further in view of Khanna( US 20060168590 A1).
As to claim 7, Khanna teaches the accelerator driver is application processor agnostic( a set of OS agnostic drivers is included with the processor system. To provide functionality to these drivers, a set of abstracted functions is provided by the OS agnostic core. The OS agnostic core, like the boot services, provides common functions to the drivers for managing hardware components so that the functionality does not need to be included in each driver, para[0007], ln 17-25).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao, Tan and Min with Khanna to incorporate the above feature because this facilitates the execution of a driver that is bound to the OS agnostic services,
As to claim 8, Khanna teaches the accelerator driver is application programming interface (API) agnostic( para[0031], ln 1-5) for the same reason as to claim 7 above.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Min( US 20160285722 A1) and further in view of RIERA(WO 2021174225 A1).
As to claim 9, Riera teaches accelerator driver is direct dataflow compute- in-memory accelerator agnostic( The HALO framework 14 is provided as an open-ended extensible multi-agent software framework that implements the proposed hardware-agnostic principles and C.sup.2MPI specification for enabling the portable and performance- optimized execution of hardware-agnostic application codes across heterogeneous computing devices. Dual-agent embodiments of the HALO framework 14 include two system agents, i.e., a runtime agent and a virtualization agent, which work asynchronously in a star topology. The runtime agent is responsible for implementing and offering the C.sup.2MPI interface 12, as well as being the crossbar switch for application processes and virtualization agents. The runtime agent also manages system resources, including device buffers, accelerator manifests, kernels, etc. The virtualization agent provides an asynchronous peer that encapsulates hardware-specific compilers, libraries, runtimes, and drivers, para[0034], ln 1-23).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao, Tan and Min with Riera to incorporate the feature of accelerator driver is direct dataflow compute- in-memory accelerator agnostic because this facilitates dynamic plugin of an accelerator onto the network fabric, which can be auto-discovered and utilized by applications.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Tan (US 20110035522 A1) and further in view of Rossbach( US 20130232495 A1).
As to claim 10, Rossbach teaches the one or more direct dataflow compute-in- memory accelerators comprise one or more edge direct dataflow compute-in-memory accelerators(A graph is generated with a node corresponding to each of the accelerator tasks with edges that represent the data flow and data dependencies between the accelerator tasks. The generated graph is used by a scheduler to schedule the execution of the accelerator tasks across multiple accelerators. The application programming interface further provides an abstraction of the various memories of the accelerators called a datablock. The programmer can store and use data stored on the datablocks without knowing where on the accelerators the data is stored. The application programming interface can further schedule the execution of accelerator tasks to minimize the amount of data that is copied to and from the accelerators based on the datablocks and the generated graph, para[0003], ln 3-31/ The graph 900 may be used by the datablock manager 310 of the accelerator interface 140 to eliminate unnecessary communication between the CPU 111 and the accelerators 120a-c. For example, the edge connecting the node 901 and the node 905, and the edge connecting the node 903 and the node 907, can be used by the datablock manager 310 to establish a direct data transfer from the cameras to the memories of the accelerators 120a-c that execute the accelerator tasks associated with the nodes 905 and 907. Data transfer in this manner may eliminate double buffering between the memories130a-c of the accelerators 120a-c and the memory 105 of the CPU 111, para[0084]).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao and Tan with Rossbach to incorporate the feature of the one or more direct dataflow compute-in- memory accelerators comprise one or more edge direct dataflow compute-in-memory accelerators because this minimizes the amount of data that is copied to and from the accelerators based on the datablocks and the generated graph.
Claims 11, 12 are rejected under 35 U.S.C. 103 as being unpatentable over in view of Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Tan (US 20110035522 A1) and further in view of BISHT( US 20160191058 A1).
As to claim 11, Bisht teaches each of the one or more direct dataflow compute- in-memory accelerators comprise a respective integrated circuit die( The support components 12 can include any of the many types of operating units on the integrated circuit die 10, including memory, which may be RAM, ROM, EPROM, flash, cache, and the like. The support components 12 may also include memory exchange interfaces, shift registers, accelerator logic blocks, peripheral circuits, arithmetic logic units (ALUs), display drivers, power supplies, voltage regulators, clock circuits, timers, and any number of memory arrays or logic units that are required for the integrated circuit die 10 to operate properly, para[0005], ln 15-28).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao and Tan with Bisht to incorporate the feature of each of the one or more direct dataflow compute- in-memory accelerators comprise a respective integrated circuit die because provides connection of all the components to each other and ensure proper chip operation.
As to claim 12, Bisht teaches each of the one or more direct dataflow compute- in-memory accelerators comprise a respective integrated circuit chip package( para[0005], ln 1-30) for the same reason as to claim 11 above.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Tan (US 20110035522 A1) and further in view of MacKenna(US 8341382 B2).
As to claim 13, Mackenna teaches the one or more direct dataflow compute-in- memory accelerators are coupled in a module( A microcontroller in accordance with an embodiment of the invention comprises a memory accelerator operatively coupled between the processor and the memory, the memory accelerator including a plurality of buffers, col 1, ln 53-60).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao and Tan with Bisht to incorporate the feature of direct dataflow compute-in- memory accelerators are coupled in a module because this provides needed to improve the performance of these processors.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Tan (US 20110035522 A1) and further in view of SHIN( US 20220075645 A1).
As to claim 14, it is rejected for the same reason as to claim 1 above. In additional, Shin teaches An artificial intelligence accelerator method comprising: initiating an artificial intelligence task ( The accelerator board 120 may be an artificial intelligence (AI) accelerator configured to execute the neural network according to the instruction set of the host processor 110 and perform an inference on input data, and may be a separate processor distinguished from the host processor 110. The accelerator board 120 may be, for example, a neural processing unit or neural processor (NPU), a graphics processing unit (GPU), a tensor processing unit (TPU), a digital signal processor (DSP), and the like. The accelerator board 120 may be a separate dedicated processor that processes a task more effectively than by the host processor 110, para[0051]/ Referring to FIG. 2, an accelerator board 200 may include an off-chip memory 210 and an accelerator chip 220. The accelerator chip 220 may include a processor 221, a direct memory access (DMA) engine 223, a buffer 225, and a plurality of computation units or processing elements (PEs) 227, para[0056]/ In the example of FIG. 2, the on-chip memory may be, or may be indicated as, the buffer 225. The buffer 225 may include a task kernel in which an operation of a task is defined, a weight to be applied to the task, an input feature map (IFM), and an output feature map (OFM). Here, as many IFMs and OFMs as a batch size to be processed in the task may be stored in the buffer 225., para[0061], ln 1-10).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao and Tan with Shin to incorporate the feature of An artificial intelligence accelerator method comprising: initiating an artificial intelligence task because this minimizes a sum of a computation cost of executing the model in the accelerator and a memory access cost.
Claim15 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Tan (US 20110035522 A1) in view of SHIN( US 20220075645 A1) and further in view of Haller( US 20180284994 Al).
As to claim 15, Shin teaches the artificial intelligence task is initiated by an application executing on the host processor( para[0056]/ para[0061], ln 1-10 for the same reason as to claim 14 above.
Haller teaches the accelerator task result is returned to the application( The first communication path 171 may be established by writing, by the software program 115 executed on the host processor 110, operand and/or control data of the acceleration task 116 to the command port 141, that is then read by the near memory accelerator 150 directly from the command port 141, and by writing, by the near memory accelerator 150, result data of the acceleration task 116 directly to the command port 141, which is then read by the software program 115 executed on the host processor 110. /para[0042], ln 7-11/a device driver is provided as an interface for the communication of the software program 115 that is running on the host processor 110 with the access processor 140 and the near memory accelerators 150. The device driver may be responsible for the management of the acceleration tasks 116 and the associated management of the memory regions and/or address ranges that are used to access the command port 141 and exchange operand and result data between the software program 115 and the near memory accelerators 150. The device driver may also be responsible for triggering flush operations on the caches in order to make sure that data is transferred immediately between the software program 115 and the command port 141, the memory system 160, and the near memory accelerators 150, para[0069], ln 11-17).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao, Tan and Shin with Haller to incorporate the above feature because this improves performance and optimize power for selected application domains.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of SHIN( US 20220075645 A1) and further in view of O'Brien( US 20070174828 A1).
As to claim 16, Shin teaches artificial intelligence task ( para[0042], ln 7-11/ para[0069], ln 11-17) for the same reason as to claim 14 above.
O’Brien teaches the accelerator task calls an accelerator model including nodes and edges for execution on the one or more direct dataflow compute-in- memory accelerators, wherein nodes of the accelerator model are mapped to compute cores of the one or more direct dataflow compute-in-memory accelerators and the compute cores are coupled based on the edges of the accelerator model( The call graph for the program is augmented with the new outlined procedures, if any, and the call graph is partitioned into homogenous units based on the assignment of procedures or portions of the procedures to particular ones of the main core and the accelerators. Instructions may be added to the call graph to orchestrate the flow of control among the various partitions., para[0010], ln 1-10/ The degree of matching of each accelerator may be identified by the program partition engine 228 based on the results of the application of these rules. In addition, the negative characteristics of the accelerators, e.g., constraints and timing requirements, may also be evaluated to generate a decision as to which accelerator, or the main core processor, is to be used to execute the identified procedure. Based on this identification of the accelerator or main core processor, the call graph may be annotated to identify which accelerator or main core processor is to execute that procedure in the call graph, para[0050]).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao, Tan and Shin with O’Brien to incorporate the feature of the accelerator task calls an accelerator model including nodes and edges for execution on the one or more direct dataflow compute-in- memory accelerators, wherein nodes of the accelerator model are mapped to compute cores of the one or more direct dataflow compute-in-memory accelerators and the compute cores are coupled based on the edges of the accelerator model because this determines which accelerators, or the main core processor, should execute the function.
Claim 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of SHIN( US 20220075645 A1) and further in view of Drepper(US 20200167139 A1).
As to claim 17, Shin teaches artificial intelligence task (para[0042], ln 7-11/ para[0069], ln 11-17) for the same reason as to claim 14 above.
Drepper teaches the accelerator driver: receives the streamed accelerator task data from an application programming interface (API) of the operating system executing one on the one or more application processors and passes the streamed accelerator task data to an application programming interface (API) of the accelerator task executing on the one or more direct dataflow compute- in-memory accelerators; and receives the accelerator task result from the application programming interface (API) of the accelerator task and passes the accelerator task result to the application programming interface (API) of the operating system or a given one of the one or more applications executing on the one or more application processors( When the host processor encounters the portions of the host object code that are accelerated in the computer application, the host processor executes one or more operation calls included in the host object code that cause the OS kernel driver to communicate with the accelerator. The communication may request the accelerator to execute the softcore processor object code. The softcore processor object code may include the one or more instructions that enable interacting with the logic block instantiated by transmitting the representation of hardware logic (e.g., a bitstream that was generated using the HDL code) to the accelerator, para[0028]/ wherein the processing device is further to: receive, by the operating system kernel, a request to perform an operation of the softcore processor object code executing on the accelerator from the host processor in response to the host processor executing an operation call included in the first code to interact with the softcore processor object code; receiving a result from the accelerator in response to the accelerator executing an operation in the logic block that is called by the softcore processor object code using the one or more instructions; and transmitting the result to the host processor, para[0142]).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao, Tan and Shin with Drepper to incorporate the above feature because this provides enhanced processing capabilities in part due to parallelization that enables performing multiple operations at the same time.
Claims 18, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Tan (US 20110035522 A1) in view of SHIN( US 20220075645 A1) and further in view of Khanna( US 20060168590 A1).
As to claim 18, Khanna teaches the accelerator driver is host processor agnostic ( a set of OS agnostic drivers is included with the processor system. To provide functionality to these drivers, a set of abstracted functions is provided by the OS agnostic core. The OS agnostic core, like the boot services, provides common functions to the drivers for managing hardware components so that the functionality does not need to be included in each driver, para[0007], ln 17-25).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao, Tan and Shin with Khanna to incorporate the above feature because this facilitates the execution of a driver that is bound to the OS agnostic services.
As to claim 19, Khanna teaches the accelerator driver is operating system agnostic(para[0007], ln 17-25) for the same reason as to claim 18 above.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Zheng(US 11461662 B1) in view of GAO( US 20180367460 A1) in view of Ghosh(US 20200311569 A1) in view of Tan (US 20110035522 A1) in view of SHIN( US 20220075645 A1) and further in view of RIERA(WO 2021174225 A1).
As to claim 20, Riera teaches accelerator driver is direct dataflow compute- in-memory accelerator agnostic( The HALO framework 14 is provided as an open-ended extensible multi-agent software framework that implements the proposed hardware-agnostic principles and C.sup.2MPI specification for enabling the portable and performance- optimized execution of hardware-agnostic application codes across heterogeneous computing devices. Dual-agent embodiments of the HALO framework 14 include two system agents, i.e., a runtime agent and a virtualization agent, which work asynchronously in a star topology. The runtime agent is responsible for implementing and offering the C.sup.2MPI interface 12, as well as being the crossbar switch for application processes and virtualization agents. The runtime agent also manages system resources, including device buffers, accelerator manifests, kernels, etc. The virtualization agent provides an asynchronous peer that encapsulates hardware-specific compilers, libraries, runtimes, and drivers, para[0034], ln 1-23).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Zheng, Ghosh, Gao, Tan and Shin with Riera to incorporate the feature of accelerator driver is direct dataflow compute- in-memory accelerator agnostic because this facilitates dynamic plugin of an accelerator onto the network fabric, which can be auto-discovered and utilized by applications.
Response to the argument:
A. Applicant amendment filed on 03/11/2026 has been considered but they are not persuasive:
Applicant argued in substance that :
“ However, Zheng fails to teach or suggest that the processing engine array (presumably equated to the claimed "plurality of processing regions") is interleaved between the memory subsystem (presumably equated to the claimed "plurality of memory regions"), where the processing engine array is configurable for core-to-memory dataflow from one or more of the plurality of processing engines (presumably equated to the claimed "compute cores") within each of the processing engine arrays to adjacent ones of memory subsystems, as recited in amended independent Claim 1.”
B. Examiner respectfully disagreed with Applicant's remarks:
As to the point (1), Gao teaches a processor core is on a forwarding plane, para[0065], ln 15-17/ the processor core (also referred to as a forwarding core) belongs to a forwarding plane, and is mainly configured to forward and process a packet in a data flow, para[0021], ln 14-18/FIG. 1 is a schematic scenario diagram before and after a pipeline is spread according to an embodiment of the present disclosure. As shown in FIG. 1, initially, a first processor core receives a packet flow, performs traffic detection and all three processing actions, and spreads an action 3 when determining, according to a traffic detection result, that a preset pipeline spreading condition is met. In one embodiment, for each packet, the first processor core enqueues the packet into a queue after completing an action 2, and a second processor core obtains the packet from the queue and performs the action 3 on the packet. Further, when the action 3 is spread, the first processor core spreads the action 2 if detecting that traffic is still overloaded. After the action 2 is spread, the first processor core enqueues the packet into a queue after completing an action 1, and the second processor core performs the action 2 on the packet. After the second processor core completes the action 2, because the action 3 is still spread, the second processor core enqueues the packet into a queue, so that a next processor core performs the action 3. The action 2 and the action 3 may be performed by a same second processor core or different second processor cores, para[0089] to para[0090]/ Cores in the multi-core processor may share one or more storage areas in a memory, and the storage area is configured to cache a to-be-processed packet. In one embodiment, the storage area may be managed by using multiple queues, and it can be understood that an element enqueued into a queue is actually stored in a storage area corresponding to the queue, para[0168], ln 16-24/ the first processor core modifies spreading attributes of the N processing actions that are not spread, so as to indicate that the processing actions are spread, and then transfers a packet to the second processor core by using a storage area, and the second processor core performs, on the packet, a processing action that is spread. The storage area is configured to store a packet on which a processing action corresponding to the storage area is to be performed(para[0038], ln 1-10).
Ghosh teaches methods enable hardware accelerators, para[0036], ln 21-26/ The accelerator includes: a plurality of processor cores, each assigned to a pipeline stage of a plurality of pipeline stages and configured to process the pipeline stage, wherein the plurality of pipeline stages together comprise the computational graph of a deep learning inference neural network and the plurality of processor cores are configured to: receive a plurality of input data units at different times; as a data unit arrives at a processor core, process the data unit in a pipeline stage assigned to the processor core and output the processed data to a next pipeline stage and associated processor core until the data unit is processed through the plurality of the pipeline stages, para[0013/ Accelerator 65 includes a memory unit 62 and a chip 64. While the memory unit 62 and the chip 64 are shown as separate components, they can be integrated as one component or as part of an integrated system. The chip 64 can include one or more compute units 66, 68 and 70 designed to handle neural network, deep learning, CNNs, machine learning and/or other AI processing tasks. In one embodiment, compute unites 66, 68 and 70 can be processor cores similar to processor cores 26, 28 and 30 in embodiment of FIG. 1., para[0051]/ FIG. 5 illustrates an AI accelerator 90 utilizing a spatial model of computation and the semantic pipeline processing as described earlier. The accelerator 90 can be a chip designed to handle AI processing tasks, such as deep learning inference processing. The accelerator 90 can include memory regions R1, R2 and R3 and processing resources, such as processing cores 92, 94 and 96. Fewer or more memory regions and/or processing resources are possible depending on the implementation of an embodiment. Memory regions can store AI processing data locally and near the hardware resources intended to process them. In the example shown, memory region R1 can store activation map 98 and deep learning weight W_1, which are to be processed in, or used in processing of other data in processor core 92. Memory region R2 can store activation map 100 and deep learning weight W_2, which are to be processed in or used in processing of other data in processor core 94. Memory region R3 can store activation map 102 and deep learning weight W_3, which are to be processed in, or used in processing of other data in processor core 96, para[0054]/ the accelerator 90 utilizes a semantic pipelining technique and can process the input data as they arrive. Processor core 92 can start processing the input data 18, 20, 22, etc. as they arrive in memory region R1 and output the resulting activation map to the next memory region. Pipeline processing (as described in relation to FIGS. 2A-2E and 3) and data produced by each pipeline stage can move across the memory regions of the accelerator 90 through adjacent and/or physically close memory regions, para[0055], ln 3-15).
Conclusion
US 20110035522 A1 teaches In FIG. 8A, the first core 804 and the second core 806 process a plurality of functional blocks 808 using a static scheduling scheme. This implementation is based on the observation that the schedule of each block in a PHY processing pipeline is actually static, i.e., the processing pattern of previous blocks can determine whether a subsequent block is ready or not. Implementations of the SDR herein can thus partition the whole PHY processing pipeline into several sub-pipelines 8 10 and statically assign the sub-pipelines 810 to different cores 804, 806.
US 20190243651 A1 teaches The instruction may include a third input operand comprising a list of producer cores and consumer cores of the processor. The executing may cause the memory address and the allowed sequence of memory accesses to the memory address to be stored in a tracking table, and an access synchronization circuit separate from the execution unit compares a memory address for a memory access request to one or more memory addresses in the tracking table, and blocks a memory access.
US 20130219130 A1 teaches delayed until the conflicting access or reservation is finished. This may be the situation when the core Y is busy processing some previous data and the token LSU FU-6 is connected to some other token memory, which would be considered as a reservation conflict. The end of such a reservation conflict may be safely detected by observing the core Y to send a get_data( ) or acquire_input( ) message to the FU-CTL which would indicate that it is ready to start processing the next data. The operations in the processor core X and the processor core Y may be synchronized by the system timing 20.
US 20140281243 A1 teaches In one embodiment, the processor cores 110 are interconnected using a packet-switched 2D planar NoC that is organized into two planes--control-plane and data-plane. The control data plane provides an ultra-low-latency communication path between cores that bypasses the memory hierarchy to provide rich set of synchronization primitives for support of non-cache-coherent memory consistency models. The node has a separate memory fabric data plane that enables high-bandwidth datapaths for large data transfers and forms the basis for a scalable global memory address space fabric
US 20230370304 teaches A1one or more consumers may identify a producer to be part of a multi-cast group. The producer may send the data to all a consumers using multi-cast protocol. In this way, the present invention provides maximum flexibility for multicasting by requiring each consumer (e.g., receiver/core) to individually request the multicast data transfer. The producer (e.g., sends of the multicast data and can be a core in the multi-cast group) enforces synchronization by waiting until all the participating consumers have made the multicast data requests, and then delivers the multicast data in a single group communication.
US 9432245 B1 teaches The core packet processing architecture may use a single producer/single consumer paradigm for packet flow through the queues and cores of the multicore packet processor. In this paradigm, each queue inputs to one and only one core, and each core outputs to one and only one core for each other core that it feeds packets to. In addition, memory used by the cores in the multicore packet processor is not shared; each core has its own, separate memory region. Thus, there is no memory or queue sharing between cores.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LECHI TRUONG whose telephone number is (571)272-3767. The examiner can normally be reached 10-8 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 Young Kevin can be reached on (571)270-3180. 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.
/LECHI TRUONG/ Primary Examiner, Art Unit 2194