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 .
Information Disclosure Statement
The IDS filed 7/3/2024 and 1/23/2025 have been considered.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, and 3 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, the claim recites “first core” and “second core” but does not define what constitutes as “core” (i.e. whether it is a dedicated processor, hardware threat, or programmable unit?). Further, the claim recites “the first and second cores operating independently of one another.” It is unclear as to what constitutes “independent.” Lastly, the claim recites “congestion control instruction of one or more of first type… congestion instructions of one or more second types.” It is unclear how the first type distinguishes from the second type as both are being disclosed as being congestion control instructions.
Regarding claim 3, the claim recites “load balance the RUE events.” It is unclear as to how the load is balanced (i.e., amongst queue, amongst cores, etc.).
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-4 and 6 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Wang et al., (EP 3930272, hereinafter referred to as “Wang.” NOTE: this reference is cited in the IDS filed 7/3/2025).
Regarding claim 1, Wang teaches a system (figure 3; 320; [0035]), comprising:
a first core (abstract; a first processor configured to analyze packets received over a communication protocol system; figure 4: 460; figure 5: 580) having a first computing unit dedicated to processing congestion control instructions (rate update algorithm) of one or more first types ((congestion indicators 432); [0036] Fig. 4. the second stage rate update engine may include one or more processors 460, memory 470 and input, output components 490 for receiving and transmitting data with other components included in the first node hardware, such as the first stage computing devices 330; [0043] The processor 460 at the second stage 340 may be capable of assessing congestion indicators 432 from the data 472. The congestion indicators 432 may be provided by the processing devices [0044] The processor 460 of the second stage 340 may also be capable of storing and accessing congestion control parameters in the data 472. The congestion control parameters may be the parameters used to set the congestion central settings by the computing devices of the first stage 330. [0048] The rate update engine software 570 may further have access to one or more processor 580 separate from the first node hardware 520, whereby Instructions of the rate update engine software module may control the processor 580 to process the data stored in memory 560 in accordance with programmed rate update algorithm to derive rate update results from the input data);
a second core (abstract - a second processor) having a second computing unit dedicated to processing congestion control instructions of one or more second types, the first and second cores operating independently of one another ([0036] Fig. 4, the second stage rate update engine may include one or more processors 460); and
a register file in communication with each of the first core and the second core and adapted to receive processed instructions from the first core and the second core (]0050] Each buffer 630, 640 may be stored in a memory space associated with the software module 570. The event queue may include a tail pointer 632 for adding rate update requests to the queue, and a head pointer 634 for advancing the queued requests to the software module. Similarly, the result queue may include a tail pointer 642 for adding rate update results to the queue, and a head pointer 644 for advancing the queued results to the first node. Each of the pointers 632, 634, 642, 644, as well as an overall size of each buffer, may be stored in control/status registers of the first node memory so that the read/write interface 615 of the hardware can push requests to and pull results from the correct cells of the respective buffers.).
Regarding claim 2, Wang teaches the system of claim 1, wherein the first core and the second core are part of a rate update engine (abstract - The system also includes a rate update engine), and wherein the rate update engine is configured to: receive, by one or both of the first and second core, a rate update engine (RUE) event (abstract - The system also includes a rate update engine separate from the packet datapath and configured to operate a second processor to receive the determined one or more congestion indicators); and process the RUE event to generate a RUE response, wherein the RUE response comprises one or more congestion control parameter values for updating a connection associated with the RUE event (abstract - determine one or more congestion control parameters for controlling transmission of data packets based on the received one or more congestion indicators, and output a congestion control result based on the determined one or more congestion control parameters.).
Regarding claim 3, Wang teaches the system of claim 2, wherein the rate update engine is further configured to: receive a plurality of RUE events (abstract - determine one or more congestion control parameters for controlling transmission of data packets based on the received one or more congestion indicators, and output a congestion control result based on the determined one or more congestion control parameters.); and load balance the RUE events based on whether the plurality of RUE events are associated with the same connection ([0021] offload processing steps from the main datapath to a separate, offline, location while also providing for robust congestion control. Additionally, offline implementation of congestion control is flexible, since the proposed architecture is not limited to any particular type of congestion control or rate update algorithm. Furthermore, bursts and temporary back pressure between the main datapath and offline engine can be absorbed using a rate limiter to ensure that the main datapath does not stall.).
Regarding claim 4, Wang teaches the system of claim 2, wherein the rate update engine: is configured to receive, from a hardware transport layer managing a plurality of connections (figure 3: datapath in 301), the RUE event (figure 3: incoming steam 302); and in processing the RUE event, the rate update engine is configured to maintain a state for a connection associated with the RUE event, that is separate from a state for the connection maintained by the hardware transport layer ([0033] At a second stage, a determination of the updated parameters for data packet transmission is made in response to initiation of the rate update event. The second stage may be implemented using a rate update engine 204 that is separate from the main datapath 201. For example, data from the incoming stream 201 may be stored separately from the data cache 210, and the rate update engine 240 may analyze the separately stored data in order to determine the updated parameters for data packet transmission. Separating the congestion control process between these two stages helps to offload processing from the main datapath, and thus avoids congestion over the main datapath. Other advantages of offloading the congestion control process include increased flexibility in defining the congestion control algorithm, and in at least some examples increased flexibility in controlling whether rate update events are initiated.).
Regarding claim 6, Wang teaches the system of claim 1, further comprising a shared instruction memory, wherein the shared instruction memory is shared by the first core and the second core ([0049] Memory, such as memory 560 of Fig. 5, may be provided between rate update scheduler 610 and rate update engine 620 in order to temporarily store rate update requests sent from the first node to the software and rate update results fed back from the software to the first node.).
Claim(s) 1-4, 6-13, and 15-19 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ibanez et al., (US 20230139762, hereinafter referred to as “Ibanez.” NOTE: this reference is cited in the IDS filed 7/3/2025).
Regarding claim 1, Ibanez teaches a system (figure 9; [0023] a programmable architecture consisting of one or more EPUs. An EPU can perform read-modify-write operations on a set of state variables. At least one EPU can process 1 event per clock cycle. An EPU may utilize one or more programmable compute engines to execute VLIW instructions in order to process multiple event metadata fields in parallel. One or more programmable compute engines may be integrated into an EPU or programmable compute engines may be assigned to each EPU from a disaggregated resource pool at compilation time of an event processing program.), comprising:
a first core ([0122] select an AUL core to perform processing of the event) having a first computing unit ([0056] FIG. 2B depicts an example PTA ALU core. An instruction memory can store event processing programs. A register file can store current thread state. A VLIW ALU can perform compute operations to update thread state.) dedicated to processing congestion control instructions of one or more first types ([0115] At (3), control 905 can determine an EPU control configuration by event type and metadata. Control 905 can look up the rules for processing the event based on the event type. Control 905 can instruct lookup 906 to issue a read for table conn_state_at index event->conn_cache_idx and inform register packing 908 how to pack the event metadata and table entry data into ALU core registers, as well as the starting program counter (PC) for the ALU core. Control 905 can instruct register unpacking 914 how to use the final ALU core register state to update the event metadata and table entry.);
a second core having a second computing unit ([0058]) dedicated to processing congestion control instructions of one or more second types, the first and second cores operating independently of one another ([0118] At (6), ALU core scheduler 910 can select an ALU core to perform processing of the event. ALU core scheduler 910 can select an ALU core to dispatch the event to. Upon core selection, ALU core scheduler 910 can instruct the register packing module to dispatch the packed registers as well as starting PC to the selected core.); and
a register file in communication with each of the first core and the second core and adapted to receive processed instructions from the first core and the second core ([0119] At (7), the selected ALU core can execute a routine and/or perform a fixed function operation to process the event. Examples of events are described herein and can be specified by a developer or CSP or CoSP administrator. The packed registers can be loaded into the register file of the selected ALU core which then executes the program indicated by the starting PC. In this example, the ALU core can execute a sequence of instructions that record the PSN to assign to the packet, increment the request_psn, load an opcode into the register file that defines how to update num_outstanding_pkts_global state, and set a control & status register (CSR) indicating that the program is complete.).
Regarding claim 2, Ibanez teaches the system of claim 1, wherein the first core and the second core are part of a rate update engine, and wherein the rate update engine is configured to: receive, by one or both of the first and second core, a rate update engine (RUE) event ([0310] RUE request); and process the RUE event to generate a RUE response, wherein the RUE response comprises one or more congestion control parameter values for updating a connection associated with the RUE event ([0120] At (8), register contents can be used to update event data and table entry(s). ALU core scheduler 910 can identify that the core has finished processing the event and instruct the core to dispatch its final register state to register unpacking 914. Register unpacking 914 can issue the write to update the conn_state_table with the new request_psn value from the register state, issue the provided opcode to the globals module to increment the num_outstanding_pkts_state, copy the packet PSN from the register state to the event metadata, copy the final value of the num_outstanding_pkts_state into the event metadata, and forwards the updated event metadata to the next EPU.)
Regarding claim 3, Ibanez teaches the system of claim 2, wherein the rate update engine is further configured to: receive a plurality of RUE events ([0113] At (1), classify classifies an arriving event); and load balance the RUE events based on whether the plurality of RUE events are associated with the same connection ([0118] At (6), ALU core scheduler 910 can select an ALU core to perform processing of the event. ALU core scheduler 910 can select an ALU core to dispatch the event to. Upon core selection, ALU core scheduler 910 can instruct the register packing module to dispatch the packed registers as well as starting PC to the selected core.).
Regarding claim 4, Ibanez teaches the system of claim 2, wherein the rate update engine: is configured to receive, from a hardware transport layer managing a plurality of connections, the RUE event; and in processing the RUE event, the rate update engine is configured to maintain a state for a connection associated with the RUE event, that is separate from a state for the connection maintained by the hardware transport layer ([0117] At (5), select event and memory/pack registers 908 can load table entry(s) and event metadata into registers for processing. For example, table entry(s) and event metadata can be loaded into 31 16 bit registers. Table entry(s) can include protocol state (e.g., connection context).).
Regarding claim 6, Ibanez teaches the system of claim 1, further comprising a shared instruction memory, wherein the shared instruction memory is shared by the first core and the second core ([0090] CPU interface 568 can implement a shared memory queue interface with software running on one or more general purpose processors or embedded cores.).
Regarding claim 7, Ibanez teaches the system of claim 6, wherein the shared instruction memory comprises a separate read port for each of the first core and the second core (figure 9: each ALU core has its own port).
Regarding claim 8, Ibanez teaches the system of claim 6, wherein the shared instruction memory comprises a plurality of memory bank partitions ([0106] One or more ALU cores in compute pool 912 can include a processor to complete calculations in an event graph node. ALU core can include partitionable ALU with VLIW dispatch).
Regarding claim 9, Ibanez teaches the system of claim 8, wherein output from the plurality of memory bank partitions is combined by an XOR operation ([0106] One or more ALU cores in compute pool 912 can include a processor to complete calculations in an event graph node. ALU core can include partitionable ALU with VLIW dispatch; capable of a wide (64b) operation or multiple narrow (16/32b) operations in a single cycle; support Boolean expressions (e.g., complex expressions on up to 8 input bits (which may be any 8 bits from any registers) calculable in a single cycle).
Regarding claim 10, Ibanez teaches the system of claim 1, further comprising a first data memory in communication with the first core and a second data memory in communication with the second core ([0108] Read-Modify-Write memory bypass 916 can provide a write-through cache for table entries. Read-Modify-Write memory bypass 916 can store recently accessed table entries so that they can be accessed again with lower latency than would otherwise be if the table access reached the memory pool.).
Regarding claim 11, Ibanez teaches the system of claim 1, wherein the register file comprises a plurality of custom state registers ([0134] An upper protocol engine can provide an interface to applications. In some examples, an RDMA protocol engine can implement the InfiniBand Verbs interface and provide an interface to applications as well as the associated packetization such as splitting up a large message into maximum transmission unit (MTU) sized packets. A programmable event processing architecture with scheduling circuitry, packet buffering, and processors can then perform a configured and potentially custom reliable delivery and congestion control for packets generated by the upper protocol engine.).
Regarding claim 12, Ibanez teaches a method, comprising:
receiving, at a computing device having a plurality of customized cores, an instruction for congestion control ([0134] An upper protocol engine can provide an interface to applications. In some examples, an RDMA protocol engine can implement the InfiniBand Verbs interface and provide an interface to applications as well as the associated packetization such as splitting up a large message into maximum transmission unit (MTU) sized packets. A programmable event processing architecture with scheduling circuitry, packet buffering, and processors can then perform a configured and potentially custom reliable delivery and congestion control for packets generated by the upper protocol engine.);
inputting, based on a type of the instruction, the instruction to a given one of the plurality of customized cores ([0122] select an AUL core to perform processing of the event) having a first computing unit ([0056] FIG. 2B depicts an example PTA ALU core. An instruction memory can store event processing programs. A register file can store current thread state. A VLIW ALU can perform compute operations to update thread state.);
processing, by a first core of the plurality of customized cores, the instruction independently of processing by other cores in the plurality of customized cores ([0118] At (6), ALU core scheduler 910 can select an ALU core to perform processing of the event. ALU core scheduler 910 can select an ALU core to dispatch the event to. Upon core selection, ALU core scheduler 910 can instruct the register packing module to dispatch the packed registers as well as starting PC to the selected core.); and
providing, by the first core, the processed instruction to a multiported register file ([0119] At (7), the selected ALU core can execute a routine and/or perform a fixed function operation to process the event. Examples of events are described herein and can be specified by a developer or CSP or CoSP administrator. The packed registers can be loaded into the register file of the selected ALU core which then executes the program indicated by the starting PC. In this example, the ALU core can execute a sequence of instructions that record the PSN to assign to the packet, increment the request_psn, load an opcode into the register file that defines how to update num_outstanding_pkts_global state, and set a control & status register (CSR) indicating that the program is complete.).
Regarding claim 13, Ibanez teaches the method of claim 12, further comprising accessing, by the first core, an instruction memory shared with a second core ([0090] CPU interface 568 can implement a shared memory queue interface with software running on one or more general purpose processors or embedded cores.).
Regarding claim 15, Ibanez teaches the method of claim 13, wherein the instruction memory comprises a plurality of memory bank partitions, the method further comprising combining output from the plurality of memory bank partitions with an XOR operation ([0106] One or more ALU cores in compute pool 912 can include a processor to complete calculations in an event graph node. ALU core can include partitionable ALU with VLIW dispatch; capable of a wide (64b) operation or multiple narrow (16/32b) operations in a single cycle; support Boolean expressions (e.g., complex expressions on up to 8 input bits (which may be any 8 bits from any registers) calculable in a single cycle).
Regarding claim 16, Ibanez teaches the method of claim 15, further comprising: receiving, by the computing device, a rate update engine (RUE) event; and processing, by the plurality of customized cores, the RUE event to generate a RUE response, wherein the RUE response comprises one or more congestion control parameter values for updating a connection associated with the RUE event ([0113] At (1), classify classifies an arriving event); and load balance the RUE events based on whether the plurality of RUE events are associated with the same connection ([0118] At (6), ALU core scheduler 910 can select an ALU core to perform processing of the event. ALU core scheduler 910 can select an ALU core to dispatch the event to. Upon core selection, ALU core scheduler 910 can instruct the register packing module to dispatch the packed registers as well as starting PC to the selected core.).
Regarding claim 17, Ibanez teaches the method of claim 16, further comprising: receiving, by the computing device, a plurality of RUE events; and load balancing, by the computing device, the plurality of RUE events based on whether RUE events are associated with the same connection ([0118] At (6), ALU core scheduler 910 can select an ALU core to perform processing of the event. ALU core scheduler 910 can select an ALU core to dispatch the event to. Upon core selection, ALU core scheduler 910 can instruct the register packing module to dispatch the packed registers as well as starting PC to the selected core.).
Regarding claim 18, Ibanez teaches the method of claim 12, wherein receiving the plurality of RUE events comprises receiving the plurality of RUE events from a hardware transport layer managing a plurality of connections ([0117] At (5), select event and memory/pack registers 908 can load table entry(s) and event metadata into registers for processing. For example, table entry(s) and event metadata can be loaded into 31 16 bit registers. Table entry(s) can include protocol state (e.g., connection context).).
Regarding claim 19, Ibanez teaches the method of claim 18, further comprising: processing the plurality of RUE events, comprising maintaining a state for a connection associated with a RUE event that is separate from a state for the connection maintained by the hardware transport layer ([0117] At (5), select event and memory/pack registers 908 can load table entry(s) and event metadata into registers for processing. For example, table entry(s) and event metadata can be loaded into 31 16 bit registers. Table entry(s) can include protocol state (e.g., connection context).).
Allowable Subject Matter
Claims 5, 14 and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Regarding claim 5, the prior art of record does not teach the system of claim 1, wherein instructions of the one or more first types and one or more second types comprise one or more of a Log2Floor instruction, a clamp instruction, one or more instructions for a getPacketTiming function, one or more instructions for a getSmooth function, a divider instruction, or a multiplier instruction.
Regarding claim 14, the prior art of record does not teach the method of claim 13, wherein accessing the instruction memory comprises executing a collision avoidance algorithm comprising: snooping read addresses from the first core and the second core; determining that the first core and the second core are reading from a same memory location for multiple cycles; and issuing a stall to one of the first core or the second core.
Regarding claim 20, the prior art of record does not teach the method of claim 12, wherein instructions of the one or more first types and one or more second types comprise one or more of a Log2Floor instruction, a clamp instruction, one or more instructions for a getPacketTiming function, one or more instructions for a getSmooth function, a divider instruction, or a multiplier instruction.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Damodaran et al., US 8862836 - a multi-port register file.
Mahadevan et al., US 8799547- data packet processing for multi core processor.
Thompson et al., US 20160124883 – core processor including a register file to control flow.
Kumar et al., US 20080002575 - Techniques for managing a TCP congestion window.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALINA N BOUTAH whose telephone number is (571)272-3908. The examiner can normally be reached M-F 7:00 AM - 3:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Umar Cheema can be reached at (571) 270-3037. 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.
ALINA BOUTAH
Primary Examiner
Art Unit 2458
/ALINA A BOUTAH/Primary Examiner, Art Unit 2458