How to tag virtual elements located near a user's device

Abstract

The parallel reality application allows users to approach virtual elements and tag them for subsequent interaction. It receives the user's geographical location and uses it to identify virtual locations within the virtual world that correspond to the user's geographical location. Based on the identified virtual locations, it identifies regions within the virtual world and selects one or more virtual elements within those regions. The identifiers of the one or more virtual elements are stored in conjunction with the user's identifier, and a list of tagged virtual elements is provided for the user to view. The user then interacts with one of the selected tagged virtual elements.

Description

Technical Field

[0001] The subject matter of the present invention generally relates to a parallel real world, and more particularly to tagging virtual elements in a parallel real world and then enabling a user to remotely interact with the tagged virtual elements.

Background Art

[0002] This application claims priority based on Singapore Application No. 10202301152W filed on April 25, 2023, and US Application No. 18 / 644,523 filed on April 24, 2024, and incorporates these applications by reference.

[0003] Parallel reality applications provide a virtual world that has a geography associated with at least a portion of the real world. A user navigates the virtual world by moving around in the real world. In conventional parallel reality applications, a user can interact with virtual elements that are in proximity to the user only when an application for interacting with the virtual world is open on the user's client device. When the application is not open and not in front of the display of the user's client device, the user does not recognize the virtual elements around him or her. As a result, the user may miss an opportunity to communicate with the virtual elements in the virtual world.

Summary of the Invention

[0004] This disclosure describes an approach for tagging virtual elements within a parallel reality application based on proximity to a user. Tagged virtual elements can then be remotely interacted with by the user. In one embodiment, virtual elements can be tagged even when the user is not using the parallel reality application. Background processing monitors the location of the user's client device and reports the client device's location to the parallel reality application server if one or more conditions are met (e.g., the location has changed by a threshold amount since the previous location was sent to the server, the location has moved from one geographic virtual boundary region to another, or more than a threshold amount of time has elapsed since the previous location was sent to the server). The server tags one or more virtual elements that are close to the client device's location (e.g., within a predetermined distance from the location, or within the same geographic virtual boundary region as the location). The user may then be presented with the opportunity to interact with the tagged items within the parallel reality application, regardless of the current location of the user's client device.

[0005] In one embodiment, when the server receives the location of the user's client device, the server tags one or more virtual elements in the vicinity of the client device (assuming that taggable virtual elements exist in the vicinity of the client device). If the server receives an updated location of the client device and indicates that the client device has moved a significant distance from its previous received location (either because the client device has moved a predetermined distance or because the user has entered a different geographic virtual boundary region), the server tags one or more additional virtual elements in the vicinity of the client device's new location (assuming again that taggable virtual elements exist in the vicinity of the new location). Thus, as the user moves around the world, the server tags virtual elements each time the user moves a predetermined distance or moves from one encircling region to another. [Brief explanation of the drawing]

[0006] [Figure 1] This is a diagram illustrating a representation of a virtual world having geography parallel to the real world, according to one embodiment. [Figure 2] This figure illustrates an exemplary game interface for a parallel reality game according to one embodiment. [Figure 3] This is a block diagram showing a networked computing environment suitable for providing virtual element tagging according to one embodiment. [Figure 4] This is a block diagram showing a client device as depicted in Figure 3, according to one embodiment. [Figure 5] This is a block diagram showing a server according to one embodiment, as shown in Figure 3. [Figure 6] This figure illustrates an example of a surrounding environment configuration around a user, according to one embodiment. [Figure 7] This is a flowchart showing a process for tagging virtual elements and performing remote interactions with those virtual elements according to one embodiment. [Figure 8] This figure illustrates an example of a computer system suitable for use in the networked computing environment shown in Figure 1, according to one embodiment. [Modes for carrying out the invention]

[0007] The drawings and the following description describe specific embodiments for illustrative purposes only. Those skilled in the art will recognize from the following description that alternative embodiments of the configuration and method may be used without departing from the principles described. Where practicable, similar or identical reference numerals are used in the drawings to indicate similar functions or similar functionality. Where elements share different letters following a common numeral, this indicates that those elements are similar or identical. References to numerals alone usually refer to any one or any combination of such elements, unless the context indicates otherwise.

[0008] Various embodiments are described in relation to parallel reality games, which include augmented reality content in a virtual world geography that parallels at least a portion of the real world geography. This allows player movements and actions in the real world to influence actions in the virtual world. The subject matter described is applicable to other situations where providing remote interaction with virtual elements is desirable. Furthermore, the inherent flexibility of computer-based systems allows for a wide variety of possible configurations, combinations, and divisions of tasks and functionalities between two, and three or more, components of the system.

[0009] [Example of a location-based parallel reality game] Figure 1 is a conceptual diagram showing a virtual world 110 parallel to the real world 100. The virtual world 110 can function as a game board for each player in a parallel reality game or for users of other parallel reality applications. As illustrated, the virtual world 110 includes geography parallel to that of the real world 100. In particular, coordinate ranges that define geographical areas or spaces in the real world 100 are mapped to corresponding ranges of coordinates that define virtual spaces in the virtual world 110. Coordinate ranges in the real world 100 can be associated with towns, neighborhoods, cities, campuses, regions, countries, continents, the entire globe, or other geographical areas. Each geographic coordinate within a geographic coordinate range is mapped to a corresponding coordinate in virtual space in the virtual world 110.

[0010] A player's position in the virtual world 110 corresponds to their position in the real world 100. For example, player A, located at position 112 in the real world 100, has a corresponding position 122 in the virtual world 110. Similarly, player B, located at position 114 in the real world 100, has a corresponding position 124 in the virtual world 110. As players move within the range of geographic coordinates in the real world 100, they also move within the range of coordinates defining the virtual space in the virtual world 110. In particular, positioning systems associated with mobile computing devices carried by players (e.g., GPS systems, location systems, or both) can be used to track a player's position as they navigate within the range of geographic coordinates in the real world 100. Data associated with a player's position in the real world 100 is used to update the player's position within the corresponding range of coordinates defining the virtual space in the virtual world 110. In this way, players can navigate along a continuous orbit within a coordinate range that defines the virtual space in the virtual world 110 by moving between corresponding ranges of geographic coordinates in the real world 100, without needing to record or periodically update location information at specific individual locations in the real world 100.

[0011] Location-based games can include game objectives that require each player to move to or interact with various virtual elements or objects scattered at various virtual locations within a virtual world 110. Players can move to these virtual locations by moving to the corresponding locations of the virtual elements or objects in the real world 100. For example, a positioning system can track each player's location. This causes players to navigate the parallel virtual world 110 as they navigate the real world 100. Players can then interact with various virtual elements and objects at specific locations to achieve or accomplish one or more game objectives.

[0012] The game objective may involve each player interacting with virtual elements 130 located at various virtual locations within a virtual world 110. These virtual elements 130 can 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 appropriate real-world landmarks or objects. Interactions may include capturing virtual items, claiming ownership, using virtual items, using virtual currency, etc. To capture these virtual elements 130, players must move to the real-world landmark or geographical location 140 linked to the virtual element 130 and perform any necessary interactions with the virtual element 130 in the virtual world 110 (as defined by the game rules). For example, player A may need to interact with a virtual element 130 linked to a specific landmark 140, or capture that virtual element. Interaction with the virtual element 130 may require real-world actions, such as taking a photograph, or confirming, obtaining, or capturing other information about a landmark or object 140 associated with the virtual element 130.

[0013] Game objectives may require players to use one or more virtual items collected by each player in a location-based game. For example, players may travel through the virtual world 110 in search of virtual items 132 (e.g., weapons, creatures, power-ups, other items) that can be useful in achieving game objectives. These virtual items 132 can be discovered or collected by traveling to various locations in the real world 100, or by completing various actions in either the virtual world 110 or the real world 100 (e.g., interacting with virtual elements 130, battling non-player characters or other players, or completing quests). In the example shown in Figure 1, a player acquires one or more virtual elements 130 using virtual items 132. In particular, a player may place virtual items 132 at a location in the virtual world 110 near or within a virtual element 130. Placing one or more virtual items 132 in this way may result in the capture of a virtual element 130 for the player or for the player's team / faction.

[0014] In certain implementations, players may collect virtual energy as part of a parallel reality game. This virtual energy (150) can be distributed across various locations within the virtual world (110). Players can collect this virtual energy (150) by moving to locations in the real world (100) that correspond to the virtual energy locations in the virtual world (110) (or within a threshold distance). The virtual energy (150) can be used to power virtual items or to accomplish various game objectives within the game. A player who has lost all of their virtual energy (150) may be disconnected from the game or prevented from playing for a certain period of time, or until they collect additional virtual energy (150).

[0015] In accordance with the aspects of this disclosure, a parallel reality game can be a massively multiplayer location-based game in which all participants in the game share the same virtual world. Players can be divided into separate teams or factions and can cooperate to achieve one or more game objectives, such as acquiring or claiming ownership of virtual elements. In this way, a parallel reality game can be a social game that essentially facilitates cooperation among players in the game. During a parallel reality game, players from opposing teams can compete against each other (or, in some cases, cooperate to achieve each other's objectives). Players can use virtual items to attack or hinder each other in the opposing team. Players may use virtual items to attack or hinder each other in the opposing team. In some cases, for cooperative or interactive events in a parallel reality game, players may be encouraged to gather in real-world locations. In such cases, the server will strive to ensure that players are actually physically present and that their locations are not spoofed.

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

[0017] According to aspects of this disclosure, a player can interact with a parallel reality game by carrying a client device in the real world. For example, a player can access an application associated with a parallel reality game on a smartphone and play the game by moving around in the real world with the smartphone. In this regard, the player does not need to continuously view a visual representation of the virtual world on a display screen in order to play a location-based game. As a result, the user interface 200 can include non-visual elements that enable the user to interact with the game. For example, the game interface can provide the player with audible notifications when the player approaches 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 control these audible notifications using audio controls 240. Different types of audible notifications can be provided to the user depending on the type of virtual element or event. The frequency or volume of the audible notifications can be increased or decreased depending on the player's proximity to the virtual element or object. Other non-visual notifications and signals, such as vibration notifications or other appropriate notifications or signals, can also be provided to the user.

[0018] Parallel reality games can have various features to enhance and facilitate gameplay within the game. For example, players can accumulate virtual currency or other virtual rewards (e.g., virtual tokens, virtual points, virtual goods, etc.), which can be used throughout the game (e.g., to purchase in-game items, exchange items for other items, craft items, etc.). Players can progress to various levels as they achieve one or more game objectives and gain experience within the game. Players can also acquire enhanced "powers" or virtual items that can be used to achieve in-game objectives.

[0019] One skilled in the art will understand that, using the provided disclosure, numerous game interface configurations and underlying functions are possible. The present disclosure is not intended to be limited to any one particular configuration, unless expressly stated to the contrary.

[0020] [Examples of Parallel Reality Systems] FIG. 3 illustrates one embodiment of a distributed parallel reality system 300. The parallel reality system 300 includes user interactions in a virtual world having a geography that parallels the real world. In particular, geographic regions within the real world can have a direct coupling or association with corresponding regions within the virtual world. A user can move about within the virtual world by moving to various geographic locations within the real world. The system 300 can track the position of a user in the real world and update the position of the user in the virtual world based on the user's current position in the real world. For example, a coordinate system in the real world (e.g., longitude and latitude, etc.) can be associated with a coordinate system in the virtual world (e.g., an x - coordinate / y - coordinate, virtual longitude and latitude, etc.).

[0021] In the embodiment shown in FIG. 3, the distributed parallel reality system 300 includes a server 310 and client devices 320 connected via a network 370. Three client devices 320 are shown, but 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. Further, each function may be distributed among the elements in a manner different from that described.

[0022] Server 310 includes one or more computing devices that provide application functions to client device 320. In one embodiment, server 310 serves as a host for the universal state of a location-based game and provides game status update information to the client device 320 of each player (e.g., based on actions performed by other players in the game, changes in the real-world situation, changes in the game state or situation, etc.). Server 310 receives and processes inputs from players in the location-based game. The players can be identified by a username or player ID (e.g., a unique number or alphanumeric string, etc.) that the client device 320 of each player sends to server 310 in conjunction with each player's input.

[0023] For example, server 310 may receive a request from client device 320 for a corresponding player to perform an in-game action. This request may include information regarding the requested action, such as the player's identifier, the identification of the object with which the player desires to interact, and the nature of the requested interaction (e.g., to perform pickup, drop, capture, upgrade, etc.). Server 310 determines the result and may return a game update to the client device based on the determined result. Also, server 310 receives real-world activity data from the client device 310 of the player and determines in-game results based on the real-world activity data. Further, server 310 may notify each player of the specific in-game results resulting from the real-world activity data (e.g., via push notifications, etc.). Various embodiments of server 310 will be described in more detail below with reference to FIG. 5.

[0024] The client device 320 can be any portable computing device that can be used by the player to establish an interface connection to the server 310. For example, the 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. Depending on the use case, the client device 320 may be a less mobile device, such as a desktop computer or laptop computer. Furthermore, the client device 320 may be a vehicle with a built-in computing device.

[0025] The client device 320 may run software (e.g., a game application or app) to enable the player to interact with the virtual world. The client device 320 may perform background processing, providing location information to the server 310 periodically or in response to specific trigger events. The server 310 may use its location information to tag virtual elements in the vicinity of the client device 320 (e.g., within a threshold distance), and its software may later enable the user to interact with the tagged virtual elements remotely (i.e., without requiring the client device to be in close proximity to the virtual elements when the interaction occurs). The software may also allow the user to manually tag virtual elements in the vicinity of the client device and provide subsequent remote interactions with the manually tagged virtual elements. Various embodiments of the client device 320 are described in more detail below with reference to Figure 4.

[0026] Network 370 can be any type of communication network, such as a local area network (e.g., an intranet), a wide area network (e.g., the Internet), or a combination thereof. The network may also include a direct connection between client devices 320 and server 310. In general, communication between server 310 and client devices 320 can be performed via a network interface using any type of wired or wireless connection, employing various communication protocols (e.g., TCP / IP, HTTP, STP, FTP, etc.), encoding or formatting (e.g., HTML, JSON, NW, etc.), or protection schemes (e.g., VPN, Secure HTTP, SSL, etc.).

[0027] This disclosure refers to servers, databases, software applications, and other computer-based systems, as well as actions performed on such systems and information transmitted to and from such systems. Those skilled in the art will understand that the inherent flexibility of computer-based systems allows for a wide variety of possible configurations, combinations, and divisions of tasks and functions between two or more components. For example, a process disclosed as being implemented by a server may be implemented using a single server or multiple servers working in conjunction. Databases and applications may be implemented on a single system or distributed across multiple systems. Distributed components may operate sequentially or in parallel.

[0028] Where disclosed systems and methods access and analyze personal information about a user, or use personal information such as location information, the user may be given the opportunity to control whether the program or function collects such information, and whether or not it receives content from the system or other applications, and how it receives it. Such information or data will not be collected or used until the user is given meaningful notice about what information is collected and how it will be used. Unless the user provides consent, the information will not be collected or used. This consent can be withdrawn or modified by the user at any time. Thus, the user can have control over how information about them is collected and used by the application or system. Furthermore, certain information or data may be processed in one or more ways before being stored or used, so that personally identifiable information is removed. For example, a user's ID may be processed in such a way that personally identifiable information about the user cannot be identified.

[0029] [Example of client device] Figure 4 illustrates 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 front tagging module 440, a notification module 450, and a local data store 460. In other embodiments, the client device 320 includes different or additional elements. Furthermore, each function may be distributed among the elements in a manner different from that described.

[0030] The game module 410, run by the client device 320, provides an interface between the player and the location-based game. The game module 410 can provide a user interface to a display associated with the client device 320 (e.g., a built-in screen or an AR headset). This client device displays the virtual world 110 associated with the game and allows the player to interact with the virtual world to complete various game objectives. The game module 410 can also control various other outputs to allow the player to interact with the game without requiring them to look at the display screen. For example, the game module 410 can control various sounds, vibrations, and other notifications. The game module 410 can access game data received from the server 310 to provide the player with an accurate representation of the current state of the virtual world 110. The game module 410 can receive and process player input and provide update information for the virtual world 110 to the server 310 via the network 370.

[0031] The positioning subsystem 420 monitors the location of the client device 320. The positioning subsystem 420 can be any device or circuit for monitoring 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 system (e.g., GPS system, Galileo positioning system, Global Navigation Satellite System (GLONASS), Beidou satellite navigation system, etc.), an inertial navigation system, a dead reckoning system, triangulation or proximity to a cell tower or Wi-Fi hotspot, or other appropriate techniques. 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 of the client device 320, and optionally its orientation (collectively, "pose"), by comparing images captured by one or more cameras with a 3D map of the client device's environment. For example, a rough location may be determined using GPS, and the positioning subsystem 420 may search a 3D map based on the rough location, and then visual positioning is used to determine the more precise location (and optionally the orientation) of the client device.

[0032] As the player moves around the real world with the client device 320, the positioning subsystem 420 tracks the player's location and provides the player's location data to the game module 410. The game module 410 updates the player's location in the virtual world 110 based on the player's location in the real world 100. In particular, the player's location in the virtual world 110 can be made to correspond to the player's location in the real world 100 (as described above, see Figure 1). As the player plays the game, the game module 410 can provide the player's location data to the server 310 via the network 370, so that the universal game module 510 can continue to track the player's location throughout the game.

[0033] The location reporting module 430 enables reporting the location of the client device 320 to the server 310 when the player is not actively playing the game. In one embodiment, the location reporting module 430 initiates background processing to monitor the location of the client device 320. This background processing may be initiated in response to the player switching on an in-game feature to provide back tagging of virtual elements. The player may be notified that this feature causes the player's location to be provided to the server 310, and that the player may refuse or disable this feature.

[0034] Assuming this function is enabled, background processing updates server 310 with the player's current location if one or more criteria are met. For example, if the user closes or defocuses the game on client device 320, the location reporting module 430 may provide server 310 with the current location of client device 320. In another example, when client device 320 is restarted, its current location is reported. Background processing may periodically compare the location of client device 320 with a previous location provided by server 310. If this location has changed sufficiently (for example, if it has changed by at least a threshold amount, or if the user has moved away from the area containing the previous location), the location reporting module 430 provides server 310 with updated location information. Alternatively, the current location of client device 320 is reported to server 310 after a threshold amount of time has elapsed since the previous location was reported. Subsequently, server 310 may use the updated location to make changes within the game, such as tagging one or more virtual elements (e.g., creatures or items) that are close to the client device's current location, allowing the user to interact with them remotely later.

[0035] In one embodiment, the location reporting module 430 instantiates persistent background processing that can withstand application and device restarts. This persistent background processing is configured to report the client device's location within X minutes (e.g., within 1 to 10 minutes) if the device has moved at least Y meters since the last update (e.g., within a range of 5 to 100 meters), or both conditions are met. Limiting the number of updates by time can prevent excessive battery drain by activating the device to send update information frequently when the device is moving at high speed (e.g., in a car, train, or airplane). Conversely, limiting updates based on changes in location prevents unnecessary battery drain by sending multiple update messages indicating the same or substantially the same location. In some embodiments, if sensor data indicates that the device is not moving, location updates are not considered at all, and if sensor data indicates that the device is moving, the device may initiate periodic determinations as to whether it has moved a sufficient distance since the previous update in order to provide an updated location.

[0036] The front tagging module 440 provides a user interface that allows players to tag virtual elements while they are playing the game (i.e., while the game is in the foreground on the player's client device 320). In one embodiment, if a player is within a threshold distance (e.g., 40 meters) of a virtual element, the player is presented with the option to select the virtual element (e.g., tap or click) and interact with that virtual element now or tag it for future interaction. For example, if the virtual element is a powerful creature that the player wishes to fight, the player can tag that creature and fight it later when the player has more powerful equipment or has more other players in the game to team up with.

[0037] Regardless of how virtual elements are tagged, the game module 410 allows players to interact with tagged virtual elements remotely. In one embodiment, the player may access a list of all tagged virtual elements in the game and select one or more elements to interact with. Alternatively, virtual elements tagged by background processing may be displayed in a separate list from virtual elements manually tagged in the foreground. The player's current location may be irrelevant to interaction with tagged virtual elements. Therefore, the player may interact with virtual elements they were previously remotely close to without having to return to the virtual element's location. Tagged virtual elements may remain tagged for a predetermined period of time, or they may remain tagged until the player interacts with the virtual element or manually untags it. In some embodiments, the server 310 limits the number of virtual elements that remain associated with a given user or limits the number of virtual elements that can be tagged (using background tagging and foreground tagging processes) at specified time intervals. For example, a user may be limited to tagging three virtual elements per day and to saving eight virtual elements at a given time. In some embodiments, these limits are initially set to default quantities but can be adjusted, for example, at the user's discretion. Additionally or alternatively, a user may be limited to having no more than a threshold number of tagged virtual elements (e.g., three to nine) at any given time, and a slot for tagging a new virtual element opens as soon as a previously tagged virtual element is untagged (through timer expiration, user interaction with the virtual element, or manual untagging).

[0038] The notification module 450 presents information about the parallel reality game on one or more user interfaces on the client device 320. In one embodiment, the notification module 450 receives a push notification from the server 310 when a virtual element is tagged. The player is then notified that they are currently near a virtual element and can choose to interact with it immediately. This may be desirable, for example, when there is a limit on the number of virtual elements that can be tagged at the same time, and it is possible to reserve those elements that have been virtually tagged due to the importance of rare virtual elements. Additionally or alternatively, the notification module 450 may periodically (e.g., daily) notify the player about the number of tagged virtual elements they currently own, or when the player has tagged the maximum number of virtual items, it may notify the player to open the game and interact with some or all of the tagged virtual elements, or to manually untag one or more virtual elements.

[0039] The local data store 460 is one or more computer-readable media configured to store data used by the client device 320. For example, the local data store 460 may store a local copy of the current state of a parallel reality game, a local list of virtual elements tagged by the player, or any other suitable data. Although the local data store 460 is presented as a single entity, its data may be divided among multiple media. Furthermore, its data may be stored elsewhere (e.g., in a distributed database) and accessed remotely via the network 370.

[0040] [Example of a server] Figure 5 illustrates one embodiment of a server 310 suitable for hosting a location-based parallel reality game. In the illustrated embodiment, the server 310 includes a universal game module 510, a back tagging module 520, a notification generation module 530, and a game database 540. In other embodiments, the server 310 includes different or additional elements. Furthermore, each function may be distributed among the elements in a manner different from that described.

[0041] The server 310 can be configured to receive requests for game data from one or more clients 320 (for example, via remote procedure calls (RPCs)) and to respond to those requests via the network 370. For example, the server 310 can encode game data into one or more data files and provide those data files to the clients 320. Furthermore, the server 310 can be configured to receive game data (for example, player position, player actions, player input, etc.) from one or more clients 320 via the network 370. For example, a client device 320 can be configured to periodically send player input, player position, and other update information to the server 310, which can then use this update information to update the game data in the game database 540 to reflect the changed conditions for the game.

[0042] The Universal Game Module 510 acts as a host for the location-based game for the player and serves as a reliable source of information regarding the current status within the location-based game. The Universal Game Module 510 receives game data (e.g., player input, player location, player actions, player status, landmark information, etc.) from the client device 320 and incorporates the received game data into the entire location-based game for all players. The Universal Game Module 510 can also manage the distribution of game data to the client 320 via the network 370.

[0043] The universal game module 510 may issue tokens that allow processes running on the client device 320 to access functions provided by the server 310. These tokens may be valid for a specified period of time after generation (e.g., 1 hour, 1 day, 7 days, 30 days, etc.). In one embodiment, when a player logs into a location-based game, the universal game module 510 generates a token for background processing used to provide location information and sends the token to the player's client device 320. The background processing token may be valid for an extended period of time (e.g., 30 days, etc.) to allow background processing to continue providing location information even when the player is not playing the game. Each time the player starts the game, the universal game module 510 may reinitialize the background processing token or issue a new token to restart the period.

[0044] In some embodiments, the universal game module 510 handles interactions between players and virtual elements. Multiple players may interact collaboratively with the same game element. For example, the first player may request assistance in combat with a monster (e.g., by sharing a QR code with other players in the same geographical area), and other players may offer assistance and propose to participate in the collaborative battle against the monster. In one embodiment, all players in a geographical area see the same monster on the map (e.g., monsters A, B, and C). If player A wants allies in combat against monster A, player A requests assistance. All nearby players acknowledge player A's request for combat against monster A. If more players than the maximum number (e.g., 3) attempt to join player A's battle, the first set of players that reach the threshold number join player A's battle, and any remaining players are placed in new battles against monster A in groups up to the maximum group size (threshold number of assisting players + 1). When multiple players request assistance against monster A, these requests may be grouped together rather than creating multiple battles, each limiting the number of players in each battle to below the maximum number. Therefore, if there are many players (e.g., a thousand) all requesting assistance, these requests are grouped by monster, and the total number of requests is the number of monsters that will be battled by at least one player, rather than the total number of players. Players requesting battle against the same monster are divided into groups up to the maximum group size based on one or more criteria. In the example described, the criterion is simply the order in which players express their desire to battle the monster, but other criteria may be used, such as player affinity, distance between players, player preferences, player team or faction, player level, and similarity.

[0045] In various embodiments, the back tagging module 520 is either part of the universal game module 510 or separate from it. The back tagging module 520 receives location data from the client device 320 and tags one or more virtual elements based on the received location data. In one embodiment, the back tagging module 520 receives the location of the client device 320 and identifies the area surrounding the client device 320. This area may be a circular area of ​​a predetermined radius centered on the location of the client device 320, another shape centered on the current location (e.g., a square with predetermined side lengths), or an existing ring area including the current location (e.g., an S2 cell).

[0046] The back tagging module 520 determines whether there are taggable virtual elements within the identified area. A virtual element is taggable if it is of a type defined as taggable (for example, within the game database 540). Therefore, some virtual element types (e.g., monsters) may be taggable, while others (e.g., power-ups) may not. Assuming that there is at least one taggable virtual element within the identified area, one or more virtual elements will be tagged by the player. Tagging may involve adding the player's identifier to a table in the game database 540 in conjunction with the virtual element's identifier.

[0047] In various embodiments, elements that can be tagged via back-tagging may be the same as, or different from, elements that can be tagged using foreground processing. For example, in some implementations, virtual elements that are different from virtual elements that a user can manually tag while the application is open and in front of the client device 320 are available through back-tagging. Therefore, in location-based games, users may be encouraged to use back-tagging to obtain virtual elements that are otherwise unavailable (e.g., weapons, creatures, etc.).

[0048] If an identified region contains multiple taggable virtual elements, various approaches can be used to determine which virtual element or group of virtual elements should be tagged. In one embodiment, the back tagging module 520 tags one or more taggable virtual elements closest to the player. In another embodiment, the back tagging module 520 tags one or more taggable virtual elements that are the most valuable or rarest (for example, as defined by the rarity of their value score in the game database 540). In yet another embodiment, the back tagging module 520 randomly selects one or more taggable virtual elements. In a further embodiment, the back tagging module 520 tags all taggable virtual elements. In an even further embodiment, the user may provide input regarding one or more parameters that the back tagging module 520 uses when selecting which virtual elements to tag (for example, tagging a first type of virtual element but not a second type, tagging virtual elements with a rarity score higher than a specified value, tagging only virtual elements within a specified geographical region, etc.). As described above, when the client device 320 moves, the server 310 receives location information from the client device 320. Therefore, without being directly involved in how virtual elements are selected for tagging, players can tag additional virtual elements by traversing the world without even needing to open the game on the client device 320.

[0049] The notification generation module 530 generates notifications based on tagged virtual elements and sends them to the player's client device 320. As previously described with reference to Figure 4, each notification may be generated under various circumstances. For example, a notification may be generated when a player tags a virtual element, when a player tags a virtual element that has at least a predetermined rarity or value, when a player tags a type of virtual element that the player has previously shown interest in (e.g., in game settings), when a player tags a predetermined number of virtual elements (e.g., the maximum number of virtual elements), or when the tagging of a virtual element falls within a threshold time period before it expires (e.g., one hour). Alternatively, notifications may be generated at regular intervals (e.g., daily at a default time or a time selected by the user) and sent to the client device 320.

[0050] The game database 540 includes one or more machine-readable media configured to store game data used in a location-based game, which is contributed to or provided to client devices 320 via the network 370. The game data stored in the game database 540 may include: (1) data associated with the virtual world in a 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 the player in a location-based game (e.g., player information, player experience level, player currency, player assets, player's current location in the virtual world / 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, game objective status, previous game objective, future game objective, desired game objective, etc.); (4) data associated with virtual elements in the virtual world (e.g., location of virtual elements, type of virtual element, game objective associated with virtual elements, real-world location information corresponding to virtual elements, behavior of virtual elements, relationships of virtual elements). (5) Data associated with locations of real-world objects, landmarks, and virtual world elements (e.g., location of real-world objects / landmarks, description of real-world objects / landmarks, relationship of virtual elements to real-world objects, etc.). (6) Game status (e.g., current number of players, current status of game objectives, player leaderboards, etc.). (7) Data associated with player actions / inputs (e.g., current player location, previous player location, player movement, player input, player queries, player communications, etc.). (8) Identifiers of virtual elements in conjunction with player identifiers indicating that the virtual elements have been tagged by a player. (9) Any other data used, related to, or retrieved during the implementation of a location-based game.Game data stored in the game database 540 can be imported either 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 the network 370.

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

[0052] [Example of a ring structure] Figure 6 illustrates an example of a ring configuration around a user according to one embodiment. As described above, in some embodiments, when location update information is provided from the client device 320, the location reporting module 430 sets up one or more geographic virtual boundaries around the provided location. These geographic virtual boundaries can be used to determine when to activate the next tagging operation. For example, in the configuration shown in Figure 6, the user (e.g., client device 320) is placed at the center of the configuration, while circular (or other shaped) geographic virtual boundaries are placed around predetermined distance sets from the user in each basic direction (e.g., 25 meters, 50 meters, 80 meters, and 150 meters north, south, east, and west of the user, respectively). When the location reporting module 430 determines that the client device 320 is within any of these geographic virtual boundary areas, the parallel reality application may be activated and provide the updated location to the server 310.

[0053] The geographic virtual boundary or set of geographic virtual boundaries that are input can affect what kind of update information is provided to the parallel reality application. For example, server 310 may provide application data for the geographical area contained within the largest geographic virtual boundary input by client device 320. Therefore, if the client device is moving further (for example, if the client device is moving faster), server 310 will provide application data for a wider area than if the client device 320 were moving a shorter distance (for example, if the client device is moving slower).

[0054] [Example of method] Figure 7 is a flowchart illustrating an exemplary method 700 for tagging virtual elements in a parallel reality application and interacting with them remotely, according to one embodiment. Each step in Figure 7 is illustrated from the perspective of a server 310 that performs method 700. However, some or all of the steps may be performed by other entities or components. Furthermore, in some embodiments, the steps may be performed in parallel, in a different order, or different steps may be performed.

[0055] In the illustrated embodiment, method 700 begins with the step (710) that the server 310 receives the user's new geographic location. The user's geographic location may be the location of the user's client device 320, which is sent to the server if the client device 320 has moved a significant distance since the last location update, or if a threshold amount of time has elapsed since the previous location was reported to the server 310. This location may be provided by background processing if no parallel reality application is active on the user's client device 320 (e.g., running only in the background or not running at all).

[0056] Server 310 identifies a virtual location within the virtual world that corresponds to the user's geographical location (720). As previously mentioned, in parallel reality applications, the virtual world has a coordinate system that corresponds to the coordinate system of the real world, so that the user can navigate the virtual world by moving around in the real world. Server 310 also identifies a region of the virtual world based on the user's location in the virtual world (730). For example, this region may be a circle or other shape centered on the user's location, or it may be a predefined ring region that incorporates the user's location.

[0057] Server 310 selects one or more virtual elements within the area to be tagged by the user (740). In one embodiment, Server 310 selects one virtual element to be tagged. If multiple virtual elements are available, Server 310 may select them randomly or using any other appropriate criteria, based on proximity to the user, the value or rarity of the virtual elements, or the user's preferences (740). Server 310 stores the identifier of the selected virtual element (or group of virtual elements) in conjunction with the user's identifier (for example, in the game database 540) to indicate that the user has tagged the virtual elements (750).

[0058] Later (for example, when the user is actively using the parallel reality application), the server 310 provides the user with a list of tagged virtual elements (including the selected virtual element 740) for display (760). The user selects one of the enumerated virtual elements, and the server 310 facilitates the interaction between the user and the virtual element (770). For example, the user may request, capture, battle, recharge, repair, or communicate with the selected virtual element without being physically close to it. After the user has interacted with the virtual element, its tag is removed.

[0059] [Example of a computing system] Figure 8 is a block diagram showing an example of a computer 800 suitable for use as a client device 320 or a server 310. The exemplary computer 800 includes at least one processor 802 coupled to a chipset 804. References to processors (or any other components of computer 800) should be understood to refer to such components, or combinations of such components that work together to provide the described functionality. The chipset 804 includes a memory controller hub 820 and an input / output (I / O) controller hub 822. 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 computer 800 have different architectures.

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

[0061] The type of computer used by the entities in Figures 3 to 5 may vary depending on the embodiment and the processing power required by the entities. For example, server 310 may include multiple blade servers that cooperate to provide the described functionality. Furthermore, these computers may lack some of the components described above, such as keyboard 810, graphics adapter 812, and display 818.

[0062] [Additional considerations] Some parts of the above description describe embodiments in terms of algorithmic processing or operation. These algorithmic descriptions and expressions are generally used by those skilled in computing technology to effectively communicate the content of their work to others skilled in the art. These operations are described functionally, computationally, or logically, but are understood to be implemented by computer programs, which include instructions for execution by a processor or equivalent electrical circuit, microcode, or similar. Furthermore, it has proven convenient at times, without loss of generality, to refer to arrangements of these functional operations as modules.

[0063] References to "one embodiment" or "an embodiment" mean that certain elements, features, configurations, or characteristics described in relation to that embodiment are included in at least one embodiment. The phrase "in one embodiment" appearing in various places in this 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. Such statements should be understood to mean that one or more elements or components exist, unless it becomes clear that the statement means otherwise.

[0064] When a number is described as "approximate" or "substantially" (or a derivative thereof), such a number should be interpreted with a precision of + / - 10% unless the context makes it clear otherwise. For example, "approximately ten" should be understood as "in a range from nine to eleven."

[0065] The terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variations thereof are intended to describe non-exclusive inclusion. For example, a process, method, article, or apparatus that includes a list of elements may include other elements that are not explicitly listed or are not specific to such process, method, article, or apparatus, but are not necessarily limited to those elements alone. Furthermore, unless explicitly stated otherwise, “or” refers to an inclusive “or” and not an exclusive “or.” For example, condition A or B is satisfied by one of the following: A is true (or exists) and B is false (or does not exist); or A is false (or does not exist) and B is true (or exists), and both A and B are true (or exist).

[0066] A person skilled in the art will understand, upon reading this disclosure, the design of further additional alternative configurations and functional designs for systems and processes to provide the described functionality. Therefore, while specific embodiments and applications have been illustrated and described, it should be understood that the subject matter described is not limited to the exact configurations and components disclosed. The scope of protection should be limited only by the following claims:

Claims

1. A computer implementation method, Steps include receiving the user's geographical location, The steps include identifying a virtual location in a virtual world that corresponds to the user's geographical location, The steps include identifying a region of the virtual world based on the identified virtual location, The steps include selecting a virtual element within the region of the virtual world, The steps include: storing the identifier of the virtual element in conjunction with the user identifier in order to indicate that the virtual element is tagged; A step of providing a list of tagged virtual elements for display to the user, wherein the tagged virtual elements include the virtual element, The steps include performing an interaction between the user and one of the selected tagged virtual elements. A computer implementation method comprising the above.

2. A step of receiving the updated geographic location of the user, wherein the updated geographic location indicates that the user has moved beyond a threshold distance from the geographic location. The steps include selecting additional virtual elements located near the updated geographical location, A step of storing the identifier of the additional virtual element in conjunction with the identifier of the user, wherein the list of tagged virtual elements further includes the additional virtual element. The computer implementation method according to claim 1, further comprising:

3. A step of receiving the updated geographical location of the user, wherein the updated geographical location indicates that the user has moved to a different region of the virtual world. The steps include selecting additional virtual elements within the different regions of the virtual world, A step of storing the identifier of the additional virtual element in conjunction with the identifier of the user, wherein the list of tagged virtual elements further includes the additional virtual element. The computer implementation method according to claim 1, further comprising:

4. The computer implementation method according to claim 1, wherein the user's geographical location is received from a back-tagging process to monitor the location of the user client device, while the application associated with the virtual element is not focused on the user client device.

5. The computer implementation method according to claim 4, wherein the virtual elements that can be tagged via the back tagging process are different from the virtual elements that can be tagged via the foreground tagging process.

6. The aforementioned virtual element is one of a plurality of virtual elements within the selected region, and the identifier of each of the plurality of virtual elements is stored in conjunction with the user's identifier. The computer implementation method according to claim 1.

7. The computer implementation method according to claim 1, wherein the virtual element belongs to a type defined as taggable via back-tagging, and at least one other type of virtual element belongs to a type defined as not taggable via back-tagging.

8. The computer implementation method according to claim 1, wherein the virtual element is selected based on one or more of the following: proximity to the user, value or rarity of the virtual element, or the user's preferences, or is selected randomly.

9. The computer implementation method according to claim 1, further comprising the step of removing the identifier of the selected tagged virtual element from storage in conjunction with the user's identifier, in response to determining that the interaction between the user and the selected tagged virtual element has ended.

10. The computer implementation method according to claim 1, further comprising the step of sending a notification to the user in response to storing the identifier of the virtual element in conjunction with the identifier of the user.

11. A non-temporary computer-readable storage medium containing instructions that can be executed by a processor, wherein the executable instructions are: Receiving the user's geographical location, In the virtual world, to identify a virtual location that corresponds to the user's geographical location, Based on the identified virtual location, the region of the virtual world is identified, Selecting a virtual element within the said region of the virtual world, In order to indicate that the virtual element is tagged, the identifier of the virtual element is stored in conjunction with the user's identifier, To provide a list of tagged virtual elements for display to the user, wherein the tagged virtual elements include the virtual elements. To perform an interaction between the user and one of the selected tagged virtual elements. A non-temporary computer-readable storage medium intended for performing operations including [specific operations].

12. The aforementioned operation is, Receiving the updated geographical location of the user, wherein the updated geographical location indicates that the user has moved beyond a threshold distance from the geographical location. Selecting additional virtual elements located near the aforementioned updated geographical location, The method involves storing the identifier of the additional virtual element in conjunction with the identifier of the user, wherein the list of tagged virtual elements further includes the additional virtual element. A non-temporary computer-readable storage medium according to claim 11, further comprising:

13. The aforementioned operation is, Receiving the updated geographical location of the user, wherein the updated geographical location indicates that the user has moved to a different region of the virtual world. Selecting additional virtual elements within the different regions of the aforementioned virtual world, The method involves storing the identifier of the additional virtual element in conjunction with the user's identifier, wherein the list of tagged virtual elements further includes the additional virtual element. A non-temporary computer-readable storage medium according to claim 11, further comprising:

14. The non-temporary computer-readable storage medium according to claim 11, wherein the user's geographical location is received from a back tagging process to monitor the location of the user client device, while the application associated with the virtual element is not focused on the user client device.

15. The non-temporary computer-readable storage medium according to claim 14, wherein the virtual elements that can be tagged via the back tagging process are different from the virtual elements that can be tagged via the foreground tagging process.

16. The aforementioned virtual element is one of a plurality of virtual elements within the selected region, and the identifier of each of the plurality of virtual elements is stored in conjunction with the user's identifier. The non-temporary computer-readable storage medium according to claim 11.

17. The non-temporary computer-readable storage medium according to claim 11, wherein the virtual element belongs to a type defined as taggable via a back-tagging process, and at least one other type of virtual element belongs to a type defined as not taggable via the back-tagging process.

18. The non-temporary computer-readable storage medium according to claim 11, wherein the virtual elements are selected based on one or more of the following: proximity to the user, value or rarity of the virtual elements, or the user's preferences, or are selected randomly.

19. The non-temporary computer-readable storage medium according to claim 11, 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 storing in conjunction with the user's identifier.

20. The non-temporary computer-readable storage medium according to claim 11, further comprising sending a notification to the user in response to storing the identifier of the virtual element in conjunction with the user's identifier.

Images