A method for personalized spatial keyword privacy query of indoor multi-users based on GIS enhanced index tree

Abstract

The application relates to the field of privacy protection query schemes, in particular to an indoor multi-user personalized spatial keyword privacy query method based on a GIS enhanced index tree. In view of the demand of multi-user spatial keyword privacy query in an indoor environment, a GISEnhancedIndexTree index structure is constructed by fusing Hilbert coding, an R tree, an encrypted Bloom filter and an EASPE encrypted vector, and spatial and text information of indoor objects are encrypted and indexed. During query, a user request is encrypted and processed into a trapdoor, a server performs spatial, floor and keyword pre-filtering in the index tree according to the trapdoor, calculates the similarity of encrypted vectors by means of EASPE, and returns the encrypted result to the user after threshold filtering, score aggregation and sorting. Meanwhile, a comprehensive position vector construction method and a privacy protection coordinate conversion method based on a local coordinate system are designed to guarantee the privacy safety of the whole data flow. The method can effectively protect the privacy of users and improve the efficiency and accuracy of indoor multi-user personalized spatial keyword query.

Description

Technical Field

[0001] This invention relates to the field of privacy protection query solutions, and more specifically to a method for personalized spatial keyword privacy query for multiple users indoors based on an enhanced GIS index tree. Background Technology

[0002] With the development of indoor positioning technologies (such as Wi-Fi RTT, BLE 5.1, UWB) and location-based services (LBS), the demand for indoor spatial keyword queries (e.g., "finding a quiet cafe near the 3rd floor") is increasing. Users outsource data and queries to cloud servers to save local resources, but this raises serious privacy concerns. Privacy-preserving spatial keyword query (PPSKQ) has become an important research direction.

[0003] The closest existing technical solution:

[0004] 1.e1—《A personalized query method for spatial keywords in indoor environments》This scheme proposes the ISKIR-tree index, which integrates Hilbert encoding, Bloom filters, and distance matrices to support personalized queries for indoor spaces. It returns results through a scoring function that comprehensively considers text similarity, spatial proximity, and user preferences.

[0005] Disadvantages: Its privacy protection mechanism is relatively weak. The paper does not mention strong encryption of data (object location, keywords) and query vectors (such as using ASPE / EASPE). Privacy relies on the index structure itself rather than cryptographic guarantees, making it vulnerable to privacy inference attacks. Its multi-user queries are more like independently processed aggregations than true privacy-protected collaborative queries.

[0006] 2.e2—《Efficient Privacy-Preserving Spatial Data Query in CloudComputing》 This solution is based on enhanced ASPE (EASPE) encryption technology, providing strong cryptographic security guarantees (IND-CPA), and designs an index based on Geohash and R-tree (GR-tree) to achieve efficient sub-linear queries.

[0007] Disadvantages: It mainly targets outdoor environments (using Geohash and WGS84 coordinates) and does not model or handle the special characteristics of indoor environments (such as floors, indoor zoning, indoor distance calculation, and local coordinate systems). Its core solution is exact matching (inner product is 0), rather than ranking based on similarity, making it difficult to support personalized needs such as "nearest" or "most similar".

[0008] 3. Other related technologies: For example, methods based on homomorphic encryption or secure multi-party computation, although highly secure, have huge computational overhead and are difficult to meet the real-time requirements of indoor LBS.

[0009] Summary of the shortcomings of existing technologies:

[0010] 1. The e1 solution lacks security, lacks strong encryption protection, and cannot resist attacks from untrusted cloud servers.

[0011] 2. The e2 scheme lacks support for indoor space, and its geocoding and indexing structure is not suitable for indoor multi-story buildings and indoor distance semantics.

[0012] 3. Both of the above have limitations in efficiently supporting personalized sorting queries for multiple users. The sorting in e1 is not performed in the encrypted domain, while e2 focuses on Boolean range queries rather than sorting. Summary of the Invention

[0013] To overcome the shortcomings of existing technologies, this invention provides a method for personalized spatial keyword privacy query for multiple indoor users based on GIS enhanced index tree;

[0014] Specific objectives include:

[0015] 1. Achieve joint privacy protection for "location-keyword": Encrypt the location vector and keyword semantic vector through the EASPE encryption component, combine trapdoor technology to support similarity calculation in the encrypted state, and use encrypted Bloom filter to achieve keyword pre-retrieval to avoid privacy leakage;

[0016] 2. Improve spatial retrieval accuracy and adaptability: Combine GIS tools to achieve "indoor local coordinates → WGS84 → UTM" conversion, introduce Hilbert encoding to compress spatial features, construct an enhanced GIS index tree, and adapt to global and local spatial scenarios;

[0017] 3. Optimize the performance of multi-user collaborative queries: Design a user weighting mechanism and a multi-dimensional scoring model of "keyword similarity + location similarity + accessibility" to achieve the integration of multi-user preferences and improve the accuracy of collaborative queries;

[0018] 4. Improve query efficiency: Construct a hierarchical filtering process of "spatial filtering → floor matching → keyword pre-checking → encrypted matching" to reduce invalid calculations and lower response latency in large-scale scenarios.

[0019] The technical solution adopted by this invention to solve its technical problem is:

[0020] A keyword privacy-preserving indoor query index structure integrating multi-level indexes includes a Hilbert encoding module, an R tree index module, an encrypted Bloom filter module, an EASPE encrypted vector module, and indoor floor grouping units;

[0021] The Hilbert encoding module is used to receive the two-dimensional planar coordinates (x, y) of indoor objects and convert them into one-dimensional Hilbert encoded values ​​to preserve spatial locality;

[0022] The R-tree index module is constructed using rtree.index, which creates a minimum bounding rectangle (MBR) for the UTM coordinates of indoor objects. During a query, the rtree_index.intersection() method recursively checks the intersection of the node MBR with the query box from the root node, and quickly returns the ID of the intersecting object to achieve efficient spatial range query.

[0023] The encrypted Bloom filter module is a joint Bloom filter. It uses a key (bloom_key) to initialize the hash function. All Bloom filters for indoor objects are built using this key, and all queries also use this key to check keywords. This is used to quickly determine whether "at least one word in the query keyword set may exist in the object" without exposing the specific matching keywords.

[0024] The EASPE encryption vector module includes an encrypt unit, a generate_trapdoor unit, and a match unit. The encrypt unit encrypts the 40-dimensional position vector and the 16-dimensional keyword vector to generate two encrypted fragments ((e1,e2)). The generate_trapdoor unit generates a trapdoor vector ((t1,t2)) from the query vector. The match unit calculates the cosine similarity approximation between the encrypted vector and the trapdoor vector without knowing the plaintext and provides IND-CPA security guarantee.

[0025] The indoor floor grouping unit groups indoor objects by floor to form index leaf nodes. The root node manages all floor child nodes. All modules are integrated through this unit into a unified index (GISEnhancedIndexTree) that supports complex indoor environments.

[0026] A keyword privacy protection query processing method for multiple users includes the following steps: S1: Receive multiple user query requests. Each request includes local coordinates loc (referenced to the indoor local origin), keyword list keywords, user preferences, maximum distance the user is willing to walk (max_distance), current floor of the user, unique user identifier user_id, weight (each user's weight value is less than 1) reflecting the importance of user preferences in the multi-user query, spatial relationship expected by the user (spatial_relation), and buffer radius (buffer_radius) defining the query range. Convert all request information into encrypted trapdoors using the generate_trapdoors method.

[0027] S2: The server performs spatial filtering by calling the spatial_filter() method of GISEnhancedIndexTree to obtain buffer_zone (Shapely geometry object) from the user query, and calls the rtree_index.intersection(user_query.buffer_zone.bounds) method to obtain the object IDs in the buffer, forming a spatial candidate set spatial_candidates;

[0028] S3: Perform floor and keyword pre-filtering, traverse each floor node of the index tree, and skip if the floor of a node is not in the set of all user target floors; for the remaining nodes, extract the encrypted Bloom filter of any object in the node, check all user query keywords, and count the number of users with "possible" matching results (hits). If the number of hits is less than the preset minimum number of matching users (min_users), skip the node.

[0029] S4: For objects that pass the pre-filter and are in spatial_candidates, use the EASPE.match() method to calculate the encrypted location vector similarity loc_scores and encrypted keyword vector similarity kw_scores between the object and each user; the encrypted location vector of the object is 40-dimensional, obtained by concatenating local coordinates, WGS84 coordinates, UTM coordinates, Hilbert encoded values, and floor information, and then encrypting it with EASPE; the encrypted keyword vector of the object is 16-dimensional, obtained by encoding the keyword list with SemanticEncoder and then encrypting it with EASPE.

[0030] S5: Perform threshold filtering and score aggregation, check if at least min_users users have loc_scores exceeding the location similarity threshold loc_th and kw_scores exceeding the keyword similarity threshold kw_th; calculate the accessibility score accessibility_score based on floor switching cost and path smoothness; extract the weight of each user, and calculate the weighted average of loc_scores and kw_scores according to the formula sum (ls * w for ls, w in zip (loc_scores,weights)) / norm to obtain loc_score and kw_score; store candidate objects and (obj, loc_score, kw_score, accessibility_score) tuples in the candidates list;

[0031] S6: Processed using the MultiUserScoring class, the total_score() method calculates the overall score according to the formula (alpha*kw_score+ beta*loc_score + gamma*accessibility_score) / (alpha+beta+gamma) (alpha is the keyword weight, beta is the location weight, and gamma is the accessibility weight), and the rank() method sorts the results in descending order of the overall score and returns the results; all processes are performed in encrypted or trapdoor state, and the server cannot obtain plaintext information.

[0032] A comprehensive location vector construction method suitable for indoor environments includes the following steps: S1: Obtain the local coordinates (two-dimensional or three-dimensional Cartesian coordinates with the local indoor origin as a reference), WGS84 coordinates, UTM coordinates (obtained by converting local coordinates through GISUtils), Hilbert encoded values ​​(obtained by encoding local coordinates through HilbertEncoder) and floor information of indoor objects;

[0033] S2: Standardize and concatenate the local coordinates, WGS84 coordinates, UTM coordinates, Hilbert encoded values, and floor information to form a 40-dimensional initial position vector;

[0034] S3: Using the encrypt unit of the EASPE encryption module, the initial position vector is encrypted using a random matrix (M1,M2), a random permutation (perm), and a random mask (s) to generate two encrypted fragments ((e1,e2)) and obtain the encrypted composite position vector;

[0035] S4: The distance and similarity of the encrypted integrated location vector are calculated using the EASPE.match() method. The higher the similarity, the closer the indoor objects are in space and the more matched the floor information is. This is used for location privacy protection in indoor multi-user personalized space keyword queries.

[0036] A privacy-preserving coordinate transformation method based on a local coordinate system includes the following steps: S1: Preset an indoor fixed reference point (such as an elevator entrance) as the local origin;

[0037] S2: Establish a local coordinate system, setting the coordinate axis directions with the local origin as the origin, in meters;

[0038] S3: Obtain the original location information of indoor objects or users and convert it into local coordinates in the local coordinate system;

[0039] S4: When spatial calculations are required, GISUtils is used to convert local coordinates to WGS84 coordinates (adapted to the global positioning standard) and UTM coordinates (used for spatial calculations and R tree index construction). The conversion is completed internally by the system.

[0040] S5: When providing location information to external parties, only expose local coordinates or their EASPE-encrypted vectors, hiding WGS84 coordinates to protect absolute geographic location privacy.

[0041] Different indoor scenarios (such as shopping malls and office buildings) can correspond to independent local coordinate systems, and the coordinate transformation of each scenario is independent of each other, further protecting location privacy.

[0042] The beneficial effects of this invention, a method for personalized spatial keyword privacy query for multiple indoor users based on an enhanced GIS index tree, are as follows:

[0043] 1. Enhanced privacy protection: Compared to the e1 scheme, this invention introduces the EASPE encryption algorithm, which has undergone formal security proof (IND-CPA), and is resistant to known-plaintext attacks and chosen-plaintext attacks, providing cryptographic-level security guarantees, while the e1 scheme lacks such encryption mechanisms.

[0044] 2. Better adaptability to indoor environments: Compared to the e2 solution (for outdoor Geohash), this invention is specifically designed for indoor environments, handling issues such as floors, indoor zoning, and indoor distance calculations, and more effectively handling the proximity of indoor spaces through Hilbert coding and local coordinate systems.

[0045] 3. Superior multi-user personalization support: Compared with the e1 and e2 solutions, this invention explicitly proposes and implements a privacy protection processing flow for multi-user queries, which can comprehensively consider the weights and preferences of different users and return a unified, sorted, personalized result list, a scenario that existing solutions have not fully considered.

[0046] 4. Balance between efficiency and accuracy: By adopting a three-layer filtering strategy of "R tree spatial filtering -> Bloom filter keyword coarse screening -> EASPE precise similarity calculation", the number of objects that need to be subjected to expensive encryption calculations is greatly reduced while ensuring high accuracy, thus improving efficiency. Attached Figure Description

[0047] The present invention will now be described in further detail with reference to the accompanying drawings and specific implementation methods.

[0048] Figure 1 A flowchart for a keyword privacy protection query processing method for multi-user applications;

[0049] Figure 2 A flowchart illustrating the interaction process between the data owner, the cloud server, and the authorized user;

[0050] Figure 3 This is a schematic diagram of the hierarchical index structure of the GIS Enhanced Index Tree. Detailed Implementation

[0051] In a system for a personalized spatial keyword privacy query method for indoor multi-users based on a GIS-enhanced index tree:

[0052] Each function box contains the following components:

[0053] (1) User Query:

[0054] *User location: A local coordinate loc, a relative coordinate with a local indoor origin such as the elevator entrance as a reference. It is usually a two-dimensional or three-dimensional Cartesian coordinate (such as (x, y) or (x, y, floor)), and the unit can be meters or other units.

[0055] *Keyword list: e.g., ["coffee", "sugar-free", "with socket"]

[0056] *User preferences: e.g., {"Coffee brand": "Starbucks", "Atmosphere": "Quiet"}

[0057] *Maximum distance (max_distance): The farthest distance a user is willing to walk, used to determine the buffer radius for spatial queries.

[0058] *Floor: The user's current floor number, such as 3 or "L3". The system will prioritize checking objects on the user's floor, as crossing floors usually means a longer reach (requiring finding an elevator / stairs). This is an efficient primary filter.

[0059] *User ID (user_id): A unique identifier for the user, used to ensure that the user is a legitimate registered user.

[0060] *Weight: In a multi-user query, this indicates how important a user's preference is relative to other users in the group. It is a numerical value, and the user's weight is less than 1.

[0061] * Spatial Relation: The type of spatial relationship the user expects between the user and the target object, such as "near" (nearby) or "inside" (a store within a certain area).

[0062] * Buffer radius (buffer_radius): Defines the radius of the spatial query range. It is directly used in the R tree index.intersection() method to quickly retrieve all candidate objects located within this region from the spatial index.

[0063] * loc, floor, max_distance, buffer_radius, spatial_relation → Used for spatial filtering, quickly finding a set of candidate locations on an R tree index.

[0064] * keywords, preferences → Used for keyword filtering and similarity calculation, using Bloom filters and EASPE encrypted matching to find content-related candidate sets.

[0065] EASPE encryption is an improved encryption tool based on the original ASPE technology, providing stronger data security. It adds three random numbers and a random permutation π to the original d-dimensional data, transforming it into d+3 dimensions. After a d+3-dimensional permutation, the data is divided according to a partition vector and encrypted using keys M1 and M2. This design makes EASPE indistinguishable under chosen-plaintext attacks (IND-CPA), ensuring that cloud servers cannot deduce the original information from the encrypted data.

[0066] * preferences, weight, user_id → Used to perform personalized weighted scoring and ranking after encrypted similarity calculation, determining the final ranking of the results.

[0067] * user_id → Used for system management and security authentication.

[0068] Before being sent to the cloud server, all of the above information is converted into encrypted trapdoors using the generate_trapdoors method, ensuring that the cloud server cannot know the plaintext content throughout the entire query process, thus achieving comprehensive privacy protection.

[0069] (2) Query Processor:

[0070] The MultiUserQuery class manages multi-user query requests. An instance of this class represents a composite query that needs to be processed and includes requests from multiple users.

[0071] *PrivacyQuery.query() method:

[0072] It contains the following fields, multi_query: A MultiUserQuery object containing query requests for all users, global weight, and focus mode.

[0073] index_tree: A pre-built GISEnhancedIndexTree index tree object that provides data access and spatial filtering capabilities.

[0074] loc_th (location similarity threshold): A floating-point number. For an object to be considered a valid match, its location similarity to a user must be higher than this threshold.

[0075] kw_th (keyword similarity threshold): A floating-point number. For an object to be considered a valid match, its keyword similarity to a user's keyword must exceed this threshold.

[0076] min_users (minimum number of matching users): An integer. An object must satisfy the query condition of at least min_users users (i.e., exceed the threshold) to be considered a candidate result. Used to control the group relevance of the results.

[0077] The flow of the query() method:

[0078] a. Spatial filtering: The empty set spatial_candidates calls index_tree.spatial_filter(uq) to obtain the object IDs within all user query buffers. This is the first and coarsest level of filtering.

[0079] b. Floor and keyword pre-filtering:

[0080] l Traverse each floor node (node) of the index tree.

[0081] l Floor check: If the node floor is not in the set of target floors of all users, skip it.

[0082] l Bloom filter check: Use the Bloom filter of any object within a node to check all user query keywords. The hits variable records how many users' query keywords may match the node.

[0083] If hits < min_users, skip the entire node.

[0084] c. Exact encrypted similarity calculation:

[0085] l Perform exact calculations on the objects that pass the pre-filtering and are in spatial_candidates.

[0086] l loc_scores: A list storing the similarity scores (calculated by EASPE.match) of the object with the encrypted location vectors of each user.

[0087] l kw_scores: A list storing the similarity scores of the object with the encrypted keyword vectors of each user.

[0088] d. Threshold filtering and score aggregation:

[0089] l Check whether there are enough (>= min_users) users whose loc_scores and kw_scores exceed the threshold.

[0090] l accessibility_score: (Reachability score) Calculated based on floor switching cost, path smoothness, etc.

[0091] l weights: A list composed of the weights extracted from each UserQuery.

[0092] `loc_score`: A weighted average of the location scores for all users. `sum(ls * w for ls, w inzip(loc_scores, weights)) / norm`

[0093] l kw_score: A weighted average of the keyword scores for all users.

[0094] e. Results Collection: Store all filtered candidates and their scores in a list named `candidates`. Each element is a tuple (obj, loc_score, kw_score, accessibility_score).

[0095] The MultiUserScoring class is responsible for performing comprehensive scoring and sorting on the candidate list obtained from PrivacyQuery.

[0096] Its total_score() method includes the following fields:

[0097] l multi_query: Used to retrieve the global weight parameters alpha, beta, gamma.

[0098] Alpha (keyword weight): controls the importance of keyword similarity in the final score.

[0099] beta (positional weight): controls the importance of positional proximity in the final score.

[0100] gamma (accessibility weight): controls the importance of accessibility in the final score.

[0101] l obj: Candidate object.

[0102] l loc_score: The position score of this object after aggregation.

[0103] l kw_score: The aggregated keyword score for this object.

[0104] l accessibility_score: The accessibility score of this object.

[0105] Its total_score() method logic: Calculates the weighted composite score: (alpha * kw_score + beta * loc_score + gamma * accessibility_score) / (alpha + beta + gamma)

[0106] Its rank() method:

[0107] Input: multi_query and a list of candidates.

[0108] l Processing: For each element in the candidates list, call total_score() to calculate the final overall score.

[0109] Output: Returns a new list sorted in descending order of overall score.

[0110] Summarize:

[0111] PrivacyQuery.query() is used to perform:

[0112] Receive a multi-user query task.

[0113] We strictly follow the workflow of "space -> keyword pre-filtering -> precise calculation".

[0114] Handles all logic related to encrypted calculations and threshold determination.

[0115] Output a preliminary candidate list containing the scores for each object.

[0116] MultiUserScoring is used for decision-making: based on preset weights (alpha, beta, gamma), multiple scores are combined into a final, comparable composite score, generating a final ordered list of results.

[0117] All of these processes are performed in encrypted or trapdoor states, so the cloud server cannot see the user's real location, query keywords, or plaintext information of database objects, thus achieving the goal of privacy protection.

[0118] (3) GIS Enhanced Index Tree:

[0119] The GISEnhancedIndexTree class iterates through each indoor object (IndoorObject), sequentially calling the following components to process the objects and form the final encrypted index structure.

[0120] l Call GISUtils: Perform coordinate transformation (WGS84↔UTM)

[0121] The global standard WGS84 is not ideal for calculating distances and areas, and UTM (Universal Projected Dimensioning) is very inefficient.

[0122] Suitable for local spatial calculations and indexing. Indoor environments typically use local coordinates (units...).

[0123] (meters). GISUtils converts it to WGS84 and UTM for subsequent R tree indexing and...

[0124] Distance-based scoring forms the basis.

[0125] GISUtils is a utility class for coordinate transformation, including converting local indoor coordinates to WGS84 coordinates and converting WGS84 coordinates to UTM coordinates. Since the global standard WGS84 is not ideal for calculating distances and areas, while UTM (unified planar projection coordinates) is suitable for local spatial calculations and indexing, indoor environments typically use local coordinates (in meters). Using GISUtils for coordinate transformation provides a suitable coordinate basis for subsequent R-tree indexing and distance-based scoring.

[0126] l Call HilbertEncoder: Performs Hilbert curve space encoding, converting two-dimensional planar coordinates (x, y) into a one-dimensional Hilbert encoded value (an integer).

[0127] The SemanticEncoder is called to perform semantic encoding of keywords, mapping a list of text keywords (such as ["coffee", "quiet"]) into a fixed-length 16-dimensional real-valued vector that reflects a certain semantic meaning. For example, if the query is for "coffee shop" and the object tag is "coffee shop", it will still match because they are normalized to the same word or have similar vector representations. Transforming the text matching problem into vector similarity calculation also prepares the ground for subsequent encryption calculations.

[0128] l Call EASPE: Encrypt the position and keyword vectors. The `encrypt` function encrypts the plaintext vector (a 40-dimensional position vector or a 16-dimensional keyword vector) to generate two encrypted fragments ((e1, e2)). The `generate_trapdoor` function generates a special "trapdoor" vector ((t1, t2)) for the query vector.

[0129] The `match` function directly calculates the cosine similarity approximation between the encrypted vector (e1, e2) and the trapdoor vector (t1, t2) without knowing the plaintext. It provides a strong cryptographic security guarantee (IND-CPA), ensuring that the cloud server cannot deduce the original information from the encrypted data.

[0130] The `EncryptedBloomFilter` function is called to construct a federated Bloom filter. This is used to quickly check whether at least one word in a set of query keywords might exist in a certain object. The federated nature of the filter means that a single key (`bloom_key`) is used to initialize the hash function. All Bloom filters for all objects are constructed using the same key, and all queries use the same key for checking. Third parties who do not know this key cannot perform effective queries. Furthermore, the specific keyword that matched is not revealed during the query process.

[0131] The `rtree.index` function calls the R-tree index: This performs a spatial index. The R-tree index is used first during a query.

[0132] Perform a spatial range query to narrow down the selection range and avoid a full table scan.

[0133] (4) Spatial Filter (First Layer Filter):

[0134] The `a.GISEnhancedIndexTree.spatial_filter(self, user_query)` method retrieves the pre-computed `buffer_zone` (query buffer region, a Shapely geometry object) from the `user_query` parameter, then calls the `self.rtree_index.intersection(user_query.buffer_zone.bounds)` method, and finally converts the result returned by the R tree into a list and returns it.

[0135] b. Using R-tree indexes for spatial range queries (rtree_index.intersection()): R-trees organize the MBRs (Minimum Bounding Rectangles) of adjacent objects in space under the same node. When querying a bounding box, the R-tree starts from the root node and quickly and recursively checks which nodes' MBRs intersect the query box. The IDs of all intersecting objects are collected and returned.

[0136] c. The process of generating a list of candidate object IDs based on the UTM coordinates and buffer radius queried by the user (in the generate_trapdoors method):

[0137] l Obtain user UTM coordinates: Convert the user's local coordinates (loc) to UTM coordinates (utm_coord) using GISUtils. l Create geometric point: Create a point object based on the UTM coordinates using Shapely's Point class.

[0138] l Generate buffer: Centered on this point and with the user-specified buffer_radius as the radius, call GISUtils.create_buffer (which internally calls Shapely's .buffer() method) to generate a circular region (buffer_zone).

[0139] The final result: This buffer_zone (a polygon) is the user's "query range".

[0140] The buffer_zone.bounds attribute extracts the minimum bounding rectangle of this polygon, which is used for fast intersection detection in R-trees.

[0141] The workflow for the above three to work together:

[0142] 1. Calculate the UTM coordinates for each IndoorObject. Create an MBR based on the UTM coordinates (with a buffer distance of ±5 meters) and insert it into rtree_index.

[0143] 2. When processing user queries, in the generate_trapdoors method, the UTM coordinates are calculated based on the user's loc (location) and buffer_radius (buffer radius), and a buffer_zone (buffer zone) is generated.

[0144] 3. The PrivacyQuery.query method iterates through each user uq, calls the index_tree.spatial_filter(uq) method to retrieve uq.buffer_zone.bounds (the boundaries of the user buffer), and passes it to rtree_index.intersection() for a quick search to see if there is an intersection.

[0145] 4. An R-tree index returns an iterator of the IDs of all objects that intersect with the query box. These IDs are collected into a set (spatial_candidates) for later use in keyword filtering and precise calculations.

[0146] (5) Keyword Filter (Second Layer Filtering):

[0147] a.EncryptedBloomFilter.contains_any() method

[0148] 1. For each user query keyword input, normalize it using the same KeywordProcessor.normalize() method.

[0149] 2. For each normalized word, use keyed hash (hash(w) + seed + query_key) to calculate its multiple positions in the Bloom filter bit array.

[0150] 3. If all bits corresponding to a word are set to 1, return True, indicating "may exist". If at least one bit corresponding to any word is 0, return False, indicating "definitely does not exist".

[0151] b. Use a Bloom filter to pre-check keyword matching

[0152] 1. In the PrivacyQuery.query method, for each floor node, retrieve the Bloom filter of one of the objects (such as node.objects[0]).

[0153] 2. Iterate through all user queries (for uq in user_queries) and check them using the contains_any(uq.keywords, bloom_key) method of the Bloom filter. Count how many user queries (hits) returned "potentially exist" results.

[0154] If even this rapid, false-positive check indicates that a given floor node cannot satisfy a sufficient number of users (min_users), then all objects under that node can be safely skipped without the need for costly encrypted similarity calculations. From a security perspective, the server only knows that "a node's Bloom filter matched a user's query," but it doesn't know which specific keyword was matched.

[0155] c. Combine with synonym processing (KeywordProcessor.normalize()): Before adding keywords to the Bloom filter or performing query checks, process them using the KeywordProcessor.normalize() method.

[0156] Processing content:

[0157] Word segmentation: Use jieba.lcut(kw.lower()) to segment Chinese keywords and perform lowercase processing. (e.g., "cafe" -> ["coffee", "hall"])

[0158] Synonym expansion: Based on the loaded thesaurus, replace words with their standard forms. (For example, normalize "cafe" and "cafe" to "coffee").

[0159] effect:

[0160] Standardization: Ensure that the user's query for "gym" and the object's record for "fitness center" can be normalized to the same word, thereby achieving matching at the Bloom filter level.

[0161] Enhanced robustness: Improves the system's tolerance to the diversity of user input, avoiding missed detections due to different expression methods.

[0162] d. Floor matching check (node.floor matches user floor): Before entering the Bloom filter check, first check if the floor (node.floor) of the current index tree node appears in the target floor set of all user queries ({uq.floor for uq in user_queries}). If the node floor is not in the user set, all objects under that node can be immediately excluded without any further calculations, improving efficiency.

[0163] Summarize:

[0164] These four elements together constitute a two-stage keyword filtering process:

[0165] Phase 1 (Deterministic Filtering): Floor Check. Directly eliminate all irrelevant floors, significantly reducing the workload.

[0166] The second stage (probabilistic filtering): Bloom filter check. In the remaining layers, nodes that are "unlikely" to contain enough user query keywords are quickly eliminated. Synonym processing at this stage ensures semantic recall, upgrading the system's filtering process from literal matching to semantic matching, thus finding all relevant results.

[0167] (6) Encrypted Similarity Calculation: Allows the cloud server to calculate the similarity between data objects and user queries without seeing the plaintext. That is, for a small number of candidate objects that have passed the first two layers of filtering (space, keywords), the similarity between them and each user query is accurately calculated in the encrypted domain, and threshold filtering is performed.

[0168] a. EASPE.match() method:

[0169] This method calculates the cosine similarity of encrypted vectors. It takes four parameters: two fragments (e1, e2) of the encrypted data vector and two fragments (t1, t2) of the query trapdoor vector, and returns a floating-point number between 0 and 1, approximating the cosine similarity of the original encrypted vectors. Throughout the calculation, the cloud server operates on meaningless random fragments (e1, e2) and (t1, t2), making it impossible to deduce the values ​​of the original vectors A and B, yet it still obtains the correct calculation result. The cosine similarity formula is: cos(θ) = (A · B) / (||A|| * ||B||).

[0170] *Location similarity: Compares obj.enc_loc and uq.loc_trapdoor, a cryptographic metric used to measure spatial proximity.

[0171] `obj.enc_loc` is the encrypted location vector of the queried object. This 40-dimensional vector is encrypted by concatenating local coordinates, WGS84 coordinates, UTM coordinates, Hilbert encoding, and floor information.

[0172] `luq.loc_trapdoor`: This is a location trapdoor generated by the user query. It is generated by rules that are symmetric and complementary to the encryption process.

[0173] loc_score = EASPE.match(obj.enc_loc[0], obj.enc_loc[1],uq.loc_trapdoor[0], uq.loc_trapdoor[1])

[0174] The closer the value is to 1, the more similar the location characteristics of the object are to the location characteristics queried by the user; that is, the closer they are spatially, and the more they match information such as floor level. The closer the value is to 0, the less related they are.

[0175] *Keyword similarity: Compares obj.enc_kw and uq.kw_trapdoor, an encrypted metric used to measure the relevance of text.

[0176] `obj.enc_kw`: This is the encrypted keyword semantic vector of the queried object. This 16-dimensional vector is composed of...

[0177] SemanticEncoder encodes the list of keywords of an object and then encrypts it.

[0178] `l uq.kw_trapdoor`: This is a keyword trapdoor generated from the user's search keywords.

[0179] kw_score = EASPE.match(obj.enc_kw[0], obj.enc_kw[1], uq.kw_trapdoor[0], uq.kw_trapdoor[1])

[0180] The closer the value is to 1, the more similar the semantics of the object's keywords are to the semantics of the keywords the user is querying (for example, "coffee" and "coffee shop" will score highly). The closer the value is to 0, the less relevant the text is.

[0181] *Threshold filtering (loc_th and kw_th): loc_th (location similarity threshold) and kw_th (keyword similarity threshold) are parameters of the PrivacyQuery.query method, used to determine whether an object is relevant enough for a particular user.

[0182] process:

[0183] l calculates the loc_scores and kw_scores lists of all users for a candidate object.

[0184] The system checks how many users in these two lists have scores exceeding the threshold:

[0185] if (sum(s > loc_th for s in loc_scores) >= min_users and

[0186] sum(s > kw_th for s in kw_scores) >= min_users):

[0187] The object will only be retained if all conditions are met.

[0188] effect:

[0189] l Control precision: Threshold filtering filters out edge objects that, although they passed the previous coarse screening (Bloom filter may have false positives), have very low actual similarity.

[0190] Multi-user support: The min_users parameter ensures that an object must meet the minimum relevance criterion of at least a sufficient number of users to become a final candidate.

[0191] (7) Scoring and Ranking of Results:

[0192] The `MultiUserScoring.total_score()` method calculates the total score.

[0193] *Formula: Overall Score = (α * kw_score + β * loc_score + γ * accessibility_score) / (α + β + γ)

[0194] Input parameters:

[0195] *multi_query: Used to retrieve the global weight parameters alpha, beta, and gamma.

[0196] *obj: The candidate object itself (in your code implementation, this method does not directly use object properties; the score is passed in from outside).

[0197] *loc_score: The aggregated location similarity score of this object (weighted average according to user weights).

[0198] *kw_score: The keyword similarity score aggregated for this object (weighted average according to user weights).

[0199] *accessibility_score: The accessibility score of this object (set to a constant of 0.8 in the code).

[0200] Output:

[0201] *A floating-point number between 0 and 1, representing the final overall score.

[0202] Weighting parameters: alpha (keywords), beta (location), gamma (reachability)

[0203] *alpha (keyword weight): Controls the importance of keyword similarity (kw_score) in the final score. A higher alpha value indicates greater emphasis on text relevance. For example, when searching for "quiet coffee shop," the alpha should be increased.

[0204] *beta (Location Weight): Controls the importance of location similarity (loc_score) in the final score. A higher beta value indicates greater emphasis on distance. For example, if a user wants to find the "nearest" convenience store, the beta should be increased.

[0205] *gamma (accessibility weight): Controls the importance of accessibility (accessibility_score) in the final score.

[0206] A higher gamma value indicates that the system places greater emphasis on the ease of arrival. This can include complex factors such as the cost of changing floors, the accessibility of the path, and the presence of obstacles. (This step is currently implemented in a simplified manner.)

[0207] The MultiUserScoring.rank() method sorts the results in descending order of their scores. This method takes a MultiUserQuery and a list of candidate objects, calls total_score() to calculate a total score for each object, and then sorts the results based on the scores.

[0208] enter:

[0209] multi_query: A query object for multiple users.

[0210] `candidates`: A list where each element is a tuple (obj, loc_score, kw_score, accessibility_score). This list is from the output of the `PrivacyQuery.query` method.

[0211] Output: A new list sorted by overall score from highest to lowest (descending order). Each element in the list is a tuple of (obj, final_score).

[0212] Summary of the process:

[0213] Input: The PrivacyQuery.query method produces a coarsely filtered list of candidates, each of which already has a weighted average of loc_score and kw_score for the user group, as well as an estimated accessibility_score.

[0214] Aggregation: The MultiUserScoring.total_score() method combines the three scores into a single comprehensive score based on a preset global strategy (alpha, beta, gamma).

[0215] Sorting: The MultiUserScoring.rank() method sorts all candidate objects in descending order based on their overall scores.

[0216] Output: Generate a final ordered list of results and return it to the user. The top of the list is the optimal solution that best meets the personalized needs of multiple user groups.

[0217] (8) Return Results:

[0218] Final candidate list

[0219] Detailed information for each object:

[0220] ID (obj_id)

[0221] Location (loc)

[0222] Floor

[0223] Keywords

[0224] Overall score

[0225] UTM coordinates (utm_coord)

[0226] 2. Detailed technical solution

[0227] (a) Data preprocessing and encrypted index construction (GISEnhancedIndexTree._build method)

[0228] For each indoor object, perform the following steps:

[0229] (1) Coordinate transformation and encoding: Use GISUtils to convert local coordinates to WGS84 and UTM coordinates. Use HilbertEncoder to encode the scaled local coordinates using Hilbert encoding, mapping the two-dimensional space to one dimension while preserving spatial locality.

[0230] (2) Constructing feature vectors:

[0231] Location vector (40-dimensional): Combines local coordinates, WGS84 coordinates, UTM coordinates, Hilbert encoded values, and floor information into a comprehensive location vector.

[0232] Keyword vector (16-dimensional): The set of keywords of an object is mapped to a semantic vector using SemanticEncoder (through random vector allocation and mean pooling).

[0233] (3) Vector encryption: Two independent EASPE instances (loc_easpe and kw_easpe) are used to encrypt the position vector and the keyword vector respectively. EASPE encrypts and fragments the vector using random matrices (M1, M2), random permutations (perm), and random masks (s) to generate ciphertext (enc_loc, enc_kw).

[0234] (4) Bloom filter: Build an EncryptedBloomFilter for each object and add its keywords to the filter using keyed hashing for fast pre-filtering.

[0235] (5) Spatial index: Use the rtree library to create minimum bounding rectangles (MBR) for the UTM coordinates of objects and build spatial indexes for efficient spatial range queries (such as buffer queries).

[0236] (6) Index organization: Group objects by floor to form leaf nodes of the tree.

[0237] (b) Privacy query generation (generate_trapdoors method)

[0238] User queries are processed in a similar manner:

[0239] (1) Coordinate transformation and buffer generation: Convert the user's local location to UTM coordinates and create a query buffer (buffer_zone).

[0240] (2) Trapdoor generation:

[0241] Location trapdoor: Constructs a location vector similar to the object, using loc_easpe.generate_trapdoor

[0242] Generate a location lookup trapdoor (loc_trapdoor). The trapdoor generation uses a masking rule that complements the encryption.

[0243] Keyword Trapdoor: Use SemanticEncoder to encode query keywords and generate keyword query trapdoors (kw_trapdoor) using kw_easpe.generate_trapdoor.

[0244] (c) Safe query processing (PrivacyQuery.query method)

[0245] The cloud server performs the following steps to process multi-user queries:

[0246] (1) Spatial filtering: Using R tree index, quickly find all candidate object IDs (spatial_candidates) located in any user query buffer.

[0247] (2) Floor and keyword pre-filtering:

[0248] * Check whether each floor node in the index tree matches the target floor of the query group.

[0249] Use the object's Bloom filter to check if enough (min_users) of the keywords in the user queries might exist in the node's object. This is a fast, coarse screening that may produce false positives but will not miss any.

[0250] (3) Precise encryption similarity calculation:

[0251] For objects that pass the pre-filtering, calculate their location similarity and keyword similarity with each user's query. This is achieved using the EASPE.match method, which calculates the cosine similarity between the encrypted vector and the trapdoor vector in the encrypted domain without decrypting any data.

[0252] *The weighted composite score of the object is calculated by combining the ratings of all users and based on the preset weights (alpha, beta, gamma) and user weights.

[0253] (4) Result sorting and return: The MultiUserScoring.rank method sorts all candidates in descending order based on the comprehensive score and returns the result that best meets the personalized needs of the multi-user group.

[0254] 3. Encryption Principle of the Core Algorithm (EASPE.match)

[0255] This method is the core of privacy-preserving computation. Although both the data vector E and the trapdoor vector T are randomly encrypted, due to the symmetric design of EASPE (the encryption and trapdoor use the same M1, M2, perm, s), the inner product operation in the encrypted domain, after normalization, can approximately reconstruct the cosine similarity of the original explicit vectors. Throughout the process, the cloud server cannot know the original vector values, yet it can obtain a usable similarity score.

[0256] A keyword privacy-preserving indoor query index structure integrating multi-level indexes includes a Hilbert encoding module, an R tree index module, an encrypted Bloom filter module, an EASPE encrypted vector module, and indoor floor grouping units;

[0257] The Hilbert encoding module is used to receive the two-dimensional planar coordinates (x, y) of indoor objects and convert them into one-dimensional Hilbert encoded values ​​to preserve spatial locality;

[0258] The R-tree index module is constructed using rtree.index, which creates a minimum bounding rectangle (MBR) for the UTM coordinates of indoor objects. During a query, the rtree_index.intersection() method recursively checks the intersection of the node MBR with the query box from the root node, and quickly returns the ID of the intersecting object to achieve efficient spatial range query.

[0259] The encrypted Bloom filter module is a joint Bloom filter. It uses a key (bloom_key) to initialize the hash function. All Bloom filters for indoor objects are built using this key, and all queries also use this key to check keywords. This is used to quickly determine whether "at least one word in the query keyword set may exist in the object" without exposing the specific matching keywords.

[0260] A cryptographic Bloom filter is a tool that combines cryptographic techniques with the principles of Bloom filters. It uses a single key to initialize a hash function, and all Bloom filters for all objects are constructed using the same key. All queries are also checked using the same key. Third parties unaware of this key cannot perform effective queries, and the specific keyword that matched is not revealed during the query process. In this patent, it is used for rapid keyword pre-filtering to protect data privacy.

[0261] The EASPE encryption vector module includes an encrypt unit, a generate_trapdoor unit, and a match unit. The encrypt unit encrypts the 40-dimensional position vector and the 16-dimensional keyword vector to generate two encrypted fragments ((e1,e2)). The generate_trapdoor unit generates a trapdoor vector ((t1,t2)) from the query vector. The match unit calculates the cosine similarity approximation between the encrypted vector and the trapdoor vector without knowing the plaintext and provides IND-CPA security guarantee.

[0262] The indoor floor grouping unit groups indoor objects by floor to form index leaf nodes. The root node manages all floor child nodes. All modules are integrated through this unit into a unified index (GISEnhancedIndexTree) that supports complex indoor environments.

[0263] A keyword privacy protection query processing method for multiple users includes the following steps: S1: Receive multiple user query requests. Each request includes local coordinates loc (referenced to the indoor local origin), keyword list keywords, user preferences, maximum distance the user is willing to walk (max_distance), current floor of the user, unique user identifier user_id, weight (each user's weight value is less than 1) reflecting the importance of user preferences in the multi-user query, spatial relationship expected by the user (spatial_relation), and buffer radius (buffer_radius) defining the query range. Convert all request information into encrypted trapdoors using the generate_trapdoors method.

[0264] S2: The server performs spatial filtering by calling the spatial_filter() method of GISEnhancedIndexTree to obtain buffer_zone (Shapely geometry object) from the user query, and calls the rtree_index.intersection(user_query.buffer_zone.bounds) method to obtain the object IDs in the buffer, forming a spatial candidate set spatial_candidates;

[0265] S3: Perform floor and keyword pre-filtering, traverse each floor node of the index tree, and skip if the floor of a node is not in the set of all user target floors; for the remaining nodes, extract the encrypted Bloom filter of any object in the node, check all user query keywords, and count the number of users with "possible" matching results (hits). If the number of hits is less than the preset minimum number of matching users (min_users), skip the node.

[0266] S4: For objects that pass the pre-filter and are in spatial_candidates, use the EASPE.match() method to calculate the encrypted location vector similarity loc_scores and encrypted keyword vector similarity kw_scores between the object and each user; the encrypted location vector of the object is 40-dimensional, obtained by concatenating local coordinates, WGS84 coordinates, UTM coordinates, Hilbert encoded values, and floor information, and then encrypting it with EASPE; the encrypted keyword vector of the object is 16-dimensional, obtained by encoding the keyword list with SemanticEncoder and then encrypting it with EASPE.

[0267] S5: Perform threshold filtering and score aggregation, check if at least min_users users have loc_scores exceeding the location similarity threshold loc_th and kw_scores exceeding the keyword similarity threshold kw_th; calculate the accessibility score accessibility_score based on floor switching cost and path smoothness; extract the weight of each user, and calculate the weighted average of loc_scores and kw_scores according to the formula sum (ls * w for ls, w in zip (loc_scores,weights)) / norm to obtain loc_score and kw_score; store candidate objects and (obj, loc_score, kw_score, accessibility_score) tuples in the candidates list;

[0268] S6: Processed using the MultiUserScoring class, the total_score() method calculates the overall score according to the formula (alpha*kw_score+ beta*loc_score + gamma*accessibility_score) / (alpha+beta+gamma) (alpha is the keyword weight, beta is the location weight, and gamma is the accessibility weight), and the rank() method sorts the results in descending order of the overall score and returns the results; all processes are performed in encrypted or trapdoor state, and the server cannot obtain plaintext information.

[0269] A comprehensive location vector construction method suitable for indoor environments includes the following steps: S1: Obtain the local coordinates (two-dimensional or three-dimensional Cartesian coordinates with the local indoor origin as a reference), WGS84 coordinates, UTM coordinates (obtained by converting local coordinates through GISUtils), Hilbert encoded values ​​(obtained by encoding local coordinates through HilbertEncoder) and floor information of indoor objects;

[0270] S2: Standardize and concatenate the local coordinates, WGS84 coordinates, UTM coordinates, Hilbert encoded values, and floor information to form a 40-dimensional initial position vector;

[0271] S3: Using the encrypt unit of the EASPE encryption module, the initial position vector is encrypted using a random matrix (M1,M2), a random permutation (perm), and a random mask (s) to generate two encrypted fragments ((e1,e2)) and obtain the encrypted composite position vector;

[0272] S4: The distance and similarity of the encrypted integrated location vector are calculated using the EASPE.match() method. The higher the similarity, the closer the indoor objects are in space and the more matched the floor information is. This is used for location privacy protection in indoor multi-user personalized space keyword queries.

[0273] A privacy-preserving coordinate transformation method based on a local coordinate system includes the following steps: S1: Preset an indoor fixed reference point (such as an elevator entrance) as the local origin;

[0274] S2: Establish a local coordinate system, setting the coordinate axis directions with the local origin as the origin, in meters;

[0275] S3: Obtain the original location information of indoor objects or users and convert it into local coordinates in the local coordinate system;

[0276] S4: When spatial calculations are required, GISUtils is used to convert local coordinates to WGS84 coordinates (adapted to the global positioning standard) and UTM coordinates (used for spatial calculations and R tree index construction). The conversion is completed internally by the system.

[0277] S5: When providing location information to external parties, only expose local coordinates or their EASPE-encrypted vectors, hiding WGS84 coordinates to protect absolute geographic location privacy.

[0278] Different indoor scenarios (such as shopping malls and office buildings) can correspond to independent local coordinate systems, and the coordinate transformation of each scenario is independent of each other, further protecting location privacy.

[0279] Key points of this invention:

[0280] 1. A keyword privacy-preserving indoor query index structure integrating multi-level indexes: The key is to organize Hilbert encoding (preserving spatial locality), R-tree (efficient spatial range query), encrypted Bloom filter (fast keyword pre-filtering), and EASPE encrypted vector (strong security and computability) according to indoor floors to form a unified index (GISEnhancedIndexTree) that supports complex indoor environments.

[0281] 2. A keyword privacy protection query processing method for multiple users: The key is to support multiple users to submit queries, and to perform group keyword pre-filtering on the server side through a Bloom filter. Then, EASPE is used to calculate the similarity of each object for each user in the encrypted domain. Finally, the results that meet the group preferences are obtained through weighted aggregation and sorting. The whole process is carried out on the ciphertext.

[0282] 3. A comprehensive location vector construction method suitable for indoor environments: The local coordinates, global coordinates, UTM coordinates, Hilbert encoded values, and floor information of an object are fused into a vector, and encrypted using EASPE, so that the encrypted distance and similarity comparison can accurately reflect the semantics of the indoor space.

[0283] 4. A privacy-preserving coordinate transformation method based on a local coordinate system: The system performs coordinate transformation and calculation based on a preset local origin (such as the Shanghai Center), and exposes the local coordinates or encrypted vectors relative to this origin, effectively hiding the absolute geographical location information.

[0284] Example 1: Multi-department joint space query scenario in a smart office building

[0285] I. Application Scenarios

[0286] A company's Shanghai headquarters office building has 12 floors, encompassing 120 indoor functional areas including meeting rooms, R&D labs, lounges, printing areas, and tea rooms. Each floor is equipped with a UWB indoor positioning system (positioning accuracy 0.5 meters). On a certain weekday morning, six employees from the Marketing Department (3 people), R&D Department (2 people), and Administration Department (1 person) need to jointly search for locations that meet the following requirements for a cross-departmental ad-hoc collaborative meeting using the company's internal app:

[0287] (1) Marketing Department Employee A (located in office 502 on the 5th floor, local coordinates (25,40)): needs a "meeting room that can accommodate 8 people and is equipped with a projection device", acceptable within a range of 30 meters, weight 0.9 (high priority of demand);

[0288] (2) R&D Department Employee B (located in Laboratory 710 on the 7th floor, local coordinates (60,85): needs "space with high-speed Wi-Fi support and whiteboard", acceptable range within 50 meters, weight 0.7;

[0289] (3) Administrative staff C (located in the 2nd floor, office 205, local coordinates (15,20)): must be in an area "near the elevator entrance and with tea service", within 20 meters is acceptable, weight 0.6;

[0290] Based on this patented algorithm, the enterprise app backend can quickly return a list of locations that meet the collaborative needs of multiple departments while protecting the privacy of employee location, query intent, and office area data, and at the same time avoiding the leakage of sensitive individual query information (such as the R&D department's special need for "high-speed Wi-Fi").

[0291] II. Operating Procedures of this Patent

[0292] 1. Offline Preparation Phase: Data Preprocessing and GIS Enhanced Index Tree Construction (Executed by Enterprise IT Department)

[0293] The company's IT department pre-converted all functional areas of the office building into IndoorObject instances and constructed a "spatial-keyword-encryption" composite index using GISEnhancedIndexTree. The specific steps are as follows:

[0294] (1) Data modeling of indoor functional areas

[0295] Taking three candidate collaboration locations within an office building as an example, construct an IndoorObject object:

[0296] Location 1 (ID:508): 5th floor medium-sized conference room, local coordinates (28,45), keywords ["conference room", "8-person capacity", "projection equipment", "within 30 meters of elevator"], floor 5, address "5th floor, room 508", space type "closed conference room";

[0297] Location 2 (ID:715): 7th floor R&D collaboration area, local coordinates (65,90), keywords ["collaboration area", "high-speed Wi-Fi", "whiteboard", "accommodates 6 people"], floor 7, address "7th floor, room 715", space type "open office area";

[0298] Location 3 (ID:208): 2nd floor administrative reception area, local coordinates (18,25), keywords ["reception area", "tea service", "within 10 meters of elevator", "accommodates 6 people"], floor 2, address "2nd floor, room 208", space type "semi-open area".

[0299] (2) GIS coordinate transformation and spatial coding

[0300] Spatial feature processing is accomplished using the GISUtils utility class and HilbertEncoder from the patented algorithm.

[0301] L-coordinate transformation: Using the office building's reference point (121.452°E, 31.230°N) as the origin, the local coordinates (28, 45) of location 1 are converted to WGS84 coordinates (121.4523°E, 31.2304°N), and then converted to planar coordinates (358750, 3457200) in the 32N coordinate system through UTM projection, which facilitates distance calculation and R-tree index construction;

[0302] lHilbert encoding: The local coordinates are scaled by a factor of 10,000 according to the patented algorithm (to avoid decimal errors). The (28,45) coordinates of location 1 are scaled to (280000,450000). A one-dimensional Hilbert code 98 is generated by HilbertEncoder (order=4) to preserve spatial locality (adjacent regions have similar codes).

[0303] (3) Feature vector construction and encryption

[0304] 40-dimensional location vector: By splicing together the local coordinates (28,45), WGS84 coordinates (121.4523,31.2304), UTM coordinates (358750,3457200), Hilbert code 98, floor 5, and other information of location 1, a 40-dimensional location vector is formed.

[0305] 16-dimensional keyword semantic vector: The keywords ["conference room", "8-person capacity", "projection equipment"] are mapped to semantic vectors using a SemanticEncoder (e.g., "conference room" corresponds to vector [0.21, 0.15, ..., 0.08], "projection equipment" corresponds to [0.18, 0.09, ..., 0.12], and finally a 16-dimensional vector is obtained through mean pooling).

[0306] lEASPE encryption: Using the EASPE component in the patented algorithm, the position vector and keyword vector are encrypted by random matrix M1 / M2, random permutation perm, and random mask s respectively, generating enc_loc (position ciphertext: (e1_loc, e2_loc)) and enc_kw (keyword ciphertext: (e1_kw, e2_kw)), which meets the IND-CPA security standard;

[0307] l Encrypted Bloom Filter Construction: The keywords of venue 1 are inserted into the filter using EncryptedBloomFilter (key 0x8a7f2d1c) for subsequent fast keyword pre-filtering, avoiding full encrypted computation.

[0308] (4) GIS Enhanced Index Tree Organization

[0309] Build a hierarchical index:

[0310] The root node (l): a non-leaf node that manages 12 floor child nodes;

[0311] Floor 5 child node: leaf node, storing all IndoorObjects on floor 5 (including location 1), each object is associated with the minimum bounding box of UTM coordinates (e.g., location 1 is (358745, 3457195, 358755, 3457205));

[0312] lR Tree Spatial Index: Inserts the UTM bounding boxes of all locations into the rtree_index, supporting millisecond-level spatial range queries.

[0313] 2. Online query phase: Multi-user privacy query and result matching (executed in real time)

[0314] (1) User query modeling and trapdoor generation

[0315] Six employees submitted query requests via the app. The backend converted these requests into UserQuery instances and used the "generate_trapdoors method" in this patented algorithm to generate privacy-protecting trapdoors.

[0316] Query processing for user A:

[0317] a. Coordinate transformation: Local coordinates (25, 40) → WGS84 coordinates (121.4522°E, 31.2303°N) → UTM coordinates (358748, 3457198);

[0318] b. Buffer generation: Generate a circular buffer in UTM coordinates (center (358748, 3457198), radius 30 meters) with buffer_radius=30 for spatial filtering;

[0319] c. Trapdoor Generation: Construct a 40-dimensional location vector (including local coordinates, Hilbert encoding 96, and floor 5) consistent with the location vector structure, and generate the location trapdoor loc_trapdoor_A using loc_easpe.generate_trapdoor; after semantic encoding of the keywords ["8-person meeting room", "projection equipment"], generate the keyword trapdoor kw_trapdoor_A using kw_easpe.generate_trapdoor;

[0320] Multi-user query aggregation: The UserQuery of 6 users is encapsulated into a MultiUserQuery object, and global weights are set according to the patented algorithm: alpha=0.4 (keyword weight), beta=0.3 (location weight), gamma=0.3 (accessibility weight) to balance multi-dimensional needs.

[0321] (2) Three-layer filtering: space → floor → keyword pre-check (core process of this patent)

[0322] This patented algorithm uses the PrivacyQuery.query method to perform hierarchical filtering, reducing unnecessary calculations.

[0323] a. Spatial filtering (first layer):

[0324] Call GISEnhancedIndexTree.spatial_filter to quickly retrieve the location IDs within each user's buffer range using the R tree index:

[0325] User A's buffer covers location 1 (ID:508).

[0326] User B's buffer covers location 2 (ID:715).

[0327] User C's buffer covers location 3 (ID:208), summarizing the candidate space set {508,715,308};

[0328] b. Floor Filtering (Second Floor):

[0329] Traverse the 12 floor child nodes of the root node of the index tree and filter the nodes that match the user's target floor (5, 7, 2): only keep the nodes of floor 5 (including venue 1), floor 7 (including venue 2), and floor 2 (including venue 3), and directly exclude the other 10 floors, reducing the amount of data by 83%.

[0330] c. Keyword Bloom pre-filtering (third layer):

[0331] For the retained floor nodes, take the EncryptedBloomFilter of any object within the node (e.g., location 1 of the node on floor 5) and check if it meets the keyword requirement of at least min_users=3 users:

[0332] The Bloom filter in location 1 matches user A's ["8-person meeting room", "projection equipment"], user B's ["accommodates 6 people"] (false positives are allowed), and user C's ["within 30 meters of elevator entrance"], with hits=3≥min_users=3, thus passing the pre-filter;

[0333] (3) Encryption similarity calculation and multi-user rating

[0334] Using the EASPE.match algorithm and the "MultiUserScoring" class in this patented algorithm, precise matching and scoring are completed in the encrypted domain.

[0335] a. Encryption similarity calculation:

[0336] Location similarity: The location similarity between the location and the user is calculated using EASPE.match(obj.enc_loc, uq.loc_trapdoor): Location 1 has a location similarity of 0.92 with user A (distance 8 meters), 0.35 with user B (distance 60 meters across floors), and 0.12 with user C (distance 120 meters across floors).

[0337] Keyword similarity: Semantic similarity was calculated using EASPE.match(obj.enc_kw, uq.kw_trapdoor): Location 1 has a keyword similarity of 0.95 with User A (matching "8-person capacity" and "projection equipment"), 0.68 with User B (matching "accommodates 6 people"), and 0.72 with User C (matching "within 30 meters of elevator entrance").

[0338] b. Multi-user weighted rating:

[0339] Calculate the aggregate score based on user weights (A: 0.9, B: 0.7, C: 0.6, total weight 2.2):

[0340] Location aggregation score for location 1: (0.92×0.9 + 0.35×0.7 + 0.12×0.6) / 2.2 ≈0.51;

[0341] Keyword aggregation score for Location 1: (0.95×0.9 + 0.68×0.7 + 0.72×0.6) / 2.2 ≈0.81;

[0342] Accessibility score: fixed at 0.8 according to the algorithm of this patent (location 1 is close to the elevator entrance on the 5th floor, and the cost of changing floors is low);

[0343] Overall score: Calculated according to the patent formula (alpha×kw_score + beta×loc_score + gamma×accessibility_score) / (alpha+beta+gamma):

[0344] Location 1 Overall Score: (0.4×0.81 + 0.3×0.51 + 0.3×0.8) / 1 ≈ 0.71;

[0345] Similarly, the overall score for location 2 is approximately 0.65, and the overall score for location 3 is approximately 0.58.

[0346] (4) Result sorting and return

[0347] The results are sorted in descending order of comprehensive score using the MultiUserScoring.rank algorithm of this patent, and then returned to the APP.

[0348] Location 1 (ID:508): Rating 0.71, 5th floor medium-sized conference room, matches 67% of user needs;

[0349] Location 2 (ID:715): Rating 0.65, 7-story R&D collaboration area, matching 50% of user needs;

[0350] Location 3 (ID:208): Rating 0.58, 2nd floor administrative reception area, matches 33% of user needs.

[0351] Example 2: Multi-user joint query scenario in shopping malls

[0352] I. Application Scenarios

[0353] A large shopping mall in Shanghai (such as "Shanghai Global Harbor") has eight floors, encompassing various businesses including restaurants, fitness centers, retail, and entertainment. Each floor is equipped with an indoor positioning system (with an accuracy of 1 meter). One weekend afternoon, three users (users A, B, and C) arranged to meet at the mall and needed to jointly search for a place that met the following requirements using a mobile app:

[0354] (1) User A (located in the atrium on the 3rd floor, with local coordinates (50,80)): wants to find a "quiet coffee shop", is acceptable within 50 meters, prefers places with comfortable seating, weight 0.8;

[0355] (2) User B (located at the entrance of the cinema on the 4th floor, local coordinates (70,120)): wants to find "Chinese restaurants that provide dinner", acceptable range within 80 meters, weight 0.6;

[0356] (3) User C (located near the gym on the 2nd floor, local coordinates (30,60): wants to find a "24-hour convenience store", acceptable within 30 meters, weight 0.6;

[0357] The shopping mall app's backend must be based on the algorithm of this patent to quickly return a list of venues that meet the needs of multiple users, while protecting the privacy of users' location and query intent, and must avoid leaking individual user query information.

[0358] II. Algorithm Execution Flow

[0359] 1. Initialization Phase: Data Preprocessing and Index Building (Executed offline in the mall's backend)

[0360] The shopping mall operator pre-converted all indoor spaces (such as cafes, restaurants, and convenience stores) into IndoorObject instances and constructed a spatial-keyword joint index using GISEnhancedIndexTree. The specific steps are as follows:

[0361] (1) Site data modeling

[0362] Taking three target locations within the shopping mall as an example, construct an IndoorObject object:

[0363] Location 1 (ID:101): 3rd floor coffee shop, local coordinates (55,85), keywords ["coffee shop", "quiet", "comfortable seating"], floor 3, address "3rd floor, shop 302";

[0364] Location 2 (ID:203): 4th floor Chinese restaurant, local coordinates (65,110), keywords ["Chinese restaurant", "dinner", "Sichuan cuisine"], floor 4, address "4th floor, shop 415";

[0365] Location 3 (ID:305): 2nd floor convenience store, local coordinates (32,62), keywords ["convenience store", "24-hour operation", "snacks"], floor 2, address "2nd floor, shop 208".

[0366] (2) GIS coordinate transformation and spatial coding

[0367] The backend uses the GISUtils utility class to perform coordinate transformation:

[0368] l Convert the local coordinates (meters) to WGS84 coordinates (latitude and longitude): Using the mall's reference point (121.448°E, 31.226°N) as the origin, the local coordinates (55, 85) of location 1 are converted to WGS84 coordinates (121.4486°, 31.2267°), and then further converted to UTM coordinates ((358620, 3456890) in the 32N coordinate system);

[0369] After scaling the local coordinates by 10000 using HilbertEncoder, the Hilbert code is generated: the local coordinates (55, 85) of location 1 are scaled to (550000, 850000), and the Hilbert code (order=4) is 126, which is used for spatial partitioning and indexing acceleration.

[0370] (3) Privacy encryption and index construction

[0371] Location and Keyword Encryption: The 40-dimensional location vector (including local coordinates, WGS84 / UTM coordinates, Hilbert encoding, and floor level) and the 16-dimensional keyword semantic vector (generated by SemanticEncoder) are encrypted using the EASPE component to generate enc_loc (location ciphertext) and enc_kw (keyword ciphertext).

[0372] l Bloom filter construction: A keyword Bloom filter (joint_bloom) is constructed for each location using EncryptedBloomFilter. The key is randomly generated by GISEnhancedIndexTree (e.g., 0x7f3a92c4) for fast keyword pre-filtering;

[0373] lR Tree Spatial Index: Insert the UTM coordinate bounding box of each location (e.g., location 1 is (358615,3456885, 358625, 3456895)) into rtree_index to support fast spatial range queries.

[0374] 2. Query Phase: Multi-user privacy query and result matching (executed in real time)

[0375] (1) User query modeling and trapdoor generation

[0376] Three users submitted query requests through the app. The backend converted these requests into UserQuery instances and generated privacy-protected query traps using GISEnhancedIndexTree.generate_trapdoors.

[0377] User A's query trapdoor: The location vector contains local coordinates (50,80), WGS84 / UTM coordinates, and Hilbert encoding, which are used by EASPE.generate_trapdoor to generate the location trapdoor loc_trapdoor_A; the keywords ["coffee shop", "quiet"] are semantically encoded to generate the keyword trapdoor kw_trapdoor_A;

[0378] l Buffer generation: Based on user A's buffer_radius=50, generate a circular buffer in UTM coordinates (center at user A's UTM coordinates, radius 50 meters) for spatial filtering.

[0379] (2) Multi-user query aggregation

[0380] The backend encapsulates the UserQuery instances of the three users into a MultiUserQuery object and sets a weight allocation strategy: because the focus is on "taking into account the needs of all users", alpha=0.3 (keyword weight), beta=0.3 (location weight), and gamma=0.4 (accessibility weight) are set to balance the needs of multiple dimensions.

[0381] (3) Three-layer filtering: space → floor → keywords

[0382] 1. Spatial filtering: Query the location IDs within each user's buffer range using GISEnhancedIndexTree.spatial_filter: User A's buffer covers location 1 (ID:101), User B's buffer covers location 2 (ID:203), and User C's buffer covers location 3 (ID:305), summarizing to obtain the spatial candidate set {101,203,305};

[0383] 2. Floor Filtering: Traverse the floor nodes of GISEnhancedIndexTree (the child nodes of the root node are divided by floor), and filter out the locations that match the user's floor: Location 1 (3 floors) matches user A, Location 2 (4 floors) matches user B, Location 3 (2 floors) matches user C;

[0384] 3. Keyword Bloom pre-filtering: Check if the location contains user keywords using joint_bloom.contains_any: The Bloom filter for location 1 matches user A's ["coffee shop", "quiet"], location 2 matches user B's ["Chinese restaurant", "dinner"], and location 3 matches user C's ["convenience store", "24-hour operation"], all of which pass the pre-filtering.

[0385] (4) Similarity calculation and multi-user rating

[0386] 1. Encryption Similarity Matching: Calculates the similarity between the location ciphertext and the user trapdoor using EASPE.match:

[0387] Location 1 has a location similarity of 0.92 with User A (only 10 meters apart), and keyword similarity of 0.88 (matching "coffee shop" and "quiet").

[0388] Location 2 has a location similarity of 0.85 with User B (distance 15 meters) and a keyword similarity of 0.91 (matching "Chinese restaurant" and "dinner").

[0389] Location 3 has a location similarity of 0.95 with User C (distance 3 meters) and a keyword similarity of 0.93 (matching "convenience store" and "open 24 hours").

[0390] 2. Multi-user weighted scoring: MultiUserScoring.total_score is used to calculate the total score based on the weights.

[0391] Location 1 Total Score: (0.3×0.88 + 0.3×0.92 + 0.4×0.85) = 0.88 (Accessibility score 0.85, due to direct elevator access to the 3rd floor);

[0392] Venue 2 Total Score: (0.3×0.91 + 0.3×0.85 + 0.4×0.82) = 0.85 (Accessibility score 0.82, requires a 50-meter walk from the 4th floor cinema);

[0393] Location 3 Total score: (0.3×0.93 + 0.3×0.95 + 0.4×0.90) = 0.92 (Accessibility score 0.90, convenience store on the 2nd floor is close to the escalator).

[0394] (5) Result sorting and return

[0395] The backend sorts the results in descending order of total score using MultiUserScoring.rank and returns the results to the user's app.

[0396] Location 3 (ID:305): Rating 0.92, 24-hour convenience store, only 3 meters away from user C;

[0397] 2. Location 1 (ID:101): Rating 0.88, a quiet coffee shop, 10 meters from user A;

[0398] 3. Location 2 (ID:203): Rating 0.85, Chinese restaurant, 15 meters from user B.

[0399] Figure 1 This is a flowchart of a keyword privacy protection query processing method for multiple users. Figure 1 middle:

[0400] User query: The starting point of the process, where the user submits a query request containing information such as location, keywords, and preferences.

[0401] Query processor: Receives and schedules requests, and determines which modules to call for processing.

[0402] GIS Enhanced Index Tree: The "data core" of the system, upon which the following is built:

[0403] Spatial filtering: Use R tree indexes, etc., to filter objects within the user's buffer range;

[0404] Keyword filtering: Quickly filter out objects that do not match keywords using encrypted Bloom filters, etc.

[0405] Encryption similarity calculation: Use EASPE to calculate the similarity of position and keywords in the ciphertext field.

[0406] Results scoring and ranking: The candidate objects are comprehensively scored and ranked by combining multi-user weights and alpha / beta / gamma parameters.

[0407] Return result: The encrypted / de-identified sorting results will be returned to the user, completing one query loop.

[0408] Figure 2 This is a flowchart illustrating the interaction process between the data owner, the cloud server, and the authorized user. Figure 2 middle:

[0409] Take the scenario of multi-user joint query in a shopping mall as an example (Example 2).

[0410] The data owner is the shopping mall operator, who is responsible for managing the mall's indoor space data (such as the location, type, and facilities of shops on each floor). The data, including shop locations and keywords, is converted into an encrypted index using encryption technology (such as EASPE and encrypted Bloom filters) and a GIS-enhanced index tree, and then stored on the cloud server.

[0411] The cloud server is the cloud service platform for the mall's APP backend. It receives and stores encrypted data from the data owner and responds to user queries (storing encrypted data and indexes, and executing privacy query algorithms).

[0412] Authorized users are customers using the mall's app (users A, B, C, etc.). After registration and authentication, their authorization is confirmed, ensuring that only legitimate users can access the data. Users input their needs in the app (e.g., looking for a quiet coffee shop or Chinese restaurant). The app uses an algorithm to convert these needs into an encrypted query trap (containing encrypted location and keyword information) and sends it to the cloud server, preventing privacy leaks caused by plaintext queries. After executing the algorithm, the cloud server returns the encrypted store ranking results (e.g., a list of coffee shops and Chinese restaurants ranked by rating) to the app. The app decrypts and displays the results to the user, allowing them to see locations that meet their various needs.

[0413] Figure 3 This is a schematic diagram of the hierarchical index structure of the GIS Enhanced Index Tree. Figure 3 middle:

[0414] The root node at the top level represents the entire building. The child nodes (also leaf nodes) of the root node represent each floor of the building, and each child node stores information about objects such as shopping malls and entertainment facilities on each floor. The following example (a multi-department collaborative space query scenario in a smart office building) illustrates this:

[0415] Root Node: A non-leaf node that manages all floor child nodes and is the top-level entry point of the index tree. It corresponds to the overall spatial index entry point of a company's Shanghai headquarters office building. When employees from multiple departments initiate queries, they enter the index system starting from the root node to find the functional areas within each floor.

[0416] Child node 1 (floor 5), child node 2 (floor 7), etc.: are all leaf nodes with floor identifiers (floor=5, floor=7), storing indoor object data for the corresponding floor.

[0417] Indoor objects (such as a medium-sized conference room on the 5th floor, ID:508): contain basic information (ID, local coordinates, keywords), spatial encoding and coordinates (WGS84, UTM, Hilbert encoding, minimum bounding box), and encrypted information (EASPE encrypted location / keyword vector, encrypted Bloom filter), used for data organization and indexing in indoor space privacy query scenarios.

Claims

1. A keyword privacy-preserving indoor query indexing method integrating multi-level indexes, characterized in that, This paper constructs a GIS-enhanced index tree, including a Hilbert encoding module, an R-tree index module, a cryptographic Bloom filter module, an EASPE cryptographic vector module, and indoor floor grouping units. The Hilbert encoding module receives the two-dimensional planar coordinates of indoor objects and converts them into one-dimensional Hilbert encoded values ​​to preserve spatial locality. The R-tree index module uses `rtree.index` to create minimum bounding rectangles for the UTM coordinates of indoor objects. During queries, the `rtree_index.intersection` method recursively checks the intersection of the minimum bounding rectangles of nodes with the query box from the root node, quickly returning the IDs of intersecting objects for efficient spatial range queries. The cryptographic Bloom filter module is a joint Bloom filter, using a key-initialized hash function. All Bloom filters for indoor objects are constructed using this key, and all queries also use this key to check keywords, quickly determining whether at least one word in the query keyword set might exist in the object without revealing the specific matching keyword. The EASPE cryptographic vector module includes an `encrypt` unit, a `generate_trapdoor` unit, and a `match` unit. The `encrypt` unit encrypts 40-dimensional location vectors to generate location encryption fragments and 16-dimensional location vectors to generate location encryption fragments. The keyword vector encryption generates keyword encryption fragments. The generate_trapdoor unit generates trapdoor vectors from query vectors. The match unit calculates the cosine similarity approximation between the encrypted vector and the trapdoor vector without knowing the plaintext and provides IND-CPA security guarantee. The indoor floor grouping unit groups indoor objects by floor to form index leaf nodes. The root node manages all floor child nodes. All modules are integrated through this unit into a GIS enhanced index tree that supports complex indoor environments.

2. A keyword privacy protection query processing method for multi-user applications, characterized in that, The implementation of the GIS enhanced index tree based on claim 1 includes the following steps: S1: Receive multiple user query requests, each request containing local coordinates referenced to the indoor local origin, a keyword list, user preferences, the maximum distance the user is willing to walk, the user's current floor, a unique user identifier, weights reflecting the importance of user preferences in multi-user queries, the spatial relationships expected by the user, and the buffer radius defining the query range. All request information is converted into encrypted trapdoors using the generate_trapdoors method; S2: The server performs spatial filtering, calling the spatial_filter method of the GIS enhanced index tree to obtain the buffer from the user queries and calling rtree_index.intersection. The method obtains the object IDs in the buffer to form a spatial candidate set; S3: Perform floor and keyword pre-filtering, traverse each floor node of the index tree, and skip if the floor of a node is not in the set of all user target floors; for the remaining nodes, extract the encrypted Bloom filter of any object in the node, check all user query keywords, and count the number of users who may have matching results. If it is less than the preset minimum number of matching users, skip the node; S4: For objects that have passed the pre-filtering and are in the spatial candidate set, use the EASPE.match method to calculate the similarity between the encrypted position vector and the encrypted keyword vector of the object and each user; the encrypted position vector of the object is 40-dimensional, obtained by concatenating local coordinates, WGS84 coordinates, UTM coordinates, Hilbert encoded values, and floor information and then encrypting them with EASPE; the encrypted keyword vector of the object is 16-dimensional, obtained by encoding the keyword list with SemanticEncoder and then EASPE. S5: Perform threshold filtering and score aggregation, check if the location similarity of users with at least the minimum number of matching users exceeds the location similarity threshold and the keyword similarity exceeds the keyword similarity threshold; calculate the accessibility score based on floor switching cost and path smoothness; extract the weight of each user, and calculate the weighted average of location similarity and keyword similarity to obtain the aggregated location score and aggregated keyword score; store the candidate objects and aggregated location score, aggregated keyword score, and accessibility score in a candidate list; S6: Calculate the comprehensive score according to the preset weights through multi-user scoring, sort the comprehensive scores in descending order, and return the results; all processes are performed in encrypted or trapdoor state, and the server cannot obtain plaintext information.

3. A comprehensive location vector construction method suitable for indoor environments, characterized in that, Applied to the EASPE encryption vector module as described in claim 1, Includes the following steps: S1: Obtain the local coordinates, WGS84 coordinates, UTM coordinates, Hilbert encoding values, and floor information of the indoor object; S2: Standardize the local coordinates, WGS84 coordinates, UTM coordinates, Hilbert encoding values, and floor information, and then concatenate them to form a 40-dimensional initial position vector; S3: Use the encrypt unit of the EASPE encryption module to encrypt the initial position vector through random matrix, random permutation, and random mask, generating two encrypted fragments to obtain the encrypted comprehensive position vector.

4. The comprehensive location vector construction method applicable to indoor environments according to claim 3, characterized in that, It also includes step S4: The distance and similarity of the encrypted integrated location vector are calculated using the EASPE.match method. The higher the similarity, the closer the indoor objects are in space and the more matched the floor information is, which is used for location privacy protection in indoor multi-user personalized space keyword query.

5. A privacy-preserving coordinate transformation method based on a local coordinate system, characterized in that, The GIS enhanced index tree described in claim 1 includes the following steps: S1: Preset an indoor fixed reference point as the local origin; S2: Establish a local coordinate system, setting the coordinate axis direction with the local origin as the origin, in meters; S3: Obtain the original location information of indoor objects or users, and convert it into local coordinates under the local coordinate system; S4: When spatial calculation is required, convert the local coordinates into WGS84 coordinates and UTM coordinates through GISUtils, and the conversion is completed internally by the system; S5: When providing location information externally, only the local coordinates or their vectors encrypted by EASPE are exposed, and the WGS84 coordinates are hidden to protect the privacy of absolute geographic location.

6. The privacy-preserving coordinate transformation method based on the local coordinate system according to claim 5, characterized in that, Different indoor scenes correspond to independent local coordinate systems, and the coordinate transformations of each scene are independent of each other, further ensuring location privacy.

Images