Anonymizing user location data in location-based applications

Abstract

A location-based application, such as a parallel reality game, may receive location data from a client device of a user of the application that represents the user's location in the real world. In one embodiment, a gaming platform associated with the application writes location data derived from the received location data to each of a number of retention tables, each storing the location data at a different level of granularity and for a different retention period. Upon expiration of the retention period for a first retention table, the gaming platform anonymizes the location data and transfers the anonymized data to a second retention table that stores data at a lower level of granularity. The gaming platform repeats this process until the retention period for the table having the lowest level of granularity expires before deleting the location data from storage.

Description

[Technical field]

[0001] The subject matter described relates generally to location-based applications, and in particular to systems and methods for storing geospatial location data for users at various levels of granularity and various retention periods, and systems and methods for providing downstream services to groups of users without initiating upstream services that do not know the identities of the individual users. [Background technology]

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 315,055, filed February 28, 2022, which is incorporated by reference.

[0003] Location-based games and other applications use the real world as geography. Parallel reality games are a type of location-based game that uses a virtual world that is parallel to the real world geography. The parallel virtual world may span the entire real world, and players from all over the world can interact in the parallel virtual world and perform various game objectives by navigating and performing actions in the real world. Many client devices used by players in parallel reality games include positioning devices that track the player's location data as the player moves through the real world playing the parallel reality game and interacting with virtual elements in the game. This data may be stored in a central game platform and used to perform location data analytics. However, long-term storage of player location data may raise privacy concerns. Additionally, the usefulness of player location information for analytics purposes may degrade over time, and continued storage would cause stale data to clog game databases. Summary of the Invention

[0004] In a location-based parallel reality game, or other location-based application, a user (also referred to as a "player") navigates the real world using a location-aware client device, such as a smartphone. As the player navigates the virtual world, the player may interact with virtual elements and participate in virtual experiences that may be strategically placed within the virtual world. The player's client device may transmit location data to a server hosting the parallel reality game or application for storage and use in data analysis. This disclosure describes an approach to anonymizing received location data by storing the location data in each of a number of retention tables and periodically reducing the level of granularity of the stored data before eventually deleting the data from storage.

[0005] In one embodiment, upon receiving player location data from a client device, the gaming platform writes location information derived from the location data to each of multiple retention tables in the gaming database, each retention table having a different level of granularity and retention period. For example, a first fine-grained retention table that stores data at the highest level of granularity (e.g., the player's exact longitude and latitude) may have the shortest retention period, while a second coarse-grained retention table having a lower level of data granularity (e.g., the city block in which the player is located) may retain the data for a longer period. As a result, the same item of location data originally provided by the client device may be anonymized and stored differently in each of the tables. Upon expiration of a table's retention period, the gaming platform may further abstract or anonymize the location data and transfer it to a different retention table. For example, in the above example, the player's longitude and latitude may be abstracted to a city block level for transfer to a second table, while the data initially stored in the second table may be further abstracted (e.g., to the city in which the player is located) for transfer to a third, coarser-grained retention table having the longest retention period. Upon expiration of the retention period of the third retention table, the gaming platform may cause the location data to be deleted from storage in the gaming database.

[0006] Storing location data at various levels of granularity allows the gaming platform's servers to perform different types of location-based analytics and provide various services, while periodic anonymization and deletion of data helps increase efficiency over existing systems and protect player privacy by storing less data. For example, in one embodiment, players may be segmented based on various characteristics (e.g., location data within a specified time period) for purposes of A / B testing or "make-good" services. A first service, e.g., on a first server of the gaming platform, uses location data or other characteristics to identify a list of hashed player IDs, such as a list of players located in a particular city, or players who visited a particular point of interest in a game. The first service sends the list of hashed player IDs and an identification of a second service via a one-way application programming interface (API) call to a mapping module. The mapping module queries a lookup table to identify the raw player ID associated with the received hash, and sends the player ID data to the identified second service, which may be a downstream service on a separate server of the gaming platform. For example, if the second service is a "make good" service, the identified player may receive additional game objects as compensation for a previous error in the game. By limiting the exposure of hashed player IDs to upstream services and raw player IDs to downstream services, the gaming platform protects player privacy and reduces the likelihood of accidental disclosure of personally identifiable information. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 is a block diagram of a networked computing environment suitable for hosting a parallel reality game, according to one embodiment. [Diagram 2] 2 is a block diagram of the client device of FIG. 1 according to one embodiment. [Diagram 3] FIG. 2 is a block diagram of the gaming platform of FIG. 1 according to one embodiment. [Figure 4] 2 is a block diagram illustrating additional components of the gaming platform of FIG. 1 according to one embodiment. [Diagram 5] FIG. 1 illustrates an exemplary unit sphere subdivided using an S2 hierarchy, according to one embodiment. [Figure 6A] FIG. 13 illustrates a short-term retention table that stores player location data, according to one embodiment. [Figure 6B] FIG. 13 illustrates a medium-term retention table for storing player position data, according to one embodiment. [Figure 6C] FIG. 2 illustrates a long-term retention table that stores player location data, according to one embodiment. [Figure 7] FIG. 7 is a diagram illustrating a representation of a virtual world having a parallel geography to the real world, according to one embodiment. [Figure 8] FIG. 8 is a flow chart illustrating a method for anonymizing stored player position data according to one embodiment. [Figure 9] FIG. 9 is a high-level block diagram illustrating a functional view of a typical computer system for use as the gaming platform of FIG. 1, according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] The drawings and the following description describe specific embodiments for illustrative purposes only. Those skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods may be employed without departing from the principles described. Wherever practicable, similar or similar reference numbers are used in the figures to indicate similar or similar functionality. When elements share a common numeral followed by another letter, this indicates that the elements are similar or similar. Unless the context dictates otherwise, reference to a numeral alone generally refers to any one or any combination of such elements.

[0009] Various embodiments are described in the context of a parallel reality game that includes augmented reality content in a virtual world geography that parallels at least a portion of the real world geography, such that player movements and actions in the real world affect actions in the virtual world and vice versa. With the aid of this disclosure, one of ordinary skill in the art will appreciate that the subject matter described is applicable to other situations in which device location data is collected and stored. For example, a restaurant guide application may want to identify users who have recently been near a new restaurant and recommend it to a subset of those users (e.g., users who like a particular dish at the restaurant).

[0010] FIG. 1 is a block diagram of a networked computing environment 100 suitable for hosting a parallel reality game, according to one embodiment. The networked computing environment 100 provides for interaction with players in a virtual world having a geography parallel to the real world. In particular, geographical regions of the real world can be directly linked or mapped to corresponding regions in the virtual world. Players can navigate the virtual world by moving to various geographical locations in the real world. For example, the player's location in the real world can be tracked and used to update the player's location in the virtual world. For example, a coordinate system in the real world (e.g., longitude and latitude) can be mapped to a coordinate system in the virtual world (e.g., x / y coordinates, virtual longitude and latitude, etc.).

[0011] Typically, the player's location in the real world is determined by finding the location of the client device 110 at which the player is interacting with the virtual world and assuming that the player is in the same (or approximately the same) location. For example, in various embodiments, a player may interact with a virtual element if the player's location in the real world is within a threshold distance (e.g., 10 meters, 20 meters, etc.) of a real-world location that corresponds to the virtual location of the virtual element in the virtual world. For convenience, various embodiments are described with reference to the "player's location," although those skilled in the art will understand that such reference may also refer to the location of the player's client device 110.

[0012] The virtual world may be divided into regions (e.g., cells) that correspond to contiguous geographic regions of the real world. In various embodiments, the portions of the virtual world may be defined according to a geographic index framework. For example, the portions of the virtual world may be defined according to an S2 library that defines a hierarchy of cells that divides a three-dimensional object, the Earth, into a set of two-dimensional cells at different levels of granularity. In other embodiments, a different geographic index framework may be used.

[0013] For example, FIG. 5 shows a portion of a geographical map 500 that has been partitioned using the S2 library framework, where a unit sphere is partitioned into a hierarchy of cells. To obtain the top level of the hierarchy, the six faces of a cube are projected onto the unit sphere, and lower levels are obtained by recursively subdividing each cell into four children. In the embodiment shown in FIG. 5, the unit sphere represented by map 400 includes two of six surface cells 505 and 510, of which surface cell 510 has been subdivided four times. Each cell in the hierarchy has a level, which is defined as the number of times the cell has been subdivided. For example, surface cell 510 has cell level 0, cell 515 has level 1, cell 520 has level 2, cell 525 has level 3, and cell 530 has level 4. As discussed herein, the S2 hierarchy can be used for spatial indexing and approximating points as individual cells and areas as collections of cells. Each cell level may include a set of cell numbers that identify a particular cell, and may be mapped to one or more labels indicating a location, such as latitude / longitude, neighborhood, city, country, etc.

[0014] Returning now to FIG. 1 , the regions of the virtual world may be used to index various geolocation data, such as player location data, for storage in the game database 130. For example, as described below, the game database 130 may include multiple retention tables that store player location data at various levels of granularity (e.g., different S2 cell levels) and various retention periods. In one embodiment, the player location data is periodically aggregated and transferred to a different retention table having a coarser-grained data storage component than the previous retention table. The data transfer process may be iterative such that player location data is transferred to tables of decreasing granularity before being deleted from storage. Each retention table may have a different retention period. For example, in one embodiment, fine-grained location data (e.g., longitude / latitude of a player measured at the 30 S2 cell level) may be stored in a short-term retention table, coarse-grained location data (e.g., city block in which a player is located measured at the 14 S2 cell level) may be stored in a medium-term table, and even coarser-grained location data (e.g., city in which a player is located measured at the 10 S2 cell level) may be stored in a long-term retention table.

[0015] The networked computing environment 100 uses a client-server architecture, with the gaming platform 120 communicating with the client devices 110 over a network 140 to provide parallel reality games to players of the client devices 110. The networked computing environment 100 may also include other external systems, such as sponsor / advertiser systems or business systems. Although only one client device 110 is shown in FIG. 1, any number of client devices 110 or other external systems may be connected to the gaming platform 120 over the network 140.

[0016] The client device 110 may be any portable computing device that a player can use to interact with the gaming platform 120. For example, the client device 110 may be a wireless device, a personal digital assistant (PDA), a portable gaming device, a mobile phone, a smartphone, a tablet, a navigation system, a handheld GPS system, a wearable computing device (e.g., a headset), a display having one or more processors, or other such devices. In another example, the client device 110 includes a conventional computer system such as a desktop computer or a laptop computer. Furthermore, the client device 110 may be a vehicle having a computing device. In short, the client device 110 may be any computing device or system that allows a player to interact with the gaming platform 120. As a computing device, the client device 110 may include one or more processors and one or more computer-readable storage media. The computer-readable storage media may store instructions that cause the processor to perform operations. The client device 110 is preferably a portable computing device that can be easily carried or otherwise transported with a player, such as a smartphone or tablet. Various embodiments of the client device 110 are described in more detail below with reference to FIG. 2.

[0017] The gaming platform 120 can be any computing device and can include one or more processors and one or more computer-readable storage media. The computer-readable storage media can store instructions that cause the processor to perform operations. In various embodiments, the gaming platform 120 maintains a copy of the master game state and manages the interactions between the players' client devices 110 so that all of the players interact with a consistent game world. The gaming platform 120 can include services provided by different servers. For example, as described below with respect to FIG. 4, a call service located on a first server can send a list of hashed player IDs (e.g., a list of users who are located within a specified area or have one or more other shared characteristics) to a mapping module on a separate server of the gaming platform. The mapping module queries a lookup table to identify raw player ID data associated with each of the hashed player IDs and sends the raw player ID data to a destination service on yet another server of the gaming platform 120. The division of services between different servers ensures that the caller service does not know the identities of the players and the destination service does not know the hashed player IDs.

[0018] In various embodiments, gaming platform 120 determines the region of the parallel reality game based on a snapshot of real-world data, including device location information indicating the player's location in the real world. Gaming platform 120 divides the geographic region of the virtual world into cells (e.g., S-2 cells) that cover a portion of the geographic region. In some embodiments, the geographic region of the virtual world may correspond to the entire real world. In other embodiments, the geographic region corresponds to a smaller portion (e.g., a region) of the real world.

[0019] The gaming platform 120 may be configured to receive requests for game data from the client devices 110 (e.g., via remote procedure calls (RPCs)) and respond to those requests over the network 140. For example, the gaming platform 120 may encode the game data in one or more data files and provide the data files to the client devices 110. Additionally, the gaming platform 120 may be configured to receive game data (e.g., player positions, play actions, player inputs, etc.) from the client devices 110 over the network 140. For example, the client devices 110 may be configured to periodically send player inputs and other updates to the gaming platform 120, which the gaming platform 120 uses to update the game data in the gaming database 130 to reflect any and all changed conditions of the game. Various embodiments of the gaming platform 120 are described in more detail below with reference to FIG. 3.

[0020] The gaming platform 120 may include or be in communication with a game database 130. The game database 130 stores game data used in the parallel reality game that is provided or is provided to the client device 110 over the network 140. The game data stored in the game database 130 may include: (1) data associated with a virtual world in the parallel reality game (e.g., image data used to render the virtual world on a display device, geographic coordinates of locations within the virtual world, etc.); (2) data associated with a player of the parallel reality game (e.g., player profile including, but not limited to, player information, player experience level, player currency, current and past player locations in the virtual / real world, player energy level, player preferences, team information, faction information); (3) data associated with game goals (e.g., data associated with current game goals, game goal states, past game goals, future game goals, desired game goals, etc.); (4) data associated with virtual elements in the virtual world (e.g., location of virtual elements, virtual (5) data associated with real world objects, landmarks, locations linked to virtual world elements (e.g., location of real world object / landmark, description of real world object / landmark, location of virtual element linked to real world object, etc.); (6) game state (e.g., current number of players, current state of game goals, player leaderboard, etc.); (7) data associated with player actions / inputs (e.g., current player position, past player positions, player movement, player input, player queries, player communications, etc.); and (8) any other data used, related to, or obtained during the implementation of the parallel reality game.The game data stored in game database 130 is entered either offline or in real time by a system administrator or by data received from users / players of the game, such as from client devices 110 over network 140. In one embodiment, game database 130 stores current and historical player position data in multiple retention tables with various levels of granularity and retention periods, as described in more detail below with reference to Figures 3 and 6A-6C.

[0021] Network 140 may be any type of communications network, such as a local area network (e.g., an intranet), a wide area network (e.g., the Internet), or some combination thereof. A network may also include a direct connection between client device 110 and gaming platform 120. In general, communications between gaming platform 120 and client device 110 may occur over a network interface using any type of wired or wireless connection, using a variety of communications protocols (e.g., TCP / IP, HTTP, SMTP, FTP), encodings or formats (e.g., HTML, XML, JSON), or protection schemes (e.g., VPN, Secure HTTP, SSL).

[0022] The technology discussed herein refers to servers, databases, software applications, and other computer-based systems, as well as actions performed on these systems and information sent to and received from these systems. Those skilled in the art will recognize that the inherent flexibility of computer-based systems allows for a wide variety of possible configurations, combinations, and divisions of tasks and functions between components. For example, the server processes discussed herein may be implemented using a single server or multiple servers operating in combination. Databases and applications may be implemented on a single system or distributed across multiple systems. Distributed components may operate sequentially or in parallel. Additionally, the network computing environment 100 may include different or additional components, and functionality may be distributed among the client device 110, the server 120, the database 130, and the feature matching system 140 in ways different from those described.

[0023] Where the systems and methods described herein access and analyze personal information about a user, or utilize personal information such as location information, the user may be provided with an opportunity to control whether the program or function collects information and whether or how it receives content from the system or other applications. Such information or data will not be collected or used until the user is provided with meaningful notice of what information will be collected and how that information will be used. Information will not be collected or used unless the user consents, and the user may revoke or change consent at any time. Thus, the user can control how information about the user is collected and used by the application or system. Additionally, certain information or data may be processed in one or more ways such that any personally identifiable information is removed before it is stored or used. For example, a user's identifier may be processed such that personally identifiable information cannot be determined for the user.

[0024] Figure 2 is a block diagram of the client device 110 of Figure 1, according to one embodiment. In the embodiment shown, the client device 110 includes a game module 210, a positioning module 220, a camera assembly 230, and an image matching module 240. In other embodiments, the client device 110 may include different or additional elements. Furthermore, functionality may be distributed among the elements in a manner different than that described.

[0025] The game module 210 provides an interface for players to participate in the parallel reality game. The game platform 120 transmits game data over the network 140 to the client device 110 for use by the game module 210 to provide a local version of the game to players located remotely from the game platform 120. In one embodiment, the game module 210 presents a user interface on a display device associated with the client device 110 that displays a virtual world associated with the game (e.g., renders an image of the virtual world) and allows the user to interact with the virtual world to perform various game objectives. In some embodiments, the game module 210 presents real-world image data (e.g., captured by the camera assembly 230) augmented with virtual elements from the parallel reality game. In these embodiments, the game module 210 may generate or adjust virtual content according to other information received from other components of the client device 110. For example, the game module 210 may adjust virtual objects displayed on the user interface according to a depth map of the scene captured in the image data (e.g., as generated by a depth estimation model).

[0026] The game module 210 can also control various other outputs to allow a player to interact with a game without the player needing to view a display screen. For example, the game module 210 can control various sounds, vibrations, or other notifications that allow a player to play a game without seeing a display screen. The game module 210 can access game data received from the gaming platform 120 to provide an accurate representation of the game to the user. The game module 210 can receive and process player input and provide updates to the gaming platform 120 over the network 140.

[0027] The positioning module 220 may be any device or circuitry for monitoring the location of the client device 110. For example, the positioning module 220 may determine the actual or relative location by using a satellite navigation positioning system (e.g., GPS system, Galileo positioning system, Global Navigation Satellite System (GLONASS), Beidou satellite navigation and positioning system), an inertial navigation system, a dead reckoning system, based on an IP address, by using triangulation or proximity to cellular towers or Wi-Fi hotspots, or by using other suitable techniques to determine the location. The positioning module 220 may further include various other sensors that may help precisely locate the location of the client device 110.

[0028] As the player moves around with the client device 110 in the real world, the positioning module 220 tracks the player's location and provides player location information to the game module 210. The game module 210 updates the player's location in the virtual world associated with the game based on the player's actual location in the real world. Thus, the player can interact with the virtual world simply by carrying or transporting the client device 110 in the real world. In particular, the player's location in the virtual world can correspond to the player's location in the real world.

[0029] The game module 210 can provide player location information to the game platform 120 over the network 140. In response, the game server 120 can implement various techniques to verify the location of the client device 110 to prevent cheaters from spoofing the location of the client device 110. It should be understood that location information associated with a player is utilized only if permission is granted after the player has been informed that the player's location information will be accessed and how the location information will be utilized in the context of the game (e.g., to update the player's location in a virtual world).

[0030] Additionally, any location information associated with a player is stored and maintained in a manner that protects the player's privacy. For example, as described in more detail below with reference to FIG. 3 and FIG. 6A-6C, fine-grained location data may be stored in a holding table for a short period of time before the data is transferred to a holding table represented by a lower level of granularity. Thus, a player's latitude / longitude (e.g., the latitude / longitude of the client device 110) may be stored for a short period of time before the data is transferred to a holding table represented by a city block or the city in which the player is located. Player location data may be periodically aggregated and reduced in granularity over time before being deleted from the game database 130.

[0031] The camera assembly 230 includes one or more cameras configured to capture images of the physical environment in which the client device 110 is located. The portion of the physical environment shown in the image is referred to as a scene. The camera assembly 230 captures image data corresponding to the scene and stores it in a storage medium of the client device. Additionally or alternatively, the image data may be transmitted to the gaming platform 120 over the network 140. The camera assembly 230 may use various photosensors having various color capture ranges at various capture rates. The camera assembly 230 may include a wide-angle lens or a telephoto lens. The camera assembly 230 may be configured to capture a single image or a video as the image data. The client device 110 may also include other sensors for recording data about the physical environment of the client device, such as an accelerometer, a gyroscope, an inertial measurement unit (IMU), a barometer, a thermometer, a light sensor, a microphone, etc. The image data may be appended with metadata describing other details of the image data, including sensory data (e.g., temperature, brightness of the environment) or capture data (e.g., exposure, warmth, shutter speed, focal length, capture time, etc.).

[0032] 3 is a block diagram of the gaming platform 120 of FIG. 1 according to one embodiment. In the embodiment shown, gaming platform 120 includes a universal game module 310, a commercial game module 320, a data collection module 330, and an event module 340. As described above, gaming platform 120 interacts with a game database 130 that may be part of gaming platform 120 or may be accessed remotely (e.g., game database 130 may be a distributed database accessed via network 140). In other embodiments, gaming platform 120 includes different or additional elements. Furthermore, functionality may be distributed among elements in a manner different from that described. For example, game database 130 may be integrated into gaming platform 120.

[0033] The universal game module 310 hosts the parallel reality game for the players and serves as an authoritative source of the current status of the parallel reality game for all players. As a host, the universal game module 310 generates game content for presentation to the players, for example, via their respective client devices 110. The universal game module 310 may access the game database 130 to retrieve or store game data when hosting the parallel reality game. The universal game module 310 also receives game data (e.g., depth information, player input, player position, playaction, landmark information, etc.) from the client devices 110 and incorporates the received game data into the overall parallel reality game for all players of the parallel reality game. The universal game module 310 may also manage the distribution of game data to the client devices 110 over the network 140. The universal game module 310 may also manage security aspects of the client devices 110, including, but not limited to, ensuring connectivity between the client devices 110 and the game platform 120, establishing connectivity between the various client devices 110, and verifying the location of the various client devices 110.

[0034] The commercial games module 320 may be separate from the universal games module 310, or may be part of the universal games module 310, in embodiments where one is included. The commercial games module 320 may manage the incorporation of various game features linked to commercial activities in the real world within the parallel reality game. For example, the commercial games module 320 may receive a request over the network 140 (via the network interface) from an external system, such as a sponsor / advertiser, a business, or other entity, to include game features linked to commercial activities within the parallel reality game. The commercial games module 320 may then arrange to include these game features in the parallel reality game.

[0035] The data collection module 330 may be separate from the universal game module 310 or may be part of the universal game module 310 in embodiments where one is included. The data collection module 330 may manage the incorporation of various game features within the parallel reality game that are linked with data collection activities in the real world. For example, the data collection module 330 may modify the game data stored in the game database 130 to include game features that are linked with data collection activities within the parallel reality game. The data collection module 330 may also analyze data collected by players (e.g., as part of a crowdsourcing effort) and provide the data for access by various platforms. To take a specific example, players may be prompted to submit photos of landmarks and other features of interest within their environment, and the data collection module 330 may incorporate virtual elements into the parallel reality game that correspond to the real-world landmarks or features based on the player's submissions (e.g., subject to verifying that the landmarks exist and are located where the submitting player indicated).

[0036] The event module 340 manages player access to events within a parallel reality game. While the term "event" is used for convenience, it should be understood that the term does not necessarily refer to a specific event at a specific location or time. Rather, it may refer to any offering of access-controlled game content in which one or more access criteria are used to determine whether a player can access that content. Such content may be part of a larger parallel reality game that includes game content with little or no access control, or may be a stand-alone access-controlled parallel reality game.

[0037] The location storage module 350 receives player location data (e.g., from the positioning module 220 of the client device 110) and assigns the received data to one or more of a plurality of retention tables for storage in the game database 130. In one embodiment, the location storage module 350 hashes a player ID associated with the received location data before providing the location data for storage in a retention table. Each of the retention tables may be associated with a level of granularity at which player location data is stored, such that a single player location may be represented and stored differently in each of the retention tables.

[0038] The level of granularity of the tables may be represented by an S2 cell level or other geographic index level that includes the geographic range in which the device may be located. For example, Figures 6A, 6B, and 6C each show a holding table that stores location data associated with a client device 110, such as a client device 110 associated with a player of a parallel reality game. As shown in Figures 6A-6C, the location data of the same player is represented differently in each of tables 600, 610, and 620 based on the S2 cell level associated with the respective table, with table 600 containing the most granular location data and table 620 containing the least granular location data. That is, in table 600, the location of player 1 is represented at a first S2 cell level such that the location data essentially provides the specific latitude and longitude of the player's client device 110. The location data of player 1 is stored in table 610 at a second S2 cell level, which may indicate, for example, the city block in which player 1 is located. Additionally, player 1's location data is stored in tables 620 at a third S2 cell level, for example indicating the city in which player 1 is located. In each table, the player's location is represented by a cell number that identifies a particular cell, and may be mapped to one or more labels that indicate the player's location, such as latitude / longitude, neighborhood, city, country, etc. While this description and FIGS. 6A-6C describe and depict three retention tables used to store location data in the game database 130, one skilled in the art will appreciate that fewer or additional retention tables may be used. Additionally, while the retention tables are described as using the S2 cell library, one skilled in the art will appreciate that other geographic indexing frameworks may be used.

[0039] In one embodiment, a single item of location information derived from the received location data is first written to a fine-grained location holding table, such as table 600 of FIG. 6A, and then abstracted to one or more less fine-grained tables as the corresponding holding times expire. Alternatively, the location storage module 350 writes the location information derived from the location data to each of the holding tables in the game database 130. To do so, the location storage module 350 abstracts the received data from its current level of granularity to the level of granularity associated with each of the holding tables. For example, the exact latitude and longitude where player 1 is located may be abstracted to the player's city block (stored in table 610) and the player's current city (stored in table 620). In this manner, the player location data is stored at various levels of granularity in each of the different holding tables in the game database 130. In yet other embodiments, the received location data is written to two or more holding tables, but less than all of the holding tables in the game database 130.

[0040] The location storage module 350 may further establish and modify retention periods for each of the retention tables in the game database 130. For example, a retention table that stores location data at the highest level of granularity (e.g., table 600) may have the shortest retention period, such that a player's exact location is stored for only a short period of time. As the data in a retention table becomes increasingly coarse, the data may be retained for longer periods of time. Thus, the retention period associated with a table is inversely proportional to the level of granularity at which the data in the table is stored, with coarse-grained location data being stored for longer periods of time than fine-grained location data. With respect to the retention tables illustrated in FIGS. 6A-6C, table 600 may be designated the "short-term table," table 610 may be designated the "medium-term table," and table 620 may be designated the "long-term table." In one example, data in a "short term table" is retained for a specified number of days (e.g., 15-45 days), data in a "medium term table" is retained for a specified number of months (e.g., 10-20 months), and data in a "long term table" is retained for a specified number of years (e.g., 5-10 years).

[0041] In one embodiment, the location storage module 350 aggregates location data whose retention period has expired and reduces the granularity of the data for transfer to a different retention table. For example, when the retention period associated with a short-term retention table (e.g., table 600) expires, the location storage module 350 transfers the location data to a medium-term retention table (e.g., table 610). Thus, the player's location may be stored at a fine-grained level for a first period (i.e., the retention period associated with table 600), but at the end of that first period, the location data is abstracted for storage in a coarser-granular table. Similarly, at the end of the medium-term table retention period, the location data is further abstracted and transferred to the long-term table 620. When the retention period of the long-term table expires, the location storage module 350 causes the player's location data to be deleted from storage in the game database 130. In this manner, the accuracy with which the player's location data is stored in the game database 130 decreases over time (i.e., as the time period since the positioning module 220 reported the location data to the game platform 120 increases).

[0042] The gaming platform 120 may use the location data stored at various levels of granularity in the holding tables to perform different types of location-based analytics. For example, data stored at the city level may be used to analyze how many players in a particular city are participating in a parallel reality game, or how and how often players are traveling between cities. In still other embodiments, the data in the holding tables may be used for data segmentation and ingestion.

[0043] For example, Figure 4 is a block diagram illustrating additional components of the gaming platform 120 of Figure 1, according to one embodiment. In the embodiment shown in Figure 4, the gaming platform 120 includes a first service 405, a mapping module 410, and a second service 415. As described above, the location storage module 350 of the gaming platform 120 hashes the player ID associated with the received location data before storing the player location data in a retention table. The mapping module 410 maintains a lookup table (e.g., a rainbow table) that maps the hashed user ID to a raw player ID, which may be used, for example, to identify individual players or groups of players that have certain attributes or for which certain actions should be performed.

[0044] In one embodiment, a first service 405 (also referred to as an "upstream service" or "calling service") communicates with the mapping module 410 via a one-way API call requesting the identification of one or more hashed player IDs. The request includes an identification of a second service (also referred to as a "downstream service" or "destination service") to which the mapping module 410 should send the raw player ID data associated with the hashes.

[0045] The mapping module 410 maintains an authorization list of second services 415 that are authorized to receive raw player ID data. In various embodiments, authorization may be based on the purpose for which the player ID data is being shared (e.g., the second service 415 may be authorized to receive ID data only for AB testing) or the associated first service 405 (e.g., the second service 415 may be authorized to receive ID data based on a hash sent by the first service 405A, but not from the first service 405B). In other embodiments, the second service 415 may be authorized to receive ID data regardless of the associated first service 405.

[0046] The mapping module 410 consults the authorization list to determine whether the identified second service 415 is authorized to receive the raw player ID data associated with the received hash. If so, the mapping module 410 consults the lookup table to identify the raw player ID information associated with the received hashed user ID and transmits the raw player ID to the second service 415 (also referred to as a "downstream service" or "destination service"). The lookup table cannot be accessed by the first service 405, the second service 415, or other components of the gaming platform 120. Rather, the lookup table receives the hashed ID from the first service 405 as an input and outputs the raw player ID to the second service 415. Thus, the lookup table is the only place on the gaming platform 120 where the hashed player ID and the raw player ID are available together and cannot be accessed to the broader gaming platform 120. Because the first service 405 does not receive raw player IDs and the second service 415 does not receive hashed player IDs, the lookup table acts as a "secret keeper" and provides increased privacy and security by ensuring that player data is not shared more than necessary to achieve a specified goal.

[0047] For example, the architecture of FIG. 4 may be used to implement A / B testing or to identify segments of players to receive game objects or virtual rewards. In a first example, the first service 405 identifies a group of players with certain characteristics for running an A / B test. Exemplary characteristics may include players located in a specified city, players with a specified level or levels within a specified range in the parallel reality game, players who have received a specified game item, players who have visited a specified geographic area within a time period, players with a specified last login time, etc. The above-mentioned maintained tables, such as the tables shown in FIGS. 6A-6C, may be used to identify hashed IDs of players with desired location-based characteristics, while non-location-based player characteristics may be obtained from other portions of the game database 130. If the desired features include fine-grained player location data (e.g., to identify players located in a specified level 30 S2 cell), the first service 405 must generate a list of hashed IDs before the expiration of the short-term table's retention period, and A / B testing on the coarser location data may be performed over a longer period of time, taking into account the longer retention periods of the medium-term and long-term tables.

[0048] After identifying a set of hashed player IDs associated with players having one or more specified characteristics, the first service 405 transmits the hashed player IDs to the mapping module 410 for identification. The player IDs can be transmitted individually or as a group. The mapping module 410 uses the hashed player IDs to query a lookup table and transmits the corresponding raw player ID data to the second service 415, which implements one or more game modifications according to the parameters of the A / B test. For example, in one embodiment, the second service 415 splits the raw player IDs (e.g., randomly) into two groups, such as an "A" group (i.e., a control group) in which no modifications are made, and a "B" group (i.e., a treatment group) in which the second service 405 implements one or more game modifications (e.g., modifications to game rules). A second service 410 collects and analyzes game data for the A and B groups to evaluate the impact of one or more game changes on, for example, player performance, duration of game play, player location, etc.

[0049] In a second example, the architecture of FIG. 4 may be used to identify players to receive game objects or virtual rewards, for example, a group of players who are or were located in a specified geographic area, who interacted with a specified point of interest in a parallel reality game, or a group of players who have some other shared characteristic, who were positively or negatively affected by an intended or unintended change to the game. For example, the first service 405 may be a "make-good" service that compensates for a previous game error. To identify and compensate affected users, the gaming platform 120 uses the segmentation method described above. That is, the first service 405 generates a list of hashed IDs of players affected by the error and makes a one-way API call to the mapping module 410. The mapping module 410 consults a lookup table to identify the raw player ID associated with the received hash and transmits the player ID to the second service 410, which compensates the identified player (e.g., by granting the player additional game objects).

[0050] In yet another example, the location data stored in the holding table, and optionally the one-way lookup table, are used to perform further location-based analysis, such as calculating real-world social interactions between players of a parallel reality game. For example, a module of the gaming platform 120 may use the location data to determine how many players were in close proximity to each other (e.g., located in the same S2 cell), how many players visited a specified point of interest, how many players interacted with virtual objects and / or each other (e.g., players who interacted with virtual objects in the same level 20 S2 cell during the same minute), and the like. In some embodiments, the gaming platform 120 does not identify a particular player associated with the location data, for example, if the purpose of the analysis is to measure the success of an event (e.g., based on the number of players who used a location-based application within a specified area within a specified period of time). However, the one-way lookup table may be used when a service of the gaming platform 120 takes some action with respect to a subset of users, such as sending a message to players located in a specified S2 cell or granting a virtual item.

[0051] Exemplary parallel reality games 7 illustrates a conceptual diagram of a virtual world 710 parallel to a real world 700 that may serve as a game board for players of a parallel reality game, according to one embodiment. As illustrated, the virtual world 710 may include a geography that parallels the geography of the real world 700. In particular, a range of coordinates that defines a geographical area or space in the real world 700 is mapped to a corresponding range of coordinates that defines a virtual space in the virtual world 710. A range of coordinates in the real world 700 may be associated with a town, neighborhood, city, campus, place, country, continent, the entire globe, or other geographical area. Each geographic coordinate within the range of geographic coordinates is mapped to a corresponding coordinate in the virtual space of the virtual world.

[0052] The position of a player in the virtual world 710 corresponds to the position of the player in the real world 700. For example, player A, located at position 712 in the real world 700, has a corresponding position 722 in the virtual world 710. Similarly, player B, located at position 714 in the real world, has a corresponding position 724 in the virtual world. As a player moves within a range of geographic coordinates in the real world, the player also moves within a range of coordinates that define a virtual space in the virtual world 710. In particular, a positioning system (e.g., a GPS system) associated with a mobile computing device carried by the player may be used to track the player's position as the player navigates the range of geographic coordinates in the real world. Data associated with the player's position in the real world 700 is used to update the player's position in the corresponding range of coordinates that define a virtual space in the virtual world 710. In this manner, a player can navigate along a continuous track within a range of coordinates that define a virtual space in the virtual world 710 by simply moving within the range of corresponding geographic coordinates in the real world 700, without having to check in or periodically update location information at a specific individual location in the real world 700.

[0053] A location-based game may include multiple game objectives that require a player to travel to or interact with various virtual elements or objects scattered at various virtual locations within the virtual world. A player can travel to these virtual locations by moving to the corresponding locations of the virtual elements or objects in the real world. For example, a positioning system can continuously track the player's location such that as the player continuously navigates the real world, the player also continuously navigates the parallel virtual world. The player can then interact with the various virtual elements and objects at the specific locations to accomplish or perform one or more game objectives.

[0054] For example, a game goal may have the player interact with virtual elements 730 located at various virtual locations in the virtual world 710. These virtual elements 730 may be linked to landmarks, geographic locations, or objects 740 in the real world 700. The real world landmarks or objects 740 may be works of art, monuments, buildings, businesses, libraries, museums, or other suitable real world landmarks or objects. Interactions may include capturing, claiming ownership, using some virtual items, using some virtual currency, etc. To capture these virtual elements 730, the player must travel to the landmark or geographic location 740 linked to the virtual elements 730 in the real world and perform any necessary interactions with the virtual elements 730 in the virtual world 710. For example, Player A may have to travel to a landmark 740 in the real world 700 to interact with or capture the virtual element 730 linked to that particular landmark 740. Interaction with the virtual element 730 may require an action in the real world, such as taking a photograph or verifying, obtaining, or capturing other information about a landmark or object 740 associated with the virtual element 730.

[0055] A game objective may require a player to use one or more virtual items that are collected by the player in a location-based game. For example, a player may travel through the virtual world 710 in search of virtual items (e.g., weapons, creatures, power-ups, or other items) that may be useful in achieving a game objective. These virtual items may be found or collected by traveling to different locations in the real world 700 or by completing various actions in either the virtual world 710 or the real world 700. In the example shown in FIG. 7, a player uses a virtual item 732 to capture one or more virtual elements 730. In particular, a player may deploy a virtual item 732 to a location in the virtual world 710 in proximity to or within the virtual element 730. Deploying one or more virtual items 732 in this manner may result in the capture of the virtual element 730 for a particular player or a particular player's team / faction.

[0056] In one particular implementation, a player may have to collect virtual energy as part of a parallel reality game. As shown in FIG. 7, virtual energy 760 may be scattered at different locations in the virtual world 710. A player may collect virtual energy 760 by traveling to the corresponding location of the virtual energy 760 in the real world 700. The virtual energy 760 may be used to power virtual items or perform various game objectives in the game. A player who loses all virtual energy 760 may be disconnected from the game.

[0057] According to aspects of the present disclosure, a parallel reality game may be a massively multiplayer location-based game in which all participants of the game share the same virtual world. Players may split into separate teams or factions and cooperate to achieve one or more game objectives, such as capturing or claiming ownership of virtual elements. In this way, a parallel reality game may essentially be a social game that encourages cooperation between players in the game. Players on opposing teams may play against each other (or sometimes cooperate to achieve mutual objectives) during the parallel reality game. Players may use virtual items to attack or impede the progress of players on the opposing team. In some cases, players are encouraged to gather at real-world locations for cooperative or interactive events in the parallel reality game. In these cases, the gaming platform attempts to verify that players are actually physically present and not impersonating.

[0058] A parallel reality game may have various features to enhance and encourage gameplay within the parallel reality game. For example, a player may accumulate virtual currency or another virtual reward (e.g., virtual tokens, virtual points, virtual material resources, etc.) that may be used throughout the game (e.g., to purchase in-game items, to redeem other items, to create items, etc.). Players may progress through various levels as they accomplish one or more game objectives and gain experience within the game. In some embodiments, players may communicate with each other through one or more communication interfaces provided within the game. Players may also gain enhanced "powers" or virtual items that may be used to complete game objectives within the game. Using the disclosure provided herein, one skilled in the art should understand that various other game features may be included in a parallel reality game without departing from the scope of the present disclosure.

[0059] Exemplary Methods 8 is a flow chart illustrating a method 800 for anonymizing stored player position data, according to one embodiment. In some embodiments, method 800 is performed by one or more servers of gaming platform 120, although some or all of the operations of method 800 may be performed by other entities in other embodiments. In some embodiments, operations in method 800 may be performed in a different order and may include different or additional steps.

[0060] In the embodiment shown, the method 800 begins with the location storage module 350 of the gaming platform 120 receiving 805 player location data from the positioning module 220 of the client device 110. The player location data may be represented by the location of the player's client device 110 in the real world according to a satellite navigation positioning system or one or more other suitable techniques for determining location, as described above with respect to FIGURE 2. In one embodiment, the location storage module 350 hashes a player ID associated with the received location data.

[0061] The location storage module 350 assigns 810 the received location data to one or more retention tables stored in the game database 130 included in or in communication with the game platform 120. Each retention table stores player location data at a different level of granularity and a different retention period. In one embodiment, the location storage module 350 writes location information derived from the location data to each retention table such that the player's location is stored at different levels of granularity in the game database 130. For example, the player's location may be stored in a first table containing fine-grained location data (e.g., indicating the player's latitude and longitude), in a second table containing coarse-grained location data (e.g., indicating the city block in which the player is located), and in a third table containing even coarser-grained location data (e.g., indicating the city in which the player is located). In one embodiment, the level of granularity of the tables may be represented by an S2 cell level or other geographic index level that includes a geographic range in which the client device 110 may be located.

[0062] Upon determining that the retention period associated with a particular retention table has expired, the location storage module 350 reduces 815 the granularity of the location data stored in that table and transfers 820 the location data to a less granular table. In one embodiment, location data stored in a fine-grained retention table having a first S2 cell level may be abstracted to a second S2 cell level for transfer to a different retention table associated with the latter S2 cell level. For example, a player's latitude and longitude may be abstracted to the city block in which the player is located or the city in which the player is located.

[0063] In one embodiment, steps 815 and 820 are iterative. That is, the location storage module 350 performs this abstraction and transfer process for each location data item stored in the multiple retention tables in the game database 130 based on the retention period of each retention table. In this manner, the player location data becomes increasingly coarse-grained as the time since the client device 110 reported the location data increases. Upon expiration of the retention period, if the location storage module 350 determines that the associated retention table is the smallest granularity table in the game database 130, the location storage module 350 deletes 825 the location data item whose retention period has expired from the game database 130. If the current table is not the smallest granularity table, the location storage module 350 repeats steps 815 and 820 until the retention period of the smallest granularity table expires.

[0064] Examples of Computing Systems Figure 9 is a block diagram illustrating a functional diagram of an exemplary computer system 900 for use as a client device 110 or server of the gaming platform 120 of Figure 1, according to one embodiment. Figure 9 illustrates various physical components of a computer used as some or all of one or more of the entities described herein, although a computer may have additional, fewer, or variations of the components illustrated in Figure 9. As will be recognized by one of ordinary skill in the art, items illustrated individually may be combined and some items may be separated into multiple portions.

[0065] 9 shows at least one processor 902 coupled to a chipset 904. Also coupled to the chipset 904 are a memory 906, a storage device 908, a keyboard 910, a graphics adapter 912, a pointing device 914, and a network adapter 916. A display 918 is coupled to the graphics adapter 912. In one embodiment, the functionality of the chipset 904 is provided by a memory controller hub 920 and an I / O hub 922. In another embodiment, the memory 906 is directly coupled to the processor 902 instead of the chipset 904. In some embodiments, the computer 900 includes one or more communication buses for interconnecting these components. The one or more communication buses optionally include circuitry (sometimes referred to as a chipset) that interconnects and controls communication between the system components.

[0066] The storage device 908 is any non-transitory computer-readable storage medium, such as a hard drive, a compact disk read-only memory (CD-ROM), a DVD, or a solid-state memory device or other optical storage device, a magnetic cassette, a magnetic tape, a magnetic disk storage device or other magnetic storage device, a magnetic disk storage device, an optical disk storage device, a flash memory device, or other non-volatile solid-state storage device. Such a storage device 908 may also be referred to as persistent memory. The pointing device 914 may be a mouse, a trackball, or other type of pointing device and may be used in combination with the keyboard 910 to input data into the computer 900. The graphics adapter 912 displays images and other information on the display 918. The network adapter 916 couples the computer 900 to a local or wide area network.

[0067] The memory 906 holds instructions and data used by the processor 902. The memory 906 may be non-persistent memory, examples of which include high-speed random access memory such as DRAM, SRAM, DDR RAM, ROM, EEPROM, flash memory, etc.

[0068] As is known in the art, computer 900 may have different components or other components than those shown in FIG. 9. Additionally, computer 900 may lack certain illustrated components. In one embodiment, a computer 900 functioning as a server may not have a keyboard 910, a pointing device 914, a graphics adapter 912, or a display 918. Additionally, storage device 908 may be located locally or remotely relative to computer 900 (such as incorporated within a storage area network (SAN)).

[0069] As known in the art, the computer 900 is adapted to execute computer program modules for providing the functionality described herein. As used herein, the term "module" refers to computer program logic utilized to provide a specified functionality. Thus, a module can be implemented in hardware, firmware, or software. In one embodiment, the program module is stored in the storage device 908, loaded into the memory 906, and executed by the processor 902.

[0070] Additional Considerations Some portions of the above description describe embodiments in terms of algorithmic processes or operations. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to effectively convey the substance of their work to others skilled in the art. While these operations have been described functionally, computationally, or logically, they will be understood to be implemented by computer programs including instructions for execution by a processor or equivalent electrical circuitry, microcode, or the like. Additionally, and without loss of generality, it may sometimes be convenient to refer to these arrangements of functional operations as modules.

[0071] As used herein, a reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

[0072] Some embodiments may be described using the terms "coupled" and "connected," along with their derivatives. It should be understood that these terms are not intended as synonyms for each other. For example, some embodiments may be described using the term "connected" to indicate that two or more elements are in direct physical or electrical contact with each other. In another example, some embodiments may be described using the term "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other. The embodiments are not limited in this context.

[0073] As used herein, "comprises," "comprises," "includes," "including," "has," "having," or any other variation thereof, is intended to include a non-exclusive inclusion. For example, a process, method, article, or apparatus that includes a list of elements is not necessarily limited to only those elements, but may include other elements not expressly listed or inherent in such process, method, article, or apparatus. Furthermore, unless expressly stated to the contrary, "or" refers to an inclusive "or" and not an exclusive "or." For example, a condition A or B is satisfied by any one of the following: A is true (or exists) and B is false (or does not exist), A is false (or does not exist) and B is true (or exists), and both A and B are true (or exists).

[0074] Furthermore, the use of "a" or "an" is employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the disclosure. The description includes one or at least one, and the singular should be read to include the plural, unless it is clear that this is not meant.

[0075] Upon reading this disclosure, those skilled in the art will appreciate that still further alternative structural and functional designs for the system and process for verifying an account with an online service provider correspond to a genuine business. Thus, while specific embodiments and applications have been illustrated and described, it is to be understood that the described subject matter is not limited to the exact structure and components disclosed herein, and that various modifications, changes and variations may be made in the arrangement, operation and details of the disclosed methods and apparatus, which would be apparent to one skilled in the art. The scope of protection should be limited only by the scope of the following claims.

Claims

1. 1. A computer-implemented method for anonymizing user location data, comprising: receiving location data from a client device associated with a user of a location-based application; hashing a player identifier (ID) associated with the user; writing location information derived from the location data and the hashed player ID into each of a plurality of retention tables, each retention table storing the location data at a different level of granularity and for a different retention period; in response to determining that a retention period for a first retention table has expired, anonymizing the location data and transferring the anonymized location data to a second retention table having a lower level of granularity than the first retention table; periodically repeating the anonymizing and transferring steps for each of the plurality of holding tables; in response to determining that a retention period for the retention table having the lowest level of granularity has expired, causing the location data to be deleted from storage; 10. A computer-implemented method comprising:

2. The step of writing the position information into each of the plurality of holding tables includes: writing location information having a first level of granularity to a first retention table having retention times; 2. The computer-implemented method of claim 1, further comprising: in response to the retention time expiring, writing location information having a second level of granularity to a second retention table, the second level of granularity being smaller than the first level of granularity.

3. The computer-implemented method of claim 1 , wherein each retention table stores location data at a cell level associated with an S2 library framework.

4. The computer-implemented method of claim 1 , wherein the retention tables include a short-term retention table, a medium-term retention table, and a long-term retention table.

5. 5. The computer-implemented method of claim 4, wherein the short-term retention table stores location data indicating the longitude and latitude of the client device, the medium-term retention table stores location data indicating the city block in which the client device is located, and the long-term retention table stores location data indicating the city in which the client device is located.

6. The computer-implemented method of claim 1 , wherein a retention period of a retention table is inversely proportional to the level of granularity of the retention table.

7. The computer-implemented method of claim 1 , wherein the location-based application is a parallel reality game.

8. writing the hashed player ID into a one-way lookup table that maps hashed player IDs to raw player IDs of users of the location-based application; receiving a request from a first service to identify one or more hashed player IDs, the request including an identification of a second service; consulting the one-way lookup table to identify a raw player ID associated with each of the one or more hashed player IDs; The computer-implemented method of claim 1 , further comprising: transmitting the identified raw player ID to the second service.

9. 9. The computer-implemented method of claim 8, wherein the first service generates the list of the one or more hashed player IDs for identification using location data from one or more of the maintaining tables.

10. The computer-implemented method of claim 8 , wherein the second service performs modifications to the location-based application for the user associated with the raw player ID.

11. 1. A non-transitory computer-readable storage medium containing instructions executable by a processor, the executable instructions comprising: receiving location data from a client device associated with a user of a location-based application; hashing a player identifier (ID) associated with the user; writing location information derived from the location data and the hashed player ID into each of a plurality of retention tables, each retention table storing the location data at a different level of granularity and a different retention period; in response to determining that a retention period for a first retention table has expired, anonymizing the location data and transferring the anonymized location data to a second retention table having a lower level of granularity than the first retention table; periodically repeating the anonymization and transfer for each of the plurality of holding tables; In response to determining that a retention period for the retention table having the lowest level of granularity has expired, causing the location data to be deleted from storage. A non-transitory computer-readable storage medium for causing operations to be performed, including:

12. Writing the position information into each of the plurality of holding tables includes: writing location information having a first level of granularity into a first retention table having retention times; 12. The non-transitory computer-readable storage medium of claim 11, further comprising: in response to the retention time expiring, writing location information having a second level of granularity to a second retention table, the second level of granularity being smaller than the first level of granularity.

13. The non-transitory computer-readable storage medium of claim 11 , wherein each retention table stores location data at a cell level associated with an S2 library framework.

14. The non-transitory computer-readable storage medium of claim 11 , wherein the retention tables include a short-term retention table, a medium-term retention table, and a long-term retention table.

15. The non-transitory computer-readable storage medium of claim 11 , wherein a retention period of a retention table is inversely proportional to a level of granularity of the retention table.

16. The non-transitory computer-readable storage medium of claim 11 , wherein the location-based application is a parallel reality game.

17. The early operation is writing the hashed player ID into a one-way lookup table that maps hashed player IDs to raw player IDs of users of the location-based application; receiving a request from a first service to identify one or more hashed player IDs, the request including an identification of a second service; consulting the one-way lookup table to identify a raw player ID associated with each of the one or more hashed player IDs; and transmitting the identified raw player ID to the second service.

18. 20. The non-transitory computer-readable storage medium of claim 17, wherein the first service generates the list of the one or more hashed player IDs for identification using location data from one or more of the maintaining tables.

19. 20. The non-transitory computer-readable storage medium of claim 18, wherein the second service performs modifications to the location-based application for the user associated with the raw Player ID.

20. receiving, from the first service via a one-way application programming interface call invocation, an identification of the second service and a list of one or more hashed player IDs for the identification, the player IDs being associated with users of a location-based application; querying an authorization list to determine whether the identified second service is authorized to receive raw player ID data associated with the hashed player ID; in response to determining that the second service is authorized to receive the raw player ID data, consulting a lookup table to identify a raw player ID associated with each of the one or more hashed player IDs; transmitting the identified raw player ID to the second service, wherein the second service performs modifications to the location-based application for the user associated with the raw player ID; 10. A computer-implemented method comprising:

Images