Tagging virtual elements near user equipment

Abstract

A parallel reality application enables users to mark virtual elements in their vicinity for later interaction. Geolocation information of a user is received and used to identify, in a virtual world, a virtual location mapped to the user's geolocation. Based on the identified virtual location, a region in the virtual world is identified, and one or more virtual elements within the region of the virtual world are selected. Identifiers of the one or more virtual elements are stored in conjunction with an identifier of the user, and a list of marked virtual elements is provided for display to the user. At a later time, the user interacts with a selected one of the marked virtual elements.

Description

Background Technology

[0001] This application claims priority based on Singapore application No. 10202301152W, filed April 25, 2023, and U.S. application No. 18 / 644,523, filed April 24, 2024, which are incorporated herein by reference. Background Technology 1. Technical Field

[0002] The described subject matter generally involves parallel realities, and more particularly involves marking virtual elements in parallel realities so that users can remotely interact with the marked virtual elements at a later time. 2. Problem

[0003] Parallel reality applications provide a virtual world whose geographical location is mapped to at least a portion of the real world. Users explore the virtual world by moving within it. In typical parallel reality applications, users can only interact with nearby virtual elements when the application used to interact with the virtual world is open on the user's client device. When the application is not open and not in the foreground of the user's client device's display, the user cannot perceive the virtual elements around them. Therefore, users may miss opportunities to interact with virtual elements in the virtual world. Summary of the Invention

[0004] This disclosure describes a method for tagging virtual elements in a parallel reality application based on proximity to a user. The tagged virtual elements can later be interacted with remotely by the user. In one embodiment, virtual elements can be tagged when the user is not using the parallel reality application. A background process monitors the location of the user's client device and reports the client device's location to the parallel reality application server when one or more conditions are met (e.g., if the location has changed by a threshold amount since the last location was sent to the server; if the location has changed from one geofence region to another; or if more than a threshold amount of time has elapsed since the last location was sent to the server). The server tags one or more virtual elements in the vicinity of the client device's location (e.g., within a predetermined distance of the location or within the same geofence region). Later, regardless of the current location of the user's client device, the user has the opportunity to interact with the tagged items in the parallel reality application.

[0005] In one embodiment, when the server receives the location of a user's client device, it marks one or more virtual elements near the client device (assuming there are tagged virtual elements nearby). When the server receives an updated location from the client device, indicating that the client device has moved a considerable distance since the last received location (either because the client device has moved a predetermined distance or because the user has entered a different geofenced area), the server marks one or more additional virtual elements near the client device's new location (assuming there are tagged virtual elements nearby). Therefore, as the user moves around the world, the server can mark virtual elements each time the user moves a predetermined distance or transitions from one geofenced area to another. Attached Figure Description

[0006] Figure 1 A representation of a virtual world having a geographical location parallel to the real world is shown according to one embodiment.

[0007] Figure 2 An exemplary game interface for a parallel reality game according to one embodiment is shown.

[0008] Figure 3 This is a block diagram of a network computing environment suitable for providing tags for virtual elements, according to one embodiment.

[0009] Figure 4 According to one embodiment Figure 3 The diagram shows a block diagram of the client device.

[0010] Figure 5 According to one embodiment Figure 3 The diagram shows a block diagram of the server.

[0011] Figure 6 The diagram illustrates an example configuration of a fence around a user according to one embodiment.

[0012] Figure 7 This is a flowchart of a process for marking virtual elements and interacting remotely with virtual elements, according to one embodiment.

[0013] Figure 8 The figure illustrates an application for supply according to one embodiment. Figure 1 This is an example computer system used in a network computing environment. Detailed Implementation

[0014] The figures and the following description illustrate certain embodiments by way of illustration only. Those skilled in the art will understand from the following description that alternative embodiments of the structure and method may be employed without departing from the principles described. Wherever practicable, similar or identical graphic symbols are used in the figures to indicate similar or identical functions. Elements sharing a common number followed by a different letter indicate that these elements are similar or identical. Unless the context otherwise requires, individual references to numbers generally refer to any element or combination of these elements.

[0015] Various embodiments are described in the context of parallel reality games, which include augmented reality content in a virtual world geolocation that is at least partially parallel to a real-world geolocation, such that a player's movement and actions in the real world affect actions in the virtual world. The described subject matter is also applicable to other situations where remote interaction with virtual elements is required. Furthermore, the inherent flexibility of computer-based systems enables various possible configurations, combinations, and divisions of tasks and functions between and in between the system's components. Example of a location-based parallel reality game

[0016] Figure 1 This is a concept diagram of Virtual World 110, which is parallel to Real World 100. Virtual World 110 can be used as a game board for players of parallel reality games or other parallel reality applications. As illustrated, Virtual World 110 includes geographical locations parallel to those in Real World 100. Specifically, the coordinate range of a defined geographical area or space in Real World 100 is mapped to a corresponding range of coordinates defining a virtual space in Virtual World 110. The range of coordinates in Real World 100 can be associated with towns, communities, cities, campuses, regions, countries, continents, the entire Earth, or other geographical areas. Each geographical coordinate within the range is mapped to a corresponding coordinate in the virtual space of Virtual World 110.

[0017] A player's location in virtual world 110 corresponds to a player's location in real world 100. For example, player A, located at location 112 in real world 100, has a corresponding location 122 in virtual world 110. Similarly, player B, located at location 114 in real world 100, has a corresponding location 124 in virtual world 110. As players move within the geographic coordinates of real world 100, they also move within the coordinates of the virtual space defined in virtual world 110. Specifically, as players navigate within the geographic coordinates of real world 100, a positioning system (e.g., GPS, GPS, or both) associated with the player's mobile computing device can be used to track the player's location. Data associated with the player's location in real world 100 is used to update the player's location within the corresponding range of coordinates in the virtual space defined in virtual world 110. In this way, without checking in at specific discrete locations in the real world 100 or periodically updating location information, players can navigate along continuous tracks within the coordinate range of a limited virtual space in the virtual world 110 simply by moving between corresponding ranges of geographical coordinates in the real world 100.

[0018] Location-based games can include game objectives that require players to navigate to or interact with various virtual elements or objects scattered throughout a virtual world 110. Players can navigate to these virtual locations by moving to the corresponding locations of virtual elements or objects in the real world 100. For example, a positioning system can track the player's location so that as the player navigates in the real world 100, they are also navigating in the parallel virtual world 110. The player can then interact with various virtual elements and objects at specific locations to achieve or perform one or more game objectives.

[0019] The game objective may be to allow players to interact with virtual elements 130 located at various virtual locations within a virtual world 110. These virtual elements 130 can then be linked to landmarks, geographical locations, or objects 140 in the real world 100. Real-world landmarks or objects 140 can be works of art, monuments, buildings, businesses, libraries, museums, or other suitable real-world landmarks or objects. Interactions include capturing, claiming, using virtual items, and spending virtual currency. To capture these virtual elements 130, players travel to real-world landmarks or geographical locations 140 linked to the virtual elements 130, and perform necessary interactions with the virtual elements 130 within the virtual world 110 (as defined by the game rules). For example, player A may be required to travel to a landmark 140 in the real world 100 to interact with or capture virtual elements 130 linked to that landmark 140. Interaction with virtual element 130 may require actions in the real world, such as taking photos or verifying, obtaining, or capturing other information about landmarks or objects 140 associated with virtual element 130.

[0020] Game objectives may require players to use one or more virtual items collected by the player in a location-based game. For example, a player may move through a virtual world 110, searching for virtual items 132 (such as weapons, creatures, power-ups, or other items) that can help achieve the game objective. These virtual items 132 can be found or collected by moving to different locations in the real world 100, or by performing various actions in the virtual world 110 or the real world 100 (such as interacting with virtual elements 130, fighting non-player characters or other players, or completing quests). Figure 1 In the example shown, the player uses virtual item 132 to capture one or more virtual elements 130. Specifically, the player can deploy virtual item 132 in the virtual world 110 near or within virtual element 130. Deploying one or more virtual items 132 in this way can cause the capture of virtual element 130 targeting the player or the player's team / faction.

[0021] In one implementation, players can collect virtual energy as part of a parallel reality game. Virtual energy 150 can be scattered across different locations in virtual world 110. Players collect virtual energy 150 by traveling to locations in real world 100 that correspond to the locations of virtual energy in virtual world 110 (or within a threshold distance of those locations). Virtual energy 150 can be used to enhance virtual items or perform various game objectives. Players who lose all of their virtual energy 150 may be disconnected from the game or restricted from playing for a certain period of time, or until they have collected additional virtual energy 150.

[0022] According to this disclosure, the parallel reality game can be a large-scale, multiplayer, location-based game where each participant shares the same virtual world. Players can be divided into separate teams or factions and can work together to achieve one or more game objectives, such as capturing or claiming ownership of virtual elements. In this way, the parallel reality game can essentially be a social game that encourages cooperation between players within the game. During a parallel reality game, players from opposing teams can compete against each other (or sometimes cooperate to achieve a common goal). Players can use virtual items to attack or hinder the progress of players from opposing teams. In some cases, the game encourages players to gather at real-world locations for cooperative or interactive events within the parallel reality game. In these cases, the server seeks to ensure that players are genuinely and physically present, rather than falsifying their locations.

[0023] Figure 2 An embodiment of a game interface 200 is shown, which can be presented as part of the interface between a player and a virtual world 110 (e.g., on a player's smartphone). The game interface 200 includes a display window 210 that can be used to display various other aspects of the virtual world 110 and the game, such as player location 122 and the locations of virtual elements 130, virtual items 132, and virtual energy 150 within the virtual world 110. The user interface 200 may also display other information, such as game data, game communications, player information, client location verification instructions, and other information associated with the game. For example, the user interface may display player information 215, such as player name, experience level, and other information. The user interface 200 may include a menu 220 for accessing various game settings and other game-related information. The user interface 200 may also include a communication interface 230 that enables communication between the game system and the player, and between one or more players in a parallel reality game.

[0024] According to aspects of this disclosure, players can interact with parallel reality games by carrying client devices around the real world. For example, players can play the game by accessing an application associated with the parallel reality game on a smartphone and by having the smartphone move around in the real world. In this respect, players do not need to constantly view a visual representation of the virtual world on a display screen to play location-based games. Therefore, the user interface 200 can include non-visual elements that allow users to interact with the game. For example, the game interface can provide sound notifications to the player when the player is approaching a virtual element or object in the game, or when an important event occurs in the parallel reality game. In some embodiments, the player can use audio control 240 to control these sound notifications. Different types of sound notifications can be provided to the user depending on the type of virtual element or event. The frequency or volume of the sound notifications can increase or decrease depending on the player's proximity to the virtual element or object. Other non-visual notifications and signals can also be provided to the user, such as vibration notifications or other appropriate notifications or signals.

[0025] Parallel reality games can have various features to enhance and encourage players to play within them. For example, players can accumulate virtual currency or other virtual rewards (e.g., virtual tokens, virtual points, virtual resources, etc.), which can be used throughout the game (e.g., to purchase in-game items, exchange for other items, craft items, etc.). As players complete one or more game objectives and gain experience within the game, they can gradually level up. Players can also acquire enhanced "energy" or virtual items that can be used to complete in-game objectives.

[0026] Using the content of this disclosure, those skilled in the art will understand that various game interface configurations and underlying functionalities are possible. Unless expressly stated otherwise, this disclosure is not intended to be limited to any particular configuration. Example Parallel Reality System

[0027] Figure 3 The figure illustrates an embodiment of a distributed parallel reality system 300. The parallel reality system 300 provides interaction for users in a virtual world with geographical locations parallel to the real world. Specifically, geographical regions in the real world can be directly linked or mapped to corresponding regions in the virtual world. Users can move in the virtual world by moving to various geographical locations in the real world. The system 300 can track the user's location in the real world and update the user's location in the virtual world based on the user's current location in the real world. For example, a coordinate system in the real world (e.g., longitude and latitude) can be mapped to a coordinate system system in the virtual world (e.g., x / y coordinates, virtual longitude and latitude, etc.).

[0028] exist Figure 3 In the illustrated embodiment, the distributed parallel reality system 300 includes a server 310 and client devices 320 connected via a network 370. Although three client devices 320 are shown, any number of client devices can be connected to the server 310 via the network 370. In other embodiments, the distributed parallel reality system 300 includes different or additional elements. Furthermore, functionality can be distributed among these elements in a manner different from that described.

[0029] Server 310 includes one or more computing devices that provide application functionality to client device 320. In one embodiment, server 310 hosts a general state of the location-based game and provides game state updates to the player's client device 320 (e.g., based on actions taken by other players in the game, changes in real-world conditions, changes in game state or conditions, etc.). Server 310 receives and processes input from players in the location-based game. Players can be identified by a username or player ID (e.g., a unique numeric or alphanumeric string), and in conjunction with the player's input, the player's client device 320 can send the username or player ID to server 310.

[0030] For example, server 310 can receive requests from client device 320 for a corresponding player to perform an in-game action. This request may include the player's identifier and information about the requested action, such as the identity of the object the player wishes to interact with and the nature of the requested interaction (e.g., pick up, drop, capture, upgrade, etc.). Server 310 can determine the result and return a game update to the client device based on the determined result. Server 310 also receives real-world activity data from the player's client device 310 and determines in-game results based on this real-world activity data. Server 310 may also notify the player of certain in-game results generated by the real-world activity data (e.g., via push notifications). Figure 5 Various embodiments of server 310 are described in more detail below.

[0031] Client device 320 can be any portable computing device capable of being used by a player to interact with server 310. For example, client device 320 is preferably a portable wireless device that can be carried by the player, such as a smartphone, portable gaming device, augmented reality (AR) headset, mobile phone, tablet, personal digital assistant (PDA), navigation system, handheld GPS system, or other such device. In some use cases, client device 320 can be a less mobile device, such as a desktop computer or laptop. Furthermore, client device 320 can be a vehicle with built-in computing equipment.

[0032] Client device 320 may execute software (e.g., a game application or app) to allow players to interact with a virtual world. Client device 320 may execute a background process that periodically or in response to certain triggering events provides location information to server 310. Server 310 can use this location information to mark virtual elements near client device 320 (e.g., within a threshold distance), and the software can subsequently enable users to remotely interact with the marked virtual elements (i.e., without the client device being in the vicinity of the virtual element at the time of interaction). The software may also enable users to manually mark virtual elements near the client device and later provide remote interaction with these manually marked virtual elements. Various embodiments of client device 320 are described below. Figure 4 It was described in more detail.

[0033] Network 370 can be any type of communication network, such as a local area network (e.g., a corporate intranet), a wide area network (e.g., the Internet), or a combination thereof. The network may also include a direct connection between client device 320 and server 310. Typically, communication between server 310 and client device 320 can be carried via a network interface, using any type of wired or wireless connection, employing various communication protocols (e.g., TCP / IP, HTTP, SSL, FTP), encodings or formats (e.g., HTML, JSON, XML), or protection schemes (e.g., VPN, Secure HTTP, SSL).

[0034] This disclosure relates to servers, databases, software applications, and other computer systems, as well as the actions taken and the information sent to and from such systems. Those skilled in the art will recognize that the inherent flexibility of computer-based systems makes it possible to have various possible configurations, combinations, and divisions of tasks and functions between and in between components. For example, the disclosed processes, such as those implemented by a server, can be implemented using a single server or a combination of multiple servers. Databases and applications can be implemented on a single system or distributed across multiple systems. Distributed components can operate sequentially or in parallel.

[0035] In the systems and methods disclosed herein, when accessing and analyzing personal information about a user or using personal information (such as location information), the user can be provided with the opportunity to control whether a program or function collects such information, and to control whether and how content is received from the system or other applications. No such information or data is collected or used until the user has been provided with meaningful notification of what information will be collected and how such information will be used. Information is not collected or used unless the user consents, and the user can withdraw or modify their consent at any time. Therefore, the user can control how information about them is collected and how it is used by applications or systems. Furthermore, certain information or data may be processed in one or more ways before being stored or used, such that personally identifiable information is removed. For example, the user's identity may be processed so that no personally identifiable information can be used to identify that user. Example client device

[0036] Figure 4 The illustration depicts one embodiment of a client device 320 suitable for use as part of a distributed parallel reality system 300. In the illustrated embodiment, the client device 320 includes a game module 410, a positioning subsystem 420, a location reporting module 430, a foreground tagging module 440, a notification module 450, and local data storage 460. In other embodiments, the client device 320 includes different or additional components. Furthermore, functionality may be distributed among the components in a different manner than described above.

[0037] The game module 410, executed by the client device 320, provides an interface between the player and the location-based game. The game module 410 can present a user interface on a display associated with the client device 320 (e.g., a built-in screen or an AR headset), displaying the virtual world 110 associated with the game and allowing the player to interact with the virtual world to perform various game objectives. The game module 410 can also control various other outputs to allow the player to interact with the game without the player looking at the display screen. For example, the game module 410 can control various audio, vibration, or other notifications. The game module 410 can access game data received from the server 310 to provide the player with an accurate depiction of the current state of the virtual world 110. The game module 410 can receive and process player input and provide updates to the virtual world 110 to the server 310 via the network 370.

[0038] The positioning subsystem 420 monitors the location of the client device 320. The positioning subsystem 420 can be any device or circuit used to monitor the location of the client device 320. For example, the positioning subsystem 420 can determine the actual or relative location by using a satellite navigation positioning system (e.g., GPS, Galileo, GLONASS, BeiDou, etc.), an inertial navigation system, a dead reckoning system, by using triangulation, or by approaching a cell tower or WiFi hotspot, or other suitable technology. Location information can be provided anonymously to protect the player's privacy. Additionally or alternatively, the positioning subsystem 420 may include a visual positioning system that determines the location and (optionally) orientation (collectively, "attitude") of the client device 320 by comparing images captured by one or more cameras with a 3D map of the client device 320's environment. For example, using GPS, a rough location can be determined, and the positioning subsystem 420 can retrieve a 3D map based on this rough location; then, visual positioning is used to determine a more precise location (and optional orientation) of the client device.

[0039] As the player moves in the real world with the client device 320, the positioning subsystem 420 tracks the player's position and provides the player's position data to the game module 410. The game module 410 updates the player's position in the virtual world 110 based on the player's position in the real world 100. Specifically, the player's position in the virtual world 110 can be compared with the player's position in the real world 100 (as previously mentioned, see reference...). Figure 1 Correspondingly, while the player is playing the game, the game module 410 can provide the player's location data to the server 310 via the network 370, enabling the general game module 510 to track the player's location throughout the game.

[0040] When the player is not actively playing the game, the location reporting module 430 enables the location of the client device 320 to be reported to the server 310. In one embodiment, the location reporting module 430 initiates a background process to monitor the location of the client device 320. This background process can be initiated in response to the player enabling a feature in the game to provide background markers for virtual elements. The player can be notified that the feature will provide their location to the server 310, and can choose to exit or disable the feature.

[0041] Assuming this feature is enabled, the background process updates server 310 with the player's current location if one or more criteria are met. For example, the location reporting module 430 may provide the server 310 with the current location of client device 320 when the user closes or shifts their attention away from client device 320. In another example, the current location of client device 320 is reported when client device 320 is restarted. The background process may periodically compare the location of client device 320 with the previous location provided by server 310. If the location has been significantly changed (e.g., the location has changed by at least a threshold amount, or the user has left the fenced area that includes the previous location), the location reporting module 430 provides the updated location to server 310. Alternatively, the current location of client device 320 is reported to server 310 after a threshold amount of time has elapsed since the last location was reported. Server 310 can then use the updated location to make changes to the game, such as marking one or more virtual elements (e.g., mobs or items) near the current location of the client device, which the user can then interact with remotely later.

[0042] In one embodiment, the location reporting module 430 instantiates a persistent background process that can continue running after both application and device restarts. The persistent background process is configured to report the client device's location every X minutes (e.g., from one to ten minutes) if the device has moved at least Y meters (e.g., a range from five to one hundred meters) since the last update, or if both conditions are met. Limiting the number of updates by time prevents excessive battery drain caused by frequently waking the device to send updates when the device is moving at high speeds (e.g., in a car, train, or airplane). Conversely, limiting updates based on changes in location prevents unnecessary battery drain caused by sending multiple updates indicating the same or substantially the same location. In some embodiments, location updates may be completely disregarded if sensor data indicates the device is not moving; and once sensor data indicates the device is moving, the device can begin periodically determining whether it has moved a sufficient distance since the last update to provide an updated location.

[0043] The foreground marking module 440 provides a user interface that allows players to mark virtual elements while playing the game (i.e., while the game is in the foreground on the player's client device 320). In one embodiment, when a player is within a threshold distance of a virtual element (e.g., forty meters), the player can select (e.g., tap or click) the virtual element and be provided with options to interact with it immediately or mark it for future interaction. For example, if the virtual element is a powerful creature the player wants to fight, the player can mark the powerful creature to fight it later when the player has better equipment or more other players in the game team up with them.

[0044] Regardless of how specifically the virtual elements are marked, game module 410 enables players to interact remotely with the marked virtual elements. In one embodiment, players can access a list of all marked virtual elements in the game and select one or more marked virtual elements to interact with. Alternatively, virtual elements marked by a background process can be presented in separate lists from those manually marked in the foreground. The player's current location can be irrelevant to interacting with marked virtual elements. Therefore, players can remotely interact with previously nearby virtual elements without returning to their location. Marked virtual elements can remain marked for a predetermined period of time, or they can be marked until the player interacts with the virtual element or manually unmarks it. In some embodiments, server 310 limits the number of virtual elements that can be stored and associated with a given user, or limits the number of virtual elements that can be marked per specified time period (using both background and foreground marking processes). For example, a user can be limited to marking three virtual elements per day and storing eight virtual elements for a given time period. In some embodiments, these limits are initially set to default numbers, but can be adjusted, for example, in response to user selection. Additionally or alternatively, at any given time, a user may be limited to having no more than a threshold number of marked virtual elements (e.g., three to nine), and once a previously marked virtual element is unmarked (whether by the expiration of a timer, user interaction with the virtual element, or manual unmarking), a new slot becomes available for marking a new virtual element.

[0045] The notification module 450 displays information related to the parallel reality game on one or more user interfaces of the client device 320. In one embodiment, the notification module 450 receives a push notification from the server 310 when a virtual element is marked. Thus, players can be notified that they are currently near the virtual element and can choose to interact with it immediately. This approach may be desirable, for example, where the number of virtual elements that can be marked simultaneously is limited, allowing players to reserve marked elements for important, rare virtual elements. Additionally or alternatively, the notification module 450 may periodically (e.g., daily) notify players of the number of virtual elements they currently mark, or notify them when they have marked the maximum number of virtual elements, to encourage players to open the game and interact with some or all of the marked virtual elements, or manually unmark one or more virtual elements.

[0046] Local data storage 460 is one or more computer-readable media configured to store data used by client device 320. For example, local data storage 460 may store a local copy of the current state of a parallel reality game, a local list of virtual elements already marked by the player, or any other suitable data. Although local data storage 460 is presented as a single entity, the data can be distributed across multiple media. Furthermore, the data can be stored in other locations (e.g., a distributed database), and the data can be accessed remotely via network 370. Example Server

[0047] Figure 5 The figure illustrates one embodiment of server 310 suitable for hosting location-based parallel reality games. In the illustrated embodiment, server 310 includes a general game module 510, a background tagging module 520, a notification generation module 530, and a game database 540. In other embodiments, server 310 includes different or additional components. Furthermore, functionality may be distributed among the components in a different manner than described above.

[0048] Server 310 can be configured to receive requests for game data from one or more clients 320 (e.g., via Remote Procedure Call (RPC)) and respond to those requests via network 370. For example, server 310 can encode game data into one or more data files and provide these data files to clients 320. Furthermore, server 310 can also be configured to receive game data (e.g., player position, player actions, player input, etc.) from one or more clients 320 via network 370. For example, client devices 320 can be configured to periodically send player input, player position, and other updates to server 310, which server 310 uses to update game data in game database 540 to reflect changes in the game.

[0049] The general-purpose game module 510 hosts the location-based game for players and serves as the authoritative source for the current state of that location-based game. The general-purpose game module 510 receives game data (e.g., player input, player location, player actions, player state, landmark information, etc.) from the client device 320 and merges the received game data into the entire location-based game for all players. The general-purpose game module 510 can also manage the delivery of game data to the client 320 via network 370.

[0050] The general gaming module 510 can issue tokens that authorize processes executing on client device 320 to access functionality provided by server 310. Tokens are valid for a specified time period after generation (e.g., one hour, one day, seven days, thirty days, etc.). In one embodiment, when a player logs into a location-based game, the general gaming module 510 generates a token for a background process used to provide location data and sends the token to the player's client device 320. This background process token can be valid for an extended period (e.g., thirty days) so that the background process can continue to provide location data even when the player is not playing the game. Each time a player initiates a game, the general gaming module 510 can reinitialize the background process token or issue a new token to restart the time period.

[0051] In some embodiments, the general game module 510 handles interactions between players and virtual elements. Multiple players can collaborate to interact with the same game element. For example, a first player can request help to fight a monster (e.g., by sharing a QR code with other players in the same geographic area), and other players can offer assistance and participate in cooperative combat with that monster. In one embodiment, all players in the geographic area can see the same monsters on the map (e.g., monsters A, B, and C). When player A wants companions to fight monster A, player A requests help. All nearby players see the request for player A fighting monster A. If more than a maximum number (e.g., three) of players attempt to join player A's battle, the first set of players, up to the maximum threshold number, joins player A's battle, and any remaining players are placed into a new battle with monster A, each group being at most the maximum group size (the threshold number of players helping plus one). If multiple players request help fighting monster A, these requests can be grouped into one battle instead of creating multiple battles, where each battle has fewer than the maximum number of players. Therefore, if a large number of players (e.g., a thousand) all request help, these requests will be grouped by monster, and the total number of requests will become the number of monsters that at least one player is fighting, rather than the total number of players. Players requesting to fight the same monster will be grouped into groups up to the largest possible group size based on one or more criteria. In the example above, the criterion is simply the order in which players indicate their desired monster to fight, but other criteria can be used, such as player affinity, distance between players, player preferences, player teams or factions, player skill level, etc.

[0052] In various embodiments, the background tagging module 520 may be part of or separate from the general game module 510. The background tagging module 520 is configured to receive location data from the client device 320 and tag one or more virtual elements based on the received location data. In one embodiment, the background tagging module 520 receives the location of the client device 320 and identifies an area surrounding the client device 320. This area may be a circular area centered at the location of the client device 320 with a predetermined radius, another shape centered at the current location (e.g., a square with predetermined side lengths), or a pre-existing fenced area including the current location (e.g., an S2 cell), etc.

[0053] The background tagging module 520 determines whether any tagable virtual element is located within the identified area. If a virtual element is defined as a tagable type (e.g., in the game database 540), then that virtual element can be tagable. Therefore, some virtual element types (e.g., monsters) can be tagable, while others (e.g., enhancement items) cannot. Assuming at least one tagable virtual element exists within the identified area, one or more virtual elements are tagged by the player. Tagging may include adding the player's identifier along with the virtual element's identifier to a table in the game database 540.

[0054] In various embodiments, the taggable elements via a background tagging process may be the same as or different from those taggable elements using a foreground process. For example, in some implementations, the virtual elements available for background tagging may differ from those that a user can manually tag simultaneously when the application is open and in the foreground of the client device 320. Therefore, users may be incentivized to use the background tagging process to obtain virtual elements (e.g., weapons, creatures) that would otherwise be unavailable in a location-based game.

[0055] If the identified area includes more than one taggable virtual element, various methods can be used to determine which virtual element(s) to tag. In one embodiment, the background tagging module 520 tags one or more taggable virtual elements closest to the player. In another embodiment, the background tagging module 520 tags one or more of the most valuable or rarest taggable virtual elements (e.g., defined by rarity scores in the game database 540). In another embodiment, the background tagging module 520 randomly selects one or more taggable virtual elements. In yet another embodiment, the background tagging module 520 tags all taggable virtual elements. In yet another embodiment, the user can provide input about one or more parameters for the background tagging module 520 to use in selecting virtual elements to tag (e.g., tagging a first type of virtual element instead of a second type, tagging virtual elements with a specified rarity higher than the value score, tagging only virtual elements within a specified geographic area, etc.). As previously described, the server 310 receives the location from the client device 320 when the client device 320 moves. Therefore, regardless of how the virtual elements are selected for marking, players can mark the attached virtual elements by moving around the world without having to open the game on their client device 320.

[0056] The notification generation module 530 generates a notification based on the marked virtual element and sends the notification to the player's client device 320. As previously mentioned, refer to Figure 4Notifications can be generated under various circumstances. For example, notifications can be generated when a player marks a virtual element, when a player marks a virtual element with at least a predetermined rarity or value, when a player marks a virtual element of a type the player has previously expressed interest in (e.g., in game settings), when a player has marked a predetermined number of virtual elements (e.g., the maximum number of virtual elements), or when the marking of a virtual element expires within a threshold number of time periods (e.g., one hour). Alternatively, notifications can be generated and sent to the client device 320 on a periodic basis (e.g., daily at a default time or at a time selected by the user).

[0057] The game database 540 includes one or more machine-readable media configured to store game data used in location-based games, which will be served or provided to client devices 320 via network 370. The game data stored in the game database 540 may include: (1) data associated with the virtual world in the location-based game (e.g., image data used to render the virtual world on a display device, geographic coordinates of locations in the virtual world, etc.); (2) data associated with players in the location-based game (e.g., player information, player experience level, player currency, player inventory, current player location in the virtual / real world, player energy level, player preferences, team information, etc.); (3) data associated with game objectives (e.g., data associated with the current game objective, the state of the game objective, past game objectives, future game objectives, desired game objectives, etc.); and (4) data associated with virtual elements in the virtual world (e.g., the location of the virtual element, the type of the virtual element, the game objective associated with the virtual element, etc.). (5) Data associated with real-world objects, landmarks, and locations linked to virtual elements (e.g., location of real-world objects / landmarks, description of real-world objects / landmarks, and the relevance of virtual elements linked to real-world objects); (6) Game status (e.g., current number of players, current status of game objectives, player leaderboards, etc.); (7) Data related to player actions / inputs (e.g., current player location, past player location, player movement, player input, player queries, player communication, etc.); (8) Identifiers of virtual elements that indicate that the virtual element has been marked by the player, combined with player identifiers; and (9) any other data used, related to, or acquired during the implementation of location-based games. Game data stored in the game database 540 may be populated offline or in real-time by the system administrator, or by data received from players, such as from one or more client devices 320 via network 370.

[0058] The game database 540 can also store real-world condition data. Real-world condition data may include: aggregated player locations in the real world; player actions associated with locations of cultural or commercial value; map data providing the locations of roads, highways, and waterways; current and past locations of individual players; hazard data; weather data; event calendar data; player activity data (e.g., distance traveled, minutes of practice); and other appropriate data. Real-world condition data can be collected or obtained from any appropriate source. For example, the game database 540 may be coupled to, or be part of, a map database that stores map information (such as one or more map databases accessed by a map service). As another example, the server 310 may be coupled to one or more external data sources or services that periodically provide population data, hazard data, weather data, event calendar data, etc. Example Fence Configuration

[0059] Figure 6 An example configuration of a geofence around a user is shown according to one embodiment. As described above, in some embodiments, when a location update is provided from client device 320, location reporting module 430 sets one or more geofences around the provided location, which can be used to determine when to trigger the next tagging operation. For example, in Figure 6 In the configuration illustrated, the user (e.g., client device 320) is positioned at the center of the configuration, while circular (or other shaped) geofences are placed at the center of a predetermined set of distances from the user in each basic direction (e.g., 25 meters, 50 meters, 80 meters, and 150 meters from the user's north, south, east, and west). When the location reporting module 430 determines that the client device 320 has entered any of these geofenced areas, the Parallel Reality application can be activated and provide the server 310 with an updated location.

[0060] One or more geofences that have been entered may affect updates provided for parallel reality applications. For example, server 310 can provide application data for the geographic area included within the largest geofence entered by client device 320. Therefore, if the client device has traveled further (e.g., because it is moving faster), server 310 will provide application data for a larger area than if the client device 320 had traveled a shorter distance (e.g., because it is moving slowly). Example Method

[0061] Figure 7This is an example method 700 described according to one embodiment for marking virtual elements in a parallel reality application and remotely interacting with virtual elements in a parallel reality application. Figure 7 The steps are illustrated from the perspective of server 310 executing method 700. However, some or all of the steps may be performed by other entities or components. Furthermore, some embodiments may execute these steps in parallel, in a different order, or by performing different steps.

[0062] In the illustrated embodiment, method 700 begins at server 310, which receives a new geographic location of the user. The user's geographic location can be the location of the user's client device 320, which is sent to the server when the client device 320 has moved a considerable distance since the last location update or when a threshold amount of time has elapsed since the last location was reported to server 310. If a parallel reality application is inactive on the user's client device 320 (e.g., running only in the background or not running at all), the location can be provided by a background process.

[0063] Server 310 identifies a virtual location 720 in the virtual world, which maps to the user's geographic location. As previously described, in parallel reality applications, the virtual world has a coordinate system that maps to the real-world coordinate system, allowing the user to navigate the virtual world by moving around in the real world. Server 310 also identifies a region 730 in the virtual world based on the user's location. For example, this region could be a circle or other shape centered on the user's location, or a predefined fenced area including the user's location.

[0064] Server 310 selects one or more virtual elements within region 740 for the user to mark. In one embodiment, server 310 selects one virtual element to mark. If multiple virtual elements are available, server 310 may select 740 based on proximity to the user, the value or rarity of the virtual element, user preference, randomly, or using any other suitable criterion. Server 310 stores the identifier of the selected virtual element (or multiple virtual elements) in conjunction with the user's identifier (e.g., in game database 540) to indicate that the user has marked the virtual element.

[0065] At a later time (e.g., while the user is actively using a parallel reality application), server 310 provides a list of 760 marked virtual elements (including the selected virtual element 740) for display to the user. The user selects one of the listed virtual elements, and server 310 facilitates interaction between the user and that virtual element. For example, without being physically near the selected virtual element, the user can claim, capture, fight, recharge, repair, or communicate with it. After the user has interacted with the virtual element, the marker is removed. Example computing system

[0066] Figure 8 This is a block diagram of an example computer 800 suitable for use as a client device 320 or a server 310. The example computer 800 includes at least one processor 802 coupled to a chipset 804. References to the processor (or any other component of the computer 800) should be understood to refer to any one or a combination of such components that work together to provide the aforementioned functionality. The chipset 804 includes a memory controller hub 820 and an input / output (I / O) controller hub 822. A memory 806 and a graphics adapter 812 are coupled to the memory controller hub 820, and a display 818 is coupled to the graphics adapter 812. A storage device 808, a keyboard 810, a pointing device 814, and a network adapter 816 are coupled to the I / O controller hub 822. Other embodiments of the computer 800 have different architectures.

[0067] exist Figure 8 In the illustrated embodiment, storage device 808 is a non-transitory computer-readable storage medium, such as a hard disk drive, optical disc read-only memory (CD-ROM), DVD, or solid-state storage device. Memory 806 holds instructions and data used by processor 802. Pointing device 814 is a mouse, trackball, touchscreen, or other type of pointing device, and can be used in conjunction with keyboard 810 (which may be an on-screen keyboard) to input data into computer system 800. Graphics adapter 812 displays images and other information on display 818. Network adapter 816 couples computer system 800 to one or more computer networks, such as network 370.

[0068] Depend on Figures 3 to 5 The type of computer used by the entity can vary depending on the embodiment and the processing power required by the entity. For example, server 310 may include multiple blade servers working together to provide the aforementioned functionality. Furthermore, the computer may lack some of the components described above, such as keyboard 810, graphics adapter 812, and display 818. Additional considerations

[0069] Some of the foregoing descriptions describe embodiments in the form of algorithmic processes or operations. These algorithmic descriptions and representations are commonly used by those skilled in the art to effectively communicate the substance of their work to others skilled in the art. While these operations are described functionally, computationally, or logically, they should be understood as being implemented by computer programs, including instructions, microcode, etc., for execution by a processor or equivalent circuitry. Furthermore, it has sometimes proven convenient, without loss of generality, to refer to the arrangement of these functional operations as modules.

[0070] Any reference to "one embodiment" or "an embodiment" indicates that a particular element, feature, structure, or characteristic associated with that embodiment is included in at least one embodiment. The phrase "in one embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment. Similarly, the use of "a" or "an" before an element or component is merely for convenience. Unless otherwise expressly stated, this description should be understood to indicate the presence of one or more elements or components.

[0071] When a value is described as “approximate” or “basic” (or its derivatives), it should be understood to be within ±10% of the total range unless the context clearly indicates otherwise. For example, “approximately ten” should be understood to mean “in the range of nine to eleven”.

[0072] The terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variation thereof are intended to cover non-exclusive inclusion. For example, an process, method, article, or apparatus that includes a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such a process, method, article, or apparatus. Furthermore, unless expressly stated otherwise, “or” refers to an inclusive or, not an exclusive, or. For example, condition A or B is satisfied by any 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 exist).

[0073] Upon reading this disclosure, those skilled in the art will understand that additional alternative structural and functional designs exist for providing the described functions in the systems and processes. Therefore, while specific embodiments and applications have been illustrated and described, it should be understood that the described subject matter is not limited to the precise structures and components disclosed. The scope of protection should be limited to the following claims.

Claims

1. A computer-implemented method comprising: receiving a geographic location of a user; identifying a virtual location in a virtual world that maps to the geographic location of the user; identifying a region of the virtual world based on the identified virtual location; selecting a virtual element within the region of the virtual world; storing an identifier of the virtual element in conjunction with an identifier of the user to indicate that the virtual element is tagged; providing a list of tagged virtual elements for display to the user, the tagged virtual elements including the virtual element; and implementing an interaction between the user and a selected one of the tagged virtual elements.

2. The computer-implemented method of claim 1, further comprising: receiving an updated geographic location of the user, the updated geographic location indicating that the user has moved more than a threshold distance from the geographic location; selecting additional virtual elements that are proximate to the updated geographic location; and storing identifiers of the additional virtual elements in conjunction with the identifier of the user, wherein the list of tagged virtual elements further includes the additional virtual elements.

3. The computer-implemented method of claim 1, further comprising: receiving an updated geographic location of the user, the updated geographic location indicating that the user has moved to a different region of the virtual world; selecting additional virtual elements within the different region of the virtual world; and storing identifiers of the additional virtual elements in conjunction with the identifier of the user, wherein the list of tagged virtual elements further includes the additional virtual elements.

4. The computer-implemented method of claim 1, wherein the geographic location of the user is received from a background tagging process that monitors a location of a user client device while an application associated with the virtual element is not in focus on the user client device.

5. The computer-implemented method of claim 4, wherein virtual elements taggable via the background tagging process are different from virtual elements taggable via a foreground tagging process.

6. The computer-implemented method of claim 1, wherein the virtual element is one of a plurality of virtual elements in the selected region, and an identifier of each of the plurality of virtual elements is stored in conjunction with the identifier of the user.

7. The computer-implemented method of claim 1, wherein the virtual element is of a type defined to be taggable via a background tagging process, and wherein at least one other type of virtual element is defined to be of a type that is not taggable via the background tagging process.

8. The computer-implemented method of claim 1, wherein the virtual element is selected based on one or more of proximity to the user, value or rarity of the virtual element, or user preferences, or is selected randomly. ​ ​ ​ 9. The computer-implemented method of claim 1, further comprising: In response to determining that the interaction between the user and the selected one of the tagged virtual elements has ended, removing the identifier of the selected one of the tagged virtual elements from being stored in connection with the identifier of the user.

10. The computer-implemented method of claim 1, further comprising: In response to storing the identifier of the virtual element in connection with the identifier of the user, sending a notification to the user.

11. A non-transitory computer-readable storage medium comprising instructions executable by a processor, the instructions executable to perform operations comprising: receiving a geographic location of a user; identifying a virtual location in a virtual world that maps to the geographic location of the user; identifying a region of the virtual world based on the identified virtual location; selecting a virtual element within the region of the virtual world; storing an identifier of the virtual element in connection with an identifier of the user to indicate that the virtual element is tagged; providing a list of tagged virtual elements for display to the user, the tagged virtual elements including the virtual element; and implementing an interaction between the user and a selected one of the tagged virtual elements.

12. The non-transitory computer-readable storage medium of claim 11, wherein the operations further comprise: receiving an updated geographic location of the user, the updated geographic location indicating that the user has moved more than a threshold distance from the geographic location; selecting additional virtual elements that are proximate to the updated geographic location; and storing identifiers of the additional virtual elements in connection with the identifier of the user, wherein the list of tagged virtual elements further includes the additional virtual elements.

13. The non-transitory computer-readable storage medium of claim 11, wherein the operations further comprise: receiving an updated geographic location of the user, the updated geographic location indicating that the user has moved to a different region of the virtual world; selecting additional virtual elements within the different region of the virtual world; and storing identifiers of the additional virtual elements in connection with the identifier of the user, wherein the list of tagged virtual elements further includes the additional virtual elements.

14. The non-transitory computer-readable storage medium of claim 11, wherein the geographic location of the user is received from a background tagging process that monitors a location of a user client device while an application associated with the virtual element is not in focus on the user client device.

15. The non-transitory computer-readable storage medium of claim 14, wherein virtual elements taggable via the background tagging process are different from virtual elements taggable via a foreground tagging process.

16. The non-transitory computer-readable storage medium of claim 11, wherein the virtual element is one of a plurality of virtual elements in the selected region, and an identifier of each of the plurality of virtual elements is stored in connection with the identifier of the user.

17. The non-transitory computer readable storage medium of claim 11, wherein the virtual elements are of a type defined to be taggable via a background tagging process, and wherein at least one other type of virtual element is of a type defined to be untaggable via the background tagging process.

18. The non-transitory computer readable storage medium of claim 11, wherein the virtual elements are selected based on one or more of proximity to the user, value or rarity of the virtual element, or user preference, or are selected randomly.

19. The non-transitory computer-readable storage medium of claim 11, wherein the operations further comprise: responsive to determining that the interaction between the user and the selected one of the tagged virtual elements has ended, removing the identifier of the selected one of the tagged virtual elements from being stored in association with the identifier of the user.

20. The non-transitory computer-readable storage medium of claim 11, wherein the operations further comprise: responsive to storing the identifier of the virtual element in association with the identifier of the user, sending a notification to the user.

Images