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 .
Claims 15-33 are subject to examination and rejected.
Claim Objections
Claims 15, 20, 26 are objected to because of the following informalities: The recited ACRONYMS such as IP, TCP/IP and CPU must be defined within the claims. Appropriate correction is required.
Specification
The abstract of the disclosure is objected to because the abstract includes a paragraph number, [00153]. Correction is required. See MPEP § 608.01(b).
Drawings
The drawings are objected to because some features of figure 14 are illegible. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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 15 and 26 recite the limitations "… generating a flow-hash lookup key for the packet …”. There is insufficient antecedent basis for this limitation in the claims. The term “the packet” does not have a proper antecedent basis in the referenced claims 15 and 26.
In addition, claims 15 and 26 recite the limitations " … determining an application protocol inspection …” and “… according to application protocol inspection”. There are two ‘application protocol inspection’ within the claims and if these terms ‘application protocol inspection’ refers to the same feature, the later ‘application protocol inspection’ should be treated to show antecedent basis. Appropriate correction is required.
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.
Claims 15-33 are rejected under 35 U.S.C. 103 as being unpatentable over Arisoylu (US PGPub 2013/0297798) in view of Dolganow (US PGPub 2010/0212006).
Regarding claims 15 and 26, Arisoylu teaches a computer-implemented method (Arisoylu, see abstract, A method, in one or more network elements that are in communication between clients that transmit packets and servers, of distributing the packets among the servers which are to process the packets), comprising:
receiving a plurality of IP packets including a set of packets associated with a flow (Arisoylu, see paragraph 0029, The multi-level packet distribution system 100 is coupled, connected, or otherwise in communication with the one or more networks 102 to receive the packets of the flows 105 from the clients 101);
for each packet in the set of packets:
generating a flow-hash lookup key for the packet based on a TCP/IP header of the packet (Arisoylu, see paragraph 0033, a hash function may map attributes of the packet to a group identifier of the selected group. A flow identifier may be generated from the packet (e.g., based on certain fields of the packets header). The flow ID may represent an ID or tag (e.g., a number) that is used to identify a flow); and
updating flow state of the flow using the flow-hash lookup key (Arisoylu, see paragraph 0079, The flow table is only populated when a new flow is accepted for processing by the corresponding server. The exists-on-others flow table corresponding to the added server may be updated with the existing flows for the group prior to making decisions to accept or drop packets. After the exists-on-others flow table has been updated);
grouping the set of packets associated with the flow into a batch (Arisoylu, see paragraph 0033, The static/stateless first level packet distribution module is coupled, connected, or otherwise in communication to provide a flow-to-group distribution of packets 106 to the distributed, stateful second level packet distribution system 107);
performing a stateful processing of the batch (Arisoylu, see paragraph 0034, The distributed, stateful second level packet distribution system 107 includes multiple distributed, stateful second level packet distribution modules 108), including:
accessing the flow state of the batch (Arisoylu, see paragraph 0035, In statefully selecting the server, the server selection module 109 may be operable to access and use the corresponding state 110. In some embodiments, the state may map or assign the flow to the selected server).
Arisoylu teaches the above yet fails to teach determining an application protocol inspection to apply to the batch; for each packet in the batch: decoding a payload of the packet; and performing a deep packet inspection (DPI) processing operation on the payload according to application protocol inspection.
Then Dolganow teaches determining an application protocol inspection to apply to the batch (Dolganow, see paragraph 0032, determine whether the application protocol is a P2P protocol. The specification of the imminent application is silent to define what is an application protocol inspection, so that it is hard to understand about the application protocol inspection. Examiner interprets ‘application protocol inspection’ as a mechanism or algorithm identifying an application protocol applied to the incoming packets);
for each packet in the batch: decoding a payload of the packet (Dolganow, see paragraph 0034, Upon receipt of the packets from DPI A 134, DPI B 136 may perform deep packet inspection to extract a key from one or more packets in the unencrypted flow between a source peer and a destination peer); and
performing a deep packet inspection (DPI) processing operation on the payload according to application protocol inspection (Dolganow, see paragraph 0010, One or more Deep Packet Inspection (DPI) devices may then perform DPI to identify IP flows that use a P2P application protocol and perform further DPI to extract a P2P content key uniquely identifying the P2P content item).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Arisoylu with Two level packet distribution with stateless first level packet distribution to a group of servers and stateful second level packet distribution to a server within the group of Dolganow, because doing so would make Arisoylu more efficient in providing an ability to efficiently handle large numbers of flows and/or the ability to handle a number of flows efficiently without excessive hardware provisioning (Dolganow, see paragraph 0009).
Regarding claims 16 and 27, Arisoylu in view of Dolganow teaches wherein:
the flow state includes flow statistics of the flow (Arisoylu, see paragraph 0036, The servers 112 may perform processing associated with the connections, such as, for example, subscriber management, deep packet inspection, or the like. Alternatively, in other embodiments, the servers 112 may be the connection or flow end points and the servers 112 may provide the full set of content and/or services for the clients); and
the flow state is stored in a hash table (Arisoylu, see paragraph 0033, a hash function may map attributes of the packet to a group identifier of the selected group. A flow identifier may be generated from the packet (e.g., based on certain fields of the packets header). The flow ID may represent an ID or tag (e.g., a number) that is used to identify a flow).
Regarding claim 17, Arisoylu in view of Dolganow teaches wherein the updating of the flow state includes performing transport layer state tracking for the individual groups (Arisoylu, see paragraph 0036, The servers 112 may perform processing associated with the connections, such as, for example, subscriber management, deep packet inspection, or the like. Alternatively, in other embodiments, the servers 112 may be the connection or flow end points and the servers 112 may provide the full set of content and/or services for the clients).
Regarding claim 18, Arisoylu in view of Dolganow teaches wherein the application protocol inspection is performed by a DPI server that executes a DPI engine (Arisoylu, see paragraph 0035, The distributed, stateful second level packet distribution module is coupled, connected, or otherwise in communication to provide flow-to-server distribution or forwarding of packets 111 to the selected servers which may process the packets. The distributed, stateful second level packet distribution module may provide flow-to-server stickiness such that all packets of the flow are distributed to the same server).
Regarding claim 19, Arisoylu in view of Dolganow teaches wherein different batches of packets are stored in different receive queues stored at a network interface device of the DPI server (Arisoylu, see paragraph 0035, The distributed, stateful second level packet distribution module is coupled, connected, or otherwise in communication to provide flow-to-server distribution or forwarding of packets 111 to the selected servers which may process the packets. The distributed, stateful second level packet distribution module may provide flow-to-server stickiness such that all packets of the flow are distributed to the same server).
Regarding claim 20, Arisoylu in view of Dolganow teaches wherein contents of different receive queues are processed by different CPU threads associated with different CPU cores of the DPI server (Arisoylu, see paragraph 0035, The distributed, stateful second level packet distribution module is coupled, connected, or otherwise in communication to provide flow-to-server distribution or forwarding of packets 111 to the selected servers which may process the packets. The distributed, stateful second level packet distribution module may provide flow-to-server stickiness such that all packets of the flow are distributed to the same server).
Regarding claim 21, Arisoylu in view of Dolganow teaches wherein the DPI server implements kernel bypass so that the DPI engine executes in user space to access the different batches directly from user space (Arisoylu, see paragraph 0035, The distributed, stateful second level packet distribution module is coupled, connected, or otherwise in communication to provide flow-to-server distribution or forwarding of packets 111 to the selected servers which may process the packets. The distributed, stateful second level packet distribution module may provide flow-to-server stickiness such that all packets of the flow are distributed to the same server).
Regarding claim 22, Arisoylu in view of Dolganow teaches wherein the DPI engine accesses the different batches via a shared memory ring buffer (Arisoylu, see paragraph 0036, The servers 112 may perform processing associated with the connections, such as, for example, subscriber management, deep packet inspection, or the like. Alternatively, in other embodiments, the servers 112 may be the connection or flow end points and the servers 112 may provide the full set of content and/or services for the clients).
Regarding claim 23, Arisoylu in view of Dolganow teaches wherein the DPI server is connected to a switch port analyzer to receive the IP packets from the switch port analyzer (Arisoylu, see paragraph 0035, The distributed, stateful second level packet distribution module is coupled, connected, or otherwise in communication to provide flow-to-server distribution or forwarding of packets 111 to the selected servers which may process the packets. The distributed, stateful second level packet distribution module may provide flow-to-server stickiness such that all packets of the flow are distributed to the same server).
Regarding claim 24, Arisoylu in view of Dolganow teaches wherein the DPI engine includes one or more compiler optimization that increases an instruction throughput of the DPI engine when same-flow packets are batched (Arisoylu, see paragraph 0035, The distributed, stateful second level packet distribution module is coupled, connected, or otherwise in communication to provide flow-to-server distribution or forwarding of packets 111 to the selected servers which may process the packets. The distributed, stateful second level packet distribution module may provide flow-to-server stickiness such that all packets of the flow are distributed to the same server).
Regarding claim 25, Arisoylu in view of Dolganow teaches wherein the DPI engine includes a loop unrolling optimization (Arisoylu, see paragraph 0033, The static/stateless first level packet distribution module is coupled, connected, or otherwise in communication to provide a flow-to-group distribution of packets 106 to the distributed, stateful second level packet distribution system 107).
Regarding claim 28, Arisoylu in view of Dolganow teaches wherein the DPI server is implemented as part of a port scanning system that scans for open ports on a network (Arisoylu, see paragraph 0033, The static/stateless first level packet distribution module is coupled, connected, or otherwise in communication to provide a flow-to-group distribution of packets 106 to the distributed, stateful second level packet distribution system 107).
Regarding claim 29, Arisoylu in view of Dolganow teaches wherein the DPI server implements one or more anomaly detection algorithms based on analysis of packets (Arisoylu, see paragraph 0033, The static/stateless first level packet distribution module is coupled, connected, or otherwise in communication to provide a flow-to-group distribution of packets 106 to the distributed, stateful second level packet distribution system 107).
Regarding claim 30, Arisoylu in view of Dolganow teaches wherein the DPI server is implemented in a cloud computing environment (Arisoylu, see paragraph 0033, The static/stateless first level packet distribution module is coupled, connected, or otherwise in communication to provide a flow-to-group distribution of packets 106 to the distributed, stateful second level packet distribution system 107).
Regarding claim 31, Arisoylu in view of Dolganow teaches wherein the DPI server is configured to perform a stateless processing operation on the received IP packets (Arisoylu, see paragraph 0032, The multi-level packet distribution system 100, which in this case is a two-level packet distribution system, includes a static and/or stateless first level packet distribution module 103 and a distributed, stateful second level packet distribution system 107), including a timer management bookkeeping operation to:
determine a current time of the batch (Arisoylu, see paragraph 0033, a hash function may map attributes of the packet to a group identifier of the selected group. A flow identifier may be generated from the packet (e.g., based on certain fields of the packets header). The flow ID may represent an ID or tag (e.g., a number) that is used to identify a flow); and
expire flow data associated with the flow-hash lookup keys of the batch if the current time is after a bookkeeping time threshold (Arisoylu, see paragraph 0033, The static/stateless first level packet distribution module is coupled, connected, or otherwise in communication to provide a flow-to-group distribution of packets 106 to the distributed, stateful second level packet distribution system 107).
Regarding claim 32, Arisoylu in view of Dolganow teaches wherein to access the flow state, the DPI server is configured to:
access a hash table using the flow-hash lookup key, wherein the hash table is accessed in parallel using a multi-threaded lookup operation (Arisoylu, see paragraph 0033, a hash function may map attributes of the packet to a group identifier of the selected group. A flow identifier may be generated from the packet (e.g., based on certain fields of the packets header). The flow ID may represent an ID or tag (e.g., a number) that is used to identify a flow).
Regarding claim 33, Arisoylu in view of Dolganow teaches wherein:
the batch of packets is stored in a queue at a network interface device of the DPI server (Arisoylu, see paragraph 0034, The distributed, stateful second level packet distribution system 107 includes multiple distributed, stateful second level packet distribution modules 108); and
the stateful processing accesses the batch from user space using a kernel bypass mechanism (Arisoylu, see paragraph 0034, Each of the distributed, stateful second level packet distribution modules 108 includes a corresponding distributed, stateful second level server selection module 109 and a corresponding state 110. In particular, the second level packet distribution module 1 includes a distributed, stateful second level server selection module 109-1 and a state 110-1, and the Mth second level packet distribution module M includes a distributed, stateful second level server selection module 109-M and a state 110-M).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHONG G KIM whose telephone number is (571)270-0619. The examiner can normally be reached Mon-Fri @ 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, Nicholas R. Taylor can be reached at 571-272-3889. 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.
/CHONG G KIM/Examiner, Art Unit 2443
/NICHOLAS R TAYLOR/Supervisory Patent Examiner, Art Unit 2443