Patent Drafting Analysis of Microsoft’s Spatial Anchor Connectivity for Augmented Reality | US 11,922,560 B2
Patent Drafting Analysis of Microsoft's Spatial Anchor Connectivity for Augmented Reality | US 11,922,560 B2
A structural and strategic analysis of Microsoft's granted AR spatial anchor patent, covering claim architecture, dependency design, §101 eligibility risk, spec–claim consistency, and prosecution positioning across 20 claims.
Spec Words
7,200
Across 6 sections
Draft now ↗
Total Claims
20
3 independent · 17 dependent
Draft now ↗
Figure Sheets
7
AR environment, method flows, system architecture, UI displays
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 58% of total specification words (~4,200 of ~7,200), providing substantial operational narrative for each figure. The claim set comprises 20 total claims with 3 independent claims (Claims 1, 8, and 14) spanning method and apparatus types, with a dependent-to-independent ratio of 5.67:1. Seven figure sheets cover the AR usage environment, multiple method flow diagrams, computing system architecture, and mobile device UI displays, providing reasonably broad visual support across the main embodiments.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 7 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Depicts an example environment 100 in which users 110, 120, 130, 140 employ mobile devices to interact with virtual spatial anchors 114A–114D and associated virtual content 116A–116B across a physical space such as a museum or gallery.Search in Eureka ↗ | Key embodiment |
| FIG. 2 | Flow diagram of example method 200 for creating spatially connected spatial anchors, showing steps 210–232 from initial image capture through sending spatial relationship data to a network-accessible service.Search in Eureka ↗ | Flow diagram |
| FIG. 3 | Flow diagram of example method 300 for a network-accessible computing service facilitating an exchange between spatial anchor creators and consumers, including steps 310–322 for receiving, comparing, and sending perspective-dependent anchor poses.Search in Eureka ↗ | Flow diagram |
| FIG. 4 | Flow diagram of example method 400 for a mobile device consumer of spatial anchors, showing steps 410–424 for capturing image data, querying the network service, receiving perspective-dependent anchor poses, and displaying wayfinding information.Search in Eureka ↗ | Flow diagram |
| FIG. 5 | Schematic block diagram of computing system 500 comprising logic machine 510, storage machine 512 holding instructions 520 and data 522, display subsystem 514, input subsystem 516, and communication subsystem 518.Search in Eureka ↗ | System architecture |
| FIG. 6 | Depicts mobile device 610 with display 612 showing camera view of a first physical world location (table 614) with overlaid virtual content 616 (holographic architectural model) and wayfinding directional indicator 618.Search in Eureka ↗ | UI/interface |
| FIG. 7 | Depicts mobile device 610 at a second physical world location showing camera view of table 714 with updated virtual content 716 (second architectural model) and updated wayfinding indicator 718 guiding to the associated spatial anchor.Search in Eureka ↗ | UI/interface |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Claims
Claim Architecture Analysis
The patent contains 3 independent claims: Claim 1 (method performed by a computing device), Claim 8 (computing device apparatus), and Claim 14 (method performed by a computing system/server). The dependent-to-independent ratio of 5.67:1 is slightly below the software/AR norm of approximately 6–8:1, suggesting somewhat limited fallback depth. The tripartite structure effectively covers both client-side device (Claims 1, 8) and server-side system (Claim 14) perspectives, providing enforcement coverage that addresses the distributed nature of the spatial anchor platform.
Core inventive concept: The claims address the problem of connecting spatially separated AR anchor points when a user moves between physical locations — a scenario where a single camera view cannot capture both anchors simultaneously. The solution, expressed across Claims 1, 8, and 14, uses tracking of user movement between two physical locations combined with sparse-point-cloud spatial representations and user-defined anchor poses to derive a spatial relationship between the two virtual spatial anchor points, then transmits this relational data to a remote computing device for perspective-dependent pose rendering.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method performed by a computing device, the method comprising: | comprising | capturing first/second image data via camera; creating first/second sparse-point-cloud spatial representations; receiving first/second user inputs defining virtual spatial anchor poses within respective spatial representations; tracking user movement toward second physical world location; sending to remote computing device: first spatial representation, first anchor pose, second spatial representation, second anchor pose, and spatial relationship between anchors identified from user movementSearch prior art ↗ |
| Claim 8 | A computing device comprising: | comprising | camera; graphical display; processor; memory storing instructions to: capture first/second image data, create first/second sparse-point-cloud spatial representations, receive first/second user inputs (touch or eye tracking) defining anchor poses, track user movement, send to remote computing device: first spatial representation, first anchor pose, second spatial representation, second anchor pose, and spatial relationship between anchorsSearch prior art ↗ |
| Claim 14 | A method performed by a computing system, the method comprising: | comprising | receiving from mobile device: first/second spatial anchor pose data (sparse point cloud spatial representations + anchor poses) and spatial relationship between anchors; storing the data; receiving different spatial representation from requesting mobile device (third sparse point cloud); determining perspective-dependent poses of first/second anchors based on spatial relationship; sending perspective-dependent poses to requesting mobile deviceSearch prior art ↗ |
Claim Dependency Tree
1 Method (computing device): capture images, create sparse-point-cloud representations, receive anchor poses, track movement, send spatial relationship to remote deviceSearch Claim 1 prior art ↗
2 Adds: first image capture comprises visible light RGB cameraSearch in Eureka ↗
3 Adds: first image capture comprises depth cameraSearch in Eureka ↗
4 Adds: further determining spatial relationship based on poses of first/second anchors and tracked user movementSearch in Eureka ↗
5 Adds: tracking to third physical world location, capturing third image data, creating third sparse point cloud, receiving third anchor pose, sending third anchor spatial relationshipSearch in Eureka ↗
6 Further: (depends on 5) third user input received in different session than first and second user inputsSearch in Eureka ↗
7 Adds: first user input defining pose includes at least the eye tracking input captured via eye tracking cameraSearch in Eureka ↗
8 Apparatus (computing device): camera, graphical display, processor, memory with instructions to perform anchor creation and spatial relationship determinationSearch Claim 8 prior art ↗
9 Adds: camera is visible light camera; instructions capture first visible light imageSearch in Eureka ↗
10 Adds: camera is depth camera; instructions capture first depth imageSearch in Eureka ↗
11 Adds: instructions further determine spatial relationship based on respective poses and tracked user movementSearch in Eureka ↗
12 Adds: instructions further track to third location, capture third image, create third sparse point cloud, obtain third anchor pose, send third anchor spatial relationship to remote deviceSearch in Eureka ↗
13 Adds: pose of first virtual spatial anchor defines location in 3D space relative to computing deviceSearch in Eureka ↗
14 Method (computing system/server): receive anchor pose data from mobile device, store, receive third spatial representation from requesting device, determine perspective-dependent poses, send to requesting deviceSearch Claim 14 prior art ↗
15 Adds: storing comprises maintaining relationship graph defining associations between spatial representations and virtual spatial anchorsSearch in Eureka ↗
16 Further: (depends on 15) comparison determined by comparing different spatial representation to stored spatial representations in relationship graphSearch in Eureka ↗
17 Adds: perspective-dependent pose of first anchor represents pose from perspective of requesting mobile deviceSearch in Eureka ↗
18 Adds: first spatial anchor pose data, second spatial anchor pose data, and spatial relationship data received during different sessionsSearch in Eureka ↗
19 Adds: receiving different spatial representation comprises receiving sparse point cloud based on visible RGB image dataSearch in Eureka ↗
20 Adds: receiving different spatial representation comprises receiving sparse point cloud based on depth image dataSearch in Eureka ↗
| Metric | This Application | Software / Cloud AR Norm |
|---|---|---|
| Total claims | 20 | 15 – 25 |
| Independent claim count | 3 | 2 – 4 |
| Dependent : Independent ratio | 5.67 : 1 | 5 – 8 : 1 |
| Method claims present? | Yes — Claims 1, 14 | Common |
| System / apparatus claims? | Yes — Claim 8 | Common |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Drafting Quality
Drafting Quality Signals
The claim set demonstrates strong structural consistency between the method claims (Claims 1 and 14) and apparatus claim (Claim 8), with the sparse-point-cloud spatial representation requirement appearing consistently across all three independent claims as a concrete technical anchor. A notable weakness is the absence of a computer-readable medium (CRM) claim, leaving a significant design-around avenue open for software implementations distributed without dedicated hardware.
✅
Antecedent Basis
Antecedent basis appears clean across all 20 claims. In Claim 1, "the first image data" (step 2) properly refers back to "first image data" introduced in step 1; "the first sparse point cloud" in step 3 traces to "a first sparse point cloud" created in step 2. Claim 8 follows the same pattern in the apparatus context. No orphaned "the" references were identified in the dependent claims (e.g., "the camera" in Claims 9–10 correctly refers to "a camera" introduced in Claim 8's preamble).
✅
Spec–Claim Consistency
Key independent claim limitations map well to specific specification sections and figures. The sparse-point-cloud spatial representation limitation of Claim 1 is supported at col. 6 ll. 13–19 and col. 7 ll. 10–16. The user-movement tracking step maps to FIG. 2 step 220 and col. 7 ll. 1–10. The sending-to-remote-device limitation maps to FIG. 2 step 218/232 and col. 6 ll. 53–65. The server-side Claim 14 is directly supported by FIG. 3 steps 310–322 and col. 7 ll. 54 – col. 8 ll. 65.
✅
Transition Word Usage
All three independent claims correctly use "comprising" as the transition word, which is the strategically optimal choice for the computing/software domain as it leaves open additional, unclaimed steps and components. "Comprising" in Claims 1 and 14 prevents a competitor from avoiding infringement by adding extra processing steps. Claim 8's apparatus likewise uses "comprising," allowing the claims to read on implementations with additional hardware components beyond those recited.
✅
§112(f) Means-Plus-Function Risk
No "means for" or "step for" language appears in any of the 20 claims, eliminating direct §112(f) invocation risk. Claim 8 uses functional labels such as "memory storing instructions executable by the processor to" followed by enumerated steps — this is the standard software patent claim format that courts treat as structural (hardware plus stored software), not as means-plus-function. The specification at FIG. 5 and col. 11 provides corresponding structural disclosure for logic machine 510 and storage machine 512 that maps to these claim elements.
⚠️
§101 Eligibility Risk
Claims 1 and 14 are method claims tied to computing devices but may face Alice step-two scrutiny because the core inventive concept — determining a spatial relationship between two anchor points based on tracked movement — could be characterized as an abstract mathematical/geometric calculation. The §101 defense rests primarily on the concrete physical-world elements: camera capture, sparse-point-cloud creation, and user-movement tracking via real sensors. Claim 8's apparatus form provides stronger §101 ground due to explicit hardware recitation (camera, graphical display, processor). Examiners in class G06T have historically raised Alice rejections for coordinate-transformation and spatial-mapping claims.
⚠️
Dependent Claim Fallback Quality
Several dependent claims add genuinely distinct technical limitations that create meaningful fallback positions: Claim 6 adds the cross-session anchor creation scenario; Claim 15 adds the relationship graph storage structure; and Claim 18 adds the multi-session data receipt scenario. However, Claims 2/9 (RGB camera) and Claims 3/10 (depth camera) are near-duplicate pairs across independent claims 1 and 8, consuming two claim slots for minor camera-type limitations rather than introducing structurally distinct fallback positions. Similarly, Claims 4 and 11 essentially replicate the same spatial relationship determination step across Claims 1 and 8 respectively.
⚠️
Abstract Quality
An examiner reading only the abstract may identify the general AR spatial anchor concept but will struggle to identify the specific novel contribution — the cross-location anchor connectivity through tracked user movement. The abstract describes the broader computing device flow (capture, create, receive user input, track, send) but omits the key claim limitation that the spatial relationship is "identified from the user movement" — the specific mechanism that distinguishes this invention from simple multi-anchor placement systems. This omission could lead an initial examiner to anchor prior art searches around generic AR anchor patents rather than the movement-tracking connectivity problem.
⚠️
Figure Support Quality
Most core claim limitations have figure support: FIG. 2 maps directly to Claims 1/8's client-side method steps, FIG. 3 maps to Claim 14's server-side method, and FIG. 5 provides structural support for Claim 8's apparatus. However, no figure explicitly illustrates the "spatial relationship" as a computed geometric or vector relationship between two anchor points — the most novel limitation — relying entirely on text description at col. 7 ll. 26–29. The eye-tracking input modality recited in Claims 7 and referenced in Claim 8's "eye tracking input" is not depicted in any figure, creating a written description support gap that could be exploited in IPR proceedings.
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
3.5
Prosecution Defensibility
3.8
Spec–Claim Consistency
3.7
Dependent Claim Coverage
3.2
Claim Type Diversity
3
Figure Support Quality
3.5
Key observation: Prosecution Defensibility scores highest (3.8/5.0) because the tripartite claim structure (client method, client apparatus, server method) across Claims 1, 8, and 14 provides layered enforcement avenues, and the absence of §112(f) language reduces a major prosecution vulnerability. Claim Type Diversity scores lowest (3.0/5.0) because no computer-readable medium (CRM) or cloud-service apparatus claim was filed — a significant omission for a patent whose commercial embodiment is explicitly described as "a cloud-based network-accessible service" (col. 4 ll. 44–48), leaving a direct design-around path for software distribution without dedicated hardware. Practitioners should note that a continuation application targeting CRM and networked-service apparatus claims would substantially strengthen this patent family's enforcement posture.
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 CRM claim for software distribution Server apparatus claim entirely absent No multi-user shared anchor session claim
Unlock Full Analysis — Free Frequently asked questions
US 11,922,560 B2 — 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