Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to communications filed on 7/14/2026.
Claims 1-30 are pending and presented for examination.
Response to Amendment
Claims 1 & 16 have been amended.
Double patenting rejections to claims 1-30 made in the Non-final rejection dated 5/5/2026 have been withdrawn based on amendments to claims 1 & 16, but new grounds of double patenting rejections have been made based on new reference Herbert et al. (US 12461885)(herein after “Herbert”).
Rejections to claims 1-3, 5, 15-18, 20 & 30 under 35 USC 102 and rejections to claims 4, 6-14, 19 & 21-29 under 35 USC 103 made in the Non-final Rejection dated 5/5/2026 have been withdrawn based on amendments to claims 1 & 16, but new grounds of rejections to these claims have been made under 35 USC 103 based on new reference Herbert et al. (US 12461885)(herein after “Herbert”).
Response to Arguments
Applicant's arguments filed 7/14/2026 have been fully considered but they are not persuasive.
Applicant argues that Ulman fails to disclose “loading a next parser configuration into the parser configuration registers in response to finding a next protocol found while parsing a previous header of the header section”, but instead discloses selecting a parsing configuration data set responsively to the first parsed data, updating parsing configuration data as needed, and passing the header section from one hardware parser to a next hardware parser. Examiner respectfully disagrees nothing that Fig 6 & col 12, lines 34-59 disclose loading a selected parsing configuration data set (i.e. a next parser configuration) into parser configuration registers 24 in response to parsing of a header of a default parsing configuration data set (i.e. a previous header of the header section) using match and action tables 28. Col 6, lines 60-67 & col 7, lines 1-17 disclose that the action tables 28 include data for protocols such as TCP or UDP to be matched to the parsed information. Therefore, the selected parsing configuration set loaded into the parser configuration registers 24 is in response to protocols found through action tables 28 while parsing the header using the default parsing configuration (i.e. the previous header). Examiner notes that Ulman discloses that the selection of the parsing configuration set loaded into the parser configuration registers in response to protocols found while parsing the header using the default parsing configuration is only performed once and not for each header, one-by-one on demand, as required by other amended limitations to claim 1.
Applicant’s arguments, see “Remarks”, filed 7/14/2026, with respect to the rejections of claims 1-3, 5, 15-18, 20 & 30 under 35 USC 102 and rejections to claims 4, 6-14, 19 & 21-29 under 35 USC 103 made in the Non-final Rejection dated 5/5/2026 have been fully considered and are persuasive. Therefore, these rejections have been withdrawn. However, upon further consideration, new grounds of rejections to these claims are made in view of new reference Herbert et al. (US 12461885)(herein after “Herbert”).
Regarding claim 1, applicant submits that amendments to this claim traverse the rejection of this claim under 35 USC 102 made in the Non-final Rejection dated 5/5/2026. Examiner agrees and withdraws rejection of claim 1 under 35 USC 102 made in the Non-final Rejection dated 5/5/2026. However, after further consideration, examiner introduces a new ground of rejection of claim 1 under 35 USC 103 based on new reference Herbert. Applicant’s arguments with respect to claim 1 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Regarding claims 16, applicant submits that this claim traverses the rejection of this claim under 35 USC 102 made in the Non-final Rejection dated 5/5/2026 due to similar amendments and arguments as made for claim 1. Examiner agrees and withdraws rejection of claim 16 under 35 USC 102 made in the Non-final Rejection dated 5/5/2026. However, for the same reasons as discussed above, examiner introduces a new ground of rejection of claim 16 under 35 USC 102 based on new reference Herbert.
Regarding claims 2-15 & 17-30, applicant submits that claims 2, 3, 5, 15, 17, 18, 20 & 30 traverse the rejections of these claims under 35 USC 102 and claims 4, 6-14, 19 & 21-29 traverse the rejections of these claims under 35 USC 103 made in the Non-final Rejection dated 5/5/2026 due to amendments and arguments made for claims 1 & 16 and due to their dependency on claims 1 or 16. Examiner agrees and withdraws rejections of claims 2, 3, 5, 15, 17, 18, 20 & 30 under 35 USC 102 and the rejections of claims 4, 6-14, 19 & 21-29 under 35 USC 103 made in the Non-final Rejection dated 5/5/2026. However, for the same reasons as discussed above, examiner introduces new grounds of rejections of claims 2-15 & 17-30 under 35 USC 103 based on new reference Herbert.
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-3 & 16-18 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 9 & 10, 12, 20 & 21 of U.S. Patent No. 11258885 in view of Herbert et al. (US 12461885)(herein after “Herbert”). Although the claims at issue are not identical, they are not patentably distinct from each other as demonstrated in the table below and because claims 1-3 & 16-18 of the current application merely broaden the scope of claims 1, 9, 10, 12, 20 & 21 of US11258885 Patent. Eliminating the additional elements (i.e. bolded features in the table below) and their functions of claims 1, 9, 10, 12, 20 & 21 of US11258885 Patent, claims 1-3 & 16-18 of the current application are an obvious variant thereof, since it has been held that the omission an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karlson, 136 USPQ 184 (CCPA).
Instant Application 18/665615
Patent US11258885
Claim 1
A network device, comprising:
parser configuration registers;
hardware parsers coupled to receive data of a header section of a packet and including flexible hardware parsers to parse the data of the header section based on parser configurations loaded into the parser configuration registers; and
a controller to selectively load the parser configurations associated with different protocols one-by-one on demand for parsing respective headers of the header section of the packet into the parser configuration registers such that for each of the respective headers of the header section a next parser configuration is loaded into the parser configuration registers in response to finding on a next protocol found while parsing a previous header of the header section.
(Examiner notes that “including flexible hardware parsers” is not given patentable weight since there are no further details defining flexible hardware parsers in this claim.
Examiner notes that the limitations “one-by-one on demand” and “for each of the respective headers of the header section” are discussed below this table.)
Claim 1
A network device, comprising: parser configuration registers
configured to store a default parsing configuration data set, wherein at least one of the hardware parsers is configured to parse at least one of the headers responsively to the default parsing configuration data set yielding first parsed data; hardware parsers coupled to receive data of a header section of a packet, the header section including respective headers;
a packet processing engine coupled to the hardware parsers, and configured to: select a virtual machine (VM) parsing configuration data set from a selection of VM parsing configuration data sets of respective VMs having respective header parser schemes, responsively to the first parsed data being identified as being associated with a given one of the VMs; cause loading of the selected VM parsing configuration data set into the parser configuration registers, and wherein ones of the hardware parsers are configured to parse respective ones of the headers in accordance with a respective one of the header parsing schemes of the given VM responsively to the selected VM parsing configuration data set, yielding second parsed data; the header section including respective headers; and process the packet responsively to the second parsed data.
Claim 9
The device according to claim 1, wherein respective ones of the hardware parsers are configured to successively parse the header section according to respective offsets in the header section, ones of the hardware parsers being configured to compute the respective offsets responsively to the selected VM parsing configuration data and the header section.
Claim 10
The device according to claim 9, wherein the selected VM parsing configuration data set includes for respective ones of the hardware parsers: a next header offset of a next header identification (ID) in the header section; and a next protocol table linking next header IDs with next protocols, wherein a first one of the hardware parsers is coupled to: retrieve the next header offset for the first hardware parser from the selected VM parsing configuration data set in the parser configuration registers; retrieve the next header ID, which is located in the header section at the next header offset, from the header section responsively to the retrieved next header offset; retrieve an identification of a next protocol to be processed from the next protocol table for the first hardware parser from the selected VM parsing configuration data set in the parser configuration registers responsively to the retrieved next header ID; and transfer the header section to a second one of the hardware parsers, which is configured to parse the header section in accordance with the next protocol.
Claim 2
The device according to claim 1, wherein: the flexible hardware parsers include a first flexible hardware parser and a second flexible hardware parser;
the controller is to load a first parser configuration associated with a given protocol into the parser configuration registers;
the first flexible hardware parser is to: parse a first header of the header section according to the loaded first parser configuration yielding first parsed data; and
find a next protocol of a second header of the header section based on the first parsed data;
the controller is to load a second parser configuration associated with the found next protocol of the second header into the parser configuration registers in response to finding the next protocol of the second header based on the first parsed data; and
the second flexible hardware parser is to parse the second header according to the loaded second parser configuration yielding second parsed data.
(Examiner notes that “including flexible hardware parsers” is not given patentable weight since there are no further details defining flexible hardware parsers in this claim. Examiner notes that “a parser configuration associated with a given protocol” may be interpreted as “a default parsing configuration data set” since no further details of “associated with a given protocol” are given in this claim.)
Claim 1
A network device, comprising: hardware parsers coupled to receive data of a header section of a packet, the header section including respective headers;
parser configuration registers configured to store a default parsing configuration data set,
wherein at least one of the hardware parsers is configured to parse at least one of the headers responsively to the default parsing configuration data set, yielding first parsed data;
a packet processing engine coupled to the hardware parsers, and configured to: select a virtual machine (VM) parsing configuration data set from a selection of VM parsing configuration data sets of respective VMs having respective header parser schemes, responsively to the first parsed data being identified as being associated with a given one of the VMs;
Claim 10
The device according to claim 9, wherein the selected VM parsing configuration data set includes for respective ones of the hardware parsers: a next header offset of a next header identification (ID) in the header section; and a next protocol table linking next header IDs with next protocols, wherein a first one of the hardware parsers is coupled to: retrieve the next header offset for the first hardware parser from the selected VM parsing configuration data set in the parser configuration registers; retrieve the next header ID, which is located in the header section at the next header offset, from the header section responsively to the retrieved next header offset; retrieve an identification of a next protocol to be processed from the next protocol table for the first hardware parser from the selected VM parsing configuration data set in the parser configuration registers responsively to the retrieved next header ID; and transfer the header section to a second one of the hardware parsers, which is configured to parse the header section in accordance with the next protocol.
Claim 1
cause loading of the selected VM parsing configuration data set into the parser configuration registers, and wherein ones of the hardware parsers are configured to parse respective ones of the headers in accordance with a respective one of the header parsing schemes of the given VM responsively to the selected VM parsing configuration data set, yielding second parsed data; and process the packet responsively to the second parsed data.
Claim 9
The device according to claim 1, wherein respective ones of the hardware parsers are configured to successively parse the header section according to respective offsets in the header section, ones of the hardware parsers being configured to compute the respective offsets responsively to the selected VM parsing configuration data and the header section.
Claim 3
The device according to claim 2, wherein: the first parser configuration includes a next protocol table providing a mapping between next header identifications and next protocols; and
the first flexible hardware parser is to find the next header protocol of the second header by matching a next header identification included in the first header with one of the next header identifications included in the next protocol table.
Claim 10
The device according to claim 9, wherein the selected VM parsing configuration data set includes for respective ones of the hardware parsers: a next header offset of a next header identification (ID) in the header section; and a next protocol table linking next header IDs with next protocols,
wherein a first one of the hardware parsers is coupled to: retrieve the next header offset for the first hardware parser from the selected VM parsing configuration data set in the parser configuration registers; retrieve the next header ID, which is located in the header section at the next header offset, from the header section responsively to the retrieved next header offset; retrieve an identification of a next protocol to be processed from the next protocol table for the first hardware parser from the selected VM parsing configuration data set in the parser configuration registers responsively to the retrieved next header ID; and transfer the header section to a second one of the hardware parsers, which is configured to parse the header section in accordance with the next protocol.
Claim 1
A network device, comprising: hardware parsers coupled to receive data of a header section of a packet, the header section including respective headers; parser configuration registers configured to store a default parsing configuration data set, wherein at least one of the hardware parsers is configured to parse at least one of the headers responsively to the default parsing configuration data set, yielding first parsed data; a packet processing engine coupled to the hardware parsers, and configured to: select a virtual machine (VM) parsing configuration data set from a selection of VM parsing configuration data sets of respective VMs having respective header parser schemes, responsively to the first parsed data being identified as being associated with a given one of the VMs; cause loading of the selected VM parsing configuration data set into the parser configuration registers, and wherein ones of the hardware parsers are configured to parse respective ones of the headers in accordance with a respective one of the header parsing schemes of the given VM responsively to the selected VM parsing configuration data set, yielding second parsed data; and process the packet responsively to the second parsed data.
Claim 9
The device according to claim 1, wherein respective ones of the hardware parsers are configured to successively parse the header section according to respective offsets in the header section, ones of the hardware parsers being configured to compute the respective offsets responsively to the selected VM parsing configuration data and the header section.
Claim 16
A method, comprising: receiving data of a header section of a packet;
selectively loading parser configurations associated with different protocols one-by-one on demand for parsing respective headers of the header section of the packet into parser configuration registers such that for each of the respective headers of the header section a next parser configuration is loaded into the parser configuration registers in response to on a next protocol found while parsing a previous header of the header section; and
parsing the data of the header section based on the parser configurations loaded into the parser configuration registers.
Claim 12
A network method, comprising: receiving data of a header section of a packet, the header section including respective headers;
storing a default parsing configuration data set in parser configuration registers; selecting a virtual machine (VM) parsing configuration data set from a selection of VM parsing configuration data sets of respective VMs having respective header parsing schemes, responsively to the first parsed data being identified as being associated with a given one of the VMs; causing loading of the selected VM parsing configuration data set into the parser configuration registers;
Claim 21
The method according to claim 20, wherein the selected VM parsing configuration data set includes: a next header offset of a next header identification (ID) in the header section; and a next protocol table linking next header IDs with next protocols, the method further comprising: retrieving the next header offset from the selected VM parsing configuration data set; retrieving the next header ID, which is located in the header section at the next header offset, from the header section responsively to the retrieved next header offset; retrieving an identification of a next protocol to be processed from the next protocol table from the selected VM parsing configuration data set responsively to the retrieved next header ID;
and parsing the header section in accordance with the next protocol.
Claim 12
parsing at least one of the headers responsively to the default parsing configuration data set, yielding first parsed data; parsing respective ones of the headers in accordance with a respective one of the header parser schemes of the given VM responsively to the selected VM parsing configuration data set, yielding second parsed data; and processing the packet responsively to the second parsed data.
Claim 20
The method according to claim 12, further comprising: successively parsing the header section according to respective offsets in the header section; and computing the respective offsets responsively to the selected VM parsing configuration data set and the header section.
Claim 17
The method according to claim 16, further comprising: loading a first parser configuration associated with a given protocol into the parser configuration registers;
parsing a first header of the header section according to the loaded first parser configuration yielding first parsed data;
finding a next protocol of a second header of the header section based on the first parsed data;
loading a second parser configuration associated with the found next protocol of the second header into the parser configuration registers in response to finding the next protocol of the second header based on the first parsed data; and
parsing the second header according to the loaded second parser configuration yielding second parsed data.
Claim 12
A network method, comprising: receiving data of a header section of a packet, the header section including respective headers; storing a default parsing configuration data set in parser configuration registers;
parsing at least one of the headers responsively to the default parsing configuration data set, yielding first parsed data;
selecting a virtual machine (VM) parsing configuration data set from a selection of VM parsing configuration data sets of respective VMs having respective header parsing schemes, responsively to the first parsed data being identified as being associated with a given one of the VMs;
Claim 21
The method according to claim 20, wherein the selected VM parsing configuration data set includes: a next header offset of a next header identification (ID) in the header section; and a next protocol table linking next header IDs with next protocols, the method further comprising: retrieving the next header offset from the selected VM parsing configuration data set; retrieving the next header ID, which is located in the header section at the next header offset, from the header section responsively to the retrieved next header offset; retrieving an identification of a next protocol to be processed from the next protocol table from the selected VM parsing configuration data set responsively to the retrieved next header ID; and parsing the header section in accordance with the next protocol.
Claim 12
causing loading of the selected VM parsing configuration data set into the parser configuration registers; parsing respective ones of the headers in accordance with a respective one of the header parser schemes of the given VM responsively to the selected VM parsing configuration data set, yielding second parsed data; and processing the packet responsively to the second parsed data.
Claim 20
The method according to claim 12, further comprising: successively parsing the header section according to respective offsets in the header section; and computing the respective offsets responsively to the selected VM parsing configuration data set and the header section.
Claim 18
The method according to claim 17, wherein: the first parser configuration includes a next protocol table providing a mapping between next header identifications and next protocols; and
the finding includes finding the next header protocol of the second header by matching a next header identification included in the first header with one of the next header identifications included in the next protocol table.
Claim 21
The method according to claim 20, wherein the selected VM parsing configuration data set includes: a next header offset of a next header identification (ID) in the header section; and a next protocol table linking next header IDs with next protocols,
the method further comprising: retrieving the next header offset from the selected VM parsing configuration data set; retrieving the next header ID, which is located in the header section at the next header offset, from the header section responsively to the retrieved next header offset; retrieving an identification of a next protocol to be processed from the next protocol table from the selected VM parsing configuration data set responsively to the retrieved next header ID; and parsing the header section in accordance with the next protocol.
Claim 12
A network method, comprising: receiving data of a header section of a packet, the header section including respective headers; storing a default parsing configuration data set in parser configuration registers; parsing at least one of the headers responsively to the default parsing configuration data set, yielding first parsed data; selecting a virtual machine (VM) parsing configuration data set from a selection of VM parsing configuration data sets of respective VMs having respective header parsing schemes, responsively to the first parsed data being identified as being associated with a given one of the VMs; causing loading of the selected VM parsing configuration data set into the parser configuration registers; parsing respective ones of the headers in accordance with a respective one of the header parser schemes of the given VM responsively to the selected VM parsing configuration data set, yielding second parsed data; and processing the packet responsively to the second parsed data.
Claim 20
The method according to claim 12, further comprising: successively parsing the header section according to respective offsets in the header section; and computing the respective offsets responsively to the selected VM parsing configuration data set and the header section.
Regarding claim 1, Urman discloses a network device, comprising:
parser configuration registers (Figs 1 & 2 and col 6, lines 24-33 & col 8, lines 25-33 disclose a network device 10 including parser configuration registers 24.);
hardware parsers coupled to receive data of a header section of a packet and including flexible hardware parsers to parse the data of the header section based on parser configurations loaded into the parser configuration registers (Fig 2 & col 8, lines 15-18 & 25-64 disclose hardware parsers 18 that receive a header section of a packet for processing and including flexible hardware parsers 40 configured to parse the header section according to data in the parser configuration registers 24. Fig 3 & col 9, lines 38-34 disclose that the parser configuration data is loaded into parser configuration registers 24.); and
a controller to selectively load the parser configurations associated with different protocols for parsing respective headers of the header section of the packet into the parser configuration registers such that a next parser configuration is loaded into the parser configuration registers in response to finding a next protocol found while parsing a previous header of the header section (Fig 1 & col 6, lines 39-49 disclose a controller 22 that, under instruction by processing engine 20, selectively loads parsing configuration data into parser registers 24 for parsing respective headers of a header section of a packet received by network interface 12. Col 5, lines 33-36 disclose that the parser configuration data may be associated with different respective protocols. Fig 6 & col 12, lines 34-59 disclose loading a selected parsing configuration data set (i.e. a next parser configuration) into parser configuration registers 24 in response to parsing of a header of a default parsing configuration data set (i.e. a previous header of the header section) using match and action tables 28 . Col 6, lines 60-67 & col 7, lines 1-17 disclose that the action tables 28 include data for protocols such as TCP or UDP to be matched to the parsed information. Therefore, the selected parsing configuration set loaded into the parser configuration registers 24 is in response to protocols found through action tables 28 while parsing the header using the default parsing configuration.).
Urman fails to disclose but Herbert teaches wherein the selection is one-by-one on demand for each of the respective headers of the header section (Fig 10, col 16, lines 51-67 & col 17, lines 1-27 disclose parsing of a packet wherein after completion of parsing a header, CAM and array lookup instructions are used to lookup a next protocol which in response sets a next parser register. The example in figure 10 & col 17, lines 13-27 discloses a packet being parsed wherein each header of the header section is parsed, and in response to completion of each header, CAM and array lookup instructions are used to find a next protocol for setting a next parser register, one-by-one and on demand, for parsing the next protocol header. Specifically, the example discloses a packet being parsed wherein an Ethernet header of the header section is parsed, and in response to completion of parsing the Ethernet header, CAM and array lookup instructions are used find a next protocol being IPv4 for a next header and setting parser registers for parsing the IPv4 header, then in response to completion of parsing the IPv4 header, CAM and array lookup instructions are used to find a next protocol being TCP for a next header and setting parser registers for parsing the TCP header.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have a network device, comprising: parser configuration registers; hardware parsers coupled to receive data of a header section of a packet and including flexible hardware parsers to parse the data of the header section based on parser configurations loaded into the parser configuration registers; and a controller to selectively load the parser configurations associated with different protocols for parsing respective headers of the header section of the packet into the parser configuration registers such that a next parser configuration is loaded into the parser configuration registers in response to parsing a previous header of the header section, as disclosed by Urman, wherein the selection is one-by-one on demand for each of the respective headers of the header section, as taught by Herbert. The motivation to do so would have been to have a network device that can avoid pre-loading of incorrect parser configurations into the parser configuration registers that would cause dropped packets and routing errors by always checking a next protocol indication in a previous header before setting and loading the parser configurations for parsing the next header.
Regarding claim 16, Urman discloses a method, comprising:
receiving data of a header section of a packet (Figs 2 & 5 and col 11, lines 5-7 disclose a parsing method for a device 10. Fig 2 & col 8, lines 15-18 & 25-64 disclose hardware parsers 18 that receive a header section of a packet for processing.);
selectively loading parser configurations associated with different protocols for parsing respective headers of the header section of the packet into parser configuration registers such that a next parser configuration is loaded into the parser configuration registers in response to finding a next protocol found while parsing a previous header of the header section (Fig 1 & col 6, lines 39-49 disclose a controller 22 that, under instruction by processing engine 20, selectively loads parsing configuration data into parser registers 24 for parsing respective headers of a header section of a packet received by network interface 12. Col 5, lines 33-36 disclose that the parser configuration data may be associated with different respective protocols. Fig 6 & col 12, lines 34-59 disclose loading a selected parsing configuration data set (i.e. a next parser configuration) into parser configuration registers 24 in response to parsing of a header of a default parsing configuration data set (i.e. a previous header of the header section) using match and action tables 28 . Col 6, lines 60-67 & col 7, lines 1-17 disclose that the action tables 28 include data for protocols such as TCP or UDP to be matched to the parsed information. Therefore, the selected parsing configuration set loaded into the parser configuration registers 24 is in response to protocols found through action tables 28 while parsing the header using the default parsing configuration.); and
parsing the data of the header section based on the parser configurations loaded into the parser configuration registers (Fig 6 & col 12, lines 63-66 disclose that hardware parsers 40, 42 are configured to parse the headers of the header section based on the selected parsing configuration data set that were loaded into registers 24 to yield second parsed data.).
Urman fails to disclose but Herbert teaches wherein the selection is one-by-one on demand for each of the respective headers of the header section (Fig 10, col 16, lines 51-67 & col 17, lines 1-27 disclose parsing of a packet wherein after completion of parsing a header, CAM and array lookup instructions are used to lookup a next protocol which in response sets a next parser register. The example in figure 10 & col 17, lines 13-27 discloses a packet being parsed wherein each header of the header section is parsed, and in response to completion of each header, CAM and array lookup instructions are used to find a next protocol for setting a next parser register, one-by-one and on demand, for parsing the next protocol header. Specifically, the example discloses a packet being parsed wherein an Ethernet header of the header section is parsed, and in response to completion of parsing the Ethernet header, CAM and array lookup instructions are used find a next protocol being IPv4 for a next header and setting parser registers for parsing the IPv4 header, then in response to completion of parsing the IPv4 header, CAM and array lookup instructions are used to find a next protocol being TCP for a next header and setting parser registers for parsing the TCP header.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have a method, comprising: receiving data of a header section of a packet; selectively loading parser configurations associated with different protocols for parsing respective headers of the header section of the packet into parser configuration registers such that a next parser configuration is loaded into the parser configuration registers in response to finding a next protocol found while parsing a previous header of the header section; and parsing the data of the header section based on the parser configurations loaded into the parser configuration registers, as disclosed by Urman, wherein the selection is one-by-one on demand for each of the respective headers of the header section, as taught by Herbert. The motivation to do so would have been to have a method for a network device to avoid pre-loading of incorrect parser configurations into the parser configuration registers that would cause dropped packets and routing errors by always checking a next protocol indication in a previous header before setting and loading the parser configurations for parsing the next header.
Claims 4 & 19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert et al. (US 12461885)(herein after “Herbert”), as applied to claims 1 & 16, and further in view of Kfir et al. (US 2019/0215384)(herein after “Kfir”).
Regarding claims 4 & 19, claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert disclose the device according to claim 1 and the method of claim 16.
Claims 10 & 21 of U.S. Patent No. 11258885 fail to disclose but Kfir teaches wherein respective ones of the protocols include a basic parsing option configuration and an advanced parsing option configuration (Fig 2 & [0035]-[0044] discloses different parsing options including an option to parse fixed parts of a header (i.e. a basic parsing option configuration for parsing fixed parts of the header such as a MAC header, IPv4 basic header and UDP upper-layer header) and an option to parse optional records of the header (i.e. an advanced parsing option configuration for parsing optional records such as TLV fields.).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 1, or the method of claim 16, as disclosed in claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert, wherein respective ones of the protocols include a basic parsing option configuration and an advanced parsing option configuration, as taught by Kfir. The motivation to do so would have been to have certain devices, or a method for certain devices, that perform only basic parsing of fixed headers such as a MAC header, IPv4 basic header and a UDP upper-layer header, in order to be lower cost with less memory, while having other devices that perform more advanced parsing of not only fixed headers but also optional headers such as TLV fields in order to support advanced network functions such as network security and route monitoring.
Claims 5, 15, 20 & 30 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert et al. (US 12461885)(herein after “Herbert”), as applied to claims 1 & 16, and further in view of Urman et al. (US 11258885)(herein after “Urman”).
Regarding claims 5 & 20, claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert disclose the device according to claim 1 and the method of claim 16.
Claims 10 & 21 of U.S. Patent No. 11258885 fail to disclose but Urman teaches wherein the controller is to selectively load, or the method selectively loads: a given parser configuration into the parser configuration registers for a first packet (Fig 1 & col 6, lines 39-49 disclose a controller 22 that selectively loads parsing configuration data into parser registers 24 for packets received (i.e. a first packet).); and
only part of the given parser configuration into the parser configuration registers for a second packet (Col 1, lines 19-24 disclose that custom headers can vary from packet to packet. Fig 3 & col 9, lines 29-43 disclose that parsing configuration data may consist of subsets of a parsing configuration data set 48. Thus, the controller may load a given parser configuration into the parser configuration registers for the first packet to be parsed by flexible hardware parser 40-1 based on a data subset 1, and load only part of the given parser configuration into the parser configuration registers for a second packet to be parsed by flexible hardware parser 40-2 based on a data subset 2, which may be a subset of data subset 1.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 1, or the method of claim 16, as disclosed in claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert, wherein the controller is to selectively load, or the method selectively loads: a given parser configuration into the parser configuration registers for a first packet; and only part of the given parser configuration into the parser configuration registers for a second packet, as taught by Urman. The motivation to do so would have been to have a device, or method for a device, wherein a controller in the device loads a first subset of parsing configuration data into parser configuration registers for a first packet, and loads a second subset of parsing configuration data into the parser configuration registers for a second packet, wherein the second subset of parsing configuration data is a subset of the first subset of parsing configuration data, in order to be able to flexibly load parsing configuration data into parsing configuration data registers for different packets with different headers where some packets (e.g. the second packet) may have a subset of headers of other packets (e.g. the first packet).
Regarding claims 15 & 30, claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert disclose the device according to claim 1 and the method of claim 16.
Claims 10 & 21 of U.S. Patent No. 11258885 fail to disclose but Urman teaches wherein the first parser configuration includes information indicating how to parse the first header according to the given protocol (Col 5, lines 58-67 & col 6, line 1 disclose a first parse may be performed according to a default parsing configuration data set for at least one header (i.e. a first header) of a header section. Col 5, lines 33-36 disclose that the parsing configuration data set provides configuration information for parsing headers of different protocols. Thus, the default parsing configuration would include information indicating how to parse the at least one header according to a given protocol.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 1, or the method of claim 16, as disclosed in claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert, wherein the first parser configuration includes information indicating how to parse the first header according to the given protocol, as taught by Urman. The motivation to do so would have been to have a device, or method for a device, wherein the device is provided a default parsing configuration data set that provides configuration information for how to perform a first parse of a header in a header section of a packet based on of a certain protocol, so that the device is able to yield first parsed data that can provide information for how to parse a next header.
Claims 6 & 21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert et al. (US 12461885)(herein after “Herbert”), as applied to claims 1 & 16, and further in view of Bosshart et al. (US 2017/0063690)(herein after “Bosshart”).
Regarding claims 6 & 21, claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert disclose the device according to claim 1 and the method of claim 16.
Claims 10 & 21 of U.S. Patent No. 11258885 fail to disclose but Bosshart teaches wherein the controller is to receive, or the method comprises receiving, a parse graph providing corresponding configuration options for the different protocols (Fig 7 & [0071] disclose a parser configuration generator 725 (i.e. a controller) receiving a parse graph from parser graph generator 720 that is used to generate configuration data to configure a parser for each packet header type (i.e. each different protocol) that needs to be parsed.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 1 or the method of claim 16, as disclosed in claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert, wherein the controller is to receive a parse graph providing corresponding configuration options for the different protocols, as taught by Bosshart. The motivation to do so would have been to have a device , or a method for a device, where a parser configuration generator, as part of a controller in the device, receives a parse graph that is used to identify specific parser configuration options relevant to specific header types or protocols of a header, so that the controller can select a parser configuration option, optimized to parse the specific header type or protocol, to load into a register for a hardware parser to parse the header.
Claims 7, 8, 10, 22, 23 & 25 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert et al. (US 12461885)(herein after “Herbert”) and Bosshart et al. (US 2017/0063690)(herein after “Bosshart”), as applied to claims 6 and 21, and further in view of Urman et al. (US 11258885)(herein after “Urman”).
Regarding claims 7 & 22, claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart disclose the device according to claim 6 and the method of claim 21.
Claims 10 & 21 of U.S. Patent No. 11258885 fail to disclose but Urman further teaches wherein the controller is to, or the method comprises to, selectively load only some of the parser configurations of the different protocols into the parser configuration registers in order for the hardware parsers to parse the header section of the packet (Fig 3 & col 9, lines 29-43 disclose that parsing configuration data may consist of subsets of a parsing configuration data set 48. Thus, the controller may load a only some of the parser configurations of the different protocols (e.g. data subset 1) into the parser configuration registers in order to parse a header section of a packet by flexible hardware parser 40-1.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6, or the method of claim 21, as disclosed by claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart, wherein the controller is to selectively load only some of the parser configurations of the different protocols into the parser configuration registers in order for the hardware parsers to parse the header section of the packet, as further taught by Urman. The motivation to do so would have been to have a device, or a method for a device, where a controller in the device identifies a subset of parser configuration options relevant to specific header types or protocols of a header, so that the controller can select a parser configuration option, optimized to parse the subset of specific header types or protocols, to load into a register for a hardware parser to parse the header.
Claims 10 & 21 of U.S. Patent No. 11258885 fail to discuss but Bosshart teaches wherein the parser configurations of the different protocols are listed in the parse graph (Fig 7 & [0071] disclose a parse graph that is used to generate configuration data to configure a parser for each packet header type (i.e. each different protocol) that needs to be parsed.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6, or the method of claim 21, wherein the controller is to selectively load only some of the parser configurations of the different protocols into the parser configuration registers in order for the hardware parsers to parse the header section of the packet, as disclosed by claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert and Urman and Bosshart, wherein the parser configurations of the different protocols are listed in the parse graph, as taught by Bosshart. The motivation to do so would have been to have a device, or a method for a device, where a parser configuration generator, as part of a controller in the device, receives a parse graph that is used to identify a subset of parser configuration options relevant to specific header types or protocols of a header, so that the controller can select a parser configuration option, optimized to parse the subset of specific header types or protocols, to load into a register for a hardware parser to parse the header.
Regarding claim 8, claim 10 of U.S. Patent No. 11258885 in view of Herbert and Bosshart disclose the device according to claim 6.
Claim 10 of U.S. Patent No. 11258885 fail to disclose but Urman further teaches further comprising a network interface to receive the packet over a network, wherein: the hardware parsers are to receive the header section of the packet from the network interface in order to perform an initial parse of the header section (Fig 1 & col 6, lines 24-33 disclose a network interface 12 that can receive packets from a packet data network. Col 6, lines 39-49 disclose that the packets are stored in a buffer 16, for which the header section of the packets can be accessed (i.e. received) by hardware parsers 18 in order to parse (i.e. perform an initial parse) the header section.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6, as disclosed by claim 10 of U.S. Patent No. 11258885 in view of Herbert and Bosshart, further comprising a network interface to receive the packet over a network, wherein: the hardware parsers are to receive the header section of the packet from the network interface in order to perform an initial parse of the header section, as further taught by Urman. The motivation to do so would have been to have a device with a network interface that can receive a packet from a network and buffer the packet so that hardware parsers can access the header section of the packet for performing an initial parse of a header in the header section so that a controller in the device can select parser configuration options, optimized to further parse specific header types or protocols in further headers of the header section identified by the initial parse, to load into a register for the hardware parser to parse the further headers in the header section.
Claim 10 of U.S. Patent No. 11258885 fail to disclose but Bosshart teaches wherein the controller is to receive a default parse graph corresponding to the initial parse of the header section (Fig 7 & [0071] disclose a parser configuration generator 725 (i.e. a controller) receiving a parse graph (i.e. a default parse graph) from parser graph generator 720, and that the parse graph is based on the current packet header (i.e. initial parse of the header section).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6, further comprising a network interface to receive the packet over a network, wherein: the hardware parsers are to receive the header section of the packet from the network interface in order to perform an initial parse of the header section, as disclosed by claim 10 of U.S. Patent No. 11258885 in view of Herbert and Urman and Bosshart, wherein the controller is to receive a default parser graph corresponding to the initial parse of the header section, as taught by Bosshart. The motivation to do so would have been to have a device with a network interface that can receive a packet from a network and buffer the packet so that hardware parsers can access the header section of the packet for performing an initial parse of a header in the header section so that a parser configuration generator, as part of a controller in the device, can receive an initial parse graph based on the initial parse of the header section, and then select a parser configuration option, optimized to further parse specific header types or protocols in further headers of the header section identified by the initial parse, to load into a register for the hardware parser to parse the further headers in the header section.
Regarding claim 10, claim 10 of U.S. Patent No. 11258885 in view of Herbert and Bosshart disclose the device according to claim 6.
Claim 10 of U.S. Patent No. 11258885 fail to disclose but Urman further teaches wherein: the hardware parsers include native hardware parsers which have fixed parser configurations, wherein the native hardware parsers are to parse the header section until an initial flexible parser of the flexible hardware parsers is reached (Fig 2 & col 8, lines 25-48 disclose that the hardware parsers 18 of device 10 may include native hardware parsers 42 that are not reconfigurable after the network device 10 has been manufactured (i.e. fixed parser configurations). Fig 2 & col 8, lines 48-55 disclose that after a native hardware parser 42 finishes parsing part of a header section, the header section may be passed on to a flexible hardware parser 40 (i.e. when an initial flexible parser of the flexible hardware parsers is reached).);
there is an initial flexible hardware parser (Fig 2 & col 12, lines 29-30 discloses that one of the hardware parsers 42 (i.e. a flexible hardware parser) may be defined as an initial parser.); and
the controller is to load a parser configuration of the initial flexible parser into the parser configuration registers (Fig 1 & col 12, lines 23-28 disclose that controller 22 may load a default parser configuration (i.e. an initial parser configuration) into parser configuration registers 24.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6, as disclosed by claim 10 of U.S. Patent No. 11258885 in view of Herbert and Bosshart, wherein: the hardware parsers include native hardware parsers which have fixed parser configurations, wherein the native hardware parsers are to parse the header section until an initial flexible parser of the flexible hardware parsers is reached; there is an initial flexible hardware parser; and the controller is to load a parser configuration of the initial flexible parser into the parser configuration registers, as further taught by Urman. The motivation to do so would have been to have a device with both native and flexible hardware parsers that can parse a header section of a packet based on a parse graph that identifies basic headers that can be parsed first by native hardware parsers and then, through the parse graph, identifies a first optional, more advanced header so that a controller in the device can load a parser configuration for a first flexible parser of the flexible hardware parsers into parser configuration registers to parse the optional, more advanced headers, so that fast processing native hardware parsers can be used to first parse the basic headers to insure minimal delay in processing a majority of the packet header, before slower processing flexible hardware are used to parse optional, more advanced sections of the header.
Claim 10 of U.S. Patent No. 11258885 fail to disclose but Bosshart teaches wherein the parse graph includes a reference to the initial hardware parser (Fig 6 & [0065] disclose that based on a parse graph, a first packet header to be extracted (i.e. for parsing by a hardware parser) is identified.); and
wherein the loading of the parser configuration of the initial flexible parser into the parser configuration registers is based on the reference in the parse graph (Fig 6 & [0065] discloses that the parse graph identifies the first packet header to be extracted (i.e. for loading of the parser configuration of the initial flexible parser into the parser configuration registers).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6, wherein: the hardware parsers include native hardware parsers which have fixed parser configurations, wherein the native hardware parsers are to parse the header section until an initial flexible parser of the flexible hardware parsers is reached; there is an initial flexible hardware parser; and the controller is to load a parser configuration of the initial flexible parser into the parser configuration registers, as disclosed by claim 10 of U.S. Patent No. 11258885 in view of Herbert and Urman and Bosshart, wherein the parse graph includes a reference to the initial hardware parser; and wherein the loading of the parser configuration of the initial flexible parser into the parser configuration registers is based on the reference in the parse graph, as taught by Bosshart. The motivation to do so would have been to have a device with both native and flexible hardware parsers that can parse a header section of a packet based on a parse graph that identifies reference to basic headers that can be parsed first by native hardware parsers and then, through the parse graph, identifies reference to a first optional, more advanced header so that a controller in the device can load a parser configuration for a first flexible parser of the flexible hardware parsers into parser configuration registers to parse the optional, mor advanced headers, so that fast processing native hardware parsers can be used to first parse the basic headers to insure minimal delay in processing a majority of the packet header, before slower processing flexible hardware are used to parse optional, more advanced sections of the header.
Regarding claim 23, claim 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart disclose the method according to claim 21.
Claim 21 of U.S. Patent No. 11258885 fail to disclose but Urman further teaches further comprising: receiving the header section of the packet from a network interface in order to perform an initial parse of the header section (Fig 1 & col 6, lines 24-33 disclose a network interface 12 that can receive packets from a packet data network. Col 6, lines 39-49 disclose that the packets are stored in a buffer 16, for which the header section of the packets can be accessed (i.e. received) by hardware parsers 18 in order to parse (i.e. perform an initial parse) the header section.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the method of claim 21, as disclosed by claim 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart, further comprising: receiving the header section of the packet from a network interface in order to perform an initial parse of the header section, as further taught by Urman. The motivation to do so would have been to have a method for a device with a network interface that can receive a packet from a network and buffer the packet so that hardware parsers can access the header section of the packet for performing an initial parse of the header section so that information from the initial parse can be used to select a parser configuration option, optimized to further parse specific header types or protocols in further headers of the header section identified by the initial parse, to load into a register for the hardware parser to further parse the further headers.
Claim 21 of U.S. Patent No. 11258885 fail to disclose but Bosshart teaches receiving a default parse graph corresponding to the initial parse of the header section (Fig 7 & [0071] disclose a parser configuration generator 725 (i.e. a controller) receiving a parse graph (i.e. a default parse graph) from parser graph generator 720, and that the parse graph is based on the current packet header (i.e. initial parse of the header section).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the method of claim 21, further comprising: receiving the header section of the packet from a network interface in order to perform an initial parse of the header section, as disclosed by claim 21 of U.S. Patent No. 11258885 in view of Herbert and Urman and Bosshart, and receiving a default parse graph corresponding to the initial parse of the header section, as taught by Bosshart. The motivation to do so would have been to have a method for a device with a network interface that can receive a packet from a network and buffer the packet so that hardware parsers can access the header section of the packet for performing an initial parse of the header section so that a parser configuration generator, as part of a controller in the device, can receive the initial parse graph based on the initial parse of the header section, and then select a parser configuration option, optimized to further parse specific header types or protocols in further headers identified by the initial parse, to load into a register for the hardware parser to further parse the further headers.
Regarding claim 25, claim 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart disclose the method according to claim 21.
Claim 21 of U.S. Patent No. 11258885 fail to disclose but Urman further teaches further comprising: parsing the header section with native hardware parsers until an initial flexible parser is reached (Fig 2 & col 8, lines 25-48 disclose that the hardware parsers 18 of device 10 may include native hardware parsers 42 that are not reconfigurable after the network device 10 has been manufactured (i.e. fixed parser configurations). Fig 2 & col 8, lines 48-55 disclose that after a native hardware parser 42 finishes parsing part of a header section, the header section may be passed on to a flexible hardware parser 40 (i.e. when an initial flexible parser of the flexible hardware parsers is reached).);
there is an initial flexible hardware parser (Fig 2 & col 12, lines 29-30 discloses that one of the hardware parsers 42 (i.e. a flexible hardware parser) may be defined as an initial parser.); and
loading a parser configuration of the initial flexible parser into the parser configuration registers (Fig 1 & col 12, lines 23-28 disclose that controller 22 may load a default parser configuration (i.e. an initial parser configuration) into parser configuration registers 24.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the method of claim 21, as disclosed by claim 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart, further comprising: parsing the header section with native hardware parsers until an initial flexible parser is reached; there is an initial flexible hardware parser; and loading a parser configuration of the initial flexible parser into the parser configuration register, as further taught by Urman. The motivation to do so would have been to have a method for a device with both native and flexible hardware parsers that can parse a header section of a packet based on a parse graph that identifies basic headers that can be parsed first by native hardware parsers and then, through the parse graph, identifies a first optional, more advanced header so that a controller in the device can load a parser configuration for a first flexible parser of the flexible hardware parsers into parser configuration registers to parse the optional, more advanced headers, so that fast processing native hardware parsers can be used to first parse the basic headers to insure minimal delay in processing a majority of the packet header, before slower processing flexible hardware are used to parse optional, more advanced sections of the header.
Claim 21 of U.S. Patent No. 11258885 fail to disclose but Bosshart teaches wherein the parse graph includes a reference to the initial hardware parser (Fig 6 & [0065] disclose that based on a parse graph, a first packet header to be extracted (i.e. for parsing by a hardware parser) is identified.); and
wherein the loading of the parser configuration of the initial flexible parser into the parser configuration registers is based on the reference in the parse graph (Fig 6 & [0065] discloses that the parse graph identifies the first packet header to be extracted (i.e. for loading of the parser configuration of the initial flexible parser into the parser configuration registers).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the method of claim 21, wherein: the hardware parsers include native hardware parsers which have fixed parser configurations, wherein the native hardware parsers are to parse the header section until an initial flexible parser of the flexible hardware parsers is reached; there is an initial flexible hardware parser; and the controller is to load a parser configuration of the initial flexible parser into the parser configuration registers, as disclosed by claim 21 of U.S. Patent No. 11258885 in view of Herbert and Urman and Bosshart, wherein the parse graph includes a reference to the initial hardware parser; and wherein the loading of the parser configuration of the initial flexible parser into the parser configuration registers is based on the reference in the parse graph, as taught by Bosshart. The motivation to do so would have been to have a method for a device with both native and flexible hardware parsers that can parse a header section of a packet based on a parse graph that identifies reference to basic headers that can be parsed first by native hardware parsers and then, through the parse graph, identifies reference to a first optional, more advanced header so that a controller in the device can load a parser configuration for a first flexible parser of the flexible hardware parsers into parser configuration registers to parse the optional, mor advanced headers, so that fast processing native hardware parsers can be used to first parse the basic headers to insure minimal delay in processing a majority of the packet header, before slower processing flexible hardware are used to parse optional, more advanced sections of the header.
Claims 9 & 24 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert et al. (US 12461885)(herein after “Herbert”) and Bosshart et al. (US 2017/0063690)(herein after “Bosshart”) and Urman et al. (US 11258885)(herein after “Urman”), as applied to claims 8 and 23, and further in view of Kfir et al. (US 10757230)(herein after “Kfir2”).
Regarding claim 9, claim 10 of U.S. Patent No. 11258885 in view of Herbert and Bosshart and Urman disclose the device according to claim 8.
Claim 10 of U.S. Patent No. 11258885 fails to disclose but Urman further teaches further comprising a packet processing engine to: receive parsed data of the initial parse of the header section (Fig 1 & col 6, lines 50-57 discloses that hardware parsers 18 parse various headers included in the header section of packets (e.g. an initial parse) and that a packet processing engine 20 receives the parsed data from hardware parsers 18.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 8, as disclosed by claim 10 of U.S. Patent No. 11258885 in view of Herbert and Bosshart and Urman, further comprising a packet processing engine to: receive parsed data of the initial parse of the header section, as further taught by Urman. The motivation to do so would have been to have a device with a packet processing engine that can receive initial parsed data so that a parse graph identified in the initial parsed data can be sent to a controller in the device for providing packet header processing relationships with protocols of the packet headers for parsing of further headers.
Claim 10 of U.S. Patent No. 11258885 fails to disclose but Bosshart teaches further comprising: finding the parse graph based on the received parsed data (Fig 7 & [0068]-[0069] discloses that a parse graph generator (i.e. a packet processing engine) may generator (i.e. find) a parse graph based on received code and a set of match and action tables specifying one or more packet header fields (i.e. based on the received parsed data) for which packets will be matched, with corresponding actions for packets that match an entry in the match and action tables.); and
providing the parse graph to the controller, wherein the controller is to receive the parse graph (Fig 7 & [0071] disclose a parser configuration generator 725 (i.e. a controller) receiving a parse graph from parser graph generator 720.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 8, further comprising a packet processing engine to: receive parsed data of the initial parse of the header section, as disclosed by claim 10 of U.S. Patent No. 11258885 in view of Herbert and Urman and Bosshart, and finding the parse graph based on the received parsed data; and providing the parse graph to the controller, wherein the controller is to receive the parse graph, as taught by Bosshart. The motivation to do so would have been to have a device with a packet processing engine that can determine a parge graph through a parse graph generator based on received initial parsed data so that the parse graph can be sent to a controller for providing packet header processing relationships with protocols of the packet headers for parsing of further headers.
Claim 10 of U.S. Patent No. 11258885 fails to disclose but Kfir2 further teaches wherein the providing of the parse graph to the controller is through an identification of the parse graph, and wherein the receiving of the parse graph by the controller is based on the identification (Col 4, lines 16-27 disclose aliases that can be used to simplify a parse graph by identifying groups of multiple different types of sub-headers for looking up parsing instructions.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 8, further comprising a packet processing engine to: receive parsed data of the initial parse of the header section; and finding the parse graph based on the received parsed data; and providing the parse graph to the controller, wherein the controller is to receive the parse graph, as disclosed by claim 10 of U.S. Patent No. 11258885 in view of Herbert and Urman and Bosshart, wherein the providing of the parse graph to the controller is through an identification of the parse graph, and wherein the receiving of the parse graph by the controller is based on the identification, as further taught by Kfir2. The motivation to do so would have been to have a device with a packet processing engine that can determine a parse graph through a parse graph generator based on received parsed data and provide aliases to a controller for accessing specific entries in the parse graph in order to simplify the process of providing the parse graph information to the controller when the parse graph becomes very large in size.
Regarding claim 24, claim 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart disclose the method according to claim 23.
Claim 21 of U.S. Patent No. 11258885 fails to disclose but Urman further teaches further comprising: receiving parsed data of the initial parse of the header section (Fig 1 & col 6, lines 50-57 discloses that hardware parsers 18 parse various headers included in the header section of packets (e.g. an initial parse) and that a packet processing engine 20 receives the parsed data from hardware parsers 18.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the method of claim 23, as disclosed by claim 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart and Urman, further comprising: receiving parsed data of the initial parse of the header section, as further taught by Urman. The motivation to do so would have been to have a method for a device to receive initial parsed data so that a parse graph identified in the initial parsed data can be sent to a controller in the device for providing packet header processing relationships with protocols of the packet headers for parsing of further headers.
Claim 21 of U.S. Patent No. 11258885 fails to disclose but Bosshart teaches further comprising: finding the parse graph based on the received parsed data (Fig 7 & [0068]-[0069] discloses that a parse graph generator (i.e. a packet processing engine) may generator (i.e. find) a parse graph based on received code and a set of match and action tables specifying one or more packet header fields (i.e. based on the received parsed data) for which packets will be matched, with corresponding actions for packets that match an entry in the match and action tables.);
providing the parse graph (Fig 7 & [0071] disclose a parser configuration generator 725 (i.e. a controller) receiving a parse graph provided from parser graph generator 720.); and
receiving the parse graph (Fig 7 & [0071] disclose a parser configuration generator 725 (i.e. a controller) receiving a parse graph from parser graph generator 720.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the method of claim 23, further comprising: receiving parsed data of the initial parse of the header section, as disclosed by claim 21 of U.S. Patent No. 11258885 in view of Herbert and Urman and Bosshart, and further comprising: finding the parse graph based on the received parsed data; providing the parse graph; and receiving the parse graph, as taught by Bosshart. The motivation to do so would have been to have a method for a device with a packet processing engine to determine a parse graph through a parse graph generator based on received parsed data so that the parse graph can be sent to a controller for providing packet header processing relationships with protocols of the packet headers for parsing of the packet headers.
Claim 21 of U.S. Patent No. 11258885 fails to disclose but Kfir2 further teaches wherein the providing of the parse graph is through an identification of the parse graph, and wherein the receiving of the parse graph is based on the identification (Col 4, lines 16-27 disclose aliases that can be used to simplify a parse graph by identifying groups of multiple different types of sub-headers for looking up parsing instructions.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the method of claim 23, further comprising: receiving parsed data of the initial parse of the header section; finding the parse graph based on the received parsed data; providing the parse graph; and receiving the parse graph, as disclosed by claim 21 of U.S. Patent No. 11258885 in view of Herbert and Urman and Bosshart, wherein the providing of the parse graph is through an identification of the parse graph, and wherein the receiving of the parse graph is based on the identification, as further taught by Kfir2. The motivation to do so would have been to have a method for a device with a packet processing engine to determine a parge graph through a parse graph generator based on received parsed data and provide aliases to a controller for accessing specific entries in the parse graph in order to simplify the process of providing the parse graph information to the controller when the parse graph becomes very large in size.
Claims 11, 12, 26 & 27 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert et al. (US 12461885)(herein after “Herbert”) and Bosshart et al. (US 2017/0063690)(herein after “Bosshart”), as applied to claims 6 and 21, and further in view of Kfir et al. (US 10757230)(herein after “Kfir2”).
Regarding claims 11 & 26, claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart disclose the device according to claim 6 and the method of claim 21.
Claims 10 & 21 of U.S. Patent No. 11258885 fail to disclose but Kfir2 further teaches wherein the parse graph indicates whether to load a basic parsing option configuration or an advanced parsing option configuration per respective ones of the different protocols (Col 3, lines 57-67 & col 4, lines 1-5 disclose a parse graph that indicates parsing logic depending on types of sub-headers. Col 3, lines 38-56 disclose that types of sub-headers may include MAC and IP basic headers (i.e. basic headers) or extension headers (i.e. advanced headers). Thus, the parse graph would indicate to load basic parsing configurations for parsing the MAC and IP basic headers or advanced parsing configurations for parsing the extension headers.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6 or the method of claim 21, as disclosed by claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart, wherein the parse graph indicates whether to load a basic parsing option configuration or an advanced parsing option configuration per respective ones of the different protocols, as further taught by Kfir2. The motivation to do so would have been to have a device, or a method for a device, with both native and flexible hardware parsers that can parse a header section of a packet based on a parse graph that identifies reference to basic headers that can be parsed by native hardware parsers and identifies reference to more advanced header that can be parsed by flexible hardware parsers, so that fast processing native hardware parsers can be used parse the basic headers while slower processing flexible hardware are used to parse the more advanced sections of the header in order to provide a balance between processing speed and upgradability/cost by having a parser graph indicate the use of fast processing native hardware parsers process for basic headers that generally don’t change, while indicating the use of slower processing flexible hardware parsers for more advanced headers such as extension headers that can be software upgraded to address changes or the introduction of new extension headers over time.
Regarding claims 12 & 27, claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart disclose the device according to claim 6 and the method of claim 21.
Claims 10 & 21 of U.S. Patent No. 11258885 fail to disclose but Kfir2 teaches wherein the parse graph indicates whether to load a lookup table per respective ones of the different protocols (Table 1 & col 7, lines 20-50 disclose a transition table (i.e. a lookup table) that simplifies a parse graph for providing parsing instructions for sub-header types (i.e. different protocols).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6 or the method of claim 21, as disclosed by claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart, wherein the parse graph indicates whether to load a lookup table per respective ones of the different protocols, as further taught by Kfir2. The motivation to do so would have been to have a device, or a method for a device, with a parse graph that indicates to use a transition lookup table for parsing instructions for different sub-header types in order to simplify the parse graph when the size and complexity of the parse graph becomes unmanageable.
Claims 13 & 28 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert et al. (US 12461885)(herein after “Herbert”) and Bosshart et al. (US 2017/0063690)(herein after “Bosshart”), as applied to claims 6 and 21, and further in view of Opalka et al. (US 6259699)(herein after “Opalka”).
Regarding claims 13 & 28, claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart disclose the device according to claim 6 and the method of claim 21.
Claims 10 & 21 of U.S. Patent No. 11258885 fail to disclose but Opalka further teaches wherein the parse graph indicates whether to sample or skip sampling per respective ones of the different protocols (Figs 14, 17 & 18 and col 15, lines 12-32 disclose a parse graph where one element of the parse graph can be branch or leaf elements (i.e. sample) or a skip element (i.e. skip sampling).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6 or the method of claim 21, as disclosed by claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart, wherein the parse graph indicates whether to sample or skip sampling per respective ones of the different protocols, as further taught by Opalka. The motivation to do so would have been to have a device, or a method for a device, with a parse graph that can indicate to skip a header parsing element for scenarios where the header is an optional header in order to reduce processing time.
Claims 14 & 29 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert et al. (US 12461885)(herein after “Herbert”) and Bosshart et al. (US 2017/0063690)(herein after “Bosshart”), as applied to claims 6 and 21, and further in view of Kfir et al. (US 2019/0215384)(herein after “Kfir”).
Regarding claim 14 & 29, claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart disclose the device according to claim 6 and the method of claim 21.
Claims 10 & 21 of U.S. Patent No. 11258885 fail to disclose but Bosshart teaches wherein the parse graph indicates whether to load attributes per respective ones of the different protocols (Fig 7 & [0071] disclose a parse graph used to generate configuration data to configure a parser (I.e. load attributes) for each packet header type (i.e. each different protocol) that needs to be parsed.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6 or the method of claim 21, as disclosed by claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart, wherein the parse graph indicates whether to load attributes per respective ones of the different protocols, as taught by Bosshart. The motivation to do so would have been to have a device, or a method for a device, with a parse graph that is used to identify specific parser configuration options relevant to specific header types or protocols of a header, so that a controller of the device can select a parser configuration option, optimized to parse the specific header type or protocol, to load into a register for a hardware parser to parse the header.
Claims 10 & 21 of U.S. Patent No. 11258885 fail to disclose but Kfir further teaches wherein the attributes are type–length–value (TLV) attributes ([0004] discloses that IPv4 header options are often encoded in TLV format.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6 or the method of claim 21, wherein the parse graph indicates whether to load attributes per respective ones of the different protocols, as disclosed by claims 10 & 21 of U.S. Patent No. 11258885 in view of Herbert and Bosshart, wherein the attributes are type–length–value (TLV) attributes, as further taught by Kfir. The motivation to do so would have been to have a device, or a method for a device, with a parse graph that is used to identify specific parser configuration options relevant to TLV header types of a header, so that a controller of the device can select a parser configuration option, optimized to parse the TLV header type, to load into a register for a hardware parser to parse the header.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 5, 15-18, 20 & 30 are rejected under 35 U.S.C. 103 as being unpatentable over Urman et al. (US 11258885)(herein after “Urman”) in view of Herbert et al. (US 12461885)(herein after “Herbert”).
Regarding claim 1, Urman discloses a network device, comprising:
parser configuration registers (Figs 1 & 2 and col 6, lines 24-33 & col 8, lines 25-33 disclose a network device 10 including parser configuration registers 24.);
hardware parsers coupled to receive data of a header section of a packet and including flexible hardware parsers to parse the data of the header section based on parser configurations loaded into the parser configuration registers (Fig 2 & col 8, lines 15-18 & 25-64 disclose hardware parsers 18 that receive a header section of a packet for processing and including flexible hardware parsers 40 configured to parse the header section according to data in the parser configuration registers 24. Fig 3 & col 9, lines 38-34 disclose that the parser configuration data is loaded into parser configuration registers 24.); and
a controller to selectively load the parser configurations associated with different protocols for parsing respective headers of the header section of the packet into the parser configuration registers such that a next parser configuration is loaded into the parser configuration registers in response to finding a next protocol found while parsing a previous header of the header section (Fig 1 & col 6, lines 39-49 disclose a controller 22 that, under instruction by processing engine 20, selectively loads parsing configuration data into parser registers 24 for parsing respective headers of a header section of a packet received by network interface 12. Col 5, lines 33-36 disclose that the parser configuration data may be associated with different respective protocols. Fig 6 & col 12, lines 34-59 disclose loading a selected parsing configuration data set (i.e. a next parser configuration) into parser configuration registers 24 in response to parsing of a header of a default parsing configuration data set (i.e. a previous header of the header section) using match and action tables 28 . Col 6, lines 60-67 & col 7, lines 1-17 disclose that the action tables 28 include data for protocols such as TCP or UDP to be matched to the parsed information. Therefore, the selected parsing configuration set loaded into the parser configuration registers 24 is in response to protocols found through action tables 28 while parsing the header using the default parsing configuration.).
Urman fails to disclose but Herbert teaches wherein the selection is one-by-one on demand for each of the respective headers of the header section (Fig 10, col 16, lines 51-67 & col 17, lines 1-27 disclose parsing of a packet wherein after completion of parsing a header, CAM and array lookup instructions are used to lookup a next protocol which in response sets a next parser register. The example in figure 10 & col 17, lines 13-27 discloses a packet being parsed wherein each header of the header section is parsed, and in response to completion of each header, CAM and array lookup instructions are used to find a next protocol for setting a next parser register, one-by-one and on demand, for parsing the next protocol header. Specifically, the example discloses a packet being parsed wherein an Ethernet header of the header section is parsed, and in response to completion of parsing the Ethernet header, CAM and array lookup instructions are used find a next protocol being IPv4 for a next header and setting parser registers for parsing the IPv4 header, then in response to completion of parsing the IPv4 header, CAM and array lookup instructions are used to find a next protocol being TCP for a next header and setting parser registers for parsing the TCP header.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have a network device, comprising: parser configuration registers; hardware parsers coupled to receive data of a header section of a packet and including flexible hardware parsers to parse the data of the header section based on parser configurations loaded into the parser configuration registers; and a controller to selectively load the parser configurations associated with different protocols for parsing respective headers of the header section of the packet into the parser configuration registers such that a next parser configuration is loaded into the parser configuration registers in response to parsing a previous header of the header section, as disclosed by Urman, wherein the selection is one-by-one on demand for each of the respective headers of the header section, as taught by Herbert. The motivation to do so would have been to have a network device that can avoid pre-loading of incorrect parser configurations into the parser configuration registers that would cause dropped packets and routing errors by always checking a next protocol indication in a previous header before setting and loading the parser configurations for parsing the next header.
Regarding claim 2, Urman in view of Herbert disclose the network device of claim 1.
Urman discloses wherein:
the flexible hardware parsers include a first flexible hardware parser and a second flexible hardware parser (Fig 3 & Col 9, lines 29-43 disclose a first flexible hardware parser 40-1 and a second flexible hardware parser 40-2.);
the controller is to load a first parser configuration associated with a given protocol into the parser configuration registers (Figs 1 & 6 and col 12, lines 23-28 disclose controller 22 is configured to load a default parsing configuration set (i.e. a first parser configuration) into parser configuration registers 24.);
the first flexible hardware parser is to: parse a first header of the header section according to the loaded first parser configuration yielding first parsed data (Figs 1 & 6 and col 12, lines 29-36 disclose an initial hardware parser (i.e. first flexible hardware parser) is configured to parse at least one of the headers of the header section (i.e. a first header) responsively to the default parsing configuration data set, yielding first parse data.); and
find a next protocol of a second header of the header section based on the first parsed data (Figs 1-3 and col 8, lines 43-67 disclose that when one hardware parser (e.g. first flexible hardware parser 40-1) finishes parsing part of the header section (i.e. first parsed data), the header section is passed to a next hardware parser (e.g. second flexible hardware parser 40-2). Figs 1, 4 & 5 and col 11, lines 51-67 & col 12, lines 1-12 disclose that upon flexible hardware 40-1 yielding first parsed data, first hardware parser 40-1 is configured to retrieve from a data subset 50 a next protocol to be processed from a next protocol table 62 for parsing the next header (i.e. second header) of the header section.);
the controller is to load a second parser configuration associated with the found next protocol of the second header into the parser configuration registers in response to finding the next protocol of the second header based on the first parsed data (Figs 1 & 6 and col 12, lines 47-67 disclose controller 22 is configured to load a selected parsing configuration set (i.e. a second parser configuration) into parser configuration registers 24 for parsing respective ones of the headers (i.e. the second header) of the header section to yield second parsed data. The selected parsing configuration is responsive to the first parsed data (i.e. associated with the found next protocol of the second header).); and
the second flexible hardware parser is to parse the second header according to the loaded second parser configuration yielding second parsed data (Figs 1 & 6 and col 12, lines 63-66 discloses the hardware parsers (i.e. the second flexible hardware parser) are configured to parse respective ones of the headers (i.e. the second header) responsively to the selected parsing configuration (i.e. the loaded second parser configuration), yielding second parsed data.).
Regarding claim 3, Urman in view of Herbert disclose the network device of claim 2.
Urman discloses wherein: the first parser configuration includes a next protocol table providing a mapping between next header identifications and next protocols (Fig 4 & col 10, lines 5-6 disclose a next protocol table 62 which maps next header identifications with protocols.); and
the first flexible hardware parser is to find the next header protocol of the second header by matching a next header identification included in the first header with one of the next header identifications included in the next protocol table (Figs 1, 4 & 5 and col 11, lines 51-67 & col 12, lines 1-12 disclose that flexible hardware parser 40-1 may retrieve a next protocol for the next header (i.e. the second header) of the header section through a next protocol table 62 responsively to a retrieved next header ID in the header (i.e. the first header) of the header section, wherein the next protocol table 62 links the next header ID with next protocols.).
Regarding claims 5 & 20, Urman discloses the device according to claim 1 or the method of claim 16.
Urman discloses wherein the controller is to selectively load, or the method selectively loads: a given parser configuration into the parser configuration registers for a first packet (Fig 1 & col 6, lines 39-49 disclose a controller 22 that selectively loads parsing configuration data into parser registers 24 for packets received (i.e. a first packet).); and
only part of the given parser configuration into the parser configuration registers for a second packet (Col 1, lines 19-24 disclose that custom headers can vary from packet to packet. Fig 3 & col 9, lines 29-43 disclose that parsing configuration data may consist of subsets of a parsing configuration data set 48. Thus, the controller may load a given parser configuration into the parser configuration registers for the first packet to be parsed by flexible hardware parser 40-1 based on a data subset 1, and load only part of the given parser configuration into the parser configuration registers for a second packet to be parsed by flexible hardware parser 40-2 based on a data subset 2, which may be a subset of data subset 1.).
Regarding claims 15 & 30, Urman discloses the device according to claim 1 or the method of claim 16.
Urman discloses wherein the first parser configuration includes information indicating how to parse the first header according to the given protocol (Col 5, lines 58-67 & col 6, lines 1-3 disclose a first parse may be performed according to a default parsing configuration data set indicating how to parse a header (i.e. a first header). Col 5, lines 33-36 disclose that the parsing configuration data set provides configuration information for parsing headers of different protocols.).
Regarding claim 16, Urman discloses a method, comprising:
receiving data of a header section of a packet (Figs 2 & 5 and col 11, lines 5-7 disclose a parsing method for a device 10. Fig 2 & col 8, lines 15-18 & 25-64 disclose hardware parsers 18 that receive a header section of a packet for processing.);
selectively loading parser configurations associated with different protocols for parsing respective headers of the header section of the packet into parser configuration registers such that a next parser configuration is loaded into the parser configuration registers in response to finding a next protocol found while parsing a previous header of the header section (Fig 1 & col 6, lines 39-49 disclose a controller 22 that, under instruction by processing engine 20, selectively loads parsing configuration data into parser registers 24 for parsing respective headers of a header section of a packet received by network interface 12. Col 5, lines 33-36 disclose that the parser configuration data may be associated with different respective protocols. Fig 6 & col 12, lines 34-59 disclose loading a selected parsing configuration data set (i.e. a next parser configuration) into parser configuration registers 24 in response to parsing of a header of a default parsing configuration data set (i.e. a previous header of the header section) using match and action tables 28 . Col 6, lines 60-67 & col 7, lines 1-17 disclose that the action tables 28 include data for protocols such as TCP or UDP to be matched to the parsed information. Therefore, the selected parsing configuration set loaded into the parser configuration registers 24 is in response to protocols found through action tables 28 while parsing the header using the default parsing configuration.); and
parsing the data of the header section based on the parser configurations loaded into the parser configuration registers (Fig 6 & col 12, lines 63-66 disclose that hardware parsers 40, 42 are configured to parse the headers of the header section based on the selected parsing configuration data set that were loaded into registers 24 to yield second parsed data.).
Urman fails to disclose but Herbert teaches wherein the selection is one-by-one on demand for each of the respective headers of the header section (Fig 10, col 16, lines 51-67 & col 17, lines 1-27 disclose parsing of a packet wherein after completion of parsing a header, CAM and array lookup instructions are used to lookup a next protocol which in response sets a next parser register. The example in figure 10 & col 17, lines 13-27 discloses a packet being parsed wherein each header of the header section is parsed, and in response to completion of each header, CAM and array lookup instructions are used to find a next protocol for setting a next parser register, one-by-one and on demand, for parsing the next protocol header. Specifically, the example discloses a packet being parsed wherein an Ethernet header of the header section is parsed, and in response to completion of parsing the Ethernet header, CAM and array lookup instructions are used find a next protocol being IPv4 for a next header and setting parser registers for parsing the IPv4 header, then in response to completion of parsing the IPv4 header, CAM and array lookup instructions are used to find a next protocol being TCP for a next header and setting parser registers for parsing the TCP header.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have a method, comprising: receiving data of a header section of a packet; selectively loading parser configurations associated with different protocols for parsing respective headers of the header section of the packet into parser configuration registers such that a next parser configuration is loaded into the parser configuration registers in response to finding a next protocol found while parsing a previous header of the header section; and parsing the data of the header section based on the parser configurations loaded into the parser configuration registers, as disclosed by Urman, wherein the selection is one-by-one on demand for each of the respective headers of the header section, as taught by Herbert. The motivation to do so would have been to have a method for a network device to avoid pre-loading of incorrect parser configurations into the parser configuration registers that would cause dropped packets and routing errors by always checking a next protocol indication in a previous header before setting and loading the parser configurations for parsing the next header.
Regarding claim 17, Urman in view of Herbert disclose the method according to claim 16.
Urman discloses further comprising:
loading a first parser configuration associated with a given protocol into the parser configuration registers (Figs 1 & 6 and col 12, lines 23-28 disclose controller 22 is configured to load a default parsing configuration set (i.e. a first parser configuration) into parser configuration registers 24.);
parsing a first header of the header section according to the loaded first parser configuration yielding first parsed data (Figs 1 & 6 and col 12, lines 29-36 disclose an initial hardware parser (i.e. first flexible hardware parser) is configured to parse at least one of the headers of the header section (i.e. a first header) responsively to the default parsing configuration data set, yielding first parse data.);
finding a next protocol of a second header of the header section based on the first parsed data (Figs 1-3 and col 8, lines 43-67 disclose that when one hardware parser (e.g. first flexible hardware parser 40-1) finishes parsing part of the header section (i.e. first parsed data), the header section is passed to a next hardware parser (e.g. second flexible hardware parser 40-2). Figs 1, 4 & 5 and col 11, lines 51-67 & col 12, lines 1-12 disclose that upon flexible hardware 40-1 yielding first parsed data, first hardware parser 40-1 is configured to retrieve from a data subset 50 a next protocol to be processed from a next protocol table 62 for parsing the next header (i.e. second header) of the header section.);
loading a second parser configuration associated with the found next protocol of the second header into the parser configuration registers in response to finding the next protocol of the second header based on the first parsed data (Figs 1 & 6 and col 12, lines 47-67 disclose controller 22 is configured to load a selected parsing configuration set (i.e. a second parser configuration) into parser configuration registers 24 for parsing respective ones of the headers (i.e. the second header) of the header section to yield second parsed data. The selected parsing configuration is responsive to the first parsed data (i.e. associated with the found next protocol of the second header).); and
parsing the second header according to the loaded second parser configuration yielding second parsed data (Figs 1 & 6 and col 12, lines 63-66 discloses the hardware parsers (i.e. the second flexible hardware parser) are configured to parse respective ones of the headers (i.e. the second header) responsively to the selected parsing configuration (i.e. the loaded second parser configuration), yielding second parsed data.).
Regarding claim 18, Urman in view of Herbert disclose the method according to claim 17.
Urman discloses wherein: the first parser configuration includes a next protocol table providing a mapping between next header identifications and next protocols (Fig 4 & col 10, lines 5-6 disclose a next protocol table 62 which maps next header identifications with protocols.); and
the finding includes finding the next header protocol of the second header by matching a next header identification included in the first header with one of the next header identifications included in the next protocol table (Figs 1, 4 & 5 and col 11, lines 51-67 & col 12, lines 1-12 disclose that flexible hardware parser 40-1 may retrieve a next protocol for the next header (i.e. the second header) of the header section through a next protocol table 62 responsively to a retrieved next header ID in the header (i.e. the first header) of the header section, wherein the next protocol table 62 links the next header ID with next protocols.).
Claims 4 & 19 are rejected under 35 U.S.C. 103 as being unpatentable over Urman et al. (US 11258885)(herein after “Urman”) in view of Herbert et al. (US 12461885)(herein after “Herbert”), as applied to claims 1 & 16 respectively, and further in view of Kfir et al. (US 2019/0215384)(herein after “Kfir”).
Regarding claims 4 & 19, Urman in view of Herbert discloses the device according to claim 1 and the method according to claim 16.
Urman fails to disclose but Kfir further teaches wherein respective ones of the protocols include a basic parsing option configuration and an advanced parsing option configuration (Fig 2 & [0035]-[0044] discloses different parsing options including an option to parse fixed parts of a header (i.e. a basic parsing option configuration for parsing fixed parts of the header such as a MAC header, IPv4 basic header and UDP upper-layer header) and an option to parse optional records of the header (i.e. an advanced parsing option configuration for parsing optional records such as TLV fields.).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 1 or the method of claim 16, as disclosed by Urman in view of Herbert, wherein respective ones of the protocols include a basic parsing option configuration and an advanced parsing option configuration, as further taught by Kfir. The motivation to do so would have been to have certain devices, or a method for certain devices, that perform only basic parsing of fixed headers such as a MAC header, IPv4 basic header and a UDP upper-layer header, in order to be lower cost with less memory, while having other devices that perform more advanced parsing of not only fixed headers but also optional headers such as TLV fields in order to support advanced network functions such as network security and route monitoring.
Claims 6-8, 10, 21-23 & 25 are rejected under 35 U.S.C. 103 as being unpatentable over Urman et al. (US 11258885)(herein after “Urman”) in view of Herbert et al. (US 12461885)(herein after “Herbert”), as applied to claims 1 & 16 respectively, and further in view of Bosshart et al. (US 2017/0063690)(herein after “Bosshart”).
Regarding claims 6 & 21, Urman in view of Herbert discloses the device according to claim 1 and the method of claim 16.
Urman fails to disclose but Bosshart further teaches wherein the controller is to receive, or the method comprises receiving, a parse graph providing corresponding configuration options for the different protocols (Fig 7 & [0071] disclose a parser configuration generator 725 (i.e. a controller) receiving a parse graph from parser graph generator 720 that is used to generate configuration data to configure a parser for each packet header type (i.e. each different protocol) that needs to be parsed.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 1 or the method of claim 16, as disclosed by Urman in view of Herbert, wherein the controller is to receive a parse graph providing corresponding configuration options for the different protocols, as further taught by Bosshart. The motivation to do so would have been to have a device , or a method for a device, where a parser configuration generator, as part of a controller in the device, receives a parse graph that is used to identify specific parser configuration options relevant to specific header types or protocols of a header, so that the controller can select a parser configuration option, optimized to parse the specific header type or protocol, to load into a register for a hardware parser to parse the header.
Regarding claims 7 & 22, Urman in view of Herbert and Bosshart disclose the device according to claim 6 and the method of claim 21.
Urman discloses wherein the controller is to, or the method comprises to, selectively load only some of the parser configurations of the different protocols into the parser configuration registers in order for the hardware parsers to parse the header section of the packet (Fig 3 & col 9, lines 29-43 disclose that parsing configuration data may consist of subsets of a parsing configuration data set 48. Thus, the controller may load only some of the parser configurations of the different protocols (e.g. data subset 1) into the parser configuration registers in order to parse a header section of a packet by flexible hardware parser 40-1.).
Urman fails to disclose but Bosshart further teaches wherein the parser configurations of the different protocols are listed in the parse graph (Fig 7 & [0071] disclose a parse graph that is used to generate configuration data to configure a parser for each packet header type (i.e. each different protocol) that needs to be parsed.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6 or the method of claim 21, wherein the controller is to selectively load only some of the parser configurations of the different protocols into the parser configuration registers in order for the hardware parsers to parse the header section of the packet, as disclosed by Urman in view of Herbert and Bosshart, wherein the parser configurations of the different protocols are listed in the parse graph, as further taught by Bosshart. The motivation to do so would have been to have a device, or a method for a device, where a parser configuration generator, as part of a controller in the device, receives a parse graph that is used to identify a subset of parser configuration options relevant to specific header types or protocols of a header, so that the controller can select a parser configuration option, optimized to parse the subset of specific header types or protocols, to load into a register for a hardware parser to parse the header.
Regarding claim 8, Urman in view of Herbert and Bosshart disclose the device according to claim 6.
Urman discloses further comprising a network interface to receive the packet over a network, wherein: the hardware parsers are to receive the header section of the packet from the network interface in order to perform an initial parse of the header section (Fig 1 & col 6, lines 24-33 disclose a network interface 12 that can receive packets from a packet data network. Col 6, lines 39-49 disclose that the packets are stored in a buffer 16, for which the header section of the packets can be accessed (i.e. received) by hardware parsers 18 in order to parse (i.e. perform an initial parse) the header section.); and
Urman fails to disclose but Bosshart further teaches wherein the controller is to receive a default parse graph corresponding to the initial parse of the header section (Fig 7 & [0071] disclose a parser configuration generator 725 (i.e. a controller) receiving a parse graph (i.e. a default parse graph) from parser graph generator 720, and that the parse graph is based on the current packet header (i.e. initial parse of the header section).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6, further comprising a network interface to receive the packet over a network, wherein: the hardware parsers are to receive the header section of the packet from the network interface in order to perform an initial parse of the header section, as disclosed by Urman in view of Herbert and Bosshart, wherein the controller is to receive a default parser graph corresponding to the initial parse of the header section, as further taught by Bosshart. The motivation to do so would have been to have a device with a network interface that can receive a packet from a network and buffer the packet so that hardware parsers can access the header section of the packet for performing an initial parse of the header section so that a parser configuration generator, as part of a controller in the device, can receive the initial parse graph based on the initial parse of the header section, and then select a parser configuration option, optimized to further parse specific header types or protocols in the header identified by the initial parse, to load into a register for the hardware parser to further parse the header.
Regarding claim 10, Urman in view of Herbert and Bosshart disclose the device according to claim 6.
Urman discloses wherein: the hardware parsers include native hardware parsers which have fixed parser configurations, wherein the native hardware parsers are to parse the header section until an initial flexible parser of the flexible hardware parsers is reached (Fig 2 & col 8, lines 25-48 disclose that the hardware parsers 18 of device 10 may include native hardware parsers 42 that are not reconfigurable after the network device 10 has been manufactured (i.e. fixed parser configurations). Fig 2 & col 8, lines 48-55 disclose that after a native hardware parser 42 finishes parsing part of a header section, the header section may be passed on to a flexible hardware parser 40 (i.e. when an initial flexible parser of the flexible hardware parsers is reached).);
there is an initial flexible hardware parser (Fig 2 & col 12, lines 29-30 discloses that one of the hardware parsers 42 (i.e. a flexible hardware parser) may be defined as an initial parser.); and
the controller is to load a parser configuration of the initial flexible parser into the parser configuration registers (Fig 1 & col 12, lines 23-28 disclose that controller 22 may load a default parser configuration (i.e. an initial parser configuration) into parser configuration registers 24.).
Urman fails to disclose but Bosshart further teaches wherein the parse graph includes a reference to the initial hardware parser (Fig 6 & [0065] disclose that based on a parse graph, a first packet header to be extracted (i.e. for parsing by a hardware parser) is identified.); and
wherein the loading of the parser configuration of the initial flexible parser into the parser configuration registers is based on the reference in the parse graph (Fig 6 & [0065] discloses that the parse graph identifies the first packet header to be extracted (i.e. for loading of the parser configuration of the initial flexible parser into the parser configuration registers).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6, wherein: the hardware parsers include native hardware parsers which have fixed parser configurations, wherein the native hardware parsers are to parse the header section until an initial flexible parser of the flexible hardware parsers is reached; there is an initial flexible hardware parser; and the controller is to load a parser configuration of the initial flexible parser into the parser configuration registers, as disclosed by Urman in view of Herbert and Bosshart, wherein the parse graph includes a reference to the initial hardware parser; and wherein the loading of the parser configuration of the initial flexible parser into the parser configuration registers is based on the reference in the parse graph, as further taught by Bosshart. The motivation to do so would have been to have a device with both native and flexible hardware parsers that can parse a header section of a packet based on a parse graph that identifies reference to basic headers that can be parsed by native hardware parsers and then, through the parse graph, identifies reference to a first optional, more advanced header so that a controller in the device can load a parser configuration for a first flexible parser of the flexible hardware parsers into parser configuration registers to parse the optional, mor advanced headers, so that fast processing native hardware parsers can be used to first parse the basic headers to insure minimal delay in processing a majority of the packet header, before slower processing flexible hardware are used to parse optional, more advanced sections of the header.
Regarding claim 23, Urman in view of Herbert and Bosshart disclose the method according to claim 21.
Urman discloses further comprising: receiving the header section of the packet from a network interface in order to perform an initial parse of the header section (Fig 1 & col 6, lines 24-33 disclose a network interface 12 that can receive packets from a packet data network. Col 6, lines 39-49 disclose that the packets are stored in a buffer 16, for which the header section of the packets can be accessed (i.e. received) by hardware parsers 18 in order to parse (i.e. perform an initial parse) the header section.); and
Urman fails to disclose but Bosshart further teaches receiving a default parse graph corresponding to the initial parse of the header section (Fig 7 & [0071] disclose a parser configuration generator 725 (i.e. a controller) receiving a parse graph (i.e. a default parse graph) from parser graph generator 720, and that the parse graph is based on the current packet header (i.e. initial parse of the header section).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the method of claim 21, further comprising: receiving the header section of the packet from a network interface in order to perform an initial parse of the header section, as disclosed by Urman in view of Herbert and Bosshart, and receiving a default parse graph corresponding to the initial parse of the header section, as further taught by Bosshart. The motivation to do so would have been to have a method for a device with a network interface that can receive a packet from a network and buffer the packet so that hardware parsers can access the header section of the packet for performing an initial parse of the header section so that a parser configuration generator, as part of a controller in the device, can receive the initial parse graph based on the initial parse of the header section, and then select a parser configuration option, optimized to further parse specific header types or protocols in the header identified by the initial parse, to load into a register for the hardware parser to further parse the header.
Regarding claim 25, Urman in view of Herbert and Bosshart disclose the method according to claim 21.
Urman discloses further comprising: parsing the header section with native hardware parsers until an initial flexible parser is reached (Fig 2 & col 8, lines 25-48 disclose that the hardware parsers 18 of device 10 may include native hardware parsers 42 that are not reconfigurable after the network device 10 has been manufactured (i.e. fixed parser configurations). Fig 2 & col 8, lines 48-55 disclose that after a native hardware parser 42 finishes parsing part of a header section, the header section may be passed on to a flexible hardware parser 40 (i.e. when an initial flexible parser of the flexible hardware parsers is reached).);
there is an initial flexible hardware parser (Fig 2 & col 12, lines 29-30 discloses that one of the hardware parsers 42 (i.e. a flexible hardware parser) may be defined as an initial parser.); and
loading a parser configuration of the initial flexible parser into the parser configuration registers (Fig 1 & col 12, lines 23-28 disclose that controller 22 may load a default parser configuration (i.e. an initial parser configuration) into parser configuration registers 24.).
Urman fails to disclose but Bosshart further teaches wherein the parse graph includes a reference to the initial hardware parser (Fig 6 & [0065] disclose that based on a parse graph, a first packet header to be extracted (i.e. for parsing by a hardware parser) is identified.); and
wherein the loading of the parser configuration of the initial flexible parser into the parser configuration registers is based on the reference in the parse graph (Fig 6 & [0065] discloses that the parse graph identifies the first packet header to be extracted (i.e. for loading of the parser configuration of the initial flexible parser into the parser configuration registers).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the method of claim 21, further comprising: parsing the header section with native hardware parsers until an initial flexible parser is reached; there is an initial flexible hardware parser; and loading a parser configuration of the initial flexible parser into the parser configuration register, as disclosed by Urman in view of Herbert and Bosshart, wherein the parse graph includes a reference to the initial hardware parser; and wherein the loading of the parser configuration of the initial flexible parser into the parser configuration registers is based on the reference in the parse graph, as further taught by Bosshart. The motivation to do so would have been to have a method for a device with both native and flexible hardware parsers that can parse a header section of a packet based on a parse graph that identifies reference to basic headers that can be parsed by native hardware parsers and then, through the parse graph, identifies reference to a first optional, more advanced header so that a controller in the device can load a parser configuration for a first flexible parser of the flexible hardware parsers into parser configuration registers to parse the optional, mor advanced headers, so that fast processing native hardware parsers can be used to first parse the basic headers to insure minimal delay in processing a majority of the packet header, before slower processing flexible hardware are used to parse optional, more advanced sections of the header.
Claims 9, 11, 12, 24, 26 & 27 are rejected under 35 U.S.C. 103 as being unpatentable over Urman et al. (US 11258885)(herein after “Urman”) in view of Herbert et al. (US 12461885)(herein after “Herbert”) and Bosshart et al. (US 2017/0063690)(herein after “Bosshart”), as applied to claims 8 & 23, and further in view of Kfir et al. (US 10757230)(herein after “Kfir2”).
Regarding claim 9, Urman in view of Herbert and Bosshart disclose the device according to claim 8.
Urman discloses further comprising a packet processing engine to: receive parsed data of the initial parse of the header section (Fig 1 & col 6, lines 50-57 discloses that hardware parsers 18 parse various headers included in the header section of packets (e.g. an initial parse) and that a packet processing engine 20 receives the parsed data from hardware parsers 18.);
Urman fails to disclose but Bosshart further teaches further comprising: finding the parse graph based on the received parsed data (Fig 7 & [0068]-[0069] discloses that a parse graph generator (i.e. a packet processing engine) may generator (i.e. find) a parse graph based on received code and a set of match and action tables specifying one or more packet header fields (i.e. based on the received parsed data) for which packets will be matched, with corresponding actions for packets that match an entry in the match and action tables.); and
providing the parse graph to the controller, wherein the controller is to receive the parse graph (Fig 7 & [0071] disclose a parser configuration generator 725 (i.e. a controller) receiving a parse graph from parser graph generator 720.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 8, further comprising a packet processing engine to: receive parsed data of the initial parse of the header section, as disclosed by Urman in view of Bosshart, and finding the parse graph based on the received parsed data; and providing the parse graph to the controller, wherein the controller is to receive the parse graph, as further taught by Bosshart. The motivation to do so would have been to have a device with a packet processing engine that can determine a parge graph through a parse graph generator based on received parsed data so that the parse graph can be sent to a controller for providing packet header processing relationships with protocols of the packet headers for parsing of the packet headers.
Urman fails to disclose but Kfir2 further teaches wherein the providing of the parse graph to the controller is through an identification of the parse graph, and wherein the receiving of the parse graph by the controller is based on the identification (Col 4, lines 16-27 disclose aliases that can be used to simplify a parse graph by identifying groups of multiple different types of sub-headers for looking up parsing instructions.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 8, further comprising a packet processing engine to: receive parsed data of the initial parse of the header section; and finding the parse graph based on the received parsed data; and providing the parse graph to the controller, wherein the controller is to receive the parse graph, as disclosed by Urman in view of Bosshart, wherein the providing of the parse graph to the controller is through an identification of the parse graph, and wherein the receiving of the parse graph by the controller is based on the identification, as further taught by Kfir2. The motivation to do so would have been to have a device with a packet processing engine that can determine a parge graph through a parse graph generator based on received parsed data and provide aliases to a controller for accessing specific entries in the parse graph in order to simplify the process of providing the parse graph information to the controller when the parse graph becomes very large in size.
Regarding claims 11 & 26, Urman in view of Herbert and Bosshart disclose the device according to claim 6 and the method of claim 21.
Urman fails to disclose but Kfir2 further teaches wherein the parse graph indicates whether to load a basic parsing option configuration or an advanced parsing option configuration per respective ones of the different protocols (Col 3, lines 57-67 & col 4, lines 1-5 disclose a parse graph that indicates parsing logic depending on types of sub-headers. Col 3, lines 38-56 disclose that types of sub-headers may include MAC and IP basic headers (i.e. basic headers) or extension headers (i.e. advanced headers). Thus, the parse graph would indicate to load basic parsing configurations for parsing the MAC and IP basic headers or advanced parsing configurations for parsing the extension headers.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6 or the method of claim 21, as disclosed by Urman in view of Herbert and Bosshart, wherein the parse graph indicates whether to load a basic parsing option configuration or an advanced parsing option configuration per respective ones of the different protocols, as further taught by Kfir2. The motivation to do so would have been to have a device, or a method for a device, with both native and flexible hardware parsers that can parse a header section of a packet based on a parse graph that identifies reference to basic headers that can be parsed by native hardware parsers and identifies reference to more advanced header that can be parsed by flexible hardware parsers, so that fast processing native hardware parsers can be used parse the basic headers while slower processing flexible hardware are used to parse the more advanced sections of the header in order to provide a balance between processing speed and upgradability/cost by having a parser graph indicate the use of fast processing native hardware parsers process for basic headers that generally don’t change, while indicating the use of slower processing flexible hardware parsers for more advanced headers such as extension headers that can be software upgraded to address changes or the introduction of new extension headers over time.
Regarding claims 12 & 27, Urman in view of Herbert and Bosshart disclose the device according to claim 6 and the method of claim 21.
Urman fails to disclose but Kfir2 further teaches wherein the parse graph indicates whether to load a lookup table per respective ones of the different protocols (Table 1 & col 7, lines 20-50 disclose a transition table (i.e. a lookup table) that simplifies a parse graph for providing parsing instructions for sub-header types (i.e. different protocols).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6 or the method of claim 21, as disclosed by Urman in view of Herbert and Bosshart, wherein the parse graph indicates whether to load a lookup table per respective ones of the different protocols, as further taught by Kfir2. The motivation to do so would have been to have a device, or a method for a device, with a parse graph that indicates to use a transition lookup table for parsing instructions for different sub-header types in order to simplify the parse graph when the size and complexity of the parse graph becomes unmanageable.
Regarding claim 24, Urman in view of Herbert and Bosshart disclose the method according to claim 23.
Urman discloses further comprising: receiving parsed data of the initial parse of the header section (Fig 1 & col 6, lines 50-57 discloses that hardware parsers 18 parse various headers included in the header section of packets (e.g. an initial parse) and that a packet processing engine 20 receives the parsed data from hardware parsers 18.);
Urman fails to disclose but Bosshart further teaches further comprising: finding the parse graph based on the received parsed data (Fig 7 & [0068]-[0069] discloses that a parse graph generator (i.e. a packet processing engine) may generator (i.e. find) a parse graph based on received code and a set of match and action tables specifying one or more packet header fields (i.e. based on the received parsed data) for which packets will be matched, with corresponding actions for packets that match an entry in the match and action tables.);
providing the parse graph (Fig 7 & [0071] disclose a parser configuration generator 725 (i.e. a controller) receiving a parse graph provided from parser graph generator 720.); and
receiving the parse graph (Fig 7 & [0071] disclose a parser configuration generator 725 (i.e. a controller) receiving a parse graph from parser graph generator 720.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the method of claim 23, further comprising: receiving parsed data of the initial parse of the header section, as disclosed by Urman in view of Bosshart, and further comprising: finding the parse graph based on the received parsed data; providing the parse graph; and receiving the parse graph, as further taught by Bosshart. The motivation to do so would have been to have a method for a device with a packet processing engine to determine a parse graph through a parse graph generator based on received parsed data so that the parse graph can be sent to a controller for providing packet header processing relationships with protocols of the packet headers for parsing of the packet headers.
Urman fails to disclose but Kfir2 further teaches wherein the providing of the parse graph is through an identification of the parse graph, and wherein the receiving of the parse graph is based on the identification (Col 4, lines 16-27 disclose aliases that can be used to simplify a parse graph by identifying groups of multiple different types of sub-headers for looking up parsing instructions.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the method of claim 23, further comprising: receiving parsed data of the initial parse of the header section; finding the parse graph based on the received parsed data; providing the parse graph; and receiving the parse graph, as disclosed by Urman in view of Bosshart, wherein the providing of the parse graph is through an identification of the parse graph, and wherein the receiving of the parse graph is based on the identification, as further taught by Kfir2. The motivation to do so would have been to have a method for a device with a packet processing engine to determine a parge graph through a parse graph generator based on received parsed data and provide aliases to a controller for accessing specific entries in the parse graph in order to simplify the process of providing the parse graph information to the controller when the parse graph becomes very large in size.
Claims 13 & 28 are rejected under 35 U.S.C. 103 as being unpatentable over Urman et al. (US 11258885)(herein after “Urman”) in view of Herbert et al. (US 12461885)(herein after “Herbert”) and Bosshart et al. (US 2017/0063690)(herein after “Bosshart”), as applied to claims 6 & 21, and further in view of Opalka et al. (US 6259699)(herein after “Opalka”).
Regarding claims 13 & 28, Urman in view of Herbert and Bosshart disclose the device according to claim 6 and the method of claim 21.
Urman fails to disclose but Opalka further teaches wherein the parse graph indicates whether to sample or skip sampling per respective ones of the different protocols (Figs 14, 17 & 18 and col 15, lines 12-32 disclose a parse graph where one element of the parse graph can be branch or leaf elements (i.e. sample) or a skip element (i.e. skip sampling).).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6 or the method of claim 21, as disclosed by Urman in view of Herbert and Bosshart, wherein the parse graph indicates whether to sample or skip sampling per respective ones of the different protocols, as further taught by Opalka. The motivation to do so would have been to have a device, or a method for a device, with a parse graph that can indicate to skip a header parsing element for scenarios where the header is an optional header in order to reduce processing time.
Claims 14 & 29 are rejected under 35 U.S.C. 103 as being unpatentable over Urman et al. (US 11258885)(herein after “Urman”) in view of Herbert et al. (US 12461885)(herein after “Herbert”) and Bosshart et al. (US 2017/0063690)(herein after “Bosshart”), as applied to claims 6 & 21 respectively, and further in view of Kfir et al. (US 2019/0215384)(herein after “Kfir”).
Regarding claim 14 & 29, Urman in view of Herbert and Bosshart disclose the device according to claim 6 and the method of claim 21.
Urman fails to disclose but Bosshart further teaches wherein the parse graph indicates whether to load attributes per respective ones of the different protocols (Fig 7 & [0071] disclose a parse graph used to generate configuration data to configure a parser (I.e. load attributes) for each packet header type (i.e. each different protocol) that needs to be parsed.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6 or the method of claim 21, as disclosed by Urman in view of Bosshart, wherein the parse graph indicates whether to load attributes per respective ones of the different protocols, as further taught by Bosshart. The motivation to do so would have been to have a device, or a method for a device, with a parse graph that is used to identify specific parser configuration options relevant to specific header types or protocols of a header, so that a controller of the device can select a parser configuration option, optimized to parse the specific header type or protocol, to load into a register for a hardware parser to parse the header.
Urman fails to disclose but Kfir further teaches wherein the attributes are type–length–value (TLV) attributes ([0004] discloses that IPv4 header options are often encoded in TLV format.).
Therefore, it would have been obvious to someone having ordinary skill in the art prior to the effective filing date of the claimed invention to have the device of claim 6 or the method of claim 21, wherein the parse graph indicates whether to load attributes per respective ones of the different protocols, as disclosed by Urman in view of Herbert and Bosshart, wherein the attributes are type–length–value (TLV) attributes, as further taught by Kfir. The motivation to do so would have been to have a device, or a method for a device, with a parse graph that is used to identify specific parser configuration options relevant to TLV header types of a header, so that a controller of the device can select a parser configuration option, optimized to parse the TLV header type, to load into a register for a hardware parser to parse the header.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Sun et al. (Yin Sun & Zhichuan Guo, “The Design of Dynamic Configurable Packet Parser Based on FPGA”, MDPI journal on Micromachines 2023, 14, 1560, August 5, 2023) discloses The Design of Dynamic Configurable Packet Parser Based on FPGA.
Wang et al. (Ke Wan, Zhichuan Guo, Mangu Song & Meng Sha, “100 Gbps Dynamic Extensible Protocol Parser Based on an FPGA”, MDPI journal on Electronics 2022, 11, 1501, May 7, 2022) discloses 100 Gbps Dynamic Extensible Protocol Parser Based on an FPGA.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES P SEYMOUR whose telephone number is (571)272-7654. The examiner can normally be reached M-F 8-5 EST.
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, Nishant Divecha can be reached at 571-270-3125. 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.
/JAMES P SEYMOUR/Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Prosecution Insights