DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This communication is in response to the election made without traverse filed on June 19, 2026, in which Applicant has elected claims 10-20 without traverse. Accordingly, claims 1-20 remain pending for examination.
Status of Claims
3. Claims 1-20 are pending, of which claims 17, 18 and 20 are rejected under 35 U.S.C. 102(a)(1). Claims 10-16 and 19 are rejected under 35 U.S.C. 103. Claims 1-9 are withdrawn from further consideration.
Election/Restrictions
4. Applicant’s election without traverse of claims 10-20 in the reply filed on June 19, 2026 is acknowledged.
5. Claim set 1-9 stands withdrawn from further consideration pursuant to 37 CFR 1.142(b), as being drawn to nonelected species, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on June 19, 2026.
Priority
6. Examiner has acknowledged Applicant’s claim of priority from U.S. Provisional Patent Application Serial No. 63/556,922, filed February 23, 2024.
Information Disclosure Statement
7. The information disclosure statements, filed November 8, 2024, and August 6, 2025, are in compliance with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609. They have been placed in the application file, and the information referred to therein has been considered as to the merits.
Claim Rejections - 35 USC § 102
8. 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 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.
9. 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.
10. Claims 17, 18 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by SUBRAHMANYA et al. (United States Patent Application Publication No. US 2022/0045940 A1), hereinafter “SUBRAHMANYA”.
Regarding claim 17, SUBRAHMANYA discloses a network accelerator comprising: a first processor core (control plane 102, 302 (See FIGS 1 and 3, respectively), is disclosed as a CPU (central processing unit) and can include multiple CPU cores and other elements, and also shown as cores 607 as part of NIC 601 in FIG. 1) (SUBRAHMANYA, FIGS. 1, 3 and 6, paragraphs [0042], [0045] and [0060]); a processor scheduler, communicatively coupled with the first processor core (also including packet buffer and traffic manager 106, 609) (SUBRAHMANYA, FIGS. 1 and 6); and a lookup table engine (match units 517 - See FIG. 5, particularly expanded view within the box of dotted lines - which are part of match-action units 501, 502, 503, are also referred to as table engines) (SUBRAHMANYA, FIG. 5, paragraph [0068]), communicatively coupled with the processor scheduler (are part of packet processing circuit implementing P4 pipelines 606, which are coupled to packet buffer traffic manager 609, both of which are arranged on NIC 601 - See, e.g., FIG. 6) (SUBRAHMANYA, FIG. 6), wherein the lookup table engine is configured to: receive first data from the first processor core (wherein packets are processed using match-action pipelines, extended packet processing pipelines, and CPU (central processing unit) cores. The match-action pipeline is a part of a data plane that can process network traffic flows extremely quickly, but only after being configured to process those traffic flows. That is, the match-action pipeline must be specifically configured for each traffic flow. As such, the match-action pipeline cannot process a new network traffic flow because it has not yet been configured for that flow. Packets for a new flow are often called “flow miss packets”. The extended packet processing pipelines and CPU cores can handle packets that the match-action pipeline is not configured to handle, such as flow miss packets. SUBRAHMANYA teaches that one way to handle flow miss packets is to configure the match-action pipeline to process them, then to resubmit the packets to the match-action pipeline. In particular, whenever the match-action pipeline receives a packet (or packet header vector (PHV)), the match-action pipeline determines a hash key and entry location for the lookup table (See again, e.g., FIG. 5, element 510) for each packet that is received. If there is no entry at the entry location of the lookup table, then the packet is considered to be a flow miss packet and the entry location is considered an insertion point for a new entry into the lookup table. The extended packet processing pipeline, or alternatively, the CPU cores, can generate a configuration based on the flow miss packet. Installing the configuration into the match-action pipeline configures the match-action pipeline to handle the flow miss packet. Thus, SUBRAHMANYA teaches receiving a configuration from the processing cores referencing the packet and insertion into the lookup table) (SUBRAHMANYA, paragraphs [0042] and [0043]), and, in response, access a first rule and a second rule (wherein in processing the packet header vector (PHV), each match-action unit of the match-action pipeline processes an input PHV to produce an output PHV, according to rules or “actions” to take that are governed by the lookup table. See again, FIG. 5, which illustrates the match-action pipeline 500 in detail. In particular, match-action pipeline 500 includes a series of match-action units, 501, 502, 503, each of which receive an input PHV, originally generated by a parser (such as that shown in FIG. 4, at element 402), and produce an output PHV. Each match-action unit 501, 502, 503 includes a match unit and a corresponding action unit. More particularly, match-action unit 501 includes match unit 517 - again the “lookup table engine” - denoted by the smaller dotted-line box, that operates on an input PHV 406, as well as a corresponding action unit 514, that produces an output PHV 506, which may be a modified version of the input PHV 406. The match unit 517 can include key construction logic 509, the lookup table 510, and selector logic 512. The key construction logic 509 is configured to generate a key from at least one field in the PHV, while the lookup table 510 is populated with key-action pairs, where a key-action pair includes a lookup key and a corresponding action code 515 and/or action data 516. The key generation and lookup function constitutes the “match” portion of the operation and produces an action that is provided to the action unit via the selector logic. For clarity, Examiner maps the key-action pairs of the lookup table, to the recited “first rule” and “second rule,” as the keys generated by the key construction logic 509 are matched against the stored keys of the lookup table 510 to determine which action to take. The action unit executes an action over the input data (which may include data 513 from the PHV) and provides an output that forms at least a portion of the output PHV. For example, the action unit executes action code 515 on action data 516 and data 513 to produce an output that is included in the output PHV) (SUBRAHMANYA, FIGS. 4 and 5, paragraph [0068]); generate a search word from a packet referenced in the first data (wherein FIG. 12 illustrates populating a key-value table. In particular, a first key (e.g., key 1209) is read from the PHV 1201 of a packet. The key can be, e.g., the 5-tuple of the packet or can be assembled from other data in the PHV 1201. A hash generator 1202 receives the key 1209 and generates a hash value to be used as a second key 1203. The hash value can be a CRC-32 computed using the key or can be computed using a different hashing algorithm or different PHV fields. SUBRAHMANYA notes that CRC-32 can be used as a hashing algorithm for the purpose of generating keys in the context of a P4 pipeline) (SUBRAHMANYA, FIG. 12, paragraph [0111]), wherein the search word includes a first portion of the packet (wherein the hash value 1203 can be divided into an index 1208 and a hint or residue 1207. For example, the index 1208 can be the 21 least significant bits of the key 1203 while the residue 1207 can be the remaining 11 bits. SUBRAHMANYA teaches that the index 1208 can provide the location of a value 1205 in a key-value table 1206) (SUBRAHMANYA, FIG. 12, paragraph [0111]) and omits a second portion of the packet based on the first rule (wherein the residue 1207 is not used for providing the location of the value 1205 in the key-value table 1206) (SUBRAHMANYA, FIG. 12, paragraph [0111]); perform a plurality of comparing operations according to the second rule, wherein each comparing operation compares a respective portion of the search word to a respective value from a lookup table entry (wherein the table engine 906 may be configured to hash, lookup, and/or compare keys to table entries. The table engine 906 may be configured to control the address and size of the table, use PHV fields to generate a lookup key, and find Session Ids or MPU instruction pointers that define the P4 program associated with a table entry) (SUBRAHMANYA, paragraph [0101]); and write an event to the processor scheduler based in part on results of the plurality of comparing operations (wherein the packets processed by the parser may be placed in a packet buffer/traffic manager (e.g. See again, FIG. 1, element 106, also FIG. 6, element 609) for scheduling and possible replication. More particularly, a packet processed by an ingress pipeline may be placed in the packet buffer for scheduling and possible replication. In some cases, once the packet is scheduled and leaves the packet buffer, it may be parsed again to create an egress parsed header vector. The egress parsed header vector may be passed through a P4 egress pipeline in a similar fashion as a packet passing through a P4 ingress pipeline, after which a final deparser operation may be executed before the packet is sent to its destination interface or recirculated for additional processing) (SUBRAHMANYA, FIGS. 1 and 6, paragraphs [0062] and [0096]).
Regarding claim 18, SUBRAHMANYA discloses the network accelerator of claim 17, further comprising: a data memory configured to store the packet and configured to store the results of the plurality of comparing operations (wherein the packet payloads may travel and be stored in separate queues and/or buffers, such as first-in-first-out (FIFO) queues, until the packet payload is reassembled with its corresponding PHV at the deparser to form a packet. As well, register file unit 806 of match processing unit 801 (See also FIG. 1) may be used to store SRAM addresses, ternary content addressable memory (TCAM) search values, ALU operands, comparison sources, or action results) (SUBRAHMANYA, FIGS. 3 and 8, paragraphs [0062] and [0089]); and a lookup table memory configured to store a plurality of rules (again, the lookup tables in each of the match-action units storing the key-action pairs) (SUBRAHMANYA, FIG. 5, paragraph [0068]), including the first rule and the second rule (again, the series of key-action pairs) (SUBRAHMANYA, FIG. 5, paragraph [0068]), and also configured to store the lookup table entry (again, storing the lookup keys, as part of the key-action pairs) (SUBRAHMANYA, FIG. 5, paragraph [0068]).
Regarding claim 20, SUBRAHMANYA discloses the network accelerator of claim 17, wherein the first processor core is configured to: generate the first data to include an indication of the first rule in response to a source of the packet (again, with the flow miss packets, the PHV of the packets will include a source IP address as part of the packet 5-tuple, which is often used for generating keys for match tables (See also FIG. 4, illustrating packet 5-tuple 410)) (SUBRAHMANYA, FIG. 4, paragraph [0065]).
Claim Rejections - 35 USC § 103
11. 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.
12. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
13. Claims 10-16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over SUBRAHMANYA in view of Henderson (United States Patent Application Publication No. US 2003/0231634 A1), hereinafter “Henderson”.
Regarding claim 10, SUBRAHMANYA discloses a circuit comprising (any of network appliances 101, 301, NICs 601, 700, each of which include a packet processing circuit implementing P4 pipelines) (SUBRAHMANYA, FIGS. 1, 3, 6, 7 and 9): a first set of registers (see also FIG. 8, illustrating a match processing unit (MPU) 801, having a register file unit 806 may comprise a plurality of general-purpose registers (e.g., R0, R1,…Rn) which may be initially loaded with metadata values then later used to store temporary variables within execution of a program until completion of the program) (SUBRAHMANYA, FIG. 8, paragraph [0089]), wherein each register of the first set of registers is configured to receive data for a lookup operation from a respective processor core of a set of processor cores (wherein as discussed and shown above with respect to independent claim 17, packets are processed using match-action pipelines, extended packet processing pipelines, and CPU (central processing unit) cores. The match-action pipeline is a part of a data plane that can process network traffic flows extremely quickly, but only after being configured to process those traffic flows. That is, the match-action pipeline must be specifically configured for each traffic flow. As such, the match-action pipeline cannot process a new network traffic flow because it has not yet been configured for that flow. Packets for a new flow are often called “flow miss packets”. The extended packet processing pipelines and CPU cores can handle packets that the match-action pipeline is not configured to handle, such as flow miss packets. SUBRAHMANYA teaches that one way to handle flow miss packets is to configure the match-action pipeline to process them, then to resubmit the packets to the match-action pipeline. In particular, whenever the match-action pipeline receives a packet (or packet header vector (PHV)), the match-action pipeline determines a hash key and entry location for the lookup table (See again, e.g., FIG. 5, element 510) for each packet that is received. If there is no entry at the entry location of the lookup table, then the packet is considered to be a flow miss packet and the entry location is considered an insertion point for a new entry into the lookup table. The extended packet processing pipeline, or alternatively, the CPU cores, can generate a configuration based on the flow miss packet. Installing the configuration into the match-action pipeline configures the match-action pipeline to handle the flow miss packet. Thus, SUBRAHMANYA teaches receiving a configuration from the processing cores referencing the packet and insertion into the lookup table) (SUBRAHMANYA, paragraphs [0042] and [0043]); a first memory configured to store a first set of rules, a second set of rules, and a set of lookup tables (wherein as further set forth above, SUBRAHMANYA discloses a series of match-action units in a match-action pipeline, each match-action unit including a lookup table populated with a series of key-value pairs (See again, FIG. 5). SUBRAHMANYA teaches that in processing a packet header vector (PHV), each match-action unit of the match-action pipeline processes an input PHV to produce an output PHV, according to rules or “actions” to take that are governed by the lookup table. See again, FIG. 5, which illustrates the match-action pipeline 500 in detail. In particular, match-action pipeline 500 includes a series of match-action units, 501, 502, 503, each of which receive an input PHV, originally generated by a parser (such as that shown in FIG. 4, at element 402), and produce an output PHV. Each match-action unit 501, 502, 503 includes a match unit and a corresponding action unit. More particularly, match-action unit 501 includes match unit 517 - again the “lookup table engine” - denoted by the smaller dotted-line box, that operates on an input PHV 406, as well as a corresponding action unit 514, that produces an output PHV 506, which may be a modified version of the input PHV 406. The match unit 517 can include key construction logic 509, the lookup table 510, and selector logic 512. The key construction logic 509 is configured to generate a key from at least one field in the PHV, while the lookup table 510 is populated with key-action pairs, where a key-action pair includes a lookup key and a corresponding action code 515 and/or action data 516. The key generation and lookup function constitutes the “match” portion of the operation and produces an action that is provided to the action unit via the selector logic. For clarity, Examiner maps the key-action pairs of the lookup table, to the recited “first rule” and “second rule,” as the keys generated by the key construction logic 509 are matched against the stored keys of the lookup table 510 to determine which action to take. The action unit executes an action over the input data (which may include data 513 from the PHV) and provides an output that forms at least a portion of the output PHV. For example, the action unit executes action code 515 on action data 516 and data 513 to produce an output that is included in the output PHV) (SUBRAHMANYA, FIGS. 4 and 5, paragraph [0068]); and a set of lookup table engines configured to access the first memory and to access data from the first set of registers (again, match units 17 are the lookup table engines) (SUBRAHMANYA, FIG. 5, paragraph [0068]); wherein a first lookup table engine of the set of lookup table engines is further configured to: receive first data from a first processor core, wherein the first data references a first rule of the first set of rules for a first lookup operation (again, packets are processed using the match-action pipelines, extended packet processing pipelines, and CPU (central processing unit) cores. The match-action pipeline is a part of a data plane that can process network traffic flows extremely quickly, but only after being configured to process those traffic flows. That is, the match-action pipeline must be specifically configured for each traffic flow. As such, the match-action pipeline cannot process a new network traffic flow because it has not yet been configured for that flow. Packets for a new flow are often called “flow miss packets”. The extended packet processing pipelines and CPU cores can handle packets that the match-action pipeline is not configured to handle, such as flow miss packets. SUBRAHMANYA teaches that one way to handle flow miss packets is to configure the match-action pipeline to process them, then to resubmit the packets to the match-action pipeline. In particular, whenever the match-action pipeline receives a packet (or packet header vector (PHV)), the match-action pipeline determines a hash key and entry location for the lookup table (See again, e.g., FIG. 5, element 510) for each packet that is received. If there is no entry at the entry location of the lookup table, then the packet is considered to be a flow miss packet and the entry location is considered an insertion point for a new entry into the lookup table. The extended packet processing pipeline, or alternatively, the CPU cores, can generate a configuration based on the flow miss packet. Installing the configuration into the match-action pipeline configures the match-action pipeline to handle the flow miss packet. Thus, SUBRAHMANYA teaches receiving a configuration from the processing cores referencing the packet and insertion of the key into the lookup table) (SUBRAHMANYA, paragraphs [0042] and [0043]); generate a search word according to the first rule (wherein FIG. 12 illustrates populating a key-value table. In particular, a first key (e.g., key 1209) is read from the PHV 1201 of a packet. The key can be, e.g., the 5-tuple of the packet or can be assembled from other data in the PHV 1201. A hash generator 1202 receives the key 1209 and generates a hash value to be used as a second key 1203. The hash value can be a CRC-32 computed using the key or can be computed using a different hashing algorithm or different PHV fields. SUBRAHMANYA notes that CRC-32 can be used as a hashing algorithm for the purpose of generating keys in the context of a P4 pipeline) (SUBRAHMANYA, FIG. 12, paragraph [0111]), including storing a first subset of the packet to a register and omitting to store a second subset of the packet to the register (wherein the hash value 1203 can be divided into an index 1208 and a hint or residue 1207. For example, the index 1208 can be the 21 least significant bits of the key 1203 while the residue 1207 can be the remaining 11 bits. SUBRAHMANYA teaches that the index 1208, not the residue 1207, can provide the location of a value 1205 in a key-value table 1206) (SUBRAHMANYA, FIG. 12, paragraph [0111]); access, according to the first rule, a second rule of the second set of rules (wherein each match-action unit iteratively processes the input PHV, which has been modified from the previous action taken, according to the previous lookup key, each output PHV undergoing a new lookup and new action by being used as an input PHV into the next match-action unit in the pipeline) (SUBRAHMANYA, paragraph [0068]); generate, according to the second rule, a comparison value based on a portion of the search word (wherein based on the location of the value indicated by the index 1208 of the second key 1203, generated from the first key 1209, a corresponding action is matched against, whereby the PHV may undergo some change/processing to become an output PHV and then an input PHV for input into the next stage of the match-action pipeline. For clarity, Examiner maps the recited “comparison value” to the modified/processed PHV, which is compared with the key from the next match-action table) (SUBRAHMANYA, paragraphs [0068] and [0096]); compare the comparison value to respective entries from the lookup tables according to the second rule (again, each subsequent PHV is compared to a lookup table entry of a given stage in the pipeline) (SUBRAHMANYA, paragraphs [0068] and [0096]); and write an event to a scheduler of the first processor core, based at least in part on results of comparing the portion of the search word (wherein the packets processed by the parser may be placed in a packet buffer/traffic manager (e.g. See again, FIG. 1, element 106, also FIG. 6, element 609) for scheduling and possible replication. More particularly, a packet processed by an ingress pipeline may be placed in the packet buffer for scheduling and possible replication. In some cases, once the packet is scheduled and leaves the packet buffer, it may be parsed again to create an egress parsed header vector. The egress parsed header vector may be passed through a P4 egress pipeline in a similar fashion as a packet passing through a P4 ingress pipeline, after which a final deparser operation may be executed before the packet is sent to its destination interface or recirculated for additional processing) (SUBRAHMANYA, FIGS. 1 and 6, paragraphs [0062] and [0096]). SUBRAHMANYA does not explicitly disclose wherein the first data references a location of a packet in a second memory. However Henderson discloses wherein first data references a location of a packet in a second memory (wherein Henderson discloses a block diagram (See FIG. 3) that illustrates a packet 301 and a packet context 204 associated with that particular packet 301. When the packet 301 is first received at services processor 110 (shown in FIG. 1), it is received by packet input unit 210 (See also FIG. 2), which stores packet data into one or more free blocks in the cache 230. Control is then passed to the packet processing controller 200. To aid in processing, the packet processing controller 200 then initiates assignment of a packet context 204 to each received packet 301. In one embodiment, the packet context 204 is assigned to each packet 301 as soon has the packet fills the first block in cache 230 or the end of the packet 301 is detected. Each packet context 204 contains several different sets of registers for storing data related to the packet 301. In particular, the packet context 204 includes information about the packet 301 itself. A packet handle register 402 stores a pointer to the location in memory of the packet 301 to which the given packet context 204 relates) (Henderson, FIGS. 1-3, paragraphs [0035] and [0038]). SUBRAHMANYA and Henderson are analogous art because they are from the same problem solving area, namely, systems, methods and techniques for efficiently processing network packets. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of SUBRAHMANYA and Henderson before him or her, to modify the packet processing circuit implementing the P4 pipelines of SUBRAHMANYA to include the additional limitation of wherein first data references a location of a packet in a second memory, as disclosed in Henderson, with reasonable expectation that this would result in a packet processing circuit having the added benefit of maintaining a packet context that contained a higher level of detailed information about the packet, state information related to the packet, and about the actions to be done to the packet. This method of improving the packet processing circuit implementing the P4 pipelines of SUBRAHMANYA and was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Henderson. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of SUBRAHMANYA with Henderson to obtain the invention as specified in claim 10.
Regarding claim 11, SUBRAHMANYA-Henderson discloses the circuit of claim 10, wherein the comparison value includes a plurality of bytes of the search word (again, the key includes the index 1208, which can be the 21 least significant bits of the key 1203) (SUBRAHMANYA, FIG. 12, paragraph [0111]). The motivation regarding the obviousness of claim 10 is also applied to claim 11.
Regarding claim 12, SUBRAHMANYA-Henderson discloses the circuit of claim 10, wherein the first rule corresponds to a first packet protocol, further wherein a third rule of the first set of rules corresponds to a second packet protocol, and wherein the first lookup table engine is further configured to generate a further search word according to the third rule for a second lookup operation (wherein the table engine 906 can be further configured to control a table selection. In particular, upon entering a stage, a PHV is examined to select which table(s) to enable for the arriving PHV. Table selection criteria may be determined based on the information contained in the PHV. In some cases, a match table may be selected based on packet type information related to a packet type associated with the PHV. For instance, the table selection criteria may be based on packet type or protocols (e.g., Internet Protocol version 4 (IPv4), Internet Protocol version 6 (IPv6), MPLSA, or the next table ID as determined by the preceding stage) (SUBRAHMANYA, FIG. 9, paragraph [0102]). The motivation regarding the obviousness of claim 10 is also applied to claim 12.
Regarding claim 13, SUBRAHMANYA-Henderson discloses the circuit of claim 12, wherein a second lookup table engine of the set of lookup table engines is configured to generate the search word according to the first rule for a third lookup operation and to generate the further search word according to the third rule for a fourth lookup operation (again, each of the match-action units of the pipeline, processing the PHV and performing match “lookups” with corresponding actions in sequence (See again, FIG. 5, and also FIG. 9)) (SUBRAHMANYA, FIGS. 5 and 9, paragraphs [0068] and [0096]). The motivation regarding the obviousness of claim 10 is also applied to claim 13.
Regarding claim 14, SUBRAHMANYA-Henderson discloses the circuit of claim 10, wherein the first lookup table engine is further configured to receive the first data from the first processor core via the first set of registers (see again, FIGS. 6, 7 and 9, each illustrating the packet processing circuit 606, 901, as well as FIG. 8, illustrating the MPU having the register file unit 806 comprising all of the general-purpose registers (e.g., R0, R1,…Rn). Again, each match unit of a match-action unit is referred to as a table engine. SUBRAHMANYA teaches that pipeline MPUs (See in particular, FIG. 9) of the match-action units 905, 910, 911, 912, 913, 914 can be same as the MPU 801 of FIG. 8, and that the match-action units can have any number of MPUs. The table engine 906 may be configured to support per-stage table match. For example, the table engine 906 may be configured to hash, lookup, and/or compare keys to table entries. The table engine 906 may be configured to control the address and size of the table, use PHV fields to generate a lookup key, and find Session Ids or MPU instruction pointers that define the P4 program associated with a table entry. A table result produced by the table engine can be distributed to the multiple MPUs) (SUBRAHMANYA, FIGS. 6-9, paragraphs [0089] and [0100]-[0101]). The motivation regarding the obviousness of claim 10 is also applied to claim 14.
Regarding claim 15, SUBRAHMANYA-Henderson discloses the circuit of claim 10, further comprising a configuration interface, wherein the configuration interface is configured to receive configuration data and to configure the first set of rules, the second set of rules, and the lookup tables according to the configuration data (wherein as indicated and shown above, SUBRAHMANYA teaches that one way to handle flow miss packets is to configure the match-action pipeline to process them, then to resubmit the packets to the match-action pipeline. In particular, whenever the match-action pipeline receives a packet (or packet header vector (PHV)), the match-action pipeline determines a hash key and entry location for the lookup table (See again, e.g., FIG. 5, element 510) for each packet that is received. If there is no entry at the entry location of the lookup table, then the packet is considered to be a flow miss packet and the entry location is considered an insertion point for a new entry into the lookup table. The extended packet processing pipeline, or alternatively, the CPU cores, can generate a configuration based on the flow miss packet. Installing the configuration into the match-action pipeline configures the match-action pipeline to handle the flow miss packet. Thus, SUBRAHMANYA teaches receiving a configuration from the processing cores referencing the packet and insertion into the lookup table) (SUBRAHMANYA, paragraphs [0042] and [0043]). The motivation regarding the obviousness of claim 10 is also applied to claim 15.
Regarding claim 16, SUBRAHMANYA-Henderson discloses the circuit of claim 10, further comprising: a second set of registers, wherein the first lookup table engine is configured to place the results of comparing in the second set of registers in response to determining that the second rule indicates a shared operation, and wherein the second set of registers is configured to be read by each processor core of the set of processor cores (wherein the match-action units can further share a common set of SRAMs and TCAMs 902 (See again, FIG. 9). The SRAMs and TCAMs 902 may be components of the pipeline. This arrangement may allow the six match-action units to divide match table resources in any suitable proportion which provides convenience to the compiler and eases the complier's task of resource mapping. Any suitable number of SRAM resources and any suitable number of TCAM resources may be used by each pipeline. For example, the illustrated pipeline can be coupled to ten SRAM resources and four or eight TCAM resources. In some instances, TCAMs may be fused vertically or horizontally for a wider or deeper search) (SUBRAHMANYA. FIG. 9, paragraph [0106]). The motivation regarding the obviousness of claim 10 is also applied to claim 16.
As to claim 19, SUBRAHMANYA discloses the network accelerator of claim 18, wherein the first data comprises a second pointer to the first rule in the lookup table memory (wherein table data 1204 (See FIG. 12) can be stored in the table 1206 in association with the key. SUBRAHMANYA teaches that the table data 1204 can be, e.g., data that is input to a function (e.g. one or more arguments of a function), or can indicate a set of instructions that can be executed by the MPUs (e.g. a pointer to function)) (SUBRAHMANYA, FIG. 12, paragraph [0112]), but does not expressly disclose wherein the first data comprises a first pointer to the packet in the data memory. However in an analogous art, Henderson discloses wherein a first data comprises a first pointer to a packet in a data memory (wherein Henderson discloses a block diagram (See FIG. 3) that illustrates a packet 301 and a packet context 204 associated with that particular packet 301. When the packet 301 is first received at services processor 110 (shown in FIG. 1), it is received by packet input unit 210 (See also FIG. 2), which stores packet data into one or more free blocks in the cache 230. Control is then passed to the packet processing controller 200. To aid in processing, the packet processing controller 200 then initiates assignment of a packet context 204 to each received packet 301. In one embodiment, the packet context 204 is assigned to each packet 301 as soon has the packet fills the first block in cache 230 or the end of the packet 301 is detected. Each packet context 204 contains several different sets of registers for storing data related to the packet 301. In particular, the packet context 204 includes information about the packet 301 itself. A packet handle register 402 stores a pointer to the location in memory of the packet 301 to which the given packet context 204 relates) (Henderson, FIGS. 1-3, paragraphs [0035] and [0038]). SUBRAHMANYA and Henderson are analogous art because they are from the same problem solving area, namely, systems, methods and techniques for efficiently processing network packets. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of SUBRAHMANYA and Henderson before him or her, to modify the packet processing circuit implementing the P4 pipelines of SUBRAHMANYA to include the additional limitation of wherein a first data comprises a first pointer to a packet in a data memory, as disclosed in Henderson, with reasonable expectation that this would result in a packet processing circuit having the added benefit of maintaining a packet context that contained a higher level of detailed information about the packet, state information related to the packet, and about the actions to be done to the packet. This method of improving the packet processing circuit implementing the P4 pipelines of SUBRAHMANYA and was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Henderson. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of SUBRAHMANYA with Henderson to obtain the invention as specified in claim 19.
Conclusion
14. Further references of interest are cited on Form PTO-892, which is an attachment to this Office Action. For instance, Remen (USPAT 10,944,675) discloses a network element that includes ports, a hardware fabric, a packet classifier and control logic. The ports are configured to transmit and receive packets over a network. The fabric is configured to forward the packets between the ports. The packet classifier is configured to receive at least some of the packets and to specify an action to be applied to a packet in accordance with a set of rules. The classifier includes (i) multiple Ternary Content Addressable Memories (TCAMs), each TCAM configured to match the packet to a respective subset of the set of rules and to output a match result, and (ii) circuitry configured to specify the action to be applied to the packet based on match results produced for the packet by the multiple TCAMs, and based on a priority defined among the multiple TCAMs. The control logic is configured to apply the specified action to the packet (See Abstract). Wickeraad (USPAT 10,586,594) discloses embodiments that relate to an electronic device including a processor, a lookup engine, and a content addressable memory (CAM) including a plurality of data tables. The lookup engine may obtain from the processor a search word and a table identifier identifying a selected data table from the plurality of data tables, and using a lookup table, determine table parameters associated with the selected data table. The lookup engine may also generate search parameters based on the search word and the table parameters and provide the search parameters to the CAM. The search parameters may cause the CAM to determine whether the selected data table comprises a word corresponding to the search word, and if the selected data table comprises the word, to output an entry address of an entry of the CAM that comprises the word (See Abstract). Wickeraad (USPGPUB 2018/0210829) discloses a method of searching a content addressable memory (CAM) that stores a plurality of entries. The method may include obtaining a search word corresponding to a matching data word stored in a matching entry of the CAM, where the matching entry may include a plurality of data words. The method may also include determining, based at least on a value of a predetermined bit of the search word, a search mask to mask off any data words within the matching entry other than the matching data word. The method may also determine, based on the search mask and a search key that includes the search word, the address of the matching entry within the CAM (See Abstract). Neely (USPGPUB 2013/0117504 and WIPOIPN 2013/070297) discloses an integrated circuit having programmable circuitry operable according to a first clock frequency and a block random access memory. The block random access memory can include a random access memory (RAM) element having at least one data port and a memory processor coupled to the data port of the RAM element and to the programmable circuitry. The memory processor can be operable according to a second clock frequency that is higher than the first clock frequency. Further, the memory processor can be hardwired and dedicated to perform operations in the RAM element of the block random access memory (See Abstract). The IC can include a programmable circuitry and a multi-stage pipeline circuit structure. The multi-stage pipeline circuit structure can include a plurality of block random access memories. Each block random access memory can include a RAM element having at least one data port and a dedicated memory processor coupled to the data port. Each dedicated memory processor of the plurality of block random access memories can be coupled to at least one other memory processor of another block random access memory of the plurality of block random access memories through a hardwired signal path. At least one memory processor of the plurality of block random access memories can be coupled to the programmable circuitry and can be configured to receive at least a portion of a search key (See paragraph [0006]). As shown in FIG. 4, a multi-stage pipelined structure 400 using BRAMs illustrates that different ones of BRAMs 205 can be grouped into stages, where each stage can correspond to a level of a data structure, e.g., a binary search tree (BST). As shown, each BRAM 205 includes a RAM element 210 and a memory processor 215. Signal path 405 illustrates the data flow through memory processors 215 forming the hardwired pipelining of multi-stage pipelined structure 400. Multi-stage pipelined structure 400 can be implemented, e.g., mapped, onto a column of BRAMs 205 so long as a sufficient number of adjacent BRAMs 205 are allocated to meet the memory requirements of each stage. FIG. 4 illustrates two stages denoted as stage 0 and stage 1, with the pipeline flowing from bottom up, e.g., from stage 0 to stage 1. The example pictured in FIG. 4 shows the amount of memory doubling at each stage, which is characteristic of deeper levels of a BST implementation. In general, each memory processor 215 can be configured to perform functions such as storing table entries, storing lookup results, and comparing a selected entry against a search key, or portion thereof (See FIG. 4, paragraphs [0060], [0061] and [0063]). Bhadra (USPGPUB 2012/0246400) discloses a method for performing packet lookups, whereby packets (which each have a body and a header) are received and parsed to parsing headers. A hash function is applied to each header, and each hashed header is compared with a plurality of binary rules stored within a primary table, where each binary rule is a binary version of at least one ternary rule from a first set of ternary rules. For each match failure with the plurality of rules, a secondary table is searched using the header associated with each match failure, where the secondary table includes a second set of ternary rules (See Abstract). Kalampoukas (USPGPUB 2008/0175241) discloses a system and method for obtaining packet forwarding data for routing packets. The steps may include (1) receiving packet identification information including a virtual router identifier (VRID) and route data; (2) determining if the VRID of the received packet identification information belongs to a pre-defined set of VRIDs. Additionally, if the VRID of the received packet identification information belongs to the pre-defined set of VRIDs, then the method preferably performs the steps of: (1) converting the VRID into a shortened VRID; and (2) obtaining packet forwarding data by performing a ternary content addressable memory (TCAM) lookup using a short key. But if the VRID of the received packet identification information does not belong to the pre-defined set of VRIDs, then the method performs the step of obtaining packet forwarding data by performing a ternary content addressable memory (TCAM) lookup using a long key (See Abstract).
15. Any inquiry concerning this communication or earlier communications from the examiner should be directed to KOSTAS J. KATSIKIS whose telephone number is (571)270-5434. The examiner can normally be reached Monday-Friday, 9:00am-5:00pm. 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, Kamal B. Divecha can be reached at 571-272-5863. 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.
/KOSTAS J KATSIKIS/Primary Examiner, Art Unit 2453
Prosecution Insights