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 .
This office correspondence is in response to the application number 19/025932 filed on January 16, 2025.
Preliminary Amendment
Prior to examination on the merits, Applicant has requested amendments filed on September 25, 2024 to the claims for examination. The amendments are accepted.
Claims 1, 4- 11, 13, and 16 – 20 are amended
Claims 1 – 20 are pending.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
Priority
This application is a continuation of International Application No.PCT/CN2023/103357, filed on June 28, 2023, which claims priority to Chinese Patent Application No. 202210844312.5, filed on July 18, 2022, and Chinese Patent Application No. 202211691427.1 filed on December 27, 2022. The applicant has filed the appropriate documents to establish priority and as such the applicant is entitled to a priority date of July 28, 2022.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 02/12/2025 and 09/17/2025 were filed on or after the mailing date of the application on 01/16/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
35 USC § 101 Analysis
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 – 20 are directed to statutory subject matter and are not rejected under 35 USC 101 because of a judicial exception. The claimed subject matter is integrated into a practical application under Prong 2 of the Step 2A analysis described in MPEP 2016.04(d). The claims are directed to non-abstract improvements in computer related technology. A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception. Instead, the claimed invention is directed to a technological improvement for a packet forwarding system wherein a processor creates a session/flow entry for a packet flow, and a coprocessor later uses that same entry to forward subsequent packets in the flow. When a first packet arrives, the device checks whether a matching flow entry already exists. If it does, the coprocessor forwards the packet using the stored forwarding instructions. If not, the processor creates a new flow entry based on the packet’s flow identification information. The entry can store routing/NAT/other forwarding instructions, plus separate linked information blocks for statistics and control parameters. The system also supports aging: if a flow is idle too long, the coprocessor detects this and reports aging information to the processor for deletion. . A ring storage queue can be used to pass aging records efficiently between coprocessor and processor. The ordered steps of the claim language impose meaningful limits on the scope of the claims and provides a specific improvement for forwarding packets using gateway devices by creating one shared flow table entry on the processor side and the coprocessor directly uses that same flow table to forward later packets of the flow. The flow entry is structured with pointers to separate storage for forwarding data, statistics data, and processor-control data, allowing each side to access only the parts it needs. Aging and deletion are handled cooperatively: the coprocessor detects idle entries and reports aging information to the processor for cleanup. This removes the need for duplicate software and hardware tables. Therein the claims are statutory under 35 USC 101.
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 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 of this title, 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 1 – 6 and 11 - 16 are rejected under 35 U.S.C. 103 as being unpatentable over Janarthanan et al. (U.S. 2015/0146719 A1; herein referred to as Janarthanan) in view of Guo (U.S. 2024/0098023 A1; herein referred to as Guo)
In regard to claim 1, Janarthanan teaches a packet forwarding method (see ¶ [0028] “ . . . A content aware packet processing engine 120 can be used to perform a number of scalable content billing and filtering functionality for postpaid and prepaid services in a communication system 100. The packet processing engine 120 can perform deep packet and high-touch functions on packets received and routed through the packet processing engine 120. For instance, packet processing engine 120 can perform select billing, filtering and QoS capabilities for a mobile network provider. In providing some of these capabilities, the packet processing engine 120 may needs to be able to parse and inspect the contents of the packets. Such parsing, inspection, and processing of packets, while valuable can negatively affect overall performance of the packet processing engine 120 and limit the degree of service packet processing engine 120 can be provide using fixed hardware resources in more traditional configurations. Performance of a packet processing engine 120 can be improved, however, by incorporating selective acceleration functionality, as described herein, allowing portions of data flows in need of deeper parsing and inspection to be processed accordingly, while more straightforward portions of the data flow are accelerated through the packet processing engine according to simpler packet forwarding procedures not requiring the specialized processing capabilities of the packet processing engine 120 . . . “), comprising:
receiving a first packet at a packet forwarding device (e.g. packet processing engine) (see ¶ [0020] “ . . . A content aware packet processing engine 120, such as a network or service gateway, may also be connected to Ethernet backhaul 118 and a mobile data center 121 through one or more intermediate network elements. The mobile data center may include a Multimedia Messaging Service (MMS) 124 and an Internet protocol (IP) Multimedia Subsystem (IMS) 126. A Mobility Management Entity (MME) 128 is also provided for facilitating user interaction, such as tracking user equipment and authenticating users . . .”) .having a processor (e.g. general processor) and a coprocessor (e.g. Network processor) (see ¶ [0015] “ . . . In another general aspect of the subject matter described in this specification can be embodied in systems that include at least one memory element storing data, at least one general processor and at least one network processor. The general processor can be configured to perform a set of deep packet inspection operations on at least one received data flow, and generate an acceleration request for the received data flow, the acceleration request including instructions to accelerate at least a portion of the received data flow by bypassing the general processor. The network processor can be configured to forward frames in received data flows to at least one remote network element according to acceleration requests received from the general processor . . .”) ;
querying a flow table (e.g. table of aggregation records) based on flow identification information (e.g. flow ids) carried in the first packet (see ¶ [0092] “ . . . a flow record of an individual data flow can include an associated statistics record used to track statistical information for the data flow, including tracking measurements of the amount of traffic processed in the flow. In one particular example of an aggregate flow record 800, such as represented in the block diagram of FIG. 8, the aggregate flow record 800 can be referenced by the flow record statistics 810, 815 of one or more flow records 820, 825. In turn, flow records (and flow record statistics) can be also be referenced by the aggregate flow record 800. In such instances, all of the affected flow IDs and aggregate IDs can be tracked as packets are forwarded for a flow when an aggregate session is triggered. A NPU can be tasked with implementing a table of aggregation records, which correlate flows to aggregation sessions. The NPU can also update aggregation records per instructions of the GPU. Further, the NPU can read session status from the aggregate records and initiate deceleration of all related flows upon detecting an aggregate trigger condition. . . .”), wherein
the flow table comprises at least one flow entry (e.g. flow record) (see ¶ [0065]“ . . . a network element, including a GPU and a NPU, receives an inbound packet. The inbound packet can arrive via the NPU. The NPU can perform a lookup for a flow record corresponding to the data flow of the inbound packet. In the event the NPU does not find an existing flow record for the flow, the NPU can forward the packet to the GPU to inspect the packet and establish parameters of the flow as well as any corresponding billing and enforcement policies.. . . “), and the flow entry is a session entry created by the processor(see ¶ [0065] “ . . . The GPU can receive the packet, begin a session corresponding to the data flow and perform acceleration pre-processing to determine whether an opportunity exists to accelerate subsequent packets in the data flow. Acceleration preprocessing can include searching for trailers or sequence numbers associated with the packet and determining whether the session is in a decelerated or accelerated state. Further, a content definition of the packet can be identified and checked to see if this content is configured for acceleration. If the content definition is configured for acceleration and the data flow is in a decelerated state, it can be determined that the data flow is a candidate for acceleration . . . “) based on flow identification information of any received flow (see ¶ [0017] “ . . . A flow record can be generated for the first data flow and statistics of the first data flow can be maintained in the flow record. The flow record can include a temporary flow record maintained by the network processor during an accelerated data flow session. The temporary copy of the flow record can be deleted upon conclusion of the accelerated data flow session. The general processor can process the at least one first frame in connection with at least one of a content billing policy and a content filtering policy of a particular subscriber associated with the first data flow. An acknowledgement message can be sent from the network processor to the general processor in response to the received flow acceleration request. A deceleration request can be received, at the network processor, from the general processor, requesting that at least a next frame in the set of frames be passed to the general processor for processing. An acceleration request can itself include at least one condition for decelerating an accelerated portion of the received data flow, and the network processor configured to identify that the at least one condition has been met and pass processing of at least a subsequent portion of the received data flow to the general processor. The network processor can be configured to initially receive the received data flow, determine that a particular frame in the received data flow is to be processed by a general processor, and forward the particular frame to the general processor . . .”).; and
when a (see ¶ [0099] “ . . . ingress packets received by a NPU can be passed to a lookup engine implemented in connection with the NPU. The lookup engine can be used to match each flow to a flow record. Identifying the ingress packet's corresponding flow path allows the NPU to correctly update the flow statistics of the flow record to account for the amount of data processed in the ingress packet. . . .”), forwarding, by the coprocessor (see ¶ [0098] “ . . . certain data flows can be processed by a GPU and then routed to a NPU for forwarding onto the backplane. In order to identify to the NPU that packets of the non-accelerated data flow belong to a particular aggregate session, the packets can be tagged with aggregate IDs of the aggregate session. In some instances, the NPU can be tasked with updating the aggregate record in accordance with non-accelerated packet routed through the NPU by the GPU. . . .”) , the first packet based on the target flow entry, wherein the target flow entry is a session entry created by the processor based on flow identification information of a first flow to which the first packet belongs (see ¶ [0076] “ . . . Once the NPU receives the acceleration request from the GPU (as appended to the header of the first packet returned from the GPU), the NPU can create a flow record for the flow. A subsequent inbound packet can be received by the NPU for the flow. Before taking complete ownership of the flow, the NPU can check to see that each proceeding packet in the flow made round trip through the network element and out to the backplane. The NPU can tag the packet with a serial number and forward the tagged packet to the GPU. The demultiplexer module can identify the packet and invoke acceleration preprocessing. If the session state is "acceleration pending" the receipt of a packet with an appended serial number can act as an ACK message and the session state is transitioned to "accelerated." Further, in response to receiving the ACK message, a PCI handler can create a session key based on the information in the ACK and invokes a session callback routine ack_accel( ) to find the session block, sees the session is in "accelerated" state and that the response was a successful ACK. The ack_accel( ) function can further set a ACK_ACCEL flag in the session block indicating that full acceleration is on and disabling the idle timer for the session and performing other activities to transition the GPUs record of the flow as needed for an accelerated flow. In acceleration, the NPU can continue to receive and forward packets directly, maintaining byte counts in the flow record and watching for trigger hits that can initiate a deceleration hand-off from the NPU to the GPU. . . .”).
Janarthanan fails to explicitly teach target flow entry. However Guo teaches target flow entry (see ¶ [0014] “ . . . a searching unit to search, in a preset greedy flow table, a target table entry that includes target flow information carried in the first data packet and an identifier of the target port, and the preset greedy flow table stores flow information of a data flow whose traffic is greater than a preset traffic threshold and an identifier of a port that receives a data flow corresponding to the flow information . . .”);
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate systems and methods for processing data packets and placing them according to flow information and setting an aging counter to the packet to monitor congestion flow, as taught by Guo, into system and methods for processing a plurality of frames and setting up flow control for the packet forwarding, as taught by Janarthanan. Such incorporation provides a means to delete packets if they age out before being forwarded to the destination.
In regard to claim 2, the combination of Janarthanan and Guo teaches wherein when the target flow entry does not exist in the flow table, the flow identification information carried in the first packet is used by the processor to create the target flow entry (see Janarthanan ¶ [0091] “ . . . In instances where the data flow will be the first data flow in the aggregate session, the GPU can create the corresponding aggregate flow record and generate an aggregate ID corresponding to the aggregate session. In addition, if the GPU, during high-level processing of the first data flow, has been responsible for forwarding some of the packets in the first data flow, the GPU can generate or update the aggregate flow record according to the amount of traffic processed by the GPU (e.g., at 730) prior to handing over control of the flow to the NPU (e.g., 720). . . .”)
In regard to claim 3,the combination of Janarthanan and Guo teaches wherein the coprocessor is a network processor (NP), and the processor is a central processing unit (CPU) or an application processor (AP) (e.g. general processor) (see Janarthanan ¶ [0031] “ . . . Network element 205 can utilize the NPUs 225a-b to offload handling of portions of some flows from the GPUs 235a-b. A network processor 225a-b can implement a limited set of counting primitives and a number of trigger conditions that can be associated with each flow handled by the network element 205. For instance, if a trigger condition is met for a particular flow, packets for that flow can be dispatched to a GPU (e.g., 235a-b) via in-band communication paths with an appended message (or if no packets are currently flowing via an out-of-band communication path), the message summarizing the counters and conditions of that flow as noted by the NPU 225a-b, as well as trigger conditions that caused the message to be generated. Packets in a data flow can be processed by the GPU 235a-b, for example, for deep-packet processing in connection with billing, policy control, authentication, or other features provided, at least in part, through the network element 205. For instance, the NPU can transfer control of a flow to a GPU 235a-b so it can process portions of a particular data flow to make sure that a given session is being accounted for by the general-purpose processor 235a-b before any important accounting or billing event takes place. Upon accounting for the session, the remainder, or a portion, of the flow can be entrusted solely to the network processor 225a-b for packet counting and forwarding on to other network nodes. If the GPU cannot identify a section of the flow that can be "accelerated" before the end of the data flow, such as a sequence of packets that could be subjected to simplified accounting rules, processing of the packets can include forwarding of all packets in the flow to the general-purpose processor 235a-b and the particular flow session will not be "accelerated," by delegating processing of the flow to the network processor (e.g., 225a-b). . . .”)
In regard to claim 4, the combination of Janarthanan and Guo teaches further comprising:
determining, using the coprocessor, that aging needs to be performed on the target flow entry (see Guo ¶ [0241] “ . . . The following processing is performed for each register that meets the conditions: [0242] taking out corresponding table entry information according to the index of the register in the lookup table, querying CGFT, the table entry information being table entry information of the GF; querying GFT according to the table entry information of the GF in the CGFT; setting, if the table entry information of the GF is existed in GFT, an aging count corresponding to the table entry information of the GF to a maximum value ff, and setting an active value of the table entry information of the GF to the maximum value; otherwise, adding the table entry information of the GF to the GFT, and setting the aging count to the maximum value ff, and setting the active value of the table entry information of the GF to the maximum value. . . .”); and
reporting, using the coprocessor, aging information of the target flow entry to the processor (see Guo ¶ [0262] “ . . . forwarding the CNP to a source server address carried in the data flow, and resetting the aging count of the flow information table entry to the maximum value . . .”),
wherein the aging information of the target flow entry indicates the processor to perform deletion processing (e.g. discard the data packet) on the target flow entry (see Guo ¶ [0266] “ . . . the core module can also implement monitoring of ECN data packets. In this case, after the core module sets its physical state to the monitoring state, it can perform the following blocks: [0267] 1) monitoring whether an ECN data packet is received. If yes, executing block 2); if not, executing block 1) circularly. [0268] 2) taking out flow information from the ECN data packet, and using the flow information to query GFT. Executing, if the flow information table entry is queried, block 3); executing, if the flow information table entry is not queried, block 7). [0269] 3): subtracting 1 from the active value of the flow information table entry in the GFT, and then executing block 4). [0270] 4): detecting whether the active value of the flow information table entry in the GFT is 0. If yes, executing block 5); if not, executing block 6). [0271] 5): deleting the flow information table entry in the GFT. Then, executing block 6). 6) constructing CNP, and then executing block 8). [0272] 7) removing the congestion mark. For example, removing ECN mark, and then executing block 8). [0273] 8) querying the forwarding table. executing, if the query is successful, block 9); otherwise, executing block 10). [0274] 9) forwarding the data packet to a source server address carried in the data flow, and resetting the aging count of the flow information table entry to the maximum value ff. [0275] 10) otherwise, discarding the data packet. . . .”).
The motivation to combine Guo with Janarthanan is described for the rejection of claim 1 and is incorporated herein. Additionally, Guo teaches a means of looking for aged or stale packets to delete and not forward.
In regard to claim 5, the combination of Janarthanan and Guo teaches wherein the determining that aging needs to be performed on the target flow entry comprises: polling the flow entry in the flow table using the coprocessor, to determine whether a second packet is received within aging duration (see Guo ¶ [0576] “ . . . the processing unit 263 is specifically to: [0576] if the first data packet is a CNP, remove, if the target flow information is included in a forwarding table, the identifier of the target port carried in the first data packet; forward the first data packet with the identifier of the target port removed, and reset an aging count of the target table entry to an initial aging number; otherwise, discard the first data packet; or, remove, if target flow information is included in the forwarding table, the identifier of the target port carried in the second data packet; forward the second data packet with the identifier of the target port removed; otherwise, discarding the second data packet . . .”), wherein the second packet carries flow identification information matching the target flow entry (see Guo ¶ [0577] “ . . the processing unit 263 is specifically to: [0578] if the first data packet is an ECN data packet, forward, if target flow information is included in the forwarding table, the CNP corresponding to the first data packet; and reset an aging count of the target table entry to an initial aging number; otherwise, discard the first data packet; or, remove, if target flow information is included in the forwarding table, the identifier of the target port carried in the second data packet; forward the second data packet with the identifier of the target port removed; otherwise, discard the second data packet. . . . “); and
when determining that no second packet is received within the aging duration, determining that the aging needs to be performed on the target flow entry (see Guo ¶ [0636] “ . . . resetting the aging count of the target table entry to the initial aging number; otherwise, discarding the first data packet . . . “).
The motivation to combine Guo with Janarthanan is described for the rejection of claim 1 and is incorporated herein. Additionally, Guo manipulates the aging measurements depending on the flow environment..
In regard to claim 6, the combination of Janarthanan and Guo teaches wherein the packet forwarding device comprises a memory that includes a ring storage queue (see Guo ¶ [0350] “ . . . The statistic of each data flow is achieved by using 4 registers to form a circular queue; and, as time changes, the register resources can be naturally released. . . .”) , the ring storage queue comprises a plurality of storage units distributed in a ring, one storage unit in the ring storage queue is configured to store aging information of one flow entry (see ¶¶ [0351-0353] “ . . . the capture granularity (i.e., the calculation period) is about 1 ms, and the statistical window is moved with a period of about 0.25 ms, which achieves the precision that the control plane cannot achieve. The technical solutions provided by the examples of the present disclosure can identify the elephant flow when congestion occurs (including the elephant flow in the micro-burst), and perform precise congestion control on the elephant flow that causes the congestion, so as to slow down the micro-burst, which plays an important role in improving the transmission quality of lossless network. 7. Each time CGF information is collected, CGFT will be emptied, but GFT will not be emptied. Instead, the table entries in GFT will be naturally aged, and the GFT will be refreshed when new GF information is collected; if the CNP of a GF is not received for 256 consecutive seconds and the GF is not recognized as GF again, the table entry of the GF in the GFT will be deleted; 8. The aging count of GFT is used for controlling the existence time of GF entries; the active value is used for controlling the number of times the data flow is regulated. To avoid excessive regulation of GF, the active value can be set to a small number, such as 3 or 4. Each time GF is regulated, the active value of the GF table entry is reduced by 1, and after the active value of the GF table entry is reduced to 0, the GF table entry is deleted. . . .”) , the processor is configured to read aging information stored in a storage unit to which a read pointer points in the ring storage queue (see Janarthanan ¶ [0089] “ . . . Direct references or links can be provided in both directions (e.g., using pointers, indexes, handles, etc.). Accelerated flows can have their volume (or flow time) accounted for on the NPU handling the flow. Non-accelerated flows can have their volume accounted for on the GPU involved with processing the non-accelerated flow. Aggregate records on the NPU allow the system to accelerate flows that belong to an aggregate object, while still allowing for GPUs to properly account for aggregate volumes. Such a design can ensure that there are no accelerated flows on an aggregate session when a policy event occurs, such as billing-related event . . .”) , and the reporting the aging information of the target flow entry to the processor comprises: writing, using the coprocessor, the aging information of the target flow entry into a storage unit to which a write pointer points in the ring storage queue, wherein the write pointer is used to point to an empty storage unit in the ring storage queue (see Janarthanan ¶ [0075] “ . . . various software modules, tools, and functions can be provided in connection with a GPU for use in preprocessing a data flow, determining whether the data flow is a candidate for acceleration, and configuring an accelerated flow state. For instance, a demultiplexer module can be provided to invoke normal session services/protocol handler code, or other logic or software modules (e.g., for L4-L7 handling) to process inbound packet. A check_acceleration( ) function can be called to check the state of the session to see if this session can be accelerated. A get_trigger( ) function can be called which allocates storage for an acceleration data object corresponding to an accelerated session. The get_trigger( ) function can further fill a trigger block of the acceleration object with corresponding acceleration rules, conditions, and trigger values. For instance, the get_trigger( ) function can calculate triggers for a particular flow, including, as examples, building a buffer into the trigger to ensure that packets are decelerated in advance of a particular event corresponding to the trigger, implementing and following pre-defined parameters for an acceleration, such as minimum and/or maximum thresholds for the flow acceleration, among other considerations and criteria. Further, a start_session( ) function can be invoked to call a platform API to retrieve a header to append to the packet. The start_session( ) function can fill-in the information in the header in connection with an acceleration request/authorization communicated to the NPU. The header can include the trigger values and other rules and conditions for the acceleration. The start_session( ) function can further change the session state to "acceleration pending," pending acceptance of the NPU. Further, during pre-acceleration processing, until an accelerated session is handed-off to the NPU, the GPU and related modules can be responsible for monitoring triggers for the flow (e.g., where multiple packets are received in the flow prior to the acceleration request being accepted by the NPU). . . .”).
The motivation to combine Guo with Janarthanan is described for the rejection of claim 1 and is incorporated herein. Additionally, Guo provides a circular queue for storing aging packets.
In regard to claim 11, Janarthanan teaches a packet forwarding device(e.g. packet processing engine) (see ¶ [0020] “ . . . A content aware packet processing engine 120, such as a network or service gateway, may also be connected to Ethernet backhaul 118 and a mobile data center 121 through one or more intermediate network elements. The mobile data center may include a Multimedia Messaging Service (MMS) 124 and an Internet protocol (IP) Multimedia Subsystem (IMS) 126. A Mobility Management Entity (MME) 128 is also provided for facilitating user interaction, such as tracking user equipment and authenticating users . . .”) , comprising:
a memory storing instructions (see ¶ [0108] “ . . . a memory element (as shown in FIG. 2) can store data used for the operations described herein. This includes the memory element being able to store software, logic, code, or processor instructions that can be executed to carry out the activities described in this Specification. . . .”);
at least one processor in communication with the memory, the at least one processor configured, upon execution of the instructions (see ¶ [0108] “ . . . A processor can execute any type of instructions associated with the data to achieve the operations detailed herein in this Specification. In one example, the processor (as shown in FIG. 2) could transform an element or an article (e.g., data) from one state or thing to another state or thing. In another example, the activities outlined herein may be implemented with fixed logic or programmable logic (e.g., software/computer instructions executed by a processor) and the elements identified herein could be some type of a programmable processor, programmable digital logic (e.g., a field programmable gate array (FPGA), an erasable programmable read only memory (EPROM), an electrically erasable programmable ROM (EEPROM)) or an ASIC that includes digital logic, software, code, electronic instructions, or any suitable combination thereof. . . .”), to create a flow entry based on flow identification information of any flow received by the packet forwarding device, wherein the flow entry indicates the coprocessor to forward a packet(see ¶ [0028] “ . . . A content aware packet processing engine 120 can be used to perform a number of scalable content billing and filtering functionality for postpaid and prepaid services in a communication system 100. The packet processing engine 120 can perform deep packet and high-touch functions on packets received and routed through the packet processing engine 120. For instance, packet processing engine 120 can perform select billing, filtering and QoS capabilities for a mobile network provider. In providing some of these capabilities, the packet processing engine 120 may needs to be able to parse and inspect the contents of the packets. Such parsing, inspection, and processing of packets, while valuable can negatively affect overall performance of the packet processing engine 120 and limit the degree of service packet processing engine 120 can be provide using fixed hardware resources in more traditional configurations. Performance of a packet processing engine 120 can be improved, however, by incorporating selective acceleration functionality, as described herein, allowing portions of data flows in need of deeper parsing and inspection to be processed accordingly, while more straightforward portions of the data flow are accelerated through the packet processing engine according to simpler packet forwarding procedures not requiring the specialized processing capabilities of the packet processing engine 120 . . . “) ; and
a coprocessor in communication with the memory, the coprocessor configured, upon execution of the instructions, to(e.g. Network processor) (see ¶ [0015] “ . . . In another general aspect of the subject matter described in this specification can be embodied in systems that include at least one memory element storing data, at least one general processor and at least one network processor. The general processor can be configured to perform a set of deep packet inspection operations on at least one received data flow, and generate an acceleration request for the received data flow, the acceleration request including instructions to accelerate at least a portion of the received data flow by bypassing the general processor. The network processor can be configured to forward frames in received data flows to at least one remote network element according to acceleration requests received from the general processor . . .”) :
receive a first packet (see ¶ [0014] “ . . . the actions of receiving at least one first frame of a first data flow and passing the at least one first frame to a general processor to inspect the at least one first frame. A flow acceleration request can be received including a set of conditions for accelerated processing, by the network processor, of a set of frames in the first data flow subsequent to the at least one first frame. At least one subsequent frame in the set of frames can be processed, using the network processor, in connection with forwarding of the subsequent frame to at least one remote network node, where processing of the subsequent frame is accelerated relative to processing of the at least one first frame and based, at least in part, on the set of conditions. . . .”);
query a flow table (e.g. table of aggregation records) based on flow identification information (e.g. flow ids) carried in the first packet (see ¶ [0092] as described for the rejection of claim 1 and is incorporated herein) , wherein the flow table comprises at least one flow entry (e.g. flow record) (see ¶ [0065] as described for the rejection of claim 1 and is incorporated herein) , and the flow entry is a session entry created by the at least one processor(see ¶ [0065] as described for the rejection of claim 1 and is incorporated herein) based on flow identification information of any received flow (see ¶ [0017] as described for the rejection of claim 1 and is incorporated herein) ; and
forward the first packet based on a(see ¶ ¶ [0098-0099] as described for the rejection of claim 1 and is incorporated herein) , wherein the target flow entry is a session entry created by the at least one processor based on flow identification information of a first flow to which the first packet belongs (see ¶ [0076] as described for the rejection of claim 1 and is incorporated herein).
Janarthanan fails to explicitly teach target flow entry. However Guo teaches target flow entry (see ¶ [0014] as described for the rejection of claim 1 and is incorporated herein).
The motivation to combine Guo with Janarthanan is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 12, the combination of Janarthanan and Guo teaches wherein when the target flow entry does not exist in the flow table, the flow identification information carried in the first packet is used by the at least one processor to create the target flow entry (see Janarthanan ¶ [0091] as described for the rejection of claim 2 and is incorporated herein).
In regard to claim 13, the combination of Janarthanan and Guo teaches wherein the coprocessor is a network processor (NP), and the at least one processor is a central processing unit (CPU) or an application processor (AP) (e.g. general processor) (see Janarthanan ¶ [0031] as described for the rejection of claim 3 and is incorporated herein).
In regard to claim 14, the combination of Janarthanan and Guo teaches wherein the instructions when executed by the coprocessor further cause the coprocessor to:
determine that aging needs to be performed on the target flow entry (see Guo ¶ [0241] as described for the rejection of claim 4 and is incorporated herein) , and
report aging information of the target flow entry to the at least one processor(see Guo ¶ [0262] as described for the rejection of claim 4 and is incorporated herein) , wherein the aging information of the target flow entry indicates the at least one processor to perform deletion processing (e.g. discard the data packet) on the target flow entry (see Guo ¶ [0266] as described for the rejection of claim 4 and is incorporated herein).
The motivation to combine Guo with Janarthanan is described for the rejection of claim 4 and is incorporated herein.
In regard to claim 15, the combination of Janarthanan and Guo teaches wherein the instructions when executed by the coprocessor further cause the coprocessor to:
poll the flow entry in the flow table, to determine whether a second packet is received within aging duration (see Guo ¶ [0576] as described for the rejection of claim 5 and is incorporated herein) , wherein the second packet carries flow identification information matching the target flow entry (see Guo ¶ [0577] as described for the rejection of claim 5 and is incorporated herein); and
when determining that no second packet is received within the aging duration, determine that the aging needs to be performed on the target flow entry (see Guo ¶ [0636] as described for the rejection of claim 5 and is incorporated herein).
The motivation to combine Guo with Janarthanan is described for the rejection of claim 5 and is incorporated herein.
In regard to claim 16, the combination of Janarthanan and Guo teaches wherein the memory comprises a ring storage queue (see Guo ¶ [0350] as described for the rejection of claim 6 and is incorporated herein), the ring storage queue comprises a plurality of storage units distributed in a ring, one storage unit in the ring storage queue is configured to store aging information of one flow entry (see Guo ¶¶ [0351-0353] as described for the rejection of claim 6 and is incorporated herein) , and the processor is configured to read aging information stored in a storage unit to which a read pointer points in the ring storage queue (see Janarthanan ¶ [0089] as described for the rejection of claim 6 and is incorporated herein); and
the instructions when executed by the coprocessor further cause the coprocessor to:
write the aging information of the target flow entry into a storage unit to which a write pointer points in the ring storage queue, wherein the write pointer is used to point to an empty storage unit in the ring storage queue (see Janarthanan ¶ [0075] as described for the rejection of claim 6 and is incorporated herein);
The motivation to combine Guo with Janarthanan is described for the rejection of claim 6 and is incorporated herein.
Claims 7 – 10 and 17 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Janarthanan et al. (U.S. 2015/0146719 A1; herein referred to as Janarthanan) in view of Guo (U.S. 2024/0098023 A1; herein referred to as Guo) as applied to claim 1 -6 and 11 - 16 in further view of Caram (U.S. 2011/0296002 A1; herein referred to as Caram).
In regard to claim 7, the combination of Janarthanan, Guo, and Caram teaches wherein the target flow entry comprises a first pointer pointing to storage space for storing first information, the first information comprises the flow identification information of the first flow and forwarding information of the first flow (see Caram ¶ ¶ [0031-0033] “ . . Entries in the flow record memories 124 are organized as a hash table, based on a hash of the flow key. The entries also contain the corresponding flow key 144 along with the flow data 146 corresponding to the flow as well as associated flow information table identifier (FIT number) 142 . The flow data field 146 stores the information generated by the packet inspection systems 1055, 105U from the monitoring of the flow. Typically, the flow data includes information on the packet payloads contained in the packets of the flow, whether the flows are encrypted, TCP flags, and packet counts. It also contains pointers to rate limits and other actions that are to be applied to the flows. FIG. 3 illustrates the construction of the flow information table memories 122 maintained by both of the flow systems 118S, 118U. Entries in this table are indexed by the FIT number 142 and each contains the state of the FIT number: the FIT state 152. This is a variable that identifies the state of the flow information entry. In general, the FIT state 152 indicates the ownership of the entry among the packet inspection subsystems 105S, 105U and also the state of the entry such as whether it is cached by one of the packet inspection subsystems 1055, 105U. . . .”), and the forwarding information of the first flow indicates a forwarding type and/or a forwarding action of the first flow (see Caram ¶ [0040] “ . . . packet processing thread 125 of the flow system 118 allocates a FIT from the flow information table Stocker Ring and creates a flow that is stored in the flow record memory 124 in step 218. In step 220, the new record is populated with the statistics associated with this flow. By default, all new flows are classified according to their well-known port number (e.g. TCP port 80=HTTP). This classification is updated by the packet processing threads 125 based on the results of the deep packet inspection systems 120 processing of the flow. The flow key field 144 updated with the calculated flow key. A new flow identifier or FIT number is assigned to the flow and entered into the FIT number field 142. Finally, according to the invention a FIT state for the corresponding FIT number is updated in the flow information table memory 122. . . .”).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate systems and methods for packet inspection systems for storing flow entries that includes a flow key characterizing a packet flow associated with flow entry, and a flow identifier. State information is further maintained indicating ownership of the flow identifiers, as taught by Caram, into system and methods for processing a plurality of frames and setting up flow control for the packet forwarding, placing them according to flow information and setting an aging counter to the packet to monitor congestion flow, as taught by the combination of Janarthanan and Guo. Such incorporation enables processing certain flows by a priority.
In regard to claim 8, the combination of Janarthanan, Guo, and Caram teaches wherein the first information further comprises a second pointer, pointing to storage space for storing second information (see Caram Fig. 3, ¶¶ [0032-0033] “ . . . FIG. 3 illustrates the construction of the flow information table memories 122 maintained by both of the flow systems 118S, 118U. Entries in this table are indexed by the FIT number 142 and each contains the state of the FIT number: the FIT state 152. This is a variable that identifies the state of the flow information entry. In general, the FIT state 152 indicates the ownership of the entry among the packet inspection subsystems 105S, 105U and also the state of the entry such as whether it is cached by one of the packet inspection subsystems 1055, 105U, . . .”) the second information comprises association data of a newly received packet in the first flow, the association data comprises data for collecting statistics on flow information of the first flow (see Caram Fig. 3, ¶¶ [0034-0035] “ . . . FIG. 4 illustrates the processing threads that are executed by the flow systems 1185, 118U to process the packets and allocate FIT numbers to the flows. In more detail, a free list 154 is maintained by the secure flow system 118S functioning as the master. In one example, the free list 154 contains flow identifiers (FIT numbers) 142, in an ordered linked list, that are currently not assigned to any active flow. In one implementation, the flow identifiers 142 are numbered between one and 16 million and the freelist is characterized by a local head that starts with FIT number (1) or the lowest valued free FIT number. The remote head of the freelist 154 starts with FIT number (16 million) or the highest valued free FIT number . . .”), the flow information is used to locate an exception when the exception occurs during transmission of the first flow (see Caram ¶ [0036] “ . . . Multiple packet processing threads 125 execute in parallel to analyze each of the packets that are received by the corresponding flow system 118. When a new packet is received, it is assigned to a packet processing thread 125, which then takes appropriate action such as determining whether the new packet is part of an existing flow in flow record memory 1245,124U, creating a new packet flow if required, and updating the information associated with that packet flow if an associated flow is present in the flow record memory 124 such as by incrementing a packet count. On the other hand, when a packet is received that is not part of an existing flow, the assigned packet processing thread designates a free FIT number and creates a flow in flow record memory 124. . . .”) , and when the target flow entry matching the flow identification information carried in the first packet exists in the flow table (see Caram ¶ [0038] “ . . . a new packet is received. In step 212, the receiving packet processing thread 125 derives the flow key for the packet. This is calculated from the packet's public network IP address, secure network IP address, public network TCP/UDP port, secure network TCP/UDP port, and protocol. The packet processing thread 125 then looks for a matching flow key in its flow record memory 124S,124U via a hashing of the flow key. In step 214, it determines whether a matching record exists. . . .”), the method further comprises: updating the second information using the coprocessor, wherein updated second information comprises association data of the first packet (see Caram ¶ [0039] “ . . . the record is updated with the information from the new packet. Typically, the rate limit for the flow is checked, and the counter associated with the number of bytes in the flow is incremented in the corresponding record in the flow record memory 124. If required, the packet, in some examples, is then further passed to the associated deep packet inspection systems 120 for signature detection and/or content inspection for further analysis to determine whether the packet complies with or violates established network security policies . . .”).
The motivation to combine Caram with the combination of Janarthanan and Guo is described for the rejection of claim 7 and is incorporated herein. Additionally Caram associates a packet to a specific flow.
In regard to claim 9, the combination of Janarthanan, Guo, and Caram teaches wherein the first information further comprises a third pointer, pointing to storage space for storing third information comprising a control parameter of a process for processing the first flow in the processor (see Caram Fig. 4 ¶¶ [0042-0043] “ . . . flow systems 118 pull new FIT numbers 142 for new flows from a common pool, or freelist 154. The freelist 154 contains FIT numbers that are currently not assigned to the FIT number for any active flow, and the freelist 154 is maintained by the secure flow system 118S. The single freelist 154 for both flow systems 118S, 118U is required because each flow must be assigned a unique FIT number regardless of which flow system 118S, 118U creates the flow table entry. Packet processing threads 125, in one implementation, acquire and free new FIT numbers using two caches, a stocker ring 310 and a return ring 312. These caches are maintained by each of the flow systems 118S, 118U as separate processing threads. . . .”)
The motivation to combine Caram with the combination of Janarthanan and Guo is described for the rejection of claim 7 and is incorporated herein. Additionally Caram provides specifics for creating a flow control entry.
In regard to claim 10, the combination of Janarthanan, Guo, and Caram teaches wherein the flow entry in the flow table is stored in preset storage space, and wherein first information, second information, and the third information are stored in storage space that the processor applies for from an address pool when the target flow entry is created (see Caram Fig. 4 ¶¶ [0044-0048] “ . . . The stocker ring 310 and the return ring 312 respectively pull/push FIT numbers from/to different ends of the freelist 154 depending on the flows system on which they are executing. In the illustrated embodiment, the stocker ring 310 and a return ring 312 of the secure flow system 118S pull/push free FIT numbers from/to the local head of the freelist 154, and the stocker ring 310 and a return ring 312 of the unsecure flow system 118U pull/push free FIT numbers from/to the remote head of the freelist 154. Each stocker thread 310 maintains the associated stocker ring for the corresponding flow system 118. The stocker thread 310 insurers that the stocker ring contains a block of free FIT numbers. As each of the packet processing threads requires new FIT numbers, the packet processing threads 125 acquire the new FIT numbers from the stocker ring 310. The stocker 310 on the secure and unsecure flow systems 118S, 118U behave somewhat differently, however. The secure flow system 118S has direct access to the freelist 154. The unsecure flow system 118U needs to send messages when it needs another block of free FIT numbers, or when the limits of the stocker and/or return ring caches 310, 312 have been met, and excess FIT number need to be put back on the freelist 154. Somewhat similarly, return ring threads 312 for each of the flow systems 118S, 118U maintain return ring caches that receive discarded FIT numbers. Typically FIT numbers are discarded when the flow has been terminated, such as receipt of a TCP FIN or RST packet, or the flow has been removed from the flow memory by operation of an ager thread when no new packet have been detected for the flow for a predetermined time period. These discarded FIT numbers are held on the return rings 312. From the return ring, the free FIT numbers are either returned to the freelist 154 or given to the stocker ring 310. Using a combination of the stocker ring 310 and the return ring 312 for each of the flow systems 118S, 118U, free flow identifiers are cached locally in each of the flow systems 118S, 118U so that they can be quickly distributed as required by the packet processing threads 125.
The motivation to combine Caram with the combination of Janarthanan and Guo is described for the rejection of claim 7 and is incorporated herein. Additionally Caram provides an address pool using an architecture of two rings for distribution of packets.
In regard to claim 17, the combination of Janarthanan, Guo, and Caram teaches wherein the target flow entry comprises a first pointer, pointing to storage space for storing first information, the first information comprises the flow identification information of the first flow and forwarding information of the first flow (see Caram ¶ ¶ [0031-0033] as described for the rejection of claim 7 and is incorporated herein), and the forwarding information of the first flow indicates a forwarding type and/or a forwarding action of the first flow (see Caram ¶ [0040] as described for the rejection of claim 7 and is incorporated herein).
The motivation to combine Caram with the combination of Janarthanan and Guo is described for the rejection of claim 7 and is incorporated herein..
In regard to claim 18, the combination of Janarthanan, Guo, and Caram teaches wherein the first information further comprises a second pointer, pointing to storage space for storing second information (see Caram Fig. 3, ¶¶ [0032-0033] as described for the rejection of claim 8 and is incorporated herein) , the second information comprises association data of a newly received packet in the first flow, the association data comprises data for collecting statistics on flow information of the first flow (see Caram Fig. 3, ¶¶ [0034-0035] as described for the rejection of claim 8 and is incorporated herein), the flow information is used to locate an exception when the exception occurs during transmission of the first flow (see Caram ¶ [0036] as described for the rejection of claim 8 and is incorporated herein), and the instructions when executed by the coprocessor further cause the coprocessor to: when the target flow entry matching the flow identification information carried in the first packet exists in the flow table (see Caram ¶ [0038] as described for the rejection of claim 8 and is incorporated herein], update the second information, wherein updated second information comprises association data of the first packet (see Caram ¶ [0039] as described for the rejection of claim 8 and is incorporated herein).
The motivation to combine Caram with the combination of Janarthanan and Guo is described for the rejection of claim 8 and is incorporated herein.
In regard to claim 19, the combination of Janarthanan, Guo, and Caram teaches wherein the first information further comprises a third pointer, pointing to storage space for storing third information, comprising a control parameter of a process for processing the first flow in the at least one processor (see Caram Fig. 4 ¶¶ [0042-0043] as described for the rejection of claim 9 and is incorporated herein).
The motivation to combine Caram with the combination of Janarthanan and Guo is described for the rejection of claim 9 and is incorporated herein.
In regard to claim 20, the combination of Janarthanan, Guo, and Caram teaches wherein the flow entry in the flow table is stored in preset storage space, and wherein the first information, the second information, and the third information are stored in storage space that the at least one processor applies for from an address pool when the target flow entry is created (see Caram Fig. 4 ¶¶ [0044-0048] as described for the rejection of claim 10 and is incorporated herein).
The motivation to combine Caram with the combination of Janarthanan and Guo is described for the rejection of claim 10 and is incorporated herein.
Conclusion
There are prior art made of record which are not relied upon but are considered pertinent to applicant’s disclosure. They are listed on the PTO-892 accompanying this action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES N FIORILLO whose telephone number is (571)272-9909. The examiner can normally be reached on 7:30 - 5 PM Mon - Fri..
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, John A. Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAMES N FIORILLO/Primary Examiner, Art Unit 2444
Prosecution Insights