Most NTN IP work fails at the first step. A team searches "NTN patent", gets tens of thousands of hits spanning launch vehicles, antenna manufacturing, modem silicon and scheduling algorithms, and concludes either that everything is crowded or that nothing is relevant. Both conclusions are artefacts of the search, not of the technology. The alternative is a taxonomy. Decompose the system into technology areas, identify the engineering problem inside each area, locate the mechanisms that solve it, and only then ask the IP questions: what is the invention surface, what prior art exists, what standards exposure applies, what product layer implements it, and what commercial value follows.
- 01Technology area
- 02Engineering problem
- 03Invention
- 04Prior art
- 05Patent application
- 06Patent family
- 07Standards
- 08Product
- 09Competitive IP
- 10Commercial value
This article sets out the 15 technology areas Hashi uses when scoping NTN invention harvesting, filing programmes, landscapes, white-space studies, FTO work and due diligence. It deliberately avoids ground already covered elsewhere on this site: spectrum coordination mechanics, convergence architecture and regenerative payload landscapes each have dedicated articles linked at the end.
Related NTN reading
- NTN Spectrum Sharing: Where Spectrum Coordination Becomes an IP Problem
Interference coordination, dynamic allocation and spectrum white space
- NTN Convergence: Satellite, Cellular, Modems, Vehicles and Software
Cross-domain interfaces and product-to-patent convergence
- Regenerative NTN Payload Patent Landscape
Onboard processing, satellite gNB and inter-satellite links
- Non-Terrestrial Network Standard Essential Patents
Broad NTN SEP landscape and the four-pillar framework
How each technology area is analysed
Every area below follows the same nine-part structure: the technical problem, the engineering mechanisms, where invention can occur, the claim perspectives that may arise, the prior-art questions to ask, the specifications to review, the product layer that implements it, the IP intelligence to monitor, and the Hashi service that applies. The language is deliberately careful throughout. Nothing here says an area is patentable. Patentability is a claim-level determination against specific prior art under specific law. What a taxonomy gives you is a defensible map of *where to look*.
01 Waveform & PHY
02 Network Architecture & Convergence
03 Mobility & Session Management
04 Payload & Platform
05 Network Management & AI/ML
06 Spectrum Management
07 Protocol & Signaling
08 Applications & Verticals
09 Emerging & Cross-Domain
10 Ground Segment & Terminal
11 Security & Trust
12 IoT & Low-Power NTN
13 Testing & Conformance
14 Timing, Sync & Positioning
15 Direct-to-Device
= High-quality, enforceable patent draft
Area 1 — Waveform & PHY Layer
Satellite links impose physical conditions terrestrial radio does not: propagation delays measured in tens of milliseconds, Doppler shifts that change continuously with orbital velocity, low link budgets, and geometry that varies over the duration of a single session. The physical layer must remain demodulable under conditions that terrestrial numerology and procedures were never designed for.
Engineering mechanisms that address the problem
- Doppler estimation and pre-compensation at the terminal and network side
- Timing advance derivation from ephemeris, GNSS position or measurement feedback
- Frequency pre-compensation and residual frequency offset correction
- Numerology, subcarrier spacing and cyclic prefix selection for long-delay links
- Random access preamble design and extended RACH windows
- HARQ handling, disabling and feedback strategies under long round-trip time
- Link adaptation, MCS selection and power control adapted to satellite geometry
- Reference signal and synchronisation signal design for wide beams
**Where invention can occur.** Invention typically sits in the specific computation: how a compensation value is derived, from which inputs, at which node, at what update rate, and how errors are bounded when inputs are stale or unavailable. Fallback behaviour — what happens when GNSS is lost, ephemeris is outdated or the terminal is stationary versus fast-moving — is often where genuine technical contribution lives. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** Depending on the contribution, PHY-layer work may be expressed as terminal-side methods, network-node methods, system claims covering the coordinated exchange, device claims covering the processing chain, or processor/computer-readable-medium forms where legally appropriate. Which forms are supportable depends on the technical contribution and applicable law.
Prior-art questions an R&D/IP team should ask
- Is the compensation algorithm itself novel, or only its parameter values?
- Does terrestrial high-speed-train or aeronautical prior art already disclose the mechanism?
- Has the same computation been published in 3GPP contributions before the priority date?
- Is the invention in the derivation, the signalling of the result, or both?
- Does satellite communications literature predating 5G NTN disclose equivalent processing?
**Standards and specifications to review.** 3GPP TS 38.211/38.213/38.214 and TS 38.321 as adapted for NTN, the NTN work-item and study-item outputs, and RAN1 contribution records that show which mechanisms were debated and when. **Product and system layers that implement it.** Baseband modem silicon and firmware, terminal RF front-end, gNB scheduler and PHY software, and satellite payload signal processing where regenerative. **IP intelligence to monitor.** Modem vendor filing patterns per mechanism, RAN1 contribution volume by company, jurisdictional split of PHY families, and continuation activity around compensation and RACH families. **Relevant Hashi service.** Prior art search, patentability assessment and patent drafting for PHY-layer inventions; standards mapping where the mechanism touches normative specification text.
Area 2 — Network Architecture & Convergence
An NTN deployment must present itself to the core network and to applications as a coherent access network, despite the access segment moving, changing topology and sometimes routing through multiple hops. Architecture decisions determine which functions sit on the satellite, on the gateway, in the core, or at the edge.
Engineering mechanisms that address the problem
- Functional split decisions between space and ground segments
- Transparent versus regenerative architecture selection and hybrid modes
- Feeder-link and service-link separation in the control plane
- Integration of NTN access into 5G core procedures and identifiers
- Multi-orbit and multi-operator architecture coordination
- Edge function placement relative to the access segment
**Where invention can occur.** Architecture-level invention tends to concern how state is distributed and reconciled: which node holds context, how context migrates as topology changes, and how the core is shielded from access-segment volatility. Interface definitions between segments — what is exchanged, when, and in what representation — are frequently the concrete contribution. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** Architecture contributions often support system claims and network-node methods, sometimes with corresponding terminal-side claims covering the behaviour the terminal must exhibit. Care is needed to ensure a claim recites technical mechanism rather than a topology diagram.
Prior-art questions an R&D/IP team should ask
- Is the split itself new, or is only its application to satellites new?
- Do terrestrial C-RAN, fronthaul and functional-split patents already cover the mechanism?
- Has the architecture been described in ETSI, ITU-R or operator white papers before the priority date?
- Is the invention in the architecture or in a specific procedure inside it?
**Standards and specifications to review.** 3GPP TR 38.821 architecture options, TS 23.501 as extended for satellite access, and SA2 documentation covering NTN core integration. **Product and system layers that implement it.** Core network software, gateway systems, satellite payload controllers, orchestration platforms and network management systems. **IP intelligence to monitor.** Operator and vendor architecture filings, cross-licensing posture between space and terrestrial players, and which architecture options attract disproportionate filing density. **Relevant Hashi service.** Patent landscape and portfolio development; technology due diligence where an architecture claim underpins a valuation.
Area 3 — Mobility & Session Management
In LEO systems the cell moves, not just the user. Earth-moving cells sweep across terminals, satellites set below the horizon on predictable schedules, and sessions must survive handovers driven by orbital mechanics rather than user motion. Conventional measurement-triggered mobility is poorly matched to this environment.
Engineering mechanisms that address the problem
- Ephemeris-assisted and time-triggered handover decisions
- Conditional handover configuration with location and time conditions
- Earth-fixed versus earth-moving cell mapping and cell re-anchoring
- Feeder-link switchover coordination with service-link continuity
- Tracking-area management under moving coverage
- Session continuity, context transfer and interruption minimisation
- Paging and reachability under intermittent visibility
**Where invention can occur.** The invention surface concentrates on prediction and pre-configuration: how future visibility is computed, how conditions are expressed and signalled, how the network pre-positions context ahead of a predictable event, and how failure cases are recovered when prediction is wrong. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** Typically network-node methods and terminal methods paired as a coordinated procedure, plus system claims where the technical effect arises from the interaction. Where the contribution is a data structure exchanged between nodes, the claim must tie it to a technical outcome.
Prior-art questions an R&D/IP team should ask
- Does terrestrial conditional-handover prior art disclose the trigger structure?
- Is ephemeris-based prediction already published in satellite mobility literature?
- Is the contribution the prediction, the signalling, or the pre-configuration?
- Does aeronautical or maritime mobility prior art anticipate the mechanism?
**Standards and specifications to review.** 3GPP TS 38.331 and TS 38.300 NTN mobility procedures, TS 23.502 procedures, and RAN2 contribution history on conditional handover for NTN. **Product and system layers that implement it.** RRC software in terminal and gNB, core mobility management functions, constellation planning and scheduling systems. **IP intelligence to monitor.** Filing density around conditional handover variants, which companies file terminal-side versus network-side, and how families are extended into constellation-operations claims. **Relevant Hashi service.** Prior art search and claim strategy; patent-to-product mapping where mobility behaviour is observable in deployed systems.
Area 4 — Payload & Platform Architecture
The payload determines what the access network can do. Beyond the regenerative-versus-transparent debate covered in our dedicated payload landscape article, there is a wide set of platform-level engineering problems: power budget, thermal envelope, reconfigurability in orbit, and graceful degradation across a multi-year mission.
Engineering mechanisms that address the problem
- Beamforming hardware and digital beamforming resource allocation on the platform
- Payload reconfiguration and software-defined payload update mechanisms
- Power and thermal-aware scheduling of payload processing
- Redundancy, fault detection and degraded-mode operation
- Payload resource sharing across beams, operators or services
- Antenna aperture control and beam-pattern management
**Where invention can occur.** Contribution frequently lies in constrained optimisation: allocating finite onboard power, processing or beams under mission constraints, and doing so with mechanisms that are verifiable in operation. In-orbit reconfiguration workflows — validation, rollback, staged activation — are a distinct and under-mapped surface. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** System and device claims covering the payload subsystem, method claims covering the control loop, and network-node claims where the payload behaves as a RAN node. Avoid claims that recite only a hardware inventory without a mechanism.
Prior-art questions an R&D/IP team should ask
- Is the control loop distinguishable from terrestrial base-station resource management?
- Does existing spacecraft-systems prior art disclose the redundancy or thermal mechanism?
- Is the contribution the onboard decision or the ground-to-space coordination?
**Standards and specifications to review.** 3GPP TR 38.821 payload options, ITU-R recommendations on satellite system characteristics, and ECSS-derived platform documentation where relevant. **Product and system layers that implement it.** Payload processors and FPGAs, antenna subsystems, satellite bus controllers, and ground control software. **IP intelligence to monitor.** Satellite manufacturer and newspace filing patterns, cross-domain filings from terrestrial RAN vendors entering payload design, and family expansion into ground-control claims. **Relevant Hashi service.** Patent landscape, white-space analysis and IP due diligence for payload and platform programmes.
Area 5 — Network Management & AI/ML
Constellations generate operational complexity no static planning process can absorb: thousands of beams, continuously changing geometry, variable demand and weather-dependent feeder links. Increasingly the answer is learned or predictive control — and this is becoming one of the most active emerging IP domains in NTN.
Engineering mechanisms that address the problem
- Predictive resource allocation using orbital and demand forecasts
- AI/ML-based beam scheduling and capacity steering
- Anomaly detection and self-healing across space and ground segments
- Autonomous network configuration and intent-driven operation
- Digital-twin modelling of constellation behaviour
- Model training, deployment, monitoring and rollback pipelines for network functions
**Where invention can occur.** Invention surface is concentrated in the technical framing: what inputs are collected, how they are represented, where inference runs, how outputs are constrained to safe operating envelopes, and how the system behaves when a model is uncertain. Purely abstract 'apply ML to X' framing is rarely sufficient in any jurisdiction; the technical effect must be articulated in the mechanism. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** Method claims tied to a technical control outcome, system claims covering the training-and-inference pipeline as deployed, and network-node claims. Subject-matter eligibility varies significantly by jurisdiction and requires careful drafting.
Prior-art questions an R&D/IP team should ask
- Does terrestrial SON or RAN-intelligence prior art already disclose the loop?
- Is the model architecture itself the contribution, or its integration into a network procedure?
- Is the technical effect articulable without reference to accuracy improvement alone?
- Has the approach appeared in O-RAN or ETSI ENI documentation?
**Standards and specifications to review.** 3GPP AI/ML for NG-RAN and air-interface work items, O-RAN specifications for RIC and rApps/xApps, and ETSI ENI/ZSM outputs. **Product and system layers that implement it.** OSS/BSS platforms, network management systems, RIC platforms, constellation-operations software, and gNB scheduler software. **IP intelligence to monitor.** Which operators and vendors are filing on network-AI mechanisms, how those families are drafted for eligibility, and where terrestrial AI-RAN families are being extended to satellite contexts. **Relevant Hashi service.** AI-driven patent search and analytics, patentability assessment and drafting for AI-implemented network inventions.
Area 6 — Spectrum Management
Spectrum is finite, shared and regulated, and NTN systems must coexist with terrestrial networks, other constellations and incumbent services. Our dedicated spectrum-sharing article covers coordination mechanics in depth; from a filing-taxonomy perspective the relevant point is what belongs in this area versus elsewhere.
Engineering mechanisms that address the problem
- Spectrum monitoring and sensing across space and ground assets
- Spectrum planning and assignment across beams and orbits
- Interference-aware configuration of transmission parameters
- Spectrum utilisation analytics and reporting
- Regulatory-constraint enforcement in resource allocation
**Where invention can occur.** Within this taxonomy the invention surface is in the management layer: how spectrum state is measured, represented, predicted and turned into configuration decisions — as distinct from the coordination protocols themselves, which are treated in the dedicated spectrum-sharing analysis. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** Method and system claims around the measurement-to-configuration pipeline, plus network-node claims. Regulatory compliance framing alone is not a technical mechanism.
Prior-art questions an R&D/IP team should ask
- Is the sensing technique distinguishable from cognitive-radio prior art?
- Is the contribution in the analytics or in the resulting configuration change?
- Does regulatory documentation constitute prior disclosure of the mechanism?
**Standards and specifications to review.** ITU-R Radio Regulations and relevant recommendations, national regulator technical conditions, and 3GPP coexistence studies. **Product and system layers that implement it.** Spectrum management platforms, gateway controllers, network planning tools and payload configuration systems. **IP intelligence to monitor.** Filing patterns from spectrum-analytics vendors, and whether families are drafted around measurement, prediction or enforcement. **Relevant Hashi service.** Patent landscape and FTO analysis for spectrum-management subsystems.
Area 7 — Protocol & Signaling
NTN introduces information that terrestrial protocols never had to carry: ephemeris, satellite identity, validity windows, coverage timing and NTN-specific capabilities. Every new information element and procedure is a potential point of technical contribution and a potential point of standards exposure.
Engineering mechanisms that address the problem
- NTN-specific system information broadcast and update procedures
- Capability exchange for NTN-aware terminals
- Ephemeris and assistance-data delivery formats and refresh policies
- Configuration procedures for timing, compensation and mobility parameters
- Network–device coordination for coverage-gap handling
- Signalling efficiency and overhead reduction under constrained links
**Where invention can occur.** Invention surface lies in what is signalled, when, at what granularity, and how validity and staleness are handled. Overhead reduction mechanisms — differential encoding, predictive delivery, on-demand request — are frequently concrete and demonstrable. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** Network-node and terminal method claims describing the procedure, system claims covering the exchange, and device claims covering the processing of received elements. Signalling contributions are among the most likely to carry standards exposure.
Prior-art questions an R&D/IP team should ask
- Is the information element already defined in an earlier release?
- Was the procedure disclosed in a RAN2 contribution before the priority date?
- Is the contribution the content, the delivery mechanism or the update policy?
- Does GNSS assistance-data prior art anticipate the delivery scheme?
**Standards and specifications to review.** 3GPP TS 38.331, TS 38.413, TS 24.501 and the NTN-specific additions across releases, together with RAN2/CT1 contribution records. **Product and system layers that implement it.** RRC and NAS software stacks in terminals and network nodes, and gateway signalling gateways. **IP intelligence to monitor.** Which companies file around specific information elements, timing of filings relative to contribution dates, and declared-SEP activity concentrated in signalling families. **Relevant Hashi service.** Standards mapping and SEP analysis; claim charting where signalling behaviour is specification-mandated.
Area 8 — Applications & Verticals
NTN's commercial case is built on verticals with specific technical requirements — maritime, aviation, agriculture, logistics, emergency communications, industrial IoT and remote infrastructure. Vertical requirements drive technical adaptations that are often overlooked in filing programmes focused on the radio stack.
Engineering mechanisms that address the problem
- Service-level adaptation to vertical traffic profiles and duty cycles
- Terminal behaviour tuned to platform motion (vessel, aircraft, vehicle)
- Priority and pre-emption mechanisms for emergency traffic
- Store-and-forward and delay-tolerant data handling
- Vertical-specific device management and provisioning at scale
- Coverage-aware application scheduling
**Where invention can occur.** The contribution is usually in the adaptation mechanism, not the application. A claim reciting 'a maritime tracking service' is a business context; a claim reciting how transmission opportunities are selected from predicted visibility windows against a duty-cycle constraint is a mechanism. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** Method and system claims covering the adaptation, terminal and network-node claims, and device claims for vertical terminals. Business-method framing must be avoided.
Prior-art questions an R&D/IP team should ask
- Is the mechanism distinguishable from delay-tolerant networking prior art?
- Does existing M2M or telematics prior art disclose the scheduling approach?
- Is the vertical context load-bearing in the claim, or decorative?
**Standards and specifications to review.** 3GPP service requirement specifications, vertical-specific standards bodies (IMO, ICAO, industry consortia) and relevant regulatory service mandates. **Product and system layers that implement it.** Vertical terminals and gateways, device management platforms, application servers and fleet-management systems. **IP intelligence to monitor.** Which vertical integrators hold patents rather than only deployments, and where operator filings extend into application-layer mechanisms. **Relevant Hashi service.** Patent-to-product mapping and competitive IP intelligence for vertical product lines.
Area 9 — Emerging & Cross-Domain
The highest-uncertainty, highest-optionality filings sit at intersections: NTN with AI, 6G, edge computing, quantum-safe security, autonomous systems and sensing. Filing here is a bet on where the architecture goes, and the prior-art landscape is thin precisely because the combination is new.
Engineering mechanisms that address the problem
- NTN integration into 6G architecture concepts and service classes
- Edge compute placement across space, gateway and terrestrial edge
- Integrated sensing and communication using satellite geometry
- Autonomous constellation operation and inter-satellite coordination logic
- NTN in non-cellular ecosystems and hybrid connectivity fabrics
**Where invention can occur.** Cross-domain invention surface is best identified by asking which interface between two previously separate domains now has to carry new information or new decisions. That interface is where the concrete mechanism usually lives. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** System claims spanning the interface, plus node-level method claims on each side. Claims that merely combine two known systems without a technical interaction are vulnerable.
Prior-art questions an R&D/IP team should ask
- Is the combination disclosed in any roadmap document or research publication?
- Does prior art in either domain individually render the interaction obvious?
- Is there a technical problem created by the combination itself?
**Standards and specifications to review.** 6G study items, IETF and ETSI edge specifications, and pre-standard research consortium outputs. **Product and system layers that implement it.** Edge platforms, next-generation core, satellite compute payloads and terminal software. **IP intelligence to monitor.** Early filing signals from research-heavy organisations, university and consortium filings, and priority-date clustering around emerging concepts. **Relevant Hashi service.** White-space analysis and portfolio development; competitive IP intelligence to monitor early movers.
Area 10 — Ground Segment & Terminal
The ground segment is where NTN meets deployment economics. Gateways must be selected, switched and managed; terminals must acquire, track and maintain links with hardware constrained by cost, size and power. Both are substantial engineering domains with distinct invention patterns.
Engineering mechanisms that address the problem
- Gateway selection, load balancing and diversity switching under weather fading
- Gateway management, monitoring and failover orchestration
- Terminal antenna pointing, tracking and acquisition (mechanical, phased-array, hybrid)
- Terminal power management and duty-cycle control
- Installation, calibration and self-alignment procedures
- User-terminal handover between satellites and between operators
**Where invention can occur.** Terminal invention often sits in acquisition and tracking under constrained hardware: search strategies, prediction-assisted pointing, and recovery from loss of lock. Gateway invention concentrates on diversity decisions and the coordination cost of switching without disturbing active sessions. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** Device and system claims for terminal hardware/firmware, method claims for acquisition and switching procedures, and network-node claims for gateway-side orchestration.
Prior-art questions an R&D/IP team should ask
- Does VSAT and legacy satcom terminal prior art disclose the tracking mechanism?
- Is the phased-array control approach distinguishable from radar prior art?
- Is the gateway diversity decision novel, or a known site-diversity technique applied to a new band?
**Standards and specifications to review.** 3GPP terminal requirement specifications, ITU-R propagation and site-diversity recommendations, and antenna-related industry specifications. **Product and system layers that implement it.** User terminals, antenna modules, terminal firmware, gateway RF and baseband systems, and NOC software. **IP intelligence to monitor.** Terminal-vendor filing intensity by antenna architecture, and where consumer-scale D2D terminals attract new entrants. **Relevant Hashi service.** Freedom-to-operate analysis for terminal hardware and prior art search for antenna control mechanisms.
Area 11 — Security & Trust
NTN expands the attack surface: long-range broadcast links, physically inaccessible nodes, multi-operator routing and terminals in uncontrolled environments. Security mechanisms must work with intermittent connectivity and constrained links, which rules out many terrestrial assumptions.
Engineering mechanisms that address the problem
- Authentication and key management adapted to intermittent visibility
- Anti-spoofing and anti-jamming detection and mitigation
- Secure onboard software update and attestation for payloads
- Multi-operator trust establishment and routing integrity
- Privacy and location-exposure control for satellite-connected terminals
- Post-quantum-ready key exchange under constrained link budgets
**Where invention can occur.** Invention surface concentrates on adaptation to constraint: how credentials are refreshed when the terminal is out of coverage for hours, how attestation completes across a lossy link, and how detection operates without ground-truth reference. Generic cryptographic protocol claims are usually well anticipated. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** Method and system claims around the adapted procedure, device claims for terminal or payload security subsystems, and network-node claims.
Prior-art questions an R&D/IP team should ask
- Is the underlying cryptographic mechanism known, with only the transport adapted?
- Does GNSS anti-spoofing prior art disclose the detection method?
- Is the contribution the protocol or its scheduling under intermittency?
**Standards and specifications to review.** 3GPP SA3 security specifications as applied to NTN, CCSDS security standards, and relevant national security guidance for space systems. **Product and system layers that implement it.** Terminal secure elements, payload security modules, key management infrastructure and core network security functions. **IP intelligence to monitor.** Filing activity from security vendors entering the space domain and defence-adjacent filings with commercial spillover. **Relevant Hashi service.** Prior art search and IP due diligence for security subsystems.
Area 12 — IoT & Low-Power NTN
NB-IoT and eMTC over NTN target devices with tiny power budgets, long deployment lifetimes and sporadic traffic — a very different optimisation problem from broadband NTN. Coverage may be intermittent by design, and the device must plan around it.
Engineering mechanisms that address the problem
- Extended coverage and repetition strategies under low link budget
- Discontinuous coverage handling and next-visibility computation
- Extended DRX and power-saving mode adaptation to satellite passes
- Uplink-first and store-then-transmit device behaviour
- Massive device access and congestion control across wide beams
- Low-complexity GNSS and ephemeris handling on constrained devices
**Where invention can occur.** Invention surface is dominated by energy: how the device decides when to wake, how it computes the next opportunity cheaply, and how the network signals coverage timing at minimal overhead. Small, concrete mechanisms here can be widely implemented. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** Terminal method and device claims, network-node method claims for coverage-timing signalling, and system claims covering the coordinated behaviour.
Prior-art questions an R&D/IP team should ask
- Does terrestrial NB-IoT power-saving prior art disclose the wake mechanism?
- Is discontinuous-coverage handling already published in satellite IoT literature?
- Is the computation offloaded to the network, and is that offload the contribution?
**Standards and specifications to review.** 3GPP NB-IoT/eMTC over NTN work items, TS 36.331 and TS 38.331 power-saving procedures, and coverage-enhancement specifications. **Product and system layers that implement it.** IoT modules and chipsets, device firmware, IoT core functions and device-management platforms. **IP intelligence to monitor.** Chipset-vendor filings on discontinuous coverage, and how satellite IoT startups position families ahead of scale deployment. **Relevant Hashi service.** Patentability assessment and drafting for constrained-device inventions; landscape work per mechanism.
Area 13 — Testing & Conformance
You cannot deploy what you cannot test, and satellite channel conditions cannot be reproduced by terrestrial test equipment without deliberate emulation. Test methodology is a real engineering domain — and a frequently under-filed one.
Engineering mechanisms that address the problem
- Satellite channel and propagation emulation, including Doppler profiles
- Long-delay and variable-delay emulation in conformance setups
- Test case generation for NTN-specific procedures
- Ephemeris and constellation simulation in test environments
- Field validation methodology across passes and geometries
- Automated regression testing for payload software updates
**Where invention can occur.** The invention surface is in emulation fidelity and efficiency: how a realistic channel is synthesised, how test coverage is derived from specification requirements, and how results are correlated back to configuration parameters. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** System and device claims for test apparatus, method claims for test procedures, and computer-implemented claims for generation and analysis where legally appropriate.
Prior-art questions an R&D/IP team should ask
- Does existing channel-emulator prior art disclose the synthesis method?
- Is test-case generation distinguishable from general model-based testing prior art?
- Is the contribution in the emulation model or the measurement methodology?
**Standards and specifications to review.** 3GPP TS 38.521 and 38.181-series conformance testing specifications as extended to NTN, and GCF/PTCRB certification requirements. **Product and system layers that implement it.** Test and measurement instruments, channel emulators, conformance test systems and lab automation software. **IP intelligence to monitor.** Test-equipment vendor filing patterns and whether operators file defensively on validation methodology. **Relevant Hashi service.** Prior art search and portfolio development for test and measurement programmes.
Area 14 — Timing, Sync & Positioning
Everything in NTN depends on time. Timing advance, frame alignment, handover scheduling and positioning all rest on synchronised references distributed across moving nodes with variable propagation delay, and often with GNSS as both a dependency and a service.
Engineering mechanisms that address the problem
- Timing synchronisation between satellite, gateway and terminal
- Timing advance computation, signalling and validity management
- Onboard clock alignment and holdover strategies
- Satellite–ground synchronisation under feeder-link switching
- Positioning assistance and NTN-based positioning methods
- GNSS-denied operation and fallback timing sources
**Where invention can occur.** GNSS-independent operation is a distinctive invention surface: deriving usable timing and position from the NTN signal itself, bounding error growth during holdover, and deciding when to trust which source. Validity-window management for distributed timing parameters is another concrete area. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** Method claims at terminal and network node, system claims covering the distributed timing arrangement, and device claims covering timing subsystems.
Prior-art questions an R&D/IP team should ask
- Does GNSS or terrestrial positioning prior art disclose the fallback method?
- Is holdover strategy distinguishable from telecom clock-synchronisation prior art?
- Is the contribution the estimation or the decision logic between sources?
**Standards and specifications to review.** 3GPP positioning specifications (TS 38.305 and related) as applied to NTN, ITU-R timing recommendations and GNSS interface control documents. **Product and system layers that implement it.** Terminal timing subsystems, payload clocks, gateway timing distribution and location management functions. **IP intelligence to monitor.** Filings on GNSS-free NTN positioning, and overlap between positioning specialists and NTN vendors. **Relevant Hashi service.** Standards mapping and prior art search for timing and positioning mechanisms.
Area 15 — Direct-to-Device
Direct-to-device connects unmodified handsets to satellites. The constraints are brutal: no specialised antenna, no pointing, ordinary transmit power, and a link budget that must still close. Rather than repeating the convergence narrative covered elsewhere, the question here is narrow — what technical mechanisms create potential IP positions around D2D systems?
Engineering mechanisms that address the problem
- Link-budget compensation through very large aperture and beamforming on the space side
- Uplink coverage enhancement and repetition for handset-class transmit power
- Spectrum use under terrestrial operator licences and associated network coordination
- Handset behaviour for satellite discovery, selection and fallback
- Emergency and messaging service procedures over constrained D2D links
- Roaming, identity and regulatory-compliance handling across operator boundaries
**Where invention can occur.** Because the handset cannot change, invention concentrates on the network side and on software behaviour within existing handset capability: how coverage is discovered without draining battery, how service is selected between terrestrial and satellite, and how partial service levels are represented to the user and to applications. Each of these is a potential invention surface only — novelty and inventive step require claim-level assessment against the actual prior art in the specific mechanism, not against "NTN" as a subject area.
**Claim perspectives that may arise.** Network-node and terminal method claims, system claims covering the coordinated service, and device claims where handset software behaviour is the contribution.
Prior-art questions an R&D/IP team should ask
- Does existing satellite-messaging prior art disclose the discovery mechanism?
- Is the coverage-enhancement approach already known from terrestrial coverage extension?
- Is the contribution the service model or the underlying radio mechanism?
**Standards and specifications to review.** 3GPP NTN work items covering satellite access for handheld devices, regulatory frameworks for supplemental coverage from space, and operator technical requirements. **Product and system layers that implement it.** Handset modem software, network core and RAN, satellite payload and operator service platforms. **IP intelligence to monitor.** Which operators, satellite players and chipset vendors are filing on D2D mechanisms, and how declared-SEP activity is trending in this area. **Relevant Hashi service.** Competitive IP intelligence, standards mapping and SEP analysis for D2D programmes.
Master taxonomy table
The table below condenses all 15 areas. Every entry describes a potential invention surface and a candidate IP domain; none asserts patentability, which requires claim-level analysis in every case.
| Technology area | Technical problem | Representative invention surface | Potential IP focus | Standards exposure | Product/system layer | Hashi service |
|---|---|---|---|---|---|---|
| 1. Waveform & PHY | Delay, Doppler, low link budget | Compensation derivation, RACH and HARQ adaptation | Terminal and node processing methods | High — RAN1 specifications | Modem, gNB PHY, payload DSP | Prior art search, drafting |
| 2. Architecture & Convergence | Coherent access despite moving topology | Functional split, context distribution, interfaces | System and node architecture claims | Medium–high — SA2/RAN3 | Core, gateway, payload controller | Landscape, portfolio development |
| 3. Mobility & Session Mgmt | Cells move, visibility is time-bound | Ephemeris-based prediction and pre-configuration | Coordinated procedure claims | High — RAN2 procedures | RRC stack, core mobility | Prior art search, claim strategy |
| 4. Payload & Platform | Finite power, thermal and mission constraints | Onboard resource control, reconfiguration workflows | Subsystem and control-loop claims | Low–medium | Payload processor, antenna, bus | White space, IP due diligence |
| 5. Network Mgmt & AI/ML | Operational complexity at constellation scale | Predictive control loops and safe-envelope inference | Computer-implemented network methods | Medium — O-RAN, 3GPP AI/ML | OSS, RIC, scheduler | AI patent search & analytics |
| 6. Spectrum Management | Coexistence with terrestrial and incumbent users | Sensing-to-configuration pipeline | Measurement and configuration methods | Medium — ITU-R, coexistence | Spectrum platforms, gateway | Landscape, FTO |
| 7. Protocol & Signaling | New NTN information must be carried efficiently | Elements, delivery policy, overhead reduction | Signalling procedure claims | Very high — normative text | RRC/NAS stacks | Standards mapping, SEP analysis |
| 8. Applications & Verticals | Vertical traffic and platform constraints | Adaptation mechanisms, not applications | Adaptation method claims | Low–medium | Vertical terminals, app servers | Patent-to-product mapping |
| 9. Emerging & Cross-Domain | New interfaces between previously separate domains | Interface mechanisms across domains | System claims spanning the interface | Emerging | Edge, next-gen core, compute payload | White space, portfolio development |
| 10. Ground Segment & Terminal | Deployment economics and constrained hardware | Acquisition, tracking, gateway diversity | Device and orchestration claims | Medium | Terminals, antennas, gateways | FTO, prior art search |
| 11. Security & Trust | Exposed links and inaccessible nodes | Security adapted to intermittency | Adapted protocol and subsystem claims | Medium — SA3 | Secure elements, KMI, core | Prior art search, IP due diligence |
| 12. IoT & Low-Power NTN | Energy budget under sparse coverage | Wake scheduling, next-visibility computation | Constrained-device method claims | High — NB-IoT NTN | IoT chipsets, firmware | Patentability, landscape |
| 13. Testing & Conformance | Satellite conditions cannot be reproduced naively | Channel emulation and test generation | Apparatus and method claims | Medium — conformance specs | Emulators, test systems | Prior art search, portfolio |
| 14. Timing, Sync & Positioning | Distributed time across moving nodes | GNSS-denied timing and validity management | Estimation and decision-logic claims | High — positioning specs | Timing subsystems, LMF | Standards mapping, search |
| 15. Direct-to-Device | Unmodified handsets must close the link | Discovery, selection, coverage enhancement | Network-side and handset-software claims | High and rising | Handset software, RAN, payload | Competitive IP intelligence, SEP analysis |
All entries indicate candidate IP domains and potential invention surfaces. Standards exposure indicates where specification text is most likely to be relevant; it does not indicate essentiality, which requires claim-level analysis.
The NTN IP filing workflow
A taxonomy is only useful inside a process. This is the workflow Hashi runs with NTN clients, and what we support at each stage.
- 0101 Technology decomposition
- 0202 Invention identification
- 0303 Prior art search
- 0404 Patentability assessment
- 0505 Claim strategy
- 0606 Patent drafting
- 0707 Patent filing
- 0808 Standards mapping
- 0909 Patent landscape
- 1010 FTO / white-space analysis
- 1111 Portfolio strategy
- 1212 Continuous IP monitoring
What Hashi supports at each stage
- Technology decomposition — mapping the client architecture onto the 15 areas and identifying which areas the product actually depends on.
- Invention identification — structured invention-harvesting sessions per area, run by engineers who understand the mechanism.
- Prior art search — mechanism-level searching with 3GPP contribution coverage, not keyword searching on "NTN".
- Patentability assessment — novelty and inventive-step analysis against the identified art, with a documented rationale.
- Claim strategy — determining which claim perspectives the technical contribution can support under applicable law.
- Patent drafting — AI-assisted, attorney-reviewed drafting with mechanism-level specification support.
- Patent filing — coordinated filing and jurisdiction strategy, including PCT routes.
- Standards mapping — mapping claims to specification requirements with traceable citations.
- Patent landscape — filing density, claim density and competitor positioning per technology area.
- FTO and white-space analysis — third-party exposure for the product, and thin areas where filing may be worthwhile.
- Portfolio strategy — horizontal and vertical coverage decisions across areas and jurisdictions.
- Continuous IP monitoring — tracking new publications, standards contributions and competitor filings per area.
Patent filing questions for each NTN technology area
Use this checklist against every candidate invention, regardless of which of the 15 areas it sits in.
- What technical problem is solved?
- What is technically different from existing approaches?
- What mechanism produces the technical result?
- What alternative solutions exist, and why were they rejected?
- What prior art already addresses the problem?
- Is the invention implementation-specific or architecture-level?
- Does it interact with a technical standard, and if so which requirement?
- Could multiple claim categories be supported by the contribution?
- Which product components implement it?
- Which competitors may have similar technology?
- Which jurisdictions matter commercially and for enforcement?
- Should the invention be monitored after filing for standards and competitor developments?
From technology area to claim strategy
NTN inventions can potentially be expressed through different claim perspectives depending on the contribution and applicable law: system, method, device, network node, terminal, processor-based implementation, and computer-readable medium where legally appropriate. Not every invention supports every perspective. A contribution that resides entirely in a terminal computation may not support a network-node claim. A contribution that arises from an exchange between nodes may be poorly captured by a single-node claim, which is a common cause of weak enforceability later. And subject-matter eligibility for computer-implemented and AI-implemented mechanisms varies materially across jurisdictions. The governing principle is simple: claim strategy must follow the actual technical contribution and applicable patent law — not a template applied uniformly across a filing programme. This article does not provide jurisdiction-specific legal advice.
How to search prior art across NTN technology areas
Searching "NTN patent" is insufficient, and the reason is structural. "NTN" is a deployment context, not a technical mechanism. The relevant prior art for a Doppler pre-compensation invention may never use the term NTN at all — it may sit in aeronautical satcom literature from the 1990s, in high-speed-train terrestrial work, or in a GNSS receiver patent. Effective searching works from the mechanism outward.
Mechanism-level search dimensions
- Technology area and specific mechanism (e.g. ephemeris-derived timing advance, not "NTN mobility")
- Technical function and the physical effect achieved
- Adjacent-domain terminology: aeronautical, maritime, VSAT, GNSS, radar, high-speed terrestrial
- CPC/IPC classes across H04B7/185, H04W and adjacent positioning and antenna classes
- 3GPP contribution records (RAN1/RAN2/SA2) as non-patent literature with hard dates
- Applicant, assignee and inventor clusters known to work in the mechanism
- Jurisdiction, filing year, legal status and claim scope for relevance filtering
- Terminology drift over time — the same mechanism named differently across eras
White-space analysis across the taxonomy
White space is not empty space. Methodologically it means: build the technology taxonomy, measure filing density per mechanism, measure claim density (how much of the mechanism the existing claims actually cover), overlay standards activity and product roadmaps, and identify mechanisms where technical necessity is rising while claim coverage remains thin. Areas 5, 9, 13 and 15 tend to look thinner than they will be in two years. Areas 1, 3, 7 and 12 tend to be denser than a keyword search suggests, because much of the relevant art predates the NTN label. Neither observation is a filing recommendation on its own — each requires mechanism-level verification.
Technology due diligence versus IP due diligence
These are distinct exercises and are frequently conflated in NTN transactions. **Technology due diligence** asks whether the technology works and whether the differentiation is real: what are the core technical differentiators, do they hold under the constraints claimed, what standards does the product depend on, and what is the engineering risk in the roadmap. **IP due diligence** asks who owns what and what exposure exists: patent ownership and chain of title, whether rights are in force in target markets, whether the families actually read on the product architecture, prior-art vulnerability, standards dependencies and declared-SEP obligations, licensing commitments, and third-party FTO risk. A company can pass one and fail the other. The most common failure pattern in NTN diligence is a strong technical story supported by patent families drafted around a different mechanism than the one the product actually implements — visible only when patent-to-product mapping is done per technology area.
Standards exposure and SEP considerations
Some of the 15 areas sit close to normative specification text — protocol and signalling, mobility procedures, PHY-layer parameters, IoT coverage procedures and direct-to-device. Others sit largely outside it — payload platform engineering, ground infrastructure, testing methodology. Proximity to standards is not essentiality. A patent is potentially essential only where a claim reads onto behaviour that a specific normative requirement in a specific specification release mandates, and that determination requires claim-level analysis with citations to specification text. Subject-matter relevance to NTN establishes nothing.
Standards and SEP services
Which analysis answers which question
Different NTN IP questions require different studies. Choosing the wrong one is the most common source of wasted budget.
| The question | The analysis |
|---|---|
| Where can we file, and is it worth filing? | Technology decomposition, invention harvesting, prior art search, patentability assessment |
| Who owns what in this technology area? | Patent landscape per mechanism |
| Where is coverage thin relative to technical necessity? | White-space analysis |
| Could our product face third-party patent exposure? | NTN FTO analysis |
| What IP risks and ownership issues exist in this target? | IP due diligence |
| Is the technology real and defensible? | Technology due diligence |
| Does this claim read on a specification requirement? | Standards mapping and SEP analysis |
| Which competitor is moving into our area? | Competitive IP intelligence and monitoring |
Scope an NTN IP programme
Tell us which technology areas your product touches and we will come back with a scoped approach — invention harvesting, prior art search, landscape, FTO or due diligence.
Frequently asked questions
They are distinct technical domains within non-terrestrial networks — waveform and PHY, network architecture, mobility, payload, network management and AI/ML, spectrum, protocol and signalling, verticals, cross-domain, ground segment and terminal, security, IoT, testing, timing and positioning, and direct-to-device. Each has its own engineering problems, invention patterns, prior-art density and standards exposure, so each requires separate IP analysis.
Talk to our NTN IP team
Bring us your architecture and we will map it onto the 15 technology areas, identify the candidate invention surfaces and scope the searches that matter.
Talk to our NTN IP team
