Patent Drafting Analysis of Universidad de Vigo’s Decentralized Edge Computing Node Management via UE | US 2024/0281263 A1
Patent Drafting Analysis of Universidad de Vigo's Decentralized Edge Computing Node Management via UE | US 2024/0281263 A1
A structural and strategic analysis of US 2024/0281263 A1 examining claim architecture, means-plus-function drafting risks, critical coverage gaps, and prosecution positioning for UE-controlled edge computing node management.
Spec Words
6,200
Across 6 sections
Draft now ↗
Total Claims
7
1 independent · 6 dependent
Draft now ↗
Figure Sheets
9
System architecture, network topology, sequence diagrams
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 50% of total words (~3,100 of ~6,200), providing multi-embodiment coverage across seven figures depicting system architecture, network topology, and five-step sequence diagrams. The claim set is unusually lean at only 7 claims — 1 independent and 6 dependent — which is well below the software/telecom industry norm of 15–25 claims. Figure coverage is strong across 9 sheets depicting the UE-edge node architecture (FIG. 1), network deployment scenarios (FIGS. 2–4), and detailed protocol sequence flows (FIGS. 5–7 with continuations).
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 9 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Block diagram showing the two main system elements: the UE (119) containing edge manager module (123), edge application repository (126), edge content storage (124), and client applications (120), alongside the edge computing node (101) with application lifecycle manager (103), relocation module (107), onboarding module (108), and edge application repository (110).Search in Eureka ↗ | System architecture |
| FIG. 2 | Network topology diagram showing core network (201), edge data network (203) with base station RAN 1 (204) and edge computing node EDGE 1 (205), and UE (207) performing application onboarding, uploading, and lifecycle management via dashed connections (208–210).Search in Eureka ↗ | System architecture |
| FIG. 3 | Application handover scenario diagram showing two independent core networks (301, 302), edge data networks (305, 306) with edge nodes (309, 310), and the UE (315/323) performing context save at EDGE 1 and application onboarding/uploading/lifecycle/context upload at EDGE 2 following handover through coverage gap.Search in Eureka ↗ | Claim support |
| FIG. 4 | Simultaneous dual-connection handover scenario showing UE (413) maintaining concurrent radio links to RAN 1 (407) and RAN 2 (408) during application context relocation (420), with direct end-to-end communication link (420) between edge computing nodes (409, 410) established via UE.Search in Eureka ↗ | Claim support |
| FIG. 5 | Five-step sequence diagram for the FIG. 2 embodiment showing protocol message flows between UE components (edge manager 504, edge app repository 505, client app 506, TX/RX 507/508) and edge node components (RAN 508, edge app repository 509, onboarding 510, APP LCM 511, edge app 512) covering network connection, edge app onboarding, upload, instantiation, and activation steps (messages 513–534).Search in Eureka ↗ | Flow diagram |
| FIG. 6 | Multi-part sequence diagram for the FIG. 3 context-relay embodiment, showing context transfer (steps 625–635) where UE edge manager (612) retrieves application context data from EDGE NODE 1 relocation module (610) over a secure channel, stores it in edge context storage (614), onboards and instantiates at EDGE NODE 2, then performs cleanup of the old instance.Search in Eureka ↗ | Flow diagram |
| FIG. 7 | Multi-part sequence diagram for the FIG. 4 direct edge-to-edge relocation embodiment, showing secure tunnel establishment between relocation modules (710, 717) via UE (702), application context transfer over these tunnels (messages 736–741), and final activation and cleanup steps (messages 742–747).Search in Eureka ↗ | Flow diagram |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Claims
Claim Architecture Analysis
The patent presents only one independent claim (Claim 1), structured as a method claim covering decentralized management of edge computing nodes controlled by at least one UE. The dependent:independent ratio of 6:1 is within the telecom/software norm at the lower bound, but the absolute claim count of 7 is critically low for a technology of this complexity. The claim strategy relies almost entirely on a single independent method claim with means-plus-function language throughout, with dependent Claims 2–7 adding relocation modules, context migration mechanisms, application repositories, and concurrent connectivity — but no separate apparatus or system independent claim is filed.
Core inventive concept: Claims 1 and 3 address the problem of centralized edge computing management (requiring an orchestrator or management entity) by placing direct control in the UE itself through an 'edge manager module' with 'means for onboarding application configurations,' 'means for managing application lifecycles,' and 'means for triggering migration of edge applications and their context between edge computing nodes' — enabling UE devices to manage edge computing systems without a central management entity in the network.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method for decentralized management of edge computing nodes that are directly controlled by at least one user equipment device | comprising | At each user equipment: edge manager module with (1) means for onboarding application configurations at edge computing nodes, (2) means for managing application lifecycles at edge computing nodes, (3) means for triggering migration of edge applications and their context between edge computing nodes; At each edge computing node: onboarding module with means for receiving and storing application onboarding configurations sent by the edge manager modules of UE devices; lifecycle manager module with means for instantiation, updating, terminating, and deleting edge applications as commanded by the edge manager modules of UE devicesSearch prior art ↗ |
Claim Dependency Tree
1 Method for decentralized UE-controlled edge computing node management; edge manager module at UE with onboarding, lifecycle, and migration means; onboarding and lifecycle modules at edge nodesSearch Claim 1 prior art ↗
2 Adds: relocation module at each edge computing node for edge application relocation operations as requested by edge manager moduleSearch in Eureka ↗
3 Adds: UE further includes context storage module and means for edge manager to request context data of running edge applications, temporarily store context data, onboard new edge app configurations, instantiate apps, and add context data — enabling relocation without requiring direct edge node interconnectionSearch in Eureka ↗
4 Further: each edge computing node includes edge application repository module to locally store edge application imagesSearch in Eureka ↗
5 Further: each terminal includes terminal application repository module to locally store edge application imagesSearch in Eureka ↗
6 Further: each edge node includes edge application repository AND each terminal includes terminal application repositorySearch in Eureka ↗
7 Further: UE devices set direct concurrent radio connections with a plurality of edge computing nodes to exchange edge application configurations, contexts, images, or any other informationSearch in Eureka ↗
| Metric | This Application | Software / Cloud Norm |
|---|---|---|
| Total claims | 7 | 15 – 25 |
| Independent claim count | 1 | 3 – 5 |
| Dependent : Independent ratio | 6.0 : 1 | 4 – 8 : 1 |
| Method claims present? | Yes — Claim 1 | Common |
| System / apparatus claims? | No | Common |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Drafting Quality
Drafting Quality Signals
The specification is technically rich with detailed multi-embodiment sequence diagrams and strong written description support across paragraphs [0028]–[0091], but the claims suffer two serious structural risks: pervasive means-plus-function language throughout Claim 1 triggers §112(f) interpretation for all key limitations, and the total absence of apparatus/system independent claims leaves the patent vulnerable to straightforward design-arounds. Claims 4 and 5 add genuine fallback value by capturing dual-repository configurations, but Claims 4–6 share a near-redundant dependency chain off Claim 3.
⚠️
Antecedent Basis
Claim 3 introduces 'a context storage module' and then refers to 'the context storage module' correctly, providing clean antecedent basis for this element. However, Claim 1's 'edge manager module with means for...' introduces a module-level element in sub-claim (i) and the 'means for triggering the migration' in sub-claim (i)(3) references 'edge computing nodes' that were introduced in the preamble — this is adequate but the preamble's 'at least one user equipment device' creates ambiguity when Claim 1(a) says 'At each user equipment,' potentially suggesting a singular UE context inconsistent with the plural preamble. An examiner may require clarification of this consistency.
⚠️
Spec–Claim Consistency
The specification provides strong but unevenly distributed support. FIG. 1 and paragraphs [0032]–[0033] map directly to the 'edge manager module' (123), 'onboarding module' (108), and 'lifecycle manager module' (103) recited in Claim 1. The 'context storage module' of Claim 3 is supported by element 124 in FIG. 1 and paragraph [0033]. However, Claim 7's 'direct concurrent radio connections with a plurality of edge computing nodes' maps to the FIG. 4 embodiment and paragraphs [0047]–[0048], but this feature is presented as an optional design choice rather than a defined structural element — a weakness an examiner could exploit to require narrowing.
⚠️
Transition Word Usage
All claims use 'comprising' — the open-ended transition — which is strategically correct and preserves the broadest claim scope by permitting additional unrecited elements. However, the opportunity to use 'wherein' clauses to modularize limitations was missed; instead, limitations are nested in a complex multi-level 'a ... with 1. means for... 2. means for... 3. means for...' structure that could complicate claim construction if the entire module structure is interpreted as a single means-plus-function element rather than three separate functional modules. A cleaner drafting approach would separate the three 'means for' sub-elements into discrete wherein clauses.
⚠️
§112(f) Means-Plus-Function Risk
This is the most critical drafting risk in the patent: Claim 1 uses explicit 'means for' language throughout all three key functional limitations — 'means for onboarding,' 'means for managing application lifecycles,' and 'means for triggering migration' — as well as in the edge node's 'means for receiving and storing,' 'means for instantiation,' 'means for updating,' 'means for terminating,' and 'means for deleting.' Under §112(f), each of these will be construed to cover only the corresponding structures disclosed in the specification and their equivalents, dramatically narrowing claim scope to the specific modules described in FIGS. 1–7 (edge manager module 123, onboarding module 108, APP LCM 103). A design-around that uses functionally equivalent structures not described in the spec may escape infringement.
⚠️
§101 Eligibility Risk
Claim 1 is a method claim with a hardware tie-in through the UE device ('user equipment device') and the physical edge computing nodes, which provides a meaningful §101 defense under the machine-or-transformation test. However, the Alice/Mayo two-step analysis is non-trivial: the abstract idea risk is that 'managing' and 'onboarding' are abstract concepts, and the examiner may argue that the 'means for' limitations are merely functional description of the abstract idea. The strongest §101 defense elements are the specific physical context storage module (Claim 3) and the concurrent radio connections (Claim 7), which ground the invention in physical hardware. A software/cloud art unit examiner may still issue a §101 rejection requiring claim amendments to add specific technical implementation language.
⚠️
Dependent Claim Fallback Quality
Claims 2 and 3 add genuinely distinct and valuable fallback positions: Claim 2 adds the relocation module at the edge node, while Claim 3 adds the critical UE-side context storage module with the full context relay procedure — this is the core technical innovation of the patent. Claims 4, 5, and 6 form a partially redundant set, with Claim 6 being the logical combination of Claims 4 and 5 (both edge node and terminal repositories), which is acceptable but wastes two claim slots. Claim 7 adds concurrent multi-radio connectivity, which is a distinct and valuable fallback. The total of 7 claims for a technology this complex — covering three distinct deployment scenarios across 9 figure sheets — is a significant strategic underutilization.
⚠️
Abstract Quality
The abstract describes the UE assuming 'direct control of the edge nodes through an integrated edge manager module' and mentions context migration 'even in scenarios without direct connectivity between edge nodes' — the latter is the key distinguishing feature over prior art. However, an examiner reading only the abstract may overweight the generic 'managing edge computing nodes' framing and miss the specific decentralized, UE-centric, connectivity-agnostic migration mechanism that is the true novel contribution. The abstract does not mention the means-plus-function architecture or the secure channel communication protocol that are central to the claim scope, making it less useful for prior art search anchoring.
✅
Figure Support Quality
Figure support is comprehensive and well-organized across 9 sheets. The 'edge manager module' (Claim 1) maps to element 123/504/612/712 across FIGS. 1, 5, 6, 7. The 'onboarding module' maps to elements 108/510/608/708 in FIGS. 1, 5, 6, 7. The 'context storage module' (Claim 3) maps to element 124/614 in FIGS. 1 and 6. The 'relocation module' (Claim 2) maps to elements 107/610/618/710/717 across FIGS. 1, 6, 7. The concurrent radio connection scenario (Claim 7) is depicted in FIG. 4 and elaborated in FIG. 7. No claim limitation appears to lack figure support, which is the patent's strongest drafting quality dimension.
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Scorecard
Strategic Intent Scorecard
Multi-dimensional assessment of this application's patent strategy quality, based on claim structure, specification depth, and prosecution positioning.
Claim Breadth
2.5
Prosecution Defensibility
2
Spec–Claim Consistency
4.2
Dependent Claim Coverage
3
Claim Type Diversity
1.5
Figure Support Quality
4.5
Key observation: Figure Support Quality scores highest (4.5/5) because every structural claim limitation — from the edge manager module to the context storage module to the relocation module — has direct, labeled correspondence across multiple figures (FIGS. 1–7), providing robust written description support that would survive §112(a) challenges. Claim Type Diversity scores lowest (1.5/5) because the entire patent relies on a single independent method claim with pervasive means-plus-function language, with no apparatus, system, or CRM independent claims filed — a competitor implementing the same decentralized edge management concept using a product-form claim may be able to design around the patent by not performing a 'method' in the claimed sense. Practitioners should immediately file continuation applications with apparatus/system independent claims and non-means-plus-function functional language to close these coverage gaps.
See how your own draft compares — Open Eureka IP Drafting →
Critical Gaps
3 Critical Gaps in This Claim Set
A senior-attorney lens on the three highest-priority structural weaknesses — what each exposes in prosecution and litigation, and what a stronger filing would have done differently.
🔒
3 Critical Gaps in This Claim Set
See the full attorney-level analysis of what this application leaves unprotected — and how to draft it more defensively for your own filings.
No apparatus independent claim filed Means-plus-function narrows all key claims Offline migration scenario lacks independent claim
Unlock Full Analysis — Free Frequently asked questions
US 2024/0281263 A1 — key questions answered
Still have questions? PatSnap Eureka can answer them from patent data instantly. Search in Eureka
Disclaimer: This analysis is generated by PatSnap Eureka AI based on publicly available patent data from the USPTO. It does not constitute legal advice and should not be relied upon as such. Patent data may be subject to change as prosecution progresses. Scores and assessments reflect automated analysis and may not capture all relevant legal or technical nuances. Always consult a qualified patent attorney for formal legal opinions on patentability, freedom to operate, or infringement.
Ask anything about this patent.
PatSnap Eureka searches patents and data to answer instantly.
PatSnap Eureka searches patents and data to answer instantly.
Powered by PatSnap Eureka
Link copied to clipboard