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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 7, 9-15, and 18-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Bosshart; Patrick US PGPUB 20170063690 A1.
Regarding claim 1. A non-transitory computer-readable medium comprising instructions stored thereon, that if executed by one or more processors, ([0042] The information, in some embodiments, includes, among other data, an instruction memory address for the action engine 320 and an action memory address and size. ) cause the one or more processors to: execute a driver that is to:
determine a configuration of a packet processing pipeline of a network interface device ([0002] The hardware switch of some embodiments includes, among other elements, an ingress pipeline and an egress pipeline. Each pipeline includes a parser, a match-action unit (MAU), and a deparser.) to perform an instruction set written in a domain specific language (DSL) for the packet processing pipeline based on emulation of a parser of the packet processing pipeline ([0005] a compiler in the control plane receives the data required for configuring the pipeline (e.g., through a programming language code), generates a set of configuration data, and distributes the generated data to a configurator module (also part of the control plane). The configurator module then distributes the configuration data to both the parser and MAU of the pipeline in the switch.)and
provide the configuration to the packet processing pipeline of the network interface device to specify operations of the packet processing pipeline of the network interface device. ([[0038] [0038] The parser of some embodiments determines which header fields are participating header fields (i.e., the fields that may be processed by the MAU) and which header fields are non-participating header fields based on configuration data that the parser receives from a configurator module in the control plane.]
Regarding claim 2. Bosshart teaches The computer-readable medium of claim 1, wherein the emulation of the parser of the packet processing pipeline is based on a parser logic configuration utilized by the parser of the packet processing pipeline and wherein the parser logic configuration specifies at least one offset into the packet corresponding to at least one header field for a particular packet type. ([0059] FIG. 6 conceptually illustrates a process 600 of some embodiments that populates the PPHV and SPHV with different header field values (e.g., source and destination port addresses, fragmentation offset field, transport layer ports, encapsulation addresses, etc.) of a packet header (e.g., IPv4, TCP, UDP, etc.).)
Regarding claim 3. Bosshart teaches The computer-readable medium of claim 2, wherein the particular packet type is associated with particular arrangements and locations of header fields and definitions of header field values according to at least one protocol. ([0037] As described above, the parser 310 receives a packet (e.g., through a set of input modules of the switch) and extracts the packet headers (e.g., Ethernet header, IPv4 header, IPv6 header, TCP header, UPD header, tunnel encapsulation headers, etc.) from the body of the packet. The parser 310 then separates the header field values that may be processed by the MAU from the rest of the header field values in each packet header. As stated above, the header fields of a packet header are the different segments of the packet header, each of which stores a particular value representing a particular piece of data. For example, an IPv4 packet header includes a source IP address header field, a destination IP address header field, an IPv4 identification field header field, a time-to-live header field, etc.)
Regarding claim 4. Bosshart teaches The computer-readable medium of claim 1, comprising instructions stored thereon, that if executed by one or more processors, cause the one or more processors to: execute the driver to: generate one or more code execution tree representations of the instruction set. ([0006] This configuration data represents a parse graph that identifies how to parse the packet based on values of certain packet header fields as well as table flow and control flow graphs used to generate the configuration data for the MAU, which describe how packets will be processed through the stages of the MAU.)
Regarding claim 7. Boosshart teaches The computer-readable medium of claim 1, wherein the configuration comprises one or more of: a packet type, key, and action. ([0055] In some embodiments, the parse graph is implemented in the parser 530 as a set of entries in TCAMs that the extractor state machine matches. The packet header is received as a set of bits stored in, e.g., a buffer, and at any time during the extraction process a pointer points to a particular location in the buffer. The TCAM entries of the parse graph of some embodiments specify which type of header is next based on the value of certain fields of a current header (e.g., the EtherType field of an Ethernet header, the protocol field of an IPv4 header, etc.), and how to extract the header fields of the next header.)
Regarding claim 9. Bosshart teaches The computer-readable medium of claim 1, wherein the DSL comprises one or more of: Protocol-independent Packet Processors (P4), Software for Open Networking in the Cloud (SONiC), Broadcom® Network Programming Language (NPL), NVIDIA® CUDA®, NVIDIA® DOCA™, Data Plane Development Kit (DPDK), OpenDataPlane (ODP), Infrastructure Programmer Development Kit (IPDK), or eBPF. ([0051] In some embodiments, the compiler 520 generates configuration data for the hardware switch based on a switch configuration received by the compiler 520 (e.g., through code written by a user, such as P4 code for designing switch operations))
Regarding claim 10. Bosshart teaches The computer-readable medium of claim 1, wherein the network interface device comprises one or more of: a network interface controller (NIC), a remote direct memory access (RDMA)-enabled NIC, SmartNIC, router, switch, forwarding element, infrastructure processing unit (IPU), data processing unit (DPU), or network-attached appliance. ([0002] Some embodiments provide a novel packet processing pipeline that enhances the match-action packet header processing performed by reconfigurable hardware switches.)
Regarding claim 11-13, and 15, An apparatus comprising: a network interface device comprising a programmable packet processing pipeline, (Fig. 1) wherein the programmable packet processing pipeline comprises a packet parser (Fig. 1, Parser 145) and performing the method carried out by the instructions in claim 1-3, and 7. They are rejected for the same reasons.
Regarding claim 14. Bosshart teaches The apparatus of claim 12, wherein the programmable packet processing pipeline comprises circuitries that perform match-action operations in a pipelined manner. ([0002] Some embodiments provide a novel packet processing pipeline that enhances the match-action packet header processing performed by reconfigurable hardware switches. )
Regarding claim 18-20 Bosshart teaches A method comprising steps recited in claim 1-3. They are rejected for the same reasons.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 5, 6 are rejected under 35 U.S.C. 103 as being unpatentable over Bosshart as applied to claim 1 and 11 above, and further in view of McGhee; David W. et al. US PGPUB 20170093715 A1.
Regarding claim 5. Bosshart teaches The computer-readable medium of claim 1, but it does not teach comprising instructions stored thereon, that if executed by one or more processors, cause the one or more processors to: execute the driver to: apply the instruction set to a packet buffer and mask buffer to generate a modified packet and corresponding mask with locations of packet modifications based on actions specified in the instruction set.
However, McGhee teaches
execute the driver to: apply the instruction set to a packet buffer and mask buffer to generate a modified packet and corresponding mask with locations of packet modifications based on actions specified in the instruction set. ([0029] The match filter 214 also receives a payload mask 216 from the packet parser 116 to indicate which portions of the packet are eligible for masking and can also receive additional control signals 218, for example, from the controller 108. The match filter 214 uses the payload mask 216, if applied, to adjust the match vector 212 based upon bits within the payload mask 216. The parallel data multiplexers 222 then receive the mask control vector 220 and use bits within the mask control vector 220 as control signals to selectively output original packet data held in packet data buffer 224 or mask data held in data buffer 226.)
in order to improve processing speed by using regular expression in packet matching.
Bosshart and McGhee are analogous art in the same field of endeavor of packet switching network communication. It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify the method in Bosshart with the technique of regular express mask filter in McGhee in order to improve processing speed.
Regarding claim 6. Bosshart and McGhee teaches The computer-readable medium of claim 5, Bosshart does not teach wherein the emulation of a parser of the packet processing pipeline is based on the generated modified packet and corresponding mask.
However, McGhee teaches
wherein the emulation of a parser of the packet processing pipeline is based on the generated modified packet and corresponding mask. ([0026] These match vectors are in turned used to generate mask control vectors that are applied to parallel data multiplexers to pass either the original data or mask data that obscures the original data. As such, the output packet data 105 output by the parallel data masking engine 104 includes original data and/or mask data depending upon the results of the match comparisons. The packet processor 106 receives and further processes the output packet data 105 which now can include mask data that obscures data within the original input packet data 103.)
in order to improve processing speed by using regular expression in packet matching.
Bosshart and McGhee are analogous art in the same field of endeavor of packet switching network communication. It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify the method in Bosshart with the technique of regular express mask filter in McGhee in order to improve processing speed.
Claim(s) 8, 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Bosshart as applied to claim 1 and 11 above, and further in view of Daly; Daniel et al. US 20170180273 A1.
= Regarding claim 8. Bosshart teachese The computer-readable medium of claim 1, but it deos not teach wherein the configuration specifies at least one exception case to be processed by a processor.
However, Daly teaches wherein the configuration specifies at least one exception case to be processed by a processor. ([0052] 2) Configure a set of FlowDirector® (Intel® packet steering product) rules that work as exceptions to the RSS default-spreading rule, which places specific flow types and mega flows into specific flows or given specific priorities)
In order to increase agility and lower costs by using software defined networking ([0010])
Bosshart and Daly are analogous art in the same field of endeavor of wireless communication. It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify the method in Bosshart with the technique of exception handling in Daly in order to increase agility and lower costs by using software defined networking.
Regarding claim 16. Booshart teaches The apparatus of claim 11, but it does not teach wherein the configuration is to specify an exception case to be processed by a processor.
However, Daly teaches wherein the configuration specifies at least one exception case to be processed by a processor. ([0052] 2) Configure a set of FlowDirector® (Intel® packet steering product) rules that work as exceptions to the RSS default-spreading rule, which places specific flow types and mega flows into specific flows or given specific priorities)
In order to increase agility and lower costs by using software defined networking ([0010])
Bosshart and Daly are analogous art in the same field of endeavor of wireless communication. It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify the method in Bosshart with the technique of exception handling in Daly in order to increase agility and lower costs by using software defined networking.
Regarding claim 17. Bosshart teaches The apparatus of claim 11, but it does not teach comprising: a server communicatively coupled to the network interface device, wherein the server is to execute the driver.
However, Daly teaches a server communicatively coupled to the network interface device, wherein the server is to execute the driver. ( [0087] In an embodiment, the control device 300 integrated within and/or interfaced to a multi-core processor. In an embodiment, the multicore processor is a server.)
In order to increase agility and lower costs by using software defined networking ([0010])
Bosshart and Daly are analogous art in the same field of endeavor of wireless communication. It would have been obvious before the effective filing date of the claimed invention to a person with ordinary skill in the art to modify the method in Bosshart with the technique of exception handling in Daly in order to increase agility and lower costs by using software defined networking.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHAOHUI YANG whose telephone number is (571)270-7527. The examiner can normally be reached 9 AM to 5 PM M-F.
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, Marcus Smith can be reached at 571 270-1096. 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.
/ZHAOHUI YANG/Examiner, Art Unit 2468
/MARCUS SMITH/Supervisory Patent Examiner, Art Unit 2468