DETAILED ACTION
This office action is responsive to communications filed on March 30, 2026. Claims 1-20 are pending in the application.
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 .
Information Disclosure Statement
The Information Disclosure Statement filed on 10/11/2024 has been considered.
Election/Restrictions
Claims 7-10 and 17-20 are withdrawn from further consideration pursuant to 37 CFR 1.142(b), as being drawn to a nonelected invention, there being no allowable generic or linking claim. Applicant timely traversed the restriction (election) requirement in the reply filed on March 30, 2026.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 2, 6, 11, 12, and 16 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Guy et al. (US 2022/0276809).
Regarding Claim 1, Guy teaches a method performed by a first device performing packet processing in a mobile communication system, the method comprising:
receiving, from a second device performing packet processing, a packet processing allocation request message requesting packet processing (“At 406, the first control plane can receive a configuration from the orchestrator. For example, the orchestrator can include an SDN controller. For example, the configuration can include a data plane pipeline configuration. Data plane pipeline configuration can include parser, exact match table, wild card match, longest prefix match, packet mirroring, packet modifier, or others. Data plane pipeline configuration can include match action rules or other configuration file (e.g., P4 file or other file). At 408, the first control plane can change device configuration of the packet processing device by writing to the communication interface and based on the received configuration by requesting that the second control plane configure the packet processing device based on the received configuration” – See [0042]; “the first control plane can be executed by a compute complex or platform in a packet processing device” – See [0041]; The packet processing device (first device) receives a packet processing allocation request message from the SDN controller (second device));
receiving a packet (“in response to receiving a packet, the packet is directed to one of the ingress pipelines 620” – See [0056]; A packet is received);
determining a packet processing method of the received packet based on the packet processing allocation request message (“A least one ingress pipeline 620 includes a parser 622, plural match-action units (MAUs) 624” – See [0057]; “MAUs 624 or 634 can perform processing on the packet data. In some examples, MAUs includes a sequence of stages, with a stage including one or more match tables and an action engine. A match table can include a set of match entries against which the packet header fields are matched (e.g., using hash tables), with the match entries referencing action entries. When the packet matches a particular match entry, that particular match entry references a particular action entry which specifies a set of actions to perform on the packet (e.g., sending the packet to a particular port, modifying one or more packet header field values, dropping the packet, mirroring the packet to a mirror buffer, etc.)” – See [0058]; The packet processing device determines an action/processing method for the packet based on the configuration specified in the packet processing allocation request message); and
performing packet processing of the received packet based on the determined packet processing method (“The action engine of the stage can perform the actions on the packet” – See [0058]; The packet processing device performs the determined action/processing method on the received packet).
Regarding 2, Guy teaches the method of Claim 1. Guy further teaches that the packet processing allocation request message comprises at least one of packet reference information, flow identifier, flow allocation information, or flow requirement information, wherein the packet reference information comprises at least one of terminal information, flow information, or security information, wherein the terminal information comprises a terminal context, wherein the flow information comprises at least one of protocol data unit (PDU) session information, service data adaption protocol (SDAP) information, packet data convergence protocol (PDCP) information, transmission control protocol (TCP) information, user datagram protocol (UDP) information, Internet protocol (IP) information, or quick DUP Internet connection (QUIC) information, and wherein the security information comprises at least one of base station security information or security key information (“Data plane pipeline configuration can include parser, exact match table, wild card match, longest prefix match, packet mirroring, packet modifier, or others” – See [0042]; “Examples of flow rules include exact match table rules, wild card match table rules, longest prefix match rules, or others” – See [0043]; “A flow can be a sequence of packets being transferred between two endpoints, generally representing a single session using a protocol. Accordingly, a flow can be identified, using a match, by a set of defined tuples and, for routing purpose, a flow is identified by the two tuples that identify the endpoints, e.g., the source and destination addresses. For content-based services (e.g., load balancer, firewall, Intrusion detection system etc.), flows can be identified at a finer granularity by using N-tuples (e.g., source address, destination address, IP protocol, transport layer source port, and destination port). A packet in a flow is expected to have the same set of tuples in the packet header. A packet flow to be controlled can be identified by a combination of tuples (e.g., Ethernet type field, source and/or destination IP address, source and/or destination User Datagram Protocol (UDP) ports, source/destination TCP ports, or any other header field) and a unique source and destination queue pair (QP) number or identifier” – See [0017]; The processing allocation request message indicates exact match tables which correspond to flow identifier tuples, and are also considered to be flow allocation information and flow requirement information).
Regarding 6, Guy teaches the method of Claim 1. Guy further teaches that the packet processing method comprises: performing full processing of a received packet by the first device, performing partial processing of a received packet by the first device and then transmitting the packet to the second device, or forwarding a received packet to the second device by the first device and then performing partial processing (“The action engine of the stage can perform the actions on the packet” – See [0058]; The packet processing device performs the determined action/processing method on the received packet according to the specified rules/actions specified in the packet processing allocation request message. Thus, full processing is performed on the received packet).
Claim 11 is rejected based on reasoning similar to Claim 1.
Claim 12 is rejected based on reasoning similar to Claim 2.
Claim 16 is rejected based on reasoning similar to Claim 6.
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 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Guy et al. (US 2022/0276809) in view of Seewald et al. (US 2018/0287422).
Regarding Claim 3, Guy teaches the method of Claim 2. Guy does not explicitly teach transmitting a packet processing allocation response message to the second device performing the packet processing, wherein the packet processing allocation response message further comprises information on whether packet processing allocation is acceptable.
However, Seewald teaches transmitting a packet processing allocation response message to the second device performing the packet processing, wherein the packet processing allocation response message further comprises information on whether packet processing allocation is acceptable (“In response to the SDN controller 22 receiving a reply 56 from one or more of the network devices (e.g., a reply acknowledging implementation of the SDN configuration data 52, a reply indicating failure in implementing the SDN configuration data 52” – See [0025]; The packet processing device transmits a response message indicating acknowledgement of the packet processing allocation/configuration).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Guy to transmit a packet processing allocation response message to the second device performing the packet processing, wherein the packet processing allocation response message further comprises information on whether packet processing allocation is acceptable. Motivation for doing so would be to indicate an acknowledgement or failure in implementing the packet processing allocation request (See Seewald, [0025]).
Claim 13 is rejected based on reasoning similar to Claim 3.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Guy et al. (US 2022/0276809) in view of Lee et al. (US 2015/0319078).
Regarding Claim 4, Guy teaches the method of Claim 1. Guy further teaches that the first device is configured to perform functions of packet processing performed by the second device (“At 406, the first control plane can receive a configuration from the orchestrator. For example, the orchestrator can include an SDN controller” – See [0042]; The packet processing device (first device) performs functions packet processing according to the packet processing configuration performed by the SDN controller (second device)),
wherein the first device comprises a smart network device (SND) (“wherein the packet processing device comprises one or more of: a network interface controller (NIC), a remote direct memory access (RDMA)-enabled NIC, SmartNIC, router, switch, forwarding element, infrastructure processing unit (IPU), or data processing unit (DPU)” – See [0100]; The packet processing device (first device) includes a smartNIC (smart network device)).
Guy does not explicitly teach that the second device comprises a virtual machine (VM).
However, Lee teaches that the second device comprises a virtual machine (VM) (“The first SDN controller 122 and the second SDN controller 123 may be one or more VMs” – See [0028]; The SDN controller (second device) comprises a VM).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Guy such that the second device comprises a virtual machine (VM). Motivation for doing so would be to enable migration of services from dedicated hardware to software, such that services can be implemented as software components, moved out of a centralized location, and instantiated at different locations (See Lee, [0005]).
Claim 14 is rejected based on reasoning similar to Claim 4.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Guy et al. (US 2022/0276809) in view of Han et al. (US 2025/0301309).
Regarding Claim 5, Guy teaches the method of Claim 1. Guy does not explicitly teach receiving, from the second device performing packet processing, a capability request message of the first device performing packet processing; and transmitting, to the second device performing the packet processing, a first device capability response message, wherein the first device capability response message comprises at least one of available encryption algorithm and mode information of the first device or trusted execution environment (TEE) support information of the first device.
However, Han teaches receiving, from the second device performing packet processing, a capability request message of the first device performing packet processing (“The first communication apparatus sends request information to the second communication apparatus, where the request information is used to request capability information of the second communication apparatus” – See [0122]; The second communication apparatus (first device) receives, from the first communication apparatus (second device), a capability request message); and
transmitting, to the second device performing the packet processing, a first device capability response message, wherein the first device capability response message comprises at least one of available encryption algorithm and mode information of the first device or trusted execution environment (TEE) support information of the first device (“S506: The second communication apparatus sends the capability information to the first communication apparatus based on the request information. Correspondingly, the first communication apparatus receives the capability information from the second communication apparatus, where the capability information indicates whether the second communication apparatus supports encrypting/decrypting the message” – See [0129]; “the second management message may include a TLV type field, a TLV length field, a field of the identity of the request device, a field of an identity of a response device (which may be denoted as grantIdentity), and a field of a capability of the response device (which may be denoted as a grantMACsecAbility field)” – See [0131]; “The TLV type field of the second management message indicates that the message is used to report the capability information of the second communication apparatus, that is, the message carries the capability information of the second communication apparatus” – See [0132]; The second communication apparatus (first device) transmits, to the first communication apparatus (second device), a capability response message indicating that the second communication apparatus supports an encryption algorithm and mode information of the second communication apparatus indicating an identity and that the message is being used to report the capability information of the second communication apparatus).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Guy to include receiving, from the second device performing packet processing, a capability request message of the first device performing packet processing; and transmitting, to the second device performing the packet processing, a first device capability response message, wherein the first device capability response message comprises at least one of available encryption algorithm and mode information of the first device or trusted execution environment (TEE) support information of the first device. Motivation for doing so would be to improve security of message transmissions (See Han, [0140]).
Claim 15 is rejected based on reasoning similar to Claim 5.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Scott M Sciacca whose telephone number is (571)270-1919. The examiner can normally be reached Monday thru Friday, 7:30 A.M. - 5:00 P.M. EST.
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, Joseph Avellino can be reached at (571) 272-3905. 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.
/SCOTT M SCIACCA/ Primary Examiner, Art Unit 2478
Prosecution Insights