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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/25/2025 has been entered.
Response to Arguments
Applicant’s arguments with respect to the claim(s) have been considered but are moot because of the new ground of rejection.
Election/Restrictions
Applicant’s election without traverse of Group I (claims 40-52), in the reply filed on 01/13/2025 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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 40-44, 48, 49, 52, 65 and 70-72 is/are rejected under 35 U.S.C. 103 as being unpatentable over Multi-access Edge Computing (MEC); Phase 2: Use Cases and Requirements, ETSI GS MEC 002 V2.l.l, 25 October 2018 herein ETSI in view of US 20200137648 A1 herein Tata.
Claim 40, ETSI discloses a mobile device comprising:
interface circuitry to obtain network-related information from an edge compute node; (A.20.2, A.23.2, a MEC service available via a MEC platform, radio network information to a dedicated application in order to identify wireless network congestion, by service providers, since reception of network information thus interface circuitry);
(since a mobile device, thus memory for storing of program code) (A.20.2, A.23.2, a dedicated application is provided network information);(A.20.2, A.23.2, a MEC service available via a MEC platform, radio network information to a dedicated application in order to identify wireless network congestion, by service providers; off-loading computation resource required by the application by using rich compute resource m a MEC host); and
at least one programmable circuit (since a mobile device, thus processor), to operate the client-side application to:
at least one of adapt one or more network parameters or offload one or more application tasks to the edge compute node based on the network-related information (A.20.2, A.23.2, offloading of tasks for edge compute nodes to MEC).
ETSI may not explicitly disclose detect a trigger event based on the network-related information, the trigger event corresponding to at least one of a message timeout or a duplicated acknowledgement ; after the detection of the trigger event, classify the trigger event as a congestion event or a non-congestion event based on a channel quality measurement and an amount of allocated resource blocks obtained from the network-related information; and at least one of adapt one or more network parameters or halt transmission of the mobile device based on the classification.
Tata discloses detect a trigger event based on the network-related information, the trigger event corresponding to at least one of a message timeout or a duplicated acknowledgement (0044, detection loss based on timeout and duplicate ACKs);
after the detection of the trigger event, classify the trigger event as a congestion event or a non-congestion event based on a channel quality measurement and an amount of allocated resource blocks obtained from the network-related information (0070-0071, changes in congestion window for transmission based on a detection loss, thus classification; 0070-0071, CQI dip due to RTO/change in distance, since dip in CQI is noticed, thus CQI measurements on allocated resources); and at least one of adapt one or more network parameters or halt transmission of the mobile device based on the classification (Fig. 11; 0070, The communication stalls until UE1 requests for grant, which is in sync with the congestion window (cwnd) as depicted in FIG. 9A-9B).Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify ETSI to include congestion window and channel quality as taught by Tata so as to maintain the best possible link quality (0003).
Claim 41, ETSI discloses the mobile device of claim 40, wherein the network-related information includes at least one of a capacity information or connection information (6.3.1, when an MEC system supports the feature User Apps, the system shall, in response to a request by the user, support the establishment of connectivity between a UE and an instance of a specific MEC application, thus TPR entity), the one or more network parameters are transport protocol parameters of a transport protocol used to transport traffic between the mobile device the edge compute node (6.3.1, fulfilling requirements of the application regarding the UE, wherein requirements of the application can include latency, energy consumption, location, compute resources, storage resources, network capability, security conditions), and one or more of the at least one programmable circuit is to: adapt the transport protocol parameters based on the capacity and connection related information (6.3.1, fulfilling requirements of the application regarding the UE, wherein requirements of the application can include latency, energy consumption, location, compute resources, storage resources, network capability, security conditions).
Claim 42, ETSI discloses he mobile device of claim 42, wherein one of more of the at least one programmable circuit is to: after the detection the trigger event, cause a request message to be sent to a Radio Network Information (RNI) service provided by the edge compute node via an RNI Application Programming Interface (API) (A.20.2, when network congestion is identified, the MEC application can communicate with counterpart applications running on devices, to request them to activate direct device-to-device communication network capabilities through application-specific means; 6.2.2, a MEC system shall support two instances of a MEC application running on different MEC hosts to communicate with each other, and this allows application-specific procedures to move information from one application instance to another, in order to maintain continuity of the service provided by the application as the UE moves around).
Claim 43, ETSI discloses the mobile device of claim 40, wherein the one or more of the at least one programmable circuit is to: cause a request message to be sent to a location service provided by the edge compute node via a location API (A.7.2, The application can either be running permanently on the MEC host, or based on demand from the operator, possibly in response to a request from a third-party; the application collects location-related information from the UEs connected to the radio node(s) which the MEC host is associated with. Depending on the application, specific UEs, specific categories of UEs, or all UEs need to be tracked, possibly anonymously (based on authorization), the application performs the required (application-specific) analysis and provides the analysis results to an external entity; and obtain location information of the mobile device from the location service via the location API (A.7.2, the MEC application needs to be able to connect to external applications).
Claim 44, ETSI discloses the mobile device of claim 41, wherein one or more of the at least one programmable circuit is to: subscribe to an RNI service provided by the compute node (6.2.2, a MEC system shall support two instances of a MEC application running on different MEC hosts to communicate with each other, and this allows application-specific procedures to move information from one application instance to another); and receive the capacity and connection related information from the RNI service via an RNI API when the edge app detects a trigger event (6.2.2, a MEC system shall support two instances of a MEC application running on different MEC hosts to communicate with each other, and this allows application-specific procedures to move information from one application instance to another, in order to maintain continuity of the service provided by the application as the UE moves around).
Claim 48, ETSI discloses the mobile device of claim 40, wherein one or more of the at least one programmable circuit is to: select an interaction pattern based on one or more performance requirements of the client-side application, the interaction pattern including at least one of a request/response pattern or a publish/subscribe pattern (A.20.2, when network congestion 1s identified, the MEC application can communicate with counterpart applications running on devices, to request them to activate direct device-to-device communication network capabilities through application-specific means).
Claim 49, ETSI discloses the mobile device of claim 48. ETSI discloses wherein the one or more performance requirements include at least one of service reliability requirements, end-to-end latency requirements, a quality of service (QoS) requirements, subscription requirements or restrictions, user equipment (UE) type (A.20.2, A.20.3).
Claim 52, ETSI discloses the mobile device of claim 40. ETSI discloses wherein the edge app is a Multi-access Edge Computing (MEC) app and the edge compute node is a MEC server (A.20.2-A.23.3).
Claim 65, as analyzed with respect to the limitations as discussed in claim 40.
Claim 70, as analyzed with respect to the limitations as discussed in claims 40 and 46.
Claim 71, as analyzed with respect to the limitations as discussed in claim 48.
Claim 72, as analyzed with respect to the limitations as discussed in claim 49.
Claim(s) 46-47 and 66-69 is/are rejected under 35 U.S.C. 103 as being unpatentable over ETSI in view of Tata in view of PAVEL MACH et al. Mobile Edge Computing: A Survey on Architecture and Computation Offloading. IEEE Communications Surveys & Tutorials, 15 March 2017, Vol. 19, pp. 1628-1656 herein Pavel.
Claim 46, ETSI discloses the mobile device of claim 40. ETSI may not explicitly disclose wherein one or more of the at least one programmable circuit is to: based on the trigger event being classified as the congestion event, adapt the one or more network parameters by at least one of a reduction of a congestion window (CW) or implementation of a congestion control algorithm; and based on the trigger event is being classified as the non-congestion event, the adapt the one or more network parameters by halting transmission without reducing the CW.
Pavel discloses based on the trigger event being classified as the congestion event, adapt the one or more network parameters by at least one of a reduction of a congestion window (CW) or implementation of a congestion control algorithm (and a greedy offloading policy (UE schedules data waiting in the buffer whenever the local CPU or the transmission unit is idle)); and based on the trigger event is being classified as the non-congestion event, the adapt the one or more network parameters by halting transmission without reducing the CW (a module decides, during each time slot, whether an application waiting in a buffer should be processed locally or at the MEC while minimizing an execution delay; and performance of the proposed algorithm is compared to a local execution policy ( computation done always locally), a cloud execution policy (computation performed always by the MEC server), and a greedy offloading policy (UE schedules data waiting in the buffer whenever the local CPU or the transmission unit is idle)). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify ETSI to include computational offloading as taught by Pavel so as to extending battery lifetime by offloading energy consuming computations and providing higher data storage capabilities to the users (Introduction).
Claim 47, ETSI discloses the mobile device of claim 40. ETSI may not explicitly disclose wherein one or more of the at least one programmable circuit is to:
classify the trigger event as the congestion event based on the trigger even corresponding to at least one of a message timeout or a receipt of a duplicated acknowledgement, and classify the trigger event as the non-congestion event based on the trigger event corresponding to at least one of a signal strength measurement at or below a first threshold or a channel quality measurement at or below second threshold.
Pavel discloses classify the trigger event as the congestion event based on the trigger even corresponding to at least one of a message timeout or a receipt of a duplicated acknowledgement (section V, in case the UE performs all computation by itself (i.e., no offloading is performed), the execution delay (DI) represents solely the time spent by the local execution at the UE), classify the trigger event as the non-congestion event based on the trigger event corresponding to at least one of a signal strength measurement at or below a first threshold or a channel quality measurement at or below second threshold (Section V: part 2). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify ETSI to include computational offloading as taught by Pavel so as to extending battery lifetime by offloading energy consuming computations and providing higher data storage capabilities to the users (Introduction).
Claim 66, as analyzed with respect to the limitations as discussed in claim 46.
Claim 67, as analyzed with respect to the limitations as discussed in claim 46.
Claim 68, as analyzed with respect to the limitations as discussed in claim 47.
Claim 69, as analyzed with respect to the limitations as discussed in claim 47.
Claim(s) 50 and 51 is/are rejected under 35 U.S.C. 103 as being unpatentable over ETSI in view of Tata in view of US 20210014755 A1 herein Caceres.
Claim 50, ETSI discloses the mobile device of claim 40. ETSI discloses wherein the client application is an extended In-advance Quality of Service Notification (e-IQN) consumer, the network-related information includes one or more e-IQN attributes, and one or more of the at least one programmable circuit (A.20.2-A.23.3, A.25.1; QOS and end-to-end quality) is to operate to the client-side app to:
ETSI may not explicitly disclose obtain an e-IQN response message from an e-IQN producer; and cause an e-IQN request to be sent to the e-IQN producer the e-IQN request including a planned route, the planned route including one or more waypoints along the planned route and corresponding one or more expected arrival times for of the one or more waypoints, the e-IQN response message based on the e-IQN request.
Caceres discloses obtain an e-IQN response message from an e-IQN producer (0071); and cause an e-IQN request to be sent to the e-IQN producer the e-IQN request including a planned route, the planned route including one or more waypoints along the planned route and corresponding one or more expected arrival times for of the one or more waypoints (0035, navigation information acquired from UE, which contains route with hops and arrival times; 0069, request with navigation information), the e-IQN response message based on the e-IQN request (0069-0071). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify ETSI to include navigation information as taught by Caceres so as to in the provisioning of limited network resources in cells that the end device does not ultimately enter/access (0001).
Claim 51, ETSI discloses the mobile device of claim 50. ETSI may not explicitly disclose wherein the one ore more e-IQN attributes include: one or more predicted radio conditions corresponding to the one or more waypoints at the corresponding one or more expected arrival times; and one or more predicted computing resources of one or more edge compute nodes serving the one of the one or more waypoints at the corresponding one or more expected arrival times.
Caceres discloses wherein the one or more e-IQN attributes include: one or more predicted radio conditions corresponding to the one or more waypoints at the corresponding one or more expected arrival times (0035, 0069-0071); one or more predicted computing resources of one or more edge compute nodes serving the one of the one or more waypoints at the corresponding one or more expected arrival times (0069-0071). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify ETSI to include navigation information as taught by Caceres so as to in the provisioning of limited network resources in cells that the end device does not ultimately enter/access (0001).
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20180242204 A1 - Embodiments of the present invention relate to the communications field, and provide an MEC platform handover method, apparatus, and system. The method includes: receiving a handover notification sent by a handover notification device, where the handover notification device is a source access network device of to-be-handed-over UE or a target MEC platform of the to-be-handed-over UE; determining a TEID of the to-be-handed-over UE according to the handover notification; obtaining context of the to-be-handed-over UE according to the TEID of the to-be-handed-over UE; and sending the context to the target MEC platform. The present invention resolves a problem that provision of application data by an MEC platform to UE is interrupted when the UE is being handed over between access network devices, thereby providing continuous services to the UE. The present invention is applicable to a handover between MEC platforms.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mehmood B. Khan whose telephone number is (571)272-9277. The examiner can normally be reached M-F 9:30 am-6:30 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, Nishant Divecha can be reached on (571) 270-3125. 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.
/Mehmood B. Khan/ Primary Examiner, Art Unit 2468