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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 9/17/2024 was filed in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim 14 is objected to because of the following informalities:
In Claim 14, “the MEC platform” in limitation “wherein instances of the MEC application run as virtual machines and/or containers within the MEC platform” should read “the MEC system”. The MEC application is the robot application 130 in the specification. According to FIG. 1 in the drawing, Robot application 130 is in MEC system 124, but not in MEC platform 122. Robot application 130 consumes the service of RCSM in platform 122.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
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.
The claimed invention is directed to non-statutory subject matter. Claims 10-15 do not fall within at least one of the four categories of patent eligible subject matter because claims 10-15 are directed to a computer program. More specifically, Claim 10 is directed to a system, where the system comprises a radio context map service (RCMS). Further, all recited steps of claim 10 is performed by RCMS, which is software. Therefore, they are directed to the software itself, not a process occurring as a result of executing the software, a machine programmed to operate in accordance with the software nor a manufacture structurally and functionally interconnected with the software in a manner which enables the software to act as a computer component and realize its functionality. They are also clearly not directed to a composition of matter. Therefore, claims 10-15 are non-statutory under 35 U.S.C. 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 (i.e., changing from AIA to pre-AIA ) 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, 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-15 are rejected under 35 U.S.C. 103 as being unpatentable over Filippou et al. (US20220353732A1, hereinafter Filippou) in view of Svennebring et al. (US20190319868A1, hereinafter Svennebring).
For claim 1, Filippou teaches A method of providing radio context map information to a Multi-Access Edge Computing (MEC) application that is deployed at a MEC host and manages a 5G or Beyond 5G (B5G) enabled network device ([Para. 0040], Disclosed embodiments are related to techniques for implementing Vehicle-to-Everything (V2X) communications in Multi-access Edge Computing (MEC) systems. [Para. 0166], The client applications in vehicles collect their environmental perception, upload relevant perception to the application running in edge node; and download high definition (HD) map data that was consolidated in the edge node. [Para. 0184] and [FIG. 15], A Client App 1518 at the vehicle V-ITS-S 1501. A corresponding MEC App 1526 runs at a MEC platform 1532 (e.g., as part of a MEC host 1540). MEC app 1526 and client app 1518 exchange data over interface 1519 [Examiner’s Note: MEC App 1526 is the Multi-Access Edge Computing (MEC) application. MEC App 1526 corresponds to Robot Control System (RCS) of this patent application]. [Para. 0196, 0197 and 0098] and [FIG. 15], MEC App 1526 associated with Client App 1518 sends a request for predicted QoS to VIS 1580. The request includes radio measurement and locations of the measurement from vUE 1501. [Para. 0204] and [FIG. 16], the VIS 1580 concatenates the prediction attributes to form response message to be sent to the requesting MEC App 1526 at 1605 a. The prediction attributes are related to radio characteristics [Examiner’s Note: VIS 1580 provides the radio context map to MEC App 1526]), the method comprising: registering and running a Radio Context Map Service (RCMS), on an MEC platform of the MEC host ([Para. 0166], The client applications in vehicles collect their environmental perception, upload relevant perception to the application running in edge node; and download high definition (HD) map data that was consolidated in the edge node. [Para. 0196, 0197 and 0098] and [FIG. 15], MEC App 1526 associated with Client App 1518 sends a request for predicted QoS to VIS 1580. The request includes radio measurement and locations of the measurement from vUE 1501. [Para. 0204] and [FIG. 16], the VIS 1580 concatenates the prediction attributes to form response message to be sent to the requesting MEC App 1526 at 1605 a. The prediction attributes are related to radio characteristics [Examiner’s Note: VIS 1580 is the service that provides the radio map to the MEC application MEC App 1526. VIS 1580 corresponds to RCMS]. [Para. 0185] and [FIG. 15 and 25], MEC platform 1532 may be the same or similar as MEC platform 2532 discussed herein. [Para. 0221], while the VIS is the service, the MEC platform owns the Service Registry, and makes the VIS service discovery possible [Examiner’s Note: Making VIS discovery possible indicates VIS 1580 registers on the MEC platform]. [Para. 0257], Mp1 provides service registration 2538, service discovery, for various services, such as the MEC services 2536 provided by MEC host 2502 [Examiner’s Note: Mp1 is the interface between an MEC application and platform]. [Para. 0258], When provided by an application, a MEC service 2536 can be registered in a list of services in the service registries 2538 to the MEC platform 2532 over the Mp1 reference point [Examiner’s Note: VIS 1580 is the service corresponding to MEC service 2536. When provided by an application (not native in the platform), VIS 1580 registers on the platform 1532 corresponding to platform 2532. MEC host is 1540 including platform 1532 in FIG. 15]); subscribing, by the RCMS, to location and radio information from existing MEC services of the MEC platform ([Para. 0186] and [FIG.2 and 15], The VIS 1580 may be the same or similar as the MEC VIS 280 discussed previously. [Para. 0072] and [FIG. 2], The VIS 280 may be produced by the MEC app 228 [Examiner’s Note: That VIS 1580 (VIS 280) is produced by an MEC app indicates that an MEC app provides the service VIS 1580 in the MEC platform by the MEC app registering the service in the platform]. [Para. 0185] and [FIG. 15 and 25], MEC platform 1532 may be the same as MEC platform 2532. [Para. 0258] and [FIG. 25], a MEC App 2526 can subscribe to services 2530/2536 [Examiner’s Note: MEC App 2526 referring all MEC applications includes the MEC app that produces service VIS 1580]. [Para. 0259], MEC services 2536 include the radio network information service (RNIS) and location service (LS) [Examiner’s Note: The MEC app that produces service VIS 1580 subscribes to RNIS and LS referred to as 2536]. [Para. 0145], The information on current radio conditions are shared via the MEC platform over an RNIS, and location information is shared via a Location Service (LS) [Examiner’s Note: RNIS and LS are the existing MEC service providing radio and location information]); creating and updating, by the RCMS, a radio context map by processing location and radio information received from the subscribed MEC services and by combining the received location and radio information with additional application related context information provided through the MEC application or any other MEC application deployed at the MEC host ([Para. 0186], The VIS 1580 may be the same or similar as the MEC VIS 280 discussed previously. [Para. 0073] and [FIG. 2], the MEC platform 230 (corresponding to MEC platform 2532) can include a MEC V2X API that provides MEC VIS 280. The VIS 280 can include functionalities (e) gathering and processing information available in Radio Network Information (RNI) API, Location API, in order to provide suitable notifications to the ITS-S 201. [Examiner’s Note: RNI and LS are the subscribed MEC services]. [Para. 0184] and [FIG. 15], MEC app 1526 and client app 1518 exchange data over interface 1519. [Para. 0186], the VIS 1580 consumes requests and provides responses. [Para. 0196, 0197 and 0098], MEC App 1526 associated with Client App 1518 sends a request for predicted QoS to VIS 1580. The request includes radio measurement and locations of the measurement from vUE 1501 [Examiner’s Note: The request received at VIS 1580 includes the additional application related context information from MEC App 1526, the MEC application]. [Para. 0197, 0198], At step 1603 a and At step 1604 a, the VIS 1580 provides the request(s) to the RAN prediction function (RAN PF 1550) and obtains from RAN PF 1550 the radio attributes that indicates predicted radio signal quality related to radio characteristics. [Para. 0204], the VIS 1580 concatenates the prediction attributes to form a response message to be sent to the requesting MEC App 1526 at 1605 a. [Examiner’s Note: The response is the radio context map]. [Para. 0166], The client applications in vehicles that process sensory data to collect their environmental perception, upload relevant perception to the application running in distributed edge nodes; and download high definition (HD) map data that was consolidated in the distributed edge nodes [Examiner’s Note: The Context information is received by the MEC application and used for creating the radio context map]. [Para. 0169], both the vehicle app and the MEC App may periodically request extended e-IQNs in order to maintain updates of the HD maps with real-time data [Examiner’s Note: Updating the map]), and providing, by the RCMS, the radio context map to the MEC application ([Para. 0204], the VIS 1580 concatenates the prediction attributes to form response message to be sent to the requesting MEC App 1526 at 1605 a. The prediction attributes are related to radio characteristics).
Although Filippou teaches that VIS 1580 receiving radio information from the MEC app 1526 ([Para. 0166], The client applications in vehicles that process sensory data (e.g., radar) to collect their environmental perception. Upload relevant perception to the application running in distributed edge nodes [Para. 0098], individual vUEs 201 provide radio information to MEC Hosts 240. Each measurement report is tagged the location of the measurement (e.g., the vUE's 201 current location). [Para. 0184], MEC app 1526 and client app 1518 exchange data. [Para. 0197], at step 1602 a an request is sent to VIS 1580 by MEC app 1526), Svennebring more specifically discloses the radio context in creating and updating, by the RCMS, a radio context map by processing location and radio information received from the subscribed MEC services and by combining the received location and radio information with additional application related context information provided through the MEC application or any other MEC application deployed at the MEC host
Svennebring is directed to providing Link performance prediction technologies. More specifically, Svennebring teaches creating and updating, by the RCMS, a radio context map by processing location and radio information received from the subscribed MEC services and by combining the received location and radio information with additional application related context information provided through the MEC application or any other MEC application deployed at the MEC host ([Para. 0110] and [FIG. 4], The link performance predication information service (LPP-IS) 452 may be produced by the MEC Apps 436 [Examiner’s Note: LPP is both MEC App 436 and MEC platform service]. [Para. 0112], the MEC platform 437 can include a MEC LPP API 451 and provide MEC LPP-IS 452, which can include functionalities: (b) gathering of relevant radio link and/or backhaul link information from the access network for determining and providing LPPs to the UEs 420, (d) gathering and processing information obtained from the RNI API, LS API within the MEC platform 437in order to predict radio network congestion, UE 420 location(s)/mobility, and provide suitable notifications (e.g., LPP notifications) to the UE 420 [Examiner’s Note: LPP is the MEC app that receives radio information and providing notification to UEs. Therefore, LPP functions such as RCS. LPP processes the received radio information, and the radio and location information from RNIS and LS for determining prediction and creates the prediction. LPP also functions such as RCMS]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Filippou, so that the radio context is received and processed with information from RNIS and LS to determine and produce link prediction, as taught by Svennebring. The modification would have dynamically predicted the quality and/or performance of any given radio link and optimized application level behaviors (Svennebring [Para. 0011]).
For claim 2, Filippou and Svennebring teach the method according to claim 1. The references further teach wherein the MEC application is a Robot Control System (RCS) configured to manage operation of a5G or B5G-enabled robot device (Filippou [Para. 0184] and [FIG. 15], A Client App 1518 at the vehicle 1501. A corresponding MEC App 1526 runs at a MEC platform 1532. MEC app 1526 and client app 1518 exchange data over interface 1519. [Examiner’s Note: MEC app 1526 is the MEC application that corresponds to RCS]. Filippou [Para. 0197], at step 1601, a request for journey-specific predicted QoS is sent by Client App 1518 to MEC App 1526, and at step 1602 a an request is sent to VIS 1580 by MEC App 1526. Filippou [Para. 0204], the VIS 1580 concatenates the prediction attributes to form a response message to be sent to the requesting MEC App 1526 at 1605 a. The prediction attributes are related to radio characteristics. Filippou [Para. 0210] and [FIG. 17], At step 7. the VIS 1580 sends an RESP with all attributes/parameters to MEC App 1526. At step 8, the e-IQN consumer forwards the predictions to Client App 1518. At step 9, Client App 1518 makes an offloading decision based on communicated prediction [Examiner’s Note: MEC app 1526 manages device 1501]. Filippou [Para. 0379], some aspects of the described process may take place on a different processing system (e.g., in a computer in a data center) than that in which the code is deployed (e.g., in a computer embedded in a robot) [Examiner’s Note: That the code is deployed in a robot indicates the managed device includes robot]).
For claim 3, Filippou and Svennebring teach the method according to claim 1. The references further teach further comprising: sharing the radio context map with other MEC applications and/or MEC services (Svennebring [Para. 0110] and [FIG. 4], LPP Information Services (LPP-IS) (collectively referred to as “MEC LPP-IS 452”) permits information exposure pertinent to the support of link quality/performance prediction use cases to MEC app 436 instances. In presence of multiple MEC hosts 136, the LPP-IS 452 permits exposure of LPP information between MEC Apps 436 running on different MEC hosts 136).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Filippou, so that the link quality information provided by LPP-IS service is shared among MEC applications, as taught by Svennebring. The modification would have dynamically predicted the quality and/or performance of any given radio link and optimized application level behaviors (Svennebring [Para. 0011]).
For claim 4, Filippou and Svennebring teach the method according to claim 1. The references further teach wherein the RCMS subscribes to and receives network-based information from an MEC Radio Network Information Service (RNIS) and/or from an MEC Location Service MEC (LS) (Filippou [Para. 0186], The VIS 1580 may be the same or similar as the MEC VIS 280 discussed previously. Filippou [Para. 0072], The VIS 280 may be produced by the MEC app 228, Filippou [Para. 0258], a MEC App 2526 can subscribe to services 2530/2536 for which it is authorized over the Mp1 reference point [Examiner’s Note: MEC App 2526 corresponds to the MEC application]. Filippou [Para. 0259], MEC services 2536 include the radio network information service (RNIS) and location service (LS). Filippou [Para. 0145], The information on current radio conditions is shared via the MEC platform over an RNIS, and location information is shared via a Location Service (LS)).
For claim 5, Filippou and Svennebring teach the method according to claim 4. The references further teach wherein the network-based information the RCMS retrieved through the RNIS includes at least one of measurement information related to a user plane (Filippou [Para. 0073], the MEC platform 230 (corresponding to MEC platform 2532) can include a MEC V2X API that provides MEC VIS 280. The VIS 280 can include functionalities (e) gathering and processing information available in Radio Network Information (RNI) API in order to provide suitable notifications to the ITS-S 201. Filippou [Para. 0106], The RNI that may be provided may include up-to-date radio network information regarding radio network conditions; measurement information related to the user plane based on 3GPP specifications), information related to specific UEs connected to radio node(s) associated with the MEC host (Filippou [Para. 0106], The RNI that may be provided may include information about UEs connected to the radio node(s) associated with the MEC host), and changes in information related to UEs connected to the radio node(s) associated with the MEC host (Filippou [Para. 0106], The RNI that may be provided may include changes on information related to UEs connected to the radio node(s) associated with the MEC host), UE context and related radio access bearers (Filippou [Para. 0106], The RNI that may be provided may include their UE context and the related radio access bearers).
For claim 6, Filippou and Svennebring teach the method according to claim 4. The references further teach wherein the network-based information the RCMS retrieved through the MEC LS includes at least one of a position of radio node(s) associated with the MEC host (Filippou [Para. 0073], the MEC platform 230 (corresponding to MEC platform 2532) can include a MEC V2X API that provides MEC VIS 280. The VIS 280 can include functionalities (e) gathering and processing information available in Location API in order to provide suitable notifications to the ITS-S 201. Filippou [Para. 0133], The Location Service (LS) supports the location information: information about the location of all RAN node(s) currently associated with the MEC host), a position of UEs connected by radio node(s) associated with the MEC host (Filippou [Para. 0133], The Location Service (LS) supports the location information: location information of specific UEs currently served by the radio node(s) associated with a particular MEC host; location information of all UEs currently served by RAN node(s) associated with the MEC host), and a list of UEs located in or moving to/from a particular geographical area (Filippou [Para. 0133], The Location Service (LS) supports the location information: a list of UEs in a particular location area; the specific UEs which move in or out of a particular location area).
For claim 7, Filippou and Svennebring teach the method according to claim 1. The references further teach wherein the RCMS creates and updates the radio context map by additionally including information collected by the MEC application (Filippou [Para. 0184] and [FIG. 15], MEC app 1526 and client app 1518 exchange data over interface 1519. Filippou [Para. 0186], the VIS 1580 consumes requests and provides responses. Filippou [Para. 0196, 0197 and 0098], MEC App 1526 associated with Client App 1518 sends a request for predicted QoS to VIS 1580. The request includes radio measurement and locations of the measurement from vUE 1501 [Examiner’s Note: The request received at VIS 1580 includes the additional application related context information from MEC App 1526, the MEC application]. Filippou [Para. 0204], the VIS 1580 concatenates the prediction attributes to form a response message to be sent to the requesting MEC App 1526 at 1605 a), which collects the information locally via on-board sensors by the 5G or B5G-enabled network devices and/or by further 5G or B5G-enabled network devices deployed in a coverage area of the radio node(s) associated with the MEC host (Filippou [Para. 0076], The MEC V2X APIs (e.g., to expose VIS 280) can be provided as a general middleware service, providing information gathered from vehicles 201 and other V2X elements, The MEC V2X APIs can be configured to gather information and data from various sensors. Filippou [Para. 0166], The client applications in vehicles that process sensory (sensor) data to collect their environmental perception, upload relevant perception data to the host application side, which is the application running in distributed edge nodes; and download HD map data that was consolidated in the distributed edge nodes [Examiner’s Note: The Context information is received by the MEC application and used for creating the radio context map]. Filippou [Para. 0169], both the vehicle app and the MEC App may periodically request extended e-IQNs in order to maintain updates of the HD maps with real-time data [Examiner’s Note: Updating the map]. Filippou [Para. 0172], The host applications running in the edge nodes 1240 receive the perception and situation awareness data from multiple vehicles 1201 in their respective coverage areas. Filippou [Para. 0039], The 3GPP V2X RATs include “5G-V2X”).
For claim 8, Filippou and Svennebring teach the method according to claim 1. The references further teach wherein the RCMS stores a collected set of historical real-time RAN information over a specified time period in a geographical area including a set of radio node(s) associated with the MEC host (Svennebring [Para. 0110] and [FIG. 4], The link performance predication information service (LPP-IS) 452 may be produced by the MEC Apps 436. Svennebring [Para. 0112], the MEC platform 437 can include a MEC LPP API 451 and provide MEC LPP-IS 452 [Examiner’s Note: LPP-IS corresponds to RCMS as service in platform. LPP-IS is provided by MEC Apps 436]. Svennebring [Para. 0043], the LPPS 200 uses spatial and temporal (spatio-temporal) historical data to predict link quality. [Para. 0051], These predictions may be based on spatio-temporal history data associated with the UE 111, 121 and/or the current cell. Svennebring [Para. 0027], The UEs 111, 121 are capable of measuring various signals or determining/identifying various signal/channel characteristics. The measurements collected by the UEs 111, 121 may include: SINR and RSRQ [Examiner’s Note: The measurement data is RAN information]. Svennebring [Para. 0117], MEC apps 436 can be configured to host and/or store LPP-related data and/or configuration parameters, such as collected measurement data. Svennebring [Para. 0177], The spatial-temporal-history data 722 may be stored in a database and represented as timed data structure. In the example of FIG. 7, the spatial-temporal-history data 722 includes records or database objects for respective time instances [Examiner’s Note: That the MEC apps 436 providing LPP service stores measurement data, the measurement data is RAN information and the temporal-history data for LPP prediction is stored in database indicates that the application stores the historical real-time RAN information]. Svennebring [Para. 0185], the data collection layer collects and stores spatio-temporal history data, which may be done on a periodic basis, and updated or new temporal spatio-temporal history data is used to predicted performance metrics [Examiner’s Note: The temporal history data is collected periodically indicating that specified time period]. Svennebring [Para. 0025] and [FIG. 1], the access networks provide network connectivity to the end-user devices 120, 110 via respective NANs 131-133. Svennebring [Para. 0038], multiple NANs 131-133 are co-located or otherwise communicatively coupled with one edge compute node 136. Svennebring [Para. 0037], the edge compute nodes 136 may include or be part of a MEC system 135 [Examiner’s Note: The UEs are in the current cell of the NANs that are associated with MEC system 135]. Svennebring [Para. 0051], These predictions may be based on spatio-temporal history data associated with the UE 111, 121 and the current cell [Examiner’s Note: The temporal history data is associated with the current cell of the NANs associated with the MEC system]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Filippou, so that the application for LPP service stores the temporal history data of RAN over a period in the current cell including NANs associated with the MEC host, as taught by Svennebring. The modification would have dynamically predicted the quality and/or performance of any given radio link and optimized application level behaviors (Svennebring [Para. 0011]).
For claim 9, Filippou and Svennebring teach the method according to claim 1. The references further teach wherein the MEC application uses the radio context map to generate and send via an existing mobile network communication channel appropriate control instructions to the 5G or B5G-enabled network device managed by the MEC application (Filippou [Para. 0196, 0197 and 0098] and [FIG. 16], a consumer is a MEC App 1526 associated with a Client App 1518 running at a vUE 1501, which is the primary beneficiary of information. MEC App 1526 sends a request for predicted QoS to VIS 1580. The request includes radio measurement and locations of the measurement from vUE 1501. Filippou [Para. 0197, 0198], At step 1603 a and At step 1604 a, the VIS 1580 provides the request(s) to the RAN prediction function (RAN PF 1550) and obtains from RAN PF 1550 the radio attributes that indicates predicted radio signal quality related to radio characteristics. Filippou [Para. 0204], the VIS 1580 concatenates the prediction attributes to form a response message to be sent to the requesting MEC App 1526 at 1605 a [Examiner’s Note: The response is the radio context map. The map is sent to MEC App 1526 and MEC App 1526 is the MEC application]. Filippou [Para. 0210] and [FIG. 17], At step 7. the VIS 1580 sends a RESP with all attributes/parameters to MEC App 1526. At step 8, the e-IQN consumer forwards the predictions to Client App 1518. At step 9, Client App 1518 makes an offloading decision based on communicated prediction [Examiner’s Note: MEC App 1526 sends the prediction of radio characteristics to Client 1518 as the e-IQN beneficiary. The prediction is the radio map and also control instruction to the vehicle for decision based on the prediction]. Filippou [Para. 0184], Client app 1518 running on the V-ITS-S 1501, which is camping on NAN 1510, reports its planned journey information to a MEC Host 1540. A corresponding instantiated MEC App 1526 runs as part of a MEC host 1540 collocated with NAN 1510. MEC app 1526 and client app 1518 exchange data over interface 1519 [Examiner’s Note: That the Client app 1518 camps on NAN, MEC App 1526 is part of Host 1540 collocated with NAN and MEC app 1526 and client app 1518 exchanges data over interface 1519 indicates that the existing mobile network channel for sending the prediction]).
For claim 10, Filippou teaches a system for providing radio context map information to a Multi-Access Edge Computing (MEC) application that is deployed at a MEC host and manages a 5G or Beyond 5G (B5G) enabled network device ([Para. 0040], Disclosed embodiments are related to techniques for implementing Vehicle-to-Everything (V2X) communications in Multi-access Edge Computing (MEC) systems, such as Multi-access Edge Computing (MEC) systems [Examiner’s Note: MEC system is the system]. [Para. 0166], The client applications in vehicles collect their environmental perception, upload relevant perception to the application running in edge node; and download high definition (HD) map data that was consolidated in the edge node. [Para. 0184] and [FIG. 15], A Client App 1518 at the vehicle V-ITS-S 1501. A corresponding MEC App 1526 runs at a MEC platform 1532 (e.g., as part of a MEC host 1540). MEC app 1526 and client app 1518 exchange data over interface 1519 [Examiner’s Note: MEC App 1526 is the Multi-Access Edge Computing (MEC) application. MEC App 1526 corresponds to Robot Control System (RCS) of this patent application]. [Para. 0196, 0197 and 0098] and [FIG. 15], MEC App 1526 associated with Client App 1518 sends a request for predicted QoS to VIS 1580. The request includes radio measurement and locations of the measurement from vUE 1501. [Para. 0204] and [FIG. 16], the VIS 1580 concatenates the prediction attributes to form response message to be sent to the requesting MEC App 1526 at 1605 a. The prediction attributes are related to radio characteristics [Examiner’s Note: VIS 1580 provides the radio context map to MEC App 1526]), the system comprising: a Radio Context Map Service (RCMS), registered at and running on an MEC platform of the MEC host ([Para. 0166], The client applications in vehicles collect their environmental perception, upload relevant perception to the application running in edge node; and download high definition (HD) map data that was consolidated in the edge node. [Para. 0196, 0197 and 0098] and [FIG. 15], MEC App 1526 associated with Client App 1518 sends a request for predicted QoS to VIS 1580. The request includes radio measurement and locations of the measurement from vUE 1501. [Para. 0204] and [FIG. 16], the VIS 1580 concatenates the prediction attributes to form response message to be sent to the requesting MEC App 1526 at 1605 a. The prediction attributes are related to radio characteristics [Examiner’s Note: VIS 1580 is the service that provides the radio map to the MEC application MEC App 1526. VIS 1580 corresponds to RCMS]. [Para. 0185] and [FIG. 15 and 25], MEC platform 1532 may be the same or similar as MEC platform 2532 discussed herein. [Para. 0221], while the VIS is the service, the MEC platform owns the Service Registry, and makes the VIS service discovery possible [Examiner’s Note: Making VIS discovery possible indicates VIS 1580 registers on the MEC platform]. [Para. 0257], Mp1 provides service registration 2538, service discovery, for various services, such as the MEC services 2536 provided by MEC host 2502 [Examiner’s Note: Mp1 is the interface between an MEC application and platform]. [Para. 0258], When provided by an application, a MEC service 2536 can be registered in a list of services in the service registries 2538 to the MEC platform 2532 over the Mp1 reference point [Examiner’s Note: VIS 1580 is the service corresponding to MEC service 2536. When provided by an application (not native in the platform), VIS 1580 registers on the platform 1532 corresponding to platform 2532. MEC host is 1540 including platform 1532 in FIG. 15]); the RCMS being configured to subscribe to location and radio information from existing MEC services of the MEC platform ([Para. 0186] and [FIG.2 and 15] , The VIS 1580 may be the same or similar as the MEC VIS 280 discussed previously. [Para. 0072] and [FIG. 2], The VIS 280 may be produced by the MEC app 228 [Examiner’s Note: That VIS 1580 (VIS 280) is produced by an MEC app indicates that an MEC app provides the service VIS 1580 in the MEC platform by the MEC app registering the service in the platform]. [Para. 0185] and [FIG. 15 and 25], MEC platform 1532 may be the same as MEC platform 2532. [Para. 0258] and [FIG. 25], a MEC App 2526 can subscribe to services 2530/2536 [Examiner’s Note: MEC App 2526 referring all MEC applications includes the MEC app that produces service VIS 1580]. [Para. 0259], MEC services 2536 include the radio network information service (RNIS) and location service (LS) [Examiner’s Note: The MEC app that produces service VIS 1580 subscribes to RNIS and LS referred to as 2536]. [Para. 0145], The information on current radio conditions are shared via the MEC platform over an RNIS, and location information is shared via a Location Service (LS) [Examiner’s Note: RNIS and LS are the existing MEC service providing radio and location information]); generate and update a radio context map by processing location and radio information received from the subscribed MEC services and by combining the received location and radio information with additional application related context information provided through the MEC application or any other MEC application deployed at the MEC host ([Para. 0186], The VIS 1580 may be the same or similar as the MEC VIS 280 discussed previously. [Para. 0073] and [FIG. 2], the MEC platform 230 (corresponding to MEC platform 2532) can include a MEC V2X API that provides MEC VIS 280. The VIS 280 can include functionalities (e) gathering and processing information available in Radio Network Information (RNI) API, Location API, in order to provide suitable notifications to the ITS-S 201. [Examiner’s Note: RNI and LS are the subscribed MEC services]. [Para. 0184] and [FIG. 15], MEC app 1526 and client app 1518 exchange data over interface 1519. [Para. 0186], the VIS 1580 consumes requests and provides responses. [Para. 0196, 0197 and 0098], MEC App 1526 associated with Client App 1518 sends a request for predicted QoS to VIS 1580. The request includes radio measurement and locations of the measurement from vUE 1501 [Examiner’s Note: The request received at VIS 1580 includes the additional application related context information from MEC App 1526, the MEC application]. [Para. 0197, 0198], At step 1603 a and At step 1604 a, the VIS 1580 provides the request(s) to the RAN prediction function (RAN PF 1550) and obtains from RAN PF 1550 the radio attributes that indicates predicted radio signal quality related to radio characteristics. [Para. 0204], the VIS 1580 concatenates the prediction attributes to form a response message to be sent to the requesting MEC App 1526 at 1605 a. [Examiner’s Note: The response is the radio context map]. [Para. 0166], The client applications in vehicles that process sensory data to collect their environmental perception, upload relevant perception to the application running in distributed edge nodes; and download high definition (HD) map data that was consolidated in the distributed edge nodes [Examiner’s Note: The Context information is received by the MEC application and used for creating the radio context map]. [Para. 0169], both the vehicle app and the MEC App may periodically request extended e-IQNs in order to maintain updates of the HD maps with real-time data [Examiner’s Note: Updating the map]), provide the radio context map to the MEC application ([Para. 0204], the VIS 1580 concatenates the prediction attributes to form response message to be sent to the requesting MEC App 1526 at 1605 a. The prediction attributes are related to radio characteristics).
Although Filippou teaches that VIS 1580 receiving radio information from the MEC app 1526 ([Para. 0166], The client applications in vehicles that process sensory data (e.g., radar) to collect their environmental perception. Upload relevant perception to the application running in distributed edge nodes [Para. 0098], individual vUEs 201 provide radio information to MEC Hosts 240. Each measurement report is tagged the location of the measurement (e.g., the vUE's 201 current location). [Para. 0184], MEC app 1526 and client app 1518 exchange data. [Para. 0197], at step 1602 a an request is sent to VIS 1580 by MEC app 1526), Svennebring more specifically discloses the radio context in generate and update a radio context map by processing location and radio information received from the subscribed MEC services and by combining the received location and radio information with additional application related context information provided through the MEC application or any other MEC application deployed at the MEC host
Svennebring is directed to providing Link performance prediction technologies. More specifically, Svennebring teaches generate and update a radio context map by processing location and radio information received from the subscribed MEC services and by combining the received location and radio information with additional application related context information provided through the MEC application or any other MEC application deployed at the MEC host ([Para. 0110] and [FIG. 4], The link performance predication information service (LPP-IS) 452 may be produced by the MEC Apps 436 [Examiner’s Note: LPP is both MEC App 436 and MEC platform service]. [Para. 0112], the MEC platform 437 can include a MEC LPP API 451 and provide MEC LPP-IS 452, which can include functionalities: (b) gathering of relevant radio link and/or backhaul link information from the access network for determining and providing LPPs to the UEs 420, (d) gathering and processing information obtained from the RNI API, LS API within the MEC platform 437in order to predict radio network congestion, UE 420 location(s)/mobility, and provide suitable notifications (e.g., LPP notifications) to the UE 420 [Examiner’s Note: LPP is the MEC app that receives radio information and providing notification to UEs. Therefore, LPP functions such as RCS. LPP processes the received radio information, and the radio and location information from RNIS and LS for determining prediction and creates the prediction. LPP also functions such as RCMS]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Filippou, so that the radio context is received and processed with information from RNIS and LS to determine and produce link prediction, as taught by Svennebring. The modification would have dynamically predicted the quality and/or performance of any given radio link and optimized application level behaviors (Svennebring [Para. 0011]).
Claim 11 is an apparatus claim and it does not teach or further define over the limitations recited in claim 2. Therefore, claim 11 is also rejected for similar reasons set forth in claim 2.
For claim 12, Filippou and Svennebring teach the system according to claim 10. The references further teach wherein the RCMS is configured to receive network-based information from an MEC Radio Network Information Service (RNIS) and/or from an MEC Location Service MEC (LS) (Filippou [Para. 0186], The VIS 1580 may be the same or similar as the MEC VIS 280 discussed previously. Filippou [Para. 0072], The VIS 280 may be produced by the MEC app 228, Filippou [Para. 0258], a MEC App 2526 can subscribe to services 2530/2536 for which it is authorized over the Mp1 reference point [Examiner’s Note: MEC App 2526 corresponds to the MEC application]. Filippou [Para. 0259], MEC services 2536 include the radio network information service (RNIS) and location service (LS). [Para. 0145], The information on current radio conditions is shared via the MEC platform over an RNIS, and location information is shared via a Location Service (LS)).
Claim 13 is an apparatus claim and it does not teach or further define over the limitations recited in claim 7. Therefore, claim 13 is also rejected for similar reasons set forth in claim 7.
For claim 14, Filippou and Svennebring teach the system according to claim 10. The references further teach wherein instances of the MEC application run as virtual machines and/or containers within the MEC platform (Filippou [Para. 0141], the embodiments herein include a MEC-based enhancement of the client-server communication, practically implemented as a customized MEC app both as container or VM. Filippou [Para. 0257], MEC Apps 2526 may run as VM on top of the VI 2522 provided by the MEC server 2502, and can interact with the MEC platform 2532 to consume and provide the MEC services 2536 [Examiner’s Note: MEC Apps 2526 corresponds to MEC App 1526. MEC App 1526 corresponds to the MEC application]).
For claim 15, Filippou and Svennebring teach the system according to claim 10. The references further teach wherein connectivity between the 5G or B5G-enabled network device and the MEC application is provided by the 5G or B5G network data plane exploiting a dedicated User Plane Function (UPF) deployed within the MEC system (Filippou [Para. 0184], A corresponding instantiated MEC App 1526 runs in computational resources (e.g., virtualization infrastructure) at the data network near or at a MEC platform 1532 (e.g., as part of a MEC host 1540 collocated with NAN 1510). MEC app 1526 and client app 1518 exchange data over interface 1519. Filippou [Para. 0249] and [FIG. 25], The VI 2522 includes a data plane 2524 coupled to the MEC platform 2522 via an MP2 interface [Examiner’s Note: MEC app 1526 is the MEC application. Interface 1519 is the connectivity. MEC app 1526 exchanges data with Client 1518 using virtualization infrastructure coupled to platform. Virtualization infrastructure includes data plane 2524]. Filippou [Para. 0254], The MEC host 2502 is an entity that contains an MEC platform 2532 and VI 2522 which provides network resources for the purpose of running MEC Apps 2526 [Examiner’s Note: MEC Apps 2526 is MEC app 1526]. Filippou [Para. 0277], a user plane function (UPF) of the 5GS is mapped into the MEC architecture 2500 as the MEC data plane 2524. The UPF handles the user plane path of PDU sessions. Additionally, UPF provides the interface to a data network (DN) and supports the functionality of a PDU session anchor [Examiner’s Note: UPF corresponding to MEC data plane 2524 is deployed within virtualization infrastructure and within the MEC host 2502. FIG. 25 illustrates architecture 2500. Therefore, UPF is a dedicated to the MEC system]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHU LIU whose telephone number is (571)272-5186. The examiner can normally be reached Monday - Friday 9:00 am - 5:00 pm.
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, REBECCA E SONG can be reached at (571)270-3667. 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.
/S.L./Examiner, Art Unit 2417
/REBECCA E SONG/Supervisory Patent Examiner, Art Unit 2417
Prosecution Insights