DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is in response to the communication filed on 10/11/2024. Claims 1-20 are pending in this application.
Priority
This application was effectively filed on 10/11/2024. The assignee of record is HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP. The listed inventor(s) is/are: Beecroft et al..
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 10/25/2024, 03/12/2026, 05/14/2026 and 06/15/2026 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDS(s) is/are being considered by the examiner.
Claim Interpretation
Claim 1 recites the limitations “a network node,” “a packet-header parser,” “a hash logic unit” and “a flow-identifying logic unit,” Claim 7 recites the limitation “a congestion-management logic unit.” The analysis of claim 1 and claim 7 are based on these limitations.
“A network node” is a known structural term to one of ordinary skill in the art. “A network node” in claim 1 is not modified by functional language, and the structure of “network device” in FIG. 5 exemplifies that the “network node” may have hardware such as processing resource and storage device. Therefore, “a network node” may not invoke 112(f) in claim 1.
“Parser” is also a known structural term to one of ordinary skill in the art. The instant specification recites “instructions to parse a received packet to extract a plurality of header fields 512” being executed by processing resource 506 (FIG. 5, para. [0044]). Therefore, “a packet-header parser” may not invoke 112(f) in claim 1.
The modifier “hash” narrows the structure for the generic term “logic unit.” The instant specification also recites “instructions to compute a hash value based on the extracted header fields” being executed by processing resource 506 (FIG. 5, para. [0044], [0045]). Therefore, “a hash logic unit” may not invoke 112(f) in claim 1.
The “flow-identifying logic unit” appears associated with instructions “to associate the packet with a flow ID based on the computed hash value 516” and “to forward the packet with the flow ID to the next-hop network device 518,” and the instructions may be executed by processing resource (FIG. 5, para. [0044], [0046] and [0047]). The execution of the instructions also involve structural components such as TCAM implemented match function. Therefore, the “flow-identifying logic unit” may not invoke 112(f) in claim 1.
There is no sufficient structural information documented in the instant specification for “a congestion-management logic unit” in claim 7. It may invoke 112(f). See detailed analysis as following.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a congestion-management logic unit” in claim 7.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 7 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
In Claim 7, the limitation “a congestion-management logic unit” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The instant specification recites the limitation in paragraphs [0030] and [0059], but the instant specification is devoid of any structure that performs the function in claim 7. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
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 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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-2, 9-11, 13-15 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20240053930 A1 (hereinafter Foo), in view of US 20140341029 A1 (hereinafter Allan).
For Claim 1, Foo teaches a network node (Foo exemplifies a packet capture device in FIG. 14A; para. [0298] “… FIG. 14A depicts an arrangement of packet capture device 1300 for high-speed flow identification …”), comprising:
a packet-header parser to extract a plurality of header fields from a received packet (Foo teaches a hardware processor extracting header fields from a received packet to calculate a hash; FIG. 14; para. [0332] “… FIG. 14D depicts a subset of the operations of the packet capture device. Incoming data packets are directed to onboard or offboard hardware processor operations 1430 …”; para. [0334] “… For instance, general flow monitoring could involve calculating a hash over the data link header (including any VLAN tags), the source IP address, destination IP address, and protocol field of the IP header, and the source and destination port numbers from the transport header (e.g., TCP or UDP) header. If the data packets include one or more MPLS tags or GRE tunnel identifiers, these may be used in the hash calculation as well …”);
a hash logic unit to compute a hash value based on the plurality of extracted header fields (Foo teaches the hardware processor calculating a hash value over header fields of the received packet; FIG. 14; para. [0305] “… Further, representation 1410 includes a hash value that may be calculated over some or all of the other values shown in representation 1410. For example, the hash value may be calculated over the Ethernet addresses, VLAN tags, MPLS tags, IP address, IP protocol field, and/or TCP/UDP port numbers. This hash value provides a simple way of determining the flow to which any data packet belongs, and also facilitates storing the flow information in a hash table or similar data structure …”; para. [0321] “… identifying flows of data packets within the chunk comprises calculating, based on header field values of the data packets within the chunk, respective hash values, wherein the hash values uniquely denote respective flows to which the data packets belong …”; para. [0334] “… For instance, general flow monitoring could involve calculating a hash over the data link header (including any VLAN tags), the source IP address, destination IP address, and protocol field of the IP header, and the source and destination port numbers from the transport header (e.g., TCP or UDP) header. If the data packets include one or more MPLS tags or GRE tunnel identifiers, these may be used in the hash calculation as well …”; para. [0335] “… To be clear, a hash function calculated over parts of a data packet involves the values in those parts of the data packet being used as input to the hash function. The output of the hash function is a hash value based on these inputs …”); and
a flow-identifying logic unit to associate the packet with a flow identifier (ID) based on the computed hash value (Foo teaches the hardware processor identifying respective flows by using the hash value as a flow identifier of the received packet or as the basis for the flow identifier; FIG. 14; para. [0305] “… Further, representation 1410 includes a hash value that may be calculated over some or all of the other values shown in representation 1410. For example, the hash value may be calculated over the Ethernet addresses, VLAN tags, MPLS tags, IP address, IP protocol field, and/or TCP/UDP port numbers. This hash value provides a simple way of determining the flow to which any data packet belongs, and also facilitates storing the flow information in a hash table or similar data structure …”; para. [0340] “… Capture system CPU operations 1440 represent the activities performed by one or more processors of packet capture device 1300 in accordance with these embodiments …”; para. [0343] “… Flow lookup from metadata/hash 1446 involves identifying respective flows based on each of the hash values. This may involve dynamically building a table or database of flows using the hash values as flow identifiers or as the basis for flow identifiers, and then associating each flow identifier with other metadata of interest (e.g., representations of data packet lengths, header lengths, etc.) …”), …
Foo does not explicitly teach, but Allan teaches the flow ID facilitating subsequent network nodes along a path to the packet’s destination to recognize the packet as belonging to a flow (Allan teaches using a flow identifier generated from the packet head fields derived hash value to facilitate the packet traversing downstream packet processing elements and/or switching fabrics so that later network elements recognizing packets belonging to the same flow; FIG. 3, FIG. 4; para. [0039] “… To determine a data flow identifier, any subset of the header information can be utilized, a hashing algorithm can be applied to the header information, or a similar process can be applied to generate a value that is unique to the data flow such that it can be matched with a service chain that has been assigned to the data flow (Block 305) … the data flow identifier can be embedded or encoded into the frame to be sent to the service chain in the service network (Block 307). The data flow identifier (e.g., a flow hash value) can be encoded within the destination media access control (DA MAC) of the frame. The flow hash value can then be utilized to identify the data flow by the PPEs (i.e. packet processing elements) in the associated service chain”; para. [0040] “… The frame is then forwarded to the switching fabric that has been programmed by the PPEs in the next stage (Block 309). As discussed further herein below, the PPEs in the next stage self-select which of the PPEs in the stage service a data flow using a data flow identifier or similar identifier to differentiate data flows assigned to the service chains such that they can be load balanced across the PPEs that are associated with the service chain …”; para. [0043] “… the network element executing the PPE is connected to multiple switching fabrics through different ports. A switching fabric can be an upstream or downstream switching fabric relative to the service chain …”; para. [0044] “… The frame is examined to retrieve a data flow identifier, which is checked against the set of data flow identifiers that the PPE has self-selected to service (Block 403) …”; para. [0045] “… Where the frame has been properly received, the frame can be processed according to the packet processing functions of the PPE (Block 409). Once completed the frame is forwarded to a second switching fabric configured by a PPE of the next stage of the service chain (Block 409) …”).
Allan and Foo are analogous art because they are both related to network packet processing.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the forwarding packets of a data flow with a flow identifier throughout the same path of switching fabrics techniques of Allan with the system of Foo to reduce processing overhead, improve forwarding efficiency and manage load balancing across switch fabrics (Allan, para. [0040]).
For Claim 2, Foo-Allan teaches the network node of claim 1, wherein the flow-identifying logic unit is to:
in response to determining that the packet belongs to an existing flow, associate the packet with the flow ID corresponding to the existing flow (Foo, FIG. 14; para. [0305] “… the hash value may be calculated over the Ethernet addresses, VLAN tags, MPLS tags, IP address, IP protocol field, and/or TCP/UDP port numbers. This hash value provides a simple way of determining the flow to which any data packet belongs, and also facilitates storing the flow information in a hash table or similar data structure. For instance, a data packet may be identified within a chunk, and the hash value calculated over at least some of the relevant values shown in representation 1410. If the identified flow is already present as an entry in the hash table, statistics from the data packet may be added to the flaw's entry …”; para. [0343] “… Flow lookup from metadata/hash 1446 involves identifying respective flows based on each of the hash values. This may involve dynamically building a table or database of flows using the hash values as flow identifiers or as the basis for flow identifiers, and then associating each flow identifier with other metadata of interest (e.g., representations of data packet lengths, header lengths, etc.) …”); and
in response to determining that the packet belongs to a new flow, allocate the new flow and associate the packet with the flow ID corresponding to the new flow (Foo, FIG. 14; para. [0305] “… If the flow is not already present in the hash table, the flow may be added as a new entry to the hash table …”; para. [0343] “… Flow lookup from metadata/hash 1446 involves identifying respective flows based on each of the hash values. This may involve dynamically building a table or database of flows using the hash values as flow identifiers or as the basis for flow identifiers, and then associating each flow identifier with other metadata of interest (e.g., representations of data packet lengths, header lengths, etc.) …”).
For Claim 9, Foo-Allan teaches the network node of claim 1, wherein the flow-identifying logic unit is to associate the packet with the flow ID without performing header translation (Foo teaches identifying respective flows by using the hash value as a flow identifier of the received packet or as the basis for the flow identifier, the associating the received packet with the flow identifier does not involve header translation; FIG. 14; para. [0305] “… Further, representation 1410 includes a hash value that may be calculated over some or all of the other values shown in representation 1410. For example, the hash value may be calculated over the Ethernet addresses, VLAN tags, MPLS tags, IP address, IP protocol field, and/or TCP/UDP port numbers. This hash value provides a simple way of determining the flow to which any data packet belongs, and also facilitates storing the flow information in a hash table or similar data structure … If the identified flow is already present as an entry in the hash table, statistics from the data packet may be added to the flaw's entry. If the flow is not already present in the hash table, the flow may be added as a new entry to the hash table …”; para. [0340] “… Capture system CPU operations 1440 represent the activities performed by one or more processors of packet capture device 1300 in accordance with these embodiments …”; para. [0343] “… Flow lookup from metadata/hash 1446 involves identifying respective flows based on each of the hash values. This may involve dynamically building a table or database of flows using the hash values as flow identifiers or as the basis for flow identifiers, and then associating each flow identifier with other metadata of interest (e.g., representations of data packet lengths, header lengths, etc.) …”).
For Claim 10, the claim is substantially similar to claim 1 and therefore is rejected for the same reasoning set forth above.
For Claim 11, the claim is substantially similar to claim 2 and therefore is rejected for the same reasoning set forth above.
For Claim 13, Foo-Allan teaches the method of claim 10, further comprising selecting, from the plurality of header fields, a subset of header fields for computation of the hash value, wherein the subset of header fields comprises at least a source address field, a destination address field, and a traffic class field (Foo teaches selecting a subset of header fields such as IP addresses, Ethernet addresses, and traffic class field from an MPLS header to calculate the hash value; FIG. 14; para. [0296] “… A common way of identifying a flow is through the 5-tuple of source IP address, destination IP address, and protocol fields of an IP header, as well as the source port number and destination port number of a TCP or UDP header. But more, fewer, or different identifying protocol fields or other metadata may be used to identify flows. For example, some embodiments herein may use one or more of a source Ethernet address, destination Ethernet address, one or more VLAN tags, an Ethernet protocol type of an Ethernet header, one or more multi-protocol label switching (MPLS) tags or traffic class fields from an MPLS header, the result of an hash function (e.g., SHA1) calculated on some or all metadata as described above for each data packet, or the physical port through which the packet was captured …”; para. [0305] “… Further, representation 1410 includes a hash value that may be calculated over some or all of the other values shown in representation 1410. For example, the hash value may be calculated over the Ethernet addresses, VLAN tags, MPLS tags, IP address, IP protocol field, and/or TCP/UDP port numbers. This hash value provides a simple way of determining the flow to which any data packet belongs, and also facilitates storing the flow information in a hash table or similar data structure …”).
For Claim 14, Foo-Allan teaches the method of claim 13, wherein the subset of header fields further comprises one or more of: an encapsulation header field; a Differentiated Service Code Point (DSCP) field; a User Datagram Protocol (UDP) port field (Foo teaches selecting a UDP port field to calculate the hash value; FIG. 14; para. [0305] “… Further, representation 1410 includes a hash value that may be calculated over some or all of the other values shown in representation 1410. For example, the hash value may be calculated over the Ethernet addresses, VLAN tags, MPLS tags, IP address, IP protocol field, and/or TCP/UDP port numbers. This hash value provides a simple way of determining the flow to which any data packet belongs, and also facilitates storing the flow information in a hash table or similar data structure …”); one or more Ultra Ethernet Consortium (UEC) Transport headers; or a snoop number field.
For Claim 15, Foo-Allan teaches the method of claim 13, wherein the packet is encapsulated (Foo, para. [0318] “… The header may also be encapsulated by another protocol such as GRE …”), and
wherein the subset of header fields further comprise layered header fields within the encapsulation (Foo teaches calculating the hash value over different parts of the packets, including GRE tunnel identifiers; para. [0334] “… How hashes are calculated on the data packets can vary with applications. For instance, general flow monitoring could involve calculating a hash over the data link header (including any VLAN tags), the source IP address, destination IP address, and protocol field of the IP header, and the source and destination port numbers from the transport header (e.g., TCP or UDP) header. If the data packets include one or more MPLS tags or GRE tunnel identifiers, these may be used in the hash calculation as well … Other applications may involve the hash being calculated over different parts of the data packets, possibly including application layer data. Each application may involve a set of rules that are applied to identify what locations in the data packets are to be used as input to the hash function …”).
For Claim 18, the claim is substantially similar to claim 9 and therefore is rejected for the same reasoning set forth above.
For Claim 19, the claim is substantially similar to claim 1 and therefore is rejected for the same reasoning set forth above. Additionally, Foo-Allan teaches a non-transitory machine-readable storage medium storing instructions executable by a processing resource (Foo, para. [0014] “… In a seventh example embodiment, an article of manufacture may include a non-transitory computer-readable medium, having stored thereon program instructions that, upon execution by a computing system, cause the computing system to perform operations in accordance with any of the previous embodiments …”).
For Claim 20, Foo-Allan teaches the non-transitory machine-readable storage medium of claim 19, wherein the header fields comprise one or more of: a source address field; a destination address field; a traffic class field; an encapsulation header field; a Differentiated Service Code Point (DSCP) field; a User Datagram Protocol (UDP) port field; one or more Ultra Ethernet Consortium (UEC) Transport headers; or a snoop number field (Foo teaches selecting a subset of header fields such as IP addresses, Ethernet addresses, traffic class field from an MPLS header, or a UDP port number to calculate the hash value; FIG. 14; para. [0305] “… Further, representation 1410 includes a hash value that may be calculated over some or all of the other values shown in representation 1410. For example, the hash value may be calculated over the Ethernet addresses, VLAN tags, MPLS tags, IP address, IP protocol field, and/or TCP/UDP port numbers. This hash value provides a simple way of determining the flow to which any data packet belongs, and also facilitates storing the flow information in a hash table or similar data structure …”).
Claim Rejections - 35 USC § 103
Claims 3 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20240053930 A1 (hereinafter Foo), in view of US 20140341029 A1 (hereinafter Allan), and in further view of US 20180068032 A1 (hereinafter Levy).
For Claim 3, Foo-Allan teaches the network node of claim 1, wherein the flow-identifying logic unit comprises a match function to perform a match operation based on the computed hash value (Foo teaches a match operation based on the computed hash value; FIG. 14; para. [0305] “… the hash value may be calculated over the Ethernet addresses, VLAN tags, MPLS tags, IP address, IP protocol field, and/or TCP/UDP port numbers. This hash value provides a simple way of determining the flow to which any data packet belongs, and also facilitates storing the flow information in a hash table or similar data structure. For instance, a data packet may be identified within a chunk, and the hash value calculated over at least some of the relevant values shown in representation 1410. If the identified flow is already present as an entry in the hash table, statistics from the data packet may be added to the flaw's entry …”; para. [0343] “… Flow lookup from metadata/hash 1446 involves identifying respective flows based on each of the hash values. This may involve dynamically building a table or database of flows using the hash values as flow identifiers or as the basis for flow identifiers, and then associating each flow identifier with other metadata of interest (e.g., representations of data packet lengths, header lengths, etc.) …”), and …
Foo-Allan does not explicitly teach, but Levy teaches wherein the match function is implemented using a Ternary Content Addressable Memory (TCAM), a plurality of Random-Access Memories (RAMs) (Levy teaches implementing packet classification matching function using TCAM or RAM; FIG. 2; para. [0004] “… Multiple hash tables are defined in a RAM, each is used for searching for a rule that matches a given classification key. A match result of a given rule in a given hash table is also indicative of which of the other hash tables are to be used for subsequent searching. The data items are classified by matching the respective classification keys to the rules using one or more of the hash tables …”; para. [0024] “… The small TCAM can be used to temporarily store new rules until they are incorporated into the matching database in the RAM. Rules that belong to a rule pattern with a small number of rules can also be stored in the TCAM. Lookup for each key is typically performed initially in the RAM, and the TCAM is accessed as needed based on the results of the RAM lookup …”; para. [0048] “… Searching for matching rules using the entire hash tables in the RAM is equivalent to searching the key using a TCAM that stores the same m rules …”), or a plurality of discrete logic gates.
Levy and Foo-Allan are analogous art because they are both related to network packet processing.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the implementing packet processing match function in TCAM or RAM techniques of Levy with the system of Foo-Allan to facilitate flexible and sophisticated packet classification (Levy, para. [0002]).
For Claim 12, Foo-Allan teaches the method of claim 10, wherein associating the packet with the flow ID comprises performing a match operation based on the computed hash value (Foo teaches a match operation based on the computed hash value; FIG. 14; para. [0305] “… the hash value may be calculated over the Ethernet addresses, VLAN tags, MPLS tags, IP address, IP protocol field, and/or TCP/UDP port numbers. This hash value provides a simple way of determining the flow to which any data packet belongs, and also facilitates storing the flow information in a hash table or similar data structure. For instance, a data packet may be identified within a chunk, and the hash value calculated over at least some of the relevant values shown in representation 1410. If the identified flow is already present as an entry in the hash table, statistics from the data packet may be added to the flaw's entry …”; para. [0343] “… Flow lookup from metadata/hash 1446 involves identifying respective flows based on each of the hash values. This may involve dynamically building a table or database of flows using the hash values as flow identifiers or as the basis for flow identifiers, and then associating each flow identifier with other metadata of interest (e.g., representations of data packet lengths, header lengths, etc.) …”), …
Foo-Allan does not explicitly teach, but Levy teaches wherein the perform the match operation comprising looking up a table stored in a Ternary Content Addressable Memory (TCAM), a plurality of Random-Access Memories (RAMs), or a plurality of discrete logic gates (Levy teaches implementing packet classification matching function using TCAM or RAM; FIG. 2; para. [0004] “… Multiple hash tables are defined in a RAM, each is used for searching for a rule that matches a given classification key. A match result of a given rule in a given hash table is also indicative of which of the other hash tables are to be used for subsequent searching. The data items are classified by matching the respective classification keys to the rules using one or more of the hash tables …”; para. [0024] “… The small TCAM can be used to temporarily store new rules until they are incorporated into the matching database in the RAM. Rules that belong to a rule pattern with a small number of rules can also be stored in the TCAM. Lookup for each key is typically performed initially in the RAM, and the TCAM is accessed as needed based on the results of the RAM lookup …”; para. [0048] “… Searching for matching rules using the entire hash tables in the RAM is equivalent to searching the key using a TCAM that stores the same m rules …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the implementing packet processing match function in TCAM or RAM techniques of Levy with the system of Foo-Allan to facilitate flexible and sophisticated packet classification (Levy, para. [0002]).
Claim Rejections - 35 USC § 103
Claims 4-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20240053930 A1 (hereinafter Foo), in view of US 20140341029 A1 (hereinafter Allan), and in further view of US 20210160350 A1 (hereinafter Volpe).
For Claim 4, Foo-Allan teaches the network node of claim 1, further comprising … to select, from the plurality of header fields, a subset of header fields for computation of the hash value, wherein the subset of header fields comprises at least a source address field, a destination address field, and a traffic class field (Foo teaches selecting a subset of header fields such as IP addresses, Ethernet addresses, and traffic class field from an MPLS header to calculate the hash value; FIG. 14; para. [0296] “… A common way of identifying a flow is through the 5-tuple of source IP address, destination IP address, and protocol fields of an IP header, as well as the source port number and destination port number of a TCP or UDP header. But more, fewer, or different identifying protocol fields or other metadata may be used to identify flows. For example, some embodiments herein may use one or more of a source Ethernet address, destination Ethernet address, one or more VLAN tags, an Ethernet protocol type of an Ethernet header, one or more multi-protocol label switching (MPLS) tags or traffic class fields from an MPLS header, the result of an hash function (e.g., SHA1) calculated on some or all metadata as described above for each data packet, or the physical port through which the packet was captured …”; para. [0305] “… Further, representation 1410 includes a hash value that may be calculated over some or all of the other values shown in representation 1410. For example, the hash value may be calculated over the Ethernet addresses, VLAN tags, MPLS tags, IP address, IP protocol field, and/or TCP/UDP port numbers. This hash value provides a simple way of determining the flow to which any data packet belongs, and also facilitates storing the flow information in a hash table or similar data structure …”).
Foo-Allan does not explicitly teach, but Volpe teaches a control and status register (CSR) to select the packet header fields to be extracted for processing the network packets (Volpe, FIG. 2, FIG. 7; para. [0032] “… a controller may be configured to program memory devices with new or additional information (e.g., update next hop tables, action tables, insert or remove forwarding routes, etc.) or program control status registers or other components at packet processors 250 with instructions to generate metadata fields or hash values, such as programmatically defined fields according to the techniques discussed below with regard to FIGS. 7-8 …”; para. [0060] “… As indicated at 710, instructions to generate a programmatically defined field of metadata for processing network packets may be stored at a packet processor, in various embodiments. Instructions may describe which headers include data to be extracted, validations or checks to be performed, such as checks to identify if the data is from the identified header, checks to identify if the previous header and current header information match, and/or a check to determine the packet type matches an indicated packet type for the data, the location of the portion of data within the header, the location of the portion of the data within the programmatically defined field (e.g., the particular byte in which the extracted nibble is stored) and whether any further data manipulations, such as a mask, are to be applied to the extracted portion of the data. Instructions may be stored in a register bundle array (RBA) or other component that controls the operation of a packet processor to extract particular portions of packet header data into a programmatically defined field …”).
Volpe and Foo-Allan are analogous art because they are both related to network packet processing.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the CSR to select packet header fields for processing network packets techniques of Volpe with the system of Foo-Allan to improve network processing capacity (Volpe, para. [0003]).
For Claim 5, Foo-Allan-Volpe teaches the network node of claim 4, wherein the subset of header fields further comprises one or more of: an encapsulation header field; a Differentiated Service Code Point (DSCP) field; a User Datagram Protocol (UDP) port field (Foo teaches selecting a UDP port field to calculate the hash value; FIG. 14; para. [0305] “… Further, representation 1410 includes a hash value that may be calculated over some or all of the other values shown in representation 1410. For example, the hash value may be calculated over the Ethernet addresses, VLAN tags, MPLS tags, IP address, IP protocol field, and/or TCP/UDP port numbers. This hash value provides a simple way of determining the flow to which any data packet belongs, and also facilitates storing the flow information in a hash table or similar data structure …”); one or more Ultra Ethernet Consortium (UEC) Transport headers; or a snoop number field.
For Claim 6, Foo-Allan-Volpe teaches the network node of claim 4, wherein the packet is encapsulated (Foo, para. [0318] “… The header may also be encapsulated by another protocol such as GRE …”), and
wherein the subset of header fields further comprise layered header fields within the encapsulation (Foo teaches calculating the hash value over different parts of the packets, including GRE tunnel identifiers; para. [0334] “… How hashes are calculated on the data packets can vary with applications. For instance, general flow monitoring could involve calculating a hash over the data link header (including any VLAN tags), the source IP address, destination IP address, and protocol field of the IP header, and the source and destination port numbers from the transport header (e.g., TCP or UDP) header. If the data packets include one or more MPLS tags or GRE tunnel identifiers, these may be used in the hash calculation as well … Other applications may involve the hash being calculated over different parts of the data packets, possibly including application layer data. Each application may involve a set of rules that are applied to identify what locations in the data packets are to be used as input to the hash function …”).
Claim Rejections - 35 USC § 103
Claims 7 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20240053930 A1 (hereinafter Foo), in view of US 20140341029 A1 (hereinafter Allan), and in further view of US 20190386924 A1 (hereinafter Srinivasan).
For Claim 7, Foo-Allan teaches the network node of claim 1. Foo-Allan does not explicitly teach, but Srinivasan teaches further comprising a congestion-management logic unit to perform flow-channel-based congestion management on received packets (Srinivasan teaches a network device managing congestion associated with a packet flow and operating congestion control on received packets; para. [0024] “… Various embodiments provide at least part of an end-to-end congestion management scheme with coordination between a transmitter network device that transmits a congestion causing flow and a network device that experiences congestion. A network device can be any of switch buffers, packet buffers, routers, network interfaces, or switches, or combination thereof …”; para. [0025] “… Application of flow differentiation can include extending traffic classes (TCs) with packet level fields in network devices. For example, more than 8 buckets of TCs can be supported. In response to packet fields that identify TCs, network devices can provide buffer management and scheduling. For example, a flow can be identified by one or more of: a destination port, a destination IP address, a destination port, a destination IP address, or any other packet header, preamble, or payload contents. For latency sensitive flows (e.g., mice flows), a network device can differentiate the flows in near real time …”; para. [0026] “… A network device that experiences congestion can identify a source of congestion, form a Fast-path Congestion Hints (FCH) message and transmit the FCH message to a transmitter of a congestion causing flow. The source can be identified from a packet that caused or is causing congestion as a source address can be in a packets' header (e.g., 5tuple). In some examples, a source transmitter can be an intermediary network device such as a switch. In some examples, the source transmitter can use a table to determine an actual source of a congestion causing flow. The FCH message can describe nature of congestion and the source can choose whether to apply load balancing, reduce transmit rate, or modify a route of the flow …”).
Srinivasan and Foo-Allan are analogous art because they are both related to network packet processing.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the congestion management associated with packet flows techniques of Srinivasan with the system of Foo-Allan to improve network QoS and optimize the utilization of network resources (Srinivasan, para. [0003]).
For Claim 16, the claim is substantially similar to claim 7 and therefore is rejected for the same reasoning set forth above.
Claim Rejections - 35 USC § 103
Claims 8 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20240053930 A1 (hereinafter Foo), in view of US 20140341029 A1 (hereinafter Allan), and in further view of “Efficient Flow Table Management Scheme in SDN-Based Cloud Computing Networks” (hereinafter Ha).
For Claim 8, Foo-Allan teaches the network node of claim 1. Foo-Allan does not explicitly teach, but Ha teaches wherein the hash value comprises a first number of bits, and wherein the flow ID comprises a second number of bits, the second number being smaller than the first number (Ha teaches using lower n bits of the packet hash value as a flow entry index, the flow entry index corresponding to a flow identifier in the hash-based flow table, and the flow entry index value having smaller number of bits than the hash value; Section 4.1 Implementation p. 234 “… OpenFlow switches implement both hash-based flow tables and wildcard-based flow tables. The hash-based flow table of the OpenFlow switch uses CRC32 as a hash function. The wildcard-based flow table is composed of flow entries with wildcards and search its entries in a linear way. In this paper, we use OpenFlow switch version 1.0 and modifies it to implement and compare the hash-assisted wildcard scheme and the hash-indexed wildcard scheme … In the OpenFlow switch, the size of the hash-based flow table is fixed as a unit of 2n. The index value is the lower n bits of the value obtained by computing the packet information by hash function. For example, if n is 10, and the value of the hash is 1105482, then the index value will be the lower 10 bits of 1105482, which is 586, and the corresponding flow entry will be stored in index 586 …”).
Ha and Foo-Allan are analogous art because they are both related to network packet processing.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the hash-based flow entry index searching techniques of Ha with the system of Foo-Allan to “maximize(s) the capacity of the flow table by efficiently storing flow entry information while quickly executing the operation of flow-entry search” (Ha, Abstract p. 228).
For Claim 17, the claim is substantially similar to claim 8 and therefore is rejected for the same reasoning set forth above.
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed below, thank you:
i. US 20160294710 A1 (Sreeramoju) teaches assigning a data flow-specific identification value to each packet of a data flow. In some embodiments, a particular source endpoint transmits packets belonging to several different data flows to one or more destination endpoints. When sending packets, the source endpoint inserts a unique flow identification value to a particular field of the Internet Protocol (IP) header of each packet of a data flow. The use of these flow identification values enables intermediate network elements and the destination endpoint to efficiently identify to which data flow each packet belongs. In some embodiments, the source endpoint inserts the flow identification value into the 16-bit Internet Protocol version 4 (IPv4) identification field of the IP header of the packets (Abstract).
ii. US 20200304415 A1 (Zaifman) teaches that a processing system including at least one processor may obtain a first packet, determine a first tunnel identifier from a tunnel identifier field and a first source port identifier from a source port identifier field of the header of the first packet, and assign the first packet to a first flow. The processing system may further obtain a second packet, extract a first value from a tunnel identifier field and a second value from a source port identifier field of a header of the second packet, determine that the first value matches the first tunnel identifier and that the second value matches the first source port identifier, and assign the second packet to the first flow in response to the determining that the first value matches the first tunnel identifier and that the second value matches the first source port identifier (Abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZONGHUA DU whose telephone number is (408)918-7596. The examiner can normally be reached Monday - Friday 8 AM - 5 PM PST.
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, John Follansbee can be reached on (571) 272-3964. 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.
/Z.D./Examiner, Art Unit 2444
/SCOTT B CHRISTENSEN/Primary Examiner, Art Unit 2444
Prosecution Insights