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 within proximity of the client device. The detection of the other client devices may result in the occurrence of various application actions, such as triggering multi-user activity between users. Detection of a client device may be performed using a personal area network device of the client device, such as Bluetooth. When a client device is disconnected from an online system hosting a location-based application, proximity detection may occur, where the detection is later reported to the online system by one or both devices.

Description

Technical Field

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

[0002] Location-based applications use the real world as their geographic environment. Parallel reality games are a kind of location-based applications that use a virtual world parallel to the real world's geographic environment. Parallel virtual worlds can span the entire real world, and players from all over the world can interact and perform various game goals in parallel virtual worlds by navigating in the real world and performing actions. Some location-based applications can also provide multi-user activities. In the example of parallel reality games, players with similar positions can play together in the same physical location in the real world, such as by participating in organized group game actions (e.g., live game actions associated with specific geographic locations). However, outside the planned application functions (e.g., game actions), application users with similar positions can cross the path in the physical world during their daily lives without realizing each other. For example, two players of parallel reality games can walk past each other in a public space while carrying their respective mobile devices used to play parallel reality games. In this way, application users may not realize the user groups they encounter and the opportunities for dynamic interaction. Summary of the invention

[0003] Methods, systems, and computer-readable storage media for proximity detection between client devices associated with users of location-based applications are disclosed. A user's client device can detect client devices associated with other users that are within proximity of the client device. Proximity detection of other client devices can result in application functionality corresponding to the detection (e.g., game actions in a location-based parallel reality game), such as the exchange of application data (e.g., game data between players or their client devices, game progress for players, access to game features, or establishing connections between players). In an embodiment, using a client device (such as The player device may perform detection of the client device by connecting to a personal area network device (e.g., a Wi-Fi Direct device or a Wi-Fi Direct device). In the same or different embodiments, proximity detection may occur when the client device is disconnected from an online system hosting a location-based application. In this case, the player device may store proximity detections of other client devices and provide information describing the detections to the online system after connecting to the online system (e.g., via the Internet). The online system may then perform application functions (e.g., game actions) based on the received information describing the proximity detections.

[0004] In some embodiments, a first client device detects a second client device within proximity 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 the 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 if the user wants to participate in a raid with nearby players. The first client device receives user input indicating that the first player has selected the notification, and in response, the first client device provides the multiplayer activity of the location-based application.

[0005] In some embodiments, the first client device detects the second client device via the 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 broadcast network range of each other, but within an enhanced range of each other. The first client device detects the second client device within a second proximity (e.g., within The first client device receives data from the third client device indicating that the third client device has detected that the second client device is within a third proximity of the third client device. For example, the third client device may be located between the first client device and the second client device and within the broadcast range of both of them. 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. For example, the first client device may use a player identifier of a player using the second client device and a timestamp of a Bluetooth LE advertisement broadcast by the second client device to determine an excess-threshold likelihood that the second client device is within the first proximity of the first client device at substantially the same time as the time identified in the timestamp (e.g., within five minutes before or after the time identified in the timestamp).

[0006] These and other features, aspects and advantages may be better understood with reference to the following description and the appended claims. The accompanying drawings illustrate specific embodiments and, together with the description, are used to explain various principles. However, the accompanying drawings should not be considered limiting. Instead, the scope of protection should be determined by the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 is a block diagram illustrating a computing environment for a location-based gaming system according to one embodiment.

[0008] Figure 2 According to an embodiment Figure 1 A block diagram of the client device is shown in FIG.

[0009] Figure 3 According to an embodiment Figure 1 A block diagram of a game server is shown in .

[0010] Figure 4 is a conceptual illustration of a scheme for extending the range of device proximity detection according to one embodiment.

[0011] Figure 5 is a flow chart illustrating a method for device proximity detection according to one embodiment.

[0012] Figure 6 is a flow chart illustrating a method for trading gaming items using device proximity detection, according to one embodiment.

[0013] Figure 7 is a flow chart illustrating an embodiment of a method for coordinating multi-player activities for devices detected as being within proximity of each other.

[0014] Figure 8 is a flow chart illustrating an embodiment of a method for detecting that a second client device is within proximity of a first client device.

[0015] Fig. 9 is a diagram showing an embodiment of the invention applicable to Figure 1 A block diagram of an example computer used in the computing environment of FIG. DETAILED DESCRIPTION

[0016] Reference will now be made to a number of embodiments, examples of which are shown in the accompanying drawings. Note that, wherever practicable, similar or similar reference numerals are used in the accompanying drawings to indicate similar or similar functions. In addition, where similar elements are identified by reference numerals followed by letters, individual references to the numerals in the subsequent specification may refer to all such elements, any one such element, or any combination of such elements. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods may be employed without departing from the principles described.

[0017] Reference will also be made to a parallel reality gaming system to describe one context in which proximity-based functionality (e.g., multi-player augmented reality activities) may be triggered. However, the described proximity detection and functionality triggered by proximity detection may be extended to suitable multi-user online applications. Examples of multi-user online applications include, but are not limited to, social networks, educational programs, group health and fitness activities, multi-user games, or any suitable multi-user activity facilitated over a wireless network.

[0018] Exemplary Location-Based Parallel Reality Gaming System

[0019] Various embodiments 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 parallels 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 the present disclosure may be equally applicable to other location-based applications, such as other types of games or interactive applications.

[0020] Figure 1 1 is a block diagram showing an embodiment of a computing environment for a location-based gaming system 100. In the embodiment shown, the location-based gaming system 100 provides for the interaction of multiple players in a virtual world having a geographic environment parallel to the real world. In particular, geographic areas in the real world can be directly linked or mapped to corresponding areas in the virtual world. Players can move around in the virtual world by moving to various geographic locations in the real world. For example, the system 100 can track the positioning of the player in the real world and update the positioning of the player in the virtual world based on the current positioning of the player in the real world. For example, a coordinate system (e.g., longitude and latitude) in the real world can be mapped to a coordinate system (e.g., x / y coordinates, virtual longitude and latitude, etc.) in the virtual world.

[0021] exist Figure 1 In the embodiment shown in FIG. 1 , the system 100 has a client-server architecture in which a game server 110 communicates with one or more client devices 120 via a network 130. Figure 1 1, three client devices 120 are shown, but any number of client devices 120 may be connected to the game server 110 via the network 130. In other embodiments, the distributed location-based gaming system 100 includes different or additional elements. Furthermore, functionality may be distributed among the elements in a manner different from that described.

[0022] The game server 110 hosts the general state 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 real-world conditions, changes in game state 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), which the player's client device 120 sends to the game server 110 in conjunction with the player's input. In some embodiments, the game server hosts multiple location-based games, other types of games, or other applications.

[0023] In various embodiments, the game server 110 processes game actions based on client devices 120 detecting each other in the real world. The game server 110 receives information from the client devices 120 indicating that the client device 120 (e.g., client device 120A) is in proximity to 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 a player username or ID or a device ID. The following references to the client devices 120 and Figure 2 The game server 110 also performs various game actions based on information received from the client device 120 describing the detection of another client device 120. Figure 3 Various embodiments of game actions and game servers 110 based on device proximity detection are described in more detail.

[0024] Client device 120 is a computing device that a player can use to interact with game server 110. For example, client device 120 may be a smart phone, a portable gaming device, a tablet computer, a personal digital assistant (PDA), a cellular phone, a navigation system, a handheld GPS system, or other such device. Figure 1 Only three client devices (i.e., client device 120A, client device 120B, and client device 120C) are depicted in the figure, but the location-based gaming system 100 may include any number of client devices 120. The client devices 120 execute software (such as a client game application) associated with a location-based game hosted by the server 110 to allow players to interact with the virtual world. The client devices 120 may also include hardware, software, or both for providing a user interface for a chat room. The client devices 120 are configured to detect other client devices 120 when the devices are in proximity to each other in the physical world (i.e., device proximity detection). In an embodiment, the client devices 120 perform proximity detection using a personal area network (PAN) device and an associated communication protocol (e.g., Bluetooth, ZigBee, infrared, ultra-wideband, near field communication, Wi-Fi Direct, etc.). The client devices 120 may store information describing the detection of other client devices 120 in the physical 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). The client device 120 may provide the stored information corresponding to the detection to the game server 110. Figure 2 Various embodiments of client device 120 are described in further detail.

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

[0026] The network 130 may 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 may also include a direct connection between the client 120 and the game server 110. Typically, the communication between the game server 110 and the client 120 may be carried via a network interface using any type of wired and / or wireless connection, using various 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).

[0027] Figure 2 yes Figure 1is a block diagram of one embodiment of a client device 120A shown in . Client device 120A is associated with a player of a parallel reality game. Other client devices (e.g., client device 120B and client device 120C) have the same or similar architecture and are associated with other players of the parallel reality game. Because the gaming system 100 is used for location-based gaming, the client device 120 is preferably a portable computing device (such as a smart phone or other portable device) that can be easily carried or otherwise transported by the player. Players 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 gaming module 220, a user interface module 230, a device detection data repository 240, and a local data repository 250. In other embodiments, the client device 120A includes additional components or is associated with Figure 2 Components that are different from those depicted in .

[0028] As the player moves around in the real world with the client device 120A, the device proximity module 210 detects other client devices 120 that fall within the proximity of the client device 120A (i.e., the player device) associated with the player of the location-based game. In some embodiments, the device proximity module 210 includes a PAN device. In these embodiments, the PAN device broadcasts information describing the broadcasting client device 120 or a player associated with the broadcasting client device 120, so that another client device 120 within the proximity of the broadcasting client device 120 can receive the broadcast information. In addition, 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 can use one or more channels to continuously broadcast a notification data packet including a universally unique identifier (UUID) corresponding to the Bluetooth LE device, and broadcast a message including an identifier of the player (e.g., a player ID or user name). As described above, the Bluetooth LE device can periodically or continuously listen to one or more channels used to broadcast the notification data packets.

[0029] In the same or different embodiments, upon detecting another client device 120, device proximity module 210 stores information describing the detection in device detection data store 240. In particular, device proximity module 210 stores information identifying the player received by the PAN device or other contextual information, such as a timestamp indicating when the detection occurred. Device proximity module 210 provides information corresponding to the device detection to game module 220. In an alternative embodiment, device proximity module 210 provides information corresponding to the device detection directly to game server 110.

[0030] In some embodiments, the device proximity module 210 verifies that a particular device proximity detection satisfies one or more criteria before storing information describing the device proximity detection in the device detection data repository 240 or 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 embodiment, the device proximity module 210 verifies that the detected client device 120 or the player associated with the detected client device 120 has not been detected in a previous time interval (e.g., previous hour, previous day, previous week, etc.). For example, a location-based game may perform a game action only once per time interval based on proximity detection of the same client device 120. In this way, a location-based game may prevent multiple or frequent game actions for two players over a period of time or otherwise detect each other multiple times in some time intervals, with the client devices 120 of the two players being in the same physical location. By verifying that device proximity detections satisfy one or more criteria, device proximity module 120 prevents duplicate storage of proximity detections that will not result in additional gaming action after being provided to game server 110. In an alternative embodiment, device proximity module 210 stores information describing all device proximity detections, and the device proximity detections are instead verified by game module 220 or game server 110 based on one or more criteria as described above.

[0031] The device proximity module 210 can implement range enhancement for proximity detection. The enhanced range can be the distance between two devices that is greater than the local network or PAN broadcast range. The LE network range is approximately 60 meters in radius, and another device 110 meters away may not be within the range of the device. The device proximity module 210 implements range enhancement, which enables another device to be within the proximity of the device. In order to achieve range enhancement, the device proximity module 210 can detect another device (e.g., device 120B) within its 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 another device (e.g., device 120C) within the network broadcast range of client device 120B but not within the network broadcast range of client device 120A. In this example, client device 120C is within the enhanced range of client device 120A. In addition, the device proximity module 210 determines that client device 120A, client device 120B, and client device 120C are close to each other.

[0032] The enhanced range can be a multiple of the broadcast network range. For example, two devices can be within range (e.g., 60 meters), and a third device may be 60 meters from one device but 120 meters from another device (e.g., in a range similar to Figure 4 ). Following this example further, devices can be within 180 meters of each other while being within enhanced range of each other: a fourth device is within 60 meters of the third device but 180 meters 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 for the first device to determine that the fourth device is within its enhanced proximity. The maximum distance of the enhanced range can be pre-configured or dynamically adjusted based on a threshold number of players detected as being within enhanced range of each other. For example, the enhanced proximity range can be increased until at least a threshold number of devices are within the enhanced proximity range or the maximum enhanced range is reached. Thus, players in more sparsely populated areas can have a greater enhanced range than players in more densely populated areas.

[0033] In some embodiments, client device 120A may receive proximity information of another device, determine that the other device is outside of an enhanced range, and determine that the other device is not close. For example, a client device may annotate proximity information passed from device to device with a number indicating how many times the data has jumped from device to device (e.g., a device increments a number it receives before passing the number to another device). A client device may use a maximum number of hops to determine that a device is located further than the enhanced range (e.g., a maximum enhanced range of 30 meters may be equal to a maximum number of hops of 3).

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

[0035] Device proximity module 210 may broadcast information about client device 120A or devices within proximity of client device 120A to other devices. Device proximity module 210 may broadcast a list of devices within proximity of client device 120A. In some embodiments, the list may include enhanced proximity or non-enhanced proximity (e.g., The client device may automatically determine whether to broadcast a list of devices within the enhanced proximity or a list of devices within the unenhanced proximity based on the number of players within the unenhanced proximity. In a crowded area where the number of players within the broadcast range is greater than a threshold number, the client device may determine to limit the list of devices to those within unenhanced proximity (e.g., to prioritize multiplayer activity with players in close proximity). In sparsely populated areas (eg, rural areas) where the number of players within broadcast range is below a threshold number, the client device may determine a list of devices that share the enhanced proximity.

[0036] Device proximity module 210 may determine the likelihood that another client device is within proximity of client device 120A. Device proximity module 210 may use information provided within broadcast messages sent from nearby devices (e.g., LE announcements) to determine the likelihood. The information may include a timestamp at which the announcement was generated, a hardware identifier of the device that generated the announcement, the device type, the device manufacturer, device movement data (e.g., accelerometer data), device capabilities, or any other suitable information about the device or broadcast metadata. The device proximity module 210 can use information provided within a message generated by a location-based gaming application that includes information related to the game. For example, a device proximity module of a nearby client device can generate a message that includes a player identifier and the player's intent to participate or not participate in a multi-player activity with a proximate player. The generated message can then be sent to nearby devices via a local area network or a personal area network.

[0037] The device proximity module 210 may receive data indicating that another client device has detected one or more other client devices within proximity or enhanced proximity. In some embodiments, 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 timestamp may indicate when the corresponding broadcast message was generated or sent. The broadcast message may be a local or personal area network broadcast message. The device proximity module 210 may compare the first timestamp with the second timestamp. In response to determining that the first timestamp is within a threshold time range of the second timestamp, the device proximity module 210 may determine that the second client device is within proximity or enhanced proximity of the first client device.

[0038] The device proximity module 210 can use the broadcast message data and a model (e.g., a rule-based model, a machine learning model, a statistical model, or any suitable prediction algorithm) to determine the likelihood that devices are close to each other. In one example, the device proximity module 210 applies a machine learning model that is trained on broadcast message data for two or more devices that are marked as being close to each other. The device proximity module 210 can 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, and accelerometer data). Therefore, a machine learning model can be trained to determine that two devices that broadcast messages with substantially similar timestamps, but one device is moving at 10 kilometers per hour and one device is stationary, may have a probability of less than 10% of being close to each other.

[0039] In some embodiments, game server 110 uses the information sent by client device to game server 110 to promote device proximity detection. For example, client device 120A can send a broadcast message received from a proximity device to game server 110. Then, game server 110 can use the content of the message to determine the possibility that the device is in proximity to each other. In one example, game server 110 receives broadcast messages from multiple client devices, and uses the timestamp of the broadcast message and the player identifier provided in the broadcast message to determine that the device is in proximity to each other, and game server 110 sends instructions to initiate actions (for example, in-game item transactions) to corresponding client devices. In order to determine that the device is indeed in proximity to each other, game server 110 can determine that the timestamp lists substantially similar times (for example, within one minute of each other). However, in response to determining that the timestamp does not list substantially similar times (for example, more than one minute of each other), game server 110 can determine that the devices are not close to each other.

[0040] In a first example of determining that devices are not close to each other based on timestamps, a client device or a game server receives a local or personal area network broadcast message from two or more client devices. A device proximity module hosted on a client device can perform this determination. The client device or the game server compares the timestamps of the broadcast message (e.g., to compare when the broadcast message was generated or sent). In response to determining that the timestamp is within a threshold time range or duration (e.g., the time difference between the earliest timestamp and the latest timestamp is less than one minute), the client device or the game server determines that the devices associated with the compared timestamps are within proximity to each other. Then, the client device or the game server can notify the client device associated with the compared timestamps that the devices are within proximity to each other (e.g., a message listing device identifiers or player identifiers and a binary flag indicating that the devices are within proximity to each other or enhanced proximity).

[0041] In a second example of determining that devices are not in proximity to each other based on timestamps, a player's client device receives a message from another device. A notification that the other device had been at the player's current location ten minutes ago but has since moved away, but the notification is still communicated by retaining a local device that maintains a list of devices that were determined to be in proximity at a certain time. In this example, the player's client device or a game server that has forwarded the broadcast information from the player's client device can determine that the timestamp indicating that the notification was broadcast ten minutes ago exceeds a threshold time duration of one minute since the broadcast, and determine that the other device is no longer within proximity.

[0042] The game module 220 operates a client-side game application for a parallel reality game hosted by the game server 110. In an embodiment, the game module 220 communicates information about the virtual world with the user interface module 230, such as to display content associated with the virtual world. The game module 220 also receives or obtains game data from the game server 110. For example, the game module 220 can receive game data from the game server 110 that describes available game content based on the location of the client device 120 (e.g., game items), the geographic location of devices associated with other players, or an upcoming group event (e.g., a competitive tournament). In the same or different embodiments, the game module 220 sends information describing device proximity detection performed by the device proximity module 210 or stored in the device detection data repository 240 to the game server 110. In this case, the game module 220 receives or obtains game data from the game server 110 that describes one or more game actions based on the information describing the device proximity detection provided to the game server 110 by the game module 220. Reference is made below Figure 3 Describes game actions based on device detection in more detail.

[0043] In some embodiments, the game module 220 sends information describing device detections to the game server 210 based on the occurrence of certain events. 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 can store information describing any device detections that occurred during the time period when the game module 220 was disconnected. In this case, after the game module 220 reconnects to the game server 110 (e.g., through the network 130), the game module 220 can send some or all of the device detections that occurred during the time period. As another example, the game module 220 can send information describing one or more device proximity detections in response to certain user interactions with the client device 120, such as 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 can manually indicate a desire to provide the stored device detections through user interactions with the client device 120. In the same or different embodiments, game module 220 periodically provides information describing one or more stored device detections to game server 110, such as at predetermined time intervals (eg, every minute).

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

[0045] In an offline mode of a location-based game (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 The game module 220 may transmit the player's data (e.g., avatar appearance, gameplay statistics, gameplay inventory, etc.) to the game module of another client device, where the other game module may display the player's data via the user interface module of the other client device. When the client device 120A is online again (e.g., connected to the game server 110 via the network 130), the game module 220 may upload the game data generated at the client device 120A during the offline gameplay to the game server 110.

[0046] The game data communicated by the game module 220 may include player status information indicating their availability to participate in the multi-player activity. The status information may indicate that the player does not want to participate in the multi-player activity, wants to participate in the multi-player activity, is currently participating in the multi-player activity and can accept additional players, is participating in the multi-player activity and cannot accept additional players, or any suitable status to enable another game module to facilitate the multi-player activity between two or more players. After the device proximity module 210 determines that another client device is within the proximity of the client device 120A or was within the proximity of the client device 120A, the game module 220 may request the status information of the other client device and begin facilitating the multi-player activity based on the received status information.

[0047] In one example of coordinating multiplayer activities, client device 120A is offline from game server 110 and is currently within the Bluetooth range of client device 120B, as determined by device proximity module 210. Game module 220 sends a request for status information to client device 120B. Game module 220 uses the received status information to determine that client device 120B is not currently participating in multiplayer activities, but the corresponding player may want to participate in the multiplayer activities. In response, game module 220 sends a multiplayer activity invitation to client device 120B, wherein the invitation is used as a request for the availability of multiplayer activities for players involving client device 120A and client device 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 can also send game data of multiplayer activities to client device 120B).

[0048] In another example of coordinating multiplayer activities, client device 120A is currently online but is offline when device proximity module 210 detects that client device 120A is within proximity of client device 120B. In addition, the player did not participate in the location-based game at an earlier time (e.g., client device 120A is in the player's backpack or the player watches a movie downloaded to their device instead of playing a location-based game). At an earlier time, game module 220 requests status information from client device 120B, and the status information indicates that client device 120B is currently participating in multiplayer activities (e.g., with client device 120C) and accepts additional players. Since the player of client device 120A did not participate in the location-based game at an earlier time, the player does not participate in the multiplayer activity in real time. However, when client device 120A returns online and can download game data from game server 110, game module 220 can record the identifier of the multiplayer activity or other suitable metadata of the multiplayer activity (e.g., timestamp, location, identifier of the player involved in the multiplayer activity, etc.) for further access to the game data of the multiplayer activity.

[0049] Alternatively or additionally, the game module 220 can download the game data of multi-player activities from the client device 120B when it is in the proximity with the client device 120B. At present, the game module 220 provides the notification that the multi-player activities are now available to the player. For example, the game module 220 can regard the real player as a non-player character, and recreate the gameplay as if the player of the client device 120A is participating in the live game play. When the device is in the proximity of each other, the device can exchange the game data related to the multi-player activities (for example, the player identifier, the information of the game items that can be used by other players (such as damage statistics), or any other suitable information for promoting the multi-player activities). The client device can query the game server 110 about the additional data of other players associated with the proximity device (for example, querying when their connection to the network 130 is returned). For example, the client device 120A can use the player identifier associated with the player of the client device 120B to query the game server 110 for the history of the actions that the player of the client device 120B has been performed during the multi-player activities. Game data received while the devices are within proximity of each other, additional game data queried from game server 110, or a combination of both can be used by game module 220 to recreate or simulate gameplay of other players regardless of the current proximity of client device 120A to other client devices. For example, game module 220 can use geo-fences associated with points of interest (e.g., landmarks or other geographic locations) to determine one or more players to recreate or simulate gameplay with the one or more players. In response to a player selecting a notification indicating that they are interested in participating in a multi-player activity, game module 220 provides the multi-player activity to the player (e.g., at a display of client device 120A).

[0050] 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 embodiments, the user interface displays a depiction of the virtual world to the user, including components of the virtual world, such as virtual elements and virtual experiences, as received from the game module 220. The user interface module 230 can also display chat room locations in the virtual world, and messages sent between users in the chat room. The user can interact with the client device 120 to participate in virtual elements, participate in virtual experiences, or talk in the chat room. For example, the user interface module 230 can display a view of the virtual world depicting points of interest, chat rooms, and other virtual experiences. The user of the client device 120 can interact with these components via the user interface to complete tasks, join chat rooms, or participate in competitions, etc.

[0051] In some embodiments, 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 indicating that another client device 120 has been detected and information related to the detection, such as the player ID of the player associated with the detected device or the time when the detection occurred. In the same or different embodiments, the user interface module 230 provides elements that allow a user of the client device 120 to determine what has occurred based on proximity detection of other client devices. 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 describing device proximity detection stored in the device detection data repository 240, viewing device proximity detection stored in the device detection data repository 240, or selecting from possible game actions based on proximity detection. In particular, the user interface module 230 may provide an interface including elements for initiating proximity detection, such as a "search for other players" element (e.g., button).

[0052] The user interface module 230 may provide user input for participating in a multiplayer activity of a client device that is close to the client device 120A. The user interface module 230 may provide a notification of an available multiplayer activity, wherein the notification may include game data describing the activity or a player that is arranged to be involved in the activity. The notification may be a push notification provided at the client device 120A when the client device 120A is not executing a location-based application. For example, the notification may appear in the notification bar of the user's smart phone. As another example, the user interface module 230 causes the push notification to pop up to appear on other applications executed on the client device 120A. The user may select the push notification and cause the client device 120A to launch a location-based application and participate in the multiplayer activity. The notification may be an invitation to join the multiplayer activity. In response to the device proximity module 210 detecting another device within the range of the client device 120A and in response to the game module 220 determining that the status information received from the other device indicates that another player wants to participate in the multiplayer activity, the notification may be displayed by the user interface module 230. The user interface module 230 may receive a user input (e.g., a "join now" button of the displayed notification) that selects the displayed notification. In response to receiving the user input, the game module 220 may provide a multi-player activity.

[0053] The device detection data repository 240 is one or more computer-readable media configured to store information describing the device proximity detection by the client device 120. The information stored by the device detection data repository 240 can be received from the client device 120 or otherwise obtained or determined by the game server 110. In an embodiment, the device detection data repository 240 stores at least an identifier of a player associated with a device detected based on the device proximity detection. The device detection data repository 240 can also store contextual information describing the device proximity detection, such as a timestamp indicating when the device proximity detection occurs or a geographic location indicating where the device proximity detection occurs (e.g., GPS coordinates). In some embodiments where the game server 110 hosts multiple games, the device detection data repository 240 stores information describing one or more games corresponding to a given device proximity detection (e.g., game name or identifier). In another embodiment, the device detection data repository 240 stores security information to prevent inaccurate or deceptive proximity detection, the duration of proximity detection (e.g., the amount of time another device is detected) or other information describing a player or device related to proximity detection.

[0054] The local data repository 250 is one or more computer-readable media configured to store data used by the client device 120. For example, the local data repository 250 can store player location information tracked by the positioning device 210, a local copy of the current state of the parallel reality game, or any other appropriate data. The local data repository 250 can also store player settings or preferences, such as the preferences of the player to join multi-player activities, which can be used by the game module to determine whether multi-player activities should be promoted between two proximity devices. Although the local data repository 250 is shown as a single entity, the data can be divided across multiple media. In addition, the data can be stored elsewhere (e.g., in a distributed database) and accessed remotely via the network 130.

[0055] Figure 3 One embodiment of a game server 110 hosting a location-based parallel reality game is shown. In the embodiment shown, the game server 110 includes a general game module 310, a game action module 320, and a game database 330. In other embodiments, the game server 110 includes different or additional elements. In addition, the functions can be distributed between the elements in a different manner than described.

[0056] The game server 110 may be configured to receive a request for game data from one or more client devices 120 (e.g., via a remote procedure call (RPC)), and to respond to the request via the network 130. For example, the game server 110 may encode the game data in one or more data files and provide the data files to the client devices 120. In addition, the game server 110 may be configured to receive game data (e.g., player positions, player actions, player inputs, etc.) from one or more client devices 120 via the network 130. For example, the client devices 120 may be configured to periodically send player inputs, player positions, and other updates to the game server 110, which the game server 110 uses to update the game data in the game database 330 to reflect the changed conditions for the game. The game server 110 may also send game data, such as other player positions, chat room positions, or virtual element positions, to the client devices 120.

[0057] The universal game module 310 hosts the location-based game for the player and serves as the authoritative source for the current state of the location-based game. The universal game module 310 receives game data (e.g., player input, player position, player action, player state, landmark information, etc.) from the client device 120 and incorporates the received game data into the entire location-based game for all players of the location-based game. Using the game data, the universal game module 310 stores the total game state of the game, which can be sent to the client device 120 to update the local game state in the game module 220. The universal game module 310 can also manage the delivery of game data to the client device 120 via the network 130.

[0058] The game action module 320 may be part of or separate from the general game module 310. The game action module may also be generally referred to as an application action module (e.g., an application for fitness or social networking that does not necessarily facilitate playing games and exchanging game data). The game action module 320 is configured to perform game actions based on proximity detection performed by the client device 120. The game action module 320 receives information describing the proximity detection from the client device 120. Using the received proximity detection information, the game action module 320 performs a game action that creates, modifies, or otherwise processes game data. The game action module 220 may provide game data to the client device 120 based on the game action performed, such as the client device 120 that provides the proximity detection information to the game action module 320 that caused the game action. For example, the game action module 320 performs a game action that processes game data (e.g., associated with a player's profile or account) corresponding to a player of a location-based game, such as any combination of game data described below with reference to the game database 330 (e.g., game data of types (1) to (9)). 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 action.

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

[0060] In various embodiments, the game action module 320 performs a game action that processes the game data of one or two players corresponding to the device proximity detection. In some embodiments, the game action module 320 performs a game action for a player associated with the client device 120, and the client device 120 (i.e., the detection device) provides information describing the proximity detection. For example, if the client device 120A provides information describing the device proximity detection of the client device 120B, the game action module 320 can perform a game action that affects the game data for the player associated with the client device 120A. Such a game action may include a game action module 320 that provides a game item as a reward to the player, provides a game experience to the player (e.g., upgrades the game character associated with the player), recommends that the player send a friend request to other players, or other game actions specific to the player. As another example of a game action performed by the game action module 320 in response to the proximity detection provided by the client device 120, the game action module 320 can provide a notification of multi-player activity to client devices detected as being within the proximity of each other. If both users select the notification and indicate that they would like to participate in the multi-player activity, the game action module 320 may provide the multi-player activity to proximate client devices.

[0061] In the same or different embodiments, the game action module 320 performs a game action that processes the game data of the player associated with the detected device (e.g., the client device 120B in the previous example). The game action module 320 can perform a game action for the player associated with the detected device, which is the same or different from the game action performed for the player associated with the detection device. In another same or different embodiment, the game action module 320 performs a game action that processes the game data of both the player associated with the detection device and the player associated with the detected device (e.g., the client device 120A and the client device 120B in the above example). The game action performed by the game action module 320 that affects the game data of two players may include exchanging game elements (e.g., game items, images, messages, game states, etc.) between players, providing game elements from one player to another player, initiating an in-game event (e.g., fighting) for two players in the player, adding a player to an existing augmented reality experience in which another player has participated, updating a map in the game associated with one or both players in the player, or providing information describing the relative player for establishing a connection between players.

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

[0063] In some embodiments, the game action performed by the game action module 320 is an exchange of game items between two players of a location-based game (i.e., a game item transaction). For example, in response to receiving information describing a 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 one or more game items associated with the second player. In one embodiment, players can specify one or more game items (e.g., game items associated with their player profile or account) that they wish to trade with other players. As an example, when device proximity detection occurs, players can select from a collection of game items they have collected by playing location-based games to be added to a group of game items that can be traded with other players. The selection can 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 a game server 110. Then, the game action module 320 can perform a transaction between the two players when one or both of the client devices 120 associated with the two players detect another 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 may exchange one or more game items for a player associated with client device 120A and a player associated with game client device 120B. In exchanging game items, the game action module 320 updates the game data in the game database 330. The game action module 320 may additionally or alternatively communicate with the general game module 310 to perform a game item transaction or to communicate that a game item transaction has occurred. In an embodiment, the game action module 320 provides a notification for display to one or both of the client devices 120 involved in the game item transaction indicating that a transaction has occurred or describing the details of the transaction.

[0064] In various embodiments, the game action module 320 performs additional processing to perform game item transactions. In one embodiment, the game action module 320 determines or identifies a value associated with a game item, which is designated for trading by a player corresponding to device proximity detection. The value for the game item may correspond to the characteristics of the game item, the price for the game item in real money or in-game currency, other indicators of the game item value, or some combination thereof. The game action module 320 uses the value of the game item to select one or more game items for each player corresponding to device proximity detection to trade. For example, the game action module 320 may exchange game items with the same value or with values ​​that differ within a trading threshold. Other examples of information that the game action module 320 may consider when performing transactions between players include associations between players in location-based games (e.g., whether the players are friends, whether they are both associated with an organization (such as a team, etc.) in the game), or characteristics of the game item (e.g., game item type).

[0065] The game database 330 includes one or more machine-readable media configured to store game data used in the location-based game, which is to be delivered or provided to the client device 120 via the network 130. In an embodiment, the game data stored in the game database 330 may include: (1) data associated with the virtual world in the location-based game (e.g., image data used to render the virtual world on a display device, geographic coordinates of locations in the virtual world, etc.); (2) data associated with players of the location-based game, such as player profiles or account data (e.g., player information, player experience level, player currency, player inventory, current player location in the virtual world / real world, player energy level, player preferences, team information, etc.); (3) data associated with game objectives (e.g., data associated with the current game objective, the state of the game objective, past game objectives, future game objectives, expected game objectives, etc.); (4) data associated with virtual elements in the virtual world (e.g., the location of the virtual element, the type of virtual element, the game objective associated with the ... The game database 330 may include data associated with real-world objects, landmarks, locations linked to virtual world elements (e.g., locations of real-world objects / landmarks, descriptions of real-world objects / landmarks, relevance of virtual elements linked to real-world objects, etc.); (6) game state (e.g., number of current players, state of current game objectives, player leaderboards, etc.); (7) data associated with player actions / inputs (e.g., current player locations, past player locations, player movements, player inputs, player queries, player communications, etc.); (8) data associated with virtual experiences (e.g., locations of virtual experiences, player actions related to virtual experiences, virtual events such as team battles, etc.); and (9) any other data used, related to, or obtained during the implementation of location-based games. The game data stored in the game database 330 may be populated by a system administrator offline or in real time or by data received from players, such as data received from one or more client devices 120 via a network 130.

[0066] The game database 330 may also store real-world data. The real-world data may include population density data describing the gathering locations of individuals in the real world; player density data describing the gathering locations of players in the real world; player actions associated with locations of cultural value or commercial value; player heat map data describing the distribution of game actions in a geographic area; point of interest data describing real-world locations corresponding to the locations of virtual elements in the virtual world; terrain data describing the locations of various terrain and ecological conditions, such as large bodies of water, mountains, canyons, etc.; map data providing the locations of roads, highways, and waterways; the current and past locations of individual players; hazard data; weather data; event calendar data; activity data for players (e.g., distance traveled, minutes of exercise, 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 a map database that includes or is 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 periodically provide population data, hazard data, weather data, event calendar data, etc.

[0067] Apart from Figure 3 Other modules outside the modules shown in can be used together with game server 110. Any number of modules can be programmed or otherwise configured to perform the server-side functions described herein. In addition, various components on the server side can be rearranged. According to the present disclosure, other configurations will be apparent, and the present disclosure is not intended to be limited to any particular configuration.

[0068] Figure 4 4 is a conceptual illustration of a scheme for extending the range of device proximity detection according to one embodiment. The conceptual illustration includes an environment in which client device 120A and client device 120C are close to each other with enhanced range. Client devices 120A-120C have respective network broadcast ranges 400, 410, and 420. Broadcast ranges 400, 410, and 420 may be approximately 60 meters. LE broadcast range. Thus, each circle of the broadcast range may have a radius of 60 meters. Client device 120A and client device 120B may be separated from each other by less than 60 meters, and the device proximity modules of each device may use short-range local connection 430 to determine that the two devices are within the proximity of each other. Similarly, client device 120B and client device 120C are within 10 meters of each other, and connection 440 may be used to determine that the two devices are within the proximity of each other. However, client device 120A and client device 120C are outside the broadcast range of each other, and the device proximity modules of each device may not be able to establish a short-range local connection and initially determine that the two devices are not within the proximity of each other. However, the device proximity module of device 120A or device 120C may determine that client device 120B is close to another device, and therefore determine that the other device is within the enhanced range and is indeed close. Client device 120A and client device 120C may form connection 450, which may be facilitated by client device 120B. The device proximity module may request information of proximity 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.

[0069] Device proximity detection method

[0070] Figure 5 1 is a flow chart showing an embodiment of a method 500 for device proximity detection. In the illustrated embodiment, the method 500 is described from the perspective of the client device 120 executing the method 500. Figure 5 However, some or all of the steps may be performed by other entities or components. In addition, some embodiments may perform different steps or some steps in different orders or in parallel.

[0071] exist Figure 5In the embodiment shown in , method 500 begins with a first client device (e.g., client device 120A) scanning 510 a PAN for 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 other client devices 120 for device proximity detection. Based on the scan, the first client device receives 520 an identifier corresponding to an application on the second client device from a second client device (e.g., client device 120B) via the PAN. For example, the first client device may perform proximity detection of the second client device (e.g., using device proximity module 210) by receiving information broadcast by the second client device, the information 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 a device detection data repository 240.

[0072] 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). Based on the first client device's receipt of the identifier, the first client device receives 550 data for the application corresponding to the action performed by the online system. For example, the first client device may receive game data corresponding to the game action performed by the game server 110.

[0073] Figure 6 1 is a flow chart illustrating an embodiment of a method 600 for trading gaming items using device proximity detection. In the illustrated embodiment, the method 600 is described from the perspective of a client device 120 executing the method. Figure 6 However, some or all of the steps may be performed by other entities or components. In addition, some embodiments may perform different steps or some steps in different orders or in parallel.

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

[0075] 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 a game server 110 (e.g., using a game module 220). In response, the first client device receives 650 game data from the online system indicating an exchange of a first game item for a second game item. For example, the first client device may receive a push notification from the game server 110 indicating that an exchange occurred or describing a game item received by the first player.

[0076] Figure 7 1 is a flow chart illustrating an embodiment of a method 700 for coordinating multiplayer activities for devices detected as being in proximity to each other. In the illustrated embodiment, the method 700 is described from the perspective of a client device 120 executing the method. Figure 7 However, some or all of the steps may be performed by other entities or components. In addition, some embodiments may perform different steps or some steps in different orders or in parallel.

[0077] The 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 in proximity of the second client device. The device proximity module of the first client device detects that the second client device is within the Bluetooth broadcast range of the first client device, and therefore the second client device is within proximity.

[0078] The first client device provides 720 a notification of the availability of a multiplayer activity involving a first player and a second player. For example, a game module of the first client device provides a notification for display at the screen of the first client device, the notification including an invitation to participate in a multiplayer activity (e.g., an AR activity) with a second client device. Before providing the notification, the game module may determine whether the second player is available or wants to participate in the multiplayer activity. The game module may send a request for status information to the second client device. The game module may then use the received status 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 notifications for display at the screen of the first client device (e.g., a text string describing the invitation "Another trainer nearby is currently participating in a team battle with other trainers. Do you want to join them?" and a user input button for accepting the invitation).

[0079] The first client device receives 730 a user input indicating a selection of a notification. For example, a user interface module of the first client device displays a notification with a user input element (e.g., a button) at the first client device for the user to select the notification. The user input element can be used to provide approval or rejection of the invitation to join the multiplayer activity.

[0080] The first client device 740 provides a multiplayer activity of a location-based game at the first client device. In one embodiment, in response to receiving a 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 can generate the requested invitation and send the invitation to the game module of the first client device, wherein the invitation can include game data of the multiplayer activity stored locally at the second client device or at the 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 can use the received game data to provide the multiplayer activity at the first client device (e.g., via the user interface module).

[0081] Figure 8 800 is a flow chart illustrating an embodiment of a method 800 for detecting a second client device within proximity of a first client device. Figure 8 steps. Figure 8The steps are shown from the perspective of the client device 120 executing the method 800. However, some or all of the steps may be performed by other entities or components. In addition, some embodiments may perform different steps or perform some steps in a different order or in parallel.

[0082] The first client device detects 810 a third client device within a second proximity 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 the proximity of the first client device. Figure 4 , client device 120A (first client device) may detect 710 client device 120C (second client device) using method 800. Client device 120A detects 810 client device 120B (third client device). Detection 810 may be performed by, for example, This is achieved by connecting to a local network or PAN of LE.

[0083] The first client device receives 820 data indicating that the third client device has detected that the second client device is within a third proximity 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 broadcast device, the broadcast itself, or a combination thereof. Figure 4 In the previous example of the configuration in , client device 120A can receive 820 data from client device 120B, wherein the data includes broadcast information sent by client device 120C to client device 120B or is derived from the broadcast information. Client device 120C sends data within a broadcast message (e.g., a Bluetooth LE announcement), such as an identifier of the device, an identifier of the player, or a timestamp of the transmission. Client device 120B receives the broadcast message from client device 120C and can store the data or derive additional data from the received broadcast message. For example, client device 120B can create a record of the content of the broadcast message and supplement the data of the signal strength at which the broadcast message was received. Client device 120B can then provide data received from other devices about the proximity of the other device, such as the example record, to other devices such as client device 120A. The first client device can receive 820 data in response to requesting data from other client devices within the proximity of its broadcast range. Alternatively or additionally, the first client device may automatically receive 820 data as part of a broadcast message received from other devices announcing their presence. Likewise, the first client device may broadcast data about devices within its proximity to other devices.

[0084] In another example where the first client device receives 820 data indicating that the third client device has detected that the second client device is within a third proximity of the third client device, the third client device uses the timestamp to determine that both the first client device and the second client device are within the proximity of the third client device, and then the third client device sends data indicating this determination to the first client device. Figure 4 In the configuration of FIG. 1 , client device 120B receives local network broadcast messages (e.g., Then, the client device 120B 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 (e.g., a time difference of one minute or less) of each other. In this example, the client device 120B may also have a device proximity module, a game module, and a Figure 2 , which is shown as being hosted on client device 120A. In particular, the device proximity module described herein can be configured to perform this timestamp comparison to determine whether two or more devices are within proximity of each other.

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

[0086] In use Figure 4In one example where the configuration shown in determines that two devices may be within the proximity of each other, client device 120A applies the data received from client device 120B to a statistical model to determine that client device 120C has at least a threshold probability within the proximity of client device 120A. The statistical model can be generated by a first client device or a game server (e.g., game server 110) and stored at the first client device. The first client device can create a statistical model using historical broadcast data received from the client device and verification of proximity. An example of verifying proximity includes confirmation that the confirmation comes from a player confirming to device proximity module 210 that another player is within the enhanced proximity or within the location information provided by game server 110, and the device confirms online that another player is within the enhanced proximity. Client device 120A receives the timestamp of a 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 from client device 120B, and applies the received data to the statistical model. The output of the statistical model is a probability or score of meeting a threshold (eg, a pre-configured threshold) indicating that client device 120C is likely within an enhanced proximity of client device 120A, such as Figure 4 As shown in .

[0087] Fig. 9 is a diagram showing a method suitable for Figure 1 A block diagram of an example computer used in a network computing environment. Specifically, Fig. 9 A diagrammatic representation of a machine in the example form of a computer system 900 is shown. The computer system 900 may be used to execute instructions 924 (e.g., program code or software) for causing the machine to perform any one or more of the methods (or processes) described herein, including those methods associated with and described using components (or modules) of a game server 110 or a client device 120.

[0088] 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 a bridge, a cellular phone tower, or any machine capable of executing instructions 924 (sequentially or otherwise) that specify actions to be taken by the machine. In addition, while only a single machine is shown, the term "machine" should also be understood to include any collection of machines that individually or jointly execute instructions 924 to perform any disclosed method.

[0089] The example computer system 900 includes one or more processing units (generally one or more processors 902). For example, the processor 902 is 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 of these. Any reference to the processor 902 may refer to a single processor or multiple processors. 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.

[0090] In addition, the computer system 900 may include a static memory 906, a display driver 910 (e.g., to drive a plasma display panel (PDP), a liquid crystal display (LCD), or a projector). The 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 instrument), a signal generating device 918 (e.g., a speaker), and a network interface device 820, which are also configured to communicate via the bus 908.

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

[0092] Although the machine-readable medium 922 is shown as a single medium in the example embodiment, the term "machine-readable medium" should be understood to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that can store instructions 924. The term "machine-readable medium" should also be understood to include any medium that can store instructions 924 for execution by a machine and cause 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.

[0093] Although the subject matter has been described in detail with respect to specific exemplary embodiments and methods thereof, it should be understood that those skilled in the art, upon reaching an understanding of the foregoing, may easily produce changes, modifications, and equivalents to such embodiments. Therefore, the scope of the present disclosure is by way of example rather than by way of limitation, and the present disclosure does not exclude such modifications, modifications, or additions to the subject matter that are obvious to those of ordinary skill in the art.

[0094] Additional considerations

[0095] Some parts described above describe embodiments according to algorithmic processes or operations. These algorithmic descriptions and representations are usually used by those skilled in the art of computing to efficiently convey the essence of their work to other skilled in the art. Although these operations are described functionally, computationally or logically, the operations should be understood to be implemented by a computer program including instructions, which are used to be executed by a processor or equivalent circuits, microcodes, etc. In addition, without loss of generality, it is sometimes convenient to refer to these arrangements of functional operations as modules.

[0096] As used herein, any reference to "one embodiment" or "embodiment" means that a particular element, feature, structure or characteristic described in conjunction with the embodiment is included in at least one embodiment. The appearance of the phrase "in one embodiment" in various places in the specification does not necessarily refer to the same embodiment. Similarly, the use of "one" or "a" before an element or component is merely for convenience. This description should be understood to mean that there are one or more elements or components, unless otherwise clearly meant.

[0097] Where a value is described as "about" or "substantially" (or their derivatives), such value should be interpreted as being exactly + / - 10%, unless another meaning is obvious from the context. For example, "about 10" should be understood to mean "within the range of from 9 to 11".

[0098] As used herein, the terms "comprises," "comprising," "including," "including," "having," "having," or any other variation 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 such process, method, article, or apparatus. In addition, unless expressly stated to the contrary, "or" refers to an inclusive or and not an exclusive or. For example, condition A or condition B is satisfied by any of the following: A is true (or exists) and B is false (or does not exist), A is false (or does not exist) and B is true (or exists), and both A and B are true (or exist).

[0099] Upon reading this disclosure, those skilled in the art will appreciate that additional alternative structural and functional designs may be used to employ the described techniques and solutions. Thus, although specific embodiments and applications have been shown and described, it will be understood that the described subject matter is not limited to the precise configurations and components disclosed. The scope of protection shall be limited only by the appended claims.

Claims

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 perform operations comprising: detecting a second client device within proximity of the first client device, the second client device being associated with a second user of the location-based application; responsive to detecting the second client device, providing a notification of the availability of a multi-user activity involving the first user and the second user; receiving user input indicating a selection of the notification; as well as In response to the user input, the multi-user activity of the location-based application is provided.

2. The non-transitory computer-readable medium of claim 1 , wherein the proximity is a first proximity, and wherein 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; as well as Data is received from the third client device indicating that the second client device is within a third proximity of the third client device.

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 wherein the first proximity is greater than the personal area network broadcast range.

4. The non-transitory computer-readable medium of claim 1 , wherein detecting the second client device comprises: An identifier of the second user is received via the local network.

5. The non-transitory computer-readable medium of claim 1 , wherein detecting the second client device comprises: An identifier of the second user is received via a personal area network (PAN).

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

7. The non-transitory computer-readable medium of claim 1, wherein the second client device is detected while the first client device does not have connectivity to an online system hosting the location-based application, and wherein the operations further comprise: Providing the second user's identifier to the online system by: detecting, via a network, that the first client device has connectivity to the online system; receiving the identifier of the second user via a local network or a PAN; as well as The identifier of the second client device is sent to the online system via the network.

8. The non-transitory computer readable medium of claim 7, wherein the operations further comprise: In response to detecting the second client device, the identifier of the second user is stored by the first client device.

9. The non-transitory computer-readable medium of claim 8, wherein storing the identifier of the second user comprises: comparing the identifier of the second user to 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; as well as In response to determining that the identifier of the second user has not been previously stored on the client device within a time interval, storing the user identifier with a current timestamp.

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

11. The non-transitory computer readable medium of claim 1 , wherein the second client device is detected while the first client device does have connectivity to an online system hosting the location-based application, and wherein the operations further comprise: receiving, from the online system, status information indicating whether the second client device participated in the multi-user activity during a time when the second client device was detected; in response to determining, using the state information, that the second client device is participating, requesting, by the first client device, an invitation to join the multi-user activity, the notification including the invitation; as well as In response to determining, using the state information, that the second client device is not participating, requesting, by the first client device, the availability of the multi-user activity involving the first user and the second user. 12 . The non-transitory computer-readable medium of claim 11 , wherein requesting the availability of the multi-user activity comprises determining that the second client device has indicated an intent to join the multi-user activity.

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

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

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

16. 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 perform operations comprising: 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, wherein detecting 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 user of the location-based application; receiving, from the third client device, data indicating that the third client device has detected that the second client device is within a third proximity of the third client device; and The received data is used to determine a likelihood that the second client device is within the first proximity of the first client device.

17. The non-transitory computer readable medium of claim 16, wherein the operations further comprise: responsive to detecting the second client device, providing a notification of the availability of a multi-user activity involving the first user and the second user; receiving, at the first client device, a user input indicating a selection of the notification; as well as In response to the user input, the multi-user activity of the location-based application is provided at the first client device.

18. The non-transitory computer readable medium of claim 16, wherein the second client device is detected while the first client device does have connectivity to an online system hosting the location-based application, and wherein the operations further comprise: receiving, from the second client device, status information indicating whether the second client device participated in a multi-user activity during a time when the second client device was detected; responsive to determining, using the state information, that the second client device is participating, requesting from the second client device an invitation to join the multi-user activity; as well as In response to determining that the second client device is not participating using the state information, initiating the multi-user activity including the first user and the second user in an offline environment by the first client device, wherein application data generated from the multi-user activity in the offline environment is locally stored at one or more client devices of the first client device or the second client device, and the application data is uploaded to the online system when the one or more client devices of the first client device or the second client device have connectivity to the online system.

19. The non-transitory computer readable medium of claim 16, wherein the operations further comprise: sending a first broadcast message to the third client device, the first broadcast message comprising a first timestamp indicating when the first broadcast message was sent; as well as Wherein receiving data indicating that the third client device has detected that the second client device is within the third proximity of the third client device comprises: A timestamp comparison result determined by the third client device is received, 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 when the second broadcast message was sent by the second client device.

20. An online system comprising: a database storing application data for location-based applications; An application action module, wherein the application action module is configured to perform an operation, wherein the operation includes: 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, wherein detecting the second client device comprises: 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 that the second client device is within a third proximity of the third client device, and determining, using the received data, a likelihood that the second client device is within the first proximity of the first client device; responsive to detecting the second client device, providing a notification of the availability of a multi-user activity involving the first user and the second user; receiving, at the first client device, user input indicating a selection of the notification; and In response to the user input, the multi-user activity of the location-based application is provided at the first client device.

Images