Prosecution Insights
Last updated: July 05, 2026
Application No. 18/345,411

VECTOR-BASED PACKET PROCESSING METHOD AND APPARATUS IN USER PLANE FUNCTION

Final Rejection §103
Filed
Jun 30, 2023
Priority
Jan 04, 2021 — RE 10-2021-0000443 +1 more
Examiner
AKBARI, FARAZ TIMA
Art Unit
2196
Tech Center
2100 — Computer Architecture & Software
Assignee
Samsung Electronics Co., Ltd.
OA Round
2 (Final)
0%
Grant Probability
At Risk
3-4
OA Rounds
4m
Est. Remaining
0%
With Interview

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 4 resolved
-55.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 5m
Avg Prosecution
26 currently pending
Career history
42
Total Applications
across all art units

Statute-Specific Performance

§103
99.3%
+59.3% vs TC avg
§112
0.7%
-39.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 4 resolved cases

Office Action

§103
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 action is in response to the amendment filed 02/26/2026. By the amendment, Claims 1-2, 4-7, and 9-15 have been amended. Claims 1-15 are pending. Priority Applicant’s claim for priority from foreign application no. KR10-2021-0000443 filed 01/04/2021 is acknowledged. 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 1-15 are rejected under 35 U.S.C. 103 as being unpatentable over Goel et al. (US 20190289102 A1) in view of Kutch (US 20200348973 A1), hereinafter referred to as Goel and Kutch, respectively. Regarding Claim 1, Goel discloses A packet processing control apparatus configured to control packet processing, the packet processing control apparatus ([0005] Aspects of this disclosure describes techniques for parsing network packets, processing network packets, and modifying network packets before forwarding the modified network packets over a network.; [0154] The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses. Please note the apparatus implementing the disclosure, which describes techniques for processing network packets, corresponds to Applicant’s packet processing control apparatus.) comprising: at least one processor comprising processing circuitry; and memory storing instructions, wherein the instructions, when executed by the at least one processor, cause the packet processing control apparatus ([0151] Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. Please note that data storage media that contains instructions corresponds to Applicant’s memory storing instructions, and being accessed by processors for implementing the described techniques, corresponding to Applicant’s processor comprising processing circuitry, which executes the instructions to cause the packet processing control apparatus to carry out the operations.) to: analyze, for each of a plurality of packet processing pipelines, a pipeline processing state in which packets are processed ([0007] aspects of one or more systems described herein may further enable high speed yet flexible parsing of multiple types of network packets in an efficient manner. For instance, in some examples, multiple parsing devices may be used in parallel.; [0070] Later blocks (e.g., forwarding pipeline 440) may use the template to interpret parsed result vector 421 and perform operations based on the contents of parsed result vector 421; [0079] Sequence machine 513 determines a new state and determines which bytes within packet byte vector 504 to parse. Please note that the Sequence machine 513 computing a new parser state corresponds to analyzing a pipeline processing state in which packets are processed for each of a plurality of packet processing pipelines. Additionally, the systems enabling flexible parsing of multiple types of network packets, wherein multiple parsing devices may be used in parallel, to provide parsed result vectors 421 as part of respective forwarding pipelines 440, corresponds to Applicant’s plurality of packet processing pipelines.), determine, for each of the plurality of packet processing pipelines, a packet vector size based on a result of the analyzing ([0079] Sequence machine 513 determines a new state and determines which bytes within packet byte vector 504 to parse. For instance, in the example of FIG. 5A, sequence memory 512 outputs to sequence machine 513 information at the addresses identified by content-addressable memory 508; [0082] The amount of time required for parser 420 to compute a new parser state may be, in the example shown, the amount of time that it takes to (1) perform a lookup within content-addressable memory 508, (2) read sequence memory 512, and (3) compute the new state based on the information read from sequence memory 512. Since a limited amount of data at a time from packet byte vector 504 is processed in one state, the speed of parser 420 is limited by the speed in which a new parser state can be computed. Please note that the Sequence machine 513 computing a new parser state and which bytes within packet byte vector 504 to parse dependent on the amount of data at a time processed from packet byte vector 504 in one state corresponds to determining a packet vector size for each of the plurality of packet processing pipelines based on a result of the analyzing, as the state is dependent on the size of the vector (the amount of bytes) to be processed since it affects the processing speed of parser 420. Therefore, the size of the packet must be determined as part of determining which bytes to parse within packet byte vector 504.), and allocate a number of processing cores to each of the plurality of packet processing pipelines based on the result of the analyzing for the corresponding pipeline ([0048] In some examples, the plurality of cores 140 may be capable of processing a plurality of events related to each data packet of one or more data packets, received by networking unit 142, in a sequential manner using one or more work units; [0067] packet parsing to create a PRV, flow key generation based on the PRV, determination of one of processing cores 140 for the incoming packet and allocation of a buffer handle in buffer memory, send the incoming FCP request and grant packets to destination agent block 182, and write the incoming data packets to buffer memory with the allocated buffer handle. Please note that determination of processing cores 140 for the incoming packet as part of packet processing, where the cores 140 process events to related to each data packet corresponds to allocating a number of processing cores to each of the plurality of packet processing pipelines based on the result of the analyzing, as determination of cores to process events corresponds to allocating processing cores to each of the plurality of packet processing pipelines. Since the analyzed state has a limited processing speed based on computing capability, the cores would be allocated to provide the computing capability for that particular pipeline with its associated state, corresponding to being based on the result of the analyzing for the corresponding pipeline.). Goel does not explicitly disclose packet processing of a user plane function (UPF);UPF packets; a packet vector size comprising a number of packets included in a packet vector; However, Kutch discloses packet processing of a user plane function (UPF); UPF packets ([0001] In computing networks and data centers, central processing units (CPUs) can be configured to run various network processing operations to rapidly handle network processing of packets. Examples of network processing operations include […] 5G User Plane Function (UPF) solutions. Please note that network processing operations to handle network processing of packets including 5G UPF solutions corresponds to Applicant’s packet processing of a UPF, as 5G UPF is a variant of UPF. Additionally, the packets relating to the 5G UPF processed by the system correspond to UPF packets.); a packet vector size comprising a number of packets included in a packet vector ([0032] packet processing activity (e.g., packets processed per time interval). Please note that a number of packets processed per time interval corresponds to Applicant’s packet vector size comprising a number of packets included in a packet vector, as it quantifies a value comprising a number of included packets, and would be obvious to one of ordinary skill in the art to apply in conjunction with a packet vector as previously described by Goel.) Goel and Kutch are both considered to be analogous to the claimed invention because they are in the same field of computer packet processing. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Goel to incorporate the teachings of Kutch to modify the packet processing system analyzing the state in which packets are processed by a packet processing pipelines, determining sizes of respective packet vectors and allocating processing cores to each of the pipelines to operate with UPF packets and have the packet vector size comprise a number of included packets, allowing for improved system flexibility and scaling, as described in Kutch. Regarding Claim 2, Goel-Kutch as described in Claim 1, Goel further discloses the plurality of packet processing pipelines is configured to process packets of different types ([0007] aspects of one or more systems described herein may further enable high speed yet flexible parsing of multiple types of network packets in an efficient manner. For instance, in some examples, multiple parsing devices may be used in parallel. Please note that the systems enabling flexible parsing of multiple types of network packets, wherein multiple parsing devices may be used in parallel corresponds to Applicant’s plurality of packet processing pipelines, i.e., parsing devices running in parallel, configured to process packets of different types. ). Regarding Claim 3, Goel-Kutch as described in Claim 2, Goel further discloses the types of the packets are defined according to at least one of a direction of a communication link, a type of a communication protocol, a version of the communication protocol, or a communication rule ([0134] identify, based on packet byte vector 504, one or more network layer protocols (e.g., Ethernet, IPv4, IPv6) that are associated with the packet header within packet byte vector 504. Please note that identifying network layer protocols associated with the packet header corresponds to Applicant’s types of packets being defined according to a type of a communication protocol. As Applicant states “at least one of” the methods of packet definition, this is interpreted as meeting the limitation.). Regarding Claim 4, Goel-Kutch as described in Claim 1, Goel further discloses analyze, for each packet processing pipeline, the pipeline processing state in which the UPF packets are processed based on at least one of a size of a current packet vector of the packet processing pipeline, a number of cores currently allocated to the packet processing pipeline, cycle information of the packet processing pipeline, a number of packets received by the packet processing pipeline, or a number of packets of a type received by the UPF ([0079] Sequence machine 513 determines a new state and determines which bytes within packet byte vector 504 to parse. For instance, in the example of FIG. 5A, sequence memory 512 outputs to sequence machine 513 information at the addresses identified by content-addressable memory 508; [0082] The amount of time required for parser 420 to compute a new parser state may be, in the example shown, the amount of time that it takes to (1) perform a lookup within content-addressable memory 508, (2) read sequence memory 512, and (3) compute the new state based on the information read from sequence memory 512. Since a limited amount of data at a time from packet byte vector 504 is processed in one state, the speed of parser 420 is limited by the speed in which a new parser state can be computed. Please note that the Sequence machine 513 computing a new parser state and which bytes within packet byte vector 504 to parse dependent on the amount of data at a time processed from packet byte vector 504 in one state, this corresponds to analyzing the pipeline processing state in which UPF packets are processed by the plurality of packet processing pipelines for each of the plurality of packet processing pipelines being based on a size of a current packet vector of the packet processing pipeline, as the state is dependent on the size of the vector (the amount of bytes) to be processed. As Applicant states “at least one of” the methods of analysis, this is interpreted as meeting the limitation.). Regarding Claim 5, Goel-Kutch as described in Claim 1, Kutch further discloses increase the number of processing cores allocated to each of the plurality of packet processing pipelines as an idle cycle decreases ([0054] At 504, an orchestrator can read performance information from particular registers of the core. Register content and specific types of telemetry information (e.g., busyness, packet drops per unit of time, packets processed per unit of time, and so forth) can be attributed to the application via a configuration […] At 506, the orchestrator can determine whether to adjust resource allocation to the workload running on the core. For example, the orchestrator can determine to adjust resource allocation based on specific performance requirements for the application and a particular resource adjustment scheme for the application. For example, if performance requirements are violated, resource allocation can be adjusted according to the resource adjustment scheme […] If a resource allocation is to be adjusted, the process can continue to 508; [0055] At 508, the orchestrator can adjust resource allocation to a core or workload. Please note that adjusting the resource allocation according to the resource adjustment scheme based on telemetry information such as busyness attributed to the application corresponds to Applicant’s increasing the number of processing cores allocated to each of the plurality of packet processing pipelines as an idle cycle decreases, since Applicant states on Page 8 Lines 26-31 and Page 9 Lines 1-5 of the specification that “as the degree of busyness of a packet processing pipeline increases, the processor 110 may increase the number of cores allocated to the packet processing pipeline. Here, that the degree of busyness increases may include that the execution cycle of the packet processing […] increases. That the execution cycle increases may be, for example, that the absolute value or a relative value of the execution cycle becomes greater than or equal to a preset threshold value. That the degree of busyness increases may include that the idle cycle decreases. That the idle cycle decreases may be, for example, that the absolute value or a relative value of the idle cycle becomes less than or equal to a preset threshold value.” Therefore, the degree of busyness decreasing, and thus violating a performance requirement, this would correspond to the idle cycle decreasing, which would cause a resource allocation to an application, i.e., packet processing pipeline, to change, by changing the core resource allocation, known to one of ordinary skill in the art to include increasing the number of processing cores allocated to it.). Regarding Claim 6, Goel-Kutch as described in Claim 1, Goel further discloses increase the size of the packet vector for each of the plurality of packet processing pipelines ([0079] Since a limited amount of data at a time from packet byte vector 504 is processed in one state, the speed of parser 420 is limited by the speed in which a new parser state can be computed. Please note that the parser 420 computing which bytes within packet byte vector 504 to parse dependent on the amount of data at a time processed from packet byte vector 504 in one state, corresponds to increasing the size of the packet vector for each of the plurality of packet processing pipelines, as the size of the vector (the amount of bytes) to be processed would affect the amount of computing resources required to maintain or improve a speed of processing of the data. Therefore, if more computing resources were available, the size of the packet vector could be increased.) Kutch further discloses as an idle cycle decreases ([0054] At 504, an orchestrator can read performance information from particular registers of the core. Register content and specific types of telemetry information (e.g., busyness, packet drops per unit of time, packets processed per unit of time, and so forth) can be attributed to the application via a configuration […] At 506, the orchestrator can determine whether to adjust resource allocation to the workload running on the core. For example, the orchestrator can determine to adjust resource allocation based on specific performance requirements for the application and a particular resource adjustment scheme for the application. For example, if performance requirements are violated, resource allocation can be adjusted according to the resource adjustment scheme […] If a resource allocation is to be adjusted, the process can continue to 508; [0055] At 508, the orchestrator can adjust resource allocation to a core or workload. Please note that, as previously stated in the rejection for Claim 5, the idle cycle decreasing, i.e., busyness increasing, could indicate that more processing cores are allocated to the packet processing pipeline. This is known in the art to increase the processing power of the application. Therefore, as Goel states that the speed of parser state computation by the parser 420 is related to the amount of data processed from the packet byte vector 504, the decrease in an idle cycle would indicate the capability to process a packet vector with an increased size, as more computing resources are being utilized.) Regarding Claim 7, Goel-Kutch as described in Claim 6, Goel further discloses the size of the packet vector ([0079] Since a limited amount of data at a time from packet byte vector 504 is processed in one state, the speed of parser 420 is limited by the speed in which a new parser state can be computed. Please note that the bytes within packet byte vector 504 to parse corresponds to the size of the packet.) Kutch further discloses increase the number of the processing cores allocated to each of the plurality of packet processing pipelines as an idle cycle decreases when the size of the packet vector is at a maximum. ([0010] In some cases, software executing on a platform may be allocated a highest expected resource use of a central processing unit (CPU) frequency as well as cache allocation, memory allocation, and network interface allocation to handle a worst case scenario workload and avoid violating terms of service such as service level agreement (SLA) requirements. For example, CPU utilization can be set at 100%.; ([0054] At 504, an orchestrator can read performance information from particular registers of the core. Register content and specific types of telemetry information (e.g., busyness, packet drops per unit of time, packets processed per unit of time, and so forth) can be attributed to the application via a configuration […] At 506, the orchestrator can determine whether to adjust resource allocation to the workload running on the core. For example, the orchestrator can determine to adjust resource allocation based on specific performance requirements for the application and a particular resource adjustment scheme for the application. For example, if performance requirements are violated, resource allocation can be adjusted according to the resource adjustment scheme […] If a resource allocation is to be adjusted, the process can continue to 508; [0055] At 508, the orchestrator can adjust resource allocation to a core or workload. Please note that, as previously stated in the rejection for Claim 5, the idle cycle decreasing, i.e., busyness increasing, could indicate that more processing cores are allocated to the packet processing pipeline. This is known in the art to increase the processing power of the application. Therefore, as Goel states that the speed of parser state computation by the parser 420 is related to the amount of data processed from the packet byte vector 504, the decrease in an idle cycle would indicate the capability to process a packet vector with an increased size, as more computing resources are being utilized. As CPU utilization for a particular workload could be set to 100% allocated for a particular workload, this would determine the maximum size of the packet vector that could be processed without violating the SLA requirements.) Regarding Claim 8, Goel-Kutch as described in Claim 1, Goel further discloses each of the plurality of packet processing pipelines includes a packet processing pipeline dedicated to process packets of a particular type ([0007] aspects of one or more systems described herein may further enable high speed yet flexible parsing of multiple types of network packets in an efficient manner. For instance, in some examples, multiple parsing devices may be used in parallel.; Please note that the systems enabling flexible parsing of multiple types of network packets, wherein multiple parsing devices may be used in parallel, corresponds to Applicant’s plurality of packet processing pipelines, i.e., parsing devices running in parallel, configured to process packets of different types. It would be obvious to someone of ordinary skill in the art to dedicate each of the pipelines operating in parallel to process a particular type of packet, as Goel anticipates the system processing various types of packets, and operating in parallel would improve the efficiency of doing so.). Regarding Claim 9, Goel-Kutch as described in Claim 1, Goel further discloses receive a UPF packet, select one of the plurality of packet processing pipelines based on a type of the received UPF packet, and deliver the received UPF packet to the selected packet processing pipeline ([0070] Parser 420 may generate parsed result vector 421.; 0093] the input to parser 420 may be a set of packet bytes, denoted as Packet Byte Vector (PBV). The incoming packet is streamed through packet byte vector 504 as the bytes arrive and are consumed by the parser; [0106] an example pipeline of functional blocks for processing network information, in accordance with one or more aspects of the present disclosure. In the example of FIG. 6, forwarding pipeline 440 includes a number of functional blocks, including stream selection block 602, flexible forwarding engines 604 (flexible forwarding engines 604A through 604F) and next hop block 606. […] Stream selection block 602 selects a stream and associated parsed result vector 421 (e.g., from one of parsers 558 of FIG. 5E) and passes the selected parsed result vector 421 to the next block. Next hop block 606 determines how the packet is to be forwarded. Please note that an incoming packet being input to parser 420 that generates parsed result vector 421 corresponds to receiving a UPF packet, selecting a stream and associated parsed result vector 421 corresponds to selecting one of the plurality of packet processing pipelines based on a type of the received UPF packet, and forwarding the packet to the next block of the pipeline corresponds to delivering the received UPF packet to the selected packet processing pipeline.). Regarding Claim 10, Goel-Kutch as described in Claim 9, Kutch further discloses select a packet processing pipeline having a highest idle cycle ([0051] At 436, orchestration can determine whether to adjust the resource allocation to the core n based on the telemetry information. […] For example, if the telemetry information indicates the core is underutilized […] orchestration can proceed to 438, 440, and 442; [0052] Orchestration 430 can be configured to perform one or more of 438, 440, and 442 to reduce resources to the core or application or provide additional resources to the core or application to perform the workload. Please note that using the telemetry information to determine whether to adjust the resource allocation to the core if it indicates the core is underutilized corresponds to selecting a packet processing pipeline, since, as previously described in the rejection for Claim 5, having high busyness, i.e., high utilization, corresponds to having a low idle cycle, and therefore having low busyness, i.e., being underutilized, would indicate a higher idle cycle. Therefore, the core/cores dedicated to a packet processing pipeline having the highest idle cycles could be selected.) Goel further discloses from among packet processing pipelines corresponding to the type of the received UPF packet ([0007] aspects of one or more systems described herein may further enable high speed yet flexible parsing of multiple types of network packets in an efficient manner. For instance, in some examples, multiple parsing devices may be used in parallel.; Please note that the systems enabling flexible parsing of multiple types of network packets, wherein multiple parsing devices may be used in parallel, corresponds to Applicant’s plurality of packet processing pipelines, i.e., parsing devices running in parallel, configured to process packets of different types. It would be obvious to someone of ordinary skill in the art to dedicate each of the pipelines operating in parallel to process a particular type of packet, as Goel anticipates the system processing various types of packets, and operating in parallel would improve the efficiency of doing so. From among these dedicated pipelines, the ones corresponding to the type of the received UPF packet could be selected.). Regarding Claim 11, Goel discloses A method of operating a packet processing control apparatus ([0005] Aspects of this disclosure describes techniques for parsing network packets, processing network packets, and modifying network packets before forwarding the modified network packets over a network.; [0154] The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses. Please note the techniques for processing network packets, corresponds to Applicant’s method of operating a packet processing control apparatus.), the method comprising: analyzing, for each of a plurality of packet processing pipelines, a pipeline processing state in which packets are processed ([0007] aspects of one or more systems described herein may further enable high speed yet flexible parsing of multiple types of network packets in an efficient manner. For instance, in some examples, multiple parsing devices may be used in parallel.; [0070] Later blocks (e.g., forwarding pipeline 440) may use the template to interpret parsed result vector 421 and perform operations based on the contents of parsed result vector 421; [0079] Sequence machine 513 determines a new state and determines which bytes within packet byte vector 504 to parse. Please note that the Sequence machine 513 computing a new parser state corresponds to analyzing a pipeline processing state in which packets are processed for each of a plurality of packet processing pipelines. Additionally, the systems enabling flexible parsing of multiple types of network packets, wherein multiple parsing devices may be used in parallel, to provide parsed result vectors 421 as part of respective forwarding pipelines 440, corresponds to Applicant’s plurality of packet processing pipelines.); determining, for each of the plurality of packet processing pipelines, a packet vector size based on a result of the analyzing ([0079] Sequence machine 513 determines a new state and determines which bytes within packet byte vector 504 to parse. For instance, in the example of FIG. 5A, sequence memory 512 outputs to sequence machine 513 information at the addresses identified by content-addressable memory 508; [0082] The amount of time required for parser 420 to compute a new parser state may be, in the example shown, the amount of time that it takes to (1) perform a lookup within content-addressable memory 508, (2) read sequence memory 512, and (3) compute the new state based on the information read from sequence memory 512. Since a limited amount of data at a time from packet byte vector 504 is processed in one state, the speed of parser 420 is limited by the speed in which a new parser state can be computed. Please note that the Sequence machine 513 computing a new parser state and which bytes within packet byte vector 504 to parse dependent on the amount of data at a time processed from packet byte vector 504 in one state corresponds to determining a packet vector size for each of the plurality of packet processing pipelines based on a result of the analyzing, as the state is dependent on the size of the vector (the amount of bytes) to be processed since it affects the processing speed of parser 420. Therefore, the size of the packet must be determined as part of determining which bytes to parse within packet byte vector 504.), and allocating a number of processing cores to each of the plurality of packet processing pipelines based on the result of the analyzing for the corresponding pipeline ([0048] In some examples, the plurality of cores 140 may be capable of processing a plurality of events related to each data packet of one or more data packets, received by networking unit 142, in a sequential manner using one or more work units; [0067] packet parsing to create a PRV, flow key generation based on the PRV, determination of one of processing cores 140 for the incoming packet and allocation of a buffer handle in buffer memory, send the incoming FCP request and grant packets to destination agent block 182, and write the incoming data packets to buffer memory with the allocated buffer handle. Please note that determination of processing cores 140 for the incoming packet as part of packet processing, where the cores 140 process events to related to each data packet corresponds to allocating a number of processing cores to each of the plurality of packet processing pipelines based on the result of the analyzing, as determination of cores to process events corresponds to allocating processing cores to each of the plurality of packet processing pipelines. Since the analyzed state has a limited processing speed based on computing capability, the cores would be allocated to provide the computing capability for that particular pipeline with its associated state, corresponding to being based on the result of the analyzing for the corresponding pipeline.). Goel does not explicitly disclose packet processing of a user plane function (UPF);UPF packets; a packet vector size comprising a number of packets included in a packet vector; However, Kutch discloses packet processing of a user plane function (UPF); UPF packets ([0001] In computing networks and data centers, central processing units (CPUs) can be configured to run various network processing operations to rapidly handle network processing of packets. Examples of network processing operations include […] 5G User Plane Function (UPF) solutions. Please note that network processing operations to handle network processing of packets including 5G UPF solutions corresponds to Applicant’s packet processing of a UPF, as 5G UPF is a variant of UPF. Additionally, the packets relating to the 5G UPF processed by the system correspond to UPF packets.); a packet vector size comprising a number of packets included in a packet vector ([0032] packet processing activity (e.g., packets processed per time interval). Please note that a number of packets processed per time interval corresponds to Applicant’s packet vector size comprising a number of packets included in a packet vector, as it quantifies a value comprising a number of included packets, and would be obvious to one of ordinary skill in the art to apply in conjunction with a packet vector as previously described by Goel.) Goel and Kutch are both considered to be analogous to the claimed invention because they are in the same field of computer packet processing. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Goel to incorporate the teachings of Kutch to modify the packet processing system analyzing the state in which packets are processed by a packet processing pipelines, determining sizes of respective packet vectors and allocating processing cores to each of the pipelines to operate with UPF packets and have the packet vector size comprise a number of included packets, allowing for improved system flexibility and scaling, as described in Kutch. Regarding Claim 12, Goel-Kutch as described in Claim 11, Goel further discloses the plurality of packet processing pipelines is configured to process packets of different types ([0007] aspects of one or more systems described herein may further enable high speed yet flexible parsing of multiple types of network packets in an efficient manner. For instance, in some examples, multiple parsing devices may be used in parallel. Please note that the systems enabling flexible parsing of multiple types of network packets, wherein multiple parsing devices may be used in parallel corresponds to Applicant’s plurality of packet processing pipelines, i.e., parsing devices running in parallel, configured to process packets of different types. ). Regarding Claim 13, Goel-Kutch as described in Claim 12, Goel further discloses the types of the packets are defined according to at least one of a direction of a communication link, a type of a communication protocol, a version of the communication protocol, or a communication rule ([0134] identify, based on packet byte vector 504, one or more network layer protocols (e.g., Ethernet, IPv4, IPv6) that are associated with the packet header within packet byte vector 504. Please note that identifying network layer protocols associated with the packet header corresponds to Applicant’s types of packets being defined according to a type of a communication protocol. As Applicant states “at least one of” the methods of packet definition, this is interpreted as meeting the limitation.). Regarding Claim 14, Goel-Kutch as described in Claim 11, Goel further discloses analyzing, for each packet processing pipeline, the pipeline processing state in which the UPF packets are processed, based on at least one of a size of a current packet vector of the packet processing pipeline, a number of cores currently allocated to the packet processing pipeline, cycle information of the packet processing pipeline, a number of packets received by the packet processing pipeline, or a number of packets of a type received by a UPF ([0079] Sequence machine 513 determines a new state and determines which bytes within packet byte vector 504 to parse. For instance, in the example of FIG. 5A, sequence memory 512 outputs to sequence machine 513 information at the addresses identified by content-addressable memory 508; [0082] The amount of time required for parser 420 to compute a new parser state may be, in the example shown, the amount of time that it takes to (1) perform a lookup within content-addressable memory 508, (2) read sequence memory 512, and (3) compute the new state based on the information read from sequence memory 512. Since a limited amount of data at a time from packet byte vector 504 is processed in one state, the speed of parser 420 is limited by the speed in which a new parser state can be computed. Please note that the Sequence machine 513 computing a new parser state and which bytes within packet byte vector 504 to parse dependent on the amount of data at a time processed from packet byte vector 504 in one state, this corresponds to analyzing the state in which UPF packets are processed by the plurality of packet processing pipelines for each of the plurality of packet processing pipelines being based on a size of a current packet vector of the packet processing pipeline, as the state is dependent on the size of the vector (the amount of bytes) to be processed. As Applicant states “at least one of” the methods of analysis, this is interpreted as meeting the limitation.). Regarding Claim 15, Goel discloses A non-transitory computer-readable recording medium having recorded thereon a program which, when executed by at least one processor, causes the at least one processor to control a packet processing control apparatus to perform operations comprising: ([0151] In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media, which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. Please note that non-transitory computer-readable storage media that contains instructions that can be accessed by computers to implement the disclosed techniques corresponds to Applicant’s non-transitory computer-readable recording medium having recorded thereon a program which, when executed by a processor, causes the processor to control a packet processing control apparatus to perform operations.) analyzing, for each of a plurality of packet processing pipelines, a pipeline processing state in which packets are processed ([0007] aspects of one or more systems described herein may further enable high speed yet flexible parsing of multiple types of network packets in an efficient manner. For instance, in some examples, multiple parsing devices may be used in parallel.; [0070] Later blocks (e.g., forwarding pipeline 440) may use the template to interpret parsed result vector 421 and perform operations based on the contents of parsed result vector 421; [0079] Sequence machine 513 determines a new state and determines which bytes within packet byte vector 504 to parse. Please note that the Sequence machine 513 computing a new parser state corresponds to analyzing a pipeline processing state in which packets are processed for each of a plurality of packet processing pipelines. Additionally, the systems enabling flexible parsing of multiple types of network packets, wherein multiple parsing devices may be used in parallel, to provide parsed result vectors 421 as part of respective forwarding pipelines 440, corresponds to Applicant’s plurality of packet processing pipelines.); determining, for each of the plurality of packet processing pipelines, a packet vector size based on a result of the analyzing ([0079] Sequence machine 513 determines a new state and determines which bytes within packet byte vector 504 to parse. For instance, in the example of FIG. 5A, sequence memory 512 outputs to sequence machine 513 information at the addresses identified by content-addressable memory 508; [0082] The amount of time required for parser 420 to compute a new parser state may be, in the example shown, the amount of time that it takes to (1) perform a lookup within content-addressable memory 508, (2) read sequence memory 512, and (3) compute the new state based on the information read from sequence memory 512. Since a limited amount of data at a time from packet byte vector 504 is processed in one state, the speed of parser 420 is limited by the speed in which a new parser state can be computed. Please note that the Sequence machine 513 computing a new parser state and which bytes within packet byte vector 504 to parse dependent on the amount of data at a time processed from packet byte vector 504 in one state corresponds to determining a packet vector size for each of the plurality of packet processing pipelines based on a result of the analyzing, as the state is dependent on the size of the vector (the amount of bytes) to be processed since it affects the processing speed of parser 420. Therefore, the size of the packet must be determined as part of determining which bytes to parse within packet byte vector 504.), and allocating a number of processing cores to each of the plurality of packet processing pipelines based on the result of the analyzing for the corresponding pipeline ([0048] In some examples, the plurality of cores 140 may be capable of processing a plurality of events related to each data packet of one or more data packets, received by networking unit 142, in a sequential manner using one or more work units; [0067] packet parsing to create a PRV, flow key generation based on the PRV, determination of one of processing cores 140 for the incoming packet and allocation of a buffer handle in buffer memory, send the incoming FCP request and grant packets to destination agent block 182, and write the incoming data packets to buffer memory with the allocated buffer handle. Please note that determination of processing cores 140 for the incoming packet as part of packet processing, where the cores 140 process events to related to each data packet corresponds to allocating a number of processing cores to each of the plurality of packet processing pipelines based on the result of the analyzing, as determination of cores to process events corresponds to allocating processing cores to each of the plurality of packet processing pipelines. Since the analyzed state has a limited processing speed based on computing capability, the cores would be allocated to provide the computing capability for that particular pipeline with its associated state, corresponding to being based on the result of the analyzing for the corresponding pipeline.). Goel does not explicitly disclose packet processing of a user plane function (UPF);UPF packets; a packet vector size comprising a number of packets included in a packet vector; However, Kutch discloses packet processing of a user plane function (UPF); UPF packets ([0001] In computing networks and data centers, central processing units (CPUs) can be configured to run various network processing operations to rapidly handle network processing of packets. Examples of network processing operations include […] 5G User Plane Function (UPF) solutions. Please note that network processing operations to handle network processing of packets including 5G UPF solutions corresponds to Applicant’s packet processing of a UPF, as 5G UPF is a variant of UPF. Additionally, the packets relating to the 5G UPF processed by the system correspond to UPF packets.); a packet vector size comprising a number of packets included in a packet vector ([0032] packet processing activity (e.g., packets processed per time interval). Please note that a number of packets processed per time interval corresponds to Applicant’s packet vector size comprising a number of packets included in a packet vector, as it quantifies a value comprising a number of included packets, and would be obvious to one of ordinary skill in the art to apply in conjunction with a packet vector as previously described by Goel.) Goel and Kutch are both considered to be analogous to the claimed invention because they are in the same field of computer packet processing. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Goel to incorporate the teachings of Kutch to modify the packet processing system analyzing the state in which packets are processed by a packet processing pipelines, determining sizes of respective packet vectors and allocating processing cores to each of the pipelines to operate with UPF packets and have the packet vector size comprise a number of included packets, allowing for improved system flexibility and scaling, as described in Kutch. Response to Arguments Applicant's arguments filed 02/26/2026 have been fully considered but they are not persuasive. Applicant’s arguments are summarized as follows: The system of Goel-Kutch does not disclose the limitations of Claim 1. Goel discloses a “state” referring to a parser state for which header to parse next, not a pipeline processing state, as well as a packet byte vector which is a set of packet bytes for a single packet’s header parsing, not a packet vector containing multiple packets. Goel further does not disclose a per-pipeline size as a number of packets, nor allocating a variable number of processing cores per pipeline based on analyzed pipeline processing states. Lastly, Kutch does not remedy Goel’s deficiencies regarding pipeline state analysis per pipeline, packet vectors containing multiple packets with a size equal to packet count, or pipeline core allocation driven based on that analysis. Therefore, its rejection under 35 U.S.C. 103 should be withdrawn. Claims 11 and 15, as well as their dependent claims, distinguish from the references for reasons similar to Claim 1, and should have their rejections under 35 U.S.C. 103 withdrawn as well. Regarding A, the examiner respectfully disagrees. Firstly, as described above in Goel, the Sequence machine 513 computing a new parser state corresponds to analyzing a pipeline processing state in which packets are processed for each of a plurality of packet processing pipelines, as it would be obvious to one of ordinary skill in the art to obtain the state information for a pipeline processing state, as a pipeline is known to have multiple states/stages/steps, and thus obtaining data about the state of each pipeline process in order to proceed with the process would be obvious to perform. Additionally, regarding allocating a variable number of processing cores per pipeline based on analyzed pipeline processing states, as stated above by Goel, the determination of processing cores 140 for the incoming packet as part of packet processing, where the cores 140 process events to related to each data packet corresponds to allocating a number of processing cores to each of the plurality of packet processing pipelines based on the result of the analyzing, as determination of cores to process events corresponds to allocating processing cores to each of the plurality of packet processing pipelines. Since the analyzed state has a limited processing speed based on computing capability, the cores would be allocated in a variable manner to provide the computing capability for that particular pipeline with its associated state, corresponding to being based on the result of the analyzing for the corresponding pipeline. It should be noted that the limitation regarding a packet vector size specifically comprising a number of packets included in a packet vector was not present in the previous version of the Claim, but is now disclosed by Kutch in the system of Goel-Kutch, as described above. Therefore, the recited features can be found in the cited combination of references, and independent Claim 1 remains rejected under 35 U.S.C. 103 for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. The rejections under 35 U.S.C. 103 are maintained. Regarding B, the examiner respectfully disagrees. Independent Claim 1 remains rejected for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. Therefore, contrary to Applicant’s arguments, because independent Claims 11 and 15 contain similar limitations to unpatentable Claim 1 and do not add limitations that overcome the rejection, they likewise remain rejected, and the application is not in condition for allowance. Additionally, contrary to Applicant’s arguments, because the dependent Claims thus depend on unpatentable claims and do not add limitations that overcome the rejection, they likewise remains rejected. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Kantecki et al. (US20190097951) discloses processing packets, packets organized into vectors, processing different packets in parallel, and packet processing pipelines (see [0015-0020, 0028]). THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARAZ T AKBARI whose telephone number is (571)272-4166. The examiner can normally be reached Monday-Thursday 9:30am-7:30pm ET. 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, April Blair can be reached at (571)270-1014. 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. /FARAZ T AKBARI/Examiner, Art Unit 2196 /APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Read full office action

Prosecution Timeline

Jun 30, 2023
Application Filed
Nov 26, 2025
Non-Final Rejection mailed — §103
Feb 05, 2026
Examiner Interview Summary
Feb 26, 2026
Response Filed
May 07, 2026
Final Rejection mailed — §103 (current)

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
0%
Grant Probability
0%
With Interview (+0.0%)
3y 5m (~4m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 4 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month