DETAILED ACTION
This Action is responsive to the Amendment filed on 02/23/2026.
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 .
Claim Status
Claims 1-20 are amended. Claim 19 remains withdrawn by examiner as being drawn to a non-elected invention. Claims 1-18 and 20 are pending and have been examined.
Election/Restrictions
Claim 19 is withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected invention, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 02/23/2026.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-18 and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding Claim 1,
Claim 1, 16-17th lines recites “input the key entry to the first TCAM block and the second TCAM block”, the scope of which cannot be determined due to numerous reasonable interpretations.
Under a first reasonable interpretation (interpreted as written), applicant intends to claim an embodiment whereby, in the wide search mode, the limitation recited in lines 16-17 is performed in addition to the “input the first key segment and the second key segment to the first TCAM block and the second TCAM block, respectively” limitation recited in lines 14-15. Examiner notes that support for such an interpretation does not appear to be found in the Specification.
Under a second reasonable interpretation, applicant intends to claim an embodiment such as disclosed in Fig. 7, whereby in the wide search mode, a single step of “input the first key segment and the second key segment to the first TCAM block and the second TCAM block, respectively” step is performed (see, e.g., step 720). Examiner considers the second reasonable interpretation provided above as reasonable in view of the Specification and as reasonable further in view of the 01/07/2026 interview with applicant’s representative. Accordingly, examiner will interpret Claim 1 according to the second reasonable interpretation provided above.
Therefore, the scope of Claim 1 is indefinite, and the claim is rejected under 35 U.S.C. 112(b). Claims 2-17 depend on Claim 1 and are therefore similarly rejected according to the same rationale. Claim 20 recites substantially similar language as compared to Claim 1 and is therefore similarly rejected according to the same rationale.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 1-3, 5, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Park et al. (US 20080134283 A1)(hereafter referred to as Park) further in view of Levy et al. (US 20140310307 A1)(cited by examiner in previous action)(hereafter referred to as Levy) and Zhang et al. (US 20080279185 A1)(cited by examiner in previous action)(hereafter referred to as Zhang).
Regarding Claim 1, (see 35 U.S.C. 112(b) rejections above for details regarding claim interpretation)
Park discloses the following limitations:
A ternary content addressable memory (TCAM) system, comprising:
a first TCAM block (First Bank 231, Fig. 2) and a second TCAM block (Second Bank 232, Fig.2); and
a TCAM logic (Packet Classifier 210 + Key Generator 220, Fig. 2) configured to:
receive (Fig. 2 // ¶0040) a key entry (“The key generator 220 … generates a discrimination key … The discrimination key for inquiring the lookup engine 230” [0040-41]) – As shown in Fig. 2, a “discrimination key” (i.e., “a key entry”) associated with a received IP packet is generated by key generator 220 based on information received from packet classifier 210--;
detect (Fig. 2 // ¶0039) a key-type associated with the key entry (“The packet classifier 210 classifies an IPv4 packet and an IPv6 packet based on version information in header information of an input IP packet” [0039]) – As shown in Fig. 2, packet classifier 210 classifies whether the received packet is an IPv4 packet or an IPv6 packet (i.e., detects “a key-type”)--; and
operate (Fig. 2 // ¶0044) the TCAM system in one of a wide search mode (“a 288-bit search mode” [0044]) or a narrow search mode (“a 144-bit search mode” [0044]) based on the detected key-type (“basic packet header information is generated from the IP packet classified by the packet classifier by operating an IPv4 parsing module for the IPv4 packet or operating an IPv6 parsing module for the IPv6 packet according to an IP version … For example 144 bits are assigned to the first bank 231 in which the security policy for an IPv4 packet is established, and accordingly, a 144-bit search mode can be performed. In addition, 288 bits are assigned to the second bank 232 in which the security policy for an IPv6 packet is established, and accordingly, a 288-bit search mode can be performed. Thus, each bank can apply a different search method” [0041-44]) , wherein:
in the narrow search mode, the TCAM logic is further configured to input (Fig. 2) the key entry to the first TCAM block (“The discrimination key for inquiring the lookup engine 230 … The lookup engine includes two banks 231 and 232 … Different bits are assigned to the two banks 231 and 232 … 144 bits are assigned to the first bank 231 in which the security policy for an IPv4 packet is established, and accordingly, a 144-bit search mode can be established” [0041-44] // Fig. 2) – As shown in Fig. 2, in a 144-bit search mode for IPv4 packets, the discrimination key generated for the IPv4 packet is looked up in first bank 231.
Park does not disclose following limitations:
in the narrow search mode, the TCAM logic is further configured to input the key entry to the first TCAM block and the second TCAM block, and
in the wide search mode, the TCAM logic is further configured to: split the key entry into a first key segment and a second key segment; and
input the first key segment and the second key segment to the first TCAM block and the second TCAM block, respectively;
However, Levy discloses a following method of searching lookup tables implemented using TCAM memories. Levy discloses the following limitations:
in the narrow search mode (Fig. 4), the TCAM logic (Packet Processor 14, Fig. 1 // ¶¶0058; 0060; 0075) is further configured to – Examiner considers Packet Processor 14 coupled to Lookup Memory 24 depicted in Levy Fig. 1 as analogous to the Packet Classifier 210 + Key Generator 220 coupled to Lookup Engine 230, respectively, as depicted in Park Fig. 2, whereby a first and a second bank 30 of the Levy Lookup Memory 24 correspond to first bank 231 and second bank 232 of Park--
input (Fig. 4, blocks 108-110) the key entry to the first TCAM block (Memory Bank 30-1, Fig. 1) and the second TCAM block (“At block 108, a hash operation is performed on the lookup key … to compute a hashed lookup key segment … At block 110, a database is queried, using the hashed lookup key segment computed at block 108 … In some embodiments, the database is queried by using the hashed lookup key segment to access each of at least two different banks of the two or more memory banks.” [0063-64]) – As shown in Fig. 4 and detailed in ¶¶0063-64, the lookup key is hashed using a single hash function (block 108) to create a hashed lookup segment, whereby the hashed lookup segment is queried in (i.e., “input” to) each of at least two different banks of lookup table 26 (e.g., at least Memory Banks 30-1 and 30-2). Examiner accordingly considers the first lookup technique as described in Fig. 4 as a “narrow search mode”--, and
in the wide search mode (Fig. 6), the TCAM logic is further configured to:
split (Fig. 6, block 146) the key entry into a first key segment and a second key segment (“At block 146, two or more hash operations are performed on the lookup key … to compute two or more respective hashed lookup key segments” [0077]) – As shown in Fig. 6 and detailed in ¶0077, the lookup key is hashed by at least two hash operations into at least two respective hashed lookup key segments (i.e., at least “a first key segment” and “a second key segment”)--; and
input (Fig. 6, block 150) the first key segment and the second key segment to the first TCAM block and the second TCAM block, respectively (“At blocks 148 … a database is queried, using the two or more hashed lookup key segments computed at block 146 … the database queried at blocks 148 is distributed among N memory banks each corresponding to a different one of N hash functions, and the hash operations at block 146 include N hash operations using the N different hash functions … At block 150, the two or more memory banks are accessed using the hashed lookup key segments computed at block 146 to identify two or more respective matching segments” [0078-79]) – As shown in Fig. 6 and detailed in ¶¶0078-79, each hashed lookup key segment is looked up in a respective memory bank (i.e., at least Memory Banks 30-1 and 30-2) to which the hash function used to generate the respective hashed lookup key segment is uniquely associated. Examiner accordingly considers the second lookup technique described in Fig. 6 as a ”wide search mode”--;
Park and Levy are considered analogous to the claimed invention because they all relate to the same field of performing searches of TCAM blocks in response to classifying a received network packet. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Park with the teachings of Levy and realize a TCAM system whereby a wide and a narrow search mode are employed for IPv4 and IPv6 packets, respectively, using the same TCAM blocks. Doing so provides a common set of memory banks for lookup keys having different sizes without requiring shorter keys to be padded to the length of the longest supported key, which is an efficient implementation of exact match lookup techniques used for packet processing operations, as disclosed in Levy ¶¶0005 // 0021: “Exact match lookups are currently used to perform any of numerous different packet processing operations … due to the wide variety of possible processing operations, exact match lookups can require using a number of different types of keys having different key sizes” [0005] // “In embodiments described below, lookup keys having different sizes (e.g., bit lengths) are efficiently stored in a unified memory (e.g., a common set of memory banks) without requiring that shorter keys be padded to the length of the longest supported key.” [0021]
The combined teachings of Park and Levy do not provide specific detail regarding a format of the output of a lookup of TCAM blocks. Specifically, Park and Levy do not disclose the following limitations:
input the key entry to the first TCAM block and the second TCAM block to generate a first hit-bitmap and a second hit-bitmap, and
interleave the first hit-bitmap with the second hit-bitmap to obtain an interleaved hit-bitmap;
merge the first hit-bitmap and the second hit-bitmap using a logical bitwise AND operation to obtain a merged hit-bitmap;
However, Zhang discloses the following limitations:
input the key entry to the first TCAM block (Lookup Engine 1 56.1, Fig. 2) and the second TCAM block (Lookup Engine 2 56.2, Fig. 2) to generate a first hit-bitmap and a second hit-bitmap (“In an example embodiment, the rule results generated by each of the lookup engines 56.1 to 56.N are in a combinable format, e.g., the rule results may be bitmaps” [0035] // Fig. 2 // ¶¶0033-36) – Examiner considers Processor 52 and Key Extraction Module 54 coupled to Lookup Engines 56 depicted in Zhang Fig. 2 as analogous to Packet Classifier 210 and Key Generator 220 coupled to Lookup Engine 230 of Park Fig. 2. As taught in ¶0035, the results of a lookup into Lookup Engines 56.1 and 56.2 are in a “bitmap” type of format (i.e., “a first hit-bitmap” and “a second hit-bitmap”)--, and
interleave the first hit-bitmap with the second hit-bitmap to obtain an interleaved hit-bitmap (“the group logic module 58 may combine the rule results of the multiple lookup engines 56.1 to 56.N to provide a result (e.g., a combined result) for this group as well” [0036]) – As taught in ¶0036, the output of each lookup engine is combined together (i.e., each bitmap is “interleave[d]” together)--;
merge the first hit-bitmap and the second hit-bitmap using a logical bitwise AND operation to obtain a merged hit-bitmap (“the group logic module 58 may perform an AND operation on the bitmap results of the various lookup engines 56.1 to 56.N to provide a combined result for the primary lookup” [0036]);
Park, Levy, and Zhang are all considered analogous to the claimed invention because they all relate to the same field of performing TCAM searches during packet processing in network environments. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Park and Levy with the teachings of Zhang and realize TCAM blocks which generate a lookup results in a bitmap-type of format. Using a combinable format, such as a bitmap, to generate TCAM lookup results enables the results of several TCAM lookups to be combined together into a master bitmap, enabling varying sizes of TCAM table lookups to be utilized and thus allowing for limits to be placed on amount of memory and time spent of performing data packet classification, as disclosed in Zhang ¶¶0035-36 // 0074: “In an example embodiment, the rule results generated by each of the lookup engines … are in a combinable format, e.g., the rule results may be bitmaps … In one example embodiment, the group logic module 58 may combine the rule results of the multiple lookup engines … to provide a result (e.g., a combined result) for this group” [0035-36] // “From this disclosure it will be evident that the apparatus and methods of the example embodiments provide for the configuration of different secondary lookup tables having varying sizes. The varying sizes of the secondary lookup tables enable the packet classifier to limit the amount of memory and time spent on processing and classifying data packets.” [0074]
The combined teachings of Park, Levy, and Zhang additionally disclose the following limitations:
and interleave the merged hit-bitmap with a plurality of zeros to obtain the interleaved hit-bitmap. (Fig. 13 // “two packet classifiers 50A and 50B used in combination to provide a combined result or master bit to a primary lookup table … Each of the lookup engines may generate a rule result for its associated secondary lookup table, which is respectively combined by group logic modules 58A and 58B of the two packet classifiers. These combined result bitmaps may then be mapped to a global bitmap (or master bitmap) by a combiner module 60” [0064-70] // “In the above example, the master bitmap will have a value “1001110” [0061]) – As shown in Fig.13, the combined bitmap results of a first packet classifier 50A (i.e., “the merged hit-bitmap”) is combined by a combined module 60 with the bitmap results of another packet classifier 50B for form a global bitmap with respect to the two classifiers. As clarified in ¶0061, the bitmap result of a packet classifier can contain at least three (i.e., “a plurality of”) zeros. Therefore, examiner considers the process of combining two bitmap results, one of which containing at least three zeros, as reading on the claimed concept of “interleav[ing] the merged hit-bitmap with a plurality of zeros”, the combined result of Fig. 13 corresponding to “the interleaved hit-bitmap”.
Regarding Claim 2,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of Park, Levy and Zhang disclose the following limitations:
The TCAM system of claim 1, wherein the first TCAM block and the second TCAM block are physical TCAM blocks (Park, “a network attack security apparatus implemented by hardware” [0011] // ¶0006)
Regarding Claim 3,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 3. The combined teachings of Park, Levy and Zhang disclose the following limitations:
The TCAM system of claim 1, wherein the first TCAM block and the second TCAM block are populated based on at least one logical TCAM (Levy, “in an embodiment, hash tables are defined according to key size, with each hash table being a virtual/logical grouping of one or more of the memory banks that is accessed (for key insertion and key searching) using a single hash function” [0021]) – As clarified in Levy ¶0021, memory banks are logically grouped according to the hash function used to access the respective banks.
Regarding Claim 5,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 5. The combined teachings of Park, Levy and Zhang disclose the following limitations:
The TCAM system of claim 1, wherein the first TCAM block is configured to store a first plurality of entries and the second TCAM block is configured to store a second plurality of entries (Levy, “the multi-hash lookup table 26 is subdivided into four hash table portions stored in four different memory banks 30-1 through 30-4 of lookup memory 24 … In an embodiment, the number of value/action entries is equal to the maximum number of minimum size keys that can be stored in multi-hash lookup table 26.” [0028] // Fig. 1) – As clarified in Levy ¶0028 and shown in Fig. 1, each bank 30-1 through 30-4 comprising lookup table 26 comprises a plurality of respective entries.
Regarding Claim 20, (see 35 U.S.C. 112(b) rejections above for details regarding claim interpretation)
Park discloses the following limitations:
A method, comprising:
receiving (Fig. 2 // ¶0040) a key entry (“The key generator 220 … generates a discrimination key … The discrimination key for inquiring the lookup engine 230” [0040-41]) – As shown in Fig. 2, a “discrimination key” (i.e., “a key entry”) associated with a received IP packet is generated by key generator 220 based on information received from packet classifier 210--;
detecting (Fig. 2 // ¶0039) a key-type associated with the key entry (“The packet classifier 210 classifies an IPv4 packet and an IPv6 packet based on version information in header information of an input IP packet” [0039]) – As shown in Fig. 2, packet classifier 210 classifies whether the received packet is an IPv4 packet or an IPv6 packet (i.e., detects “a key-type”)--; and
operating (Fig. 2 // ¶0044) a ternary content addressable memory (TCAM) system (Fig. 2), comprising at least a first TCAM block (First Bank 231, Fig. 2) and a second TCAM block (Second Bank 232, Fig.2),
in one of a wide search mode (“a 288-bit search mode” [0044]) or a narrow search mode (“a 144-bit search mode” [0044]) based on the detected key-type (“basic packet header information is generated from the IP packet classified by the packet classifier by operating an IPv4 parsing module for the IPv4 packet or operating an IPv6 parsing module for the IPv6 packet according to an IP version … For example 144 bits are assigned to the first bank 231 in which the security policy for an IPv4 packet is established, and accordingly, a 144-bit search mode can be performed. In addition, 288 bits are assigned to the second bank 232 in which the security policy for an IPv6 packet is established, and accordingly, a 288-bit search mode can be performed. Thus, each bank can apply a different search method” [0041-44]) wherein: operating the TCAM system in the narrow search mode comprises inputting (Fig. 2) the key entry to the first TCAM block (“The discrimination key for inquiring the lookup engine 230 … The lookup engine includes two banks 231 and 232 … Different bits are assigned to the two banks 231 and 232 … 144 bits are assigned to the first bank 231 in which the security policy for an IPv4 packet is established, and accordingly, a 144-bit search mode can be established” [0041-44] // Fig. 2) – As shown in Fig. 2, in a 144-bit search mode for IPv4 packets, the discrimination key generated for the IPv4 packet is looked up in first bank 231.
Park does not disclose the following limitations
operating the TCAM system in the narrow search mode comprises inputting the key entry to the first TCAM block and the second TCAM block ,
and operating the TCAM system in the wide search mode comprises splitting the key entry into a first key segment and a second key segment, and inputting the first key segment and the second key segment to the first TCAM block and the second TCAM block, respectively;
However, Levy discloses a following method of searching lookup tables implemented using TCAM memories. Levy discloses the following limitations:
operating the TCAM system in the narrow search mode (Fig. 4) comprises – Examiner considers Packet Processor 14 coupled to Lookup Memory 24 depicted in Levy Fig. 1 as analogous to the Packet Classifier 210 + Key Generator 220 coupled to Lookup Engine 230, respectively, as depicted in Park Fig. 2, whereby a first and a second bank 30 of the Levy Lookup Memory 24 correspond to first bank 231 and second bank 232 of Park--
inputting (Fig. 4, blocks 108-110) the key entry to the first TCAM block (Memory Bank 30-1, Fig. 1) and the second TCAM block (“At block 108, a hash operation is performed on the lookup key … to compute a hashed lookup key segment … At block 110, a database is queried, using the hashed lookup key segment computed at block 108 … In some embodiments, the database is queried by using the hashed lookup key segment to access each of at least two different banks of the two or more memory banks.” [0063-64]) – As shown in Fig. 4 and detailed in ¶¶0063-64, the lookup key is hashed using a single hash function (block 108) to create a hashed lookup segment, whereby the hashed lookup segment is queried in (i.e., “input” to) each of at least two different banks of lookup table 26 (e.g., at least Memory Banks 30-1 and 30-2). Examiner accordingly considers the first lookup technique as described in Fig. 4 as a “narrow search mode”--,
and operating the TCAM system in the wide search mode (Fig. 6) comprises splitting (Fig. 6, block 146) the key entry into a first key segment and a second key segment (“At block 146, two or more hash operations are performed on the lookup key … to compute two or more respective hashed lookup key segments” [0077]) – As shown in Fig. 6 and detailed in ¶0077, the lookup key is hashed by at least two hash operations into at least two respective hashed lookup key segments (i.e., at least “a first key segment” and “a second key segment”)--; and
inputting (Fig. 6, block 150) the first key segment and the second key segment to the first TCAM block and the second TCAM block, respectively (“At blocks 148 … a database is queried, using the two or more hashed lookup key segments computed at block 146 … the database queried at blocks 148 is distributed among N memory banks each corresponding to a different one of N hash functions, and the hash operations at block 146 include N hash operations using the N different hash functions … At block 150, the two or more memory banks are accessed using the hashed lookup key segments computed at block 146 to identify two or more respective matching segments” [0078-79]) – As shown in Fig. 6 and detailed in ¶¶0078-79, each hashed lookup key segment is looked up in a respective memory bank (i.e., at least Memory Banks 30-1 and 30-2) to which the hash function used to generate the respective hashed lookup key segment is uniquely associated. Examiner accordingly considers the second lookup technique described in Fig. 6 as a ”wide search mode”--;
Park and Levy are considered analogous to the claimed invention because they all relate to the same field of performing searches of TCAM blocks in response to classifying a received network packet. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Park with the teachings of Levy and realize a TCAM system whereby a wide and a narrow search mode are employed for IPv4 and IPv6 packets, respectively, using the same TCAM blocks. Doing so provides a common set of memory banks for lookup keys having different sizes without requiring shorter keys to be padded to the length of the longest supported key, which is an efficient implementation of exact match lookup techniques used for packet processing operations, as disclosed in Levy ¶¶0005 // 0021: “Exact match lookups are currently used to perform any of numerous different packet processing operations … due to the wide variety of possible processing operations, exact match lookups can require using a number of different types of keys having different key sizes” [0005] // “In embodiments described below, lookup keys having different sizes (e.g., bit lengths) are efficiently stored in a unified memory (e.g., a common set of memory banks) without requiring that shorter keys be padded to the length of the longest supported key.” [0021]
The combined teachings of Park and Levy do not provide specific detail regarding a format of the output of a lookup of TCAM blocks. Specifically, Park and Levy do not disclose the following limitations:
inputting the key entry to the first TCAM block and the second TCAM block in the wide search mode to generate a first hit-bitmap and a second hit-bitmap, and
interleave the first hit-bitmap with the second hit-bitmap to obtain an interleaved hit-bitmap;
merging the first hit-bitmap and the second hit-bitmap using a logical bitwise AND operation to obtain a merged hit-bitmap;
However, Zhang discloses the following limitations:
inputting the key entry to the first TCAM block (Lookup Engine 1 56.1, Fig. 2) and the second TCAM block (Lookup Engine 2 56.2, Fig. 2) to generate a first hit-bitmap and a second hit-bitmap (“In an example embodiment, the rule results generated by each of the lookup engines 56.1 to 56.N are in a combinable format, e.g., the rule results may be bitmaps” [0035] // Fig. 2 // ¶¶0033-36) – Examiner considers Processor 52 and Key Extraction Module 54 coupled to Lookup Engines 56 depicted in Zhang Fig. 2 as analogous to Packet Classifier 210 and Key Generator 220 coupled to Lookup Engine 230 of Park Fig. 2. As taught in ¶0035, the results of a lookup into Lookup Engines 56.1 and 56.2 are in a “bitmap” type of format (i.e., “a first hit-bitmap” and “a second hit-bitmap”)--, and
interleave the first hit-bitmap with the second hit-bitmap to obtain an interleaved hit-bitmap (“the group logic module 58 may combine the rule results of the multiple lookup engines 56.1 to 56.N to provide a result (e.g., a combined result) for this group as well” [0036]) – As taught in ¶0036, the output of each lookup engine is combined together (i.e., each bitmap is “interleave[d]” together)--;
merging the first hit-bitmap and the second hit-bitmap using a logical bitwise AND operation to obtain a merged hit-bitmap(“the group logic module 58 may perform an AND operation on the bitmap results of the various lookup engines 56.1 to 56.N to provide a combined result for the primary lookup” [0036]);
Park, Levy, and Zhang are all considered analogous to the claimed invention because they all relate to the same field of performing TCAM searches during packet processing in network environments. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Park and Levy with the teachings of Zhang and realize TCAM blocks which generate a lookup results in a bitmap-type of format. Using a combinable format, such as a bitmap, to generate TCAM lookup results enables the results of several TCAM lookups to be combined together into a master bitmap, enabling varying sizes of TCAM table lookups to be utilized and thus allowing for limits to be placed on amount of memory and time spent of performing data packet classification, as disclosed in Zhang ¶¶0035-36 // 0074: “In an example embodiment, the rule results generated by each of the lookup engines … are in a combinable format, e.g., the rule results may be bitmaps … In one example embodiment, the group logic module 58 may combine the rule results of the multiple lookup engines … to provide a result (e.g., a combined result) for this group” [0035-36] // “From this disclosure it will be evident that the apparatus and methods of the example embodiments provide for the configuration of different secondary lookup tables having varying sizes. The varying sizes of the secondary lookup tables enable the packet classifier to limit the amount of memory and time spent on processing and classifying data packets.” [0074]
The combined teachings of Park, Levy, and Zhang additionally disclose the following limitations:
and interleaving the merged hit-bitmap with a plurality of zeros to obtain the interleaved hit-bitmap. (Fig. 13 // “two packet classifiers 50A and 50B used in combination to provide a combined result or master bit to a primary lookup table … Each of the lookup engines may generate a rule result for its associated secondary lookup table, which is respectively combined by group logic modules 58A and 58B of the two packet classifiers. These combined result bitmaps may then be mapped to a global bitmap (or master bitmap) by a combiner module 60” [0064-70] // “In the above example, the master bitmap will have a value “1001110” [0061]) – As shown in Fig.13, the combined bitmap results of a first packet classifier 50A (i.e., “the merged hit-bitmap”) is combined by a combined module 60 with the bitmap results of another packet classifier 50B for form a global bitmap with respect to the two classifiers. As clarified in ¶0061, the bitmap result of a packet classifier can contain at least three (i.e., “a plurality of”) zeros. Therefore, examiner considers the process of combining two bitmap results, one of which containing at least three zeros, as reading on the claimed concept of “interleav[ing] the merged hit-bitmap with a plurality of zeros”, the combined result of Fig. 13 corresponding to “the interleaved hit-bitmap”.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Park further in view of Levy, Zhang, and Wang et al. (US 20160142316 A1)(cited by examiner in previous action)(hereafter referred to as Wang).
Regarding Claim 4,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 4. The combined teachings of Park, Levy and Zhang disclose the following limitations:
The TCAM system of claim 3 (see Claim 3 limitation mappings above),
Although Levy ¶0005 discloses that different lookup tables stored in different memories can have various key sizes, the combined teachings of Park, Levy, and Zhang do not provide a specific example of a 512-bit and a 256-bit TCAM entries. Specifically, the combined teachings of Park, Levy, and Zhang do not explicitly disclose the following limitations:
wherein the at least one logical TCAM comprises one or more 512-bit entries and one or more 256-bit entries
However, Wang discloses the following limitations:
wherein the at least one logical TCAM (TCAM Pool 116, Fig. 9) comprises one or more 512-bit entries and one or more 256-bit entries (Fig. 10 // “FIG. 10 depicts an example of configuration of a TCAM table 1000 configured for TCAM searches on TCAM pools 116, wherein the TCAM table includes a key size parameter … and a data size parameter. In some embodiments, the search key section has allowed sizes of 64, 128, 192 and 384 bits. In some embodiments, the data size may be 32, 42, 128, or 256 bits.” [0038]) – As shown in Wang Fig. 10 and detailed in ¶0038, TCAM tables can be configured with several key and data sizes, including: 384-bit key + 128-bit data = 512 bit entry; and 128-bit key + 128-bit data = 256-bit entry.
Park, Levy and Zhang discloses a packet processor in a network environment comprising TCAM tables distributed across memory banks (see Levy Fig. 3). Wang discloses a known method of configuring TCAM tables within a TCAM pool to have both 512-bit entries and 256-bit entries (see limitation mappings above). It would have been obvious to someone of ordinary skill in the art to implement the method of configuring TCAM tables to have 512-bit entries and 256-bit entries, as taught by Wang, to a packet processor comprising TCAM tables distributed across memory banks of Levy. A person of ordinary skill in the art would have recognized that applying the known technique of configuring TCAM tables within a TCAM pool to have both 512-bit and 256-bit entries would have yielded the predictable result of a TCAM system configured to include a logical TCAM having both 512-bit and 256-bit entries. Configuring a TCAM system with both 512-bit and 256-bit entries would have been expected to improve system performance by enabling variable-sized keys to be searched in the same TCAM system, obviating the need to pad each key to be the same bit length. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to apply the known technique of configuring a TCAM system with both 512-bit and 256-bit entries, as taught by Wang, to the packet processor in a network environment comprising TCAM tables distributed across memory banks disclosed in Levy and Shoham. Doing so would predictably result in a TCAM system which comprises both 512-bit and 256-bit entries. See MPEP 2143, Rationale D.
Claims 6-18 are rejected under 35 U.S.C. 103 as being unpatentable over Park further in view of Levy, Zhang and Kanekar et al. (US 20070002862 A1)(cited by examiner in previous action)(hereafter referred to as Kanekar).
Regarding Claim 6,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of Park, Levy and Zhang disclose the following limitations:
The TCAM system of claim 5, further comprising:
a plurality of priority decoders coupled to the first TCAM block and the second TCAM block (Zhang, Group Logic Modules 58A + 58B + Combiner Module 60, Fig. 13) – Examiner considers the group logic modules 50A + 50B and the combiner module 60 as “a plurality of priority decoders”)--
The combined teachings of Park, Levy, and Zhang do not disclose the following limitations:
a plurality of associated data look-ups coupled to the plurality of priority decoders
However, Kanekar discloses the following limitations:
a plurality of associated data look-ups (Memories 906, Fig. 9A) coupled to the plurality of priority decoders (Fig. 9A // “FIG. 9A illustrates one embodiment of a system for identifying a merged lookup result … Based on lookup value 903, a lookup operation is performed in associative memory entries 904 … in multiple associative memory banks … to generate a results 905, based on which, memories 906 generate results 907.” [0097-99]) – As shown in Kanekar Fig. 9A, a lookup value 903 is looked up in a plurality of associative memory banks 904 resulting in results 905, similar to how a key in Zhang Fig. 13 is looked up in a plurality of lookup engines 56 resulting in a combined result. Examiner accordingly considers the results 905 shown in Kanekar Fig. 9A as analogous to the combined result of Zhang Fig. 13. As shown in Kanekar Fig. 9A, results 905 are fed into memories 906 which subsequently generate results 907. In this context, examiner considers Memories 906, which receive lookup results 905, as “a plurality of associated data look-ups” which are “coupled to” (i.e., receive outputs from) the priority decoders of Zhang.
Park, Levy, Zhang, and Kanekar are considered analogous to the claimed invention because they all relate to the same field of performing packet processing and classification in a network environment. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Park, Levy, and Zhang with the teachings of Kanekar and realize a TCAM system whereby a plurality of data lookups are coupled to a plurality of priority encoders. Such a configuration is a known approach to address the problem of the high rate at which packet classification must be performed, as disclosed in Kanekar ¶0009: “One problem with performing packet classification is the rate at which it must be performed, especially when multiple features of a certain type are to be evaluated. A prior approach uses a series of lookups to evaluate an action to be taken for each of these features … Lookup operations can then be performed on the associative and adjunct memories to identify a corresponding action to use for a particular packet being processed.” [0009]
Regarding Claim 7,
The same motivation to combine provided in Claim 6 is equally applicable to Claim 7. The combined teachings of Park, Levy, Zhang, and Kanekar disclose the following limitations:
The TCAM system of claim 6, wherein the key-type is one of a narrow key or a wide key. (Levy, “each different key size … corresponds to a different type of search/lookup” [0027] // Figs. 4 + 6) – As previously discussed (see Claim 1 limitation mappings above) and as detailed in Levy ¶0027, each key size (i.e., “key-type”) corresponds to a particular/different type of search (e.g., Figs. 4 and 6). Examiner accordingly considers the particular key size resulting in the lookup technique shown in Levy Figs. 4 and 6 as “a narrow key” and “a wide key”, respectively.
Regarding Claim 8,
The same motivation to combine provided in Claim 6 is equally applicable to Claim 8. The combined teachings of Park, Levy, Zhang, and Kanekar disclose the following limitations:
The TCAM system of claim 7, wherein a size of the narrow key is smaller than a size of the wide key (Levy, “A first exact match lookup technique … is particularly well-suited for applications in which most keys are expected to have a minimum key size … A second, alternative exact match lookup technique … provides a more general solution that is agnostic to the distribution of key sizes” [0033] // ¶¶0059; 0074) – As disclosed in Levy ¶0033, the first lookup technique (i.e., the narrow search mode) can be applied in situations where most keys (i.e., narrow keys) have “a minimum key size”; whereas the second lookup technique (i.e., the wide search mode) can be applied in more general situations which are agnostic to the distribution of the size of keys (i.e., wide keys). In this case, one of ordinary skill in the art would understand that an average key size for applications suited for the first search technique (i.e., “a size of the narrow key”) would be “smaller than” an average key size for applications suited for the second technique (i.e., “a size of the wide key”).
Regarding Claim 9,
The same motivation to combine provided in Claim 6 is equally applicable to Claim 9. The combined teachings of Park, Levy, Zhang, and Kanekar disclose the following limitations:
The TCAM system of claim 7, wherein the TCAM logic is further configured to operate the TCAM system in the narrow search mode (Levy, Fig. 4) in response to detecting that the key-type is the narrow key (Levy, “each different key size .. corresponds to a different type of search/lookup” [0027] // “key search/insertion unit 22 identifies/selects one or more hash tables based on the key size (e.g., using a key size indicator provided by key generation unit).” [0037]) – As previously discussed (see Claims 1 + 7 above) and as detailed in Levy, key size determines the particular search technique (e.g., the “narrow search mode” shown in Levy Fig. 4; see also “a key size indicator” [0037]) employed for the associated lookup key. One of ordinary skill in the art would accordingly understand that the search technique of Fig. 4 (i.e., the narrow search mode) would be performed based on detecting the particular key size which corresponds to the narrow search technique (i.e., detecting the narrow key type).
Regarding Claim 10,
The same motivation to combine provided in Claim 6 is equally applicable to Claim 10. The combined teachings of Park, Levy, Zhang, and Kanekar disclose the following limitations:
The TCAM system of claim 9, wherein in response to inputting the key entry to the first TCAM block and the second TCAM block: the first TCAM block is further configured to generate a first hit-bitmap based on the key entry and the first plurality of entries, and the second TCAM block is further configured to generate a second hit-bitmap based on the key entry and the second plurality of entries. (Zhang, Fig. 2 // see Claim 1 limitation mappings above) – As discussed above with respect to Claim 1, outputs of respective lookup engines 56.1 result in generation of a respective bitmap.
Regarding Claim 11,
The same motivation to combine provided in Claim 10 is equally applicable to Claim 11. The combined teachings of Park, Levy, Zhang, and Kanekar disclose the following limitations:
The TCAM system of claim 10, wherein the TCAM logic is further configured to:
interleave the first hit-bitmap with the second hit-bitmap to obtain an interleaved hit- bitmap (Zhang, “combined result bitmap” [0036] // “the group logic module 58 may perform an AND operation on the bitmap results of the various lookup engines 56.1 to 56.N to provide a combined result for the primary lookup table. This combined result bitmap may then be mapped to a global bitmap (or master bitmap)” [0036]) – As taught in Zhang ¶0036, the results of each lookup engine (i.e., the “first” and “second” “hit-bitmap[s]”) are combined together to form a “combined result bitmap” (i.e., “an interleaved hit-bitmap”); and
provide the interleaved hit-bitmap to the plurality of priority decoders (Zhang, Fig. 13) -- As previously discussed (see Claim 6 limitation mappings above) and as shown in Zhang Fig. 3, the results of TCAM block lookups (i.e., “the interleaved hit-bitmap”) are provided to Group Logic Modules 58.
Regarding Claim 12,
The same motivation to combine provided in Claim 10 is equally applicable to Claim 12. The combined teachings of Park, Levy, Zhang, and Kanekar disclose the following limitations:
The TCAM system of claim 11, wherein:
the plurality of priority decoders is configured to output one or more index values (Kanekar, Results 905, Fig. 9A) based on the interleaved hit-bitmap (Kanekar, Fig. 9A) – As previously discussed (see Claim 11 limitation mappings above), the TCAM block search results are combined as an “interleaved hit-bitmap”. As shown in Kanekar Fig. 9A, the results of the TCAM block search are fed into Memories 906 so that Results 907 can be determined. In this context, Results 905 are effectively indexed into Memories 906 in order to generate Results 907. Examiner accordingly considers the Results 905 of Kanekar Fig. 9A as “one or more input values”--, and
the plurality of associated data look-ups is configured to output a set of results (Kanekar, Results 907, Fig. 9A) mapped to the one or more index values (Kanekar, Fig. 9A // ¶0099)—As shown in Kanekar Fig. 9A, Memories 906 output Results 907 based on the received Results 905.
Regarding Claim 13,
The same motivation to combine provided in Claim 10 is equally applicable to Claim 13. The combined teachings of Park, Levy, Zhang, and Kanekar disclose the following limitations:
The TCAM system of claim 12, wherein the TCAM logic is further configured to:
merge the set of results (Kanekar, Fig. 9A); and
obtain, based on the merging of the set of results, a single result (Kanekar, Merged Results 911, Fig. 9A) configured to indicate at least one action (Kanekar, “Combiner mechanism 910 merges results 907 to produce one or more merged results 911, which are typically used by packet processor 902 in the processing of packets … Different associative memories are each programmed with associative memory entries corresponding to a different one of the features…” [0099-0100] // Figs. 9A + 9B) – As shown in Kanekar Fig. 9A, Results 907 are merged into a single, merged result 911, which is fed back into packet processor 902 to assist in processing the packet. As clarified in Fig. 9B, several actions wither respect to the packet (e.g., permit, deny) are performed based on the merged result.
Regarding Claim 14,
The same motivation to combine provided in Claim 6 is equally applicable to Claim 14. The combined teachings of Park, Levy, Zhang, and Kanekar disclose the following limitations:
The TCAM system of claim 7, wherein the TCAM logic is further configured to operate the TCAM system in the wide search mode (Levy, Fig. 6) in response to detecting that the key-type is the wide key. (Levy, “each different key size .. corresponds to a different type of search/lookup” [0027] // “key search/insertion unit 22 identifies/selects one or more hash tables based on the key size (e.g., using a key size indicator provided by key generation unit).” [0037]) – As previously discussed (see Claims 1 + 7 above) and as detailed in Levy, key size determines the particular search technique (e.g., the “wide search mode” shown in Levy Fig. 6; see also “a key size indicator” [0037]) employed for the associated lookup key. One of ordinary skill in the art would accordingly understand that the search technique of Fig. 6 (i.e., the wide search mode) would be performed based on detecting the particular key size which corresponds to the wide search technique (i.e., detecting the wide key type).
Regarding Claim 15,
The same motivation to combine provided in Claim 6 is equally applicable to Claim 15. The combined teachings of Park, Levy, Zhang, and Kanekar disclose the following limitations:
The TCAM system of claim 14, wherein in response to inputting the first key segment to the first TCAM block and the second key segment to the second TCAM block:
the first TCAM block is further configured to generate a first hit-bitmap based on the inputted first key segment and the first plurality of entries, and the second TCAM block is further configured to generate a second hit-bitmap based on the inputted second key segment and the second plurality of entries. (Zhang, Fig. 2 // see Claim 1 limitation mappings above) – As discussed above with respect to Claim 1, outputs of respective lookup engines 56.1 result in generation of a respective bitmap.
Regarding Claim 16,
The same motivation to combine provided in Claim 6 is equally applicable to Claim 16. The combined teachings of Park, Levy, Zhang, and Kanekar disclose the following limitations:
The TCAM system of claim 15, wherein the TCAM logic is further configured to:
generate a merged hit-bitmap based on the first hit-bitmap and the second hit-bitmap; and interleave the merged hit-bitmap with a plurality of zeros to obtain an interleaved hit- bitmap (Zhang, Fig. 13; see also Claim 1 limitation mappings above) – As discussed above with respect to Claim 1, outputs of respective lookup engines 56.1 result in generation of a respective bitmap and are combined and interleaved with other bitmaps to form a result.
Regarding Claim 17,
The same motivation to combine provided in Claim 6 is equally applicable to Claim 17. The combined teachings of Park, Levy, Zhang, and Kanekar disclose the following limitations:
The TCAM system of claim 16, wherein:
the plurality of priority decoders is configured to output one or more index values (Kanekar, Results 905, Fig. 9A) based on the interleaved hit-bitmap (Kanekar, Fig. 9A) – As previously discussed (see Claim 16 limitation mappings above), the TCAM block search results are combined as an “interleaved hit-bitmap”. As shown in Kanekar Fig. 9A, the results of the TCAM block search are fed into Memories 906 so that Results 907 can be determined. In this context, Results 905 are effectively indexed into Memories 906 in order to generate Results 907. Examiner accordingly considers the Results 905 of Kanekar Fig. 9A as “one or more input values”--, and
the plurality of associated data look-ups is configured to output a set of results (Kanekar, Results 907, Fig. 9A) mapped to the one or more index values (Kanekar, Fig. 9A // ¶0099)—As shown in Kanekar Fig. 9A, Memories 906 output Results 907 based on the received Results 905.
Regarding Claim 18,
The same motivation to combine provided in Claim 6 is equally applicable to Claim 18. The combined teachings of Park, Levy, Zhang, and Kanekar disclose the following limitations:
The TCAM system of claim 17, wherein the TCAM logic is further configured to:
merge the set of results (Kanekar, Fig. 9A); and
obtain, based on the merging of the set of results, a single result (Kanekar, Merged Results 911, Fig. 9A) configured to indicate at least one action (Kanekar, “Combiner mechanism 910 merges results 907 to produce one or more merged results 911, which are typically used by packet processor 902 in the processing of packets … Different associative memories are each programmed with associative memory entries corresponding to a different one of the features…” [0099-0100] // Figs. 9A + 9B) – As shown in Kanekar Fig. 9A, Results 907 are merged into a single, merged result 911, which is fed back into packet processor 902 to assist in processing the packet. As clarified in Fig. 9B, several actions wither respect to the packet (e.g., permit, deny) are performed based on the merged result.
Response to Arguments
The previous objection of Claim 20 is withdrawn.
Applicant’s arguments with respect to claims 1-18 and 20 have been considered but are moot in view of the newly-identified Park reference 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.
Having reviewed the Specification, examiner notes that if applicant wishes to distinguish the claimed invention from the prior art of record (including Zhang), amending the independent claims to provide more specific detail regarding the process of interleaving hit-bitmaps with a plurality of zeros (see, e.g., Specification ¶0078) would be helpful in moving prosecution of the application forward.
Conclusion
THIS ACTION IS MADE FINAL. 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 JULIAN SCOTT MENDEL whose telephone number is (703)756-1608. The examiner can normally be reached M-F 10am - 4pm 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, Rocío del Mar Pérez-Vélez can be reached at 571-270-5935. 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.
/J.S.M./Examiner, Art Unit 2133
/ROCIO DEL MAR PEREZ-VELEZ/Supervisory Patent Examiner, Art Unit 2133
Prosecution Insights