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 .
Election/Restrictions
Applicant’s election without traverse of claims 65-81 and 86-91 in the reply filed on 10 September 2025 is acknowledged.
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)(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.
Claim(s) 65-71, 80, 81, 86, 87, and 89-91are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Ramamurthi et al. (US 2022/0264335 A1), hereinafter referred to as D1.
Regarding claim 65, D1 discloses a MEC integration with RAN facilities, which comprises:
memory circuitry to store program code of the RAN function; and processor circuitry connected to the memory circuitry, wherein the processor circuitry is to execute the program code to: receive, from a RAN intelligent controller (RIC), a configuration including information for routing edge data to an edge compute function co-located with the RAN function (Referring to Figures 2 and 3, CRAN HUB 310, comprising RAN function, memory and processor, receives configuration information from the RIC, RAN Intelligent Controller, for routing edge data to MEC, multi-access edge computing device, co-located with the RAN. See paragraph 0031.)
receive, from a user equipment (UE), a network packet including edge data intended for delivery to an edge computing application (app) based on scheduling information included in the configuration (Referring to Figures 5 and 5, UE in connection (network packet) with a co-located MEC device with a RAN node communicating (receive from a UE) with an application (edge data intended for delivery to an edge computing application) as scheduled and controlled by the RIC. See paragraphs 0055 and 0056.),
extract the edge data from the network packet using data extraction information in the configuration, send the extracted edge data to an edge compute function, obtain processed edge data from the edge compute function, insert the processed edge data into the network packet, and send the network packet towards a destination node (Referring to Figures 4 and 5, MEC device 135 may modify performance of the function associated with the application being executed by UE 180 based on the received parameters (block 530). For example, MEC device 135 may take different actions based on the network conditions being experienced by UE 180. In one example, MEC device 135 may change the definition (e.g., resolution) of video being transmitted to UE 180 based on conditions experienced by UE 180. For example, if UE 180 is in an area with poor RAN channel conditions, MEC device 135 may present lower resolution/definition images. If, on the other hand, UE 180 is experiencing high channel quality and low congestion, MEC device 135 may present higher resolution/definition images or higher density content (such as multimedia, augmented reality, etc.) (interpreted as the MEC receives network conditions as co-located with the RAN in which the RAN exposes its API to the MEC as the MEC performs application level service scaling according to network conditions; thereby, extracting edge data from network packets using information in the configuration (network conditions), send the extracted edge data to an edge compute function (MEC receiving network conditions), obtain processed edge data from the edge compute function (MEC adjusting application according to network conditions), insert the processed edge data into the network packet (Adjusted application according to scaling), and send the network packet towards a destination (transmitting the scaled application to the UE). See paragraph 0058.)
Regarding claim 66, D1 discloses wherein the memory circuitry is to store an edge-specific dataflow of a network protocol stack, and the processor circuitry is to execute the program code to: operate edge-specific dataflow to process the extracted edge data for consumption by the edge compute function (Referring to Figures 3-6, MEC device 135 may modify performance of the function associated with the application being executed by UE 180 based on the received parameters (block 530). For example, MEC device 135 may take different actions based on the network conditions being experienced by UE 180. In one example, MEC device 135 may change the definition (e.g., resolution) of video being transmitted to UE 180 based on conditions experienced by UE 180. For example, if UE 180 is in an area with poor RAN channel conditions, MEC device 135 may present lower resolution/definition images. If, on the other hand, UE 180 is experiencing high channel quality and low congestion, MEC device 135 may present higher resolution/definition images or higher density content (such as multimedia, augmented reality, etc.) (store an edge specific dataflow of a network protocol stack, operate edge-specific dataflow to process the extracted edge data for consumption by the edge compute function, interpreted as the MEC storing and processing data for application level service. See paragraph 0057-0059.)
Regarding claim 67, D1 discloses wherein, to insert the processed edge data into the network packet, the processor circuitry is to execute the program code to: operate edge-specific dataflow to rebuild the network packet to include the processed edge data (Referring to Figures 3-6, MEC device 135 may modify performance of the function associated with the application being executed by UE 180 based on the received parameters (block 530). For example, MEC device 135 may take different actions based on the network conditions being experienced by UE 180. In one example, MEC device 135 may change the definition (e.g., resolution) of video being transmitted to UE 180 based on conditions experienced by UE 180. For example, if UE 180 is in an area with poor RAN channel conditions, MEC device 135 may present lower resolution/definition images. If, on the other hand, UE 180 is experiencing high channel quality and low congestion, MEC device 135 may present higher resolution/definition images or higher density content (such as multimedia, augmented reality, etc.) (operate edge-specific dataflow to rebuild the network packet to include the processed edge data, interpreted as the MEC storing and processing data for application level service scaling and transmitting the newly scaled data packet. See paragraph 0057-0059.)
Regarding claim 68, D1 discloses wherein: the RAN function is configured to perform one or more sublayers of a network protocol stack (Referring to Figures 3 and 4, RAN comprising DU performing sublayers of the network protocol stack, see paragraphs 0029-0034,), other RAN functions of the plurality of RAN functions are configured to perform other sublayers of the network protocol stack (Referring to figures 3 and 4, RAN comprising CU-UP performing sublayers of the network protocol stack, see paragraphs 0029-0034,), and the edge-specific dataflow includes performing operations of the one or more sublayers and performing operations of lightweight versions of the other sublayers of the network protocol stack (Referring to Figures 3-5, For example, MEC device 135 may take different actions based on the network conditions being experienced by UE 180. In one example, MEC device 135 may change the definition (e.g., resolution) of video being transmitted to UE 180 based on conditions experienced by UE 180. For example, if UE 180 is in an area with poor RAN channel conditions, MEC device 135 may present lower resolution/definition images. If, on the other hand, UE 180 is experiencing high channel quality and low congestion, MEC device 135 may present higher resolution/definition images or higher density content (such as multimedia, augmented reality, etc.) (edge-specific dataflow includes performing operations of one or more sublayers and performing operations of lightweight versions of the other sublayers of the network protocol stack, interpreted as the MEC storing and processing data for application level service (lightweight version) scaling and transmitting the newly scaled data packet. See paragraph 0057-0059.)
Regarding claim 69, D1 discloses wherein the edge-specific dataflow includes one or more of a set of core network functions, a transport layer protocol, a network layer protocol, and an application layer protocol (Referring to Figures 3-5, For example, MEC device 135 may take different actions based on the network conditions being experienced by UE 180. In one example, MEC device 135 may change the definition (e.g., resolution) of video being transmitted to UE 180 based on conditions experienced by UE 180. For example, if UE 180 is in an area with poor RAN channel conditions, MEC device 135 may present lower resolution/definition images. If, on the other hand, UE 180 is experiencing high channel quality and low congestion, MEC device 135 may present higher resolution/definition images or higher density content (such as multimedia, augmented reality, etc.) (MEC storing and processing data for application level service scaling). See paragraph 0057-0059.)
Regarding claim 70, D1 discloses wherein the network protocol stack is a Third Generation Partnership Project (3GPP) Fifth Generation (5G) New Radio (NR) protocol stack including a low physical (PHY) sublayer, a high-PHY sublayer, a Medium Access Control (MAC) sublayer, a Radio Link Control (RLC) sublayer, a Packet Data Convergence Protocol (PDCP) sublayer, a Service Data Protocol (SDAP) sublayer, a Backhaul Adaptation Protocol (BAP) sublayer, and an F1 application protocol (F1AP) sublayer (Referring to Figures 3-5, access network 105 may include a 5G radio access network (RAN), a Fourth Generation (4G) RAN, and/or another type of future generation RAN. By way of further example, access network 105 may be implemented to include a 5G New Radio (5G NR) RAN, by definition the standard comprises the recited sublayers. See paragraphs 0018 and 23. Operates according to a protocol stack and a communication standard. See paragraph 0050-0052.)
Regarding claims 71 and 90, D1 discloses wherein the one or more sublayers of the RAN function include the MAC sublayer and the high-PHY sublayer (Referring to Figures 3-5, Each DU 210, RAN, of the multiple DUs 210 includes a logical node that hosts functions associated with the Radio Link Control layer, the Media Access Control (MAC) layer, and the physical layer (PHY). See paragraphs 0028-0030.)
Regarding claims 80 and 91, D1 discloses wherein the destination node is the UE, another UE, a RAN node, a RAN function, an edge compute node, a cloud computing service, a web platform, an application server, or a database (Referring to Figures 3-5, For example, MEC device 135 may take different actions based on the network conditions being experienced by UE 180. In one example, MEC device 135 may change the definition (e.g., resolution) of video being transmitted to UE 180 based on conditions experienced by UE 180. For example, if UE 180 is in an area with poor RAN channel conditions, MEC device 135 may present lower resolution/definition images. If, on the other hand, UE 180 is experiencing high channel quality and low congestion, MEC device 135 may present higher resolution/definition images or higher density content (such as multimedia, augmented reality, etc.) (MEC storing and processing data for application level service scaling for service to a UE). See paragraph 0057-0059.)
Regarding claim 81, D1 discloses wherein the plurality of RAN functions include one or more remote units (RUs), one or more distributed units (DUs), and one or more centralized units (CUs), wherein the one or more RUs are connected to the one or more DUs via respective next generation fronthaul interface (NGFI)-I links, the one or more DUs are connected to the one or more CUs via respective NGFI-II links, and the one or more CUs are connected to one or more core network functions via respective backhaul links (Referring to Figures 3-5, the RAN comprising RUs, DUs, and CUs; wherein the Rus are connected to the DUs via links, the DUs connected to the CUs via links and the CUs connected to the core network via backhaul links. Comprising standard interfaces such as fronthaul and backhaul interfaces. See paragraphs 0011.)
Regarding claim 86, discloses a MEC integration with RAN facilities, which comprises: receiving, by the edge compute function from a RAN intelligent controller (RIC), edge compute information and edge data information based on one or more edge services provided by the edge compute function (Referring to Figures 5 and 5, UE in connection (network packet) with a co-located MEC device (edge compute function receive from the core/RIC, see paragraph 0033) with a RAN node communicating with an application, the RIC providing current network conditions information and additional conditions associated with the UE (edge compute information and edge data information, see paragraph 0034 and 0035) as scheduled and controlled by the RIC. See paragraphs 0055 and 0056.),
receiving, by the edge compute function, edge data extracted from a network packet by at least one RAN function of the plurality of RAN functions; processing the extracted edge data by operating the one or more edge apps to provide the one or more edge services involving the extracted edge data; and providing the processed edge data to a destination node indicated by the edge compute information or the edge data information (Referring to Figures 4 and 5, MEC device 135 may modify performance of the function associated with the application being executed by UE 180 based on the received parameters (block 530). For example, MEC device 135 may take different actions based on the network conditions being experienced by UE 180. In one example, MEC device 135 may change the definition (e.g., resolution) of video being transmitted to UE 180 based on conditions experienced by UE 180. For example, if UE 180 is in an area with poor RAN channel conditions, MEC device 135 may present lower resolution/definition images. If, on the other hand, UE 180 is experiencing high channel quality and low congestion, MEC device 135 may present higher resolution/defi9nition images or higher density content (such as multimedia, augmented reality, etc.) (interpreted as the MEC receives network conditions as co-located with the RAN in which the RAN exposes its API to the MEC as the MEC performs application level service scaling according to network conditions; thereby, the MEC, co-located with the RAN/RAN function, receives the application data conditions (edge data extracted from a network packet), adjusts the service scaling accordingly (processing the extracted edge data by operating the one or more edge apps to provide the one or more edge services involving the extracted edge data) and transmits the scaled application to the UE (providing the processed edge data to a destination node indicated by the edge compute information or the edge data information). See paragraph 0058.)
Regarding claims 87 and 89, D1 discloses wherein the method includes: receiving the edge compute information and the edge data information directly from the RIC; or receiving the edge compute information and the edge data information via the RAN function co-located with the edge compute function (Referring to Figures 3-5, the RAN is co-located with the MEC. See paragraphs 0021 and 0043.)
Allowable Subject Matter
Claims 72-79 and 88 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chou et al (US 2022/0159501 A1) - The processor circuitry can be configured to transmit a request to an edge computing management system to instantiate an edge computing virtualized network function (VNF). The request can include an identifier of a Network Service (NS) where a User Plane Function (UPF) VNF supporting the edge computing VNF is located. The processor circuitry can be further configured to receive, from the edge computing management system, a response indicating that the edge computing VNF is instantiated.
Chou et al. (US 2022/0417122 A1) - The management system receives a request from an edge computing management system to provide information of a user plane function to which the edge computing related resources in a local data network can be connected. The management system then selects a satisfactory user plane function, or if none can be found, deploys a new user plane function. The management system then provides the information of the selected or deployed user plane function for use in edge computing to the edge computing management system.
Ding et al. (US 2022/0159090 A1) - At least one of the methods includes: processing an ICN create-service request received from an Access and Mobility Management Function (AMF); allocating one or more ICN point of attachments (ICN-PoAs) based on the ICN create-service request; and forwarding the ICN create-service request to at least one of the allocated one or more ICN-PoAs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONALD L MILLS whose telephone number is (571)272-3094. The examiner can normally be reached Monday through Friday from 9-5 PM 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, Yemane Mesfin can be reached at 571-272-3927. 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.
DONALD L. MILLS
Primary Examiner
Art Unit 2462
/Donald L Mills/Primary Examiner, Art Unit 2462