Triggering location-based functionality based on user proximity

Abstract

A client device associated with a user of a location-based application detects client devices associated with other users that are within proximity of the client device. The aforementioned detection of other client devices may result in various application actions occurring, such as, for example, triggering multi-user activities between the users. The detection of client devices may occur using a personal area network device of the client device, such as, for example, Bluetooth. Proximity detection may occur when a client device is disconnected from an online system hosting the location-based application, with the detection later reported by one or both devices to the online system.

Description

[Technical field]

[0001] The present disclosure relates generally to device proximity detection, and more particularly to detecting player devices over a local area network for use in location-based applications. [Background technology]

[0002] Location-based applications use the real world as a geography. A parallel reality game is a type of location-based application that uses a virtual world that is parallel to the real world geography. The parallel virtual world may span the entire real world, and players from around the world may interact and perform various game objectives in the parallel virtual world by progressing and performing actions in the real world. Additionally, some location-based applications may provide multi-user activities. In an example of a parallel reality game, similarly located players may play together in the same physical location in the real world, such as by participating in organized community game actions (e.g., live game actions associated with a particular geographic location). However, outside of the planned application functionality (e.g., game actions), similarly located application users may cross paths in the physical world without noticing each other during daily life. For example, two players of a parallel reality game may pass each other in a public space while carrying their respective mobile devices used to play the parallel reality game. As noted above, application users may be unaware of the user communities and opportunities for dynamic interaction they encounter. Summary of the Invention

[0003] A method, system, and computer-readable medium are disclosed for proximity detection between client devices associated with users of a location-based application. A user's client device may detect client devices associated with other users within the proximity of the client device. Proximity detection of other client devices may result in application functionality (e.g., game actions in a location-based parallel reality game) corresponding to the detection, such as, for example, exchange of application data (e.g., game data between players or between client devices, game progress of players, access to game features, or establishing a connection between players). In an aspect, detection of the client device is performed using a personal area network device of the client device, such as, for example, a Bluetooth device or a Wi-Fi Direct device. In the same or a different aspect, proximity detection can occur when the client device is disconnected from an online system hosting the location-based application. In the just described case, the player device can store proximity detection of other client devices and provide information representative of the detection to the online system after connecting to the online system (e.g., via the Internet). The online system then performs application functionality (e.g., game actions) based on the received information representative of the proximity detection.

[0004] In some aspects, a first client device detects a second client device within a proximity range of the first client device. A first player of a location-based application is associated with the first client device, and a second player is associated with the second client device. In response to detecting the second client device, the first client device provides a notification of availability of a multiplayer activity involving the first player and the second player. For example, the first client device displays a prompt on a screen of the first client device asking whether the user would like to join a raid with nearby players. The first client device receives user input indicating that the first player has selected the notification, and in response, provides the multiplayer activity of the location-based application.

[0005] In some aspects, a first client device detects a second client device via a third client device. The second client device is within a first proximity of the first client device. For example, the second client device and the first client device may be outside the range of each other's broadcast network, but within the enhanced range of each other. The first client device detects a third client device within the second proximity (e.g., within a Bluetooth broadcast range). The first client device receives data from the third client device indicating that the third client device has detected the second client device within the third proximity of the third client device. For example, the third client device may be located midway between the first client device and the second client device and within the broadcasting range of both. The first client device uses the data received from the third client device to determine a likelihood that the second client device is within the first proximity of the first client device. For example, the first client device may use a player identifier of a player using a second client device and a timestamp of a Bluetooth LE advertisement broadcast by the second client device to determine a threshold-exceeding likelihood that the second client device is within a first proximity of the first client device at substantially the same time as the time identified in the timestamp (e.g., within 5 minutes before or after the time identified in the timestamp).

[0006] The foregoing, as well as other features, aspects, and advantages, may be better understood with reference to the following description and the appended claims. The accompanying drawings are diagrams illustrating certain embodiments and, together with the description, serve to explain various principles. The drawings should not, however, be considered limiting. Rather, the scope of protection should be determined from the claims. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 is a block diagram illustrating a computing environment for a location-based gaming system according to one aspect. [Diagram 2] 2 is a block diagram of a client device shown in FIG. 1 according to one embodiment. [Diagram 3] FIG. 2 is a block diagram of the game server shown in FIG. 1 according to one embodiment. [Figure 4] 1 is a conceptual example of an approach to extending the range of device proximity detection according to one aspect. [Diagram 5] 1 is a flow chart illustrating a method for device proximity detection according to one aspect. [Figure 6] 1 is a flow chart illustrating a method for trading gaming items using device proximity detection according to one aspect. [Figure 7] 1 is a flow chart illustrating an aspect of a method for coordinating multiplayer activity of devices detected to be within proximity of one another. [Figure 8] 1 is a flow chart illustrating an embodiment of a method for detecting a second client device within proximity of a first client device. [Figure 9] FIG. 2 is a block diagram illustrating an example computer suitable for use in the computing environment of FIG. 1 according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] Reference will now be made to several embodiments, examples, illustrated in the accompanying drawings. It is noted that wherever practical, similar or similar reference numerals are used in the drawings to indicate similar or similar functionality. Furthermore, where similar elements are identified by a reference numeral followed by a letter, reference to a single numeral in the following description may refer to all such elements, any one of such elements, or any combination of such elements. Those skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods may be utilized without departing from the principles described.

[0009] Further, one context in which proximity-based functionality (e.g., multiplayer augmented reality activities) may be triggered will be described with reference to a parallel reality gaming system. However, the described proximity detection and proximity-triggered functionality may be extended to any suitable multi-user online application. Without limitation, examples of multi-user online applications include social networks, educational programs, group health and fitness activities, multi-user games, or any suitable multi-user activity facilitated over a wireless network.

[0010] Exemplary Location-Based Parallel Reality Gaming System Various aspects are described in which player device proximity detection is performed in the context of a parallel reality game. A parallel reality game is a location-based game having a virtual world geography that is parallel to at least a portion of the real world geography, such that player movement and actions in the real world affect actions in the virtual world. However, the subject matter of this disclosure may be equally applicable to other location-based applications, such as, for example, other types of games or interactive applications.

[0011] FIG. 1 is a block diagram illustrating one embodiment of a computing environment for a location-based gaming system 100. In the embodiment shown, the location-based gaming system 100 provides for multiple player interaction in a virtual world having a geography that is parallel to the real world. In particular, geographical regions in the real world can be directly linked or mapped to corresponding regions in the virtual world. Players can move around in the virtual world by moving relative to various geographical locations in the real world. As an example, the system 100 can track the position of a player in the real world and update the player's position in the virtual world based on the player's current position in the real world. For example, a coordinate system in the real world (e.g., longitude and latitude) may be mapped to a coordinate system in the virtual world (x / y coordinates, virtual longitude and virtual latitude, etc.).

[0012] 1, system 100 has a client-server architecture, with a game server 110 in communication with one or more client devices 120 over a network 130. Although three client devices 120 are illustrated in FIG. 1, any number of client devices 120 can be connected to game server 110 over network 130. In other embodiments, a distributed location-based gaming system 100 includes different or additional elements. Moreover, functionality may be distributed among the elements differently than described.

[0013] The game server 110 hosts the overall context of the location-based game and provides game state updates to the player's client device 120 (e.g., based on actions taken by other players in the game, changes in the real-world surroundings, changes in the game situation or conditions, etc.). The game server 110 receives and processes input from players in the location-based game. Players may be identified by a username or player ID (e.g., a unique number or alphanumeric string) that the player's client device 120 combines with the player's input and sends to the game server 110. In some aspects, a game server hosts multiple location-based games, other types of games, or other applications.

[0014] In various aspects, the game server 110 processes game actions based on the client devices 120 detecting each other in the real world. The game server 110 receives information from a client device 120 indicating that the client device 120 (e.g., client device 120A) has come into proximity with another client device (e.g., client device 120B). In particular, the information identifies one or more players associated with the relevant client device 120, such as, for example, the player's username or ID or device ID. Proximity detection is described in more detail below with respect to the client device 120 and FIG. 2. Additionally, the game server 110 performs various game actions based on information describing the information received from the client device 120 representing detection of another client device 120. Game actions based on device proximity detection and various aspects of the game server 110 are described in more detail below with respect to FIG. 3.

[0015] Client devices 120 are computing devices through which players can interact with game server 110. By way of example, client devices 120 can be smartphones, portable gaming devices, tablets, personal digital assistants (PDAs), mobile phones, navigation systems, handheld GPS systems, or other devices. Although only three client devices are depicted in FIG. 1 (i.e., client devices 120A, 120B, 120C), location-based game system 100 may include any number of client devices 120. Client devices 120 execute software associated with location-based games hosted by server 110, such as, for example, client game applications, and enable players to interact with the virtual world. Additionally, client devices 120 may include hardware, software, or both for providing a user interface for chat rooms. Client devices 120 are configured to detect other client devices 120 when the devices are in close proximity to each other in the physical world (i.e., device proximity detection). In aspects, client device 120 performs proximity detection using a personal area network (PAN) device and associated communication protocols (e.g., Bluetooth, ZigBee, infrared, ultra-wideband, near-field communication, Wi-Fi Direct, etc.). Client device 120 may store information representative of detection of other client devices 120 in the physically applicable world (e.g., a player identifier associated with a user of the detected client device or a device identifier associated with the detected client device). Client device 120 may provide the stored information corresponding to the detection to game server 110. Various aspects of client device 120 are described in more detail below with respect to FIG. 2.

[0016] The distance range within which a client device 120 can perform proximity detection of another client device 120 may vary depending on the technique or device used. If the client device 120 uses a PAN device for proximity detection as described above, the distance range for proximity detection is the range within which a particular PAN device can detect another PAN device. For example, in the case of Bluetooth LE (Bluetooth Low Energy), a Bluetooth LE device can detect or connect to other Bluetooth LE devices within a range of approximately 60 meters. As another example, in the case of Wi-Fi Direct, a Wi-Fi Direct device can detect or connect to other Wi-Fi Direct devices within a range of approximately 100 meters. In the same or different embodiment, the client device 120 may perform proximity detection of other client devices 120 using other devices or techniques. As an example, the client device 120 may use the geographic coordinates of the client device 120 determined using the GPS receiver of the client device 120. In the case just described, the distance range for proximity detection may be an established threshold distance (e.g., 20 meters). As another example, client device 120 may connect to a local area network (LAN), such as a Wi-Fi network, and identify other devices connected to the same LAN. In the case just mentioned, the distance range for proximity detection may be the range within which client device 120 is able to connect to a particular LAN, and may be affected by the relevant software and hardware providing the LAN (e.g., the type of wireless LAN router used).

[0017] The network 130 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 some combination thereof. The network can also include a direct connection between the client 120 and the game server 110. In general, communication between the game server 110 and the client 120 can be via a network interface using any type of wired and / or wireless connection, using a variety of communication protocols (e.g., TCP / IP, HTTP, S1v1TP, FTP), encodings or formats (e.g., HTML, JSON, XML), and / or protection schemes (e.g., VPN, Secure HTTP, SSL).

[0018] FIG. 2 is a block diagram of one embodiment of the client device 120A shown in FIG. 1. The client device 120A is associated with a player of the parallel reality game. Other client devices (e.g., client devices 120B, 120C) have the same or similar architecture and are associated with other players of the parallel reality game. Because the gaming system 100 is a location-based gaming system, the client device 120 is preferably a portable computing device that the player can easily carry or otherwise transport, such as, for example, a smartphone or other portable device. The player can interact with the virtual world simply by carrying or transporting their client device 120 in the real world. In the embodiment shown, the client device 120A includes a device proximity module 210, a game module 220, a user interface module 230, a device detection data store 240, and a local data store 250. In other embodiments, the client device 120A includes additional or different components compared to the components depicted in FIG. 2.

[0019] The device proximity module 210 detects other client devices 120 that come within proximity of the client device 120A (i.e., player device) associated with a player of a location-based game when the player moves around with the client device 120A in the real world. In some aspects, the device proximity module 210 includes a PAN device. In the aspects just described, the PAN device broadcasts information representing the broadcast client device 120 or a player associated with the broadcast client device 120, for example, so that another client device 120 within the proximity of the broadcast client device 120 can receive the broadcast information. Moreover, the PAN device includes a scanner that identifies information broadcast by the PAN device of other client devices 120. For example, if the PAN device is a Bluetooth LE device, the Bluetooth LE device may continuously broadcast advertisement data packets using more than one channel, the advertisement data packets including a universally unique identifier (UUID) corresponding to the Bluetooth LE device and a message including an identifier of the player (e.g., a player ID or a user name). A Bluetooth LE device may periodically or continuously listen to one or more channels used to broadcast advertisement data packets, as described above.

[0020] In the same or a different embodiment, after another client device 120 is detected, the device proximity module 210 stores information representative of the detection in the device detection data store 240. In particular, the device proximity module 210 stores information identifying the player received by the PAN device or other contextual information, such as, for example, a timestamp indicating when the detection occurred. The device proximity module 210 provides information corresponding to the device detection to the game module 220. In an alternative embodiment, the device proximity module 210 provides information corresponding to the device detection directly to the game server 110.

[0021] In some aspects, the device proximity module 210 verifies that a particular device proximity detection meets one or more criteria before storing information representative of the device proximity detection in the device detection data store 240 or before providing the information to the game module 220. For example, the device proximity module 210 may verify the device proximity detection based on criteria corresponding to the time of the device proximity detection, the geographic location of the device proximity detection, the player associated with the detected device, or other contextual information. In one aspect, the device proximity module 210 verifies that the detected client device 120 or a player associated with the detected client device 120 has not been detected within a previous time interval (e.g., the previous hour, the previous day, the previous week, etc.). For example, a location-based game may take a game action based on the proximity detection of the same client device 120 only once per time interval. In this manner, the location-based game may prevent multiple or frequent game actions for two players whose client devices 120 are at the same physical location for a period of time or who otherwise detect each other multiple times in a time interval. By verifying that a device proximity detection satisfies one or more criteria, the device proximity module 120 prevents duplicate storage of proximity detections that would not result in additional game actions after being provided to the game server 110. In an alternative embodiment, the device proximity module 210 stores information representative of all device proximity detections, which are instead verified by the game module 220 or the game server 110 based on one or more criteria as described above.

[0022] The device proximity module 210 can enable range extension of proximity detection. The enhanced range can be a distance between two devices that is greater than the local network or PAN broadcast range. For example, the Bluetooth® LE network range of a device may be approximately a 60 meter radius, and another device 110 meters away may not be within the detectable range of the device's Bluetooth® network range. The device proximity module 210 enables range extension that allows the other device to be within the proximity of the device. To enable range extension, the device proximity module 210 can detect another device (e.g., device 120B) that is within the network broadcast range (e.g., local network or PAN). Through data exchange with client device 120B, the device proximity module 210 can determine the presence of yet another device (e.g., device 120C) that is within the network broadcast range of client device 120B but not within the network broadcast range of client device 120A. In the example just described, client device 120C is within the enhanced range of client device 120A. Additionally, the device proximity module 210 determines that the client devices 120A, 120B, 120C are in proximity to one another.

[0023] The enhanced range may be a distance that is a multiple of the range of the broadcast network. For example, two devices may be within Bluetooth range (e.g., 60 meters) of each other, and a third device may be 60 meters away from one device but 120 meters away from another device (e.g., in a configuration similar to that shown in FIG. 4). Further following the example just described, the devices may be within 180 meters of each other but within enhanced range of each other, and a fourth device may be within 60 meters of the third device but 180 meters away from the first device, but the Bluetooth advertisement of the fourth device is passed from the third device to the second device, which in turn is passed to the first device, and the first device determines that the fourth device is within enhanced proximity. The maximum distance of the enhanced range may be preconfigured or dynamically adjusted based on a threshold number of players detected to be within enhanced range of each other. For example, the enhanced proximity range may be increased until at least a threshold number of devices are within enhanced proximity range or until a maximum enhanced range is reached, thus players in more sparsely populated areas may have a larger enhanced range than players in more densely populated areas.

[0024] In some aspects, the client device 120A may receive proximity information of another device and determine that the other device is outside of the enhanced range and is not in proximity. For example, the client device may annotate the proximity information passed from device to device with a number indicating how many hops the data has made from device to device (e.g., the device increments the number it receives before passing it on to another device). The client device may use the maximum hop count to determine that the device is located farther than the enhanced range (e.g., a maximum enhanced range of 30 meters may equal a maximum hop count of 3).

[0025] The device proximity module 210 may communicate with proximate devices to determine whether the devices are within an enhanced range, and may also be referred to as enhanced proximity. Continuing with the previous example, the device proximity module 210 may receive data from client device 120B indicating that client device 120C is within its network broadcast range (e.g., after the device proximity module of client device 120B determines which devices are within the proximity of client device 120B). After receiving the data from client device 120B, the device proximity module 210 may determine whether client device 120C is already within the network broadcast range of client device 120A. If client device 120C is not already within the network broadcast range, the device proximity module 210 may add a record that client device 120C is within the enhanced range of client device 120A.

[0026] The device proximity module 210 may broadcast information about the client device 120A or devices within the proximity of the client device 120A to other devices. The device proximity module 210 may broadcast a list of devices within the proximity of the client device 120A. In some aspects, the list may include devices within enhanced or non-enhanced proximity (e.g., within Bluetooth broadcast range). The client device may automatically determine whether to broadcast a list of devices within enhanced or non-enhanced proximity depending on the number of players within the non-enhanced proximity. For example, in a crowded area where the number of players within Bluetooth broadcast range is more than a threshold number, the client device may decide to limit the list of devices within the non-enhanced proximity (e.g., to prioritize multiplayer activity with players in the immediate vicinity). In a sparsely populated area (e.g., a rural area) where the number of players within Bluetooth broadcast range is less than a threshold number, the client device may decide to share a list of devices within enhanced proximity.

[0027] The device proximity module 210 may determine the likelihood that another client device is within the proximity of the client device 120A. The device proximity module 210 may determine the likelihood using information provided in a broadcast message (e.g., a Bluetooth LE advertisement) transmitted from a nearby device. The information may include a timestamp when the advertisement was generated, a hardware identifier of the device generating the advertisement, the type of device, the manufacturer of the device, device motion data (e.g., accelerometer data), device capabilities, or any other suitable information about the device or broadcast metadata. The device proximity module 210 may use information provided in a message generated by a location-based gaming application that includes information related to the game. For example, the device proximity module of a nearby client device may generate a message that includes a player identifier and the player's willingness to participate or not participate in a multiplayer activity with the nearby player. The generated message may then be transmitted to the nearby device via a local area network or a personal area network.

[0028] The device proximity module 210 may receive data indicating that another client device has detected one or more other client devices within a proximity or proximity enhancement range. In some aspects, the device proximity module 210 may receive a first timestamp of a first broadcast message generated by a first client device and a second timestamp of a second broadcast message generated by a second client device. The timestamps may indicate when the respective broadcast messages were generated or transmitted. The broadcast messages may be local broadcast messages or personal area network broadcast messages. The device proximity module 210 may compare the first and second timestamps. In response to determining that the first timestamp is within a threshold time of the second timestamp, the device proximity module 210 may determine that the second client device is within a proximity or enhanced proximity range of the first client device.

[0029] The device proximity module 210 may use the broadcast message data and a model (e.g., a rule-based model, a machine learning model, a statistical model, or any suitable predictive algorithm) to determine the likelihood that devices are in proximity to each other. In one example, the device proximity module 210 applies a machine learning model trained with broadcast message data of two or more devices labeled with whether the two or more devices were in proximity to each other. The device proximity module 210 may represent the broadcast message data as a feature vector, where the dimensions of the feature vector correspond to the independent data provided in the broadcast message (e.g., timestamp, device type, accelerometer data). Thus, the machine learning model may be trained to determine that the likelihood that two devices with substantially similar timestamps but broadcasting messages where one device is moving at 10 kilometers per hour while the other device is stationary is in proximity to each other is less than 10 percent.

[0030] In some aspects, the game server 110 uses information that client devices transmit to the game server 110 to facilitate device proximity detection. For example, the client device 120A may transmit broadcast messages received from nearby devices to the game server 110. The game server 110 may then use the contents of the messages to determine the likelihood that the devices are in proximity to one another. In one example, the game server 110 receives broadcast messages from multiple client devices and uses the timestamps of the broadcast messages and the player identifiers provided in the broadcast messages to determine that the devices were in proximity to one another and transmits instructions to each client device to initiate an action (e.g., an in-game item trade). To determine that the devices were indeed in proximity to one another, the game server 110 may determine that the timestamps describe a substantially similar time (e.g., within one minute of each other). However, in response to determining that the timestamps do not describe a substantially similar time (e.g., more than one minute of each other), the game server 110 may determine that the devices were not in proximity to one another.

[0031] In a first example of determining that devices are not in proximity to each other based on timestamps, a client device or game server receives local or personal area network broadcast messages from two or more client devices. A device proximity module hosted on the client device may make the determination just described. The client device or game server compares the timestamps of the broadcast messages (e.g., comparing when the broadcast messages were generated or sent). In response to determining that the timestamps are within a threshold time range or threshold time duration (e.g., the time difference between the earliest and latest timestamps is less than one minute), the client device or game server determines that the devices associated with the compared timestamps were within proximity of each other. The client device or game server may then notify the client device associated with the compared timestamps of the determination that the devices were within proximity of each other (e.g., a message listing a device identifier or player identifier and a binary flag indicating that the devices were within proximity or enhanced proximity of each other).

[0032] In a second example of determining that devices are not in proximity to one another based on timestamps, a player's client device receives a Bluetooth advertisement for another device that was at the player's current location 10 minutes ago but has since moved away, but the advertisement was still being communicated by the remaining local devices that maintain a list of devices that were determined to be in proximity at one point in time. In the example just described, the player's client device, or a game server that has been forwarded the broadcast information from the player's client device, may determine that the timestamp indicating that the advertisement was broadcast 10 minutes ago has exceeded a threshold time duration of 1 minute since the broadcast and that the other device is no longer within proximity.

[0033] The game module 220 operates a client-side game application of a parallel reality game hosted by the game server 110. In an embodiment, the game module 220 communicates information about the virtual world, such as display content associated with the virtual world, with the user interface module 230. The game module 220 also receives or retrieves game data from the game server 110. For example, the game module 220 may receive game data from the game server 110 representing available game content (e.g., game items) based on the location of the client device 120, the geographic locations of devices associated with other players, or upcoming community events (e.g., competitive tournaments). In the same or different embodiment, the game module 220 transmits information to the game server 110 representative of device proximity detections made by the device proximity module 210 or stored in the device detection data store 240. In the presently described case, the game module 220 receives or retrieves game data representative of one or more game actions from the game server 110 based on the information representative of device proximity detections provided by the game module 220 to the game server 110. Game actions based on device detection are described in more detail below with respect to FIG.

[0034] In some aspects, the game module 220 transmits information representative of device detections to the game server 210 based on the occurrence of an event. For example, if the game module 220 is disconnected from the game server 110 (e.g., when the client device 120 is not connected to the Internet), the device proximity module 210 may store information representative of any device detections that occurred during the time period during which the game module 220 was disconnected. In the case just described, after the game module 220 reconnects to the game server 110 (e.g., via the network 130), the game module 220 may transmit some or all of the device detections that occurred during the time period. As another example, the game module 220 may transmit information representative of one or more device proximity detections in response to a user interaction with the client device 120, such as, for example, a user launching or resuming a client game application associated with a location-based game hosted by the game server 110. As yet another example, a player associated with the client device 120 may manually indicate a desire to provide the stored device detections through a user interaction with the client device 120. In the same or a different embodiment, the game module 220 provides information representing one or more stored device detections to the game server 110 periodically, for example at predefined time intervals (e.g., every minute).

[0035] The client-side game application operated by the game module 220 may include a multiplayer activity (e.g., an AR activity). The game module 220 may receive game data from the game server 110, including data for providing the multiplayer activity at the client device 120A. For example, the game data for the multiplayer activity may include AR objects, game actions based on the number of participating players or the proximity of the players, reward objects for completing the multiplayer activity, special effects for rendering the environment of the multiplayer activity, and the like. The game module 220 may receive data for providing the multiplayer activity while the client device 120A is connected to the game server 110, and when the client device 120A is not able to maintain a network connection with the game server 110, the game module 220 may still provide the multiplayer activity to the client device 120A (e.g., in an offline mode of a location-based game). The game module 220 may provide the multiplayer activity to the client device 120A in response to receiving a user input indicating that the user is requesting to participate in the multiplayer activity.

[0036] In an offline mode of location-based gaming (e.g., client device 120A is not connected to game server 110 via network 130), game module 220 may use a local network or PAN to communicate data between game modules of other client devices to facilitate offline gameplay. For example, game module 220 may use Bluetooth to transmit player data (e.g., avatar appearance, gameplay statistics, gameplay inventory, etc.) to a game module of another client device, which may display the player data via a user interface module of the other client device. Game module 220 may upload game data generated at client device 120A during offline gameplay to game server 110 when client device 120A is online again (e.g., connected to game server 110 via network 130).

[0037] The game data communicated by the game module 220 may include player state information indicating availability of participating in multiplayer activity. The state information may indicate that the player does not want to participate in the multiplayer activity, wants to participate, is currently participating and able to accept additional players, is participating and not able to accept additional players, or any appropriate state that would enable another game module to facilitate multiplayer activity between two or more players. After the device proximity module 210 determines that another client device is or was within proximity of client device 120A, the game module 220 may request state information of the other client device and begin facilitating the multiplayer activity depending on the received state information.

[0038] In one example of coordinating a multiplayer activity, client device 120A is offline from game server 110 and is currently within Bluetooth range of client device 120B as determined by device proximity module 210. Game module 220 sends a request for state information to client device 120B. Game module 220 uses the received state information to determine that client device 120B is not currently participating in the multiplayer activity, but that a corresponding player may wish to participate. In response, game module 220 sends an invitation for the multiplayer activity to client device 120B, the invitation serving as a request for availability of the multiplayer activity to participate players of client devices 120A, 120B. If the player using client device 120B accepts the invitation, game module 220 determines that the multiplayer activity is indeed available and provides the multiplayer activity to at least the player of client device 120A (e.g., game module 220 may also send game data for the multiplayer activity to client device 120B).

[0039] In another example of coordinating a multiplayer activity, client device 120A is currently online but was offline when the device proximity module 210 detected that it was within proximity of client device 120B. Moreover, the player was not involved in a location-based game at an earlier time (e.g., client device 120A was in a backpack, or the player was watching a movie downloaded to his device rather than playing a location-based game). At the earlier time, the game module 220 requests state information from client device 120B, and the state information indicates that client device 120B is currently participating in a multiplayer activity (e.g., with client device 120C) and is accepting additional players. Because the player at client device 120A was not involved in a location-based game at an earlier time, the player does not participate in the multiplayer activity in real time. However, the game module 220 may record an identifier for the multiplayer activity or other suitable metadata for the multiplayer activity (e.g., a timestamp, a location, identifiers of the players involved in the multiplayer activity, etc.) for future access to the game data for the multiplayer activity once the client device 120A is back online and is able to download the game data from the game server 110.

[0040] Alternatively or additionally, the game module 220 may download game data for the multiplayer activity from the client device 120B while in proximity with the client device 120B. At this time, the game module 220 provides a notification to the player that the multiplayer activity is now available. For example, the game module 220 may treat the real players as non-player characters and regenerate the gameplay as if the player of the client device 120A had participated in the live gameplay. When the devices are within proximity of each other, the devices may exchange game data related to the multiplayer activity (e.g., player identifiers, information such as damage statistics for game items available to the other players, or other suitable information to facilitate the multiplayer activity). The client device may query the game server 110 for additional data regarding the remaining players associated with the proximate devices (e.g., when the connection to the network 130 is restored). For example, the client device 120A may use a player identifier associated with the player of the client device 120B to query the game server 110 for a history of actions taken by the player of the client device 120B during the multiplayer activity. The game data received when the devices were in proximity to one another, the additional game data queried from the game server 110, or a combination of both may be used by the game module 220 to recreate or simulate gameplay for the remaining players, regardless of the current proximity of client device 120A to other client devices. For example, the game module 220 may use geofencing associated with points of interest (e.g., landmarks or other geographic locations) to determine one or more players for which to recreate or simulate gameplay.In response to the player selecting the notification indicating an interest in participating in the multiplayer activity, the game module 220 provides the multiplayer activity to the player (eg, on the display of the client device 120A).

[0041] The user interface module 230 of the client device 120 constructs and displays components of the user interface of the client device 120. In some aspects, the user interface may display to the user a representation of the virtual world including components of the virtual world, such as virtual elements and virtual experiences, that have been received from the game module 220. Additionally, the user interface module 230 may display chat room locations in the virtual world, as well as messages sent between users in the chat rooms. Users may interact with the client device 120 to engage with virtual elements, participate in virtual experiences, or converse in chat rooms. For example, the user interface module 230 may display views of the virtual world depicting points of interest, chat rooms, and other virtual experiences. Users of the client device 120 may interact with the just-mentioned components through the user interface to complete tasks, join chat rooms, or participate in competitions, among other actions.

[0042] In some aspects, the user interface module 230 provides a user interface related to proximity detection of one or more other client devices 120. For example, the user interface module 230 may display a notification that another client device 120 has been detected and information related to the detection, such as, for example, the player ID of a player associated with the detected device or the time the detection occurred. In the same or a different aspect, the user interface module 230 provides elements that allow a user of the client device 120 to determine what to do based on the proximity detection of the other client device. For example, the user interface module 230 may provide a user interface that includes elements for adjusting proximity detection preferences (e.g., enabling or disabling device proximity detection), initiating transmission of information representative of device proximity detection stored in the device detection data store 240, reviewing device proximity detections stored in the device detection data store 240, or selecting from possible game actions based on the proximity detection. In particular, the user interface module 230 may provide an interface that includes an element for initiating proximity detection, such as, for example, a "find other players" element (e.g., a button).

[0043] The user interface module 230 may provide user input for participating in a multiplayer activity with client devices proximate to the client device 120A. The user interface module 230 may provide a notification of an available multiplayer activity, and the notification may include game data representing the activity or players arranged to participate in the activity. The notification may be a push notification provided at the client device 120A when the client device 120A is not running a location-based application. For example, the notification may appear in a notification bar on the user's smartphone. As another example, the user interface module 230 causes a push notification pop-up to appear on top of other applications running at the client device 120A. The user may select the push notification to cause the client device 120A to launch the location-based application and participate in the multiplayer activity. The notification may be an invitation to join the multiplayer activity. The notification may be displayed by the user interface module 230 in response to the device proximity module 210 detecting another device within range of the client device 120A and in response to the game module 220 determining that status information received from the other device indicates that the other player wishes to join the multiplayer activity. The user interface module 230 may receive user input selecting the displayed notification (e.g., a "Join Now" button on the displayed notification). In response to receiving the user input, the game module 220 may provide the multiplayer activity.

[0044] The device detection data store local data store 240 is one or more computer-readable media configured to store information representative of a device proximity detection by a client device 120. The information stored by the device detection data store 240 may be received from the client device 120 or otherwise obtained or determined by the game server 110. In an embodiment, the device detection data store 240 stores at least an identifier of a player associated with a device detected based on a device proximity detection. The device detection data store 240 may further store contextual information representative of a device proximity detection, such as, for example, a timestamp indicating when the device proximity detection occurred, or a geographic location (e.g., GPS coordinates) indicating where the device proximity detection occurred. In some embodiments in which the game server 110 hosts multiple games, the device detection data store 240 stores information representative of one or more games (e.g., game name or identifier) ​​corresponding to a given device proximity detection. In further aspects, the device detection data store 240 stores security information to prevent inaccurate or fraudulent proximity detections, the period of time during which a proximity detection occurred (e.g., the amount of time another device was detected), or other information describing the player or device involved in the proximity detection.

[0045] The local data store 250 is one or more computer-readable media configured to store data used by the client device 120. For example, the local data store 250 may store player location information tracked by the positioning device 210, a local copy of the current situation of a parallel reality game, or any other suitable data. Additionally, the local data store 250 may store player settings or preferences, such as preferences to join a multiplayer activity, and can be used by a game module to determine whether a multiplayer activity should be facilitated between two devices in close proximity. Although the local data store 250 is shown as a single entity, the data may be distributed across multiple media. Moreover, the data may be stored elsewhere (e.g., in a distributed database) and accessed remotely via the network 130.

[0046] 3 illustrates one embodiment of a game server 110 hosting a location-based parallel reality game. In the embodiment shown, the game server 110 includes a universal game module 310, a game actions module 320, and a game database 330. In other embodiments, the game server 110 includes different or additional elements. Furthermore, functionality may be distributed among the elements differently than described.

[0047] The game server 110 may be configured to receive requests for game data from one or more client devices 120 (e.g., via remote procedure calls (RPCs)) and respond to those requests over the network 130. By way of example, the game server 110 may encode the game data into one or more data files and provide the data files to the client devices 120. Additionally, the game server 110 may be configured to receive game data (e.g., player locations, player activities, player inputs, etc.) from one or more client devices 120 over the network 130. By way of example, the client devices 120 may be configured to periodically send player inputs, player locations, and other updates to the game server 110 that the game server 110 uses to update the game data in the game database 330 to reflect changed circumstances for the game. Additionally, the game server 110 may send game data for the client devices 120, such as, for example, other player locations, chat room locations, or virtual element locations.

[0048] The universal game module 310 hosts the location-based game for the players and acts as an authoritative source for the current state of the location-based game. The universal game module 310 receives game data (e.g., player input, player location, player activity, player state, landmark information, etc.) from the client devices 120 and incorporates the received game data into the overall location-based game for all players of the location-based game. The game data allows the universal game module 310 to store an overall game state of the game that can be sent to the client devices 120 to update the local game state at the game module 220. Additionally, the universal game module 310 can manage the distribution of game data to the client devices 120 over the network 130.

[0049] The game action module 320 can be part of the universal game module 310 or can be separate from the universal game module 310. Additionally, the game action module may also be generally referred to as an application action module (e.g., for applications for fitness or social networking that do not need to facilitate gaming and do not need to exchange game data). The game action module 320 is configured to perform game actions based on a proximity detection performed by the client device 120. The game action module 320 receives information representative of the proximity detection from the client device 120. Using the received proximity detection information, the game action module 320 performs game actions that create, modify, or otherwise process game data. The game action module 220 can provide game data to the client device 120 based on the performed game actions, such as the client device 120 providing the proximity detection information to the game action module 320 resulting in a game action. For example, the game action module 320 performs game actions to process game data corresponding to a player of a location-based game (e.g., associated with a player's profile or account), such as any combination of the game data (e.g., game data types (1)-(9)) described below with reference to the game database 330. As an example, if a client device 120 associated with player A detects another client device 120 associated with player B, the game action module 320 may modify the player profile of player A or player B based on the game actions.

[0050] In some aspects, the game action module 320 communicates with the universal game module 310 to perform game actions. For example, the game action module 320 may communicate with the universal game module 310 to determine what game actions can be performed based on the received proximity detection information or other context information (e.g., a current time or game features). In the same or a different aspect, the game action module 320 provides information to the client device 120 representative of one or more game actions performed, such as, for example, information representative of processing performed on game data corresponding to the one or more game actions. The information representative of the one or more game actions performed may include, for example, a notification for display at the client device 120, such as a notification indicating the game action that occurred or a notification representative of the game action.

[0051] In various aspects, the game action module 320 performs game actions to process game data of one or both players corresponding to the device proximity detection. In some aspects, the game action module 320 performs game actions for the player associated with the client device 120 (i.e., the detection device) that provided information representative of the proximity detection. For example, if client device 120A provided information representative of device proximity detection of client device 120B, the game action module 320 could perform game actions that affect game data of the player associated with client device 120A. Such game actions may include the game action module 320 providing game items as rewards to the player, providing game experience points to the player (e.g., leveling up a game character associated with the player), encouraging the player to send a friend request to the other player, or other game actions specific to the player. As another example of game actions performed by the game action module 320 in response to proximity detection provided by the client device 120, the game action module 320 may provide notifications of multiplayer activity to client devices detected to be within proximity of each other. If both users select the notification and indicate a desire to participate in the multiplayer activity, the game actions module 320 may offer the multiplayer activity to the proximate client devices.

[0052] In the same or a different embodiment, the game action module 320 performs game actions that process game data of a player associated with the detected device (e.g., client device 120B in the previous example). The game action module 320 may perform game actions for a player associated with the same or different detected device as performed for the player associated with the detecting device. In still the same or a different embodiment, the game action module 320 performs game actions that process game data of both the player associated with the detecting device and the player associated with the detecting device (e.g., both client device 120A and client device 120B in the above example). Game actions performed by the game action module 320 that affect the game data of both players may include exchanging game elements (e.g., game items, images, messages, game state, etc.) between the players, providing game elements from one player to the other player, initiating an in-game event (e.g., a battle) for both players, adding one player to an existing augmented reality experience in which the other player is already engaged, updating an in-game map associated with one or both players, or providing information representing the opposing player to establish a connection between the players.

[0053] In some aspects, the game action module 320 determines one or more game actions to take based on whether the game action module 320 receives information indicative of device proximity detection from both client devices 120 involved in the proximity detection. For example, if the game action module receives information indicative of detection of client device 120B from client device 120A, the game action module 320 may determine one or more game actions to take based on whether it also receives information indicative of detection of client device 120A from client device 120B. In other aspects, the game action module 320 determines one or more game actions to take based on device proximity detection information received from a single client device 120.

[0054] In some aspects, the game action taken by the game action module 320 is an exchange of game items (i.e., trading game items) between two players of a location-based game. For example, in response to receiving information representative of proximity detection between a first player and a second player, the game action module 320 can obtain one or more game items associated with the first player to trade for one or more game items associated with the second player. In one aspect, a player can specify one or more game items (e.g., game items associated with a player profile or account) that the player desires to trade with the other player. As an example, a player may select from a set of game items collected by playing a location-based game that will be added to a group of game items that can be traded with other players when device proximity detection occurs. The selection may be made by the player using a client device 120 associated with the player or another device (e.g., a laptop or desktop computer) that can communicate with the game server 110. The game action module 320 can then execute a trade between the two players when one or both of the two players' associated client devices 120 detect the other's device in the real world, as indicated by the received device proximity detection information. For example, if client device 120A detects client device 120B, the game action module 320 can exchange one or more game items for the player associated with client device 120A and the player associated with game client device 120B. When exchanging game items, the game action module 320 updates the game data in the game database 330.The game actions module 320 may additionally or alternatively communicate with the universal game module 310 to effectuate the game item trade or to communicate that a game item trade has occurred. In aspects, the game actions module 320 provides a notification for display to one or both of the client devices 120 that participated in the trade of game items indicating the trade that has occurred or providing details of the trade. In various aspects, the game action module 320 performs additional processing to execute a game item trade. In one aspect, the game action module 320 determines or identifies a value associated with a game item designated for trade by a player corresponding to the device proximity detection. The value of the game item may correspond to a characteristic of the game item, the price of the game item in real or in-game currency, other indicators of game item value, or a combination thereof. The game action module 320 uses the value of the game item to select and trade one or more game items of each player corresponding to the device proximity detection. For example, the game action module 320 may exchange game items having the same value or a difference in value within a trade threshold. Other examples of information that the game action module 320 may consider when executing a trade between players include associations between players in a location-based game (e.g., players are friends, both are associated with an in-game organization, such as a team, etc.), or characteristics of the game item (e.g., type of game item).

[0055] Game database 330 includes one or more machine-readable media configured to store game data used in a location-based game served or provided to client devices 120 over network 130. In an embodiment, the game data stored in game database 330 may include (1) data associated with a 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 a player of a location-based game, such as, for example, player profile or account data (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., current game objectives, game objective state, past game objectives, future game objectives, desired game objectives, etc.), and (4) data associated with a game objective (e.g., game objectives associated with a game objective, game objective status ... (4) data related to virtual elements in the virtual world (e.g., location of virtual elements, type of virtual element, game objectives associated with virtual elements, real-world location information corresponding to virtual elements, behavior of virtual elements, relevance of virtual elements, etc.); (5) data associated with real-world objects, landmarks, and locations linked to virtual world elements (e.g., location of real-world objects / landmarks, description of real-world objects / landmarks, relevance of virtual elements linked to real-world objects, etc.); (6) game state (current number of players, current state of game objectives, player leaderboards, etc.); (7) data associated with player activities / input (e.g., current player location, past player locations, player movement, player input, player queries, player communications, etc.); (8) data associated with the virtual experience (e.g.,The game data stored in the game database 330 may include the location of the virtual experience, player activities related to the virtual experience, e.g., virtual events such as raids, and (9) other data used, related to, or obtained during the implementation of the location-based game. The game data stored in the game database 330 may be entered either offline or in real-time by a system administrator, or by data received from a player, such as from one or more client devices l20 over the network 130.

[0056] Additionally, the game database 330 may store real-world data. The real-world data may include population density data representing the collective locations of individuals in the real world, player density data representing the collective locations of players in the real world, player actions associated with locations of cultural or commercial value, player heatmap data representing the distribution of game actions in geographical areas, point of interest data representing real-world locations corresponding to locations of virtual elements in the virtual world, terrain data representing locations of various landforms and ecological conditions, such as large bodies of water, mountains, canyons, map data providing 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, time exercised, etc.), and other suitable data. The real-world data may be collected or obtained from any suitable source. For example, the game database 330 may be coupled to, included in, or be 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 game server 110 may be coupled to one or more external data sources or services that provide demographic data, hazard data, weather data, event calendar data, and the like.

[0057] Other modules than those shown in Figure 3 may be used by the game server 110. Any number of modules may be programmed or otherwise configured to perform the server-side functionality described herein. Additionally, various components of the server-side may be rearranged. Other configurations will be apparent in light of this disclosure, and this disclosure is not intended to be limited to any particular configuration.

[0058] FIG. 4 is a conceptual example of an approach to extending the range of device proximity detection according to one embodiment. The conceptual example includes an environment in which client devices 120A, 120C are in close proximity to each other through enhanced range. Client devices 120A-120C have network broadcast ranges 400, 410, 420, respectively. Broadcast ranges 400, 410, 420 may be a Bluetooth LE broadcast range of approximately 60 meters. Thus, each circle of broadcast range may have a radius of 60 meters. Client device 120A and client device 120B may be less than 60 meters away from each other, and a device proximity module of each device may determine that the two devices are within proximity of each other using a short-range, local connection 430. Similarly, client device 120B and client device 120C may be within 10 meters of each other and determine that the two devices are in close proximity to each other using a connection 440. However, client devices 120A, 120C are outside of broadcast range from each other, and the device proximity module of each device may initially determine that the two devices are not within proximity of each other, unable to establish a short-range local connection. However, the device proximity module of either device 120A or device 120C may determine that client device 120B is in proximity to the other device, and therefore that the other device is within enhanced range and indeed in proximity. Client devices 120A, 120C may form a connection 450 that can be facilitated by client device 120B. The device proximity module may request information of nearby devices from client device 120B. For example, client device 120A receives a player identifier of a player using client device 120C from client device 120B.

[0059] Device Proximity Detection Method 5 is a flow chart illustrating one embodiment of a method 500 for device proximity detection. In the embodiment shown, the steps of FIG. 5 are illustrated from a perspective client device 120 performing the method 500. However, some or all of the steps may be performed by other entities or components. Additionally, some embodiments may perform different steps or perform some of the steps in a different order or in parallel.

[0060] In the embodiment shown in FIG. 5, the method 500 begins with a first client device (e.g., client device 120A) scanning 510 the PAN of other client devices. For example, the first client device may use a scanner of the PAN device to scan for information broadcast by the PAN devices of the other client devices 120 to perform device proximity detection. Based on the scan, the first client device may receive 520 an identifier from a second client device (e.g., client device 120B) via a PAN corresponding to an application of the second client device. For example, the first client device may perform proximity detection of the second client device by receiving information broadcast by the second client device (e.g., using the device proximity module 210) including a player ID of a location-based game player associated with the second client device. The first client device stores 530 the identifier received from the second client device. For example, the first client device may store the identifier in the device detection data store 240.

[0061] The first client device provides 540 an identifier to the online system corresponding to the application. For example, the first client device may provide the identifier to the game server 110 (e.g., using the game module 220). The first client device receives 550 data for the application corresponding to actions taken by the online system based on receiving by the first client device regarding the identifier. For example, the first client device may receive game data corresponding to game actions taken by the game server 110.

[0062] 6 is a flow chart illustrating one embodiment of a method 600 for trading gaming items using device proximity detection. In the embodiment shown, the steps of FIG. 6 are illustrated from the perspective of a client device 120 performing the method 600. However, some or all of the steps may be performed by other entities or components. Additionally, some embodiments may perform different steps, or perform some of the steps in a different order or in parallel.

[0063] In the aspect shown in FIG. 6, the method 600 begins by identifying 610 a first game item of a first player of a location-based game associated with a first client device (e.g., client device 120A) that is available for trading. For example, the first player may designate one or more game items included in the first player's game data as available for trading. The first client device detects 620 a second client device associated with a second player (e.g., client device 120B) within a proximity range of the first client device. In particular, the first client device receives an identifier of the second player based on a proximity detection of the second client device. For example, the first client device may perform a proximity detection of the second client device using the device proximity module 210. The first client device stores 630 an identifier of the second player. For example, the first client device may store the player identifier in the device detection data store 240.

[0064] The first client device provides 640 the identifier to an online system hosting the location-based game. For example, the first client device may provide the identifier to the game server 110 (e.g., using the game module 220). In response, the first client device receives 650 game data from the online system indicating the exchange of the first game item with the second game item. For example, the first client device may receive a push notification from the game server 110 indicating the exchange that occurred or representing a game item received by the first player.

[0065] 7 is a flow chart illustrating an embodiment of a method 700 for coordinating multiplayer activity of devices detected to be within proximity of one another. In the embodiment shown, the steps of FIG. 7 are illustrated from the perspective of a client device 120 performing the method 700. However, some or all of the steps may be performed by other entities or components. Additionally, some embodiments may perform different steps, or perform some of the steps in a different order or in parallel.

[0066] A first client device detects 710 a second client device within proximity of the first client device. The first client device is associated with a first player and the second device is associated with a second player. For example, the first client device may be offline from a game server (e.g., game server 110) and within Bluetooth range of the second client device. A device proximity module of the first client device detects that the second client device is within Bluetooth broadcast range of the first client device and therefore within proximity.

[0067] The first client device provides 720 a notification of availability of a multiplayer activity to join the first and second players. For example, a game module of the first client device provides a notification for display on a screen of the first client device, including an invitation to join a multiplayer activity (e.g., an AR activity) with the second client device. Before providing the notification, the game module may determine that a second player is available or wants to join the multiplayer activity. The game module may send a request for state information to the second client device. The game module may then use the received state information to determine that the second client device is currently participating in a multiplayer activity (e.g., with a third client device) and is accepting additional players for the multiplayer activity. The game module may then provide 720 a notification for display on a screen of the first client device (e.g., a string representing an invitation that "Another trainer nearby is currently joining a raid with other trainers. Would you like to join?" and a user input button to accept the invitation).

[0068] The first client device receives user input indicating a selection for the notification 730. For example, a user interface module of the first client device displays the notification on the first client device along with a user input element (e.g., a button) for the user to select the notification. The user input element can be for providing an acceptance or rejection of the invitation to join the multiplayer activity.

[0069] The first client device provides 740 a location-based game multiplayer activity at the first client device. In one aspect, in response to receiving the user's approval to join the multiplayer activity, the game module of the first client device sends a request for an invitation to join the multiplayer activity to the second client device. The game module of the second client device may generate and send the requested invitation to the game module of the first client device, where the invitation may include game data for the multiplayer activity stored locally at the second client device or at a game server (e.g., the second client device is online but the first client device is not online). The game module of the first client device may provide the multiplayer activity at the first client device (e.g., via a user interface module) using the received game data.

[0070] 8 is a flow chart illustrating an embodiment of a method 800 for detecting a second client device within proximity of a first client device. Method 800 is shown as one embodiment of detecting step 710 in method 700 of FIG. 7. The steps of FIG. 8 are illustrated from the perspective of client device 120 performing method 800. However, some or all of the steps may be performed by other entities or components. Additionally, some embodiments may perform different steps or perform some of the steps in a different order or in parallel.

[0071] The first client device detects 810 a third client device within a second proximity range of the first client device. The third client device is associated with a third player. The device proximity module of the first client device may detect 810 other client devices within a proximity range of the first client device. With reference to the layout of client devices shown in FIG. 4, the client device 120A, the first client device, may detect 710 a client device 120C, the second client device, using the method 800. The client device 120A detects 810 a client device 120B, the third client device. The detection 810 may be accomplished via a local network or a PAN connection, such as Bluetooth LE.

[0072] The first client device receives 820 data indicating that the third client device has detected a second client device within a third proximity range of the third client device. The device proximity module of the first client device may receive 820 the data. The received 820 data may include broadcast information identifying the broadcasting device, the broadcast itself, or a combination thereof. Following the previous example with reference to the configuration of FIG. 4, the client device 120A may receive 820 data from the client device 120B, where the data includes or is derived from the broadcast information sent by the client device 120C to the client device 120B. The client device 120C sends data such as, for example, a device identifier, a player identifier, or a timestamp of the transmission in a broadcast message (e.g., a Bluetooth LE advertisement). The client device 120B may receive the broadcast message from the client device 120C and store data or derive additional data from the received broadcast message. For example, the client device 120B may create a record of the contents of the broadcast message and append data of the signal strength at which the broadcast message was received. Client device 120B may then provide data received from other devices regarding their proximity, such as, for example, the example records just discussed, to other devices, such as, for example, client device 120A. The first client device may receive 820 the data in response to requesting data from other client devices within the vicinity of its broadcast range. Alternatively or additionally, the first client device may receive 820 the data automatically as part of a broadcast message received from the other device announcing its presence. Similarly, the first client device may broadcast data regarding devices within its proximity to other devices.

[0073] The first client device receives data indicating that the third client device has detected a second client device within a third proximity of the third client device 820. In another example, the third client device uses a timestamp to determine that both the first and second client devices are within the proximity of the third client device, and the third client device then transmits data indicating this determination to the first client device. For example, referring to the configuration of FIG. 4, client device 120B receives local network broadcast messages (e.g., Bluetooth advertisements) from both client device 120A and client device 120C. Client device 120B then compares the timestamps of the received messages to determine whether the messages were generated or sent by the respective devices within a threshold time duration of each other (e.g., within one minute of each other). In this example, client device 120B may also have a device proximity module, a gaming module, and other components of FIG. 2 shown as hosted at client device 120A. In particular, the device proximity module described herein may be configured to perform this timestamp comparison to determine whether two or more devices are within proximity of one another.

[0074] The first client device uses the received data to determine 830 a likelihood that the second client device is within a first proximity of the first client device. A device proximity module of the first client device may make this determination. The device proximity module may compare the determined 830 likelihood to a threshold to determine whether another device is within a proximity or enhanced proximity of the first client device. The first client device may implement a statistical model, a decision tree, a machine learning model, or any other suitable algorithm to determine the likelihood that the two devices are within a proximity of each other based on the broadcasted data (e.g., a timestamp of the broadcast, a signal strength of the received broadcast, a sender of the broadcast, an author of the broadcast, etc.). Additionally, the first client device may use additional context information, such as a current location (e.g., GPS coordinates) as an input to an algorithm to determine the likelihood that the two devices are within a proximity of each other. In one example where a third client device has compared timestamps associated with broadcast messages transmitted by a first device and a second device that are within proximity of the third device, the first client device may use a received confirmation that the timestamps meet a condition indicating that the devices are in proximity (e.g., the difference between the timestamps is within a threshold time difference) to determine 830 that the likelihood that the second device is within proximity of the first device exceeds a threshold likelihood (e.g., 100% likelihood). Thus, the first client device determines 830 that the devices are indeed within proximity of each other.

[0075] In one example of determining that two devices are likely within proximity of each other, using the configuration shown in FIG. 4, client device 120A applies data received from client device 120B to a statistical model to determine that client device 120C is within proximity of client device 120A with at least a threshold likelihood. The statistical model may be generated by the first client device or by a game server (e.g., game server 110) and stored on the first client device. The first client device may use historical broadcast data received from the client device and proximity verification to create the statistical model. Examples of proximity verification include confirmation from a player confirming to the device proximity module 210 that another player is within enhanced proximity, or location information provided by the game server 110 while the device is online that confirms that the other player is within enhanced proximity. Client device 120A receives from client device 120B the timestamp of the broadcast message from client device 120C, the signal strength of the broadcast message from client device 120C, and a player identifier associated with client device 120C, and applies the received data to a statistical model. The output of the statistical model is a likelihood or score that satisfies a threshold (e.g., a preconfigured threshold) indicating that client device 120C is likely within enhanced proximity of client device 120A, as shown in FIG.

[0076] Figure 9 is a block diagram illustrating an example computer suitable for use in the network computing environment of Figure 1 according to one embodiment. Specifically, Figure 9 shows a diagrammatic representation of a machine in the example form of a computer system 900. The computer system 900 can be associated with a component (or module) of the game server 110 or the client device 120 and can be used to execute instructions 924 (e.g., program code or software) to cause the machine to perform any one or more of the methodologies (or processes) described herein, including those described.

[0077] The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a smart phone, a network router, a switch or bridge, a cell phone tower, or any machine capable of executing (serially or otherwise) instructions 924 that specify actions to be taken by the machine. Additionally, although only a single machine is shown, the term "machine" should also be taken to include any collection of machines that individually or collectively execute instructions 924 to perform any of the disclosed methods.

[0078] The exemplary computer system 900 includes one or more processing units, typically one or more processors 902. The processor 902 may be, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a controller, a state machine, one or more application specific integrated circuits (ASICs), one or more radio-frequency integrated circuits (RFICs), or any combination thereof. Any reference to a processor 902 may refer to a single processor or multiple processors. Additionally, the computer system 900 also includes a main memory 904. The computer system may include a storage unit 916. The processor 902, the memory 904, and the storage unit 916 communicate via a bus 908.

[0079] Additionally, computer system 900 may include static memory 906, a display driver 910 (e.g., for driving a plasma display panel (PDP), a liquid crystal display (LCD), or a projector). Additionally, computer system 900 may also include an alphanumeric input device 912 (e.g., a keyboard), a cursor control device 914 (e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing device), a signal generating device 918 (e.g., a speaker), and a network interface device 820, which are also configured to communicate over bus 908.

[0080] The storage unit 916 includes a machine-readable medium 922 that may store instructions 924 (e.g., software) for performing any of the methods or functions described herein. Moreover, the instructions 924 may reside, completely or partially, within the main memory 904 or within the processor 902 (e.g., within a processor's cache memory) during execution by the computer system 900. Moreover, the main memory 904 and the processor 902 also constitute machine-readable media. The instructions 924 may be transmitted or received over the network 130 via the network interface device 920.

[0081] While machine-readable medium 922 is shown in the exemplary embodiment to be a single medium, the term "machine-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) capable of storing instructions 924. Furthermore, the term "machine-readable medium" should also be taken to include any medium capable of storing instructions 924 for execution by a machine, causing the machine to perform any one or more of the methods or functions disclosed herein. The term "machine-readable medium" includes, but is not limited to, data repositories in the form of solid-state memory, optical media, and magnetic media.

[0082] Although the present subject matter has been described in detail with respect to certain exemplary embodiments and methods, it will be appreciated that those skilled in the art, upon attaining the foregoing understanding, may readily make modifications, variations, and equivalents to the above-described embodiments. Accordingly, the scope of the present disclosure is by way of example rather than limitation, and the disclosure of the subject matter does not preclude the inclusion of the above modifications, variations, or additions to the present subject matter that would be readily apparent to those skilled in the art.

[0083] Additional Considerations Some portions of the above description describe aspects in terms of algorithmic processes or operations. Typically, the algorithmic descriptions and representations just described are used by those skilled in the computing arts to effectively convey the contents of their work to others skilled in the art. While the operations just described are described functionally, computationally, or logically, it will be understood that they are implemented by computer programs that include instructions for execution by a processor or equivalent electrical circuitry, microcode, or the like. Moreover, it has also been shown that it is sometimes convenient, without loss of generality, to refer to the just described arrangements of functional operations as modules.

[0084] As used herein, any reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in this specification are not necessarily all referring to the same embodiment. Similarly, the use of "a" or "an" before an element or component is merely done for convenience. It should be understood that the description just given means that there are one or more elements or components present, unless it is clear that this is not meant.

[0085] When values ​​are described as "approximately" or "substantially" (or their derivatives), the above values ​​should be constructed as accurate to ±10%, unless another meaning is clear from the context. For example, "approximately 10" should be understood to mean "in the range of 9 to 11."

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

[0087] Upon reading this disclosure, those skilled in the art will recognize yet additional alternative structural and functional designs that may be used to utilize the techniques and approaches described. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the described subject matter is not limited to the precise structures and components disclosed. The scope of protection shall be limited only by the following claims.

Claims

1. 1. A non-transitory computer-readable medium comprising instructions that, when executed by a first client device associated with a first user of a location-based application, cause the first client device to: detecting a second client device within a proximity of the first client device, the second client device being associated with a second user of the location-based application; in response to detecting the second client device, providing a notification of availability of a multi-user activity involving the first user and the second user; receiving a user input indicating a selection for said notification; providing the multi-user activity of the location-based application in response to the user input; and A non-transitory computer-readable medium configured to cause operations including:

2. The proximity is a first proximity, and detecting, by the first client device, the second client device comprises: detecting a third client device within a second proximity of the first client device, the third client device being associated with a third player of the location-based application, the second proximity; receiving data from the third client device indicating that the second client device is within a third proximity of the third client device; 10. The non-transitory computer-readable medium of claim 1, comprising:

3. 3. The non-transitory computer-readable medium of claim 2, wherein the second proximity and the third proximity are within a personal area network broadcast range of the third client device, and the first proximity is greater than the personal area network broadcast range.

4. 10. The non-transitory computer-readable medium of claim 1, wherein detecting the second client device includes receiving an identifier of the second user over a local network.

5. 10. The non-transitory computer-readable medium of claim 1, wherein detecting the second client device includes receiving an identifier of the second user over a personal area network (PAN).

6. 6. The non-transitory computer-readable medium of claim 5, wherein the personal area network is a Bluetooth Low Energy network.

7. The second client device is detected while the first client device does not have connectivity to an online system that hosts the location-based application, and the operation includes: Detecting that the first client device has connectivity to the online system over a network; receiving an identifier of the second user via a local network or a PAN; transmitting the identifier of the second client device to the online system over the network; providing an identity of the second user to the online system by 10. The non-transitory computer-readable medium of claim 1, further comprising:

8. The operation includes: storing the identifier of the second user in response to detecting the second client device by the first client device.

8. The non-transitory computer-readable medium of claim 7, further comprising:

9. Storing the identifier of the second user includes: comparing the identifier of the second user with one or more previously stored user identifiers, the one or more previously stored user identifiers being associated with corresponding timestamps indicating when the one or more user identifiers were stored on the first client device; storing the user identifier with a current timestamp in response to determining that the identifier of the second user has not been previously stored on the client device within a time interval; 9. The non-transitory computer-readable medium of claim 8, comprising:

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

11. The second client device is detected while the first client device has connectivity to an online system that hosts the location-based application, and the operation includes: receiving, from the online system, status information indicating whether the second client device is participating in the multi-user activity during the time the second client device is detected; requesting an invitation by the first client device to join the multi-user activity in response to determining using the state information that the second client device is participating, the notification including the invitation; and requesting, by the first client device, the availability of the multi-user activity involving the first user and the second user in response to determining, using the state information, that the second client device is not participating; 10. The non-transitory computer-readable medium of claim 1, further comprising:

12. 12. The non-transitory computer-readable medium of claim 11, wherein requesting availability of the multi-user activity includes determining that the second client device has indicated a willingness to join the multi-user activity.

13. 2. The non-transitory computer-readable medium of claim 1, wherein the multi-user activity is an augmented reality (AR) activity.

14. The second client device is detected while the first client device does not have connectivity to an online system that hosts the location-based application, and the operation includes: receiving state information from the second client device indicating whether the second client device participated in the multi-user activity during a time period during which the second client device was detected; in response to determining using the state information that the second client device is participating, requesting an invitation from the second client device to join the multi-user activity, the notification including the invitation; and initiating, by the first client device, the multi-user activity involving the first user and the second user in an offline environment in response to determining using the state information that the second client device is not participating, wherein game data generated from the multi-user activity in the offline environment is stored locally at one or more of the first client device or the second client device and uploaded to the online system when the one or more of the first client device or the second client device have connectivity to the online system; 10. The non-transitory computer-readable medium of claim 1, further comprising:

15. 2. The non-transitory computer-readable medium of claim 1, wherein the notification is a push notification provided for display on a screen of the first client device.

16. 1. A non-transitory computer-readable medium comprising instructions that, when executed by a first client device associated with a first user of a location-based application, cause the first client device to: detecting a second client device within a first proximity of the first client device, the second client device being associated with a second user of the location-based application, the detecting the second client device comprising: detecting a third client device within a second proximity of the first client device, the third client device being associated with a third user of the location-based application; receiving data from the third client device indicating that the third client device has detected the second client device within a third proximity range of the third client device; using the received data to determine a likelihood that the second client device is within the first proximity of the first client device; Including A non-transitory computer-readable medium configured to cause operations including:

17. The operation includes: in response to detecting the second client device, providing a notification of availability of a multi-user activity involving the first user and the second user; receiving user input at the first client device indicating a selection for the notification; providing the multi-user activity of the location-based application at the first client device in response to the user input; and 20. The non-transitory computer readable medium of claim 16, further comprising:

18. The second client device is detected while the first client device has connectivity to an online system that hosts the location-based application, and the operation includes: receiving state information from the second client device indicating whether the second client device was participating in a multi-user activity during a time period during which the second client device was detected; in response to determining using the state information that the second client device is participating, requesting an invitation from the second client device to join the multi-user activity; initiating, by the first client device, the multi-user activity involving the first user and the second user in an offline environment in response to determining using the state information that the second client device is not participating, wherein application data generated from the multi-user activity in the offline environment is stored locally at one or more of the first client device or the second client device and uploaded to the online system when the one or more of the first client device or the second client device have connectivity to the online system; 20. The non-transitory computer readable medium of claim 16, further comprising:

19. The operation includes: sending a first broadcast message to the third client device, the first broadcast message including a first timestamp indicating when the first broadcast message was sent; Further comprising: Receiving data indicating that the third client device has detected the second client device within the third proximity range of the third client device includes: receiving a timestamp comparison result determined by the third client device, the timestamp comparison result indicating that the first timestamp is within a threshold time range of a second timestamp of a second broadcast message, the second timestamp indicating a time when the second broadcast message was transmitted by the second client device; 20. The non-transitory computer readable medium of claim 16, comprising:

20. a database for storing application data for the location-based application; detecting, by a first client device associated with a first user, a second client device within a first proximity of the first client device, the second client device being associated with a second user of the location-based application, the detecting the second client device comprising: detecting, by the first client device, a third client device within a second proximity of the first client device, the third client device being associated with a third user of the location-based application; receiving data from the third client device indicating that the third client device has detected the second client device within a third proximity range of the third client device; and Using the received data to determine a likelihood that the second client device is within the first proximity of the first client device. Including, in response to detecting the second client device, providing a notification of availability of a multi-user activity involving the first user and the second user; receiving user input at the first client device indicating a selection for the notification; providing the multi-user activity of the location-based application at the first client device in response to the user input; and an application action module configured to perform an action including: An online system comprising:

Images