DETAILED ACTION
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 § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 2, 4, 5, 8, 15, 18 are rejected under 35 U.S.C. 102(a) as being anticipated by Goglin et al (USPN 20080005352).
Regarding claim 15, Goglin discloses
a switch, comprising: (network controller/device comprising, FIG. 1 #126 [¶ 0016, 0017, 0011]
memory for storing executable instructions (memory storing instructions, FIG. 1 #132, [¶ 0018]
a packet entropy engine (protocol table [¶ 0019]
at least one processor to execute the instructions, wherein the packet entropy engine is configured to: (processor, FIG. 1 #102A, for executing machine readable instructions [¶ 0011, 0012]
determine a protocol type for the packet (determine type of packet [¶ 0024-0028, 0036-0040]
extract information from the packet (information such as header, IP, source/destination are extracted from packet [¶ 0021, 0023]
match a configured protocol field corresponding to the extracted information in the header of the packet to a specified value (extracted packet information such as source/destination are used to match/lookup with entries in one of protocol tables [¶ 0023, 0024, 0030]
determine a byte range for the packet using the specified value (each entry in protocol table comprise a corresponding offset that specifies a distance and a corresponding bitmask (offset + mask = byte range) [¶ 0025, 0026]
create entropy for the packet by using data from the byte range (apply hash function to byte range (offset + bitmask) to generate hash result [¶ 0025], FIG. 2 #204-208.
Claim 1 is rejected based on similar ground(s) provided in rejection of claim 15.
Regarding claim 4, Goglin discloses “accessing a database that includes a plurality of destination ports, wherein the database includes bytes to hash that correspond to each of the destination ports; ” each of at least one protocol table(s) may comprise entries that include packet characteristics such as destination port [¶ 0024, 0032]
“and determining which bytes from the packet are included in the hash to create the entropy for the packet” packet characteristic corresponding to last reveal layer corresponding to offset and mask to be applied to the packet to generate hash value [¶ 0025, 0030, 0033].
Regarding claim 5, Goglin discloses “wherein the creating includes each byte of a payload of the packet being included or excluded in an entropy calculation for the packet based on a particular destination port of the packet being included in the database” start bit may comprise end of packet header, e.g. bit 112, with offset 0 bits and bitmask at 32 bits, bits 112-143 may be masked to generate hash value corresponding to payload region. Offset and mask can be specified to default fields enabling customization of fields for hash value [¶ 0025, 0031, 0032].
Regarding claim 8, Goglin discloses “wherein the determining of the byte range is determined by an 8. arbitrary header field within the header of the packet” multiple header fields that can drive byte range determination/arbitrarily header field [¶ 0024, 0027, 0036, 0037].
Regarding claim 18, Goglin discloses “a database that includes a plurality of destination ports, wherein the database includes bytes to hash that correspond to each of the destination ports” each of at least one protocol table(s) may comprise entries that include packet characteristics such as destination port [¶ 0024, 0032].
“and wherein each byte of a payload of the packet is included or excluded in an entropy calculation for the packet based on a particular destination port of the packet being included in the database that includes the plurality of destination ports” start bit may comprise end of packet header, e.g. bit 112, with offset 0 bits and bitmask at 32 bits, bits 112-143 may be masked to generate hash value corresponding to payload region. Offset and mask can be specified to default fields enabling customization of fields for hash value [¶ 0025, 0031, 0032].
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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 3, 16 are rejected under 35 U.S.C. 103 as being unpatentable over Goglin in view of Roitshtein et al (USPN 20120134497).
Regarding claims 3, 16, Goglin does not expressly disclose “wherein the byte range corresponds to a payload byte range and includes non-consecutive bytes”
Roitshtein discloses “wherein the byte range corresponds to a payload byte” network device, FIG. 1 #ND1, utilizes subset of bytes defined by mask, FIG. 2 #120/byte range with input bytes operated on are bytes of packet, FIG. 2 #102, which includes both header and data regions [¶ 0024, 0028, 0035]
“and includes non-consecutive bytes” the mask, FIG. 2 #102, selectively turns on or off individual bytes in N input bytes [¶ 0035]
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to implement “wherein the byte range corresponds to a payload byte range and includes non-consecutive bytes” as taught by Roitshtein into Goglin’s system with the motivation to achieve better entropy distribution (Roitshtein, paragraph [¶ 0035].
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Goglin in view of Roitshtein as applied to claim 16 and in further view of Anand et al (USPN 20150373164).
Regarding claim 17, Goglin discloses wherein a payload type is identified using a destination port in the header” protocol table includes entry for different destination ports which results in payload bytes get hashed [¶ 0024, 0030-0032, 0028]
Combined system of Goglin and Roitshtein does not expressly disclose “wherein the protocol type is user datagram protocol (UDP) for the packet”
Anand discloses UDP as supported layer [¶ 0048]
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to implement “wherein the protocol type is user datagram protocol (UDP) for the packet” as taught by Anand into combined system of Roitshtein and Goglin with the motivation to enable support of UDP as well-known technology.
Claims 2, 6, 7, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Goglin in view of Anand et al (USPN 20150373164).
Regarding claim 2, Goglin discloses wherein a payload type is identified using a destination port in the header” protocol table includes entry for different destination ports which results in payload bytes get hashed [¶ 0024, 0030-0032, 0028]
Goglin does not expressly disclose “wherein the protocol type is user datagram protocol (UDP) for the packet”
Anand discloses UDP as supported layer [¶ 0048].
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to implement “wherein the protocol type is user datagram protocol (UDP) for the packet” as taught by Anand into Goglin’s system with the motivation to enable support of UDP as well-known technology.
Regarding claims 6, 19, Goglin does not expressly disclose “using a plurality of offset bytes in a header field of the packet to determine a location of data in a payload field of the packet to be used to create the hash for the packet”
Anand discloses a plurality of offset bytes, i.e. offset 0 (MAC DA) and offset 16 (IP DA), in header of packet to determine location of data in payload [¶ 0064, 0079-0080, 0090]
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to implement “using a plurality of offset bytes in a header field of the packet to determine a location of data in a payload field of the packet to be used to create the hash for the packet” as taught by Anand into Goglin’s system with the motivation to enable improving hash function (Anand, paragraph [¶ 0064, 0079-0080, 0090]).
Regarding claim 7, Goglin does not expressly disclose “wherein the plurality of offset bytes can be configured at run time for an associated switch that receives the packet”
Anand discloses generic hash commands with “fieldOffset” per protocol layer where these fields are software defined/run time configuration [¶ 0079, 0009, 0017, 0078]
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to implement “using a plurality of offset bytes in a header field of the packet to determine a location of data in a payload field of the packet to be used to create the hash for the packet” as taught by Anand into Goglin’s system with the motivation to enable improving hash function (Anand, paragraph [¶ 0064, 0079-0080, 0090]).
Claims 9, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Goglin in view of Basso et al (USPN 20130156036).
Regarding claims 9, 20, Goglin discloses next-protocol driven layer revealing and destination-port keyed table entries [0024, 0027, 0032, 0037]
Goglin does not expressly disclose “wherein the protocol type for the packet is identified by a next protocol field, which corresponds to a destination port field”
Basso discloses parsing a packet header to extract bytes for hash code generation, including extracting both destination port and protocol byte from the same header. A tunneled IP-in-IP table reciting “DP Inner packet destination port 2 byte” along “proto inner packet protocol byte [0014, 0019, 0021, 0022]
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to implement “wherein the protocol type for the packet is identified by a next protocol field, which corresponds to a destination port field” as taught by Basso into Goglin’s system with the motivation to providing higher entropy hash inputs by leveraging both next-protocol identifier and destination port (Basso, paragraph [¶ 0014, 0019, 0021, 0022]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Caputo et al (USPN 20150098465) FIG. 3
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THAI NGUYEN whose telephone number is (571)270-7632. The examiner can normally be reached M-F campus 10:30-5pm, telework 6pm-8pm| Telework count days.
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, Ian N Moore can be reached at (571)272-3085. 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.
/THAI NGUYEN/Primary Examiner, Art Unit 2469
Prosecution Insights