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 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.
Claim(s) 1-7, 9-15 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liao (US PAT 7188168 ), hereinafter “Liao” in views of Urman et al. (US PG PUB 20210176345), hereinafter "Urman".
Regarding Claims 1, 10 and 19, Liao discloses:
(Claim 1) A method implemented at least in part by hardware circuitry (i.e. a method for implementing a hardware parser) (Column 3 Line # 63 – 67 and Column 4 Line # 1 - 5), the method comprising:
(Claim 10) A system (i.e. a hardware parser) (Column 3 Line # 63 – 67 and Column 4 Line # 1 - 5), comprising;
one or more processors (i.e. processor) (Column 4 Line # 29 - 37); and one or more non-transitory computer-readable media storing instructions executable by the one or more processors (i.e. random-access memory) (Column 5 Line # 1 - 15), wherein the instructions program the one or more processors to perform operations comprising:
(Claim 19) One or more non-transitory computer-readable media maintaining instructions that, when executed by one or more processors (i.e. memory storing programs/instructions executable by processor) (Column 5 Line # 1 - 15), program the one or more processors to perform operations comprising:
receiving a network packet comprising a plurality of tokens (i.e. method/system may receive a packet including a string of lexical tokens [i.e. a plurality of tokens], wherein each protocol header is defined as a lexical token) (Column 1 Line # 50 – 51, Column 3 Line # 63 – 67 and Column 4 Line # 1 – 5 and Column 5 Line # 62 - 67);
identifying, by a first parser, a first token of the plurality of tokens (i.e. the hardware parser [i.e. a first parser] may identify a lexical token [i.e. a first token] of the string of lexical tokens [i.e. the plurality of tokens]) (Column 3 Line # 63 – 67 and Column 4 Line # 1 – 5 and Column 5 Line # 44 - 51).
However, Liao does not explicitly disclose:
determining, by the first parser, first boundaries of the first token, the first boundaries including a first token type; triggering, by the first parser and based on the first token type, a second parser; identifying, by the first parser, a second token of the plurality of tokens; determining, by the first parser, second boundaries of the second token, the second boundaries including a second token type; and triggering, by the first parser and based on the second token type, a third parser.
On the other hand, in the same field of endeavor, Urman teaches:
identifying, by a first parser, a first token of the plurality of tokens (i.e. flexible hardware parser 40 [i.e. a first parser] may identify a header [i.e. a first token] of a plurality of headers [i.e. the plurality of tokens] to be parsed) (40 – Fig. 2 and ¶ 0059 - 0060);
determining, by the first parser, first boundaries of the first token (i.e. the flexible hardware parser 40 [i.e. the first parser] may determine parameters such as “offset, header size, next offset, next header offset and next header ID” [i.e. first boundaries] of the header [i.e. the first token]; Note that those parameters define the starting & ending points associated with the header and identification of the next header [i.e. thus defines the boundaries between the header and the next header; In other words, those parameters are boundaries of the first header/token]) (102, 106, 108, 114 & 116 – Fig. 5, ¶ 0068 and ¶ 0070),
the first boundaries including a first token type (i.e. next header ID indicated by the next header offset [i.e. the first boundaries] links/includes next protocol [i.e. a first token type] associated with the next header; Note that the next protocol [i.e. a first token type] indicates the protocol associated with the next header [i.e. a token], thus next protocol is a type of the token [i.e. token type]) (118 – Fig. 5, ¶ 0024 and ¶ 0070);
triggering, by the first parser and based on the first token type, a second parser (i.e. flexible hardware parser 40 [i.e. the first parser] may transfer, based on the next protocol [i.e. the first token type], header section to a next hardware parser [i.e. a second parser] associated with the next protocol causing [i.e. triggering] the next hardware parser [i.e. a second parser] to further process the header section) (120 – Fig. 5 and ¶ 0070);
identifying, by the first parser, a second token of the plurality of tokens (i.e. flexible hardware parser 40 [i.e. the first parser] may identify a second header [i.e. a second token] of a plurality of headers [i.e. the plurality of tokens] to be parsed) (40 – Fig. 2 and ¶ 0059 - 0060);
determining, by the first parser, second boundaries of the second token (i.e. the flexible hardware parser 40 [i.e. the first parser] may determine “second offset, second header size, second next offset, second next header offset and second next header ID” [i.e. second boundaries] of the second header [i.e. the second token]) (102, 106, 108, 114 & 116 – Fig. 5, ¶ 0068 and ¶ 0070),
the second boundaries including a second token type (i.e. the second next header ID indicated by the second next header offset [i.e. the second boundaries] links/includes second next protocol [i.e. a second token type] associated with the second next header) (118 – Fig. 5, ¶ 0024 and ¶ 0070); and
triggering, by the first parser and based on the second token type, a third parser (i.e. flexible hardware parser 40 [i.e. the first parser] may transfer, based on the second next protocol [i.e. the second token type], header section to a next hardware parser [i.e. a third parser] associated with the second next protocol causing [i.e. triggering] the next hardware parser [i.e. a third parser] to further process the header section) (120 – Fig. 5 and ¶ 0070).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method/system/computer-readable-medium of Liao to include the features for determining, by the first parser, first boundaries of the first token, the first boundaries including a first token type; triggering, by the first parser and based on the first token type, a second parser; identifying, by the first parser, a second token of the plurality of tokens; determining, by the first parser, second boundaries of the second token, the second boundaries including a second token type; and triggering, by the first parser and based on the second token type, a third parser as taught by Urman so that the method/system may be implemented as a main hardware parser comprised of a group of reconfigurable parsers (18 - Fig. 1, ¶ 0044 – 0046 and ¶ 0053 - 0054).
Regarding Claims 2 and 11, Liao and Urman disclose, in particular Urman teaches:
wherein the first boundaries of the first token further comprise processing a header of the first token to determine token length and token data length (i.e. The flexible hardware parser 40-1 is configured to compute (block 108) an offset for passing to the next hardware parser 40, 42 responsively to the retrieved header size and the offset received in the step of block 102. The computed offset provides the offset of the last bit in this header. Therefore, the flexible hardware parser 40-1 is configured to compute the offset responsively to the header size offset field 52 (and optionally header size mask field 54) [i.e. token length and token data length] of the parsing configuration data and the header size from the header section, and the offset received in the step of block 102) (¶ 0068).
The prior art used in the rejection of the current claim is combined using the same motivations as was applied in claim 1.
Regarding Claims 3, 12 and 20, Liao and Urman disclose, in particular Urman teaches:
wherein the first parser operates in parallel to one or more of the second parser and the third parser (i.e. the flexible hardware parser 40-1 operates in parallel to flexible hardware processor 40-1, 40-2, etc.) (Fig. 2, Fig. 3 and ¶ 0059).
The prior art used in the rejection of the current claim is combined using the same motivations as was applied in claim 1.
Regarding Claims 4 and 13, Liao and Urman disclose, in particular Urman teaches:
wherein identifying the first token comprises identifying the first token using a byte pointer (i.e. header offset field 58 provides the relative offset of a header identification field [i.e. a byte pointer] in the header giving the identification of the header [i.e. identifying the first token] to be parsed in the header section) (¶ 0060).
The prior art used in the rejection of the current claim is combined using the same motivations as was applied in claim 1.
Regarding Claims 5 and 14, Liao and Urman disclose, in particular Urman teaches:
wherein triggering the second parser comprises: determining the second parser based at least in part on the first token type (i.e. flexible hardware parser 40 [i.e. the first parser] may transfer, based on the next protocol [i.e. the first token type], header section to a next hardware parser [i.e. a second parser] associated with the next protocol causing [i.e. triggering] the next hardware parser [i.e. a second parser] to further process the header section) (120 – Fig. 5 and ¶ 0070); and
sending, to the second parser the first boundaries associated with the first token (i.e. parameters such as the offset computed in the step of block 108 and the header size offset from the header size offset field [i.e. the first boundaries associated with the first token] may be provided to the next hardware parser 40, 42 [i.e. the second parser]. The steps of blocks 102-122 are repeated by the next hardware parser 40, and so on) (¶ 0067 - 0068 and ¶ 0070),
wherein the first boundaries further comprise pointer attributes associated with the first token (i.e. the parameters [i.e. the first boundaries associated with the first token] include the offset computed in the step of block 108 and the header size offset from the header size offset field [i.e. pointer attributes associated with the first token]) (¶ 0067 – 0068).
The prior art used in the rejection of the current claim is combined using the same motivations as was applied in claim 1.
Regarding Claims 6 and 18, Liao and Urman disclose, in particular Urman teaches:
wherein the first parser comprises a high-level parser thread (i.e. The flexible hardware parsers 40 [i.e. the first parser] are configured to parse header section data according to the data in the parser configuration registers 24. The flexible hardware parsers 40 are therefore reconfigurable [i.e. a high-level parser thread] even after the network device 10 has been manufactured) (¶ 0054).
The prior art used in the rejection of the current claim is combined using the same motivations as was applied in claim 1.
Regarding Claims 7 and 15, Liao and Urman disclose, in particular Urman teaches:
wherein the second parser and the third parser comprise different per-token parser threads (i.e. each flexible hardware parser 40-1, 40-2, etc. [i.e. the second parser and third parser] are configured for parsing different protocol types [i.e. different per-token parser threads]) (118 – Fig. 5, ¶ 0024 and ¶ 0070).
The prior art used in the rejection of the current claim is combined using the same motivations as was applied in claim 1.
Regarding Claims 9 and 17, Liao and Urman disclose, in particular Urman teaches:
identifying, by the first parser, a third token (i.e. flexible hardware parser 40 [i.e. the first parser] may identify a third header [i.e. a third token] of a plurality of headers to be parsed) (40 – Fig. 2 and ¶ 0059 - 0060),
determining, third boundaries of the third token (i.e. the flexible hardware parser 40 [i.e. the first parser] may determine “third offset, third header size, third next offset, third next header offset and third next header ID” [i.e. second boundaries] of the third header [i.e. the third token]) (102, 106, 108, 114 & 116 – Fig. 5, ¶ 0068 and ¶ 0070),
the third boundaries including a third token type (i.e. the third next header ID indicated by the third next header offset [i.e. the second boundaries] links/includes third next protocol [i.e. a third token type] associated with the third next header) (118 – Fig. 5, ¶ 0024 and ¶ 0070);
determining, that the third token type does not match a corresponding per-token parser (i.e. The multiplexer searches the compare data field 70 of the data subsets 50 until a match is found [i.e. comparing/determining as long as the comparison doesn’t match; In other words, determining that the third token type does not match a corresponding per-token parser]. A match means that the multiplexer should send the header section and offset to the flexible hardware parser 40 associated with that data subset 50 in which the match was found) (¶ 0065); and
triggering a fourth parser associated with an unknown token type (i.e. multiplexer of flexible hardware parser 40 [i.e. the fourth parser] be caused to find a match; A match means that the multiplexer should send the header section and offset to the flexible hardware parser 40 associated with that data subset 50 in which the match was found; In some instances, the multiplexer may not find a match to the next header identification in any of the data subsets [i.e. an unknown token type]) (¶ 0065),
where the fourth parser refrains from processing token data associated with the third token (i.e. If the multiplexer cannot find a match to the next header identification in any of the data subsets 50 parsing is stopped and further processing of the packet is passed [i.e. refrains from processing token data associated with the third token]) (¶ 0065).
The prior art used in the rejection of the current claim is combined using the same motivations as was applied in claim 1.
Claim(s) 8 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liao in views of Urman as applied to claims 1 and 10 above, and further in view of Herbert et al. (US PAT 11032398), hereinafter "Herbert".
Regarding Claims 8 and 16, the combination of Liao and Urman discloses all the features with respect to Claims 1 and 10 as described above.
However, the combination of Liao and Urman does not explicitly disclose:
identifying, by the first parser, an end of the network packet; and transmitting to the second parser and the third parser, a message indicating the end of the network packet is reached to cause the second parser and the third parser to output one or more values associated with processing each of the first token and the second token.
On the other hand, in the same field of endeavor, Herbert teaches:
identifying, by the first parser, an end of the network packet (i.e. with the use of a parser associated with low level socket [i.e. the first parser] may identify that the entire message has been read [i.e. end portion of the message has been read/identified]) (Fig. 9, Column 9 Line # 53 – 59 and Column 10 Line # 9 – 19); and
transmitting to the second parser and the third parser, a message indicating the end of the network packet is reached to cause the second parser and the third parser to output one or more values associated with processing each of the first token and the second token (i.e. the parser associated with low level socket may transmit the message indicating that the entire message has been received/read [i.e. the end of the network packet is reached] to the parsers associated with high level sockets [i.e. the second parser and third parser] and cause the message to be processed at the high level sockets [i.e. output one or more values associated with processing each of the first token and the second token]) (Fig. 9 and Column 10 Line # 23 – 31).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method/system/computer-readable-medium of Liao and Urman to include the features for identifying, by the first parser, an end of the network packet; and transmitting to the second parser and the third parser, a message indicating the end of the network packet is reached to cause the second parser and the third parser to output one or more values associated with processing each of the first token and the second token as taught by Herbert so that the messages may be firstly processed at a lower level parsers and passed down to the higher lever parsers upon completion (Fig. 9, Column 9 Line # 53 – 59, Column 10 Line # 9 – 19 and Column 10 Line # 23 – 31).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SOE MIN HLAING whose telephone number is (303)297-4282. The examiner can normally be reached Monday-Friday 9AM - 5PM.
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, Christopher Parry can be reached at 571-272-8328. 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.
/Soe Hlaing/ Primary Examiner, Art Unit 2451
Prosecution Insights